Bug 707553

you can probably add to that list ntp as well it should be configured enabled and started in firstboot if the novice end user actually knows what it is and has any intent of using it..

And the various NFS related services such as nfslock, rpcbind, rpcgssd, rpcidmapd

And smart card related services such as pcscd

This should be done in the spin's kickstart.

This is going to be tricky. You need to fire off some post install process to check which of these services is really needed.
Probably you could do this with a service that runs on the first boot and disables the unneeded services (including itself).
I don't know that one person is going to have the knowledge to write all of the checks. Probably something will be needed where it is easy to add new checks as people think of them.

I know anaconda has some logic to install appropriate fsck packages based on the fs that its installing to. I don't see it should be much different from that. Have it disabled by default, check for FCoE card, if its there enable the service, or even better have udev rules deal with it. To install for things like boot from SAN you need to go into advanced options and deal with such things like LUN masking etc so the code path for that determination is there. NFS is likely a little harder.

anaconda has logic to enable services as needed, sure.  But that assumes an environment where most everything is off by default - like the regular installation environment.  The livecd defaults to having a ton of stuff on by default, and anaconda doesn't run around turning everything off.

> fcoe and lldpad, only needed, if you have fibre channel over ethernet
> devices

lldpad, on a desktop computer without any fancy FC stuff, installed to basic storage, this service takes between 5% and 10% cpu time ALLWAYS. I noticed when dealing with a strange performance problem affecting kvm. It was not related to it but it consumes cpu for nothing and i discovered it because it was at the top of top's list most of the normal time. 

> livesys and livesys-late, only needed for the live CD

Totally forgot of those, i rediscovered them some minutes ago and was going to file a bugreport and found this on. These definitively should be disabled after firstboot (or maybe by firstboot itself). Do these services provide anything useful on an installed Fedora?

> iscsi and iscsid, only needed, if you have iSCSI devices

WOW! these were on!!! now i am paranoid because i need to audit what got enabled after install. Even some nfs suff seems enabled.

This is not good, maybe firstboot or anaconda should provide a 'active services after install' screen showing what services will be enabled (the user can choose to disable/enable some services here).

Is that related to the fact that is the kde-livecd image? does it not happen with the dvd?

(In reply to comment #6)
> anaconda has logic to enable services as needed, sure.  But that assumes an
> environment where most everything is off by default - like the regular
> installation environment.  The livecd defaults to having a ton of stuff on by
> default, and anaconda doesn't run around turning everything off.

I don't see where the livecd turns 'a ton of stuff' on.
All I can see in fedora-live-base.ks is that the mentioned livesys initscripts are added, and then there is a bunch of chkconfig off calls.

So, is the consensus here that we should pile on more of those, or should the package defaults of inidividual services be changed ?

Ideally we would fix the resource hogs not to be resource hogs when they aren't needed. Possibly would could look at selectively disabling services post install, but then we need to have some way to do that and some idea of how to determine what hardware support is needed. anaconda has some way of doing this now, that isn't directly usable for live installs.

Related, for the LiveCD ones:

https://bugzilla.redhat.com/show_bug.cgi?id=637187

I think this is still a problem so moving to rawhide for F-18 tracking

This kinda depends a bit on [1] to be properly fixed and easily customized for spins...

1.http://fedoraproject.org/wiki/Features/PackagePresets

I should also mentioned when I looked at optimizing the bootup process for spins during the F15 I hit a snag with the dependency of /dev/root being present various tools/application. 

Which kinda blows away a bit initramfs less boot up support which I think is needed at least from a *DE spins point of view for the best experience . 

Now I know that Grub2 has been fixed and grubby is still broken however I'm not so sure where the image creation tools are in this regard...

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This still applies to Fedora 25, doesn't it?

(In reply to Vedran Miletić from comment #18)
> This still applies to Fedora 25, doesn't it?

Maybe, most of them are enabled/disabled as part of the edition 'profile' (not sure the real name of it)

(In reply to Peter Robinson from comment #19)
> (In reply to Vedran Miletić from comment #18)
> > This still applies to Fedora 25, doesn't it?
> 
> Maybe, most of them are enabled/disabled as part of the edition 'profile'
> (not sure the real name of it)

Workstation and Server

Disable the Avahi daemon.

(In reply to Vedran Miletić from comment #18)
> This still applies to Fedora 25, doesn't it?

This may still apply to RAWHIDE actually.

Automation has figured out the package is retired in rawhide.

If you like it to be unretired, please open a ticket at https://pagure.io/releng/new_issue?template=package_unretirement