5 ms·

I hate to say it, but this is just a rant by a RedHat/CentOS admin who has started using Debian/Ubuntu for the first time and just doesn't know why things are d

by jmomo 13y ago

I hate to say it, but this is just a rant by a RedHat/CentOS admin who has started using Debian/Ubuntu for the first time and just doesn't know why things are done differently there.

jrochkind1 13y ago
do you really hate to say it?
MPSimmons 13y ago
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.
lmickh 13y ago
Maybe it would be a good idea to provide the reason why things are done differently. He seems happy to accept the Debian standards despite disagreeing with them. Help the guy (and the rest of us who has asked the same question) out.

by jmomo 13y ago

I hate to say it, but this is just a rant by a RedHat/CentOS admin who has started using Debian/Ubuntu for the first time and just doesn't know why things are done differently there.

jrochkind1 13y ago

do you really hate to say it?

MPSimmons 13y ago

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.

lmickh 13y ago

Maybe it would be a good idea to provide the reason why things are done differently. He seems happy to accept the Debian standards despite disagreeing with them. Help the guy (and the rest of us who has asked the same question) out.