[Puppet Users] Re: how to exec a directory creation before downloading a file to that directory?

[Samuli Seppanen]

Hi,

I was wondering this too last week. I haven't tested this yet, but I 
assume using "require" and "before" would do the trick:

http://reductivelabs.com/trac/puppet/wiki/TypeReference

Samuli


> 
> I want to create a directory and THEN get files into that directory on
> a client.
> Puppet it seems does not follow the order of commands, like below in
> my example.
> Sometimes it creates the directory, then downloads the file, and
> sometimes it tries to download the file before creating the directory,
> so the file won't be downloaded.
> 
> How can I download a file and make certain the destination directory
> will be there before this file is downloaded?  thanks again!  -jason
> 
> class theclass (
> 
>  exec{'mkdir -p /opt/scripts':
> unless => 'test -d /opt/scripts',
> }
> 
>  file { "/opt/scripts/my_script.sh":
> owner => "root",
> group => "thegroup",
> mode => 770,
> source => "puppet:///files/my_script.sh",
> }
> 
> )
> 
> > 


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

[Puppet Users] Debugging external node scripts

[Curt Micol]

Hello,
Alright, my puppetmaster configuration works without external nodes,
but I really need my external node script to work.

In my /etc/puppet/puppet.conf I have the following:
[main]
...
node_terminus = exec
external_nodes = /etc/puppet/tools/external_nodes.py

When running puppetmaster, I get:
[r...@vpsadmins ~]# puppetmasterd --no-daemonize --verbose --debug
[--snip--]
info: Listening on port 8140
notice: Starting Puppet server version 0.24.8
debug: Overriding dc2-vps1-400.example.com with cert name dc2-
vps1-400b.example.com
info: access[fileserver]: allowing *.example.com access
info: access[puppetmaster]: allowing *.example.com access
info: access[resource]: allowing vpsadmins.example.com access
info: access[puppetbucket]: allowing *.example.com
access  info: access
[puppetreports]: allowing *.example.com access
debug: Allowing authenticated client dc2-vps1-400b.example.com
(67.227.199.245) access to puppet
master.getconfig
debug: Our client is remote
debug: Executing '/etc/puppet/tools/external_nodes.py dc2-
vps1-400b.example.com'
err: Could not call: Could not find node 'dc2-vps1-400b.example.com';
cannot compile
notice: Caught INT; shutting down
debug: Signal caught here:
debug: /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-
loop.rb:127:in `call'
debug: /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-
loop.rb:127:in `select'
debug: /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-
loop.rb:127:in `select'
debug: /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-
loop.rb:116:in `iterate'
debug: /usr/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-
loop.rb:107:in `run'
debug: /usr/lib/ruby/site_ruby/1.8/puppet.rb:320:in `start'
debug: /usr/sbin/puppetmasterd:285
notice: Shutting down

When I run the script directly:
[r...@vpsadmins ~]# python /etc/puppet/tools/external_nodes.py dc2-
vps1-400b.example.com
---
classes:
- custom
- monitoring::base
- ntpd
- puppetd
- rpms
- sshd
- yum
- crontab
- iptables
- ldap::client
- monitoring::vps
- sudo
- virtuozzo
- vpsscripts


Here's the script I am running:
#!/usr/local/bin/python
#
# external_nodes.py
#   Take a YAML file containing node types, regular expressions to
match
#   a hostname, and which modules are get loaded for each node type.
#   Print to stdout the list of classes (in YAML) associated with the
node
#   type. This script is currently not very pythonic.
#
# TODO: actual error checking, particularly for file handling

### Imports
import sys
import re
import time
import yaml

### Constants
# puppet user must have read acces to this
NODEFILE = '/etc/puppet/nodes.yaml'
# puppet user must have write access to this
LOGFILE = '/var/log/puppet/nodes.log'

### Arguments
hostname = sys.argv[1]

### Functions

# Open NODESFILE and load the two documents into structures, return as
tuple
def parse_nodefile():
f = file(NODEFILE, 'r')
docs = yaml.load_all(f.read())
f.close()
return (docs.next(), docs.next())

# Write a msg to LOGFILE
def log(msg):
f = file(LOGFILE, 'a')
timestamp = time.strftime('%Y%m%d-%H:%M')
f.write(timestamp + ' - ' + msg + '\n')
f.close()

### Action!

(regexes, modules) = parse_nodefile()

for nodetype, regexlist in regexes.iteritems():
for regex in regexlist:
p = re.compile(regex)
m = p.match(hostname)
if m:
found_nodetype = nodetype

modulelist = modules['default']

try:
if found_nodetype and modules[found_nodetype] is not None:
modulelist.extend(modules[found_nodetype])
except NameError:
log(hostname + ' doesn\'t match a defined node type')
sys.exit(1)

yamldoc = {'classes': modulelist}
print yaml.dump(yamldoc, explicit_start=True,
default_flow_style=False)

# Puppet expects a return code of 0 to signal to indicate success
# and non-zero for error or a non-regcognized hostname
sys.exit(0)

This particular server is covered by this in my nodes.yaml:
- ^dc2-vps[12]-[2-9][0-9][0-9]b\.example\.com$

According to the wiki all I need to do is return YAML with an exit
code of 0, which this script does.

Anyone have any ideas as to why I am getting this error?

I appreciate any help,

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

[Puppet Users] Re: Debugging external node scripts

[Nicolas Szalay]

Le lundi 29 juin 2009 à 01:09 -0700, Curt Micol a écrit :

> When I run the script directly:
> [r...@vpsadmins ~]# python /etc/puppet/tools/external_nodes.py dc2-
> vps1-400b.example.com
> ---
> classes:
> - custom
> - monitoring::base
> - ntpd
> - puppetd
> - rpms
> - sshd
> - yum
> - crontab
> - iptables
> - ldap::client
> - monitoring::vps
> - sudo
> - virtuozzo
> - vpsscripts

Did you try running it as the "puppet" user ? permissions on NODEFILE &
LOGFILE could be source of errors.

Regards,

Nicolas


signature.asc
Description: Ceci est une partie de message numériquement signée

[Puppet Users] Re: Debugging external node scripts

[Curt Micol]

2009/6/29 Nicolas Szalay :
> Le lundi 29 juin 2009 à 01:09 -0700, Curt Micol a écrit :
> Did you try running it as the "puppet" user ? permissions on NODEFILE &
> LOGFILE could be source of errors.

Yes, sorry, I get the same results with running as the puppet user.
Just tested once more to verify and received the same error.

-- 
# Curt Micol

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

[Puppet Users] pkg_deploy on Macs - how to maintain "State"

[Gary Larizza]

Hi All,

I'm successfully using pkg_deploy to deploy DMG-encapsulated packages
on Mac Clients.  My question would be - since Puppet is essentially
used to define a "state" that the computer is in, what would be the
best way to maintain a "state" after deploying a package?

For example, if you deployed a package to install Microsoft Office,
you would probably ensure that the Microsoft Office directory (as well
as the individual .Apps) was Present.  If the directory WASN'T present
(someone deleted it, for example), is there a way to call pkg_deploy
again to re-deploy the package, or would you have to keep the
Microsoft Office directory structure on the Puppetmaster server
(inside your module/files directory, for example) in order for it to
send the directory structure down to the damaged client?

In that vein (and a separate question), how does puppet know that
pkg_deploy has been run and that the DMG-encapsulated package has been
run/installed?  It doesn't call pkg_deploy on subsequent catalog
checks by the client - so it's not bringing down the DMG again and
attempting an install.  Is there some sort of "receipt" that it checks
- or does it actually USE the Receipts directory to monitor
installation?

I know I'm trying to use Puppet to maintain staff and lab computers -
which is somewhat unconventional, but it stands up to the
implementation!  Thanks for all your help and support!

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

[Puppet Users] Re: pkg_deploy on Macs - how to maintain "State"

[Udo Waechter]

Hi Gary,

On 29.06.2009, at 14:12, Gary Larizza wrote:



Hi All,

I'm successfully using pkg_deploy to deploy DMG-encapsulated packages
on Mac Clients.  My question would be - since Puppet is essentially
used to define a "state" that the computer is in, what would be the
best way to maintain a "state" after deploying a package?



pkg_deploy is only a convenience/wrapper define around the package-type.
Since OS X does not really have something like a package-management,  
you can really only install stuff.
The package-type does mark a successfull installation of a package by  
creating a

/var/db/.puppet_[pkg|app]dmg_

Thats it. You can remove that file by hand, then puppet thinks it did  
not install the package and reinstalls it again.
Another trick (what we do), is to simply increase the version number  
of the package. One could also call it: rename the package.  
(OfficeX-2008.1.dmg -> OfficeX-2008.2.dmg)



For example, if you deployed a package to install Microsoft Office,
you would probably ensure that the Microsoft Office directory (as well
as the individual .Apps) was Present.  If the directory WASN'T present
(someone deleted it, for example), is there a way to call pkg_deploy
again to re-deploy the package, or would you have to keep the
Microsoft Office directory structure on the Puppetmaster server
(inside your module/files directory, for example) in order for it to
send the directory structure down to the damaged client?

I think that copying recursive directory data in huge amounts will  
crash your puppetmaster, even with only one client. (Hints: xmlrpc and  
file-serving)



In that vein (and a separate question), how does puppet know that
pkg_deploy has been run and that the DMG-encapsulated package has been
run/installed?  It doesn't call pkg_deploy on subsequent catalog
checks by the client - so it's not bringing down the DMG again and
attempting an install.  Is there some sort of "receipt" that it checks
- or does it actually USE the Receipts directory to monitor
installation?


no, see above.


I know I'm trying to use Puppet to maintain staff and lab computers -
which is somewhat unconventional, but it stands up to the
implementation!  Thanks for all your help and support!



uh? Why do you thinkg this is unconventional? Puppet manages  
computers. What these computers are used for is irrelevant :)
We do manage some macs (laptops and workstations) with puppet and  
everything works fine. Package managment does require quite  a lot of  
time, but that is not puppet's fault.


Have fun,
udo.

--
:: udo waechter - r...@zoide.net :: N 52º16'30.5" E 8º3'10.1"
:: genuine input for your ears: http://auriculabovinari.de
::  your eyes: http://ezag.zoide.net
::  your brain: http://zoide.net






smime.p7s
Description: S/MIME cryptographic signature

[Puppet Users] Unable to get storedconfigs to work

[Felix Schäfer]

Hello,

I can't get storedconfigs to work, puppetmaster keeps complaining  
about "missing Rails". Fact is I do have rails installed, I even have  
a few rails apps running fine with a mysql backend in passenger. I  
have tried to localise a possible error by starting puppetmasterd with  
debug, but nothing obvious there, no help either in the logs. I also  
tried setting RUBYLIB to the gempath and even the paths to the gems,  
but that didn't help either. irb also is quite happy with the active  
record invocations puppet uses:

"""
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'active_record'
=> true
"""

Here's the important part of the puppet.conf:
"""
storeconfigs = true
dbadapter= mysql
dbuser   = puppet
dbpassword   = xx
dbserver = localhost
dbsocket = /var/lib/mysql/mysql.sock
"""

gem also lists rails and active_record as present:
"""
*** LOCAL GEMS ***

actionmailer (2.3.2, 2.1.2)
actionpack (2.3.2, 2.1.2)
activerecord (2.3.2, 2.1.2)
activeresource (2.3.2, 2.1.2)
activesupport (2.3.2, 2.1.2)
fastthread (1.0.7, 1.0.1)
haml (2.0.9)
passenger (2.1.2)
rack (1.0.0, 0.9.1)
rails (2.3.2, 2.1.2)
rake (0.8.5, 0.8.3)
"""

Both sides are running a suse flavour and have puppet, resp.  
puppetmaster, at version 0.24.8.

Any help to get storedconfigs going would be great, thanks!

Felix

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

[Puppet Users] External Node Classifiers

[Gary Larizza]

Hi everyone,

I've defined an external node classifier (the script is http://pastie.org/528040
) in my puppet.conf ( http://pastie.org/528046 ) , and have moved the
regular nodes.pp files.  I've also commented out the import statement
for the nodes.pp file in my site.pp file.  When I connect from a
client, I'm getting the "Could not retrieve catalog:  Could not find
default node or by name with " -- http://pastie.org/528034
If I run the external node classifier with the hostname passed -->
http://pastie.org/528043  the YAML data comes out fine.  What can I do
to debug this further?  It looks like the script is passing everything
correctly, but puppet seems to have a problem with it?

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

[Puppet Users] Re: pkg_deploy on Macs - how to maintain "State"

[Nigel Kersten]

So along these lines, there are two things I've been thinking about to
improve package distribution with Puppet.

a) Add a parameter called something like "creates" that would be an
array of files and/or directories that a given package is expected to
create. If any of these are missing, Puppet reinstalls the package,
regardless of the state of the marker file.

b) Work on a "munki" provider.

"Munki" is a project a friend of mine Greg Neagle has been working on
to produce a good third party pkg based repository system for OS X.

http://code.google.com/p/munki/

Munki "knows" whether a given package is installed, flat or bundle
based, so it could be used to solve this problem.

The primary problem we have with the pkgdmg provider is that there is
no necessary relationship between the dmg name and the pkg bundle
identifier, and the marker file is based upon the former, whereas the
package receipt is based upon the latter.

Unless we changed the pkgdmg provider to mount every single dmg and
inspect the contents (bad idea) Puppet has no visibility to the pkg
contained within the dmg.



On Mon, Jun 29, 2009 at 7:27 AM, Udo
Waechter wrote:
> Hi Gary,
>
> On 29.06.2009, at 14:12, Gary Larizza wrote:
>
>>
>> Hi All,
>>
>> I'm successfully using pkg_deploy to deploy DMG-encapsulated packages
>> on Mac Clients.  My question would be - since Puppet is essentially
>> used to define a "state" that the computer is in, what would be the
>> best way to maintain a "state" after deploying a package?
>>
>
> pkg_deploy is only a convenience/wrapper define around the package-type.
> Since OS X does not really have something like a package-management, you can
> really only install stuff.
> The package-type does mark a successfull installation of a package by
> creating a
> /var/db/.puppet_[pkg|app]dmg_
>
> Thats it. You can remove that file by hand, then puppet thinks it did not
> install the package and reinstalls it again.
> Another trick (what we do), is to simply increase the version number of the
> package. One could also call it: rename the package. (OfficeX-2008.1.dmg ->
> OfficeX-2008.2.dmg)
>
>> For example, if you deployed a package to install Microsoft Office,
>> you would probably ensure that the Microsoft Office directory (as well
>> as the individual .Apps) was Present.  If the directory WASN'T present
>> (someone deleted it, for example), is there a way to call pkg_deploy
>> again to re-deploy the package, or would you have to keep the
>> Microsoft Office directory structure on the Puppetmaster server
>> (inside your module/files directory, for example) in order for it to
>> send the directory structure down to the damaged client?
>>
> I think that copying recursive directory data in huge amounts will crash
> your puppetmaster, even with only one client. (Hints: xmlrpc and
> file-serving)
>
>> In that vein (and a separate question), how does puppet know that
>> pkg_deploy has been run and that the DMG-encapsulated package has been
>> run/installed?  It doesn't call pkg_deploy on subsequent catalog
>> checks by the client - so it's not bringing down the DMG again and
>> attempting an install.  Is there some sort of "receipt" that it checks
>> - or does it actually USE the Receipts directory to monitor
>> installation?
>>
> no, see above.
>
>> I know I'm trying to use Puppet to maintain staff and lab computers -
>> which is somewhat unconventional, but it stands up to the
>> implementation!  Thanks for all your help and support!
>
>
> uh? Why do you thinkg this is unconventional? Puppet manages computers. What
> these computers are used for is irrelevant :)
> We do manage some macs (laptops and workstations) with puppet and everything
> works fine. Package managment does require quite  a lot of time, but that is
> not puppet's fault.
>
> Have fun,
> udo.
>
> --
> :: udo waechter - r...@zoide.net :: N 52º16'30.5" E 8º3'10.1"
> :: genuine input for your ears: http://auriculabovinari.de
> ::                          your eyes: http://ezag.zoide.net
> ::                          your brain: http://zoide.net
>
>
>
>
>



-- 
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.

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

[Puppet Users] Re: Problems running on Mac OS X

[Nigel Kersten]

On Sat, Jun 27, 2009 at 5:15 PM, Allan B. Marcus wrote:
>
> I don't think a flat package works on 10.4, that's why packages still need
> to be wrapped in a dmg.

Yep. Unless you case 10.4 and post 10.4 separately, or drop 10.4
support, you need to wrap the pkgs in a dmg.



>
> -Allan
>
>
> On Fri, June 26, 2009 10:35 pm, Jason Hueske wrote:
>> Nigel, if you have similar scripts for flat or dmg pkgs I would love
>> to take a look. Does puppet's support such packages? Did you have any
>> trouble reconciling the different receipt mechanisms in 10.4/10.5?
>>
>> On Jun 26, 2009, at 12:03 PM, Nigel Kersten wrote:
>>>
>>> Please note that for both Puppet and Facter, you can create packages
>>> from any git checkout/source tarball with conf/osx/createpackage.sh
>>
>>
>> >
>>
>
>
> --
> Thanks,
>
> Allan Marcus
> 505-667-5666
>
> >
>



-- 
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.

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

[Puppet Users] Re: Puppet reparsing puppet.conf every 24 hours - is this configurable?

[Nigel Kersten]

On Sun, Jun 28, 2009 at 4:42 PM, Greg wrote:
>
> Hi all,
>
> I've noticed roughly every 24 hours my puppetmasters will reread the
> puppet.conf even if there is no change to
> the file. Logs look something like this:
>
> Jun 27 18:15:10 puppet-prod puppetmasterd[15161]: [ID 702911
> daemon.notice] Sat Jun 27 18:09:43 +1000 2009 vs Fri Jun 26 18:06:11
> +1000 2009
> Jun 27 18:15:17 puppet-prod puppetmasterd[15200]: [ID 702911
> daemon.notice] Reparsing /etc/opt/csw/puppet/puppet.conf
>
> Does anyone know if we can influence the frequency of this? I'd like
> to make it less frequent as it re-reads the config file as soon as its
> changed anyway (not that it changes much anyway)... Maybe weekly is
> sufficient...

Does this happen to correlated to backup times on these servers?

I ran into an issue with NetBackup where by default it restores the
atime of a file after backing it up, which modifies the ctime of the
file, which causes Puppet to think that the file has changed and
reparse it.




>
> thanks,
>
> Greg
> >
>



-- 
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.

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

[Puppet Users] Re: Unable to get storedconfigs to work

[Nigel Kersten]

On Mon, Jun 29, 2009 at 8:23 AM, Felix Schäfer wrote:
>
> Hello,
>
> I can't get storedconfigs to work, puppetmaster keeps complaining
> about "missing Rails". Fact is I do have rails installed, I even have
> a few rails apps running fine with a mysql backend in passenger. I
> have tried to localise a possible error by starting puppetmasterd with
> debug, but nothing obvious there, no help either in the logs. I also
> tried setting RUBYLIB to the gempath and even the paths to the gems,
> but that didn't help either. irb also is quite happy with the active
> record invocations puppet uses:

Do you possibly have multiple versions installed?

I ran into that issue, and this comment from this bug offered me a workaround.

http://projects.reductivelabs.com/issues/2041#note-22




>
> """
> irb(main):001:0>             require 'rubygems'
> => true
> irb(main):002:0>             require 'active_record'
> => true
> """
>
> Here's the important part of the puppet.conf:
> """
>        storeconfigs = true
>        dbadapter    = mysql
>        dbuser       = puppet
>        dbpassword   = xx
>        dbserver     = localhost
>        dbsocket     = /var/lib/mysql/mysql.sock
> """
>
> gem also lists rails and active_record as present:
> """
> *** LOCAL GEMS ***
>
> actionmailer (2.3.2, 2.1.2)
> actionpack (2.3.2, 2.1.2)
> activerecord (2.3.2, 2.1.2)
> activeresource (2.3.2, 2.1.2)
> activesupport (2.3.2, 2.1.2)
> fastthread (1.0.7, 1.0.1)
> haml (2.0.9)
> passenger (2.1.2)
> rack (1.0.0, 0.9.1)
> rails (2.3.2, 2.1.2)
> rake (0.8.5, 0.8.3)
> """
>
> Both sides are running a suse flavour and have puppet, resp.
> puppetmaster, at version 0.24.8.
>
> Any help to get storedconfigs going would be great, thanks!
>
> Felix
>
> >
>



-- 
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.

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

[Puppet Users] Re: pkg_deploy on Macs - how to maintain "State"

[Jason Hueske]

The potential for a mac-repository functionality is exactly what led  
me to puppet in the first place, so that is very interesting to hear.  
I will be keeping my eye on the munkie!

It seems that flat packages would not suffer from the identifier  
problem that you have with Tiger pkgs/dmgs because they don't have to  
be monkeyed with for distribution, so the pkgdmg problem would at  
least be moot moving forward with newer systems.

Does munkie "know" which packages are installed by looking at the  
receipts/bom db? If so, leveraging that would seem to make a lot of  
sense for "legacy" packages..

Jason

On Jun 29, 2009, at 10:40 AM, Nigel Kersten wrote:

>
> So along these lines, there are two things I've been thinking about to
> improve package distribution with Puppet.
>
> a) Add a parameter called something like "creates" that would be an
> array of files and/or directories that a given package is expected to
> create. If any of these are missing, Puppet reinstalls the package,
> regardless of the state of the marker file.
>
> b) Work on a "munki" provider.
>
> "Munki" is a project a friend of mine Greg Neagle has been working on
> to produce a good third party pkg based repository system for OS X.
>
> http://code.google.com/p/munki/
>
> Munki "knows" whether a given package is installed, flat or bundle
> based, so it could be used to solve this problem.
>
> The primary problem we have with the pkgdmg provider is that there is
> no necessary relationship between the dmg name and the pkg bundle
> identifier, and the marker file is based upon the former, whereas the
> package receipt is based upon the latter.
>
> Unless we changed the pkgdmg provider to mount every single dmg and
> inspect the contents (bad idea) Puppet has no visibility to the pkg
> contained within the dmg.
>
>
>
> On Mon, Jun 29, 2009 at 7:27 AM, Udo
> Waechter wrote:
>> Hi Gary,
>>
>> On 29.06.2009, at 14:12, Gary Larizza wrote:
>>
>>>
>>> Hi All,
>>>
>>> I'm successfully using pkg_deploy to deploy DMG-encapsulated  
>>> packages
>>> on Mac Clients.  My question would be - since Puppet is essentially
>>> used to define a "state" that the computer is in, what would be the
>>> best way to maintain a "state" after deploying a package?
>>>
>>
>> pkg_deploy is only a convenience/wrapper define around the package- 
>> type.
>> Since OS X does not really have something like a package- 
>> management, you can
>> really only install stuff.
>> The package-type does mark a successfull installation of a package by
>> creating a
>> /var/db/.puppet_[pkg|app]dmg_
>>
>> Thats it. You can remove that file by hand, then puppet thinks it  
>> did not
>> install the package and reinstalls it again.
>> Another trick (what we do), is to simply increase the version  
>> number of the
>> package. One could also call it: rename the package.  
>> (OfficeX-2008.1.dmg ->
>> OfficeX-2008.2.dmg)
>>
>>> For example, if you deployed a package to install Microsoft Office,
>>> you would probably ensure that the Microsoft Office directory (as  
>>> well
>>> as the individual .Apps) was Present.  If the directory WASN'T  
>>> present
>>> (someone deleted it, for example), is there a way to call pkg_deploy
>>> again to re-deploy the package, or would you have to keep the
>>> Microsoft Office directory structure on the Puppetmaster server
>>> (inside your module/files directory, for example) in order for it to
>>> send the directory structure down to the damaged client?
>>>
>> I think that copying recursive directory data in huge amounts will  
>> crash
>> your puppetmaster, even with only one client. (Hints: xmlrpc and
>> file-serving)
>>
>>> In that vein (and a separate question), how does puppet know that
>>> pkg_deploy has been run and that the DMG-encapsulated package has  
>>> been
>>> run/installed?  It doesn't call pkg_deploy on subsequent catalog
>>> checks by the client - so it's not bringing down the DMG again and
>>> attempting an install.  Is there some sort of "receipt" that it  
>>> checks
>>> - or does it actually USE the Receipts directory to monitor
>>> installation?
>>>
>> no, see above.
>>
>>> I know I'm trying to use Puppet to maintain staff and lab  
>>> computers -
>>> which is somewhat unconventional, but it stands up to the
>>> implementation!  Thanks for all your help and support!
>>
>>
>> uh? Why do you thinkg this is unconventional? Puppet manages  
>> computers. What
>> these computers are used for is irrelevant :)
>> We do manage some macs (laptops and workstations) with puppet and  
>> everything
>> works fine. Package managment does require quite  a lot of time,  
>> but that is
>> not puppet's fault.
>>
>> Have fun,
>> udo.
>>
>> --
>> :: udo waechter - r...@zoide.net :: N 52º16'30.5" E 8º3'10.1"
>> :: genuine input for your ears: http://auriculabovinari.de
>> ::  your eyes: http://ezag.zoide.net
>> ::  your brain: http://zoide.net
>>
>>
>>
>>
>>
>
>
>
> -- 
> Nigel Kersten
> nig...@go

[Puppet Users] Re: pkg_deploy on Macs - how to maintain "State"

[Nigel Kersten]

On Mon, Jun 29, 2009 at 9:10 AM, Jason Hueske wrote:
>
> The potential for a mac-repository functionality is exactly what led
> me to puppet in the first place, so that is very interesting to hear.
> I will be keeping my eye on the munkie!
>
> It seems that flat packages would not suffer from the identifier
> problem that you have with Tiger pkgs/dmgs because they don't have to
> be monkeyed with for distribution, so the pkgdmg problem would at
> least be moot moving forward with newer systems.

Yes. You'd lose the current ability of the pkgdmg provider to install
multiple pkgs from a single dmg though.

>
> Does munkie "know" which packages are installed by looking at the
> receipts/bom db? If so, leveraging that would seem to make a lot of
> sense for "legacy" packages..

It collates information together from both the old style
"/Library/Receipts" for bundled packages and the new style sqlite db
for flat packages.

It's still a very young project, but I really do feel that a Puppet
Munki provider could give us something really quite wonderful on the
Mac platform.



>
> Jason
>
> On Jun 29, 2009, at 10:40 AM, Nigel Kersten wrote:
>
>>
>> So along these lines, there are two things I've been thinking about to
>> improve package distribution with Puppet.
>>
>> a) Add a parameter called something like "creates" that would be an
>> array of files and/or directories that a given package is expected to
>> create. If any of these are missing, Puppet reinstalls the package,
>> regardless of the state of the marker file.
>>
>> b) Work on a "munki" provider.
>>
>> "Munki" is a project a friend of mine Greg Neagle has been working on
>> to produce a good third party pkg based repository system for OS X.
>>
>> http://code.google.com/p/munki/
>>
>> Munki "knows" whether a given package is installed, flat or bundle
>> based, so it could be used to solve this problem.
>>
>> The primary problem we have with the pkgdmg provider is that there is
>> no necessary relationship between the dmg name and the pkg bundle
>> identifier, and the marker file is based upon the former, whereas the
>> package receipt is based upon the latter.
>>
>> Unless we changed the pkgdmg provider to mount every single dmg and
>> inspect the contents (bad idea) Puppet has no visibility to the pkg
>> contained within the dmg.
>>
>>
>>
>> On Mon, Jun 29, 2009 at 7:27 AM, Udo
>> Waechter wrote:
>>> Hi Gary,
>>>
>>> On 29.06.2009, at 14:12, Gary Larizza wrote:
>>>

 Hi All,

 I'm successfully using pkg_deploy to deploy DMG-encapsulated
 packages
 on Mac Clients.  My question would be - since Puppet is essentially
 used to define a "state" that the computer is in, what would be the
 best way to maintain a "state" after deploying a package?

>>>
>>> pkg_deploy is only a convenience/wrapper define around the package-
>>> type.
>>> Since OS X does not really have something like a package-
>>> management, you can
>>> really only install stuff.
>>> The package-type does mark a successfull installation of a package by
>>> creating a
>>> /var/db/.puppet_[pkg|app]dmg_
>>>
>>> Thats it. You can remove that file by hand, then puppet thinks it
>>> did not
>>> install the package and reinstalls it again.
>>> Another trick (what we do), is to simply increase the version
>>> number of the
>>> package. One could also call it: rename the package.
>>> (OfficeX-2008.1.dmg ->
>>> OfficeX-2008.2.dmg)
>>>
 For example, if you deployed a package to install Microsoft Office,
 you would probably ensure that the Microsoft Office directory (as
 well
 as the individual .Apps) was Present.  If the directory WASN'T
 present
 (someone deleted it, for example), is there a way to call pkg_deploy
 again to re-deploy the package, or would you have to keep the
 Microsoft Office directory structure on the Puppetmaster server
 (inside your module/files directory, for example) in order for it to
 send the directory structure down to the damaged client?

>>> I think that copying recursive directory data in huge amounts will
>>> crash
>>> your puppetmaster, even with only one client. (Hints: xmlrpc and
>>> file-serving)
>>>
 In that vein (and a separate question), how does puppet know that
 pkg_deploy has been run and that the DMG-encapsulated package has
 been
 run/installed?  It doesn't call pkg_deploy on subsequent catalog
 checks by the client - so it's not bringing down the DMG again and
 attempting an install.  Is there some sort of "receipt" that it
 checks
 - or does it actually USE the Receipts directory to monitor
 installation?

>>> no, see above.
>>>
 I know I'm trying to use Puppet to maintain staff and lab
 computers -
 which is somewhat unconventional, but it stands up to the
 implementation!  Thanks for all your help and support!
>>>
>>>
>>> uh? Why do you thinkg this is unconventional? Puppet manages
>>> computers. What
>>> these computers a

[Puppet Users] Re: Unable to get storedconfigs to work

[Felix Schäfer]

Hello Nigel,

Am 29.06.2009 um 17:52 schrieb Nigel Kersten:

> Do you possibly have multiple versions installed?

I did, deleted all but the newest, no change.

Felix

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

[Puppet Users] Re: facter problem

[Roy Nielsen]

Hello,

Sorry, my RUBYLIB was incorrect.. Fixed now.

Regards,
-Roy

Roy Nielsen wrote:
> Hello,
> 
> I've created a simple fact (with 
> http://reductivelabs.com/trac/puppet/wiki/AddingFact ) to check the 
> version of an installed program, it was working friday, now I don't get 
> any return values from facter.
> 
> I've got my RUBYLIB set properly (export RUBYLIB=~/lib/ruby/facter) with 
> my home-made facts in it.  When typing:
> 
> facter prog_version
> 
> All I get returned is nothing...
> 
> Anyone seen this before?
> 
> Thanks,
> -Roy Nielsen
> 
> PS. I'm running facter 1.5.6 on a Mac 10.5.7 machine.
> 

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

[Puppet Users] facter problem

[Roy Nielsen]

Hello,

I've created a simple fact (with 
http://reductivelabs.com/trac/puppet/wiki/AddingFact ) to check the 
version of an installed program, it was working friday, now I don't get 
any return values from facter.

I've got my RUBYLIB set properly (export RUBYLIB=~/lib/ruby/facter) with 
my home-made facts in it.  When typing:

facter prog_version

All I get returned is nothing...

Anyone seen this before?

Thanks,
-Roy Nielsen

PS. I'm running facter 1.5.6 on a Mac 10.5.7 machine.

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

[Puppet Users] Re: pkg_deploy on Macs - how to maintain "State"

[Allan Marcus]

I think people are missing Gary's point (or maybe I am). Puppet works  
by ensuring a package is installed. If the package version changes,  
puppet will install the new version.

I a lab where those pesky students might delete a file in, say the MS  
Office directory, puppet would do nothing since the package version  
has not changed.

There is very well architected solution to this: radmind.

In my mind, puppet is great in an environment where there is either  
good system administrative controls on the computers, or knowledgeable  
users that know not to delete an arbitrary file. In a student lab  
situation where who knows what might happen, radmind or even deep  
freeze might be a better solution.

That said, i want to thank Udo's explanation for how the provider  
works. He explanation should be added to the wiki page:
http://reductivelabs.com/trac/puppet/wiki/PuppetMacOSX

> pkg_deploy is only a convenience/wrapper define around the package- 
> type.
> Since OS X does not really have something like a package-management,  
> you can really only install stuff.
> The package-type does mark a successfull installation of a package  
> by creating a
> /var/db/.puppet_[pkg|app]dmg_
>
> Thats it. You can remove that file by hand, then puppet thinks it  
> did not install the package and reinstalls it again.
> Another trick (what we do), is to simply increase the version number  
> of the package. One could also call it: rename the package.  
> (OfficeX-2008.1.dmg -> OfficeX-2008.2.dmg)

The only issue I see is the possible proliferation of these .puppet_  
files in /var/db. How do people deal with them (or not)?

---
Thanks,

Allan Marcus
505-667-5666



On Jun 29, 2009, at 6:12 AM, Gary Larizza wrote:

>
> Hi All,
>
> I'm successfully using pkg_deploy to deploy DMG-encapsulated packages
> on Mac Clients.  My question would be - since Puppet is essentially
> used to define a "state" that the computer is in, what would be the
> best way to maintain a "state" after deploying a package?
>
> For example, if you deployed a package to install Microsoft Office,
> you would probably ensure that the Microsoft Office directory (as well
> as the individual .Apps) was Present.  If the directory WASN'T present
> (someone deleted it, for example), is there a way to call pkg_deploy
> again to re-deploy the package, or would you have to keep the
> Microsoft Office directory structure on the Puppetmaster server
> (inside your module/files directory, for example) in order for it to
> send the directory structure down to the damaged client?
>
> In that vein (and a separate question), how does puppet know that
> pkg_deploy has been run and that the DMG-encapsulated package has been
> run/installed?  It doesn't call pkg_deploy on subsequent catalog
> checks by the client - so it's not bringing down the DMG again and
> attempting an install.  Is there some sort of "receipt" that it checks
> - or does it actually USE the Receipts directory to monitor
> installation?
>
> I know I'm trying to use Puppet to maintain staff and lab computers -
> which is somewhat unconventional, but it stands up to the
> implementation!  Thanks for all your help and support!
>
> -Gary
> >


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

[Puppet Users] Re: pkg_deploy on Macs - how to maintain "State"

[Nigel Kersten]

On Mon, Jun 29, 2009 at 4:13 PM, Allan Marcus wrote:
>
> I think people are missing Gary's point (or maybe I am). Puppet works
> by ensuring a package is installed. If the package version changes,
> puppet will install the new version.
>
> I a lab where those pesky students might delete a file in, say the MS
> Office directory, puppet would do nothing since the package version
> has not changed.
>
> There is very well architected solution to this: radmind.

There's an even better solution for labs. Permissions :)

This was what I was referring to with a) though. Files you consider
mandatory that Puppet can use the existence of to determine whether a
package should be reinstalled.

>
> In my mind, puppet is great in an environment where there is either
> good system administrative controls on the computers, or knowledgeable
> users that know not to delete an arbitrary file. In a student lab
> situation where who knows what might happen, radmind or even deep
> freeze might be a better solution.
>
> That said, i want to thank Udo's explanation for how the provider
> works. He explanation should be added to the wiki page:
> http://reductivelabs.com/trac/puppet/wiki/PuppetMacOSX
>
>> pkg_deploy is only a convenience/wrapper define around the package-
>> type.
>> Since OS X does not really have something like a package-management,
>> you can really only install stuff.
>> The package-type does mark a successfull installation of a package
>> by creating a
>> /var/db/.puppet_[pkg|app]dmg_
>>
>> Thats it. You can remove that file by hand, then puppet thinks it
>> did not install the package and reinstalls it again.
>> Another trick (what we do), is to simply increase the version number
>> of the package. One could also call it: rename the package.
>> (OfficeX-2008.1.dmg -> OfficeX-2008.2.dmg)
>
> The only issue I see is the possible proliferation of these .puppet_
> files in /var/db. How do people deal with them (or not)?

I don't bother. They're invisible files that take up almost no space.

>
>
>
> On Jun 29, 2009, at 6:12 AM, Gary Larizza wrote:
>
>>
>> Hi All,
>>
>> I'm successfully using pkg_deploy to deploy DMG-encapsulated packages
>> on Mac Clients.  My question would be - since Puppet is essentially
>> used to define a "state" that the computer is in, what would be the
>> best way to maintain a "state" after deploying a package?
>>
>> For example, if you deployed a package to install Microsoft Office,
>> you would probably ensure that the Microsoft Office directory (as well
>> as the individual .Apps) was Present.  If the directory WASN'T present
>> (someone deleted it, for example), is there a way to call pkg_deploy
>> again to re-deploy the package, or would you have to keep the
>> Microsoft Office directory structure on the Puppetmaster server
>> (inside your module/files directory, for example) in order for it to
>> send the directory structure down to the damaged client?
>>
>> In that vein (and a separate question), how does puppet know that
>> pkg_deploy has been run and that the DMG-encapsulated package has been
>> run/installed?  It doesn't call pkg_deploy on subsequent catalog
>> checks by the client - so it's not bringing down the DMG again and
>> attempting an install.  Is there some sort of "receipt" that it checks
>> - or does it actually USE the Receipts directory to monitor
>> installation?
>>
>> I know I'm trying to use Puppet to maintain staff and lab computers -
>> which is somewhat unconventional, but it stands up to the
>> implementation!  Thanks for all your help and support!
>>
>> -Gary
>> >
>
>
> >
>



-- 
Nigel Kersten
nig...@google.com
System Administrator
Google, Inc.

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

[Puppet Users] Re: Puppet reparsing puppet.conf every 24 hours - is this configurable?

[Greg]

Nigel,

Actually, its happening 10 mins into backups... And its using
Netbackup...

Looks like I'm stuck with it, unless its possible to get that check to
happen on mtime
instead of ctime... (Of course then theres the question of which is
more useful, etc...)
Its not a major issue... The only real issue is that it pollutes the
logs a little bit...

Thanks,

Greg

On Jun 30, 1:50 am, Nigel Kersten  wrote:
> On Sun, Jun 28, 2009 at 4:42 PM, Greg wrote:
>
> > Hi all,
>
> > I've noticed roughly every 24 hours my puppetmasters will reread the
> > puppet.conf even if there is no change to
> > the file. Logs look something like this:
>
> > Jun 27 18:15:10 puppet-prod puppetmasterd[15161]: [ID 702911
> > daemon.notice] Sat Jun 27 18:09:43 +1000 2009 vs Fri Jun 26 18:06:11
> > +1000 2009
> > Jun 27 18:15:17 puppet-prod puppetmasterd[15200]: [ID 702911
> > daemon.notice] Reparsing /etc/opt/csw/puppet/puppet.conf
>
> > Does anyone know if we can influence the frequency of this? I'd like
> > to make it less frequent as it re-reads the config file as soon as its
> > changed anyway (not that it changes much anyway)... Maybe weekly is
> > sufficient...
>
> Does this happen to correlated to backup times on these servers?
>
> I ran into an issue with NetBackup where by default it restores the
> atime of a file after backing it up, which modifies the ctime of the
> file, which causes Puppet to think that the file has changed and
> reparse it.
>
>
>
> > thanks,
>
> > Greg
>
> --
> Nigel Kersten
> nig...@google.com
> System Administrator
> Google, Inc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Cache puppet files

[Alexandre Nascimento]

Friends,

I Make the update of my files on the puppetmaster server, but servers
customers run the classes that no longer exist.

Someone could help me?

Thank you!

-- 
Alexandre
SlackUser

"Seja Livre, Use Linux!"

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

[Puppet Users] Re: yum provider executes rpm -e?

[Fletch]

I also noticed this today.
Is there a better yum provider?
I want to ensure cups and all the crap it comes with is absent.
puppet calls rpm -e cups and fails on dependencies check.

thanks for any tips

On Jun 22, 8:12 am, Arnau Bria  wrote:
> Hi all,
>
> I have defined in my site.pp:
>
> Package {
>        provider=>yum,
>         ensure   => latest,
>         }
>
> and in one of my modules:
>
>  package {"qt":
>                provider=>yum,
>                 ensure   => absent,
>                 }
>         package {"ati-fglrx":
>                provider=>yum,
>                 ensure   => absent,
>                 }
>
>         package {"libmng":
>                provider=>yum,
>                 ensure   => absent,
>                 }
>
> (I've dobledproviderdefinition cause I tought it was not working).
>
> Then, if I go to node and run it by hand I see next error:
>
> err: 
> /:main/Node[td007.pic.es]/blade_x5355/glite31/yaim_packages/Package[libmng]/ensure:
>  change from 1.0.8-1 to absent failed: Execution of '/bin/rpm -e 
> libmng-1.0.8-1.x86_64' returned 1: error: Failed dependencies:
>         libmng.so.1()(64bit) is needed by (installed) qt-3.3.3-16.el4.x86_64
>
> Why is it executing rmp -e and notyumremove?
>
> TIA,
> Arnau

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