3 ms·

The post is missing a critical point: per the Debian policy, services should only bind to localhost upon installation. Further, Debain advertises itself as the

The post is missing a critical point: per the Debian policy, services should only bind to localhost upon installation. Further, Debain advertises itself as the "universal" operating system. This implies that the defaults are sane for many people, and if the administrator of the system installs a service, the administrator probably wants the service running. So, the only thing left to do, is change the bind address, and restart the daemon. Further, per the Debian policy, when a daemon package is installed, it's configured to start automatically on boot for run level 2. The policy is written in such a way, that Debian system administrators know _exactly_ the state of their system, after installing packages. This post is written from the Red Hat way of doing things, in that you install the daemon, do configuration, then start the daemon. However, there is no consistency with Red Hat systems. Some package maintainers will have the daemon configured to start on boot, some not. So, after configuring and starting, you also need to use chkconfig(8) to check if the daemon you just installed is ready to start on boot. More often than not, it's "off", which means it won't start. Painful thing to discover when the server restarts, and customers are calling in that their website isn't loading, or they can't access their NFS share. IMO, I have come to find the Debian way of installing services more sane, than the Red Hat way. I want my system working, and I want to know the state my system is in when making major changes. Red Hat is just too inconsistent here, and it doesn't help that they have the /etc/rc.d/init.d/ historical baggage.

fsniper 12y ago
I really like the way it's now. But in some edge cases you need the service stopped in the first place. For example RabbitMQ initiates a database which denies cluster configurations if intact. So in Debian way if you are using some configuration management tool to start a RabbitMQ cluster you have install/stop/resetdb/restart cycle which is prone to failing. So some edge cases need this kind of 2cents.
- atoponce 12y ago
  This is why upstream developers should use /etc/default/ to place daemon configuration files into. Then the configuration file could have "START=no", and even though the policy would start the daemon by default, the upstream developer could prevent this from happening.
  - fsniper 12y ago
    But if it's not covered yet rc-d policy would help.
  - regularfry 12y ago
    > This is why upstream developers should Eh, not so much. Any system which tries to convince upstream to change their ways is going to be fraught, so we're always going to need another way to force the behaviour we want in spite of the upstream.

fsniper 12y ago

I really like the way it's now. But in some edge cases you need the service stopped in the first place. For example RabbitMQ initiates a database which denies cluster configurations if intact. So in Debian way if you are using some configuration management tool to start a RabbitMQ cluster you have install/stop/resetdb/restart cycle which is prone to failing. So some edge cases need this kind of 2cents.

atoponce 12y ago
This is why upstream developers should use /etc/default/ to place daemon configuration files into. Then the configuration file could have "START=no", and even though the policy would start the daemon by default, the upstream developer could prevent this from happening.
- fsniper 12y ago
  But if it's not covered yet rc-d policy would help.
- regularfry 12y ago
  > This is why upstream developers should Eh, not so much. Any system which tries to convince upstream to change their ways is going to be fraught, so we're always going to need another way to force the behaviour we want in spite of the upstream.