Bug 808317 - enabling sshd via yast2 runlevel doesn't work
Summary: enabling sshd via yast2 runlevel doesn't work
Status: RESOLVED DUPLICATE of bug 799471
Alias: None
Product: openSUSE 12.3
Classification: openSUSE
Component: YaST2 (show other bugs)
Version: Final
Hardware: x86-64 Other
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: Lukas Ocilka
QA Contact: Jiri Srain
URL:
Whiteboard: GOLD
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-08 13:54 UTC by Heiko Rommel
Modified: 2013-09-27 15:34 UTC (History)
7 users (show)

See Also:
Found By: Component Test
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
YaST2 log (52.11 KB, text/ascii)
2013-03-11 10:06 UTC, Heiko Rommel
Details
output of systemctl status sshd.service after reboot and before starting yast2 runlevel (initial test condition) (170 bytes, text/plain)
2013-03-11 10:24 UTC, Heiko Rommel
Details
Possible updates through zypper up that might have caused the regression (7.96 KB, text/plain)
2013-05-07 13:41 UTC, Wilfred van Velzen
Details
/var/log/zypp/history (60.61 KB, text/plain)
2013-08-15 09:31 UTC, Wilfred van Velzen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Rommel 2013-03-08 13:54:02 UTC
When launching yast2 runlevel and Enabling the sshd in the simple view (non-export mode) sshd get's started but the service is not persistenly activated.

I experienced this only on x86_64. On i586 this worked fine.
Comment 1 Heiko Rommel 2013-03-11 10:06:03 UTC
Created attachment 529077 [details]
YaST2 log
Comment 2 Heiko Rommel 2013-03-11 10:22:00 UTC
What is odd is that yast2 reports sshd as being enabled (Yes*) and therefore might consider of not having to do anything.

However, in the situation above sshd.service was NOT enabled when starting yast2.

In the meantime, to manually fix my system I ran
/bin/systemctl enabled sshd.service

That changed the display to Yes (without an asterik) in yast2 lan.
Comment 3 Heiko Rommel 2013-03-11 10:24:32 UTC
Created attachment 529080 [details]
output of systemctl status sshd.service after reboot and before starting yast2 runlevel (initial test condition)
Comment 4 Thomas Fehr 2013-03-13 10:16:01 UTC
Reassigned to maintainer of yast2-runlevel
Comment 5 Maitreya Maziarz 2013-03-15 16:14:07 UTC
For me, this behavior applied to apache2 in addition to sshd.  I don't know if it's related (and if I ought to file a separate bug report), but, additionally, there are no options in the default runlevel dropdown under advanced settings.  I'd like to change my default runlevel to 3.  Does anybody know the systemctl command to accomplish that?
Comment 6 Wilfred van Velzen 2013-05-07 13:39:54 UTC
I have (kind of) noticed the same behavior after the latest updates (through zypper up).
Because of the kernel update I "needed" to reboot. After the reboot sshd wasn't running. It was running before the reboot!

sshd.service in systemctl was disabled. Trying to enable it through Yast wasn't possible (the setting wouldn't stick). But 'systemctl enable sshd' did the trick. After that it was enabled in Yast also.

(I'll add an extraction of /var/log/zypp/history as attachment, which shows the updates that were installed previous to the reboot)
Comment 7 Wilfred van Velzen 2013-05-07 13:41:49 UTC
Created attachment 538192 [details]
Possible updates through zypper up that might have caused the regression
Comment 8 Lukas Ocilka 2013-06-11 07:09:07 UTC
This should be working now. See bug #807507

Already fixed by a maintenance update openSUSE-RU-2013:0533-1

*** This bug has been marked as a duplicate of bug 807507 ***
Comment 9 Wilfred van Velzen 2013-06-11 07:29:38 UTC
(In reply to comment #8)
> This should be working now. See bug #807507
> 
> Already fixed by a maintenance update openSUSE-RU-2013:0533-1

This update was published on 25 March.

What I described above happened in May. The system was fully updated end of April. So what I experienced can't have been bug 807507 !?
Comment 10 Wilfred van Velzen 2013-06-11 07:32:13 UTC
Btw: The UTC time above these comments is wrong. It's now 13:32 UTC ... ?
Comment 11 Lukas Ocilka 2013-06-25 09:11:25 UTC
This will hopefully fix the issue: New YaST module as a replacement for YaST Runlevel. Also available for 12.3

http://kobliha-suse.blogspot.cz/2013/06/yast-runlevel-is-dead-long-live-yast.html
Comment 12 Lukas Ocilka 2013-08-15 07:42:28 UTC
Fixed by implementing new Yast configuration module: Yast Services Manager.
It's already in Factory.
Comment 13 Wilfred van Velzen 2013-08-15 07:48:31 UTC
(In reply to comment #12)
> Fixed by implementing new Yast configuration module: Yast Services Manager.
> It's already in Factory.

Will this be fixed in 12.3 also? Or do we have to live with the fact that sshd gets disabled every time you run a "zypper up" ?
Comment 14 Lukas Ocilka 2013-08-15 08:25:23 UTC
If `zypper up` disables the sshd service, then it doesn't seem to be
a Yast issue as Yast is not in the play at all.

Command `systemctl enable sshd` should enable SSH service in your system.
If you then run `zyper up`, reboot, and the service is not running, then
it's a ssh issue.
Comment 15 Lukas Ocilka 2013-08-15 08:48:20 UTC
Wilfred, please try not to use Yast at all and report the result:

1.) Check the SSHD status with `systemctl status sshd`
2.) enable SSHD if not enabled
3.) start SSHD if not started
4.) Check the SSHD status with `systemctl status sshd`
4.) Run `zypper up`
5.) Reboot
6.) Check the SSHD status with `systemctl status sshd`

Something could be also found in /var/log/messages

I'd like to see all three outputs from the systemctl status.
I can't reproduce it on my system.
Thanks in advance
Comment 16 Wilfred van Velzen 2013-08-15 09:07:36 UTC
I already did something similar this morning. Except for the reboot. Because I'm remotely administering this server through an ssh connection, it is _very_ inconvenient if I loose the ssh connection after a reboot. ;)

I even have a cronjob that starts the sshd service every hour, just in case this happens again and there is an uncontrolled reboot. 

But today the sshd service was still enabled after the zypper up. Last week when I did the zypper up however it was disabled afterwards. There were lots of updated packages last week, because of the holiday season the previous zypper up was almost 2 months before that.

I can provide for instance /var/log/zypp/history, if that would help?
But sshd wasn't updated since April this year.
Comment 17 Lukas Ocilka 2013-08-15 09:24:33 UTC
Yep, let's try the zypp history, please.
Comment 18 Wilfred van Velzen 2013-08-15 09:31:58 UTC
Created attachment 552728 [details]
/var/log/zypp/history

The attachment contains log from today's and the previous zypper up.
Comment 19 Krasimir Ivanov 2013-09-17 10:41:40 UTC
I have the same problem with a fully updated openSUSE 12.3 x86_64 installation.
Comment 20 Josef Reidinger 2013-09-27 15:34:38 UTC
have all related problems with systemd in runlevel in one place

*** This bug has been marked as a duplicate of bug 799471 ***