[Puppet Users] Augeus: Duplicate "sysctl" setting
Hello
I have a issue with duplicate Augeas settings and hoping to bounce the
issue off the community for some ideas.
I like to "pre-deploy" my servers regardless of what application they will
run and I typically have them sitting in
(/etc/puppet/manifest/classes/-linux-server) where they remain until
they are moved into an "application class" which then adds additional
modules
My "base" setup does not allow ip_forwarding:
[root@puppetdev-stc development]# grep net.ipv4.ip_forward
defaults/manifests/config.pp
sysctl { 'net.ipv4.ip_forward': value => '0', comment => 'this is a
comment' }
[root@puppetdev-stc development]#
However, I have an application that does require ip_forwarding .and
when I add the "application layer" I get a conflict:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Sysctl[net.ipv4.ip_forward] is already declared in
file /etc/puppet/modules/development/defaults/manifests/config.pp:4; cannot
redeclare at /etc/puppet/modules/development/wombat/manifests/config.pp:5
on node puppet-client..xxx.xx
How can I force puppet to simply execute the sysctl settings in order (I
use requires to control module order) ...meaning the last setting will
become the valid setting?
Thanks
Bruce
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAHvj1qaRySdJudgCHFVe2Y%3DGrJu0F-0B5QbnwWce8gM2Ve3iwA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet 3.3.0 Certificate Issue
Hi I've been struggling with Puppet 3.3.0 in what appears to be a bug so I'm hoping this post invites some assistance. My setup is 100% stock standard default. with the exception of a single dns entry (cname) of "puppet" which point to my master "adm6." I 've been running puppet 2.7.23 without any problems and decided to upgrade to the latest version. In order to test 3.3.0, I installed to new RHEL 6.4 boxes, added the puppetlabs-products repository and installed the latest puppet (3.3.0) Everything appears to work ...until I sign a test clients key immediately after singing a client key, the puppetmaster (adm6.xx.xx.xx) decided that I need to clean it's OWEN client key. [root@puppetmaster ~]# [root@puppetmaster ~]# [root@puppetmaster ~]# puppet ca list --all + adm6.xxx.xxx.xxx (SHA256) 9B:71:FB:A4:C2:06:F2:83:3E:40:55:CF:41:39:91:4F:F7:5C:45:8D:79:8E:D3:68:63:FD:B0:14:A6:AC:FE:59 bbushby-linux.xxx.xxx.xxx (SHA256) FF:11:53:FE:3C:85:75:33:2E:C0:8A:A1:00:BD:23:96:62:73:64:1F:8B:C8:5C:7D:65:7D:04:7F:8F:89:89:13 [root@puppetmaster ~]# [root@puppetmaster ~]# puppet cert list "bbushby-linux.xxx.xxx.xxx" (SHA256) FF:11:53:FE:3C:85:75:33:2E:C0:8A:A1:00:BD:23:96:62:73:64:1F:8B:C8:5C:7D:65:7D:04:7F:8F:89:89:13 [root@puppetmaster ~]# [root@puppetmaster ~]# puppet cert sign bbushby-linux.xxx.xxx.xxx Notice: Signed certificate request for bbushby-linux.xxx.xxx.xxx Notice: Removing file Puppet::SSL::CertificateRequest bbushby-linux.xxx.xxx.xxx at '/var/lib/puppet/ssl/ca/requests/bbushby-linux.xxx.xxx.xxx.pem' [root@puppetmaster ~]# [root@puppetmaster ~]# puppet cert list -all + "adm6.xxx.xxx.xxx" (SHA256) 9B:71:FB:A4:C2:06:F2:83:3E:40:55:CF:41:39:91:4F:F7:5C:45:8D:79:8E:D3:68:63:FD:B0:14:A6:AC:FE:59 (alt names: "DNS:xxx.xxx.xxx.xxx", "DNS:puppet", "DNS:puppet.xxx.xxx.xxx") + "bbushby-linux.xxx.xxx.xxx" (SHA256) B5:B7:2D:44:52:07:CA:DC:5C:99:3A:AC:24:29:85:A6:88:E9:0C:3B:54:30:71:4D:D0:FC:DC:3A:D5:E8:E2:52 [root@puppetmaster ~]# [root@puppetmaster ~]# puppet ca list --all Error: The certificate retrieved from the master does not match the agent's private key. Certificate fingerprint: B5:B7:2D:44:52:07:CA:DC:5C:99:3A:AC:24:29:85:A6:88:E9:0C:3B:54:30:71:4D:D0:FC:DC:3A:D5:E8:E2:52 To fix this, remove the certificate from both the master and the agent and then start a puppet run, which will automatically regenerate a certficate. On the master: puppet cert clean adm6.xxx.xxx.xxx On the agent: rm -f /var/lib/puppet/ssl/certs/adm6.xxx.xxx.xxx.pem puppet agent -t Error: Try 'puppet help ca list' for usage [root@puppetmaster ~]# I have tried so many different setups, fresh OS installs ... all of it and I am unable to sign a key and then run "pupppet ca list --all" Anybody else have this issue? Both my machines are RHEL 6.4 Both have ntp and correct UTC time Both have exact same versions of rpms (puppetmaster has an extra rpm "puppet-server") I then dropped my puppet and puppet-server versions down to 3.2.4 same problem (now I'm wondering if it is a bug...since it's happening across versions) These people appear to experience similar problems: http://www.mail-archive.com/puppet-bugs@googlegroups.com/msg46757.html http://projects.puppetlabs.com/issues/19680 http://comments.gmane.org/gmane.comp.sysutils.puppet.user/46356 http://thr3ads.net/puppet-users/2012/12/2238067-puppet-ca-list-all-ERROR http://thr3ads.net/puppet-users/2007/10/186450-puppetca-is-unable-to-sign-certificate Any ideas? Thanks Bruce -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] escaping the "@" symbol
Hi
I've been writing a little module to handle some grub settings on RHEL
6 and appear the have run into a silly little problem that I just
can't fix.
I've trying to append the string "crashkernel=128M@16M" to the kernel
line in my grub.conf. The following module works 100% if I leave out
the "@" symbol. Any ideas how I can escape the "@" ??
I know I can use "crashkernel=auto" but I would like to know how
to insert any string I chooseeven an "@".
Thanks
init.pp:
class grub {
include grub::grub
grub::set {
"timeout": value => 10;
}
grub::insert {
"/files/boot/grub/grub.conf/title/kernel/ro": value =>
'crashkerne128M@16M';
}
}
grub.pp:
class grub::grub {
define set ( $value ) {
$key = $name
$context = "/files/boot/grub/grub.conf"
augeas { "grub_conf/$key":
context => "$context",
onlyif => "get $key != '$value'",
changes => "set $key '$value'",
incl=> '/boot/grub/grub.conf',
lens=> 'grub.lns',
}
}
define insert ( $value ) {
$key = $name
$context = "/files/boot/grub/grub.conf"
augeas { "grub_conf/$key":
context => "$context",
changes => "insert '$value' after \'$key'",
incl=> '/boot/grub/grub.conf',
lens=> 'grub.lns',
}
}
file { "grub_conf":
name => $operatingsystem ? {
default => "/boot/grub/grub.conf",
},
}
}
--
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.
[Puppet Users] Re: Puppet module layout
Thanks Nigel, appreciate the heads up! I'm finding that puppet module are great when you want a module for "ssh" or a module for "sudoers" ...but I can't find an example where there is a module called "os" which contains "ssh.pp" , "prod_sudoers.pp" , "dev_sudoers.pp" , "userauth.pp", "iptables.pp" etc Then /etc/puppet/manifest/site.pp would include the module "os" and then /etc/puppet/modules/os/manifest/init.pp would include the various "pp" components for various hosts lists. Is this even possible? On Jun 20, 5:50 pm, Nigel Kersten wrote: > On Sat, Jun 18, 2011 at 1:29 AM, Bruce Bushby wrote: > > > > > > > > > > > Hello > > > I'm new to large scale puppet deployment and was hoping the list could > > offer some pointers on "module layout" > > > My initial "layout" was motivated by a need to "harden" our Linux > > systems. I grouped the various hardening configs into: > > > Kernel > > OS > > Network > > Shell > > Files > > Application > > > I'm hoping I can create the same module structure within puppet. > > In my experience, these module categories are too broad and it will make > maintenance difficult. > > You don't want to get too fine-grained with your modules, but if you keep > things this broad, you'll end up having lots of complicated relationships > like Class[os::foo] -> Class[files::foo] > > I made this mistake on a large deployment and regretted it. -- 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.
[Puppet Users] Re: Puppet module layout
Thanks again Ken!! I found it, /etc/puppet/puppet.conf requires: server = and then: puppetd --test works without having to specify the server name..doh I should have checked that this morning! At last I can start testing a module layout and augeas :)) I'll be sure to post the results in case others have a similar question. Bruce On Jun 20, 7:30 pm, Ken Barber wrote: > > Getting back to my ultra simple setup, I'm finding that I can't run > > "puppetd --test": > > [root@msukpuppet02 puppet]# puppetd --test > > err: Could not retrieve catalog from remote server: SSL_connect > > returned=1 errno=0 state=SSLv3 read server certificate B: certificate > > verify failed > > warning: Not using cache on failed catalog > > err: Could not retrieve catalog; skipping run > > [root@msukpuppet02 puppet]# > > > HOWEVER...this works perfectly: > > > [root@msukpuppet02 puppet]# puppetd --test -- > > server=msukpuppet01.mserv.local > > info: Caching catalog for msukpuppet02.mserv.local > > info: Applying configuration version '1308583986' > > notice: Finished catalog run in 0.02 seconds > > [root@msukpuppet02 puppet]# > > > My puppet config file sits in "/etc/sysconfig/puppet" > > Well - thats the RedHat specific environment file. Your configuration > file for puppet (at least the one we usually refer to) is usually > /etc/puppet/puppet.conf ;-). > > Anyway - the error you are getting is an SSL certificate security > issue. When you run: > > puppet agent --test > > Its looking for the hostname 'puppet' and trying to connect to it. Now > if the server side certificate doesn't have the alias 'puppet' in the > CN field its going to get rejected by the client. Think web server > certificates in your browser ... except instead of giving you a > warning you can push through ... we reject the connection. > > This is why using the alternate hostname works: > > puppet agent --test --server=msukpuppet01.mserv.local > > The hostname matches the CN field in the certificate this time :-). > > So you have a few choices here. You can update the > /etc/puppet/puppet.conf on your clients with the setting: > > [agent] > server=msukpuppet01.mserv.local > > That way it will just use that each time you do a 'puppet agent -t'. > > Or, you can regenerate your server certificate to have a number of > aliases: puppet, msukpuppet01.mserv.local, puppet.mserv.local etc. I > can explain this but ... what version of Puppet are you running btw? I > get the impression its an old one. I would recommend upgrading to 2.6 > before you proceed too far :-). If you already run 2.6 let me know > :-). > > ken. -- 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.
[Puppet Users] Re: Puppet module layout
Thanks Ken.I think I'm getting itslowly :)
> "...Start developing _something_ and see how your organisation works for
> you.."
RightI've started with the most basic setup to test CA keys by
simply implementing file perms for /etc/sudoers
I think my initial confusion was that I didn't realize that when
deploying "modules" ... you still need a "/etc/puppet/manifest/
site.pp" etc
> "How do you identify these hosts now?"
Some of the prod systems have "prod" in their hostnamebut there
are a lot that don't confirm, thanks for the examples for "grouping"
will give them a go.
Getting back to my ultra simple setup, I'm finding that I can't run
"puppetd --test":
[root@msukpuppet02 puppet]# puppetd --test
err: Could not retrieve catalog from remote server: SSL_connect
returned=1 errno=0 state=SSLv3 read server certificate B: certificate
verify failed
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
[root@msukpuppet02 puppet]#
HOWEVER...this works perfectly:
[root@msukpuppet02 puppet]# puppetd --test --
server=msukpuppet01.mserv.local
info: Caching catalog for msukpuppet02.mserv.local
info: Applying configuration version '1308583986'
notice: Finished catalog run in 0.02 seconds
[root@msukpuppet02 puppet]#
My puppet config file sits in "/etc/sysconfig/puppet"
[root@msukpuppet02 puppet]# cat /etc/sysconfig/puppet
# The puppetmaster server
PUPPET_SERVER=msukpuppet01.mserv.local
# If you wish to specify the port to connect to do so here
PUPPET_PORT=8140
# Where to log to. Specify syslog to send log messages to the system
log.
PUPPET_LOG=/var/log/puppet/puppet.log
# You may specify other parameters to the puppet client here
PUPPET_EXTRA_OPTS=--waitforcert=500
[root@msukpuppet02 puppet]#
I have checked both systems time is correct perfect and both system
resolve in the dns correctly for both A and PTR records.
I'm using RHEL 6.1 (puppet-0.25.5-1.el6.noarch)
Thanks again for the help
Bruce
On Jun 20, 1:12 pm, Ken Barber wrote:
> Augeas is a resource - I don't see how it fits in as a module. You may
> _use_ it in your modules if you like.
>
>
>
>
>
>
>
> On Mon, Jun 20, 2011 at 12:09 PM, Bruce Bushby wrote:
> > One last question:
>
> > Would the list suggest implementing "augeas" where possible? and would
> > "augeas" fit into the "module layout"
>
> > Thanks
> > Bruce
>
> > On Jun 18, 9:29 am, Bruce Bushby wrote:
> >> Hello
>
> >> I'm new to large scale puppet deployment and was hoping the list could
> >> offer some pointers on "module layout"
>
> >> My initial "layout" was motivated by a need to "harden" our Linux
> >> systems. I grouped the various hardening configs into:
>
> >> Kernel
> >> OS
> >> Network
> >> Shell
> >> Files
> >> Application
>
> >> I'm hoping I can create the same module structure within puppet.
>
> >> Using "sudo" as the first example, I want puppet to ensure "/usr/bin/
> >> sudo" has "4111" file perms and "root:root" ownership.
>
> >> Directory layout:
> >> I used this handy script from
> >> "ProfFalken"http://www.threedrunkensysadsonthe.net/2010/04/quick-creation-of-pupp...
>
> >> BUT...this is where things are getting a little grey. I currently
> >> have:
>
> >> [root@laptop manifests]# pwd
> >> /etc/puppet/manifests
> >> [root@laptop manifests]#
> >> [root@laptop manifests]# tree os
> >> os
> >> |-- files
> >> |-- lib
> >> | |-- facter
> >> | `-- puppet
> >> | |-- parser
> >> | |-- provider
> >> | `-- type
> >> |-- manifests
> >> | |-- init.pp
> >> | `-- sudo.pp
> >> `-- templates
>
> >> 9 directories, 2 files
> >> [root@laptop manifests]#
> >> [root@laptop manifests]# cat os/manifests/sudo.pp
> >> # /etc/puppet/manifests/classes/sudo.pp
>
> >> class sudo {
> >> file { "/etc/sudoers":
> >> owner => "root",
> >> group => "root",
> >> mode => 4111,
> >> }}
>
> >> [root@laptop manifests]#
>
> >> Am I on the correct track?
>
> >> I'm guessing I should break the classes down into:
> >> sudo::perms
> >> sudo::ownership
> >> sudo::file (have puppet serve the sudo template)
>
> >> th
[Puppet Users] Re: Puppet module layout
One last question:
Would the list suggest implementing "augeas" where possible? and would
"augeas" fit into the "module layout"
Thanks
Bruce
On Jun 18, 9:29 am, Bruce Bushby wrote:
> Hello
>
> I'm new to large scale puppet deployment and was hoping the list could
> offer some pointers on "module layout"
>
> My initial "layout" was motivated by a need to "harden" our Linux
> systems. I grouped the various hardening configs into:
>
> Kernel
> OS
> Network
> Shell
> Files
> Application
>
> I'm hoping I can create the same module structure within puppet.
>
> Using "sudo" as the first example, I want puppet to ensure "/usr/bin/
> sudo" has "4111" file perms and "root:root" ownership.
>
> Directory layout:
> I used this handy script from
> "ProfFalken"http://www.threedrunkensysadsonthe.net/2010/04/quick-creation-of-pupp...
>
> BUT...this is where things are getting a little grey. I currently
> have:
>
> [root@laptop manifests]# pwd
> /etc/puppet/manifests
> [root@laptop manifests]#
> [root@laptop manifests]# tree os
> os
> |-- files
> |-- lib
> | |-- facter
> | `-- puppet
> | |-- parser
> | |-- provider
> | `-- type
> |-- manifests
> | |-- init.pp
> | `-- sudo.pp
> `-- templates
>
> 9 directories, 2 files
> [root@laptop manifests]#
> [root@laptop manifests]# cat os/manifests/sudo.pp
> # /etc/puppet/manifests/classes/sudo.pp
>
> class sudo {
> file { "/etc/sudoers":
> owner => "root",
> group => "root",
> mode => 4111,
> }}
>
> [root@laptop manifests]#
>
> Am I on the correct track?
>
> I'm guessing I should break the classes down into:
> sudo::perms
> sudo::ownership
> sudo::file (have puppet serve the sudo template)
>
> then in "os/manifests/site.pp" . would I import sudo?
>
> and the second question: How would I create hosts groups? I would like
> to group my hosts in "dev", "uat", "staging" and "prod" etc?
>
> ThanksBruce
--
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.
[Puppet Users] Puppet module layout
Hello
I'm new to large scale puppet deployment and was hoping the list could
offer some pointers on "module layout"
My initial "layout" was motivated by a need to "harden" our Linux
systems. I grouped the various hardening configs into:
Kernel
OS
Network
Shell
Files
Application
I'm hoping I can create the same module structure within puppet.
Using "sudo" as the first example, I want puppet to ensure "/usr/bin/
sudo" has "4111" file perms and "root:root" ownership.
Directory layout:
I used this handy script from "ProfFalken"
http://www.threedrunkensysadsonthe.net/2010/04/quick-creation-of-puppet-modules/
BUT...this is where things are getting a little grey. I currently
have:
[root@laptop manifests]# pwd
/etc/puppet/manifests
[root@laptop manifests]#
[root@laptop manifests]# tree os
os
|-- files
|-- lib
| |-- facter
| `-- puppet
| |-- parser
| |-- provider
| `-- type
|-- manifests
| |-- init.pp
| `-- sudo.pp
`-- templates
9 directories, 2 files
[root@laptop manifests]#
[root@laptop manifests]# cat os/manifests/sudo.pp
# /etc/puppet/manifests/classes/sudo.pp
class sudo {
file { "/etc/sudoers":
owner => "root",
group => "root",
mode => 4111,
}
}
[root@laptop manifests]#
Am I on the correct track?
I'm guessing I should break the classes down into:
sudo::perms
sudo::ownership
sudo::file (have puppet serve the sudo template)
then in "os/manifests/site.pp" . would I import sudo?
and the second question: How would I create hosts groups? I would like
to group my hosts in "dev", "uat", "staging" and "prod" etc?
Thanks
Bruce
--
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.
