Bug 699286

Summary: openssh upgrade to openssh-server-5.8p1-30.fc16 converts a working sshd service into a dead one
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: rawhideCC: eparis, jchadima, mattias.ellert, mgrepl, tmraz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-28 06:13:24 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Michal Jaegermann 2011-04-24 17:46:34 EDT
Description of problem:

After a transition from a working openssh-5.8p1-27.fc16.1 to openssh-5.8p1-30.fc16.1 status for sshd service shows:

sshd.service - OpenSSH server daemon.
          Loaded: loaded (/lib/systemd/system/sshd.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/sshd.service

That despite that "chkconfig sshd --list" reports

.... 3:on    4:on    5:on ....

To ensure that sshd really starts on boot one has to add in /etc/systemd/system/multi-user.target.wants a mising link sshd.service to /lib/systemd/system/sshd.service.

If that would be a truly remote machine such "upgrade" would create a serious problem (and quite costly in a number of scenarios).

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Eric Paris 2011-04-26 12:01:32 EDT
This caused a serious problem for me.  I know if you look at daemon(7) it describes the right way to handle updates in the spec files.  I'm not sure how to fix it now that it's broken.  But hopefully you can quickly stop breaking people's working systems....
Comment 2 Michal Jaegermann 2011-04-26 13:57:53 EDT
(In reply to comment #1)
> I'm not sure how
> to fix it now that it's broken.  But hopefully you can quickly stop breaking
> people's working systems....

Something like that in %post of openssd-server package?

if chkconfig sshd --list | grep -q 3:on ; then
  if [ ! -L /etc/systemd/system/multi-user.target.wants/sshd.service ]; then
     ... do whatever magic required to unbreak the system ...

Likely "magic" is something with 'systemctl enable ...' or just make that link.
Also instead of checking directly for that link one can probably do:

  if ! systemctl list-units | grep -q sshd ; then
Comment 3 Jan F. Chadima 2011-04-26 14:58:38 EDT
the scriptlets are now according to the systemd-packaging-guide
Comment 4 Eric Paris 2011-04-26 15:48:50 EDT
They are still wrong.  This will break every user who updates.  They will loose ssh access to their box.  Which guidelines did you look at?  I will make sure they get fixed to indicate that you need something like (from man (7) daemon): 

%triggerun -- foobar < 0.47.11-1
           if /sbin/chkconfig --level 3 foobar ; then
                   /bin/systemctl --no-reload enable foobar.service foobar.socket >/dev/null 2>&1 || :

This is what enables the service on an update IFF it was enabled in runlevel 3 before the update.  I'm not sure how that's going to work along with your chkconfig --add on every update, so it might take some testing.....
Comment 5 Michal Jaegermann 2011-04-27 00:05:42 EDT
(In reply to comment #4)
> %triggerun -- foobar < 0.47.11-1

Maybe I am misinformed but I heard that package triggers are frowned upon.  OTOH checking that /sbin/chkconfig is aware of sshd but 'systemctl list-units' is not, and acting on that information in a %post script, does not look to me that complicated. That does not need any specific version information.
Comment 6 Jan F. Chadima 2011-04-27 03:26:28 EDT
(In reply to comment #4)
> %triggerun -- foobar < 0.47.11-1
>            if /sbin/chkconfig --level 3 foobar ; then
>                    /bin/systemctl --no-reload enable foobar.service
> foobar.socket >/dev/null 2>&1 || :
>            fi
this switch the service on every time when the package is updated and originaly was in runlevel 3. IMHO it's wrong.
Comment 7 Eric Paris 2011-04-27 08:56:25 EDT
You need to set the version there equal to the last version using sysinit.  This will only be run the first time one updates past the version that removes sshd from sysinit.

After you update to systemd you should remove it from chkconfig with --del.

I believe both the NM and the sssd packages have sucessfully implemented spec files that handle updates.

As it stands today every F16 box that you update will lose ssh on the next reboot.  That's a huge problem and why this method was documented....
Comment 8 Jan F. Chadima 2011-04-27 13:06:24 EDT
(In reply to comment #7)
> After you update to systemd you should remove it from chkconfig with --del.

This is a problem because deleting the ssh from sysv-init is problem for those who uses it instead of systemd.
Comment 9 Eric Paris 2011-04-27 15:02:28 EDT
I thought we were trying to move away from sysv-init and to just use systemd.  It's not possible or supported to install F16 without systemd.  I understand that upstream might not want to completely drop chkconfig, but in F16 we should.

In any case post seems wrong, since you are going to add it into chkconfig every time, not just on initial install.  (which explains why my box now has it enabled in chkconfig and in systemd)   I'd pretty strongly suggest putting the if [-x server] as an 'else' clause to systemd if you need support for both.

I'm guessing that postun is going to double restart it based on how it is coded there....

preun might be right....

I still think you should just convert all the way to systemd and use the trigger like in the man page....
Comment 10 Lennart Poettering 2011-04-27 15:07:01 EDT
Jan, non-systemd systems are not supported anymore on Fedora, no need for that compatibility.

Also, it is not strictly necessary to remove the old sysv services, as they are ignored when native services exist by the same name.
Comment 11 Jan F. Chadima 2011-04-28 06:13:24 EDT
Temporarily revert sytemd units according to https://bugzilla.redhat.com/show_bug.cgi?id=697698#c30
There is still nor fpc nor fesco guidance how to do it.