Upgrading from 18.104.22.168 to 10.0.1.113 ?
running Kopano community version 22.214.171.124.02d8c6ffb-0+262.1 on GNU/Linux Debian Stretch. I’m aware about the usual upgrade/backup procedure. Can I safely upgrade from my running version to latest (as today) 10.0.1.113 ?
jengelh last edited by
Yes. Most of the prose in the instructions is for ancient datasets (as carried over from Zarafa 7.0 or that kind of vintage).
These days, it’s really just install, run, check for residual error messages (e.g. hints as to removed config directives, or special db issues that do not warrant an automatic edit).
hispeed last edited by
Yes this is no problem, i just did it.
thank you so far. One more general question I have to Kopano upgrades.
whenever I upgrade core or webapp several Kopano services are upgraded (server, dagent, spooler, …) and the installation process often asks the user to use the .cfg file for that particular service. The currently used .cfg file is then renamed to .dpkg-old or similar (in my case GNU/Linux Debian).
So I’m always performing this task: I let the installer/upgrader touch the new .cfg file so new directives can take place. Then I open two shell windows next to each other. On the left window I see the empty default server.cfg and on the right window I have the view of my customized server.cfg.dpkg-old. Then I go through each line of my old server.dpkg-old and integrate it into the fresh new-created config file. So I don’t miss any new directives, I read through important notes in the config file comments and so on.
But this is very time-consuming and such an upgrade costs a lot of time. That is also true for other similar debian packages when upgrading, not only to Kopano. Of course I could answer “No - don’t replace the config file, keep on using my existing one” when the installer asks me, but in that case I would have an older config file and likely miss new directives.
what is best practice to perform such upgrades?
“No - don’t replace the config file, keep on using my existing one”
That is imho the option you should choose in the first place, as it will not nuke your existing configuration. Afterwards you could still check the new config file for any options that may apply to your environment and apply them afterwards.
thctlo last edited by thctlo
How i do it and are running it.
Before upgrade backup /etc/kopano (always)…
i get all config from : /usr/share/doc/kopano/example-config/ and put these in /etc/kopano
then i include all files with :
(per service one file).
all my settings are in the -custom.cfg, and if its needed to overrwrite (default) files i just do it, all then i need todo is include my configs again.
I might be handy that this is handeld by default by kopano.
for example, something like:
default i uses the configs as shown in /usr/share/doc/kopano/example-config/.
and these all have the option to include the files in /etc/kopano/conf.d
add per service and override file.
Its much less worring when you override files.
this sounds indeed like a very nice and convenient solution which I will dig further into. Thanks!