* Toni Mueller <t...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603115132.ga4...@client.brlink.eu