3 ms·
You keep saying things like "so many non-standard ways that a package can decide to not start" and "whatever the packager thought up". Can you provide examples
by sciurus 13y ago
You keep saying things like "so many non-standard ways that a package can decide to not start" and "whatever the packager thought up". Can you provide examples of what you mean?
In your blog post you only mention one way of controlling startup- via an environment variable sourced from a file in /etc/defaults. This is the standardized, documented place in Debian for controlling the behavior of init scripts. Offhand, I can't think of any other ways I've seen packager maintainers controlling startup. I'd really need to see more evidence before agreeing that things are "ridiculous", "nuts", or "wrong".
http://www.debian.org/doc/manuals/maint-guide/dother.en.html#initd http://www.debian.org/doc/manuals/maint-guide/dother.en.html...
- jsight 13y agoThe file is a standard, but the contents are not. For the most part, that makes sense, but it would be nice if there were a few standards there. Eg, DISABLE_ALL_SERVICES=true|false. :) More examples here: http://serverfault.com/questions/526075/fixing-services-that-have-been-disabled-in-etc-default-with-puppet http://serverfault.com/questions/526075/fixing-services-that... As it is, figuring out exactly how to do this has to be done for each service. It's tedious, IMO, though I understand the history of why this is the case.
- sciurus 13y agoSure, I can see the value in making service configuration more standard. E.G. after getting over the learning curve I've found working with systemd more pleasant than SysVinit. I disagree that this is currently really more of a problem on Debian/Ubuntu that it is on Red Hat. E.G. If I want to manage BIND via puppet on Red Hat, I'm going to have to care about /etc/sysconfig/named.