Rootless Puppet

[Spencer Krum]

Hello,

I was recently reached out to by someone who was interested in using Puppet without root. I gave a presentation on this at Puppet Conf 2013. There aren't a lot of resources about how to do this available to the general public.

I believe that there is a block of people doing this but most are being silent about it. I would like to start a discussion about this, and hopefully generate some resources for the next group of people trying to implement a system like this.

I would like people who are doing this to chime in that they are doing so, just generating some numbers from this thread would be very useful. I would also like people to share their techniques for getting Puppet working. I am especially interested in what patterns people are using to manage applications, etc with Puppet. For instance, in my environment we have a munging of the Package-File-Service model that we use to deploy some java applications.

I also have a corpus of rootless-puppet defined types and facts for public consumption at:

https://github.com/utiworldwide/

A few default questions to spark descriptions of your environment, with my answers.

Are you using Puppet in a rootless environment?

Yes

What version of Puppet?

3.2.4 Master,  3.1 clients

Are you using PuppetDB, a dashboard, and/or Hiera?

We have hiera, hiera-file, PuppetDB(using the in-memory datastore), and PuppetBoard leightweight dashboard.

Are you running the Master from nonroot?

Yes

Are you running masterless with puppet apply ?

No

How are you running the Master?

Under Passenger/Apache

What are you managing with Puppet?

We are deploying and confguring java applications. We are setting crons. We are setting up NRPE daemon and its configuration. We are shipping java keystores and required .jar files for the application.

How did you install Puppet?

We build a userland with all the libraries and tar'd it up. Then we untar it where we need it.

Thanks for your input everybody!

Spencer Krum

[James Henderson]

Hello,

I am the guy who Spencer is talking about.  Since I am brand new to puppet, and puppet non-root is not well supported at this time, we have decided to go with a more script based option.

However I am very interested in the future of puppet and I am willing to provide input, testing and development help as time permits.

I agree with Spencer in saying that there are an awful lot of companies that are either

a) interested in non-root puppet, but aren't using it because it isn't well supported

b) using it despite the challenges

I would love to hear from more people who are in the same boat.

-James Henderson

[Klavs Klavsen]

I know of several who have managed servers, but want to use Puppet to roll manage the applications they install, and whatelse they have been allowed to manage - but that will never be able to run puppet as root, since the OS is not their responsibility.

Also - some of those, the managers of the server use puppet (as root) to set them up - but again - they can't share puppet repo.. so it would be preferrable to be able to install root elsewhere (they build their own patched version of puppet, to make it support installing under /opt - not something puppet supports very well currently). They are also using puppet on a lot of diff. unix OS'es - so they have to compile it for several themselves, and since they want thing uniform (and none-intrusive) - they choose to install under /opt on all.

[Klavs Klavsen]

Den fredag den 11. oktober 2013 14.12.32 UTC+2 skrev Klavs Klavsen:

so it would be preferrable to be able to install root elsewhere

Dooh - to install puppet elsewhere :) (ie. under /opt/puppet f.ex.)

[R.I.Pienaar]

----- Original Message -----
> From: "James Henderson" <james.m....@gmail.com>
> To: puppet...@googlegroups.com
> Sent: Thursday, October 10, 2013 10:17:31 PM
> Subject: [Puppet Users] Re: Rootless Puppet
>
> Hello,
>
> I am the guy who Spencer is talking about. Since I am brand new to puppet,
> and puppet non-root is not well supported at this time, we have decided to
> go with a more script based option.
>
> However I am very interested in the future of puppet and I am willing to
> provide input, testing and development help as time permits.
>
> I agree with Spencer in saying that there are an awful lot of companies
> that are either
>
> a) interested in non-root puppet, but aren't using it because it isn't well
> supported

when you say "isn't well supported" what do you mean? Sure for Puppet Enterprise
I don't think there is a good/sanctioned workflow but puppet as non root user
works just fine out of the box with the obvious restrictions.

[jcbollinger]

On Thursday, October 10, 2013 4:17:31 PM UTC-5, James Henderson wrote:

Hello,

I am the guy who Spencer is talking about.  Since I am brand new to puppet, and puppet non-root is not well supported at this time, we have decided to go with a more script based option.

You should use what works best for you, of course, but like R.I., I'm not sure what you mean by "not well supported".  I'd estimate that Puppet non-root is not widely used, but that's because many of the resources that people want to manage cannot be modified by unprivileged users.  That's not a problem that Puppet (or any other system) can solve.

 

However I am very interested in the future of puppet and I am willing to provide input, testing and development help as time permits.

How about starting by describing some of the features you think Puppet should have to support non-root use well?


John

[James Henderson]

On Friday, October 11, 2013 9:28:44 AM UTC-4, jcbollinger wrote:

On Thursday, October 10, 2013 4:17:31 PM UTC-5, James Henderson wrote:

Hello,

I am the guy who Spencer is talking about.  Since I am brand new to puppet, and puppet non-root is not well supported at this time, we have decided to go with a more script based option.

You should use what works best for you, of course, but like R.I., I'm not sure what you mean by "not well supported".  I'd estimate that Puppet non-root is not widely used, but that's because many of the resources that people want to manage cannot be modified by unprivileged users.  That's not a problem that Puppet (or any other system) can solve. 

 

What I mean by "not well supported":

 - installing puppet if you do not have root is a non-trivial exercise and isn't documented anywhere that I could find.  In my case we could probably get the sys admins to install a version, but at my company it is definitely better to do things yourself.

 - most packages on puppetforge will not work out of the box as they do assume that you have root access

 - you need to write your puppet files in a special way in order to use them without root

 - when someone asked on ask.puppetlabs.com about this configuration, here is the answer they got: https://ask.puppetlabs.com/question/413/puppet-agent-running-as-unprivileged-user/

  - this answer does not show that this is a typical and supported option, rather it is an option that you can make work if you write all of your manifests in a very particular way.

 

However I am very interested in the future of puppet and I am willing to provide input, testing and development help as time permits.

How about starting by describing some of the features you think Puppet should have to support non-root use well?

I am brand new to puppet, so I certainly don't know the best way to solve these issues.

The basic problem is that puppet assumes that it is root and you need to specifically craft your manifests to know that fact.

My wishlist would be:

 - clear documentation stating what is and what is not possible under this configuration

 - some method for puppet to run where it does not perform any ownership or user editing at all

 - a way to target puppet at a particular location of the filesystem rather than just root by default (maybe this exists already)

John

One point is that the usual "non-root puppet" configuration is actually simpler than the "puppet as root" configuration as far as user management goes.  This simplicity is because from the context of the puppet install, there is only one user.  So there is never a need to run chown on any puppet managed file or to sudo to any other user.

Again, I am very new to puppet.  I read some of the docs and went through the lessons.  I googled the problems I was having (using puppet to deploy to a particular directory in a non-root context).  After that, this is what I observe.  Maybe some of my points reek of my lack of knowledge about puppet and I apologize for that.

Thanks for your time,

James

[R.I.Pienaar]

----- Original Message -----
> From: "James Henderson" <james.m....@gmail.com>
> To: puppet...@googlegroups.com
> Sent: Friday, October 11, 2013 4:12:21 PM
> Subject: [Puppet Users] Re: Rootless Puppet
>
>
>

> On Friday, October 11, 2013 9:28:44 AM UTC-4, jcbollinger wrote:
> >
> >
> >
> > On Thursday, October 10, 2013 4:17:31 PM UTC-5, James Henderson wrote:
> >>
> >> Hello,
> >>
> >> I am the guy who Spencer is talking about. Since I am brand new to
> >> puppet, and puppet non-root is not well supported at this time, we have
> >> decided to go with a more script based option.
> >>
> >
> >
> > You should use what works best for you, of course, but like R.I., I'm not
> > sure what you mean by "not well supported". I'd estimate that Puppet

> > non-root is not widely *used*, but that's because many of the resources

> > that people want to manage cannot be modified by unprivileged users.
> > That's not a problem that Puppet (or any other system) can solve.
> >
>
> >
> What I mean by "not well supported":
> - installing puppet if you do not have root is a non-trivial exercise and
> isn't documented anywhere that I could find. In my case we could probably
> get the sys admins to install a version, but at my company it is definitely
> better to do things yourself.

export GEM_HOME=~/.gem
gem install puppet
export PATH=$PATH:~/.gem/bin

puppet --version

> - most packages on puppetforge will not work out of the box as they do
> assume that you have root access

yes, packages are gonna require root.

> - you need to write your puppet files in a special way in order to use
> them without root

not really, it just means you need to not try to do things only root can do
past that nothing changes.

> - when someone asked on ask.puppetlabs.com about this configuration, here
> is the answer they got:
> https://ask.puppetlabs.com/question/413/puppet-agent-running-as-unprivileged-user/
> - this answer does not show that this is a typical and supported option,
> rather it is an option that you can make work if you write all of your
> manifests in a very particular way.

the agent just works if you start it as your user, you'll have instead of /var/lib/puppet
~/.puppet and everything else roughly stays the same.

If you put the manifests in your homedir you can just use puppet apply and do
not even need a master to fully manage everything your user can managed

[Trevor Vaughan]

OpenShifit is trying to abstract away a lot of the issues with this type of scenario.

Unfortunately, I'm not certain of the support on non RHEL-based distros at this point but the idea is at least worth looking at.

http://openshift.github.io/

On Fri, Oct 11, 2013 at 8:12 AM, Klavs Klavsen <kl...@enableit.dk> wrote:

I know of several who have managed servers, but want to use Puppet to roll manage the applications they install, and whatelse they have been allowed to manage - but that will never be able to run puppet as root, since the OS is not their responsibility.

Also - some of those, the managers of the server use puppet (as root) to set them up - but again - they can't share puppet repo.. so it would be preferrable to be able to install root elsewhere (they build their own patched version of puppet, to make it support installing under /opt - not something puppet supports very well currently). They are also using puppet on a lot of diff. unix OS'es - so they have to compile it for several themselves, and since they want thing uniform (and none-intrusive) - they choose to install under /opt on all.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Spencer Krum]

So I've been in contact with Puppet Labs and will be doing a blog post on how to do Puppet without Root. I'm hoping to keep it very 'this is what I do, there are lots of ways to solve this problem'. If there are specific things you'd like to see in this please speak up. My plan is to punt on installing it, and get straight to package, file, service with Puppet in a rootless environment.

R. I., you said to install:

 

export GEM_HOME=~/.gem
gem install puppet
export PATH=$PATH:~/.gem/bin
puppet --version

This is the easiest installation and not representative of my situation. At my place of work we don't have Ruby installed from packages so we have to build one from source and push it out. We also have to push out some libraries, most notably libyaml, as well. After this is set up the gem/rvm install works okay. I've tried pushing binary rubies out with rvm's tooling but I couldn't get it working. I think the problem is that even when rvm is pushing a binary, it depends on having some minimum libraries installed as system libs.

With any source installation, upgrading is a major undertaking, and its not clear to me under the current scheme how I would use Puppet to upgrade itself.

With any non-root installation the question comes up how to enable a daemon. Right now I have @reboot crons to fire off the Puppet agent. More time than I would like is spent looking which hosts' Puppet has died in icinga and going out and restarting them.

Two(related) problems I have when running Puppet without root:

1) The File resource:

If we have a file resource like:

file { '/tmp/foobar':

   source => "puppet:///blah",

   ensure => file,

}

The group and owner are unmanaged but do not default to the user puppet is running as. They also don't default to the root user. The user and group are copied over from the file on disk on the puppet master. Or at least I think thats whats going on. This means I have to do stuff like this:

file {'/tmp/foobar':

   source => 'puppet://blah',

   ensure => file,

   owner   => $owner,

   group   => $group,

}

Which means I need to know the owner and group of Puppet. Which takes us to my second problem:

2) Facter doesn't have native facts for detecting what user its running as. It has $id which is ~= the running user, but nothing for the group.

I've written three facts into my rootless module:

$puppet_user

$puppet_group

$puppet_user_home

These are very small facts that just read information from getent.

Again I'm mostly using Puppet to roll out the application.

Thanks,

Spencer Krum

Spencer Krum
(619)-980-7820

[James Henderson]

> >
> > You should use what works best for you, of course, but like R.I., I'm not
> > sure what you mean by "not well supported".  I'd estimate that Puppet
> > non-root is not widely *used*, but that's because many of the resources
> > that people want to manage cannot be modified by unprivileged users.
> > That's not a problem that Puppet (or any other system) can solve.
> >
>  
> >
> What I mean by "not well supported":
>  - installing puppet if you do not have root is a non-trivial exercise and
> isn't documented anywhere that I could find.  In my case we could probably
> get the sys admins to install a version, but at my company it is definitely
> better to do things yourself.

export GEM_HOME=~/.gem
gem install puppet
export PATH=$PATH:~/.gem/bin

puppet --version

That seems easy enough.  Of course the docs say that installing from gem is not recommended:

http://docs.puppetlabs.com/guides/installation.html#installing-from-gems-not-recommended

I'm not sure why it is not recommended though.

>  - most packages on puppetforge will not work out of the box as they do
> assume that you have root access

yes, packages are gonna require root. 

>  - you need to write your puppet files in a special way in order to use
> them without root

not really, it just means you need to not try to do things only root can do
past that nothing changes.

However, puppet by its default assumes that you are root and implicitly uses root only commands.

It would be convenient if puppet could understand that its deployment context was non-root and essentially single

user.  This may be too difficult to do or a bad design decision though.

>  - when someone asked on ask.puppetlabs.com about this configuration, here
> is the answer they got:
> https://ask.puppetlabs.com/question/413/puppet-agent-running-as-unprivileged-user/
>   - this answer does not show that this is a typical and supported option,
> rather it is an option that you can make work if you write all of your
> manifests in a very particular way.

the agent just works if you start it as your user, you'll have instead of /var/lib/puppet
~/.puppet and everything else roughly stays the same.

If you put the manifests in your homedir you can just use puppet apply and do
not even need a master to fully manage everything your user can managed

That sounds great.

I think the best thing to do at this point might just be to document exactly where the state of puppet non-root is.

I looked at the puppet wiki, but it seems to be in a retirement phase.

A documentation page should target people who are looking at puppet for the first time and have a non-root requirement.

The basic questions that need to be answered are:

- how do I install puppet as non-root?

  - are there any risks/gotchas to this sort of puppet install rather than one of the recommended install paths?

- can I use packages that I find on puppet forge as non root?

- what sort of things do I need to watch out for if writing a non-root puppet package?

- are there any other gotchas that I should be aware of?

I wouldn't mind taking the answers to these questions that people are posting here and creating a first draft of such a page.

I do need to know where to put it.  I think the best strategy is to fork the puppet-docs repo and work with whoever can help to come out with a decent page.

Thanks for your help,

James

 

 

[R.I.Pienaar]

----- Original Message -----
> From: "James Henderson" <james.m....@gmail.com>
> To: puppet...@googlegroups.com

because it doesnt bring a service script etcetc, not a problem in this instance.

>
> >
> > > - most packages on puppetforge will not work out of the box as they do
> > > assume that you have root access
> >
> > yes, packages are gonna require root.
>
>
> > > - you need to write your puppet files in a special way in order to use
> > > them without root
> >
> > not really, it just means you need to not try to do things only root can
> > do
> > past that nothing changes.
>
> However, puppet by its default assumes that you are root and implicitly
> uses root only commands.
> It would be convenient if puppet could understand that its deployment
> context was non-root and essentially single
> user. This may be too difficult to do or a bad design decision though.

it wont use them if you do not use those resource types. also there are some
detection of what runs as root and what not and then certain providers are
disabled. no doubt some weirdness left that should be fixable

yeah that sounds good

[KEIGNAERT Mathieu]

Dear all,

I am very new to puppet, I have been playing with puppet a long time ago, I haven't done anything recently with puppet but I try to follow it.
One of my main concern with puppet and what I try to achieve is to have puppet running as both root and non root in the same time.

It won't be a suprise to you but I want to use puppet as root user to setup and ensure the consistency of my server's configuration, and I would like my users to be able to use puppet to manage their applications configuration.
I saw the video of Spencer, and now found this topic. As you correctly said, there is not a lot of documentation out there describing experience of people using puppet as non root.

I believe things have changed since the last post on this subject here (Nov 2013) and I wanted to ask you guys if you have had some success, evolution in the way you use puppet as non root ? Anything changed with latest puppet versions to achieve this ?

Mat

[Felix Frank]

On 01/14/2015 09:55 AM, KEIGNAERT Mathieu wrote:
> Dear all,
>
> I am very new to puppet, I have been playing with puppet a long time
> ago, I haven't done anything recently with puppet but I try to follow it.
> One of my main concern with puppet and what I try to achieve is to
> have puppet running as both root and non root in the same time.
>
> It won't be a suprise to you but I want to use puppet as root user to
> setup and ensure the consistency of my server's configuration, and I
> would like my users to be able to use puppet to manage their
> applications configuration.
> I saw the video of Spencer, and now found this topic. As you correctly
> said, there is not a lot of documentation out there describing
> experience of people using puppet as non root.
>
> I believe things have changed since the last post on this subject here
> (Nov 2013) and I wanted to ask you guys if you have had some success,
> evolution in the way you use puppet as non root ? Anything changed
> with latest puppet versions to achieve this ?
>
> Mat

Hi,

I cannot supply a good user's perspective, but I run Puppet unprivileged
a lot, albeit for debugging and analysis only.

With Puppet 3.x, this works without issue. Users maintain individual
configurations in ~/.puppet/puppet.conf, and everything else defaults to
this location as well, e.g.

$vardir=~/.puppet/var

Just run `puppet agent --configprint all` to get a feeling of Puppet's
environment.

Sure, you cannot manage things from root's domain. Things like service
{} or package {} will not just work, although they are still viable for
e.g. the `base` provider for service, `gem` for package etc.

All things considered, I'm quite convinced that you can have a multitude
of agents sharing the same host, each with individual configuration and
data.

HTH,
Felix