Re: [Puppet Users] time issue with puppet
On Wed, Dec 14, 2011 at 16:00, Corey Osman wrote: > I have the following manifest that basically syncs the time for nodes really > out of sync and ntpd can't drift the time back fast enough. > > The problem is that when puppet executes the catalog, and puppet changes the > time, puppet never finishes because it can't calculate the "run time" since > puppet changed the time during the puppet run. > > Is this a bug? Should I do something different? Wow. Personally, I used custom logic from cron, and at boot, so that having Puppet broken because SSL is time sensitive and can have ... headaches if it is too far out of sync, but there is no theoretical reason that can't work. You might want to consider using an exec with an `unless` or `onlyif` clause so that the check and sync are both local to the client instead of using a fact that requires the server to sign-off. That means that the default of using the cached catalog on failure will fix time sync that breaks SSL. Fundamentally, though, changing time like that should not break a Puppet run, full stop. We should cope, and carry on, regardless of what happens to the clock. (Reporting bogus timing data? Don't really mind that so much. :) So, yeah, please turn this into a bug report. We should totally fix that up some time. (haha) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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] time issue with puppet
Hi,
I have the following manifest that basically syncs the time for nodes really
out of sync and ntpd can't drift the time back fast enough.
The problem is that when puppet executes the catalog, and puppet changes the
time, puppet never finishes because it can't calculate the "run time" since
puppet changed the time during the puppet run.
Is this a bug? Should I do something different?
For example:
1. puppet starts at 3:53 pm
2. tmesync module alters the time accordingly back 10 minutes to 3:43
3. puppet is done, but never reports that it finished and appears hung since it
probably cant output a negative number anyways.
4. a restart of puppet seems to fix the issue until the time changes again.
# Class: timesync
#
# This module is a bandaid to keep virtual machines in sync with the time
server.
# This will basically sync the time whenver the time drifts out further than xx
seconds.
#
# Parameters:
#
# Actions: syncs the time with the timeserver
#
# Requires: timeoffset fact (esentially ntpdate -q ntpserver)
#
# Sample Usage:
#
class timesync {
# time in seconds that the clock needs to be out of sync before calling
ntpdate
$seconds=60
$timeserver="0.pool.ntp.org"
# only run max of six times per day
schedule { timecheck:
period => daily,
repeat => 6,
}
# only execute if time is out of sync by specified seconds
if ( $timeoffset > $seconds ){
exec{"synctime":
path => ["/bin", "/usr/bin/", "/sbin", "/usr/sbin/"],
# schedule => timecheck,
command => "ntpdate $timeserver",
}
alert("Puppet had to sync the time as it was out of sync")
}
}
Corey Osman
co...@logicminds.biz
Green I.T and Datacenter Automation Specialist
--
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: lookup $confdir within a function
Should have looked at this more closely before posting... :)
Obvious Answer after looking at the code: confdir =
Puppet.settings.value('confdir')
On Dec 14, 4:12 pm, nothings_absolute wrote:
> I will try to make this short... I need to determine what the absolute
> path is to the module base directory from within a function. So far I
> have found that I can use the following to get part of it:
>
> env = lookupvar('environment').to_sym
> env_path = Puppet.settings.instance_variable_get(:@values)[env]
> [:modulepath].split(":")
>
> This results in "$confdir//modules", but I haven't been
> able to find any way to look up what "$confdir" is. Does anyone know
> of a way to look this up from within a function? It doesn't appear to
> be accessible as a variable using lookupvar.
>
> Thank
--
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] lookup $confdir within a function
I will try to make this short... I need to determine what the absolute
path is to the module base directory from within a function. So far I
have found that I can use the following to get part of it:
env = lookupvar('environment').to_sym
env_path = Puppet.settings.instance_variable_get(:@values)[env]
[:modulepath].split(":")
This results in "$confdir//modules", but I haven't been
able to find any way to look up what "$confdir" is. Does anyone know
of a way to look this up from within a function? It doesn't appear to
be accessible as a variable using lookupvar.
Thank
--
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] restarting "service" when configuration changes
Try
notify => Service['autofs']
On Dec 14, 2011, at 5:35 AM, Sans wrote:
> I know it has been discussed several time and "notify" is the "magic
> word" to use here but it's not working here; my case is a bit
> different. This is what I have:
>
> ***
> define line_check($fname, $line, $bool = 'false') {
>
>exec { "/bin/echo '${line}' >> '${fname}'":
>unless=> "/bin/grep -q '^$line' '$fname'",
>refreshonly => "$bool";
>}
> }
>
> class zmfs::config {
>
>zmfs::defined::line_check {'auto.master':
>fname => '/etc/auto.master',
>line => '/zmfs /etc/auto.zmfs',
>notify=> Class['zmfs::service'];
>}
> }
>
> class zmfs::service {
>service { 'autofs':
>enable => true,
>ensure => running,
>hasstatus => true,
>hasrestart => true,
>status => 'service zmfs probe',
>require => Package['zmfs','zmfs-init-scripts'];
>}
> }
> ***
>
> So, I'm expecting, whenever "/etc/auto.master" is modified, autofs
> service will be restarted but that's not case I see here. What am I
> missing?
>
> Another question: Can I just do "service { 'autofs':" or "service
> { 'nfs':" (or any given standard unix/linux service) just like that?
> I'm wondering if that part is being completely ignored.
>
> Cheers,
> San
>
> --
> 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.
>
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and other
randomness
--
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: new user: need Conditional statement example within a file resource type
On Dec 13, 12:31 pm, Kenneth Lo wrote:
> Searching old archive I find this topic:
>
> http://groups.google.com/group/puppet-users/browse_thread/thread/187e...
>
> I understand that "case statements must be outside of resource
> statements" per that discussion and I understand the usage for the
> selector in-statement solution, however that's just for assignment
> though.
You seem to have a misapprehension here. See below.
> Consider this simple file resource, I just want to have a external
> variable that control whether I need the file in the system:
>
> file { "somefile" :
>
> case ${hasfile} {
> "true": { ensure => present }
> default: { ensure => absent }
> }
> source => "puppet:///somefile",
> owner => "root",
> .
> .
> .
>
> }
>
> Obviously I had a syntax error here because case statement is not
> happy within the resource.
I would write it using a selector, like this:
file { "somefile" :
ensure => ${hasfile} ? {
'true' => present,
default => absent
},
source => "puppet:///somefile",
owner => "root",
}
Others' examples of using an 'if' statement outside the resource are
also fine, but where the desired conditional effect is so localized, I
prefer to localize the conditional itself.
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-dev] Puppet integration with SecretServer (Thycotic)
On Mon, Dec 12, 2011 at 18:47, Steve Shipway wrote:
G'day Steve.
> I've done some more development on my Puppet module that handles password
> integration with Secret Server from Thycotic, and now it handles
> certificates as well.
That is pretty darn awesome - lots of people out there want some sort
of solution to this, and when I looked the Thycotic solution seemed
pretty solid. Does this work with the hosted service as well as the
in-house service?
(Not that I can imagine ever using the hosted service, but it might
make sense in some folks threat models. ;)
> This allows you to have a 'password' define that ensures the password is
> stored in SecretServer, and changes it on a regular basis:
>
> password { 'root': maxage=>60; }
> password { 'oracle': }
>
> Also now you can manage certificates, and it will install and update them:
>
> ssl::cert { $fqdn: }
> ssl::cert { 'foo.company.com': key=>'/usr/local/ssl/foo.key',
> crt=>'/usr/local/ssl/foo.crt'; }
>
> The module will retrieve the certificate and key from SecretServer, then
> optionally restart Apache after installing them. You can override this
> behaviour, or specify a different location for the files than the default of
> /etc/httpd/conf.
> It can also work from files instead of secretserver if necessary.
That looks pretty reasonable, but there are a couple of points that I
wondered at - and so, I wanted to take a look at the code and help
this be absolutely awesome!
> If anyone would like a copy, let me know.
Do you have the code in GitHub or somewhere like that, where I can have a look?
Is this the best email address to send any suggestions about improvements?
Would you accept pull requests or whatever?
Again, this looks absolutely awesome, and I would love to make it
something that everyone wanted to use.
Daniel
--
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons
--
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] restarting "service" when configuration changes
You should see the refreshonly parameter in exec resource type from
http://docs.puppetlabs.com/references/stable/type.html#exec
There is also an example with subscribe (instead of notify) which i think
you can solve your problem using that example.
bekir
On Wed, Dec 14, 2011 at 15:35, Sans wrote:
> I know it has been discussed several time and "notify" is the "magic
> word" to use here but it's not working here; my case is a bit
> different. This is what I have:
>
> ***
> define line_check($fname, $line, $bool = 'false') {
>
>exec { "/bin/echo '${line}' >> '${fname}'":
>unless=> "/bin/grep -q '^$line' '$fname'",
>refreshonly => "$bool";
>}
> }
>
> class zmfs::config {
>
>zmfs::defined::line_check {'auto.master':
>fname => '/etc/auto.master',
>line => '/zmfs /etc/auto.zmfs',
>notify=> Class['zmfs::service'];
>}
> }
>
> class zmfs::service {
>service { 'autofs':
>enable => true,
>ensure => running,
>hasstatus => true,
>hasrestart => true,
>status => 'service zmfs probe',
>require => Package['zmfs','zmfs-init-scripts'];
>}
> }
> ***
>
> So, I'm expecting, whenever "/etc/auto.master" is modified, autofs
> service will be restarted but that's not case I see here. What am I
> missing?
>
> Another question: Can I just do "service { 'autofs':" or "service
> { 'nfs':" (or any given standard unix/linux service) just like that?
> I'm wondering if that part is being completely ignored.
>
> Cheers,
> San
>
> --
> 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] Ruby error when running puppet agent on host
Hi. We have started to receive some strange errors when running puppet agent on some hosts in our datacenter. We have about 500 clients and there are about 30 that gives us this error: /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:53:in `handle_serve': uninitialized constant Puppet::Network::Handler (NameError) from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:329:in `send' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:329:in `parse_options' from /usr/lib/ruby/1.8/optparse.rb:1247:in `call' from /usr/lib/ruby/1.8/optparse.rb:1247:in `order!' from /usr/lib/ruby/1.8/optparse.rb:1205:in `catch' from /usr/lib/ruby/1.8/optparse.rb:1205:in `order!' from /usr/lib/ruby/1.8/optparse.rb:1279:in `permute!' from /usr/lib/ruby/1.8/optparse.rb:1300:in `parse!' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:335:in `parse_options' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:284:in `run' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:393:in `exit_on_fail' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:284:in `run' from /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:55:in `execute' from /usr/bin/puppet:4 It has worked before and there has not been any change to the system configuration. This affects both Suse and Redhat servers. I have reinstalled the ruby dependencies and puppet but the error still persists. When checking the logs it says that the service has been executed and i can see that the files and configuration has been applied. *puppet-agent[7067]: Finished catalog run in 1.11 seconds * *puppet agent --version* 2.6.4 * ruby-libs-1.8.5-5.el5_4.8 ruby-1.8.5-5.el5_4.8 puppetmasterd --version* 2.6.4 Any clues what might be the problem? Regards Richard. -- 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 Dashboard or Forman on SLES?
Hi,
thx this package could be installed on SLES.
I tried to use this guide
http://docs.puppetlabs.com/guides/installing_dashboard.html
Setup a MySQL database server, create a user and database for use with
the Dashboard by either:
1.
Using a rake task to create just the database from settings in
the
config/database.yml file. You must cd into the directory with the
Puppet
Dashboard software containing this README.markdown file before running
these commands:
But after this point i get this error message:
rake RAILS_ENV=production db:create --trace
rake aborted!
no such file to load -- spec/rake/spectask
/usr/lib64/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:29:in
`gem_original_require'
/usr/lib64/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:29:in
`require'
/usr/share/puppet-dashboard/vendor/gems/haml-3.1.2/vendor/sass/vendor/
fssm/Rakefile:20
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/rake_module.rb:
25:in
`load'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/rake_module.rb:
25:in
`load_rakefile'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
501:in `raw_load_rakefile'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
82:in
`load_rakefile'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
133:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
81:in
`load_rakefile'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
65:in
`run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
133:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:
63:in
`run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.9.2.2/bin/rake:33
/usr/bin/rake:19:in `load'
/usr/bin/rake:19
I searched in Google but the solution "you need to install the rspec
gem" don't resolve my problem.
Best regards
Benjamin
On 11 Dez., 14:30, Darin Perusich wrote:
> Mike,
>
> I'd recommend pulling down the SRPM from the Open(SuSE) Build Service if
> you're thinking about at building packages for SuSE. Ben has put a lot of
> work and effort into packaging for Puppet and the dashboard on SuSE
> systems. We've SuSE'fied the init scripts, added them for the dashboard
> worker processes, etc. Also using the magic of the build service it's
> trivial to build the packages for other distributions.
>
> http://download.opensuse.org/repositories/home:/eclipseagent:/puppet/...https://build.opensuse.org/package/show?package=puppet-dashboard&proj...
>
> --
> Later,
> Darin
>
> On Fri, Dec 9, 2011 at 10:18 PM, Michael Stahnke
> wrote:
>
> > Thanks. I'll tackle this next week.
>
> > Mike
>
> > On Fri, Dec 9, 2011 at 2:42 PM, Jeffrey Watts
> > wrote:
> > > Here you go:
>
> > > $ diff puppet-dashboard.spec puppet-dashboard.spec-sles
> > > 2c2
> > > < %global initrddir /etc/rc.d/init.d
> > > ---
> > >> %global initrddir /etc/init.d
> > > 9c9
> > > < Release: 1%{?dist}
> > > ---
> > >> Release: 2%{?dist}
> > > 17,18c17,18
> > > < Requires: ruby(abi) = 1.8, rubygems, ruby-mysql
> > > < Requires: ruby > 1.8.7, rubygem(rake)
> > > ---
> > >> Requires: rubygems, ruby-mysql
> > >> Requires: ruby > 1.8.7, rubygem-rake
> > > 22,25d21
> > > < Requires(post): chkconfig
> > > < Requires(preun): chkconfig
> > > < Requires(preun): initscripts
> > > < Requires(postun): initscripts
> > > 137a134,136
> > >> * Wed Dec 07 2011 Jeffrey Watts - 1.2.3-2
> > >> - Modified it to work on SLES
>
> > > Jeffrey.
>
> > > On Fri, Dec 9, 2011 at 3:35 PM, Michael Stahnke <
> > stah...@fedoraproject.org>
> > > wrote:
>
> > >> If somebody has a spec file that is working pretty well for SLES and/or
> > >> OpenSUSE we'd be glad to look at it and potentially host packages for
> > it.
> > >> It's on the list of things to do, it just hasn't made it to the top yet.
>
> > >> Mike
>
> > > --
> > > 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/grou
Re: [Puppet Users] Re: new user: need Conditional statement example within a file resource type
It's to be future proof, you can read about @ http://docs.puppetlabs.com/guides/scope_and_puppet.html Stefan -- 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/-/ZZfr1sZfo7cJ. 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: new user: need Conditional statement example within a file resource type
right, the reason I did not opt for this syntax is because my file
resource is actually quite large, and I think the other method Stefan
suggested has better readability.
On Wed, Dec 14, 2011 at 7:34 AM, Felix Frank
wrote:
> This should also work:
>
> file { "somefile": source => ..., owner => ... }
>
> if $::hasfile {
> File["somefile"] { ensure => present }
> }
> else {
> File["somefile"] { ensure => absent }
> }
>
> It's up to you to decide which is more obscure.
>
> Cheers,
> Felix
>
> --
> 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: new user: need Conditional statement example within a file resource type
This works. thx!
Another rookie question, what is the :: in front of the variable name
signify in general?
--KL
On Tue, Dec 13, 2011 at 3:37 PM, Stefan Heijmans
wrote:
> How about something like;
>
>
> $hasfile = true
> if $::hasfile {
> $fileensure = 'present'
> }
> else {
> $fileensure = 'absent'
> }
>
> file { "somefile" :
>
> ensure => $::fileensure,
> source => "puppet:///somefile",
> owner => "root",
> .
> .
> .
> }
>
> --
> 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/-/CWF3DekKQwAJ.
>
> 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] Is it possible to chain events from an Exec?
Hi Edd,
On 14.12.2011, at 13:27, Edd Grant wrote:
> Hi Martin,
>
> I have swapped all the subscribes out for requires as per your
> suggestion but copy_archive_$name still runs every time. Any ideas?
The exec check_unpacked_archive_exists_$name is parsed and validated on every
run.
I see two possibilities:
1. make the exec fail if the directory exists.
e.g. command => "/bin/test ! -d $targetDir && mkdir $targetDir"
But: This will put an error in every puppet report.
2. do not remove the archive or touch a file with the same name.
e.g.
command => "/bin/rm -f $targetDir/$archiveName && /usr/bin/touch
$targetDir/$archiveName",
this will work, because the file resource has replace => false.
>
> Code below:
>
> define archive::unpack($archiveName,
> $appName,
> $archiveDir,
> $targetDir,
> $pathFolder,
> $owner = "root",
> $group = "root",
> $mode = "644") {
>
> #Set the extraction command appropriately based on the archive type.
> $command = $archiveName ? {
>/(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf $targetDir/
> $archiveName",
>/(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
>/^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
>default => "Error: Could not detect archive type from archive name
> ($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
> }
>
> exec { "check_unpacked_archive_exists_$name":
>command => "/bin/echo '$targetDir/$appName does not exist, it will
> be created.'",
>cwd => $targetDir,
>creates => "$targetDir/$appName",
>onlyif => "/usr/bin/test ! -d $targetDir/$appName",
>logoutput => true,
> }
>
> # copy file from puppet master to local system
> file { "copy_archive_$name":
>path => "$targetDir/$archiveName",
>source => "$archiveDir/$archiveName",
>replace => false,
>require => Exec["check_unpacked_archive_exists_$name"],
> }
>
> # extract local file
> exec { "unpack_archive_$name":
>command => $command,
>cwd => $targetDir,
>creates => "$targetDir/$appName",
>logoutput => true,
>require => File["copy_archive_$name"],
> }
>
> # delete copied archive
> exec { "delete_copied_archive_$name":
>command => "/bin/rm -f $targetDir/$archiveName",
>cwd => "$targetDir",
>logoutput => true,
>require => Exec["unpack_archive_$name"],
> }
> }
>
>
>
>
> On Dec 14, 11:20 am, Martin Alfke wrote:
>> Edd,
>>
>> On 14.12.2011, at 11:54, Edd Grant wrote:
>>
>>> Martin,
>>
>>> r.e. your comment: "The command will only get executed in case that
>>> $targeDir/$appName does not exists. The command will always return
>>> 0 !!" can I ask what you were referring to here? was it the exec
>>> "check_unpacked_archive_exists_$name"? I tested the statement in the
>>> onlyif and that definitely returns 0 when the directory is absent and
>>> 1 when the directory is present. I'm not quite sure what to do here to
>>> correct this?
>>
>> I was referring to exec "check_unpacked_archive_exists_$name"
>> I only wanted to make clear that the command always returns exitcode 0.
>> Nothing wrong here.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Cheers,
>>
>>> Edd
>>
>>> On Dec 14, 10:18 am, Edd Grant wrote:
Wow - thanks for the super quick reply Martin. Will try out your
suggestions.
>>
Cheers,
>>
Edd
>>
On Dec 14, 10:16 am, Martin Alfke wrote:
>>
> Hi,
>>
> my answer is inline..
>>
> On 14.12.2011, at 11:09, Edd Grant wrote:
>>
>> Hi All,
>>
>> I'm trying to write a module which unpacks an archive to a specified
>> location, the idea is as follows:
>>
>> Let's say I'm trying to deploy an archive of grails-1.3.7
>> Check that a directory exists at $targetDir/grails-1.3.7
>> If it does, do nothing
>> If it doesn't then do the following...
>> Copy grails-1.3.7.zip from the module source to $targetDir
>> Unpack to $targetDir/grails-1.3.7
>> Delete the archive so we don't end up with mess in our directories
>> I have this mostly working, i.e. the code below performs all of the
>> steps above successfully, but for some reason I cannot stop steps 4 and
>> onwards from happening every time Puppet applies the manifests,
>> irrespective of whether the $targetDir/grails-1.3.7 directory already
>> exists.
>>
>> Here's the code
>> Module code: modules/archive/unpack.pp
>>
>> define archive::unpack($archiveName,
>> $appName,
>> $archiveDir,
>> $targetDir,
>> $pathFolder,
>> $owner = "root",
>> $group = "root",
>> $mode = "644") {
>>
>> #Set the
Re: [Puppet Users] Is it possible to chain events from an Exec?
On 12/14/2011 11:16 AM, Martin Alfke wrote:
> Here you subscribe to the exec resource.
> Exec resource will get parsed but the command will not run
> What you want is
> require => Exec[...]
No.
Subscribe creates a notification for the subscribing resource if the
subscribed resource needs a change, e.g. an exec is run. However, file
resources are *always* evaluated, whether notified or not.
The only way to do what the OP wants is to use 'exec { "cp ...":
refreshonly => true }' instead of file { }. Exec is one of the few types
that can be controlled with subscriptions/notifications.
However, that would be poor design.
I'd suggest writing a simple wrapper script to do all that needs doing
and have exec {} call that script instead.
Failing that, put all your commands in variables and exec { "$cmd1 &&
$cmd2 && $cmd3 ...": ... }.
But that's no quite best practice, either.
HTH,
Felix
--
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: User management
On Dec 14, 1:09 am, Marek Dohojda wrote:
> I am wondering what would be a good way of managing users. I need to add
> user to some host and ensure that they are absent on another box. so for
> instance, I want Bob to be present on server A but absent on server B. as
> far as I know, you can only have one defined object. so I could have Bob
> either set to ensure present or ensure absent.
No node may declare duplicate resources, but that does not mean your
overall manifest set cannot do so.
> Is there a way to have users be in two different classes?
Absolutely:
class users::serverA {
user { 'bob': ensure => 'present' }
}
class users::serverB {
user { 'bob': ensure => 'absent' }
}
Nodes may include at most one of those two classes, but there is no
problem with both being available.
There are several other ways to approach the problem as well.
Depending on the circumstances, I might look to a data-driven approach
based involving the create_resources() function, for instance.
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] restarting "service" when configuration changes
I know it has been discussed several time and "notify" is the "magic
word" to use here but it's not working here; my case is a bit
different. This is what I have:
***
define line_check($fname, $line, $bool = 'false') {
exec { "/bin/echo '${line}' >> '${fname}'":
unless=> "/bin/grep -q '^$line' '$fname'",
refreshonly => "$bool";
}
}
class zmfs::config {
zmfs::defined::line_check {'auto.master':
fname => '/etc/auto.master',
line => '/zmfs /etc/auto.zmfs',
notify=> Class['zmfs::service'];
}
}
class zmfs::service {
service { 'autofs':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
status => 'service zmfs probe',
require => Package['zmfs','zmfs-init-scripts'];
}
}
***
So, I'm expecting, whenever "/etc/auto.master" is modified, autofs
service will be restarted but that's not case I see here. What am I
missing?
Another question: Can I just do "service { 'autofs':" or "service
{ 'nfs':" (or any given standard unix/linux service) just like that?
I'm wondering if that part is being completely ignored.
Cheers,
San
--
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] Using an array to manage a string of directories that need to be managed
Hi,
On 12/13/2011 11:25 PM, Forrie wrote:
> I thought I could just create a simple array and then use a file {}
> statement to ensure they are created. Seems simple enough. Some
> don't feel that's the most efficient way.
>
> Since I'm going to be using autofs to ensure the mounts exist, I
> suppose I could craft a template which could make use of this array
> and then ship out the autofs configuration to each system, as a
> dependency.
this sounds pretty good to me.
Cheers,
Felix
--
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: new user: need Conditional statement example within a file resource type
This should also work:
file { "somefile": source => ..., owner => ... }
if $::hasfile {
File["somefile"] { ensure => present }
}
else {
File["somefile"] { ensure => absent }
}
It's up to you to decide which is more obscure.
Cheers,
Felix
--
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] uppet and ruby 1.9
Are there still any known issues with puppet and ruby 1.9? Or 1.8.7 is still the preferred version to use with puppet? latest 2.7 is imho fully supported by 1.9 ~pete -- 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: Is it possible to chain events from an Exec?
Hi Martin,
I have swapped all the subscribes out for requires as per your
suggestion but copy_archive_$name still runs every time. Any ideas?
Code below:
define archive::unpack($archiveName,
$appName,
$archiveDir,
$targetDir,
$pathFolder,
$owner = "root",
$group = "root",
$mode = "644") {
#Set the extraction command appropriately based on the archive type.
$command = $archiveName ? {
/(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf $targetDir/
$archiveName",
/(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
/^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
default => "Error: Could not detect archive type from archive name
($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
}
exec { "check_unpacked_archive_exists_$name":
command => "/bin/echo '$targetDir/$appName does not exist, it will
be created.'",
cwd => $targetDir,
creates => "$targetDir/$appName",
onlyif => "/usr/bin/test ! -d $targetDir/$appName",
logoutput => true,
}
# copy file from puppet master to local system
file { "copy_archive_$name":
path => "$targetDir/$archiveName",
source => "$archiveDir/$archiveName",
replace => false,
require => Exec["check_unpacked_archive_exists_$name"],
}
# extract local file
exec { "unpack_archive_$name":
command => $command,
cwd => $targetDir,
creates => "$targetDir/$appName",
logoutput => true,
require => File["copy_archive_$name"],
}
# delete copied archive
exec { "delete_copied_archive_$name":
command => "/bin/rm -f $targetDir/$archiveName",
cwd => "$targetDir",
logoutput => true,
require => Exec["unpack_archive_$name"],
}
}
On Dec 14, 11:20 am, Martin Alfke wrote:
> Edd,
>
> On 14.12.2011, at 11:54, Edd Grant wrote:
>
> > Martin,
>
> > r.e. your comment: "The command will only get executed in case that
> > $targeDir/$appName does not exists. The command will always return
> > 0 !!" can I ask what you were referring to here? was it the exec
> > "check_unpacked_archive_exists_$name"? I tested the statement in the
> > onlyif and that definitely returns 0 when the directory is absent and
> > 1 when the directory is present. I'm not quite sure what to do here to
> > correct this?
>
> I was referring to exec "check_unpacked_archive_exists_$name"
> I only wanted to make clear that the command always returns exitcode 0.
> Nothing wrong here.
>
>
>
>
>
>
>
>
>
> > Cheers,
>
> > Edd
>
> > On Dec 14, 10:18 am, Edd Grant wrote:
> >> Wow - thanks for the super quick reply Martin. Will try out your
> >> suggestions.
>
> >> Cheers,
>
> >> Edd
>
> >> On Dec 14, 10:16 am, Martin Alfke wrote:
>
> >>> Hi,
>
> >>> my answer is inline..
>
> >>> On 14.12.2011, at 11:09, Edd Grant wrote:
>
> Hi All,
>
> I'm trying to write a module which unpacks an archive to a specified
> location, the idea is as follows:
>
> Let's say I'm trying to deploy an archive of grails-1.3.7
> Check that a directory exists at $targetDir/grails-1.3.7
> If it does, do nothing
> If it doesn't then do the following...
> Copy grails-1.3.7.zip from the module source to $targetDir
> Unpack to $targetDir/grails-1.3.7
> Delete the archive so we don't end up with mess in our directories
> I have this mostly working, i.e. the code below performs all of the
> steps above successfully, but for some reason I cannot stop steps 4 and
> onwards from happening every time Puppet applies the manifests,
> irrespective of whether the $targetDir/grails-1.3.7 directory already
> exists.
>
> Here's the code
> Module code: modules/archive/unpack.pp
>
> define archive::unpack($archiveName,
> $appName,
> $archiveDir,
> $targetDir,
> $pathFolder,
> $owner = "root",
> $group = "root",
> $mode = "644") {
>
> #Set the extraction command appropriately based on the archive type.
> $command = $archiveName ? {
> /(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf
> $targetDir/$archiveName",
> /(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
> /^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
> default => "Error: Could not detect archive type from archive name
> ($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
> }
>
> # Check if the unpacked archive directory exists
> # the idea here was to have all subsequent actions
> # subscribe to the outcome of this check so that the archive
> # would only be cop
Re: [Puppet Users] Re: Is it possible to chain events from an Exec?
Edd,
On 14.12.2011, at 11:54, Edd Grant wrote:
> Martin,
>
> r.e. your comment: "The command will only get executed in case that
> $targeDir/$appName does not exists. The command will always return
> 0 !!" can I ask what you were referring to here? was it the exec
> "check_unpacked_archive_exists_$name"? I tested the statement in the
> onlyif and that definitely returns 0 when the directory is absent and
> 1 when the directory is present. I'm not quite sure what to do here to
> correct this?
I was referring to exec "check_unpacked_archive_exists_$name"
I only wanted to make clear that the command always returns exitcode 0.
Nothing wrong here.
>
> Cheers,
>
> Edd
>
>
>
> On Dec 14, 10:18 am, Edd Grant wrote:
>> Wow - thanks for the super quick reply Martin. Will try out your
>> suggestions.
>>
>> Cheers,
>>
>> Edd
>>
>> On Dec 14, 10:16 am, Martin Alfke wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Hi,
>>
>>> my answer is inline..
>>
>>> On 14.12.2011, at 11:09, Edd Grant wrote:
>>
Hi All,
>>
I'm trying to write a module which unpacks an archive to a specified
location, the idea is as follows:
>>
Let's say I'm trying to deploy an archive of grails-1.3.7
Check that a directory exists at $targetDir/grails-1.3.7
If it does, do nothing
If it doesn't then do the following...
Copy grails-1.3.7.zip from the module source to $targetDir
Unpack to $targetDir/grails-1.3.7
Delete the archive so we don't end up with mess in our directories
I have this mostly working, i.e. the code below performs all of the steps
above successfully, but for some reason I cannot stop steps 4 and onwards
from happening every time Puppet applies the manifests, irrespective of
whether the $targetDir/grails-1.3.7 directory already exists.
>>
Here's the code
Module code: modules/archive/unpack.pp
>>
define archive::unpack($archiveName,
$appName,
$archiveDir,
$targetDir,
$pathFolder,
$owner = "root",
$group = "root",
$mode = "644") {
>>
#Set the extraction command appropriately based on the archive type.
$command = $archiveName ? {
/(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf
$targetDir/$archiveName",
/(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
/^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
default => "Error: Could not detect archive type from archive name
($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
}
>>
# Check if the unpacked archive directory exists
# the idea here was to have all subsequent actions
# subscribe to the outcome of this check so that the archive
# would only be copied, unpacked, chowned and chmodded if
# the directory specified by this exec did not exist. This doesn't seem
# to work though since "copy_archive_$name" always seems to be invoked
# irrespective of the outcome of the onlyif condition in this exec.
exec { "check_unpacked_archive_exists_$name":
command => "/bin/echo '$targetDir/$appName does not exist, it will be
created.'",
cwd => $targetDir,
creates => "$targetDir/$appName",
onlyif => "/usr/bin/test ! -d $targetDir/$appName",
logoutput => true,
}
>>
>>> The command will only get executed in case that $targeDir/$appName does not
>>> exists.
>>> The command will always return 0 !!
>>
# copy file from puppet master to local system
file { "copy_archive_$name":
path => "$targetDir/$archiveName",
source => "$archiveDir/$archiveName",
replace => false,
subscribe => Exec["check_unpacked_archive_exists_$name"],
}
>>
>>> Here you subscribe to the exec resource.
>>> Exec resource will get parsed but the command will not run
>>> What you want is
>>> require => Exec[...]
>>
>>> Using require instead of subscribe will make sure that the file resource
>>> will only be done if the exec resource command is executed.
>>
# extract local file
exec { "unpack_archive_$name":
command => $command,
cwd => $targetDir,
creates => "$targetDir/$appName",
refreshonly => true,
logoutput => true,
subscribe => File["copy_archive_$name"],
}
>>
>>> Same here: use require instead of subscribe.
>>
# delete copied archive
exec { "delete_copied_archive_$name":
command => "/bin/rm -f $targetDir/$archiveName",
cwd => "$targetDir",
subscribe => Exec["unpack_archive_$name"],
logoutput => true,
}
}
>>
>>> Same here.
>>
>>> Kind regards,
>>
>>> Martin
>>
[Puppet Users] Re: Is it possible to chain events from an Exec?
Martin,
r.e. your comment: "The command will only get executed in case that
$targeDir/$appName does not exists. The command will always return
0 !!" can I ask what you were referring to here? was it the exec
"check_unpacked_archive_exists_$name"? I tested the statement in the
onlyif and that definitely returns 0 when the directory is absent and
1 when the directory is present. I'm not quite sure what to do here to
correct this?
Cheers,
Edd
On Dec 14, 10:18 am, Edd Grant wrote:
> Wow - thanks for the super quick reply Martin. Will try out your
> suggestions.
>
> Cheers,
>
> Edd
>
> On Dec 14, 10:16 am, Martin Alfke wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > my answer is inline..
>
> > On 14.12.2011, at 11:09, Edd Grant wrote:
>
> > > Hi All,
>
> > > I'm trying to write a module which unpacks an archive to a specified
> > > location, the idea is as follows:
>
> > > Let's say I'm trying to deploy an archive of grails-1.3.7
> > > Check that a directory exists at $targetDir/grails-1.3.7
> > > If it does, do nothing
> > > If it doesn't then do the following...
> > > Copy grails-1.3.7.zip from the module source to $targetDir
> > > Unpack to $targetDir/grails-1.3.7
> > > Delete the archive so we don't end up with mess in our directories
> > > I have this mostly working, i.e. the code below performs all of the steps
> > > above successfully, but for some reason I cannot stop steps 4 and onwards
> > > from happening every time Puppet applies the manifests, irrespective of
> > > whether the $targetDir/grails-1.3.7 directory already exists.
>
> > > Here's the code
> > > Module code: modules/archive/unpack.pp
>
> > > define archive::unpack($archiveName,
> > > $appName,
> > > $archiveDir,
> > > $targetDir,
> > > $pathFolder,
> > > $owner = "root",
> > > $group = "root",
> > > $mode = "644") {
>
> > > #Set the extraction command appropriately based on the archive type.
> > > $command = $archiveName ? {
> > > /(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf
> > > $targetDir/$archiveName",
> > > /(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
> > > /^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
> > > default => "Error: Could not detect archive type from archive name
> > > ($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
> > > }
>
> > > # Check if the unpacked archive directory exists
> > > # the idea here was to have all subsequent actions
> > > # subscribe to the outcome of this check so that the archive
> > > # would only be copied, unpacked, chowned and chmodded if
> > > # the directory specified by this exec did not exist. This doesn't seem
> > > # to work though since "copy_archive_$name" always seems to be invoked
> > > # irrespective of the outcome of the onlyif condition in this exec.
> > > exec { "check_unpacked_archive_exists_$name":
> > > command => "/bin/echo '$targetDir/$appName does not exist, it will be
> > > created.'",
> > > cwd => $targetDir,
> > > creates => "$targetDir/$appName",
> > > onlyif => "/usr/bin/test ! -d $targetDir/$appName",
> > > logoutput => true,
> > > }
>
> > The command will only get executed in case that $targeDir/$appName does not
> > exists.
> > The command will always return 0 !!
>
> > > # copy file from puppet master to local system
> > > file { "copy_archive_$name":
> > > path => "$targetDir/$archiveName",
> > > source => "$archiveDir/$archiveName",
> > > replace => false,
> > > subscribe => Exec["check_unpacked_archive_exists_$name"],
> > > }
>
> > Here you subscribe to the exec resource.
> > Exec resource will get parsed but the command will not run
> > What you want is
> > require => Exec[...]
>
> > Using require instead of subscribe will make sure that the file resource
> > will only be done if the exec resource command is executed.
>
> > > # extract local file
> > > exec { "unpack_archive_$name":
> > > command => $command,
> > > cwd => $targetDir,
> > > creates => "$targetDir/$appName",
> > > refreshonly => true,
> > > logoutput => true,
> > > subscribe => File["copy_archive_$name"],
> > > }
>
> > Same here: use require instead of subscribe.
>
> > > # delete copied archive
> > > exec { "delete_copied_archive_$name":
> > > command => "/bin/rm -f $targetDir/$archiveName",
> > > cwd => "$targetDir",
> > > subscribe => Exec["unpack_archive_$name"],
> > > logoutput => true,
> > > }
> > > }
>
> > Same here.
>
> > Kind regards,
>
> > Martin
>
> > > Invocation code:
>
> > > class grails {
>
> > > $appName = "grails-2.0.0.M1"
> > > $archiveName = "$appName.zip"
> > > $archiveDir = "puppet:///modules/grails"
> > > $targetDir = "/usr/local/java"
> > > $pathFolder = "bin
[Puppet Users] Re: Is it possible to chain events from an Exec?
Wow - thanks for the super quick reply Martin. Will try out your
suggestions.
Cheers,
Edd
On Dec 14, 10:16 am, Martin Alfke wrote:
> Hi,
>
> my answer is inline..
>
> On 14.12.2011, at 11:09, Edd Grant wrote:
>
>
>
>
>
>
>
>
>
> > Hi All,
>
> > I'm trying to write a module which unpacks an archive to a specified
> > location, the idea is as follows:
>
> > Let's say I'm trying to deploy an archive of grails-1.3.7
> > Check that a directory exists at $targetDir/grails-1.3.7
> > If it does, do nothing
> > If it doesn't then do the following...
> > Copy grails-1.3.7.zip from the module source to $targetDir
> > Unpack to $targetDir/grails-1.3.7
> > Delete the archive so we don't end up with mess in our directories
> > I have this mostly working, i.e. the code below performs all of the steps
> > above successfully, but for some reason I cannot stop steps 4 and onwards
> > from happening every time Puppet applies the manifests, irrespective of
> > whether the $targetDir/grails-1.3.7 directory already exists.
>
> > Here's the code
> > Module code: modules/archive/unpack.pp
>
> > define archive::unpack($archiveName,
> > $appName,
> > $archiveDir,
> > $targetDir,
> > $pathFolder,
> > $owner = "root",
> > $group = "root",
> > $mode = "644") {
>
> > #Set the extraction command appropriately based on the archive type.
> > $command = $archiveName ? {
> > /(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf $targetDir/$archiveName",
> > /(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
> > /^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
> > default => "Error: Could not detect archive type from archive name
> > ($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
> > }
>
> > # Check if the unpacked archive directory exists
> > # the idea here was to have all subsequent actions
> > # subscribe to the outcome of this check so that the archive
> > # would only be copied, unpacked, chowned and chmodded if
> > # the directory specified by this exec did not exist. This doesn't seem
> > # to work though since "copy_archive_$name" always seems to be invoked
> > # irrespective of the outcome of the onlyif condition in this exec.
> > exec { "check_unpacked_archive_exists_$name":
> > command => "/bin/echo '$targetDir/$appName does not exist, it will be
> > created.'",
> > cwd => $targetDir,
> > creates => "$targetDir/$appName",
> > onlyif => "/usr/bin/test ! -d $targetDir/$appName",
> > logoutput => true,
> > }
>
> The command will only get executed in case that $targeDir/$appName does not
> exists.
> The command will always return 0 !!
>
>
>
> > # copy file from puppet master to local system
> > file { "copy_archive_$name":
> > path => "$targetDir/$archiveName",
> > source => "$archiveDir/$archiveName",
> > replace => false,
> > subscribe => Exec["check_unpacked_archive_exists_$name"],
> > }
>
> Here you subscribe to the exec resource.
> Exec resource will get parsed but the command will not run
> What you want is
> require => Exec[...]
>
> Using require instead of subscribe will make sure that the file resource will
> only be done if the exec resource command is executed.
>
>
>
> > # extract local file
> > exec { "unpack_archive_$name":
> > command => $command,
> > cwd => $targetDir,
> > creates => "$targetDir/$appName",
> > refreshonly => true,
> > logoutput => true,
> > subscribe => File["copy_archive_$name"],
> > }
>
> Same here: use require instead of subscribe.
>
>
>
> > # delete copied archive
> > exec { "delete_copied_archive_$name":
> > command => "/bin/rm -f $targetDir/$archiveName",
> > cwd => "$targetDir",
> > subscribe => Exec["unpack_archive_$name"],
> > logoutput => true,
> > }
> > }
>
> Same here.
>
> Kind regards,
>
> Martin
>
>
>
>
>
>
>
>
>
> > Invocation code:
>
> > class grails {
>
> > $appName = "grails-2.0.0.M1"
> > $archiveName = "$appName.zip"
> > $archiveDir = "puppet:///modules/grails"
> > $targetDir = "/usr/local/java"
> > $pathFolder = "bin"
> > $owner = root
> > $group = dev
> > $mode = 6775
>
> > archive::unpack { "install_$appName":
> > archiveName => $archiveName,
> > appName => $appName,
> > archiveDir => $archiveDir,
> > targetDir => $targetDir,
> > pathFolder => $pathFolder,
> > owner => $owner,
> > group => $group,
> > mode => $mode,
> > }
> > }
>
> > The frustrating thing is that the exec called
> > "check_unpacked_archive_exists_$name" is definitely only firing when it
> > finds the sought folder to be missing, which is what I want it to do. What
> > I don't understand is why the file called "copy_archive_$name" which
> > subscribes to tha
Re: [Puppet Users] Is it possible to chain events from an Exec?
Hi,
my answer is inline..
On 14.12.2011, at 11:09, Edd Grant wrote:
> Hi All,
>
> I'm trying to write a module which unpacks an archive to a specified
> location, the idea is as follows:
>
> Let's say I'm trying to deploy an archive of grails-1.3.7
> Check that a directory exists at $targetDir/grails-1.3.7
> If it does, do nothing
> If it doesn't then do the following...
> Copy grails-1.3.7.zip from the module source to $targetDir
> Unpack to $targetDir/grails-1.3.7
> Delete the archive so we don't end up with mess in our directories
> I have this mostly working, i.e. the code below performs all of the steps
> above successfully, but for some reason I cannot stop steps 4 and onwards
> from happening every time Puppet applies the manifests, irrespective of
> whether the $targetDir/grails-1.3.7 directory already exists.
>
> Here's the code
> Module code: modules/archive/unpack.pp
>
> define archive::unpack($archiveName,
> $appName,
> $archiveDir,
> $targetDir,
> $pathFolder,
> $owner = "root",
> $group = "root",
> $mode = "644") {
>
> #Set the extraction command appropriately based on the archive type.
> $command = $archiveName ? {
> /(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf $targetDir/$archiveName",
> /(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
> /^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
> default => "Error: Could not detect archive type from archive name
> ($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
> }
>
> # Check if the unpacked archive directory exists
> # the idea here was to have all subsequent actions
> # subscribe to the outcome of this check so that the archive
> # would only be copied, unpacked, chowned and chmodded if
> # the directory specified by this exec did not exist. This doesn't seem
> # to work though since "copy_archive_$name" always seems to be invoked
> # irrespective of the outcome of the onlyif condition in this exec.
> exec { "check_unpacked_archive_exists_$name":
> command => "/bin/echo '$targetDir/$appName does not exist, it will be
> created.'",
> cwd => $targetDir,
> creates => "$targetDir/$appName",
> onlyif => "/usr/bin/test ! -d $targetDir/$appName",
> logoutput => true,
> }
The command will only get executed in case that $targeDir/$appName does not
exists.
The command will always return 0 !!
>
> # copy file from puppet master to local system
> file { "copy_archive_$name":
> path => "$targetDir/$archiveName",
> source => "$archiveDir/$archiveName",
> replace => false,
> subscribe => Exec["check_unpacked_archive_exists_$name"],
> }
Here you subscribe to the exec resource.
Exec resource will get parsed but the command will not run
What you want is
require => Exec[...]
Using require instead of subscribe will make sure that the file resource will
only be done if the exec resource command is executed.
>
># extract local file
> exec { "unpack_archive_$name":
> command => $command,
> cwd => $targetDir,
> creates => "$targetDir/$appName",
> refreshonly => true,
> logoutput => true,
> subscribe => File["copy_archive_$name"],
> }
Same here: use require instead of subscribe.
>
> # delete copied archive
> exec { "delete_copied_archive_$name":
> command => "/bin/rm -f $targetDir/$archiveName",
> cwd => "$targetDir",
> subscribe => Exec["unpack_archive_$name"],
> logoutput => true,
> }
> }
Same here.
Kind regards,
Martin
>
> Invocation code:
>
> class grails {
>
> $appName = "grails-2.0.0.M1"
> $archiveName = "$appName.zip"
> $archiveDir = "puppet:///modules/grails"
> $targetDir = "/usr/local/java"
> $pathFolder = "bin"
> $owner = root
> $group = dev
> $mode = 6775
>
> archive::unpack { "install_$appName":
> archiveName => $archiveName,
> appName => $appName,
> archiveDir => $archiveDir,
> targetDir => $targetDir,
> pathFolder => $pathFolder,
> owner => $owner,
> group => $group,
> mode => $mode,
> }
> }
>
> The frustrating thing is that the exec called
> "check_unpacked_archive_exists_$name" is definitely only firing when it finds
> the sought folder to be missing, which is what I want it to do. What I don't
> understand is why the file called "copy_archive_$name" which subscribes to
> that exec gets fired everytime. I can't help but think that this would be
> made much much easier if only the file resource supported 'onlyif'... but
> while it doesn't does anyone have any insight as to why I'm seeing this issue?
>
> Cheers,
>
> Edd
>
> --
> Web: http://www.eddgrant.com
> Email: e...@eddgrant.com
> Mobile: +44 (0) 7861 394
[Puppet Users] Is it possible to chain events from an Exec?
Hi All,
I'm trying to write a module which unpacks an archive to a specified
location, the idea is as follows:
Let's say I'm trying to deploy an archive of grails-1.3.7
1. Check that a directory exists at $targetDir/grails-1.3.7
2. If it does, do nothing
3. If it doesn't then do the following...
4. Copy grails-1.3.7.zip from the module source to $targetDir
5. Unpack to $targetDir/grails-1.3.7
6. Delete the archive so we don't end up with mess in our directories
I have this *mostly* working, i.e. the code below performs all of the steps
above successfully, but for some reason I cannot stop steps 4 and onwards
from happening every time Puppet applies the manifests, irrespective of
whether the $targetDir/grails-1.3.7 directory already exists.
Here's the code
*Module code:* modules/archive/unpack.pp
define archive::unpack($archiveName,
$appName,
$archiveDir,
$targetDir,
$pathFolder,
$owner = "root",
$group = "root",
$mode = "644") {
#Set the extraction command appropriately based on the archive type.
$command = $archiveName ? {
/(^.*\.tar\.gz$)|(^.*\.tgz$)/ => "/bin/tar zxf $targetDir/$archiveName",
/(^.*\.tar$)/ => "/bin/tar xf $targetDir/$archiveName",
/^.*\.zip$/ => "/usr/bin/unzip $targetDir/$archiveName",
default => "Error: Could not detect archive type from archive name
($archiveName), cannot unpack. Supported types: .tar.gzip, .zip",
}
# Check if the unpacked archive directory exists
# the idea here was to have all subsequent actions
# subscribe to the outcome of this check so that the archive
# would only be copied, unpacked, chowned and chmodded if
# the directory specified by this exec did not exist. This doesn't seem
# to work though since "copy_archive_$name" always seems to be invoked
# irrespective of the outcome of the onlyif condition in this exec.
exec { "check_unpacked_archive_exists_$name":
command => "/bin/echo '$targetDir/$appName does not exist, it will be
created.'",
cwd => $targetDir,
creates => "$targetDir/$appName",
onlyif => "/usr/bin/test ! -d $targetDir/$appName",
logoutput => true,
}
# copy file from puppet master to local system
file { "copy_archive_$name":
path => "$targetDir/$archiveName",
source => "$archiveDir/$archiveName",
replace => false,
subscribe => Exec["check_unpacked_archive_exists_$name"],
}
# extract local file
exec { "unpack_archive_$name":
command => $command,
cwd => $targetDir,
creates => "$targetDir/$appName",
refreshonly => true,
logoutput => true,
subscribe => File["copy_archive_$name"],
}
# delete copied archive
exec { "delete_copied_archive_$name":
command => "/bin/rm -f $targetDir/$archiveName",
cwd => "$targetDir",
subscribe => Exec["unpack_archive_$name"],
logoutput => true,
}
}
*Invocation code:*
class grails {
$appName = "grails-2.0.0.M1"
$archiveName = "$appName.zip"
$archiveDir = "puppet:///modules/grails"
$targetDir = "/usr/local/java"
$pathFolder = "bin"
$owner = root
$group = dev
$mode = 6775
archive::unpack { "install_$appName":
archiveName => $archiveName,
appName => $appName,
archiveDir => $archiveDir,
targetDir => $targetDir,
pathFolder => $pathFolder,
owner => $owner,
group => $group,
mode => $mode,
}
}
The frustrating thing is that the exec called "*
check_unpacked_archive_exists_$name*" is definitely only firing when it
finds the sought folder to be missing, which is what I want it to do. What
I don't understand is why the file called "*copy_archive_$name*" which
subscribes to that exec gets fired everytime. I can't help but think that
this would be made much much easier if only the *file* resource supported '*
onlyif*'... but while it doesn't does anyone have any insight as to why I'm
seeing this issue?
Cheers,
Edd
--
Web: http://www.eddgrant.com
Email: e...@eddgrant.com
Mobile: +44 (0) 7861 394 543
--
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] User management
On 14 Dec 2011, at 07:10, Marek Dohojda wrote: > I am wondering what would be a good way of managing users. I need to add > user to some host and ensure that they are absent on another box. so for > instance, I want Bob to be present on server A but absent on server B. as > far as I know, you can only have one defined object. so I could have Bob > either set to ensure present or ensure absent. > Is there a way to have users be in two different classes? > > Thank you Virtual resources are what you're after: http://docs.puppetlabs.com/guides/virtual_resources.html Cheers, -- Richard Clark rich...@fohnet.co.uk -- 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.
