On Thu, Jul 15, 2010 at 04:18:06PM +0200, Lennart Poettering wrote: > On Thu, 15.07.10 08:58, Till Maas (opensource@xxxxxxxxx) 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
Attachment:
pgpE0PLfif6Sx.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel