ANNOUNCE: Facter 1.5.8rc2

For 40 days and 40 nights Facter wandered in the wilderness sustained
only by the occasional patch and bottle of Kool-Aid. Tanned and happy
Facter 1.5.8rc1 has now emerged from its desert retreat.

1.5.8 is a feature and maintenance release containing a number of fixes,
updates and additional tests.

You can get the release candidate at:

http://reductivelabs.com/downloads/fa...r-1.5.8rc1.tar.gz

Please test and log any bugs to Redmine (http://projects.puppetlabs.com).

CHANGELOG

4398b36  Updated CHANGELOG rake task
e02be1d  [#4156] Updating spec to match Kai's change
bff84c2  [#4156] Applying patch by Kai
b7fe989  [#2330] Update uptime calculation to use /bin/cat
e9a60bc  Facter::Manufacturer - sunos test + simplified regex
be411c0  Facter::Manufacturer - test for SunOS and FreeBSD
67f6604  [#4062] Implement operating system facts for MeeGo
a2bcacd  [#2330] Uptime should not make redundant system calls
ce7bd9f  Refactor rakefile to use spec.ops, separate rcov task
faaa169  Fix #4352 - Support for detecting KVM virtuals on FreeBSD
82286e4  Fix #4352 - Support for detecting virtuals (jails) on FreeBSD
b2c2114  Properly wrapped the windows ipaddress fact in a setcode block.
1bd2ca2  Fixed #3929 - Added user confine to AIX memory facts
8106bc3  Adding HP-UX support to Facter's IP facts
83b3ea6  Fixed #3393 - Updates to Facter for MS Windows
ffcae46  Fixed #3403 - Added fact to query vlans; added spec test
d4b8401  Merged Jos Backus patch to remove requirement for ftools
altogether
73dcbb9  Fixed #2355 read hang on /proc/xen/capabilties on RHEL 4.7
d109def  Fix #1365 - load all facts via cli
6c87917  Fixed failing test introduced by previous commit
c5b8d3b  Fixes #3740 - split dmi output on regex
25bf5c2  Fix virtual unit test on non-linux by stubbing kernel
9a00eae  Fixed #2313 - Somewhat essential hardware facts not available
on OpenBSD, patch included
e19024b  Fixed #2938 - interfaces that don't match ^\w+[.:]?\d+ are
ignored
97879f9  Added support for Slackware in operatingsystem and
operatingsystemrelease
802e6c2  Fixed #3542 - Ruby 1.9: broken unittest, String#each no longer
exists
2f016f3  Fixed #3541 - Ruby 1.9: broken unittest, unexpected invocation:
Process.waitall()
84d3d9f  Fixed #3445 - Facter does not handle solaris branded zones
properly
b5a8de0  Fix for #3411 install.rb should not put "." first in the tmp_dirs
8ea33eb  Fixed #3447 - OVS and OEL not matching in operatingsystemrelease
aeee83c  Fixed #3410 - Warnings in rake spec
8bf8cb5  Fixes #3397 - is_virtual fact does not detect Linux-VServer
62b6773  Add kvm support to virtual fact
dca615c  fixes #2573, #2085, #1291 - fixes domain and fqdn facts
resolution
86447c8  Revert "use popen3 in Resolution.exec"
7750f03  Fix #2341 - stricter handling of dmidecode split
f4269d9  Fix #2746 - add architecture support for GNU/kFreeBSD
50cef83  Fix missing error case
356cf15  Remove whitespace in DMI facts (#3008, #3011)
feecd39  Only ignore IPs starting with 127.
68fc123  Added package signing task
33fb770  use popen3 in Resolution.exec to catch stderr
8109806  introduce a warn mechanism for debugging
b2c1ca5  Add docs to Mac OS X package creation script and clean out old
docs in the preflight
5412eab  Fixed : 2788 - ftools missing in Ruby 1.9
5b95a12  Fixes #2704. Problem finding install.rb three levels up
9aef69e  Removed all ChangeLog

Regards

James Turnbull

Example:

    ./ext/facter-diff 1.5.5 1.5.8rc1

Signed-off-by: Rein Henrichs <rei### @puppetlabs.com>
---
 ext/facter-diff |   73
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 73 insertions(+), 0 deletions(-)
 create mode 100755 ext/facter-diff

diff --git a/ext/facter-diff b/ext/facter-diff
new file mode 100755
index 0000000..361b80b
--- /dev/null
+++ b/ext/facter-diff
@@ -0,0 +1,73 @@
+#!/usr/bin/env sh
+#
+# Output the difference between a facter command run on two different
versions
+# of facter. Uses unified diff format.
+
+OPTIONS_SPEC="\
+facter-diff [options] <rev1> <rev2> [fact]...
+
+Example:
+
+    ./ext/facter-diff 1.5.7 1.0.2
+
+--
+h,help      Display this help"
+
+. "$(git --exec-path)/git-sh-setup"
+eval "$(echo "$OPTIONS_SPEC" | git rev-parse --parseopt -- "$@" || echo
exit $?)"
+trap 'err=$?; cleanup; exit $err' 0
+
+cleanup() {
+  test $origin && git checkout "$origin" &> /dev/null
+}
+
+facter() {
+  ruby -Ilib bin/facter "$@"
+}
+
+log_facter_run() {
+  local ref=$1 && shift
+  local tmpfile=$1 && shift
+
+  git checkout -f "$ref" &> /dev/null ||
+    die "fatal: unable to checkout $ref"
+  facter "$@" > $tmpfile
+}
+
+verify_revision() {
+  git rev-parse --verify --quiet "$1" > /dev/null ||
+    die "fatal: '$1' is not a valid revision"
+}
+
+test $1 = "--" && shift # git rev-parse seems to leave the -- in
+test $# -eq 0 && usage
+
+test $# -gt 1 ||
+  die "fatal: must specify two revisions"
+
+status=$(git status -s)
+test -z "$status" ||
+  die "fatal: $0 cannot be used with a dirty working copy"
+
+origin=$(git name-rev --name-only HEAD)
+test -n "$origin" ||
+  die "fatal: $0 cannot be used unless currently on a branch"
+
+test -x "bin/facter" ||
+  die "fatal: $0 must be run from the project root"
+
+ref1="$1" && shift
+ref2="$1" && shift
+
+verify_revision $ref1
+verify_revision $ref2
+
+tmpfile1="/tmp/$(basename $0).$$.1.tmp"
+tmpfile2="/tmp/$(basename $0).$$.2.tmp"
+
+log_facter_run $ref1 $tmpfile1 $@
+log_facter_run $ref2 $tmpfile2 $@
+
+git checkout -f "$origin" &> /dev/null
+
+diff --label "$ref1" --label "$ref2" -u $tmpfile1 $tmpfile2

Simplify the binary by moving all application specific code into a new
Facter::Application module. This module is then refactored to use
OptionParser and to simplify invocation logic, while maintaining
existing behavior.

Signed-off-by: Rein Henrichs <rei### @puppetlabs.com>
---
 bin/facter                |  135 ++++

Hello everyone,

While discovering puppet, I just figured out that facter does not
recognise my server as Xen HVM DomU, at least not in virtual fact:

# facter
facterversion => 1.5.1
manufacturer => Xen
operatingsystem => Debian
operatingsystemrelease => 5.0.5
productname => HVM domU
puppetversion => 0.25.4
rubyversion => 1.8.7
type => Other
virtual => physical

My dom0 is ok: virtual => xen0

The problem is that I want to use virtual fact to manage grub menu.lst
options related to xen. For the moment, I'm trying to use virtual fact.

A quick look into virtual.rb, and a dirty hack later, I can see my HVM
domU as what they are. Now I wonder to know if I use the right fact ?

Regards,
JB


Here's my diff:
# diff -C 10 /usr/lib/ruby/1.8/facter/virtual.rb
/usr/lib/ruby/1.8/facter/virtual.rb.xen
*** /usr/lib/ruby/1.8/facter/virtual.rb	2010-08-07 14:20:31.000000000
+0200
--- /usr/lib/ruby/1.8/facter/virtual.rb.xen	2010-08-07
14:20:09.000000000 +0200
***************
*** 34,53 ****
--- 34,54 ----
              end
          end

          if result == "physical"
              output = Facter::Util::Resolution.exec('lspci')
              if not output.nil?
                  output.each_line do |p|
                      # --- look for the vmware video card to determine
if it is virtual => vmware.
                      # ---     00:0f.0 VGA compatible controller:
VMware Inc [VMware SVGA II] PCI Display Adapter
                      result = "vmware" if p =~ /VM[wW]are/
+                     result = "xenhvm" if p =~ /XenSource/
                  end
              else
                  output = Facter::Util::Resolution.exec('dmidecode')
                  if not output.nil?
                      output.each_line do |pd|
                          result = "vmware" if pd =~ /VMware|Parallels/
                      end
                  else
                      output = Facter::Util::Resolution.exec('prtdiag')
                      if not output.nil?

Reviewing next branch for RC as discussed, I'm happy with all the
changes up to 6edf3199a212e6b33f9e09edbb3cb34710710326, we should
create a branch with the RC version bump and think about generating
the tarballs, documentation and release notes.

Paul

For the benefit of those running OEL (Oracle Enterprise Linux) or OVS,
be aware that under 2.6.0rc4 facter doesn't properly recognize OEL in
/usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb.  A diff
for a fix is below; probably not the best fix but if you need it work
now, this'll do it for you.

I've already filed a bug:
http://projects.puppetlabs.com/issues/4289

-Jim

*** /usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb.orig
 2010-07-19 12:34:26.000000000 -0700
--- /usr/lib/ruby/site_ruby/1.8/facter/operatingsystemrelease.rb
 2010-07-19 12:33:25.000000000 -0700
***************
*** 1,5 ****
  Facter.add(:operatingsystemrelease) do
!     confine :operatingsystem => %w{CentOS Fedora oel ovs RedHat}
      setcode do
          case Facter.value(:operatingsystem)
          when "CentOS", "RedHat"
--- 1,5 ----
  Facter.add(:operatingsystemrelease) do
!     confine :operatingsystem => %w{CentOS Fedora oel OEL ovs OVS
RedHat}
      setcode do
          case Facter.value(:operatingsystem)
          when "CentOS", "RedHat"
***************
*** 8,15 ****
--- 8,19 ----
              releasefile = "/etc/fedora-release"
          when "oel"
              releasefile = "/etc/enterprise-release"
+         when "OEL"
+             releasefile = "/etc/enterprise-release"
          when "ovs"
              releasefile = "/etc/ovs-release"
+         when "OVS"
+             releasefile = "/etc/ovs-release"
          end
          File::open(releasefile, "r") do |f|
              line = f.readline.chomp

I've attached the first pass of a patch that adds a -t option to
facter to show how long each fact is taking to execute. I've added
basic tests but pointers to anything else that needs testing (and some
examples in the source tree to crib from) would be helpful.

Any feed back is welcome.

  Dean

When Facter returns operatingsystem as "oel" or "ovs", the
operatingsystemrelease fact does not catch these properly, causing an
error.

Specs added to catch failure and case statement updated to catch "oel"
and "ovs" as well as "OEL" and "OVS"

Signed-off-by: Rein Henrichs <rei### @puppetlabs.com>
---
 lib/facter/operatingsystemrelease.rb |    4 +-
 spec/unit/operatingsystemrelease.rb  |   39
++++++++++++++++++++++++++++++++++
 2 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 spec/unit/operatingsystemrelease.rb

diff --git a/lib/facter/operatingsystemrelease.rb
b/lib/facter/operatingsystemrelease.rb
index 30f2989..280208b 100644
--- a/lib/facter/operatingsystemrelease.rb
+++ b/lib/facter/operatingsystemrelease.rb
@@ -8,9 +8,9 @@ Facter.add(:operatingsystemrelease) do
             releasefile = "/etc/fedora-release"
         when "MeeGo"
             releasefile = "/etc/meego-release"
-        when "OEL"
+        when "OEL", "oel"
             releasefile = "/etc/enterprise-release"
-        when "OVS"
+        when "OVS", "ovs"
             releasefile = "/etc/ovs-release"
         end
         File::open(releasefile, "r") do |f|
diff --git a/spec/unit/operatingsystemrelease.rb
b/spec/unit/operatingsystemrelease.rb
new file mode 100644
index 0000000..31d4ae8
--- /dev/null
+++ b/spec/unit/operatingsystemrelease.rb
@@ -0,0 +1,39 @@
+#!/usr/bin/env ruby
+
+require File.dirname(__FILE__) + '/../spec_helper'
+
+require 'facter'
+
+describe "Operating System Release fact" do
+
+    before do
+        Facter.clear
+    end
+
+    after do
+        Facter.clear
+    end
+
+    test_cases = {
+        "CentOS" => "/etc/redhat-release",
+        "RedHat" => "/etc/redhat-release",
+        "Fedora" => "/etc/fedora-release",
+        "MeeGo"  => "/etc/meego-release",
+        "OEL"    => "/etc/enterprise-release",
+        "oel"    => "/etc/enterprise-release",
+        "OVS"    => "/etc/ovs-release",
+        "ovs"    => "/etc/ovs-release"
+    }
+
+    test_cases.each do |system, file|
+        context "with operatingsystem reported as #{system.inspect}" do
+            it "should read the #{file.inspect} file" do
+               
Facter.fact(:operatingsystem).stubs(:value).returns(system)
+
+                File.expects(:open).with(file, "r").at_least(1)
+
+                Facter.fact(:operatingsystemrelease).value
+            end
+        end
+    end
+end

Hi,

I'd like to announce the availability of Commons FileUpload 1.2.2.
This is a binary compatible bug fix release, intended to replace all
previous versions. Binary and source distributions are available from

    http://www.apache.org/dyn/closer.cgi/commons/fileupload

The list of changes, compared to version 1.2.1, is below.

Jochen Wiedmann


- Added a check for file names containing a NULL characters. Such file
names are now triggering an InvalidFileNameException since the file
name cannot be used as provided to create the file since it will be
truncated at the NUL character on most (all?) operating systems. E.g.
a file name like "test.foo0.bar" would result in "test.foo" being
created. Thanks to Daniel Fabian.
- Temporary files have not been deleted, if an error occurred in
FileUploadBase.parseRequest(); Fixes FILEUPLOAD-160. Thanks to Stepan
Koltsov.
- Fixed example in MultipartStream Javadocs. Fixes FILEUPLOAD-158.
Thanks to Stepan Koltsov.
- Ensured, that the ProgressListener is called for all items. Fixes
FILEUPLOAD-157. Thanks to Paul Spurr.
- Made the ProgressNotifier public. Fixes FILEUPLOAD-156.
- Multiple documentation fixes. Fixes FILEUPLOAD-155. Thanks to Jörg
Heinicke.
- Fixed the error message for FileSizeLimitExceededException from "too
many characters" to "too many bytes". Fixes FILEUPLOAD-152. Thanks to
Duzakropka.
- A FileSizeLimitExceededException does now contain the file and field
name of the item, which caused the problem. Fixes FILEUPLOAD-154.

code available at

http://github.com/normanb/couchdb-clucene

builds on windows and linux and I have included a demo that pulls a
json feed from flickr.

This is an initial version, there are areas for improvement.

Where possible it has followed java lucene, the main difference being
that this clucene version returns either a json structure or a string
value from the fulltext design document instead of a new document(),
this is then interpreted by spidermonkey.

Help / suggestions appreciated - I will be working more on this over
the coming weeks.

Many thanks,

Norman

Hi Chris,

I think it would be great if we mentioned libdeltacloud on the
deltacloud.org website. Probably to the Download section under the
"Additional Tools".

If you want do it yourself, feel free to grab the docs repo[1] and send
a patch to the list.

Otherwise, I'll do it this Friday.

Take care,
Thomas

[1]: git://git.fedorahosted.org/git/deltacloud/docs.git/ (the `next`
branch)



On Wed, 2010-07-21 at 16:19 -0400, Chris Lalancette wrote:
 All,
      I'm pleased to announce the release of libdeltacloud v0.3.0.
 libdeltacloud is a C library that wraps the deltacloud REST API in a
 convenient-to-use C/C++ library.  There are a number of significant
changes
 to libdeltacloud compared to previous releases:
 
 - Rename of the project from libdcloudapi to libdeltacloud.  Since
dcloudapi
 didn't really conform to the naming conventions of the rest of the
deltacloud
 project, it has now been renamed to libdeltacloud.  The repository
for the
 code and the name of the RPM package have also been renamed (see
below for
 pointers on where to get it).
 
 - Compatibility with the latest version of deltacloud core.  There
were a few
 recent changes to the deltacloud API that broke compatibility with
earlier
 versions of libdcloudapi.  This release of libdeltacloud fixes those
 incompatibilities up.  Note that libdeltacloud will *only* work
against the
 newest deltacloud API; it is not backwards compatible with the old
API (since
 it was declared unstable anyway, this shouldn't be a huge surprise).
 
 - Much better error reporting.  libdeltacloud now stores detailed
error
 information in per-thread variables, meaning that it is has become
multithread
 safe and gives detailed errors on failures.
 
 The git repository that holds the source code for libdeltacloud is
here:

http://git.fedorahosted.org/git/?p=de...oud.git;a=summary
 
 Until I get this packaged for Fedora proper, pre-compiled RPM
packages for
 Fedora 12 and 13 are here:
 http://people.redhat.com/clalance/libdeltacloud
 
 If you have any questions, problems, concerns, or bugs, please let me
know!
 
 --
 Chris Lalancette
 

* Per #4466, Ruby has trouble reading files in /proc [1]. The
  alternative is to use `bin/cat`.

* Also refactored methods to explicitly redirect standard error to
  /dev/null for *nix and BSD system calls.

  [1] http://blade.nagaokaut.ac.jp/cgi-bin/.../ruby-talk/155745

Signed-off-by: Rein Henrichs <re### @puppetlabs.com>
---
 lib/facter/util/uptime.rb |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/lib/facter/util/uptime.rb b/lib/facter/util/uptime.rb
index f8a17db..353ebf5 100644
--- a/lib/facter/util/uptime.rb
+++ b/lib/facter/util/uptime.rb
@@ -16,20 +16,19 @@ module Facter::Util::Uptime
     private
 
     def self.uptime_proc_uptime
-        if File.exists? uptime_file
-            r = File.read uptime_file
-            r.split(" ").first.to_i
+        if output = `/bin/cat #{uptime_file} 2>/dev/null` and
$?.success?
+            output.chomp.split(" ").first.to_i
         end
     end
 
     def self.uptime_sysctl
-        if (output = `#{uptime_sysctl_cmd}`) and $?.success?
+        if output = `#{uptime_sysctl_cmd} 2>/dev/null` and $?.success?
             compute_uptime(Time.at(output.unpack('L').first))
         end
     end
 
     def self.uptime_who_dash_b
-        if (output = `#{uptime_who_cmd}`) and $?.success?
+        if output = `#{uptime_who_cmd} 2>/dev/null` and $?.success?
             compute_uptime(Time.parse(output))
         end
     end
@@ -43,10 +42,10 @@ module Facter::Util::Uptime
     end
 
     def self.uptime_sysctl_cmd
-        'sysctl -b kern.boottime 2>/dev/null'
+        'sysctl -b kern.boottime'
     end
 
     def self.uptime_who_cmd
-        'who -b 2>/dev/null'
+        'who -b'
     end
 end

The EC2 fact is completely broken at the moment:

* Timeout::Error isn't caught by rescue (due to how it inherits)
* The issue of wrong open semantics outlined here, this is causing hidden
immediate failure
* The fact is going to cause a 2 second wait to every facter run

Whilst the following patch fixes the first two, I'm not sure we want to
take
the timeout hit, we also want to add tests as even simple ruby code can
get
logic errors such as the open().

Signed-off-by: Paul Nasrat <pnas### @googlemail.com>
---
 lib/facter/ec2.rb |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lib/facter/ec2.rb b/lib/facter/ec2.rb
index ef84757..447a4d8 100644
--- a/lib/facter/ec2.rb
+++ b/lib/facter/ec2.rb
@@ -6,8 +6,11 @@ require 'open-uri'
 require 'timeout'
 
 def can_connect?(ip,port,wait_sec=2)
- Timeout::timeout(wait_sec) {open(ip, port)}
+ url = "http://#{ip}:#{port}/"
+ Timeout::timeout(wait_sec) {open(url)}
  return true
+rescue Timeout::Error
+  return false
 rescue
   return false
 end

Welcome back again to the Puppet release cycle with really truly next to
final release candidate 4.

The 2.6.0 release is a major feature release and includes a huge variety
of new features, fixes, updates and enhancements.  These include the
complete cut-over from XMLRPC to the REST API, numerous language
enhancements, a complete rewrite of the events and reporting system, an
internal Ruby DSL, a single binary, Windows support, a new HTTP report
processor, and a myriad of other enhancements.

As a result of the bucket-load of new features and enhancements we also
need lots of help testing it.  Please run up the release candidate in
your test environment or using VMs and test it as extensively as
possible.

We've include release notes below that you can also see at:

http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes

The release candidate is available for download at:

http://puppetlabs.com/downloads/puppe...t-2.6.0rc4.tar.gz

Please note that all final releases of Puppet are signed with the
Puppet Labs key (we'll sign the production release with the new,
improved Puppet Labs key).

See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet

Please test this release candidate and report feedback via the
Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.0rc4.

RELEASE NOTES

Language

Support for parameterised classes

The 2.6.0 release provides an extension to the existing class syntax to
allow parameters to be passed to classes. This brings classes more in
line with definitions, with the significant difference that definitions
have multiple instances whilst classes remain singletons.

To create a class with parameters you can now specify:

class apache($version) {
... class contents ...
}

Classes with parameters are NOT added using the include function but
rather the resulting class can then be included more like a definition:

node webserver {
    class { apache: version => "1.3.13" }
}

Like definitions, you can also specify default parameter values in your
class like so:

class apache($version="1.3.13",$home="/var/www") {
... class contents ...
}

New relationship syntax

You can now specify relationships directly in the language:

File[/foo] -> Service[bar]

Specifies a normal dependency while:

File[/foo] ~> Service[bar]

Specifies a subscription.

You can also do relationship chaining, specifying multiple relationships
on a single line:

File[/foo] -> Package[baz] -> Service[bar]

Note that while it’s confusing, you don’t have to have all of the
arrows
be the same direction:

File[/foo] -> Service[bar] <~ Package[baz]

This can provide some succinctness at the cost of readability.

You can also specify full resources, rather than just resource references:

file { "/foo": ensure => present } -> package { bar: ensure =>
installed }

But wait! There’s more! You can also specify a subscription on either
side of the relationship marker:

yumrepo { foo: .... }
package { bar: provider => yum, ... }
Yumrepo <| |> -> Package <| provider == yum |>

This, finally, provides easy many to many relationships in Puppet, but
it also opens the door to massive dependency cycles. This last feature
is a very powerful stick, and you can considerably hurt yourself with it.

Run Stages

Run Stages are a way for you to provide coarse-grained ordering in your
manifests without having to specify relationships to every resource you
want in a given order. It’s most useful for setup work that needs to be
done before the vast majority of your catalog even works – things like
configuring yum repositories so your package installs work.

Run Stages are currently (intentionally) a bit limited – you can only
put entire classes into a run stage, you can’t put individual resources
there.

There’s a main stage that resources all exist in by default; if you
don’t use run stages, everything’s in this, but it doesn’t matter to
you. You can define new stages via the new stage resource type:

stage { pre: before => Stage[main] }

Here we’ve used the before metaparameter but you could also use after,
require, etc to establish the necessary relationships between stages.

Now you just specify that your class belongs in your new run stage:

class yum { ... }
class redhat {
  ...
  class { yum: stage => pre }
}

This will make sure that all of the resources in the yum are applied
before the main stage is applied.

Note that we’re using the new parameterized classes here – this is
necessary because of the class-level limitations of Run Stages. These
limitations are present because of the complication of trying to
untangle resource dependencies across stage boundaries if we allowed
arbitrary resources to specify stages.

On a related note, if you specify a stage for a given class, you should
specify as few as possible explicit relationships to or from that class.
Otherwise you risk a greater chance of dependency cycles.

This can all be visualized relatively easily using the —graph option to
puppetd and opening the graphs in OmniGraffle or GraphViz.

Specifying the ordering of Run Stages also works much better when
specified using the new relationship syntax, too:

stage { [pre, post]: }
Stage[pre] -> Stage[main] -> Stage[post]

This way it’s very easy to see at a glance exactly how the stages are
ordered.

Support for hashes in the DSL

This brings a new container syntax to the Puppet DSL: hashes.

Hashes are defined like Ruby Hashes:

{ key1 => val1, ... }

The Hash keys are strings but hash values can be any possible right
values admitted in Puppet DSL (i.e. a function call or a variable)

Currently it is possible:

* to assign hashes to a variable
$myhash = { key1 => "myval", key2 => $b }

* to access hash members (recursively) from a variable containing a hash
(works for array too):

$myhash = { key => { subkey => "b" }}
notice($myhash[key][subkey]]

* to use hash member access as resource title

* to use hash in default definition parameter or resource parameter if
the type supports it (known for the moment).

It is not possible to use an hash as a resource title. This might be
possible once we support compound resource title.

Support for an elsif syntax

Allows use of an elsif construct:

  if $server == 'mongrel' {
      include mongrel
  } elsif $server == 'nginx' {
      include nginx
  } else {
      include thin
  }

Case and Selectors now support undef

The case and selector statements now support the undef syntax (see #2818).

Pure Ruby Manifests

Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom
language. That is, you can now have Ruby programs along side your Puppet
manifests. As is our custom, it’s a limited first version, but it covers
most of the specification functionality of the current language. For
instance, here’s a simple ssh class:

hostclass :ssh do
  package "ssh", :ensure => :present
  file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config",
:require => "Package[ssh]"
  service :sshd, :ensure => :running, :require =>
"File[/etc/ssh/sshd_config]"
end

Similar to the ‘hostclass’ construct here, you can specify defined
resource types:

define "apache::vhost", :ip, :docroot, :modperl => false do
  file "/etc/apache2/sites-enabled/#{@name}.conf", :content =>
template("apache/vhost.erb")
end

As you can see from this code, the parameters for the resources become
instance variables inside of the defined resource types (and classes,
now that we support parameterized classes).

We can do nodes, too:

node “mynode” do
  include “apache”
end

Ruby has become a first-class citizen alongside the existing external
DSL. That means anywhere you can put a manifest, you should be able to
put Ruby code and have it behave equivalently. So, the ‘ssh’ class
above
could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost
type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the
node should probably be in your ‘site.pp’ file.

You can also apply Ruby manifests directly with puppet:

puppet -e mystuff.rb

Note that the Ruby support does not yet cover all of the functionality
in Puppet’s language. For instance, there is not yet support for
overrides or defaults, nor for resource collections. Virtual and
exported resources are done using a separate method:

virtual file("/my/file", :content => "something")

All of the standard functions are also pulled into Ruby and should work
fine — e.g., ‘include’, ‘template’, and ‘require’.

Stored Configuration

Support is now added for using Oracle databases as a back-end for your
stored configuration.

Facts

There are three new facts available in manifests:

$clientcert – the name of the client certificate
$module_name – the name of the current module (see #1545)
$caller_module_name – the name of the calling module (see #1545)

In addition all puppet.conf configuration items are now available as
facts in your manifests. These can be accessed using the structure:

$settings::setting_name

Where setting_name is the name of the configuration option you’d like to
retrieve.

Types and Providers

A new provider for pkg has been added to support Solaris and OpenSolaris
(pkgadd).

A new package provider has been added to support AIX package management.

The augeas type has added the ‘incl’ and ‘lens’ parameters. These
parameters allow loading a file anywhere on the filesystem; using them
also greatly speeds up processing the resource.

Binaries and Configuration

Single Binary

Puppet is now available as a single binary with sub-arguments for the
functions previously provided by the seperate binaries (the existing
binaries remain for backwards compatibility). This includes renaming
several Puppet functions to better fit an overall model.

List of binary changes

puppetmasterd –> puppet master
puppetd –> puppet agent
puppet –> puppet apply
puppetca –> puppet cert
ralsh –> puppet resource
puppetrun –> puppet kick
puppetqd –> puppet queue
filebucket –> puppet filebucket
puppetdoc –> puppet doc
pi –> puppet describe

This also results in a change in the puppet.conf configuration file.
The sections, previously things like [puppetd], now should be renamed to
match the new binary names.  So [puppetd] becomes [agent].  You will be
prompted to do this when you start Puppet with a log message for each
section that needs to be renamed.  This is merely a warning - existing
configuration file will work unchanged.

New options

A new option is available, ca_name, to specify the name to use for the
Certificate Authority certificate. It defaults to the value of the
certname option (see http://projects.reductivelabs.com/issues/1507).

A new option, dbconnections, is now available that specifies a limit for
the number of database connections made to remote databases (postgreSQL,
MySQL).

A new option, dbport, is now available that specifies the database port
for remote database connections.

There’s also a new option/feature that lets the puppet client use HTTP
compression (—http_compression):

Allow http compression in REST communication with the master. This
setting might improve performance for agent –> master communications
over slow WANs. Your puppetmaster needs to support compression (usually
by activating some settings in a reverse-proxy in front of the
puppetmaster, which rules out webrick).

It is harmless to activate this settings if your master doesn’t support
compression, but if it supports it, this setting might reduce on
high-speed LANs.

Binary changes

The puppetd (or puppet agent) binary now supports the
--detailed-exitcodes option available in the puppet binary.

Certificates cleaned with puppetca (or puppet cert) are now also revoked.

The puppetca (puppet cert) and puppetd (puppet agent) binaries now have
support for certificate fingerprinting and support for specifying digest
algorithms. To display the fingerprint of a client certificate use:

$ puppetd --fingerprint

or

$ puppet agent --fingerprint

To specify a particular digest algorithm use --digest DIGESTNAME.

To fingerprint a certificate with puppetca use:

$ puppetca --fingerprint host.example.com

or

$ puppet cert --fingerprint host.example.com

Also supported is the --digest option.

The puppetdoc binary now documents inheritance between nodes, shows
classes added via the require function and resources added via the
realize function.

Functions

The regsubst function now takes arrays as input (see #2491).

Reports

There is a new report type called http. If you specify:

reports = http

Then the new report processor will make a HTTP POST of the report in
YAML format to a specified URL. By default this URL is the report import
URL for a local Puppet Dashboard installation. You can override this
with the new reporturl setting.

reports = http
reporturl = http://yoururl/post/

CHANGELOG since RC3

cf597d7  [#4233] Ruby regexps are not multiline by default, but Resource
titles can be multilined6cbb21  Fix for #4234 -- ruby DSL fails on
second resource
4822de3  Fix for #4236 -- Only interpolate $ if followed by a variable
b509032  Fix #4238 - if should match undef as ''
8c8c146  Minimal fix for #4243 -- import isn't thread safe
d319da4  [#4247] storeconfigs was calling Puppet::Parser::Resource.new
with the wrong arguments
9f91540  [#4256] External nodes parameters can now be assigned to nodes
680dd1a  Fix for #4257 -- problems resolving ::-prefixed classes
6e07a19  Fix #4262 - Puppetmaster used to log compilation time
5b68afe  Fix for #4255 -- misleading diagnostic message
dd03ac9  Partial fix for #4278 -- the performance aspects
4ce33fd  Fixed #4249 - Updated SUSE packaging specifications
91185c6  New man pages for 2.6.0
1cda7c5  Fixes errant Trac references in documentation

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

In the long Puppet tradition of fast releases and agile iteration comes
the 2.6.1 release!

The second release candidate is now available and is a maintenance
release in the 2.6.x branch.

It contains a number of functional and performance enhancements
including preliminary support for running Puppet under JRuby (thanks
Brice!).

We've include release notes below that you can also see at:

http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes

The release candidate is available for download at:

http://puppetlabs.com/downloads/puppe...t-2.6.1rc2.tar.gz

Please note that all final releases of Puppet are signed with the
Puppet Labs key.

See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet

Please test this release candidate and report feedback via the
Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.1rc2.

RELEASE NOTES

Added R.I. Pienaar's extlookup function (see release notes for
documentation).  We'll add JSON and YAML back-ends to the CSV back-ends
in future releases.

Added preliminary JRuby support

Added ext/puppet-load - a tool for testing master compilation speeds

Added md5 hash function

Migration of internal Restructured Text Documentation to Markdown

Minor supporting fixes including updated VIM syntax, SuSE packaging,
Passenger configuration and Red Hat Spec file amongst others.

CHANGELOG since 2.6.0

252c9b8  Further RST to Markdown fixes for types, values, tests
1157e8d  Updated all types to Markdown output
fef8800  Updated reference output to generate valid Markdown
79e0a2e  Reformatting documentation from RST to MarkDown (#4509)
Signed-off-by: Jes Fraser <j### @gadg
et.geek.nz>
62435e5  Rewrote functions documentation to Markdown
e4b2aa6  Removed legacy Trac code
8ddea2a  Maint.  Passenger fix broke a test
f43e87b  Fix for #4476 -- rails calling yaml internals
a23d80a  Fixes #4485 -- single quoted strings should not treat \n as new
line
8e31b52  Passenger needs HTTP headers values to be string
037bb32  [#4404] Remove requirement for source on Parser::Resource::Param
0e4bc62  [#4364] Fix failing spec due to incorrect loglevel
3a6ca54  Fix #4458 - Do not dump the whole environment when instances
can't be found
d909827  Fix for #4465 -- earlier "feature" patch broke ldap
47005aa  Maint -- tests need to respect RFC-952
6aac8f0  [#4467] Make Puppet Master respect facts_terminus settings
1cba9a7  added md5 support as requested in
http://serverfault.com/questions/1661...md5-sum-of-string
1dfd2b6  [#4381] extlookup shouldn't trigger reparses of .pp files
be2b1f3  [#4370] Fixes extlookup precedence getting overwritten between
runs
03808fd  Fixed #4364 - Reduced audit msg from info to debug
539b57c  [#4347] run_mode was colliding with --mode for "puppet doc"
1faebdd  [#4423] repair parameterized class instantiation
37568bd  [#4423] class { shouldn't get stored on the namespace stack
449315a  [#4397]+[#4344] Move type-name resolution out of
Puppet::Resource into the AST resources.
daa801b  [#4344] Temporary fix to stop agent from importing modules
00ebf01  [#4344] Fix for failing templates when module name matches file
in local dir.
e32320e  [#4336] "reportdir" was in the wrong section
0f9672a  Fixed #4311 - Typo in defaults.rb
f54d843  Fix #4461 - attempt to fix another performance issue
2c21fae  Fix for #4300 Solaris svc files need new pid filenames
83c2419  [#4284] Fix failing specs run as root due to missing puppet group
8237f68  [#4242] Fixed (removed) a broken unit test
d5ad0fb  Removed eventual documentation line ... eventually came
871e6fd  Fixed #4368 - Updated clean stored configs ext script for new
config sections
cb64477  Updated version to 2.6.1
bdfcac5  Update Red Hat spec file for 2.6.0
9f08e7c  Feature: puppet-load - a tool to stress-test master compilation
ef9a4a6  Fix #4245 - default insertion of ACL is not thread safe
4065e81  Fix race condition in rack autoloading of request/response
3163932  Fix #4244 - Cached Attributes is not thread safe
7d42f77  JRuby doesn't implement Process.maxgroups
760e418  Fix #4349 - Parsing with ignoreimport=true was always loading
site.pp
67bdf89  Fix #4348 - Puppet doc single manifest broken
13c71b9  extlookup() is a builtin
d38e522  [#4333] old optparse doesn't support default_argv=
86b0882  Fixed #4326 - Updated SUSE packaging
03313b8  Fix #4319 - source file url sent to the master is invalid
ac3a0d2  vim: highlight default parameters in definition/classes
be2141a  vim: match collected resources.
c047c8d  vim: added elsif
9569136  Fix for 4314 -- Need to allow '-' in class name for refs
636079f  Fixed #4304 - Changed logging level for auto import message
000fd1e  Fix for #4303 -- reverting to old escaping in '-strings
1d494a3  Tweak to fix for #4302--dangling ref to known_resource_types
2383050  Fix #4302 - Compilation speed regression compared to 2.6
63ec207  Minimal fix for #4297, with notes for follow-up
7ad7eb1  Fix #4286 - rename puppetdoc global module  to __site__
28bb195  Fixed yumrepo type deprecation wanring `
067a46d  Temporary tweak to tests for #4242
9778f2a  [#4242] Fixed recursion due to parents including their children
59a23d6  Fix for #3382 -- Empty classes as graph placeholders
865282a  Fixed example config.ru
a0a63c3  Fixed network and indirection reference
64386cf  Fixed Indirection reference

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

So you probably thought the Dashboard didn't love you anymore ... that
we'd forgotten about you and we're very sorry for that.  But we're
trying to make up for it ... starting with the Puppet Dashboard 1.0.1
release.

The 1.0.1 release is a maintenance release that fixes a lot of the
outstanding bugs and issues with the 1.0 release.  We're planning a 1.1
release in the near future that will add additional features (you can
see the Roadmap at http://projects.puppetlabs.com/versions/show/48)

http://puppetlabs.com/downloads/dashb...shboard-1.0.1.tgz

Fixed in this release is:

* Fixed exception in display of audit log messages
* Fixed deletion of nodes to remove their reports, eliminating orphans
* Fixed exception on node group pages if they had associated classes or
groups
* Fixed unwanted pagination of JSON and YAML results
* Fixed reporting of successful and failed nodes
* Added deletion of single reports
* Added labels and placeholders to form fields
* Added local copies of all JavaScript files
* Added run status chart to node list pages (all, successful, failed)
* Added searching to node, class and group index pages
* Added tooltips to node and report status indicators
* Improved README's installation and configuration instructions
* Improved sidebar with links to classes and groups, added it to homepage
* Improved tabular display of nodes, groups and classes
* Removed empty reports.css to make packagers happy
* Removed loading of seed data by default
* Updated UI with status icons, improved typography and spacing, more
noticeable buttons
* Updated packaging information for DEB and RPM

New packages are also available - see the following email.

Regards

James Turnbull

 OK, will start filing bugs right now..


First bug filed, still 2 more questions before I will file more bugs
since I'm not to sure it's by design or a bug.

1) Do external nodes don't accept parameters anymore? (Not a big deal
for us since we are deprecating those anyway but still different
behavior)

Master error:
err: Failed when searching for node cs-ops001b.intern.marktplaats.nl:
undefined method `parameters=' for #<Puppet::Node:0xb6f2b8ac>

Client error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed when searching for node
cs-ops001b.intern.marktplaats.nl: undefined method `parameters=' for
#<Puppet::Node:0xb6f2b8ac>
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Stripped YAML Output:
--- %YAML:1.0
"classes": ["cs-ops"]
"parameters":
  "cmdb_generated": 1
  "company": "CustomerSupport"
  "vendor": "Dell"

2) In the output of the client when using puppetd --test I see more
output then previous versions, for example:
cs-ops001b:/home/seedpimp/rc3# puppetd --test
info: Retrieving plugin
info: /File[/var/lib/puppet/lib]: Setting mode to 493
info: /File[/var/lib/puppet/lib]: Storing newly-audited value  for content
info: /File[/var/lib/puppet/lib/facter]: Setting mode to 493
info: /File[/var/lib/puppet/lib/facter/conterm.rb]: Setting mode to 420
info: /File[/var/lib/puppet/lib/facter/conterm.rb]: Setting content to
{md5}2d189bceaac522ae1f78d171b8e45531
info: Loading facts in conterm
info: Loading facts in conterm
info: Caching catalog for cs-ops001b.intern.marktplaats.nl
info: Applying configuration version 'ref="refs/heads/master"
commit=212f99a4bce8f2b9edc5254d05d16573a2a84057'
info: /Stage[main]/Nginx/File[/etc/nginx/nginx.conf]: Setting content
to {md5}481ca4ffd65e9c8ae3268b38cfaabfa2
info: /Stage[main]/Nginx/File[/etc/nginx/cert.key]: Setting content to
{md5}9351a9b772c885c8e295541fe11a1c04
info: /Stage[main]/Nginx/File[/etc/nginx/cert.pem]: Setting content to
{md5}48bad668bd52b934aaa7be007be55ead
info: /Stage[main]/Nginx/File[/etc/nginx/sites-available/nginx_status]:
Setting content to {md5}9b3770d588ff756612471634ecf7c1e2
info: /Stage[main]/Cacti/File[/var/cache/debconf/cacti.seed]: Setting
content to {md5}71d829ca1c120c8c98a45299941f6af6
info: /Stage[main]/Nscd/File[/etc/nscd.conf]: Setting content to
{md5}2e06eeb94b8fe8085d8cbd0af118f93e
info: /Stage[main]/Nginx/File[/etc/nginx/sites-available/default]:
Setting content to {md5}e732b889d790c1000c3a1c1c39be000

Those Setting content to lines keep returning every run, and are
exactly the same.

Welcome back again to the Puppet release cycle with the just out of the
gate release candidate 3.

The 2.6.0 release is a major feature release and includes a huge variety
of new features, fixes, updates and enhancements.  These include the
complete cut-over from XMLRPC to the REST API, numerous language
enhancements, a complete rewrite of the events and reporting system, an
internal Ruby DSL, a single binary, Windows support, a new HTTP report
processor, and a myriad of other enhancements.

As a result of the bucket-load of new features and enhancements we also
need lots of help testing it.  Please run up the release candidate in
your test environment or using VMs and test it as extensively as
possible.

We've include release notes below that you can also see at:

http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes

The release candidate is available for download at:

http://puppetlabs.com/downloads/puppe...t-2.6.0rc3.tar.gz

Please note that all final releases of Puppet are signed with the
Puppet Labs key (we'll sign the production release with the new,
improved Puppet Labs key).

See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet

Please test this release candidate and report feedback via the
Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.0rc3.

RELEASE NOTES

Language

Support for parameterised classes

The 2.6.0 release provides an extension to the existing class syntax to
allow parameters to be passed to classes. This brings classes more in
line with definitions, with the significant difference that definitions
have multiple instances whilst classes remain singletons.

To create a class with parameters you can now specify:

class apache($version) {
... class contents ...
}

Classes with parameters are NOT added using the include function but
rather the resulting class can then be included more like a definition:

node webserver {
    class { apache: version => "1.3.13" }
}

Like definitions, you can also specify default parameter values in your
class like so:

class apache($version="1.3.13",$home="/var/www") {
... class contents ...
}

New relationship syntax

You can now specify relationships directly in the language:

File[/foo] -> Service[bar]

Specifies a normal dependency while:

File[/foo] ~> Service[bar]

Specifies a subscription.

You can also do relationship chaining, specifying multiple relationships
on a single line:

File[/foo] -> Package[baz] -> Service[bar]

Note that while it’s confusing, you don’t have to have all of the
arrows
be the same direction:

File[/foo] -> Service[bar] <~ Package[baz]

This can provide some succinctness at the cost of readability.

You can also specify full resources, rather than just resource references:

file { "/foo": ensure => present } -> package { bar: ensure =>
installed }

But wait! There’s more! You can also specify a subscription on either
side of the relationship marker:

yumrepo { foo: .... }
package { bar: provider => yum, ... }
Yumrepo <| |> -> Package <| provider == yum |>

This, finally, provides easy many to many relationships in Puppet, but
it also opens the door to massive dependency cycles. This last feature
is a very powerful stick, and you can considerably hurt yourself with it.

Run Stages

Run Stages are a way for you to provide coarse-grained ordering in your
manifests without having to specify relationships to every resource you
want in a given order. It’s most useful for setup work that needs to be
done before the vast majority of your catalog even works – things like
configuring yum repositories so your package installs work.

Run Stages are currently (intentionally) a bit limited – you can only
put entire classes into a run stage, you can’t put individual resources
there.

There’s a main stage that resources all exist in by default; if you
don’t use run stages, everything’s in this, but it doesn’t matter to
you. You can define new stages via the new stage resource type:

stage { pre: before => Stage[main] }

Here we’ve used the before metaparameter but you could also use after,
require, etc to establish the necessary relationships between stages.

Now you just specify that your class belongs in your new run stage:

class yum { ... }
class redhat {
  ...
  class { yum: stage => pre }
}

This will make sure that all of the resources in the yum are applied
before the main stage is applied.

Note that we’re using the new parameterized classes here – this is
necessary because of the class-level limitations of Run Stages. These
limitations are present because of the complication of trying to
untangle resource dependencies across stage boundaries if we allowed
arbitrary resources to specify stages.

On a related note, if you specify a stage for a given class, you should
specify as few as possible explicit relationships to or from that class.
Otherwise you risk a greater chance of dependency cycles.

This can all be visualized relatively easily using the —graph option to
puppetd and opening the graphs in OmniGraffle or GraphViz.

Specifying the ordering of Run Stages also works much better when
specified using the new relationship syntax, too:

stage { [pre, post]: }
Stage[pre] -> Stage[main] -> Stage[post]

This way it’s very easy to see at a glance exactly how the stages are
ordered.

Support for hashes in the DSL

This brings a new container syntax to the Puppet DSL: hashes.

Hashes are defined like Ruby Hashes:

{ key1 => val1, ... }

The Hash keys are strings but hash values can be any possible right
values admitted in Puppet DSL (i.e. a function call or a variable)

Currently it is possible:

* to assign hashes to a variable
$myhash = { key1 => "myval", key2 => $b }

* to access hash members (recursively) from a variable containing a hash
(works for array too):

$myhash = { key => { subkey => "b" }}
notice($myhash[key][subkey]]

* to use hash member access as resource title

* to use hash in default definition parameter or resource parameter if
the type supports it (known for the moment).

It is not possible to use an hash as a resource title. This might be
possible once we support compound resource title.

Support for an elsif syntax

Allows use of an elsif construct:

  if $server == 'mongrel' {
      include mongrel
  } elsif $server == 'nginx' {
      include nginx
  } else {
      include thin
  }

Case and Selectors now support undef

The case and selector statements now support the undef syntax (see #2818).

Pure Ruby Manifests

Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom
language. That is, you can now have Ruby programs along side your Puppet
manifests. As is our custom, it’s a limited first version, but it covers
most of the specification functionality of the current language. For
instance, here’s a simple ssh class:

hostclass :ssh do
  package "ssh", :ensure => :present
  file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config",
:require => "Package[ssh]"
  service :sshd, :ensure => :running, :require =>
"File[/etc/ssh/sshd_config]"
end

Similar to the ‘hostclass’ construct here, you can specify defined
resource types:

define "apache::vhost", :ip, :docroot, :modperl => false do
  file "/etc/apache2/sites-enabled/#{@name}.conf", :content =>
template("apache/vhost.erb")
end

As you can see from this code, the parameters for the resources become
instance variables inside of the defined resource types (and classes,
now that we support parameterized classes).

We can do nodes, too:

node “mynode” do
  include “apache”
end

Ruby has become a first-class citizen alongside the existing external
DSL. That means anywhere you can put a manifest, you should be able to
put Ruby code and have it behave equivalently. So, the ‘ssh’ class
above
could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost
type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the
node should probably be in your ‘site.pp’ file.

You can also apply Ruby manifests directly with puppet:

puppet -e mystuff.rb

Note that the Ruby support does not yet cover all of the functionality
in Puppet’s language. For instance, there is not yet support for
overrides or defaults, nor for resource collections. Virtual and
exported resources are done using a separate method:

virtual file("/my/file", :content => "something")

All of the standard functions are also pulled into Ruby and should work
fine — e.g., ‘include’, ‘template’, and ‘require’.

Stored Configuration

Support is now added for using Oracle databases as a back-end for your
stored configuration.

Facts

There are three new facts available in manifests:

$clientcert – the name of the client certificate
$module_name – the name of the current module (see #1545)
$caller_module_name – the name of the calling module (see #1545)

In addition all puppet.conf configuration items are now available as
facts in your manifests. These can be accessed using the structure:

$settings::setting_name

Where setting_name is the name of the configuration option you’d like to
retrieve.

Types and Providers

A new provider for pkg has been added to support Solaris and OpenSolaris
(pkgadd).

A new package provider has been added to support AIX package management.

The augeas type has added the ‘incl’ and ‘lens’ parameters. These
parameters allow loading a file anywhere on the filesystem; using them
also greatly speeds up processing the resource.

Binaries and Configuration

Single Binary

Puppet is now available as a single binary with sub-arguments for the
functions previously provided by the seperate binaries (the existing
binaries remain for backwards compatibility). This includes renaming
several Puppet functions to better fit an overall model.

List of binary changes

puppetmasterd –> puppet master
puppetd –> puppet agent
puppet –> puppet apply
puppetca –> puppet cert
ralsh –> puppet resource
puppetrun –> puppet kick
puppetqd –> puppet queue
filebucket –> puppet filebucket
puppetdoc –> puppet doc
pi –> puppet describe

This also results in a change in the puppet.conf configuration file.
The sections, previously things like [puppetd], now should be renamed to
match the new binary names.  So [puppetd] becomes [agent].  You will be
prompted to do this when you start Puppet with a log message for each
section that needs to be renamed.  This is merely a warning - existing
configuration file will work unchanged.

New options

A new option is available, ca_name, to specify the name to use for the
Certificate Authority certificate. It defaults to the value of the
certname option (see http://projects.reductivelabs.com/issues/1507).

A new option, dbconnections, is now available that specifies a limit for
the number of database connections made to remote databases (postgreSQL,
MySQL).

A new option, dbport, is now available that specifies the database port
for remote database connections.

There’s also a new option/feature that lets the puppet client use HTTP
compression (—http_compression):

Allow http compression in REST communication with the master. This
setting might improve performance for agent –> master communications
over slow WANs. Your puppetmaster needs to support compression (usually
by activating some settings in a reverse-proxy in front of the
puppetmaster, which rules out webrick).

It is harmless to activate this settings if your master doesn’t support
compression, but if it supports it, this setting might reduce on
high-speed LANs.

Binary changes

The puppetd (or puppet agent) binary now supports the
--detailed-exitcodes option available in the puppet binary.

Certificates cleaned with puppetca (or puppet cert) are now also revoked.

The puppetca (puppet cert) and puppetd (puppet agent) binaries now have
support for certificate fingerprinting and support for specifying digest
algorithms. To display the fingerprint of a client certificate use:

$ puppetd --fingerprint

or

$ puppet agent --fingerprint

To specify a particular digest algorithm use --digest DIGESTNAME.

To fingerprint a certificate with puppetca use:

$ puppetca --fingerprint host.example.com

or

$ puppet cert --fingerprint host.example.com

Also supported is the --digest option.

The puppetdoc binary now documents inheritance between nodes, shows
classes added via the require function and resources added via the
realize function.

Functions

The regsubst function now takes arrays as input (see #2491).

Reports

There is a new report type called http. If you specify:

reports = http

Then the new report processor will make a HTTP POST of the report in
YAML format to a specified URL. By default this URL is the report import
URL for a local Puppet Dashboard installation. You can override this
with the new reporturl setting.

reports = http
reporturl = http://yoururl/post/

CHANGELOG since RC2

9df87e9  [#4219] Install misses command_line dir, puppet $app --help fails
0422852  conf/redhat: Consistently pass pidfile option to daemon,
killproc, and status
63bf037  conf/redhat: Update conf/init files for single binary
f72741f  conf/redhat: Rebase rundir-perms patch
793d7b7  [#4213] -o option for setting onetime now works properly
2edf7fe  [#3656] Serializing arrays of references
27d5a47  [#4215] Have rundir depend on vardir
06cc552  Fix for #4220 -- modules not implicitly loading their init files

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

Welcome back again to the Puppet release cycle with the long-awaited
eleventy times better RC2 release.

The 2.6.0 release is a major feature release and includes a huge variety
of new features, fixes, updates and enhancements.  These include the
complete cut-over from XMLRPC to the REST API, numerous language
enhancements, a complete rewrite of the events and reporting system, an
internal Ruby DSL, a single binary, Windows support, a new HTTP report
processor, and a
myriad of other enhancements.

As a result of the bucket-load of new features and enhancements we also
need lots of help testing it.  Please run up the release candidate in
your test environment or using VMs and test it as extensively as
possible.

We've include release notes below that you can also see at:

http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...iki/Release_Notes

The release candidate is available for download at:

http://puppetlabs.com/downloads/puppe...t-2.6.0rc2.tar.gz

Please note that all final releases of Puppet are signed with the
Puppet Labs key (we'll sign the production release with the new,
improved Puppet Labs key).

See the Verifying Puppet Download section at
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet" rel="nofollow" target="_blank">http://projects.puppetlabs.com/projec...ownloading_Puppet

Please test this release candidate and report feedback via the
Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.0rc2.

RELEASE NOTES

Language

Support for parameterised classes

The 2.6.0 release provides an extension to the existing class syntax to
allow parameters to be passed to classes. This brings classes more in
line with definitions, with the significant difference that definitions
have multiple instances whilst classes remain singletons.

To create a class with parameters you can now specify:

class apache($version) {
... class contents ...
}

Classes with parameters are NOT added using the include function but
rather the resulting class can then be included more like a definition:

node webserver {
    class { apache: version => "1.3.13" }
}

Like definitions, you can also specify default parameter values in your
class like so:

class apache($version="1.3.13",$home="/var/www") {
... class contents ...
}

New relationship syntax

You can now specify relationships directly in the language:

File[/foo] -> Service[bar]

Specifies a normal dependency while:

File[/foo] ~> Service[bar]

Specifies a subscription.

You can also do relationship chaining, specifying multiple relationships
on a single line:

File[/foo] -> Package[baz] -> Service[bar]

Note that while it’s confusing, you don’t have to have all of the
arrows
be the same direction:

File[/foo] -> Service[bar] <~ Package[baz]

This can provide some succinctness at the cost of readability.

You can also specify full resources, rather than just resource references:

file { "/foo": ensure => present } -> package { bar: ensure =>
installed }

But wait! There’s more! You can also specify a subscription on either
side of the relationship marker:

yumrepo { foo: .... }
package { bar: provider => yum, ... }
Yumrepo <| |> -> Package <| provider == yum |>

This, finally, provides easy many to many relationships in Puppet, but
it also opens the door to massive dependency cycles. This last feature
is a very powerful stick, and you can considerably hurt yourself with it.

Run Stages

Run Stages are a way for you to provide coarse-grained ordering in your
manifests without having to specify relationships to every resource you
want in a given order. It’s most useful for setup work that needs to be
done before the vast majority of your catalog even works – things like
configuring yum repositories so your package installs work.

Run Stages are currently (intentionally) a bit limited – you can only
put entire classes into a run stage, you can’t put individual resources
there.

There’s a main stage that resources all exist in by default; if you
don’t use run stages, everything’s in this, but it doesn’t matter to
you. You can define new stages via the new stage resource type:

stage { pre: before => Stage[main] }

Here we’ve used the before metaparameter but you could also use after,
require, etc to establish the necessary relationships between stages.

Now you just specify that your class belongs in your new run stage:

class yum { ... }
class redhat {
  ...
  class { yum: stage => pre }
}

This will make sure that all of the resources in the yum are applied
before the main stage is applied.

Note that we’re using the new parameterized classes here – this is
necessary because of the class-level limitations of Run Stages. These
limitations are present because of the complication of trying to
untangle resource dependencies across stage boundaries if we allowed
arbitrary resources to specify stages.

On a related note, if you specify a stage for a given class, you should
specify as few as possible explicit relationships to or from that class.
Otherwise you risk a greater chance of dependency cycles.

This can all be visualized relatively easily using the —graph option to
puppetd and opening the graphs in OmniGraffle or GraphViz.

Specifying the ordering of Run Stages also works much better when
specified using the new relationship syntax, too:

stage { [pre, post]: }
Stage[pre] -> Stage[main] -> Stage[post]

This way it’s very easy to see at a glance exactly how the stages are
ordered.

Support for hashes in the DSL

This brings a new container syntax to the Puppet DSL: hashes.

Hashes are defined like Ruby Hashes:

{ key1 => val1, ... }

The Hash keys are strings but hash values can be any possible right
values admitted in Puppet DSL (i.e. a function call or a variable)

Currently it is possible:

* to assign hashes to a variable
$myhash = { key1 => "myval", key2 => $b }

* to access hash members (recursively) from a variable containing a hash
(works for array too):

$myhash = { key => { subkey => "b" }}
notice($myhash[key][subkey]]

* to use hash member access as resource title

* to use hash in default definition parameter or resource parameter if
the type supports it (known for the moment).

It is not possible to use an hash as a resource title. This might be
possible once we support compound resource title.

Support for an elsif syntax

Allows use of an elsif construct:

  if $server == 'mongrel' {
      include mongrel
  } elsif $server == 'nginx' {
      include nginx
  } else {
      include thin
  }

Case and Selectors now support undef

The case and selector statements now support the undef syntax (see #2818).

Pure Ruby Manifests

Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom
language. That is, you can now have Ruby programs along side your Puppet
manifests. As is our custom, it’s a limited first version, but it covers
most of the specification functionality of the current language. For
instance, here’s a simple ssh class:

hostclass :ssh do
  package "ssh", :ensure => :present
  file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config",
:require => "Package[ssh]"
  service :sshd, :ensure => :running, :require =>
"File[/etc/ssh/sshd_config]"
end

Similar to the ‘hostclass’ construct here, you can specify defined
resource types:

define "apache::vhost", :ip, :docroot, :modperl => false do
  file "/etc/apache2/sites-enabled/#{@name}.conf", :content =>
template("apache/vhost.erb")
end

As you can see from this code, the parameters for the resources become
instance variables inside of the defined resource types (and classes,
now that we support parameterized classes).

We can do nodes, too:

node “mynode” do
  include “apache”
end

Ruby has become a first-class citizen alongside the existing external
DSL. That means anywhere you can put a manifest, you should be able to
put Ruby code and have it behave equivalently. So, the ‘ssh’ class
above
could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost
type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the
node should probably be in your ‘site.pp’ file.

You can also apply Ruby manifests directly with puppet:

puppet -e mystuff.rb

Note that the Ruby support does not yet cover all of the functionality
in Puppet’s language. For instance, there is not yet support for
overrides or defaults, nor for resource collections. Virtual and
exported resources are done using a separate method:

virtual file("/my/file", :content => "something")

All of the standard functions are also pulled into Ruby and should work
fine — e.g., ‘include’, ‘template’, and ‘require’.

Stored Configuration

Support is now added for using Oracle databases as a back-end for your
stored configuration.

Facts

There are three new facts available in manifests:

$clientcert – the name of the client certificate
$module_name – the name of the current module (see #1545)
$caller_module_name – the name of the calling module (see #1545)

In addition all puppet.conf configuration items are now available as
facts in your manifests. These can be accessed using the structure:

$settings::setting_name

Where setting_name is the name of the configuration option you’d like to
retrieve.

Types and Providers

A new provider for pkg has been added to support Solaris and OpenSolaris
(pkgadd).

A new package provider has been added to support AIX package management.

The augeas type has added the ‘incl’ and ‘lens’ parameters. These
parameters allow loading a file anywhere on the filesystem; using them
also greatly speeds up processing the resource.

Binaries and Configuration

Single Binary

Puppet is now available as a single binary with sub-arguments for the
functions previously provided by the seperate binaries (the existing
binaries remain for backwards compatibility). This includes renaming
several Puppet functions to better fit an overall model.

List of binary changes

puppetmasterd –> puppet master
puppetd –> puppet agent
puppet –> puppet apply
puppetca –> puppet cert
ralsh –> puppet resource
puppetrun –> puppet kick
puppetqd –> puppet queue
filebucket –> puppet filebucket
puppetdoc –> puppet doc
pi –> puppet describe

This also results in a change in the puppet.conf configuration file.
The sections, previously things like [puppetd], now should be renamed to
match the new binary names.  So [puppetd] becomes [agent].  You will be
prompted to do this when you start Puppet with a log message for each
section that needs to be renamed.  This is merely a warning - existing
configuration file will work unchanged.

New options

A new option is available, ca_name, to specify the name to use for the
Certificate Authority certificate. It defaults to the value of the
certname option (see http://projects.reductivelabs.com/issues/1507).

A new option, dbconnections, is now available that specifies a limit for
the number of database connections made to remote databases (postgreSQL,
MySQL).

A new option, dbport, is now available that specifies the database port
for remote database connections.

There’s also a new option/feature that lets the puppet client use HTTP
compression (—http_compression):

Allow http compression in REST communication with the master. This
setting might improve performance for agent –> master communications
over slow WANs. Your puppetmaster needs to support compression (usually
by activating some settings in a reverse-proxy in front of the
puppetmaster, which rules out webrick).

It is harmless to activate this settings if your master doesn’t support
compression, but if it supports it, this setting might reduce on
high-speed LANs.

Binary changes

The puppetd (or puppet agent) binary now supports the
--detailed-exitcodes option available in the puppet binary.

Certificates cleaned with puppetca (or puppet cert) are now also revoked.

The puppetca (puppet cert) and puppetd (puppet agent) binaries now have
support for certificate fingerprinting and support for specifying digest
algorithms. To display the fingerprint of a client certificate use:

$ puppetd --fingerprint

or

$ puppet agent --fingerprint

To specify a particular digest algorithm use --digest DIGESTNAME.

To fingerprint a certificate with puppetca use:

$ puppetca --fingerprint host.example.com

or

$ puppet cert --fingerprint host.example.com

Also supported is the --digest option.

The puppetdoc binary now documents inheritance between nodes, shows
classes added via the require function and resources added via the
realize function.

Functions

The regsubst function now takes arrays as input (see #2491).

Reports

There is a new report type called http. If you specify:

reports = http

Then the new report processor will make a HTTP POST of the report in
YAML format to a specified URL. By default this URL is the report import
URL for a local Puppet Dashboard installation. You can override this
with the new reporturl setting.

reports = http
reporturl = http://yoururl/post/

CHANGELOG since RC1

fa74020  [#4209] catalog.resources should return resources
f5f9a38  Fix for #4210 -- missing require in CA
1c3e844  Minimal fix for #4205 -- incorrect Import loop messages
99d8323  Fix #4206 - import "path/*" tries to import files twice
a2115af  Alt fix for #4207 -- serialize environments as their names
fe4dcd8  [#4208] Missing parameter breaks multithread compilation

Regards

James Turnbull

-- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571

2010/7/10 Jesús M. Navarro <jesus.### @andago.com>

 Hi:

 On Saturday 10 July 2010 19:11:12 Patrick Mohr wrote:
 > On Jul 10, 2010, at 7:57 AM, Peter Meier wrote:
 > > -----BEGIN PGP SIGNED MESSAGE-----
 > > Hash: SHA1
 > >
 > > On 07/10/2010 04:54 PM, Patrick Mohr wrote:
 > >> On Jul 9, 2010, at 11:58 PM, James Turnbull wrote:
 > >>> Certificates cleaned with puppetca (or puppet cert)
are now also
 > >>> revoked.
 > >>
 > >> Is there some way to clean a cert (using puppet cert)
without
 > >> revoking it?  Something like "puppet cert --clean
hostname.domain
 > >> --no-revoke".
 > >
 > > afaik, not. But could be a feature request. On the other
hand, what's
 > > the use case?
 >
 > This isn't my usecase so I don't care, but since you ask...
 >
 > Suppose you have machines that:
 > *) Don't get any sensitive information through puppet.
 > *) Are re-imaged often using PXE+preseeding or PXE+kickstart
 > *) All the computers have names in the form of
"lab-client-*.domainname"
 >
 > Someone said that in this case you can put "puppetca --clean
 > lab-client-*.domainname" as a cron job, and put
"lab-client-*.domainname"
 > in autosign.conf.
 >
 > Again, I don't do this, so don't do it for me.

 I don't see that to be a use case in need of a "no-revoke" option. 
Once
 you
 delete the old machine and re-image it with "PXE+preseeding or
 PXE+kickstart"
 it won't get the old certkey so it'll need to be resigned anyway: to
all
 practical purposes it's a new machine, so no benefit on not revoking
the
 old
 one.


But I was saying clean out all client certs and private keys (for clients
in
this group) off the server once per hour.  Meaning you are running clean
while the client exists and has a valid cert/key combo.

I guess you would always do the same thing with two "rm" statements in the
cron job instead.