On Wed, 14.07.10 11:53, Colin Walters (walters@xxxxxxxxxx) wrote: > > On Wed, Jul 14, 2010 at 11:43 AM, Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > > > time which is enabled via "systemd-install" because the admin wanted so, > > Does it make sense to export iscsid for administrator control? I mean > - won't things explode if it's stopped? It's more of a userspace > component of the operating system, as opposed to an add-on server that > runs on top of the OS like httpd. I think it does make sense to give the admin control, since it can be used to browse for iscsi devices on the network, which is something admin might or might not want. systemd actually supports the destinction between admin-controllable and non-admin-controllable enabling of units. For example, if you want to make sure from within a package that a service is run during normal runtime without giving the admin tha ability to disable it you would just package a symlink like this: /lib/systemd/system/multi-user.target.wants/foo.service → /lib/systemd/system/foo.service (along with your service file foo.service; and note that multi-user.target is a unit which is kinda equivalent to the old runlevel 3, and this symlink simply hooks in foo.service into that unit). And if you want to give the admin the control, then you would not put any symlinks like this into the package, but instead include a small section in the .service file which contains information about how a service should be hooked in if it is enabled. That can look like this: <snip> [Install] WantedBy=multi-user.target </snip> This section is then read by systemd-install, which is the admin's command to enable or disable units. When he calls "systemd-install enable foo.service" this would then have the effect of create a symlink like this: /etc/systemd/system/multi-user.target.wants/foo.service → /lib/systemd/system/foo.service Note the difference in the /etc vs. /lib prefix. Or in other words: If you have a service that should be enabled and be outside of the admin control place a link in /lib/systemd/... and do so by simply shipping it like that in the rpm. If you have a service that should be enabled/disabled depending on admin decision, then place an [Install] section in the unit file which then allows the admin to enable this unit via 'systemd-install' and results in symlinks in /etc/systemd/.... That all said I think if there is reasonable doubt, then I'd go the systemd-install way, to empower the admin to do whatever he likes to do. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
