Re: [Puppet Users] Augeas: Skipping because no files were changed
Thanks Ian,
I had tried with and without the context, also tried with set and setm,
tried to include the values first... but nothing worked.
I was about to go insane and through to remove the trailing slash in the
changes...
augeas { 'grub.conf/8250_LAR':
incl = '/etc/grub.conf',
lens= 'Grub.lns',
changes = [
'set title[1]/kernel/8250.nr_uarts 4',
'set title[1]/kernel/8250_core.nr_uarts 4',
],
}
and now it works, with and without the context.. but I'll put it back in
anyway just in case.
Thanks!
Chris
On Wednesday, 8 July 2015 05:23:59 UTC+2, ianm wrote:
Actually in this case it needs:
context = '/files/boot/grub/grub.conf',
or:
context = '/files/etc/grub.conf',
incl = '/etc/grub.conf',
--
Ian
--
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/789e685d-04b9-4918-b044-34e6f96e9b7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Augeas: Skipping because no files were changed
I am trying to add two new options to grub.conf using augeas.
The code is as follows:
augeas { 'grub.conf/8250_LAR':
tag = chris1,
incl= '/boot/grub/grub.conf',
lens= 'Grub.lns',
changes = [
'set /title[1]/kernel/8250.nr_uarts 8',
'set /title[1]/kernel/8250_core.nr_uarts 8',
],
}
However nothing is added to /etc/grub.conf at all, and the puppet run
completes as follows with debug.
Debug: Augeas[grub.conf/8250_LAR](provider=augeas): Augeas version 1.0.0 is
installed
Debug: Augeas[grub.conf/8250_LAR](provider=augeas): Will attempt to save and
only run if files changed
Debug: Augeas[grub.conf/8250_LAR](provider=augeas): sending command 'set'
with params [/title[*]/kernel/8250.nr_uarts, 8]
Debug: Augeas[grub.conf/8250_LAR](provider=augeas): sending command 'set'
with params [/title[*]/kernel/8250_core.nr_uarts, 8]
Debug: Augeas[grub.conf/8250_LAR](provider=augeas): Skipping because no
files were changed
Debug: Augeas[grub.conf/8250_LAR](provider=augeas): Closed the augeas
connection
Manually, Augeas appears to work fine:
augtool set /files/boot/grub/grub.conf/title[1]/kernel/8250_core.nr_uarts 8
augtool save
Saved 1 file(s)
I'd appreciate any ideas?
Thanks
Chris
--
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/9f4a854d-e3b3-4be1-b7f2-5d495dba21d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Dependency cycle using tidy with puppet 3
Alternatively, you should be able to overcome any autorequire by declaring
a contradictory explicit relationship. For example, you could try this:
define crond::job($jobs,$comment,$mail=root) {
include crond::cleanup
file {
/etc/cron.d/${name}.puppet.cron:
owner=root,group=root,
content=template(crond/job.erb)
} - Tidy['/etc/cron.d']
}
That worked perfectly, and it doesn't appear to be removing any of the
other files.
The next part of our migration will obviously be moving what we can from
extdata to hiera, etc and then a massive code clean up to conform with all
the new best practises. Getting around this now though makes it much
easier to get the system working with Puppet 3.0+ and start the big project
of cleaning.
Thank you so much
Chris
--
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/2ab1e1b8-accb-42b0-ad4e-7ac984681a9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Dependency cycle using tidy with puppet 3
We try not to use stages at all, unless absolutely necessary and we would love to avoid them if we could. Our puppet code is used on around ~3000 machines in a heterogeneous environment of both various hardwares, os boot systems and applications, so at times its an unnecessary evil It is my understanding that tidy now now creates a dependency on the file, but since this is run in the beginning, the tidy on the files which are created in post creates a loop. For all the other times we use tidy I was able to get around by splitting the tidy from the classes and simple including them, this is the last one I cant seem to get around. I did find another post about this and puppet 3, but no solution https://ask.puppetlabs.com/question/13431/how-do-i-work-around-puppet-3-semantics-change/ Unfortunately we have way to many variables, and while direct requires might be possible it would mean an entire rewrite of ~ 4 years of code, and many times we have run into conflicts anyway which finally forced us into this. Mostly the idea is that our (systems admin) configuration is run in main, specific user requirements are configured in apps, and only after all of that, do we declare the machine usable. Finally we ensure that things like puppet are running, where prior to that on a broken system it wouldn't be required anyway, and then apply certain safety checks, as with this cron which does a daily check to ensure puppet hasn't been disabled and mails a report which we can compare with puppet dashboards output. With out the stages this would literally require hundreds of if defined statements due to all the various configurations available. The File[/etc/cron.d/puppetcheck.puppet.cron] - Tidy[/etc/cron.d] relationship is from the new design of tidy as explained in the post I linked above. The code I posted is simple called in a class that is set to stage post. -- 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/8972ab55-6b62-499c-bd58-eb82d5593192%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Dependency cycle using tidy with puppet 3
We try not to use stages at all, unless absolutely necessary and we would love to avoid them if we could. Our puppet code is used on around ~3000 machines in a heterogeneous environment of both various hardwares, os boot systems and applications, so at times its an necessary evil It is my understanding that tidy now now creates a dependency on the file, but since this is run in the beginning of the catalog, the tidy on the files which are created in post creates a loop. For all the other times we use tidy I was able to get around this by splitting the tidy from the classes and simple including them, this is the last one I cant seem to get around. I did find another post about this and puppet 3, but no solution https://ask.puppetlabs.com/question/13431/how-do-i-work-around-puppet-3-semantics-change/ Unfortunately we have way to many variables, and while direct requires might be possible it would mean an entire rewrite of ~ 4 years of code, and many times we have run into conflicts anyway which finally forced us into this. Mostly the idea is that our (systems admin) configuration is run in main, specific user requirements are configured in apps, and only after all of that, do we declare the machine usable (remove nologin, etc). Finally, we then ensure that things like puppet are running, where prior to that on a broken system it wouldn't be required anyway, and then apply certain safety checks, as with this cron which does a daily check to ensure puppet hasn't been disabled and mails a report which we can compare with puppet dashboards output. With out the stages this would literally require hundreds of if defined statements due to all the various configurations available. The File[/etc/cron.d/puppetcheck. puppet.cron] - Tidy[/etc/cron.d] relationship is from the new design of tidy as explained in the post I linked above. The code I posted is simple called in a class that is set to stage post? -- 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/3e097655-c925-4bd9-bebf-1dbf6d87782f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Dependency cycle using tidy with puppet 3
hmmm, I've created a new class trying to replicated the exact same thing with different files, and I cant seem to.. Will have to do a lot more digging to see where this is coming from -- 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/7161a278-b98b-4782-9fb9-abeb5117120c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Dependency cycle using tidy with puppet 3
The first error was being thrown out and I didn't see the second one. Its
easy to replicate using puppet 3.3.2
node test {
class {crond::test:stage=post,}
}
define crond::job($jobs,$comment,$mail=root) {
include crond::cleanup
file {
/etc/cron.d/${name}.puppet.cron:
owner=root,group=root,
content=template(crond/job.erb)
}
}
class crond::cleanup {
tidy {
/etc/cron.d:
age = 0, recurse = true,
matches = *.puppet.cron,
}
service {
crond: ensure=running,enable=true
}
}
class crond::test {
crond::job {tidytest:
mail=root,
comment=testing tidy,
jobs=6 6 * * * root nice /bin/true,
}
}
--
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/886b7539-751a-4b32-b283-dcb9859fb561%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: mod_passenger.so is missing
assuming linux you could run yum whatprovides *mod_passenger.so for example on my system it is as follows: mod_passenger-3.0.17-2.el6.1.x86_64 : Apache Module for Phusion Passenger Repo: atds Matched from: Filename: /usr/lib64/httpd/modules/mod_passenger.so mod_passenger-3.0.17-2.el6.1.x86_64 : Apache Module for Phusion Passenger Repo: installed Matched from: Filename: /usr/lib64/httpd/modules/mod_passenger.so -- 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/ac351ec6-c2e0-4913-b657-6dca873aff4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: mod_passenger.so is missing
ps: not so sure about the gems and why its not there? -- 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/f6c11be1-88a2-4cc2-8431-907cf0078a68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Dependency cycle using tidy with puppet 3
Hi all,
We are busy migrating out puppet 2.7 code to puppet 3 and have run into a
problem where we are getting dependency cycles when using tidy.
This mostly happens with stages (and yes, I completely understand why we
should avoid them).
As an example we have a defined class that we use to create our cron jobs,
and then a tidy to clean up anything that isn't defined.
class crond::cleanup {
tidy {
/etc/cron.d:
age = 0, recurse = true,
matches = *.puppet.cron
}
}
define crond::job($jobs,$comment,$mail=root) {
include crond::cleanup
file {
/etc/cron.d/${name}.puppet.cron:
owner=root,group=root,
content=template(crond/job.erb)
}
}
and we get a dependency as follows:
(File[/etc/cron.d/puppetcheck.puppet.cron] = Tidy[/etc/cron.d] =
Class[Crond::Cleanup] = Stage[main] = Stage[apps] = Stage[apps] =
Stage[post] = Class[Puppet::Service] = Crond::Job[puppetcheck] =
File[/etc/cron.d/puppetcheck.puppet.cron])
Does anyone know of a workaround?
Thanks
Chris
--
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/01a1dc4a-ab91-4653-a879-ba4d4d26ea21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet Master fails when dashboard is unreachable
I would like to know if anyone has seen this before or has any suggestions. After a power cut recently we were bringing our farm back on line, and our dashboard server (separate to our puppet master) was not online yet as reporting at this point was not considered critical. However, we noticed that none of our critical machines completed their puppet runs. It appears to us that puppet freezes when its unable to get a response back from the dashboard, and never times out. As soon as we brought the dashboard back online everything started working again. Cheers Chris -- 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] Re: Puppet Master fails when dashboard is unreachable
Hi Marcus We aren't running PuppetDB, so hoping that shouldn't effect anything? Chris -- 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] Re: Puppet apply and send reports?
I forgot to say thank you. The changes below worked perfectly. At first I tried them just by changing on command line. Using --reports=http and --reporturl= https://dashboard.example.com:3000/reports/upload , worked, but though I wasn't able to use --report=true so still nothing happened. Modifying the report=true however on the central puppet.conf file on our netbooted systems worked perfectly and our dashboard very quickly started getting reports from all the nodes Thanks again Cheers Chris On Sunday, 24 February 2013 19:58:13 UTC+1, Nick Fagerlund wrote: Yes, you can definitely rig puppet apply to send reports. The trick is that it works like a puppet master, not like a puppet agent, so you need to configure the nodes to talk directly to the dashboard server; they can't go through the puppet master. (It also means that by default, puppet apply has reports = store and puts its run reports on the local disk in the reportdir. I guess you could find those and manually import them into dashboard, if you felt like it.) So, you need to set the following in each node's puppet.conf: # Use http report processor; don't bother storing reports on disk reports = http # Send reports to dashboard server reporturl = https://dashboard.example.com:3000/reports/upload -- 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] Re: Puppet apply and send reports?
Seem to of lost me last reply again. Anyway, we can see the puppet server, and the dashboard server. However since these are specialised netbooted machines with very little RAM, the puppet apply method with a cron job has been our only solution. WE currently have the cron sending us emails when it makes changes, but this is amounting to 2000+ emails a day and we were wanting to know if there was a way to have the reports rather sent to our dashboard server, where we filter out the SQL database for details On Wednesday, 20 February 2013 17:48:02 UTC+1, jcbollinger wrote: On Wednesday, February 20, 2013 7:46:11 AM UTC-6, Chris Lee wrote: Hi all, I hope somebody can help me with something. We have a rather large number of netbooted nodes that we are running puppet apply via a script and a cron job every 30 minutes I was wondering if there is a way to configure puppet apply, to also send any reports to our dashboard server that is being used for our normal puppet clients and what would be the way to go about doing this? Currently run script runs something like this : puppet apply --config=$PUP/puppet.conf --detailed-exitcodes --onetime --no-daemonize $PUP/manifests/site.pp I suppose that the reason you are using puppet apply (for which some of those options are irrelevant) instead of puppet agent is that the nodes in question are not registered with the master (and you want it that way) or they cannot reliably contact the master. That's fine, but why, in that case, do you think that the master could or should accept reports from those nodes? John -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet apply and send reports?
Hi all, I hope somebody can help me with something. We have a rather large number of netbooted nodes that we are running puppet apply via a script and a cron job every 30 minutes I was wondering if there is a way to configure puppet apply, to also send any reports to our dashboard server that is being used for our normal puppet clients and what would be the way to go about doing this? Currently run script runs something like this : puppet apply --config=$PUP/puppet.conf --detailed-exitcodes --onetime --no-daemonize $PUP/manifests/site.pp -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Dashboard with RackbaseURI / and RailsAutoDetect off
Has anyone ever got this right before? -- 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/-/DiGW9XkhIF4J. 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.
