[Pulp-list] Pulp or Puppet (was: Help setting permissions on roles)

[Lutchy Horace (Mailing List)]

On Sun, 1 May 2016 13:02:43 -0400
Kodiak Firesmith <kfiresmith at gmail.com> wrote:

> Lutchy,
> I would not really worry too much about the client certificate model,
> to me it looks pretty darn similar to how RHSM works upstream, and
> within the scope of Pulp it seems like consumers really can't do much
> other than pull packages, subscribe to repos, and update their state
> information to the Pulp server.

Yeah, that really ease my worries. I would have not like the pulp
server compromised and distributing compromise software to all my
systems. 

> To be honest, unless you *need* the Pulp server to manage the package
> state of your hosts, you might find it's a whole lot easier to just
> get back to the un-bound client/server model of having your hosts
> just use .repo files for your repos and use Puppet/Ansible/Etc to
> manage your host's package state.

To be quite honest, Pulp was what was recommended to me (and a lot
reviews I've come across have positives things to say) of
keeping my systems up to date without the need to log into each system
and manually running 'yum update' (or a like). 

At a cursory look at Puppet and what I've read from reviews. 

"Puppet is bloated, complex, and tedious to administer"

And I am quite a lazy admin (who wants to join the automation crowd),
that have ton of projects on my todo list that get backlogged by
maintaining tedious task on my systems. Puppet did not seem like an
ideal solution.

Ideally in a perfect world, a system that accomplish these
tasks would be great:

1) [b]be Light Weight[/b]
2) Have a web interface
3) Centralize management of updating packages across systems on
scheduled bases.
4) Configure reboot per system with E-Mail notification (or configure
reboot with exceptions, systems that are associated in a group)
5) Optionally, centralize location to manage system configurations
(something I saw Spacewalk offer)
5) [b]Great community support[/b]

Pulp seems to solve 1, 2 (although a minimalistic web interface), 3, and
5.

> We already have a pretty robust Puppet installation so we're just
> dropping .repo files with Puppet and making puppet tell our hosts
> when to run package updates.

Yeah, that would be a whole lot easier on the surface. I've already
created my repository, repository group, consumer group, assigned a
single node, and remotely sent a update command to a group with
pulp-admin. Which looks to me, went effortlessly. Perhaps I should
revisit puppet in a test environment which would add another project on
my todo list :(. 

Taking another glance at
https://docs.puppet.com/guides/introduction.html did clear up a few a
things for me. I do like the idea of storing common repetitive task in a
central location.

> We'll probably take another look at the consumer here in a year or
> two and see how well it ends up solidifying into a useful product.

Nothing much to really change unless to make it more secure.
 
>  -Kodiak
> 
> On Sun, May 1, 2016 at 12:46 PM, Lutchy Horace (Mailing List) <
> mailinglist.subscriptions at lhprojects.net> wrote:  
> 
> > On Sun, 1 May 2016 09:53:29 -0400
> > "Lutchy Horace (Mailing List)"
> > <mailinglist.subscriptions at lhprojects.net> wrote:
> >  
> > >
> > > I don't mind registering clients with the admin user. However, I
> > > do have a concern. Do consumers need the admin password to update
> > > from repository? Assuming that admin password is no where stored
> > > on the consumer machines? And lastly, assuming the consume
> > > machine has been compromise, is the Pulp server at risk from
> > > pulp-consumer?  
> >
> > Reviewing
> >
> > https://pulp.readthedocs.io/en/latest/user-guide/consumer-client/register.html
> > .
> > It appears that a certificate is stored on the consumer machine:
> >
> > /Once a consumer is registered, a certificate is written into its
> > PKI: `/etc/pki/pulp/consumer/consumer-cert.pem`
> >
> > This certificate will automatically suffice for authentication
> > against the server’s API for all future operations until the
> > consumer is unregistered./
> >
> > This is a bit troublesome as I am unfamiliar of the security
> > implications of pulp-consumer. I looked over 'pulp-consumer' command
> > options and it appears that is not much it can do. Although I
> > wonder if a malicious user on a compromise machine can use the the
> > client certificate to conduct malicious activities via REST API?
> >
> > Regards
> >
> > --
> > Lutchy Horace
> > Owner/Operator/Administrator [http://www.lhprojects.net]
> > Owner/Operator/Administrator [http://www.bombshellz.net]
> > Owner/Operator/Administrator [http://www.animehouse.club]
> > About Me [http://about.me/lhprojects]
> > USA
> >
> > _______________________________________________
> > Pulp-list mailing list
> > Pulp-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-list
> >  



-- 
Lutchy Horace
Owner/Operator/Administrator [http://www.lhprojects.net]
Owner/Operator/Administrator [http://www.bombshellz.net]
Owner/Operator/Administrator [http://www.animehouse.club]
About Me [http://about.me/lhprojects]
USA