Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using puppet to (theoretically) get npcd to start upon installation, however on Ubuntu, that service comes installed with the default setting in /etc/default/npcd of RUN="no":

 $ cat /etc/default/npcd 
 # Default settings for the NPCD init script.

 # Should NPCD be started? ("yes" to enable)

 # Additional options that are passed to the daemon.
 DAEMON_OPTS="-d -f /etc/pnp4nagios/npcd.cfg"

I would think that this block of puppet config would take care of things:

    service { "npcd":
       enable   => true,
       ensure   => "running",
       require  => Package["pnp4nagios"],

But alas, it doesn't, and short of actually rewriting the file in /etc/default, I'm not sure what to do. Is there a straightforward way to enable the service that I'm not seeing?

For the record, I'm using Ubuntu 12.04.2 and puppet version 3.1.0.

share|improve this question
Why not just rewrite /etc/default/npcd with a file resource? The file depends on the package, and the service depends on the file. I'm always leery of editing files via sed or augeas if I can avoid it. – larsks Jul 26 '13 at 2:30

Updating that file and then restarting the service is the only way. You can push a new file and then make the service Require that; that way when the contents are updated the service will properly start.

If you don't want to replace the file entirely you can use the Puppet augeas tool to just modify the single line in the defaults file.

There are a few services in Debian and its derivatives that don't autostart after the package is installed unless it's enabled in /etc/default. Kind of annoying.

Edit: FYI the init script is actually reading the values from that file (just sourcing it usually).

share|improve this answer
Interesting. I have a mind to file a bug. If you set "enable" to "true", it only makes sense that it does, in fact, enable the script (in addition to any various symlinks to run levels). – Matt Simmons Jul 25 '13 at 2:37
I think there's no easy way for Puppet to know whether or not a service would need the "defaults" file updated so they've not baked that in; might be easier to file a bug with the distribution. I doubt you'll get any traction though :-) – Luke Jul 25 '13 at 2:42
use a defined type called something like "defaulted_service" which has a service resource, and also an exec resource that updates the file in place using sed if needed, or a file resource that uses augeas, up to you. – Sirex Jul 25 '13 at 3:22
@MattSimmons The people making these packages ought to be using the symlinks and update-rc.d for enabling/disabling the service, not /etc/default - it's not a standard way to manage services, so it's out of puppet's control. – Shane Madden Jul 25 '13 at 6:13

For the hell of it I checked a few of the standard daemons on my 12.04 machines. You have to manage the file, no way around it at this point in time.


# snmpd control (yes means start daemon).


# 0: start collectd on boot, 1: do not start collectd on boot
# default: 0


# Start puppet on boot?


#   should mdadm start the MD monitoring daemon during boot?


# Set ENABLED to 1 if you want the init script to start haproxy.
share|improve this answer

I think one of feasible ways to do it is using augeas tool with puppet, e.g.

augeas { "npcd_default":
  changes => [
    "set /files/etc/default/npcd/Run yes",

refer to the manual for details

share|improve this answer

I use sed to modify the file. Augeas seems like overkill.

sed -i /etc/default/puppet -e 's/START=no/START=yes/'

Idea taken from here:

So, in your case

sed -i /etc/default/npcd -e 's/RUN="no"/RUN="yes"/'
share|improve this answer
if you think augeas is an overkill, isn't puppet an overkill too? :) Your solution is also ok, but you assume that you have the file and needed line it, so what if it's not there? it will just fail without telling you anything. I believe augeas is so much robust, convenient and purposefull that it worth installing if you are using puppet – DukeLion Aug 4 '13 at 8:31
My example was from bootstrapping puppet via cloud-init. I looked at augeas and immediately decided to avoid it if at all possible. So far I haven't needed augeas nor have I needed to bootstrap another service besides puppet to start=yes. – dmourati Aug 4 '13 at 18:01
I'm really curious about your point of view. I can see your point, but ain't augeas and puppet use the same ideology of providing abstract top-level interface for unified management? So if you don't like augeas how come you like puppet? Why not ansible then? – DukeLion Aug 6 '13 at 6:58
I think the better approach is editing stub or fragment configuration files such as in apache conf.d, sysctl.d, sudoers.d, etc. Trying to piece your way through other config files just doest appeal to me. In the simplest case, where fragmented config files with .d directories don't exist, use sed/perl/whatever. Thus there is no need for augeas. – dmourati Aug 6 '13 at 7:06

Doing this with the augeas type in Puppet is one way (as suggested by @DukeLion).

Another way is to use the augeasproviders module, with the shellvar provider:

shellvar { 'npcd_default':
  ensure   => present,
  target   => '/etc/default/npcd',
  variable => 'RUN',
  value    => 'yes',
  comment  => 'We want npcd to run',

This is better because Augeas will be used cleanly by the Ruby provider. It will also manage quoting and comment automatically.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.