Re: [Puppet Users] Puppet Continuous Integration - your help needed

2010-02-12 Thread James Turnbull 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/02/10 11:28 AM, Aaron Lippold wrote:
> Hi James,
> 
> My team at DISA and the Forge.mil project is looking to setup a
> Puppet/Hudson/Cobbler driven setup for our CI. I was hoping you may
> have some pointers you would be willing to share.
> 

Hi - sure can - depends on what you need to know.  So feel free to
email me queries off-list.

I have also been meaning to put together some proper notes and a
modules for the Hudson set-up.  Teyo may already have done some of
this but if he hasn't I'll bump it up the priority list. :)

Regards

James

- -- 
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS3ZHMCFa/lDkFHAyAQIh6ggAqCxNylBH785SnCXe4n+iEJi5AKl3X0Lv
z47HZW0YIsCcE46bPTp77VrhAaLFgLM/ewNUIGVNbnE/UoDPIKyrpLSYIGof3pt7
Vibgdzy2rzSwvCkXxBzSeVNWD4x0GI9qSBURpuTuq+6YjAKlTbXwIV+8ULh8RjYW
IyKBtbvEEOyVGNYpO7BBgOwPQeJZvSIahwUpeyKGEHJztJv5sst2naACR9Y/wLws
T93KGkVyBMhgrO7NzNifT7BCR+efVCjViD3OCcq8887IY1w1JvG4Ee40rPdFOJqG
O1eeiJc9Ccx8WVj0PeWv5268PZErHzaVAXhzSydLsHMtLlAFR4Wt2w==
=wA2d
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 Continuous Integration - your help needed

2010-02-12 Thread Aaron Lippold 
Hi James,

My team at DISA and the Forge.mil project is looking to setup a
Puppet/Hudson/Cobbler driven setup for our CI. I was hoping you may
have some pointers you would be willing to share.

Thanks,

Aaron

On Mon, Dec 1, 2008 at 10:19 PM, James Turnbull  wrote:
>
> Hi all
>
> We're implementing a Hudson Continuous Integration server for Puppet and
> Facter.  The CI server will monitor the current development repositories
> - currently 0.24.x and master.  When new commits are detected it will
> run the unit and rspec tests on build slaves.
>
> Why all this?
>
> Well as Puppet and Facter are cross-platform tools a lot of bugs and
> issues we encounter are because a change has unexpected consequences on
> a particular platform.  This diversity of platforms also means the
> development team can't test sufficiently broadly.  By having
> tests run on many platforms we hope to quickly identify and correct any
> cross-platform bugs before they get into a release.
>
> So why Hudson and what does it do?
>
> Hudson monitors executions of repeated jobs, such as building a software
> project or jobs run by cron. Among those things, current Hudson focuses
> on building/testing software projects continuously, just like
> CruiseControl or DamageControl. In a nutshell, Hudson provides an
> easy-to-use so-called continuous integration system, making it easier
> for developers to integrate changes to the project, and making it easier
> for users to obtain a fresh build. The automated, continuous build
> increases the productivity.
>
> So what are build slaves?
>
> Build slaves are installations of particular operating systems and
> versions on which we want to run our tests after committing.
>
> So what do you need in order to submit a slave?
>
> See http://reductivelabs.com/trac/puppet/wiki/PuppetContinuousIntegration
>
> So what slaves do we need?
>
> This is a short list of the slaves we'd like (and multiple slaves of
> differing versions across a platform are also welcome).  But if you're
> running Puppet on a platform and are you able to contribute a build
> slave for that platform we'd very much appreciate it.
>
> OSX
> HP-UX
> AIX
> NetBSD
> OpenBSD
> FreeBSD
> Gentoo
> Ubuntu
> SuSE
> Red Hat
> CentOS
> Solaris - Open and Solaris 8/9/10
>
> So if you are able to provide a slave - email me the required details.
> Fleshing out the documentation on the wiki for your specific platform
> would also be most welcome.
>
> Thanks
>
> James Turnbull
>
> --
> Author of:
> * Pulling Strings with Puppet
> (http://www.amazon.com/gp/product/1590599780/)
> * Pro Nagios 2.0
> (http://www.amazon.com/gp/product/1590596099/)
> * Hardening Linux
> (http://www.amazon.com/gp/product/159059/)
>
>
>
>
>
> --~--~-~--~~~---~--~~
> 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-us...@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] satellite sites management

2010-02-12 Thread Nigel Kersten 
On Fri, Feb 12, 2010 at 11:41 AM, Michael DeHaan
 wrote:
> On Thu, Feb 11, 2010 at 7:20 PM, Nat  wrote:
>> Hi,
>>
>> We have got puppet set up and running at our main office with no
>> issues.
>> We are using an external node classifier instead of directly creating
>> node definition files.
>>
>> We would like to manage our remote offices using puppet also. A little
>> about our set up. From our main site we have VPN links out to a remote
>> site. each site is generally identical with the same number of servers
>> and roughly the same services running on each server. Essentially
>> the only differences at each remote site the subnet and related IP
>> addresses.
>>
>> Since we are using an external node classifier we do not explicitly
>> have node definition so we can not inherit a class and override a
>> default value.
>> Is there a way to do this using node classifiers?
>>
>>
>> An example will probably show this better
>>
>> Site1:
>>         + location UK
>>         + subnet  192.168.1.0/24
>>         + gateway 192.168.1.254 (acts also as nameserver and local
>> dns etc
>>                                               for all servers at site
>> 1, for example ntp will
>>                                               use the closest time
>> source geographically)
>>         + sever1 ip - 192.168.1.1 gateway of 192.168.1.254
>>         + sever2 ip - 192.168.1.2 gateway of 192.168.1.254
>> Site 2:
>>         + location US
>>         + subnet  192.168.2.0/24
>>         + gateway 192.168.2.254 (acts also as nameserver and local
>> dns etc
>>                                               for all servers at site
>> 2, for example ntp will
>>                                               use the closest time
>> source geographically)
>>         + sever1 ip - 192.168.2.1 gateway of 192.168.2.254
>>         + sever2 ip - 192.168.2.2 gateway of 192.168.2.254
>>
>> As you can see most details are identical between sites except for a
>> few
>> network and geographical differences.
>>
>> Has there been any consensus within the community on the best way to
>> manage situations like this?
>>
>
> I was talking with Eric yesterday about his external nodes regex classifier:
>
> http://github.com/reductivelabs/puppet/tree/master/ext/regexp_nodes/

I see this classifier uses "hostname" to refer to what strictly
speaking is the certname...

>
> This might be a start to some sort of evolved smart node idea (that we
> could stick in Dashboard and also build a CLI tool to) that could
> support the concept of variable inheritance.  So not just define what
> machines are webservers (rather than what webservers are what machine)
> but use similar regexen (or another system of groups) to classify what
> machines live in what areas -- and blend the two groups together.

Aren't we going to need more info than just the certname for external
nodes to be able to really be able to functionally classify them?

I realize this is a bit of a hobby horse for me as we don't use
hostnames for the certname... :) but even if you're using hostnames as
certnames do you really want to have to encode all this info into the
hostnames?


>
> Dan Bode mentions he sees several logical groups here -- there's what
> type of a machine you have, whether it's a stage/prod machine, and
> what location (datacenter) it is in (i.e. what is the machine's
> geographic location).   Some variables may come from one or more of
> those sources, and they can have some basic defaults.   (This is
> somewhat similar to Cobbler's "blender" inheritance for groups of
> things... allowing extension of arrays and adding keys to hashes, or
> overriding of scalars, as we evaluate the group orders.    The
> location groups and the classification groups would not need to be
> chained (i..e one a parent of another) but we'd want to support the
> idea of inherited subgroups (acme-datacenter is a subset of
> us-datacenters is a subset of datacenters).    Apologies if I'm being
> confusing :)
>
> There's obviously a lot to do here, but I can see the need for a
> intelligent external nodes classifier that understands those kinds of
> ideas that can really model a multi-site environment as a first class
> concept.
>
> --Michael
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Exec doesn't work with Ubuntu Server 10.04 (Lucid Lynx) 64bit

2010-02-12 Thread Joel Ebel 
Kai, and anyone else experiencing this problem, please go vote, and
optionally chime in with any details you can provide on:
https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715

Thanks,
Joel

On Feb 11, 3:06 pm, Joel Ebel  wrote:
> I've reported this bug to Ubuntu.  The solution is to rebuild ruby1.8
> without pthreads, unless ruby fixes the bug upstream which causes the
> hang.
>
> https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/520715
>
> Joel
>
> On Feb 10, 2:42 pm, Nigel Kersten  wrote:
>
>
>
> > On Wed, Feb 10, 2010 at 11:48 AM, Nigel Kersten  wrote:
> > > On Tue, Feb 9, 2010 at 5:06 AM, kai.steverding
> > >  wrote:
> > >> I installed ruby on the above server and tried with a simple exec-
> > >> test :
>
> > >> class testmodule {
> > >>                exec {"TEST-EXEC" :
> > >>                        cwd => "/tmp/",
> > >>                        command =>"/usr/bin/touch /tmp/ >/tmp/123 
> > >> 2>&1",
> > >>                        timeout => 5,
> > >>                        logoutput=> on_failure
> > >>                }
> > >> }
>
> > >> This simple thing gets the following output from "puppet --debug --
> > >> test"
>
> > >> debug: Loaded state in 0.00 seconds
> > >> info: Applying configuration version '1265719507'
> > >> debug: //testmodule/Exec[TEST-EXEC]: Changing returns
> > >> debug: //testmodule/Exec[TEST-EXEC]: 1 change(s)
> > >> debug: //testmodule/Exec[TEST-EXEC]: Executing '/usr/bin/touch /tmp/
> > >> '
> > >> debug: Executing '/usr/bin/touch /tmp/'
> > >> err: //testmodule/Exec[TEST-EXEC]/returns: change from notrun to 0
> > >> failed: Command exceeded timeout at /etc/puppet/modules/testmodule/
> > >> manifests/init.pp:6
> > >> debug: Finishing transaction 69914685668640 with 1 changes
> > >> debug: Storing state
> > >> debug: Stored state in 0.01 seconds
> > >> debug: Format pson not supported for Puppet::Transaction::Report; has
> > >> not implemented method 'from_pson'
> > >> debug: Format s not supported for Puppet::Transaction::Report; has not
> > >> implemented method 'from_s'
>
> > >> What can I do ? Did i make a mistake, or is exec broken ?
>
> > > Kai, something is definitely broken in Lucid.
>
> > > We're seeing all sorts of process exec issues.
>
> > > Have you nailed this down at all?
>
> > So Kai, we've been doing some experimenting here today, and have
> > reproduced these hangs in all the Debian Ruby1.8 packages back to
> > 1.8.7.174-2.
>
> > 1.8.7.174-1 we've been unable to reproduce it on though.
>
> > From the changelog I'm wondering if the first entry under 174-2 is
> > responsible. Note this was later removed after upstream integrated it.
>
> > ruby1.8 (1.8.7.174-2) unstable; urgency=medium
>
> >    [ akira yamada ]
> >    * Added debian/patches/090811_thread_and_select.dpatch: threads may 
> > hangup
> >      when IO.select called from two or more threads.
> >    * Added debian/patches/090812_finalizer_at_exit.dpatch: finalizers 
> > should be
> >      run at exit (Closes: #534241)
> >    * Added debian/patches/090812_class_clone_segv.dpatch: avoid segv when an
> >      object cloned.  (Closes: #533329)
> >    * Added debian/patches/090812_eval_long_exp_segv.dpatch: fix segv when 
> > eval
> >      a long expression.  (Closes: #510561)
> >    * Added debian/patches/090812_openssl_x509_warning.dpatch: suppress 
> > warning
> >      from OpenSSL::X509::ExtensionFactory.  (Closes: #489443)
>
> >    [ Lucas Nussbaum ]
> >    * Removed Fumitoshi UKAI  from Uploaders. Thanks a
> >      lot for the past help! Closes: #541037
>
> >    [ Daigo Moriwaki ]
> >    * debian/fixshebang.sh: skip non-text files, which works around hanging 
> > of
> >      sed on scanning gif images.
> >    * Bumped up Standards-Version to 3.8.2.
>
> > --
> > nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] satellite sites management

2010-02-12 Thread Michael DeHaan 
On Thu, Feb 11, 2010 at 7:20 PM, Nat  wrote:
> Hi,
>
> We have got puppet set up and running at our main office with no
> issues.
> We are using an external node classifier instead of directly creating
> node definition files.
>
> We would like to manage our remote offices using puppet also. A little
> about our set up. From our main site we have VPN links out to a remote
> site. each site is generally identical with the same number of servers
> and roughly the same services running on each server. Essentially
> the only differences at each remote site the subnet and related IP
> addresses.
>
> Since we are using an external node classifier we do not explicitly
> have node definition so we can not inherit a class and override a
> default value.
> Is there a way to do this using node classifiers?
>
>
> An example will probably show this better
>
> Site1:
>         + location UK
>         + subnet  192.168.1.0/24
>         + gateway 192.168.1.254 (acts also as nameserver and local
> dns etc
>                                               for all servers at site
> 1, for example ntp will
>                                               use the closest time
> source geographically)
>         + sever1 ip - 192.168.1.1 gateway of 192.168.1.254
>         + sever2 ip - 192.168.1.2 gateway of 192.168.1.254
> Site 2:
>         + location US
>         + subnet  192.168.2.0/24
>         + gateway 192.168.2.254 (acts also as nameserver and local
> dns etc
>                                               for all servers at site
> 2, for example ntp will
>                                               use the closest time
> source geographically)
>         + sever1 ip - 192.168.2.1 gateway of 192.168.2.254
>         + sever2 ip - 192.168.2.2 gateway of 192.168.2.254
>
> As you can see most details are identical between sites except for a
> few
> network and geographical differences.
>
> Has there been any consensus within the community on the best way to
> manage situations like this?
>

I was talking with Eric yesterday about his external nodes regex classifier:

http://github.com/reductivelabs/puppet/tree/master/ext/regexp_nodes/

This might be a start to some sort of evolved smart node idea (that we
could stick in Dashboard and also build a CLI tool to) that could
support the concept of variable inheritance.  So not just define what
machines are webservers (rather than what webservers are what machine)
but use similar regexen (or another system of groups) to classify what
machines live in what areas -- and blend the two groups together.

Dan Bode mentions he sees several logical groups here -- there's what
type of a machine you have, whether it's a stage/prod machine, and
what location (datacenter) it is in (i.e. what is the machine's
geographic location).   Some variables may come from one or more of
those sources, and they can have some basic defaults.   (This is
somewhat similar to Cobbler's "blender" inheritance for groups of
things... allowing extension of arrays and adding keys to hashes, or
overriding of scalars, as we evaluate the group orders.The
location groups and the classification groups would not need to be
chained (i..e one a parent of another) but we'd want to support the
idea of inherited subgroups (acme-datacenter is a subset of
us-datacenters is a subset of datacenters).Apologies if I'm being
confusing :)

There's obviously a lot to do here, but I can see the need for a
intelligent external nodes classifier that understands those kinds of
ideas that can really model a multi-site environment as a first class
concept.

--Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Building a better puppetrun and related ideas

2010-02-12 Thread Scott Smith 

On 2/12/10 2:10 AM, Alan Barrett wrote:

Not exactly, but that would probably be acceptable.  What actually
happens today is that puppetd is not run at all on the client unless an
authorised change is known to be ready for deployment; then puppetd is
run in --noop mode to verify that the changes it wants to make are as
expected; finallly puppetd is run in --no-noop mode.



What happens if a manual change is made outside of the scope of your scheduled Puppet changes? For 
example, someone tweaks /etc/syslog.conf. Puppet manages it but because you don't run regular noops, 
how will you know it needs to be changed back? Do plan around the organization (Ops or IT or w/e) 
not knowing it was changed? Since you don't have regular reports, how do you find out?


-scott

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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 Paris Meet up?

2010-02-12 Thread Brice Figureau 
Hi,

I know there are some French Puppet users around here.

On next wednesday (Feb 17th), there is a Github Drinkup[1] in Paris, and
I was wondering if we couldn't piggy-back the event for a mini-puppet
meet up.

It seems we're already a few to be interested in this event (github
and/or puppet). So if you're interested please answer and/or come drink
and meet some other Puppet users on next wednesday.

[1]:
http://github.com/blog/596-github-drinkup-paris-edition
-- 
Brice Figureau
Follow the latest Puppet Community evolutions on www.planetpuppet.org!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Problems with certs

2010-02-12 Thread James Cammarata 

Trying to setup a sandbox environment, and I'm running into some issues. 
When I run the system in --noop mode, everything works as it should (long
list of options truncated to ...):

[r...@kvm001 ~]# puppetd ... --noop
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
notice:
//dev_server/basenode/role_general/ntpd/File[/etc/localtime]/ensure: is
file, should be link (noop)
...

But when I run it without --noop, this happens:

[r...@kvm001 ~]# puppetd ...
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
warning: Certificate validation failed; consider using the certname
configuration option
err: //dev_server/basenode/role_general/ntpd/File[/etc/localtime]/ensure:
change from file to link failed: Certificates were not trusted: certificate
verify failed
...

I've verified the servers are sync'd in time (both running NTP from the
same servers), and I've verified that the hostnames all match up.  These
are VM's running on a private network, but I've got the VM's in the
puppetmaster's hosts file, so it can resolve them correctly, and the VM's
have matching /etc/hosts files as well, so I don't think name resolution is
the issue.

Any ideas?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Error 400 on SERVER: private method `gsub' called for nil:NilClass

2010-02-12 Thread Dan 
I found also that with puppetd --pluginsync I also get:

Feb 11 20:25:02 emu1076 puppetd[10505]: (/File[/var/puppet/lib])
Failed to generate additional resources using 'eval_generate':
Error 400 on SERVER: private method `gsub' called
for nil:NilClass

which forms the URL:

/production/file_metadatas/plugins?&ignore=---+%0A-+%22.svn%22%0A-+CVS
%0A-+%22.git%22&links=manage&recurse=true

(note the first empty param position).  It appears to be the
recurselimit param that is missing (written as empty string).

So the problem appears to be present in the puppetd impl of pluginsync
as well.  I am trying to work around this by syncing using a file
resource defined in my site.pp for /var/puppet/lib.










On Feb 12, 8:18 am, Eric Black  wrote:
> That is awesome! I had to go back to cfengine for this task, but now I can
> implement this type of thing in puppet again. Thanks so much!
>
> On Thu, Feb 11, 2010 at 10:13 PM, Dan  wrote:
> > I figured it out.  I hacked around and found that by adding params
> > 'ignore' and 'recurselimit' the problem goes away.
>
> > For example:
>
> > file {
> >      "/var/faban/faban/benchmarks":
> >          recurse => "true",
> >          ignore => "foo",
> >          recurselimit => 10,
> >          source => "puppet:///modules/faban2/benchmarks";
> >     }
>
> > Without those two params, I get your error.
>
> > On Feb 9, 6:44 am, eblack  wrote:
> > > Thanks for the response. I did try putting in the subdirectory path as
> > > well, but the same thing occurs. I continued to play around with it
> > > and the error message disappears if I remove the recurse parameter.
> > > The trace dump is below, but I can't find the problem from it (I don't
> > > know ruby):
>
> > > /usr/lib/ruby/1.8/webrick/httprequest.rb:342:in `parse_query'
> > > /usr/lib/ruby/1.8/webrick/httprequest.rb:122:in `query'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick/rest.rb:16:in
> > > `params'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/handler.rb:64:in `process'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick/rest.rb:23:in
> > > `service'
> > > /usr/lib/ruby/1.8/webrick/httpserver.rb:92:in `service'
> > > /usr/lib/ruby/1.8/webrick/httpserver.rb:54:in `run'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:45:in `listen'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `call'
> > > /usr/lib/ruby/1.8/webrick/server.rb:151:in `start_thread'
> > > /usr/lib/ruby/1.8/webrick/server.rb:145:in `start'
> > > /usr/lib/ruby/1.8/webrick/server.rb:145:in `start_thread'
> > > /usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
> > > /usr/lib/ruby/1.8/webrick/server.rb:89:in `each'
> > > /usr/lib/ruby/1.8/webrick/server.rb:89:in `start'
> > > /usr/lib/ruby/1.8/webrick/server.rb:79:in `start'
> > > /usr/lib/ruby/1.8/webrick/server.rb:79:in `start'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `listen'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in
> > > `initialize'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `new'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `listen'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:38:in
> > > `synchronize'
> > > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:38:in `listen'
> > > /usr/lib/site_ruby/1.8/puppet/network/server.rb:131:in `listen'
> > > /usr/lib/site_ruby/1.8/puppet/network/server.rb:146:in `start'
> > > /usr/lib/site_ruby/1.8/puppet/daemon.rb:128:in `start'
> > > /usr/lib/site_ruby/1.8/puppet/application/puppetmasterd.rb:122:in
> > > `main'
> > > /usr/lib/site_ruby/1.8/puppet/application/puppetmasterd.rb:80:in
> > > `main'
> > > /usr/lib/site_ruby/1.8/puppet/application.rb:226:in `send'
> > > /usr/lib/site_ruby/1.8/puppet/application.rb:226:in `run_command'
> > > /usr/lib/site_ruby/1.8/puppet/application.rb:217:in `run'
> > > /usr/lib/site_ruby/1.8/puppet/application.rb:217:in `exit_on_fail'
> > > /usr/lib/site_ruby/1.8/puppet/application.rb:217:in `run'
> > > /usr/sbin/puppetmasterd:66
> > > err: private method `gsub' called for nil:NilClass
>
> > > On Feb 8, 5:20 pm, Daniel  wrote:
>
> > > > You are missing the path to sync. The full path may be something like
> > > > "puppet://$server/modules/dev_oracle_dev_tools/the_tools_folder
> > > > dev_oracle_dev_tools just identifies the module
>
> > > > On Mon, Feb 8, 2010 at 11:13 PM, eblack  wrote:
> > > > > Hi all,
>
> > > > > I'm new to puppet and I can't seem to figure out how to get rid of
> > > > > this error on the client or to get the recursive copy of files to the
> > > > > client:
>
> > > > > err: //dev_oracle_dev_tools::install/File[/tmp/oracle_dev_tools]:
> > > > > Failed to generate additional resources using 'eval_generate': Error
> > > > > 400 on SERVER: private method `gsub' called for nil:NilClass
>
> > > > > My module is called 'dev_oracle_dev_tools' and it is defined as:
>
> > > > > class dev_oracle_dev_tools {
> > > > >        include dev_oracle

[Puppet Users] Re: Error 400 on SERVER: private method `gsub' called for nil:NilClass

2010-02-12 Thread Eric Black 
That is awesome! I had to go back to cfengine for this task, but now I can
implement this type of thing in puppet again. Thanks so much!



On Thu, Feb 11, 2010 at 10:13 PM, Dan  wrote:

> I figured it out.  I hacked around and found that by adding params
> 'ignore' and 'recurselimit' the problem goes away.
>
> For example:
>
> file {
>  "/var/faban/faban/benchmarks":
>  recurse => "true",
>  ignore => "foo",
>  recurselimit => 10,
>  source => "puppet:///modules/faban2/benchmarks";
> }
>
> Without those two params, I get your error.
>
>
>
>
> On Feb 9, 6:44 am, eblack  wrote:
> > Thanks for the response. I did try putting in the subdirectory path as
> > well, but the same thing occurs. I continued to play around with it
> > and the error message disappears if I remove the recurse parameter.
> > The trace dump is below, but I can't find the problem from it (I don't
> > know ruby):
> >
> > /usr/lib/ruby/1.8/webrick/httprequest.rb:342:in `parse_query'
> > /usr/lib/ruby/1.8/webrick/httprequest.rb:122:in `query'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick/rest.rb:16:in
> > `params'
> > /usr/lib/site_ruby/1.8/puppet/network/http/handler.rb:64:in `process'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick/rest.rb:23:in
> > `service'
> > /usr/lib/ruby/1.8/webrick/httpserver.rb:92:in `service'
> > /usr/lib/ruby/1.8/webrick/httpserver.rb:54:in `run'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:45:in `listen'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `call'
> > /usr/lib/ruby/1.8/webrick/server.rb:151:in `start_thread'
> > /usr/lib/ruby/1.8/webrick/server.rb:145:in `start'
> > /usr/lib/ruby/1.8/webrick/server.rb:145:in `start_thread'
> > /usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
> > /usr/lib/ruby/1.8/webrick/server.rb:89:in `each'
> > /usr/lib/ruby/1.8/webrick/server.rb:89:in `start'
> > /usr/lib/ruby/1.8/webrick/server.rb:79:in `start'
> > /usr/lib/ruby/1.8/webrick/server.rb:79:in `start'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:42:in `listen'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in
> > `initialize'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `new'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:41:in `listen'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:38:in
> > `synchronize'
> > /usr/lib/site_ruby/1.8/puppet/network/http/webrick.rb:38:in `listen'
> > /usr/lib/site_ruby/1.8/puppet/network/server.rb:131:in `listen'
> > /usr/lib/site_ruby/1.8/puppet/network/server.rb:146:in `start'
> > /usr/lib/site_ruby/1.8/puppet/daemon.rb:128:in `start'
> > /usr/lib/site_ruby/1.8/puppet/application/puppetmasterd.rb:122:in
> > `main'
> > /usr/lib/site_ruby/1.8/puppet/application/puppetmasterd.rb:80:in
> > `main'
> > /usr/lib/site_ruby/1.8/puppet/application.rb:226:in `send'
> > /usr/lib/site_ruby/1.8/puppet/application.rb:226:in `run_command'
> > /usr/lib/site_ruby/1.8/puppet/application.rb:217:in `run'
> > /usr/lib/site_ruby/1.8/puppet/application.rb:217:in `exit_on_fail'
> > /usr/lib/site_ruby/1.8/puppet/application.rb:217:in `run'
> > /usr/sbin/puppetmasterd:66
> > err: private method `gsub' called for nil:NilClass
> >
> > On Feb 8, 5:20 pm, Daniel  wrote:
> >
> > > You are missing the path to sync. The full path may be something like
> > > "puppet://$server/modules/dev_oracle_dev_tools/the_tools_folder
> > > dev_oracle_dev_tools just identifies the module
> >
> > > On Mon, Feb 8, 2010 at 11:13 PM, eblack  wrote:
> > > > Hi all,
> >
> > > > I'm new to puppet and I can't seem to figure out how to get rid of
> > > > this error on the client or to get the recursive copy of files to the
> > > > client:
> >
> > > > err: //dev_oracle_dev_tools::install/File[/tmp/oracle_dev_tools]:
> > > > Failed to generate additional resources using 'eval_generate': Error
> > > > 400 on SERVER: private method `gsub' called for nil:NilClass
> >
> > > > My module is called 'dev_oracle_dev_tools' and it is defined as:
> >
> > > > class dev_oracle_dev_tools {
> > > >include dev_oracle_dev_tools::install
> > > > }
> >
> > > > class dev_oracle_dev_tools::install {
> > > >file { "/tmp/oracle_dev_tools":
> > > >recurse => "true",
> > > >ensure  => "directory",
> > > >group   => "root",
> > > >owner   => "eblack",
> > > >mode=> 750,
> > > >source  => "puppet://$server/modules/
> > > > dev_oracle_dev_tools",
> > > >}
> > > > }
> >
> > > > And I call it like:
> >
> > > > node "file01.eblack.dev.gg.net" {
> > > >include "dev_oracle_dev_tools"
> > > > }
> >
> > > > All the other file parameters directives are followed on the client;
> > > > ie: directory is created if it doesn't exist and mode, group, owner
> > > > are set.
> >
> > > > The error goes away if I comment out the 'source' parameter.
> >
> > > > Hoping someone can help me because I've spent

Re: [Puppet Users] Re: virtual resource realizing by require?

2010-02-12 Thread Frederik Wagner 
Hi John,

perfect, thanks!

In the meantime I already found the flaw in the before mentioned
"simple" extension of the realize function:

The (virtual) requirements of virtual resources are evaluated, even if
the resource itself is not realized.
E.g. just including the following class test::virtual without
realizing resource_two would lead to a realization of resource_one!
:-(

class test::virtual {
@resource_one{ test: ...}

@resource_two{ test: ..., require => realize( Resource_one[test] ) }
}

Now I'm stuck again (and am lost where to start to look for the
solution in the sources of puppet ;-).

Bye,
Frederik

On Fri, Feb 12, 2010 at 3:52 PM, jcbollinger  wrote:
>
>
> On Feb 12, 8:32 am, jcbollinger  wrote:
>> I second this feature request, especially for the <| |> and <<| |>>
>> operators.
>
> In fact, I have logged a feature request in redmine, issue 3178.
>
> 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-us...@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-us...@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: virtual resource realizing by require?

2010-02-12 Thread jcbollinger 


On Feb 12, 8:32 am, jcbollinger  wrote:
> I second this feature request, especially for the <| |> and <<| |>>
> operators.

In fact, I have logged a feature request in redmine, issue 3178.

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-us...@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: Port 8139 needs to be open between machine running puppetrun and a client puppetd machine, correct?

2010-02-12 Thread Joe McDonagh 

Raj Gurung wrote:

Modified the puppet.conf but no joy still.

# puppetrun -d --host client.mydomain.com 
debug: Parsing /etc/puppet/puppet.conf
Finished

I dont see the changes pushed to client.mydomain.com 
 box. I wonder if LDAP is required 
component for puppetrun?


Thanks,
grg350

On Thu, Feb 11, 2010 at 12:44 PM, Iain Sutton > wrote:


Hi,

We are able to successfully invoke puppetrun from the
puppetmaster. The two main differences between our configuration
and what is posted below are:

a) the line 'server=puppet.mydomain.com
' is in the [puppetd] section on the
client, not in the [main] section
b) we don't have a namespaceauth.conf on the puppetmaster at all,
since when we had this in place, all clients would receive a '500
Internal Server Error' when they checked in. I haven't revisited
this recently.

We're running puppet 0.24.8 on CentOS/RHEL on client and server.

Hope this helps,

Iain


On 11 February 2010 13:49, grg350 mailto:grg...@gmail.com>> wrote:

Don, looks like you are able to run puppetrun to configure
clients.
Its not working for me.
My config files goes:

On Client:
cat puppet.conf
[main]
server=puppetmaster.mydomain.com

logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true

[puppetd]
listen=true

cat namespaceauth.conf
[puppetrunner]
   allow puppetmaster.mydomain.com


On puppetmaster:
cat namespaceauth.com 
[fileserver]
   allow *.mydomain.com 
[puppetmaster]
   allow *.mydomain.com 
[puppetrunner]
   allow *.mydomain.com 

I ran puppetrun with
#puppetrun --host client.mydomain.com 

But it doesn't looks like the client get updated and exits with
"Failed to load ruby LDAP library. LDAP functionality will not be
available
Finished"

Also, I dont see any traffic on port 8139 and 8140 while running
tcpdump.Those two machines are on same LAN and no firewall between
them. Not sure what I have been missing. any help would be
appreciated.

Thanks,
grg350

On Jan 31, 4:28 pm, Dan Bode mailto:d...@reductivelabs.com>> wrote:
> On Sun, Jan 31, 2010 at 12:11 PM, Don Jackson <
>
>
>
>
>
> puppet-us...@clark-communications.com
> wrote:
>
> > Hello,
>
> > I am attempting to get my machines configured properly so
I can use
> > puppetrun on my puppetmaster to get clients to update
themselves during my
> > development/testing of new recipes.
>
> > I understand about listen = true in the puppetd.conf file,
and I also have
> > learned about the namespaceauth.conf file,
> > where I put stuff like:
>
> >[puppetrunner]
> >allow puppet.mydomain.com

>
> > This was all I needed to get machines on the same LAN as
my puppetmaster to
> > work, but it didn't work across firewalls to machines in a
colo.
>
> > From router/firewall logs, it appears that the
puppetmaster needs to
> > connect to port 8139 of the machine running puppetd.
>
> that is correct, when using puppetrun, the authorized host
needs to initiate
> a connection with the client on port 8139, then that host
will initiate a
> request with its puppetmaster on 8140.
>
> You can change the puppetd listen port with the puppetport
option.
>
> -Dan
>
>
>
> > I wasn't able to find this clearly documented, hence this
email.
>
> > Regards,
>
> > Don
>
> > --
> > 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

http://groups.com>>
> > .
> > For more options, visit

[Puppet Users] Re: virtual resource realizing by require?

2010-02-12 Thread jcbollinger 


On Feb 12, 3:23 am, Frederik Wagner  wrote:
> So wouldn't be a simple idea to just change the realize function (or
> the '<| ... |>' operator) to return the resources it realised?

I second this feature request, especially for the <| |> and <<| |>>
operators.


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-us...@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: Failed to retrieve current state of resource: Error 400 on SERVER: Permission denied

2010-02-12 Thread jcbollinger 


On Feb 11, 9:16 am, Anchi Zhang  wrote:
> Thank you for the pointers.  My thinking was that if puppetd was allowed to
> do "owner => root" puppetmasterd should be able to read files owned by root,
> without realizing puppetd was running as root.

You're welcome.

Yes, puppetmasterd and puppetd are independent, and each is subject to
the standard security scheme of the host on which it runs.  As you
observed, puppetd requires great privilege to perform some of the
actions in its repertoire.  Not so much puppetmasterd.


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-us...@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: puppetrun doesn't update the clients

2010-02-12 Thread jcbollinger 


On Feb 11, 1:48 pm, Raj Gurung  wrote:
> *I am running 0.24.5-3 version of puppet/puppetmaster on lenny systems.

Also, that's a pretty old version of Puppet.  If you need to stick
with the 0.24 series, then I suggest updating to 0.24.8.  The latest
released version is 0.25.4; that is probably your best option if you
are working on a new Puppet deployment.


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-us...@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: puppetrun doesn't update the clients

2010-02-12 Thread jcbollinger 


On Feb 11, 1:48 pm, Raj Gurung  wrote:
[...]

> I ran puppetrun with
> #puppetrun --host client.mydomain.com
>
> But it doesn't looks like the client get updated and exits with
> "Failed to load ruby LDAP library. LDAP functionality will not be
> available
> Finished"

I'm not certain about puppetrun, but that message is only a warning
when emitted by puppetd.  As long as no LDAP functions are required,
puppetd works fine despite it.  If you want to get rid of the warning
then install the ruby-ldap package.

[...]

> any help would be
> appreciated.

If installing the ruby-ldap module doesn't solve the problem then it
would help to have some more information.  What messages does
puppetrun emit if you run it with --debug?  Do you see anything
relevant in the clients' logs?  What are you expecting to see on the
client side that isn't happening?  What do the manifests look like
that you are trying to push?

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-us...@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] vmwaretools

2010-02-12 Thread Filip Slunecko 
thx, that helps a lot.

Filip

On Thu, Feb 11, 2010 at 9:37 PM, Ohad Levy  wrote:
> the way we solved it is by setting up an additional service which compiles
> and set the driver (main reason for that was that network gets restarted
> which might disturb the puppet run)
>
> an example can be found here:
> http://theforeman.org/repositories/entry/foreman/app/views/unattended/snippets/_vmware.erb
>
>
> On Thu, Feb 11, 2010 at 5:55 PM, slune  wrote:
>>
>> hi, i am trying to run /usr/bin/vmware-config-tools.pl -d, but i was
>> end with exec timeout. I cannot find any think on google. Have anyone
>> experience with this?
>> It works, when I run it normally from shell.
>>
>> this is my exec resource.
>>
>> { "vmwaretools_config":
>>  subscribe   => [ Package["VMwareTools"] ],
>>   refreshonly => true,
>>   path        => "/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/
>> local/bin",
>>   command     => "/usr/bin/vmware-config-tools.pl -d";  }
>>
>> Thx
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@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-us...@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-us...@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] custom function load

2010-02-12 Thread Frederik Wagner 
Hi again,

reading the documentation about custom function distribution
, I don't
understand the following:

Normally custom per module facts, types, providers and functions are
distributed to the puppet hosts when they are in a the modules lib/
directory, like
/etc/puppet/modules//lib/{facter,puppet}.

This is also true form custom general facts, types and providers when
they are a 'custom'-module directory: /etc/puppet/modules/custom/lib/.
But this does not hold for general custom functions!

Now my question is:
Why are general functions _not_ distributed by this mechanism, when I
put hem in /etc/puppet/modules/custom/lib/puppet/parser/functions/,
but per module functions are?
Is there a way to distribute these functions?

Thanks and bye,
Frederik

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Building a better puppetrun and related ideas

2010-02-12 Thread Alan Barrett 
On Thu, 11 Feb 2010, Scott Smith wrote:
> >Of course there are change control procedures for getting the manifests
> >updated on the puppetmaster, but that's not enough; it's also necessary
> >to run the puppet client only when specifically authorised.  For
> >example, the manifest update and a --noop mode client puppet run might
> >happen during working hours, but the --no-noop client puppet run might
> >happen during a maintenance window after hours.
> 
> So let me get this straight: You run --noop throughout the day,
> aggregate the changes that need to be made, and then have a EOD/EOW
> "change control" meeting to go over them and determine if you need
> to run puppet without --noop ?

Not exactly, but that would probably be acceptable.  What actually
happens today is that puppetd is not run at all on the client unless an
authorised change is known to be ready for deployment; then puppetd is
run in --noop mode to verify that the changes it wants to make are as
expected; finallly puppetd is run in --no-noop mode.

--apb (Alan Barrett)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: How to disable file checksums?

2010-02-12 Thread Joshua Anderson 
On Feb 9, 2010, at 11:12 AM, Tim Stoop wrote:

> file { "/tmp": mode => 1777 }

I think you're seeing odd behavior because Puppet doesn't know that /tmp is 
supposed to be a directory.

Try this instead:

file { "/tmp": ensure => directory, mode => 1777 }

-Josh

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] virtual resource realizing by require?

2010-02-12 Thread Frederik Wagner 
Hi again,

On Thu, Feb 11, 2010 at 11:12 AM, Frederik Wagner
 wrote:
> On Thu, Feb 11, 2010 at 10:42 AM, Alan Barrett  wrote:
>> On Tue, 09 Feb 2010, Frederik Wagner wrote:
>>> I just tried using the define, and hit a problem which I would avoid
>>> (and actually need to avoid) by using the not implemented feature.
>>> Realizing the virtual define across modules forces me to give the
>>> namespace of the define explicitly, i.e. creating the virtual define
>>> @mymount in a class nas-1::virtual (in the Module nas-1) forces me to
>>> realize it in a second module as Nas-1::Virtual::Mymount<| |>, instead
>>> of just Mymount<| |>.
>>
>> Could you put the define in a common module, rather than a NAS-specific
>> module?  For example:
>>
>>/* In the "util" module */
>>
>>define mymount ($mountpoint) {
>>realize File[$mountpoint]
>>mount { $mountpoint: require => File[$mountpoint], }
>>}
>>
>>/* In the nas-1::virtual class */
>>
>>@util::mymount { "foo": }
>>
>>/* Wherever you want to instantiate the mount: */
>>
>>include nas-1::virtual
>>realize Util::Mymount["foo"]
>
> yes, in principle, if it wouldn't be just for this generic Mymount
> definition. Mymount is somehow just an extended redifinition of mount
> where all parameters are passed.
>
> But besides the required file resource some very nas-1 specific
> editing in /etc/sysctl.conf etc. (via augeas) should be done.
> Therefore any Mymount (there are multiple mountspoint on that filer)
> should also realize an augeas resource which defenitly can not go into
> the Util module. Do you see what I mean? The nas-1 module would be
> like:
>
> @augeas{ very specifig editing }
>
> @file{ mountpoint }
>
> @mount{ mountpoint: require => [realize Augeas, realize File] }
>
> where - like you said - mount+file have a generic form which can end
> up in a definition in "Util" but augeas has to stay in "nas-1".
>
> As far as I see - and I was thinking quite a while about it - I really
> end up needing the realization by require feature :-( or it's going to
> be a intermodule dependency mess.
>

I found a working for this problem! I hope this will work in more
complicated situations.

I copied the code of the realize-function to be of :type => :rvalue,
just additionally returning the resources it realized.
In this way I can use it as a input for the 'require' parameter, like

   @resource_one{ name: ... }

   @resource_two{ name:... , require => new_realize( Resource_one[name] ) }

   realize Resource_two[name]

This works perfect for this simple case, resource_one is realize
automatically and before resource_two. That should be it. I go on
testing in a more complicated setup.

So wouldn't be a simple idea to just change the realize function (or
the '<| ... |>' operator) to return the resources it realised?

Bye,
Frederik

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.