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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux