search

zokradonh / kopano-docker

Unofficial Kopano Docker images for all Kopano services.
MIT License
59 stars 37 forks source link

image versions are not fail-safe for backup restores #261

Closed cguentherTUChemnitz closed 5 years ago

cguentherTUChemnitz commented 5 years ago

At first, i am sorry that i lost the exact log of the problem. So i now try to recapture what i still know from the problem, but it will lack some specific information and snippets. I have no specific idea how to solve this, so i hope to see some nice proposals here^^

Describe the bug The overall structure of some images (like the webapp) prevent the startup of old ones. The container installs at start-up additional packages from the bundled package manager. The problem is, that some configuration files are not system default, like php-configuration. So when the image is old and the package installation triggers dependencies or updates, which involves to update the not default configuration files, the problem occurs. The startup hangs and the container is not able to boot, because apt-get mentions that configuration files are modified and the new packages are not able to install. This happened to me, when the image had php5 bundled but the installation of the webapp plugins tried to update to php7, mentioning that the php-config was modified.

I know why you do this at start-up, since providing all plugin install combinations as tags for the images would result in a very high number of different images. I vote for an image with all (official) plugins preinstalled, to get a robust behavior for old images, when nothing is done with the package manager at startup.

To Reproduce Steps to reproduce the behavior:

  1. Try to use an old webapp container, containing php5 and install plugins, which try to update to php7.

Expected behavior The container starts as expected with the old setup.

Additional context This is a typicall use-case for us, since we backup our volumes and docker-compose stack configuration (including the .env files) together. In this way we are able to restore the service and its data in their depending specific versions. This assumes, static docker image tags, referencing stable images, which are able to start, even when they are old.

fbartels commented 5 years ago

Hi,

since these containers have so far only used Debian 9 there should not have been a container with php5, but at max php7.0.

Normally the upgrade of old packages should be prevented by https://github.com/zokradonh/kopano-docker/blob/master/webapp/start.sh#L22.

For a production deployment I would though recommend to use the bundled makefile to produce your own images with the desired plugins directly backed into the container at startup.

fbartels commented 5 years ago

hm.. thinking a bit further about this its probably better to remove the ability to dynamically install packages as startup altogether. Or only install packages that are part of the image already.

The reason to not install any webapp plugins by default is, since every installed package needs to be loaded at login, which slows down the login process. so in general its recommended to only have plugins installed that you plan on using.

fbartels commented 5 years ago

Hi @cguentherTUChemnitz,

do you have any further input?

fbartels commented 5 years ago

I actually saw this this morning on my testing setup:

Modified configuration file
---------------------------

php.ini: A new version (/usr/lib/php/7.3/php.ini-production) of configuration file /etc/php/7.3/apache2/php.ini is available, but the version installed currently has been locally
modified.

  1. install the package maintainer's version    3. show the differences between the versions            5. start a new shell to examine the situation
  2. keep the local version currently installed  4. show a side-by-side difference between the versions

Which resulted in the container hanging at startup.

cguentherTUChemnitz commented 5 years ago

I actually saw this this morning on my testing setup:

Modified configuration file
---------------------------

php.ini: A new version (/usr/lib/php/7.3/php.ini-production) of configuration file /etc/php/7.3/apache2/php.ini is available, but the version installed currently has been locally
modified.

  1. install the package maintainer's version    3. show the differences between the versions            5. start a new shell to examine the situation
  2. keep the local version currently installed  4. show a side-by-side difference between the versions

Which resulted in the container hanging at startup.

Wow yeah, that is exactly what i tried to describe from my memory. The non-interactive apt-get should do the trick for the exact problem. Nevertheless, the idea of building the own image with imprinted plugins seems also quite good for me. In my eyes, we can close this ticket.

fbartels commented 5 years ago

Ok, lets close it here.

To summarise: