Please do not reintroduce shell scripts when we don't need them

Posted Feb 7, 2014 15:24 UTC (Fri) by Shewmaker (guest, #1126)
In reply to: Please do not reintroduce shell scripts when we don't need them by Siosm
Parent article: Systemd programming part 1: modularity and configuration

I've found that config services can be extremely useful in cluster settings where I don't want to have hundreds or thousands of slightly different config files to manage. The config services can look up a host's name and ip address in a flat-file describing the entire cluster and generate all of the configuration files necessary to customize the host.

That way you get one system image instead of many, and can treat a cluster like a single system instead of thousands.

I'm not saying that everything should be optimized for the cluster use case, but it would be nice if distributions kept that more in mind and didn't actively make it more difficult with their new configuration tools (e.g. RedHat's NetworkManager has been unfriendly towards automation, although I've heard it has a command line now).

Please do not reintroduce shell scripts when we don't need them

Posted Feb 7, 2014 15:59 UTC (Fri) by Siosm (subscriber, #86882) [Link] (6 responses)

> The config services can look up a host's name and ip address in a flat-file describing the entire cluster and generate all of the configuration files necessary to customize the host.

As far as I understand this looks like a one time process, not really a case for a systemd unit and more adapted to "configuration management" tools usage.

Moreover, you could use systemd unit specifiers (http://www.freedesktop.org/software/systemd/man/systemd.u...) to tell your service to start using a particular configuration depending on the hostname.

Also, why is the maintainer discussing this issue here and not on the systemd mailing list where he could get official recommendations/suggestions from the developers themselves?

Please do not reintroduce shell scripts when we don't need them

Posted Feb 7, 2014 16:07 UTC (Fri) by Siosm (subscriber, #86882) [Link] (5 responses)

From the article:
> Unfortunately the "systemctl" command handles an abbreviated unit name but it assumes a ".service" suffix rather than a ".target" suffix. This tends to discourage the use of targets and blurs the line between API and implementation.

Maybe this issue should also be reported upstream?

Please do not reintroduce shell scripts when we don't need them

Posted Feb 10, 2014 10:43 UTC (Mon) by Darkmere (subscriber, #53695) [Link] (4 responses)

It used to be that systemctl would throw a big "huh? Whatchatalkingabout?" When you didn't specify .service, which made "systemctl restart sshd" annoying and hard to use. So they made .service be the default.

Maybe it should balk if there's an ambigious selection (".service and .target? I'm not making a choice!" )

Please do not reintroduce shell scripts when we don't need them

Posted Feb 13, 2014 11:12 UTC (Thu) by kisko (guest, #95529) [Link] (3 responses)

In this case sshd would be an ambigious selection because there's also sshd.socket unit present.

Please do not reintroduce shell scripts when we don't need them

Posted Feb 13, 2014 13:02 UTC (Thu) by Darkmere (subscriber, #53695) [Link] (2 responses)

I have to read up more on what socket-activated things I have on my system, going to be interesting I think.

I'm a tad worried that I might have some things socket-activated where I thought they were disabled.

Please do not reintroduce shell scripts when we don't need them

Posted Feb 13, 2014 14:17 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

If you run "systemctl disable sshd", you get a warning that sshd.socket may still cause its activation and a command you can use to disable it as well. I don't know which version this was implemented in, but in pretty sure it was after 204.

Please do not reintroduce shell scripts when we don't need them

Posted Feb 13, 2014 17:13 UTC (Thu) by Darkmere (subscriber, #53695) [Link]

Yep, looking over the socket activations, I found some of my traditional bastards were there and enabled. PCMCIA, iscsi-related things and so on.

Off with their heads! Though I should look a bit at what
Listen: @ISCSIADM_ABSTRACT_NAMESPACE (Stream)
means.