EGroupware install error

Apps & App Center
#1

I tried to install EGroupware (again) today on 5.0.7 but failed.

The installation from the appcenter ran without apparent errors, however the join script 50egroupware.inst produced an error.
Digging into tail -f /var/lib/egroupware/egroupware-docker-install.log showed:

/usr/bin/php8.2 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --setup-cmd-database sub_command=create_db 'domain=default' 'db_type=mysqli' 'db_host=172.17.42.1' 'db_port=3306' 'db_name=egroupware' 'db_user=egroupware' 'db_pass=XXXXXXXXX' 'db_root=root' 'db_root_pw=' 'db_grant_host=localhost'
Kann nicht zur mysqli Datenbank mysql auf Rechner 172.17.42.1:3306 als Benutzer root verbinden! (ADOdb::Connect(172.17.42.1:3306, root, $Password, mysql) failed.) (100)
/usr/share/egroupware/setup/inc/class.setup_cmd_database.inc.php (158)

Installation failed --> exiting!

After severl retries using backup server role, updates, etc, I found the solution to be simple. For some reason, the mysql port 3306 is not opened on the host for network connections, so the docker container can not connect.

On the host I executed “ucr set security/packetfilter/tcp/3306/172.16.1.2=ACCEPT” to permit only the docker container IP to connect.

UPDATE: maybe I have some bigger problem that I can not understand so far. After the “successful” install, I can log in as admin, but the GUI does not load properly. Error in the gui:

Ein Fehler ist aufgetreten.

Attempt to assign property "client_debug" on null

/usr/share/egroupware/vendor/egroupware/imap-client/lib/Horde/Imap/Client/Socket.php (4386)

There is no other docker app installed on this server and the docker subnet is not the same as Lan, so I do NOT think this relates to UCS 4.4-3 errata 413 - EGroupware Proxy error

Also, I compared this new install with a test I have made before, installing EGroupware on a single (primary) univention (some 5.0.x version). The install worked there without any problem and without any firewall exceptions.

In the domain, there is a kopano installation currently running. EGroupware should replace kopano.

Any help would be very welcome.

#2

UPDATE 2:
I think that the problem of not being able to load the gui comes from the fact, that because of trying to migrate from Kopano to EGroupware, I have 2 mailservers in the Univention domain.

The mailserver app in Univention uses dovecot with ldap and there uses the filters

user_filter = (&(|(objectClass=univentionMail)(objectClass=univentionMailSharedFolder))(|(!(univentionMailHomeServer=))(univentionMailHomeServer=mail2.familieriess.at))(|(mailPrimaryAddress=%Lu)(&(uid=%u)(|(mailPrimaryAddress=)(uid=Administrator)))))

iterate_filter = (&(objectClass=univentionMail)(|(!(univentionMailHomeServer=))(univentionMailHomeServer=mail2.familieriess.at))(mailPrimaryAddress=))

which makes sure that users are not able to log in to the wrong server.
I will alter the template for now, so that users can exist on both mailservers during migration.

Any comments are more than welcome, I am far from sure about what I am doing here xD

#3

That stops the correct installation, EGroupware installation expects 0 or 1 mailserver in the UCS system!

Can you uninstall the Kopano server, AFTER migrating your mailboxes to UCS Mail app (Dovecot)?

Ralf

#4

The plan is to leave Kopano running for now and slowly migrate to EGroupware.

As far as I can see, EGroupware install did not have a problem, as the Kopano server is not listed when the install of EGroupware uses

/usr/bin/univention-ldapsearch -x “(univentionAppID=mailserver_)" univentionAppInstalledOnServer|sed -n "s/univentionAppInstalledOnServer: \(.\)/\1/p”

The above command correctly returns the one (newly) installed mailserver app that EGroupware is supposed to use. Only afterwards, EGroupware bugs out as Dovecot does not permit access to users that have Kopano set as home mail server.

Once the migration is complete, all users will use the new mailserver as home mail server and I can revert the template change.

#5

Ok, you could also limit the used EGroupware mail account to a group containing the already migrated users, instead of all users.

If Kopano allows IMAP access, you can also use a second profile to give the not yet migrated users access to Kopano.

Ralf

#6

Thank you Ralf.

At the moment it looks like we will give users IMAP access to both mailservers during migration. I’ll have to look into how to route internal and external mails during migration for that to work

Mastodon