Description of problem: Today a lot of "unnecessary" daemons default to "on" which both can be a security whole and a hw resource waste. The "default daemons running" seems to be determent by either the package maintainer and or developer or a wrong decision making ( Daemons are left "on" based on a guess which HW people mostly likely have and what is thought to be most likely used and what's popular this time... ) A proper way to deal with this *issue ( which daemons should be running and which daemons should not )* is to only have daemons running (default to on ) that are required for system and network functionality after installation and let the end user configure which daemon/services he wants to enable in in firstboot with good/simple explanation to the end user like are you gonna connect printer to this computer yes/no ( yes == cupsd on )( no == do nothing, defaults to off)? Do you have and want to enable bluetooth support yes/no? Do you want to enable avahi yes/no? Are you gonna run ssh server yes/no etc. By doing it the "Proper way" responsibility and potential security risks is moved away from Fedora ( The "I think this is right for you" from maintainers, developers and the community )to the end users ( the end user decides for himself what he wants to be running). Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I have a less polarizing suggestion. I don't mind going system-config-services and turning a few services off. I wish, however, that the service descriptions were more informative specifically stating what functionality requires a particular service. Good examples: NetworkManager: This is a daemon for automatically switching network connections to the best available connection. kudzu: This runs the hardware probe, and optionally configures changed hardware. Poor examples: autofs: Automounts filesystems on demand (Excuse me?) But some services currently don't bother to inform us. This is beyond poor. bluetooth: dund: fuse: irqbalance: nasd: pand: rdisc: squid:
I don't think this RFE is specific to only one component (even less firstboot), therefore I'll move it to the distribution component (for the time being, perhaps this discussion should rather be held on fedora-devel-list -- feel free to close it in this case). To get this off my chest, if there would be the need for services to be handled by groups, it would surely have to be done in system-config-services, but so far I don't see that this is necessary (see bug #249204). I see the following issues that should be tackled: 1) services that are unnecessarily enabled by default 2) services that need to run only if certain hardware is present 3) services that aren't described properly I think for 1) and 3), individual bugs should be opened against the relevant components and 2) needs the packages in question to be moved from running all the time to be e.g. activated by HAL if the hardware in question is present -- I think this one warrants a fully-fledged Feature for future Fedora versions.
Yeah, this probably needs to be filed at the individual package level. If you want to use this as a tracking bug that those bugs would block, go ahead.
I think the login first configure later approach is not the user friendly solution. User(s) only want to configure things once and then log into their *configured* system and be done with the configuration part and be able to start using their system. There are ( currently ) only 2 places to do that... First one is anaconda and the second one is first boot. Anaconda is not the right place to do that, in fact I think some options ( language/keyboard/timezone etc) that aren't strictly installing related should be moved out of anaconda and to first boot. Users that accept the "default" fedora installation schema should be able to do so,in the first "page" of entering anaconda <click> [ Install] ( they could also get to choose Gnome KDE and XFCE there ) and are then asked to provide the root password <click> ok and install starts. Others can <click> [Advanced] but all this is an different RFE.... Which leaves us with first boot.. We are already *asking* our users to configure the system in first boot and that's where this belong, along with language/keyboard settings timezone avatars etc.. 1) Reporting this as an "bug" serves no purpose, given the history.. some package maintainers/developers and their response to bug reports ( little or none ) along with this been allowed in the name of *feature* being introduced or silently swiped under the carped due to social status of the developer(s) and or connections ( his needs/their needs outweigh(s) the needs of many ) which then leads to the bug report being closed WONTFIX.. So whats the gain here none.. 2) Think theres work being done to achieve just that. 3) Yes this also would have to be done for first bootn and s-c-s along with proper descriptions of the services along with what they do. With tips if ports needs to be open in firewall or some other addition configurations needs to be done. A firm cold cut rule "nothing is "on" unless it's needed for system functionality and network connectivity ( and yes that includes all the service necessary for a functional network connection isdn included along with many more and no sshd is not needed for network connectivity...), needs to be in place and FOLLOWED.. Even.. Yes Even if the current behavior in service "on" or "of" scenario continuous and this RFE comes to reality then nobody can complain about the current decided services schema, whether it enables some unwanted services by default or not.. Simple point out is needed... "you had the opportunity to configure this before you logged in for the first time, at the same time you configure other things for you system including your user account, you got nobody to blame but you self for not turning these service on or off! "...
In my mind, one major reason for moving configuration out of firstboot and into user programs is that we aren't asking users to do something in a special environment. Instead they are up and running with their system as soon as possible. They don't have to do these configuration tasks they may not want to do, and may not even understand, before being able to actually use the system. By delaying configuration until after they are logged in, the user also has the option to pull up a web browser or help browser and investigate what they are being asked to decide. I feel the best way to proceed on things like this is to establish sensible defaults (most everything blocked by default in my opinion) and only ask the user to configure things if they really really need to. In Fedora, we are trying to move towards more dynamic configuration of open ports and enabled services - only enabling these things when needed - so allowing configuration at all, but especially in firstboot, seems counter to this goal.
Again I think the login first configure later approach is not the user friendly solution it's better to let him be done with it before he logs in.. If user does not understand how to configure those thing we ain't making it clear enough. What do you thing is more userfriendly a menu in firstboot where user is asked to choose his avatar or him trying to find out that he has to go to.. system --> preference --> personal --> about me and he figures that by google it.. Plus M$ user switching to Fedora are used to this.. If firstboot sole purpose is to create one user account we might ( or agenda to achieve just that ) just as well drop it all together and let the user create it as in the root account. "most everything blocked by default in my opinion" With other words leave thing as they are.. "dynamic configuration of open ports" Allowing applications to poke holes in the firewall is not good idea from security perspective... But then again since we leave sshd on and open by default We might just as well start allowing application to poke holes in the firewall..
Could some please close this idea of mine..