On 02/03/2017 07:59 AM, Lars Vogdt wrote:
Am 2. Februar 2017 19:48:37 MEZ, schrieb Ralf Lang
: Sorry, but on such a business critical system I expect the admin to have disabled automatic restarting of all services in /etc/sysconfig anyway. I just wanted to advise against admins running random live updates on virtualisation hosts. Packaging cannot anticipate use cases and admins should not assume it does. I don't disagree with you. From my personal point as sysadmin maintaining hundreds of machines over years: I trust the packagers that they know best about their services. I never touched the variable you mentioned on any of my systems since I use Linux.
If a services has to be up for the magic 99,999%, you need a HA setup anyway.
In all other cases, I expect: * security updates might require a restart to have the patched service running instead of the vulnerable one * a restart might take some time, but I expect the service to be up as before without loss of configured features * as even productive machines might have a hardware problem, see a power outage or simply need a reboot after kernel/ systemd update, the system as such has to come up with all needed services up and running after a reboot
So from packagers I would except: * never ever change (runtime) configurations * if you restart a service, do it right (I saw untested conditions in init scripts that resulted in a failure during restart)
The problem with docker is that restarting docker stops your containers and they will only come back if, and only if, you had started them with the option "restart". https://docs.docker.com/engine/reference/run/#/restart-policies---restart However, I have the feeling most users do not expect this behavior, they expect to have the same containers running after an update.
* if needed (and only then) allow a sysadmin to disable an automated restart - but this requires a lot of documentation as this is nothing an admin like me expects as a default setting => and add a big warning sign that disabling an automated restart might have big security implications!
Lars
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org