[Puppet Users] mount type is constantly remounting

[slune]

Hi,

I have defined mount resource like this:

mount { "/mnt/test/":
device   => "//test/test",
fstype   => cifs,
ensure   => mounted,
options=> "defaults,acl,soft,uid=test,gid=test=x","
remounts => true,
  }

For the first time (mount point is not mounted) it mounts perfectly,
but after that it keeps mounting to that mount point with every puppet
client run and piling up mounts. After while I have many the same
mounts on this mount point. For now I've changed ensure => present,
but this is not ideal. Is there any way how prevent this behaviour.

Thank you,

Filip

puppet client 2.6.9
puppet server 2.6.9
CentOS release 5.7 (Final)

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

Re: [Puppet Users] How To Expand an .erb Template Without Doing a Full Puppet Run?

[Jon Forrest]

On 9/14/2011 1:58 PM, Dominik Zyla wrote:


named-checkzone(8) should be suitable tool for your needs.


I already knew that. To repeat, what I'm trying to find out
is a way to get an expanded template without doing a full
run of puppet. I could then run named-checkzone on that
and then do a regular run.

In fact, this is only a special case of the more
general problem of getting access to any file generated
by a puppet run without actually putting the files
in the ultimate destination. In other words, it would
be like a --test run except files will be generated and
kept.

Jon Forrest



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

[Puppet Users] ANNOUNCE: Puppet-dashboard 1.2.1rc3 available

[Matthaus Litteken]

This is a maintenance release candidate of Puppet Dashboard.
This release candidate (rc3) fixes a broken init script on redhat
systems (issue #7405). For those playing at home, rc2 fixed the
puppet-dashboard-workers init script, while this rc fixes the
puppet-dashboard init script. 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.1rc3
http://projects.puppetlabs.com/projects/dashboard

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

1.2.1rc3 Release Notes
===

Fix #7405 - Daemonized redhat init script for dashboard

The previous redhat init script would not daemonize, but would merely
background the dashboard server start, so running start over ssh would hang.
This patch replaces the 'su -c' with daemon and passes -d to the
server start
command, so it daemonizes. Start can now be run over ssh without the hang.

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

Re: Re: [Puppet Users] cucumber puppet - ymllookups

[tu2Bgone]

Thanks for the reply Nikolay,

If I have a class like the following:
class role {
$myrole = ymllookup('web_role')
notify{"this is my role: $myrole": }
}

I then use the ymllookup parser that I grabbed from  
http://projects.puppetlabs.com/attachments/1297/ymllookup.rb which will  
parse my /etc/puppet/manifest/extdata directory looking for assignments of  
the 'web_role' - using the following precedence.


# For external lookups
$ymllookup_datadir = "/etc/puppet/manifests/extdata"
$ymllookup_precedence =  
["node/%{fqdn}", "location/%{location}", "role/%{hitwise_role}", "common/common"]


So I would have something like

cat /etc/puppet/manifest/extdata/node/testnode.yml
web_role: 'php_zend'

I create the module feature like so:
cat features/modules/role/role.feature
Feature: role
In order to run a client webserver
As a admin
I want role to be installed

Scenario: testing role
Given a node specified by "features/yaml/testnode.yaml"
Given a node of class "role"
When I compile the catalog
Then the node should notify "this is my role: php_zend"

and it runs like this:

Feature: role
In order to run a client webserver
As a admin
I want role to be installed

Scenario: testing role # features/modules/role/role.feature:6
Given a node specified by "features/yaml/testnode.yaml" #  
cucumber-puppet-0.3.5/lib/cucumber-puppet/steps.rb:1

Given a node of class "role" # features/steps/puppet.rb:1
When I compile the catalog # features/steps/puppet.rb:25
No match found for 'web_role' in any data file during ymllookup() at  
/home/dennism/workspace/ChangeControl/puppet/trunk/modules/role/manifests/init.pp:2  
on node testnode (Puppet::Error)

/usr/lib/ruby/site_ruby/1.8/puppet/parser/compiler.rb:30:in `compile'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:77:in  
`compile'

/usr/lib/ruby/site_ruby/1.8/puppet/util.rb:198:in `benchmark'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:75:in  
`compile'
/usr/lib/ruby/site_ruby/1.8/puppet/indirector/catalog/compiler.rb:34:in  
`find'

/usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:188:in `find'
./features/steps/puppet.rb:26:in `/^I compile the catalog$/'
features/modules/role/role.feature:9:in `When I compile the catalog'
Then the node should notify "this is my role: php_zend" #  
features/steps/puppet.rb:41


Failing Scenarios:
cucumber features/modules/role/role.feature:6 # Scenario: testing role

1 scenario (1 failed)
4 steps (1 failed, 1 skipped, 2 passed)

That help?

Cheers,
Den
On , Nikolay Sturm  wrote:

* denmat [2011-09-12]:



> The issue here is that class roles::prod_webserver doesn't expect to



> be passed any values, but there is a bunch of ymllookups that pull



> values in from local yaml files. This causes errors when it complains



> about either invalid parameter (which it is in the above example) or



> failed lookup of value when I remove those parameters.





Please provide me with a minimal example to reproduce your problem and



I'll have a look.





cheers,





Nikolay





--



"It's all part of my Can't-Do approach to life." Wally





--


You received this message because you are subscribed to the Google  
Groups "Puppet Users" group.



To post to this group, send email to puppet-users@googlegroups.com.


To unsubscribe from this group, send email to  
puppet-users+unsubscr...@googlegroups.com.


For more options, visit this group at  
http://groups.google.com/group/puppet-users?hl=en.





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

[Puppet Users] ANNOUNCE: Facter 1.6.1rc3 available

[Matthaus Litteken]

Facter 1.6.1rc3 is a maintenance release containing fixes for issues
#8491 and #9457, as detailed below.

This release is available for download at:
 http://puppetlabs.com/downloads/facter/facter-1.6.1rc3.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 1.6.1rc3:
 http://projects.puppetlabs.com/projects/facter/

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

Facter 1.6.1rc3 Release Notes
===

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

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

Re: [Puppet Users] How To Expand an .erb Template Without Doing a Full Puppet Run?

[Dominik Zyla]

Hello,

On 09/11/2011 04:59 AM, Jon Forrest wrote:

On 9/10/2011 6:57 PM, Jonathan Stanton wrote:


Maybe I'm missing something here, but I think Jon was asking
something a bit different -- he doesn't want to check the validity of
the erb template (i.e. ruby syntax check) but syntax check the named
zone file generated by the template.


Precisely. Maybe later I'll face the issue of ruby syntax
problems but right now I need to detect named syntax errors
before they cause problems.


So the tricky bit is how to get the variables out of the puppet
manifests that the erb template needs to generate the output file
that 'would' be generated by a new puppet run for this node --
without the actual puppet run (as he asks at the end of the email).


Precisely again.


My first thought is that the only accurate way to do this is by doing
a full puppet run, as any part of the node's manifest could effect
the variables used in the zone file template. You should be able to
get away with a --noop run so the changes won't actually be applied
(because noop does generate files from templates, but you would need
to have a way to capture the newly generated zone file on the client
host and run the named-checkzone there.


That's what I figured. I was hoping that there would be an easier way
that could somehow do a facter run but only run the minimal amount
of puppet.


named-checkzone(8) should be suitable tool for your needs.

Best,
--
Dominik Zyla

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

[Puppet Users] Re: use cached catalog

[Craig White]

On Sep 8, 2011, at 8:52 AM, Craig White wrote:

> Silly me disabled caching on catalogs throughout my testing and now that I'm 
> in production mode, I have had some issues with my puppetmaster/foreman ENC 
> server VM sometimes getting into swap and the dreadful performance has caused 
> some failures because the catalog could not be compiled.
> 
> While I have to solve the underlying problem (and I think I'm getting there), 
> I think it would be useful to have the clients cache the catalog for those 
> times that it can't get a compiled catalog from the puppetmaster.
> 
> the clients have this in puppet.conf [agent] section:
>  ignorecache = false
>  use_cached_catalog = false
> 
> the puppetmaster doesn't have any specific settings but when I run 'puppet 
> master --genconf', I can see...
> 
> localconfig = /var/lib/puppet/state/localconfig
> 
> but there is no cached catalog in any of the clients.
> 
> What am I missing?

perhaps I wasn't clear. I'm looking for a way to implement using a 
cached_catalog if the catalog can't be retrieved to prevent these...

(from Foreman e-mail so the appearance may be unusual but the message is a 
puppet message)
Puppet Output
Level   Resourcemessage
err Puppet  Could not retrieve catalog from remote server: execution expired
notice  Puppet  Using cached catalog
err Puppet  Could not retrieve catalog; skipping run

As far as I can tell, no catalog is ever cached on the puppet master or any 
puppet clients and if my VM server is in a temporary swap funk, it sends an 
e-mail like the above. It seems it would be useful in those instances to just 
use a cached catalog as opposed to a failure.

Possible?

Craig

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

[Puppet Users] Re: fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

Solved my problem:

Defined global paths for execs including the common locations for 
executables:

Exec { path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ] }

Previously i had just /usr/bin/ where apt-get is located.
Apparently apt-get runs scripts that require executables that cannot be 
found in that directory which resulted in an error. 
Things are running as expected now.

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

[Puppet Users] For Solaris users: an OpenSSL problem/fix

[Aaron Grewell]

I ran into an interesting one today, the answer to which was on display at
the bottom of the Google cache of a long-expired Blastwave mailing list
thread behind a door marked 'Beware the Leopard'.  I've repro'd it here in
case you ever hit it.

When running the Puppet agent on a Solaris 10 SPARC system for the first
time I received the following error:

ld.so.1: ruby18: fatal: relocation error: file
/opt/csw/lib/ruby/1.8/sparc-solaris2.9/openssl.so: symbol EVP_MD_CTX_md:
referenced symbol not found

The problem turned out to be that a non-CSW OpenSSL version was installed
that didn't have the symbol Ruby was looking for.  The fix (assuming you
can't remove the offending lib) is to set the LD_LIBRARY_PATH when running
the agent like so:

LD_LIBRARY_PATH=/opt/csw/lib:$LD_LIBRARY_PATH /opt/csw/bin/puppet agent

So now you know...

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

Re: [Puppet Users] Apache/Passenger RHEL6 not working

[Gary Larizza]

On Wed, Sep 14, 2011 at 11:12 AM, Kenton Brede  wrote:

> I'm attempting to move from a working puppetmaster setup to
> Apache/Passenger.  I'm following the instructions in the Pro Puppet
> book.  I'm using the epel repo and running puppet 2.6.6.  Passenger
> version 3.0.9 from the stealthymonkeys repo.  Running "puppetd -t -d"
> doesn't seem to tell me anything significant.  There's no complaining
> about SSL issues.
>
> My nodes can't find the catalog, based on the error message "puppetd
> -t" spits out:
>
> err: Could not retrieve catalog from remote server:
> Puppet::Resource::Catalog does not respond to from_s; can not intern
> instances from text/plain
> warning: Not using cache on failed catalog
> err: Could not retrieve catalog; skipping run
>
> I've googled the error and haven't found anything that helps so far.
> The catalog is currently in /etc/puppet/modules/. I really don't know
> anything about Passenger.  I fail to see in the apache/passenger
> configuration how the puppetmaster is called when a client connects to
> port 8140.  I see that apache is handling the SSL stuff but how does
> the puppetmaster fit into this?
>
> Any help appreciated.
> Thanks,
>
> --
> Kent Brede
> http://gplus.to/kbrede
> http://sandhillsnaps.com/
> http://aphotoaday.sandhillsnaps.org/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
Kent,

I recommend taking a look at the online document here -->
http://docs.puppetlabs.com/guides/passenger.html  There are specific
versions of Passenger and the Rack gem that are necessary for Puppet to work
properly.  I suspect you're using a version of one (possibly Rack) that's
incompatible here.

-- 

Gary Larizza
Professional Services Engineer
Puppet Labs

Join us for PuppetConf , September 22nd and
23rd in Portland, OR!

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

Re: [Puppet Users] Re: fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Craig White]

On Sep 14, 2011, at 9:54 AM, Stoyan Nikolov wrote:

> I have to add, if i run "apt-get upgrade -y"  manually on a machine, and then 
> run the manifest again it works fine: 
> 
> (after running "apt-get upgrade -y" manually)
> 
> root@agent3:~# puppetd --test
> info: Caching catalog for agent3.sabrewolf.net
> info: Applying configuration version '1316008127'
> notice: //aguu/Exec[upgrade]/returns: executed successfully
> notice: //aguu/Exec[update]/returns: executed successfully
> warning: Value of 'preferred_serialization_format' (pson) is invalid for 
> report, using default (marshal)
> notice: Finished catalog run in 34.87 seconds
> 
> But I suspect that as soon as it will actually need to upgrade the 
> repositories it will fail again...

I do too but the problem isn't puppet... the problem is what happens from the 
command line executions of apt-get/aptitude/etc. which obviously leave apt in a 
state where it requires console interaction to resolve. If you stop using apt 
from command line, you won't have a problem with the puppet commands. If you 
use apt on the command line, you should learn to clean up after yourself and 
run things like 'apt-get -f install' (to install needed dependencies), 'apt-get 
autoremove' (to clean up unneeded packages), etc.

Also note that the package cache will get stale over time and you would need to 
run 'apt-get update' prior to running 'apt-get update -y' which is why I told 
you to note how I used 'require' in my puppet manifests to ensure that happens 
first.

Craig

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

[Puppet Users] Apache/Passenger RHEL6 not working

[Kenton Brede]

I'm attempting to move from a working puppetmaster setup to
Apache/Passenger.  I'm following the instructions in the Pro Puppet
book.  I'm using the epel repo and running puppet 2.6.6.  Passenger
version 3.0.9 from the stealthymonkeys repo.  Running "puppetd -t -d"
doesn't seem to tell me anything significant.  There's no complaining
about SSL issues.

My nodes can't find the catalog, based on the error message "puppetd
-t" spits out:

err: Could not retrieve catalog from remote server:
Puppet::Resource::Catalog does not respond to from_s; can not intern
instances from text/plain
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

I've googled the error and haven't found anything that helps so far.
The catalog is currently in /etc/puppet/modules/. I really don't know
anything about Passenger.  I fail to see in the apache/passenger
configuration how the puppetmaster is called when a client connects to
port 8140.  I see that apache is handling the SSL stuff but how does
the puppetmaster fit into this?

Any help appreciated.
Thanks,

-- 
Kent Brede
http://gplus.to/kbrede
http://sandhillsnaps.com/
http://aphotoaday.sandhillsnaps.org/

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

[Puppet Users] Re: fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

I have to add, if i run "apt-get upgrade -y"  manually on a machine, and 
then run the manifest again it works fine: 

(after running "apt-get upgrade -y" manually)

root@agent3:~# puppetd --test
info: Caching catalog for agent3.sabrewolf.net
info: Applying configuration version '1316008127'
notice: //aguu/Exec[upgrade]/returns: executed successfully
notice: //aguu/Exec[update]/returns: executed successfully
warning: Value of 'preferred_serialization_format' (pson) is invalid for 
report, using default (marshal)
notice: Finished catalog run in 34.87 seconds

But I suspect that as soon as it will actually need to upgrade the 
repositories it will fail again...

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

[Puppet Users] Re: fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

I have to add, if i run "apt-get upgrade -y"  manually on a machine, and 
then run the manifest again it works fine: 

(after running "apt-get upgrade -y" manually)

root@agent3:~# puppetd --test
info: Caching catalog for agent3.sabrewolf.net
info: Applying configuration version '1316008127'
notice: //aguu/Exec[upgrade]/returns: executed successfully
notice: //aguu/Exec[update]/returns: executed successfully
warning: Value of 'preferred_serialization_format' (pson) is invalid for 
report, using default (marshal)
notice: Finished catalog run in 34.87 seconds

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

Re: [Puppet Users] fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

Not.

My linux knowledge is very limited, so these are clean ubuntu installations 
that i set up so i can test puppet.


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

Re: [Puppet Users] fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Martin Alfke]

On 14.09.2011, at 18:16, Stoyan Nikolov wrote:

> There isn't a problem with the "apt-get upgrade -y" command, because as i 
> wrote in the original post, If i run that exact same command on the machine 
> it works just fine. 
> 
> Here's the output of the "apt-get upgrade -y; echo $?"
> 
> root@agent3:~# apt-get upgrade -y; echo $?
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following packages will be upgraded:
>   ca-certificates capplets-data checkbox checkbox-gtk dbus dbus-x11
>   dhcp3-client dhcp3-common firefox firefox-branding firefox-gnome-support
>   foomatic-filters gnome-control-center libdbus-1-3 libgnome-window-settings1
>   libgtk-vnc-1.0-0 libnss3-1d libpng12-0 librsvg2-2 librsvg2-common
>   libsmbclient libsndfile1 libsoup-gnome2.4-1 libsoup2.4-1 libwbclient0
>   libwebkit-1.0-2 libwebkit-1.0-common libxfont1 linux-headers-2.6.32-33
>   linux-headers-2.6.32-33-generic linux-image-2.6.32-33-generic linux-libc-dev
>   samba-common samba-common-bin smbclient xulrunner-1.9.2
> 36 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0B/92.7MB of archives.
> After this operation, 45.1kB of additional disk space will be used.
> Extracting templates from packages: 100%
> Preconfiguring packages …

Does any of these packages require user interaction via debconf?

> 
> --output omitted--
> 
> Processing triggers for libc-bin ...
> ldconfig deferred processing now taking place
> 0
> 
> 
> The 0 in the end is the apt-get return, and it means that there were no 
> errors.
> 
> But if i run the exact same command through puppet it returns "100" which is 
> apt-get's error code
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-users/-/efCy34kA-m8J.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.

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

Re: [Puppet Users] Upgrading my version of perl

[Brian Gupta]

It would help to know what version of Ubuntu you are running. Presumably
finding a backport of the package version you are looking for, would
typically be the approach that most folks use.

-Brian

On Wed, Sep 14, 2011 at 11:59 AM, Puppet convert wrote:

> Hi guys,
> I totally love Puppet. I"m installing an ubuntu virtual machine with
> it and have managed to get the most rudimentary stuff working. My
> virtual machine runs 5.10 and I am needing 5.12.
> Does anyone know how to specify an install of Perl-5.12 in my .pp
> file?
> Any pointers would be appreciated...
> Julian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>


-- 


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

Re: [Puppet Users] fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

No, i do not.

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

Re: [Puppet Users] fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Sergey Zhuga]

14.09.2011 17:37, Stoyan Nikolov пишет:

So here is my manifest:

class aguu {

exec { "update":
command => "apt-get update",
path => "/usr/bin/"
}

exec { "upgrade":
command => "apt-get upgrade -y",
path => "/usr/bin/"
}
}

It it supposed to run apt-get update + upgrade

This is the output I get:

info: Applying configuration version '1316008127'
notice: //aguu/Exec[update]/returns: executed successfully
err: //aguu/Exec[upgrade]/returns: change from notrun to 0 failed:
apt-get upgrade -y returned 100 instead of one of [0] at
/etc/puppet/modules/aguu/manifests/init.pp:11
notice: //testmodule1/File[/tmp/testmodule]/ensure: created
warning: Value of 'preferred_serialization_format' (pson) is invalid for
report, using default (marshal)
notice: Finished catalog run in 3.60 seconds

Apt-get should be returning 100 in case of an error, but if i run the
exact same command from command line it runs fine.
Any suggestions what should be going wrong?



Do you use unsigned repositories?

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

[Puppet Users] Re: fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

There isn't a problem with the "apt-get upgrade -y" command, because as i 
wrote in the original post, If i run that exact same command on the machine 
it works just fine. 

Here's the output of the "apt-get upgrade -y; echo $?"

root@agent3:~# apt-get upgrade -y; echo $?
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  ca-certificates capplets-data checkbox checkbox-gtk dbus dbus-x11
  dhcp3-client dhcp3-common firefox firefox-branding firefox-gnome-support
  foomatic-filters gnome-control-center libdbus-1-3 
libgnome-window-settings1
  libgtk-vnc-1.0-0 libnss3-1d libpng12-0 librsvg2-2 librsvg2-common
  libsmbclient libsndfile1 libsoup-gnome2.4-1 libsoup2.4-1 libwbclient0
  libwebkit-1.0-2 libwebkit-1.0-common libxfont1 linux-headers-2.6.32-33
  linux-headers-2.6.32-33-generic linux-image-2.6.32-33-generic 
linux-libc-dev
  samba-common samba-common-bin smbclient xulrunner-1.9.2
36 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/92.7MB of archives.
After this operation, 45.1kB of additional disk space will be used.
Extracting templates from packages: 100%
Preconfiguring packages ...

--output omitted--

Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
0


The 0 in the end is the apt-get return, and it means that there were no 
errors.

But if i run the exact same command through puppet it returns "100" which is 
apt-get's error code

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

[Puppet Users] Upgrading my version of perl

[Puppet convert]

Hi guys,
I totally love Puppet. I"m installing an ubuntu virtual machine with
it and have managed to get the most rudimentary stuff working. My
virtual machine runs 5.10 and I am needing 5.12.
Does anyone know how to specify an install of Perl-5.12 in my .pp
file?
Any pointers would be appreciated...
Julian

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

Re: [Puppet Users] fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Craig White]

On Sep 14, 2011, at 7:37 AM, Stoyan Nikolov wrote:

> So here is my manifest:
> 
> class aguu {
> 
> exec { "update":
> command => "apt-get update",
> path => "/usr/bin/"
> }
> 
> exec { "upgrade":
> command => "apt-get upgrade -y",
> path => "/usr/bin/"
> }
> }
> 
> It it supposed to run apt-get update + upgrade
> 
> This is the output I get:
> 
> info: Applying configuration version '1316008127'
> notice: //aguu/Exec[update]/returns: executed successfully
> err: //aguu/Exec[upgrade]/returns: change from notrun to 0 failed: apt-get 
> upgrade -y returned 100 instead of one of [0] at 
> /etc/puppet/modules/aguu/manifests/init.pp:11
> notice: //testmodule1/File[/tmp/testmodule]/ensure: created
> warning: Value of 'preferred_serialization_format' (pson) is invalid for 
> report, using default (marshal)
> notice: Finished catalog run in 3.60 seconds
> 
> Apt-get should be returning 100 in case of an error, but if i run the exact 
> same command from command line it runs fine.
> Any suggestions what should be going wrong?

It's entirely possible to have something blocking the run of 'apt-get -y 
upgrade' such as unresolved dependencies which may require you to execute 
'apt-get -f install' in order to get something done.

Generally, you can check the result of a command by typing 'echo $?' to see the 
exit status... ie
apt-get upgrade -y; echo $?

as for your particular issue... hard to know for sure but it may be useful to 
see how I handle this. In a general explanation, I create a directory 
/etc/puppet/deployment_files and in that directory, I sometimes put things I 
need for deployment status or triggering.

This is what my 'apt updates' class looks like...

class apt::updates {
  include mod_puppet::deployment_files
 # Puppet maintained file /etc/puppet/deployment_files/apt_update_initiator
  file { "/etc/puppet/deployment_files/apt_update_initiator":
source  => "puppet://puppet/modules/apt/apt_update_initiator",
require => Class["mod_puppet::deployment_files"],
ensure  => present,
owner   => root,
group   => root,
mode=> 0644,
  }
  exec { "/usr/bin/aptitude update":
refreshonly => true,
subscribe   => File["/etc/puppet/deployment_files/apt_update_initiator"],
  }
 # Puppet maintained file 
/etc/puppet/deployment_files/apt_safe_upgrade_initiator
  file { "/etc/puppet/deployment_files//apt_safe_upgrade_initiator":
source  => "puppet://puppet/modules/apt/apt_safe_upgrade_initiator",
require => [ Class["mod_puppet::deployment_files"], 
Exec["/usr/bin/aptitude update"] ],
ensure  => present,
owner   => root,
group   => root,
mode=> 0644,
  }
  exec { "/usr/bin/aptitude -y safe-upgrade":
refreshonly => true,
subscribe   => 
File["/etc/puppet/deployment_files/apt_safe_upgrade_initiator"],
  }
 # Puppet maintained file 
/etc/puppet/deployment_files/apt_full_upgrade_initiator
  file { "/etc/puppet/deployment_files/apt_full_upgrade_initiator":
source  => "puppet://puppet/modules/apt/apt_full_upgrade_initiator",
require => [ Class["mod_puppet::deployment_files"], 
Exec["/usr/bin/aptitude update"] ],
ensure  => present,
owner   => root,
group   => root,
mode=> 0644,
  }
  exec { "/usr/bin/aptitude -y full-upgrade":
refreshonly => true,
subscribe   => 
File["/etc/puppet/deployment_files/apt_full_upgrade_initiator"],
  }
}

and so I '/bin/date > /etc/puppet/modules/apt/files/apt_update_initiator' ( and 
also to apt_safe_upgrade_initiator and apt_full_upgrade_initiator ) and the 
first time this is deployed, all three files are copied and the commands are 
executed on each client. Note that 'Exec["/usr/bin/aptitude update"]' is 
required by the 'upgrades'

Then I have a cron run every night to put the date into the 
apt_update_initiator file on the puppet master so that forces each puppet 
client to execute and I can do the same to either of the 'upgrade' files to 
force them to upgrade.

On any client, I can check 
/etc/puppet/deployment_files/apt_[update|safe_upgrade|full_upgrade]_initiator 
to see the date and time I last instructed it to update/upgrade.

Craig

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

[Puppet Users] fail to exec apt-get upgrade (change from notrun to 0 failed...)

[Stoyan Nikolov]

So here is my manifest:

class aguu {

exec { "update":
command => "apt-get update",
path => "/usr/bin/"
}

exec { "upgrade":
command => "apt-get upgrade -y",
path => "/usr/bin/"
}
}

It it supposed to run apt-get update + upgrade

This is the output I get:

info: Applying configuration version '1316008127'
notice: //aguu/Exec[update]/returns: executed successfully
err: //aguu/Exec[upgrade]/returns: change from notrun to 0 failed: apt-get 
upgrade -y returned 100 instead of one of [0] at 
/etc/puppet/modules/aguu/manifests/init.pp:11
notice: //testmodule1/File[/tmp/testmodule]/ensure: created
warning: Value of 'preferred_serialization_format' (pson) is invalid for 
report, using default (marshal)
notice: Finished catalog run in 3.60 seconds

Apt-get should be returning 100 in case of an error, but if i run the exact 
same command from command line it runs fine.
Any suggestions what should be going wrong?

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

[Puppet Users] ssh::auth - Multiple Keys for Multiple Users

[howards]

Hi,

I'm trying to implement ssh::auth but I can't get it to do what we
need..
The way we work is to have only a limited number of accounts on the
servers, but multiple people can access those accounts - part of this
is documented on the wiki page and that works perfectly -

node 'sles-puptest2' {
 ssh::auth::server {
 ["foo", "bar"]: user => "root"
 }
}

But I can't work out how to do this for another user on the name
server -
So that foo and bar can access root, and foo bar and blah can access
the test acount
i.e from the above
  ssh::auth::server {
 ["foo", "bar"]: user => "root"
 ["foo", "bar", "blah"]: user => "test"
 }

I can't get this to work with any combination of syntax I've tried- am
I trying to do this in the wrong way?

Thanks

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

[Puppet Users] Scope and puppet 2.7

[Arnau Bria]

Hi all,

I'm planning to upgrade our server/client to 2.7 and would like to
completely understand the big change in the dynamic scope deprecation.


It says that 2.7 will issue deprecation warning. Ok, so I've upgraded a
test server, test node and moved my code there. ran puppet and  no
warnings. Great!

So, now, I'd like to qualify my vars. In a code like:

class global_defaults {
include common::ganglia
include common::bacula
[...]
include common::snmp
}


node 'mynode' {
$mcast_ip = '22.22.11.11'
$cluster = 'Test'
$pakiti_tag = 'tag1'
$grid_service = 'ui'
$root_password = 'ui'
$rootkit_detector_mail = 'arnaubria_at_my_domain'
include global_defaults
}


all the vars defined into "mynode" refer to classes included in
global_defaults.

So,i.e, $mcast_ip and $cluster which refer to ganglia module should
they be renamed to $common::ganglia::mcast_ip and
$common::ganglia::cluster ?

Cause this is not working and giving a error:

Cannot assign to variables in other namespaces

**same if I declare them "global" variables $::mcast_ip

So, what's wrong with my code? why I can't rename my vars to new syntax?


TIA,
Arnau

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

[Puppet Users] Re: Deployment of applications

[jcbollinger]

On Sep 13, 2:53 pm, Ashley Penney  wrote:
> I know this has come up on the list numerous times before but I
> thought it would be a good time to see if the state of the art has
> advanced for this kind of thing.  I wanted to know how people are
> handling higher level deployment of applications - things that have to
> be done repeatedly but not all the time.  An example of this is
> checking an application out of svn, building it, creating a package
> and then moving it off to a repo.  Or even just building/installing
> locally for developers.
>
> It never seems to fit well into Puppet for me and I end up with crazy
> complicated manifests to deal with this kind of thing.  I recently
> moved these jobs into Rundeck (www.rundeck.org) which works pretty
> well but doesn't really leverage any of the stuff I have within
> Foreman/Puppet.  I've seen suggestions to use mcollective but this
> doesn't easily integrate our existing scripts (written in many
> languages) or processes and would require me to force a lot of
> developers to work differently.  I could just have classes that
> trigger scripts only when some condition is met (like /.buildapp
> files) or something along those lines but nothing seems elegant.
>
> What I'm trying to find out is what other people did to handle this?
> I want something I can build up over time and slowly migrate legacy
> apps and processes into without having to do a massive up front
> development.  It should also be relatively simple and not require me
> to code anything as anyone on the list who knows me can tell you that
> I am absolutely awful at coding.


Do not mistake Puppet for a script engine or a remote job executor.
It is a state management system.  Crazy complicated manifests for an
uncomplicated area should be a sign to you that you are using the
wrong tool for the job, or at minimum that you are using the tool
wrongly.  For the types of tasks you listed as examples, I would just
use an ordinary shell script, run manually -- supposing the steps were
complicated enough to warrant automating it in any way.  Run them via
a remote job executor service (such as Puppetlabs's own MCollective)
if needed.

If you insist on doing this sort of thing with Puppet then you need to
start out with a high-level view of the problem.  You must answer
these two questions right off the bat:
1) What are the *states* that (may) need to be achieved _and
maintained_?
2) How will clients' current state be measured and reported?

If you have trouble defining the target states, if you can't (or don't
want to) plan to maintain them once achieved, or if you don't have a
good way to determine the current state, then your task is not well
suited to Puppet.  If the answers to those questions are complex, then
any Puppet manifests that adequately address this area for you must
necessarily be complex -- that is the nature of your particular
problem.

On the other hand, if you have good, reasonably simple answers to
those questions then they should lead you to a good, reasonably simple
set of manifests.

As Brian implied, it may be that Puppet can contribute to your
solution even if it is not the primary driver (e.g. by building and
deploying config files and similar for other tools).


John

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

[Puppet Users] puppet kick getting hostname not match with the server certificate

[John Kennedy]

OS - RHEL5.7
Installation Source - epel-testing repo
Puppet server version - 2.6.6
puppetd version - 2.6.6

I searched Google and none of the answers were a match for my set up...

I can do 'puppetd --test' from the client and things work as expected.
When doing puppet kick hostname I get the following:

Triggering hostname
Host hostname failed: hostname not match with the server certificate
hostname finished with exit code 2
Failed: hostname

I have done openssl x509 -text -in /var/lib/puppet/ssl/certs/ca.pem and both
CA certs are identical.
When I do  openssl x509 -text -in /var/lib/puppet/ssl/certs/.pem |
more I find that they are almost identical. The client show the X509v3
extensions section differently:

On the Client:

X509v3 extensions:
Netscape Comment:
Puppet Ruby/OpenSSL Generated Certificate
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
EF:37:CB:9A:6C:42:11:6F:FF:DB:9B:77:DC:78:07:CA:8B:A1:7A:E1
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client
Authentication, E-mail Protection

On the master:

X509v3 extensions:
Netscape Comment:
Puppet Ruby/OpenSSL Generated Certificate
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
CB:07:D6:B9:37:E0:1E:C4:E1:3B:EC:53:69:4C:87:90:67:B0:49:D5
X509v3 Key Usage:
Certificate Sign, CRL Sign

The .pem files on both are called fqdn.pem. Running the hostname command
shows the fqdn of the client.

I am stuck as to why this is happening. Any help would be appreciated.

Thanks,
John

 John Kennedy

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

Re: [Puppet Users] Quick help… GitHub & Puppet Environments...

[Henrik Lindberg]

This is a good presentation of a good git branching strategy in general:
http://nvie.com/posts/a-successful-git-branching-model/

Since github does not manage permissions per branch you really do need 
additional repositories - or at least one if you are willing to accept 
that developers can screw up for each other.


Regard
- henrik

On 9/14/11 2:43 AM, Matt Wise wrote:

I'm looking for a bit of best-practices here. Our puppet environment
up-until-today has been owned and operated by IT Operations only. We've
had a single 'production' environment and our code has been managed in a
local GitHub::FI install. We have ~14,000 lines of code in our PP files.
We're trying to make two changes to our environment... that may need to
be done in the same way, or different ways. I'm looking for
recommendations on how you might handle this given a few constraints.

Constraint #1: We must continue to use GitHub as our source code repo
Constraint #2: Our developers will not run their own Puppet servers. We
want to use a few (2 ... max 3) 'Environments' in Puppet to handle
whether our systems are getting the Production release, or the Testing
release of code.

Ok... here's the two issues we need to solve:

#1: Our main "Puppet Repo" contains all of our base classes, site.pp,
extlookup tables, etc. This repo also contains our /private/ code ...
private keys, operations-owned bits of data that shouldn't be exposed to
the rest of our engineers. We want to break this into a "Production" and
a "Testing" environment on our Puppet servers themselves. I'd like these
two environments to both pull-changes every 5 minutes from Git, and have
an easy but clean method of merging changes from the Testing environment
into the Production environment. This can all be "private" ... meaning
that the same access rules apply to both environments, we just have
different process around them.

#2: Our "User Area" for Puppet modules is a much more open, free-form
place for our engineers to build their own puppet classes for their own
machine types. We'd like to do the same thing as above ... where our
engineers can update a "Testing" environment very easily. The difference
here is that we want our IT Ops staff to be the ones who pull changes
from "Testing" into "Production" for this repository, on some regular
interval. Access to these repos is different. IT Ops staff will need
read/write to both ... while the engineering teams will only be given
read/write to the Testing environment.

I'm really not super familiar with Git branching vs forking vs other
things... I'm looking for suggestions on how to handle this. I was
thinking that #1 could be handled with branches, and #2 could be handled
with forking and push/pull requests... but that seemed ugly to me to do
it differently on the two.

—Matt

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



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

Re: [Puppet Users] Problems installing Puppet Dashoboard

[Galed Friedmann]

Yup that did the trick, changed the version to 1.3.7 and it worked.
Funny that this requirement is not mentioned in the requirements list on the
bootstraping page, only when they explain how to download the rubygems.

Thanks for the help!

On Tue, Sep 13, 2011 at 10:12 PM, Bruno Leon  wrote:

> **
> Did you yuse rubygems-1.3.7 as documented in the install procedure ?
>
> I did try with rubygems-1.8.10 (the latest one) and got failures as well,
> like yours.
>
> --
> Bruno
>
>
> On 11-09-13 02:55 PM, Russell Van Tassell wrote:
>
> Just a stab in the dark, here... but looks like you might need an older
> version of rack installed?  The key line might be:
>
>   *can't activate rack-1.1.0, already activated rack-1.1.2*
>
>
>
> On Tue, Sep 13, 2011 at 8:33 AM, Galed Friedmann <
> galed.friedm...@onavo.com> wrote:
>
>> Hi all,
>> I'm trying to install Puppet Dashboard 1.2.0 and having some troubles, I'm
>> aware that it's probably something wrong with my ruby/rails environment but
>> I really can't seem to figure out why this happens..
>>
>>  My environment is:
>> ruby 1.8.7
>> rake 0.9.2
>> gem 1.8.10
>>
>>  When I try to create the DB schema using the rake command I get alot of
>> deprecated errors, which is weird because I meet the requirements that are
>> specified in the Puppet docs..
>> This is what I get when I try to run the command:
>>
>>  root@master:~/puppet-dashboard-1.2.0[0]# rake RAILS_ENV=production
>> db:migrate --trace
>> NOTE: Gem.source_index is deprecated, use Specification. It will be
>> removed on or after 2011-11-01.
>> Gem.source_index called from
>> /root/puppet-dashboard-1.2.0/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:21.
>> NOTE: Gem::SourceIndex#initialize is deprecated with no replacement. It
>> will be removed on or after 2011-11-01.
>> Gem::SourceIndex#initialize called from
>> /root/puppet-dashboard-1.2.0/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or after 2011-11-01.
>> Gem::SourceIndex#add_spec called from
>> /usr/local/lib/site_ruby/1.8/rubygems/source_index.rb:91.
>> NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec.
>> It will be removed on or 

[Puppet Users] Melbourne Australia sys admin jobs available

[Denmat]

Hi list,

We have two Sys Admin jobs going in our Melbourne office.

We are Linux (centos/ubuntu) and expect fairly high skill set for our 
positions. Obviously puppet skills are attractive to us. We are moving more 
Devopsy and engineering/architecturally focused. 

We are owned by a very large international company but we still have a start up 
feel - honest :)

I'll provide more detail to those that respond off list. Just reply to the 
gmail address (tu2bg...@gmail.com). Australian applicants only I'm afraid.

Cheers,
Den

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