[HEADS-UP] The systemd unit files I'll post
mzerqung at 0pointer.de
Thu Jul 15 14:18:06 UTC 2010
On Thu, 15.07.10 08:58, Till Maas (opensource at till.name) wrote:
> On Thu, Jul 15, 2010 at 03:30:41AM +0200, Lennart Poettering wrote:
> > I have uploaded preliminary versions of the unit files I put together
> > for the various services of our default install. I think they give an
> > indication how simple these files actually are:
> > http://0pointer.de/public/systemd-units/
> > Please have a look and if you have any questions just ask!
> How are the SSH host keys supposed to be generated with systemd?
> Currently the initscript creates them, if they do not exist.
Well, I believe the right place to create them would be in sshd
itself. I don't think the current approach to do this manually in the
shell is a good idea. (And am I the only one who wonders why the chmod's
in the init script are applied *after* key generation? If ssh-keygen
doesn't use umask internally then this is a gaping security hole!) Now,
not sure how feasible it is to get this accepted in ssh upstream, so my
(short term?) fix for this would be to add a service
ssh-generate-keys.service which basically just calls a shell script with
the current key generation code in it. It would then be pulled in by
ssh at .service (in case you are wondering: unit files with an @ are
instantiated for devices, or connectsion, or whatever). The effect of
that would then be that the key generation is done on the first
connection and only then, and does not delay the normal boot-up. To my
knowledge the key generation is fast enough these days so that the
little bit longer delay on the first log-in is acceptable, in particular
because the first login tends to be the admin himself.
> How are the /etc/sysconfig/<service> files now used? E.g. on F12 ntpd
> drops privs to ntp:ntp according to /etc/sysconfing/ntpd, but
> ntpd.service file seems not to do something like this.
To be frank I believe that a big number of the /etc/sysconfig options
are simply redundant and should go away. For example, I see little
reason why the admin should be able to configure the user id to drop
priviliges to for ntpd. There's no reason for that. I'd simply include
the "-u ntp:ntp" in the command line of ntpd.service and be done with
That said, we actually have some minimal support to deal with this: In
addition to a setting "Environment=" which may be used to control
environment variables from within the .service file there is
"EnvironmentFile=" which has the same effect but reads the environment
variables from a file in the same format as those /etc/sysconfig files
(yes, i know, these are currently handled as shell scripts, but they are
actually just variable assignments). And then there is some minimal env
var replacement available on the command lines specified in the .service
file to make use to them.
I can only urge people to rethink their use of sysconfig fragments
btw. Before you blindly go and create as many var assignments in those
fragments as you can think of, think again and try to find a use case why
somebody might want to actually fiddle with that one variable. And in
the case for the priv dropping of ntpd for example I see little reason
to make that configurable.
Note that if admins want to change the parameters passed to daemons they
have a very easy way to do that in systemd: they can just copy the
rpm-owned service file from /lib/systemd/system into
/etc/systemd/systemd and then make their changes. I generally believe
this is easier and safer then to split up the startup configuration
between multiple files and then have the admin figure out which file he
should be editing, like it is currently done with SysV.
> And why should acpid go away? What is there that can be used instead?
Used for what exactly?
upowerd handles this now.
Lennart Poettering - Red Hat, Inc.
More information about the devel