Hi All good points. See below.
On 2019-09-25 14:36, Dan Ritter wrote: > Sebastian Hyrwall wrote: >> Hi >> >> Just a question. Is there anyone except me that thinks that autostarting >> processes after installation , via apt, is completely bonkers? >> >> It's been like this for ages but can anyone name any good reason for >> this to be default? >> >> There must be a damn good one or it would have been disabled long time ago. > It turns out that Debian is relatively old. I've been using it > since 1996 or so, and it was in version 2.1 back then. (I > haven't bothered to check this.) > > Back then, nearly all servers could do reasonable things without > any additional configuration. FTPd, httpd, ntpd, sendmail: the > install process could reasonably pop good enough values in a > config file without any user intervention, start the daemon, and > it would Just Work. I agree in a way. But nowadays things are more complex. There is for example rarely a httpd getting installing without configuration getting altered. Oh and I don't have to war-dial anymore to find servers :) > Debian has three real options: > > 1. Don't change policy. Many daemons will start up smoothly; > some of them will come up with snakeoil SSL certs, and some of > them will come up with configs that are technically working but > don't do anything useful without further configuration. The > good thing about this is that you can do things like install a > web application that depends on a database and get a working but > not-very-useful system immediately. The bad thing is that the > default choices are probably wrong, and you need to go do config > immediately anyway. Don't we already have start dependencies? If you install that "web application" it should depend on that database and the database should start up also. In case a "web application" was script-based (php etc) I've yet to see any "apt install" that immediately gets you a working httpd+php+db anyway without configuration. I especially like some something where they force you to change a variable in the configuration file to show that you've checked it and refusing to start before that. > 2. Change the policy to default to off. Good: better security, > fewer running-but-badly-configured services. Bad: it's hard to > get a database user and schema installed when the database isn't > running, so users/admins will need to do more explicit work. > It's really terrible to install sshd on a remote server, reboot > it, and then discover that sshd doesn't start by default. If you install for example "mysql-server" now it doesn't prompt you to create a user anyway so why is the extra step of starting the server before creating the user a problem. For "sshd" etc there can of course be exceptions for "critical services" which there is in many other distributions/operating systems. A good example is "redis-server". It did start up very smoothly right after install binding to 0.0.0.0 without auth :D Same with "memcache" if I'm not mistaken. Don't we need more security not less? Can't we sacrifice a few extra commands for that security? > 3. Change the policy so that simple daemons default to an > immediate start -- anything where the immediate config is likely > to be useful -- but complex daemons default to off. Good: best > of both worlds. Bad: worst of both worlds; you won't know when > it's your fault until you do explicit checks. > > > -dsr- Debian is the only distribution I've used which runs applications at install and automatically adds them to run at boot. I just like to be able to control what happens to my servers. It should be a sysadmins responsibility to know what is running and what will start at boot on the systems he administrates. It should not be left to package managers to make the initial decision. I guess it's becoming more a workstation distribution every day and not something for internet facing servers. My last experience with this was installing UPS tools which started a UPS-daemon that shut down the server which the UPS was low on battery when all I wanted was to run UPS diagnostics with a client. // Sebastian H
