Good morning
This is a repost of a query to bugs, which i'm advised is better
suited to here. Also i just submitted this, but it looks like google
had logged me out...
Situation: I'm currently evaluating puppet as an alternative to
cfengine, surveying the doco indicates it is highly suitable (i've
been using cfengine for ~4 years, i'm ready and willing for a
change :) ), but i'm having issues with getting some facts to happen.
What i need to be able to do, or rather what some of the people who
manage applications on my servers need to be able to do is this:
Touch a file and thus disable a configuration change occuring. One
very common example is /etc/resolv.conf on DNS servers. For some
reason it is impossible for the App guys to notify the OS guys to say
"We need to have a custom job on this host, please disable it being
configured" instead what we get usually is "I changed this file like 4
or 5 times now, any chance cfengine is creaming it?" (to which we
respond "Does it say "don't change this file, because cfengine will
edit it" near the top?"). Anyway, (slightly exaggerated)
organizational issues aside here is where i stand:
My server "puppetbeta" (a VMware Fusion 2 VM) has the following files/
directory structure in its /etc/puppet directory:
[r...@puppetbeta puppet]# find
.
./puppet.conf
./fileserver.conf
./modules
./modules/custom
./modules/custom/plugins
./modules/custom/plugins/facter
./modules/custom/plugins/facter/deploysudoers.rb
./modules/custom/plugins/puppet
./modules/custom/plugins/puppet/type
./modules/custom/plugins/puppet/provider
./modules/sudoers-linux
./modules/sudoers-linux/depends
./modules/sudoers-linux/files
./modules/sudoers-linux/templates
./modules/sudoers-linux/manifests
./modules/sudoers-linux/manifests/init.pp
./manifests
./manifests/site.pp
./manifests/nodes.pp
./manifests/classes
./manifests/classes/solaris.classes
./manifests/classes/freebsd.classes
./manifests/classes/linux.classes
./manifests/classes/shared.classes
The config file contains:
[r...@puppetbeta puppet]# grep -v "^ #" puppet.conf | grep -v ^$
[main]
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
pulginsync = true
factpath = $vardir/lib/facter
[puppetmasterd]
modulepath = /etc/puppet/modules
[puppetd]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
[shared]
path /var/lib/puppet/files/shared
allow 192.168.154.235
[linux]
path /var/lib/puppet/files/linux
allow 192.168.154.235
[solaris]
path /var/lib/puppet/files/solaris
[freebsd]
path /var/lib/puppet/files/freebsd
[modules]
allow 192.168.154.235
I got the [modules] without a path from some page in the doco, but i
don't have that link handy (sorry). Eitherway, that doesn't matter,
because my module get's run.
my manifest/site.pp contains:
import "classes/*"
node default
{
case $operatingsystem
{
RedHat: { include linux-default }
default: { include shared-default }
}
}
The only class actually defined is linux-default:
[r...@puppetbeta classes]# ls
freebsd.classes linux.classes shared.classes solaris.classes
[r...@puppetbeta classes]# cat *classes
import "sudoers-linux"
class linux-default
{
include sudoers-linux
}
and it references sudoers-linux (which i gather really isn't the best
way of doing things, with all sudoers being in the same file and a
case statement separating them being better).
the init.pp from the module sudoers-linux looks like:
class sudoers-linux
{
# don't need package because i don't want it to install anything
# package { sudo: ensure => latest }
# don't need service because there is no process associated with sudo
# service { sudo: ensure => ??? }
if $deploysudoers
{
file
{ "/etc/sudoers":
owner => root,
group => root,
mode => 440,
source => "puppet:///shared/etc/sudoers",
}
}
else
{
file
{ "/etc/sudoers":
owner => root,
group => root,
mode => 440,
}
}
}
Now this bit of code get's "executed" but the if always evaluates as
true, so a copy is always transmitted. Which only leaves my fact(er):
[r...@puppetbeta puppet]# cat ./modules/custom/plugins/facter/
deploysudoers.rb
require 'facter'
deploysudoers = FileTest.exists?("/var/lib/puppet/classes/
DoNotDeploySudoers")
Facter.add("deploysudoers") do
setcode do
!deploysudoers
end
end
On the client "puppetslave" (another VMware Fusion 2 VM) this fact
turns up:
[r...@puppetslave puppet]# rm /var/lib/puppet/lib/facter/
deploysudoers.rb
[r...@puppetslave puppet]# puppetd -vt
[r...@puppetslave puppet]# puppetd -vt
info: Loading fact deploysudoers
info: Retrieving plugins
notice: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seluser:
seluser changed 'user_u' to 'system_u'
info: Loading fact deploysudoers
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
0a1,38
> # sudoers file.
<...snip...>
notice: //Node[default]/linux-default/sudoers-linux/File[/etc/sudoers]/
checksum: checksum changed '{md5}6004828206de06294c3994d76202d667' to
'{md5}5a9cd29a15f3c685b81d1972b2e8e555'
info: Filebucket[/var/lib/puppet/clientbucket]: Adding /etc/sudoers
(5a9cd29a15f3c685b81d1972b2e8e555)
notice: //Node[default]/linux-default/sudoers-linux/File[/etc/
sudoers]: Filebucketed to with sum 5a9cd29a15f3c685b81d1972b2e8e555
notice: //Node[default]/linux-default/sudoers-linux/File[/etc/sudoers]/
source: replacing from source puppet:///shared/etc/sudoers with
contents {md5}6004828206de06294c3994d76202d667
notice: //Node[default]/linux-default/sudoers-linux/File[/etc/sudoers]/
seluser: seluser changed 'user_u' to 'system_u'
notice: Finished catalog run in 0.42 seconds
if i do a -d in there and grep for my facter (after sudo has already
been modified)i see:
[r...@puppetslave puppet]# puppetd -vtd | grep deploy
info: Loading fact deploysudoers
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seluser:
Executing '/usr/sbin/matchpathcon /var/lib/puppet/lib/facter/
deploysudoers.rb'
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seluser:
Found seluser default 'system_u' for /var/lib/puppet/lib/facter/
deploysudoers.rb
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/selrole:
Executing '/usr/sbin/matchpathcon /var/lib/puppet/lib/facter/
deploysudoers.rb'
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/selrole:
Found selrole default 'object_r' for /var/lib/puppet/lib/facter/
deploysudoers.rb
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seltype:
Executing '/usr/sbin/matchpathcon /var/lib/puppet/lib/facter/
deploysudoers.rb'
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seltype:
Found seltype default 'var_lib_t' for /var/lib/puppet/lib/facter/
deploysudoers.rb
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/selrange:
Executing '/usr/sbin/matchpathcon /var/lib/puppet/lib/facter/
deploysudoers.rb'
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/selrange:
Found selrange default '' for /var/lib/puppet/lib/facter/
deploysudoers.rb
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/checksum:
Initializing checksum hash
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]: Creating
checksum {md5}2c636b9e03e137ca7ade28ebda0a4537
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seluser:
Executing '/usr/bin/stat -c %C /var/lib/puppet/lib/facter/
deploysudoers.rb'
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/selrole:
Executing '/usr/bin/stat -c %C /var/lib/puppet/lib/facter/
deploysudoers.rb'
debug: /File[/var/lib/puppet/lib/facter/deploysudoers.rb]/seltype:
Executing '/usr/bin/stat -c %C /var/lib/puppet/lib/facter/
deploysudoers.rb'
IF i export the FACTERLIB i can verify that facter would evaluate the
fact as being correct
[r...@puppetslave puppet]# export FACTERLIB=/var/lib/puppet/lib/facter
[r...@puppetslave puppet]# facter | grep deploy
deploysudoers => false
[r...@puppetslave puppet]# ls /var/lib/puppet/classes/
DoNotDeploySudoers
/var/lib/puppet/classes/DoNotDeploySudoers
but sudoers is still modified...
Firstly, most importantly, how do i fix this? how do i make sure my
fact is used?
Secondly, how can I find out what facter actually tells puppet are
facts?
Any information would be appreciated...
cheers
chakkerz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
