(Pull FPC autostart policy out into a page for FESCo) |
(Pulled from the Guidelines) |
||
Line 1: | Line 1: | ||
{{draft|This needs to be approved by FESCo as an Interim Policy and they need to answer the one question below of how strict they wish to be.}} | |||
== Why don't we autostart services? == | == Why don't we autostart services? == | ||
Latest revision as of 21:14, 8 March 2011
Why don't we autostart services?
The Current FPC wording around service autostarting is:
If a service should be enabled by default, make this the default in the init script. Doing otherwise will cause the service to be turned on on upgrades if the user explicitly disabled it.
Note that the default for most network-listening scripts is off. This is done for better security. We have multiple tools that can enable services, including GUIs.
contained in the SysVinit packaging Guidelines and similar language in the systemd guidelines draft. Until FESCo approves a new policy, this is what's in place.
Note that in the past, FPC has actually rendered opinions that were much stricter than the letter of this guideline language -- pretty much no daemons were allowed to autostart that weren't inherited from earlier Fedora (and if brought to their attention, even some of those were asked to stop). The issues of using excess resources and preventing local exploits were both concerns that prompted this. FESCo should decide whether they wish to enforce a more lenient or more strict policy until they create one of their own probably inline with what they think their eventual policy is going to look like.