Hacker News Reader

I think packages starting services at install time or restarting them during upgrades is primarily Debian/Ubuntu weirdness; I don't remember seeing this behaviour with RedHat or Fedora.

Automatic startup on install is supremely annoying. There's a way to disable it on Debian at least, but it's terrible as default behaviour

SVR4 pkgs could and did do this too. I don't think it's so out of the mainstream, but it does suck.

Well, considering I’m the one with 74000 servers here for whom this automatic restart via package postinstall works and works wonderfully, we are going to disagree and I’m going to continue doing what I’m doing the way I’ve been doing it for the past 20 years across IRIX, HP-UX and Solaris since it provides total automation. You’re welcome to continue theorizing but I’m the one here with a real world use case, and this approach works great. Since this is my specialty, there is a miniscule chance that I might know what I’m doing and what I’m writing about, however small and unenviable that chance might be.

I'm curious how that actually works in practice.

Do you package all software by yourself? I mean, if the vendor-provided httpd package for example started and enabled itself upon installation, how would you structure your configuration packages so that httpd does not start until it's actually configured? Or (theoretically) if you needed to deploy a configuration change and an upgrade simultaneously and can't restart the software before the new configuration is in place.

I see this being rather easy if the vendor package simply puts the binaries in place so you can have your own packages run whatever scripts it is you need and depend on the vendor package, but I don't see how it wouldn't be a headache if the vendor package contained scripts to manage the service as well, which is what primarily annoys me on Debian-likes.

The application package delivers only the application payload and integration with the OS; it does not start anything unless it sees its own processes running, in which case this must be an in-place upgrade, so restart the daemon(s) to unload the old and load the new code.

It is the *-conf package which depends on the application package, brings on the configuration and automatically (re)starts the application.

Red Hat/CentOS does this too...

They do? I admin primarily RH and CentOS hosts and I've not noticed this happening with any packages.

As a quick test, I installed httpd on my workstation, and it did not get automatically started or even enabled at boot.

I don't think there's anything wrong with using packages to control which software is running if you do it right, but I do think it shouldn't be default behaviour.

Might just be the MongoDB package then? That's the most recent one where I've noticed that upgrading the package caused MongoDB to be restarted.

Even worse, on Linux, most packages will be helpful, for example upgrading the MongoDB package on CentOS? It'll helpfully restart the service for you. Nevermind that you've just scripted this and it's being run on all of the servers all at once so instead of doing a nice easy rolling upgrade WHEN you are finally ready, it's done at the same time.

That’s exactly how it must work for total automation where humans are out of the picture. What you lack is a push, rather than a pull methodology, with a software deployment server and a capability maturity model level 3 (or higher) change management process around it. Then it works flawlessly, and I’m writing from experience of several decades of modelling and implementing such things on a very large scale (tens or even hundreds of thousands of servers).

That’s my specialty as a technical architect.

https://en.m.wikipedia.org/wiki/Capability_Maturity_Model

I have other bits of software that manage that part for me, as part of my automation.

Why would I expect a package manager to also restart my services?

I need to make sure that other parts of the stack can either handle that service going away gracefully, or have automation around it, my package manager can't know the dependencies in which certain services should be stopped/started for example to allow for graceful failover. It's illogical to try and place all of that logic in the package manager, that is not its job. Especially if there are other config changes that need to happen too that are not part of that package management system.

Humans can still be out of the picture without a package manager starting/stopping/restarting services. Your suggestion of it being part of a maturity model don't make sense. I asked for the package to be upgraded, not for the service to be restarted.

Doing it through the package manager presents a uniform interface through one single command. Executing ordinary shell scripts through the package’s postinstall minimizes dependencies (no Puppet, Chef or CFengine required) and makes it easier on system administrators who do not have to learn any of those applications to perform system maintenance or perform telemetry gathering as directed by system engineering department. Doing or calling configuration scripts inside of OS packaging ensures that the system knows about and can be queried through its standardized software management subsystem as to what has been done to it, where, and by whom (component owner will be in the package metadata).

For example: a package delivers /opt/abcd/sbin/pgadm, which would be your engineered command line interface to CREATE DATABASE, database backups, and so on; then the application-db package calls that in its postinstall to create a database specific to that application. Best of all, once one has such packages, they can be plugged into Kickstart, JumpStart, AutoYaST, or whatever the OS provides for automated provisioning and hardware whether physical or virtual, turned into fully configured systems from literally nothing with no special or custom provisioning required. You could lose entire networks of servers and prop them up in seconds again this way.

Yes, I agree, packages should never be so "useful".

> > It's never appropriate for, e.g., a PostgreSQL package to create a postgres account and configure a postgres service running as that account -- this is not how I want to run postgres

> I don't mind it creating a postgres account, but what I do mind is the package automatically enabling the service, and starting the service.

IPS is one part of a fairly well-integrated system. IPS has several different actions to deliver various things to the system. These include file, directory, user, group, etc. actions. Delivery of a postgres account in IPS is done via a user action, not via a post-install script or a service that runs after installation.

If you run a shop where you don't want the postgres account to be created, you can use pkgmogrify to transform packages. pkgmogrify makes it easy to remove actions (remove the postgres user) and transform others (set ownership of files to someone other than postgres).

IPS allows signed packages and allows you to specify which signature(s) are acceptable. A shop that wants to only install packages that have passed their QA process could require that their own signature is on every package.

Taken together, those features make it quite possible to ensure that your systems never get software (via IPS) that you've not blessed. Presumably you use automation to detect things (user actions) that you feel may be objectionable and only the new objectionable content requires manual intervention.

When you really do want postgres to start, that's pretty easy to do too. The odds are that you don't want it to run as postgres, but as some other user. Maybe you want many instances as different users. This becomes fairly easy to handle by delivering another package that depends on the postgres package. That package can deliver user action(s) and an SMF profile that creates and enables instances of the postgres service.

I did a bunch of work for Solaris 12^^11.4 to have profiles that may be applied at various layers. The enterprise-profile layer applies to things that are common across all your machines. The site-profile is for a particular site and takes precedence over the enterprise-profile layer. Then there's the node-profile layer that can be specific to a given machine. All of these layers are intended to accept packaged content (or unpackaged, perhaps delivered by puppet or similar). If you want to control the behavior via install-time profiles, you can do that with sysconfig profiles which are fully integrated with the automated installer, 'zoneadm install', etc. Details at https://docs.oracle.com/cd/E37838_01/html/E60998/dzhid.html .

IPS is part of an integrated system that is designed to solve the problems that many people assume should only be part of the packaging system. While some criticisms of it are valid, I can say that I became much more fond of IPS as I started using Linux again after a long hiatus.