Bug 437828 - [RFE] Leave only necessary system/networking daemons "on" by default move rest to firstboot..
[RFE] Leave only necessary system/networking daemons "on" by default move res...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-17 12:23 EDT by Jóhann B. Guðmundsson
Modified: 2014-03-16 23:12 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-09 21:52:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jóhann B. Guðmundsson 2008-03-17 12:23:50 EDT
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:
Comment 1 Alexei Podtelezhnikov 2008-04-02 13:54:12 EDT
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:



Comment 2 Nils Philippsen 2008-04-07 11:25:37 EDT
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.

Comment 3 Bill Nottingham 2008-04-07 12:04:05 EDT
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.
Comment 4 Jóhann B. Guðmundsson 2008-04-07 13:59:40 EDT
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! "...
Comment 5 Chris Lumens 2008-04-09 17:49:23 EDT
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.
Comment 6 Jóhann B. Guðmundsson 2008-04-09 18:43:16 EDT
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..
Comment 7 Jóhann B. Guðmundsson 2008-04-09 21:52:58 EDT
Could some please close this idea of mine..

Note You need to log in before you can comment on or make changes to this bug.