Description of problem: The "sshd" service becomes disabled after I install that group of packages. Not sure if that is intended by one of the packages or a bug, but I want the service to remain enabled so it is run on start-up. Version-Release number of selected component (if applicable): I am using a Fedora 23 box with Vagrant to crete the VM in VirtualBox 5.0.10. This is in my Vagrantfile: 'config.vm.box = "boxcutter/fedora23" How reproducible: Consistently. I believe I have reduced the steps to just that one package install command. Steps to Reproduce: 1. Start Fedora 23 using that box with Vagrant. 2. Issue command to verify the "sshd" service is running and enabled by default using this command: "systemctl status sshd.service" 2. In VM, issue command: "sudo dnf groupinstall "Fedora Workstation" -y;" 3. Check the "sshd" service status using the same command as in step 2. Actual results: " sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: disabled) ... " Expected results: " sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled) ... " Additional info: I originally ran into the issue when running many of these commands in my "bootstrap.sh" file when Vagrant provisions the machine, and notice I could not 'ssh' into the VM anymore following a reboot. It either responded with a timeout or an ssh authentication error. This can be an added verification point. " $ cat /etc/*release Fedora release 23 (Twenty Three) NAME=Fedora VERSION="23 (Workstation Edition)" ID=fedora VERSION_ID=23 PRETTY_NAME="Fedora 23 (Workstation Edition)" [...] VARIANT="Workstation Edition" VARIANT_ID=workstation "
Forgot to mention, I'm not sure which component category this would be, and there's a lot to search for. I tried the following searches to find an adequate category, but did not find one: "sshd", "ssh", "core", "main", "system", and "fedora".
Basesystem is definitely wrong - that's just basic system metapackage for dependency ordering. Let's go with fedora-release - so it can get analyzed and possibly reassigned. (btw. you can usually use `which sshd` do detemine binary location and then rpm -qf /usr/sbin/sshd - and you will have openssh-server package (and this is part of openssh component).
fedora-release is the correct component, but we should bring in the Workstation WG on this topic; I've CCed a few of them. So, the issue is this: each of the editions is allowed to set its own preferred systemd presets. In general, we keep the set of global presets (those in the fedora-release package) to be pretty universal. Then the Edition presets are additive and may enable additional services. The sshd case is a special exception to this rule; the Workstation group disables it by default because it is expected that users are generally signed into their systems directly, unlike on Server where almost all interaction occurs remotely. Normally, this isn't an issue because most people install either Workstation or Server directly from media and get the pre-defined behavior. However, if you installed from a different spin (one that was not based on an Edition) and then later added the fedora-release-workstation package, then it's going to slap down that preset and cause the default state to change. (That of course assumes that you haven't manually changed the value, in which case your explicit choice always wins). In conclusion, this is expected (though unfortunate) behavior due to how presets work. The fedora-release-$EDITION presets trump the global set when they disagree. We should probably document this, but since the easy workaround is `systemctl enable sshd.service`, I'm not sure it's worth trying to change this behavior in a generic way. We probably can't move sshd.service out of the global presets because many of the non-Edition Spins want it, and they aren't (currently) permitted to install their own presets. So as long as Workstation has a subtractive preset, this is going to be the result.
Thanks for the wealth of information. A note: Its strange because the distribution of the Fedora OS I'm using I believe is a Workstation image, although it doesn't seem to act like you describe until I install that package group. I guess the only possible solution besides the usual manual intervention of the originally unsuspecting user, is that these presets can be persistently applied during the installation process. Afterwards, they could not be applied to the system state when installing various packages through normal use, since that system and its other internals are now in a state the user expects. I understand that could be a large and disrupting amount of work, depending on the implementation, but just mentioning it for discussion.
(In reply to Pysis868 from comment #4) > Thanks for the wealth of information. > > A note: Its strange because the distribution of the Fedora OS I'm using I > believe is a Workstation image, although it doesn't seem to act like you > describe until I install that package group. > > I guess the only possible solution besides the usual manual intervention of > the originally unsuspecting user, is that these presets can be persistently > applied during the installation process. Afterwards, they could not be > applied to the system state when installing various packages through normal > use, since that system and its other internals are now in a state the user > expects. > I understand that could be a large and disrupting amount of work, depending > on the implementation, but just mentioning it for discussion. Unfortunately, we don't actually have any way of differentiating that. The tool we use (RPM) can only tell that a package is being installed, not *when* it's being installed. We use exactly the same operations to install a package during anaconda installation (and LiveCD creation) that we use when installing an individual package after the fact. And I agree; installing new presets after initial installation is not a good user experience. Fortunately, it *should* be extremely uncommon. I'm ruminating on some ideas about how we can address it though. In particular, I'm concerned about the people who might do a Fedora Server install and then install the "Fedora Workstation" group atop it in order to get a local UI, because they will then hit this case. I can probably address the case where having a different fedora-release-$EDITION package in play could at least avoid this problem. But I'm not sure how to address the non-Edition Fedora that installs a fedora-release-$EDITION package situation. That's complicated.
So, I think I have a plan for how to do this. It had been a while since I looked at how I solved this problem for /usr/lib/os-release and I realized that I actually left myself an extra piece of information on the disk that I can use to make this decision. So I should actually be able to write a fix for this. I'll take a look and submit something for review later today, hopefully.
https://pagure.io/fedora-release/pull-request/19
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.
I forgot to follow up on this ticket, but both Fedora 24 and Fedora 25 should no longer be vulnerable to this issue. We now "lock" the system to the Edition that was installed and will not attempt to activate presets installed later.