Bug 697698 - Providing native systemd file for upcoming F15 Feature Systemd
Providing native systemd file for upcoming F15 Feature Systemd
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan F. Chadima
Fedora Extras Quality Assurance
: Reopened
: 714441 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
  Show dependency treegraph
 
Reported: 2011-04-18 18:44 EDT by Jóhann B. Guðmundsson
Modified: 2011-06-30 05:35 EDT (History)
8 users (show)

See Also:
Fixed In Version: openssh-5.8p2-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-30 05:35:13 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)
Native systemd service file for sshd (221 bytes, text/plain)
2011-04-18 18:44 EDT, Jóhann B. Guðmundsson
no flags Details
ssh keygen (862 bytes, text/plain)
2011-04-18 18:48 EDT, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for openssh per connection server (170 bytes, text/plain)
2011-04-19 04:43 EDT, Jóhann B. Guðmundsson
no flags Details
sshd socket (137 bytes, text/plain)
2011-04-19 04:44 EDT, Jóhann B. Guðmundsson
no flags Details
sshd.service with environment file /etc/sysconfig/sshd (266 bytes, text/plain)
2011-04-20 04:50 EDT, Jóhann B. Guðmundsson
no flags Details
Service file that generates all key types (871 bytes, text/plain)
2011-04-20 14:53 EDT, Jóhann B. Guðmundsson
no flags Details
Service file that generates rsa key's (550 bytes, text/plain)
2011-04-20 14:53 EDT, Jóhann B. Guðmundsson
no flags Details
Service file that generates rsa1 key (533 bytes, text/plain)
2011-04-20 14:54 EDT, Jóhann B. Guðmundsson
no flags Details
Service file that generates dsa key (553 bytes, text/plain)
2011-04-20 14:55 EDT, Jóhann B. Guðmundsson
no flags Details
[PATCH 1/3] Split out the host key generation into its own tool. (7.13 KB, patch)
2011-06-22 04:55 EDT, Mathieu Bridon
no flags Details | Diff
Full migration to a native systemd service. (11.84 KB, text/plain)
2011-06-22 04:56 EDT, Mathieu Bridon
no flags Details
[PATCH 3/3] Fixed a typo in a comment (1.05 KB, text/plain)
2011-06-22 04:58 EDT, Mathieu Bridon
no flags Details
[PATCH 2/4] Full migration to a native systemd service. (11.87 KB, patch)
2011-06-23 05:29 EDT, Mathieu Bridon
no flags Details | Diff
[PATCH 3/4] Fixed a typo in a comment (1.05 KB, patch)
2011-06-23 05:30 EDT, Mathieu Bridon
no flags Details | Diff
[PATCH 4/4] Added a -server-ondemand subpackage. (4.21 KB, patch)
2011-06-23 05:31 EDT, Mathieu Bridon
no flags Details | Diff
[PATCH 4/4] Added a -server-ondemand subpackage. (4.21 KB, patch)
2011-06-24 00:28 EDT, Mathieu Bridon
no flags Details | Diff

  None (edit)
Description Jóhann B. Guðmundsson 2011-04-18 18:44:25 EDT
Created attachment 493048 [details]
Native systemd service file for sshd

Description of problem:

The attached file is a native systemd file for upcoming F15 Feature [1]

Please read [2] on how to packaging and installing systemd Service files.

To learn more about Systemd daemon see [3].

To view old SysV with the new Systemd site by site see for your component see [4]

If you have any question dont hesitate to ask them on this bug report.

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

2.https://fedoraproject.org/wiki/Systemd_Packaging_Draft

3.http://0pointer.de/public/systemd-man/daemon.html

4.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability 

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jóhann B. Guðmundsson 2011-04-18 18:48:09 EDT
Created attachment 493049 [details]
ssh keygen

This generates the ssh keys once before sshd is run. 
Once it has been run it disables it self.
Recommend that this gets enabled by default at install 
( once it has run it will disable it self )
Comment 2 Jóhann B. Guðmundsson 2011-04-18 18:51:07 EDT
Ye also might want to take a look at why the daemon is existing with status 255 could be a bug
Comment 3 Tomas Mraz 2011-04-19 02:43:05 EDT
This should be postponed to F16 as only bugfixes should be pushed to F15.
Comment 4 Jóhann B. Guðmundsson 2011-04-19 04:02:59 EDT
It would be good if this gets pushed as soon as possible to rawhide to catch any potential snags as early as possible. 

You might want to take a look at https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options and also package the old sysv script seperately.
 
And also you might want to look into why the ssh daemon is exiting with status 255.
Comment 5 Tomas Mraz 2011-04-19 04:31:04 EDT
(In reply to comment #4)
> It would be good if this gets pushed as soon as possible to rawhide to catch
> any potential snags as early as possible. 
Yes, sure.

> And also you might want to look into why the ssh daemon is exiting with status
> 255.
This is already fixed in rawhide.
Comment 6 Jóhann B. Guðmundsson 2011-04-19 04:43:30 EDT
Created attachment 493129 [details]
Native systemd service file for openssh per connection server
Comment 7 Jóhann B. Guðmundsson 2011-04-19 04:44:08 EDT
Created attachment 493130 [details]
sshd socket
Comment 8 Jóhann B. Guðmundsson 2011-04-19 04:49:31 EDT
Just threw in per connection sshd server for fun if you guys were interested try it out and shipping it along. 

The resource usage should be around 10kB per connection...
Comment 9 Jan F. Chadima 2011-04-20 04:24:54 EDT
I'm not so familiar with systemd unit description. Can you help me please with this problem.... looking into sysvinit script you can found that firstly the environment file /etc/sysconfing/sshd is read and in dependence on the environment are some ssh-keygens run and others are skipped.
thank you in advance
Comment 10 Jóhann B. Guðmundsson 2011-04-20 04:43:49 EDT
The keygen has been moved into it's own service script ( ssh-keygen.service ) as it should be and it will check for the existance of the ssh key and generate them if the dont exist.

The reason I skipped setting /etc/sysconfig/sshd enviroment file is because it does not exist on a default Fedora Gnome Desktop Live install. If the environment file is missing the service will fail to start.
Comment 11 Jóhann B. Guðmundsson 2011-04-20 04:50:59 EDT
Created attachment 493389 [details]
sshd.service with environment file /etc/sysconfig/sshd

The environment file /etc/sysconfig/sshd must exist on the system for the daemon to run!
Comment 12 Jan F. Chadima 2011-04-20 05:45:17 EDT
(In reply to comment #10)
> The keygen has been moved into it's own service script ( ssh-keygen.service )
> as it should be and it will check for the existance of the ssh key and generate
> them if the dont exist.
> 
> The reason I skipped setting /etc/sysconfig/sshd enviroment file is because it
> does not exist on a default Fedora Gnome Desktop Live install. If the
> environment file is missing the service will fail to start.

in the future f16 this file will be present (and may be added into any other system also)
Comment 13 Jan F. Chadima 2011-04-20 05:47:34 EDT
there is still unsolved the problem with switching the particular keygens on or off according to the environment
Comment 14 Jóhann B. Guðmundsson 2011-04-20 06:15:13 EDT
?

Looking at the sysv I dont see any enviromental change with regards to keys other than creating them at startup so I need you to explain a bit. 

is that something that is set in the /etc/sysconfig/sshd which does not exist btw?
Comment 15 Jóhann B. Guðmundsson 2011-04-20 06:54:06 EDT
Could you give me the content of this non existing /etc/sysconfig/sshd and these future plans you have in mind so I can get a bigger picture of what you are trying to acomplish and thus see how what is the best way to solve it in systemd.
Comment 16 Jan F. Chadima 2011-04-20 07:24:52 EDT
can you look at rawhide? there you can find the nonexistent file with its full content. The AUTOCREATE_SERVER_KEYS item is what changes the keygen behavior.
Comment 17 Jóhann B. Guðmundsson 2011-04-20 10:16:22 EDT
So we have

# The server keys are automatically generated if they ommited
# to change the automatic creation uncomment the approprite 
# line.
md 
# AUTOCREATE_SERVER_KEYS=RSAONLY
# AUTOCREATE_SERVER_KEYS=NO
AUTOCREATE_SERVER_KEYS=YES

if [ "x${AUTOCREATE_SERVER_KEYS}" != xNO ]; then
                 do_rsa_keygen
                 if [ "x${AUTOCREATE_SERVER_KEYS}" != xRSAONLY ]; then
                         do_rsa1_keygen
                         do_dsa_keygen
                 fi
fi

Systemd does not support yes no checks 

And the purpose of this is to generate new keys every startup correct?
Comment 18 Jóhann B. Guðmundsson 2011-04-20 11:08:47 EDT
Ok so I have created a sshd.daemon service that will if set in /etc/sysconfig/sshd
will generate new rsa/rsa1/dsa ( or any combination of those three ) at service startup and remove the relevent keys at shutdown which brings me to..

# Do not change this option unless you have hardware random
# generator and you REALLY know what you are doing/

export SSH_USE_STRONG_RNG=0
# export SSH_USE_STRONG_RNG=1

Is the above relevant to starting of the sshd.service ?
Comment 19 Tomas Mraz 2011-04-20 14:07:41 EDT
(In reply to comment #18)
> Ok so I have created a sshd.daemon service that will if set in
> /etc/sysconfig/sshd
> will generate new rsa/rsa1/dsa ( or any combination of those three ) at service
> startup and remove the relevent keys at shutdown which brings me to..

No, that's not how the AUTOCREATE_SERVER_KEYS setting supposed to work. Basically in case it is set to NO, it will just not create the keys at all even if they do not exist. If it is set to RSAONLY, it will generate just the RSA key for SSH protocol 2. If it is set to YES, it will generate all the three server keys. In all cases keys are generated only if they do not exist on the system.

> # Do not change this option unless you have hardware random
> # generator and you REALLY know what you are doing/
> 
> export SSH_USE_STRONG_RNG=0
> # export SSH_USE_STRONG_RNG=1
> 
> Is the above relevant to starting of the sshd.service ?

This is a regular environment variable that can affect the behavior of the sshd daemon. It is not parsed by the SysV init script. And yes, it is relevant.
Comment 20 Jóhann B. Guðmundsson 2011-04-20 14:18:29 EDT
Thanks for info it did not make sense to me stuffing this into the sshd.service 

Basically so we just need to improve the ssh-keygen.service I'll move the modification into the ssh-keygen.service and submit the new /etc/sysconfig/sshd
Comment 21 Jóhann B. Guðmundsson 2011-04-20 14:28:47 EDT
Hum we might want to split this into three diffrent keygen service + it wont make any sense continouing to use that variable et all and it will be cleaner that way.
Comment 22 Jóhann B. Guðmundsson 2011-04-20 14:53:16 EDT
Created attachment 493581 [details]
Service file that generates all key types
Comment 23 Jóhann B. Guðmundsson 2011-04-20 14:53:52 EDT
Created attachment 493582 [details]
Service file that generates rsa key's
Comment 24 Jóhann B. Guðmundsson 2011-04-20 14:54:43 EDT
Created attachment 493583 [details]
Service file that generates rsa1 key
Comment 25 Jóhann B. Guðmundsson 2011-04-20 14:55:25 EDT
Created attachment 493584 [details]
Service file that generates dsa key
Comment 26 Jóhann B. Guðmundsson 2011-04-20 14:58:15 EDT
Now the AUTOCREATE_SERVER_KEYS= and related entries can be removed from /etc/sysconfig/sshd since it no longer serves purpose

user(s) scripts and .ks files simple run the ssh keygen service they want or dont run et all if they dont want it.
Comment 27 Jan F. Chadima 2011-04-21 01:37:18 EDT
(In reply to comment #26)
> 
> user(s) scripts and .ks files simple run the ssh keygen service they want or
> dont run et all if they dont want it.


Which user(s) scripts do you mean? there are nothing like it. There is only one startup script and one configuration file. Try to make it as simple as the original solution.
Comment 28 Jóhann B. Guðmundsson 2011-04-21 08:19:14 EDT
(In reply to comment #27)
> (In reply to comment #26)
> > 
> > user(s) scripts and .ks files simple run the ssh keygen service they want or
> > dont run et all if they dont want it.
> 
> 
> Which user(s) scripts do you mean? there are nothing like it. There is only one
> startup script and one configuration file. Try to make it as simple as the
> original solution.

you cant get it anymore simplier and yet as flexible than this heck I even threw in SSH per connection server daemon setup as an added feature ;)  

This is the final solution from my pov take it or leave it.

It does not get much cleaner than this.
Comment 29 Jóhann B. Guðmundsson 2011-04-21 08:46:38 EDT
By the way the old sysv init scripts should be package seperatly and removed during update. 

You should take a look at in addition to Tom's page I mentioned in comment one

https://fedoraproject.org/wiki/User:Toshio/Systemd_scriptlet_options
Comment 30 Bill Nottingham 2011-04-26 13:35:49 EDT
Moving systemd service RFEs to rawhide.

At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades.

We therefore request:
- wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes.
- work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release.
- do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy
Comment 31 Jóhann B. Guðmundsson 2011-06-21 04:58:36 EDT
Packaging guidelines ready 

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
Comment 32 Mathieu Bridon 2011-06-21 05:59:37 EDT
I've been working on the spec file to make it respect the packaging guidelines, I should have something usable shortly/tomorrow (I need to test it to make sure that upgrades and that using it with non-systemd init work as expected).

However, there are a couple of things I think need to be cleared up before:

1. /etc/sysconfig is Fedora-specific
------------------------------------

One of the goals behind systemd is to unify the whole init process on Linux and get rid of the distro specificities. IMHO, we should keep /etc/sysconfig for compatibilities with older Fedora packages whenever it's posssible, but when it conflicts with the goal of moving to systemd/unifying between distros, it should be removed from the packages.

In this specific case, /etc/sysconfig/sshd makes it much harder and less clean to deal with the key generation, and the solution proposed by Johann (*keygen* services are enabled so they start automatically, but they don't do anything if the keys already exist) is pretty elegant, admins can regenerate the keys manually easily (they just need to remove the keys and restart the services), and for safety/boot speed the services can even be disabled.

The packaging guidelines say:
> Ideally unit files are shipped along upstream packages. In order to make adoption of upstream unit files easy please do
> not introduce new /etc/sysconfig files or options, as /etc/sysconfig files are Fedora-specific. Please support sysconfig
> files only to maintain compatibility with previous Fedora release. The recommended way for administrators to reconfigure
> systemd service files is to copy them from /lib/systemd/system to /etc/systemd/system and modify them there. Unit
> files in /etc/systemd/system override those in /lib/systemd/system if they otherwise carry the same name.
~ https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Support_for_.2Fetc.2Fsysconfig_files

So if you really don't like Johann's solution, another way could be to:
    a. create /usr/bin/sshd_keygen (you can pick a different color for the bikeshed if you don't like this name :) which reads the AUTOCREATE_SERVER_KEYS environment variable and creates the keys (or not) based on its value
    b. create ssh-keygen.service which is enabled by default and runs /usr/bin/sshd_keygen
    c. in ssh-keygen.service, use Environment=AUTOCREATE_SERVER_KEYS=... to set it to the appropriate value
    d. completely get rid of /etc/sysconfig/sshd (unless it provides something else?)

Such a solution would be just as cross-distribution as Johann's, but it would still allow for a configuration as you have right now in /etc/sysconfig. Would you prefer this implementation?

2. socket activation
--------------------

I think that shipping service files for both "classic" always-on service and socket-activated "xinetd-style" service would be very confusing for the user.

My take (which I'm toying with in the spec file right now) would be to have the openssh-server package provide one, and a second subpackage provide the other.

For example, openssh-server would include sshd.service, and openssh-server-ondemand would provide sshd.socket and sshd@.service

But that means we first need to chose which one will be shipped by default. What do you prefer?
(At the moment I'm playing with a -ondemand subpackage as that means that the default would be the same as pre-systemd, which would ease the migration. Later, this could be revisited and changed)

I need this at $dayjob, so I'm willing to spend the time necessary to provide the appropriate changes and test it all, as long as we can clear those two issues above first.
Comment 33 Tomas Mraz 2011-06-21 06:18:23 EDT
(In reply to comment #32)
> I've been working on the spec file to make it respect the packaging guidelines,
> I should have something usable shortly/tomorrow (I need to test it to make sure
> that upgrades and that using it with non-systemd init work as expected).
> 
> However, there are a couple of things I think need to be cleared up before:
> 
> 1. /etc/sysconfig is Fedora-specific
> ------------------------------------
> 
> One of the goals behind systemd is to unify the whole init process on Linux and
> get rid of the distro specificities. IMHO, we should keep /etc/sysconfig for
> compatibilities with older Fedora packages whenever it's posssible, but when it
> conflicts with the goal of moving to systemd/unifying between distros, it
> should be removed from the packages.

Please do not try to sneak in more changes than needed with some ephemeral goals in mind. Our main goal should be to make the distribution usable.

> In this specific case, /etc/sysconfig/sshd makes it much harder and less clean
> to deal with the key generation, and the solution proposed by Johann (*keygen*
> services are enabled so they start automatically, but they don't do anything if
> the keys already exist) is pretty elegant, admins can regenerate the keys
> manually easily (they just need to remove the keys and restart the services),
> and for safety/boot speed the services can even be disabled.

No, the reason for the sysconfig variable that disables the generation of the individual keys was to reduce the need to generate unnecessary keys on first startup of the system where the admin decides so (by means of kickstart). As there might be admins who prefer to use /dev/random for key generation seed generating any unnecessary key can be a big hurdle.

> The packaging guidelines say:
> > Ideally unit files are shipped along upstream packages. In order to make adoption of upstream unit files easy please do
> > not introduce new /etc/sysconfig files or options, as /etc/sysconfig files are Fedora-specific. Please support sysconfig
> > files only to maintain compatibility with previous Fedora release. The recommended way for administrators to reconfigure
> > systemd service files is to copy them from /lib/systemd/system to /etc/systemd/system and modify them there. Unit
> > files in /etc/systemd/system override those in /lib/systemd/system if they otherwise carry the same name.

This is really moot. OpenSSH upstream already contains distro-specific contrib subdirectories so if they decide to add systemd unit file for OpenSSH for Fedora, they can do it easily without any additional effort.

> 
> So if you really don't like Johann's solution, another way could be to:
>     a. create /usr/bin/sshd_keygen (you can pick a different color for the
> bikeshed if you don't like this name :) which reads the AUTOCREATE_SERVER_KEYS
> environment variable and creates the keys (or not) based on its value
>     b. create ssh-keygen.service which is enabled by default and runs
> /usr/bin/sshd_keygen
>     c. in ssh-keygen.service, use Environment=AUTOCREATE_SERVER_KEYS=... to set
> it to the appropriate value
>     d. completely get rid of /etc/sysconfig/sshd (unless it provides something
> else?)
> 
> Such a solution would be just as cross-distribution as Johann's, but it would
> still allow for a configuration as you have right now in /etc/sysconfig. Would
> you prefer this implementation?

Note that you can also set OPTIONS for sshd there with the current SysV initscript.

> 2. socket activation
> --------------------
> 
> I think that shipping service files for both "classic" always-on service and
> socket-activated "xinetd-style" service would be very confusing for the user.
> 
> My take (which I'm toying with in the spec file right now) would be to have the
> openssh-server package provide one, and a second subpackage provide the other.
> 
> For example, openssh-server would include sshd.service, and
> openssh-server-ondemand would provide sshd.socket and sshd@.service
> 
> But that means we first need to chose which one will be shipped by default.
> What do you prefer?
> (At the moment I'm playing with a -ondemand subpackage as that means that the
> default would be the same as pre-systemd, which would ease the migration.
> Later, this could be revisited and changed)
> 
> I need this at $dayjob, so I'm willing to spend the time necessary to provide
> the appropriate changes and test it all, as long as we can clear those two
> issues above first.

Yes, the regular non-socket activated service should be the default and the socket-activated units should be shipped only in a subpackage if at all.
Comment 34 Jan F. Chadima 2011-06-21 06:29:09 EDT
*** Bug 714441 has been marked as a duplicate of this bug. ***
Comment 35 Jan F. Chadima 2011-06-21 06:32:22 EDT
Correctly start/stop openssh is not as easy as you think. Some improved
units (based on Johanes's ones) are packed in the source rpm or git repo. But there are still unsolved problems.

1) in the case of restart service do not kill user child processes, but in the
case of shutdown do kill all user child processes.

2) sshd automatically creates /var/run/sshd.pid => the service pid must have
other file name (/var/run/sshd-s.pid) and the file content must be copied from
/var/run/sshd.pid after starting sshd by the means of initscript / to
distinguish it from the sshd run from command line. 

This 2 problems must be solved before the sshd units may be used. If you can
help with it, you will be welcomed.
Comment 36 Mathieu Bridon 2011-06-21 06:48:58 EDT
(In reply to comment #33)
> (In reply to comment #32)
> > The packaging guidelines say:
> > > Ideally unit files are shipped along upstream packages. In order to make adoption of upstream unit files easy please do
> > > not introduce new /etc/sysconfig files or options, as /etc/sysconfig files are Fedora-specific. Please support sysconfig
> > > files only to maintain compatibility with previous Fedora release. The recommended way for administrators to reconfigure
> > > systemd service files is to copy them from /lib/systemd/system to /etc/systemd/system and modify them there. Unit
> > > files in /etc/systemd/system override those in /lib/systemd/system if they otherwise carry the same name.
> 
> This is really moot. OpenSSH upstream already contains distro-specific contrib
> subdirectories so if they decide to add systemd unit file for OpenSSH for
> Fedora, they can do it easily without any additional effort.

So things become much easier then, we can just do the following:

> >     a. create /usr/bin/sshd_keygen (you can pick a different color for the
> > bikeshed if you don't like this name :) which reads the AUTOCREATE_SERVER_KEYS
> > environment variable and creates the keys (or not) based on its value
> >     b. create ssh-keygen.service which is enabled by default and runs
> > /usr/bin/sshd_keygen
    c. in ssh-keygen.service, source /etc/sysconfig/sshd to get the appropriate value

Upstream would source @@some_macro@@ and the distros-specific build scripts would replace with the appropriate file so the unit file would still remain upstream-able. :)

> Note that you can also set OPTIONS for sshd there with the current SysV
> initscript.

Just as with the unit file: admins can copy the unit file to /etc/systemd/system and edit the command line to add their own options.

> > 2. socket activation
> > --------------------
[... snip ...]
> Yes, the regular non-socket activated service should be the default and the
> socket-activated units should be shipped only in a subpackage if at all.

Ok, then I'll provide some patches to the Rawhide dist-git implementing that shortly.

(In reply to comment #35)
> Correctly start/stop openssh is not as easy as you think. Some improved
> units (based on Johanes's ones) are packed in the source rpm or git repo.

I know, I'm basing my work on the master branch in dist-git.

> But there are still unsolved problems.
> 
> 1) in the case of restart service do not kill user child processes, but in the
> case of shutdown do kill all user child processes.

Well, things are much simpler with systemd: all processes are in the cgroup hierarchy of the service, so they all get killed when the service stops, be it because of a real stop or because of a restart.

There is hope though, with pam_systemd that is supposed to take processes out of the sshd.service cgroup hierarchy so they don't get killed. I know this works for screen (detaching the screen session then closing the ssh connection), I'll investigate further if it can be used more generally.

It might even already work. :)

> 2) sshd automatically creates /var/run/sshd.pid => the service pid must have
> other file name (/var/run/sshd-s.pid) and the file content must be copied from
> /var/run/sshd.pid after starting sshd by the means of initscript / to
> distinguish it from the sshd run from command line.

I don't understand this. PID file are pretty much obsolete and irrelevant with systemd.

Could you give me more details?

> This 2 problems must be solved before the sshd units may be used. If you can
> help with it, you will be welcomed.

Yup, like I said, need it at $dayjob, so I'll need it solved.
Comment 37 Jóhann B. Guðmundsson 2011-06-21 07:21:02 EDT
For 1. pam_systemd should solve your problem.

If you do not use pam_systemd then all user processes started by sshd will be killed when sshd dies, since they are in the same cgroup and we kill all remaining processes of a daemon when it dies.

If you use pam_systemd then the user processes will be moved into a
per-session cgroup, and thus killing the sshd cgroup will have no effect
on it.

pam_systemd systemd can be configured to also kill user processes when the session ends but that is not the default behaviour to do it with a pam_systemd use the parameter kill-user=1 or kill-session=1. 

You can add a cgroup controller to the controller list like controllers=cpu if you want CPU load balancing between sessions (other controllers are also available depending of the kernel cgroup options enabled). If you don't intend to have any type of balancing (or you are using the BFS patch on your kernel) then you can leave the list empty. If this option is omitted then the default is controllers=cpu.

I think it should be sufficient to get this behaviour by adding to /etc/pam.d/sshd 

session     optional    pam_systemd.so kill-user=1

man pam_systemd for further details since you need evaluate what you want the default behaviour to be
Comment 38 Tomas Mraz 2011-06-21 07:48:43 EDT
> I think it should be sufficient to get this behaviour by adding to
> /etc/pam.d/sshd 
> 
> session     optional    pam_systemd.so kill-user=1

There is already pam_systemd.so in /etc/pam.d/system-auth and password-auth so it is unnecessary to add it to /etc/pam.d/sshd separately. Also the kill-user=1 should not be the default.
Comment 39 Jóhann B. Guðmundsson 2011-06-21 08:01:41 EDT
(In reply to comment #38)
> > I think it should be sufficient to get this behaviour by adding to
> > /etc/pam.d/sshd 
> > 
> > session     optional    pam_systemd.so kill-user=1
> 
> There is already pam_systemd.so in /etc/pam.d/system-auth and password-auth so
> it is unnecessary to add it to /etc/pam.d/sshd separately. Also the kill-user=1
> should not be the default.

Yeah I copy pasted that line from one of my test conf lying around was not sure if it had made in as default on F16 since I dont have an F16 test box running at the moment here @ work but are you guys saying that it does not suffice as a solution for nr.1 and could you clarify a bit what's needed for 2. preferably point me to the section in the old sysv init script where this is done.
Comment 40 Jan F. Chadima 2011-06-21 08:52:11 EDT
(In reply to comment #36)
> 
> Could you give me more details?
> 
There is a need to run sshd by systemd and run by the hand simultaneously on one computer and to make them to not disturb each other.
Comment 41 Jóhann B. Guðmundsson 2011-06-21 09:15:33 EDT
Fine and dandy again how was this done with the old sysv init script?
Comment 42 Jóhann B. Guðmundsson 2011-06-21 10:44:07 EDT
Seriously trying to get some information from you is like stealing a candy from a baby. 

Could you please explain what exactly is the problem here and how this was solved in the old sysv init file without the end user having to modify it along with the sshd_config file. 

Running the default sshd systemd file in git works just fine with another instance of sshd running of an copy of the same service file pointing to a copy of the sshd1_config and yet another instance which is started manually of the cli also on a copy of a sshd_config file.   

2 Running Instance of systemd service file that are in git. 

# cp /lib/systemd/system/sshd.service /etc/systemd/system/sshd1.service

# diff /lib/systemd/system/sshd.service /etc/systemd/system/sshd1.service 
7c7
< PIDFile=/var/run/sshd.pid
---
> PIDFile=/var/run/sshd1.pid
9c9
< ExecStartPre=/usr/sbin/sshd -t
---
> ExecStartPre=/usr/sbin/sshd -f /etc/ssh/sshd1_config

# cp /etc/ssh/sshd_config /etc/ssh/sshd1_config

diff /etc/ssh/sshd_config /etc/ssh/sshd1_config 
15c15
< ListenAddress *
---
> ListenAddress *:1111
121c121
< #PidFile /var/run/sshd.pid
---
> PidFile /var/run/sshd1.pid

# systemctl start sshd.service sshd1.service && systemctl status sshd.service sshd1.service
sshd.service - OpenSSH server daemon.
	  Loaded: loaded (/lib/systemd/system/sshd.service)
	  Active: active (running) since Tue, 21 Jun 2011 14:30:02 +0000; 26ms ago
	 Process: 2247 ExecStart=/usr/sbin/sshd $OPTIONS (code=exited, status=0/SUCCESS)
	 Process: 2244 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
	Main PID: 2250 (sshd)
	  CGroup: name=systemd:/system/sshd.service
		  └ 2250 /usr/sbin/sshd

sshd1.service - OpenSSH server daemon.
	  Loaded: loaded (/etc/systemd/system/sshd1.service)
	  Active: active (running) since Tue, 21 Jun 2011 14:30:02 +0000; 22ms ago
	 Process: 2249 ExecStart=/usr/sbin/sshd $OPTIONS (code=exited, status=0/SUCCESS)
	 Process: 2245 ExecStartPre=/usr/sbin/sshd -f /etc/ssh/sshd1_config (code=exited, status=0/SUCCESS)
	Main PID: 2248 (sshd)
	  CGroup: name=systemd:/system/sshd1.service
		  └ 2248 /usr/sbin/sshd -f /etc/ssh/sshd1_config

netstat -pant | grep ssh

tcp        0      0 127.0.0.1:22                0.0.0.0:*                   LISTEN      2250/sshd           
tcp        0      0 127.0.0.1:1111              0.0.0.0:*                   LISTEN      2248/sshd 
tcp        0      0 ::1:22                      :::*                        LISTEN      2250/sshd           
tcp        0      0 ::1:1111                    :::*                        LISTEN      2248/sshd

Let's turn off sshd.service 

# systemctl stop sshd.service && systemctl status sshd.service sshd1.service
sshd.service - OpenSSH server daemon.
	  Loaded: loaded (/lib/systemd/system/sshd.service)
	  Active: failed since Tue, 21 Jun 2011 14:34:56 +0000; 70ms ago
	 Process: 2247 ExecStart=/usr/sbin/sshd $OPTIONS (code=exited, status=0/SUCCESS)
	 Process: 2244 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
	Main PID: 2250 (code=exited, status=255)
	  CGroup: name=systemd:/system/sshd.service

sshd1.service - OpenSSH server daemon.
	  Loaded: loaded (/etc/systemd/system/sshd1.service)
	  Active: active (running) since Tue, 21 Jun 2011 14:30:02 +0000; 4min 54s ago
	 Process: 2249 ExecStart=/usr/sbin/sshd $OPTIONS (code=exited, status=0/SUCCESS)
	 Process: 2245 ExecStartPre=/usr/sbin/sshd -f /etc/ssh/sshd1_config (code=exited, status=0/SUCCESS)
	Main PID: 2248 (sshd)
	  CGroup: name=systemd:/system/sshd1.service
		  └ 2248 /usr/sbin/sshd -f /etc/ssh/sshd1_config

# netstat -pant | grep ssh
tcp        0      0 127.0.0.1:1111              0.0.0.0:*                   LISTEN      2248/sshd           
tcp        0      0 ::1:1111                    :::*                        LISTEN      2248/sshd         

Let's throw in the mix a manually started one. 

# cp /etc/ssh/sshd_config /etc/ssh/sshd2_config 
# diff /etc/ssh/sshd_config /etc/ssh/sshd2_config 
15c15
< ListenAddress *
---
> ListenAddress *:2222
121c121
< #PidFile /var/run/sshd.pid
---
> PidFile /var/run/sshd2.pid

#/usr/sbin/sshd -f /etc/ssh/sshd2_config

#netstat -pant | grep ssh
tcp        0      0 127.0.0.1:2222              0.0.0.0:*                   LISTEN      2072/sshd           
tcp        0      0 127.0.0.1:22                0.0.0.0:*                   LISTEN      2378/sshd           
tcp        0      0 127.0.0.1:1111              0.0.0.0:*                   LISTEN      2248/sshd      
tcp        0      0 ::1:2222                    :::*                        LISTEN      2072/sshd           
tcp        0      0 ::1:22                      :::*                        LISTEN      2378/sshd           
tcp        0      0 ::1:1111                    :::*                        LISTEN      2248/sshd  

Again what exactly is the problem here and how was it solved in the old sysv init script.
Comment 43 Mathieu Bridon 2011-06-22 00:07:23 EDT
A few things: it seems like you are still working on the init script and changing things in there.

It might be nice to know exactly where you want to go, to make it work properly with systemd unit files.

Also, it might be proposed to block from Fedora 16 all services that do not have native systemd unit files:
    http://lists.fedoraproject.org/pipermail/devel/2011-June/153234.html

OpenSSH being such a critical piece of a Fedora system, it appears extremely important that we get the conversion one as soon as possible.

From the systemd point of view, PID files are useless and obsoletes. The sshd command might create one (and I hope remove it), but systemd couldn't care less.

What exactly is that PID file used for? Does the sshd **daemon** (i.e not its init script) need it for some reason? 

If nothing uses it but the initscript, then:
- the PidFile= directive can be removed from the .service file
- it doesn't matter if the PID file is overwritten by a second, manually started sshd

This really looks like a non-issue with systemd, but I could be wrong.
Comment 44 Mathieu Bridon 2011-06-22 04:55:59 EDT
Created attachment 505945 [details]
[PATCH 1/3] Split out the host key generation into its own tool.

The init script calls it now, and when we move to systemd, it will make it easier to call it if its outside of the init script.

For all three possible configurations in `/etc/sysconfig/sshd', it has been tested that it works in the following cases:
- starting the sshd service with the initscript
- running `/usr/sbin/sshd-keygen' manually
Comment 45 Mathieu Bridon 2011-06-22 04:56:49 EDT
Created attachment 505946 [details]
Full migration to a native systemd service.

This commit brings in the required changes to the service file and the packaging spec so that OpenSSH is now a full systemd service.

Changes were made conformly to the packaging guidelines:
    https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
    https://fedoraproject.org/wiki/Packaging:ScriptletSnippets
    https://fedoraproject.org/wiki/Packaging:SysVInitScript

A `-sysvinit' subpackage was introduced, to ensure compatibility for people who don't use systemd as their init system.
Comment 46 Mathieu Bridon 2011-06-22 04:58:23 EDT
Created attachment 505947 [details]
[PATCH 3/3] Fixed a typo in a comment

This patch is purely a pedantic commit to fix a typo, I thought I would attach it here even though it is not directly related, as I found the typo while working on the systemd stuff.
Comment 47 Mathieu Bridon 2011-06-22 05:14:26 EDT
So, a couple of comments on the three patches I have just attached.

First, they can be applied directly on top of the master branch in the openssh dist-git module.

Second, I think I took care of everything that was needed regaring the keys generation and the `/etc/sysconfig/sshd' file. I tested it for every possible value of AUTOCREATE_SERVER_KEYS, both while starting the service with the initscript or the unit file, as well as by running the new command (introduced in patch 0001) manually.

I just tested the pam_systemd stuff:
[root@localhost ~]# alias psc='ps xawf -eo pid,user,cgroup,args'
[root@localhost ~]# psc
[... snip ...]
  941 root     name=systemd:/user/root/4   sshd: root@pts/0    
  945 root     name=systemd:/user/root/4    \_ -bash
  977 root     name=systemd:/user/root/4        \_ ps xawf -eo pid,user,cgroup,args
  972 root     cpu:/system/sshd.service;na /usr/sbin/sshd -D

As you can see the user processes are outside of the cgroup of the sshd service. As such, you don't lose your shell when you restart the service. (I verified it)

However, you also don't lose your connexion if you stop the service. That will probably require some work on pam_systemd to get it correctly, but it shouldn't be a blocker for the openssh migration to systemd.

I chose not to do the on-demand socket activation stuff for now, since we seemed to agree that it would be an optional feature. It seems more important that we agree on the default basic behavior first. :)

Finally, I believe those patches address all the comments that have been made in this bug, except maybe the PID file stuff. I can address those once I got the answers to my questions in comment 43.

---

I would also like to apologize for my earlier comment:
(In reply to comment #43)
> A few things: it seems like you are still working on the init script and
> changing things in there.

That seemed to imply that you were changing the init script "behind our backs" to make it do what you said is required after Johann asked how that was handled currently. That's in fact what I was implying, but I got confused by the fact that I only pulled this commit this morning, although looking at the commit date I can now see it had been made a day before.

My mistake, I should have checked more thoroughly and not assumed bad faith, and for that I'm sorry.

The rest of comment 43 still makes sense though and it would be awesome if it could be addressed. :)
Comment 48 Mathieu Bridon 2011-06-22 05:28:13 EDT
(In reply to comment #47)
> However, you also don't lose your connexion if you stop the service. That will
> probably require some work on pam_systemd to get it correctly, but it shouldn't
> be a blocker for the openssh migration to systemd.

Well, I had never even tried it, but I get the exact same behavior on a RHEL6 machine with Upstart.

So I guess this is not a problem after all. :)
Comment 49 Tomas Mraz 2011-06-22 08:00:58 EDT
(In reply to comment #48)
> (In reply to comment #47)
> > However, you also don't lose your connexion if you stop the service. That will
> > probably require some work on pam_systemd to get it correctly, but it shouldn't
> > be a blocker for the openssh migration to systemd.
> 
> Well, I had never even tried it, but I get the exact same behavior on a RHEL6
> machine with Upstart.
> 
> So I guess this is not a problem after all. :)

Does the Fedora with systemd units for sshd also correctly terminate the client sessions before the network shuts down on system shutdown?
Comment 50 Tomas Mraz 2011-06-22 08:04:49 EDT
(In reply to comment #47)
> However, you also don't lose your connexion if you stop the service. That will
> probably require some work on pam_systemd to get it correctly, but it shouldn't
> be a blocker for the openssh migration to systemd.

This is not a bug! This is actually correct behavior if you just stop the sshd service (not during the system shutdown).
Comment 51 Harald Reindl 2011-06-22 08:10:58 EDT
correct!

> [root@arrakisvm:~]$ service sshd stop
> sshd beenden:                                              [  OK  ]
> [root@arrakisvm:~]$ service sshd start
> sshd starten:                                              [  OK  ]
> [root@arrakisvm:~]$ cat /etc/redhat-release 
> Fedora release 14 (Laughlin)

to the question above:
this does not work on F15 even with the old LSB-scripts
"reboot" does not close the ssh-sessions and you have frozen terminals if you are using KeepAlive instead get disconnected as it was before F15
Comment 52 Tomas Mraz 2011-06-22 08:30:55 EDT
I've just tested the behaviour on shutdown on F15 and it works fine for me - it shuts the connections down.
Comment 53 Mathieu Bridon 2011-06-23 05:29:46 EDT
Created attachment 506166 [details]
[PATCH 2/4] Full migration to a native systemd service.

This commit brings in the required changes to the service file and
the packaging spec so that OpenSSH is now a full systemd service.

Changes were made conformly to the packaging guidelines:
    https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
    https://fedoraproject.org/wiki/Packaging:ScriptletSnippets
    https://fedoraproject.org/wiki/Packaging:SysVInitScript

A `-server-sysvinit' subpackage was introduced, to ensure compatibility
for people who don't use systemd as their init system.
Comment 54 Mathieu Bridon 2011-06-23 05:30:30 EDT
Created attachment 506167 [details]
[PATCH 3/4] Fixed a typo in a comment
Comment 55 Mathieu Bridon 2011-06-23 05:31:14 EDT
Created attachment 506168 [details]
[PATCH 4/4] Added a -server-ondemand subpackage.

The new subpackage only brings the system unit files necessary to
run a socket activated (à la xinetd) SSH daemon.

They were added in a subpackage so that users would get the same
behavior by default as with the SysV init script.
Comment 56 Mathieu Bridon 2011-06-23 05:50:57 EDT
So here are the new patches.

I modified the second one to name the SysV subpackage openssh-server-sysvinit instead of openssh-sysvinit, to make it more consistent with the new openssh-server-ondemand.

Patch 3 is just rebased on top of the new patch 2. It contains no actual modifications from the previous one, but I figured I'd just attach it to avoid any problem applying it.

The real new one is patch 4, which introduces the openssh-server-ondemand subpackage.

So basically, an admin can do:
    # yum update openssh\*

And he now has the systemd-enabled services. I tested the upgrade path, and everything went smoothly in my tests.

Then, to enable the on-demand service, it's only a matter of running:
    # yum install openssh-server-ondemand
    # systemctl start sshd.socket

The second command wil automatically stop the "traditional" sshd server if it was running as it conflicts with the socket.

I also tested what happens when rebooting the machine. Connections are cleanly cut, both with the traditional service and with the socket activated one, no sessions are left hanging.
Comment 57 Tomas Mraz 2011-06-23 06:04:09 EDT
Great, I think the patches are now in shape to be added to Rawhide.

Jan, can you please apply the patches?
Comment 58 Mathieu Bridon 2011-06-24 00:28:58 EDT
Created attachment 509670 [details]
[PATCH 4/4] Added a -server-ondemand subpackage.

There was a problem with the on-demand server:
# systemctl --full | grep sshd
sshd-keygen.service       loaded active exited        SSH server keys generation.
sshd@192.168.122.2:22-192.168.122.1:55612.service loaded failed failed        SSH Per-Connection Server
sshd@192.168.122.2:22-192.168.122.1:55613.service loaded failed failed        SSH Per-Connection Server
sshd@192.168.122.2:22-192.168.122.1:57849.service loaded active running       SSH Per-Connection Server
sshd.socket               loaded active listening     sshd.socket

The failed units are leftovers from previous connections. The connections were closed cleanly (logout, ctrl+d,...) but the units stayed there in systemctl.

Osirix_X in #systemd gave me the answer: when a connection is closed, the process exits with a non-zero status code, so the  ExecStart= command must start with an hyphen. (the hyphen indicates that an error code returned by the process must not be interpreted as a failure of the service)

So here is an updated patch 4 that fixes this issue:
# systemctl --full | grep sshd
sshd-keygen.service       loaded active exited        SSH server keys generation.
sshd@192.168.122.2:22-192.168.122.1:49579.service loaded active running       SSH Per-Connection Server
sshd.socket               loaded active listening     sshd.socket
[... after closing the connection then reopening a new one ...]
# systemctl --full | grep sshd
sshd-keygen.service       loaded active exited        SSH server keys generation.
sshd@192.168.122.2:22-192.168.122.1:49580.service loaded active running       SSH Per-Connection Server
sshd.socket               loaded active listening     sshd.socket
Comment 59 Jan F. Chadima 2011-06-24 04:32:56 EDT
(In reply to comment #58)
> 
> Osirix_X in #systemd gave me the answer: when a connection is closed, the
> process exits with a non-zero status code, so the  ExecStart= command must
> start with an hyphen. (the hyphen indicates that an error code returned by the
> process must not be interpreted as a failure of the service)
> 
The issue of non zero return values was once solved in openssh ... I prefer to look at it again and solve the problem correctly.
Comment 60 Mathieu Bridon 2011-06-24 04:57:23 EDT
(In reply to comment #59)
> (In reply to comment #58)
> > 
> > Osirix_X in #systemd gave me the answer: when a connection is closed, the
> > process exits with a non-zero status code, so the  ExecStart= command must
> > start with an hyphen. (the hyphen indicates that an error code returned by the
> > process must not be interpreted as a failure of the service)
> > 
> The issue of non zero return values was once solved in openssh ... I prefer to
> look at it again and solve the problem correctly.

That would indeed be much better, as this way the unit would be marked as 'failure' if ssh failed to start, whereas my latest patch would make it look like a success.

If you find a proper fix for OpenSSH (unfortunately I think this is out of my skills), just 's/ExecStart=-/ExecStart=/' in the sshd@.service file.

Note that this only concerns the fourth patch, not the three other ones, so they shouldn't be blocked by this issue.
Comment 61 Tomas Mraz 2011-06-24 05:14:50 EDT
I think this non-zero return is actually fixed in Rawhide already.

Mathieu, are you testing it on Rawhide or on F15?
Comment 62 Mathieu Bridon 2011-06-24 06:03:45 EDT
(In reply to comment #61)
> I think this non-zero return is actually fixed in Rawhide already.
> 
> Mathieu, are you testing it on Rawhide or on F15?

Rawhide, fully updated, with an openssh I rebuilt with my patches applied.

# tail /var/log/messages
[...]
Jun 24 18:02:37 localhost systemd[1]: sshd@192.168.122.2:22-192.168.122.1:43365.service: main process exited, code=exited, status=255
Jun 24 18:02:37 localhost systemd[1]: Unit sshd@192.168.122.2:22-192.168.122.1:43365.service entered failed state.
[...]


# systemctl --full | grep sshd
sshd-keygen.service       loaded active exited        SSH server keys generation.
sshd@192.168.122.2:22-192.168.122.1:43365.service loaded failed failed        SSH Per-Connection Server
sshd@192.168.122.2:22-192.168.122.1:43366.service loaded active running       SSH Per-Connection Server
sshd.socket               loaded active listening     sshd.socket
Comment 63 Tomas Mraz 2011-06-24 11:14:44 EDT
Ah I misunderstood the issue - I thought you're talking about the regular sshd daemon exit not the per-connection process spawned with the inetd option. That is yet to be fixed.
Comment 64 Jan F. Chadima 2011-06-27 01:36:38 EDT
(In reply to comment #62)
> (In reply to comment #61)
> > I think this non-zero return is actually fixed in Rawhide already.
> > 
> > Mathieu, are you testing it on Rawhide or on F15?
> 
> Rawhide, fully updated, with an openssh I rebuilt with my patches applied.
> 
> # tail /var/log/messages
> [...]
> Jun 24 18:02:37 localhost systemd[1]:
> sshd@192.168.122.2:22-192.168.122.1:43365.service: main process exited,
> code=exited, status=255
> Jun 24 18:02:37 localhost systemd[1]: Unit
> sshd@192.168.122.2:22-192.168.122.1:43365.service entered failed state.
> [...]
> 
status 255 is in sshd used for fatal errors ... it follows the fatal logging message... can you look at the /var/log/secure please.
Comment 65 Mathieu Bridon 2011-06-27 02:19:30 EDT
(In reply to comment #64)
> status 255 is in sshd used for fatal errors ... it follows the fatal logging
> message... can you look at the /var/log/secure please.

Sure, here it is.

I ran "tail -f /var/log/{messages,secure}" on my Rawhide box with the sshd.socket unit running.

When a user connects, here is what appears in those files:
==> /var/log/messages <==
Jun 24 22:57:07 localhost systemd[1]: Cannot add dependency job for unit hwclock-load.service, ignoring: Unit hwclock-load.service failed to load: No such file or directory. See system logs and 'systemctl status' for details.

==> /var/log/secure <==
Jun 24 22:57:10 localhost sshd[1176]: Accepted password for root from 192.168.122.1 port 57117 ssh2
Jun 24 22:57:10 localhost sshd[1176]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jun 24 22:57:10 localhost sshd[1180]: ssh_selinux_change_context: setcon failed with Invalid argument

Then, when he disconnects:
==> /var/log/secure <==
Jun 24 22:57:17 localhost sshd[1176]: Received disconnect from 192.168.122.1: 11: disconnected by user
Jun 24 22:57:17 localhost sshd[1176]: pam_unix(sshd:session): session closed for user root

==> /var/log/messages <==
Jun 24 22:57:17 localhost systemd[1]: sshd@192.168.122.2:22-192.168.122.1:57117.service: main process exited, code=exited, status=255
Jun 24 22:57:17 localhost systemd[1]: Unit sshd@192.168.122.2:22-192.168.122.1:57117.service entered failed state.

Could that SELinux issue (which happens when **connecting**, not when disconnecting) be the cause of the problem?
Comment 66 Jóhann B. Guðmundsson 2011-06-27 04:35:02 EDT
A simple way to determine that is to put selinux in permissive mode ( set permissive in /etc/selinux/config + reboot ) or to run setenforce 0 from cli and try again. 

I'm pretty sure Dan will fix that a.s.a.p once this has been package and he can test that in rawhide. 

Is there something preventing the native systemd being package and shipped already that cant be fixed during rest of the development cycle so we dont end up blocking the alpha release?
Comment 67 Mathieu Bridon 2011-06-27 05:12:16 EDT
(In reply to comment #66)
> A simple way to determine that is to put selinux in permissive mode ( set
> permissive in /etc/selinux/config + reboot ) or to run setenforce 0 from cli
> and try again. 

Oh, I have no idea why I just didn't think about trying that. Must have been too early in the morning... :-/

In any case, I just disabled completely SELinux. Now I don't get that error message anymore.

But I still get the 255 error code, and I still don't have any other message that could explain where it comes from.
Comment 68 Jóhann B. Guðmundsson 2011-06-27 05:21:37 EDT
(In reply to comment #67)
> (In reply to comment #66)
> But I still get the 255 error code, and I still don't have any other message
> that could explain where it comes from.

That's probably a bug in openssh. 

Tomas is there anything preventing this that cant be fixed during the rest of the release cycle so this can be to package and ship?
Comment 69 Tomas Mraz 2011-06-27 05:43:29 EDT
I'd say let's ship the regular daemon unit and then investigate the ondemand problems. I do not think we should just blindly add the ondemand subpackage - people will try it even if it is marked as experimental and they will get to the problems.

But that should not block shipping the regular daemon unit.
Comment 70 Jan F. Chadima 2011-06-28 07:37:04 EDT
Mathieu, please can you please review the changes? (and close this BZ if it fits your expectations)
Comment 71 Mathieu Bridon 2011-06-28 22:37:17 EDT
The changes you applied won't work.

One problem I can see right away is that the triggers are versioned. You didn't bump the release tag as I did, so you can't use the same version-release for the triggers.

Incidentally, this is why I had provided git patches: so that you could apply them directly (with git am) once you had reviewed them, instead of having to recreate the changes yourself manually.

So I guess I'll have to double-check everything now, again. The bits about the upgrade path are quite sensitive to get right, so I would have appreciated not having to rebuild the package and test them one more time, as if the first time had been for nothing. :(
Comment 72 Tomas Mraz 2011-06-30 05:09:20 EDT
I reviewed it and it should be OK except the comment typo fix is not applied.
Comment 73 Mathieu Bridon 2011-06-30 05:23:06 EDT
(In reply to comment #72)
> I reviewed it and it should be OK

Yes, now that the release was bumped to 12 it should work (although it looks weird to go from 10 to 12, putting the triggers to 11 would have made more sense imho).
Comment 74 Jóhann B. Guðmundsson 2011-06-30 05:26:15 EDT
It would be good that this bug get's closed now that we are shipping native systemd service file to get it of the blocker bugs list I've https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd Accordingly. 

Great work everyone

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