3 ms·

Author here. You're 99% correct. I'm historically an RHEL-based admin, who has started using Debian/Ubuntu for the first time (relatively, for about a year), bu

Author here. You're 99% correct. I'm historically an RHEL-based admin, who has started using Debian/Ubuntu for the first time (relatively, for about a year), but I totally get why these things are done. What I deeply disagree with is how they're done. Why are there so many non-standard ways that a package can decide to not start? I really appreciate that the package maintainer is trying to do the right thing, but it's ridiculous that there isn't a way to do it - there's the Debian default and then there's whatever the packager thought up. That's nuts, and needing to manage the same resource twice in puppet isn't a tragedy or big deal, but it's a symptom that something is wrong.

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 ago
  The 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 ago
    Sure, 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.

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 ago
The 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 ago
  Sure, 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.