date:20130717

Our Master (server) cert has remained intact, last installed on Nov  2 
 2011.  So I don't believe that's the issue.

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

[Puppet Users] Re: Importing environmental variables from file via exec



On Wednesday, July 17, 2013 2:56:34 AM UTC-5, Przemek wrote:

 Hi Puppet Community,

 I prepare manifests and modules to deploy stuff that I need on agent. 
 During building postgres database I have to export some environmental UNIX 
 variables stored in some_file.conf.
 Standard procedure to do this is simply run command:

 root@hostname:/path_to_config_file# . some_file.conf


 and after this I see all exported variables (env command in terminal).

 Now when I trying do the same thing in puppet exec but variables wont 
 export (no error feedback from agent on debug mode).
 Puppet code:

 exec {enviroments:
 command = '/bin/sh -c . some_file.conf',
 path = [/bin, /usr/bin,/path_to_config_file],
 cwd = /path_to_config_file,
 refreshonly = false,
 require = File[/path_to_config_file/some_file.conf],
 }




You seem to have a misconception about the scope of environment variables.  
Every process has its own, independent environment.  When one process 
spawns another, the child's environment is initialized with copies of those 
parent-process environment variables that are marked for export, but once a 
process has started, no changes to another process's (even its parent's or 
child's) environment has any effect on its own environment.

In your case, when that Exec is applied, it launches /bin/sh (presumably a 
Bourne-compatible shell such as bash), instructing it to execute the 
commands it finds in some_file.conf.  In particular, environment variable 
assignments in that file are executed, modifying the environment *of that 
shell process*.  If those environment variables are marked for export, then 
processes subsequently launched *by that shell* will receive copies of 
those variables in their environments, too.  None of that can have any 
effect on processes launched outside the scope of that Exec's shell 
process, including the puppet agent's own top-level process or any other 
process launched by it.  Everything runs successfully and correctly; it's 
just not a useful thing to do.

 

 Puppet version: 3.1.1
 Distributor ID:Debian
 Description:Debian GNU/Linux 6.0.7 (squeeze)
 Release:6.0.7
 Codename:squeeze

 I will be very grateful for any help, clues or tips that lead me to 
 resolve this problem.



If the original idea was to subsequently apply additional Execs that rely 
on the environment you are trying to initialize, then the solution is to 
wrap it all up into a single Exec.  You can do that by writing a wrapper 
script around the whole thing, using a File resource to ensure it present 
on the target node, then Execing that, or if it's simple enough then you 
can do that directly via a more clueful Exec.  For example,

exec { 'pg_setup':
command = '. some_file.conf  do_step_1  do_step_2',
path = ['/bin', '/usr/bin', '/sbin', '/usr/sbin', 
'/path/to/setup_scripts' ],
cwd = '/path/to/config_file',
require = File['/path/to/config_file/some_file.conf'],
provider = 'shell'
}


John

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

[Puppet Users] Re: Manifest that runs before anything else



On Tuesday, July 16, 2013 10:13:58 AM UTC-5, Mark Hatch wrote:

 I started making manifest that are classes so that I can declare them and 
 organize them with groups and nodes in puppet console.  I have one 
 manifest/class that I want to run before anything.  I know that there are 
 ways to order with require, before, subscribe, etc.  But it seems that if I 
 did before, I would have to list all of the other classes that it should 
 come before.  And if I add more classes, I would have to include those as 
 well.

 Same thing with subscribe.  I would have to add subscribe to every class 
 that I want to happen after this first one.  I could order with one 
 manifest/class, but then I can't organize things as granular in the puppet 
 console.

 Any way to accomplish what I am trying to do?  Is it clear what I'm trying 
 to do?



As Martin said, run stages can do what you describe.  You put the class you 
want to run first in its own stage that is applied before stage 'main'.  
Take care, however: you can cause yourself at least as much trouble with 
stages as you hope to resolve.

Although stages are probably the best solution to the problem as you have 
framed it, the requirement that a given class be applied before any other 
is probably a bit artificial.  You can usually avoid such requirements by 
using smarter classes and resources, and / or by using the chain operators 
to declare relationships separately from the classes and resources to be 
related.  Collections and tags can really grease the wheels on this.

For example, for Yum-based systems you might want to ensure that all 
Yumrepo resources are applied before any Package resources.  You can 
express that in Puppet DSL like so:

Yumrepo| | - Package| |

Put that in any class and assign that class to the target node, and you get 
all the needed relationships between Yumrepos and Packages.


John

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate



On Tuesday, July 16, 2013 4:32:35 PM UTC-5, Forrie wrote:

 We are not configured to auto-sign certificates.

 Clearly, the client is making a connection to the master:


 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/
 de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - -
 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/
 de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - -
 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/
 de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - -

 Correct, our Master is upgraded to the latest Puppet 3.2.3, as is this 
 particular agent.   I've tried starting clean/fresh on the agent (removing 
 /var/lib/puppet) and that has no effect.   The older clients are working 
 just fine.

 puppet cert list, continues to not see the inbound request from this 
 particular agent.



Well, that at least narrows it down.  The master is not recognizing the 
client's certificate-signing request, or is refusing to service it.  Does 
the master already have a signed certificate for this client (or at least 
one bearing the requested certname)?  puppet cert list --all should tell 
you.

If so, then there are two possibilities:
(1) the master signed the current client's current certificate, but is 
refusing to serve up the signed certificate.  This seems unlikely to me, 
but it cannot be altogether discounted.
(2) the signed certificate does not correspond to the certificate-signing 
request currently being presented by the agent (maybe it is an old cert 
signed for a different machine with the same name), so the master refuses 
to provide it to the agent.

If (2) applies, then you should revoke then remove the old cert via puppet 
cert, then try again to connect the agent.

Alternatively, is there any chance you have multiple copies of the master 
installed?  (Maybe one via RPM and a separate one via gem?)  If that's the 
case, then perhaps the master the agent is talking to is different from the 
one that comes first in your shell's executable path.  That could wreak all 
sorts of havoc, including misleading you about the relevant certs and CSRs.


John

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

[Puppet Users] Re: Permission problem on puppet master



On Tuesday, July 16, 2013 11:41:12 AM UTC-5, Piotr Jasiulewicz wrote:

 Hi John,

 thanks for your answer, lunching via service was the first thing I tried 
 (which also produces the same error).

 The linux is Ubuntu 13.X

  The startup:

 root@puppet:/etc/puppet# service puppetmaster start
  * Starting puppet master 
 
 
   Could not run: Could not write 
 /var/lib/puppet/ssl/private_keys/puppet.sherstondevelopments.co.uk.pem to 
 privatekeydir: Permission denied - 
 /var/lib/puppet/ssl/private_keys/puppet.sherstondevelopments.co.uk.pem

  
 The directory:

 root@puppet:/etc/puppet# ls -la /var/lib/puppet/ssl/private_keys/
 total 8
 drwxr-x--- 2 puppet root   4096 Jul 12 12:27 .
 drwxrwx--x 8 puppet puppet 4096 Jun 25 12:54 ..



 The script:

 root@puppet:/etc/puppet# cat /etc/init.d/puppetmaster 
 #! /bin/sh
 ### BEGIN INIT INFO
 # Provides:  puppetmaster
 # Required-Start:$network $named $remote_fs $syslog
 # Required-Stop: $network $named $remote_fs $syslog
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Short-Description: puppet master
 # Description:   The puppet master accepts connections from puppet 
 agents,
 #compiles manifests into catalogs for them, acts as a 
 file
 #server and report server.
 ### END INIT INFO

 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/bin/puppet
 DAEMON_OPTS=
 NAME=master
 DESC=puppet master

 test -x $DAEMON || exit 0

 [ -r /etc/default/puppetmaster ]  . /etc/default/puppetmaster

 . /lib/lsb/init-functions

 if [ ! -d /var/run/puppet ]; then
 mkdir -p /var/run/puppet
 fi

 chown puppet:puppet /var/run/puppet

 is_true() {
 if [ x$1 = xtrue -o x$1 = xyes -o x$1 = x0 ] ; then
 return 0
 else
 return 1
 fi
 }

 start_puppet_master() {
 if is_true $START ; then
 start-stop-daemon --start --pidfile /var/run/puppet/${NAME}.pid \
 --startas $DAEMON -- $NAME $DAEMON_OPTS
 else
 echo 
 echo puppetmaster not configured to start, please edit 
 /etc/default/puppetmaster to enable
 fi
 }

 stop_puppet_master() {
 start-stop-daemon --stop --quiet --oknodo --pidfile 
 /var/run/puppet/${NAME}.pid
 }

 status_puppet_master() {
 status_of_proc -p /var/run/puppet/${NAME}.pid ${DAEMON} ${NAME}
 }


 case $1 in
 start)
 log_begin_msg Starting $DESC
 start_puppet_master
 log_end_msg $?
 ;;
 stop)
 log_begin_msg Stopping $DESC
 stop_puppet_master
 log_end_msg $?
 ;;
 reload)
   # Do nothing, as Puppetmaster rechecks its config automatically
 ;;
 status)
 status_puppet_master
 ;;
 restart|force-reload)
 log_begin_msg Restarting $DESC
 stop_puppet_master
 sleep 1
 start_puppet_master
 log_end_msg $?
 ;;
 *)
 echo Usage: $0 {start|stop|status|restart|force-reload} 2
 exit 1
 ;;
 esac


 Still dunno what to do:/ 

 any clues?


 Thanks,
 Piotr


 The directory has all rights for puppet as the user, still could not get 
 anywhere with that.



Do continue to test via service puppetmaster start.

At this point, I suspect an SELinux policy or labeling problem.  You should 
be able to test this fairly easily by switching SELinux to permissive mode 
and trying again to start the master:

setenforce 0
service puppetmaster start

If the master then starts successfully then such an SELinux problem is 
confirmed.  Moreover, you will probably then find an AVC message in your 
log, and maybe even a desktop alert, that explains the nature of the 
problem.  In fact, you may see explanatory AVC messages in your log already.

Supposing that you have an SELinux issue and you do want SELinux enforcing 
mandatory access controls, the long-term solution is to ensure that your 
SELinux policy provides for the required access and that your filesystem is 
labeled correctly.  The best way to achieve those objectives depends on 
your distro and on how you installed Puppet.


John



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

[Puppet Users] Re: Permission problem on puppet master

2013-07-17 Thread Piotr Jasiulewicz

Hi John


there is no SELinux on this system. Issue still is an issue.. :/


Cheers,
Piotr


W dniu środa, 17 lipca 2013 16:13:24 UTC+1 użytkownik jcbollinger napisał:



 On Tuesday, July 16, 2013 11:41:12 AM UTC-5, Piotr Jasiulewicz wrote:

 Hi John,

 thanks for your answer, lunching via service was the first thing I tried 
 (which also produces the same error).

 The linux is Ubuntu 13.X

  The startup:

 root@puppet:/etc/puppet# service puppetmaster start
  * Starting puppet master 
 
 
   Could not run: Could not write 
 /var/lib/puppet/ssl/private_keys/puppet.sherstondevelopments.co.uk.pem to 
 privatekeydir: Permission denied - 
 /var/lib/puppet/ssl/private_keys/puppet.sherstondevelopments.co.uk.pem

  
 The directory:

 root@puppet:/etc/puppet# ls -la /var/lib/puppet/ssl/private_keys/
 total 8
 drwxr-x--- 2 puppet root   4096 Jul 12 12:27 .
 drwxrwx--x 8 puppet puppet 4096 Jun 25 12:54 ..



 The script:

 root@puppet:/etc/puppet# cat /etc/init.d/puppetmaster 
 #! /bin/sh
 ### BEGIN INIT INFO
 # Provides:  puppetmaster
 # Required-Start:$network $named $remote_fs $syslog
 # Required-Stop: $network $named $remote_fs $syslog
 # Default-Start: 2 3 4 5
 # Default-Stop:  0 1 6
 # Short-Description: puppet master
 # Description:   The puppet master accepts connections from puppet 
 agents,
 #compiles manifests into catalogs for them, acts as a 
 file
 #server and report server.
 ### END INIT INFO

 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/bin/puppet
 DAEMON_OPTS=
 NAME=master
 DESC=puppet master

 test -x $DAEMON || exit 0

 [ -r /etc/default/puppetmaster ]  . /etc/default/puppetmaster

 . /lib/lsb/init-functions

 if [ ! -d /var/run/puppet ]; then
 mkdir -p /var/run/puppet
 fi

 chown puppet:puppet /var/run/puppet

 is_true() {
 if [ x$1 = xtrue -o x$1 = xyes -o x$1 = x0 ] ; then
 return 0
 else
 return 1
 fi
 }

 start_puppet_master() {
 if is_true $START ; then
 start-stop-daemon --start --pidfile /var/run/puppet/${NAME}.pid \
 --startas $DAEMON -- $NAME $DAEMON_OPTS
 else
 echo 
 echo puppetmaster not configured to start, please edit 
 /etc/default/puppetmaster to enable
 fi
 }

 stop_puppet_master() {
 start-stop-daemon --stop --quiet --oknodo --pidfile 
 /var/run/puppet/${NAME}.pid
 }

 status_puppet_master() {
 status_of_proc -p /var/run/puppet/${NAME}.pid ${DAEMON} ${NAME}
 }


 case $1 in
 start)
 log_begin_msg Starting $DESC
 start_puppet_master
 log_end_msg $?
 ;;
 stop)
 log_begin_msg Stopping $DESC
 stop_puppet_master
 log_end_msg $?
 ;;
 reload)
   # Do nothing, as Puppetmaster rechecks its config automatically
 ;;
 status)
 status_puppet_master
 ;;
 restart|force-reload)
 log_begin_msg Restarting $DESC
 stop_puppet_master
 sleep 1
 start_puppet_master
 log_end_msg $?
 ;;
 *)
 echo Usage: $0 {start|stop|status|restart|force-reload} 2
 exit 1
 ;;
 esac


 Still dunno what to do:/ 

 any clues?


 Thanks,
 Piotr


 The directory has all rights for puppet as the user, still could not get 
 anywhere with that.



 Do continue to test via service puppetmaster start.

 At this point, I suspect an SELinux policy or labeling problem.  You 
 should be able to test this fairly easily by switching SELinux to 
 permissive mode and trying again to start the master:

 setenforce 0
 service puppetmaster start

 If the master then starts successfully then such an SELinux problem is 
 confirmed.  Moreover, you will probably then find an AVC message in your 
 log, and maybe even a desktop alert, that explains the nature of the 
 problem.  In fact, you may see explanatory AVC messages in your log already.

 Supposing that you have an SELinux issue and you do want SELinux enforcing 
 mandatory access controls, the long-term solution is to ensure that your 
 SELinux policy provides for the required access and that your filesystem is 
 labeled correctly.  The best way to achieve those objectives depends on 
 your distro and on how you installed Puppet.


 John





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

[Puppet Users] Re: template - need to fail if referencing undefined var



On Monday, July 15, 2013 11:25:50 AM UTC-5, Brano Zarnovican wrote:

 Hi,

 I have the following code snippet

 node default {
 # $var_a   .. is undefined
 $var_b = hiera(var_b, undef)
 $var_c = undef

 file { /var/tmp/foo.txt: content = inline_template(

 % if @var_a %
 var_b = %= @var_a %
 % else %
 % info(\var_a is undefined\) %
 % end -%

 % if @var_b %
 var_b = %= @var_b %
 % else %
 % info(\var_b is undefined\) %
 % end -%

 % if @var_c %
 var_c = %= @var_c %
 % else %
 % info(\var_c is undefined\) %
 % end -%

 
 ), }
 }

 Applying it, will generate these two info messages.

 Info: template[inline]: var_a is undefined
 Info: template[inline]: var_c is undefined
 var_b = 

 What I would like puppet to do is to fail if template is referencing a 
 variable which is not defined, without having to wrap it with 
 if-else-fail()-end.

 Another strange thing I've noticed that undef behaves differently if it 
 is a default value for hiera lookup (see var_b vs var_c).

 Actually, my code looks more like..

 $var_a = hiera(var_a)
 $var_b = hiera(var_b)
 $var_c = hiera(var_c)
 file {..: content = template(hiera(tmpl_name)) }

 That will fail if any variable a,b,c is undefined in hiera, no matter if 
 it is used in template or not. I can rewrite it to

 $var_a = hiera(var_a, undef)
 $var_b = hiera(var_b, undef)
 $var_c = hiera(var_c, undef)
 file {..: content = template(hiera(tmpl_name)) }

 This will not fail even if variable used by the template is undefined. The 
 value is quietly replaced by empty string.

 In other words, I would like to delay the failure from hiera() lookup to 
 the time when it is actually used in template. Can it be done without 
 explicitly testing it with if inside template ?

 Thanks,

 BranoZ

 PS: we are (or soon be) on puppet 3.2.



You have a couple of separate issues here, but first a little background to 
make sure we're on the same page: templates are evaluated by the master, 
not by agents, so the only form of failure a template can exhibit is to 
interrupt catalog compilation with a synthetic parse error.  It cannot 
cause application of the associated resource to fail on the agent.

With that said, a template can call Puppet function via the 'scope' object 
available to it.  In particular, if you want a template evaluation to fail 
as I describe, then it can invoke the fail() function:

% scope.function_fail('variable foo is not set') %


Now, as a separate matter, you are correct that hiera will translate the 
default value 'undef' to an empty string.  It will never return an undef 
value (I'm not sure that even makes sense).  A common approach is to 
instead choose a default value that you are confident will not appear as a 
valid value in your data.  One conventional choice is 'NOTSET'.  Your code 
then tests for that special value instead of (or in addition to) testing 
whether the variable is defined.


John

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

[Puppet Users] Windows Issue: Package ensure: change from absent to present failed

Master: RHEL6 running Puppet 3.2.2
Node: Windows 7 x64 Running Puppet 3.2.3

I have the following rule defined on my Puppet master to push Python to
client workstations:
package { 'Python 2.7.5 (64-bit)':
ensure = installed,
source =
'\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi',
install_options = [{ 'INSTALLDIR' = 'C:\Python27' },],
require = [Package['MinGW-W64 version 4.5.3'], Package['Cygwin
version 1.7.15']],
}

On the client, Python has already been installed via a run of: puppet
agent --test. Here is the output of a manual agent execution on the
Windows 7 node in question:
C:\Program Files (x86)\Puppet Labs\Puppet\binpuppet agent --test --trace
Info: Retrieving plugin
Info: Caching catalog for hostname
Info: Applying configuration version '1374075302'
Notice: /Stage[main]/Win7_user::Restart/Exec[restart_agent_flag]/returns:
executed successfully
Notice: Finished catalog run in 6.51 seconds

As you can see, it's up-to-date. 'Python 2.7.5 (64-bit)' is in my list of
installed programs. Where I run into problems is when the Puppet service
kicks off. For some reason it tried to install Python again, and then
fails with the mysterious INT 24 error. In previous reports of INT 24 that
I've seen, it had to do with invalid declaration of the source attribute,
which doesn't appear to be a problem here. Anyways, here is what is in
Windows Event Viewer for the Puppet service:

MsiInstaller - Information 1040:
Beginning a Windows Installer transaction:
\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process
Id: 7896.

MsiInstaller - Information 1042
Ending a Windows Installer transaction:
\\astdfs.ast.lmco.com\Data\ses\GOESR_SW_ENG\goesr01\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi.

Client Process Id: 7896.

Puppet - Error 3
Failed to install: Fail on INT 24.
/Stage[main]/Win7_user/Package[Python 2.7.5 (64-bit)]/ensure: change from
absent to present failed: Failed to install: Fail on INT 24.

What's not clear to me, is why is it trying to install again? It's already
in the list of installed programs, and manual invocations of the agent,
detect it's there. I've tried rebooting the machine, but it makes no
difference.

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

Re: [Puppet Users] Windows Issue: Package ensure: change from absent to present failed

2013-07-17 Thread Rob Reynolds

Perhaps this could be a permissions error?

Can you validate that the user the service runs under can access the
c:\Python27 folder and that it can see the registry settings?

--
Rob Reynolds

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13

On Wed, Jul 17, 2013 at 11:19 AM, Josh D joshuadavid...@gmail.com wrote:

Master: RHEL6 running Puppet 3.2.2
Node: Windows 7 x64 Running Puppet 3.2.3

As you can see, it's up-to-date. 'Python 2.7.5 (64-bit)' is in my list
of installed programs. Where I run into problems is when the Puppet
service kicks off. For some reason it tried to install Python again, and
then fails with the mysterious INT 24 error. In previous reports of INT 24
that I've seen, it had to do with invalid declaration of the source
attribute, which doesn't appear to be a problem here. Anyways, here is
what is in Windows Event Viewer for the Puppet service:

MsiInstaller - Information 1040:
Beginning a Windows Installer transaction:
\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process
Id: 7896.

MsiInstaller - Information 1042
Ending a Windows Installer transaction:
\\astdfs.ast.lmco.com\Data\ses\GOESR_SW_ENG\goesr01\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi.
Client Process Id: 7896.

Puppet - Error 3
Failed to install: Fail on INT 24.
/Stage[main]/Win7_user/Package[Python 2.7.5 (64-bit)]/ensure: change from
absent to present failed: Failed to install: Fail on INT 24.

What's not clear to me, is why is it trying to install again? It's
already in the list of installed programs, and manual invocations of the
agent, detect it's there. I've tried rebooting the machine, but it makes
no difference.

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

[Puppet Users] Installing Puppet on Windows: Error 1053

2013-07-17 Thread Иван Кадочников

Hi all,

I have trouble installing puppet open source 3.2.3 from the msi package on 
Windows 7 Home Basic.
The error message is Service 'Puppet Agent' (puppet) failed to start. 
Verify that you have sufficient privileges to start system services.

I am pretty sure it's not a privileges problem.
If (without closing the installer, as that would roll back everything) I 
open Services and try to start Puppet Agent manually it fails to start with
Error 1053: The service did not respond to the start or control request in 
a timely fashion.

This may be a timeout problem (the hardware is a netbook), but I doubt it.

1) Is there a way to install Puppet without installing or auto-starting the 
service? A checkbox in the installer would be nice.
2) Is there a way to avoid rolling back the whole installation if the 
service failed to start? A yes/no dialog would be nice. Yes, I will start 
the service later manually, after I figure out what's wrong, thank you
3) What could be causing this, what can I do to work around this?
I have tried adding registry key 
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout = 
12 (googling error 1053 led me to believe it might help, but it did not)

Then I tried to run Puppet directly (still without closing the installer):

C:\Program Files\Puppet Labs\Puppet\binpuppet.bat
C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/gems/win32-dir-
0.3.7/lib/win32/dir.rb:54:in `strip': invalid byte sequence in US-ASCII 
(Argumen
tError)
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
ms/win32-dir-0.3.7/lib/win32/dir.rb:54:in `block in class:Dir'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
ms/win32-dir-0.3.7/lib/win32/dir.rb:36:in `each'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
ms/win32-dir-0.3.7/lib/win32/dir.rb:36:in `class:Dir'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
ms/win32-dir-0.3.7/lib/win32/dir.rb:13:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:60:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:60:in `rescue in require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:35:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/config.r
b:44:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/resoluti
on.rb:7:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/facter/lib/facter/util/fact.rb:
2:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter.rb:23:in 
`mo
dule:Facter'
from C:/Program Files/Puppet Labs/Puppet/facter/lib/facter.rb:19:in 
`to
p (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet.rb:6:in 
`top
 (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/puppet/lib/puppet/util/command_
line.rb:12:in `top (required)'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
.1/rubygems/custom_require.rb:36:in `require'
from C:/Program Files/Puppet Labs/Puppet/puppet/bin/puppet:3:in 
`main'
I have no ruby experience so any help interpreting that would be welcome.

Ivan

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from

[Puppet Users] Re: Windows Issue: Package ensure: change from absent to present failed

On Wednesday, July 17, 2013 9:19:27 AM UTC-7, Josh D wrote:

Master: RHEL6 running Puppet 3.2.2
Node: Windows 7 x64 Running Puppet 3.2.3

As you can see, it's up-to-date. 'Python 2.7.5 (64-bit)' is in my list
of installed programs.

Based on http://www.python.org/download/releases/2.5/msi/ I think python is
only being installed for the current user, not all users. You'll have to
specify ALLUSERS=1 to get that behavior. I don't see this explicitly called
out in our
docs http://docs.puppetlabs.com/windows/writing.html#packagepackage but it
should be. Could you file a ticket?

Where I run into problems is when the Puppet service kicks off. For some
reason it tried to install Python again, and then fails with the mysterious
INT 24 error. In previous reports of INT 24 that I've seen, it had to do
with invalid declaration of the source attribute, which doesn't appear to
be a problem here. Anyways, here is what is in Windows Event Viewer for
the Puppet service:

MsiInstaller - Information 1040:
Beginning a Windows Installer transaction:
\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi. Client Process
Id: 7896.

MsiInstaller - Information 1042
Ending a Windows Installer transaction:
\\astdfs.ast.lmco.com\Data\ses\GOESR_SW_ENG\goesr01\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi.

Client Process Id: 7896.

Puppet - Error 3
Failed to install: Fail on INT 24.
/Stage[main]/Win7_user/Package[Python 2.7.5 (64-bit)]/ensure: change from
absent to present failed: Failed to install: Fail on INT 24.

What's not clear to me, is why is it trying to install again? It's
already in the list of installed programs, and manual invocations of the
agent, detect it's there. I've tried rebooting the machine, but it makes
no difference.

This is one area where puppet and Add/Remove Programs differ. ARP will
manage per-user packages for the current user, but puppet does not, since
typically it's running as LocalSystem.

Josh

Re: [Puppet Users] Re: Windows Issue: Package ensure: change from absent to present failed

2013-07-17 Thread Rob Reynolds

Thanks Josh. I wasn't thinking the install for only one user would be a
problem so I didn't mention it. I guess it falls into a different part of
the registry (HKCU) as well so it wouldn't show up as installed at all for
the other accounts.

--
Rob Reynolds
Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Final Countdown discount - save
15%!*


On Wed, Jul 17, 2013 at 11:39 AM, Josh Cooper j...@puppetlabs.com wrote:



 On Wednesday, July 17, 2013 9:19:27 AM UTC-7, Josh D wrote:

 Master: RHEL6 running Puppet 3.2.2
 Node: Windows 7 x64 Running Puppet 3.2.3

 I have the following rule defined on my Puppet master to push Python to
 client workstations:
 package { 'Python 2.7.5 (64-bit)':
 ensure  = installed,
 source  = '\\server\share\Puppet\win64\**
 Python\python-2.7.5.amd64.msi'**,
 install_options = [{ 'INSTALLDIR' = 'C:\Python27' },],
 require = [Package['MinGW-W64 version 4.5.3'],
 Package['Cygwin version 1.7.15']],
   }


 On the client, Python has already been installed via a run of: puppet
 agent --test.  Here is the output of a manual agent execution on the
 Windows 7 node in question:
 C:\Program Files (x86)\Puppet Labs\Puppet\binpuppet agent --test --trace
 Info: Retrieving plugin
 Info: Caching catalog for hostname
 Info: Applying configuration version '1374075302'
 Notice: /Stage[main]/Win7_user::**Restart/Exec[restart_agent_**flag]/returns:
 executed successfully
 Notice: Finished catalog run in 6.51 seconds


 As you can see, it's up-to-date.   'Python 2.7.5 (64-bit)' is in my list
 of installed programs.


 Based on http://www.python.org/download/releases/2.5/msi/ I think python
 is only being installed for the current user, not all users. You'll have to
 specify ALLUSERS=1 to get that behavior. I don't see this explicitly called
 out in our docs
 http://docs.puppetlabs.com/windows/writing.html#packagepackage but it
 should be. Could you file a ticket?


  Where I run into problems is when the Puppet service kicks off.  For
 some reason it tried to install Python again, and then fails with the
 mysterious INT 24 error.  In previous reports of INT 24 that I've seen, it
 had to do with invalid declaration of the source attribute, which doesn't
 appear to be a problem here.  Anyways, here is what is in Windows Event
 Viewer for the Puppet service:

 MsiInstaller - Information 1040:
 Beginning a Windows Installer transaction: \\server\share\Puppet\win64\
 **Python\python-2.7.5.amd64.msi. Client Process Id: 7896.

 MsiInstaller - Information 1042
 Ending a Windows Installer transaction: \\astdfs.ast.lmco.com\Data\**
 ses\GOESR_SW_ENG\goesr01\**Tools\Puppet\win64\Python\**python-2.7.5.amd64.msi.
 Client Process Id: 7896.

 Puppet - Error 3
 Failed to install:  Fail on INT 24.
 /Stage[main]/Win7_user/**Package[Python 2.7.5 (64-bit)]/ensure: change
 from absent to present failed: Failed to install:  Fail on INT 24.



 What's not clear to me, is why is it trying to install again?  It's
 already in the list of installed programs, and manual invocations of the
 agent, detect it's there.   I've tried rebooting the machine, but it makes
 no difference.


 This is one area where puppet and Add/Remove Programs differ. ARP will
 manage per-user packages for the current user, but puppet does not, since
 typically it's running as LocalSystem.

 Josh

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




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

[Puppet Users] Re: Installing Puppet on Windows: Error 1053



On Wednesday, July 17, 2013 9:27:05 AM UTC-7, Иван Кадочников wrote:

 Hi all,

 I have trouble installing puppet open source 3.2.3 from the msi package on 
 Windows 7 Home Basic.
 The error message is Service 'Puppet Agent' (puppet) failed to start. 
 Verify that you have sufficient privileges to start system services.

 I am pretty sure it's not a privileges problem.
 If (without closing the installer, as that would roll back everything) I 
 open Services and try to start Puppet Agent manually it fails to start with
 Error 1053: The service did not respond to the start or control request 
 in a timely fashion.

 This may be a timeout problem (the hardware is a netbook), but I doubt it.

 1) Is there a way to install Puppet without installing or auto-starting 
 the service? A checkbox in the installer would be nice.


This is http://projects.puppetlabs.com/issues/18268

2) Is there a way to avoid rolling back the whole installation if the 
 service failed to start? A yes/no dialog would be nice. Yes, I will start 
 the service later manually, after I figure out what's wrong, thank you


We're using WiX to build our MSI. I'm not sure if there is an option to do 
this?
 

 3) What could be causing this, what can I do to work around this?
 I have tried adding registry key 
 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout = 
 12 (googling error 1053 led me to believe it might help, but it did not)

 Then I tried to run Puppet directly (still without closing the installer):

 C:\Program Files\Puppet Labs\Puppet\binpuppet.bat
 C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/gems/win32-dir-
 0.3.7/lib/win32/dir.rb:54:in `strip': invalid byte sequence in US-ASCII 
 (Argumen
 tError)
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
 ms/win32-dir-0.3.7/lib/win32/dir.rb:54:in `block in class:Dir'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
 ms/win32-dir-0.3.7/lib/win32/dir.rb:36:in `each'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
 ms/win32-dir-0.3.7/lib/win32/dir.rb:36:in `class:Dir'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/gems/1.9.1/ge
 ms/win32-dir-0.3.7/lib/win32/dir.rb:13:in `top (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:60:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:60:in `rescue in require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:35:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/facter/lib/facter/util/config.r
 b:44:in `top (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/facter/lib/facter/util/resoluti
 on.rb:7:in `top (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/facter/lib/facter/util/fact.rb:
 2:in `top (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/facter/lib/facter.rb:23:in `mo
 dule:Facter'
 from C:/Program Files/Puppet 
 Labs/Puppet/facter/lib/facter.rb:19:in `to
 p (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet Labs/Puppet/puppet/lib/puppet.rb:6:in 
 `top
  (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/puppet/lib/puppet/util/command_
 line.rb:12:in `top (required)'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9
 .1/rubygems/custom_require.rb:36:in `require'
 from C:/Program Files/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/site_ruby/1.9

Re: [Puppet Users] Windows Issue: Package ensure: change from absent to present failed

On Wednesday, July 17, 2013 10:24:15 AM UTC-6, Rob Reynolds wrote:

 Perhaps this could be a permissions error?

 Can you validate that the user the service runs under can access the 
 c:\Python27 folder and that it can see the registry settings?


It is running as the SYSTEM account. so it should be able to.  I tested 
trying to read the reg as system using psexec:
C:\Users\davidsj2\Downloadspsexec -i -s regedit /e c:\temp\sys.reg 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{DBDD570E-0952-475F-9453-AB88F3DD565A}

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com


regedit exited on hoswith error code 0.


It exported correctly.  I then restarted the service with the debug and 
trace flags and got a bit more detail in the INT 24 error:
Failed to install:  Fail on INT 24.
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:99:in 
`check_result'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:64:in `install'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/type/package.rb:67:in `block (3 levels) in 
module:Puppet'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/property.rb:197:in `call_valuemethod'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/property.rb:498:in `set'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/property.rb:581:in `sync'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:114:in 
`apply_parameter'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:56:in 
`perform_changes'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:139:in 
`evaluate'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:48:in `apply'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:83:in `eval_resource'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block (2 levels) in 
evaluate'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:351:in 
`block in thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:350:in 
`thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block in evaluate'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:382:in `traverse'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:98:in `evaluate'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/resource/catalog.rb:146:in `apply'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:122:in `block in apply_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:179:in 
`block in benchmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:178:in 
`benchmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:121:in `apply_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:179:in `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (5 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (4 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (3 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:119:in 
`with_client'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:42:in 
`block (2 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:84:in 
`run_in_fork'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in 
`block in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in 
`run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:353:in `onetime'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:327:in `run_command'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in 
run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:456:in `plugin_hook'
C:/Program Files (x86)/Puppet

[Puppet Users] Puppet agent process get stuck

2013-07-17 Thread yannig rousseau

Hi, 

3 days ago, we had a production issue where the puppetmaster became 
unreachable for 20 minute.
All of the puppet clients which tried to connect at this time are now 
failing :  Run of Puppet configuration client already in progress; 
skipping

Further investigation show that the puppet agent process is still running 
on all of this clients 3 days later. I tried to kille the process on a 
machine, and puppet service came back to normal for this machine.

Is there a way to kill the process on all of the client ?
Is there a way to specify a timeout on the process ? This would permit to 
discard the process without human action

Regards
Yannig

Configuration :
 - Puppet master = RHEL5, Puppet 3.2.2
 - Puppet client = RHEL5, Puppet 3.1.1  3.2.2

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

[Puppet Users] Re: PUPPETDB and pgpool II

2013-07-17 Thread Robert Bachmann

ok so I got rid of caching and now in the pgpool.log I see the snippet 
below. Note that I can use pgpool to quesry the puppetdb to get data
2013-07-17 13:01:28 ERROR: pid 1193: Bind: cannot get parse message S_1
2013-07-17 13:01:28 LOG:   pid 1193: do_child: exits with status 1 due to 
error
2013-07-17 13:01:28 LOG:   pid 1178: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1192: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1191: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1189: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1187: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1185: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1181: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1179: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1183: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1190: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
2013-07-17 13:01:28 LOG:   pid 1188: ProcessFrontendResponse: failed to 
read kind from frontend. frontend abnormally exited
On Friday, July 12, 2013 1:32:34 PM UTC-4, Robert Bachmann wrote:

 I am trying to set up puppet in an HA environment using pgpool to connect 
 to the postgres DB and I get this kind of thing in the pgpool log any ideas?

 2013-07-12 11:56:45 LOG:   pid 12275: DB node id: 1 backend pid: 732 
 statement:  DISCARD ALL
 2013-07-12 11:57:47 LOG:   pid 1: connection received: host=
 xlabsvcdb2.hostname.com port=49722
 2013-07-12 11:57:47 LOG:   pid 12214: connection received: host=
 xlabsvcdb2.hostname.com port=49723
 2013-07-12 11:57:47 LOG:   pid 12275: connection received: host=
 xlabsvcdb2.hostname.com port=49726
 2013-07-12 11:57:47 LOG:   pid 12213: connection received: host=
 xlabsvcdb2.hostname.com port=49727
 2013-07-12 11:57:47 LOG:   pid 12216: connection received: host=
 xlabsvcdb2.hostname.com port=49730
 2013-07-12 11:57:47 LOG:   pid 12212: connection received: host=
 xlabsvcdb2.hostname.com port=49731
 2013-07-12 11:57:47 LOG:   pid 12209: connection received: host=
 xlabsvcdb2.hostname.com port=49734
 2013-07-12 11:57:47 LOG:   pid 12224: connection received: host=
 xlabsvcdb2.hostname.com port=49737
 2013-07-12 11:57:47 LOG:   pid 12207: connection received: host=
 xlabsvcdb2.hostname.com port=49738
 2013-07-12 11:57:47 LOG:   pid 12223: connection received: host=
 xlabsvcdb2.hostname.com port=49741
 2013-07-12 11:57:47 LOG:   pid 12205: connection received: host=
 xlabsvcdb2.hostname.com port=49742
 2013-07-12 11:57:47 LOG:   pid 12218: connection received: host=
 xlabsvcdb2.hostname.com port=49745
 2013-07-12 11:57:47 ERROR: pid 12193: Child process 1 was terminated 
 by segmentation fault
 2013-07-12 11:57:47 LOG:   pid 12214: ProcessFrontendResponse: failed to 
 read kind from frontend. frontend abnormally exited

 and this in teh puppetdb log

 2013-07-12 11:57:47,737 ERROR [main] [puppetlabs.utils] Uncaught exception
 org.postgresql.util.PSQLException: This connection has been closed.
 at 
 org.postgresql.jdbc2.AbstractJdbc2Connection.checkClosed(AbstractJdbc2Connection.java:714)
 at 
 org.postgresql.jdbc2.AbstractJdbc2Connection.getAutoCommit(AbstractJdbc2Connection.java:680)
 at 
 com.jolbox.bonecp.ConnectionHandle.getAutoCommit(ConnectionHandle.java:587)
 at 
 clojure.java.jdbc.internal$transaction_STAR_.invoke(internal.clj:200)
 at 
 com.puppetlabs.puppetdb.scf.migrate$migrate_BANG_.invoke(migrate.clj:379)
 at 
 com.puppetlabs.puppetdb.cli.services$_main$fn__10279.invoke(services.clj:396)
 at 
 clojure.java.jdbc.internal$with_connection_STAR_.invoke(internal.clj:186)
 at 
 com.puppetlabs.puppetdb.cli.services$_main.doInvoke(services.clj:394)
 at clojure.lang.RestFn.invoke(RestFn.java:421)
 at clojure.lang.Var.invoke(Var.java:419)
 at clojure.lang.AFn.applyToHelper(AFn.java:163)
 at clojure.lang.Var.applyTo(Var.java:532)
 at clojure.core$apply.invoke(core.clj:601)
 at com.puppetlabs.puppetdb.core$_main.doInvoke(core.clj:79)
 at clojure.lang.RestFn.applyTo(RestFn.java:137)
 at com.puppetlabs.puppetdb.core.main(Unknown Source)
 2013-07-12 11:57:47,759 INFO  [Thread-4] [cli.services] Shutdown request 
 received; puppetdb exiting.


-- 
You received this message because you are subscribed to the Google Groups 
Puppet

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate

2013-07-17 Thread Yaniv Kaul

On Wednesday, July 17, 2013 6:00:49 PM UTC+3, jcbollinger wrote:



 On Tuesday, July 16, 2013 4:32:35 PM UTC-5, Forrie wrote:

 We are not configured to auto-sign certificates.

 Clearly, the client is making a connection to the master:


 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/
 de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - -
 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/
 de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - -
 10.101.0.10 - - [16/Jul/2013:17:23:46 -0400] GET /production/certificate/
 de-prod-archive.ourdomain.com? HTTP/1.1 404 62 - -

 Correct, our Master is upgraded to the latest Puppet 3.2.3, as is this 
 particular agent.   I've tried starting clean/fresh on the agent (removing 
 /var/lib/puppet) and that has no effect.   The older clients are working 
 just fine.

 puppet cert list, continues to not see the inbound request from this 
 particular agent.



 Well, that at least narrows it down.  The master is not recognizing the 
 client's certificate-signing request, or is refusing to service it.  Does 
 the master already have a signed certificate for this client (or at least 
 one bearing the requested certname)?  puppet cert list --all should tell 
 you.

 If so, then there are two possibilities:
 (1) the master signed the current client's current certificate, but is 
 refusing to serve up the signed certificate.  This seems unlikely to me, 
 but it cannot be altogether discounted.
 (2) the signed certificate does not correspond to the certificate-signing 
 request currently being presented by the agent (maybe it is an old cert 
 signed for a different machine with the same name), so the master refuses 
 to provide it to the agent.

 If (2) applies, then you should revoke then remove the old cert via 
 puppet cert, then try again to connect the agent.

 Alternatively, is there any chance you have multiple copies of the master 
 installed?  (Maybe one via RPM and a separate one via gem?)  If that's the 
 case, then perhaps the master the agent is talking to is different from the 
 one that comes first in your shell's executable path.  That could wreak all 
 sorts of havoc, including misleading you about the relevant certs and CSRs.


 John


How do I verify if multiple copies are installed? I'm using Foreman to 
manage the puppet master on the same host, but I don't think it has caused 
any issues. I don't think #1 above is what happened to me - I've tried with 
a completely new client.
I must emphasize that apart from the CA's certificate, I'm not seeing 
anything under 'puppet cert --list --all'.
Is there any debug flag I can enable to provide debug output on the master 
for the signing process?

Y. 

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

[Puppet Users] Choosing provider by properties?

2013-07-17 Thread Jakov Sosic

Hi,

is it possible to choose the provider based on property?

For example, I'm trying to develop two different providers for same type
of resource. If i use path location on the local filesystem I want
provider local to be chosen, and if I use link property, then I want
provider remote to be chosen.

For example, this definition should chose provider 'local':

resource { 'a':
  path = '/some/local/disk.iso',
}


And this definition should chose provider 'remote':

resource { 'a':
  link = 'http://example.com/disk.iso',
}

Is this possible without manually specifying provider = remote?




Also, second question. It would be great if puppet could raise error in
case when both conflicting properties are set. For example this should
yeild an error:

resource { 'a':
  path = '/some/local/disk.iso',
  link = 'http://example.com/disk.iso',
}

Is this possible?


If these questions are more suitable to puppet-dev list, I will post
them there. Thank you guys.

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

[Puppet Users] Re: Windows Issue: Package ensure: change from absent to present failed



On Wednesday, July 17, 2013 10:39:51 AM UTC-6, Josh Cooper wrote:


 Based on http://www.python.org/download/releases/2.5/msi/ I think python 
 is only being installed for the current user, not all users. You'll have to 
 specify ALLUSERS=1 to get that behavior. I don't see this explicitly called 
 out in our docs 
 http://docs.puppetlabs.com/windows/writing.html#packagepackage but it 
 should be. Could you file a ticket?


Ok, I changed the rule to:
  package { 'Python 2.7.5 (64-bit)':
ensure  = installed,
source  = 
'\\server\share\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi',
install_options = [{ 'TARGETDIR' = 'C:\Python27' }, {'ALLUSERS' = 
'1' }],
require = [Package['MinGW-W64 version 4.5.3'], Package['Cygwin 
version 1.7.15']],
  }  


I also removed the existing install, so Python is not on my machine.  After 
restarting the service, I got the same exact error and stack trace.  I 
verified that ALLUSERS=1 was passed in.

Puppet - Information 1
Executing 'msiexec.exe /qn /norestart /i 
\\server\share\Python\python-2.7.5.amd64.msi TARGETDIR=C:\Python27 
ALLUSERS=1'


Puppet - Error 3
Failed to install:  Fail on INT 24.
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:99:in 
`check_result'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:64:in `install'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/type/package.rb:67:in `block (3 levels) in 
module:Puppet'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/property.rb:197:in `call_valuemethod'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/property.rb:498:in `set'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/property.rb:581:in `sync'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:114:in 
`apply_parameter'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:56:in 
`perform_changes'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:139:in 
`evaluate'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:48:in `apply'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:83:in `eval_resource'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block (2 levels) in 
evaluate'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:351:in 
`block in thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:350:in 
`thinmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block in evaluate'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:382:in `traverse'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/transaction.rb:98:in `evaluate'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/resource/catalog.rb:146:in `apply'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:122:in `block in apply_catalog'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:179:in 
`block in benchmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:178:in 
`benchmark'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:121:in `apply_catalog'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/configurer.rb:179:in `run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (5 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (4 levels) in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
`block (3 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:119:in 
`with_client'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:42:in 
`block (2 levels) in run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:84:in 
`run_in_fork'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in 
`block in run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in 
`run'
C:/Program Files (x86)/Puppet 
Labs/Puppet/puppet/lib/puppet/application/agent.rb:353:in `onetime'
C:/Program Files (x86)/Puppet

RE: [Puppet Users] Announce: Puppet 3.2.3 Available

2013-07-17 Thread Kent R. Spillner

 3.2.3 is a bugfix release of the Puppet 3.2 series. It fixes some
 Windows bugs introduced in 3.2.0, as well as a few performance
 problems and miscellaneous bugs.
 
 ===
 ## Puppet 3.2.3 Downloads ##
 ===
 
 Source: https://downloads.puppetlabs.com/puppet/puppet-3.2.3.tar.gz
 
 RPM and deb packages available in the Puppet Labs repositories at:
 http://yum.puppetlabs.com and http://apt.puppetlabs.com
 
 Gems are available via rubygems at
 https://rubygems.org/downloads/puppet-3.2.3.gem
   or by using `gem install puppet`
 
 Mac package is available at
 https://downloads.puppetlabs.com/mac/puppet-3.2.3.dmg
 
 Windows package is available at
 https://downloads.puppetlabs.com/windows/puppet-3.2.3.msi

I created an Omnibus installer for Puppet at 
https://github.com/sl4mmy/omnibus-puppet for others who can't find an official 
package for their preferred platform.

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate



[ ... ]
 Well, that at least narrows it down.  The master is not recognizing the 
 client's certificate-signing request, or is refusing to service it.  Does 
 the master already have a signed certificate for this client (or at least 
 one bearing the requested certname)?  puppet cert list --all should tell 
 you.


There are no other certificates for this new system.  I checked recursively 
in the ssl directory, just to be sure.
 

 If so, then there are two possibilities:
 (1) the master signed the current client's current certificate, but is 
 refusing to serve up the signed certificate.  This seems unlikely to me, 
 but it cannot be altogether discounted.


Not the case.
 

 (2) the signed certificate does not correspond to the certificate-signing 
 request currently being presented by the agent (maybe it is an old cert 
 signed for a different machine with the same name), so the master refuses 
 to provide it to the agent.

 If (2) applies, then you should revoke then remove the old cert via 
 puppet cert, then try again to connect the agent.

 


 Alternatively, is there any chance you have multiple copies of the master 
 installed?  (Maybe one via RPM and a separate one via gem?)  If that's the 
 case, then perhaps the master the agent is talking to is different from the 
 one that comes first in your shell's executable path.  That could wreak all 
 sorts of havoc, including misleading you about the relevant certs and CSRs.


There is only one master running, one agent:

 1149 ?S  1:19 Passenger RackApp: /etc/puppet/rack/puppetmasterd
 6946 ?Ss 0:03 /usr/local/bin/ruby /usr/local/bin/puppet agent

What strikes me as odd is this is a fresh system that was installed; 
there's nothing particularly special about it, other than it's CentOS 6.x 
versus CentOS 5.x which are most of the others.   It seems one other person 
posted here who is experiencing similar problems.

What I'm willing to do, as a test case, is configure to new VMs and try a 
proof-of-bug-or-concept with this.  The setup will be simple, one master 
and one agent; the cert request should be accepted and then manually 
signed.Though, I think my present configuration is simple enough.


Thanks.
 

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

[Puppet Users] Enterprise Puppet 3 with AIX WPAR support

2013-07-17 Thread Larry Sybrandt

Hello All

Just wondering where to manage an AIX server with multiple WPARS.  At the 
host level or at each guest level?

It seems like one way would be easier than another.  I just can't figure 
out which one that is.

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

[Puppet Users] Re: Windows Issue: Package ensure: change from absent to present failed



On Wednesday, July 17, 2013 11:33:51 AM UTC-7, Josh D wrote:



 On Wednesday, July 17, 2013 10:39:51 AM UTC-6, Josh Cooper wrote:


 Based on http://www.python.org/download/releases/2.5/msi/ I think python 
 is only being installed for the current user, not all users. You'll have to 
 specify ALLUSERS=1 to get that behavior. I don't see this explicitly called 
 out in our docs 
 http://docs.puppetlabs.com/windows/writing.html#packagepackage but it 
 should be. Could you file a ticket?


 Ok, I changed the rule to:
   package { 'Python 2.7.5 (64-bit)':
 ensure  = installed,
 source  = 
 '\\server\share\Tools\Puppet\win64\Python\python-2.7.5.amd64.msi',
 install_options = [{ 'TARGETDIR' = 'C:\Python27' }, {'ALLUSERS' = 
 '1' }],
 require = [Package['MinGW-W64 version 4.5.3'], 
 Package['Cygwin version 1.7.15']],
   }  


 I also removed the existing install, so Python is not on my machine. 
  After restarting the service, I got the same exact error and stack trace. 
  I verified that ALLUSERS=1 was passed in.

 Puppet - Information 1
 Executing 'msiexec.exe /qn /norestart /i 
 \\server\share\Python\python-2.7.5.amd64.msi TARGETDIR=C:\Python27 
 ALLUSERS=1'


 Puppet - Error 3
 Failed to install:  Fail on INT 24.
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:99:in 
 `check_result'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/provider/package/windows.rb:64:in `install'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/type/package.rb:67:in `block (3 levels) in 
 module:Puppet'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/property.rb:197:in `call_valuemethod'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/property.rb:498:in `set'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/property.rb:581:in `sync'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:114:in 
 `apply_parameter'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:56:in 
 `perform_changes'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction/resource_harness.rb:139:in 
 `evaluate'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction.rb:48:in `apply'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction.rb:83:in `eval_resource'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block (2 levels) in 
 evaluate'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:351:in 
 `block in thinmark'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:350:in 
 `thinmark'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction.rb:103:in `block in evaluate'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction.rb:382:in `traverse'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/transaction.rb:98:in `evaluate'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/resource/catalog.rb:146:in `apply'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/configurer.rb:122:in `block in apply_catalog'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:179:in 
 `block in benchmark'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:178:in 
 `benchmark'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/configurer.rb:121:in `apply_catalog'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/configurer.rb:179:in `run'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
 `block (5 levels) in run'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
 `block (4 levels) in run'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:45:in 
 `block (3 levels) in run'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:42:in 
 `block (2 levels) in run'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:84:in 
 `run_in_fork'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in 
 `block in run'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/application.rb:179:in `call'
 C:/Program Files (x86)/Puppet 
 Labs/Puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
 C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in 
 `run'

[Puppet Users] Re: Windows Issue: Package ensure: change from absent to present failed

On Wednesday, July 17, 2013 1:56:42 PM UTC-6, Josh Cooper wrote:


 Another user had to modify the NTFS and Share permissions for 'Domain 
 Computers' to access the share (map the drive)[2]. This is because 
 LocalSystem doesn't have any credentials with which to access the network.

 Josh

 [1] https://groups.google.com/d/msg/puppet-users/86dBOxvirK0/I6CtTH_BGEgJ
 [2] https://groups.google.com/d/topic/puppet-users/xoJpt6ARe0Y/discussion


I think that's the issue:
G:\Tools\Puppet\win64\Pythonpsexec -i -s msiexec.exe /qn /norestart /i 
\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi 
TARGETDIR=C:\Python27 ALLUSERS=1

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com


msiexec.exe exited on SSCLD134G82G with error code 1619. 



Side note, I think the error code (1619) isn't getting picked up by Puppet 
correctly.  So I'm trying to weigh my options.  I'm a lowly developer and 
can't muck with domain users, nor can I change the security permissions on 
any of the CIFS network shares.  Running puppet agent manually, works on my 
test machine because I'm local admin, but won't work for other users who 
aren't.  I think I've tried copying installers using a File resource and 
then requiring and installing from said file in a package, but I recall 
that causing issues.

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

Re: [Puppet Users] Enterprise Puppet 3 with AIX WPAR support

2013-07-17 Thread Michael Stahnke

On Wed, Jul 17, 2013 at 12:33 PM, Larry Sybrandt lsybra...@gmail.com wrote:
 Hello All

 Just wondering where to manage an AIX server with multiple WPARS.  At the
 host level or at each guest level?

 It seems like one way would be easier than another.  I just can't figure out
 which one that is.

I played with this a bit over the last few weeks. You have a few
options, if I understand your question correctly.

Making a wpar with a shared /opt and /usr  will allow you to use the
same PE...sort of. It's a little bit odd.  With wpars that share /usr
and /opt, you basically run puppet enterprise on the ring0 (for lack
of a better term) node, you could update items within the WPAR volume.

So, I am not sure which one is better either. I certainly would be
interested to hear your use cases or ideas, as I found it WPARs to be
a bit odd to work with on the whole as well.

Mike



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



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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate

I'm seeing this error in the logs:

Jul 17 16:37:17 server puppet-agent[17835]: (/File[/var/lib/puppet/lib]) 
Could not evaluate: Could not retrieve information from environment 
production source(s) puppet:/server.ourdomain.com/plugins

But I don't believe this is connected to the aforementioned problem.   This 
was a 2.x system upgraded to 3.x.   We went through the painful allow vs 
allow_ip issue, and everything seems to be working.  I did a diff of the 
GIT puppet repository conf/auth.conf and ours is identical.   The only 
difference we have presently (until I rewrite a bunch of stuff) is in 
fileserver.conf:

[files]
path/etc/puppet/files
# allow *
allow_ip10.101.0.0/24
allow_ip10.103.0.0/24

We have a bunch of stuff we replicate from that location; again, it seems 
to be working fine for the older clients.

I also verified that the output of puppet master --configprint=certname 
indeed matches the servername variable in our puppet.conf file(s).

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate



On Wednesday, July 17, 2013 2:33:22 PM UTC-5, Forrie wrote:



 [ ... ]
 Well, that at least narrows it down.  The master is not recognizing the 
 client's certificate-signing request, or is refusing to service it.  Does 
 the master already have a signed certificate for this client (or at least 
 one bearing the requested certname)?  puppet cert list --all should tell 
 you.


 There are no other certificates for this new system.  I checked 
 recursively in the ssl directory, just to be sure.
  

 If so, then there are two possibilities:
 (1) the master signed the current client's current certificate, but is 
 refusing to serve up the signed certificate.  This seems unlikely to me, 
 but it cannot be altogether discounted.


 Not the case.
  

 (2) the signed certificate does not correspond to the certificate-signing 
 request currently being presented by the agent (maybe it is an old cert 
 signed for a different machine with the same name), so the master refuses 
 to provide it to the agent.

 If (2) applies, then you should revoke then remove the old cert via 
 puppet cert, then try again to connect the agent.

  


 Alternatively, is there any chance you have multiple copies of the master 
 installed?  (Maybe one via RPM and a separate one via gem?)  If that's the 
 case, then perhaps the master the agent is talking to is different from the 
 one that comes first in your shell's executable path.  That could wreak all 
 sorts of havoc, including misleading you about the relevant certs and CSRs.


 There is only one master running, one agent:

  1149 ?S  1:19 Passenger RackApp: 
 /etc/puppet/rack/puppetmasterd
  6946 ?Ss 0:03 /usr/local/bin/ruby /usr/local/bin/puppet agent



Were I you, I would shut down the puppet agent on the master's system, and 
test only with a separate client until you get things sorted out.

 


 What strikes me as odd is this is a fresh system that was installed; 
 there's nothing particularly special about it, other than it's CentOS 6.x 
 versus CentOS 5.x which are most of the others.   It seems one other person 
 posted here who is experiencing similar problems.



I still say the problem is more likely with the master than with the 
agent.  My working hypothesis is that when you upgraded the master to v3.2 
you broke its certificate-signing functionality.  Supposing that the 
master's CA certificate was carried over during the upgrade, clients that 
already have certificates don't need new certs, so they continue to work.  
(And if the CA cert had not been carried over then all existing clients 
would have needed new certs.)  New clients do need signed certs before they 
can retrieve catalogs, however, so the clients you are trying to deploy now 
do not work.  By this logic, no new client deployment will work against 
this master, whether it's Puppet3/Cent6, Puppet2/Cent5, or even 
Puppet3/Cent5.  It is therefore irrelevant how similar your new client 
systems are to the ones already in operation.


John

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate



 I still say the problem is more likely with the master than with the 
 agent.  My working hypothesis is that when you upgraded the master to v3.2 
 you broke its certificate-signing functionality.  Supposing that the 
 master's CA certificate was carried over during the upgrade, clients that 
 already have certificates don't need new certs, so they continue to work.  
 (And if the CA cert had not been carried over then all existing clients 
 would have needed new certs.)  New clients do need signed certs before they 
 can retrieve catalogs, however, so the clients you are trying to deploy now 
 do not work.  By this logic, no new client deployment will work against 
 this master, whether it's Puppet3/Cent6, Puppet2/Cent5, or even 
 Puppet3/Cent5.  It is therefore irrelevant how similar your new client 
 systems are to the ones already in operation.


Curious, how could I break the CA certificate-signing functionality by 
upgrading?  Wouldn't that be a bug in the upgrade process?

I can install a fresh version of Puppet and see if that works - but, I have 
too many nodes and thus I need to retain the current certificates that are 
signed.
 

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate



On Wednesday, July 17, 2013 12:25:18 PM UTC-5, Yaniv Kaul wrote:


 How do I verify if multiple copies are installed?



I would suggest using the 'find' command on the master to look for files 
and directories named 'puppet'.  Make sure all the results belong to the 
same Puppet install.  In your case you might pass their full names to rpm 
-q -f to verify that they all come from one or another of your installed 
RPMs.  I don't know whether Forrie installed from RPM; if not, then that 
part of it will need to be different for him.

 

 I'm using Foreman to manage the puppet master on the same host, but I 
 don't think it has caused any issues. I don't think #1 above is what 
 happened to me - I've tried with a completely new client.
 I must emphasize that apart from the CA's certificate, I'm not seeing 
 anything under 'puppet cert --list --all'.
 Is there any debug flag I can enable to provide debug output on the master 
 for the signing process?


If you are running the master as a standalone daemon (i.e. using its 
built-in webrick server) then you should be able to start it as

puppet master --debug

to enable debug logging.  If you are running the master under Passenger, 
then you may be able to turn on debug logging by modifying your config.ru 
file to pass the --debug option to the master.


John

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate



On Wednesday, July 17, 2013 4:24:13 PM UTC-5, Forrie wrote:


 I still say the problem is more likely with the master than with the 
 agent.  My working hypothesis is that when you upgraded the master to v3.2 
 you broke its certificate-signing functionality.  Supposing that the 
 master's CA certificate was carried over during the upgrade, clients that 
 already have certificates don't need new certs, so they continue to work.  
 (And if the CA cert had not been carried over then all existing clients 
 would have needed new certs.)  New clients do need signed certs before they 
 can retrieve catalogs, however, so the clients you are trying to deploy now 
 do not work.  By this logic, no new client deployment will work against 
 this master, whether it's Puppet3/Cent6, Puppet2/Cent5, or even 
 Puppet3/Cent5.  It is therefore irrelevant how similar your new client 
 systems are to the ones already in operation.


 Curious, how could I break the CA certificate-signing functionality by 
 upgrading?  Wouldn't that be a bug in the upgrade process?



In principle, the upgrade could break certificate signing any number of 
ways.  Whether such an event would constitute a bug depends in part on 
whether yours was a supported upgrade path, but in any event, you cannot 
discount bugs.

You haven't said how your Puppet master was installed originally or how it 
was upgraded.  You did originally say that your agents were installed as 
gems, and a recent message added the information that one of those agents 
is on the same system as the master, so I suppose that the master is 
provided as part of the same gem.

But wait.  You said that the problematic agents were on new-built systems.  
Have you then transferred the master to a new / rebuilt host as part of 
this process?  (What could possibly go wrong?)

Alternatively, I didn't notice you responding to the possibility that you 
have two separate Puppet installs.  Did you check?


John

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

[Puppet Users] Re: err: Could not call list: header too long

2013-07-17 Thread rleelink

For what it is worth, I also was running into same error, and removed a 
zero byte cert file and the problem went away.

Only in my case, the zero byte file was in /var/puppet/ssl/ca/signed

Thanks, Jason!

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

[Puppet Users] Re: 3.2.2 on CentOS 6.3, and Did not receive certificate

I do not have separate Puppet installs.  At the moment, it's been installed 
via the Gem, so the master and agent are coming from the same code, running 
on the original host (it was not rebuilt).   It is running under 
Passenger/Apache, presently.


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

Re: [Puppet Users] Announce: Puppet 3.2.3 Available

2013-07-17 Thread Justin Brown

Moses,

The Fedora 19 packages have not been updated. Could you issue packages for
http://yum.puppetlabs.com/fedora/f19/?

Thanks,
Justin


On Mon, Jul 15, 2013 at 2:18 PM, Moses Mendoza mo...@puppetlabs.com wrote:

 3.2.3 is a bugfix release of the Puppet 3.2 series. It fixes some
 Windows bugs introduced in 3.2.0, as well as a few performance
 problems and miscellaneous bugs.

 ===
 ## Puppet 3.2.3 Downloads ##
 ===

 Source: https://downloads.puppetlabs.com/puppet/puppet-3.2.3.tar.gz

 RPM and deb packages available in the Puppet Labs repositories at:
 http://yum.puppetlabs.com and http://apt.puppetlabs.com

 Gems are available via rubygems at
 https://rubygems.org/downloads/puppet-3.2.3.gem
   or by using `gem install puppet`

 Mac package is available at
 https://downloads.puppetlabs.com/mac/puppet-3.2.3.dmg

 Windows package is available at
 https://downloads.puppetlabs.com/windows/puppet-3.2.3.msi

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

 
 ## Puppet 3.2.3 Contributors ##
 

 Adrien Thebo, Andrew Parker, Dustin J. Mitchell, Josh Cooper, Josh
 Partlow, Justin Stoller, Matthaus Owens, Moses Mendoza, Nick
 Fagerlund, Patrick Carlisle

 =
 ## Puppet 3.2.3 Release Notes ##
 =

 ### Windows Fixes

 This release fixes several Windows bugs that couldn't be targeted for
 earlier 3.2 releases.

 * [#20768: windows user provider can not manage password or home
 directory](https://projects.puppetlabs.com/issues/20768) --- This was
 a regression in 3.2.0/3.2.1.
 * [#21043: setting in puppet.conf ignored on Windows in Puppet
 3.2.1](https://projects.puppetlabs.com/issues/21043) --- This was a
 regression in 3.2.0/3.2.1.
 * [#16080: Service provider broken in Windows Server
 2012](https://projects.puppetlabs.com/issues/16080) --- This affected
 all previous Puppet versions.
 * [#20787: 'puppet resource group' takes incredibly long on
 Windows](https://projects.puppetlabs.com/issues/20787) --- This
 affected all previous Puppet versions.
 * [#20302: Windows File.executable? now returns false on ruby
 1.9](https://projects.puppetlabs.com/issues/20302)
 * [#21280: Don't create c:\dev\null in windows
 specs](https://projects.puppetlabs.com/issues/21280) --- This was only
 relevant to Puppet developers.

 ### Logging and Reporting Fixes

 * [#20383: Bring back helpful error messages like prior to Puppet
 3](https://projects.puppetlabs.com/issues/20383) --- This was a
 regression from 3.0.0, which caused file names and line numbers to
 disappear from duplicate resource declaration errors.
 * [#20900: tagmail triggers in --onetime mode without changes after
 upgrade from 3.1.1 to
 3.2.1](https://projects.puppetlabs.com/issues/20900) --- This was a
 regression in 3.2.0/3.2.1.
 * [#20919: Logging behaviour issues in
 3.2.1](https://projects.puppetlabs.com/issues/20919) --- This was a
 regression in 3.2.0/3.2.1, which caused noisy logging to the console
 even if the `--logdest` option was set.

 ### Performance Fixes

 * [#21376: Stack level too deep after updating from 3.1.1 to
 3.2.2](https://projects.puppetlabs.com/issues/21376) --- This would
 sometimes cause total failures when importing a large number of
 manifest files (such as with the `import nodes/*.pp` idiom).
 * [#21320: Puppet daemon may sleep for 100 years after receiving USR1
 on 64 bit systems](https://projects.puppetlabs.com/issues/21320) ---
 MCollective's Puppet plugin uses puppet agent's USR1 signal to trigger
 a run if the agent is running; on 64-bit systems, this could cause
 puppet agent to keep running, but stop doing scheduled configuration
 runs. This was caused by a bug in Ruby \ 2.0, but we modified Puppet
 to work around it.
 * [#20901: `puppet --version` is unnecessarily
 slow](https://projects.puppetlabs.com/issues/20901) --- This was a
 regression in 3.2.0/3.2.1.

 ### Misc Fixes

 * [#21264: parser = future breaks executing functions as class
 defaults](https://projects.puppetlabs.com/issues/21264)

 ### All 3.2.3 Changes

 [See here for a list of all changes in the 3.2.3
 release.](https://projects.puppetlabs.com/versions/410)

 ==
 ## Puppet 3.2.3 Changelog ##
 ==

 Adrien Thebo (1):
   6a0127f (#20383) Provide location of duplicate resource in error

 Andrew Parker (2):
   f19c8f2 (Maint) Cleanup specs
   ec6b51a (#21264) Update rgen dependency to 0.6.5

 Dustin J. Mitchell (1):
   b1a5092 clean up docs for new parser functions

 Josh Cooper (16):
   b4f84e1 (#20787) Do not generate NetBIOS name service requests
   ba3c4c2 Revert Merge pull request #1478 from
 dsd/fix/master/18781-webrick-old-client-compat
   694f97d (#20302) Windows ruby 1.8 workarounds are not necessary in
 1.9
   ca8602e (#20302) Append .exe to spec

[Puppet Users] Puppetmaster 3.2.3 logging different than previous versions

2013-07-17 Thread Cory Stoker

Hello:

After upgrading to Puppet 3.2.3 I have noticed that the puppetmaster does 
not log the catalog compilation time like it did in 3.1.1 or before.  This 
log line used to look like:
myserver puppet-master[19002]: Compiled catalog for myhost in environment 
production in 1.01 seconds

Even if I change the logging level to debug in the rack config I do not see 
this line.  Anyone else notice this as well?  This could be related to the 
previous logging issues with 3.2 as 
in http://projects.puppetlabs.com/issues/20919  .  If this is an intended 
change, what is the best way to get the catalog compile time as this can be 
important information in regard to how the puppetmaster is performing.

Thanks,
Cory

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

[Puppet Users] Unable to use Cloud Provisioner

2013-07-17 Thread shivaraj mathrubai


Hi Guys, 

I'm unable to load the module cloud provisioner, when I try to run node_aws 
it gives me the below errors:

Error: Could not autoload puppet/face/node_aws/list_keynames: no such file 
to load -- guid
Error: Could not parse application options: Could not autoload 
puppet/face/node_aws/list_keynames: no such file to load -- guid

And when I see the help list I can see the below message:

! node! Subcommand unavailable due to error. Check error logs.
  ! node_aws! Subcommand unavailable due to error. Check error logs.

I'm using Puppet 3.2.3 and Ruby 1.9.2

Any hint to fix this ?

Thanks in advance !




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

[Puppet Users] Re: Unable to use Cloud Provisioner

2013-07-17 Thread shivaraj mathrubai

I'm using CentOS

On Thursday, 18 July 2013 00:21:52 UTC+1, shivaraj mathrubai wrote:


 Hi Guys, 

 I'm unable to load the module cloud provisioner, when I try to run 
 node_aws it gives me the below errors:

 Error: Could not autoload puppet/face/node_aws/list_keynames: no such file 
 to load -- guid
 Error: Could not parse application options: Could not autoload 
 puppet/face/node_aws/list_keynames: no such file to load -- guid

 And when I see the help list I can see the below message:

 ! node! Subcommand unavailable due to error. Check error logs.
   ! node_aws! Subcommand unavailable due to error. Check error 
 logs.

 I'm using Puppet 3.2.3 and Ruby 1.9.2

 Any hint to fix this ?

 Thanks in advance !






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

[Puppet Users] best way override variables of parent providers?

2013-07-17 Thread Schofield

I would like to override an instance variable of a parent custom provider.  
Is it safe to override to the initialize method in the subclass in order 
override the instance variable?  Or is there a better way to do this when 
writing custom providers?

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

Re: [Puppet Users] Re: Unable to use Cloud Provisioner

2013-07-17 Thread Justin Stoller

On Wed, Jul 17, 2013 at 4:23 PM, shivaraj mathrubai
me.shiva...@gmail.comwrote:

 I'm using CentOS


 On Thursday, 18 July 2013 00:21:52 UTC+1, shivaraj mathrubai wrote:


 Hi Guys,

 I'm unable to load the module cloud provisioner, when I try to run
 node_aws it gives me the below errors:

 Error: Could not autoload puppet/face/node_aws/list_**keynames: no such
 file to load -- guid
 Error: Could not parse application options: Could not autoload
 puppet/face/node_aws/list_**keynames: no such file to load -- guid

 Hrm, it looks like it can't find a dependency...  Can you `yum install
rubygem-guid` ?


 And when I see the help list I can see the below message:

 ! node! Subcommand unavailable due to error. Check error logs.
   ! node_aws! Subcommand unavailable due to error. Check error
 logs.

 I'm using Puppet 3.2.3 and Ruby 1.9.2

 Any hint to fix this ?

 Thanks in advance !




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






-- 

Join us at PuppetConf 2013, August 22-23 in San Francisco -
http://bit.ly/pupconf13

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

[Puppet Users] Re: Puppetmaster 2.7.18-5

2013-07-17 Thread Michael Dodwell

I found 2.7 had a memory leak(s). If you wish to run as web brick I'd 
suggest restarting on a daily basis.

I haven't ran 3.x as web brick so I'm unsure if it's still a problem, 
running puppet master with apache phusion has solved a lot of those 
problems for me.



On Tuesday, July 16, 2013 9:52:24 PM UTC+10, setests setests wrote:

 Hi

 I am running Puppet version 2.7.18-5 with around ~ 100 nodes syncing with 
 the server with the defaults of half an hour.  Is it normal for the 
 puppetmaster service to take around ~ *3GB* of RAM.

 # cat /etc/debian_version
 7.1
 # dpkg --list | grep -i puppet
 ii  puppet-common  2.7.18-5  all   
Centralized configuration management
 ii  puppetmaster   2.7.18-5  all   
Centralized configuration management - master startup and compatibility 
 scripts
 ii  puppetmaster-common2.7.18-5  all   
Puppet master common scripts
 ii  vim-puppet 2.7.18-5  all   
syntax highlighting for puppet manifests in vim

 # top | head -n7
 top - 05:51:16 up 16:45,  2 users,  load average: 1.00, 0.99, 0.87
 Tasks: 101 total,   2 running,  99 sleeping,   0 stopped,   0 zombie
 %Cpu(s):  6.1 us,  0.1 sy,  0.0 ni, 93.8 id,  0.0 wa,  0.0 hi,  0.0 si, 
  0.0 st
 KiB Mem:   6117052 total,  5807676 used,   309376 free,69100 buffers
 KiB Swap:0 total,0 used,0 free,  2348596 cached

   PID USER  PR  NI  VIRT  RES  SHR S  %CPU %MEMTIME+  COMMAND
 # top | grep -i puppet
  4161 puppet  20   0 *3198m* 3.0g 3256 R  98.6 52.1 183:16.28 puppet
  4161 puppet  20   0 *3198m* 3.0g 3256 R  99.8 52.1 183:19.28 puppet
 ~# free -h
 total   used   free sharedbuffers 
 cached
 Mem:  5.8G   5.5G   *330M* 0B67M   
 2.2G
 -/+ buffers/cache:   3.2G   2.6G
 Swap:   0B 0B 0B

 Now let me stop my puppetmaster to show that memory is in fact getting 
 freed up.

 # /etc/init.d/puppetmaster stop
 [ ok ] Stopping puppet master.
 # ps aux | grep -i puppet
 root  9438  0.0  0.0   7828   892 pts/1S+   05:52   0:00 grep -i 
 puppet
 # free -h
total   used   free sharedbuffers 
 cached
 Mem:  5.8G   2.5G   *3.3G *0B67M   
 2.2G
 -/+ buffers/cache:   193M   5.6G
 Swap:   0B 0B 0B
 #



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

[Puppet Users] Welcome Cloudsmith to Puppet Labs!

2013-07-17 Thread Nigel Kersten

Some of you will already be familiar with Cloudsmith products such as
Geppetto, an IDE for Puppet modules, and some of you may be familiar with
the excellent work Cloudsmith folks like Henrik have done in areas like the
Puppet core parser.

We've been working together for a while now, and today we're thrilled to
announce the acquisition of Cloudsmith into the Puppet Labs family.


There is more about the acquisition on our blog:
https://puppetlabs.com/blog/cloudsmith-joins-puppet-labs/

For more info about the Puppet Module IDE Geppetto:


Geppetto: A Puppet IDE (blog)
http://bit.ly/12VlbCf

Geppetto 3.0 Overview (video)
http://bit.ly/12wsqR8

Geppetto, A Puppet IDE and Your Favorite Backseat Driver (podcast)
http://bit.ly/12Kz0SW



cheers,

Nigel Kersten

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

Re: [Puppet Users] Re: Windows Issue: Package ensure: change from absent to present failed

On Wed, Jul 17, 2013 at 1:29 PM, Josh D joshuadavid...@gmail.com wrote:

On Wednesday, July 17, 2013 1:56:42 PM UTC-6, Josh Cooper wrote:

Another user had to modify the NTFS and Share permissions for 'Domain
Computers' to access the share (map the drive)[2]. This is because
LocalSystem doesn't have any credentials with which to access the network.

Josh

[1] https://groups.google.com/**d/msg/puppet-users/**
86dBOxvirK0/I6CtTH_BGEgJhttps://groups.google.com/d/msg/puppet-users/86dBOxvirK0/I6CtTH_BGEgJ
[2] https://groups.google.com/**d/topic/puppet-users/**
xoJpt6ARe0Y/discussionhttps://groups.google.com/d/topic/puppet-users/xoJpt6ARe0Y/discussion

I think that's the issue:
G:\Tools\Puppet\win64\Pythonpsexec -i -s msiexec.exe /qn /norestart /i
\\server\share\Puppet\win64\Python\python-2.7.5.amd64.msi
TARGETDIR=C:\Python27 ALLUSERS=1

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

msiexec.exe exited on SSCLD134G82G with error code 1619.

This exit code means This installation package could not be opened. Verify
that the package exists and that you can access it.[1]

Side note, I think the error code (1619) isn't getting picked up by Puppet
correctly.

Yes, ruby truncates windows exit codes to a single byte[2]

C:\work\puppetruby --version
ruby 1.9.3p374 (2013-01-15) [i386-mingw32]
C:\work\puppetruby -e %x{cmd.exe /c exit 1619}; puts $?.exitstatus
83

where 1619 = 0x653 and 83 = 0x53

A fellow puppet user has tried to work around this in the dism module[3]. I
would hate to see this proliferate across modules, surely ruby will fix
this, though I can't understand why the ticket is marked as a feature.

So I'm trying to weigh my options. I'm a lowly developer and can't muck
with domain users, nor can I change the security permissions on any of the
CIFS network shares. Running puppet agent manually, works on my test
machine because I'm local admin, but won't work for other users who aren't.
I think I've tried copying installers using a File resource and then
requiring and installing from said file in a package, but I recall that
causing issues.

In the windows world, you'll either need to modify the network shares
(which you can't do), configure the puppet agent service to run as a domain
user that does have permission (not sure if that's an option for you), or
serve the packages through some other means, e.g. puppet master file
server[4], apache, etc.

Josh

[1] http://support.microsoft.com/kb/290158
[2] https://bugs.ruby-lang.org/issues/8083
[3] https://github.com/puppetlabs/puppetlabs-dism/pull/14
[4] http://docs.puppetlabs.com/guides/file_serving.html

--
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Final Countdown discount - save
15%!*

[Puppet Users] Re: Welcome Cloudsmith to Puppet Labs!

2013-07-17 Thread Niels Abspoel

Congratulations,

I think this is very good news for the community.


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

[Puppet Users] Re: PUPPETDB and pgpool II

2013-07-17 Thread Jared Curtis

This error means the client is disconnecting without sending an I'm 
Disconnecting packet.

If the client is the puppet master then you probably should file a bug report.

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

Re: [Puppet Users] Re: Weird encoding error: 0xF3 to UTF-8 in conversion from ASCII...

On Tue, Jul 2, 2013 at 12:52 AM, Álvaro Acción - CiTIUS 
alvaroaccionmon...@gmail.com wrote:

 The output I get is this one:

 C:\Program Files (x86)\Puppet Labs\Puppet\binpuppet.bat agent
 --server=pupbuntu
 .inv.usc.es --no-daemonize --verbose --debug --trace
 Could not retrieve domain: undefined method `gsub' for nil:NilClass
 Could not retrieve domain: undefined method `gsub' for nil:NilClass
 Could not retrieve domain: undefined method `gsub' for nil:NilClass
 Debug: Failed to load library 'syslog' for feature 'syslog'
 Debug: Failed to load library 'selinux' for feature 'selinux'
 Debug: Using settings: adding file resource 'confdir':
 'File[C:/ProgramData/Pupp
 etLabs/puppet/etc]{:path=C:/ProgramData/PuppetLabs/puppet/etc,
 :ensure=:dire
 ctory, :loglevel=:debug, :links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'vardir':
 'File[C:/ProgramData/Puppe
 tLabs/puppet/var]{:path=C:/ProgramData/PuppetLabs/puppet/var,
 :ensure=:direc
 tory, :loglevel=:debug, :links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'logdir':
 'File[C:/ProgramData/Puppe
 tLabs/puppet/var/log]{:path=C:/ProgramData/PuppetLabs/puppet/var/log,
 :mode=
 750, :ensure=:directory, :loglevel=:debug, :links=:follow,
 :backup=false}'

 Debug: Using settings: adding file resource 'statedir':
 'File[C:/ProgramData/Pup
 petLabs/puppet/var/state]{:path=C:/ProgramData/PuppetLabs/puppet/var/state,
 :
 mode=1755, :ensure=:directory, :loglevel=:debug, :links=:follow,
 :backup=
 false}'
 Debug: Using settings: adding file resource 'rundir':
 'File[C:/ProgramData/Puppe
 tLabs/puppet/var/run]{:path=C:/ProgramData/PuppetLabs/puppet/var/run,
 :mode=
 1777, :ensure=:directory, :loglevel=:debug, :links=:follow,
 :backup=false}
 '
 Debug: Using settings: adding file resource 'libdir':
 'File[C:/ProgramData/Puppe
 tLabs/puppet/var/lib]{:path=C:/ProgramData/PuppetLabs/puppet/var/lib,
 :ensure
 =:directory, :loglevel=:debug, :links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'certdir':
 'File[C:/ProgramData/Pupp

 etLabs/puppet/etc/ssl/certs]{:path=C:/ProgramData/PuppetLabs/puppet/etc/ssl/ce
 rts, :ensure=:directory, :loglevel=:debug, :links=:follow,
 :backup=false}'
 Debug: Using settings: adding file resource 'ssldir':
 'File[C:/ProgramData/Puppe
 tLabs/puppet/etc/ssl]{:path=C:/ProgramData/PuppetLabs/puppet/etc/ssl,
 :mode=
 771, :ensure=:directory, :loglevel=:debug, :links=:follow,
 :backup=false}'

 Debug: Using settings: adding file resource 'publickeydir':
 'File[C:/ProgramData

 /PuppetLabs/puppet/etc/ssl/public_keys]{:path=C:/ProgramData/PuppetLabs/puppet
 /etc/ssl/public_keys, :ensure=:directory, :loglevel=:debug,
 :links=:follow,
 :backup=false}'
 Debug: Using settings: adding file resource 'requestdir':
 'File[C:/ProgramData/P

 uppetLabs/puppet/etc/ssl/certificate_requests]{:path=C:/ProgramData/PuppetLabs
 /puppet/etc/ssl/certificate_requests, :ensure=:directory,
 :loglevel=:debug, :
 links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'privatekeydir':
 'File[C:/ProgramDat

 a/PuppetLabs/puppet/etc/ssl/private_keys]{:path=C:/ProgramData/PuppetLabs/pupp
 et/etc/ssl/private_keys, :mode=750, :ensure=:directory,
 :loglevel=:debug,
 :links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'privatedir':
 'File[C:/ProgramData/P

 uppetLabs/puppet/etc/ssl/private]{:path=C:/ProgramData/PuppetLabs/puppet/etc/s
 sl/private, :mode=750, :ensure=:directory, :loglevel=:debug,
 :links=:foll
 ow, :backup=false}'
 Debug: Using settings: adding file resource 'hostprivkey':
 'File[C:/ProgramData/

 PuppetLabs/puppet/etc/ssl/private_keys/ctdesk0222.pem]{:path=C:/ProgramData/Pu
 ppetLabs/puppet/etc/ssl/private_keys/ctdesk0222.pem, :mode=600,
 :ensure=:fi
 le, :loglevel=:debug, :links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'hostpubkey':
 'File[C:/ProgramData/P

 uppetLabs/puppet/etc/ssl/public_keys/ctdesk0222.pem]{:path=C:/ProgramData/Pupp
 etLabs/puppet/etc/ssl/public_keys/ctdesk0222.pem, :mode=644,
 :ensure=:file,
  :loglevel=:debug, :links=:follow, :backup=false}'
 Debug: Using settings: adding file resource 'clientyamldir':
 'File[C:/ProgramDat

 a/PuppetLabs/puppet/var/client_yaml]{:path=C:/ProgramData/PuppetLabs/puppet/va
 r/client_yaml, :mode=750, :ensure=:directory, :loglevel=:debug,
 :links=:f
 ollow, :backup=false}'
 Debug: Using settings: adding file resource 'client_datadir':
 'File[C:/ProgramDa

 ta/PuppetLabs/puppet/var/client_data]{:path=C:/ProgramData/PuppetLabs/puppet/v
 ar/client_data, :mode=750, :ensure=:directory, :loglevel=:debug,
 :links=:
 follow, :backup=false}'
 Debug: Using settings: adding file resource 'clientbucketdir':
 'File[C:/ProgramD

 ata/PuppetLabs/puppet/var/clientbucket]{:path=C:/ProgramData/PuppetLabs/puppet
 /var/clientbucket, :mode=750, :ensure=:directory, :loglevel=:debug,
 :links
 =:follow, :backup=false}'
 Debug: Using settings: adding file resource 'graphdir':

Re: [Puppet Users] Puppetmaster 3.2.3 logging different than previous versions

On Wed, Jul 17, 2013 at 4:21 PM, Cory Stoker cory.sto...@gmail.com wrote:

 Hello:

 After upgrading to Puppet 3.2.3 I have noticed that the puppetmaster does
 not log the catalog compilation time like it did in 3.1.1 or before.  This
 log line used to look like:
 myserver puppet-master[19002]: Compiled catalog for myhost in environment
 production in 1.01 seconds

 Even if I change the logging level to debug in the rack config I do not
 see this line.  Anyone else notice this as well?  This could be related to
 the previous logging issues with 3.2 as in
 http://projects.puppetlabs.com/issues/20919  .  If this is an intended
 change, what is the best way to get the catalog compile time as this can be
 important information in regard to how the puppetmaster is performing.

 Thanks,
 Cory

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




This is https://projects.puppetlabs.com/issues/21709

Josh

-- 
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Final Countdown discount - save
15%!*

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

Re: [Puppet Users] mtime/md5lite with puppet 3.x bug Bug #13199

On Tue, Jun 25, 2013 at 7:12 AM, Stefan Wiederoder 
stefanwiedero...@googlemail.com wrote:

 Hello List,

 I´ve tried to switch from md5 checksum to md5lite within all my
 configuration to spare a few cpu cycles on my master,
 but it didn´t work at all :-(

 Then I´ve found out about bug #13199, but the bugs lists only 2.7x as
 affected.


This almost always means that the bug affects 2.7.x and up.



 can anybody confirm this issue on 3.x?

 funny that the bug isn´t anywhere on the roadmap at all  I´d suggest
 to remove mtime/md5lite from the
 documentation.

 it´s not a feature, it´s a bug

 bye
 ,
 Stefan

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






-- 
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Final Countdown discount - save
15%!*

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

Re: [Puppet Users] Puppet Enterprise no longer catching Press Enter to Continue at end of Exec

On Tue, Jul 2, 2013 at 2:19 PM, Scott Crowe scott.cr...@gmail.com wrote:

 I have been working on automating our deployment process which includes a
 call to an application that expects the user to press Enter when it is
 complete.

The puppet agent runs as LocalSystem, and in newer versions of Windows, the
LocalSystem account is not allowed to interact with the logged in user's
desktop. Otherwise, it can lead to shatter (privilege escalation)
attacks[1].


  Under Puppet Enterprise 2.8.2 it works fine and automatically catches
 that the process is completed but with Puppet Enterprise 3.0.0 installed as
 the agent it hangs and fails on timeout.

I didn't follow what you meant by catches that the process is completed?
I can't think of any change in any version of Puppet on Windows that would
result in different behavior...

I'd recommend installing Process Explorer when the PE 3.0 agent hangs. I'm
guessing you will see a child application also running, and likely waiting
for user input.

Anyone else experience this?  Is there a work around?  Should I enter a bug?

What application is puppet trying to execute? Could you put together a
reproducible test case? One question I have to ask, is why does a human
need to press Enter if you are trying to automate this?


 The agent in question is a Windows 2008 R2, I wasn’t able to find a bug
 with a quick search but wasn’t sure if that was just my newness to the
 system.
 Thanks in advance

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




Josh

[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684190(v=vs.85).aspx

-- 
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Final Countdown discount - save
15%!*

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

Re: [Puppet Users] Re: Dependency Cycle Question