On Thu, Jul 15, 2010 at 04:18:06PM +0200, Lennart Poettering wrote: > On Thu, 15.07.10 08:58, Till Maas ([email protected]) 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,
Usually ssh-keygen creates key files with the correct permissions. I
guess the chmod can be removed.
> > 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
> it.
Yes, changing the user/group for ntp is probably of little use, but
there are some useful options for some other services. E.g. to use a
different config file or to disable the RSA1/DSA host key generation of
ssh.
> 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.
Maybe if all the systemd files are as simple as the ones I looked at,
this would work. The only downside I see is that one can easier miss
changes to /lib/systemd/ files and not merge them into the /etc/systemd
files, because there will be no .rpm{save,new,orig} files.
> > And why should acpid go away? What is there that can be used instead?
>
> Used for what exactly?
To react on ACPI events, e.g. when the lid of a notebook is opened[0]
or when the notebook is removed from a docking station.
> upowerd handles this now.
It looks like it is as bad documented as hal. At least the manpages on
freedesktop.org[1] did not provide any information about what one can do
with it. Acpid has a very good manpage that shows how one can easily
add scripts that react to any ACPI event.
Regards
Till
[0]
http://blogs.23.nu/till/2010/01/acpi-workaround-for-broken-display-reset-after-lid-close-in-fedora-12/
[1]
http://upower.freedesktop.org/docs/UPower.7.html
pgpfm9BA6IM2d.pgp
Description: PGP signature
-- devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/devel
