Using razorsedge-network (v3.6.0)
On every puppet run, I get the following:
Notice: /Stage[main]/Network/Service[network]/enable: enable changed 'false' to 'true'
Client is running CentOS 7.1, tried with agents 4.2.1 and 4.2.3.
Puppetmaster is PE 2015
It seems to rely on SysV scripts, but that has everything set correctly:
[root#srv08 ~]# service network status
Configured devices:
lo ens160
Currently active devices:
lo ens160
[root#srv08 ~]# echo $?
0
The manifest is called as:
class profiles::networking {
$allinterfaces = split($::interfaces, ',')
$pri_if = $allinterfaces[0]
::network::if::static {$pri_if:
ensure => hiera('network::if::static:ensure'),
ipaddress => hiera('network::if::static:ipaddress'),
netmask => hiera('network::if::static:netmask'),
gateway => hiera('network::if::static:gateway'),
peerdns => true,
dns1 => hiera('network::if::static:dns1'),
dns2 => hiera('network::if::static:dns2'),
domain => hiera('network::if::static:domain'),
}
}
Hiera in turn returns the single value
Because the network service doesn't remain up after you start it. So at each invocation the service is seen as "exited" and puppet is trying to start it again
Not the proper way I am sure, but I 'solved' it by adding this to my manifest:
file_line { 'Kill enabled':
ensure => 'absent',
line => ' enable => true,',
path => '/etc/puppetlabs/code/environments/production/modules/network/manifests/init.pp',
}
So basically remove the enable line. I had to do it in the manifest as the module is controlled by Puppetfile, this will ensure it stays absent.
Related
We have RedHat 7.2 Linux OS and use puppet to perform our tasks. I am using puppet to install some software, which has worked fine and now the final step is to create an OS level service. In earlier versions of RHEL, we used chkconfig but that has been replaced with systemctl. Of course, the recommended way of performing this task is using a service. Since this is a custom software, I have my own startup script that I usually copy over to /etc/init.d, run chkconfig and then startup the service. How do I perform these tasks via Puppet for RedHat 7.2 OS ? I only want to create the service (not start it up or anything). This way, when the server reboots, the service will startup the app.
EDIT :
#redstonemercury for RHEL 7 I would think the following would be required. But your suggestion definitely helps as I was thinking along the same lines.
https://serverfault.com/questions/814611/puppet-generated-systemd-unit-files
file { '/lib/systemd/system/myservice.service':
mode => '0644',
owner => 'root',
group => 'root',
content => template('modulename/myservice.systemd.erb'),
}~>
exec { 'myservice-systemd-reload':
command => 'systemctl daemon-reload',
path => [ '/usr/bin', '/bin', '/usr/sbin' ],
refreshonly => true,
}
In puppet, use a package resource to install the package (assuming it's in repos that you're declaring already), then use a file resource to declare the /etc/init.d file, and put require => Package[<package_resource_name>] as a parameter in the file declaration to ensure the custom file gets created after the package has installed (so doesn't potentially get overwritten by the package's /etc/init.d file). E.g.:
package { 'mypackage':
ensure => present,
}
file { '/etc/init.d/mypackage':
ensure => present,
content => template('mypackage/myinitd'),
require => Package['mypackage'],
}
This is if you want to use a template. For a file, instead of content use source: source => puppet://modules/mypackage/myinitd
In puppet, if you enable a service like this:
service { 'myservice':
ensure => running,
enable => true,
subscribe => File['/etc/init.d/myservice'];
}
file { '/etc/init.d/myservice':
source => "puppet:///modules/myservice/myservice",
ensure => file,
owner => root,
group => root,
mode => '0755',
}
Then puppet creates /etc/rc3.d/S??myservice and in my case, it always creates S65myservice. Where does the 65 come from? If puppet is choosing 65 consistently, it must be determined somewhere, but I don't know how it's making that decision. How do I make this service start later in the boot process? (for example S99myservice)
The order can be changed by adding a chkconfig clause to the startup script, such as:
#!/bin/sh
#
# chkconfig: 35 59 80
The above service should start at run level 3 and 5 using startup order 59, and shutdown order 80.
http://lpetr.org/blog/archives/startup-order-of-services-on-rhel-or-centos
I am currently hitting, for me, somewhat unintuitive behaviour in Puppet - most likely because I don't completely understand the Puppet ethos yet.
OK I have a simple puppetsimple.sh running in the puppet agent which is applying configurations from puppet master. This is all running smoothly and as expected.
Unintuitive (for me) However when I, as part of setting up master, create an error, and then run puppetsimple.sh in the agent, it will strike the error, notify me of it, and continue to apply all the other changes for that configuration.
This effectively leaves the agent in a broken state, because it pushes ahead even when there is an error.
Is there a setting somewhere to say "hey, if you strike an error, stop, revert to how you were, and carry on your merry way"?
Given the example below. I am intentionally enabling an invalid conf file (.confX) - I get notified of the error, but it continues to populate "index.html" with "Hello World 3".
define a2ensite {
exec { 'a2ensite':
path => [ '/bin', '/usr/bin', '/usr/sbin' ],
command => "a2ensite ${title}",
notify => Service['apache2'],
}
}
class mysite {
include apache
file { '/etc/apache2/sites-available/mysite.example.org.conf':
owner => root,
group => root,
mode => 0644,
source => "puppet:///files/mysite/mysite_apache.conf",
notify => Service['apache2'],
}
a2ensite { 'mysite.example.org.confX': }
file { ['/home/', '/home/www/', '/home/www/mysite.example.org']:
ensure => directory,
owner => root,
group => root,
mode => 0755,
}
file { '/home/www/mysite.example.org/index.html':
owner => www-data,
group => www-data,
mode => 755,
content => "Hello World 3",
}
}
If one reosurce failing means that another resource should not be modified, then that is a dependency relationship that you need to model via require. A failing dependency will cause puppet to skip those resources.
But, in general, puppet does not stop or rollback runs when it hits an error. If you need to rollback, it is on you to either revert to an older puppet configuration or use some other capability to revert the node.
I need to do a two step installation of a CentOS6 host with puppet (currently using puppet apply) and got stuck. Not even sure it's currently possible today.
Step 1, setup of base system e.g. setup hosts, ntp, mail and some driver stuff.
reboot required
Step 2, setup of a custom service.
Can this bee done a smooth way? I'm not very familiar with the puppet environment yet.
First off, I very much doubt that any setup steps on a CentOS machine strictly require a reboot. It is usually sufficient to restart the right set of services to make all settings take effect.
Anyway, basic approach to this type of problem could be to
Define a custom fact that determines whether a machine is ready to receive the final configuration steps (Step 2 in your question)
Protect the pertinent parts of your manifest with an if condition that uses that fact value.
You may want to create a file first, then delete it when you are done installing the base system (ntp in the below example)
for example
exec { '/tmp/reboot':
path => "/usr/bin:/bin:/sbin",
command => 'touch /tmp/reboot',
onlyif => 'test ! -f /tmp/rebooted',
}
service { 'ntp':
require => Exec['/tmp/reboot'],
...
}
exec { 'reboot':
command => "mv /tmp/reboot /tmp/rebooted; reboot",
path => "/usr/bin:/bin:/sbin",
onlyif => "test -f /tmp/reboot",
require => Service['ntp'],
creates => '/tmp/rebooted',
}
I have this puppet module (monit) in which I declare monit service to be enabled (a.k.a to be started when the machine booted)
class monit {
$configdir = "/etc/monit.d"
package {
"monit": ensure => installed;
}
service { "monit":
ensure => running,
enable => true,
require => Package["monit"],
provider => init;
}
file {
'/etc/monit.d':
ensure => directory;
'/etc/monit.conf':
content => template('monit/monitrc.erb'),
mode => 0600,
group => root,
require => File['/etc/monit.d'],
before => Service[monit],
notify => Service[monit],
}
}
I then included with include monit inside default node.
However, when I apply this configuration, puppet is not setting monit as a start up service (use chkconfig --list monit just display 'off' and 'off')
However, if I run puppet apply -e 'service { "monit": enable => true, } ' then monit is added to start up properly.
Am I doing any thing wrong here? (Puppet 2.7.6)
The full configuration can be view at https://github.com/phuongnd08/Giasu-puppet
The issue is probably the provider => init line, which is overriding the default provider for handling services. The init provider is a very simple provider that doesn't support the "enableable" feature, so it can't set a service to start on boot.
See http://docs.puppetlabs.com/references/2.7.6/type.html#service for its capabilities.
In your puppet apply example, you don't specify the provider so it picks the most appropriate for your system - in your case the "redhat" provider that uses chkconfig.
To fix this, remove the provider line from your service {} definition and it will again default to the most appropriate. You only need to specify a provider if it picks incorrectly and then it's best to specify it as a global default.