On Thu, Jul 15, 2010 at 10:18 AM, Lennart Poettering
> 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
as a downstream of Fedora (OLPC!) I am following this closely.
We use (both on XO and XS) various init scripts to perform
configuration and OS "post-upgrade" tasks. Some runs only on first
boot, other bits are executed on every boot.
This use of init script has a long history, hopefully there's a
reasonable way to do ut under systemd. A "you can use the legacy
init.d script support" answer is ok with me. Just want to make sure
it's on your map.
> 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.
The support in init scripts for configuration overrides (via
/etc/sysconfig) is important as a sysadmin practice in the field, and
something we rely on for the XS (one of the OSs produced by OLPC).
A sysadmin wanting to override config values that are passed via env
or cmdline parameters to a deamon should not need to modify the init
script, but a pure configuration file that will not get rpm upgrade
Maybe the unit files from systemd, being simpler, are more appropriate
to edit locally without concerns of future conflict. But for many
services, it is extremely important to make it easy and clear how and
where to edit those variables.
That said, we actually have some minimal support to deal with this:
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.
Ok, so it'll recognize shellish variable assignment, but not any
I can only urge people to rethink their use of sysconfig fragments
I can only urge you to work with sysadmins :-)
Note that if admins want to change the parameters passed to daemons
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.
Oooohk. So that's the "sane way"? An /etc/systemd/myservice overrodes
/lib/systemd/system/myservice completely and cleanly? Great.
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first