date:20130129

I'm CCing the pe-users list as this is a Puppet Enterprise specific question.

The passwords in puppet.conf and database.yml are not encrypted, those
are the passwords (they are also stored in the answers file in the
installer directory and in
/etc/puppetlabs/installer/database_info.install). To store the db
password encrypted, you could use hiera-gpg [1][2], or a custom
function of your own design.

HTH

[1] - 
http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/
[2] - https://rubygems.org/gems/hiera-gpg


On Tue, Jan 29, 2013 at 1:49 PM, Brendan Murtagh
 wrote:
> Hello,
>
> I ran into an issue today as I began to transition into a production
> environment from my Puppet testbed. I am using Puppet Enterprise 2.7 for
> Ubuntu (x64) and ran through the Installer and configured the Console, Cloud
> Provisioner, and Master on the same box. This all went well. I then began
> setting up agent1 for testing and after installing PE, updating the
> environment in the agent's puppet.conf, signing the agent's cert, I tried to
> do a puppet agent -td. This failed with the error:
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Access denied for user 'console'@'localhost' (using password: YES)
>
> During the Installer I was never prompted to enter the password for the
> Console user so initially I was stuck.
>
> I visited IRC and Ancillas and I went back and forth trying to figure out
> the cause. We viewed the passwords in /etc/puppetlabs/puppet/puppet.conf and
> /etc/puppetlabs/puppet-dashboard/database.yml but both are encrypted. I was
> going to attempt a reinstall of the Master, but then I found
> http://docs.puppetlabs.com/pe/2.0/maint_reconfiguring.html#changing-the-consoles-database-userpassword
> I followed the steps and everything worked like a charm.
>
> My main questions piggy-back one another...
>
> 1. What type of encryption/hash is used to initially write the password to
> those files? Can it be decrypted?
>
> 2. I'd prefer to store the db password in an encrypted fashion, is there a
> way to do this from within Puppet? I assume I could use a MySQL
> Administration and view the MySQL Users and copy that, but that seems
> excessive.
>
> Thanks,
>
> Brendan
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Matthaus Owens
Release Manager, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Help needed testing new cloud metadata facts in OpenStack, Eucalyptus, EC2, and Xen

2013-01-29 Thread Jeff McCune

Hello,

Regarding, https://github.com/puppetlabs/facter/pull/387

One of the long standing tickets with a lot of watchers is #7559 [1] where
the ec2_* metadata and userdata facts are not populated on Amazon EC2 VPC
instances.  This bug has been quite problematic to solve once and for all
because it's difficult to know if it's OK or not OK to make HTTP requests
of a server that may or may not respond.

I think I have a robust solution to this problem, but it relies on the
virtual fact returning a value of "xenu."  If the virtual fact has a value
of "xenu" then Facter will try and speak to the metadata server at
http://169.254.169.254  This server will respond in many common cloud
infrastructures, but will time out on a standard XenU instance.

To address the timeout issue, I've simply limited the maximum time the
request can take to 50ms.  The implementation retries only 3 times for a
maximum delay of 150ms.  This approach should reliably detect the metadata
server while mitigating the blocking I/O calls for environments where there
is no metadata server.

I've removed all infrastructure specific logic from Facter in this patch,
which is where I need your help.  The facts are working well for me in both
an Amazon EC2 VPC and non-vpc instance, but I don't have an easy way to
make sure they're working on OpenStack and Eucalyptus.  I also don't have a
way to ensure the 150ms delay is barely noticeable for XenU instances that
do not have a metadata server.

Finally, I'd like to solicit feedback on renaming all of these facts.
 They're no longer specific to EC2, instead they're generalized to any
infrastructure that has a responsive metadata server.  As a result, I'd
like to rename them to have a "metadata_*" prefix instead of an "ec2_*"
prefix.

My idea is to provide a Puppet module or Ruby Gem that provides backwards
compatibility for those people who don't want to refactor their manifests
to use the new Fact names.

Thoughts?  Comments?  Does the code in the branch work for you?

[1] http://projects.puppetlabs.com/issues/7559

Thanks,
-Jeff

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Referencing a variable from one class in another

On Tuesday, 29 January 2013 13:58:20 UTC-5, Ti Leggett wrote:
>
> I include that in the module that installs the shell packages and 
> configures them, in my case, I call it base. In other words, the variables 
> should be as close to the things they affect or are affected by. Just 
> because every node might include base (or site) doesn't mean every variable 
> you'll ever want to use should be in there. That, to me, creates a messier 
> and more confusing dependency relationship between modules that use a 
> variable and what that variable ultimately affects.

If you have a module that installs and configures those shells, then great. 
 But many systems come with those shells preinstalled, and there's nothing 
to manage.   Perhaps shells were a bad example, since one of tcsh or bash 
may need to be added to an OS by puppet.  What about the path to sed? 
 That's part of the base OS for all systems I manage, but the path varies 
from OS to OS.   It seems overly cumbersome to me to create an entire 
module just to assign one variable, and then repeat that for a dozen or so 
other variables with similar circumstances.  It seems cleaner to have a 
single small module that contains site-wide definitions that aren't 
obviously tied to modules of their own. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Questions/Concerns Related to Changing Console DB Password

2013-01-29 Thread Brendan Murtagh

Hello,

I ran into an issue today as I began to transition into a production
environment from my Puppet testbed. I am using Puppet Enterprise 2.7 for
Ubuntu (x64) and ran through the Installer and configured the Console,
Cloud Provisioner, and Master on the same box. This all went well. I then
began setting up agent1 for testing and after installing PE, updating the
environment in the agent's puppet.conf, signing the agent's cert, I tried
to do a puppet agent -td. This failed with the error:

*err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Access denied for user 'console'@'localhost' (using password: YES)*

During the Installer I was never prompted to enter the password for the
Console user so initially I was stuck.

I visited IRC and Ancillas and I went back and forth trying to figure out
the cause. We viewed the passwords in /etc/puppetlabs/puppet/puppet.conf
and /etc/puppetlabs/puppet-dashboard/database.yml but both are encrypted. I
was going to attempt a reinstall of the Master, but then I found
http://docs.puppetlabs.com/pe/2.0/maint_reconfiguring.html#changing-the-consoles-database-userpassword

I followed the steps and everything worked like a charm.

My main questions piggy-back one another...

1. What type of encryption/hash is used to initially write the password to
those files? Can it be decrypted?

2. I'd prefer to store the db password in an encrypted fashion, is there a
way to do this from within Puppet? I assume I could use a MySQL
Administration and view the MySQL Users and copy that, but that seems
excessive.

Thanks,

Brendan

--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] stuck installing puppet in RHEL 5

I've CCed the pe-users list as I think it is probably a better place
for this PE specific question.

The rake 400 error you see can be caused by a couple of issues. The
most common ones I've seen are

- the hostname you gave for the master isn't reachable (you may need
to add an entry to /etc/hosts or to dns for the master)
- the console has already requested and gotten signed a cert with the same name

HTH

On Tue, Jan 29, 2013 at 12:06 PM, brutuz  wrote:
> Hi All,
>
>   Im trying to install but with no luck.  Any idea what I did wrong ?
>
> ** mkdir -p /var/log/pe-console-auth
> ** touch /var/log/pe-console-auth/cas.log
> ** touch /var/log/pe-console-auth/auth.log
> ** chmod 770 /var/log/pe-console-auth
> ** chmod 660 /var/log/pe-console-auth/auth.log
> ** touch /var/log/pe-console-auth/cas_client.log
> ** chmod 660 /var/log/pe-console-auth/cas_client.log
> ** chown -R pe-auth:puppet-dashboard /var/log/pe-console-auth
> ** chown puppet-dashboard:puppet-dashboard
> /opt/puppet/share/live-management/config.ru
> ** chown pe-auth:pe-auth /opt/puppet/share/console-auth/config.ru
> ** chown pe-auth:pe-auth /opt/puppet/share/rubycas-server/config.ru
> ** service pe-httpd restart
> Stopping pe-httpd: [  OK  ]
> Starting pe-httpd: [  OK  ]
> ** chown root:root /var/opt/lib/pe-puppet/lib
> ** cd /opt/puppet/share/puppet-dashboard;
> PATH=/opt/puppet/sbin:/opt/puppet/bin:$PATH rake RAILS_ENV=production
> cert:create_key_pair
> (in /opt/puppet/share/puppet-dashboard)
> ** /opt/puppet/bin/passenger-status
> --- General information ---
> max  = 6
> count= 0
> active   = 0
> inactive = 0
> Waiting on global queue: 0
>
> --- Domains ---
> ** cd /opt/puppet/share/puppet-dashboard;
> PATH=/opt/puppet/sbin:/opt/puppet/bin:$PATH rake RAILS_ENV=production
> cert:request
> rake aborted!
> 400 "Bad Request"
>
> (See full trace by running task with --trace)
> (in /opt/puppet/share/puppet-dashboard)
>
> =
>
>
>There was an error running the installation. Please see the last few
> lines of output for more info.
>
>
> tia,
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Matthaus Owens
Release Manager, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Apache module

2013-01-29 Thread Ashley Gould

Hi,

On Mon, Jan 28, 2013 at 10:05:21PM -0800, Alex Harvey wrote:
> Hi all,
> 
> I've spent a bit of time today investigating whether or not I can use the 
> Puppet Labs Apache module -
> https://forge.puppetlabs.com/puppetlabs/apache
> 
> I've noted this helpful blog post -
> http://blog.akquinet.de/2011/11/23/managing-an-apache-server-with-puppet/
> 
> However after examining the Apache configuration I've inherited it seems to 
> me that the publicly available module exposes only a fraction of the Apache 
> options in the manifests.
> 
> E.g. I have inherited several hundred RewriteRules along with RewriteConds, 
> and all that ugliness, non standards paths to files, non standard values 
> passed to prefork and and worker MPM, and so on.  
> 
> In general, looking in templates/httpd.conf.erb file, though, it appears to 
> me that the vast majority of Apache's configuration options can't be 
> controlled by puppet if you use the Apache module.  Rather they're 
> hardcoded in this file.
> 
> This leads me to suspect that most sites must be using Apache modules that 
> were entirely developed in house?  Or have most sites just decided that 
> most of Apache's options shouldn't ever be changed from these default 
> settings?  Or is there a better Apache module I should look at?  Or should 
> I take the initiative and feedback lots and lots of changes to the module?

I suspect you are correct about in house apache modules.  I also found
the various apache modules on forge or elsewhere did not accomodate our
site's needs.  It is a tough problem.

We ended up building 2 apache modules.  the first handles our messy
"inherited" web site configs.  I opted to keep the httpd.conf static and
place all the messy stuff into vhost.conf files.  These get managed
either by template or static file depending on complexity.  This is less
than ideal and very site dependant.  We are up to 90+ vhost templates,
one per url. 

In the second version I tried to be more general.  I wanted a way for
any given application which needs web frontend to generate a vhost
config within it's own module without having to directly include an
apache class.  In the node def I can then include many such webapp
classes in any combination.  I then include my apache class which
serves any vhosts configs it finds in /etc/apache/vhost.d or whatever.
I am using exported resourses for the vhost configs, but I probably
don't need to. 

In both versions I keep the httpd.conf static, and put the apache config
complexity into the vhost configs.  

> 
> Thanks in advance for feedback.
> 
> Kind regards,
> Alex Harvey
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 

-- 

-ashley

Did you try poking at it with a stick?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Support for Windows

2013-01-29 Thread damian . folwell

no sorry, i'm only on day 2 of learning Ruby and about day 5 of Puppet.  If 
i'm lucky i get about an hour every other evening to look at this so 
progress is slow.  Once I've got something worthwhile sharing i'll post it 
somewhere.

My two projects are an ntfsfile type (in which you can specify a full DACL 
and inheritance) and a windowsservice type (which will install a service 
via installutil.exe if it doesn't already exist and allow you to specify a 
username and password).

On Tuesday, 29 January 2013 14:53:18 UTC, Rich Siegel wrote:
>
> Do you have any code on github?  Perhaps we can collaborate.  I am doing a 
> bit of windows type and provider development currently (mostly learning how 
> ;)  I have a pendinga windows clustering provider, and a windows ad dns 
> provider in the works.   I have also wrote a chocolatey provider that we 
> are now officially using on 100s of servers.
>  
>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] stuck installing puppet in RHEL 5

2013-01-29 Thread brutuz

Hi All,

  Im trying to install but with no luck.  Any idea what I did wrong ?

** mkdir -p /var/log/pe-console-auth
** touch /var/log/pe-console-auth/cas.log
** touch /var/log/pe-console-auth/auth.log
** chmod 770 /var/log/pe-console-auth
** chmod 660 /var/log/pe-console-auth/auth.log
** touch /var/log/pe-console-auth/cas_client.log
** chmod 660 /var/log/pe-console-auth/cas_client.log
** chown -R pe-auth:puppet-dashboard /var/log/pe-console-auth
** chown puppet-dashboard:puppet-dashboard 
/opt/puppet/share/live-management/config.ru
** chown pe-auth:pe-auth /opt/puppet/share/console-auth/config.ru
** chown pe-auth:pe-auth /opt/puppet/share/rubycas-server/config.ru
** service pe-httpd restart
Stopping pe-httpd: [  OK  ]
Starting pe-httpd: [  OK  ]
** chown root:root /var/opt/lib/pe-puppet/lib
** cd /opt/puppet/share/puppet-dashboard; 
PATH=/opt/puppet/sbin:/opt/puppet/bin:$PATH rake RAILS_ENV=production 
cert:create_key_pair
(in /opt/puppet/share/puppet-dashboard)
** /opt/puppet/bin/passenger-status
--- General information ---
max  = 6
count= 0
active   = 0
inactive = 0
Waiting on global queue: 0

--- Domains ---
** cd /opt/puppet/share/puppet-dashboard; 
PATH=/opt/puppet/sbin:/opt/puppet/bin:$PATH rake RAILS_ENV=production 
cert:request
rake aborted!
400 "Bad Request"

(See full trace by running task with --trace)
(in /opt/puppet/share/puppet-dashboard)

=


   There was an error running the installation. Please see the last few 
lines of output for more info.


tia,

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

We also tend to update our metadata more often than other public
repositories because we push new packages to it several times a week
(sometimes several times a day).

On Tue, Jan 29, 2013 at 11:31 AM, Greg Chavez  wrote:
> Gah... I bet that's it. We recently switched from our own sensible Internet
> egress to a tortured journey from DC to our Philly mothership.  We go
> through Websense, I think, and I know that blicky has had problems in the
> past with over-caching.
>
> Thanks.  Glad yours works, Dan.  Cheers.
>
>
> On Tue, Jan 29, 2013 at 1:44 PM, Matthaus Owens 
> wrote:
>>
>> Are you behind any sort of proxy that might be caching metadata?
>>
>> On Tue, Jan 29, 2013 at 10:30 AM, Scott Anderson  wrote:
>> > I had to not use the puppet repos to get it to work.. but this is on
>> > centos
>> > 5 and 6.
>> >
>> >
>> > On Tue, Jan 29, 2013 at 12:13 PM, Greg Chavez 
>> > wrote:
>> >>
>> >>
>> >> This is the third time I've sent a message about this.  Does anybody
>> >> know
>> >> what's going on?  I'm going to file a bug if this isn't fixed soon.
>> >>
>> >> RHEL6:
>> >>
>> >>
>> >> http://yum.puppetlabs.com/el/6/products/x86_64/repodata/primary.sqlite.bz2:
>> >> [Errno -1] Metadata file does not match checksum
>> >> Trying other mirror.
>> >> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
>> >> [Errno 256] No more mirrors to try.
>> >>
>> >> RHEL5:
>> >>
>> >>
>> >> http://yum.puppetlabs.com/el/5/products/x86_64/repodata/primary.sqlite.bz2:
>> >> [Errno -1] Metadata file does not match checksum
>> >> Trying other mirror.
>> >> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
>> >> [Errno 256] No more mirrors to try.
>> >>
>> >> I can get around it by setting "http_caching=none" in yum.conf but that
>> >> *really* sucks.
>> >>
>> >> If I'm being stupid and there's an obvious solution to my problem, I
>> >> beg
>> >> of you to tell me what it us and humiliate me in front of the entire
>> >> Puppet
>> >> users community.  I'd be so happy.
>> >>
>> >> --
>> >> \*..+.-
>> >> --Greg Chavez
>> >> +//..;};
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "Puppet Users" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to puppet-users+unsubscr...@googlegroups.com.
>> >> To post to this group, send email to puppet-users@googlegroups.com.
>> >> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> >> For more options, visit https://groups.google.com/groups/opt_out.
>> >>
>> >>
>> >
>> >
>> >
>> >
>> > --
>> > The most essential quality for leadership is not perfection,
>> > but credibility.  People must be able to trust you, or
>> > they won't follow you.
>> > From "The Purpose Driven Life" by Rick Warren
>> >
>> > Scott Anderson - web: http://www.torand.org - e-mail: s...@torand.org
>> > GoogleTalk: s...@torand.org - AIM:andersons776- Twitter:sdanderson
>> > Phone: 703-594-1284
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Puppet Users" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to puppet-users+unsubscr...@googlegroups.com.
>> > To post to this group, send email to puppet-users@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>>
>>
>> --
>> Matthaus Owens
>> Release Manager, Puppet Labs
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
>
> --
> \*..+.-
> --Greg Chavez
> +//..;};
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Matthaus Owens
Release Manager, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt

Re: [Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

2013-01-29 Thread Greg Chavez

Gah... I bet that's it. We recently switched from our own sensible Internet
egress to a tortured journey from DC to our Philly mothership.  We go
through Websense, I think, and I know that blicky has had problems in the
past with over-caching.

Thanks.  Glad yours works, Dan.  Cheers.


On Tue, Jan 29, 2013 at 1:44 PM, Matthaus Owens wrote:

> Are you behind any sort of proxy that might be caching metadata?
>
> On Tue, Jan 29, 2013 at 10:30 AM, Scott Anderson  wrote:
> > I had to not use the puppet repos to get it to work.. but this is on
> centos
> > 5 and 6.
> >
> >
> > On Tue, Jan 29, 2013 at 12:13 PM, Greg Chavez 
> wrote:
> >>
> >>
> >> This is the third time I've sent a message about this.  Does anybody
> know
> >> what's going on?  I'm going to file a bug if this isn't fixed soon.
> >>
> >> RHEL6:
> >>
> >>
> http://yum.puppetlabs.com/el/6/products/x86_64/repodata/primary.sqlite.bz2
> :
> >> [Errno -1] Metadata file does not match checksum
> >> Trying other mirror.
> >> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
> >> [Errno 256] No more mirrors to try.
> >>
> >> RHEL5:
> >>
> >>
> http://yum.puppetlabs.com/el/5/products/x86_64/repodata/primary.sqlite.bz2
> :
> >> [Errno -1] Metadata file does not match checksum
> >> Trying other mirror.
> >> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
> >> [Errno 256] No more mirrors to try.
> >>
> >> I can get around it by setting "http_caching=none" in yum.conf but that
> >> *really* sucks.
> >>
> >> If I'm being stupid and there's an obvious solution to my problem, I beg
> >> of you to tell me what it us and humiliate me in front of the entire
> Puppet
> >> users community.  I'd be so happy.
> >>
> >> --
> >> \*..+.-
> >> --Greg Chavez
> >> +//..;};
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Puppet Users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to puppet-users+unsubscr...@googlegroups.com.
> >> To post to this group, send email to puppet-users@googlegroups.com.
> >> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >>
> >
> >
> >
> >
> > --
> > The most essential quality for leadership is not perfection,
> > but credibility.  People must be able to trust you, or
> > they won't follow you.
> > From "The Purpose Driven Life" by Rick Warren
> >
> > Scott Anderson - web: http://www.torand.org - e-mail: s...@torand.org
> > GoogleTalk: s...@torand.org - AIM:andersons776- Twitter:sdanderson
> > Phone: 703-594-1284
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to puppet-users+unsubscr...@googlegroups.com.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
>
>
> --
> Matthaus Owens
> Release Manager, Puppet Labs
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
\*..+.-
--Greg Chavez
+//..;};

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How to collect hostnames or host ips

2013-01-29 Thread Dusty Doris

Thanks Luke and Ohad, this is great information.  Going to check out both 
foreman and puppetdb.


On Tuesday, January 29, 2013 4:35:27 AM UTC-5, ohad wrote:
>
>
>
> On Tue, Jan 29, 2013 at 4:30 AM, Dusty Doris 
> > wrote:
>
>> I'd like to be able to collect all the hostnames (fqdn) or ips of certain 
>> hosts to be used in setting up firewall rules.  I'd like to search for 
>> hosts that have included a particular class, perhaps by simply setting a 
>> tag when that resource is included.
>>
>> eg:
>>
>> node 'node1' {
>>   include 'somewebclass'
>> }
>>
>> class somewebclass {
>>   tag 'web'
>>   # other stuff
>> }
>>
>>
>> Then in another class, I'd like to find all my 'web' hosts and allow them 
>> access in a firewall rule.
>> eg:
>>
>> class somedbclass {
>>   tag 'db'
>>   iptables { "allow db access":
>> proto => 'tcp',
>> dport => '3306'
>> source => Node <| tag == 'web' |>,
>> jump => 'ACCEPT'
>>   } 
>> }
>>
>> So, ultimately, I'd need that Node <| tag == 'web' |> to be an array of 
>> hostnames or ipaddresses.
>>
>> This is just an example to try to explain what I am doing.  Does anyone 
>> know how to do this?  Can I do this in puppet?  Do I need to write my own 
>> function to handle this?  Or, can I use something like hiera or puppetdb to 
>> do this?
>>
>> Thanks for any tips.
>>
>
> if you use foreman, this is kind of trivial, see 
> http://blog.theforeman.org/2012/01/getting-foreman-search-results-into.html
>
> Cheers,
> Ohad 
>
>>
>>
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To post to this group, send email to puppet...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Referencing a variable from one class in another

2013-01-29 Thread Ti Leggett

On Jan 29, 2013, at 12:42 PM, Matthew Pounsett  wrote:

> 
> 
> On Tuesday, 29 January 2013 10:07:29 UTC-5, Ti Leggett wrote:
> I'm not sure I fully agree with this from a design standpoint. In 
> object-oriented programming, one of the design principles is that variables 
> relating to the object are encapsulated within the object and exposed or not 
> depending on how they should be accessed. IMHO, it also makes it more 
> obfuscated when you're accessing say the SSL CA cert path variable and that's 
> in some 'common' module that everything has to include. Granted it makes it 
> easier on the module developer - just always in include the common module and 
> your variables should be there - but it also makes it less explicit.
> 
> How would you handle variables that wouldn't otherwise be tied to a module?
> 
> An example I ran into when I was doing our first deployment was the path to 
> various shells.  They vary from OS to OS, but rarely (if ever) need a whole 
> module to manage them.  The paths get referenced in many places, such as when 
> adding users or installing scripts (erb used in the bangpath).  I've found it 
> useful to have things like $::site::params::bash and $::site::params:tcsh for 
> shells, and other site-wide variables for other things.  It means I only need 
> to put the case logic to figure out the path based on the OS in one place, 
> and not have it scattered around several modules that all need to figure out 
> the same thing.
> 

I include that in the module that installs the shell packages and configures 
them, in my case, I call it base. In other words, the variables should be as 
close to the things they affect or are affected by. Just because every node 
might include base (or site) doesn't mean every variable you'll ever want to 
use should be in there. That, to me, creates a messier and more confusing 
dependency relationship between modules that use a variable and what that 
variable ultimately affects.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

Are you behind any sort of proxy that might be caching metadata?

On Tue, Jan 29, 2013 at 10:30 AM, Scott Anderson  wrote:
> I had to not use the puppet repos to get it to work.. but this is on centos
> 5 and 6.
>
>
> On Tue, Jan 29, 2013 at 12:13 PM, Greg Chavez  wrote:
>>
>>
>> This is the third time I've sent a message about this.  Does anybody know
>> what's going on?  I'm going to file a bug if this isn't fixed soon.
>>
>> RHEL6:
>>
>> http://yum.puppetlabs.com/el/6/products/x86_64/repodata/primary.sqlite.bz2:
>> [Errno -1] Metadata file does not match checksum
>> Trying other mirror.
>> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
>> [Errno 256] No more mirrors to try.
>>
>> RHEL5:
>>
>> http://yum.puppetlabs.com/el/5/products/x86_64/repodata/primary.sqlite.bz2:
>> [Errno -1] Metadata file does not match checksum
>> Trying other mirror.
>> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
>> [Errno 256] No more mirrors to try.
>>
>> I can get around it by setting "http_caching=none" in yum.conf but that
>> *really* sucks.
>>
>> If I'm being stupid and there's an obvious solution to my problem, I beg
>> of you to tell me what it us and humiliate me in front of the entire Puppet
>> users community.  I'd be so happy.
>>
>> --
>> \*..+.-
>> --Greg Chavez
>> +//..;};
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
>
>
> --
> The most essential quality for leadership is not perfection,
> but credibility.  People must be able to trust you, or
> they won't follow you.
> From "The Purpose Driven Life" by Rick Warren
>
> Scott Anderson - web: http://www.torand.org - e-mail: s...@torand.org
> GoogleTalk: s...@torand.org - AIM:andersons776- Twitter:sdanderson
> Phone: 703-594-1284
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Matthaus Owens
Release Manager, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Referencing a variable from one class in another

On Tuesday, 29 January 2013 10:07:29 UTC-5, Ti Leggett wrote:
>
> I'm not sure I fully agree with this from a design standpoint. In 
> object-oriented programming, one of the design principles is that variables 
> relating to the object are encapsulated within the object and exposed or 
> not depending on how they should be accessed. IMHO, it also makes it more 
> obfuscated when you're accessing say the SSL CA cert path variable and 
> that's in some 'common' module that everything has to include. Granted it 
> makes it easier on the module developer - just always in include the common 
> module and your variables should be there - but it also makes it less 
> explicit.

How would you handle variables that wouldn't otherwise be tied to a module?

An example I ran into when I was doing our first deployment was the path to 
various shells.  They vary from OS to OS, but rarely (if ever) need a whole 
module to manage them.  The paths get referenced in many places, such as 
when adding users or installing scripts (erb used in the bangpath).  I've 
found it useful to have things like $::site::params::bash and 
$::site::params:tcsh for shells, and other site-wide variables for other 
things.  It means I only need to put the case logic to figure out the path 
based on the OS in one place, and not have it scattered around several 
modules that all need to figure out the same thing.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

2013-01-29 Thread Scott Anderson

I had to not use the puppet repos to get it to work.. but this is on centos
5 and 6.

On Tue, Jan 29, 2013 at 12:13 PM, Greg Chavez  wrote:

>
> This is the third time I've sent a message about this.  Does anybody know
> what's going on?  I'm going to file a bug if this isn't fixed soon.
>
> RHEL6:
> http://yum.puppetlabs.com/el/6/products/x86_64/repodata/primary.sqlite.bz2:
> [Errno -1] Metadata file does not match checksum
> Trying other mirror.
> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
> [Errno 256] No more mirrors to try.
>
> RHEL5:
> http://yum.puppetlabs.com/el/5/products/x86_64/repodata/primary.sqlite.bz2:
> [Errno -1] Metadata file does not match checksum
> Trying other mirror.
> Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
> [Errno 256] No more mirrors to try.
>
> I can get around it by setting "http_caching=none" in yum.conf but that
> *really* sucks.
>
> If I'm being stupid and there's an obvious solution to my problem, I beg
> of you to tell me what it us and humiliate me in front of the entire Puppet
> users community.  I'd be so happy.
>
> --
> \*..+.-
> --Greg Chavez
> +//..;};
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
The most essential quality for leadership is not perfection,
but credibility.  People must be able to trust you, or
they won't follow you.
>From "The Purpose Driven Life" by Rick Warren

Scott Anderson - web: http://www.torand.org - e-mail: s...@torand.org
GoogleTalk: s...@torand.org - AIM:andersons776- Twitter:sdanderson
Phone: 703-594-1284

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: define()'s sloooow

2013-01-29 Thread asq

W dniu wtorek, 29 stycznia 2013 16:54:46 UTC+1 użytkownik jcbollinger 
napisał:
>
>
> The bottom line is that I don't have an explanation for why your 
> compilations are so slow.  Sorry.  I don't think it's anything specific to 
> defined types, except inasmuch as defined type instances do have overhead 
> comparable to that of native type instances.  Perhaps the guys over on 
> puppet-dev would have a suggestion about how you can profile catalog 
> compilation to get an idea of where all the time is spent.
>
>
it's surely related to puppetmaster being slowed down by ruby gems, as i 
mentioned here: 
https://groups.google.com/d/topic/puppet-users/jpx9fNcFuMk/discussion
it might be not only cause, but giving a puppet dedicated rvm gemset (just 
semver for puppet, json for pdb and gpgme for hiera) gave us some 
significant boost.

another suspicious thing is how catalog is travelling over network. i think 
it should be compressed (lots of inlined templates) but for some reason it 
isn't (there is b64_zlib_yaml type, but there's no zlib_pson).

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

2013-01-29 Thread Greg Chavez

I've run yum clean all a hundred times, but that's besides the point since
I only notice the problem on new systems.  The build system (Cobbler)
installs the latest puppet-release rpm for each node, then instantiates
Puppet. It's worked like butter for over a year.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

RE: [Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

2013-01-29 Thread Nielsen, Steve

Try running this:   yum clean all

Steve

From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On 
Behalf Of Greg Chavez
Sent: Tuesday, January 29, 2013 11:13 AM
To: puppet-users@googlegroups.com
Subject: [Puppet Users] Seriously, am I the only one having trouble with the 
RHEL puppetlabs repos?

This is the third time I've sent a message about this.  Does anybody know 
what's going on?  I'm going to file a bug if this isn't fixed soon.

RHEL6:
http://yum.puppetlabs.com/el/6/products/x86_64/repodata/primary.sqlite.bz2: 
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products: [Errno 
256] No more mirrors to try.

RHEL5:
http://yum.puppetlabs.com/el/5/products/x86_64/repodata/primary.sqlite.bz2: 
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products: [Errno 
256] No more mirrors to try.

I can get around it by setting "http_caching=none" in yum.conf but that 
*really* sucks.

If I'm being stupid and there's an obvious solution to my problem, I beg of you 
to tell me what it us and humiliate me in front of the entire Puppet users 
community.  I'd be so happy.

--
\*..+.-
--Greg Chavez
+//..;};
--
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to 
puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Steve Nielsen VP, Open Source Engineering | comScore, Inc. (NASDAQ:SCOR)

o +1 (312) 775-6473 | f +1 (312) 775-6495 | 
sniel...@comscore.com

...

Introducing Mobile Metrix 2.0 - The next generation of mobile behavioral 
measurement
www.comscore.com/MobileMetrix

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] command "puppet node install"

2013-01-29 Thread GRANIER Bernard (MORPHO)

Hi,

If I understood correctly, this command installs puppet on a remote node.

Is this command available in enterprise version only or is it possible to use 
it in community version ?

Sincerly,

Bernard Granier
CE Plateforme Système
bernard.gran...@morpho.com
01 58 11 32 51

#
" This e-mail and any attached documents may contain confidential or 
proprietary information. If you are not the intended recipient, you are 
notified that any dissemination, copying of this e-mail and any attachments 
thereto or use of their contents by any means whatsoever is strictly 
prohibited. If you have received this e-mail in error, please advise the sender 
immediately and delete this e-mail and all attached documents from your 
computer system."
#

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Cron job based on gateway

2013-01-29 Thread Keith Burdis

Here's one way:

1) Install the erwbgy/system module:

# puppet module install erwbgy/system

2) Configure a custom fact using facter_dot_d for the default gateway:

include system::schedules
$config = {
  'default_route' => {
'type'  => 'script',
'value' => "#!/bin/bash\nprintf default_route=; /sbin/ip route show |
/usr/bin/perl -ane 'print \$F[2] if /^default /o'",
   }
}
class { '::system::facts':
  config => $config,
}

3) Create the cron job using this custom fact:

cron { 'mycron':
  command => "/usr/bin/ELFexecutable -g ${default_route}",
  hour=> 1,
  minute  => 1,
}

  - Keith



On 29 January 2013 14:12, Balasubramaniam Natarajan wrote:

> Hi
>
> Is there a way for puppet to create cron job on each of my node based on
> my gateway's IP ?
>
> bala@bala-desktop:~$ route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric RefUse
> Iface
> 10.0.2.00.0.0.0 255.255.255.0   U 1  00
> eth0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 1000   00
> eth0
> 0.0.0.0 10.0.2.20.0.0.0 UG0  00
> eth0
> bala@bala-desktop:~$
>
> For example if my gateway is 10.0.2.2 then I need to set up a cron job
> like the following, with my gateway being a parameter which I pass to my
> ELFexecutable
>
> 1 1 * * * /usr/bin/ELFexecutable -g 10.0.2.2
>
> For now I can do it to a extent, please let me know if I am on the correct
> path ? Or is there a better way to do it,  currently when I list all the
> facter I don't see any with the gateway address.
>
> --
> Regards,
> Balasubramaniam Natarajan
> www.blog.etutorshop.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Seriously, am I the only one having trouble with the RHEL puppetlabs repos?

2013-01-29 Thread Greg Chavez

This is the third time I've sent a message about this.  Does anybody know
what's going on?  I'm going to file a bug if this isn't fixed soon.

RHEL6:
http://yum.puppetlabs.com/el/6/products/x86_64/repodata/primary.sqlite.bz2:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
[Errno 256] No more mirrors to try.

RHEL5:
http://yum.puppetlabs.com/el/5/products/x86_64/repodata/primary.sqlite.bz2:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.sqlite.bz2 from puppetlabs-products:
[Errno 256] No more mirrors to try.

I can get around it by setting "http_caching=none" in yum.conf but that
*really* sucks.

If I'm being stupid and there's an obvious solution to my problem, I beg of
you to tell me what it us and humiliate me in front of the entire Puppet
users community.  I'd be so happy.

-- 
\*..+.-
--Greg Chavez
+//..;};

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet Site.pp hierarchy (multi-tenant) question

2013-01-29 Thread אלעד שמיטנקה

If you worry that 1 team will add node classification of another one, then 
the only way is via enviroments, each enviroment will have it's own site.pp
if that's not the case, you can just put "include nodes.d" in the site.pp,
create a directory named "nodes.d" and then have different files for each 
team.

On Tuesday, January 29, 2013 11:34:56 AM UTC+2, jim wrote:
>
> Hello all,
>
> I was wondering if someone could please help or explain the best approach 
> to setting up puppet as our first requirement is to support multi-tenant 
> within our company  what I mean by this is we have different teams 
> supporting different O/S or the same O/S but different configurations,
>
> Team A - Windows O/S Config A
> Team B - Linux O/S Config B
> Department C - Windows O/S Configs C & D
>
> From what I've been reading there seems multiple ways of doing this, some 
> are being phased out, and some are aren't that clear.
>
> The easiest option would be to add different manifests for different 
> groups / teams within site.pp, but if I make changes to the sub-manifests, 
> i'd need to "touch" the site.pp file for changes to kick in, which could 
> also effect the other teams / group changes and cause outages ?
>
> Can some please recommend the best approach to multi-tenant or at least 
> pass on your experiences ?
>
> Kind Regards
>
> James
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet Site.pp hierarchy (multi-tenant) question

On Tuesday, 29 January 2013 04:34:56 UTC-5, jim wrote:
>
> The easiest option would be to add different manifests for different 
> groups / teams within site.pp, but if I make changes to the sub-manifests, 
> i'd need to "touch" the site.pp file for changes to kick in, which could 
> also effect the other teams / group changes and cause outages ?
>
> Can some please recommend the best approach to multi-tenant or at least 
> pass on your experiences ?
>

You probably have several difference choices that might have different 
drawbacks or benefits depending on exactly how you're managing things.   
One option that comes to mind is to use something like 'environments' to 
define a different site.pp file for each tenant.  Each tenant could "claim" 
the machines under their control by setting a property on the console or in 
the agent's puppet.conf like so:

[agent]
tenant = "teamA"

In your master's puppet.conf, something like this:

[master]
manifest = "/usr/local/etc/puppet/tenant/${tenant}/manifests/site.pp 

And so Team A's site.pp would be at:
/usr/local/etc/puppet/tenant/teamA/manifests/site.pp

You could arrange the directory/manifest structure there any way you want. 
 This would be equally as valid:
[master]
manifest = "/usr/local/etc/puppet/manifests/${tenant}-site.pp 

Any method of getting the 'tenant' global variable defined would work. 
 Which to choose is a matter of pereference.  Some examples: a puppet.conf 
definition, a custom fact, a piece of data pulled from Hiera...  The 
documentation on setting up environments might be of interest to you. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] ssh::auth and other ways of managing ssh keys

2013-01-29 Thread Vasil Mikhalenya

hi all,

if you have big storage of public keys (may be of employees) try this one
https://github.com/bazilek/puppet-ssh_key_groups/


On Wed, Jan 23, 2013 at 11:45 PM, Jist Anidiot wrote:

>
> Thoughts?
>> (1) 
>> https://github.com/boklm/**puppet-sshkeys
>> (2) 
>> https://github.com/vurbia/**puppet-sshauth
>> (3) 
>> https://github.com/**ashleygould/puppet-sshauth
>> (4)http://projects.puppetlabs.**com/projects/1/wiki/Module_**
>> Ssh_Auth_Patterns#detailed-**usage
>>
>>
> I checked out all of these and I still opted to use the puppet builtin
> ssh_authorized_key and sshkey. Not quite the most powerful, but good enough.
>
> --
> 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/-/QPoNr2wYOVAJ.
>
> 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.
>



-- 
Best regards,
Vasil Mikhalenya

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Puppet Agent does not connect to master

On Tuesday, January 29, 2013 1:40:17 AM UTC-6, Rainer Bendig wrote:
>
> Hi,
>
> we are running several debian squeeze (64 bit, no backports) and a 
> puppetmaster (3.0.2).
>
> now i wanted to upgrade the agents from 3.0.1 to 3.0.2, and got stuck... 
> the "new" 3.0.2 agents don't connect to the master... 3.0.1 agents still 
> do... i run puppet master in debug mode, and didn't see any communications 
> between agent and master... "puppet" and "puppet.foo.bar" are both 
> resolving to the right puppet host, the machines are on the same subnet, 
> and did work under 3.0.1 ;(
>
> the error from the 3.0.2 agents is
>
> [...]
> [certificate signature failure for /CN=puppet..foo.bar] Could not retrieve 
> file metadata for puppet://puppet/plugins: SSL_connect returned=1 errno=0 
> state=SSLv3 read server certificate B: certificate verify failed: 
> [certificate signature failure for /CN=puppet.foo.bar]
> [...]
>

Look for differences in puppet.conf between broken and working clients.  
Especially make sure that the broken clients are pointed at the correct 
master.  Also verify that the clients' and master's clocks are synchronized.

If none of that reveals the problem, then probably the upgrades clobbered 
part of the clients' SSL configuration.  I can't speak to how or why that 
happened, but to go forward you probably need to re-establish trust between 
clients and master.  To do so on an affected client:

   1. Shut down the Puppet agent
   2. Revoke and remove the client certificate from the master, via "puppet 
   ca"
   3. Blow away the *client's* SSL directory, normally /var/lib/puppet/ssl
   4. Restart the agent, possibly with the --waitforcert option turned on
   5. Sign the client's new certificate request via "puppet ca" (on the 
   master)

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: How to assign variable for an URL



On Tuesday, 29 January 2013 02:05:30 UTC-5, yarlagadda ramya wrote:
>
> Hi all,
>
> I have written the following code...
>
> $someendpoint1="12345"
> $someendpoint2="54321"
> $prop = "/app/tcs/temp.properties"
>
> file{'temp.properties':
> path =>"$prop",
> ensure =>'present',
> content =>"$someendpoint1=http://sdrhuiswresw:8080/ersfrsdrs/sdersrsrs
> $someendpoint2=http://sdrhuiswresw:8080/ersfrsdrs/sdersrsrs";
> }
>
> actually i want to apply variables to the link..when am trying to do that 
> am getting an error. How can i assign the variables to link???
>
>
If I understand your request properly.. just the same as you're applying 
variables elsewhere.

$someendpoint1="12345"
$someendpoint2="54321"
$prop = "/app/tcs/temp.properties"
$uri_path = "/ersfrsdrs/sdersrsrs"

file{'temp.properties':
path =>"$prop",
ensure =>'present',
content 
=>"$someendpoint1=http://sdrhuiswresw:8080/
$uri_path
$someendpoint2=http://sdrhuiswresw:8080/
$uri_path"
 
If you have a case where the variable name is ambiguous because it's up 
against another string that could be part of the variable:.

e.g.
$foo = "super"
$bar = "$foostar"

Then you have to enclose the variable name in curly quotes to remove the 
ambiguity:

$foo = "super"
$bar = "${foo}star"

Some people consider it good style to do this all the time.

However, I'm only guessing at what errors you might be seeing.  If you 
could supply the real example of what you're trying to do, with the error 
you're getting, it would make it easier to give you specific advice.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Deploying modules and configuration - Precousions

2013-01-29 Thread אלעד שמיטנקה

Hi,
I have a production puppet server running with apache&passenger
Unfortunately, we have stumbled upon cases in which a module was installed 
in position we did not meant to install it on,
no, the blame is not on puppet, it's on us, we didn't notice some cases 
of behavior of the modules.
all the configuration and modules are stored in our SVN.
What we'd like to have is a process with the following capabilities:

   1. Will allow us to diff the changes in the modules, prior to having 
   them in "production"
   I know, SVN supports it, but I'd love to have yet another layer in case 
   of someone else has committed a change and I wasn't aware of that.
   2. Will allow us to see how (if at all) the new settings 
   (config/modules) will affect all the servers that are currently managed by 
   puppet, that is,
   diff the current catalog against the one that will be after the changes 
   are made
   3. Send mail once the new config and modules are valid on the puppet 
   server

To my best knowledge, puppet 3 offers a way to check a catalog of a node 
against a puppet server, so I'm pretty sure it's possible (probably with 
couple infrastructure changes)
My question is:
does anyone already know of such a tool and setup guide?
I'd really rather take one, than implement one,
Any language will be good as long as it's open source.

Thanks you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Extending a standard type



On Tuesday, 29 January 2013 00:29:43 UTC-5, Keith Burdis wrote:
>
> You can set the default values to undef and then the standard user type 
> will use its defaults (if any).  It usually makes sense to default the 
> ensure parameter to 'present' though because if it is undef then nothing 
> will happen:
>

Ah, I see... I'd tried using empty strings, but for some reason undef never 
occurred to me.  Thanks, it looks like this will work perfectly.


>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: define()'s sloooow

The bottom line is that I don't have an explanation for why your 
compilations are so slow.  Sorry.  I don't think it's anything specific to 
defined types, except inasmuch as defined type instances do have overhead 
comparable to that of native type instances.  Perhaps the guys over on 
puppet-dev would have a suggestion about how you can profile catalog 
compilation to get an idea of where all the time is spent.

On Monday, January 28, 2013 10:04:51 AM UTC-6, asq wrote:
>
> i know that those times are high. but anyway i can't find a single "bit" 
> that makes it so. i think puppet is very sensitible to the way its used. 
> when you look at ruby 1.8/1.9 comparisions for the same manifests, you can 
> clearly see that something worrying is happening, as newer ruby should be 
> more optimized, but instead it runs significantly slower.
>
>
Of course Puppet's compilation speed is sensitive to the contents of your 
manifests, and more so than just to their raw size.  It may be that you can 
substantially improve your performance if you can identify the problem 
area(s).

On the other hand, I don't think it's at all safe to assume that a 
higher-version Ruby (or anything else) should yield greater performance.  
Performance optimization is certainly one development objective, but it is 
often at odds with new feature implementation and even with bug fixes.  
Especially with between Ruby 1.8 and Ruby 1.9 there are some deep changes 
in Ruby's string handling and character I/O, and these (among other things) 
might easily exact a performance penalty from applications, such as Puppet, 
that do a lot of text manipulation.

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Extending a standard type

On Monday, January 28, 2013 11:07:51 AM UTC-6, Matthew Pounsett wrote:
>
>
>
> On Monday, 28 January 2013 11:14:59 UTC-5, jcbollinger wrote:
>  
>
>> define site::user (
>>> $comment,
>>> $ensure,
>>> $home,
>>> $name = $title,
>>>
>>
>>
>> Don't do that ($name = $title).  Puppet provides it automatically (both 
>> the parameter and the default).
>>
>
> In this case, $name is the login name of the user being created .. it's a 
> valid parameter of the 'user' resource type.  I'm not sure how I'm supposed 
> to do not use it.  I have read the Puppet reference manual.. but not for 
> puppet 3, since I'm not using that.  
>

You are missing the point: Puppet automatically endows every defined type 
with a $name parameter, and automatically defaults its value to the 
$title.  See 
http://docs.puppetlabs.com/puppet/3/reference/lang_defined_types.html#title-and-name.

Though Puppet might not complain, it is at best poor form to declare the 
same thing explicitly.

>
>  
>
>> Moreover, I am uncertain whether it is safe anyway to use $title as a 
>> resource default.  It certainly *isn't* safe to use explicit resource 
>> properties, regardless of the order in which they are listed.
>
>
> I'n not sure what you mean by that.  Using $title as a default is widely 
> used (see namevar) .. I'm not sure what you mean about explicit resource 
> properties.
>

I answer my own question: the automatic $title and $name parameters are 
documented safe to use as parameter defaults (but I'm not sure whether 
$name remains safe if you (re)declare it explicitly).  No (other) 
parameters you explicitly define are safe for use as default values of 
other parameters.  That is, you must not do this:

site::user ( $uid, $gid = $uid ) {
# ...
}

>
>
>> The usual paradigm is this:
>> define mymodule::foo ( $param1 = 'NOTSET' ) {
>>   $real_param1 = $param1 ? {
>> 'NOTSET' => ,
>> default => $param1
>>   }
>>   sometype { $name:
>> param => $real_param1
>>   }
>> }
>> Yes, it's a bit clunky, but it works.
>
>  
>
> This is great if I want to set my own defaults, but I don't.  The 'user' 
> resource already has its own way of handling unspecified parameters, and I 
> don't want to override those unless absolutely necessary.   I think the 
> above would require me to re-implement a bunch of its defaults logic, which 
> would be especially problematic for things like 'gid'.  
>

Note the "maybe-undef" in .  I'm 
referring there to the literal keyword 'undef', which should serve your 
needs.  In this case you can also use 'undef' directly as the default, as 
Keith suggested, but that does not allow you to distinguish between the 
case where the user doesn't set a parameter and the one where he explicitly 
sets it to undef.  You may not need that distinction now, but if you 
continue writing Puppet manifests then one day you will.

>
>  
>
>> No, Puppet doesn't have anything like that.  The closest would probably 
>> be the create_resources() function, which you can read about in the docs.
>
>
> I'll have a look.. maybe there's some way I can make use of it.
>  
>
>> I'm surprised you didn't find an example like the one above.  It appears 
>> all over the place, not least in the archives of this group.
>>
> Also, have you read the official Puppet DSL docs (at 
>> http://docs.puppetlabs.com/puppet/3/reference/)?  They don't answer your 
>> particular question, but they would have told you about $name, and they 
>> have a lot of other useful information.
>
>
> The only occurrence of the string "name" in the DSL doc at that location 
> is as a placeholder... and it applies to ruby, not puppet manifests.  I 
> don't see anything there about use of $name inside a puppet class.
>
>

You're not talking about a class, you're talking about a definition.  The 
distinction is important.  Anyway, I gave a direct link above to the docs 
for $name and $title in defined types.

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: puppetdb catalog duplication

2013-01-29 Thread llowder



On Tuesday, January 29, 2013 8:54:43 AM UTC-6, olli...@googlemail.com wrote:
>
> Hello,
>
> Just kicking the tyres with PuppetDB (1.1.0) on a test setup with 100-odd 
> nodes running only once an hour by default.
>
> Looking at the dashboard the catalog duplication is showing 0.0% which 
> seems a little odd to me. Any way to track
> down why this is and how to correct it as presumably this is not desired 
> behaviour.
>
>
If you have puppet-dashboard or the foreman, you can easily scan reports to 
see what changed. If you just had report set to store, still do able but 
will take a bit more work.

My guess is that you have a notify() or exec() that is running every time 
there is a puppet run, as a 0% catalog duplication means that evey catalog 
that comes in is unique, or had some sort of change in it.

 

> Cheers
> Paul
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Referencing a variable from one class in another

2013-01-29 Thread Ti Leggett

On Jan 29, 2013, at 8:51 AM, jcbollinger  wrote:

>> The only way to force parse-time ordering right now is to do a direct 
>> include, unfortunately. 
>> 
> 
> 
> Yes, but I'm not sure I would say "unfortunately" there.  The problem is not 
> so much with any limitation of Puppet DSL in this area, but rather an issue 
> of module design and manifest set architecture.
> 
> I mean, one should be very careful and deliberate about designing modules 
> such that their classes need to rely on class variables of other modules' 
> classes.  Indeed, it is probably a poor idea to implement such a design 
> unilaterally -- instead, the module providing the class variables should be 
> designed and implemented in anticipation of that usage as well.  That 
> probably means centralizing all variables intended for cross-module reference 
> in one well-known class, documenting their names and value ranges, and 
> committing to avoiding incompatible changes there.
> 

I'm not sure I fully agree with this from a design standpoint. In 
object-oriented programming, one of the design principles is that variables 
relating to the object are encapsulated within the object and exposed or not 
depending on how they should be accessed. IMHO, it also makes it more 
obfuscated when you're accessing say the SSL CA cert path variable and that's 
in some 'common' module that everything has to include. Granted it makes it 
easier on the module developer - just always in include the common module and 
your variables should be there - but it also makes it less explicit. I would 
argue, if you're writing a module that depends on using the SSL CA cert path 
you have some dependency on the SSL module and should have some understanding 
of what that module does and the ramifications of using that module, so you 
should explicitly include that module for that dependency. In just about every 
language you must include the external modules/libraries you depend on for 
functionality outside the standard norm. In puppet the standard norm - the 
stdlib.h equivalent if you will - I would consider to be facter variables. You 
want to use LDAP or SSL or Kerberos? You best include those modules explicitly 
and figure out what you can use from them - ldap.h <> ldap::params, ssl.h <> 
ssl::params, etc. Standardize how you create these public puppet 'headers' and 
use them explicitly and appropriately that way. At least that's my 2c.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Want to work in "cutting-edge" education in Cambridge, MA?

2013-01-29 Thread Ashley Penney

Hello!

I'm not a recruiter, manager, or otherwise non-technical person spamming
the users list in order to harvest email addresses.  I'm one of the 'devop
engineers' at EdX, a MIT/Harvard/Everyone else non-profit organization
aimed at reinventing online education.  We're the non-profit version of
Udacity/Coursera basically.

We're currently a team of three, with two members of the team having a
strong programming/dev background and me, the black sheep of the team with
a primarily ops background.

We're looking for people who would feel comfortable jumping directly into a
hodge podge environment based in AWS running a mostly Django stack with
Puppet driving the conf mgmt behind the scenes.

Must be comfortable with ongoing endless arguments about the "Right Way" to
do everything from provisioning to deployment and must be willing to wade
in feet first into the eternal vim vs emacs argument.

We're a very tight knit self organizing team with minimal direction from
above other than requirements from the developers building the stuff we
run.  You'll have a direct and visible affect on the environment here and
help us shape it to be world class (hopefully!).

We have free lunches and a relaxed (but horribly busy still as we're like a
startup) environment.  I've been here since September or so and I
absolutely love it here.  I love coming to work and I love being able to
directly design the infrastructure and build things without endless
meetings and delays and politics. :)

As you can tell, I don't write a lot of job advertisements but if you'd be
potentially interested in working with us please drop me a line at
apen...@edx.org with your resume or catch 'ashp' in #puppet.  The only real
restriction we have is that we're looking for local people rather than
remote workers due to the nature of our collaboration.

Oh and we're a 'kind of agile team, I guess', with retros and planning and
trello boards and all that kind of thing so we hope you're cool with that
too.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppetdb catalog duplication

2013-01-29 Thread ollies...@googlemail.com

Hello,

Just kicking the tyres with PuppetDB (1.1.0) on a test setup with 100-odd 
nodes running only once an hour by default.

Looking at the dashboard the catalog duplication is showing 0.0% which 
seems a little odd to me. Any way to track
down why this is and how to correct it as presumably this is not desired 
behaviour.

Cheers
Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Support for Windows

2013-01-29 Thread Rich Siegel

Do you have any code on github?  Perhaps we can collaborate.  I am doing a 
bit of windows type and provider development currently (mostly learning how 
;)  I have a pendinga windows clustering provider, and a windows ad dns 
provider in the works.   I have also wrote a chocolatey provider that we 
are now officially using on 100s of servers.
 

On Monday, January 28, 2013 5:01:10 PM UTC-5, damian@gmail.com wrote:

> Hi Josh,
>
> First of all thanks for the quick reply.  
>
> The main priorities to make Puppet usable on Windows for us would be:
>
> 1> Control complete state of the DACL for grant (we don't use deny).
> 2> Control inheritance on DACL (at the same time as being able to control 
> other DACL grant entries for that object).
> 3> Control inheritance on SACL (we only set this at a higher level).
> 4> Set user account on Service.
>
> It would also be good to have the following (although don't think it would 
> be a showstopper for adoption):
> 5> Control ACL on local SMB shares.
> 6> Control ACL on registry.
>
> And finally the nice to haves:
> 7> (Nice to have) Set DACL on parent directory but inherit permissions on 
> all children when using source param with multiple levels of hierarchy.
> 8> (Nice to have) Set DACL on parent directory but inherit permissions on 
> all children when using recurse param.
>
> Off the top of my head (not fully worked out all our requirements with the 
> devs yet) I don't think we control access to any other types of windows 
> object (e.g. service)
>
> I did start having a dig in the Puppet code for the file type and all of 
> the building blocks are already there. I'm not sure how much effort it 
> would be to write an ntfsfile class but I have started having a play with 
> writing my own (in my spare time) but I've never written Ruby before so a 
> reasonable learning curve (not least just to understand the mass of file 
> and windows provider Puppet code let alone Ruby!). The permission setting 
> methods are all there (e.g. set_acl and get_acl from security.rb including 
> the protected parameter that i couldn't see a way of setting anywhere).  My 
> plan was to replace the mode param on file.rb with a dacl param that could 
> take some form of friendly dacl description.  The get_mode and set_mode 
> methods could then be changed to translate between friendly dacl and real 
> dacl rather than POSIX mode and dacl.
>
> The friendly DACL would use something like the following to describe each 
> ACE:
>  ntfsfile { 'myfile.txt' :
> require => file,
> dacl => [ 
>   ['user1', grant, [FULL_CONTROL]],
>   ['user2', grant, [FILE_READ]],
>   ['group1', grant, [FILE_READ, FILE_WRITE, 
> CHANGE_PERMISSIONS]],
>   ['user3', deny, [FILE_READ, FILE_WRITE, FILE_EXECUTE]]
>  ],
> inheritparent => false,
> source => 'puppet://modules/something/file.txt',
> }
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Referencing a variable from one class in another