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@xxxxxxxxxx> wrote:
Michael DeHaan wrote:
Slinky wrote:
On 31/03/2008, *Michael DeHaan* <mdehaan@xxxxxxxxxx <mailto:mdehaan@xxxxxxxxxx>> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
--
Regards
Dan
_______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
