Re: [Puppet Users] Re: puppet-dashboard Explorer 8

[John Warburton]

On 13 August 2010 18:59, ScubaDude  wrote:

> Ticket filed (bug, refactor)
>
> On Aug 13, 7:56 am, Matt Robinson  wrote:
> > We weren't aware as none of us are using Internet Explorer.  We'll
> > have to have someone get a copy to test with at some point.
> >
> > Can you file a ticket?
> >
> > http://projects.puppetlabs.com
> >
> > Thanks,
> > Matt
> >
> > On Thu, Aug 12, 2010 at 6:40 AM, ScubaDude 
> wrote:
> > > puppet-dashboard on internet exploder 8:
> >
> > > Layout borked and no graphs?
> > > I was wondering if you were aware of this?
>

Am I the only other person interested in this?
https://projects.puppetlabs.com/issues/4530

Its driving our managers nuts to copy & paste URLs from email to Firefox (if
they have it) rather than just clicking on the dashboard URL and having it
work with the corporate SOE

Please "watch" this ticket if you are interested

Thanks

John

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

Re: [Puppet Users] Wrong module path when using external nodes vs. CLI args

[Brian Cully]

On Mar 22, 2011, at 19:21, Thomas Bellman  wrote:

> https://projects.puppetlabs.com/issues/3910

Thanks. I can try to work around it for now and watch the ticket for a 
resolution.

-bjc

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

Re: [Puppet Users] RFC: Refactoring the mount provider.

[Nigel Kersten]

On Tue, Mar 22, 2011 at 4:05 PM, Stefan Schulte
 wrote:

> So splitting the mounttype can lead to better reports when puppet sync
> mountpoint and entry in fstab seperatly. Because I'm lazy I'll propably
> write a define (maybe I will call it mount) that will create two
> resources for the two new types.

If we did decide to make this change, we would probably try to get
such a define/wrapped type that preserved existing semantics into core
as well, so people could choose to use it.

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

Re: [Puppet Users] Wrong module path when using external nodes vs. CLI args

[Thomas Bellman]

Brian Cully wrote:


When I run puppet with --environment=development everything works
great. When I use my external none classifier which sets the
environment, for some reason, puppet uses the wrong module path
for file references even though my puppetmasterd log shows that
it compiled the catalog for development (just like it does when
I set the environment on the CLI).

I can tell things aren't working because, while it gets the right
catalog, the files it downloads are from the production modules.


Known bug: the node classifier is only run when the client
requests the catalog, not when it is downloading files.  Thus
when the client wants to fetch a file, the master blindly
trusts the client and gives it the file from the environment
the client says it wants (and if you haven't explicitly set
the environment with --environment or in puppet.conf on the
client, it will default to "production").

https://projects.puppetlabs.com/issues/3910

The only workaround is to set the environment on the client.
But if you do that correctly, there is no need to have the
external node classifier set the environment as well...


/Bellman

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

Re: [Puppet Users] RFC: Refactoring the mount provider.

[Stefan Schulte]

On Tue, Mar 22, 2011 at 09:19:16PM +0100, Thomas Bellman wrote:
> Nigel Kersten wrote:
> 
> > TL;DR The mount provider has used a mish-mash of checking fstab and
> > actual mount state to determine state. A possible solution we're
> > looking at is splitting into two types, one that manages /etc/fstab
> > (or /etc/filesystem on other OSes), and one that manages actual mount
> > state.
> 
> [Details elided]
> 
> Two separate types is the obviously correct way.  Just like we
> have two separate types for specifying whether a service should
> be started at boot and for whether it should be running right
> now.  And just like we have nine separate types for specifying
> file type, owner, group, mode, content and SElinux parameters.
> 
> ...
> 
> Hey wait, we don't!  We only have one service type and one file
> type, with multiple properties.  Maybe there is some good reason
> for having it like that.  Perhaps like not requiring users to
> repeat the same things (service name; file path; mount-point and
> device) for things that very, very often go together.
> 
> So, no, I think splitting the mount type into two types would be
> a bad choice.
> 
> Splitting the 'ensure' parameter of the mount type into two, on
> the other hand, I think is a very good idea.
> 
> The nice way to transition would be to have two entirely new
> parameters, let's provisionally call them 'mount_state' and
> 'fstab_state', and in 2.7 have the 'ensure' parameter translated
> into those two new parameters with a warning about that syntax
> being deprecated, and then in 2.8 remove the 'ensure' parameter
> entirely.  (I actually dislike the names I propose above; they
> are just examples for the sake of discussing the principle.)

I disagree. Lets say you define something like this

mount { '/mnt/foo':
  device  => '/dev/foo',
  options => 'ro',
  mount_state => mounted
  fstab_state => present
}

and lets also say that options is 'ro' in fstab but someone mounted the
device 'rw'. What should puppet report now? Is the »options« property
insync now? If not, what is its current value? ro or rw? What if its the
other way around? Wrong entry in fstab but correctly mounted?

Yes you have to specify device etc two times. Yes I want '/dev/foo' in
fstab and yes surprisingly I also want to actually mount '/dev/foo'. But
that makes sense because you also have two is-states (current device in
fstab and current device that is mounted on /mnt/foo).

So splitting the mounttype can lead to better reports when puppet sync
mountpoint and entry in fstab seperatly. Because I'm lazy I'll propably
write a define (maybe I will call it mount) that will create two
resources for the two new types.
>   /Bellman
> 
-Stefan


pgpXwsPL2Uhe1.pgp
Description: PGP signature

[Puppet Users] Wrong module path when using external nodes vs. CLI args

[Brian Cully]

I've started using the environment capabilities with puppet and set up a 
[development] environment which points the modulepath to 
/etc/puppet/development/modules. The [main] section puts it in 
/etc/puppet/modules.

When I run puppet with --environment=development everything works great. When I 
use my external none classifier which sets the environment, for some reason, 
puppet uses the wrong module path for file references even though my 
puppetmasterd log shows that it compiled the catalog for development (just like 
it does when I set the environment on the CLI).

I can tell things aren't working because, while it gets the right catalog, the 
files it downloads are from the production modules.

Any hints?

-bjc

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

Re: [Puppet Users] RFC: Splitting up the file{} type functionality.

[Nigel Kersten]

On Tue, Mar 22, 2011 at 3:06 PM, Christian Kauhaus  wrote:
> Am 22.03.2011 02:53, schrieb Nigel Kersten:
>>
>> The intersection of files and directories isn't that big a deal, but
>> we could split out directories too if we wanted.
>
> From the user's perspective, it's more like the other way round. We should
> not let implementation issues guide the design of the manifest language.
> Files and directories are different concepts, but symlinks to either files
> or directories are handled mostly transparently.
>
> I would rather suggest a File and a Directory type. Both types should share
> basic attributes like owner/mode etc and both should support symlinks. Each
> one has unique attributes: files should support source/content, while
> directories should support the recursive copy feature.

If you're enabling recursive copies for Directories, then you're also
supporting the 'source' property, and you're also supporting the
"links => {follow, manage, ignore}" parameter and recurse and
recurselimit

I don't think this gets us to a significantly better position for the user.

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

Re: [Puppet Users] RFC: Splitting up the file{} type functionality.

[Christian Kauhaus]

Am 22.03.2011 02:53, schrieb Nigel Kersten:

The intersection of files and directories isn't that big a deal, but
we could split out directories too if we wanted.


From the user's perspective, it's more like the other way round. We should 
not let implementation issues guide the design of the manifest language. Files 
and directories are different concepts, but symlinks to either files or 
directories are handled mostly transparently.


I would rather suggest a File and a Directory type. Both types should share 
basic attributes like owner/mode etc and both should support symlinks. Each 
one has unique attributes: files should support source/content, while 
directories should support the recursive copy feature.


Regards

Christian

--
Dipl.-Inf. Christian Kauhaus <>< · k...@gocept.com · systems administration
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 11 · fax +49 345 1229889 1
Zope and Plone consulting and development

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

RE: [Puppet Users] augeas slooow

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

Oho, this --evaltrace is what I was looking for. Thanks!

> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Nigel Kersten
> Sent: Tuesday, March 22, 2011 4:40 PM
> To: puppet-users@googlegroups.com
> Cc: saurabh verma
> Subject: Re: [Puppet Users] augeas slooow
> 
> On Tue, Mar 22, 2011 at 1:24 PM, saurabh verma

> wrote:
> >>
> >>
> >> How can I profile my Puppet catalog, to see what resources take the
> >> longest to set straight? (I've only got puppet apply for now - no
> master
> >> yet)
> >>
> >> --
> >
> > +1 for profiling feature
> 
> More than --evaltrace ?
> 
> 
> 
> 
> >
> > --
> > 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.
> >
> >
> 
> 
> 
> --
> Nigel Kersten
> Product, Puppet Labs
> @nigelkersten
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to puppet-
> users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

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

Re: [Puppet Users] augeas slooow

[Nigel Kersten]

On Tue, Mar 22, 2011 at 1:24 PM, saurabh verma  wrote:
>>
>>
>> How can I profile my Puppet catalog, to see what resources take the
>> longest to set straight? (I've only got puppet apply for now - no master
>> yet)
>>
>> --
>
> +1 for profiling feature

More than --evaltrace ?




>
> --
> 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.
>
>



-- 
Nigel Kersten
Product, Puppet Labs
@nigelkersten

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

Re: [Puppet Users] Testing changes before deployment

[Christopher Webber]

I actually wrote up a post about using multiple environments for this
purpose. It includes the process flow chart as well.

http://cwebber.ucr.edu/2011/03/multiple-environments-in-puppet/

--cwebber

On 3/22/11 2:10 PM, "Thomas Bellman"  wrote:

>Giovanni Bordello wrote:
>
>> But what if I need to do a web-server specific change? And then
>> Mail-server specific change? If I had only one test client machine I
>> would have to reinstall it every time I needed to do verify a change
>>for 
>> a different group of servers. That's hardly a way to go. There must be
>>a 
>> better approach.
>> 
>> How do you guys test puppet changes before they go live?
>
>First of all, we do have multiple environments, so we can test
>new versions of the manifests before taking them into production.
>There is of course the an environment named "production" which
>clients are usually running from.  Then each sysadmin has their
>own personal environment, and some of us have multiple personal
>environments.  We do our changes in our personal environment,
>test them, and when we feel they are ready, we push them to the
>central Git repository, and then do a 'git pull' in the production
>environment.  I highly recommend this.
>
>Our approach to test machines vary a bit depending on how extensive,
>invasive and risky changes we are making.  If I'm doing something
>small and simple, like adding a member to a mail alias on the email
>server, I just do that, commit, push, pull and let puppetd on the
>email server do its job.  (Since I only run puppetd every fourth
>hour, not every thirty minutes, I might do a manual run of puppetd
>to apply my change quicker.)
>
>For somewhat larger changes, but changes where I feel the risk of
>actually harming the server is very low, I would first run puppetd
>manually in no-op mode on the live client against my environment.
>If that looks okay, I will then run puppetd again and let it do its
>changes, and then I test that my changes work as I intended.  If
>they don't, then I revert them (usually manually), and go back to
>fixing my manifests.
>
>When the risk gets higher, or if I think something will take me
>some time to implement, I install a test server.  That will usually
>be a Xen guest.  I make a new node definition in my manifests that
>is a copy of the real server I want to change, except that it has
>different hostname, IP address, and MAC address.  Then I install
>CentOS on that with kickstart (ca 5 minutes), and run Puppet on
>it (less than 15 minutes).  I have Puppet generate Xen config
>files and a kickstart file for the test machine on the Xen host,
>so it is fairly painless.  I do need to manually create the LVM
>volumes for the virtual disks, but all in all I can easily have
>a clone of server up and running in 30 minutes, including adding
>the test machine to DNS and DHCP, installing OS on it and running
>Puppet on it.
>
>When I have my test server up and running, I do all my testing
>on that.  When I'm close to finished with extensive changes, I
>often re-install my test server from scratch to check that
>everything really works.  Often I find that they don't (typically
>some missed dependencies) and have to fix that, and then I do
>a new re-install.
>
>Since virtual servers are fairly cheap (and I can often give
>them less CPU, memory and disk than the real server needs), I
>sometimes have several such test servers running, if I am doing
>work on several different features at the same time.  (That would
>typically be because I started on doing something, then some
>other change with higher priority came up and I had to put my
>original work aside for a few days or weeks.)
>
>
>Where the limit is for something you dare test directly on live
>production servers, would vary between organisations.  We can
>usually tolerate the occasional unplanned downtime if they are
>short enough, so I probably have a higher threshold than many
>others before I install a separate test machine.
>
>But regardless of how high risks you can take with your production
>machines, I heartily recommend that you make it easy to create and
>install test machines.  Virtualization is really nice for that.
>
>
>/Bellman
>
>-- 
>You received this message because you are subscribed to the Google Groups
>"Puppet Users" group.
>To post to this group, send email to puppet-users@googlegroups.com.
>To unsubscribe from this group, send email to
>puppet-users+unsubscr...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/puppet-users?hl=en.
>


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

Re: [Puppet Users] Testing changes before deployment

[Thomas Bellman]

Giovanni Bordello wrote:

But what if I need to do a web-server specific change? And then 
Mail-server specific change? If I had only one test client machine I 
would have to reinstall it every time I needed to do verify a change for 
a different group of servers. That's hardly a way to go. There must be a 
better approach.


How do you guys test puppet changes before they go live?


First of all, we do have multiple environments, so we can test
new versions of the manifests before taking them into production.
There is of course the an environment named "production" which
clients are usually running from.  Then each sysadmin has their
own personal environment, and some of us have multiple personal
environments.  We do our changes in our personal environment,
test them, and when we feel they are ready, we push them to the
central Git repository, and then do a 'git pull' in the production
environment.  I highly recommend this.

Our approach to test machines vary a bit depending on how extensive,
invasive and risky changes we are making.  If I'm doing something
small and simple, like adding a member to a mail alias on the email
server, I just do that, commit, push, pull and let puppetd on the
email server do its job.  (Since I only run puppetd every fourth
hour, not every thirty minutes, I might do a manual run of puppetd
to apply my change quicker.)

For somewhat larger changes, but changes where I feel the risk of
actually harming the server is very low, I would first run puppetd
manually in no-op mode on the live client against my environment.
If that looks okay, I will then run puppetd again and let it do its
changes, and then I test that my changes work as I intended.  If
they don't, then I revert them (usually manually), and go back to
fixing my manifests.

When the risk gets higher, or if I think something will take me
some time to implement, I install a test server.  That will usually
be a Xen guest.  I make a new node definition in my manifests that
is a copy of the real server I want to change, except that it has
different hostname, IP address, and MAC address.  Then I install
CentOS on that with kickstart (ca 5 minutes), and run Puppet on
it (less than 15 minutes).  I have Puppet generate Xen config
files and a kickstart file for the test machine on the Xen host,
so it is fairly painless.  I do need to manually create the LVM
volumes for the virtual disks, but all in all I can easily have
a clone of server up and running in 30 minutes, including adding
the test machine to DNS and DHCP, installing OS on it and running
Puppet on it.

When I have my test server up and running, I do all my testing
on that.  When I'm close to finished with extensive changes, I
often re-install my test server from scratch to check that
everything really works.  Often I find that they don't (typically
some missed dependencies) and have to fix that, and then I do
a new re-install.

Since virtual servers are fairly cheap (and I can often give
them less CPU, memory and disk than the real server needs), I
sometimes have several such test servers running, if I am doing
work on several different features at the same time.  (That would
typically be because I started on doing something, then some
other change with higher priority came up and I had to put my
original work aside for a few days or weeks.)


Where the limit is for something you dare test directly on live
production servers, would vary between organisations.  We can
usually tolerate the occasional unplanned downtime if they are
short enough, so I probably have a higher threshold than many
others before I install a separate test machine.

But regardless of how high risks you can take with your production
machines, I heartily recommend that you make it easy to create and
install test machines.  Virtualization is really nice for that.


/Bellman

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

Re: [Puppet Users] Re: parameterized classes and variable inheritance

[Ashley Gould]

On Mon, Mar 21, 2011 at 01:05:56PM -0700, jcbollinger wrote:
> 
> On Mar 21, 1:20 pm, Ashley Gould  wrote:
> > Please forgive my ignorance.  I find myself, a linux admin brought
> > up on howtos and books with animals on the cover, suddenly plunged
> > by puppet into a world of developers and computer scientists.  Could
> > you explain what is "idempotency" and "support for multiple inclusion"?
> 
> Sorry, my bad.  The point is that you can include an ordinary class
> multiple times on the same node (multiple inclusion), and the result
> is exactly the same as if that class were included only once
> (idempotency).  This can be important in a deep node inheritance
> hierarchy, but it is more commonly important in situations where
> classes include other classes.
> 
> For example, a common Puppet idiom is to create a "user" module
> containing a "user::virtual" class in which virtual user resources are
> declared for all system users.  Other classes then make decisions
> about which users should actually be present on the system by
> realizing subsets of those users (via Puppet's "realize" function or
> <| |> syntax).  In my case, users are assigned to various research
> groups, so I have a class for each group that realizes the users
> associated with that group.  But those classes can only work if the
> user::virtual class is included in the node's catalog.  It would be
> possible to address that problem by ensuring that each node explicitly
> includes "user::virtual", but that's clunky and subject to breakage.
> Instead, it's better for each class that wants to realize users to
> *itself* include user::virtual, which is possible and completely safe
> provided that user::virtual is not parameterized.
> 
> Parameterized classes, on the other hand, can be included only once
> per node, no matter what.  This is a substantial limitation on where
> and how such classes can be used.
> 
> I hope that helps.
> 

This helps bigtime.  Thanks to all for the wonderful comments on this
thread.  I am much more clear on a lot of things.

I have (for now) solved my issue by using a combination of regular and
param classes and scraping the node inheritance:

class sudoers {

import "rules.pp"

define make_sudoers($default_rules, $extra_rules) {

file { "/tmp/sudoers":
owner   => root, group => root, mode => 440,
content => template("sudoers/sudoers.erb"),
notify  => Exec["check-sudoers"],
}
exec { "check-sudoers":
command => "/usr/sbin/visudo -cf /tmp/sudoers && \
cp /tmp/sudoers /etc/sudoers",
refreshonly => true,
}
}

make_sudoers {"default":
default_rules=> "$rules_unixgroup",
extra_rules => [ "" ],
}

}


class sudoers_extras($rules) inherits sudoers {
Sudoers::Make_sudoers['default'] { extra_rules => $rules }
}


class common {
include "sudoers"
}


node 'sl11lab02-vhost.ucop.edu' {
include "common"
class { sudoers_extras: rules => [ "$rules_aig" ] }
}


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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[James Turnbull]

Ohad Levy wrote:
> Hello All,
> 
> I'm happy to announce a new release candidate of Foreman, top highlights
> for this release includes:
> 

Ohad

Awesome stuff. Just had a play with it and very impressed.

Cheers

James

-- 
James Turnbull
Puppet Labs
1-503-734-8571

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Mohamed Lrhazi]

I replaced all shbangs in the tarball, with REE, still no go! what
binary would be liked to /usr/bin/ruby in the forman tree?

cd /usr/src/redhat/SOURCES
tar jzvf foreman-0.2rc1.tar.bz2
cd forman
grep -lr '#!/usr/bin/env ruby' . | xargs  sed -i -e 's|/usr/bin/env
ruby|/opt/ruby-enterprise/bin/ruby|'
grep -lr '#!/usr/bin/ruby' . | xargs  sed -i -e
's|/usr/bin/ruby|/opt/ruby-enterprise/bin/ruby|'
cd ..
rm foreman-0.2rc1.tar.bz2
tar jcf foreman-0.2rc1.tar.bz2 foreman
cd ../SPECS/
rpmbuild  -bb foreman.spec

still: /usr/bin/ruby ends up in the deps

Provides: config(foreman) = 0.2-rc1.1
Requires(interp): /bin/sh /bin/sh /bin/sh /bin/sh /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires(pre): /bin/sh shadow-utils
Requires(post): /bin/sh chkconfig
Requires(preun): /bin/sh chkconfig initscripts
Requires(postun): /bin/sh initscripts
Requires: /bin/bash /bin/sh /bin/sh /opt/ruby-enterprise/bin/ruby
/usr/bin/env /usr/bin/make /usr/bin/ruby config(foreman) = 0.2-rc1.1
ruby-enterprise ruby-enterprise-rubygem-json_pure
ruby-enterprise-rubygem-rake ruby-enterprise-rubygems
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/var/tmp/foreman-0.2-rc1.1-root-root
Wrote: /usr/src/redhat/RPMS/noarch/foreman-0.2-rc1.1.noarch.rpm


On Tue, Mar 22, 2011 at 4:23 PM, Eduardo S. Scarpellini
 wrote:
> RPM checks the linked libraries (ldd) and some shbangs (#!) in buildtime
> (rpmbuild).
> These deps could came from these ruby-ee shbang paths.
>
> On Mar 22, 2011 5:14 PM, "Mohamed Lrhazi"  wrote:
>> am trying to rebuild the source rpm to remove deps on ruby, as i use
>> entreprise-ruby...
>> the resulting rpm still instisi it needs ruby... were does that dep come
>> from?
>>
>> during install:
>>
>> Resolving Dependencies
>> --> Running transaction check
>> ---> Package foreman.noarch 0:0.2-rc1.1 set to be updated
>> --> Processing Dependency: /usr/bin/ruby for package: foreman
>>
>> The spec file I used was changed to:
>>
>> Requires: ruby-enterprise
>> Requires: ruby-enterprise-rubygems
>> Requires: ruby-enterprise-rubygem-rake
>> #Requires: puppet >= 0.24.4
>> #Requires: rubygem(sqlite3-ruby)
>> #Requires: rubygem(rest-client)
>> Requires: ruby-enterprise-rubygem-json_pure
>> Requires(pre): shadow-utils
>> Requires(post): chkconfig
>> Requires(preun): chkconfig
>> Requires(preun): initscripts
>> Requires(postun): initscripts
>>
>>
>> Thanks a lot.
>> Mohamed.
>>
>>
>>
>> On Tue, Mar 22, 2011 at 11:21 AM, Ohad Levy  wrote:
>>> Hello All,
>>>
>>> I'm happy to announce a new release candidate of Foreman, top highlights
>>> for this release includes:
>>>
>>> * New look and feel
>>> * Extended restful API
>>> * Support for New Puppet Reports format
>>> * Full VM/physical host Provisioning
>>> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
>>> etc..)
>>> * introduce a new service called smart proxy (which can run on remote
>>> machines) to manage the following services:
>>>  ** DNS Management
>>>  ** DHCP Management
>>>  ** TFTP Management
>>>  ** Puppet/PuppetCA Management
>>>
>>> This release is a major release packed with goodies, around 130 tickets
>>> were closed
>>>
>>> Release notes can be found here:
>>> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
>>>
>>> Full change log can be found here: http://theforeman.org/versions/show/9
>>>
>>> As usually many many thanks to all contributors and users
>>>
>>> RPMS for both smart proxy and foreman can be found at
>>> http://yum.theforeman.org/test
>>>
>>> Have fun,
>>> Ohad
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

-- 
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://g

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Cody Robertson]

On 03/22/2011 04:32 PM, Ohad Levy wrote:



On Tue, Mar 22, 2011 at 10:28 PM, Cody Robertson > wrote:


On 03/22/2011 04:23 PM, Ohad Levy wrote:


On Tue, Mar 22, 2011 at 10:04 PM, Eduardo S. Scarpellini
mailto:scarpell...@gmail.com>> wrote:

Super cool, Ohad.
Is there a RPM for this RC?

http://yum.theforeman.org/test/RPMS/foreman-0.2-rc1.1.noarch.rpm


The version of rubygem-rest-client in EPEL is 1.3.1 however the
the new version requires 1.4.0. Maybe update the spec file / RPM
to reflect this?

Thanks for the reminder :-)

I guess I was not sure what would be better, a failure to install 
foreman on RHEL5 (as the package is missing) or a failure when 
starting foreman.


I know (and its in the release notes), I've asked the upstream 
maintainer in EPEL to update the package, but if that won't be 
provided, I guess we could try to provide a newer version in foreman's 
repo.


The current behavior isn't nice at all assuming people are using the 
init script provided - it just doesn't start up but provides no logs / 
output that I can tell. I only noticed when manually starting up WEBrick.


The current client is 1.6.1 so hopefully upstream just updates it :).

--
Cody Robertson 1-800-859-8803 ext. 5

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Ohad Levy]

On Tue, Mar 22, 2011 at 10:23 PM, Ohad Levy  wrote:

>
>
> On Tue, Mar 22, 2011 at 10:04 PM, Eduardo S. Scarpellini <
> scarpell...@gmail.com> wrote:
>
>> Super cool, Ohad.
>> Is there a RPM for this RC?
>>
> http://yum.theforeman.org/test/RPMS/foreman-0.2-rc1.1.noarch.rpm
>
> Ohad
>

Note that the latest RPM for the smart proxy is actually in the stable repo
-
 http://yum.theforeman.org/stable/RPMS/foreman-proxy-0.1-1.noarch.rpm

Ohad

>  On Mar 22, 2011 4:52 PM, "Martin Willemsma"  wrote:
>> > Thanks guys. Really cool new features to try out tomorrow!
>> >
>> > I would love to see the unattended installation part replace our
>> deployer
>> > solution which is currently installing hosts 1 by 1.
>> >
>> > --
>> > Kind regards,
>> >
>> > Martin Willemsma
>> >
>> >
>> > 2011/3/22 Ohad Levy 
>> >
>> >> Hello All,
>> >>
>> >> I'm happy to announce a new release candidate of Foreman, top
>> highlights
>> >> for this release includes:
>> >>
>> >> * New look and feel
>> >> * Extended restful API
>> >> * Support for New Puppet Reports format
>> >> * Full VM/physical host Provisioning
>> >> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed,
>> grub
>> >> etc..)
>> >> * introduce a new service called smart proxy (which can run on remote
>> >> machines) to manage the following services:
>> >> ** DNS Management
>> >> ** DHCP Management
>> >> ** TFTP Management
>> >> ** Puppet/PuppetCA Management
>> >>
>> >> This release is a major release packed with goodies, around 130 tickets
>> >> were closed
>> >>
>> >> Release notes can be found here:
>> >> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
>> >>
>> >> Full change log can be found here:
>> http://theforeman.org/versions/show/9
>> >>
>> >> As usually many many thanks to all contributors and users
>> >>
>> >> RPMS for both smart proxy and foreman can be found at
>> >> http://yum.theforeman.org/test
>> >>
>> >> Have fun,
>> >> Ohad
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Puppet Users" group.
>> >> To post to this group, send email to puppet-users@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> puppet-users+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/puppet-users?hl=en.
>> >>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Puppet Users" group.
>> > To post to this group, send email to puppet-users@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
>

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Ohad Levy]

On Tue, Mar 22, 2011 at 10:28 PM, Cody Robertson  wrote:

>  On 03/22/2011 04:23 PM, Ohad Levy wrote:
>
>
> On Tue, Mar 22, 2011 at 10:04 PM, Eduardo S. Scarpellini <
> scarpell...@gmail.com> wrote:
>
>> Super cool, Ohad.
>> Is there a RPM for this RC?
>>
> http://yum.theforeman.org/test/RPMS/foreman-0.2-rc1.1.noarch.rpm
>
>
> The version of rubygem-rest-client in EPEL is 1.3.1 however the the new
> version requires 1.4.0. Maybe update the spec file / RPM to reflect this?
>
> Thanks for the reminder :-)

I guess I was not sure what would be better, a failure to install foreman on
RHEL5 (as the package is missing) or a failure when starting foreman.

I know (and its in the release notes), I've asked the upstream maintainer in
EPEL to update the package, but if that won't be provided, I guess we could
try to provide a newer version in foreman's repo.





> --
> Cody Robertson 1-800-859-8803 ext. 5
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Cody Robertson]

On 03/22/2011 04:23 PM, Ohad Levy wrote:


On Tue, Mar 22, 2011 at 10:04 PM, Eduardo S. Scarpellini 
mailto:scarpell...@gmail.com>> wrote:


Super cool, Ohad.
Is there a RPM for this RC?

http://yum.theforeman.org/test/RPMS/foreman-0.2-rc1.1.noarch.rpm


The version of rubygem-rest-client in EPEL is 1.3.1 however the the new 
version requires 1.4.0. Maybe update the spec file / RPM to reflect this?


--
Cody Robertson 1-800-859-8803 ext. 5

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Ohad Levy]

On Tue, Mar 22, 2011 at 10:04 PM, Eduardo S. Scarpellini <
scarpell...@gmail.com> wrote:

> Super cool, Ohad.
> Is there a RPM for this RC?
>
http://yum.theforeman.org/test/RPMS/foreman-0.2-rc1.1.noarch.rpm

Ohad

> On Mar 22, 2011 4:52 PM, "Martin Willemsma"  wrote:
> > Thanks guys. Really cool new features to try out tomorrow!
> >
> > I would love to see the unattended installation part replace our deployer
> > solution which is currently installing hosts 1 by 1.
> >
> > --
> > Kind regards,
> >
> > Martin Willemsma
> >
> >
> > 2011/3/22 Ohad Levy 
> >
> >> Hello All,
> >>
> >> I'm happy to announce a new release candidate of Foreman, top highlights
> >> for this release includes:
> >>
> >> * New look and feel
> >> * Extended restful API
> >> * Support for New Puppet Reports format
> >> * Full VM/physical host Provisioning
> >> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
> >> etc..)
> >> * introduce a new service called smart proxy (which can run on remote
> >> machines) to manage the following services:
> >> ** DNS Management
> >> ** DHCP Management
> >> ** TFTP Management
> >> ** Puppet/PuppetCA Management
> >>
> >> This release is a major release packed with goodies, around 130 tickets
> >> were closed
> >>
> >> Release notes can be found here:
> >> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
> >>
> >> Full change log can be found here:
> http://theforeman.org/versions/show/9
> >>
> >> As usually many many thanks to all contributors and users
> >>
> >> RPMS for both smart proxy and foreman can be found at
> >> http://yum.theforeman.org/test
> >>
> >> Have fun,
> >> Ohad
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Puppet Users" group.
> >> To post to this group, send email to puppet-users@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> puppet-users+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/puppet-users?hl=en.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Eduardo S. Scarpellini]

RPM checks the linked libraries (ldd) and some shbangs (#!) in buildtime
(rpmbuild).
These deps could came from these ruby-ee shbang paths.
On Mar 22, 2011 5:14 PM, "Mohamed Lrhazi"  wrote:
> am trying to rebuild the source rpm to remove deps on ruby, as i use
> entreprise-ruby...
> the resulting rpm still instisi it needs ruby... were does that dep come
from?
>
> during install:
>
> Resolving Dependencies
> --> Running transaction check
> ---> Package foreman.noarch 0:0.2-rc1.1 set to be updated
> --> Processing Dependency: /usr/bin/ruby for package: foreman
>
> The spec file I used was changed to:
>
> Requires: ruby-enterprise
> Requires: ruby-enterprise-rubygems
> Requires: ruby-enterprise-rubygem-rake
> #Requires: puppet >= 0.24.4
> #Requires: rubygem(sqlite3-ruby)
> #Requires: rubygem(rest-client)
> Requires: ruby-enterprise-rubygem-json_pure
> Requires(pre): shadow-utils
> Requires(post): chkconfig
> Requires(preun): chkconfig
> Requires(preun): initscripts
> Requires(postun): initscripts
>
>
> Thanks a lot.
> Mohamed.
>
>
>
> On Tue, Mar 22, 2011 at 11:21 AM, Ohad Levy  wrote:
>> Hello All,
>>
>> I'm happy to announce a new release candidate of Foreman, top highlights
>> for this release includes:
>>
>> * New look and feel
>> * Extended restful API
>> * Support for New Puppet Reports format
>> * Full VM/physical host Provisioning
>> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
>> etc..)
>> * introduce a new service called smart proxy (which can run on remote
>> machines) to manage the following services:
>>  ** DNS Management
>>  ** DHCP Management
>>  ** TFTP Management
>>  ** Puppet/PuppetCA Management
>>
>> This release is a major release packed with goodies, around 130 tickets
>> were closed
>>
>> Release notes can be found here:
>> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
>>
>> Full change log can be found here: http://theforeman.org/versions/show/9
>>
>> As usually many many thanks to all contributors and users
>>
>> RPMS for both smart proxy and foreman can be found at
>> http://yum.theforeman.org/test
>>
>> Have fun,
>> Ohad
>>
>> --
>> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>

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

Re: [Puppet Users] augeas slooow

[saurabh verma]

> 
> 
> How can I profile my Puppet catalog, to see what resources take the
> longest to set straight? (I've only got puppet apply for now - no master
> yet)
> 
> -- 

+1 for profiling feature 

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

Re: [Puppet Users] Re: Trying to set up per-environment manifest file

[Mohamed Lrhazi]

I use this pattern:

[master]

templatedir = /etc/puppet/environments/$environment/
modulepath  = /etc/puppet/environments/$environment/modules
manifest= /etc/puppet/environments/$environment/manifests/site.pp
manifestdir = /etc/puppet/environments/$environment/manifests




On Tue, Mar 22, 2011 at 3:52 PM, elliott  wrote:
> Thanks Cody.
>
> The client's environment does need to be set, either through the
> puppet.conf or on the command line, but the environments also need to
> be defined on the master, as far as I know.
>
> On Mar 22, 12:46 pm, Cody Robertson  wrote:
>> On 03/22/2011 03:41 PM, elliott wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > Hi guys,
>>
>> > I've had separate development/testing environments partially working
>> > for a while, in that modules get pulled from the correct per-
>> > environment path.  However, something that has never seemed to work
>> > was a per-environment manifest.  I have more need for this now so I'd
>> > like to track it down.
>>
>> > Here is the relevant part of my puppet.conf file:
>>
>> > [puppetmasterd]
>> > modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules
>> > environments=production,testing,development
>>
>> > [production]
>> > manifest = /etc/puppet/manifests/site.pp
>> > modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules
>>
>> > [testing]
>> > manifest = /etc/puppet/testing/manifests/site.pp
>> > modulepath = /etc/puppet/testing/modules:/etc/puppet/modules:/usr/
>> > share/puppet:/var/lib/modules
>>
>> > [development]
>> > manifest = /etc/puppet/development/manifests/site.pp
>> > modulepath = /etc/puppet/development/modules:/etc/puppet/modules:/usr/
>> > share/puppet:/var/lib/modules
>>
>> > I've added some notify's to each of the site.pp files mentioned, and
>> > sure enough it is always ending up in production.
>>
>> > Any clues?  Anyone else have this working?
>>
>> > Thanks in advance!
>>
>> I don't personally use these however by glancing at the doc it appears
>> you specify the environment on the agent and not the master?
>>
>> http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environ...
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>
>

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

Re: [Puppet Users] RFC: Refactoring the mount provider.

[Thomas Bellman]

Nigel Kersten wrote:


TL;DR The mount provider has used a mish-mash of checking fstab and
actual mount state to determine state. A possible solution we're
looking at is splitting into two types, one that manages /etc/fstab
(or /etc/filesystem on other OSes), and one that manages actual mount
state.


[Details elided]

Two separate types is the obviously correct way.  Just like we
have two separate types for specifying whether a service should
be started at boot and for whether it should be running right
now.  And just like we have nine separate types for specifying
file type, owner, group, mode, content and SElinux parameters.

...

Hey wait, we don't!  We only have one service type and one file
type, with multiple properties.  Maybe there is some good reason
for having it like that.  Perhaps like not requiring users to
repeat the same things (service name; file path; mount-point and
device) for things that very, very often go together.

So, no, I think splitting the mount type into two types would be
a bad choice.

Splitting the 'ensure' parameter of the mount type into two, on
the other hand, I think is a very good idea.

The nice way to transition would be to have two entirely new
parameters, let's provisionally call them 'mount_state' and
'fstab_state', and in 2.7 have the 'ensure' parameter translated
into those two new parameters with a warning about that syntax
being deprecated, and then in 2.8 remove the 'ensure' parameter
entirely.  (I actually dislike the names I propose above; they
are just examples for the sake of discussing the principle.)


/Bellman

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

Re: [Puppet Users] RFC: Splitting up the file{} type functionality.

[Charles Johnson]

What initially attracted me to puppet wast that puppet described state and
not (in general) actions to achieve that state. Yet, I, too, was initially
confued that to manage symlinks I needed to manage "files" which had
something to "ensure" called "symlink". To make sure a directory is absent I
have to use this same "file" approach.

So, +1

Please, let us move to managing symlinks and recursive file copies, but do
look closely at splitting out directories and files as well.

~Charles~

On Mon, Mar 21, 2011 at 8:53 PM, Nigel Kersten  wrote:

> The file{} type can do all of the following:
>
> * manage single files
> * manage directories
> * manage symlinks
> * manage recursive file copies
>
> The intersection of all these bits of functionality makes it difficult
> to understand exactly what is going on when you're new to Puppet, and
> even experienced users often don't know how combining symlinks/content
> management is going to work.
>
> How would people feel about at least splitting out these into their own
> types?
>
> * symlinks
> * recursive file copies
>
> The intersection of files and directories isn't that big a deal, but
> we could split out directories too if we wanted.
>
> Thoughts?
>
>
> --
> Nigel Kersten
> Product, Puppet Labs
> @nigelkersten
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Mohamed Lrhazi]

am trying to rebuild the source rpm to remove deps on ruby, as i use
entreprise-ruby...
the resulting rpm still instisi it needs ruby... were does that dep come from?

during install:

Resolving Dependencies
--> Running transaction check
---> Package foreman.noarch 0:0.2-rc1.1 set to be updated
--> Processing Dependency: /usr/bin/ruby for package: foreman

The spec file I used was changed to:

Requires:   ruby-enterprise
Requires:   ruby-enterprise-rubygems
Requires:   ruby-enterprise-rubygem-rake
#Requires:   puppet >= 0.24.4
#Requires:   rubygem(sqlite3-ruby)
#Requires:   rubygem(rest-client)
Requires:   ruby-enterprise-rubygem-json_pure
Requires(pre):  shadow-utils
Requires(post): chkconfig
Requires(preun): chkconfig
Requires(preun): initscripts
Requires(postun): initscripts


Thanks a lot.
Mohamed.



On Tue, Mar 22, 2011 at 11:21 AM, Ohad Levy  wrote:
> Hello All,
>
> I'm happy to announce a new release candidate of Foreman, top highlights
> for this release includes:
>
> * New look and feel
> * Extended restful API
> * Support for New Puppet Reports format
> * Full VM/physical host Provisioning
> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
> etc..)
> * introduce a new service called smart proxy (which can run on remote
> machines) to manage the following services:
>  ** DNS Management
>  ** DHCP Management
>  ** TFTP Management
>  ** Puppet/PuppetCA Management
>
> This release is a major release packed with goodies, around 130 tickets
> were closed
>
> Release notes can be found here:
> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
>
> Full change log can be found here: http://theforeman.org/versions/show/9
>
> As usually many many thanks to all contributors and users
>
> RPMS for both smart proxy and foreman can be found at
> http://yum.theforeman.org/test
>
> Have fun,
> Ohad
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>
>

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Eduardo S. Scarpellini]

Super cool, Ohad.
Is there a RPM for this RC?
On Mar 22, 2011 4:52 PM, "Martin Willemsma"  wrote:
> Thanks guys. Really cool new features to try out tomorrow!
>
> I would love to see the unattended installation part replace our deployer
> solution which is currently installing hosts 1 by 1.
>
> --
> Kind regards,
>
> Martin Willemsma
>
>
> 2011/3/22 Ohad Levy 
>
>> Hello All,
>>
>> I'm happy to announce a new release candidate of Foreman, top highlights
>> for this release includes:
>>
>> * New look and feel
>> * Extended restful API
>> * Support for New Puppet Reports format
>> * Full VM/physical host Provisioning
>> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
>> etc..)
>> * introduce a new service called smart proxy (which can run on remote
>> machines) to manage the following services:
>> ** DNS Management
>> ** DHCP Management
>> ** TFTP Management
>> ** Puppet/PuppetCA Management
>>
>> This release is a major release packed with goodies, around 130 tickets
>> were closed
>>
>> Release notes can be found here:
>> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
>>
>> Full change log can be found here: http://theforeman.org/versions/show/9
>>
>> As usually many many thanks to all contributors and users
>>
>> RPMS for both smart proxy and foreman can be found at
>> http://yum.theforeman.org/test
>>
>> Have fun,
>> Ohad
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>

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

[Puppet Users] Re: RFC: Splitting up the file{} type functionality.

[jcbollinger]

On Mar 22, 10:10 am, Nigel Kersten  wrote:
> On Tue, Mar 22, 2011 at 7:20 AM, jcbollinger  
> wrote:
>
> > On Mar 21, 8:53 pm, Nigel Kersten  wrote:
> >> The file{} type can do all of the following:
>
> >> * manage single files
> >> * manage directories
> >> * manage symlinks
> >> * manage recursive file copies
>
> >> The intersection of all these bits of functionality makes it difficult
> >> to understand exactly what is going on when you're new to Puppet, and
> >> even experienced users often don't know how combining symlinks/content
> >> management is going to work.
>
> >> How would people feel about at least splitting out these into their own 
> >> types?
>
> >> * symlinks
> >> * recursive file copies
>
> >> The intersection of files and directories isn't that big a deal, but
> >> we could split out directories too if we wanted.
>
> >> Thoughts?
>
> > I agree that File is a mishmash, but I don't think symlinks and
> > recursive copying are the key concepts that would be good to split
> > out.  Instead, I think splitting directories into their own type would
> > be the way to go.
>
> > Consider what would happen if symlinks were made their own type.  What
> > about dependencies?  Right now, I can have
>
> > service { "my_service": require => File["/etc/my_service.conf"] }
>
> > without caring whether File["/etc/my_service.conf"] represents an
> > actual file or a symlink.  I can even change that in the declaration
> > of the file without having to touch anything that depends on it.  If
> > symlinks were modeled via a separate type, however, then I would need
> > everywhere to account for which files were plain and which were
> > symlinks.
>
> That's a really good point. One workaround would be to encapsulate
> such configs into a class and require that.
>
> class foo::service {
>   service { "my_service": require => Class["foo::config"] }
>
> }
>
> class foo::config { ... }
>
> Another would be to flip this around and instead use before instead of
> require, so the service resource wouldn't need to know what kind of
> object is required.


Ok, but the existence of workarounds to the problem doesn't mean there
isn't a problem.  The systems under management draw little distinction
between regular files and symbolic links to files, so at best it would
be quirky for Puppet to draw a substantially larger distinction.  It
is likely that situations would be discovered for which none of the
workarounds is very good.  Instead of solving the problem, you would
merely exchange one set of problems for a different, perhaps smaller,
set.


> > Or look at it from a modelling angle: a symlink to a regular file is
> > much more like a regular file than a directory is like a regular file,
> > so why does it make sense to split out symlinks but not directories?
>
> Because of the clash between defining a symlink and specifying the
> content of a file.
>
> We have edge cases like this:
>
> file { "/tmp/someobject":
>   ensure => present,
>   content => "foo",
>
> }
>
> Now if /tmp/someobject is a symlink (or even a directory), we need to
> special case the code so that we log that the content attribute isn't
> being used.
>
> If it's a file, it will be used.


I'm suggesting that directories get their own type, so they're not
germane here.

I'm also suggesting that the new File type know whether the target is
supposed to be a symlink (which would also trivially be the case if
symlinks were split out), so it would be reasonable for a File
managing a symlink and specifying content to manage the content of the
link target.  That would be pretty natural, in fact.


> It gets worse with the "links" parameter.
>
> file { "/tmp/foo":
>   ensure => present,
>   links => follow,
>   recurse => true,
>   source => "",
>
> }


No it doesn't, because the File type I'm proposing (like the one you
started with) does not manage directories or, therefore, support
recursion.

Moreover, with no ambiguity about whether the managed object is
expected to be a symlink, the "links" property would be unnecessary.


> This does all sorts of weird things depending upon whether the object
> is a symlink, directory or file.
>
> We've had requests to support sockets in the file type too, which
> complicate things further.


More on that below...


> > Parallel arguments can be made about directories and symlinks to
> > directories.
>
> > As for recursive copying, that's an action, not an observable,
> > manageable artifact, so why would it make sense to create a resource
> > type around it?  It could be recast as something like "directory
> > hierarchy", but that begs the question of why it should be separate
> > from ordinary directories.  If you want to think out of the box, then
> > consider re-implementing recursive directory management via a new
> > (type of) function that dynamically adds all the appropriate Directory
> > and File resources to the catalog.  That's anyway what Puppet already
> > does, right?
>
> We have fundamentally differ

[Puppet Users] Re: RFC: Splitting up the file{} type functionality.

[Nigel Kersten]

On Tue, Mar 22, 2011 at 12:39 PM, Jeffrey Goldschrafe
 wrote:
> On Monday, March 21, 2011 9:53:26 PM UTC-4, Nigel Kersten wrote:
>>
>> The file{} type can do all of the following:
>>
>> * manage single files
>> * manage directories
>> * manage symlinks
>> * manage recursive file copies
>>
>> The intersection of all these bits of functionality makes it difficult
>> to understand exactly what is going on when you're new to Puppet, and
>> even experienced users often don't know how combining symlinks/content
>> management is going to work.
>>
>> How would people feel about at least splitting out these into their own
>> types?
>>
>> * symlinks
>> * recursive file copies
>>
>> The intersection of files and directories isn't that big a deal, but
>> we could split out directories too if we wanted.
>>
>> Thoughts?
>>
>> --
>> Nigel Kersten
>> Product, Puppet Labs
>> @nigelkersten
>
> I'm not hugely up-to-date on Puppet internals when it comes to resource name
> resolution, but since they both manage the same underlying object (a path on
> the filesystem), doesn't this introduce the potential issue that someone can
> define a File and a Symlink on the same path, and Puppet will try to manage
> both in no particular order?

If we implemented this badly, yes :)

Seriously though, this is why we have all this functionality in the
one type, but I've come around to the opinion that the user-facing
confusion and pain isn't worth it. We've ended up with difficult code
to maintain and document and spend way too much effort triaging bugs
around it.

Once we've worked out how we want it to behave, we can work out how to
achieve that.





-- 
Nigel Kersten
Product, Puppet Labs
@nigelkersten

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

Re: [Puppet Users] Foreman 0.2 Release Candidate

[Martin Willemsma]

Thanks guys. Really cool new features to try out tomorrow!

I would love to see the unattended installation part replace our deployer
solution which is currently installing hosts 1 by 1.

-- 
Kind regards,

Martin Willemsma


2011/3/22 Ohad Levy 

> Hello All,
>
> I'm happy to announce a new release candidate of Foreman, top highlights
> for this release includes:
>
> * New look and feel
> * Extended restful API
> * Support for New Puppet Reports format
> * Full VM/physical host Provisioning
> * Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
> etc..)
> * introduce a new service called smart proxy (which can run on remote
> machines) to manage the following services:
>  ** DNS Management
>  ** DHCP Management
>  ** TFTP Management
>  ** Puppet/PuppetCA Management
>
> This release is a major release packed with goodies, around 130 tickets
> were closed
>
> Release notes can be found here:
> http://theforeman.org/projects/foreman/wiki/ReleaseNotes
>
> Full change log can be found here: http://theforeman.org/versions/show/9
>
> As usually many many thanks to all contributors and users
>
> RPMS for both smart proxy and foreman can be found at
> http://yum.theforeman.org/test
>
> Have fun,
> Ohad
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

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

[Puppet Users] Re: Trying to set up per-environment manifest file

[elliott]

Thanks Cody.

The client's environment does need to be set, either through the
puppet.conf or on the command line, but the environments also need to
be defined on the master, as far as I know.

On Mar 22, 12:46 pm, Cody Robertson  wrote:
> On 03/22/2011 03:41 PM, elliott wrote:
>
>
>
>
>
>
>
>
>
> > Hi guys,
>
> > I've had separate development/testing environments partially working
> > for a while, in that modules get pulled from the correct per-
> > environment path.  However, something that has never seemed to work
> > was a per-environment manifest.  I have more need for this now so I'd
> > like to track it down.
>
> > Here is the relevant part of my puppet.conf file:
>
> > [puppetmasterd]
> > modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules
> > environments=production,testing,development
>
> > [production]
> > manifest = /etc/puppet/manifests/site.pp
> > modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules
>
> > [testing]
> > manifest = /etc/puppet/testing/manifests/site.pp
> > modulepath = /etc/puppet/testing/modules:/etc/puppet/modules:/usr/
> > share/puppet:/var/lib/modules
>
> > [development]
> > manifest = /etc/puppet/development/manifests/site.pp
> > modulepath = /etc/puppet/development/modules:/etc/puppet/modules:/usr/
> > share/puppet:/var/lib/modules
>
> > I've added some notify's to each of the site.pp files mentioned, and
> > sure enough it is always ending up in production.
>
> > Any clues?  Anyone else have this working?
>
> > Thanks in advance!
>
> I don't personally use these however by glancing at the doc it appears
> you specify the environment on the agent and not the master?
>
> http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environ...

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

Re: [Puppet Users] Trying to set up per-environment manifest file

[Cody Robertson]

On 03/22/2011 03:41 PM, elliott wrote:

Hi guys,

I've had separate development/testing environments partially working
for a while, in that modules get pulled from the correct per-
environment path.  However, something that has never seemed to work
was a per-environment manifest.  I have more need for this now so I'd
like to track it down.

Here is the relevant part of my puppet.conf file:

[puppetmasterd]
modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules
environments=production,testing,development

[production]
manifest = /etc/puppet/manifests/site.pp
modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules

[testing]
manifest = /etc/puppet/testing/manifests/site.pp
modulepath = /etc/puppet/testing/modules:/etc/puppet/modules:/usr/
share/puppet:/var/lib/modules

[development]
manifest = /etc/puppet/development/manifests/site.pp
modulepath = /etc/puppet/development/modules:/etc/puppet/modules:/usr/
share/puppet:/var/lib/modules


I've added some notify's to each of the site.pp files mentioned, and
sure enough it is always ending up in production.

Any clues?  Anyone else have this working?

Thanks in advance!



I don't personally use these however by glancing at the doc it appears 
you specify the environment on the agent and not the master?


http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environments

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

[Puppet Users] Trying to set up per-environment manifest file

[elliott]

Hi guys,

I've had separate development/testing environments partially working
for a while, in that modules get pulled from the correct per-
environment path.  However, something that has never seemed to work
was a per-environment manifest.  I have more need for this now so I'd
like to track it down.

Here is the relevant part of my puppet.conf file:

[puppetmasterd]
modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules
environments=production,testing,development

[production]
manifest = /etc/puppet/manifests/site.pp
modulepath = /etc/puppet/modules:/usr/share/puppet:/var/lib/modules

[testing]
manifest = /etc/puppet/testing/manifests/site.pp
modulepath = /etc/puppet/testing/modules:/etc/puppet/modules:/usr/
share/puppet:/var/lib/modules

[development]
manifest = /etc/puppet/development/manifests/site.pp
modulepath = /etc/puppet/development/modules:/etc/puppet/modules:/usr/
share/puppet:/var/lib/modules


I've added some notify's to each of the site.pp files mentioned, and
sure enough it is always ending up in production.

Any clues?  Anyone else have this working?

Thanks in advance!

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

[Puppet Users] Re: RFC: Splitting up the file{} type functionality.

[Jeffrey Goldschrafe]

On Monday, March 21, 2011 9:53:26 PM UTC-4, Nigel Kersten wrote:
>
> The file{} type can do all of the following:
>
> * manage single files
> * manage directories
> * manage symlinks
> * manage recursive file copies
>
> The intersection of all these bits of functionality makes it difficult
> to understand exactly what is going on when you're new to Puppet, and
> even experienced users often don't know how combining symlinks/content
> management is going to work.
>
> How would people feel about at least splitting out these into their own 
> types?
>
> * symlinks
> * recursive file copies
>
> The intersection of files and directories isn't that big a deal, but
> we could split out directories too if we wanted.
>
> Thoughts?
>
>
> -- 
> Nigel Kersten
> Product, Puppet Labs
> @nigelkersten
>
I'm not hugely up-to-date on Puppet internals when it comes to resource name 
resolution, but since they both manage the same underlying object (a path on 
the filesystem), doesn't this introduce the potential issue that someone can 
define a File and a Symlink on the same path, and Puppet will try to manage 
both in no particular order?

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

Re: [Puppet Users] Listing puppet modules

[hai wu]

Nice, thanks guys ..

On Tue, Mar 22, 2011 at 2:05 PM, Cody Robertson  wrote:

> On 03/22/2011 02:51 PM, hai wu wrote:
>
>> Is there a commond to list all puppet modules applied for a certain node?
>> I tried puppet-concat (motd-register), but it is not working if some
>> puppet module is in some run stage that is before or after "main" run stage.
>> Is there another way to show all puppet modules to be applied for each
>> puppet client?
>> --
>> 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 could perhaps check out the classes.txt file in your $vardir (usually
> /var/lib/puppet).
>
> -Cody Robertson
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

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

Re: [Puppet Users] Listing puppet modules

[Charles Johnson]

Our puppet agent stores classes.txt in /var/puppet/state/

~Charles~

On Tue, Mar 22, 2011 at 1:51 PM, hai wu  wrote:

> Is there a commond to list all puppet modules applied for a certain node?
>
> I tried puppet-concat (motd-register), but it is not working if some puppet
> module is in some run stage that is before or after "main" run stage. Is
> there another way to show all puppet modules to be applied for each puppet
> client?
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

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

Re: [Puppet Users] Re: RFC: Splitting up the file{} type functionality.

[Stefan Schulte]

On Tue, Mar 22, 2011 at 08:10:40AM -0700, Nigel Kersten wrote:
> On Tue, Mar 22, 2011 at 7:20 AM, jcbollinger  
> wrote:
> >
> >
> > On Mar 21, 8:53 pm, Nigel Kersten  wrote:
[...]
> >> Thoughts?
> >
> > I agree that File is a mishmash, but I don't think symlinks and
> > recursive copying are the key concepts that would be good to split
> > out.  Instead, I think splitting directories into their own type would
> > be the way to go.
> >
> > Consider what would happen if symlinks were made their own type.  What
> > about dependencies?  Right now, I can have
> >
> > service { "my_service": require => File["/etc/my_service.conf"] }
> >
> > without caring whether File["/etc/my_service.conf"] represents an
> > actual file or a symlink.  I can even change that in the declaration
> > of the file without having to touch anything that depends on it.  If
> > symlinks were modeled via a separate type, however, then I would need
> > everywhere to account for which files were plain and which were
> > symlinks.
> 
> That's a really good point. One workaround would be to encapsulate
> such configs into a class and require that.
> 
[...]
> > This, then, is the direction that makes the most sense to me:
> >
> > 1) Split out (only) directories into their own type.  Among other
> > things, recursive-tree management would go into the new Directory
> > type.
> > 2) Give File and Directory each a "link_to" property by which these
> > types can be made to manage symbolic links instead of the underlying
> > regular file or directory.
> 
> like our existing "target" property? How does it make sense to manage
> a symlink in a Directory type? I'm not seeing it
> 

Same reason like above. If you're doing something like

  case $operatingsystem {
'Solaris': {
  # Filetype or even new link type
  file { '/foo': target => '/linktarget', ensure => link }
}
default {
  directory { '/foo': ensure => present}
}
  }

You cannot setup a dependency like require => Directory['/foo']. If the
directory type has a target attribute and ensure => link, this would be
possible.

While I think that this is a good point I still prefer splitting into
file, directory and directorytree (or similar).

One note about recursive copies. I have one case where I want to
controll owner/group/mode on a toplevel directory and just owner/group
for all the children in that directory. Thats not possible at the moment
(or not that I'm aware of). If I now can define Directorytree['foo'] and
Directory['foo'] I would be able to manage different aspects for parent
directory and children.

So +1 for Nigel's initial post from me.

-Stefan


pgpCxVF1WJkT6.pgp
Description: PGP signature

[Puppet Users] augeas slooow

[Jennings, Jared L CTR USAF AFMC 46 SK/CCI]

I've got somewhere around 130 Augeas resources in my policy (catalog,
entire set of manifests, what-have-you) and 11 custom lenses, each for
only one or two files, and it takes like 2 1/2 minutes to apply the
whole thing. Looking at the --debug output, there are a whole lot of
pauses right after "opening Augeas" sorts of lines. (That happens 79
times.) I think that's because Augeas is populating its whole tree, each
time.

I know I can avoid that behavior by specifying the lens and incl
parameters in my augeas resources, but I like the clarity I get by not
doing that, and want to preserve it.
 
Has anyone ever tried to make it so that only one Augeas connection is
opened per Puppet run?

How can I profile my Puppet catalog, to see what resources take the
longest to set straight? (I've only got puppet apply for now - no master
yet)

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

Re: [Puppet Users] Listing puppet modules

[Cody Robertson]

On 03/22/2011 02:51 PM, hai wu wrote:

Is there a commond to list all puppet modules applied for a certain node?
I tried puppet-concat (motd-register), but it is not working if some 
puppet module is in some run stage that is before or after "main" run 
stage. Is there another way to show all puppet modules to be applied 
for each puppet client?

--
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 could perhaps check out the classes.txt file in your $vardir 
(usually /var/lib/puppet).


-Cody Robertson

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

[Puppet Users] Listing puppet modules

[hai wu]

Is there a commond to list all puppet modules applied for a certain node?

I tried puppet-concat (motd-register), but it is not working if some puppet
module is in some run stage that is before or after "main" run stage. Is
there another way to show all puppet modules to be applied for each puppet
client?

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

Re: [Puppet Users] add all group members to file

[Adam Heinz]

I think you would have each host export

@@host { $fqdn:
   ...,
   tag => 'mygroup',
}

then also have each host consume those hosts

Host <<| tag == 'mygroup' |>>

On Tue, Mar 22, 2011 at 7:40 AM, danh  wrote:
> Hello all,
>
> I am trying to work out how to populate "/etc/hosts" with the IPs and
> names of all nodes in a group.
>
> For instance, I define a node "webserver" and derive all my webservers
> from it so I want to populate "/etc/hosts" with the IPs and names of
> all the nodes that derive from "webserver".
>
> Can someone clue me in?
>
> Cheers,
>
> Dan.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>
>

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

Re: [Puppet Users] about http basic authentication dashboard

[Felix Frank]

On 03/22/2011 04:34 PM, chp wrote:
> Hi,
> 
> I am running dashboard 1.1.0rc1 under passenger 3.0.5 and apache 2.2.3
> with puppet 2.6.6. Im trying to get urls like this
> 
> http://user:password@host
> 
> working as suggested in the docs for reporting but atm i did not get
> it (401 auth requided). Maybe I am forgetting something?  I use a
> common .htpasswd file. Auth type Basic, etc.
> 
> Sorry if this has been seen in this mailing-list. I searched for it
> but  I could not find it.

Hi,

do you enter this in your browser? I think that should work.

Now if you're using wget or curl, things may be different. E.g., wget
uses special extra params for authentication.

HTH,
Felix

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

[Puppet Users] about http basic authentication dashboard

[chp]

Hi,

I am running dashboard 1.1.0rc1 under passenger 3.0.5 and apache 2.2.3
with puppet 2.6.6. Im trying to get urls like this

http://user:password@host

working as suggested in the docs for reporting but atm i did not get
it (401 auth requided). Maybe I am forgetting something?  I use a
common .htpasswd file. Auth type Basic, etc.

Sorry if this has been seen in this mailing-list. I searched for it
but  I could not find it.

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

[Puppet Users] Foreman 0.2 Release Candidate

[Ohad Levy]

Hello All,

I'm happy to announce a new release candidate of Foreman, top highlights
for this release includes:

* New look and feel
* Extended restful API
* Support for New Puppet Reports format
* Full VM/physical host Provisioning
* Powerful template generator ( pxelinux, gpxe, kickstart, preseed, grub
etc..)
* introduce a new service called smart proxy (which can run on remote
machines) to manage the following services:
  ** DNS Management 
  ** DHCP Management
  ** TFTP Management
  ** Puppet/PuppetCA Management

This release is a major release packed with goodies, around 130 tickets
were closed

Release notes can be found here:
http://theforeman.org/projects/foreman/wiki/ReleaseNotes

Full change log can be found here: http://theforeman.org/versions/show/9

As usually many many thanks to all contributors and users

RPMS for both smart proxy and foreman can be found at
http://yum.theforeman.org/test

Have fun,
Ohad

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

Re: [Puppet Users] Re: RFC: Splitting up the file{} type functionality.

[Nigel Kersten]

On Tue, Mar 22, 2011 at 7:20 AM, jcbollinger  wrote:
>
>
> On Mar 21, 8:53 pm, Nigel Kersten  wrote:
>> The file{} type can do all of the following:
>>
>> * manage single files
>> * manage directories
>> * manage symlinks
>> * manage recursive file copies
>>
>> The intersection of all these bits of functionality makes it difficult
>> to understand exactly what is going on when you're new to Puppet, and
>> even experienced users often don't know how combining symlinks/content
>> management is going to work.
>>
>> How would people feel about at least splitting out these into their own 
>> types?
>>
>> * symlinks
>> * recursive file copies
>>
>> The intersection of files and directories isn't that big a deal, but
>> we could split out directories too if we wanted.
>>
>> Thoughts?
>
> I agree that File is a mishmash, but I don't think symlinks and
> recursive copying are the key concepts that would be good to split
> out.  Instead, I think splitting directories into their own type would
> be the way to go.
>
> Consider what would happen if symlinks were made their own type.  What
> about dependencies?  Right now, I can have
>
> service { "my_service": require => File["/etc/my_service.conf"] }
>
> without caring whether File["/etc/my_service.conf"] represents an
> actual file or a symlink.  I can even change that in the declaration
> of the file without having to touch anything that depends on it.  If
> symlinks were modeled via a separate type, however, then I would need
> everywhere to account for which files were plain and which were
> symlinks.

That's a really good point. One workaround would be to encapsulate
such configs into a class and require that.

class foo::service {
  service { "my_service": require => Class["foo::config"] }
}

class foo::config { ... }

Another would be to flip this around and instead use before instead of
require, so the service resource wouldn't need to know what kind of
object is required.

>
> Or look at it from a modelling angle: a symlink to a regular file is
> much more like a regular file than a directory is like a regular file,
> so why does it make sense to split out symlinks but not directories?

Because of the clash between defining a symlink and specifying the
content of a file.

We have edge cases like this:

file { "/tmp/someobject":
  ensure => present,
  content => "foo",
}

Now if /tmp/someobject is a symlink (or even a directory), we need to
special case the code so that we log that the content attribute isn't
being used.

If it's a file, it will be used.

It gets worse with the "links" parameter.

file { "/tmp/foo":
  ensure => present,
  links => follow,
  recurse => true,
  source => "",
}

This does all sorts of weird things depending upon whether the object
is a symlink, directory or file.

We've had requests to support sockets in the file type too, which
complicate things further.

>
> Parallel arguments can be made about directories and symlinks to
> directories.
>
> As for recursive copying, that's an action, not an observable,
> manageable artifact, so why would it make sense to create a resource
> type around it?  It could be recast as something like "directory
> hierarchy", but that begs the question of why it should be separate
> from ordinary directories.  If you want to think out of the box, then
> consider re-implementing recursive directory management via a new
> (type of) function that dynamically adds all the appropriate Directory
> and File resources to the catalog.  That's anyway what Puppet already
> does, right?

We have fundamentally different kinds of parameters on a recursive
file source than we do on a normal directory.

Think about the clash between source and content. links. purge.
recurse. recurselimit. ignore.

All those things *only* make sense with a recursive tree, not with a
single file or a single directory.


>
>
> This, then, is the direction that makes the most sense to me:
>
> 1) Split out (only) directories into their own type.  Among other
> things, recursive-tree management would go into the new Directory
> type.
> 2) Give File and Directory each a "link_to" property by which these
> types can be made to manage symbolic links instead of the underlying
> regular file or directory.

like our existing "target" property? How does it make sense to manage
a symlink in a Directory type? I'm not seeing it

> 3) Once (1) and (2) are done, it will be possible and appropriate to
> limit the allowed values of both types' "ensure" properties to
> "absent" and "present".
>
> I recommend seeing how (1) works out before trying to move recursive
> directory management into its own entity.  If that feature is indeed
> moved out, however, then I truly don't see how it would make sense to
> make a resource type out of it.  Making a function out of it instead
> would be a better fit.

I think you're overlooking the configurable properties for recursive
copies. A function isn't going to give you all the options that are
widely used n

[Puppet Users] Re: RFC: Splitting up the file{} type functionality.

[jcbollinger]

On Mar 21, 8:53 pm, Nigel Kersten  wrote:
> The file{} type can do all of the following:
>
> * manage single files
> * manage directories
> * manage symlinks
> * manage recursive file copies
>
> The intersection of all these bits of functionality makes it difficult
> to understand exactly what is going on when you're new to Puppet, and
> even experienced users often don't know how combining symlinks/content
> management is going to work.
>
> How would people feel about at least splitting out these into their own types?
>
> * symlinks
> * recursive file copies
>
> The intersection of files and directories isn't that big a deal, but
> we could split out directories too if we wanted.
>
> Thoughts?

I agree that File is a mishmash, but I don't think symlinks and
recursive copying are the key concepts that would be good to split
out.  Instead, I think splitting directories into their own type would
be the way to go.

Consider what would happen if symlinks were made their own type.  What
about dependencies?  Right now, I can have

service { "my_service": require => File["/etc/my_service.conf"] }

without caring whether File["/etc/my_service.conf"] represents an
actual file or a symlink.  I can even change that in the declaration
of the file without having to touch anything that depends on it.  If
symlinks were modeled via a separate type, however, then I would need
everywhere to account for which files were plain and which were
symlinks.

Or look at it from a modelling angle: a symlink to a regular file is
much more like a regular file than a directory is like a regular file,
so why does it make sense to split out symlinks but not directories?

Parallel arguments can be made about directories and symlinks to
directories.

As for recursive copying, that's an action, not an observable,
manageable artifact, so why would it make sense to create a resource
type around it?  It could be recast as something like "directory
hierarchy", but that begs the question of why it should be separate
from ordinary directories.  If you want to think out of the box, then
consider re-implementing recursive directory management via a new
(type of) function that dynamically adds all the appropriate Directory
and File resources to the catalog.  That's anyway what Puppet already
does, right?


This, then, is the direction that makes the most sense to me:

1) Split out (only) directories into their own type.  Among other
things, recursive-tree management would go into the new Directory
type.
2) Give File and Directory each a "link_to" property by which these
types can be made to manage symbolic links instead of the underlying
regular file or directory.
3) Once (1) and (2) are done, it will be possible and appropriate to
limit the allowed values of both types' "ensure" properties to
"absent" and "present".

I recommend seeing how (1) works out before trying to move recursive
directory management into its own entity.  If that feature is indeed
moved out, however, then I truly don't see how it would make sense to
make a resource type out of it.  Making a function out of it instead
would be a better fit.


John

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

[Puppet Users] Re: [Puppet-dev] RFC: Splitting up the file{} type functionality.

[Nick Moffitt]

Nigel Kersten:
> The file{} type can do all of the following:
> 
> * manage single files
> * manage directories
> * manage symlinks
> * manage recursive file copies

I tend to use different defaults for the different types, so I would
love to be able to do:

File { mode => 0444 }
Directory { mode => 0555 }

(I use read-only status as a final safety net for sysadmins who run
"sudo vi " on something managed by puppet)

...and leave Symlink types alone (since that all-bits-high mode is one
of the ways I pick them out in an ls -l lineup sometimes, and is
probably functionally significant somehow).

And as was mentioned elsewhere, the recursive copy off of the file
server is probably the quirkiest use of File resources.

-- 
"Forget the damned motor car
and build cities for lovers and friends."
   -- Lewis Mumford

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

[Puppet Users] add all group members to file

[danh]

Hello all,

I am trying to work out how to populate "/etc/hosts" with the IPs and
names of all nodes in a group.

For instance, I define a node "webserver" and derive all my webservers
from it so I want to populate "/etc/hosts" with the IPs and names of
all the nodes that derive from "webserver".

Can someone clue me in?

Cheers,

Dan.

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

Re: [Puppet Users] Re: [Puppet-dev] RFC: Splitting up the file{} type functionality.

[Dean Wilson]

On Mon, Mar 21, 2011 at 09:06:51PM -0700, James Turnbull wrote:
> Nigel Kersten wrote:
>> The file{} type can do all of the following:
>> * manage symlinks

>> How would people feel about at least splitting out these into their own 
>> types?
>>
>> * symlinks

> On a final note ... can we not overload "ensure" in our new types? :)

I'm a +1 on splitting out symlinks. It's been one of the biggest catches
for people when I've been teaching them puppet. Once that's split out
removing the overloading of ensure for the file type and replacing it with
some stricter validation would be excellent.

  Dean
-- 
Dean Wilson
http://www.unixdaemon.net   @unixdaemon
http://www.puppetcookbook.com   @puppetcookbook

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

Re: [Puppet Users] parameterized classes and variable inheritance

[Felix Frank]

> Hi,
> 
> is it me, or is class sudoers not actually parameterized?

Gah! It *is* me and my sort of ambiguous font. Never mind that bit then:

> What I'm seeing is a good old class with local variables. The way they
> are initialized, they cannot even be overridden by (ab-)using dynamic
> scoping, although this would probably work (plusignment):
> 
> include sudoers
> $sudoers::additional_rules += [ a, b, c ]

The stuff about using subclasses holds true enough though ;-)

Sorry for the noise.

Felix

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

Re: [Puppet Users] parameterized classes and variable inheritance

[Felix Frank]

> node default {
> class { sudoers: }
> }
> 
> node 'sl11lab02' inherits default {
> 
> # this runs but does nothing
> Class[sudoers] { additional_rules => [ "$rules_uas" ] }
> 
> # this errors with "Cannot assign to variables in other namespaces"
> #$sudoers::additional_rules = [ "$rules_uas" ]
> 
> # this errors with "Class[Sudoers] is already defined"
> #class { sudoers: additional_rules => [ "$rules_uas" ] }
> }
> 
> class sudoers (
> $default_rules= "$rules_unixgroup",
> $additional_rules = [ "" ]
> ) {
> 
> file { "/tmp/sudoers":
> owner   => root, group => root, mode => 440,
> content => template("sudoers/sudoers.erb"),
> notify  => Exec["check-sudoers"],
> }
> 
> exec { "check-sudoers":
> command => "/usr/sbin/visudo -cf /tmp/sudoers && cp /tmp/sudoers 
> /etc/sudoers",
> refreshonly => true,
> }
> 
> }

Hi,

is it me, or is class sudoers not actually parameterized?

What I'm seeing is a good old class with local variables. The way they
are initialized, they cannot even be overridden by (ab-)using dynamic
scoping, although this would probably work (plusignment):

include sudoers
$sudoers::additional_rules += [ a, b, c ]

To me, this actually does call for a (parameterized?) subclass that will
override the content of your /tmp file:

class sudoers_additional($additional_rules) inherits sudoers {
  File["..."] { content => template(...) }
}

This may even use the same template as the baseclass.

Don't just hate subclasses. They're often pretty helpful ;-)

HTH,
Felix

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

Re: [Puppet Users] Client no longer reads catalog

[Felix Frank]

On 03/16/2011 03:48 PM, Dennis Jacobfeuerborn wrote:
> Hi,
> One of my machines has started to refuse reading the catalog from the
> server. The log shows the following:
> 
> Mar 16 15:36:42 wmembf10 puppetd[7411]: Starting Puppet client version
> 0.25.5
> Mar 16 15:36:46 wmembf10 puppetd[7411]: Could not retrieve catalog from
> remote server:
> Mar 16 15:36:46 wmembf10 puppetd[7411]: Using cached catalog
> Mar 16 15:36:46 wmembf10 puppetd[7411]: Could not retrieve catalog;
> skipping run
> 
> Server and Client are both version 0.25.5. An identical System
> (wmembf09) has no such problems and updates the configuration just fine.
> Since I don't get any indication what the problem could be I'm at a loss
> what to do about this. Any ideas?

Does puppetd --test -dv shed any more light?

-- 
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.