ZCP 7.2.1.51838 to Kopano 8.7.0

Albert

hello all,

Currently I am migrating my home server

from zarafa 7.2.1.51838
to the kopano version 8.7.0 as distributed in Debian 10 buster.
Both old and new are a single server, no LDAP just DB

I used

On a fresh (empty) harddisk I installed debian/kopano. All /etc/kopano configs are comparable to the old /etc/zarafa settings and no major differences from the defaults.
From the old install I made an mysqldump.

Prefered

I would like to keep the default settings, so also the default naming of the database (from zarafa to kopanoserver). Therefore I did an mysqldump from the old environment and want to import that on the new environment.

However I see some differences in between the old and new structure:

a lot of new tables now have DEFAULT 0 instead of DEFAULT ‘0’.
I guess this better fits the unsigned type?
a lot of new tables now have CHARSET=utf8mb4 instead of CHARSET=utf8.
table clientupdatestatus has been removed in the new version
table ‘names’, column ‘namestring’ is shortened to 185
table ‘names’ has new keys ‘gni’ and ‘gns’.
Renamed from ‘guidnameid’ and ‘guidnamestring’?
table ‘singleinstances’ has new column ‘filename’
table ‘versions’ has new column ‘micro’ and primary key includes ‘micro’ too
procedures now have DEFINER=‘kopano-server’ instead of DEFINER=‘zarafa’.
I guess the changed mysql-username for kopano-server?
procedures now use decimal numbers for ‘tag’ instead of hexadecimal.
No problem, assuming ‘mvproperties.tag-34049’ is a minus-calculation and
not an column-name with a minus in its name?

I expect SQL-errors when I import the data in the new structure, expecially where the new table-structure does not match the old one.

Questions:

is there some kind of database-conversion program that I should run first?

Actual

I imported the old database as is in MariaDb. It is named zarafa instead of kopanoserver.
I granted mysql user kopano-server all permissions for database zarafa.

However, I see some things that worry me:

not all my calendar-entries are shown, but a webapp-search shows they are there
systemctl start kopano-server gives error messages

Dec 16 17:02:43 defiant kopano-server[22182]: Listening for pipe connections on /var/run/kopano/server.sock
Dec 16 17:02:43 defiant kopano-server[22182]: Reexecing /usr/sbin/kopano-server
Dec 16 17:02:43 defiant kopano-server[22182]: K-1240: Failed to re-exec self: Permission denied. Continuing with standard allocator and/or restricted coredumps.
Dec 16 17:02:43 defiant kernel: [105944.459902] audit: type=1400 audit(1576512163.263:34): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-server" name="/usr/sbin/kopano-server" pid=22182 comm="kopano-server" requested_mask="x" denied_mask="x" fsuid=121 ouid=0
Dec 16 17:02:43 defiant kernel: [105944.462535] audit: type=1400 audit(1576512163.267:35): apparmor="DENIED" operation="open" profile="/usr/sbin/kopano-server" name="/etc/machine-id" pid=22182 comm="kopano-server" requested_mask="r" denied_mask="r" fsuid=121 ouid=0
Dec 16 17:02:43 defiant kopano-server[22182]: Connection to database 'zarafa' succeeded
Dec 16 17:02:43 defiant kopano-server[22174]: Starting Kopano server: kopano-server.
Dec 16 17:02:43 defiant kopano-server[22184]: Setting cell cache size: 1073741824

opening calendar in webapp gives errors:

Dec 16 17:06:19 defiant kopano-server[22184]: Accepted incoming connection from file:///var/run/kopano/server.sock
Dec 16 17:06:19 defiant kopano-server[22184]: Error while connecting to search on "file:///var/run/kopano/search.sock"
Dec 16 17:06:20 defiant kopano-server[22184]: Error while connecting to search on "file:///var/run/kopano/search.sock"
Dec 16 17:06:26 defiant kopano-server[22184]: Accepted incoming connection from file:///var/run/kopano/server.sock

systemctl restart kopano-server gives error messages

Dec 16 17:08:54 defiant kopano-server[22486]: Stopping Kopano server: kopano-serverNo /usr/sbin/kopano-server found running; none killed.
Dec 16 17:08:54 defiant kopano-server[22486]:  failed!
Dec 16 17:08:54 defiant systemd[1]: kopano-server.service: Succeeded.
Dec 16 17:08:54 defiant systemd[1]: kopano-server.service: Found left-over process 22184 (kopano-server) in control group while starting unit. Ignoring.
Dec 16 17:08:54 defiant kopano-server[22502]: Audit logging not enabled.
Dec 16 17:08:54 defiant kopano-server[22502]: Starting kopano-server version 8.7.0 (pid 22502 uid 0)
Dec 16 17:08:54 defiant kopano-server[22502]: Using epoll events
Dec 16 17:08:54 defiant kopano-server[22502]: Unable to bind to port 236: Address already in use. This is usually caused by another process (most likely another server) already using this port. This program will terminate now.
Dec 16 17:08:54 defiant systemd[1]: kopano-server.service: Control process exited, code=killed, status=15/TERM
Dec 16 17:08:54 defiant kopano-server[22494]: Starting Kopano server: kopano-server
Dec 16 17:08:56 defiant kopano-server[22184]: Accepted incoming connection from file:///var/run/kopano/server.sock

Somewhere along the line kopano-server advised me to do a ‘kopano-dbadm usmp’, which I did.

Questions:

how to get this to work without loss of data?
what problems are to expect with future updates when I keep using the old database

How to proceed

My prefered way to go is as described above, a database with the tables/columns as currently in kopano (to avoid update problems in the future), filled with the same content as I currently have in my ‘old’ database.
Second best is keeping the ‘old’ database, but I fear for the stability seeing the error messages.

is my first prefered solution do-able?
what am I missing in acheiving that solution?
why don’t I see all my appointments in the actual implementation?
how to solve those errors?

Any help on anwering my questions and how to proceed are greatly appreciated.

Thanks in advance,
Albert

Albert

Hello all,

After a few days of trying:

My preferred solution is not doable, I currently have a ‘zarafa’ database and database-user. Server.cfg/Debian-db.cfg is adjusted. Database-user must also be ‘zarafa’ since the database stored procedures have a ‘zarafa’ definer (which acts as a kind of linux-sticky-bit in my understanding).

Database missing columns are auto-magically added by ‘kopano-dbadm usmp’, no worries there. Database structure now almost looks the same, except for a few AUTO INCREMENT values.

Start/stop error-messages and apparmor-messages come from some script-errors in the current debian distribution. This will most likely be solved in the next point-release, so I’m told by the debian-team.

There is still the issue that I don’t see all my appointments, for this I will post a new issue in another category.

Greetings,
Albert

fbartels

@Albert said in ZCP 7.2.1.51838 to Kopano 8.7.0:

My preferred solution is not doable

to me your approach seems very doable, in fact a lot of our customers have upgraded this way. there is no need to rename the database or change the database user, you can just continue the ones you have used with Zarafa.

As for the missing elements this would need to be investigated.

Our general recommendation is of course to use our supported packages, instead of the ones provided through Debian as they give you access to our support for questions.