Re: Starting services automatically after install
* Toni Mueller <toni@debian.org> [120603 11:41]:
> Since we obviously can't agree on *how* the service is to be run, one
> could just ask the user, eg., in the case of a printing service:
>
> "I just installed the file sharing service. Do you want to start
> sharing immediately (will allow other people to access ....
> files/media/printers)?"
The print servers I looked at did not allow remote access by default
since somewhen in the 90ties.
> But for a more real-world example, consider slapd, which also starts
> immediately, but is imho quite unlikely to be configured appropriately
> by Joe Average User who doesn't understand that he needs to start Samba
> before being able to share his files, and which is impossible to
> configure appropriately by answering debconf questions in the first
> place?
What has slapd to do with samba and why don't you want it run?
actually I'd be quite confused if slapd had not been already running
after installing...
> > If a service comes with a default config that can be a real security
> > concern, then that alone needs fixing.
>
> Many services come, eg. Apache comes with it, too (and eg. grabs all
> sockets it can, one of my pet peeves).
Sorry, you have to explain this. Do you claim apache has a security
concern in its default config?
> > As administrator I also prefer that I just have to copy a config and
> > install the package. Anything not run by default (or at last by
> > default once its configuration is complete) means I have to
> > tweak another config file, which is uncessary annoying work.
>
> You have to say something like '/etc/init.d/service restart', anyway,
> after you put your own config into place. What's so much different from
> saying '/etc/init.d/service start' instead, in such a case?
That I do not have to do it? Either I have copied the config first or
for a full install that will get a reboot anyway when deployed.
> Asking the unwitting user and providing a default answer of 'yes' should
> solve the problem, imho - the slightly more experienced user can then
> at least opt for 'no'.
That's called policy.d. (though I feel like repeating others here).
Bernhard R. Link
Reply to: