[HEADS-UP] The systemd unit files I'll post

[Simo Sorce]

On Thu, 15 Jul 2010 16:18:06 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:

> 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.

What you believe conflicts with reality, I think reality wins for now.
Try to not get in too many battles at once. Whether you like it or not
there are still a lot of programs that *assume* init scripts are
available and things can be done there, and not just setting
environment variables.
Also you can't assume something can be always deferred at connection
time.
We have a bug open with CUPS trying to generate SSL certs on the first
connections, being too slow and causing the client to timeout.
So no, you can't make assumptions here.

> 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.

So you are just re-invented sysconfig ?
sysconfig was added exactly so that admins could change configurations
without touching init scripts so that rpm updates would be able to
deploy new init scripts without blowing away customizations.

Why re-inventing the wheel here ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York