[et-mgmt-tools] Re: Cobbler Authorisation

Michael DeHaan mdehaan at redhat.com
Mon Nov 12 15:53:12 UTC 2007


Dan wrote:
> I'm keen on a modular approach. It means that when/if a requirement
> changes later down the road, chances our we just rewrite/add a module,
> rather that touch the core. Not having to touch the core also makes
> integrating future releases ten times easier.
>   

+1
> Distributions/images here don't just come from sysadmins, they're also
> internally created by users. Somebody may create a custom image which
> they wish to deploy on their cluster of 50 systems which they're solely
> responsible for. 
>
> At present, they send us the image, we manually add it to the server,
> manually amend configurations for it to be available... This is a time
> consuming activity, especially if the provider is sending over several
> images a week. We'd like to allow them to upload their own
> images/distributions, without taking up the time of our already busy
> sysadmins. We want them to take control of provisioning their systems,
> from start to finish, all on their own. We simply provide the install
> mechanism.
>
> If I need to fill in any gaps here, let me know.
>   
Yep... It's going to be difficult to model the behaviors that are 
important for a lot of different sites that are trying to replicate
different existing policies.   So, yes, this definitely points down the 
module route.

This seems to say that some users should be able to add distros, and 
edit the ones they've added,
but not modify distros that belong to others.   Right?  

Cobbler doesn't have the capability to upload initrd/kernel files to the 
WebUI yet, but as we do things like make
"cobbler import" web accessible, that is a direction we could 
consider.   Patches always welcome, of course :)

>
> Modules ftw!
>
>   
:)

>
> Yes, we need authorization/authentication at CLI, as well as webUI. 
> Not everybody wants to use a webui and not everybody wants to use a CLI,
> so we need to provide an interface for both to keep them all sweet.  
>   

Most likely all the security infrastructure will be implemented at the 
web services layer ... so this
would mean remoting the CLI.   I'd rather not do this when SSH works so 
well and it's a kludge
to maintain/develop otherwise.

If you've got a specific need for a remote app, you could write 
something simple using the XMLRPC API.

I'm guessing that would be an app that did the equivalent of "system 
edit" for people who just wanted
to modify the boot configurations of their systems, etc.





More information about the et-mgmt-tools mailing list