On Wednesday 25 September 2019 12:12:25 Sebastian Hyrwall wrote: > 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
+10 at least. Having survived such a scenario with a new ups whose batterys had been sitting for 6 months, I can agree with 95% of it, but in terms of install to a usable system out of the box, its all been downhill since wheezy. Buster runs fine, IF it can find its keyboard and mouse. But ssh doesn't want to run until the random number generator is seeded, and without a keyboard, it doesn't get seeded. It will sit there and answer a ping for half an hour, but that doesn't seed it so life can go on. So you take the drive to another machine, ask some questions on the lists and maybe fix it, and maybe not... There are so many IF's between booting buster, and a truly usable system that its no longer a learning experience, its a pita. And for arm stuff, its even worse. RT kernels can't find a wireless keyboard or mouse even if dmesg from an ssh login found both of them in plain sight. They are there, but not hooked into the system for use. Move the dongles to a different port, shows up in dmesg, but the system does NOT use them. Please, PLEASE, wintel or arm, I have both, give us a system that Just Works at bootup. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
