On Thu, Oct 09, 2008 at 08:14:37PM +0200, Valent Turkovic wrote: > > This is pretty much what is followed already. If a service is enabled by > > default, it is usually there for a good reason. > > > > Rahul > > I'm posting a revised list of services which maybe could be disabled > by default on Fedora Desktop Live CD, please correct me if I'm wrong. > > anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off > atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > > Are schedulers needed for a Desktop system? When? If you don't have cron/anacron, things like log files and other temporary files will overflow and fill up the disk since they won't be cleaned up/rotated automatically anymore. Smolt won't send client checkins to the server anymore. The manual page index won't be updated. The updatedb database won't be updated, so "locate foo" won't work. Binaries won't get prelinked, removing a security feature and potentially exposing systems to vulnerabilities. Other software that drops files in /etc/cron.*/ expecting it to get executed at regular intervals won't work anymore without manual intervention. > avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off > > Needed only for print discovery? Ok this could maybe useful for some > people. I searched the places where avahi is discussed any only time > avahi is mentioned it is for network printer discovery. I haven't got > a clue how to use avahi and I manually configure all network printers > I use, but that is me :) So this service is could be useful in desktop > usage, so it should stay enabled. Actually, avahi is for all sorts of automatic discovery of services available on the local network. Printing is just the one most often used I would guess. Its great when I visit friends and their printer just shows up automatically on my Fedora laptop... I think iTunes shares also use this mechanism show they show up automatically in e.g. rhythmbox. > irqbalance 0:off 1:off 2:off 3:on 4:on 5:on 6:off > > This service should be disabled if system uses single core CPU, > otherwise it should be enabled. I would argue that its getting harder to find single-core systems these days, and again a cost/benefit anaylsis would show that it isn't worth the cost to figure out automatically whether to enable or disable this based on the CPU the system is currently booted on, because by the time you figure it out, you've wasted more time than it would take to just start it always. > mdmonitor 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > If system isn't using lvm or raid this service should be disabled. Perhaps. > netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off > nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off > > These service should be disabled, I don't see that Desktop users need NFS... Perhaps. NFS is a dinosaur anyway. I avoid it even for servers, preferring to use CIFS instead. > ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off > > Disabled by default, and if somebody needs it and know that it is used > for he can enable it. Time synchronization is important. It should just work out of the box without requiring a user to know about it and enable it. I vote to keep ntpd on by default. > portreserve 0:off 1:off 2:on 3:on 4:on 5:on 6:off > "The portreserve program aims to help services with well-known ports > that lie in the bindresvport() range (currently 600-1023). It prevents > programs requesting a port to the libc from occupying a real service's > port by occupying it itself, until the real service tells it to > release the port (generally in its init script)." > > Not sure if this is needed for Desktop users... > > > rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off > rpcgssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > rpcidmapd 0:off 1:off 2:off 3:on 4:on 5:on 6:off > > NFS is not used on Desktop, maybe on the servers, so what do you think > - could these services be disabled by default for Desktop systems? I agree that rpcbind, rpcgssd, rpcidmapd etc. should be disabled by default for Desktop users. I think the only thing that Desktop users might need rpcbind for is if they authenticate to a NIS/yp directory, in which case they might need it and ypbind. Lots of your suggestions require logic--a decision to be made at install or firstboot time on which services should be enabled/disabled by default based on other information. Perhaps a firstboot module could be developed to implement this. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
