2 / 6
Sep 2023

This post is a follow up to How to Setup APCu settings posted in 2018. I am still unclear on how to configure the Admin account in admin/apcu.php. Specifically, what account is ADMIN_USERNAME in:

defaults('ADMIN_USERNAME','apc');                       // Admin Username
defaults('ADMIN_PASSWORD','deadcafebabec79705a0f9d9c4f1b55c');      // Admin Password - CHANGE THIS TO ENABLE!!
!

Is this just for APCu, or is this the admin account from header.inc.php? Do I need to add an apc user as an egroupware account?

One thing is very clear, if you enable apcu and you have not configured admin/apcu.php, egroupware freaks out. Pulling the latest commits seems to have helped. Now with APCu enabled, loading contacts, calendar, files and admin logs only the following:

[Fri Sep 22 22:55:54.261453 2023] [negotiation:error] [pid 45872] [client ::1:36322] AH00690: no acceptable variant: /usr/share/httpd/error/HTTP_NOT_FOUND.html.var
[Fri Sep 22 22:55:55.211039 2023] [fcgid:warn] [pid 45871] [client 192.168.6.104:50586] mod_fcgid: stderr: EGroupware\\Rocketchat\\Hooks::avatar_stat()Rocketchat is not configured!, referer: https://2pi.mysite.com/egroupware/login.php?cd=1&domain=default
[Fri Sep 22 22:56:54.677768 2023] [negotiation:error] [pid 45878] [client ::1:38268] AH00690: no acceptable variant: /usr/share/httpd/error/HTTP_NOT_FOUND.html.var

I don’t use Rocketchat, so I expect it to not be configured. The other negotiation:error is odd, but doesn’t seem to hurt.

Another question, setting apc.shm_size=128M in the site php.ini does not seem to be respected as phpinfo() still shows 32M? With a password set the doesn’t seem to adversely impact operations other than not having as large of a cache. Any other concern?

Thanks for any help!

  • created

    Sep '23
  • last reply

    Sep '23
  • 5

    replies

  • 973

    views

  • 2

    users

  • 3

    links

Hi David,

are you still trying to get EGroupware via docker-compose running, or are back to a conventional webserver install?

The password is NOT necessary for EGroupware operation!
It allows to reset e.g. APCu, like when you restart the egroupware container.

This is simply NOT true, as I wrote above. The APCu status page, does NOT change or enable APCu usage.

This depends on using a container, or not. The containers have an environment variable one can set to get a higher shared memory size.

Ralf

This is the normal install. After our last thread and the “we broke it” revelation, I was waiting a few days before trying docker again. In the mean time I was working with the normal install to learn as much as I could.

If the password doesn’t matter, then the issue was likely either in the commits from the past day or so, or the addition of the zoneinfo information to the mysql table. Those were two changes on either side of enabling APCu where before egroupware was going crazy, and after it seemed just fine. What had me believing you needed to set the password were the comments:

...         // Admin Username
...         // Admin Password - CHANGE THIS TO ENABLE!!!

That part seemed pretty clear. Also for

// (beckerr) I'm using a clear text password here, because I've no good idea how to let
//           users generate a md5 or crypt password in a easy way to fill it in above

At least on Linux a simple printf "the_password" | md5sum works fine :)

To try docker again, do I need to docker rm all the old containers and then rerun the docker compose up -d? I still have everything in the same state we left it in the last thread. I’m eager to get the docker install working. Also, I wasn’t sure what part the “we broke it” applied to? The missing DOCKERFILE link or something else that was preventing getting a response back from the running egroupware docker container?

That’s why I was giving it a couple of days before trying again. So do I need to start back at square 1 on the docker install after removing the existing containers?

Thank you Ralf for all your help!

Uugh, I give, docker hates me. I just did another docker compose up -d and did not remove all old containers first. It seemed to update them all. I left the docker-compose-yml and nginx.conf in there default state and didn’t remove collabra, rocketchat or mongo just to be sure I didn’t screw anything up. swool, collabra and mongo just continually restart, e.g.

# docker ps
CONTAINER ID   IMAGE                                     COMMAND                  CREATED         STATUS                            PORTS                                                                            NAMES
83c905a8b95c   nginx:stable-alpine                       "/docker-entrypoint.…"   7 minutes ago   Up 6 minutes                      0.0.0.0:8080->80/tcp, :::8080->80/tcp, 0.0.0.0:4443->443/tcp, :::4443->443/tcp   egroupware-nginx
4a43163f6098   phpswoole/swoole:latest-alpine            "docker-php-entrypoi…"   7 minutes ago   Restarting (127) 10 seconds ago                                                                                    egroupware-push
759a595ed7d6   egroupware/egroupware:latest              "/entrypoint.sh php-…"   7 minutes ago   Up 6 minutes                      9000/tcp                                                                         egroupware
2d76e66fe161   quay.io/egroupware/collabora-key:stable   "/start-collabora-on…"   7 minutes ago   Restarting (78) 31 seconds ago                                                                                     collabora-key
d884cbdd95d2   rocketchat/rocket.chat:latest             "docker-entrypoint.s…"   7 minutes ago   Up 6 minutes                      3000/tcp                                                                         rocketchat
5f5b77bf6154   mariadb:10.6                              "docker-entrypoint.s…"   7 minutes ago   Up 6 minutes                      3306/tcp                                                                         egroupware-db
2fe420fac406   containrrr/watchtower                     "/watchtower --sched…"   7 minutes ago   Up 7 minutes                      8080/tcp                                                                         egroupware-watchtower
376ff3bb9aee   mongo:5.0                                 "docker-entrypoint.s…"   7 minutes ago   Restarting (132) 1 second ago                                                                                      rocketchat-mongo

There is no way to connect to the host on port :8080 or :4443. Port :8080 seems to get a response, but can’t connect. Firefox reports:

Secure Connection Failed

An error occurred during a connection to 2pi.3111skyline.com:8080. SSL received a record that exceeded the maximum permissible length.

Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

But at least curl localhost:8080 shows something:

$ curl localhost:8080
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.24.0</center>
</body>
</html>

On port :4443, there is just nothing received. :(

I’ll look at this again after some sleep.