13

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)
 RUN="no"

 # 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.

Keith
  • 4,627
  • 14
  • 25
Matt Simmons
  • 20,218
  • 10
  • 67
  • 114
  • 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 02:30

5 Answers5

12

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).

Luke
  • 628
  • 1
  • 7
  • 14
  • 1
    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 02: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 02: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 03: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 06:13
8

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

# snmpd control (yes means start daemon).
SNMPDRUN=yes

collectd

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

puppet

# Start puppet on boot?
START=yes

mdadm

# START_DAEMON:
#   should mdadm start the MD monitoring daemon during boot?
START_DAEMON=true

haproxy

# Set ENABLED to 1 if you want the init script to start haproxy.
ENABLED=1
kashani
  • 3,922
  • 18
  • 18
6

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

raphink
  • 11,337
  • 6
  • 36
  • 47
DukeLion
  • 3,239
  • 1
  • 17
  • 19
0

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:

http://www.codelord.net/2010/12/19/using-puppet-to-automatically-configure-new-ec2-instances/

So, in your case

sed -i /etc/default/npcd -e 's/RUN="no"/RUN="yes"/'
dmourati
  • 24,720
  • 2
  • 40
  • 69
  • 1
    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 04 '13 at 08: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 04 '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 06 '13 at 06: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 06 '13 at 07:06
0

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.

raphink
  • 11,337
  • 6
  • 36
  • 47