[et-mgmt-tools] Cobbler and the ownership module, question about policies?

[Slinky]

I think if we are to deploy Cobbler more, we would create something which
allows remote communication to cobbler. It wouldn't care about import or
such, just things like add/remove/edit objects like
distros/profiles/systems/kickstarts and maybe sync.

The end result would be a "cobbler client" talking to the XMLRPC interface,
using kerberos5 credentials to get access (but at this point I'm not too
sure how I can pass my krb credential as a blob to Cobbler for checking with
kerberos.

For the moment if we really need the client, we can create somehting using
demo_connect and pass the approapriate credentials to ldap, via Cobbler, but
in the end we would need authentication as transparent as possibe.

If the setuid option comes in though, we like this a lot. It means we start
to move away from cobbler running as root....

Just some mumblings after lunch.



On 01/04/2008, Michael DeHaan <mdehaan at redhat.com> wrote:
>
> Michael DeHaan wrote:
>
> > Slinky wrote:
> >
> > >
> > >
> > > On 31/03/2008, *Michael DeHaan* <mdehaan at redhat.com <mailto:
> > > mdehaan at redhat.com>> wrote:
> > >
> > >
> > > -slash-
> > >
> > >    The command line has none of these restrictions so you can always
> > >    recover/reconfigure things with root if you find you've somehow
> > > locked
> > >    yourself out.
> > > Will this always been the case? We'd like to see the same ownership
> > > model apply to the webui and CLI.
> > >
> >
> > Originally I wasn't planning on adding auth to the command line.
> > Interesting idea.
> >
> > You could also perhaps get away with making a simple remote command line
> > that only contained the features you needed and used the existing
> > XMLRPC/CobblerWeb code as a basis.   It would have to accept a username and
> > password, possibly from doing something like reading ~/.cobbler.rc or
> > something?   If it didn't have to do things like "import" it would be pretty
> > simple.
> >
> > There are more complicated alternatives involving ACLs and setuid (non
> > root), but I think I like that solution better.
> >
> > Thoughts?
> >
>
> Actually the local approach may not be too bad either.
>
> We make cobbler setuid to a cobbler user (not by default, but in this
> configuration only), set that user up with ACLs on the right places, and
> turn on a flag in settings that says "require_local_auth".  We make the api
> module in cobbler make the same calls Cobbler is using for remote if
> "require_local_auth" is on.  And then we require user/password info when
> "require_local_auth" is enabled by adding some new arguments or reading a
> file in "~/" (or something... yes, kerberos is in the running but we must
> also support /non/ kerberos).
> Setup will not be super-trivial, but we could perhaps make a sample script
> to help people with that configuration.
> I see Dan has this use case, but does anyone else?   I hesistate to add to
> much to support niche cases, though often these seem to be some of the
> things larger installs are sometimes looking for.
>
> --Michael
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>



-- 
Regards
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20080402/4aa45feb/attachment.htm>