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, 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@.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 it. 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 -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
