Re: [Puppet-dev] Re: Facter config file

[Michael Stahnke]

On Tue, Mar 1, 2016 at 12:25 PM, Matthew Gaspar  wrote:

> A config file for facter is intriguing to me.
>
> Would this solely be used to change behaviors when running facter, or do
> you see some potential for defining some facts within the config itself?
>

I'd rather not mix config with content. If we want a facts.txt or
something, that's cool, but not configuration.

>
> Also, would you move facter specific configs into this facter.conf instead
> of being managed from the puppet.conf file (ie: cfacter, factpath,
> fact_terminus)?
>

I would like to see the search path for custom facts set in here. (And get
facts.d out of /etc, cause I feel bad about that).

There might also be something an 'expensive facts' list that we only
resolve once a day, or custom TTL settings, or something to improve the
performance of gathering facts. I'm just spitballing here though.


> The only problem I sometimes encounter, which may be a usage issue on my
> part, is when creating custom facts sometimes it'd be nice to just run
> `facter my_custom_fact` to get the output. If there would be some way to
> register custom facts so that facter picks them up without having to run
> puppet or run the ruby code the custom fact is in manually, that would be
> interesting. If that already exists I haven't found how to do that.
>
> Either way, I think a config where you can either specify which facts to
> enable or disable would be useful.
>



>
> On Tuesday, March 1, 2016 at 11:52:12 AM UTC-7, Eric Sorenson wrote:
>>
>> I've been thinking about a config file for Facter, which has historically
>> not been run-time configurable.
>>
>> The two problems in front of me that seem applicable are:
>>
>> * Sometimes, certain facts are just plain bad to collect and users would
>> like to prevent them from even being resolved (see FACT-718, FACT-449, ).
>> * Some facts are not inherently bad but _are_ expensive and/or change
>> infrequently, so preventing them from being resolved every time would be
>> beneficial (FACT-348)
>>
>> Are there other problems you're running into in this area that you'd like
>> to see addressed with a "facter.conf"? I'd like to gather all the
>> requirements and start up a little Puppet RFC based on them.
>>
>> --eric0
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/0f42fe6f-1f75-4aff-aa6a-77dd3e17235c%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7L%2BcB%2BEE55AX8CZsiJwBM5_a66uJ8F1sxN6OEttKRrDZhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

[Michael Stahnke]

On Fri, Feb 5, 2016 at 12:06 AM, Alex Harvey  wrote:

>
>
> On Friday, February 5, 2016 at 9:58:41 AM UTC+11, Michael Stanhke wrote:
>>
>>
>> Why would I ship a ruby when Red Hat does? The packages we ship for
>> Puppet 3 are designed to ship with System Ruby. System ruby is 1.8.7. I
>> realize that is old, but that is what is there on EL6. That ruby is
>> supported by Red Hat until 2023. If you want to run on a non-system ruby,
>> gems are provided or you are welcome to package your own thing.
>>
>>>
>>> It shouldn't be so hard to stand Puppet up in 2016.  I love Puppet, and
>>> I love Ruby, and I hate hearing super smart developers telling me that Salt
>>> or Ansible are superior, when their main reason for saying so is that Ruby
>>> and Puppet together are just way too many yaks to shave.  And I hear this,
>>> all, the, time.
>>>
>>
>> What's difficult about install a puppetlabs-release package and yum
>> install puppet?
>>
>
> Hi Mike, it's not difficult, but I also don't see what's difficult about
> putting the Rubies that Puppet Enterprise already ships with on
> yum.puppetlabs.com.
>

The ruby that ships in puppet enterprise is the same ruby in Puppet4. That
is available to you.

>
>
>> I think your complaint is that a non-standard use-case doesn't work. I
>> don't understand why you have that use-case, and we can solve everybody's
>> individual case. We provide a system-ruby enabled package. We also provide
>> puppet 4 with everything you need.
>>
>
> Like the original poster in this thread, my use-case is I ran into an old
> Ruby-version-related Puppet bug.  We install Puppet from Gems, not RPMs.  I
> think from time to time, even going into the brave new Puppet 4 future, it
> will still be useful from time to time to be able to easily change the Ruby
> on your CentOS and Ubuntu platforms, something that has never been easy in
> the past.
>

We don't test other rubies for Puppet 4 other than the one we ship with.

>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/44aa69be-925c-4a21-be7d-785dbee944e4%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LKFqL6Ex%2BWW6ngTVw82coi7FvWsb%2B349R-nK-OK3ePOtg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

[Michael Stahnke]

On Fri, Jan 29, 2016 at 8:16 AM, Alex Harvey  wrote:

> Yep, it's solved in Puppet 4 - the all-in-one package is fantastic, as is
> so much in Puppet 4.  However PE hasn't release Puppet 4 yet; my assessment
> of the Puppet Forge is that not many modules out there are ready; and I am
> not super confident that other tools in the ecosystem like Beaker,
> Librarian etc are ready; so I am not personally willing to recommend Puppet
> 4 to customers at this stage.  In any case, loads and loads of people will
> be using Puppet 3 for a long, long time yet.
>

Chris already covered this, but this incorrect. PE has had Puppet 4 since
July of 2015.

>
> And then I get back to - why not just put the RPMs in the yum repository?
> They're already in PE aren't they?  I get it that it's not really Puppet's
> problem that EL is crap, but on the other hand, it actually is.  Puppet
> made the choice to build a DSL on Ruby.  So, when I discovered earlier
> today that there's still no supported Ruby for the latest Puppet 3 for
> CentOS Linux, I couldn't believe it.  This is RUBY on EL6/7.  This is not a
> wacky feature request.  Without Ruby, the amazingly complex, feature rich
> ecosystem we know and love as Puppet is a castle built on sand.
>

Why would I ship a ruby when Red Hat does? The packages we ship for Puppet
3 are designed to ship with System Ruby. System ruby is 1.8.7. I realize
that is old, but that is what is there on EL6. That ruby is supported by
Red Hat until 2023. If you want to run on a non-system ruby, gems are
provided or you are welcome to package your own thing.

>
> It shouldn't be so hard to stand Puppet up in 2016.  I love Puppet, and I
> love Ruby, and I hate hearing super smart developers telling me that Salt
> or Ansible are superior, when their main reason for saying so is that Ruby
> and Puppet together are just way too many yaks to shave.  And I hear this,
> all, the, time.
>

What's difficult about install a puppetlabs-release package and yum install
puppet?

I think your complaint is that a non-standard use-case doesn't work. I
don't understand why you have that use-case, and we can solve everybody's
individual case. We provide a system-ruby enabled package. We also provide
puppet 4 with everything you need.


>
> On Saturday, January 30, 2016 at 12:39:15 AM UTC+11, Erik Dalén wrote:
>>
>> Isn't this already solved with the Puppet 4.x packaging (puppet-agent)?
>> So why insist on installing an old Puppet version instead of a modern one?
>>
>> Personally I prefer that PuppetLabs is developing new features in Puppet
>> 4.x instead of spending time improving packaging and stuff for Puppet 3.x.
>>
>> On Fri, 29 Jan 2016 at 14:31 Alex Harvey  wrote:
>>
>>> Thanks for the heads up.  Anything less than Puppet Labs providing a
>>> working Ruby at yum.puppetlabs.com, or CentOS providing one, feels to
>>> me like a bit of a hack.  I've seriously got a customer wanting to ditch
>>> Puppet and go to Ansible because because they just want it to be easy to
>>> install open source Puppet 3.  We were burnt by Puppet Omnibus.  It just
>>> feels a bit like Puppet's giving us the finger, when all it would take is
>>> someone to stick an RPM on a server.  This problem could have been solved
>>> years ago, as the original poster in this thread suggested.
>>>
>>> On Friday, January 29, 2016 at 10:38:29 PM UTC+11, Rob Nelson wrote:
>>>
 Ruby 1.9.3 is available in the Software Collections (SCL) repository.
 Instructions at
 https://digitalchild.info/centos-6-5-and-ruby1-9-3-via-software-collections/
 .

 There may be some side effects for any system utilities that expect
 1.8.7 but that's a risk you'll have to accept if you're still on EL6, just
 like every other ancient version of software it includes. It does "work" in
 most senses, though.

 On Friday, January 29, 2016, Alex Harvey  wrote:

> https://bugs.centos.org/view.php?id=10268
>
> On Friday, January 29, 2016 at 4:15:16 PM UTC+11, Alex Harvey wrote:
>>
>> I thought I'd just put it out there that it's the Year of Our Lord
>> 2016* and CentOS is still installing Ruby 1.8.7, and
>> yum.puppetlabs.com is still not providing a modern Ruby either.
>>
>> Yes, PE provides a Ruby.
>> Yes, Puppet 4 provides a Ruby.
>> Yes, Puppet-omnibus can build a Ruby.
>> Yes, RVM is kinda cool.
>> Yes, compiling Ruby is kinda fun sometimes.
>>
>> But, as a user, I want to type "yum install ruby" and, OMFG, ruby
>> installs.
>>
>> *With apologies to adherents of other religious faiths and proponents
>> of Lunar and non-Gregorian calendars.
>>
>> :)
>>
>> On Friday, July 26, 2013 at 1:13:24 AM UTC+10, Christian Flamm wrote:
>>>
>>> Hi,
>>> I'm (using CentOS 6.4 and I'm) suffering from an AFAIU
>>> performance/design bug (http://projects.puppetlabs.com/issues/20865)
>>> which (althoughit's not recommended as a work-around) do

[Puppet-dev] Puppet Agent Open Sourced

[Michael Stahnke]

Since we first released the All in One Agent (puppet-agent, aka AIO), we’ve
had lots of requests for people to be able to build their own versions,
experiments, and ideas. Puppet Labs wants this packaging layout to be open,
and here it is[1].  We have a few issues, in that we know it won’t work out
of the box for users outside of our infrastructure. We’ve been hacking away
at a few of those limitations, but we haven’t had time to remove every one
of them.

Rather than wait until everything is perfect, we’ve decided to open it up.
The README is fairly detailed, and of course the puppet-agent repo relies
upon the vanagon[2] tooling we previously announced.

The known limitations are mostly around the build toolchain. The
packages/requirements that start with pl- are the ones we use in house. In
general, you can use a rather modern GCC (>= 4.8.2), boost (>= 1.58), cmake
(>= 3.2.2) , binutils (varies on platforms), yaml-cpp (0.5.1) and be fine.
You will likely need to adjust some environment variables for pathing. We
have tested building the agents on random things like raspberry pi’s, ppc
architectures, etc.

We certainly will welcome improvements that make the puppet-agent
repository work for more people. Issues can be filed with the Puppet
Agent[3] project in our Jira system. Issues with Vanagon can be filed in
the Community Packaging[4] project.



[1] https://github.com/puppetlabs/puppet-agent

[2] https://github.com/puppetlabs/vanagon

[3] https://tickets.puppetlabs.com/browse/PA/

[4] https://tickets.puppetlabs.com/browse/CPR/


Michael Stahnke
Release Engineering

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LJMc_tDYsHMtBjK%3DMX%3DQhk-4L2RFvuBf3mgcZi-Rx017g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Some new tools from PuppetConf

[Michael Stahnke]

On Mon, Oct 19, 2015 at 12:41 PM, Michael Stahnke 
wrote:

>
>
> On Tue, Oct 13, 2015 at 6:04 AM, Trevor Vaughan 
> wrote:
>
>> Hi Michael,
>>
>> Thanks for getting these released to the public, it's always good to have
>> new workflow tools!
>>
>> Could you explain the benefits of Vanagon over the Open Build Service?
>> http://openbuildservice.org/help/manuals/obs-reference-guide/
>>
>
> Sorry for the late reply.
>
> Basically, vanagon is much simpler. We've looked at OBS a few times and
> been unable to make it do what we needed. We might be not very good at it
> though. When we met with some folks doing OBS in Intel/Yocto a while back,
> it sounded like they basically needed somebody dedicated 100% to OBS and
> were submitting patches/fixes to it all the time. The documentation is also
> sparse, from what we saw.  It might be very good, and honestly we're trying
> to compete with it. It has much more workflow built in than Vanagon does. \
>

^^ honestly we're *NOT* trying to compete with it. That not was kind of
important there.

>
> Vanagon has a few things I really like, but YMMV
>
> 1. It's really easy to extend. I find the code very readable, test
> coverage is pretty good, and all in all, I can bend it to my will.
> 2. Right now it supports RPM, Deb, DMG/pkg, Swix, Solaris Pkg, AIX rpm and
> maybe a couple others I'm not remembering right now. We'll be adding
> Windows in the next couple months.
> 3. It has an engine (vmpooler) that works really well with our testing
> system/CI system. That was huge for us.
>
>>
>>
>> Right now, I'm using Mock for maximum portability in isolated
>> environments but I'm always looking at ways to potentially speed things up.
>>
>
> Yup, we've used mock a lot. It's great, for rpm. There's nothing
> preventing vanagon from being able to use mock if that's how you want ot do
> builds. We don't do that because we basically build on a minimal VM and
> then  destroy it, (which is roughly what mock does, just on the same
> system).
>
>
>
>> Thanks,
>>
>> Trevor
>>
>> On Mon, Oct 12, 2015 at 2:31 PM, Michael Stahnke 
>> wrote:
>>
>>> A couple of tooling announcements (or maybe just things that happened)
>>> during the week of PuppetConf.
>>>
>>> 1. Our tool to build our clojure services and packages was open sourced.
>>> It's called ezbake[1] (like the oven). It uses our packaging[2] repo as
>>> well.  The way our services are managed in terms of init scripts, defaults
>>> and the like are all contained within ezbake.
>>>
>>> 2. Our tool build out AIO packages (for agent or other items) was also
>>> open sourced. It's called vanagon[3]. Of note, the actual repo with
>>> puppet-agent is not yet open as there is still a bit of cleanup required.
>>> It's going to happen soon. (Weeks not months).
>>>
>>> Vanagon was designed to be a build system that worked on any environment
>>> that can run rsync and has a libc. It doesn't require ruby on the target,
>>> or need vagrant. It can build on physical or virtual targets (and has a
>>> docker engine). It was about minimal dependencies. Vanagon operates with a
>>> control node talking to the target host. It also integrates very nicely
>>> with our vmpooler[4] which is used in our testing system. Issues with this
>>> project can filed in the CPR[5] project on our jira. API doc[6] is
>>> available on my fork, since we haven't gotten all of that integrated into
>>> CI yet.
>>>
>>> I realize this intro is a little sparse, we'll have more information
>>> soon. We wanted to get these out though.
>>>
>>>
>>>
>>>
>>> [1] https://github.com/puppetlabs/ezbake
>>> [2] https://github.com/puppetlabs/packaging
>>> [3] https://github.com/puppetlabs/vanagon.
>>> [4] https://github.com/puppetlabs/vmpooler
>>> [5] https://tickets.puppetlabs.com/browse/CPR
>>> [6] http://stahnma.github.io/vanagon/doc/
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gm

Re: [Puppet-dev] Some new tools from PuppetConf

[Michael Stahnke]

On Tue, Oct 13, 2015 at 6:04 AM, Trevor Vaughan 
wrote:

> Hi Michael,
>
> Thanks for getting these released to the public, it's always good to have
> new workflow tools!
>
> Could you explain the benefits of Vanagon over the Open Build Service?
> http://openbuildservice.org/help/manuals/obs-reference-guide/
>

Sorry for the late reply.

Basically, vanagon is much simpler. We've looked at OBS a few times and
been unable to make it do what we needed. We might be not very good at it
though. When we met with some folks doing OBS in Intel/Yocto a while back,
it sounded like they basically needed somebody dedicated 100% to OBS and
were submitting patches/fixes to it all the time. The documentation is also
sparse, from what we saw.  It might be very good, and honestly we're trying
to compete with it. It has much more workflow built in than Vanagon does.

Vanagon has a few things I really like, but YMMV

1. It's really easy to extend. I find the code very readable, test coverage
is pretty good, and all in all, I can bend it to my will.
2. Right now it supports RPM, Deb, DMG/pkg, Swix, Solaris Pkg, AIX rpm and
maybe a couple others I'm not remembering right now. We'll be adding
Windows in the next couple months.
3. It has an engine (vmpooler) that works really well with our testing
system/CI system. That was huge for us.

>
>
> Right now, I'm using Mock for maximum portability in isolated environments
> but I'm always looking at ways to potentially speed things up.
>

Yup, we've used mock a lot. It's great, for rpm. There's nothing preventing
vanagon from being able to use mock if that's how you want ot do builds. We
don't do that because we basically build on a minimal VM and then  destroy
it, (which is roughly what mock does, just on the same system).



> Thanks,
>
> Trevor
>
> On Mon, Oct 12, 2015 at 2:31 PM, Michael Stahnke 
> wrote:
>
>> A couple of tooling announcements (or maybe just things that happened)
>> during the week of PuppetConf.
>>
>> 1. Our tool to build our clojure services and packages was open sourced.
>> It's called ezbake[1] (like the oven). It uses our packaging[2] repo as
>> well.  The way our services are managed in terms of init scripts, defaults
>> and the like are all contained within ezbake.
>>
>> 2. Our tool build out AIO packages (for agent or other items) was also
>> open sourced. It's called vanagon[3]. Of note, the actual repo with
>> puppet-agent is not yet open as there is still a bit of cleanup required.
>> It's going to happen soon. (Weeks not months).
>>
>> Vanagon was designed to be a build system that worked on any environment
>> that can run rsync and has a libc. It doesn't require ruby on the target,
>> or need vagrant. It can build on physical or virtual targets (and has a
>> docker engine). It was about minimal dependencies. Vanagon operates with a
>> control node talking to the target host. It also integrates very nicely
>> with our vmpooler[4] which is used in our testing system. Issues with this
>> project can filed in the CPR[5] project on our jira. API doc[6] is
>> available on my fork, since we haven't gotten all of that integrated into
>> CI yet.
>>
>> I realize this intro is a little sparse, we'll have more information
>> soon. We wanted to get these out though.
>>
>>
>>
>>
>> [1] https://github.com/puppetlabs/ezbake
>> [2] https://github.com/puppetlabs/packaging
>> [3] https://github.com/puppetlabs/vanagon.
>> [4] https://github.com/puppetlabs/vmpooler
>> [5] https://tickets.puppetlabs.com/browse/CPR
>> [6] http://stahnma.github.io/vanagon/doc/
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubsc

[Puppet-dev] Some new tools from PuppetConf

[Michael Stahnke]

A couple of tooling announcements (or maybe just things that happened)
during the week of PuppetConf.

1. Our tool to build our clojure services and packages was open sourced.
It's called ezbake[1] (like the oven). It uses our packaging[2] repo as
well.  The way our services are managed in terms of init scripts, defaults
and the like are all contained within ezbake.

2. Our tool build out AIO packages (for agent or other items) was also open
sourced. It's called vanagon[3]. Of note, the actual repo with puppet-agent
is not yet open as there is still a bit of cleanup required. It's going to
happen soon. (Weeks not months).

Vanagon was designed to be a build system that worked on any environment
that can run rsync and has a libc. It doesn't require ruby on the target,
or need vagrant. It can build on physical or virtual targets (and has a
docker engine). It was about minimal dependencies. Vanagon operates with a
control node talking to the target host. It also integrates very nicely
with our vmpooler[4] which is used in our testing system. Issues with this
project can filed in the CPR[5] project on our jira. API doc[6] is
available on my fork, since we haven't gotten all of that integrated into
CI yet.

I realize this intro is a little sparse, we'll have more information soon.
We wanted to get these out though.




[1] https://github.com/puppetlabs/ezbake
[2] https://github.com/puppetlabs/packaging
[3] https://github.com/puppetlabs/vanagon.
[4] https://github.com/puppetlabs/vmpooler
[5] https://tickets.puppetlabs.com/browse/CPR
[6] http://stahnma.github.io/vanagon/doc/

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LKY-JV3F-0gX6YdztLvqwesj8A777mOeJuRjPs7Qynbww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] The Road to Facter 3

[Michael Stahnke]

On Thu, Mar 5, 2015 at 1:25 PM, Roy Nielsen  wrote:

> Curious - will this be able to be compiled and used on Arm or other
> architectures (cross platform compatibility)?
>
>
> I have been toying with ARM chips at home to get this working. (Not
official from Puppet Labs). Thus far I haven't got it all working, but it's
mostly due to versions of libraries and such and not cfacter itself. I'll
keep you posted.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LJ7FGC9QsZSUDfyFQx_Be8HKBpFEnRvoBKvZXWVAaM2Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet Dev Status -- week ending Feb 21

[Michael Stahnke]

On Tue, Feb 24, 2015 at 10:31 AM, Wil Cooley  wrote:

> On Mon, Feb 23, 2015 at 2:17 PM, Jeff McCune  wrote:
>
>> On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan 
>> wrote:
>>
>>> Yes please. Moving this out of $vardir/ssl will be quite irritating to
>>> teach existing users about the new product usage.
>>>
>>
>> Even if we kept it in $vardir/ssl, this would mean the path is
>> /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please
>> note the agent and master vardir's in the specification).  Is your concern
>> that SSL data remain in $vardir/ssl or that they remain in
>> /var/lib/puppet/ssl ?
>>
>
>
> It does not seem like a great idea to put $vardir under /opt. /opt is only
> sometimes a separate file system from / and could grow much more variably.
> If anything, I'd rather see the some of the directories under $vardir to be
> moved to /var/cache/puppet, depending on whether the data is transitory or
> persistent. (Much of it, in fact, I would expect to be cache, but
> 'reports', 'bucket' and possibly 'clientbucket' stand out as non-transitory
> so kept in 'lib'; if ssl were not in /etc I would expect it to be in 'lib'
> as it is not transitory.)
>

/var is sometimes only a separate filesystem not as well. We plan to keep
(as we have for PE) the SSL stuff in /etc/puppetlabs/puppet/ssl. Putting it
in cache doesn't make a ton of sense, at least in my head a cache should be
able to regenerated upon deletion. That wouldn't work well for ssl certs.

Distros place ssl certs as configuration information in /etc- however since
distros can't ever seem to agree on where that stuff should go, we're
putting it with our application stack.


> I agree with the hating on '/etc/opt' and '/var/opt' too.
>

I hate those so much.

>
> Also, if hiera, c?facter and mco are going to be installed in
> /opt/puppetlabs/puppet, why bother with the extra directory level and then
> have to bother symlinking into /opt/puppetlabs/bin? I'm guessing that there
> is an expectation that other projects/products will go alongside the
> 'puppet' level, but then it seems weird to put hiera c?facter and mco into
> 'puppet' instead of their own directories. I guess you're putting ruby into
> the 'puppet' directory, so that's why... Hrm
>

There will be other directories at the puppet level in some types of
installations. You could see puppet-server being there, or puppetdb or
something. More information on that to come in the future.


>
> Blue. I say it should be blue!
>
> Wil
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAMmm3r43PjKyGNbvPFYRRw5aM8XtDz%2BuQFMB6GTDdCf%2BZj%3DPcg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LJ0yXnzk9HDBz4hhoXM%2BLi%2B27ue0XqcEixrAOzVouiRZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet 4 delivery and upgrades

[Michael Stahnke]

On Tue, Nov 18, 2014 at 11:23 AM, Joshua Hoblitt  wrote:

> On 11/18/2014 12:04 PM, Eric Sorenson wrote:
> > 2. To enable #1 but still support OSes that ship with 1.8.7, we're
> > going to be packaging and delivering Puppet 4 an an 'all-in-one' (AIO)
> > package bundled together with
> >  - openssl
> >  - ruby
> >  - augeas
> >  - ruby-augeas
> >  - ruby-stomp
> >  - ruby-shadow
> >  - puppet
> >  - mcollective
> >  - facter
> >  - hiera
> > - + misc supporting gems/libs (deep merge, yaml, etc)
> > (Question: are there other *agent side* components you feel are
> > essential to the functioning of the puppet stack?)
>
> On EL6.x, why not use a new SCL?  Or even install into the existing
> ruby193 SCL?
>

Part of the goal here is to have control of the ruby version. The SCL
offers one version of Ruby 1.9.3, Ubuntu offers another in their
distribution, as does Mac OS X, and the next OS. Compound that with libssl
fun and End of Life constraints on Ruby 1.9.3, and it's just not that fun.
(SCLs also have their own lifecycle that is different than RHEL).

We'll be picking one Ruby (2.1.z), and using that everywhere for a
consistent stack.

>
> -Josh
>
> --
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/546B9CA0.3060504%40cpan.org.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7L%2BkKHgxioLDO93A1md9BY04mF-XZNtXmy6Kii2gsA9G8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Facter version guarantees

[Michael Stahnke]

>
>> That's only semantic BS. The primary consumer of facter is puppet code
>> writers. If the meaning of return values of something like sprintf would
>> change, all hell would break loose. Why should it be different for the
>> return value of $operatingsystem ?
>>
>>
>
> Preach it, Brother!
>
> Seriously, the spirit of semver is not well captured by splitting hairs
> over what actually constitutes the "API" to which it applies.  Semver is
> about using version numbering that gives users of the software reliable
> information regarding compatibility between versions, principally with a
> view toward how that software is used by other software.  Yes, Facter's
> Ruby API is an aspect of that, but certainly the fact values characteristic
> of various environments are, too.  The values are central to how Puppet
> manifests use Facter.
>
> Alternatively, in the spirit of hair splitting, you could argue that
> because manifests do not use Facter directly, Facter has no responsibility
> toward them.  Instead, then, it's up to Puppet to maintain *its own*
> semver obligations toward manifests, PuppetDB, etc., *including* the fact
> variables characteristic of each environment that it exposes to those
> consumers.  No joy there.
>
> I think the most interesting questions here are actually about bug
> compatibility and what constitutes bug.  I don't think the intention of
> semver includes requiring a major version bump to accompany every batch of
> bug fixes.  I'd argue that Facter providing a fact value inconsistent with
> that fact's definition certainly does constitute a bug -- or at least, it
> *did* at one time.  When that bug persists for so long that a significant
> body of code comes to rely on it, however, I don't think you can reasonably
> call it a bug any longer.
>
>
I totally agree with this. I'd consider facter values an API for getting
values and making decisions with Puppet code (among other things).  The
discussion John brings up about what's a bug is really the bigger issue
here, since the behavior had been defined a different way for so long.
Obviously this is the type of thing we try to avoid and unfortunately just
missed it this time.

I'd still like us to keep the truthiness in fact values as high (and
consistent) as possible.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LLq85HiT9gR49gUreFd6pnjE9zuM9UzHwpJnPauz6CAHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Lightweight PuppetDB replacement

[Michael Stahnke]

Additionally, from a performance perspective, we couldn't even run the test
suites we run with PuppetDB against the ActiveRecord based system. It falls
over, we run out of memory and the slowness is unreal. If you want to see
this in action, Look for "PuppetConf Deepak" on youtube and you'll see
talks where he shows this in live demos.

Beyond that, Ruby (MRI at least) take more memory than many PuppetDB
installations. I was never a huge fan of the JVM, but when I saw what
PuppetDB could do with only a 128MB heap, I was sold. It's a constant
memory reservation from the OS, and just works. MRI would jump from little
usage to hundreds of megs (even sometimes gigs) of memory during runs and
checkins from clients. Another advantage of the JVM is are the metrics you
can get from it to do things like tuning and monitoring all via JMX.

If the API is the main concern, there are binding for the API in python,
ruby, go, even haskell. There are probably lots more I'm just not aware of.


>From an installation point of view (your heavy comment) installing a jar
and jre isn't too difficult. (We even provide a module to do this for you).
 It's also a little easier to ensure dependencies all work together
compared to Ruby with ActiveRecord versions changing/breaking API between
2.x, 3.x and 4.x. Also, after 3.x, active record started requiring many
more gems, IIRC.

If there are specific problems, I'm sure somebody would be happy to help
you a bit. If you only have complaints, I hope some of this is food for
thought.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMto7LL01OivipRv1GhfT932wJO-LtddcFVa96TqXxheDn1KXw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Tiering platform's and providers in puppet's core

[Michael Stahnke]

On Tue, Jan 14, 2014 at 7:07 AM, Jason Antman  wrote:

>  I thought I'd throw in my 2 cents, as a long-time puppet user, current
> PE customer, and community member trying to make more code contributions...
>
> First off, this thread has been great. I was going to quote a few replies,
> but there have been so many good ideas, that's sort of pointless. I fully
> support Daniel's plan to push tier2 directly to modules. More than that,
> I'd like to see it implemented in a way that I (an "advanced user") can
> easily opt-out of a given tier2 module (did someone say Nagios?) and
> replace it with something external.
>
> I'd like to share a realization that I recently had, which could perhaps
> be an aid in delineating what's tier1 vs tier2: I'd always assumed that
> everything that shipped with Puppet was tested. Period. It was unclear to
> me until I started trying to use puppetlabs' forge modules with PE (and
> found that one or two in particular didn't work), and started actually
> submitting some PRs against core, that there were varying levels of
> support, and that just because Puppet might ship with a provider for X
> doesn't mean that it's fully validated and tested against that (i.e. Andy's
> comments about FreeBSD). (As an aside, I'd also assumed that what I
> remember hearing years ago was true, and there was no internal split
> between PE and FOSS - that PE was "just FOSS in a prettier box, with
> support and some value-adds", presumably that the only testing done to PE
> and not FOSS was around Console and packaging. Andy's comment that PE is
> tested on more platforms than FOSS was something I'd always written off as
> anti-Puppet conspiracy theory.)
>

Just for clarity here, there is more testing around PE than Puppet.
However, there aren't really additional tests in the PE system that Puppet
doesn't run on Puppet itself (other than some platform coverage, e.g, AIX,
at least to the best of my knowledge). Most of the additional testing comes
from Puppet working with a specific version of Facter, working with
PuppetDB working with a UI working with Passenger and a specific version of
Ruby, etc, etc, etc.



> As such, for the benefit of the community, I'd suggest that anything that
> (a) isn't fully tested and vetted by PL (whatever that means) or (b) is
> known to be broken (i.e. naginator) be split out into tier2, as modules,
> with a clear delineation to explain to users that these are essentially
> sub-par and warranty-free. (I suppose this largely falls in line with
> Dustin's comment about Python core vs modules).
>

Just for clarity here: it's all warranty free. See section 7 of the Apache
License. http://www.apache.org/licenses/LICENSE-2.0.txt.

>
> I can't say I have a clear picture of how this would work... but as a
> probably 'more advanced' user of Puppet, I'd like to see this happen in a
> way that makes it easy to not only run a new version of a tier2 module, but
> also perform a wholesale replacement of it with something from the
> community (once again, reference to the nagios types). As such, I guess I'd
> be in favor of installing them *somewhere* outside of the core and adding a
> config directive (true by default) to automatically append that path to
> modulepath. That would be transparent to users who don't care about it, and
> for people like me, allow us to cherry-pick specific modules to append to
> our modulepath, and ignore others. Ideally the Modulefile format would be
> updated to understand this, so it would be easier to specify requirements
> for things that might no longer be present in a given puppet install.
>
> Versioning and dependencies are another strong argument in favor of moving
> directly to modules. If tier2 "things", i.e. the FreeBSD provider, are
> maintained and versioned separately but included in the "puppet"
> distribution proper, how does a Forge module or arbitrary piece of code
> declare that it needs a specific version of the provider? If I pull in the
> latest git version but am still running "Puppet 3.5.0" how is that
> communicated to modules? We know how to do this with puppet as a whole
> ($::puppetversion) or with modules (Modulefile, and the various tools that
> support it), but it's unclear to me how this would work if, for example,
> the FreeBSD package provider version wasn't inextricably tied to the puppet
> version.
>
> Just some thoughts. I'm very excited to see this change, both for the
> implications it has around nagios, and to possibly throw my name in the hat
> as a maintainer for the `pip` package provider.
> -Jason Antman
>
>
> On 01/13/2014 09:56 PM, Nan Liu wrote:
>
>  It's great the core type/provider is getting a serious review.
>
>  On Mon, Jan 13, 2014 at 4:20 PM, Andy Parker  wrote:
>
>>   On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg wrote:
>>
> Even later to the party, but I agree :) The alternative of a contrib
>>> directory could muddy the waters so that there were 3 locations a given
>>> type/provider could la

Re: [Puppet-dev] ruby-1.9.3 in yum.puppetlabs.com

[Michael Stahnke]

There is always http://elruby.websages.com.

I am the guy behind that. I needed different rubies for lots of
projects I was working on and just decided to make them public.

Disclaimers:

1. I am not always super fast if there are updates (or CVEs). My job
is to keep Puppet Labs stuff updated, not this ;)
2. I don't always keep up with things right now because of family obligations.
3. I would welcome help with upkeep on those packages.
4. This is not endorsed nor part of Puppet Labs in any way.


Mike

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

Re: [Puppet-dev] Vendoring external configuration files with Puppet

[Michael Stahnke]

The FHS says conf files don't live in /usr, especially your data dir. (Keep
in mind the FHS follows some old-school ideas, like /usr should be able to
be mounted Read-Only.).

Anyway, a conf file, if needed should be in /etc. If it's for a specific
provider, ideally it would be something like /etc/puppet/user or libuser
with the conf file under that directory.

Now for the rulebreakers like gems, (and many other language library
bundles), you would basically put the file in the libdir. Then packaging
would correct Puppet's lack of FHS adherence. This is very common, you'll
often see packages with symlinks in /usr/share/gems (or wherever else) into
/etc where the actual file will live ater proper packaging.

I'd really rather not see Puppet do this, (put a conf file in /usr). We
know better. :)  Maybe we just munge it in the gem layout, and put it in
the gemdir, and do it correctly (from an FHS perspective) by default?
 Alternatively, Puppet could just look in /etc first and fallback to the
libdir if /etc isn't there.




On Tue, Feb 19, 2013 at 4:35 PM, Adrien Thebo  wrote:

> Hi all,
>
> I'm hoping to get community feedback on dealing with external data or
> configuration that needs to be shipped with Puppet. Pull request #1442 (
> https://github.com/puppetlabs/puppet/pull/1442) added support for
> managing local users and groups by using libuser, solving issue 7911 (
> http://projects.puppetlabs.com/issues/7911). However to make libuser work
> in a consistent manner it has to supply a specific libuser.conf config
> file. We weren't able to come to a decision onto where this file should
> ultimately go and I was hoping to collect some outside opinion.
>
> The ideal solution for this sort of thing is to use the FHS concept of an
> application datadir, eg /usr/share/puppet. Installing Puppet would drop the
> libuser.conf in a path like /usr/share/puppet/provider/libuser.conf and
> Puppet would check $datadir/provider/libuser.conf for that configuration
> file. Shipping configuration data in lib/ is definitely ideal and this
> would address that problem.
>
> While this approach works swimmingly when puppet is installed by hand or
> by package, but this completely breaks down when installing via a gem.
> Since gems are entirely self contained in a directory the $datadir location
> would have to change for gems. In short, any sort of datadir solution that
> would mesh with gems fails with normal packages.
>
> It's foreseeable that we might have more configuration like this; data
> that shouldn't be edited by the end user that Puppet needs to run. Stuffing
> files into lib/ isn't a viable solution in the long run; does anyone see a
> better way of addressing this?
>
> --
> Adrien Thebo | Puppet Labs
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-dev@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: [Puppet-dev] Outstanding changes for 2.7?

[Michael Stahnke]

On Tue, Oct 30, 2012 at 2:57 PM, Andy Parker  wrote:
> On Tue, Oct 30, 2012 at 1:41 PM, David Schmitt  wrote:
>> On 2012-10-30 16:25, Jeff McCune wrote:
>>>
>>> Are there any "nightly" rpms or some-such around?


There's a sore lack of documentation at the moment, but the packaging
repo is here: https://github.com/puppetlabs/packaging, and the README
is a good start.

In the most simple case, if someone wants their own rpms, they need to

1) install rpmbuild, facter >= 1.6.x, and ruby > 1.8.5, and
rubygem-rake on your EL-based workstation
2) git clone puppet, switch to branch you desire (2.7.x or 3.0.x)
3) in the top level, do rake package:bootstrap and rake package:rpm

This will dump puppet rpms for their dist in a./pkg directory.

This will give you an RPM.


>>>
>>>
>>> Unfortunately we don't have nightly RPM builds at this point in time.
>>>   It's definitely on our list of things we'd like to provide.  I may
>>> look into this as part of my community focus, do you think nightly RPM's
>>> would help make community contributions easier?  What sort of things are
>>> you looking for from the nightly RPM's?  A repository?  Channels for
>>> 2.7.x, 3.x and master?  Just master?
>>
>>
>> In this particular case (and my client's installation/situation) a nightly
>> 2.7.x rpm would enable pre-rc testing of the performance improvements.
>>
>> As it is now, I'll probably won't be on-site before the RCs are cut and
>> dried.
>>
>>
>> More generally speaking, I'm coming to the conviction that community testing
>> requires testable artifacts as near as possible to the form of production
>> artifacts. That is, if it is expected to install something as a package, a
>> testable version must also be a package.
>>
>
> We've come to a similar conclusion and there has been some work toward
> that end. I think we are still a little ways off of getting nightly
> RPM builds, though.
>
>>
>> Best Regards, David
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>

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

Re: [Puppet-dev] Shuffling puppet execution order in 2.6

[Michael Stahnke]

In Puppet 2.7 you get deterministic ordering of resources.

Also, 2.6.x is currently only getting security fixes, so no bug fixes
will go into it.  Is there a reason you can't use a newer puppet?

On Wed, Sep 19, 2012 at 4:34 AM, Lukáš Zapletal  wrote:
> Hello,
>
> we are using Puppet 2.6 and need to support this version for some time. We
> wrote an installer in Puppet and it has rich codebase with pretty complex
> scenarios. The issue is we have missing dependencies there. Those are bugs
> we would like to catch, but they appear "randomly". Our testers or users hit
> those when running the installer in various conditions and environments
> (different memory, hdd speed, size etc). We have tested our manifests
> zillons of times and there are still some hidden dependency bugs we hit.
>
> From what I know, Puppet 2.6 executes steps from the same "level" in the
> tree "randomly". But it seems there is not a random() call, it just orders
> it depending on the environment. Is there any way (a hack or something) of
> shuffling the order so we would be able to stress test our Puppet codebase
> under all possible conditions? I would like to find a code which orders the
> steps and just shuffle it randomly, so we can test it 50 times to be sure no
> dependency bugs are there (from the statistical point of view)?
>
> Can you help me writing such a hack? Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/SjKsK2u1skYJ.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

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

Re: [Puppet-dev] Comparing new Fact values to previous ones

[Michael Stahnke]

On Fri, Aug 24, 2012 at 1:53 PM, Kent Shultz  wrote:
> I'd rather have the monitoring solution collect incoming facts that are
> already coming to a central location rather than reaching out to the nodes.
> I suppose a cronjob on the nodes could run facter, but still it seems
> redundant since Facter gets executed along with each Puppet run. Also, I
> plan on deploying the monitoring server on my Puppetmaster, so it's nicer to
> compare new fact values to old fact values on the same server, instead of
> having nodes constantly query PuppetDB to compare new fact values against
> old ones.
>
> But yeah, if my proposed solutions involve patching the Puppet or PuppetDB
> codebase, I could see how your suggestion might be simpler. It just seems
> like better practice to leverage the facts that *are already coming in*.
>
> Can you give me an idea of what you're talking about with running facter
> node-side and comparing against values in PuppetDB?

I had a hair-brained idea for a while to expose fact values via SNMP,
but I never went anywhere with it.

(I realize this is tangental, but it reminded me of it)

Mike

>
> Thanks,
> Kent
>
> On Friday, August 24, 2012 10:29:28 AM UTC-7, Andy Parker wrote:
>>
>> Wouldn't having your monitoring tool watch the output of `facter
>> ` on the nodes that are being monitored achieve what you are
>> looking for? That seems like it would be a pretty straightforward and
>> uncomplicated way of doing this.
>>
>> On Thu, Aug 23, 2012 at 7:09 PM, Kent Shultz  wrote:
>> > EDIT:
>> >
>> > ”Id like to know the best way to collect new/incoming Fact values for a
>> > node and compare it to old/previous values (i.e. from a node making a 
>> > puppet
>> > run)”
>> >
>> > I meant the last parenthetical bit to come after ”new/incoming fact
>> > values”
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Puppet Developers" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/puppet-dev/-/JOZlrJsa0RIJ.
>> > To post to this group, send email to puppe...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > puppet-dev+...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/puppet-dev?hl=en.
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/9xfAi0KIQCMJ.
>
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

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

Re: [Puppet-dev] LDAP interface: questions regarding Puppet support for LDAP Account Manager

[Michael Stahnke]

On Thu, Aug 23, 2012 at 10:49 AM, Roland Gruber  wrote:
> Hi all,
>
> I would like to add support for Puppet to my OpenSource project LDAP Account
> Manager (LAM): http://www.ldap-account-manager.org/
> This will provide you a free web GUI to manage your Puppet entries in your
> LDAP directory (incl. entry templates, file upload via CSV and PDF export).

I assume you're using
http://projects.puppetlabs.com/projects/1/wiki/Ldap_Nodes as your
reference?
>
> Since I am no Puppet user I have little knowledge about how you typically
> use it. Therefore, I hope you can answer some questions to help me to
> provide the right GUI elements for you. ;-)
>
> Here is what I plan for the page layout:
>
> puppetVar:
> Multi-line text field where the user can enter one option in each line. LAM
> will then split them by line and fill the attribute values.
Seems fine.
>
> puppetClass:
> Multi-line text field where the user can enter one option in each line. LAM
> will then split them by line and fill the attribute values.
> I first thought about some drop-down to select the class and an "Add"
> button. But this will be slow when adding lots of classes.
> What do you think would be the best for you to enter the data?
That should workl
>
> environment:
> This is a multi-value field. So a drop-down box cannot be used. Maybe a
> multi-selection list or a drop-down box and the option to add additional
> values.

> Do Puppet entries usually have more than one environment?
A node only belongs to a single environment. So, it shouldn't be
multi-valued, IIRC.

> The list of environments is fixed?
Not at all.  You can have many (even dynamic) environments.

I mean the possible environments could be
> configured in the LAM configuration to show only predefined values to the
> user?
Not easily with the current tooling.  At least not that I can think of.

>
> parentNode:
> I guess all LDAP entries with objectClass "puppetClient" can be used and I
> have to insert the "cn" attribute's value
What is parentNode?  I'm not familiar with that field.


>
>
> Thanks in advance for your help. :)
>
>
>
> Best regards
>
> Roland
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/r3A0EvoKKlAJ.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

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

Re: [Puppet-dev] Bundling minitar for puppet module face

[Michael Stahnke]

On Mon, Aug 6, 2012 at 10:16 AM, Ken Barber  wrote:
> Hi puppet-dev,
>
> TL;DR - I'm thinking about shipping minitar with puppet to make module
> install/build work consistently (and to ease development) (see:
> http://projects.puppetlabs.com/issues/15841) and wanted some feedback
>
> --
>
> So in case you don't already know - the puppet module face utilises
> system tar and gzip to unpack and pack modules. This has been
> troublesome for me - and I anticipate it will continue to cause
> trouble.
>
> Case in point - I was pondering the following ticket:
>
> http://projects.puppetlabs.com/issues/14333
>
> And how one would implement it in a tar implementation agnostic way.
> The problem is, every tar implementation (bsd, sun, gnu) have
> different switches to support this requirement. I wanted however to
> zoom out and propose that we instead start bundling our own version of
> archive-tar-minitar with Puppet for this very use case, plus for some
> other reasons:
>
> https://github.com/halostatue/minitar
> https://rubygems.org/gems/archive-tar-minitar
>
> So as another example of hassle - I recently I had some fun getting
> Sun tar working with the puppet module face, and found that the
> discrepancies created issues - in the end I just supported gnu tar,
> but this puts a dependency now on the need for 'gtar' on the host
> before the tool will work.
>
> Another example - to get windows working we could either ship tar, or
> do something like I'm proposing. Again, using our own tool means there
> is much less special casing for platform and tar implementation.
>
> What do people think about this? Do you think there is a better way to
> get agnostic support for tar? All comments welcome ...
>
> If bundling is acceptable - how would you like to see it done? Today -
> I'm considering moving it into the Puppet:: namespace and effectively
> forking it like we have done for other tools. Since minitar hasn't
> changed for 4 years (last release was 2008) I don't anticipate a lot
> of frequent changes (perhaps ongoing Ruby version support?).
>
> I've created a ticket to track this btw and made some notes on why I'm
> thinking this way:
>
> http://projects.puppetlabs.com/issues/15841
>

If you're going to bundle it, I'd rather us not fork it.  Keep it in
its own directory, and allow distros to rm -rf it, and add mini-tar as
a dependency.

http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries pretty
much sums up my thoughts on bundled libraries in general.  Mcollective
is actually a decent example of bundling that is easily undone and
works for package maintainers.



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

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

[Puppet-dev] State of Puppet 3.0 and our commitment to quality

[Michael Stahnke]

As many of you have doubtless noticed, Puppet 3 and Facter 2 have been sitting
in RC (Release Candidate process) for a long time. That's about to change, but
they won't be getting released as they currently stand. Puppet 3 and Facter 2
have been pulled out of the RC process after we recognized that the performance
needed to be worked on and the reworked pluginsync was not going to solve the
problems that we had aimed for it to solve. What this means is the Facter
2.0rc and Puppet 3.0rc branches will be removed, and work will be targeted at
the Facter 2.x and Puppet 3.x branches. When they are ready for release we will
restart their rc process, continuing from the last rc tag.

In order for us to be able to concentrate on getting things right, we are going
to concentrate all of our efforts on 3.0 until it is out. After it is out we'll
move to an alternating release cadence between the Puppet 2.7/Facter 1.6 series
and the Puppet 3.x/Facter 2.x series. At this point Puppet 2.7/Facter 1.6 will
be in bug fix only mode, all new features will go into the Puppet 3.x/Facter
2.x series.

One reason for the Puppet 3 and Facter 2 (and Hiera 1) releases to to reset our
version number system to match SemVer (seehttp://semver.org for more
information about what exactly that is, if you are not familiar with it). At
the moment it is still a little bit up in the air how we are going to try to
focus work on 3.0.y bug fixes and new, backward compatible features for later
3.x versions. We'll keep you posted as we come up with a plan.

If you have questions or concerns, please let us know.

Mike Stahnke
Community Manager

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

Re: [Puppet-dev] Announce: Puppet 2.7.16rc1 Available

[Michael Stahnke]

On Wed, Jun 6, 2012 at 5:06 PM, Trevor Vaughan  wrote:
> All,
>
> Very awesome work on this release and I'm looking forward to trying it out.
>
> Is there any chance that DNS SRV records are going to make it into 2.7?

Short answer, no.

It required some configuration parsing changes that were quite invasive.


>
> Thanks,
>
> Trevor
>
> On Wed, Jun 6, 2012 at 7:52 PM, Matthaus Litteken
>  wrote:
>> Puppet 2.7.16rc1 is a maintenance release candidate for Puppet in the
>> 2.7.x series. (Puppet 2.7.15 died in the thunderdome). The release notes 
>> below
>> include notes from the 2.7.15 series, so you may see some changes repeated
>> from previous emails.
>>
>> Downloads are available at:
>>  * Source https://downloads.puppetlabs.com/puppet/puppet-2.7.16rc1.tar.gz
>>
>> Windows package is available at
>> https://downloads.puppetlabs.com/windows/puppet-2.7.16rc1.msi
>>
>> RPMs are available at https://yum.puppetlabs.com/el or /fedora
>>
>> Debs are available at  https://apt.puppetlabs.com
>>
>> Mac package is available at
>> https://downloads.puppetlabs.com/mac/puppet-2.7.16rc1.dmg
>>
>> See the Verifying Puppet Download section at:
>> https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
>>
>> Please report feedback via the Puppet Labs Redmine site, using an
>> affected puppet version of 2.7.16rc1:
>> http://projects.puppetlabs.com/projects/puppet/
>>
>>
>> ## Puppet 2.7.16rc1 Release Notes ##
>>
>> (#8858) Explicitly set SSL peer verification mode.
>>
>>    In Ruby 1.8 the Net::HTTP library defaults to skipping peer
>> verification when
>>    no mode is explicitly set.  Ruby 1.9, on the other hand, does not:
>> it defaults
>>    to verification of the peer certificate - leading to failure when
>> we depended
>>    on the default value in our HTTP setup.
>>
>>    This changes to explicitly set the verification mode, ensuring we get
>>    consistent results across all Ruby versions.
>>
>> *Significantly improve compilation performance when using modules
>>    When autoloading classes/defines, the typeloader constructs a set of
>>    possible locations for the class, based on its name. Effectively, it
>>    will look in the canonical locations corresponding to each namespace in
>>    the fully-qualified name. So for each namespace, it will ask the
>>    environment for a Puppet::Module instance for that module, to ask it
>>    which of the module's potentially manifests match the class it's looking
>>    for. To answer that request, the environment instantiates a
>>    Puppet::Module.
>>
>>    This amounts to potentially thousands of Puppet::Module instances being
>>    created, because it does this many times (based on nesting of the class
>>    name) per include/autoload/import. When Puppet::Module instances are
>>    created, they parse and load their metadata.json file, in part to
>>    validate their use. This implies that each compilation results in
>>    metadata.json being parsed thousands of times, which is extremely slow
>>    (and obviously provides no actual benefit).
>>
>>    Fortunately, the environment object already keeps a list of
>>    Puppet::Module instances for every module in its modulepath. The fix
>>    applied here is simply to change the environment such that it provides
>>    modules by looking them up in its cached list, resulting in up to an
>>    order of magnitude improvement in compilation time.
>>
>> *Colorize console output on Windows
>>    Previously, `Puppet[:color]` was false on Windows, because the Windows
>>    console does not support ANSI escape sequences.
>>
>>    The win32console gem converts ANSI color escape sequences into Win32
>>    console API calls to change the foreground color, etc. If the output
>>    stream has been redirected to a file, then the gem does not translate
>>    the sequences, instead preserving them in the stream, as is done on
>>    Unix.
>>
>>    To disable colorized output specify `color=false` or `--color=false` on
>>    the command line.
>>
>>    This commit adds a `Puppet.features.ansicolor?` feature that defines
>>    whether ANSI color escape sequences are supported. On Windows, this is
>>    only true if the win32console gem can be loaded. On other platforms, the
>>    value is always true.
>>
>>    The win32console gem will be packaged into the Windows installer, and
>>    so, `Puppet[:color]` now defaults to true. If the gem can't be loaded,
>>    then puppet will revert to its previous behavior.
>>
>> (#8174) Allow defines to reference topscope
>>
>>    Because the compiler re-assigned the topscope, looking up topscope vars
>>    or facts from a defined resource type was causing deprecation warnings
>>    when it should not be. By cherry-picking commits
>>    b02aa930a03a282588e81f65e14f47a138a4b9f0 and
>>    c995be16bc9e3ad8dbad9d21b49df76de5b72ea9 the topscope is no longer
>>    re-assigned and so defined resource types can now lookup these kinds of
>>    variables without problem.
>>
>> Evaluate node classes eit

Re: [Puppet-dev] Announcing Razor

[Michael Stahnke]

On Thu, May 24, 2012 at 5:44 AM, Ashley Penney  wrote:
> My only question is:  Does this really need Ruby 1.9?  As a Redhat user I
> firmly live years in the past, lumbered with ancient versions of everything
> we use in our toolchain.  The module appears to only support Ubuntu in the
> first place but it doesn't look easily portable with the references to Ruby
> 1.9.  If so we'll be unable to move to Razor, which is a shame because it
> looks -awesome-.  Maybe when it makes it to a PE release we can use it. :)
>
It's Ruby 1.9 right now.  In some very small discussions we've had, I
think porting to 1.8.7 is something will be attempting to undertake,
but it hasn't been officially placed on the roadmap, that I know of
yet.  I know a few devs have mentioned it probably wouldn't be too bad
to fix up.  So, keep your eyes on the project and hopefully we'll be
having 1.8.7 support.  I won't promise it, but we will certainly
communicate out if it can't happen for some reason.

Mike

>
> On Wed, May 23, 2012 at 8:10 PM, James Turnbull 
> wrote:
>>
>> Puppet Labs is really thrilled to announce, in conjunction with EMC, our
>> new open source bare metal provisioning tool: Razor.
>>
>> Razor is next generation provisioning software that handles bare metal
>> hardware and virtual server provisioning with inventory discovery and
>> tagging, rule-based policy management, and extensible broker plugin
>> integration. It integrates closely with Puppet and Facter.
>>
>> The full announcement and a module to install it is on the Puppet Labs
>> blog:
>>
>> http://puppetlabs.com/blog/puppet-razor-module/
>>
>> This excellent post from Nick Weaver, the EMC guy behind the original
>> idea, takes you through the history, background and workflow of Razor:
>>
>>
>> http://nickapedia.com/2012/05/21/lex-parsimoniae-cloud-provisioning-with-a-razor/
>>
>> And finally - being open source - you can find the code at:
>>
>> https://github.com/puppetlabs/Razor
>>
>> Regards
>>
>> James Turnbull
>>
>> --
>> James Turnbull
>> Puppet Labs
>> 1-503-734-8571
>> To schedule a meeting with me: http://tungle.me/jamtur01
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

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

Re: [Puppet-dev] Re: [Puppet Users] Announcing Razor

[Michael Stahnke]

On Wed, May 23, 2012 at 9:53 PM, Russell Jackson  wrote:
> On 05/23/2012 05:10 PM, James Turnbull wrote:
>>
>> Puppet Labs is really thrilled to announce, in conjunction with EMC, our
>> new open source bare metal provisioning tool: Razor.
>>
>> Razor is next generation provisioning software that handles bare metal
>> hardware and virtual server provisioning with inventory discovery and
>> tagging, rule-based policy management, and extensible broker plugin
>> integration. It integrates closely with Puppet and Facter.
>>
>> The full announcement and a module to install it is on the Puppet Labs
>> blog:
>>
>> http://puppetlabs.com/blog/puppet-razor-module/
>>
>> This excellent post from Nick Weaver, the EMC guy behind the original
>> idea, takes you through the history, background and workflow of Razor:
>>
>>
>> http://nickapedia.com/2012/05/21/lex-parsimoniae-cloud-provisioning-with-a-razor/
>>
>> And finally - being open source - you can find the code at:
>>
>> https://github.com/puppetlabs/Razor
>>
>> Regards
>>
>> James Turnbull
>>
>
> I take it the actual "microkernel" isn't open source? All I can find is a
> ISO image.
The kernel is open source, I think it's just reusing something based
on busybox, and possible right off the busybox website.  I'll find out
for sure and get a pointer to that source code.  We certainly are not
trying to hide it.
>
> --
> Russell A. Jackson 
> Network Analyst
> California State University, Bakersfield
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>

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

[Puppet-dev] Announce: PuppetDB 0.9.0 (first release) is available

[Michael Stahnke]

PuppetDB, a component of the Puppet Data Library, is a centralized storage
daemon for auto-generated data. This initial release of PuppetDB targets the
storage of catalogs and facts:

*  It’s a drop-in, 100% compatible replacement for storeconfigs
*  It’s a drop-in, 100% compatible replacement for inventory service
*  It hooks into your Puppet infrastructure using Puppet’s pre-existing
   extension points (catalog/facts/resource/node terminuses)
*  It’s much faster, much more space-efficient, and much more scalable
than current
   storeconfigs and the current inventory service.
   *  We can handle a few thousand nodes, with several hundred
resources each, with a 30m
  runinterval on our laptops during development.
*  It stores the entire catalog, including all dependency and
containment information
*  It exposes well-defined, HTTP-based methods for accessing stored information
*  Documented at http://docs.puppetlabs.com/puppetdb
*  It presents a superset of the storeconfigs and inventory service
APIs for use in scripts
or by other tools
*  In particular, we support arbitrarily nested boolean operators
*  It decouples catalog and fact storage from the compilation process
*  Goodbye puppetq...PuppetDB subsumes it
*  It works Very Hard to store everything you send it; we auto-retry
all storage requests, persist
   storage requests across restarts, and preserve full traces of all
failed requests for
   post-mortem analysis
*  It’s secured using Puppet’s built-in SSL infrastructure
*  It’s heavily instrumented and easy to integrate its performance info into
   your monitoring frameworks

As this is the first public release, the version is 0.9.0 (a.k.a. “open beta”).
While we’ve been using PuppetDB internally at Puppet Labs for months without
incident, we encourage you to try it out, hammer it with data, and let us know
if you run into any issues! A 1.0 release will come after a few cycles of bug
squashing.

# Downloads

Available in native package format at

http://yum.puppetlabs.com

http://apt.puppetlabs.com

Source (same license as Puppet):  http://github.com/puppetlabs/puppetdb

Available for use with Puppet Enterprise 2.5.1 and later at

http://yum-enterprise.puppetlabs.com/ and http://apt-enterprise.puppetlabs.com/

# Documentation (including how to install): http://docs.puppetlabs.com/puppetdb

# Issues can be filed at:
http://projects.puppetlabs.com/projects/puppetdb/issues


Michael Stahnke
Community Manager
Puppet Labs

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

Re: [Puppet-dev] does this mean no 2.7.14 ?

[Michael Stahnke]

2.7.14 released today. We will continue maintaing 2.7.x for a while now.



On Wed, May 2, 2012 at 5:09 PM, Jo Rhett  wrote:
> On May 2, 2012, at 7:35 AM, Peter Meier wrote:
>
> Unlikely, as up to now usually two major releases were supported for quite a
> while. Why do you assume it died?
>
>
> I saw RCs but no shipment, and then comments about the tree being frozen.
>
> --
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet
> projects.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

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

[Puppet-dev] Creating a system module path (starting with Telly)

[Michael Stahnke]

There was some discussion and concern about moving the Nagios
types/providers out of the core area of Puppet for Telly.  We made a
mistake of talking about a point solution to a problem rather than the
vision on where we’d like it to go, and why.  We’ve attempted to
outline this a bit more so you can hopefully have a better
understanding of our ideas.  As always, feel free to comment and voice
concerns.  This isn’t set in stone and at this point is a proposal.

== The Problem ==

Bundling types and providers into the core of Puppet has a few problems.

The most important problem is that it ties releases of the types or
providers to releases of core Puppet.  That is a pretty slow moving
(for stability) system, and it is also a system where most of the
investment goes into supporting new releases rather than improving
older releases.

We want to keep our core stable, while allowing the community platform
experts, distro maintainers and other users to enhance the experience
with certain aspects of Puppet without having to wait for the next
major release.

The secondary problem is that it plays favourites - some platform
types are in core, others are not.  Some monitoring systems, or disk
management systems are in core, others are not.  That doesn't reflect
the real importance of those types, or that some are more special or
more stable than others - just happenstance of time.

On the other hand, having Puppet work out of the box is awesome.  You
should be able to install Puppet and immediately get started, managing
your platform and generally doing awesome things.

Puppet with no types, and no providers, is not awesome.  It can't do
anything - and "install twenty things, then ..." is not a good
introductory experience.

== Proposed Solution ==

We want to take some of the great lessons from other platforms - Perl,
Python, and Ruby - and apply them to this problem:

We are proposing to pull more types and providers out of Puppet, so
they get the benefit of an independent release cycle, and the
advantages of full forge integration.

We also propose to have a "system" module path: a set of modules that
ship with core Puppet, taken from the forge, and available by default
at install time.  They will ensure that Puppet is still awesome out of
the box - but that you can list modules and their versions, and can
update freely.

We also plan a "vendor" module path, and a "site" module path.  Other
platforms have shown the value of this: when distributions package
Puppet, they might want more or different modules to support their
systems better.  Allowing them to drop into the vendor module path and
operate in the same way as our system modules makes it easy to use
normal modules in an awesome way.

Finally, the "site" module path allows for easy deployment of modules
through other packaging systems like yum and apt, internally to
companies and sites that want a different path for versioning modules.
 They separate the mutable path used by the local tool and the managed
path for self-packaged modules.

This seems to offer the best of both worlds: we can take full
advantage of the strengths of modules, but without giving up the
awesomeness of Puppet that does great things out of the box.

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

Re: [Puppet-dev] Taking github noise away from puppet-dev list

[Michael Stahnke]

So, after a week of contemplation, I don't feel like we landed anywhere.

We have people that want the github noise off of the list.

We have people that want to be able to comment on patches on the list,
but not using the current workflow.

What should we do here?  I'm still inclined to promote discussion by
removing the github output from the dev list and switching that to the
commit list.  What it sounds like we really want is some magic github
+ mailing list integration that doesn't exists to the best of my
knowledge.

We also got a pretty small sample size in response, so I'm sure that
making any executive decision will sit well.

Round 2 of discussion?  Does anybody have any actions proposed that we
can easily take now?


Mike

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

Re: [Puppet-dev] Three prototypes

[Michael Stahnke]

On Thu, Apr 19, 2012 at 1:39 PM, Ken Barber  wrote:
>> An interactive puppet shell: 
>> https://github.com/lak/puppet/tree/prototype/master/puppet_shell
>>
>> The best tool I ever had for managing ldap directories was a simple, stupid 
>> tool I wrote called ldapsh:  http://search.cpan.org/dist/ldapsh/ .  It 
>> wasn't much of a shell (e.g., no autocomplete), but it was still 100x better 
>> than the tools at the time.  I've always wanted something similar in Puppet, 
>> so I figured I'd give it a shot.
>>
>> The basic idea is that you'd treat the resource types as the top-level 
>> directories, and you could cd around, look at resources, edit them, clone 
>> them, or remove them.  The reality isn't that nice, because not all resource 
>> types play well with this -- e.g., you can't list file instances at all.  
>> It's also just really obvious how much work it is to make an ok shell, and 
>> you'd still just rather have bash or whatever.
>>
>> I think a FUSE filesystem would be fantastic for this, especially if it 
>> supported connecting to other hosts, or even parallelizing across 
>> mcollective, but this is more interesting experiment to make a point than 
>> anything I'd recommend actually supporting.
>
> This tool seems interesting - are we able to plugin-sync faces
> properly yet?
We are in master.

> Would be good to get this out into a module. At the very
> least it would be awesome for training purposes to teach people the
> power of the RAL, but beyond that it starts to get into the discussion
> we were having with Paul Anderson about his lcfg tooling that drives
> his components. I'm fascinated by the idea that not only should Puppet
> be useful for setting policy, but perhaps for providing cross-platform
> real time control on the CLI and this certainly asserts that some
> more.
>
> ken.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>

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

Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

[Michael Stahnke]

On Mon, Apr 16, 2012 at 11:36 AM, Todd Zullinger  wrote:
> Michael Stahnke wrote:
>>
>> For the next major Puppet version, code-named Telly, we have some changes
>> coming.  This is the first in a series of emails around these changes and
>> may require some input from the community.
>>
>> For Telly, the nagios types will be moved into a module.  This allows them
>> to be iterated on in isolation from the rest of Puppet's core release cycle
>> and process. In the future we have plans to move several other types into
>> modules that can be individually maintained, improved, tested and used.
>>
>> The module for Nagios will be available on the Forge.
>>
>> The upgrade path is the thing we need some feedback about.  The basic
>> steps to upgrade would be to setup a Telly master, and then install the
>> Nagios module via the Puppet Module Tool, which ships integrated with
>> 2.7.13+ and Telly.
>
>
> Is it possible to package these modules for distros?  In the past, we've had
> a few requests to do this for third-party modules but we didn't do this
> because there wasn't really any standard for it.  With puppet module tool
> being integrated now, perhaps that's something that can be reconsidered.
>
> I'm thinking that for folks using rpm, they'd rather see an update that
> pulls in the same fucntionality as they had before.  And even for new
> installs, I'd personally prefer to install these things via rpm.  If I
> wanted to use a secondary package management system, I could use gems or
> eggs or CPAN, but I don't. ;)

Todd, welcome and I feel your pain.  Trust me, I pushed every way I
could to use native packages as our module deliver mechanism.  However
we have some odd requirements that make things not work as well with
RPM (or deb, or gems).  Basically we need a mechanism to allow
multiple versions installed into separate environments (paths on
disk).  That sort of ruled out traditional packaging systems, without
doing some installation and symlink-selection magic.  Even then, there
were some issues.

Something like pm2rpm and pm2deb is very likely something we'll need
to make the lives of Puppet Users happy.  It should be fairly simple
and we'll want to be sure that the default module path is something
that is FHS compliant.

We'll also want to work with Jordan and see if we can get packaging
Puppet Modules (in this format) as an option with FPM.  I think FPM
already does some Puppet Module stuff, so it may not need any real
updates.

Mike



>
> I think it's good to split out these things, as it would allow us to
> properly add a nagios dep to the hypothetical puppet-module-nagios package.
>
> --
> Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
> ~~
> I am free of all prejudice. I hate everyone equally.
>    -- W. C. Fields
>

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

[Puppet-dev] Supported Ruby Versions for Telly

[Michael Stahnke]

Puppet Labs is happy to announce full support for Ruby 1.9.3 will be part of
the next major release of Puppet, codenamed Telly.  Ruby 1.8.7 and 1.9.3 are
considered the primary supported Ruby versions, on all platforms including
Unix, Linux, Windows, and MacOS-X.  Ruby 1.8.5 is also supported, on the agent
only.

The Puppet 2.7 series featured initial support for the Ruby 1.9 series, and we
are happy to see that work completed and brought forward to full production
support in the forthcoming release.

Other Ruby versions including 1.8.6, 1.9.1, and 1.9.2 are not officially
supported. Ruby implementations other than the "MRI" series are not officially
supported. We will accept patches that fix issues on other (non MRI)
Ruby systems.

1.9.3 was selected due to its inclusion in Fedora 17 (Beefy Miracle) and
Ubuntu Precise Pangolin.

Previews of Telly should be available in May. If you'd like to see some of the
changes happening today, you are also welcome to run Puppet's master branch.

If you have questions or concerns, feel free to respond here.

Mike Stahnke
Community Manager

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

[Puppet-dev] Telly: Nagios types moving into Module

[Michael Stahnke]

For the next major Puppet version, code-named Telly, we have some
changes coming.  This is the first in a series of emails around these
changes and may require some input from the community.

For Telly, the nagios types will be moved into a module.  This allows
them to be iterated on in isolation from the rest of Puppet's core
release cycle and process. In the future we have plans to move several
other types into modules that can be individually maintained,
improved, tested and used.

The module for Nagios will be available on the Forge.

The upgrade path is the thing we need some feedback about.  The basic
steps to upgrade would be to setup a Telly master, and then install
the Nagios module via the Puppet Module Tool, which ships integrated
with 2.7.13+ and Telly.

The only caveat with this is that if, in the past, you were relying on
the Nagios types and forget to install that module (or are unable to
for some reason), you would get a failure.  The best proposal we could
come up with was to have the platform team add some code that lets the
user know that the Nagios types have moved. This basically moves this
into a 'fail-well' state.  We'll try to provide the best information
possible to the end-user about what is going on.

Is that an acceptable path moving forward?  Comments and discussion welcome.


Mike Stahnke
Community Manager

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

[Puppet-dev] Re: [Puppet Users] Taking github noise away from puppet-dev list

[Michael Stahnke]

On Mon, Apr 9, 2012 at 2:11 PM, Jeff McCune  wrote:
> On Mon, Apr 9, 2012 at 5:09 PM, Michael Stahnke 
> wrote:
>>
>>
>> We have a goal to foster development discussion from the community.
>> Because of that, I am proposing we move the github notifications to a
>> new list, puppet-commits.  I realize this may have a consequence of
>> reducing patch/commit discussion.  This should be compensated by:
>
>
> Everything old is new again.
>
> http://groups.google.com/group/puppet-commit ?

I was pretty sure we had this list, and then forgot to look before
sending.  Oh well.

Either way, the point remains about removing the github notifications
on the puppet-dev list.




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

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

[Puppet-dev] Taking github noise away from puppet-dev list

[Michael Stahnke]

Since our move to github for pull requests and patches, the usefulness
of puppet-dev has declined significantly.  puppet-dev used to be a
great list for development discussion of puppet and the ecosystem
around it. With the information and pull request emails from github,
unless everybody has finely-tuned their email clients, the puppet-dev
list has turned into mostly noise.

We have a goal to foster development discussion from the community.
Because of that, I am proposing we move the github notifications to a
new list, puppet-commits.  I realize this may have a consequence of
reducing patch/commit discussion.  This should be compensated by:

1.  Still having a list where pull requests can be commented on
2.  Ability to comment on pull requests directly on github
3.  More forethought and discussion on the dev list prior to making a
pull request/patch.
4.  You can also watch the RSS feed for the puppet projects you have
the most interest in.

This decision isn't final, but I would like to get opinions on the
idea.  I welcome feedback until Friday, April 13.


Michael Stahnke
Community Manager

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

[Puppet-dev] Dashboard 1.2.7 available

[Michael Stahnke]

This is a maintenance release candidate of Puppet Dashboard.
It includes contributions from Carl Caum, Josh Lifton, and Matt Robinson.

This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.7
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html


1.2.7 Release Notes
===
Upgrade vendored rails from 2.3.12 to 2.3.14

   This upgrade includes security fixes:

   http://weblog.rubyonrails.org/2011/8/16/ann-rails-2-3-14/
   https://github.com/rails/rails/compare/v2.3.12...v2.3.14

   This upgrade was accomplished like so:

   gem install rails --version 2.3.14
   rake rails:freeze:gems

Add parameters support for nodes and node groups

   Previous to this commit there was no rake API for setting parameters on
   nodes and node groups.  This commit adds the `node:parameters` and
   `nodegroup:parameters` tasks. Both accept two arguments:
   - *name* Which node or node group to apply the parameters to
   - *parameters* In format param1=val,param2=val2

   This format was chosen for two reasons. I wanted multiple parameters to
   be
   able to supported on a single command. Further, rake doesn't support
   multiple instances of the same argument so a format such as
   'parameter=param,value parameter=param2,value2' could not be supported.

   Example:
   `rake node:parameters name=master.puppet.internal \
   parameters=ntpserver=ntp1.mydomain.com,dnsserver=dns.mydomain.com`

   Potential Issues:
   Currently it is impossible to escape the *=* or *,* characters when
   specifying the parameters value.  So node or node group parameters that
   include a comma or equal sign will not be able to be specified.

1.2.7 Changelog
===
Carl Caum (1):
 0108c04 Add parameters support for nodes and node groups

Joshua Harlan Lifton (3):
 cd417f1 Add account information option to header
 44d8da0 Refactor how account widgets are added to the header
 f2c3d54 Fix regression in access control protections

Matt Robinson (1):
 ecec120 Upgrade vendored rails from 2.3.12 to 2.3.14

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

[Puppet-dev] Announce: Puppet 2.7.12 now available

[Michael Stahnke]

Puppet 2.7.12 is a maintenance release candidate for Puppet in the
2.7.x series.

Downloads are available:
 * Source http://downloads.puppetlabs.com/puppet/puppet-2.7.12.tar.gz

See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 2.7.12
 http://projects.puppetlabs.com/projects/puppet

Full Release Notes at:
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.12

Packages available at:
http://yum.puppetlabs.com and http://apt.puppetlabs.com

## Community MVP for this release: Konrad Scherer for
 Updating the zypper package provider to support zypper 0.6

## Puppet 2.7.12 Highlights ##

## Features ##
* Zypper package provider supports zypper 0.6
* Raise default key lengths in Puppet
 * Restored agent lockfile behavior to 2.7.9;  in 2.7.10 and 2.7.11,
'puppet agent --disable' begun to use a new lock file named
'puppetdlock.disabled'.  This was determined to cause compatibility
issues with certain external tools, so the pre-2.7.10 behavior has
been restored.
 * Agent lockfile backwards compatibility to support users upgrading
from 2.7.10 or 2.7.11.
 * Improved status / notification message when attempting to run an
agent after agents have been administratively disabled (via 'puppet
agent --disable').
 * Cron error messages on Windows less cryptic
 * Don't overwrite symlinks in augeas provider
 * Fix zypper provider so ensure => 'latest' works

Plumbing For Puppet Module Tool improvements (note this feature will
be fully available in Puppet 2.7.13)
* Module requirements should include versions
* Fix SemVer's range behavior to work with Ruby 1.9
* Face actions should be able to set exit codes
* Implement a rich console logging prototype
* Enhance the uninstall PMT action
* All forge interactions should be centralized
* Add module dependency errors to module list output
* Enhance PMT search action output


## Bug Fixes ##
Windows Bug Fixes
* Fix puppet agent --listen on Windows
* Don't add execute bit to newly created files on Windows
* Skip default file permissions for sync'ed files on Windows
* Allow POSIX paths for files served to Windows agents
* Refactor Windows administrator detection
* Disable puppet kick on windows


Puppet 2.7.12 includes contributions from the following people:
Ben Hughes, Brice Figureau, Chris Price, Daniel Pittman, Deepak
Giridharagopal, Dominic Cleal, Dominic Maraglia, Gary Larizza, James
Turnbull, Jeff McCune, Jeff Weiss, Josh Cooper, Josh Lifton, Kelsey
Hightower, Konrad Scherer, Luke Kanies, Matt Robinson, Matthaus
Litteken, Michael Stahnke, Moses Mendoza, Nan Liu, Nick Fagerlund,
Nick Lewis, Ossi Herrala, Patrick Carlisle, Peter Meier, Pieter van de
Bruggen, R.I.Pienaar, Sean Millichamp, Stefan Schulte, Tim Bishop




---

Ben Hughes (1):
  4911faf (#12195) Fix future ruby warning messaves in process_name

Brice Figureau (1):
  0f19cbe (#11990) Puppetdoc rdoc should also parse README.rdoc

Daniel Pittman (43):
  9e7ce16 (#11057) Note why a scheduled run was skipped in Puppet.
  0f2bb27 (#6710) Fix Ruby 1.9.2 failures due to Array#to_s changes.
  dd0e405 Document why we disable GC during the test runs.
  ed24b80 (#6771) Disconnect any ActiveRecord connection after every test.
  80ecd88 (#6771) Stop stubbing some feature tests.
  3892875 (#6771) Stop other AR connection handling.
  3310470 (#12188) Better handling of PID file cleanup warnings.
  289dddc (#12188) Handle Win32 as well as Unix in pidfile tests.
  37a3e82 (#12296) Test cycle detection on real Puppet::Type instances.
  316de58 (#12296) Make `Puppet::Type` ordered.
  3f2 (#12296) Now that `Puppet::Type` is ordered, use that.
  83ca48d Make `Puppet::Provider` ordered.
  d89423f Use natural ordering of Puppet::Provider.
  f8d4be6 (#12296) Acceptance test for cycle detection in graphs.
  20e03a9 (#11423) Better error when imported resources overlap.
  a8a0f5f (#12268) String#each is not available in Ruby 1.9
  7da2c58 Alternate, and portable, stubbing of execution for upstart spec.
  03e3756 (#2927) Acceptance test for symbolic file modes.
  47510b0 Property Spec cleanup: extract new subclass to let method.
  8f9214e Property Spec cleanup: extract mock provider to let method.
  4157102 Property Spec cleanup: extract mock resource to let method.
  f17dbf7 Property Spec cleanup: extract property instance to a let method.
  a5d7bd6 Property Spec cleanup: remove some pointless extra stubs.
  cd536ab Property Spec cleanup: remove unused instance variable.
  2775dd7 Property Spec cleanup: extract more let methods.
  d66bb00 Property Spec cleanup: last let method extraction.
  7f84c49 Property Spec cleanup: eliminate stubbing of resource
and provi

[Puppet-dev] Statement from Puppet Labs regarding Github Compromise

[Michael Stahnke]

Over the weekend, we saw github[1] had been attacked, and potentially
malicious code was pushed onto the rails project. This was concerning
to us at Puppet Labs as we host nearly 100% of our code with github.

Our course of action ran as follows:

1.  We first checked our Rails based applications for the mass
assignment[2][3] issues. This includes the Puppet Forge and Puppet
Dashboard. It was determined that neither of these products were
vulnerable to mass assignment issues. Other projects using
ActiveRecord (without rails) were also verified.

2.  We checked our repositories for suspicious commits.  During the
time of the compromise of github, the attacker could have created a
phony git setup and pushed onto one of our projects with a malicious
commit.

For puppet, facter and dashboard we get notified when a push happens
onto a branch.  We saw no out-of-place commits occur.

Those repositories, and others repositories are being
hand-reviewed/audited for anything odd in the last two weeks.  This
includes repositories for mcollective, puppet modules, and packaging.


Github also made a statement saying they have "determined that no
malicious intent was present"[4] in the compromise.  At this time, Puppet
Labs also believes no harm was done as a result of this github
compromise, to our projects.

As a reminder, Puppet Labs practices Responsible Disclosure[5].  If
you ever have questions or concerns about our security practices,
contact us secur...@puppetlabs.com or see our security page[6].


Thanks,
Michael Stahnke
Community Manager


[1]https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation
[2]http://guides.rubyonrails.org/security.html#mass-assignment
[3]http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-applications/
[4]https://github.com/blog/1069-responsible-disclosure-policy
[5]http://en.wikipedia.org/wiki/Responsible_disclosure
[6]http://puppetlabs.com/security/

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

[Puppet-dev] Google Summer of Code 2012

[Michael Stahnke]

Puppet Labs will apply to be a mentoring organization for Google
Summer of Code[1] this year.  The first part of this process is to
come up with some great ideas for improvements and features in our
open source projects.  While internally we have many ideas for
projects for GSOC, I wanted to take this opportunity to solicit
feedback from the community.

If you were going to hire somebody to improve Puppet in a summer, what
would you have them work on?

If you have ideas, please put them on our wiki:
http://projects.puppetlabs.com/projects/puppet/wiki/GSOC12

If you see ideas on the wiki page you like, add a comment.  Feel free
to expand on an entry, or create your own entry.




We'll be scoping out ideas in more detail to have ready when we submit
our GSOC application.  Deadline for ideas is Monday, 27 Feb.



Thanks,

Mike Stahnke



[1] http://code.google.com/soc/

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

[Puppet-dev] Issues with Puppet 2.7.10: recommendation to stop using it

[Michael Stahnke]

We are continuing to see several issues introduced Puppet 2.7.10.  We
are recommending that users discontinue its usage.  This could mean
using 2.7.9 or waiting patiently until we can get 2.7.11 out the door.

These are the most significant tickets around the  2.7.10 regressions.

http://projects.puppetlabs.com/issues/show/12310
http://projects.puppetlabs.com/issues/show/12269
http://projects.puppetlabs.com/issues/show/12269
http://projects.puppetlabs.com/issues/show/12588

We should have declared this as a problem release earlier.  I
apologize for not doing so.

As always, if you have issues or questions, please contact us.


Mike Stahnke

stahnma in #puppet

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

Re: [Puppet-dev] Announce: Facter 1.6.6rc1 available

[Michael Stahnke]

Facter 1.6.6rc2 was cut today.  This addresses  the following issue:



Make ec2 facts work on CentOS again (#12666)

Refactoring the ec2 facts lost the support for CentOS where the
hardware address in arp -an is uppercased.  Fix and add a unit
test now that there are those

Thanks to Jeremy Katz for this patch.

This release is available for download at:
 http://downloads.puppetlabs.com/facter/facter-1.6.6rc2.tar.gz

On Wed, Feb 15, 2012 at 12:51 PM, Matthaus Litteken
 wrote:
> Facter 1.6.6rc1 is a maintenance release candidate with fixes,
> refactoring and packaging improvements.
>
> It includes contributions from the following people: Daniel Pittman,
> Jeremy Katz, Josh Cooper, Moses Mendoza
>
> This release is available for download at:
>  http://downloads.puppetlabs.com/facter/facter-1.6.6rc1.tar.gz
>
> See the Verifying Puppet Download section at:
>  http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads
>
> Please report feedback via the Puppet Labs Redmine site, using an
> affected version of 1.6.6rc1:
>  http://projects.puppetlabs.com/projects/facter/
>
> Full Release Notes at: 
> https://projects.puppetlabs.com/projects/facter/wiki/Wiki
>
> Facter 1.6.6rc1 Release Notes
> =
>
> Support EC2 facts on OpenStack
>
>    OpenStack exports an EC2 compatible API, so make the information
>    available via facts by knowing that OpenStack generates mac addresses
>    beginning with 02:16:3E
>
> #12362 Use Tempfile to generate temp files
>
>    Previously, facter used ENV['TMP'], ENV['TEMP'], /tmp, etc as it's
>    temp directory search path, using the first one that existed. It then
>    used constant file names within the temp directory to re-write the
>    files in ruby's bin directory, and bat wrappers on Windows.
>
>    First, it leads to predictable temp file names, which is bad. Second,
>    when installing facter via a non-interactive ssh shell, e.g.
>      ssh  ruby install.rb
>
>    which is what the acceptance test harness does, the TMP and TEMP
>    environment variables are usually not defined. So facter was always
>    defaulting to /tmp, which doesn't work when installing facter on
>    Windows agents during acceptance tests.
>
>    This commit just changes the install script to use ruby's Tempfile to
>    generate secure temp files that works in non-interactive shells.
>
>
> Facter 1.6.6rc1 Changelog
> 
>
> Daniel Pittman (1):
>      7d3889d (#12079) Fix order-dependent test failure due to odd stubbing.
>
> Jeremy Katz (2):
>      cb598aa Support EC2 facts on OpenStack
>      7f2a0e2 add a simple test for openstack ec2 facts
>
> Josh Cooper (1):
>      c218d84 (#12362) Use Tempfile to generate temp files
>
> Moses Mendoza (2):
>      5c5c330 Changes apple rake task to reflect package name facter
> instead of puppet.
>      f6bbe14 (#12170) Adds gem spec description
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>

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

[Puppet-dev] Re: 1 week until Feb RCs are cut

[Michael Stahnke]

On Wed, Feb 8, 2012 at 1:33 PM, Michael Stahnke  wrote:
> We have 1 week until we cut RCs for Puppet, Dashboard and Facter.  If
> you have tickets you've been working on, please try to get pull
> requests in and merged as soon as reasonably possible for this
> release.


We're not going to be able to get the Puppet RC (2.7.11rc1) out today.
We have some code still hitting, and everything has not passed through
our testing infrastructure.


Mike

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

[Puppet-dev] 1 week until Feb RCs are cut

[Michael Stahnke]

We have 1 week until we cut RCs for Puppet, Dashboard and Facter.  If
you have tickets you've been working on, please try to get pull
requests in and merged as soon as reasonably possible for this
release.


Mike

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

Re: [Puppet-dev] soliciting input on prioritization of puppet ticket #12336

[Michael Stahnke]

On Tue, Jan 31, 2012 at 11:06 AM, Chris Price  wrote:
> https://projects.puppetlabs.com/issues/12336
>
> Hello,
>
> As a result of a recent change to how we handle user-related environment
> variables when we launch processes from puppet
> (see: https://projects.puppetlabs.com/issues/5224 ), a bug was introduced
> wherein an exception will be thrown if the following conditions are met:
>
> * User's PATH contains a literal "~" character, and
> * An attempt is made (most likely via an Exec resource) to execute a system
> command with a non-absolute path
>
> I filed ticket #12336 in response to this.  At first glance it seems like a
> relatively unlikely scenario with a fairly straightforward workaround, so
> I've prioritized it "Low" for the moment.  Anyone have any concerns that
> would warrant bumping the priority up to a higher level?

I am pretty sure that is a regression.  I'd vote for that to be fixed
as early as possible.
>
> Thanks!
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

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

[Puppet-dev] Puppet Dashboard 1.2.5 Available [security update - moderate]

[Michael Stahnke]

Welcome to the first Puppet Dashboard maintenance release of the new year.

This release includes a security update to address CVE-2012-0891, a
XSS vulnerability discovered by David Dasz . We have
classified the risk from this exposure as moderate. All Puppet Dashboard
users are encouraged to upgrade when possible.

Puppet Enterprise users
should visit http://puppetlabs.com/security for links to hotfixes
and/or patches for their release. For more information, please visit
http://puppetlabs.com/security/cve/cve-2012-0891

It includes contributions from the following people: Bruno Leon,
Daniel Pittman, Daniel Sauble, Pieter van de Bruggen

This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have created Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.5
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html


Puppet Dashboard 1.2.5 Release Notes
===

(#11365) Rigorously escape user inputs (CVE-2012-0891)

   This fix addresses a bug in Puppet Dashboard versions 1.0 – 1.2.4
that allows
   for Cross Site Scripting (XSS) attacks on certain input fields. This could
   potentially allow a malicious user to share Puppet Dashboard data with other
   websites, or manipulate fields in the Dashboard database.  This commit
   sanitizes user inputs to avoid the aforementioned XSS attacks and also
   updates the jquery tokeninput library to resist XSS attacks.

(#5879) Removes 'url' column from 'nodes' table

  The url column is no longer used by Dashboard, so this
  commit removes it.


Puppet Dashboard 1.2.5 Changelog
===

Bruno Leon (1):
b448067 Fix path to pid files

Daniel Pittman (1):
da28abf Added some documentation on writing plugins.

Daniel Sauble (1):
89f6341 (#5879) Removes 'url' column from 'nodes' table

Pieter van de Bruggen (1):
 (#11365) Rigorously escape user inputs (CVE-2012-0891)

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

[Puppet-dev] Puppet 2.7.10 is available

[Michael Stahnke]

Welcome to the first maintenance release for Puppet in the
new year. Since we skipped a December release, this release is rather
large.


Thanks for the help during Triage-a-thon.  It was a great event.  See
the Puppet Labs blog for the recap.


We have several section of release notes this month due to the high
volume of commits.  Sections are Instrumentation, Core, Mac OS,
Windows, and FreeBSD.  I encourage you to look at the release notes
wiki page for full details (there are a lot).

 http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

Downloads are available:

  * Source http://downloads.puppetlabs.com/puppet/puppet-2.7.10.tar.gz
  * RPM http://yum.puppetlabs.com
  * Deb http://apt.puppetlabs.com
  * Mac DMG http://downloads.puppetlabs.com/mac
  * Gem http://rubygems.org/gems/puppet


## Community MVP for this release: Brice Figureau (@masterzen) for the
Instrumentation Framework

## Features ##
* Instrumentation Features available
* Symbolic File modes supports ( e.g. u=rw,go=r) for File type
* Write reports to a temporary file and move them into place
* Add password get/set behavior for Mac OS X 10.7
* Add support for user expiriy in pw user provider
* Improve pw group provider on FreeBSD
* Make sure managehome is respected on FreeBSD
* Add password management on FreeBSD

## Bug Fixes ##
* Make the Debian service provider handle services that don't conform
to the debian policy manual.
* Only load facts once per run
* Puppetd removes pid file upon exit
* Fix MySQL deadlock possibility within inventory service
* Test Augeas versions correctly with versioncmp
* Consider package epoch version when comparing yum package versions
* Link should autorequire target
* Use SMF's svcadm -s option to wait for errors
* Fix fact and plugin sync on Windows
* Set password before creating user on Windows
* Always serve files in binary mode on Windows
* Don't hard code ruby install paths in Windows batch files
* Don't copy owner and group when sourcing files from master on Windows
* Fix OS X supplementary group handling
* Use launchctl load -w in launchd provider (Mac OS)
* Improve error msg for missing pip command
* Better validation for IPv4 and IPv6 address in host type.

It includes contributions from the following people:
Adrien Thebo, Brice Figureau, Carl Caum, Cody Herriges, Daniel
Pittman, Deepak Giridharagopal, Dominic Cleal, Dominic Maraglia, Eli
Klein, Gary Larizza, Ilya Sher, Jacob Helwig, James Turnbull, Jeff
McCune, Josh Cooper, Joshua Harlan Lifton, Jude Nagurney, Kelsey
Hightower, Matt Robinson, Matthaus Litteken, Matthias Pigulla, Max
Martin, Michael Stahnke, Nan Liu, Nick Lewis, Patrick, Patrick
Carlisle, Paul Tinsley, Peter Meier, R.I.Pienaar, Ricky Zhou, Sean
Millichamp, Stefan Schulte, Tim Bishop, Zach Leslie, nfagerlund


See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 2.7.10:
  http://projects.puppetlabs.com/projects/puppet

Full Release Notes at:
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.10





Adrien Thebo (1):
 747ffd2 (#8341) Remove duplicate loading of facter files.

Brice Figureau (19):
 3ab4d63 Fix #10066 - when fingerprinting, agent should not daemonize
 94e9863 (#7004) Correctly form singular for indirections ending in 'es'
 e9a5116 (#6412) Return :undef when accessing non-existing
hash/array elements
 f71af6f (#10676) Include all resource statuses in reports
regardless of count
 31cef94 Add config and puppet version to the last run summary file
 b28cac8 (#7106) Obey specified owner, group, and permissions for
last run summary file
 b743b4d Instrumentation foundation layer
 6b7fcf6 Add indirection (REST usable) to manipulate instrumentation
 ff36deb Add a way to add probe to puppet code
 782f341 Add the example 'log' listener
 6c138d7 Add the 'performance' instrumentation listener
 2bf6105 Process name instrumentation listener
 fc43694 Add probe indirection for probe management
 493a1b7 Example probes for the indirector
 751ef88 Set of faces to manage instrumentation listeners, data and probes
 f7c2ea4 Fix failing tests with ruby 1.9.2 in the instrumentation framework
 b434e3b (#3757) - Move enable/disable to its own lock
 d91 (#3757) - Refactor enable/disable to its own module
 0ffe1ac (#4836) - Agent --disable should allow to put a message

Carl Caum (1):
 d092860 Retry inventory ActiveRecord transaction failure

Cody Herriges (1):
 599a146 (#11273) Updates init.pp.erb for style guide.

Daniel Pittman (15):
 cd2d2f1 (#9158) Support old and new versions of STOMP gem.
 a6996ba (#4865) Debug logging when we start evaluating resources.
 61d894e Merge pull request #61 from jblaine/patch-1
 e8e1

[Puppet-dev] Announce: Facter 1.6.5 is available

[Michael Stahnke]

Welcome to the first maintenance release for Facter in the new year.

It includes contributions from the following people: Adrien Thebo,
Barrie Bremner, Gary Larizza, Jonathan Boyett, Josh Cooper, Ken
Barber, Marcus Vinicius Ferreira, Matt Dainty, Michael Kincaid, Moses
Mendoza, Pieter Lexis

This release is available for download at:
 http://downloads.puppetlabs.com/facter/facter-1.6.5.tar.gz

Packages available on http://yum.puppetlabs.com and http://apt.puppetlabs.com

Starting this month we also will be building Mac OS X packages for
Facter and Puppet:
   http://downloads.puppetlabs.com/mac


See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.6.5:
 http://projects.puppetlabs.com/projects/facter/

Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki


Facter 1.6.5 Release Notes
=

EC2 Improvements
===

(#11566) Add windows support for ec2 facts

  This patch adds support for detecting ec2 on windows. This works
by modifying
  the linux methodology by using arp -a instead of arp -an and
searching for the
  mac address with a hyphen delimiter (as apposed to a quote).

  I've added tests and a sample fixtures which adds output from arp -a from a
  windows machine and linux machines, on ec2 and not on ec2.

  I've also re-worked the decision making into a util class so the testing is
  much easier to write and work with, so now we can test the
individual mechanism
  for detecting that we are in a cloud on their own. This will be much better
  abstracted into their own fact(s) but for now this has the least impact to
  solve the problem at hand. In the future this logic (and tests)
can certainly
  be re-used if such a fact was evercreated.

  Thanks to Feifei Jia  for contributing the original code.

(#11196) Scan all arp entries for an ec2 mac

  This patch now scans all arp entries for the magic EC2 mac address. At times
  the mac entry was being returned out of order and since we only
looked at the
  first entry there were cases where the test would fail.

  It also now removes the dependency on the arp fact which has become only
  important to the EC2 fact anyway. This was to avoid hacking the arp fact
  (which was obviously built for a different purpose) just to fix this issue.

(#8279) Join ec2 fact output with commas

  ec2 facts were being concatenated, which made array data harder to use.
  Switched to comma delimited data.

  Thanks to Hunter Haugen  for this patch.


Other Improvements
===

(#10271) Identifying 'Amazon' using '/etc/system-release'
  Previously the operating system detection depended upon the
lsbrelease package.
  This wasn't guaranteed to be present, so this could lead to
incorrect detection.
  To remedy this, the presence of /etc/system-release is now used
for detection
  on amazon linux.

(#11436) Unify memorysize and memorytotal facts

  Two different names were given for the amount of physical memory in a
  given node. Switched to the name of 'memorysize' for the RAM and added a
  fallback fact 'memorytotal' that reverts to the memorysize.

(#7753) Added error checking when adding resolves

  Added exception handling to the fact class. When adding a resolution to
  a fact, if an exception was thrown outside of the setcode block, facter
  would crash. Added handling so that if an exception is thrown, facter
  logs the error and discards the fact.

Facter 1.6.5 Changelog
===
Adrien Thebo (7):
6201820 (maint) remove redundant arch detection
cb4e294 (#7753) Added error checking when adding resolves
4633996 (#9789) Extend coverage of operatingsystem specs
5cd30eb (#8279) Join ec2 fact output with commas
5c6322a (maint) Joined conditional statements for domain
9c224d3 (#11436) Unify memorysize and memorytotal facts
82692ba (#9599) Generalize zone detection

Barrie Bremner (1):
6d21f90 Move Linux specific virtual tests to correct block.

Gary Larizza (1):
14cad7e Build a Rake task for building Apple Packages

Jonathan Boyett (1):
e6cebd3 (#9599) Add nexenta facts

Josh Cooper (1):
d1a33e5 (#11848) Don't hard code ruby install paths in Windows batch files

Ken Barber (12):
d141e7e (maint) Fix requirement for FileUtils as
operatingsystem_spec needs it now
c1604c7 (#10309) Add puppetlabs_spec helper library based on
Puppets own puppet_spec helpers
d6e8523 (#10309) Integrate new PuppetlabsSpec helpers into our
existing facter spec code and general spec cleanup
d50fc48 (#10309) Move all fixture data in spec/unit/data to spec/fixtures
a99d87c (#10309) Rename tmpfile to tmpfilename to make function clear
c473e3f (#10309) Remove the with_verbose_disabled method
3ccac87 (#9708) Amend requires in specs to use simple requires
9401b78 (#11583) Switch request method to open-uri monkey patch 'op

[Puppet-dev] Puppet 2.7.10rc1

[Michael Stahnke]

Welcome to the first maintenance release candidate for Puppet in the
new year. Since we skipped a December release, this release is rather
large.

I'll also take a moment to remind you of the Puppet Bug Triage-a-thon:
January 21st from 2012-01-21 15:00 UTC to 2012-01-22 00:00 UTC  -
http://triagepuppet.eventbrite.com/?ref=ebtn - IRC #puppethack


We have several section of release notes this month due to the high
volume of commits.  Sections are Instrumentation, Core, Mac OS,
Windows, and FreeBSD.  I encourage you to look at the release notes
wiki page for full details (there are a lot).
 http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.10rc1

## Features ##
* Instrumentation Features available
* Symbolic File modes supports ( e.g. u=rw,go=r) for File type
* Write reports to a temporary file and move them into place
* Add password get/set behavior for Mac OS X 10.7
* Add support for user expiriy in pw user provider
* Improve pw group provider on FreeBSD
* Make sure managehome is respected on FreeBSD
* Add password management on FreeBSD

## Bug Fixes ##
* Make the Debian service provider handle services that don't conform
to the debian policy manual.
* Only load facts once per run
* Puppetd removes pid file upon exit
* Fix MySQL deadlock possibility within inventory service
* Test Augeas versions correctly with versioncmp
* Consider package epoch version when comparing yum package versions
* Link should autorequire target
* Use SMF's svcadm -s option to wait for errors
* Fix fact and plugin sync on Windows
* Set password before creating user on Windows
* Always serve files in binary mode on Windows
* Don't hard code ruby install paths in Windows batch files
* Don't copy owner and group when sourcing files from master on Windows
* Fix OS X supplementary group handling
* Use launchctl load -w in launchd provider (Mac OS)
* Improve error msg for missing pip command
* Better validation for IPv4 and IPv6 address in host type.

It includes contributions from the following people:
Adrien Thebo, Brice Figureau, Carl Caum, Cody Herriges, Daniel
Pittman, Deepak Giridharagopal, Dominic Cleal, Dominic Maraglia, Eli
Klein, Gary Larizza, Ilya Sher, Jacob Helwig, James Turnbull, Jeff
McCune, Josh Cooper, Joshua Harlan Lifton, Jude Nagurney, Kelsey
Hightower, Matt Robinson, Matthaus Litteken, Matthias Pigulla, Max
Martin, Michael Stahnke, Nan Liu, Nick Lewis, Patrick, Patrick
Carlisle, Paul Tinsley, Peter Meier, R.I.Pienaar, Ricky Zhou, Sean
Millichamp, Stefan Schulte, Tim Bishop, Zach Leslie, nfagerlund

This release is available for download at:
 http://downloads.puppetlabs.com/puppet/puppet-2.7.10rc1.tar.gz

See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 2.7.10rc1:
   http://projects.puppetlabs.com/projects/puppet

Full Release Notes at:
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.10rc1





Adrien Thebo (1):
  747ffd2 (#8341) Remove duplicate loading of facter files.

Brice Figureau (19):
  3ab4d63 Fix #10066 - when fingerprinting, agent should not daemonize
  94e9863 (#7004) Correctly form singular for indirections ending in 'es'
  e9a5116 (#6412) Return :undef when accessing non-existing
hash/array elements
  f71af6f (#10676) Include all resource statuses in reports
regardless of count
  31cef94 Add config and puppet version to the last run summary file
  b28cac8 (#7106) Obey specified owner, group, and permissions for
last run summary file
  b743b4d Instrumentation foundation layer
  6b7fcf6 Add indirection (REST usable) to manipulate instrumentation
  ff36deb Add a way to add probe to puppet code
  782f341 Add the example 'log' listener
  6c138d7 Add the 'performance' instrumentation listener
  2bf6105 Process name instrumentation listener
  fc43694 Add probe indirection for probe management
  493a1b7 Example probes for the indirector
  751ef88 Set of faces to manage instrumentation listeners, data and probes
  f7c2ea4 Fix failing tests with ruby 1.9.2 in the instrumentation framework
  b434e3b (#3757) - Move enable/disable to its own lock
  d91 (#3757) - Refactor enable/disable to its own module
  0ffe1ac (#4836) - Agent --disable should allow to put a message

Carl Caum (1):
  d092860 Retry inventory ActiveRecord transaction failure

Cody Herriges (1):
  599a146 (#11273) Updates init.pp.erb for style guide.

Daniel Pittman (15):
  cd2d2f1 (#9158) Support old and new versions of STOMP gem.
  a6996ba (#4865) Debug logging when we start evaluating resources.
  61d894e Merge pull request #61 from jblaine/patch-1
  e8e1f57 (#11423) Clearer error message about duplicate imported resources.
  213cecc Revert "(#114

[Puppet-dev] Release Candidates (1 week away)

[Michael Stahnke]

We're about a  week away from the January release candidates.  If any
developers have code they'd like in
* Puppet 2.7.10
* Dashboard 1.2.5
* Facter 1.6.5

Please get it reviewd/merged.



Mike

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

Re: [Puppet-dev] Puppet bash command line completion

[Michael Stahnke]

On Tue, Jan 10, 2012 at 11:56 AM, Matt Robinson  wrote:
> I've wanted command line completion for some time, so I've whipped
> something up that gets it going:
>
> https://github.com/mmrobins/puppet-completion
>
> I've been meaning to get it to a state to merge into Puppet core, but
> haven't had the time yet, so I've made it a standalone repo so that
> people can use it if they want, or even better submit code to make it
> better or tell me a better way to do this.  Feel free to email me or
> submit pull requests with ideas or improvements.
>
> It's only for bash right now, I plan to do something for zsh since
> that's what I mainly use.

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

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

[Puppet-dev] ANNOUNCE: Puppet Dashboard 1.2.4 available

[Michael Stahnke]

This is a maintenance release candidate of Puppet Dashboard. This release
resolves issues #6717, #7554, #9529, #10017, #10076,  #11058, and
#11063.  More details below.

This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.4
http://projects.puppetlabs.com/projects/dashboard

Packages available at:
http://yum.puppetlabs.com and http://apt.puppetlabs.com

Note: We are working to add SLES/OpenSUSE support on our repositories
soon, but they are not up yet.


Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html

1.2.4 Release Notes
===
Fix #7554 Link latest report to actual report on front page

   The latest report time in the node listing on the front page was
   not linking to the latest report. Added an active link to the
   timestamp in order to navigate to the individual report.

Fix #6717 Add a rake task to cleanup orphaned report data

   The rake reports:prune task was deleting reports, but not the associated
   resource statuses, events, metrics and logs.  Running this new task will
   fix all the data you've orphaned running the prune task.

#6717 Continued - Add foreign keys and cascading deletes to report
related tables

   Using the `:dependent => :destroy` on Rails records is really slow when
   you need to delete a lot of child records since it makes an active
   record object for each one.  Instead, if we have foreign keys with
   cascading deletes, this will happen very quickly.

   We wouldn't want this if we were relying on hooks with destroy, but the
   only model that has that kind of hook is for reports, and it just
   updates the associated node table, but if you've deleted the node, that
   hook will be useless.

Fix #11063 Building deb package should keep the source tarball

   When building the deb package, the source tarball does not get saved in
   the pkg directory. Since this could be something useful to keep around,
   we should save the file. We do this by copying the latest tarball out of
   the temporary directory. The tar rake task also generates a tarball, but
   we are guaranteed that the debian source tarball will have a later mtime
   than that one.

1.2.4 Changelog
===
* 09d555a (#11063) Building deb package should keep the source tarball
* f03b2e8 (#11058) deb package should have `puppetlabs` in vendor string
* 2f4cbbd (#6717) Fix failing dependency destroy tests
* 630f540 (#6717) Update last report on the node after deleting reports
* c497195 (#6717) Add foreign keys and cascading deletes to report
related tables
* 3652aca (#6717) Add a rake task to cleanup orphaned report data
* 39bb62e (#9529) makes filter tabs accessible via keyboard
* a45a326 (#7554) Link latest report to actual report on front page
* 10f1a6c (#10638) Navigation items should be individually selectable by CSS
* 6c6d674 (#10076) Adjust RPM package versions so RCs are 'less than' finals
* 23789df (#10017) Adjust Debian package versions so RCs are 'less than' finals

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

[Puppet-dev] Announce: Puppet 2.7.8rc1 available

[Michael Stahnke]

Puppet 2.7.8rc1 is available. 2.7.8rc1 contains everything that was
being previewed in the 2.7.7rc series as well as some new content.

Key highlight in this release (beyond items from 2.7.7rc series) are:
   *  Allow providers to be selected in the run they become suitable
   * Showdiff is now not auto-enabled when running in noop mode
   * Provide default subjectAltNames while bootstrapping master
(defaulting to puppet and puppet.)
   *  Allow optional trailing comma in argument lists.
   *  Output 4-digit file modes in File type


Release Notes for 2.7.8 series --
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

This release is available for download at:
http://downloads.puppetlabs.com/puppet/

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.8rc1
 http://projects.puppetlabs.com/projects/puppet

Documentation is available at: http://docs.puppetlabs.com/index.html




# 2.7.8rc1
##10739 Provide default subjectAltNames while bootstrapping master

Prior to #2848 (CVE-2011-3872), if Puppet[:certdnsnames] was not set,
puppet would add default subjectAltNames to any non-CA cert it signed,
including agent certs. The subjectAltNames were of the form:

  DNS:puppet, DNS:, DNS:puppet.

The fix for #2848, prevented subjectAltNames from ever being
implicitly added at signing time. But during this change, the default
subjectAltNames behavior was accidentally removed.

This commit restores the 'defaulting' behavior that existed
previously, but only when bootstrapping the initial master.
Additionally, default subjectAltNames are only ever added when
generating the master's certificate signing request, not at signing
time. This is important, because it ensures all subjectAltNames
originate from the CSR and are subject to our internal signing policy.

The code now requires that all of the following be true in order to
add default subjectAltNames to the CSR:

 1. We are a CA and master
 2. We're signing the master's cert, not self-signing the CA
 3. The CSR is for the current host
 4. No subjectAltNames have been specified, e.g. Puppet[:dns_alt_names]
 5. The master can resolve its fqdn

These should only ever be true when bootstrapping the initial
master. In particular, it should never be true for the CA's
self-signed cert, for remote agents, or for servers that are either
masters or CAs, but not both.

The fqdn requirement existed previously, and so the same behavior has
been restored.

Note if Puppet[:dns_alt_names] are specified when bootstrapping the
master, then we do not merge the default options -- it's either one of
the other, but not both.


#2744 Don't automatically enable show_diff in noop mode

As of 845825a, file diffs are now logged, rather than printed to
console. Because log messages may be stored and more broadly readable,
we no longer implicitly set show_diff in noop mode.



##6907 Allow providers to be selected in the run they become suitable

Previously, if a resource did not specify its provider, it would be assigned
the most appropriate suitable provider (typically the default).
If no provider
was suitable, the run would fail before it even began.  This meant that a
provider which was going to have its requirements delivered during the run
could not be used in that run.

In the case that an unsuitable provider was explicitly specified, this would
only work in certain conditions. Suitability was lazily checked, which meant
the resources installing the provider had to come before the resources using
it. If this weren't true (because the dependencies weren't specified), those
resources would still fail.

Now, we will instead *wait* for the provider to become suitable.
Similarly, if
no provider is specified, we wait for a suitable provider to
become available.

We accomplish this by deferring unsuitable resources when they are
encountered.
Once we are out of suitable resources, we re-enqueue our
previously-unsuitable
resources and check them again. If some are now suitable, we
evaluate them as
normally, deferring the rest. If all our deferred resources are
still deferred,
they all fail, and we continue on with their dependents (which will all be
marked as skipped due to failed dependencies).

This allows providers to be used in the same run as resources using them,
without needing to specify any dependencies between resources using the
provider and resources installing the provider. Naturally, if the resources
installing the provider depend on resources using the provider,
the run cannot
succeed.

Previously, if we chose to use an unsuitable provider, we would not
prefetch it because it wasn't suitable 

[Puppet-dev] Puppet 2.7.7: Thunderdome

[Michael Stahnke]

Per our timed-release cycle process[1], we've entered the THUNDERDOME
for 2.7.7rc series (Nov) vs 2.7.8 series (Dec).

Two releases enter; one leaves.

It was determined today that 2.7.8 has won the Thunderdome.  (It was a
gory battle where 2.7.8 kicked 2.7.7 in the face, 2.7.7 fought back
with a weird behavior change, which is ultimately what cost it the
battle)

So, look for 2.7.8rc1 next week.

The main reasons for holding back 2.7.7 were concerns around
'showdiff' option.

1.  There is a feature that is a change in behavior if 'showdiff' is
enabled.  When enabled diffs will now be logged on disk (logs,
reports, etc)
2.   Showdiff is enabled by default when running 'puppet agent --test'
3.  -noop will not modify the showdiff setting at all. (this needs to
yet be fixed)


Note: 2.7.7 was tagged in our github repository, but not really
released.  If you happened to have deployed it, we will absolutely
still do our best to help you out, but 2.7.8 will have the behavior
around showdiffs setup as desired.


[1] 
http://groups.google.com/group/puppet-users/browse_thread/thread/3d703849246bd43f/c98d096d51ed221e




Mike Stahnke
Release Engineering
Puppet Labs

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

[Puppet-dev] Announce: Puppet 2.7.7rc2 is available

[Michael Stahnke]

Puppet 2.7.7rc2 is available.

This RC addresses a few significant issues found in 2.7.7rc1.

File serving performance issue with large numbers of files:
https://projects.puppetlabs.com/issues/9671

Agent may crash when attempting to manage permissions on non-NTFS
filesystems (on Windows)
https://projects.puppetlabs.com/issues/10614

Serve files in binary mode
https://projects.puppetlabs.com/issues/9983

Additionally, we were able to fix a few other items:

 (#10727) Don't rely on Kernel#Pathname -- this fixes a pre ruby-1.8.5
compatibility issue

 (#2744) Display file diffs through the Puppet log system.  -- *This
may have impact on your log file sizes*.




Release Notes for 2.7.7 series --
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

This release is available for download at:
http://downloads.puppetlabs.com/puppet/

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.7rc2
 http://projects.puppetlabs.com/projects/puppet

Documentation is available at: http://docs.puppetlabs.com/index.html


Release notes for 2.7.7rc2



(#9617) Speed up recursive file management in 2.7

Through a series of commits the managing file ownership and permissions
recurrsively is much (10x or more) faster.  As a side effect this
speed improvement can
be seen in some other scenarios.



(#10614) Detect when trying to managing ACLs on a non-ACL volume

Previously, when managing owner, group, and/or mode on a file whose
volume does not support ACLs, Puppet would raise an error when trying
to get/set the ACL.

This commit allows a file provider to optionally perform validation of
the resource. On Windows, the provider ensures that if owner, group,
and/or mode are being managed, but the underlying volume does not
support ACLs, then we fail early with an appropriate error message.

This is a noop for the POSIX file provider as no validation is
required.

File.expand_path uses the current working directory to generate
absolute paths. This was causing failures when running the specs from
a mapped network drive, e.g. HGFS, since the volume does not support
ACLs. This commit changes these tests to use make_absolute method
instead, and changes that method to always use the local 'C:\' volume.



(#10614) Provide default metadata values for Windows ACLs

Previously, when sourcing file content from a volume that doesn't
support Windows ACLs, e.g. VMware shared drive, puppet would raise an
error.

This commit defaults the owner (Administrators), group (Nobody), and
mode (0644), so that content can be sourced without requiring the
owner, group, and mode to be specified in the manifest.



(#10614) Add method for detecting Windows volumes that support ACLs

Added a method to detect whether the root of a given path is on a
volume that supports persistent Windows ACLs. Note it is not enough to
check that the volume type is 'NTFS' as some filesystems claim to be
NTFS, but do not support ACLs, e.g. NetApp. Other filesystems like FAT
and CIFS do not support ACLs either.

This commit does not add any new windows gem dependencies, as the
Windows::Volume module is part of the windows-pr gem.


(#10614) Fix setting and clearing read-only attribute on Windows

Previously, we were incorrectly checking the return value of
SetFileAttributes. In cases where we didn't own the file, the call to
set/clear the readonly attribute would fail, but we were not raising
an error.

In fixing this, I uncovered ordering issues whereby we needed to set
the file attributes before setting the owner, both in the tests and
the Puppet::Util::Windows::Security module. I also modified the code
to only call SetFileAttributes if it would actually result in a
change, such as when changing the mode, but not the owner or group.


(#10614) Fix error checking for Windows BOOL return values

Previously, the agent could segfault when attempting to manage a DACL
on a non-NTFS filesystem. The problem was that we were incorrectly
checking the return value from several of the Windows APIs due to the
windows gems automatically converting BOOL values into ruby true/false
values.

For example, this call returns a ruby true/false value:

  API.new('IsValidAcl', 'P', 'B', 'advapi32')

But this one will return an integer value:

  API.new('GetSecurityInfo', 'LLLP', 'L', 'advapi32')

The crash is now fixed because we correctly raise an exception when
IsValidAcl returns false.


(#10727) Don't rely on Kernel#Pathname

A recent change to Puppet::Type::File made use of Kernel#Pathname
which is only available in ruby 1.8.5 and later. Since the change
introduced more incompatibility with

[Puppet-dev] Announce: Puppet Dashboard 1.2.3rc2 available

[Michael Stahnke]

This is a maintenance release of Puppet Dashboard release candidate.

This rc address one issue: (#10024) Update Puppet Dashboard Workers init script


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball (in the
downloads area). Release candidate packages are not placed on
{yum,apt}.puppetlabs.com.


See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.3rc2
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html

1.2.3rc2 Release Notes

(#10024) Update Puppet Dashboard Workers init script

Minor fixes to dashboard-workers script. The script sources a sysconfig
file that uses DASHBOARD_HOME rather than DASHBOARD_ROOT, so this script
has been updated to utilize the DASHBOARD_HOME env variable.
Additionally the sysconfig file had a value for the user to run the
processes as, but then was hard-coding the user-name. Script has been
updated to allow changing of username, as per the sysconfig file.



CHANGELOG

1.2.3rc2
===
a5aaba2 (#10024)  Fix typo in fix for 10024
2cb82dc (#10024) Update Puppet Dashboard Workers init script

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

[Puppet-dev] Status of 2.7.7rc

[Michael Stahnke]

We have found 3 bugs we want tracked down before cutting the next
Puppet RC.  (2.7.7rc2)

File serving performance issue with large numbers of files:
https://projects.puppetlabs.com/issues/9671

Agent may crash when attempting to manage permissions on non-NTFS
filesystems (on Windows)
https://projects.puppetlabs.com/issues/10614

There is a pull request for this issue (binary mode on Windows)
https://projects.puppetlabs.com/issues/9983


Just wanted to let everybody know, in case you're on the edge of your
seat for 2.7.7.


Mike

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

[Puppet-dev] Announce: Puppet 2.7.7rc1 available

[Michael Stahnke]

Puppet 2.7.7rc1 is available.

This release fixes several issues with Mongrel and Puppet 2.7.x,
Windows fixes and updates, test fixes, documentation updates and more.


Release Notes for 2.7.7 series --
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

This release is available for download at:
http://downloads.puppetlabs.com/puppet/

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.7rc1
 http://projects.puppetlabs.com/projects/puppet

Documentation is available at: http://docs.puppetlabs.com/index.html


Highlights for 2.7.7rc1


   ## (10269) Search bit not set on newly created directories

Previously, puppet would not set the user, group, or other
execute/search bits for newly created directories. This was a
regression introduced in 2.7.6 in commit
22bfd9ce83ff52d909a43c370ba71112ed4961a4.

This was caused because the dirmask'ing was occurring when munging the
mode property, but that was occurring prior to the ensure property
being synced, which is when the directory is actually created. And
since the directory did not exist, the executable bits were never
added.

Similar failures would occur if the path referred to a non-executable
file or link that we wanted to change to a directory.

This commit reverts the changes to the dirmask and munge methods, and
moves the call to dirmask back to the retrieve method. This way we can
be sure that the directory has been created by the time we call
dirmask.

Ideally, we could know at munge time whether we are going to create a
directory as opposed to a file or link. But the logic for that depends
on many other properties, e.g. source, target, etc. The easiest thing
is to just revert the change.


## Maint: Revise reference text for most types and providers

This documentation-only commit makes edits for wording, clarity,
accuracy, and
formatting to the description strings in 64 type and provider
files, with the aim
of improving the type reference
(http://docs.puppetlabs.com/references/latest/type.html).

##  (7601) Use << instead of += in references

This commit refactors some reference code to use the "<<" string append
operator instead of the slower-but-equivalent += operator. (Offending
instances left in lib/puppet/reference/metaparameter.rb and
lib/puppet/reference/indirection.rb are slated for deletion in a subsequent
commit.)

## (9109) Retrieve request parameters from the request body for POSTs

When using Puppet with Mongrel, the facts were being lost with 2.7.0+
clients, since they were switched over to using POST requests for fact
submission.  This was happening because the request parameters were
only being retrieved from the query parameters of the URL, which will
not include the POSTed data.

We now merge the body of the post together with the query parameters
when dealing with POST requests.

We also rewind the request body after reading it, since retrieving the
request body multiple times would return an empty string after the
first time.

   ## (10244) Restore Mongrel XMLRPC functionality

This code was over-eagerly removed, when it turns out to actually
still be necessary for backward compatibility with XMLRPC clients.


   ## (10161) Parenthesize method arguments

Ruby 1.8.6 issues warnings when arguments to nested methods are not
parenthesized, e.g.

  f.puts(YAML.dump metadata)

results in:

  warning: parenthsize arguments(s) for future versions

These warnings were introduced during Windows development, but not
noticed on that platform due to using ruby 1.8.7, which doesn't issue
a warning. This commit just wraps the arguments in parenthesis.


In  addition to the items mentioned above, there were a slew a
testing/spec improvements around order dependent tests, and testing on
Windows.

2.7.7rc1
===
674068a (#10269) Make directories executable so they can be cleaned up
fd747cc (#10365) Add pending test when file overwrites an executable directory
fe30d8f (#10315) Add pending tests when following symlinks
a22c7aa Maint: Fix test breakage
8576e86 (#10269) Search bit not set on newly created directories
428e08c Stub File.open to not touch the disk
a97337f (#10346) Fix storeconfigs spec failures when run alone
5c4daa4 (#7601) Use definition lists in indirection references
7df46a2 (#7601) Use definition lists in type references
ad97dc9 (#7601) Add markdown_definitionlist method to reference.rb
455c9aa Maint: Revise reference text for most types and providers
ced8e19 (#7601) Remove unnecessarily abstracted paramwrap method
a6957ac (#7601) Rename "h" method to "markdown_header"
7a0ade6 (#7601) Use << instead of += in references
7d65796 (#9109) Retrieve request parameters from the 

[Puppet-dev] Announce: Facter 1.6.3rc1 available

[Michael Stahnke]

November welcomes us to another round of Release Candidates for our software.

Facter 1.6.3rc1 is a maintenance release containing fixes, updates and
refactoring.

This release is available for download at:
 http://puppetlabs.com/downloads/facter/facter-1.6.3rc1.tar.gz

See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.6.3rc1:
 http://projects.puppetlabs.com/projects/facter/

Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki

--


 (#7038) Validate prtdiag output in manufacturer

prtdiag cannot be run inside zones, and calling
Facter::Util::Resolution.exec on it will return nil. The manufacturer
utility was calling split() on nil, which was raising an exception.
Added validation of prtdiag output, and simplified the regex to extract
values for facts. Added more coverage for the related facts as well.


 (#10228) Ascendos OS support for various facts.

This patch will make various facts return the correct value on Ascendos
(a new RHEL rebuild - http://www.ascendos.org/):

* hardwareisa
* lsbmajdistrelease
* macaddress
* operatingsystem
* operatingsystemrelease
* osfamily
* uniqueid

(#10233) Adds support for Parallels Server Bare Metal to Facter

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

[Puppet-dev] Announce: Puppet 2.7.6 Available [ security/feature updates]

[Michael Stahnke]

Puppet 2.7.6 is a feature and security update release in the 2.7.x branch.

The security changes in 2.7.6 addres CVE-2011-3872
* CVE-2011-3872, Altnames Vulnerability

For more details on this vulnerability, follow the link on our
blog post: 
http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/

Other information available at:  http://puppetlabs.com/security
or visit http://puppetlabs.com/security/cve/cve-2011-3872


Puppet 2.7.6 is available as of now.  Changelog entries are available below.
More detailed information is available on our Release Notes page.

Detailed feature release notes are available:

https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.6


This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.7.6.tar.gz

RPM's are available at http://yum.puppetlabs.com/el or /fedora

Debs are available on http://apt.puppetlabs.com (lenny requires
backports enabled)

Puppet is also available via Rubygems at http://rubygems.org

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.7.6
http://projects.puppetlabs.com/projects/puppet/




Commits:

= Changes for 2.7.6 =

0d4494c Updated CHANGELOG for 2.7.6
(See 
http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/)

= Fixes due to CVE-2011-3872: see
2011841 Improve the error message when a CSR is rejected
afff3df Allow a master to bootstrap itself with dns_alt_names and autosign
388365e (maint) Remove ssl dir before starting a master with DNS alt names
e4c64c7 Fix failing CA Interface specs on Ruby 1.9
9ee1215 Fix some inconsistencies from merging
8144939 Add support for DNS alt names to `puppet ca`
2ba56e3 More 1.8.5 compatibility fixes.
6257188 Better 1.8.5 compatible implementation of `lines`.
4ba4db7 (#2848) Config options require '_', not '-'.
493f8d1 Add --allow-dns-alt-names option to `puppet certificate sign`
0cc8936 Add support for dns-alt-names option to `puppet certificate generate`
c65236d Ruby 1.8.5 compatibility changes in tests and code.
6c37623 Add `lines` alias for `each_line` in Ruby 1.8.5.
e29eb6a s/not_to/should_not/ for older versions of RSpec 2.
f1f5298 (#2848) Eliminate redundant `master_dns_alt_names`.
3a8b376 (#2848) Remove the legacy SSLCertificates code
28dead0 (#2848) Rework the xmlrpc CA handler to use the modern SSL code
a644514 (#2848) Remove unused xmlrpc code
2b1ad43 (#2848) Consistent return values from `subject_alt_names` accessors.
d8516d9 (#2848) Consistently use `subject_alt_names` as accessor name.
0b45f4c (#2848) Don't strip the subjectAltName label when listing.
99488f3 (#2848) Don't enable `emailProtection` for server keys.
f1285a4 (#2848) Only mark `subjectAltName` critical if `subject` is empty.
e65a88e (#2848) Migrate `dns-alt-names` back to settings.
b876c39 Wire up the `setbycli` slot in Puppet settings.
a53f2f2 (#2848) rename subject-alt-name option to dns-alt-names
bc2267a (#2848) Rename `certdnsnames` to match new behaviour.
a720499 (#2848) Use `certdnsnames` when bootstrapping a local master.
6e3f529 (#2848) CSR subjectAltNames handling while signing.
978b65c (#2848) List subject alt names in output of puppet cert --list
7460a5e (#7224) Add a helper to Puppet::SSL::Certificate to retrieve
alternate names
94345eb (#2848) Rewrite SSL Certificate Factory, fixing `subjectAltName` leak.
a729d90 (#2848) Reject unknown (== all) extensions on the CSR.
f4fc11d (#2848) extract the subjectAltName value from the CSR.
d64b01b (#2848) Set `certdnsnames` values into the CSR.
78a01a2 (#6928) Don't blow up when the method is undefined...

505d8d6 Updating for 2.7.6rc3
43d1e38 (#9996) Restore functionality for multi-line commands in exec resources
bedf7d2 Updated CHANGELOG for 2.7.6rc2
d457763 (#9832) General StoreConfigs regression.
245dfb7 Updated CHANGELOG for 2.7.6rc1
2958b05 maint: Deal with [].to_s problem in 1.9.2
9c25af4 (#9027) Get rid of spurious info messages in groupadd
1f25c20 (#8411) Fix change group for POSIX file provider
599642d Fix problem with set_mode (chmod) behavior on different test
environments.
b43765d Undo change to failing test on 1.8.5
c275a51 Resist directory traversal attacks through indirections.
d759f84 (#9838) Return the tranaction report when doing a ral save
127f83e (#9837) Split parameter pruning from manifest formatting
9d5ce00 (#9837) Move resource formatting method to Puppet::Resource
86230d8 (#9837) Move properties in prep to move proc to method
bf952e1 (#9837) Make a clearer variable name in the specs
6885c36 (#9837) Call puppet apply to avoid deprecation warning
93f8057 (#9837) Extract methods from the main section of the resource
application
5d33214 (#9837) Start the cleanup of the puppet resource application
54a2565 (#9832) Test failures with some ActiveRecord versions.
2bf8004 Updates for 2.6.11
8343077 (#9832)

[Puppet-dev] Announce: Puppet 2.6.12 Available [security update]

[Michael Stahnke]

Puppet 2.6.12 is a security update release in the 2.6.x branch.

The only changes since 2.6.11 are security fixes for the following
vulnerability:

* CVE-2011-3872, Altnames Vulnerability

For more details on this vulnerability, follow the link on our
blog post: 
http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/

Other information available at:  http://puppetlabs.com/security
or visit http://puppetlabs.com/security/cve/cve-2011-3872

Features/fixes that were previously targeted at 2.6.12 have been moved
to 2.6.13.

Puppet 2.6.12 is available as of now.  Changelog entries are available below.
More detailed information is available on our Release Notes page.

Release Notes have been updated:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.12

This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.6.12.tar.gz

RPM's are available at http://yum.puppetlabs.com/el or /fedora

Puppet is also available via Rubygems at http://rubygems.org

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.6.12:
http://projects.puppetlabs.com/projects/puppet/

Commits:

3ed6499 Backport Enumerable#count to Rubies < 1.8.7
5f44c23 More 1.8.5 compatibility fixes.
ef1b960 Better 1.8.5 compatible implementation of `lines`.
246e875 (#2848) Config options require '_', not '-'.
3bdeb3a Ruby 1.8.5 compatibility changes in tests and code.
6866d4b Add `lines` alias for `each_line` in Ruby 1.8.5.
2f9ec3c s/not_to/should_not/ for older versions of RSpec 2.
56320ea (#2848) Eliminate redundant `master_dns_alt_names`.
de19861 (#2848) Remove the legacy SSLCertificates code
cf008a6 (#2848) Rework the xmlrpc CA handler to use the modern SSL code
32be180 (#2848) Remove unused xmlrpc code
5f2a44d (#2848) Consistent return values from `subject_alt_names` accessors.
5e507f2 (#2848) Consistently use `subject_alt_names` as accessor name.
5ac2417 (#2848) Don't strip the subjectAltName label when listing.
44cf3a2 (#2848) Don't enable `emailProtection` for server keys.
d66def9 (#2848) Only mark `subjectAltName` critical if `subject` is empty.
8174047 (#2848) Migrate `dns-alt-names` back to settings.
f18df2b Wire up the `setbycli` slot in Puppet settings.
efa61f2 (#2848) rename subject-alt-name option to dns-alt-names
f103b20 (#2848) Rename `certdnsnames` to match new behaviour.
363b47b (#2848) Use `certdnsnames` when bootstrapping a local master.
49334ff (#2848) CSR subjectAltNames handling while signing.
5f2af93 (#2848) List subject alt names in output of puppet cert --list
bb475ec (#7224) Add a helper to Puppet::SSL::Certificate to retrieve
alternate names
bab9310 (#2848) Rewrite SSL Certificate Factory, fixing `subjectAltName` leak.
fca1ff0 (#2848) Reject unknown (== all) extensions on the CSR.
443a756 (#2848) extract the subjectAltName value from the CSR.
66101f1 (#2848) Set `certdnsnames` values into the CSR.
77b814f (#6928) Don't blow up when the method is undefined...
5427f1e (#6928) backport Symbol#to_proc for Ruby < 1.8.7

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

[Puppet-dev] Important Security Announcement: AltNames Vulnerability [new version of puppet]

[Michael Stahnke]

We have discovered a security vulnerability (“AltNames Vulnerability”)
whereby a malicious attacker can impersonate the Puppet master using
credentials from a Puppet agent node. This vulnerability cannot cross
Puppet deployments, but it can allow an attacker with elevated
privileges on one Puppet-managed node to gain control of any other
Puppet-managed node within the same infrastructure.

All Puppet Enterprise deployments are vulnerable, and Puppet open
source deployments may be, depending upon their site configuration.

We believe this to be a serious risk, and we have confirmed this with
security experts outside of Puppet Labs.

For more information we have the following resources:

* Blog Post with all the details:
http://puppetlabs.com/blog/important-security-announcement-altnames-vulnerability/
* Security links and details:
http://puppetlabs.com/security/cve/cve-2011-3872/
* Remediation module:
http://links.puppetlabs.com/cve20113872_remediation


As a result of this vulnerability (CVE-2011-3872) we have released new
version of Puppet.

* 2.6.12
* 2.7.6

We will be sending separate announcements about each of those releases.


Michael Stahnke
Release Manager - Puppet Labs

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

Re: [Puppet-dev] Announce: Puppet 2.7.6rc3 available

[Michael Stahnke]

On Fri, Oct 14, 2011 at 6:39 AM, Trevor Vaughan  wrote:
> Has this been tagged in Git? I'm not seeing it when pulling from
> git://github.com/puppetlabs/puppet.git.

It's been pushed.  Sorry about that.
>
> Thanks,
>
> Trevor
>
> On Thu, Oct 13, 2011 at 5:11 PM, Michael Stahnke  
> wrote:
>> Puppet 2.7.6rc3 is available.
>>
>>  This release candidate fixes a regression in the Exec resource that
>> prevented multi-line execs from working properly.
>>
>>
>> Release Notes for 2.7.6 series --
>> https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes
>>
>> This release is available for download at:
>> http://downloads.puppetlabs.com/puppet/
>>
>> See the Verifying Puppet Download section at:
>> http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
>>
>> Please report feedback via the Puppet Labs Redmine site, using an affected
>> version of 2.7.6rc3 http://projects.puppetlabs.com/projects/puppet
>>
>> Documentation is available at: http://docs.puppetlabs.com/index.html
>>
>>
>>
>> Changes since RC2.
>>
>>   (#9996) Restore functionality for multi-line commands in exec resources
>>
>>    Originally we were relying on the behavior that Array.new would call
>>     #to_a on its argument, which is a no-op if the object is already an
>>    array.  When #to_a is called on a string, it does not always return
>>    [original_string].  Because string.to_a is effectively equivalent to
>>    string.each_line.to_a (at least in Ruby 1.8.7) we were breaking
>>    commands with embedded newlines.
>>
>>    Manually wrapping the passed in command in an array, and calling
>>     #flatten is much safer since it will not "helpfully" split up the
>>    command string for us.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> puppet-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaug...@onyxpoint.com
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>
>

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

[Puppet-dev] Announce: Puppet 2.7.6rc3 available

[Michael Stahnke]

Puppet 2.7.6rc3 is available.

 This release candidate fixes a regression in the Exec resource that
prevented multi-line execs from working properly.


Release Notes for 2.7.6 series --
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

This release is available for download at:
http://downloads.puppetlabs.com/puppet/

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.6rc3 http://projects.puppetlabs.com/projects/puppet

Documentation is available at: http://docs.puppetlabs.com/index.html



Changes since RC2.

   (#9996) Restore functionality for multi-line commands in exec resources

Originally we were relying on the behavior that Array.new would call
 #to_a on its argument, which is a no-op if the object is already an
array.  When #to_a is called on a string, it does not always return
[original_string].  Because string.to_a is effectively equivalent to
string.each_line.to_a (at least in Ruby 1.8.7) we were breaking
commands with embedded newlines.

Manually wrapping the passed in command in an array, and calling
 #flatten is much safer since it will not "helpfully" split up the
command string for us.

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

[Puppet-dev] Announce: Puppet Dashboard 1.2.2 Available

[Michael Stahnke]

This is a maintenance release of Puppet Dashboard 1.2.2.


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

RPMs are also available on  yum.puppetlabs.com.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.2
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html



# Highlights for this release

##  (#9940) dashboard-workers can be managed as service

The stop command in the puppet-dashboard-workers init script would fail when
run using a puppet service resource. This had something to do with
the way sudo
works on EL. Removing the sudo from the stop function allows the
service to be
managed by puppet reliably. And because it is stopping the process, and not
creating the process, it doesn't matter whether it runs as root or
puppet-dashboard.

##   (#9429) Prevent editing node name

The uneditable node name was displayed in a text input control,
which was less
than ideal for a number of reasons.  Now it's plain text.

## (#9429) makes node name field readonly during edit action

The readonly attribute of the node name text field is set via the
@readonly_name
instance variable. When nil, the node name can be edited. This
commit prevents
the node name from being edited, though it can be set normally
during node creation.

##  (#9429) adds attr_readonly to name in the node model

Changes to the name attribute of nodes are ignored, via the attr_readonly
attribute in the model. In the view, readonly input controls are assigned
a #EEE background. spec tests updated with readonly changes.


## (#9282) Change user in database.yml.example to "dashboard"

Previously, our database.yml.example file suggested handing the keys to the
root MySQL user to Dashboard, which is a poor security practice. This commit
changes the default user suggestion to "dashboard", which is the
default MySQL
user used in Puppet Enterprise.

##  (#9262) causes the contents of .section divs to scroll when overflowing

This is a short-term solution to a larger problem. Dashboard is
split into two columns,
the sidebar (20% of window width), and the main content pane (80%
of window width). The
problem is when dealing with large strings of non-breaking text
(e.g. file paths), the
containing element runs off the screen unless accomodations are
made (e.g. overflow: auto;).
The better--long term--fix is to replace the 20%/80% column layout
with one that allows
the main content pane variable width. Thus, the entire window
scrolls horizonally when
elements overflow instead of requiring short-term fixes for each
offending element.

##  (#9215) Add a Rake task that removes nodes



v1.2.2
===
484b323 Change node:delete to node:del for consistency
56b141c (#9215) Rename node:del to node:delete
20cf5fe (#9954) Add a rake task to add classes to a nodegroup
d9eca18 (#9954) Add a rake task to list nodeclasses
e75b51d (#9953) Add a rake task for listing nodegroups
14b93a2 Maint: adding VERSION_LINK to .gitignore
8725921 (#9940) dashboard-workers can be managed as service
ce3868f (#9429) Prevent editing node name
edbb48e (#9429) makes node name field readonly during edit action
14bc1e5 (#9429) adds attr_readonly to name in the node model
a344e82 (#9366) removes conditional on .git for APP_VERSION_LINK
9ed1c19 (#9366) allows a custom version link to be specified
39a07de (#9773) Report content hidden
233fbf0 (#9756/Maint) Fix plugin loading.
54146c6 (#9756/Maint) Better guards around installed_plugins.
7b36bb3 (#9756) Autoload plugin initializers.
5311e6b (#9731) Refactor the Dashboard logo rendering.
1e4996c Maint: telling git to ignore MCollective logs
6c2e454 (#9306) tweaks base header styling to match markup changes
c897d00 (#9571) tweaks header markup, method of importing CSS styles
5f381a0 (#9306) adds divs to header markup
a63c1df (#9306) sanitizes header markup for assimilation by Riddler
22001cc (9571) exports global nav bar via /header.html
ca7d7a5 (#9282) Rewrite explanatory text in database.yml.example
1f42a27 (#8825) allows configuration of logo dimensions and alt text
992af88 (#9262) causes the contents of .section divs to scroll when overflowing
ad4641f (#9282) Change user in database.yml.example to "dashboard"
090538f (#9215) Add a Rake task that removes nodes

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

[Puppet-dev] Announce: Facter 1.6.2. available

[Michael Stahnke]

Facter 1.6.2 is a maintenance release containing fixes, updates and
refactoring.  Primary new features include updated facts for DragonFly
BSD, Amazon Linux and Windows.
 A few other facts have been added and updated.  Full release notes below.

This release is available for download at:
 http://puppetlabs.com/downloads/facter/facter-1.6.2.tar.gz

See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.6.2:
 http://projects.puppetlabs.com/projects/facter/

Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki

RPMs available on yum.puppetlabs.com as well.





# Facter 1.6.2 Release Notes
## Maint: (9555) Change all cases of tabs and 4 space indentation to 2
space indentation.

Since 2 space indentation seems to be Puppets (and the ruby communities)
standard this patch converts all incorrect indentation to 2 spaces.

The fact that we were mixing the indentation was causing people to mix them
within files - sometimes using 4 space, sometimes 2 space. This
single change
makes it consistent across all the code.

##  New Fact: (9830) Add sshecdsakey fact

 From version 5.7 onward, openssh has support for elliptic curve
DSA keys[1,2].
 This commit adds a fact for those keytypes.

 1 - http://openssh.org/txt/release-5.7
 2 - http://tools.ietf.org/html/rfc5656

##  New Platform: (9404) Add memory & update processor facts for
DragonFly and OpenBSD.

Since there was no coverage for memory tests these have been added for
the two OS's.

Also since the mechanism for processor detection was changes this was
fixed for OpenBSD. A similar mechanism was added for the new DragonFly
BSD support.


##  Fix (9404) De-clumsify CPU count detection and swap detection on OpenBSD.

As part of the DragonFly BSD work is was noticed that the OpenBSD
implementation could benefit from the same techniques so this commit
aligns that.

## Fix (6728) Improve openvz/cloudlinux detection.

Added more cloudlinux detection, which has /proc/lve/list present on
cloudlinux hosts. Removed a default value from openvz_type detection,
which could lead to a virtual value of "unknown" if the openvz check
partially failed, which could cause other legitimate virtual tests to
be skipped.


## New Platform: (7951) added OS support for Amazon Linux

## Maint:  (9787) Change rspec format so we use the default, not document

Current running rake spec in facter means we get the document
output which is
very verbose. Unfortunately we are forcing this in our .rspec file so you
can’t override it on a user by user basis with ~/.rspec for example.

I think we should not define —format, which means the default is progress
(which is less verbose and better for the average Joe and hacker who just
wants red light/green light) and then if people really want document format
they can override this in their own ~/.rspec file.

This way its the best of both worlds – more meaningful defaults and allowing
user overrides.

##Fix (7726) Silence prtconf error message inside zones

prtconf will output an error message when run inside a zone, which
clutters up facter output. Redirected the stderr to /dev/null.

## Fix   (4980, 6470) Fix architecture in Darwin and Ubuntu

Architecture now relies on the hardwaremodel fact unless special cased
otherwise, such as for linux distributions that require amd64 as the
expected architecture. Ubuntu was added as a special case, OpenBSD was
collapsed into the current architecture fact and Darwin was added by
removing the kernel confine statement for the architecture fact.

##New fact: (6792) Added osfamily fact.

Added osfamily fact to determine if a given operating system is a
derivative of a common operating system.

##Fix  (6515 and 2945) Fix processorcount for arm, sparc & ppc for linux.

Previously we were unable to check processor type and count on other
architectures for linux. This fix corrects that.

To remove complication from the fact we have moved the logic for parsing
cpuinfo and lsdev into their own static classes in Facter::Util::Processor.
This is to help with stubbing and to segregate that action as now we have
more conditional cases.

Tests and corresponding cpuinfo fixtures have been added to test those
alternative platforms as well.

##Fix   (3856) Detect VirtualBox on Darwin as well as Linux and SunOS

## Fix (7996) Restrict solaris cpu processor detection

x86_64 based solaris machines have a pkg_core_id field in output of
kstat cpu_info, which denotes the core id of a specific core relative to
the cpu. This could cause misreporting of processor count. The regex to
count cores was restricted to prevent this. Addition

[Puppet-dev] Announce: Puppet 2.7.6rc2 available

[Michael Stahnke]

Puppet 2.7.6rc2 is available.  This release candidate fixes issues
undercovered with using storedconfigs.



Release Notes for 2.7.6 series --
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

This release is available for download at:
http://downloads.puppetlabs.com/puppet/

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.6rc2 http://projects.puppetlabs.com/projects/puppet

Documentation is available at: http://docs.puppetlabs.com/index.html

Changes since RC1.

(#9832) General StoreConfigs regression.

The previous fixes around PostgreSQL were not complete in addressing the
regression: some StoreConfigs exported and imported resources would not be
found.

This removes the last bits that were causing regressions, and additional
testing shows that the generated SQL is now identical between 2.7.3 and the
current version.

This should resolve all the remaining regressions.

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

[Puppet-dev] More changes on yum.puppetlabs.com

[Michael Stahnke]

Greetings,

I'd like to remove the cruft (no longer maintained) areas of
yum.puppetlabs.com.  I fear they only cause confusion and offer
less-than-desirable experience for our users.

I'd like to remove

/base
/prosvc
/porsvc.unsigned
/SRMS
/sources

I'd like to do this some time next week. The stuff mostly found in
base is available elsewhere and signed properly.  The prosvc stuff has
been largely unmaintained.  The /SRPMS folder is now broken out into
each distribution area, so this high-level directory isn't needed.
The /sources directory contains a very incomplete listing of source.
We have that available either via SRPMS or at downloads.puppetlabs.com



This will basically keep:

/el (stuff for RHEL, CentOS, Scientific, Oracle Linux etc)
/fedora




For specific feedback on this change, you can update
http://projects.puppetlabs.com/issues/8473 or you can reply to this
thread.



NOTE:
There's been some discussion about other package platforms,
Debian/Ubuntu, Solaris, etc.  There are plans to begin working on
making those packages readily available (working with the community),
however it's time permitting still.



Mike

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

[Puppet-dev] Announce: Dashboard 1.2.2rc2 available

[Michael Stahnke]

This is a maintenance release candidate of Puppet Dashboard 1.2.2rc2.


New in this RC is a bug-fix to no longer allow you edit node names.
In the past you were able to

This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

Release candidate packages will not placed on yum.puppetlabs.com.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.2rc2
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html


# Release Notes for RC2.


(#9429) Prevent editing node name

The uneditable node name was displayed in a text input control,
which was less
than ideal for a number of reasons.  Now it's plain text.


(#9429) makes node name field readonly during edit action

The readonly attribute of the node name text field is set via the
@readonly_name
instance variable. When nil, the node name can be edited. This
commit prevents
the node name from being edited, though it can be set normally
during node creation.


(#9429) adds attr_readonly to name in the node model

Changes to the name attribute of nodes are ignored, via the attr_readonly
attribute in the model. In the view, readonly input controls are assigned
a #EEE background. spec tests updated with readonly changes.

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

[Puppet-dev] Announce: Puppet 2.7.6rc1 available

[Michael Stahnke]

It was a busy week last week, but we're back to our monthly release candidates
for our projects.

This is an enhancement/fix release candidate of Puppet. A major focus on this
release was Windows support. Puppet now works on Windows as agent. Another focus
was on the RAL around using it with tooling such as mcollective or scripting.

The release notes have a a world of information about the internals of making
Puppet work with Windows, specifically around File permissions, absolute
pathing, daemonizing, etc.  User-level documentation is pending.

https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

If you're using (or begin to use) Puppet on Windows, we'd like to hear from you
about your experiences.  Obviously bugs can be filed at
http://projects.puppetlabs.com/projects/puppet, with an affected version of
2.7.6rc1, but if you have other feedback or discussion, you are welcome to send
it to puppet-users.

This release contains all recent security errata as well.

https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

This release is available for download at:
http://downloads.puppetlabs.com/puppet/

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an affected
version of 2.7.6rc1 http://projects.puppetlabs.com/projects/puppet

Documentation is available at: http://docs.puppetlabs.com/index.html

The highlights of changelog have been outlined above at a very high level.  For
more details, dig into the release notes wiki page.
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes


2.7.6rc1
===
2958b05 maint: Deal with [].to_s problem in 1.9.2
9c25af4 (#9027) Get rid of spurious info messages in groupadd
1f25c20 (#8411) Fix change group for POSIX file provider
599642d Fix problem with set_mode (chmod) behavior on different test
environments.
b43765d Undo change to failing test on 1.8.5
c275a51 Resist directory traversal attacks through indirections.
d759f84 (#9838) Return the tranaction report when doing a ral save
127f83e (#9837) Split parameter pruning from manifest formatting
9d5ce00 (#9837) Move resource formatting method to Puppet::Resource
86230d8 (#9837) Move properties in prep to move proc to method
bf952e1 (#9837) Make a clearer variable name in the specs
6885c36 (#9837) Call puppet apply to avoid deprecation warning
93f8057 (#9837) Extract methods from the main section of the resource
application
5d33214 (#9837) Start the cleanup of the puppet resource application
54a2565 (#9832) Test failures with some ActiveRecord versions.
8343077 (#9832) 2.7.4 StoreConfigs regression with PostgreSQL.
dce82ea (#9458) Require main puppet module
e158b26 (#9793) "secure" indirector file backed terminus base class.
343c7bd (#9792) Predictable temporary filename in ralsh.
88512e8 Drop privileges before creating and chmodding SSH keys.
6533292 (#9328) Retrieve user and group SIDs on windows.
2775c21 (#9794) k5login can overwrite arbitrary files as root
4e8d3a1 (#9775) Only list managed resources in the resources file
51b33d1 (#9326) Support plaintext passwords in Windows 'user' provider.
fe2de81 Resist directory traversal attacks through indirections.
5fea1dc Fix issues with Windows based file URIs
1a13d24 Simplify absolute path detection
a163cd5 Eliminate duplicate absolute path detection
0ce60a5 Added methods for manipulating URI and file paths
71ba92c Restrict the absolute path regex to the start of the string
1edf767 Move group management into providers
15149c1 Remove duplicate SID resolution code
f932511 Move owner management into providers
f05fc83 Add platform-specific metadata collectors
db0b4fb Make string_to_sid_ptr block optional
7fc6baf Add the ability to retrieve user and group SIDs
22bfd9c Move mode management into the providers
4c3aae8 Fix typo bug that prevented FILE_DELETE_CHILD from being set
7de0a80 Sub away trailing backslashes at the end of sources on Windows
44cb1f1 Refactor autorequire of parent to use pathname with ancestors
1300e0a Remove unnecessary Windows-on-non-Windows-master code for path parameter
1f9b57f Cleanup file type integration tests
8d21262 Cleanup and improve coverage of file type unit tests
0a92a70 Resist directory traversal attacks through indirections.
8b6a775 Call Array#join explicitly on command
ae74c68 Fix failing SSL Host test introduced by b6a67edc
37a1975 (#4549) Fix templates to be able to call all functions
a74e56d Expand paths in catalog_spec for windows testing
8d86e5a (9547) Minor mods to acceptance tests
8ec3c7b (#4135) Update pluginsync to only load ruby files.
0c8a0c7 Fix order dependent test failures relating to ADSI
c0edb76 (#9186) Fix tests that fail on 2008 when running as SYSTEM
8e14de6 (#9186) Handle when running under non 'user' contexts
7595475 Fix device.conf error reporting
1d3a3a7 Fix #9164 - allow '-' in device certificate names
b6a67ed Fix #7982 - puppet device doesn't reset all ca

[Puppet-dev] Announce: Facter 1.6.2rc1 available

[Michael Stahnke]

After a very busy week on the security front last week, we are back to
monthly release/RC cycles.

Facter 1.6.2rc1 is a maintenance release containing fixes, updates and
refactoring.

This release is available for download at:
 http://puppetlabs.com/downloads/facter/facter-1.6.2rc1.tar.gz

See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.6.2rc1:
 http://projects.puppetlabs.com/projects/facter/

Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki


Highlights in this release candidate:
# Facter 1.6.2rc1 Release Notes
## Maint: (9555) Change all cases of tabs and 4 space indentation to 2
space indentation.

Since 2 space indentation seems to be Puppets (and the ruby communities)
standard this patch converts all incorrect indentation to 2 spaces.

The fact that we were mixing the indentation was causing people to mix them
within files - sometimes using 4 space, sometimes 2 space. This
single change
makes it consistent across all the code.

##  New Fact: (9830) Add sshecdsakey fact

 From version 5.7 onward, openssh has support for elliptic curve
DSA keys[1,2].
 This commit adds a fact for those keytypes.

 1 - http://openssh.org/txt/release-5.7
 2 - http://tools.ietf.org/html/rfc5656

##  New Platform: (9404) Add memory & update processor facts for
DragonFly and OpenBSD.

Since there was no coverage for memory tests these have been added for
the two OS's.

Also since the mechanism for processor detection was changes this was
fixed for OpenBSD. A similar mechanism was added for the new DragonFly
BSD support.


##  Fix (9404) De-clumsify CPU count detection and swap detection on OpenBSD.

As part of the DragonFly BSD work is was noticed that the OpenBSD
implementation could benefit from the same techniques so this commit
aligns that.

## Fix (6728) Improve openvz/cloudlinux detection.

Added more cloudlinux detection, which has /proc/lve/list present on
cloudlinux hosts. Removed a default value from openvz_type detection,
which could lead to a virtual value of "unknown" if the openvz check
partially failed, which could cause other legitimate virtual tests to
be skipped.


## New Platform: (7951) added OS support for Amazon Linux

## Maint:  (9787) Change rspec format so we use the default, not document

Current running rake spec in facter means we get the document
output which is
very verbose. Unfortunately we are forcing this in our .rspec file so you
can’t override it on a user by user basis with ~/.rspec for example.

I think we should not define —format, which means the default is progress
(which is less verbose and better for the average Joe and hacker who just
wants red light/green light) and then if people really want document format
they can override this in their own ~/.rspec file.

This way its the best of both worlds – more meaningful defaults and allowing
user overrides.

##Fix (7726) Silence prtconf error message inside zones

prtconf will output an error message when run inside a zone, which
clutters up facter output. Redirected the stderr to /dev/null.

## Fix   (4980, 6470) Fix architecture in Darwin and Ubuntu

Architecture now relies on the hardwaremodel fact unless special cased
otherwise, such as for linux distributions that require amd64 as the
expected architecture. Ubuntu was added as a special case, OpenBSD was
collapsed into the current architecture fact and Darwin was added by
removing the kernel confine statement for the architecture fact.

##New fact: (6792) Added osfamily fact.

Added osfamily fact to determine if a given operating system is a
derivative of a common operating system.

##Fix  (6515 and 2945) Fix processorcount for arm, sparc & ppc for linux.

Previously we were unable to check processor type and count on other
architectures for linux. This fix corrects that.

To remove complication from the fact we have moved the logic for parsing
cpuinfo and lsdev into their own static classes in Facter::Util::Processor.
This is to help with stubbing and to segregate that action as now we have
more conditional cases.

Tests and corresponding cpuinfo fixtures have been added to test those
alternative platforms as well.

##Fix   (3856) Detect VirtualBox on Darwin as well as Linux and SunOS

## Fix (7996) Restrict solaris cpu processor detection

x86_64 based solaris machines have a pkg_core_id field in output of
kstat cpu_info, which denotes the core id of a specific core relative to
the cpu. This could cause misreporting of processor count. The regex to
count cores was restricted to prevent this. Additional x86_64 tests were
added to verify this behavior.

##Fix  (

[Puppet-dev] Announce: Puppet 2.7.5 available [security updates]

[Michael Stahnke]

Puppet 2.7.5 is a security update release in the 2.7.x branch.

The only changes since 2.7.4 are security fixes for the following
vulnerabilities:

* CVE-2011-3870, a symlink attack via a user's SSH authorized_keys file
* CVE-2011-3869, a symlink attack via a user's .k5login file
* CVE-2011-3871, a privilege escalation attack via the temp file used
by puppet resource
* A low-risk file indirector injection attack

WE RECOMMEND UPDATING TO THIS VERSION IMMEDIATELY, as an issue with
our ticketing system resulted in information about these issues
leaking to a public list prior to their official disclosure.

For more details on these vulnerabilities, follow the links on our
security updates page at: http://puppetlabs.com/security

Puppet 2.7.5 is available as of now.  Changelog entries are available below.
More detailed information is available on our Release Notes page.

Release Notes have been
updated:https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.5

This release is available for download
at:http://puppetlabs.com/downloads/puppet/puppet-2.7.5.tar.gz

RPM's are available at http://yum.puppetlabs.com/el

Puppet is also available via Rubygems at http://rubygems.org

See the Verifying Puppet Download section
at:http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.7.5:http://projects.puppetlabs.com/projects/puppet/

Commits:

4079ab2 Updating version numbers for 2.7.5
de51f3d (#9832) 2.7.4 StoreConfigs regression with PostgreSQL.
1aa9be5 (#9793) "secure" indirector file backed terminus base class.
d76c309 (#9792) Predictable temporary filename in ralsh.
b29b178 Drop privileges before creating and chmodding SSH keys.
7d4c169 (#9794) k5login can overwrite arbitrary files as root

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

[Puppet-dev] Announce: Puppet 2.6.11 Available [security updates]

[Michael Stahnke]

Puppet 2.6.11 is a security update release in the 2.6.x branch.

The only changes since 2.6.10 are security fixes for the following
vulnerabilities:

* CVE-2011-3870, a symlink attack via a user's SSH authorized_keys file
* CVE-2011-3869, a symlink attack via a user's .k5login file
* CVE-2011-3871, a privilege escalation attack via the temp file used
by puppet resource
* A low-risk file indirector injection attack

WE RECOMMEND UPDATING TO THIS VERSION IMMEDIATELY, as a
misconfiguration of our infrastructure resulted in information about
these issues leaking to a public list prior to their official
disclosure.

For more details on these vulnerabilities, follow the links on our
security updates page at: http://puppetlabs.com/security

Features/fixes that were previously targeted at 2.6.11 have been moved
to 2.6.12.

Puppet 2.6.11 is available as of now.  Changelog entries are available below.
More detailed information is available on our Release Notes page.

Release Notes have been
updated:https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.11

This release is available for download
at:http://puppetlabs.com/downloads/puppet/puppet-2.6.11.tar.gz

RPM's are available at http://yum.puppetlabs.com/el

Puppet is also available via Rubygems at http://rubygems.org

See the Verifying Puppet Download section
at:http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of
2.6.11:http://projects.puppetlabs.com/projects/puppet/

Commits:

e158b26 (#9793) "secure" indirector file backed terminus base class.
343c7bd (#9792) Predictable temporary filename in ralsh.
88512e8 Drop privileges before creating and chmodding SSH keys.
2775c21 (#9794) k5login can overwrite arbitrary files as root

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

[Puppet-dev] Announce: New Puppet releases due to four security issues [critical security updates]

[Michael Stahnke]

Announce: New Puppet releases due to four security issues
=

Following the security vulnerability announced yesterday (CVE-2011-3848),
Ricky Zhou () alerted us to an unrelated
vulnerability. Our subsequent code audit uncovered three more vulnerabilities,
and we have now fixed all four of these new issues. (It's been a busy week.)

We have released the following updated versions of Puppet to fix these
vulnerabilities:

* 2.7.5
* 2.6.11

WE RECOMMEND UPDATING TO THESE VERSIONS IMMEDIATELY, as an issue with
our ticketing
system resulted in information about these issues leaking to a
public list prior to this disclosure. Official announcements of these releases
are forthcoming momentarily, and the new versions can be downloaded at:

* http://puppetlabs.com/security/hotfixes
* http://puppetlabs.com/downloads/puppet

PUPPET ENTERPRISE USERS can download hotfix packages for PE versions 1.0, 1.1,
and 1.2.x at:

* http://puppetlabs.com/security/hotfixes

Puppet Labs has been coordinating with Debian, Ubuntu, EPEL and OpenSuSE
maintainers.  We expect new packages (with a patch backported in many cases)
to be released very soon, and downstream packagers may also release Puppet
0.25.x packages that include these fixes. Thank you for your patience, and as
always, please report security vulnerabilities to secur...@puppetlabs.com.

Vulnerability Details
-

The following vulnerabilities have been discovered and fixed:

* CVE-2011-3870, a symlink attack via a user's SSH authorized_keys file
* CVE-2011-3869, a symlink attack via a user's .k5login file
* CVE-2011-3871, a privilege escalation attack via the temp file used
by the puppet resource application
* A low-risk file indirector injection attack


SSH Authorized Keys Symlink -- CVE-2011-3870 (Critical)
--

Type: Local Privilege Escalation

Credit to Ricky Zhou  for the discovery and fix.

A TOCTOU (time-of-check-to-time-of-use) race vulnerability was present in the
ssh_authorized_key type (and theoretically in the Solaris and AIX providers).
When the target file and directory did not exist, each of them would be
created as root and later chowned to the user. This made it possible to
replace either one with a symlink to an arbitrary file, which would then
become owned by that user. This would allow local privilege escalation to root
through standard TOCTOU attack techniques.

Unlike most Puppet types, this risk was exacerbated by the nature of the
ssh_authorized_key type, which almost always manages data in directories
controlled by unprivileged (and likely untrusted) users.

This issue has been fixed by making all file operations happen with the
privileges of the target user, ensuring that a user can cause no harm beyond
their normal capabilities on the system.


k5login attach -- CVE-2011-3869 (Critical)
--

Type: Local Privilege Escalation

The k5login type is typically used to manage a file in the home
directory of a user; the explicit purpose of this file is to allow
access to other users.

This type previously wrote to the target file directly, as root, without doing
anything to secure the file. If the .k5login file was replaced with a symlink,
this would allow the owner of the home directory to replace any file on the
system, including the .k5login file of a more privileged user, with the
“correct” content of their own file.

This issue was discovered during a code audit following the report of
the ssh_authorized_key vulnerability, and the fix was very similar.


Predictable temp file using RAL -- CVE-2011-3871 (Critical)
--

Type: Local Privilege Escalation

Previously, puppet resource in --edit mode used an extremely predictable file
name, which would persist on human timescales, could be known well ahead of
creation, and would be run as the invoking user upon completion of the
operation.

This could be exploited to trick the invoking user into editing an arbitrary
target file, or running arbitrary Puppet code. As puppet resource is not very
effective when not run as root, the potential effect of an attack was quite
high.


File indirector injection (Low risk)
--

The indirector/file.rb terminus base class trusted the request key and used it
as part of the pathname, like the YAML and SslFile terminus base classes did.

The mitigating factor in this vulnerability was that this code was unused
except in one unit test, which has been rewritten.





If you have any questions or need additional clarification on
anything, please respond to secur...@puppetlabs.com.



Thanks,
Michael Stahnke
Release Manager - Puppet Labs

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

[Puppet-dev] Announce: Facter 1.6.1 Available

[Michael Stahnke]

Facter 1.6.1 is a maintenance release containing fixes, updates and
refactoring. Significant effort has been put into getting to Facter to
run on Windows for this release, as noted below.

This release is available for download at:
 http://puppetlabs.com/downloads/facter/facter-1.6.1.tar.gz

See the Verifying Puppet Download section at:
 
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads


Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.6.1:
 http://projects.puppetlabs.com/projects/facter/

Full Release Notes at: https://projects.puppetlabs.com/projects/facter/wiki/Wiki

RPMs are available via http://yum.puppetlabs.com/el

Facter is also available from rubygems.org.






#  Facter 1.6.1 Release Notes
#   Fix physicalprocessorcount on windows

Fix #9517

A broken test led to a broken fact. The WMI.execquery was
incorrectly stubbed
to return an array when the actual WMI.execquery does not return
an array. This
means that length, which works on arrays, does not work with WMI.execquery.
This fixes both the fact and the test. The test is unfortunately lifted to a
higher level, but it has the benefit of being correct.

Thanks to Eric Stonfer for the fact fix.

#   Prevent repeated loading of fact files

Fix #8491

Fact loading could recurse indefinitely if a fact file attempted to call
Fact#value on a fact that was not yet defined before the current file.
If Fact#value was called outside of a setcode block, it would be
evaluated at load time and the loader would rescan the fact path from
the beginning and would reenter the current file, continuing until the
stack was full. This is a byproduct of the more exhaustive fact
searching introduced in 2255abee.

The resolution for this is to track the files that have been loaded and
ignore subsequent attempts to load them, emulating the behavior of
Kernel.require. However, since facts can be legitimately refreshed
over the life of a ruby process using Facter, Facter.clear will reset
the list of loaded files by destroying the fact collection, and
subsequently the loader.

Currently puppet agent will reload all facts preceeding a run, so normal
puppet agent behavior will remain as expected. However, the facter facts
terminus manually loads fact files itself and bypasses facter's search
path and standard loading mechanism. While it will benefit from the
recursion protection, it currently does not have a way to reset the
loaded file list.

# Fix logic for domain fact so hostname, then dnsdomainname and
finally resolv.conf is used.

Fix #9457

A recent commit changed the logic for how this fall-through logic was
working. I've fixed the logic and added more coverage to pick up on this.

# Physical Memory on Windows
   (#8439) Implement total and free physical memory on Windows

This commit adds the 'memoryfree' and 'memorytotal' facts for Windows.
These values represent the amount of physical free and total memory
respectively. Note that the free and total values come from different
WMI objects that report memory sizes in different units. The free
value reported by Win32_OperatingSystem is in kB whereas the total
value as reported by Win32_ComputerSystem is in bytes.

This commit does not add facts for free and total page sizes, since
the total page size is associated with the Win32_PageFileSetting
class, but WMI reports no instance(s) available when automatic page
file management is enabled (and it is by default).

# Physical Processor Count for Windows
   (#8439) Add physicalprocessorcount and processor facts on Windows

This commit adds the 'physicalprocessorcount', 'processor{n}' and
'processorcount' facts. The 'physicalprocessorcount' fact is obtained
by counting the number of Win32_Processor instances. Note that the WMI
query does a select on just the Name property, because it is faster
than doing a 'select *'

On Windows 2008, each Win32_Processor represents a physical processor,
and the NumberOfLogicalProcessors property (which includes both multi
and/or hyperthreaded cores) represents the number of logical
processors. For example, a dual-core processor, with quad-hyper
threads per core, will report 1 physical processor and 8 logical
processors.

Note that the NumberOfCores property could be used to distinguish
between multi-core and hyperthreading processors, but the fact does
not distinguish between them.

On Windows 2003, each Win32_Processor represents a logical processor,
and the NumberOfLogicalProcessors property is not available. In this
case, the physicalprocessorcount fact will be over-reported, but the
number of logical processors will be correct.

With that said, if this hotfix is installed, then 2003 behaves like
2008:

  htt

[Puppet-dev] Announce: Puppet 2.7.4 Available [security + more ]

[Michael Stahnke]

Puppet 2.7.4 is available.  This release of Puppet and includes a
security fix for CVE-2011-3848.

Puppet 2.7.4 is an enhancement + security release of Puppet on the
2.7.x branch.  Due to the security patches included, it is recommended
anybody using the 2.7.x series update to 2.7.4.

The significant highlights on this release are outlined below.  At a
high level, there are lots of Windows fixes/features, some
storedconfigs indirection, a security patch, and more.

This is 2.7.4rc3 + the one security patch for CVE-2011-3848.



This release is available for download at:
http://downloads.puppetlabs.com/puppet/

Release Notes have been updated:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.4

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 2.7.4
http://projects.puppetlabs.com/projects/puppet

RPM's are available at http://yum.puppetlabs.com/el

Puppet is also available via Rubygems at http://rubygems.org

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Documentation is available at:
http://docs.puppetlabs.com/index.html






2.7.4 Release Notes
===

## CVE-2011-3848

Resist directory traversal attacks through indirections.

In various versions of Puppet it was possible to cause a directory traversal
attack through the SSLFile indirection base class.  This was variously
triggered through the user-supplied key, or the Subject of the
certificate, in
the code.

Now, we detect bad patterns down in the base class for our indirections, and
fail hard on them.  This reduces the attack surface with as little
disruption
to the overall codebase as possible, making it suitable to deploy as part of
older, stable versions of Puppet.

In the long term we will also address this higher up the stack, to prevent
these problems from reoccurring, but for now this will suffice.

Huge thanks to Kristian Erik Hermansen
 for the
responsible disclosure, and useful analysis, around this defect.

## Allow cron vars to have leading whitespace

Fix #9440

Patch applied from Jeremy Thornhill. This allows whitespace to appear before
cron variables. Previously, whitespace before cron variables would trigger a
parse failure, and the crontab, except for the puppet managed portion, would
get removed. This addresses that issue. It also includes a test
for this issue,
added into the tests directory, which seems to be where the
crontab tests live.

## Write out a list of resources that are managed by puppet agent

Feature #8667

Similar to how the Puppet classes are written out each catalog apply,
the list of resources is now being written out to a text file that can
be easily used by tools like MCollective.  This allows tools that do
ad-hoc management of resources to know if they're changing a resource
that puppet manages, and adjust behavior accordingly.

## Fix value validation on options

Fix #7114

Support single options that legally include a comma like
"from=host1,host2". We now basically allow either "word" or "key=value"
as options. That's also what the parsedfile provider currently supports
when parsing options.

## GigabitEthernet/TenGigabitEthernet are uncorrectly parsed

Fix #7984

The interface name abbreviation to canonical name doesn't return
the correct name for GigabitEthernet and doesn't support TenGigabitEthernet
interfaces.

## Allow macauthorization provider to work on OS X Lion 10.7

Fix #9143

We've flipped around the confine check so we explicitly exclude the
versions of OS X where this provider won't work, rather than working
from a whitelist.


## Move complex collect expression error into terminus.

Fix #9051

When the StoreConfig system was extracted from core to a set of
termini, most
of the rules about permitted syntax were pushed down into the same place, to
allow them to also be replaced.

One set of restrictions were missed, the limitation that complex search
criteria (like and, or, or parenthetical expressions) were not
permitted, and
remained in our parser.

Now, they live in the terminus, and we enforce them only there.
This ensures
that StoreConfigs can be replaced with a back-end that supports complex
collection criteria without other changes to the Puppet core.

## Don't rely on error message to detect UAC capable platform

Fix #8662

The call to Win32::Security.elevated_privileges? can raise an
exception when running on a pre-Vista computer or if the process fails
to open its process token.

Previously, we were looking at the exception message to determine
which case it was. However, Windows 2003 and 2003 R2 return different
error codes (and th

[Puppet-dev] Announce: Puppet 2.6.10 is available [security update]

[Michael Stahnke]

Puppet 2.6.10 is a maintenance release in the 2.6.x branch.

This release is 2.6.9 + a security fix for CVE-2011-3848.

Note: Features/fixes that were targeted at 2.6.10 have been moved to 2.6.11.




Puppet 2.6.10 is available.  Changelog entries are available below.
More detailed information is available in on our Release Notes page.

Release Notes have been updated:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.10


This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.6.10.tar.gz

RPM's are available at http://yum.puppetlabs.com/el

Puppet is also available via Rubygems at http://rubygems.org

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.6.10
http://projects.puppetlabs.com/projects/puppet/



Commits:

fe2de81 Resist directory traversal attacks through indirections. (CVE-2011-3848)

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

[Puppet-dev] Announce: New Puppet releases due to CVE-2011-3848 [security]

[Michael Stahnke]

There has been a vulnerability discovered in Puppet (CVE-2011-3848).


# Recommended Action #

Puppet Labs has an updated version of Puppet available at the
following locations:

* http://puppetlabs.com/security/hotfixes
* http://puppetlabs.com/downloads/puppet


The fixed versions are 2.6.10 in the 2.6.x branch and 2.7.4 in the
2.7.x branch.

The hotfixes page also contains updated Puppet packages for Puppet
Enterprise versions 1.0, 1.1 and 1.2.x.


Puppet Labs has been coordinating with Debian, Ubuntu, EPEL and
OpenSuSE maintainers.  We expect new packages (with a patch backported
in many cases) to be released as soon as possible.


Separate release announcements for Puppet 2.6.10 and 2.7.4 are pending.



# Explanation  #


   Kristian Erik Hermansen  reported that
   an unauthenticated directory traversal could drop any valid X.509
   Certificate Signing Request at any location on disk, with the
   privileges of the Puppet Master application.  This was found in the
   2.7 series of Puppet, but the underlying vulnerability existed in
   earlier releases and could be accessed with different hostile inputs.

   There are also some additional quirks of input handling that make it
   easier to obfuscate the input.

   This exploits an input quirk where the "key" in the URI is
   double-decoded; this would also work for a single URI-encoded input
   string.

   On 2.6 this is ignored, but the CN in the Subject of the CSR is used
   in the same way, and could be exploited to drop the CSR content at an
   arbitrary location on disk.  The suffix ".pem" is always appended
to the location.


   In the 0.25 series the same CN-based injection can occur, as the
   underlying flaw still exists.

   In all cases this requires that the input data can be loaded through
   OpenSSL as a CSR, and will fail before touching disk if that is not
   valid data.


   Be aware that both double-encoded and single-encoded URI patterns will
   work, equivalently, in Puppet 2.7.  No URI decoding is done on the CN
   of the CSR Subject.



# Commit message for fix #

I have included patches for the 0.25.x, 2.6.x, and 2.7.x branches.

  Author: Daniel Pittman  Date:   Sat Sep
  24 12:44:20 2011 -0700

  Resist directory traversal attacks through indirections.

  In various versions of Puppet it was possible to cause a directory
  traversal attack through the SSLFile indirection base class.
  This was variously triggered through the user-supplied key, or
  the Subject of the certificate, in the code.

  Now, we detect bad patterns down in the base class for our
  indirections, and fail hard on them.  This reduces the attack
  surface with as little disruption to the overall codebase as
  possible, making it suitable to deploy as part of older, stable
  versions of Puppet.

  In the long term we will also address this higher up the stack,
  to prevent these problems from reoccurring, but for now this
  will suffice.

  Huge thanks to Kristian Erik Hermansen 
  for the responsible disclosure, and useful analysis, around
  this defect.

  Signed-off-by: Daniel Pittman 




# Note for 0.25 users #

If you're still shipping/using 0.25, we have supplied a patch to
several distro maintainers that
applies cleanly to our git tree, but will not be releasing any
upstream source of it.





If you have any questions or need additional clarification on
anything, please respond to secur...@puppetlabs.com.


Thanks, Michael Stahnke
Release Manager -- Puppet Labs

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

Re: [Puppet-dev] facter and indent spacing

[Michael Stahnke]

On Tue, Sep 20, 2011 at 4:55 AM, Ken Barber  wrote:
> Interesting approach. I'll be in portland for a week after puppetconf.
> Happy to lend a hand.
>
> On Tue, Sep 20, 2011 at 2:48 AM, Luke Kanies  wrote:
>> I agree. Maybe it's worth a merge-a-thon to get as many merged as possible
>> in a fixed amount of time, then just draw the line?
I think a merge-a-thon sounds like the best bet.  We have quite a bit
of outstanding code in topic branches, pulls, etc.  Let's get it
tested and put in, then switch the spacing.

Mike

>>
>> --
>> Luke Kanies | +1-615-594-8199 | http:/about.me/lak
>> On Sep 19, 2011, at 3:22 PM, Adrien Thebo  wrote:
>>
>> I'm of two minds of this. On one hand, it would be terribly nice to get as
>> many patches merged as possible before we do a whitespace change just so
>> that we don't have to deal with any weird conflicts. On the other hand, as
>> you said git can probably handle the whitespace change, and I would like to
>> drive this change through as soon as possible. Since facter bugs do tend to
>> sit for a while, I would like to get up the momentum to drive through the
>> whitespace for 1.7.x before too much time passes.
>>
>> On Mon, Sep 19, 2011 at 6:36 AM, Ken Barber  wrote:
>>>
>>> Hi,
>>>
>>> So I raised a ticket for fixing mixed whitespace in facter:
>>>
>>> http://projects.puppetlabs.com/issues/9555
>>>
>>> And I've got a preliminary patch in a topic branch just to see how bad
>>> the problem is. The reason I've raised this is that people making
>>> changes across multiple files at the moment are finding that some
>>> files are 4 space indents, some are 2 space - and sometimes people are
>>> mixing 2 space indents within 4 space indent files.
>>>
>>> I know we've done this before for Puppet - so I wouldn't mind getting
>>> some opinion and ideas on this kind of a change. From an offline
>>> discussion with Adrien Thebo we obviously want to make this easy for
>>> any forward porting of patches from 1.6 to other branches. It was
>>> suggested this kind of change wait for 1.7 which is cool - but if we
>>> still are doing active development on 1.6 the forward porting maybe
>>> become painful. Should we just do this across all active 'supported'
>>> branches so we can feel the pain once and cherry-picked patches for
>>> forward porting can then be more trivial? There is 15 pending merges
>>> that would _potentially_ need to be fixed (and who knows how many that
>>> haven't been requested yet that would need rebasing/fixing).
>>>
>>> Looking at the whitespace merge techniques around the net I can see
>>> there is a recursive merge strategy option for ignoring whitespace
>>> (-Xignore-space-change) but this seems to be in the wrong direction to
>>> what we would desire. While rebase has an option to ignore whitespace
>>> so at the very least this could be made easier for active development
>>> work.
>>>
>>> What do people think about this? Does anyone have any experience with
>>> feeling the pain of such a change? Is there a good strategy to adopt
>>> here? I guess my attitude is that the sooner this is done the better,
>>> but perhaps I'm being naive.
>>>
>>> ken.
>>>
>>> --
>>> "Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
>>> http://bit.ly/puppetconfsig";
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Developers" group.
>>> To post to this group, send email to puppet-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-dev+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-dev?hl=en.
>>>
>>
>>
>>
>> --
>> Adrien Thebo
>> adr...@puppetlabs.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>
>
>
> --
> "Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
> http://bit.ly/puppetconfsig";
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google 

[Puppet-dev] Re: [Puppet Users] Re: Community Package Repos for Puppet Labs products

[Michael Stahnke]

On Mon, Sep 12, 2011 at 3:39 PM, Vlad  wrote:
> Are there any plans to get the latest puppet and facter into
> apt.puppetlabs.com?
>
Of course.  I started with yum simply because it was asked for more
loudly, and I know rpm a bit better than the debian packaging.  I
welcome any help, reviews, ideas on the debian packaging side (all
sides really).


Mike

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

[Puppet-dev] Community Package Repos for Puppet Labs products

[Michael Stahnke]

I've had a vision of having packages for Puppet, Dashboard,
mcollective, facter, et al, available in native packaging formats for
as many distributions as possible.


I've updated http://yum.puppetlabs.com quite a bit today.

We have most of what I laid out in ticket
http://projects.puppetlabs.com/issues/8473.  I've updated RPMs for
el5, el6, f14, f15.  Next I'll do el4 and then SLES.

These RPMS are all signed, and the latest released software from Puppet Labs.



I've also created a Redmine Project around Community Packaging.  My
goal would be to get help from the community, specifically on our lesser-used
platforms.


http://projects.puppetlabs.com/projects/puppet-community-pkg-repo

Please use the redmine project to open issues, etc.  (This isn't just
for yum either)


Thanks,
Mike

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

Re: [Puppet-dev] Re: [Puppet Users] Release Cycle for September

[Michael Stahnke]

On Wed, Sep 7, 2011 at 9:04 PM, Matt Robinson  wrote:
> On Wed, Sep 7, 2011 at 6:15 PM, Michael Stahnke  
> wrote:
>> 3.  Dashboard has had no commits since 1.2.0, so no RC this month.
>
> Dashboard does have commits since 1.2.0
>
> $ git log --oneline --no-merges 1.2.0..
> 6b10a5e maint: Move duplicated code to a helper method
> 02ca4ff maint: Fix node_ids method by not overwriting it with and 
> attr_accessor
> a2b864d (#8878) Make code more DRY
> 0075dd9 (#8878) Add ability to add nodes from the group edit/create pages
> ee59af8 (#8803) A single report page has a header with too much padding
>
You're right.  I'll make this today as well.

Mike


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

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

Re: [Puppet-dev] Release Cycle for September

[Michael Stahnke]

On Wed, Sep 7, 2011 at 6:27 PM, Eric Sorenson  wrote:
> Hi Mike -- is there a 2.6.10 on the horizon? I see a few bugs slated for it 
> and many more on '2.6.x'.


Short answer, yes.  I don't know when yet though.  I'll find out more
and let you know.


Mike

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

[Puppet-dev] Release Cycle for September

[Michael Stahnke]

Greetings,

This month we're having a couple changes in our release cycle.

1.  Facter 1.6.1 will rc shortly.  We actually cut rc1 internally and
caught some test failures that appear to be order dependent.  We are
hoping to have this out 08-Sep-2011

2.  Puppet 2.7.4rc1 will be cut ASAP, likely 08-Sep-2011.  This will
have some Windows goodies in it.

3.  Dashboard has had no commits since 1.2.0, so no RC this month.

We apologize for the delay in getting you these release candidates.




Mike

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

Re: [Puppet-dev] (puppetlabs/puppet) New pull request: Fixed #663 - Changed default certification key lenght and hash

[Michael Stahnke]

Telly must support RHEL4, as PE supports RHEL4.

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

[Puppet-dev] Announce: Dashboard 1.2.0 is available now

[Michael Stahnke]

It's here.  Puppet Labs Announces Puppet Dashboard version 1.2.0.

This is a significant upgrade over the 1.1.x series, with new
features, prettier views and some all-in-all awesomeness.   Thanks to
those who filed bugs, submitted patches and helped with the RC
process.


Major Highlights:
--
*  Dashboard now processes workloads asynchronously with a delayed_job
worker.  The worker is controlled either through Rake in the RAILSROOT
or through init scripts (puppet-dashboard-workers) on rpm and deb
based systems.
* License change to Apache Software License version 2.0
* Upgraded version of Rails stack components
* Export most views to CSV
* Dashboard now requires Ruby 1.8.7 to operate
* Puppet agents should be at 2.6.4 or higher


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.0
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html


CHANGELOG since 1.1.1

v1.2.0
===
9c32431 (#8228) Reports fail to upload with spool directory
0bfa755 (#9101) Dashboard workers should not be enabled by default
3abc596 (#9103) Remove invalid files from git repo
f52b0ee (#9182) Fix ability to add classes and groups on creation
e924586 (#9195) Use a shorter date format for the report status graph
2e85b8d Apply security patch for XSS Vulnerability in the escaping
function in Ruby on Rails
d3bfcf5 Apply security patch for XSS Vulnerability in strip_tags helper
107f101 Apply security patch for SQL Injection Vulnerability in quote_table_name
0a73593 (#7934) Improve wording to filebucket error
fa8d27c (#7934) Give a better error message when filebucket contents don't exist
7b742e9 (#7934) Don't link md5s for new content
735925f (#9032) Update Debian package to ensure VERSION is packaged
620de4e (#8251 and #8042) Don't use our own logger
a2a97ab (#8796) Re-write misleading 500 error message
6b525b1 (#5845) Changed host to node in UI.
90f5ce0 (#8488) Move tfoot before tbody in reports table
ee1f182 (#8488) Make columns consistent between report views
e54ecb8 (#8790) Fix reports page column display and alignment
947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates
4ef96b6 (#8785) Close a directory that we open
0bfbbf6 (#8785) - Revert "(#8748) Upgrade vendored daemons gem to fix
umask on pids"
3f88c7f (#8748) Fix my forgetting to add a vendored gem
2f636a9 Allow setting of RUBY for the workers on redhat systems
651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
bf22939 Add document outlining preferred contribution methods
49cca0b Add document outlining preferred contribution methods
803be4f (#8745) Update gitignore to not exlucde tmp during tarball creation
e45338a (#8691) Fix the order of changed and unchanged resources on
the report summary
7653800 Provide clearer error message when report host, kind and time
are not unique
e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
82eeea7 (#7567) Refactor dashboard packaging to allow for nightly builds
a58f3e0 (#6840) Remove need for VERSION file in puppet-dashboard
d9a384f (#8316) Ruby sorting for ResourceEvents.
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
8f7da94 Remove unused node_groups/_node_groups partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
68c0236 Maint: Added $RAILSROOT/spool directory
365a432 Maint: Removing reference to CentOS 5.5.
518bbca Maint: Added rake task to generate srpm
223822e Maint: Updated rpm spec file.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
07ae6f7 Updating to rename pupet-dashboard-workers
491cf33 Updating spec.
a428d15 

Re: [Puppet-dev] Facter Branch Updates

[Michael Stahnke]

My thoughts on having three branches are the following.  I'm happy to
revisit though.


Mostly from semver.org


Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
compatible bug fixes are introduced. A bug fix is defined as an
internal change that fixes incorrect behavior.


This is 1.6.x.  Things like not being able to properly identify Oracle
Linux vs RHEL is a bug fix that could easily go in this branch.  We
have several other outstanding pull requests here that may land here
as well.


Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MAY be
incremented if substantial new functionality or improvements are
introduced within the private code. It MAY include patch level
changes.


This would be the 1.7.x branch.  This would include things like fact
caching.  It's a new feature and API-like functionality.



Major version X (X.y.z | X > 0) MUST be incremented if any backwards
incompatible changes are introduced to the public API. It MAY include
minor and patch level changes.


This is the master branch.  Things like having facts return structured
or rich data.  This is big because currently Puppet (probably the
primary consumer of facter) doesn't really deal with any data types
that are not strings.  This *could* potentially break API.


Maybe that helps?  Again, I could probably be talked out of three
branches, as I don't really like it.  It just seemed like the
least-worst way to keep it sane.

Mike


On Tue, Aug 23, 2011 at 9:26 PM, Josh Cooper  wrote:
>> We have
>>
>>  1.6.x --> feature set for 1.6 (no API breakage please, mostly bug fixes)
>>  1.7.x --> new features go here
>>  master --> newer, possibly experimental things here (this might be
>> 2.0 eventually, or who knows)
>>
>> 1.6rc exists, (as it has in the past) and is where facter is currently
>> released from.   I will spend some time adding these to jenkins to
>> ensure we stay updated with test failure, etc.
>
> We have been making facter changes in master for the Windows release. And I
> have one last set of changes to go in, also based on master. For the time
> being can we merge into master and then make the new branches (at which
> point 1.7.x is branched from master?)
> Also the Windows release should include a new version of facter, right? Will
> this be from 1.7.x?
> Let's catch up tomorrow and talk about this.
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>

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

Re: [Puppet-dev] Facter Branch Updates

[Michael Stahnke]

On Tue, Aug 23, 2011 at 7:10 PM, Luke Kanies  wrote:
> What is the master branch for, in this model?
There has been discussion of implementing structured data, and complex
data structures into facter that could lead to a 2.0 release (or
something along those lines).  That might require significant changes
to facter, and would require some puppet modification to handle
structured data.

Mike



>
> --
> Luke Kanies | +1-615-594-8199 | http:/about.me/lak
>
> On Aug 23, 2011, at 5:58 PM, Michael Stahnke  wrote:
>
>> All,
>>
>> I've added some new branches to Facter in order to get some
>> much-needed love into it.
>>
>> We have
>>
>>  1.6.x --> feature set for 1.6 (no API breakage please, mostly bug fixes)
>>  1.7.x --> new features go here
>>  master --> newer, possibly experimental things here (this might be
>> 2.0 eventually, or who knows)
>>
>> 1.6rc exists, (as it has in the past) and is where facter is currently
>> released from.   I will spend some time adding these to jenkins to
>> ensure we stay updated with test failure, etc.
>>
>>
>> Mike
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Developers" group.
>> To post to this group, send email to puppet-dev@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> puppet-dev+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/puppet-dev?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-dev?hl=en.
>
>

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

[Puppet-dev] Facter Branch Updates

[Michael Stahnke]

All,

I've added some new branches to Facter in order to get some
much-needed love into it.

We have

  1.6.x --> feature set for 1.6 (no API breakage please, mostly bug fixes)
  1.7.x --> new features go here
  master --> newer, possibly experimental things here (this might be
2.0 eventually, or who knows)

1.6rc exists, (as it has in the past) and is where facter is currently
released from.   I will spend some time adding these to jenkins to
ensure we stay updated with test failure, etc.


Mike

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

[Puppet-dev] Announce: Puppet Dashboard 1.2rc9

[Michael Stahnke]

Once more, with feeling,

Welcome to another Release Candidate for Puppet Dashboard (number 9).
This RC addresses security concerns announced/discovered in Rails over
the last couple days.


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2rc9
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html




1.2rc9
===
The three commits are related to CVE's from Rails.
We've back-ported the patches to our vendored version of Rails
included in Dashboard 1.2.


Detailed commit messages:

commit 2e85b8d53337c96c34ceffc49f17a4fb13ee9fc3
Author: Jacob Helwig 
Date:   Fri Aug 19 11:34:20 2011 -0700

Apply security patch for XSS Vulnerability in the escaping
function in Ruby on Rails

From the security announcement:

  There is a vulnerability in the escaping code used by Ruby on Rails,
  using specially crafted malformed unicode strings an attacker can
  bypass the escaping code.  This vulnerability has been assigned the
  CVE identifier CVE--.

  Versions Affected:  2.0.0 and later running on Ruby 1.8.x.
  Not Affected:   Applications running on Ruby 1.9.x
  Fixed Versions: 3.0.10, 2.3.13, 3.1.0.rc5

  Impact
  --

  Ruby on Rails has provided a high performance replacement for
  ERB::Util.h since version 2.0.0.  Due to a bug in the Ruby 1.8 Regular
  Expression code this replacement version will fail to escape certain
  malformed unicode strings.  This malformed output will then be
  interpreted as HTML by some browsers on some operating systems.

  All users running an affected release should either upgrade or use one
  of the work arounds immediately.

  Releases
  

  The 3.0.10, 2.3.13 and v3.1.0.rc5 releases are available at the normal
  locations.

  Workarounds
  ---

  It is possible to construct a before_filter to reject requests which
  contain invalid parameters, this should only be considered a temporary
  solution though.

  private
before_filter :reject_invalid_requests

def reject_invalid_requests
  if include_invalid_utf8?(params)
head :bad_request
  end
end

def include_invalid_utf8?(param)
  param.any? {|k, v| !validate(k, v)}
end

def validate(*vars)
  vars.all? do |var|
case var
when Hash
  var[:tempfile].respond_to?(:read) ? true :
!include_invalid_char?(var)
when Array
  validate(*var)
else
  ActiveSupport::Multibyte.verify(var.to_s)
end
  end
end

  Patches
  ---

  To aid users who aren't able to upgrade immediately we have provided
  patches for the two supported release series.  They are in git-am
  format and consist of a single changeset.

  * 2-3-utf_8.patch - Patch for 2.3 series
  * 3-0-utf_8.patch - Patch for 3.0 series
  * 3-1-utf_8.patch - Patch for 3.0 series

  Please note that only the 2.3.x and 3.0.x series are supported at
  present.  Users of earlier unsupported releases are advised to upgrade
  as soon as possible.

  Credits
  ---

  Thanks to Akira Matsuda and Falk Köppe for reporting the vulnerability
  to us and working with us to confirm a fix.

commit d3bfcf594d9b147e5f9f8b941d454b656b74c382
Author: Jacob Helwig 
Date:   Fri Aug 19 11:28:29 2011 -0700

Apply security patch for XSS Vulnerability in strip_tags helper

From the security announcement:

  There is a vulnerability in the strip_tags helper in Ruby On Rails,
  using specially crafted output an attacker can successfully inject
  HTML into the document. This vulnerability has been assigned the CVE
  identifier CVE--.

  Versions Affected:  All.
  Fixed Versions: 3.0.10, 2.3.13, 3.1.0.rc5

  Impact
  --
  The strip_tags helper in Ruby on Rails is designed to remove all
  HTML tags from a string.  By using specially crafted values an
  attacker can confuse the parser and cause HTML tags to be injected
  into the response.  This can be exploited to inject arbitrary
  javascript into the rendered page.

  Future releases of Ruby on Rails are likely to replace the current
  HTML tokenizer with one provided by libxml to reduce the likelihood
  of errors such as these in the future.  In the meantime users can
  install the loofah gem[1] which should enhance both the performance
  and reliability of the HTML sanitization helpers.

  Al

[Puppet-dev] Announce: Dashboard 1.2rc8

[Michael Stahnke]

Greetings,

Welcome to another Release Candidate for Puppet Dashboard (number 8).


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2rc8
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html




1.2rc8
===
* 0a73593 (#7934) Improve wording to filebucket error
* fa8d27c (#7934) Give a better error message when filebucket contents
don't exist
* 7b742e9 (#7934) Don't link md5s for new content


Highlights in 1.2rc8
===
* Debian package now reports proper version
* Ability to adjust log verbosity (no more raw SQL queries for every page view)
* Updated 500 error page
* Ensure all references to nodes are named node and not hostname,
host, machine, etc


1.2 series


Highlights Include:

* Moved to Apache 2.0 License
* LOTS of UI improvements
* Updated version of Rails
* Now Requires Ruby 1.8.7
* Has Delayed Jobs (puppet-dashboard-workers) for async actions
* Several performance improvements


More Details
===
735925f (#9032) Update Debian package to ensure VERSION is packaged
620de4e (#8251 and #8042) Don't use our own logger
a2a97ab (#8796) Re-write misleading 500 error message
6b525b1 (#5845) Changed host to node in UI.
49cca0b Add document outlining preferred contribution methods
90f5ce0 (#8488) Move tfoot before tbody in reports table
ee1f182 (#8488) Make columns consistent between report views
e54ecb8 (#8790) Fix reports page column display and alignment
947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates
4ef96b6 (#8785) Close a directory that we open
0bfbbf6 (#8785) - Revert "(#8748) Upgrade vendored daemons gem to fix
umask on pids"
3f88c7f (#8748) Fix my forgetting to add a vendored gem
2f636a9 Allow setting of RUBY for the workers on redhat systems
651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
bf22939 Add document outlining preferred contribution methods
803be4f (#8745) Update gitignore to not exclude tmp during tarball creation
45338a (#8691) Fix the order of changed and unchanged resources on the
report summary
7653800 Provide clearer error message when report host, kind and time
are not unique
e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
fbe11aa (#8196) Adjust content width based on body classes.
e756c25 (#8196) Add a body class describing sidebar state.
23cbef1 (#8196) Clean up body class manipulation.
3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost
81ec3c0 (#8090) Update .gitignore to ignore plugin files
6f117fc (#8022) Don't fail when installing plugin without `public` directory
07a9407 (#8022) Create a hook for plugins to add items to  in layout
64be352 (#7967) Add default value for read column of delayed_job_failures
240c548 (#7967) Infrastructure for displaying background failures.
8038cce (#7389) Don't auto-start DelayedJob workers.
933ae04 (#7389) Cheaper unique filenames for spooled reports.
b4384eb (#7398) Support externally managed DelayedJob workers.
184e65b (#7689) Rake task to support parallel report POSTing.
2333c08 (#5947) Rename Destroy button to Delete
2fb0ac1 (#7976) Fixed static debug data in view
393970d (#7976) Node filter links in sidebar work in all cases
4ba3d23 (#7398) Configurable DelayedJob worker count.
e839884 (#7938) Delayed import from file, not YAML string.
d24c323 (#7973) Refactor colors for changed/unchanged
58c2b52 (#7398) Use DelayedJob for background processing.
6

[Puppet-dev] Announce: Dashboard 1.2rc7

[Michael Stahnke]

Greetings,

Welcome to another Release Candidate for Puppet Dashboard (number 7).


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2rc7
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html


Highlights in 1.2rc7
===
* Debian package now reports proper version
* Ability to adjust log verbosity (no more raw SQL queries for every page view)
* Updated 500 error page
* Ensure all references to nodes are named node and not hostname,
host, machine, etc


1.2rc7
===
735925f (#9032) Update Debian package to ensure VERSION is packaged
620de4e (#8251 and #8042) Don't use our own logger
a2a97ab (#8796) Re-write misleading 500 error message
6b525b1 (#5845) Changed host to node in UI.
49cca0b Add document outlining preferred contribution methods


1.2 series



Highlights Include:

* Moved to Apache 2.0 License
* LOTS of UI improvements
* Updated version of Rails
* Now Requires Ruby 1.8.7
* Has Delayed Jobs (puppet-dashboard-workers) for async actions
* Several performance improvements


More Details
===
90f5ce0 (#8488) Move tfoot before tbody in reports table
ee1f182 (#8488) Make columns consistent between report views
e54ecb8 (#8790) Fix reports page column display and alignment
947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates
4ef96b6 (#8785) Close a directory that we open
0bfbbf6 (#8785) - Revert "(#8748) Upgrade vendored daemons gem to fix
umask on pids"
3f88c7f (#8748) Fix my forgetting to add a vendored gem
2f636a9 Allow setting of RUBY for the workers on redhat systems
651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
bf22939 Add document outlining preferred contribution methods
803be4f (#8745) Update gitignore to not exclude tmp during tarball creation
45338a (#8691) Fix the order of changed and unchanged resources on the
report summary
7653800 Provide clearer error message when report host, kind and time
are not unique
e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
fbe11aa (#8196) Adjust content width based on body classes.
e756c25 (#8196) Add a body class describing sidebar state.
23cbef1 (#8196) Clean up body class manipulation.
3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost
81ec3c0 (#8090) Update .gitignore to ignore plugin files
6f117fc (#8022) Don't fail when installing plugin without `public` directory
07a9407 (#8022) Create a hook for plugins to add items to  in layout
64be352 (#7967) Add default value for read column of delayed_job_failures
240c548 (#7967) Infrastructure for displaying background failures.
8038cce (#7389) Don't auto-start DelayedJob workers.
933ae04 (#7389) Cheaper unique filenames for spooled reports.
b4384eb (#7398) Support externally managed DelayedJob workers.
184e65b (#7689) Rake task to support parallel report POSTing.
2333c08 (#5947) Rename Destroy button to Delete
2fb0ac1 (#7976) Fixed static debug data in view
393970d (#7976) Node filter links in sidebar work in all cases
4ba3d23 (#7398) Configurable DelayedJob worker count.
e839884 (#7938) Delayed import from file, not YAML string.
d24c323 (#7973) Refactor colors for changed/unchanged
58c2b52 (#7398) Use DelayedJob for background processing.
6aefc60 (#7938) Add daemons gem to support DelayedJob
7395369 (#7398) Vendor DelayedJob for background tasks.
05040d9 (#7958) Allow plugins to add top level navigation
c4d2f26 (#7597) Bette

[Puppet-dev] ANNOUNCE: Puppet 2.7.3

[Michael Stahnke]

As stated a few days ago [1], the 2.7.2 series died in the
Thunderdome[2], as per our release process.  August has brought about
2.7.3.  This includes all fixes from the 2.7.2, series as well as
several new fixes and enhancements.  This is also the first
release of the 2.7 (Statler) series, that includes the roll-up fixes
from 2.6.9.

Puppet 2.7.3 is available.  Changelog entries are available below.
More detailed information is available in on our Release Notes page.

Release Notes have been updated:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.3


This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.7.3.tar.gz

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.7.3
http://projects.puppetlabs.com/projects/puppet/


2.7.3 merges up all changes in the 2.6.9 release that were unable to be
merged into 2.7.{0,1} due to 2.7 being frozen in release candidate
state.  It also includes changes introduced in the never-released
2.7.2 series of puppet.


CHANGELOG
===
7113448 (#4762) Ensure that clients on the moon can successfully connect.
c8835ad Add document outlining preferred contribution methods
ea0f2bf Revert "Merge branch 'vcsrepo'"
94f0b93 (#8704) Give better errors for invalid fileserver.conf
023d959 (#8690) Accept 'global' options in Puppet Faces
c315da0 Fix #1886 - Add node cleanup capability
7e6fc0d Deprecate RestAuthConfig#allowed? in favor of #check_authorization
6401dfe Fix #6026 - security file should support inline comments
0c385f1 Fix #5010 - Allow leading whitespace in auth.conf
8da0486 Fix #5777 - rule interpolation broke auth.conf CIDR rules
1d4acb5 maint: Suggest where to start troubleshooting SSL error message
fb2ffd6 (#8596) Detect resource alias conflicts when titles do not match
778127d maint: Fix cert app to print help and exit if no subcommand
0366b18 (#7293) Set default format for SSL-related faces.
89c021c (#8418) Fix inspect app to have the correct run_mode
3165364 maint: Adding logging to include environment when source fails
f484851 maint: Add debug logging when the master receives a report
10e05ad (#7266) Move Certificate option validation into face.
ae36003 (#7290) Update indirected Faces to avoid unknown options.
82e5fa9 (#8561, #7290) Implement the option contract fully.
77441be (#8561) Unify validation and modification of action arguments.
69b4e70 (#7290) Fail on unknown options.
6bec2df (#8561) Use canonical names for options to actions.
532c4f3 (#7184) Load the core of obsolete versions of Faces.
2cd3bc4 (#7184) Find actions bound to other versions of Faces.
1e0655e (#7184) Centralize "find action for face" into Puppet::Face
0396611 maint: better error reporting when test fails
395c174 (#7123) Make `find` the default action...
fd6a653 (#7123) Support runtime setting of 'default' on actions.
b75b1c1 (#6787) Add `default_to` for options.
c830ab0 (#6789) Port SSL::CertificateAuthority::Interface to a Face
cc311ad maint: SSL::Inventory.serial should report missing names.
72abe6c (#7204) Consolidate Semantic Versioning code.
d02000b (#8401) Document that --detailed-exitcodes is a bitmask
c4848d2 maint: Fix documentation link for fileserver configuration
b268fb3 (#7144) Update Settings#writesub to convert mode to Fixnum
b82f29c (#7699) Help command should only list options once
4a2f22c (maint) Fix platform dection for RHEL
45b3908 (#4142) Fix module check not to fail when empty metadata.json
ae3ef42 (#7699) - Help should only show options once
5826f73 (#8032) Add containment to create_resources
f6882d6 (#8147) Change default reporturl to match newer Dashboard versions
111a4b5 (#6857) Password disclosure when changing a user's password
99330fa (#7224) Reword 'hostname was not match' error message
1d867b0 (#7224) Add a helper to Puppet::SSL::Certificate to retrieve
alternate names
98ba407 (#7127) Stop puppet if a prerun command fails
caca469 (#4416) Ensure types are providified after reloading
413b136 (#4416) Always remove old provider before recreating it
3f0dbb5 (#650) Allow symlinks for configuration directories
1c70f0c (#2128) Add support for setting node name based on a fact
c629958 (#2128) Get facts before retrieving catalog
cd4fe14 (#2128) Add the ability to specify a node name
c02126d (#5966) Add support for hostname regular expressions in auth.conf
75e2764 (#5318) Always notice changes to manifests when compiling.
107b38a maint: Fix pacman provider to work with Ruby 1.9
90eb937 (#7139) Accept '/' as a valid path in filesets


[1] 
http://groups.google.com/group/puppet-users/browse_thread/thread/fb68f18b97f39070
[2] 
http://groups.google.com/group/puppet-users/browse_thread/thread/3d703849246bd43f/c98d096d51ed221e

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to 

[Puppet-dev] Announce: Dashboard 1.2rc6 available

[Michael Stahnke]

Greetings,

Welcome to another Release Candidate for Puppet Dashboard (number 6).


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2rc6
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html




1.2rc6
===
* Fixes a problem with delayed job that would cause it to fail silently
* Fixes an inconsistency in report views
* Ensures that files created via delayed_job have proper permissions

Details
===
90f5ce0 (#8488) Move tfoot before tbody in reports table
ee1f182 (#8488) Make columns consistent between report views
e54ecb8 (#8790) Fix reports page column display and alignment
947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates
4ef96b6 (#8785) Close a directory that we open
0bfbbf6 (#8785) - Revert "(#8748) Upgrade vendored daemons gem to fix
umask on pids"

1.2 series



Highlights Include:

* Moved to Apache 2.0 License
* LOTS of UI improvements
* Updated version of Rails
* Now Requires Ruby 1.8.7
* Has Delayed Jobs (puppet-dashboard-workers) for async actions
* Several performance improvements


More Details
===
3f88c7f (#8748) Fix my forgetting to add a vendored gem
2f636a9 Allow setting of RUBY for the workers on redhat systems
651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
bf22939 Add document outlining preferred contribution methods
803be4f (#8745) Update gitignore to not exclude tmp during tarball creation
45338a (#8691) Fix the order of changed and unchanged resources on the
report summary
7653800 Provide clearer error message when report host, kind and time
are not unique
e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
fbe11aa (#8196) Adjust content width based on body classes.
e756c25 (#8196) Add a body class describing sidebar state.
23cbef1 (#8196) Clean up body class manipulation.
3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost
81ec3c0 (#8090) Update .gitignore to ignore plugin files
6f117fc (#8022) Don't fail when installing plugin without `public` directory
07a9407 (#8022) Create a hook for plugins to add items to  in layout
64be352 (#7967) Add default value for read column of delayed_job_failures
240c548 (#7967) Infrastructure for displaying background failures.
8038cce (#7389) Don't auto-start DelayedJob workers.
933ae04 (#7389) Cheaper unique filenames for spooled reports.
b4384eb (#7398) Support externally managed DelayedJob workers.
184e65b (#7689) Rake task to support parallel report POSTing.
2333c08 (#5947) Rename Destroy button to Delete
2fb0ac1 (#7976) Fixed static debug data in view
393970d (#7976) Node filter links in sidebar work in all cases
4ba3d23 (#7398) Configurable DelayedJob worker count.
e839884 (#7938) Delayed import from file, not YAML string.
d24c323 (#7973) Refactor colors for changed/unchanged
58c2b52 (#7398) Use DelayedJob for background processing.
6aefc60 (#7938) Add daemons gem to support DelayedJob
7395369 (#7398) Vendor DelayedJob for background tasks.
05040d9 (#7958) Allow plugins to add top level navigation
c4d2f26 (#7597) Better integration of node summaries
4ad9cbc (#7913) Upgrade rspec and rspec-rails vendored gems
c09b650 (#7913) Fix tap deprecation warning
d88da0e (#7913) Update README to say we only support Ruby 1.8.7
acdc31f (#7913) upgrade will_paginate gem to avoid deprecation warnings
e935b8d (#7913) vendor newer version of RDoc
ce9be98 (#7913) Fix depreca

[Puppet-dev] Announce: Puppet 2.7.3rc1 available

[Michael Stahnke]

As stated a few days ago [1], the 2.7.2 series died in the
Thunderdome[2], as per our release process.  August has brought about
2.7.3rc1.  This includes all fixes from the 2.7.2 series as well as
several new fixes and enhancements.  This will also be the first
release of the 2.7 (Statler) series, that includes the roll-up fixes
from 2.6.9.


Puppet 2.7.3rc1 is available.  Changelog entries are available below.
More detailed information is available in on our Release Notes page.

Release Notes have been updated:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.3rc1


This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.7.3rc1.tar.gz

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected puppet version of 2.7.3rc1
http://projects.puppetlabs.com/projects/puppet/


2.7.3 merges up all changes in the 2.6.9 release that were unable to be
merged into 2.7.{0,1} due to 2.7 being frozen in release candidate
state.  It also includes changes introduced in the never-released
2.7.2 series of puppet.


CHANGELOG
===
7113448 (#4762) Ensure that clients on the moon can successfully connect.
c8835ad Add document outlining preferred contribution methods
ea0f2bf Revert "Merge branch 'vcsrepo'"
94f0b93 (#8704) Give better errors for invalid fileserver.conf
023d959 (#8690) Accept 'global' options in Puppet Faces
c315da0 Fix #1886 - Add node cleanup capability
7e6fc0d Deprecate RestAuthConfig#allowed? in favor of #check_authorization
6401dfe Fix #6026 - security file should support inline comments
0c385f1 Fix #5010 - Allow leading whitespace in auth.conf
8da0486 Fix #5777 - rule interpolation broke auth.conf CIDR rules
1d4acb5 maint: Suggest where to start troubleshooting SSL error message
fb2ffd6 (#8596) Detect resource alias conflicts when titles do not match
778127d maint: Fix cert app to print help and exit if no subcommand
0366b18 (#7293) Set default format for SSL-related faces.
89c021c (#8418) Fix inspect app to have the correct run_mode
3165364 maint: Adding logging to include environment when source fails
f484851 maint: Add debug logging when the master receives a report
10e05ad (#7266) Move Certificate option validation into face.
ae36003 (#7290) Update indirected Faces to avoid unknown options.
82e5fa9 (#8561, #7290) Implement the option contract fully.
77441be (#8561) Unify validation and modification of action arguments.
69b4e70 (#7290) Fail on unknown options.
6bec2df (#8561) Use canonical names for options to actions.
532c4f3 (#7184) Load the core of obsolete versions of Faces.
2cd3bc4 (#7184) Find actions bound to other versions of Faces.
1e0655e (#7184) Centralize "find action for face" into Puppet::Face
0396611 maint: better error reporting when test fails
395c174 (#7123) Make `find` the default action...
fd6a653 (#7123) Support runtime setting of 'default' on actions.
b75b1c1 (#6787) Add `default_to` for options.
c830ab0 (#6789) Port SSL::CertificateAuthority::Interface to a Face
cc311ad maint: SSL::Inventory.serial should report missing names.
72abe6c (#7204) Consolidate Semantic Versioning code.
d02000b (#8401) Document that --detailed-exitcodes is a bitmask
c4848d2 maint: Fix documentation link for fileserver configuration
b268fb3 (#7144) Update Settings#writesub to convert mode to Fixnum
b82f29c (#7699) Help command should only list options once
4a2f22c (maint) Fix platform dection for RHEL
45b3908 (#4142) Fix module check not to fail when empty metadata.json
ae3ef42 (#7699) - Help should only show options once
5826f73 (#8032) Add containment to create_resources
f6882d6 (#8147) Change default reporturl to match newer Dashboard versions
111a4b5 (#6857) Password disclosure when changing a user's password

[1] 
http://groups.google.com/group/puppet-users/browse_thread/thread/fb68f18b97f39070
[2] 
http://groups.google.com/group/puppet-users/browse_thread/thread/3d703849246bd43f/c98d096d51ed221e

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

[Puppet-dev] Thunderdome on Puppet 2.7.2 RC vs 2.7.3 RC

[Michael Stahnke]

Per our timed-release cycle process[1], we've entered the THUNDERDOME
for 2.7.2rc series (July) vs 2.7.3rc series (August).

Two releases enter; one leaves.

It was determined today that 2.7.3 has won the Thunderdome.  (It was a
gory battle where 2.7.3 kicked 2.7.2 in the face)


So, look for 2.7.3rc1 within the next few days.


[1] 
http://groups.google.com/group/puppet-users/browse_thread/thread/3d703849246bd43f/c98d096d51ed221e

Mike
Release Engineering
Puppet Labs

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

[Puppet-dev] ANNOUNCE: Dashboard 1.2rc5

[Michael Stahnke]

Greetings,

Welcome to another Release Candidate for Puppet Dashboard (number 5).


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2rc5
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html



Highlights of RC5
===
Allow setting of RUBY for the workers on redhat systems

While we are able to set an alternative RUBY path for the dashboard
server this is not possible for the workers.
We now include first the general dashboard sysconfig and afterwards
a (possible) dedicated workers sysconfig file, which could overwrite
the general dashboard settings.
This means that if you would adjust RUBY for the dashboard-server it
would also be used for the workers.
---

   (#8748) Upgrade vendored daemons gem to fix umask on pids

We had version 1.1.0 of the daemons gem because that's what the older
version of delayed_job says it depends on.  However, since that time,
newer versions of daemons have been release with bug fixes, including
setting better permissions on pids and logs and not changing the umask

---
  (#8694) Add backtrace info to DelayedJobFailure

If reports fail to import with DelayedJob a failure entry is created
that has the error message, but did not have the backtrace, which often
is much more helpful for debugging.

This commit adds the backtrace to the UI in an expandable form so that
it doesn't look to spammy on the web page.

---
 Add document outlining preferred contribution methods

We have historically had the preferred contribution process on the
Redmine wiki, however this is not obvious to people that don't already
know it is there.  By adding this document to the repository itself,
it becomes much easier for new contributors to find what the preferred
contribution methods are.

By having the preferred contribution method in the repository also
means that it becomes a "curated" document, which must go through the
same submission/review process that other changes to the repositories
go through.

---
(#8745) Update gitignore to not exclude tmp during tarball creation

When the tarball for the package is composed, the tmp directory is left
out due to gitignore settings. Now the project-level gitignore file does
not reference tmp.  A new gitignore file has been added in
$RAILS_ROOT/tmp to exclude everything below it.


RC5
===
3f88c7f (#8748) Fix my forgetting to add a vendored gem
2f636a9 Allow setting of RUBY for the workers on redhat systems
651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
bf22939 Add document outlining preferred contribution methods
803be4f (#8745) Update gitignore to not exclude tmp during tarball creation

1.2 series



Highlights Include:

* Moved to Apache 2.0 License
* LOTS of UI improvements
* Updated version of Rails
* Now Requires Ruby 1.8.7
* Has Delayed Jobs (puppet-dashboard-workers) for async actions
* Several performance improvements


More Details
===

45338a (#8691) Fix the order of changed and unchanged resources on the
report summary
7653800 Provide clearer error message when report host, kind and time
are not unique
e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
fbe11aa (#8196) Adjust content width based on body classes.
e756c25 (#8196) Add a body class describing sidebar state.
23cbef1 (#8196) Cl

Re: [Puppet-dev] Pulling the trigger on using GitHub Pull Requests for patch submission (and internal development).

[Michael Stahnke]

On Wed, Aug 3, 2011 at 6:54 AM, Dominic Cleal  wrote:
> On 03/08/11 01:57, Jacob Helwig wrote:
>> The tl;dr:
>>
>>   Our new preferred method of contributing changes is via GitHub pull
>>   requests, and all Puppet Labs developers will be submitting their
>>   changes for inclusion into the repository via pull request.
>>
>>   We will still be accepting changes via `rake mail_patches`,
>>   git-format-patch(1) & git-send-email(1), and attaching diffs to
>>   Redmine tickets, though these are not the preferred method.
>
> Is it best for outstanding patches to be resubmitted via pull requests
> to ensure they're tracked and reviewed?

Outstanding patches are still being worked through the normal process.
 Also note that the new process basically still allows for the old
process in its entirety; but now allows for Github pulls as well.  The
FOSS team will have to estimate the duration/backlog on current patch
review.  I know it's better than it was, but that's about it.

Mike

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

[Puppet-dev] Announce: Puppet-dashboard 1.2rc4 Available

[Michael Stahnke]

This a feature release candidate (number 4) of Puppet Dashboard.


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2rc4
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html



Highlights of RC4:
===
---
   Provide clearer error message when report host, kind and time are not unique

The previous error was just:

Host has already been taken

The problem is that host by itself isn't unique, but the error message
would lead you to believe it is.  Instead, mention that the host, kind,
time combo needs to be unique.

---

(#8686) Handle concurrent DelayedJob workers importing for same node

If you didn't have any delayed job workers and submitted multiple
reports for the same node, when you started multiple workers they would
each try to create the same node.  There was no database constraint to
prevent this, and Rails validation was worthless since the workers were
running their own transactions.

By adding the database constraint the insert will fail for workers who
don't create the node first.  Rather than discard the reports and create
an error for those workers, we're retrying the report submission 3
times before putting in a DelayedJobFailure entry.

---

RC4 Log
===
 45338a (#8691) Fix the order of changed and unchanged resources on
the report summary
 7653800 Provide clearer error message when report host, kind and time
are not unique
 e86526f (#8686) Handle concurrent DelayedJob workers importing for same node




1.2 series


Highlights Include:

* Moved to Apache 2.0 License
* LOTS of UI improvements
* Updated version of Rails
* Now Requires Ruby 1.8.7
* Has Delayed Jobs (puppet-dashboard-workers) for async actions
* Several performance improvements


More Details
===

88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
fbe11aa (#8196) Adjust content width based on body classes.
e756c25 (#8196) Add a body class describing sidebar state.
23cbef1 (#8196) Clean up body class manipulation.
3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost
81ec3c0 (#8090) Update .gitignore to ignore plugin files
6f117fc (#8022) Don't fail when installing plugin without `public` directory
07a9407 (#8022) Create a hook for plugins to add items to  in layout
64be352 (#7967) Add default value for read column of delayed_job_failures
240c548 (#7967) Infrastructure for displaying background failures.
8038cce (#7389) Don't auto-start DelayedJob workers.
933ae04 (#7389) Cheaper unique filenames for spooled reports.
b4384eb (#7398) Support externally managed DelayedJob workers.
184e65b (#7689) Rake task to support parallel report POSTing.
2333c08 (#5947) Rename Destroy button to Delete
2fb0ac1 (#7976) Fixed static debug data in view
393970d (#7976) Node filter links in sidebar work in all cases
4ba3d23 (#7398) Configurable DelayedJob worker count.
e839884 (#7938) Delayed import from file, not YAML string.
d24c323 (#7973) Refactor colors for changed/unchanged
58c2b52 (#7398) Use DelayedJob for background processing.
6aefc60 (#7938) Add daemons gem to support DelayedJob
7395369 (#7398) Vendor DelayedJob for background tasks.
05040d9 (#7958) Allow plugins to add top level navigation
c4d2f26 (#7597) Better integration of node summaries
4ad9cbc (#7913) Upgrade rspec and rspec-rails vendored gems
c09b650 (#7913) Fix tap deprecation warning
d88da0e (#7913) Update README to say we only support Ruby 1.8.7
acdc31f (#7913) upgrade will_paginate gem to avoid depre

[Puppet-dev] ANNOUNCE: Puppet 2.7.2rc3 available

[Michael Stahnke]

Puppet 2.7.2rc3 is available.   RC2 was accidentally packaged from the
wrong branch; thus causing some odd regressions and behavior.  I
apologize for that.  This rc corrects that mistake.

New since RC2
===
* Fix an issue where some commits in 2.7.x made their way into
2.7.2rc2 due to a branch confusion issue.  Several odd behaviors seen
in 2.7.2rc2 should now meet expectations.

This release is available for download at:
http://puppetlabs.com/downloads/puppet/puppet-2.7.2rc3.tar.gz

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 2.7.2rc3
http://projects.puppetlabs.com/projects/puppet/

Release notes found at:
https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.2rc3


2.7.2 merges up all changes in the 2.6.9 release that were unable to be
merged into 2.7.{0,1} due to 2.7 being frozen in release candidate
state.

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

Re: [Puppet-dev] Re: [Puppet Users] ANNOUNCE: Puppet Dashboard 1.2rc3 available

[Michael Stahnke]

>
> PS: Everyone who ever again says Debian has outdated Software should
> take a redhat floppy and ...
>

The CentOS guys back-ported 187 to EL 5.   Maybe that will help?

http://centos.karan.org/el5/ruby187/

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

Re: [Puppet-dev] OS 10.7 issues fixed in 2.7.2?

[Michael Stahnke]

On Tue, Jul 26, 2011 at 3:40 PM, Roy Nielsen  wrote:
> Hello,
>
> I was wondering if tickets 6487/8375 was fixed for 2.7.2?  They were for
> 2.6.9, but I don't think they got into the 2.7 branch yet - any idea when
> 2.7 branch will be ready for OS 10.7 (Lion)?  (I didn't see anything in the
> release notes or the tickets themselves that they were being planned for the
> 2.7 branch)
>
The 2.7.2rc2 has these fixes.  8375 is a duplicate of 6487.

 git log | grep 6487
  (#6487) Add some testing for OS X version support in
DirectoryService provider
  (#6487) Directoryservice provider will fail in future OS releases
  (#6487) Add some testing for OS X version support in
DirectoryService provider
  (#6487) Directoryservice provider will fail in future OS releases
  (#6487) Add some testing for OS X version support in
DirectoryService provider
  (#6487) Directoryservice provider will fail in future OS releases
Merge branch
'tickets/2.6.x/6487-help-directoryservice-provider-work-on-future-OSX-versions'
into 2.6.next
* 
tickets/2.6.x/6487-help-directoryservice-provider-work-on-future-OSX-versions:
  (#6487) Add some testing for OS X version support in
DirectoryService provider
  (#6487) Directoryservice provider will fail in future OS releases
 (#6487) Add some testing for OS X version support in
DirectoryService provider
 (#6487) Directoryservice provider will fail in future OS releases


HTH,

Mike

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