Puppet users - Jun 2009 - pkg_deploy on Macs - how to maintain "State"

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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_<packagename>

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 - root@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

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<udo.waechter@uni-osnabrueck.de> 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_<packagename>
>
> 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 - root@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
nigelk@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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<udo.waechter@uni-osnabrueck.de> 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_<packagename>
>>
>> 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 - root@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
> nigelk@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Jun 29, 2009 at 9:10 AM, Jason Hueske<schwifty@gmail.com>
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<udo.waechter@uni-osnabrueck.de> 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_<packagename>
>>>
>>> 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 - root@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
>> nigelk@google.com
>> System Administrator
>> Google, Inc.
>>
>> >
>
>
> >
>


-- 
Nigel Kersten
nigelk@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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_<packagename>
>
> 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Jun 29, 2009 at 4:13 PM, Allan Marcus<allan@lanl.gov>
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_<packagename>
>>
>> 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
nigelk@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

On 30.06.2009, at 01:13, 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.
>
> 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.

If things like these happen, then puppet is the wrong solution for any  
environment.
We have 3 simple rules:
- only the admins are admins, users use computers.
- only the admins know the admin-password and have admin-rights
- if a user knows the admin-passwort (teacher''s and phd''s
laptops),
the only thing that we admins do as support is reinstall.

I think that it is not wise to let users be able to do things with the  
system. Then most of the time things will fall apart.

Sorry this is off-topic.

Have fun,
udo.

-- 
:: udo waechter - root@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

Comments in-line...

On Jun 29, 8:40 am, Nigel Kersten <nig...@google.com>
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.
munki''s package metadata has an optional key for each installation
item called
"installs" which is an array of items that can be application bundles,
other bundle types, Info.plists, directories, and simple files. munki
can check for simple existence, or compare against a stored checksum,
or check version info in the case of bundles and Info.plists, and
based on this info, decide a package needs to be installed (or re-
installed). This provides a measure of "self-healing".

munki also uses the standard Receipts mechanism and the package
database - so if a package has been manually installed, munki won''t
try again.

> 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.
munki''s metadata formalizes the relationship between pkg ids and the
install item (.dmg or flat package).

-Greg

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---