Re: Starting processes after installation
On Wed 25 Sep 2019 at 18:12:25 (+0200), Sebastian Hyrwall wrote:
> On 2019-09-25 14:36, Dan Ritter wrote:
> > Sebastian Hyrwall wrote:
> >> Just a question. Is there anyone except me that thinks that autostarting
> >> processes after installation , via apt, is completely bonkers?
No, I think that's over the top.
> >> It's been like this for ages but can anyone name any good reason for
> >> this to be default?
Simply put, because a majority of people, perhaps, expect to install
packages in the expectation that they'll start performing their task
right away.
> >> 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.)
1996 takes you back to buzz, the first release, and its successor, rex.
The following spring, Bruce Perens wrote:
——✄——————
We will be attacked because:
[…]
4. Linux isn't quite ready for the naive user yet, it shows, and anyone
who wants to attack us will latch onto this.
[…]
Regarding the problem of Linux being inaccessable to naive users, this
is something we must deal with at least as well as Microsoft has if we
are to compete with Microsoft in the same market. First, one might ask
if we really want to do that. If we do, there has to be a lot more work
on hardware auto-configuration and GUI tools. If we don't want to do
this work, we might as well live with criticism on that issue.
——✄——————
> > 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.
One can always find a service that needs configuration beyond what
Debian either configures by default (like, say, ntp) or by means of a
series of questions (like, say, exim).
> 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.
Apart from your choice of "force", that's a fair description of, say,
installation of exim. Others are more passive, like wicd, which can't
do much connecting without being told what to connect to.
Bruce mentioned hardware auto-configuration and GUI tools above.
He didn't need to mention starting daemons automatically by default
because IIRC it was already the case in buzz.
> > 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?
More or less than what? There's little doubt that systems are being
configured more and more securely release by release. That's laudable,
even though many users get surprised or annoyed by it because "things
don't work like they used to". I don't follow your "sacrifice a few
extra commands": do you mean remove functionality that some people
feel is secure enough to meet their circumstances.
> > 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.
Sounds like a reasonable idea but, on balance, I feel it's unnecessary
for reasons given below.
> 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 would expect any decent sysadmin, in the sense you use it here, to
know how to install a service without it immediately starting. Isn't
that what they're paid for?
In many cases, that's as simple as
# ln -s /dev/null /etc/systemd/system/<service-name>.service
as documented by man 5 systemd-system.conf.
> I guess it's becoming more a workstation distribution every day and not
> something for internet facing servers.
Ah, a clue to where you're coming from. To which I would respond that
anybody running internet facing servers should be expected to know how
to install packages safely, otherwise they're simply unqualified.
OTOH one can hardly expect the same level of qualification or
technical expertise from the large numbers of people running home/soho
installations. Debian has to cater for these people as well; to quote,
"Debian: The universal operating system".
> 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.
Hmm.
Cheers,
David.
Reply to: