Using Puppet for Application package installation

[Dhaval]

Hello Guys,

i want to know, can we use puppet to install application packages ( not system packages ) .. if yes how , if someone can through some light ..

my requirement is

1) application team can create package on their own and update in yum repo ( without root )

2) application team can install package on their own ( without root ) to the directories mention in rpm ..

let me know if anyone is aware of similar things available ?

Thanks in advance ...

Regards,

D

[Peter Brown]

If you have them in a yum repository just add the repo to your node and install it the usual way with package.

Or do you want to manage the packages in the custom yum repository?

--
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...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[jcbollinger]

On Thursday, April 4, 2013 8:39:51 AM UTC-5, Dhaval wrote:

Hello Guys,

i want to know, can we use puppet to install application packages ( not system packages ) .. if yes how , if someone can through some light ..

my requirement is

1) application team can create package on their own and update in yum repo ( without root )

2) application team can install package on their own ( without root ) to the directories mention in rpm ..

These don't really seem to be Puppet issues.  In particular, Puppet works within the security framework of target nodes; it does not sidestep it.

Your application team can certainly create packages for the target platform(s); this would normally be part of the test or release process, and although you could wrap some Puppet automation around it, you don't need Puppet for that.

You don't need Puppet to give your application team the ability to update your yum repo.  If that's what you intend to do then you might as well let them do so directly; you do not gain any meaningful security by making Puppet mediate the process.

Generally speaking, package installation should require root privilege.  Indeed, enabling a user to manage packages allows them to modify any file on the system, so it effectively grants them root privilege even if they don't explicitly have it.  You can configure Puppet to automatically update target systems with the latest available versions of your application packages, but to do so it must run with privilege, so you cannot easily provide for your application team to trigger that behavior on demand.

To sum up, the only place I really see Puppet entering the picture is the package installation part.  The overall process might look like this:

1. Application team creates a new version of the application package(s)
2. Application team uploads the new package(s) to the local repository, and updates the repository metadata
3. Application team waits for the next scheduled Puppet run, during which Puppet applies the updated packages.

John

[Owen Smith]

Greetings,

We are using Puppet to deploy application packages, so it can indeed be done. However, you need to do some work around Puppet to enable the use cases you've mentioned:

* Something builds the package

* Something publishes the package to the yum repo

* Something kicks Puppet on the node(s) you want to install on (either starting it up in daemon mode or executing it)

* Someone (or something) ensures that package declarations are properly assigned to your node.

* At this point, Puppet takes over, figures out what packages need to be installed/upgraded, and handles that for you, in addition to whatever configuration and service control you've specified.

In short: you need a build/deployment system that uses Puppet configuration management at its core. In our case, we glued this together ourselves.

Some things to be aware of:

* To use the YUM package provider, Puppet must run as root. Therefore, whatever kicks Puppet has to run as root as well. We use MCollective for this, which involves a root agent running as a daemon on the endpoint.

* Puppet's RPM/YUM providers install packages as root into the standard system RPMDB. So, you can see, by going this route your application packages are going to be handled just like any other system package.

In other words, the key to making this easy is this: though the user doesn't have root access on the node, the deployment system does. You control who can do what to the node through authentication and authorization in the deployment system itself, and by constraining the set of operations that the deployment system supports.

Let's say this solution isn't a possibility: for example, you use a custom user/RPMDBs/prefix/RPMRC when installing via RPM. You *can* theoretically make this work with Puppet, but you've got a lot of work on your hands, because the existing package type/providers don't support it. You have my sympathy, because that's where we've been, and over the years we've banged our head against that wall so many times, for many reasons besides Puppet. One of our tenets in moving to Puppet, however, was to stop doing things that made our life needlessly difficult. :-)

If you go this way, you also need to give some thought as to how you want to upgrade an existing application on the endpoint. One way is to use 'ensure => latest' and configure the YUM repo on the node to point to a new repo with your updated packages when the time comes. Another possibility is to use 'ensure => present' and do an explicit 'yum upgrade' operation through MCollective to get the packages updated; then run Puppet to fix up the rest.

Hope this helps!

-- O

[Owen Smith]

A clarification: "whatever kicks Puppet has to run as root as well" could be something that doesn't run as root but does have sudo permissions!

-- O

[Dhaval]

Thank You guys, for the explaining  ... 

I think i have to find out something .. which helps to maintain repos without SA intervention and which as authentication and authorization ....  and then use puppet to install those packages on systems ..

and i think pulp can do this ..