[Puppet Users] Puppet class not working after use augeas-0.10.0-3
Hi ,
This my puppet class, working nicely. But after i upgarde augeas into
augeas-0.10.0-3
class modprobe {
modprobe::disableModule{Disable cramfs, 2.2.2.5: module =
cramfs }
modprobe::disableModule{Disable freevxfs, 2.2.2.5: module =
freevxfs }
modprobe::disableModule{Disable jffs2, 2.2.2.5:module =
jffs2 }
modprobe::disableModule{Disable hfs, 2.2.2.5: module =
hfs }
modprobe::disableModule{Disable hfsplus, 2.2.2.5: module =
hfsplus }
modprobe::disableModule{Disable squashfs, 2.2.2.5:
module = squashfs }
modprobe::disableModule{Disable udf, 2.2.2.5: module =
udf }
modprobe::disableModule{Disable usb-storage, 2.2.2.1:module
= usb-storage }
modprobe::disableModule{Disable ipv6, 2.5.3.1.1:module =
ipv6 }
modprobe::turnOffModule{Disable bluetooth, 3.3.14.3: module =
bluetooth }
modprobe::turnOffModule{Disable net-pf-31, 3.3.14.3: module =
net-pf-31 }
}
modprobe::disableModule{Disable DCCP, 2.5.7.1: module =
dccp }
modprobe::disableModule{Disable SCTP, 2.5.7.2: module =
sctp }
modprobe::disableModule{Disable RDS, 2.5.7.3: module = rds }
modprobe::disableModule{Disable TIPC, 2.5.7.4: module =
tipc }
define modprobe::disableModule ( $module = '' )
{
augeas::basic-change {$name:
file= /etc/modprobe.conf,
lens= modprobe.lns,
changes = set install[0] '$module /bin/true',
onlyif = match *[/files/etc/modprobe.conf[install =
'$module /bin/true']] size == 0,
}
}
define modprobe::turnOffModule ( $module ='' )
{
augeas::basic-change { $name :
file= /etc/modprobe.conf,
lens= modprobe.lns,
changes = [
set alias[last()+1] $module,
set alias[last()]/modulename off,
],
onlyif = match *[/files/etc/modprobe.conf[alias =
'$module']] size == 0,
}
}
The error message:
info: Retrieving plugin
info: Loading facts in unlabeled_device_files
info: Loading facts in unlabeled_device_files
info: Caching catalog for id41-nd016.asyx.com
info: Applying configuration version '1335867684'
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
squashfs, 2.2.2.5]/Augeas::Basic-change[Disable squashfs,
2.2.2.5]/Augeas[Disable squashfs, 2.2.2.5]/returns: change from
need_to_run to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
SCTP, 2.5.7.2]/Augeas::Basic-change[Disable SCTP,
2.5.7.2]/Augeas[Disable SCTP, 2.5.7.2]/returns: change from need_to_run
to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
TIPC, 2.5.7.4]/Augeas::Basic-change[Disable TIPC,
2.5.7.4]/Augeas[Disable TIPC, 2.5.7.4]/returns: change from need_to_run
to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
cramfs, 2.2.2.5]/Augeas::Basic-change[Disable cramfs,
2.2.2.5]/Augeas[Disable cramfs, 2.2.2.5]/returns: change from
need_to_run to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
udf, 2.2.2.5]/Augeas::Basic-change[Disable udf, 2.2.2.5]/Augeas[Disable
udf, 2.2.2.5]/returns: change from need_to_run to 0 failed: Save failed
with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
DCCP, 2.5.7.1]/Augeas::Basic-change[Disable DCCP,
2.5.7.1]/Augeas[Disable DCCP, 2.5.7.1]/returns: change from need_to_run
to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
jffs2, 2.2.2.5]/Augeas::Basic-change[Disable jffs2,
2.2.2.5]/Augeas[Disable jffs2, 2.2.2.5]/returns: change from need_to_run
to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
RDS, 2.5.7.3]/Augeas::Basic-change[Disable RDS, 2.5.7.3]/Augeas[Disable
RDS, 2.5.7.3]/returns: change from need_to_run to 0 failed: Save failed
with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
hfsplus, 2.2.2.5]/Augeas::Basic-change[Disable hfsplus,
2.2.2.5]/Augeas[Disable hfsplus, 2.2.2.5]/returns: change from
need_to_run to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
freevxfs, 2.2.2.5]/Augeas::Basic-change[Disable freevxfs,
2.2.2.5]/Augeas[Disable freevxfs, 2.2.2.5]/returns: change from
need_to_run to 0 failed: Save failed with return code false
err: /Stage[main]/Modprobe/Modprobe::Modprobe::Disablemodule[Disable
hfs, 2.2.2.5]/Augeas::Basic-change[Disable hfs, 2.2.2.5]/Augeas[Disable
hfs, 2.2.2.5]/returns: change from need_to_run to 0 failed: Save failed
with
Re: [Puppet Users] Require = Package from a different server
I have to install a client/server app. The server end is easily set
up but I need a puppet module that ensures a package is installed on a
managed node only if the server package has already been installed on
a different server.
Is there a way to do this?
As others have said, it's tricky - Could you maybe try something funky
with exported resources here? (this is untested and pretty hacky :P )
# server
define clientenabled () {
@@package { client:
ensure = latest,
}
}
package { server:
ensure = latest,
}
clientenabled { foo:
require = Package['server']
}
# client
Package | title == client |
Depends on the exact behavior you want, this may be completely the wrong
approach - this will just mean that the client will not get installed
until Puppet has been run and installed the server package first - it
wont actually do the orchestration for you though
--
Craig Dunn | http://www.craigdunn.org
Yahoo/Skype: craigrdunn | Twitter: @crayfishX
--
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: Conditional directory creation
Anybody got any idea on this?
I am really stuck with this one.
On Apr 30, 4:51 pm, Peter Horvath peter.horvat...@googlemail.com
wrote:
Hi,
I have a modul which created the vhosts and based on the variables defined
there i am creating nagios defacement host cfg.
My problem is that I can't conditionally decide if the file should be
created, based on the variable which will get content in the node config:
When the condition get evaluated $monstring still empty since it gets its
content in the node config later, so no file will be created.
If i remove the condition there will be hundreds of nagios cfg which should
not be created.
Can you give me some idea how can i make this work, so blog file gets
created and blog1 not.
*This is the important part of my resource type*
*
*
define vhost ($servername = ${hostname}.${domain}, $serveralias = [
www.${hostname}.${domain} ], $inorout = 1, $owner = root, $group =
root, $enabled = link, $rewrite = , $ssl = false, $cacert = ,
$certchain = , $certfile = , $keyfile = , $pringo = false,
$pringodir = pringo4, $staging = false, $mode = '755', $monstring = '' )
if ! $monstring == {
file{/root/${servername}.cfg:
ensure = present,
content =
template(${module_name}/defacementmon.erb),
}
}
*node config:*
import apache2/vhost.pp
vhost{'blog.domain.com':
servername = 'blog.domain.com',
serveralias = [ 'prod-blog.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
monstring = 'string',
inorout = '0';
}
vhost{'blog1.domain.com':
servername = 'blog1.domain.com',
serveralias = [ 'prod-blog1.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
inorout = '0';
}
I hope it is understandable, my english is not the best.
Peter
--
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.
Re: [Puppet Users] Puppet class not working after use augeas-0.10.0-3
On 01/05/12 13:00, heriyanto wrote:
Hi ,
This my puppet class, working nicely. But after i upgarde augeas into
augeas-0.10.0-3
There was an incompatible change to the modprobe lens in Augeas 0.10.0:
Modprobe: Parse commands in install/remove stanzas (this introduces a
backwards incompatibility)
from http://augeas.net/news.html
define modprobe::disableModule ( $module = '' )
{
augeas::basic-change {$name:
file= /etc/modprobe.conf,
lens= modprobe.lns,
changes = set install[0] '$module /bin/true',
onlyif = match *[/files/etc/modprobe.conf[install =
'$module /bin/true']] size == 0,
}
}
The value of the node is no longer a concatenation of the module name
and the command, the two were split up. Try this:
define modprobe::disableModule ( $module = '' )
{
augeas::basic-change {$name:
file= /etc/modprobe.conf,
lens= modprobe.lns,
changes = [
set install[.='$module'] '$module',
set install[.='$module']/command /bin/true,
],
}
}
This creates two nodes instead of just the one, e.g.
/files/etc/modprobe.conf/install = foo
/files/etc/modprobe.conf/install/command = /bin/true
I've also changed the install[0] so it doesn't always overwrite the
first install line and instead creates an install line per module.
Cheers,
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113
--
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 eating solaris 10 crontab for lunch
I don't think it's issue #5752, I opened that issue and provided a patch to resolve it. When I build new versions of Puppet for my Solaris hosts I apply that patch each time via my build script and I'm still having some hosts where the crontab gets eaten and it always seems to correspond with 'prtdiag' issues or timeouts. Facter has a timeout built in for prtdiag and then does a kill routine if it needs to clean up. I wonder if it's being overly agressive and accidentally killing some or all of the Puppet run in turn causing this issue? -Kent On Mar 13, 5:31 pm, Greg greg.b...@gmail.com wrote: Have seen similar. Quite often when prtdiag fails to complete, I've found that restarting svc:/system/picl:default returns everything back to normal... Hopefully all your root cron jobs are in Puppet and will be rebuilt on the next run... Greg On Mar 14, 9:26 am, John Warburton jwarbur...@gmail.com wrote: On 14 March 2012 09:16, Romeo Theriault romeo.theria...@maine.edu wrote: Here are the logs the solaris 10 box returns after it's crontab gets destroyed: ERR Puppet Could not prefetch cron provider 'crontab': Could not read crontab for root: No child processes NOTICE /Stage[main]/Puppet/Cron[puppet]/ensure created NOTICE Puppet Finished catalog run in 2.52 seconds After this the only thing that exists in the crontab is the entry we have puppet adding. I found this bug: http://projects.puppetlabs.com/issues/1672 which says there was a fix and it was merged but we're still seeing this issue... puppet agent v. 2.7.9 facter v. 1.6.5 It could be this bug -https://projects.puppetlabs.com/issues/5752 That andhttps://projects.puppetlabs.com/issues/9854arekeeping me from pushing migrating to 2.7 up my priority list Indeed, there are 5 issues marked Urgent in the 2.7.x bucket John -- 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 way of handling rdist and triggers
On Apr 30, 10:52 am, Philip Brown p...@bolthole.com wrote: I've already said that converting modified files to packages, was not an option. No, you said that getting your admins' to deploy config changes by packaging them up was not an option. My suggestion avoids imposing any need for them to do that. It may be that you also don't want to package up the rest, but that's a different story altogether. You can surely automate that process if you wish to do so -- nightly, say, on the same schedule that you now rdist -- and there are advantages to that beyond integrating Puppet into your infrastructure. In any case, the degree to which Puppet can help you is modulated by the degree to which you are willing to adopt techniques that work well with Puppet. John -- 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 way of handling rdist and triggers
On Apr 28, 9:53 am, Philip Brown p...@bolthole.com wrote:
On Saturday, April 28, 2012 2:11:23 AM UTC-7, Luke Bigum wrote:
Yes, Puppet is perfect for your file-copy-and-hook scenario. In Puppet
speak it's notify and subscribe between resources, here's a very
quick example that will restart Some Daemon if /etc/resolv.conf
changes:
node 'somehost' {
class { 'resolv': }
}
class resolv {
$resolv_conf = '/etc/resolv.conf'
$service_name = 'some-daemon'
file { $resolv_conf:
source = puppet:///modules/${module_name}/${resolv_conf},
notify = Service[$service_name],
}
But that requires the files be hosted on the puppet master.
What if the conf files are still rdisted out under /rdist/base instead?
What does that look like?
It looks exactly like what you are now doing (i.e. no Puppet). How do
you suppose Puppet is going to recognize that it needs to notify a
service if it's not managing the file? Really, think about it: how
might Puppet know a file changed if it's not the one changing it?
Could all that extra work really be an improvement over rdist
triggers? (Hint: not likely.)
I think it would be useful to you to consider what you hope to achieve
by incorporating Puppet into your infrastructure. Your rdist system
must be working fairly well because you seem resistant to changing
it. What, then, do you think Puppet can bring to the table?
John
--
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.
Re: [Puppet Users] Re: Conditional directory creation
Hi,
can't see anything wrong off the top of my head except you use an import
statement instead of an include.
http://docs.puppetlabs.com/guides/language_guide.html#importing-manifests
Have you tried testing for a string like 'false'? Just to see if something odd
not going on.
$mode = '755', $monstring = 'false' )
if ! $monstring == false {
file{/root/${servername}.cfg:
Not at a computer so can't test the code till tomorrow (that's about 8 hours
away).
Sorry,
Den
On 01/05/2012, at 22:24, Peter Horvath peter.horvat...@gmail.com wrote:
Anybody got any idea on this?
I am really stuck with this one.
On Apr 30, 4:51 pm, Peter Horvath peter.horvat...@googlemail.com
wrote:
Hi,
I have a modul which created the vhosts and based on the variables defined
there i am creating nagios defacement host cfg.
My problem is that I can't conditionally decide if the file should be
created, based on the variable which will get content in the node config:
When the condition get evaluated $monstring still empty since it gets its
content in the node config later, so no file will be created.
If i remove the condition there will be hundreds of nagios cfg which should
not be created.
Can you give me some idea how can i make this work, so blog file gets
created and blog1 not.
*This is the important part of my resource type*
*
*
define vhost ($servername = ${hostname}.${domain}, $serveralias = [
www.${hostname}.${domain} ], $inorout = 1, $owner = root, $group =
root, $enabled = link, $rewrite = , $ssl = false, $cacert = ,
$certchain = , $certfile = , $keyfile = , $pringo = false,
$pringodir = pringo4, $staging = false, $mode = '755', $monstring = '' )
if ! $monstring == {
file{/root/${servername}.cfg:
ensure = present,
content =
template(${module_name}/defacementmon.erb),
}
}
*node config:*
import apache2/vhost.pp
vhost{'blog.domain.com':
servername = 'blog.domain.com',
serveralias = [ 'prod-blog.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
monstring = 'string',
inorout = '0';
}
vhost{'blog1.domain.com':
servername = 'blog1.domain.com',
serveralias = [ 'prod-blog1.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
inorout = '0';
}
I hope it is understandable, my english is not the best.
Peter
--
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.
--
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.
Re: [Puppet Users] Re: Conditional directory creation
Hey Den, thanks for the answer
I changed the import to include it was just a leftover when for some reason
include wasnt good enough to be able to use defined resource types with
some older version.
This false solution isnt working sadly still that monstring get evaluated
with the default value and never with the later defined value.
On 1 May 2012 14:58, Denmat tu2bg...@gmail.com wrote:
Hi,
can't see anything wrong off the top of my head except you use an import
statement instead of an include.
http://docs.puppetlabs.com/guides/language_guide.html#importing-manifests
Have you tried testing for a string like 'false'? Just to see if something
odd not going on.
$mode = '755', $monstring = 'false' )
if ! $monstring == false {
file{/root/${servername}.cfg:
Not at a computer so can't test the code till tomorrow (that's about 8
hours away).
Sorry,
Den
On 01/05/2012, at 22:24, Peter Horvath peter.horvat...@gmail.com wrote:
Anybody got any idea on this?
I am really stuck with this one.
On Apr 30, 4:51 pm, Peter Horvath peter.horvat...@googlemail.com
wrote:
Hi,
I have a modul which created the vhosts and based on the variables
defined
there i am creating nagios defacement host cfg.
My problem is that I can't conditionally decide if the file should be
created, based on the variable which will get content in the node
config:
When the condition get evaluated $monstring still empty since it gets
its
content in the node config later, so no file will be created.
If i remove the condition there will be hundreds of nagios cfg which
should
not be created.
Can you give me some idea how can i make this work, so blog file gets
created and blog1 not.
*This is the important part of my resource type*
*
*
define vhost ($servername = ${hostname}.${domain}, $serveralias = [
www.${hostname}.${domain} ], $inorout = 1, $owner = root, $group =
root, $enabled = link, $rewrite = , $ssl = false, $cacert = ,
$certchain = , $certfile = , $keyfile = , $pringo = false,
$pringodir = pringo4, $staging = false, $mode = '755', $monstring =
'' )
if ! $monstring == {
file{/root/${servername}.cfg:
ensure = present,
content =
template(${module_name}/defacementmon.erb),
}
}
*node config:*
import apache2/vhost.pp
vhost{'blog.domain.com':
servername = 'blog.domain.com',
serveralias = [ 'prod-blog.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
monstring = 'string',
inorout = '0';
}
vhost{'blog1.domain.com':
servername = 'blog1.domain.com',
serveralias = [ 'prod-blog1.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
inorout = '0';
}
I hope it is understandable, my english is not the best.
Peter
--
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.
--
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.
--
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] augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf
Howdy:
Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
get augeas to address /etc/rc.conf. I was able to modify key/values
in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
I think I recall Dominic saying that the /etc/rc.conf lens was added
by the FreeBSD ports maintainer. Can you help please? I just
refreshed my ports tree (portsnap fetch extract) and remade augeas.
The checksums on the lens files has not changes between versions.
I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.
# pwd
/usr/ports/textproc/augeas
# make deinstall reinstall clean
Here is the output of augtool:
broken:
# pkg_info |grep augeas
augeas-0.10.0_1 A configuration editing tool
# find /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
# augtool
augtool print /files/etc/rc.conf
augtool
works:
# pkg_info |grep augeas
augeas-0.7.1_2 A configuration editing tool
$ find /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
# augtool
augtool print /files/etc/rc.conf
/files/etc/rc.conf
/files/etc/rc.conf/cloned_interfaces = lagg0 vlan502 vlan503 tap0
[snip]
/files/etc/rc.conf/ifconfig_em0 = up
/files/etc/rc.conf/ifconfig_em1 = up
/files/etc/rc.conf/ifconfig_lagg0 = up laggproto failover laggport em0
laggport em1
/files/etc/rc.conf/openssh_enable = YES
/files/etc/rc.conf/ntpd_enable = YES
/files/etc/rc.conf/ntpd_sync_on_start = YES
/files/etc/rc.conf/nrpe2_enable = YES
/files/etc/rc.conf/sendmail_enable = NONE
/files/etc/rc.conf/tmpmfs = YES
/files/etc/rc.conf/postgresql_enable = YES
/files/etc/rc.conf/puppet_enable = YES
/files/etc/rc.conf/snmpd_enable = YES
/files/etc/rc.conf/pf_enable = YES
/files/etc/rc.conf/jail_enable = YES
[snip]
Thanks,
-dkw
--
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.
Re: [Puppet Users] Re: puppet way of handling rdist and triggers
I can't say that my puppet installation is even close to best
practices, but I think I have a situation similar enough to OP to put
it up for scrutiny. I deploy 7600 files to /var/www/html using puppet
and rsync. Puppet manages an rssh + chroot-jailed read-only file
share and provides the web head with an ssh key to access it.
This has the advantage of working around puppet's heavy weight file
handling, but still giving you the opportunity to attach to the
subscribe/notify infrastructure.
$rsync = /usr/bin/rsync -a rsync@puppet:html/ /var/www/html --delete
exec { Sync /var/www/html:
command = $rsync,
notify = Service[httpd],
onlyif = test `$rsync --dry-run --itemize-changes | wc -l` -gt 0,
require = Host[puppet],
}
--
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: agent suddenly disabled
I am wondering what would cause a puppet client to get into a state like this. I had a test vm do the same thing to me today. On Friday, April 13, 2012 2:59:43 PM UTC-4, Thomas wrote: That worked, thanks! On Apr 13, 2:54 pm, Patrick Carlisle patr...@puppetlabs.com wrote: This is a bug in the error message ( http://projects.puppetlabs.com/issues/13299). The correct command is 'puppet agent --enable'. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ruR8Butvu3EJ. 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 Agent locking with report=true in puppet.conf
Hello, I am seeing the issue where puppet agent becomes non-responsive and says it is already running when trying to do a puppet kick and there is a lock file in /var/lib/puppet/state. I have seen other posts about this and the fix seemed to be a kernel update. I am running on RHEL6.2 so I do not have any kernel updates to apply since it is at the latest. My puppet server and agent version is 2.7.13 release 1 and puppet-dashboard version is 1.2.7. Has anyone else come across this issue recently? Thanks for your assistance. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/X_Au7TmBnCIJ. 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.
Re: [Puppet Users] Re: puppet way of handling rdist and triggers
On Tue, May 1, 2012 at 6:58 AM, jcbollinger john.bollin...@stjude.org wrote:
But that requires the files be hosted on the puppet master.
What if the conf files are still rdisted out under /rdist/base instead?
What does that look like?
It looks exactly like what you are now doing (i.e. no Puppet). How do
you suppose Puppet is going to recognize that it needs to notify a
service if it's not managing the file?
That was indeed a major part of the question I have.
I thought it keeps some kind of database of file checksums, etc?
Doesnt puppet support some kind of
(action if file changed), even if it doesnt manage the file itself?
I think it would be useful to you to consider what you hope to achieve
by incorporating Puppet into your infrastructure. Your rdist system
must be working fairly well because you seem resistant to changing
it. What, then, do you think Puppet can bring to the table?
A fair question. I thought I had mentioned it, but perhaps not
sufficiently clearly:
I want to change our existing hosttype:/etc/file.conf -
/rdistbase/conf/file.conf.hosttype symlink methodology, to be more
like
node hosttype {
keep /rdistbase/conf/file.conf.host synced to /etc/file.conf
}
Our existing methodology works well 95% of the time. There are reasons
to keep it in place as is. But I want 100% coverage. symlinks break
patches, and a few other things.. The only way to extend things in
that direction that I can see, is have puppet manage the duplication
on a per-host basis.
Yes, I understand the normal puppet way of doing things, is to have
those conf files inside the puppet tree, but it is more maintainable
*for us*, to have all multi-host related stuff, in the single rdist
directory tree.
--
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.
Re: [Puppet Users] Re: puppet way of handling rdist and triggers
On Tue, May 1, 2012 at 9:24 AM, Philip Brown p...@bolthole.com wrote:
On Tue, May 1, 2012 at 6:58 AM, jcbollinger john.bollin...@stjude.org wrote:
But that requires the files be hosted on the puppet master.
What if the conf files are still rdisted out under /rdist/base instead?
What does that look like?
It looks exactly like what you are now doing (i.e. no Puppet). How do
you suppose Puppet is going to recognize that it needs to notify a
service if it's not managing the file?
That was indeed a major part of the question I have.
I thought it keeps some kind of database of file checksums, etc?
Doesnt puppet support some kind of
(action if file changed), even if it doesnt manage the file itself?
I think it would be useful to you to consider what you hope to achieve
by incorporating Puppet into your infrastructure. Your rdist system
must be working fairly well because you seem resistant to changing
it. What, then, do you think Puppet can bring to the table?
A fair question. I thought I had mentioned it, but perhaps not
sufficiently clearly:
I want to change our existing hosttype:/etc/file.conf -
/rdistbase/conf/file.conf.hosttype symlink methodology, to be more
like
node hosttype {
keep /rdistbase/conf/file.conf.host synced to /etc/file.conf
}
Our existing methodology works well 95% of the time. There are reasons
to keep it in place as is. But I want 100% coverage. symlinks break
patches, and a few other things.. The only way to extend things in
that direction that I can see, is have puppet manage the duplication
on a per-host basis.
Yes, I understand the normal puppet way of doing things, is to have
those conf files inside the puppet tree, but it is more maintainable
*for us*, to have all multi-host related stuff, in the single rdist
directory tree.
You can use rdist to retrieve the file as usual and in the file path
source use the local rdist directory instead of puppet:/// so there's
no remote file retrieval from the puppet master.
file { '/etc/file.conf':
source = /rdistbase/conf/file.conf.${::hostname},
}
Just trigger the puppet run after your normal rdist file push.
Thanks,
Nan
--
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] RHEL 6 and ActiveRecord issues
All, I am trying to install puppet master version 2.7.13 on Red Hat Enterprise Linux 6, and utilize stored configs. I followed the guide here: http://projects.puppetlabs.com/projects/1/wiki/Using_Stored_Configuration When I run puppet --noop on one of the clients, I get the following error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not autoload active_record: uninitialized constant ActiveRecord warning: Not using cache on failed catalog err: Could not retrieve catalog; skipping run Googling this error has a smattering of hits, including one that recommends using the 3.0.11 version of the Active Record gem, but I get the same error. I have installed both the 3.2.3 and 3.0.11 versions of the ActiveRecord gem (3.0.11 was recomended here: https://groups.google.com/group/puppet-users/browse_thread/thread/55f29e9454ad5675) This error occurs regardless of the DB backend I tie to. I have tried both the postgres and mysql documentation. # ruby --version ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux] # puppet --version 2.7.13 # puppetmasterd --version 2.7.13 I have searched the puppetlabs issue tracker and found a possibly related issue:Debian Squeeze package puppetmaster: Could not autoload active_record: uninitialized constant ActiveRecord(http:// projects.puppetlabs.com/issues/14080). This indicates that I may be missing a related package or gem -- but I don't even know where to start tracking down the missing package. On IRC it has been suggested that I install rubygem-activerecord, but this does not appear to be in the EPEL repo -- Haus on IRC found a 2.3.8 version of this package that I installed to test, but I get the same error. I managed to get a different error briefly, when I was running multiple versions of activerecord, activeresource and activesupport -- installed through a mix of gem and yum. Deleting the non-yum versions returned me to the existing error, so I am chalking that up as a fluke at this time. Any help would be appreciated. Jeff -- 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.
Re: [Puppet Users] Re: puppet eating solaris 10 crontab for lunch
On Tue, May 1, 2012 at 03:14, Kent dri...@gmail.com wrote: I don't think it's issue #5752, I opened that issue and provided a patch to resolve it. When I build new versions of Puppet for my Solaris hosts I apply that patch each time via my build script and I'm still having some hosts where the crontab gets eaten and it always seems to correspond with 'prtdiag' issues or timeouts. Facter has a timeout built in for prtdiag and then does a kill routine if it needs to clean up. I wonder if it's being overly agressive and accidentally killing some or all of the Puppet run in turn causing this issue? I agree, that I think this is probably what is happening. I've since stopped using puppet to manage our solaris crontab files since we can't currently fully puppetize our crontabs. Unfortunately, solaris doesn't have a cron.d directory where we can drop crontab files either. Romeo On Mar 13, 5:31 pm, Greg greg.b...@gmail.com wrote: Have seen similar. Quite often when prtdiag fails to complete, I've found that restarting svc:/system/picl:default returns everything back to normal... Hopefully all your root cron jobs are in Puppet and will be rebuilt on the next run... Greg On Mar 14, 9:26 am, John Warburton jwarbur...@gmail.com wrote: On 14 March 2012 09:16, Romeo Theriault romeo.theria...@maine.edu wrote: Here are the logs the solaris 10 box returns after it's crontab gets destroyed: ERR Puppet Could not prefetch cron provider 'crontab': Could not read crontab for root: No child processes NOTICE /Stage[main]/Puppet/Cron[puppet]/ensure created NOTICE Puppet Finished catalog run in 2.52 seconds After this the only thing that exists in the crontab is the entry we have puppet adding. I found this bug: http://projects.puppetlabs.com/issues/1672 which says there was a fix and it was merged but we're still seeing this issue... puppet agent v. 2.7.9 facter v. 1.6.5 It could be this bug -https://projects.puppetlabs.com/issues/5752 That andhttps://projects.puppetlabs.com/issues/9854arekeeping me from pushing migrating to 2.7 up my priority list Indeed, there are 5 issues marked Urgent in the 2.7.x bucket John -- 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. -- Romeo -- 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.
Re: [Puppet Users] augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf
Hi Darryl,
On 01/05/12 16:11, Darryl Wisneski wrote:
Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
get augeas to address /etc/rc.conf. I was able to modify key/values
in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
I think I recall Dominic saying that the /etc/rc.conf lens was added
by the FreeBSD ports maintainer. Can you help please? I just
refreshed my ports tree (portsnap fetch extract) and remade augeas.
The checksums on the lens files has not changes between versions.
I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.
There are a few overlapping issues with /etc/rc.conf. There is indeed a
lens shipped with the FreeBSD port which you're seeing here. In Augeas
0.8.1, rc.conf was added to the Shellvars lens shipped with Augeas
itself, but then in 0.10.0 it was accidentally removed from the list.
This has been fixed in git, but is unreleased.
I suspect on 0.7.1 you're using the FreeBSD lens. On 0.10.0 you would
have to be using the FreeBSD lens, but it looks like this isn't being
picked up - so either the rcconf.aug lens is disabled somehow (or isn't
in the right search path) or it is failing to parse your rc.conf file.
broken:
# pkg_info |grep augeas
augeas-0.10.0_1 A configuration editing tool
# find /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
# augtool
augtool print /files/etc/rc.conf
augtool
Could you try running this in augtool to see if a lens is being used,
and if there are errors?
print /augeas/files/etc/rc.conf/
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113
--
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: augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf
Hi Steve:
On Tue, May 01, 2012 at 02:15:25PM -0400, Steve Wills wrote:
Hi,
Thanks for the info. Something is definitely not right, but it doesn't
seem to work for me even with the older version:
It looks like the problem is that the fix in ticket 255:
https://fedorahosted.org/augeas/ticket/255
https://fedorahosted.org/augeas/changeset/95515f45adf192ab10e6c6ffbd69b5977a9f78b2/
The patch worked but the rc.conf potentially needs double quotes
on the RHS, or value. No? It seems this functionality conflicts
with the resolution of ticket 255.
-dkw
is not included in the current release. That's OK, I can patch it in. See
attached patch. With this, I get:
% augtool --version
augtool 0.10.0 http://augeas.net/
Copyright (C) 2007-2011 David Lutterkort
License LGPLv2+: GNU LGPL version 2.1 or later
http://www.gnu.org/licenses/lgpl-2.1.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David Lutterkort
% augtool print /files/etc/rc.conf
/files/etc/rc.conf
/files/etc/rc.conf/keymap = \us.pc-ctrl\
/files/etc/rc.conf/sshd_enable = \YES\
[snip]
%
If this works for you, I'll go ahead and commit this.
Thanks,
Steve
Howdy:
Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
get augeas to address /etc/rc.conf. I was able to modify key/values
in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
I think I recall Dominic saying that the /etc/rc.conf lens was added
by the FreeBSD ports maintainer. Can you help please? I just
refreshed my ports tree (portsnap fetch extract) and remade augeas.
The checksums on the lens files has not changes between versions.
I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.
# pwd
/usr/ports/textproc/augeas
# make deinstall reinstall clean
Here is the output of augtool:
broken:
# pkg_info |grep augeas
augeas-0.10.0_1 A configuration editing tool
# find /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
# augtool
augtool print /files/etc/rc.conf
augtool
works:
# pkg_info |grep augeas
augeas-0.7.1_2 A configuration editing tool
$ find /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
# augtool
augtool print /files/etc/rc.conf
/files/etc/rc.conf
/files/etc/rc.conf/cloned_interfaces = lagg0 vlan502 vlan503 tap0
[snip]
/files/etc/rc.conf/ifconfig_em0 = up
/files/etc/rc.conf/ifconfig_em1 = up
/files/etc/rc.conf/ifconfig_lagg0 = up laggproto failover laggport em0
laggport em1
/files/etc/rc.conf/openssh_enable = YES
/files/etc/rc.conf/ntpd_enable = YES
/files/etc/rc.conf/ntpd_sync_on_start = YES
/files/etc/rc.conf/nrpe2_enable = YES
/files/etc/rc.conf/sendmail_enable = NONE
/files/etc/rc.conf/tmpmfs = YES
/files/etc/rc.conf/postgresql_enable = YES
/files/etc/rc.conf/puppet_enable = YES
/files/etc/rc.conf/snmpd_enable = YES
/files/etc/rc.conf/pf_enable = YES
/files/etc/rc.conf/jail_enable = YES
[snip]
Thanks,
-dkw
Index: Makefile
===
RCS file: /home/pcvs/ports/textproc/augeas/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- Makefile 25 Apr 2012 01:11:34 - 1.10
+++ Makefile 1 May 2012 18:09:53 -
@@ -8,7 +8,7 @@
PORTNAME=augeas
PORTVERSION= 0.10.0
-PORTREVISION=1
+PORTREVISION=2
CATEGORIES= textproc
MASTER_SITES=http://augeas.net/download/
@@ -38,7 +38,6 @@
post-install:
${MKDIR} ${LENSESDIR}/tests
- ${INSTALL_DATA} ${FILESDIR}/rcconf.aug ${LENSESDIR}/rcconf.aug
${INSTALL_DATA} ${FILESDIR}/test_rcconf.aug
${LENSESDIR}/tests/rcconf.aug
.include bsd.port.mk
Index: pkg-plist
===
RCS file: /home/pcvs/ports/textproc/augeas/pkg-plist,v
retrieving revision 1.2
diff -u -r1.2 pkg-plist
--- pkg-plist 12 Feb 2012 13:17:44 - 1.2
+++ pkg-plist 1 May 2012 18:09:53 -
@@ -231,7 +231,6 @@
%%DATADIR%%/lenses/dist/xml.aug
%%DATADIR%%/lenses/dist/xorg.aug
%%DATADIR%%/lenses/dist/yum.aug
-%%DATADIR%%/lenses/rcconf.aug
%%DATADIR%%/lenses/tests/rcconf.aug
share/vim/vimfiles/ftdetect/augeas.vim
share/vim/vimfiles/syntax/augeas.vim
Index: files/patch-lenses__shellvars.aug
===
RCS file: files/patch-lenses__shellvars.aug
diff -N files/patch-lenses__shellvars.aug
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/patch-lenses__shellvars.aug 1 May 2012 18:09:53 -
@@ -0,0 +1,10 @@
+--- ./lenses/shellvars.aug.orig 2012-05-01
Re: [Puppet Users] augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf
Hi Dominic:
On Tue, May 01, 2012 at 09:01:16PM +0100, Dominic Cleal wrote:
Hi Darryl,
On 01/05/12 16:11, Darryl Wisneski wrote:
Since I upgraded some of my FreeBSD boxen to augeas-0.10.0* I can't
get augeas to address /etc/rc.conf. I was able to modify key/values
in /etc/rc.conf in augeas-0.7.1_2 in my puppet classes and augtool.
I think I recall Dominic saying that the /etc/rc.conf lens was added
by the FreeBSD ports maintainer. Can you help please? I just
refreshed my ports tree (portsnap fetch extract) and remade augeas.
The checksums on the lens files has not changes between versions.
I am seeing this behavior in FreeBSD 8.2 and 9.0 RELEASE.
There are a few overlapping issues with /etc/rc.conf. There is indeed a
lens shipped with the FreeBSD port which you're seeing here. In Augeas
0.8.1, rc.conf was added to the Shellvars lens shipped with Augeas
itself, but then in 0.10.0 it was accidentally removed from the list.
This has been fixed in git, but is unreleased.
I suspect on 0.7.1 you're using the FreeBSD lens. On 0.10.0 you would
have to be using the FreeBSD lens, but it looks like this isn't being
picked up - so either the rcconf.aug lens is disabled somehow (or isn't
in the right search path) or it is failing to parse your rc.conf file.
broken:
# pkg_info |grep augeas
augeas-0.10.0_1 A configuration editing tool
# find /usr/local/share/augeas/lenses/ -name *rcconf* -exec sum {} \;
29678 1 /usr/local/share/augeas/lenses/tests/rcconf.aug
13563 1 /usr/local/share/augeas/lenses/rcconf.aug
# augtool
augtool print /files/etc/rc.conf
augtool
Could you try running this in augtool to see if a lens is being used,
and if there are errors?
print /augeas/files/etc/rc.conf/
Just reinstalling the problematic port here: augeas-0.10.0_1
install -o root -g wheel -m 444
/usr/ports/textproc/augeas/files/test_rcconf.aug
/usr/local/share/augeas/lenses/tests/rcconf.aug
=== Compressing manual pages for augeas-0.10.0_1
=== Running ldconfig
/sbin/ldconfig -m /usr/local/lib
=== Registering installation for augeas-0.10.0_1
# augtool --version
augtool 0.10.0 http://augeas.net/
Copyright (C) 2007-2011 David Lutterkort
License LGPLv2+: GNU LGPL version 2.1 or later
http://www.gnu.org/licenses/lgpl-2.1.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David Lutterkort
# augtool
augtool print /augeas/files/etc/rc.conf
/augeas/files/etc/rc.conf
/augeas/files/etc/rc.conf/path = /files/etc/rc.conf
/augeas/files/etc/rc.conf/mtime = 1335894110
/augeas/files/etc/rc.conf/lens = @RcConf
/augeas/files/etc/rc.conf/lens/info =
/usr/local/share/augeas/lenses/rcconf.aug:15.11-.39:
-dkw
--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113
--
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.
Re: [Puppet Users] Re: puppet eating solaris 10 crontab for lunch
On Tue, May 1, 2012 at 12:45 PM, Romeo Theriault romeo.theria...@maine.eduwrote: Unfortunately, solaris doesn't have a cron.d directory where we can drop crontab files either. Are you talking about /var/spool/cron/crontab on Solaris? (think that's the right path) It won't reload them without being kicked. But, you can play tricks with it by dropping the file there, then reload it by invoking crontab and feeding it the new file. You might have to massage it to get things to work properly, but it should be possible (ie. I've done it this way, manually, in a previous life). -- 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.
Re: [Puppet Users] Re: augeas-0.10.0_1 in FreeBSD can't see /etc/rc.conf
On 01/05/12 21:12, Darryl Wisneski wrote: On Tue, May 01, 2012 at 02:15:25PM -0400, Steve Wills wrote: Hi, Thanks for the info. Something is definitely not right, but it doesn't seem to work for me even with the older version: It looks like the problem is that the fix in ticket 255: https://fedorahosted.org/augeas/ticket/255 https://fedorahosted.org/augeas/changeset/95515f45adf192ab10e6c6ffbd69b5977a9f78b2/ The patch worked but the rc.conf potentially needs double quotes on the RHS, or value. No? It seems this functionality conflicts with the resolution of ticket 255. Yes, there is some conflict here. Unfortunately the path /etc/rc.conf has now been picked up by Arch Linux for all configuration (sigh): https://wiki.archlinux.org/index.php/Rc.conf In their case it's meant to be fully bash-compatible according to rc.conf(5). When /etc/rc.conf was originally added to Shellvars upstream, the same was probably assumed for FreeBSD. I assume the quotes are just for style, or are they required for parsing? I'd be hesitant to suggest changing back to the rcconf.aug lens, even though it was here first, due to Arch and that we've started to use Shellvars now. This means you'd need to update resources to add the quotes explicitly, or that Steve patched the FreeBSD port to keep the rcconf.aug lens instead of upstream's Shellvars (which could get confusing). What do you think? is not included in the current release. That's OK, I can patch it in. See attached patch. With this, I get: % augtool --version augtool 0.10.0 http://augeas.net/ Copyright (C) 2007-2011 David Lutterkort License LGPLv2+: GNU LGPL version 2.1 or later http://www.gnu.org/licenses/lgpl-2.1.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by David Lutterkort % augtool print /files/etc/rc.conf /files/etc/rc.conf /files/etc/rc.conf/keymap = \us.pc-ctrl\ /files/etc/rc.conf/sshd_enable = \YES\ [snip] This matches what should be back in the next Augeas release, and how 0.8.1/0.9.0 both behaved. -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- 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] White list of packages
Can anyone tell me if it is possible to explicitly specify the only allowed packages on a host (modules on a node?) - i.e. a white list? This is for hardening a VPS in the cloud. Thanks in advance Andrew -- 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.
Re: [Puppet Users] Re: puppet eating solaris 10 crontab for lunch
On Tue, May 1, 2012 at 10:35 AM, Russell Van Tassell russel...@gmail.com wrote: On Tue, May 1, 2012 at 12:45 PM, Romeo Theriault romeo.theria...@maine.edu wrote: Unfortunately, solaris doesn't have a cron.d directory where we can drop crontab files either. Are you talking about /var/spool/cron/crontab on Solaris? (think that's the right path) It won't reload them without being kicked. But, you can play tricks with it by dropping the file there, then reload it by invoking crontab and feeding it the new file. You might have to massage it to get things to work properly, but it should be possible (ie. I've done it this way, manually, in a previous life). I was referring to something like the /etc/cron.d/ directory on linux where you can drop in new files that have specific entries. Are you suggesting that you can drop in new files into the /var/spool/cron/crontabs dir on solaris and it will pick them up after being reloaded? How would it know which user to run this crontab as if it's not the actual users crontab file itself? See, I don't want to manage the whole file. I'd like to just be able to manage individual entries by placing new files into the dir. -- Romeo -- 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.
Re: [Puppet Users] White list of packages
You can install and remove specific packages, but not specify a whitelist. (Unless you wanted to do creative things with facts, templates, and puppetized scripts. I'm assuming you think it's better to hose your server due to a typo than run with a single unpermitted package. And then how are you going to deal with the /var/tmp/... style of file-upload packages used by various script kiddies?) On Tue, May 01, 2012 at 01:38:34PM -0700, bainar wrote: Can anyone tell me if it is possible to explicitly specify the only allowed packages on a host (modules on a node?) - i.e. a white list? This is for hardening a VPS in the cloud. Thanks in advance Andrew -- 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. -- 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.
Re: [Puppet Users] err: Could not send report: Error 400 on SERVER: execution expired
is your time the same on both client and master? it would be helpful if you provided the --verbose --debug --test --no-daemonize output of the client.. Also run your master in verbose mode and paste it's errors here as well. On Fri, Apr 27, 2012 at 10:12 AM, Demon demonicc...@hotmail.com wrote: Hey there! All my clients have gone out of sync are have the following line in the puppet.out log file... err: Could not send report: Error 400 on SERVER: execution expired The clients appear to not be updating either... I have restarted the Puppet Master to no avail... Any help appreciated! -- 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. -- *- Shawn Taaj* -- 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.
Re: [Puppet Users] White list of packages
you could always write shell to compare a whitelist against a dpkg -l listing, or whatever pkg manager you are using. Then have it generate your puppet manifest.. First I would try to figure out how to prevent unwanted packages from being installed in the first place, not removing them after they were installed. On Tue, May 1, 2012 at 8:04 PM, Christopher Wood christopher_w...@pobox.com wrote: You can install and remove specific packages, but not specify a whitelist. (Unless you wanted to do creative things with facts, templates, and puppetized scripts. I'm assuming you think it's better to hose your server due to a typo than run with a single unpermitted package. And then how are you going to deal with the /var/tmp/... style of file-upload packages used by various script kiddies?) On Tue, May 01, 2012 at 01:38:34PM -0700, bainar wrote: Can anyone tell me if it is possible to explicitly specify the only allowed packages on a host (modules on a node?) - i.e. a white list? This is for hardening a VPS in the cloud. Thanks in advance Andrew -- 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. -- 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. -- *- Shawn Taaj* -- 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.
Re: [Puppet Users] Re: Conditional directory creation
Hi Peter,
take a look at this:
class testme {
define vhost ($servername = ${hostname}.${domain}, $serveralias =
[ www.${hostname}.${domain} ], $inorout = 1, $owner = root,
$group = root, $enabled = link, $rewrite = , $ssl = false,
$cacert = , $certchain = , $certfile = , $keyfile = , $pringo
= false, $pringodir = pringo4, $staging = false, $mode = '755',
$monstring = undef ) {
if $monstring {
file{/root/test_${servername}.cfg:
ensure = present,
content = ${servername}_defacementmon.erb,
}
}
}
}
class runme {
include testme
testme::vhost{'blog.domain.com':
servername = 'blog.domain.com',
serveralias = [ 'prod-blog.domain.com' ],
enabled = 'link',
monstring = 'string',
inorout = '0',
}
testme::vhost{'blog1.domain.com':
servername = 'blog1.domain.com',
serveralias = [ 'prod-blog1.domain.com' ],
enabled = 'link',
inorout = '0',
}
}
include runme
Now the monstring, if it is not declared remains 'undef'. We now just
test on the existence of monstring. If it is declared it you create
the file, if not the file is not created.
In my quick testing it appeared to work, but may not be exactly
suitable for your env.
That help?
Den
On Wed, May 2, 2012 at 1:03 AM, Peter Horvath peter.horvat...@gmail.com wrote:
Hey Den, thanks for the answer
I changed the import to include it was just a leftover when for some reason
include wasnt good enough to be able to use defined resource types with some
older version.
This false solution isnt working sadly still that monstring get evaluated
with the default value and never with the later defined value.
On 1 May 2012 14:58, Denmat tu2bg...@gmail.com wrote:
Hi,
can't see anything wrong off the top of my head except you use an import
statement instead of an include.
http://docs.puppetlabs.com/guides/language_guide.html#importing-manifests
Have you tried testing for a string like 'false'? Just to see if something
odd not going on.
$mode = '755', $monstring = 'false' )
if ! $monstring == false {
file{/root/${servername}.cfg:
Not at a computer so can't test the code till tomorrow (that's about 8
hours away).
Sorry,
Den
On 01/05/2012, at 22:24, Peter Horvath peter.horvat...@gmail.com wrote:
Anybody got any idea on this?
I am really stuck with this one.
On Apr 30, 4:51 pm, Peter Horvath peter.horvat...@googlemail.com
wrote:
Hi,
I have a modul which created the vhosts and based on the variables
defined
there i am creating nagios defacement host cfg.
My problem is that I can't conditionally decide if the file should be
created, based on the variable which will get content in the node
config:
When the condition get evaluated $monstring still empty since it gets
its
content in the node config later, so no file will be created.
If i remove the condition there will be hundreds of nagios cfg which
should
not be created.
Can you give me some idea how can i make this work, so blog file gets
created and blog1 not.
*This is the important part of my resource type*
*
*
define vhost ($servername = ${hostname}.${domain}, $serveralias = [
www.${hostname}.${domain} ], $inorout = 1, $owner = root, $group
=
root, $enabled = link, $rewrite = , $ssl = false, $cacert = ,
$certchain = , $certfile = , $keyfile = , $pringo = false,
$pringodir = pringo4, $staging = false, $mode = '755', $monstring =
'' )
if ! $monstring == {
file{/root/${servername}.cfg:
ensure = present,
content =
template(${module_name}/defacementmon.erb),
}
}
*node config:*
import apache2/vhost.pp
vhost{'blog.domain.com':
servername = 'blog.domain.com',
serveralias = [ 'prod-blog.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
monstring = 'string',
inorout = '0';
}
vhost{'blog1.domain.com':
servername = 'blog1.domain.com',
serveralias = [ 'prod-blog1.domain.com' ],
enabled = 'link',
require = Mount['/var/www'],
inorout = '0';
}
I hope it is understandable, my english is not the best.
Peter
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To post to this group, send email
[Puppet Users] Question About filebucket vs. clientbucket on Puppet 0.22.1
I'm working in a Puppet environment (0.22.1) that I didn't setup. It's
working pretty well but there's one thing that confuses me.
/etc/puppet/manifests/site.pp has the following lines:
filebucket { main: server = server1.example.com }
File { backup = main }
-
On server1.example.com I see /var/lib/puppet/bucket so these lines
appear to be working.
Here's my main question. On the puppet clients I see
/var/lib/puppet/clientbucket. I don't understand why changes
are appearing in both /var/lib/puppet/bucket on the puppetmaster
and in /var/lib/puppet/clientbucket on the clients. The file names
in these directories are different so I can't see if the puppetmaster
bucket contains the files from all the clients. For example, on the
puppetmaster in /var/lib/puppet/bucket I see a directory called
061d9ee45f034115f696fb360d596bf8 that contains 2 files, contents
and paths. On a puppet client I see
/var/lib/puppet/clientbucket/1/d/2/3/8//9/4/1d2384945d99573319318c4b4109f15b
(I don't see a directory 1d2384945d99573319318c4b4109f15b on the
puppetmaster).
The reason I'm asking all this is because I want to turn off saving
of changed files on both the puppetmaster and the clients. Can I just
remove the 2 lines from site.pp I show above? I'm concerned that
clientbucket will remain on the clients.
Finally, in those lines from site.pp what does main mean? In
http://docs.puppetlabs.com/references/stable/type.html#file
there is a sample resource definition that also contains
backup = main but it doesn't answer this question.
I'm guessing that it just means the puppetmaster server but
it would be nice to see the official definition.
Cordially,
Jon Forrest
--
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.
Re: [Puppet Users] White list of packages
Rather than whitelisting packages, you probably want to build a severely cut-down repository and ensure it's the only one configured for your box. On May 1, 2012 1:40 PM, bainar andrew.r.b...@gmail.com wrote: Can anyone tell me if it is possible to explicitly specify the only allowed packages on a host (modules on a node?) - i.e. a white list? This is for hardening a VPS in the cloud. Thanks in advance Andrew -- 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. -- 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.
Re: [Puppet Users] White list of packages
On Tue, May 1, 2012 at 10:38 PM, bainar andrew.r.b...@gmail.com wrote:
Can anyone tell me if it is possible to explicitly specify the only
allowed packages on a host (modules on a node?) - i.e. a white list?
This is for hardening a VPS in the cloud.
Shouldn't it work using a resource default, something like:
Package {
ensure = absent,
}
$whitelist = [foo, bar, baz]
package { $whitelist:
ensure = present,
}
--
Grtz,
Jörgen Maas
--
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.
