Modifying Web UI

[Paul Company]

I'm running cobbler 1.6.6 on RHEL 5.3.

Three Questions:

Q1: Is there a way to have the Web UI behavior change according to the
person that logs in?
For example, I'd like it if user "foo" has full access to everything,
but user "bar" to only be able to  create systems.
Listing distros, profiles, and repos is ok, but I don't want
bar to have the ability to add or delete distros, profiles or repos.

Q2: Has anyone customized the "Add System" web page?
I'm not a web programmer but I'd like to simplify/customize
the "Add System" page so it's simpler for our end user.
I'd to add fields like "Location" and have the values entered
show up as --ksmeta values; so if you enter Location: nyc,
that would get processed into --ksmeta="loc=nyc"
Also, things like, if one chooses a profile that isn't a vm profile,
then don't show the VM stuff. Or if power management
is disabled, don't show the power management stuff. etc.

Q3: Should I wait for cobbler 2.0 which uses Django?
      Or should I plow ahead with the current mod_python stuff?

Any tips/information/examples on developing mod_python or Django web
pages would be a big help.

Thanks,

Paul

[Michael DeHaan]

On 08/11/2009 09:33 PM, Paul Company wrote:
>  I'm running cobbler 1.6.6 on RHEL 5.3.
>
>  Three Questions:
>
>  Q1: Is there a way to have the Web UI behavior change according to the
>  person that logs in?
>  For example, I'd like it if user "foo" has full access to everything,
>  but user "bar" to only be able to  create systems.
>  Listing distros, profiles, and repos is ok, but I don't want
>  bar to have the ability to add or delete distros, profiles or repos.
>      
There is the "authz_ownership" module which is detailed on the Wiki 
under the security pages, that can restrict
what objects people can edit.

At a generic level, there's not a concept for a read-only user group, 
but that's probably something that could be easily
added.

As a sidenote, since you sound like you are interested in helping us 
work on Cobbler Web, new things need to be done on the "master"
branch, which targets 2.0 -- that should be out in a month.
>  Q2: Has anyone customized the "Add System" web page?
>  I'm not a web programmer but I'd like to simplify/customize
>  the "Add System" page so it's simpler for our end user.
>  I'd to add fields like "Location" and have the values entered
>  show up as --ksmeta values; so if you enter Location: nyc,
>  that would get processed into --ksmeta="loc=nyc"
>  Also, things like, if one chooses a profile that isn't a vm profile,
>  then don't show the VM stuff. Or if power management
>  is disabled, don't show the power management stuff. etc.
>      
We've had some ideas on this, about making templates for self-service 
views in Cobbler.

This could be done as a seperate Django app in the cobbler Django 
project, and I would like to see something like
this very much.

It really warrants a new thread on cobbler-devel list there, would you 
like to start one?

I have a fair amount of ideas from our own IT guys -- things that we 
didn't quite implement yet -- but I think that would be exceptionally
powerful. Some of those also dovetail into puppet recipe configuration 
through a similar interface, which I'm not sure if you are interested in.

>  Q3: Should I wait for cobbler 2.0 which uses Django?
>         Or should I plow ahead with the current mod_python stuff?
>      
Aha, I got ahead of myself. Glad you're aware of that :)

Yes, we need to do things on 2.0, since it will be out soon, and porting 
anything done to the old codebase will be a lot of extra effort.

>  Any tips/information/examples on developing mod_python or Django web
>  pages would be a big help.
>      
Do a checkout of git's master branch and do a "make webtest" to get
started.

Code lives in the "web" directory and should be fairly self explanatory, 
but I'd be more than happy to answer any specific questions.

Hoping on #cobbler and #cobbler-devel on irc.freenode.net is also a 
great idea.

>  Thanks,
>
>  Paul
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Paul Company]

>  There is the "authz_ownership" module
https://fedorahosted.org/cobbler/wiki/AuthorizationWithOwnership
Thank you, I'll look into it.
Can it be used with Kerberos?
I currently have Kerberos working and it seems to require (authz_allowall).
I'll test it and see if it works.

>  As a sidenote, since you sound like you are interested in helping us
> work on Cobbler Web, 
I'd love to, but I'm not familiar with Django (Python)
development.
Both have steep learning curves - especially since I'm starting from scratch.
It'll be months before I'm even a little bit productive.
I love learning new things, so I'll start climbing the Python/Django
learning curve now
and I'll let you know when I'm skilled enough to contribute.

>  This could be done as a seperate Django app in the cobbler Django
> project
>  It really warrants a new thread on cobbler-devel list there, would you like to start one?
I would, but not quite yet.
We're going to deploy cobbler 1.6.6.
Feels like this thread will be good when we decide to go with 2.0.
For now I'm going to concentrate on modifying the Systems page for 1.6.6.
Any suggestions there?

Paul

On Wed, Aug 12, 2009 at 8:47 AM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>  On 08/11/2009 09:33 PM, Paul Company wrote:
> > I'm running cobbler 1.6.6 on RHEL 5.3.
> >
> > Three Questions:
> >
> > Q1: Is there a way to have the Web UI behavior change according to the
> > person that logs in?
> > For example, I'd like it if user "foo" has full access to everything,
> > but user "bar" to only be able to  create systems.
> > Listing distros, profiles, and repos is ok, but I don't want
> > bar to have the ability to add or delete distros, profiles or repos.
> >
>  There is the "authz_ownership" module which is detailed on the Wiki
>  under the security pages, that can restrict
>  what objects people can edit.
>
>  At a generic level, there's not a concept for a read-only user group,
>  but that's probably something that could be easily
>  added.
>
>  As a sidenote, since you sound like you are interested in helping us
>  work on Cobbler Web, new things need to be done on the "master"
>  branch, which targets 2.0 -- that should be out in a month.
> > Q2: Has anyone customized the "Add System" web page?
> > I'm not a web programmer but I'd like to simplify/customize
> > the "Add System" page so it's simpler for our end user.
> > I'd to add fields like "Location" and have the values entered
> > show up as --ksmeta values; so if you enter Location: nyc,
> > that would get processed into --ksmeta="loc=nyc"
> > Also, things like, if one chooses a profile that isn't a vm profile,
> > then don't show the VM stuff. Or if power management
> > is disabled, don't show the power management stuff. etc.
> >
>
>  We've had some ideas on this, about making templates for self-service
>  views in Cobbler.
>
>  This could be done as a seperate Django app in the cobbler Django
>  project, and I would like to see something like
>  this very much.
>
>  It really warrants a new thread on cobbler-devel list there, would you
>  like to start one?
>
>  I have a fair amount of ideas from our own IT guys -- things that we
>  didn't quite implement yet -- but I think that would be exceptionally
>  powerful.  It really warrants a new thread on cobbler-devel list there, would you
>  like to start one?
>
> > Q3: Should I wait for cobbler 2.0 which uses Django?
> >        Or should I plow ahead with the current mod_python stuff?
> >
>
>  Aha, I got ahead of myself. Glad you're aware of that :)
>
>  Yes, we need to do things on 2.0, since it will be out soon, and porting
>  anything done to the old codebase will be a lot of extra effort.
>
> > Any tips/information/examples on developing mod_python or Django web
> > pages would be a big help.
> >
>
>  Do a checkout of git's master branch and do a "make webtest" to get
> started.
>
>  Code lives in the "web" directory and should be fairly self explanatory,
>  but I'd be more than happy to answer any specific questions.
>
>  Hoping on #cobbler and #cobbler-devel on irc.freenode.net is also a
>  great idea.
>
> > Thanks,
> >
> > Paul
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Michael DeHaan]

On 08/12/2009 02:20 PM, Paul Company wrote:
> > There is the "authz_ownership" module
> >      
>  https://fedorahosted.org/cobbler/wiki/AuthorizationWithOwnership
>  Thank you, I'll look into it.
>  Can it be used with Kerberos?
>  I currently have Kerberos working and it seems to require (authz_allowall).
>  I'll test it and see if it works.
>
>      
The AuthN and Z peices do not know about each other, so yes, it can.

> > As a sidenote, since you sound like you are interested in helping
> us work on Cobbler Web,
> >      
>  I'd love to, but I'm not familiar with Django (Python) development.
>  Both have steep learning curves - especially since I'm starting from scratch.
>      
I disagree -- The Django app is infinitely easier to work on that the 
mod_python one
and is a lot easier to work on because the templates are simpler, and 
there are now even less
of them.   We are also not even using the persistance layers of Django, 
since views.py just
speaks XMLRPC back to cobblerd.

>  It'll be months before I'm even a little bit productive.
>  I love learning new things, so I'll start climbing the Python/Django
>  learning curve now
>  and I'll let you know when I'm skilled enough to contribute.
>
>     
> > This could be done as a seperate Django app in the cobbler Django project
> > It really warrants a new thread on cobbler-devel list there, would you like to start
> one?
> >      
>  I would, but not quite yet.
>  We're going to deploy cobbler 1.6.6.
>  Feels like this thread will be good when we decide to go with 2.0.
>  For now I'm going to concentrate on modifying the Systems page for 1.6.6.
>  Any suggestions there?
>      
Once 2.0 releases, there will be no further updates to the 1.6 branch.

Thankfully, nothing really changes from a user perspective, only new 
features, and easier development.

I can't help you working on 1.6.6, because that's an evolutionary dead 
end -- and subtracts
time from working on things other people will be able to get in future 
releases.

The authz modules in fact, are still pretty much the same, though I'm 
due to make some improvements to them
in coming week or so -- to make sure they are up-to-date with all of the 
new method names and so forth.

It's quite safe to try out now, and there is a very smooth upgrade path 
for production machines.

>  Paul
>
>  On Wed, Aug 12, 2009 at 8:47 AM, Michael DeHaan<mdehaan(a)redhat.com>  wrote:
>     
> > On 08/11/2009 09:33 PM, Paul Company wrote:
> >      
> >> I'm running cobbler 1.6.6 on RHEL 5.3.
> >>
> >> Three Questions:
> >>
> >> Q1: Is there a way to have the Web UI behavior change according to the
> >> person that logs in?
> >> For example, I'd like it if user "foo" has full access to
> everything,
> >> but user "bar" to only be able to  create systems.
> >> Listing distros, profiles, and repos is ok, but I don't want
> >> bar to have the ability to add or delete distros, profiles or repos.
> >>
> >>        
> > There is the "authz_ownership" module which is detailed on the Wiki
> > under the security pages, that can restrict
> > what objects people can edit.
> >
> > At a generic level, there's not a concept for a read-only user group,
> > but that's probably something that could be easily
> > added.
> >
> > As a sidenote, since you sound like you are interested in helping us
> > work on Cobbler Web, new things need to be done on the "master"
> > branch, which targets 2.0 -- that should be out in a month.
> >      
> >> Q2: Has anyone customized the "Add System" web page?
> >> I'm not a web programmer but I'd like to simplify/customize
> >> the "Add System" page so it's simpler for our end user.
> >> I'd to add fields like "Location" and have the values entered
> >> show up as --ksmeta values; so if you enter Location: nyc,
> >> that would get processed into --ksmeta="loc=nyc"
> >> Also, things like, if one chooses a profile that isn't a vm profile,
> >> then don't show the VM stuff. Or if power management
> >> is disabled, don't show the power management stuff. etc.
> >>
> >>        
> > We've had some ideas on this, about making templates for self-service
> > views in Cobbler.
> >
> > This could be done as a seperate Django app in the cobbler Django
> > project, and I would like to see something like
> > this very much.
> >
> > It really warrants a new thread on cobbler-devel list there, would you
> > like to start one?
> >
> > I have a fair amount of ideas from our own IT guys -- things that we
> > didn't quite implement yet -- but I think that would be exceptionally
> > powerful.  It really warrants a new thread on cobbler-devel list there, would you
> > like to start one?
> >
> >      
> >> Q3: Should I wait for cobbler 2.0 which uses Django?
> >>         Or should I plow ahead with the current mod_python stuff?
> >>
> >>        
> > Aha, I got ahead of myself. Glad you're aware of that :)
> >
> > Yes, we need to do things on 2.0, since it will be out soon, and porting
> > anything done to the old codebase will be a lot of extra effort.
> >
> >      
> >> Any tips/information/examples on developing mod_python or Django web
> >> pages would be a big help.
> >>
> >>        
> > Do a checkout of git's master branch and do a "make webtest" to get
> started.
> >
> > Code lives in the "web" directory and should be fairly self explanatory,
> > but I'd be more than happy to answer any specific questions.
> >
> > Hoping on #cobbler and #cobbler-devel on irc.freenode.net is also a
> > great idea.
> >
> >      
> >> Thanks,
> >>
> >> Paul
> >> _______________________________________________
> >> cobbler mailing list
> >> cobbler(a)lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/cobbler
> >>
> >>        
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
> >      
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Paul Company]

> > Can it be used with Kerberos?
>  The AuthN and Z peices do not know about each other, so yes, it can. 
Doesn't seem to work for me.

The following configuration allows me to login with my Kerberos creds
(pcompany or user2),
but I seem to only have "list" permissions on all the objects.
The documentation says:
     Users that authenticate against the chosen cobbler authentication module
     but who are not mentioned in users.conf will still be given read
access to view
     things in the Cobbler web interface, but will not be able to
perform any actions,
     such as sync, deletion, and edits.

Well, pcompany & user2 *are* "listed in users.conf" in the [admins]
and [jradmin] sections.
The way I understand it, pcompany should have full access under this
configuration;
and user2 should fall thru to the acl.conf jradmin permissions and
only have those permissions.
Why does the below configuration not work?
What am I missing?

Here is what I have configured:

# vi /etc/cobbler/modules.conf
[authentication]
module = authn_passthru

[authorization]
module = authz_ownership
:wq!

# vi /etc/cobbler/users.conf
[admins]
admin = ""
cobbler = ""
pcompany = ""

[jradmin]
user2 = ""
:wq!

# vi /etc/cobbler/acls.conf
admin: {}
admins: {}
jradmin:
    copy_distro: {}
    copy_image: {}
    copy_profile: {}
    copy_repo: {}
    modify_distro: {}
    modify_image: {}
    modify_profile: {}
    modify_repo: {}
    new_distro: {}
    new_image: {}
    new_profile: {}
    new_repo: {}
    remove_distro: {}
    remove_image: {}
    remove_profile: {}
    remove_repo: {}
    save_distro: {}
    save_profile: {}
    save_image: {}
    save_repo: {}
    write_kickstart_templates: {}
unmatched: {}
:wq!



On Wed, Aug 12, 2009 at 12:18 PM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>  On 08/12/2009 02:20 PM, Paul Company wrote:
>
>  There is the "authz_ownership" module
>
>
>  https://fedorahosted.org/cobbler/wiki/AuthorizationWithOwnership
>  Thank you, I'll look into it.
>  Can it be used with Kerberos?
>  I currently have Kerberos working and it seems to require (authz_allowall).
>  I'll test it and see if it works.
>
>
>
>  The AuthN and Z peices do not know about each other, so yes, it can.
>
>  As a sidenote, since you sound like you are interested in helping us work on
>  Cobbler Web,
>
>
>  I'd love to, but I'm not familiar with Django (Python) development.
>  Both have steep learning curves - especially since I'm starting from
>  scratch.
>
>
>  I disagree -- The Django app is infinitely easier to work on that the
>  mod_python one
>  and is a lot easier to work on because the templates are simpler, and there
>  are now even less
>  of them.   We are also not even using the persistance layers of Django,
>  since views.py just
>  speaks XMLRPC back to cobblerd.
>
>  It'll be months before I'm even a little bit productive.
>  I love learning new things, so I'll start climbing the Python/Django
>  learning curve now
>  and I'll let you know when I'm skilled enough to contribute.
>
>
>
>  This could be done as a seperate Django app in the cobbler Django project
>  It really warrants a new thread on cobbler-devel list there, would you like
>  to start one?
>
>
>  I would, but not quite yet.
>  We're going to deploy cobbler 1.6.6.
>  Feels like this thread will be good when we decide to go with 2.0.
>  For now I'm going to concentrate on modifying the Systems page for 1.6.6.
>  Any suggestions there?
>
>
>  Once 2.0 releases, there will be no further updates to the 1.6 branch.
>
>  Thankfully, nothing really changes from a user perspective, only new
>  features, and easier development.
>
>  I can't help you working on 1.6.6, because that's an evolutionary dead end
>  -- and subtracts
>  time from working on things other people will be able to get in future
>  releases.
>
>  The authz modules in fact, are still pretty much the same, though I'm due to
>  make some improvements to them
>  in coming week or so -- to make sure they are up-to-date with all of the new
>  method names and so forth.
>
>  It's quite safe to try out now, and there is a very smooth upgrade path for
>  production machines.
>
>  Paul
>
>  On Wed, Aug 12, 2009 at 8:47 AM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>
>
>  On 08/11/2009 09:33 PM, Paul Company wrote:
>
>
>  I'm running cobbler 1.6.6 on RHEL 5.3.
>
>  Three Questions:
>
>  Q1: Is there a way to have the Web UI behavior change according to the
>  person that logs in?
>  For example, I'd like it if user "foo" has full access to everything,
>  but user "bar" to only be able to  create systems.
>  Listing distros, profiles, and repos is ok, but I don't want
>  bar to have the ability to add or delete distros, profiles or repos.
>
>
>
>  There is the "authz_ownership" module which is detailed on the Wiki
>  under the security pages, that can restrict
>  what objects people can edit.
>
>  At a generic level, there's not a concept for a read-only user group,
>  but that's probably something that could be easily
>  added.
>
>  As a sidenote, since you sound like you are interested in helping us
>  work on Cobbler Web, new things need to be done on the "master"
>  branch, which targets 2.0 -- that should be out in a month.
>
>
>  Q2: Has anyone customized the "Add System" web page?
>  I'm not a web programmer but I'd like to simplify/customize
>  the "Add System" page so it's simpler for our end user.
>  I'd to add fields like "Location" and have the values entered
>  show up as --ksmeta values; so if you enter Location: nyc,
>  that would get processed into --ksmeta="loc=nyc"
>  Also, things like, if one chooses a profile that isn't a vm profile,
>  then don't show the VM stuff. Or if power management
>  is disabled, don't show the power management stuff. etc.
>
>
>
>  We've had some ideas on this, about making templates for self-service
>  views in Cobbler.
>
>  This could be done as a seperate Django app in the cobbler Django
>  project, and I would like to see something like
>  this very much.
>
>  It really warrants a new thread on cobbler-devel list there, would you
>  like to start one?
>
>  I have a fair amount of ideas from our own IT guys -- things that we
>  didn't quite implement yet -- but I think that would be exceptionally
>  powerful.  It really warrants a new thread on cobbler-devel list there,
>  would you
>  like to start one?
>
>
>
>  Q3: Should I wait for cobbler 2.0 which uses Django?
>         Or should I plow ahead with the current mod_python stuff?
>
>
>
>  Aha, I got ahead of myself. Glad you're aware of that :)
>
>  Yes, we need to do things on 2.0, since it will be out soon, and porting
>  anything done to the old codebase will be a lot of extra effort.
>
>
>
>  Any tips/information/examples on developing mod_python or Django web
>  pages would be a big help.
>
>
>
>  Do a checkout of git's master branch and do a "make webtest" to get
> started.
>
>  Code lives in the "web" directory and should be fairly self explanatory,
>  but I'd be more than happy to answer any specific questions.
>
>  Hoping on #cobbler and #cobbler-devel on irc.freenode.net is also a
>  great idea.
>
>
>
>  Thanks,
>
>  Paul
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>

[Michael DeHaan]

On 08/12/2009 03:55 PM, Paul Company wrote:
> >> Can it be used with Kerberos?
> >>        
> > The AuthN and Z peices do not know about each other, so yes, it can.
> >      
>
>  Doesn't seem to work for me.
>
>  The following configuration allows me to login with my Kerberos creds
>  (pcompany or user2),
>  but I seem to only have "list" permissions on all the objects.
>  The documentation says:
>        Users that authenticate against the chosen cobbler authentication module
>        but who are not mentioned in users.conf will still be given read
>  access to view
>        things in the Cobbler web interface, but will not be able to
>  perform any actions,
>        such as sync, deletion, and edits.
>
>  Well, pcompany&  user2 *are* "listed in users.conf" in the [admins]
>  and [jradmin] sections.
>  The way I understand it, pcompany should have full access under this
>  configuration;
>  and user2 should fall thru to the acl.conf jradmin permissions and
>  only have those permissions.
>  Why does the below configuration not work?
>  What am I missing?
>
>  Here is what I have configured:
>
>  # vi /etc/cobbler/modules.conf
>  [authentication]
>  module = authn_passthru
>
>  [authorization]
>  module = authz_ownership
>  :wq!
>
>  # vi /etc/cobbler/users.conf
>  [admins]
>  admin = ""
>  cobbler = ""
>  pcompany = ""
>
>  [jradmin]
>  user2 = ""
>
>      
With authz_ownership you control access to certain objects.   For 
instance if you set the owners field on system X to "pcompany", then 
user2 won't be able to edit it.
However everyone in admin will be able to edit something marked as user2.


>  # vi /etc/cobbler/acls.conf
>      
(note:   acls.conf is actually an unsupported/unfinished feature that 
runs after authz, you should be running with the default acls.conf and 
this won't be supported in 2.0)

Apologies on that not being clear.

I will probably make the 2.0 ownership module require admin group 
membership to run various commands.   Right now that is /not/ filtered 
very well.

We should start a discussion on cobbler-devel list about what we want 
this to be for future releases to make sure everyone's wants are planned 
for.  Self service views into Cobbler for less-trusted users (and also 
via web services) is of growing interest by numerous folks.

--Michael

[Paul Company]

So how do I do the following:

Allow users (i.e., pcompany)  listed in [admins] to do everything,
but for everyone else (i.e., user2)
allow
   list on distros, profiles, repos, kickstarts
deny
   everything else (copy/modify/new/remove/save) on distros, profiles,
repos, kickstarts
allow
   everything (list/copy/modify/new/remove/save) on systems

I'm a bit confused.

Seems like I shouldn't use acl.conf for many reasons (unsupported,
will not be in 2.0, etc.).
How do you disable using acl.conf?

Paul


On Wed, Aug 12, 2009 at 1:29 PM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>  On 08/12/2009 03:55 PM, Paul Company wrote:
>
>  Can it be used with Kerberos?
>
>
>  The AuthN and Z peices do not know about each other, so yes, it can.
>
>
>  Doesn't seem to work for me.
>
>  The following configuration allows me to login with my Kerberos creds
>  (pcompany or user2),
>  but I seem to only have "list" permissions on all the objects.
>  The documentation says:
>       Users that authenticate against the chosen cobbler authentication
>  module
>       but who are not mentioned in users.conf will still be given read
>  access to view
>       things in the Cobbler web interface, but will not be able to
>  perform any actions,
>       such as sync, deletion, and edits.
>
>  Well, pcompany & user2 *are* "listed in users.conf" in the [admins]
>  and [jradmin] sections.
>  The way I understand it, pcompany should have full access under this
>  configuration;
>  and user2 should fall thru to the acl.conf jradmin permissions and
>  only have those permissions.
>  Why does the below configuration not work?
>  What am I missing?
>
>  Here is what I have configured:
>
>  # vi /etc/cobbler/modules.conf
>  [authentication]
>  module = authn_passthru
>
>  [authorization]
>  module = authz_ownership
>  :wq!
>
>  # vi /etc/cobbler/users.conf
>  [admins]
>  admin = ""
>  cobbler = ""
>  pcompany = ""
>
>  [jradmin]
>  user2 = ""
>
>
>
>  With authz_ownership you control access to certain objects.   For instance
>  if you set the owners field on system X to "pcompany", then user2 won't be
>  able to edit it.
>  However everyone in admin will be able to edit something marked as user2.
>
>
>  # vi /etc/cobbler/acls.conf
>
>
>  (note:   acls.conf is actually an unsupported/unfinished feature that runs
>  after authz, you should be running with the default acls.conf and this won't
>  be supported in 2.0)
>
>  Apologies on that not being clear.
>
>  I will probably make the 2.0 ownership module require admin group membership
>  to run various commands.   Right now that is /not/ filtered very well.
>
>  We should start a discussion on cobbler-devel list about what we want this
>  to be for future releases to make sure everyone's wants are planned for.
>  Self service views into Cobbler for less-trusted users (and also via web
>  services) is of growing interest by numerous folks.
>
>  --Michael
>
>
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>

[Michael DeHaan]

On 08/12/2009 05:07 PM, Paul Company wrote:
>  So how do I do the following:
>
>  Allow users (i.e., pcompany)  listed in [admins] to do everything,
>  but for everyone else (i.e., user2)
>  allow
>      list on distros, profiles, repos, kickstarts
>  deny
>      everything else (copy/modify/new/remove/save) on distros, profiles,
>  repos, kickstarts
>  allow
>      everything (list/copy/modify/new/remove/save) on systems
>      
For example, the following prevents edit/save operations on all objects 
from users outside admin.

# cobbler distro list | xargs -n1 --replace cobbler object edit 
--name={} --owners="admin"
# cobbler profile list | xargs -n1 --replace cobbler object edit 
--name={} --owners="admin"
# cobbler repo list | xargs -n1 --replace cobbler object edit --name={} 
--owners="admin"

Kickstarts aren't objects right now, so they don't have ownership, but 
there is logic to say that to edit a kickstart you must
have permissions to edit all profiles and systems that use it -- this is 
a bit goofy, IMHO, but we don't have pseudo objects
wrapping kickstarts and snippets, and I'm not sure we want them.

It doesn't control who can reposync/sync/etc... which is I think what we 
want to work out, how we want that to work.
acls.conf is a little rough....

We might make it so only that admin group users can edit 
kickstarts/snippets as well.    We really do have the opportunity to figure
out exactly what we want to do here, beyond what we have, in trying to 
make this more self service.

The idea behind acls was eventually to have it fine grained enough to 
say what /fields/ someone could access -- if you can edit a MAC, you can 
effectively
make a system represent another physical system, which is crazy bad, 
because if there isn't already a system with that record there, you can 
reinstall
that system.

Thus the permissions system in Cobbler is very much "shoot foot" 
protection versus a really hardcore security system, and various folks 
who are using
it more of a self-service apporach have written their own systems/views 
on top of it.

I think, moving forward, I would like to see those self-service views 
implemented in Cobbler proper.    Doing so on top of the acls.conf 
system would
hamstring our ability to do what we /really/ need to do (whatever that 
is), which is why I think we need to break from it.

However the idea of ownership is still important, and will stay.  We 
just have to figure out that, without the ACLs system, exactly what we 
want to do
with the non-edit actions, as there are now a lot more of them.

FWIW, all of cobbler is public in terms of read access, and this /can't/ 
be locked down (because by the very nature of installation, this data is 
eventually
public, and we don't attempt to obfuscate that).

>  I'm a bit confused.
>
>  Seems like I shouldn't use acl.conf for many reasons (unsupported,
>  will not be in 2.0, etc.).
>  How do you disable using acl.conf?
>      
acl.conf in stock configuration really doesn't do anything, so you can 
just leave it as is.

>  Paul
>
>

[Paul Company]

Sorry, but I'm completely confused now.

First, it looks like admin is a member of every object's "owners" list
by default,
so the commands you gave don't do anything.

Second, I can't figure out whether you answered my question.
I think the short answer is "no", cobbler can't do what I asked?

You said,
> the following prevents edit/save operations on all objects from users
> outside admin. 
Well I don't want that.
I want to prevent edit/save operations on everything but Systems from
users outside admin.

Third, even with the simplest configuration, where I'm a member of admins,
I can't seem to edit anything.
As soon as I set module = authz_ownership
I can login with my Kerberos creds, but I can't edit/save anything.

# vi /etc/cobbler/modules.conf
[authentication]
module = authn_passthru

[authorization]
module = authz_ownership
:wq!

# vi /etc/cobbler/users.conf
[admins]
admin = ""
cobbler = ""
pcompany = ""
:wq!

With this configuration, shouldn't I be able to login with my Kerberos
credentials
and edit/save everything? It's almost as if cobbler thinks I'm not in
the user.conf file.

Here's my configuration for Kerberos (which works).

# vi /etc/httpd/conf.d/cobbler.conf <-- enable Kerberos login to the
Web Interface
<Directory "/var/www/cobbler/web/">
  AllowOverride AuthConfig
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbServiceName HTTP
  Krb5Keytab /etc/httpd/conf.d/HTTP.keytab)
  Require valid-user
  SetHandler mod_python
  PythonAuthenHandler index
  PythonHandler index
  PythonPath "sys.path + ['/var/www/cobbler/web/']"
  PythonDebug on
</Directory>
:wq!


Paul






On Wed, Aug 12, 2009 at 2:21 PM, Michael DeHaan&lt;mdehaan(a)redhat.com&gt; wrote:
>  On 08/12/2009 05:07 PM, Paul Company wrote:
> > So how do I do the following:
> >
> > Allow users (i.e., pcompany)  listed in [admins] to do everything,
> > but for everyone else (i.e., user2)
> > allow
> >     list on distros, profiles, repos, kickstarts
> > deny
> >     everything else (copy/modify/new/remove/save) on distros, profiles,
> > repos, kickstarts
> > allow
> >     everything (list/copy/modify/new/remove/save) on systems
> >
>
>  For example, the following prevents edit/save operations on all objects
>  from users outside admin.
>
>  # cobbler distro list | xargs -n1 --replace cobbler object edit
>  --name={} --owners="admin"
>  # cobbler profile list | xargs -n1 --replace cobbler object edit
>  --name={} --owners="admin"
>  # cobbler repo list | xargs -n1 --replace cobbler object edit --name={}
>  --owners="admin"
>
>  Kickstarts aren't objects right now, so they don't have ownership, but
>  there is logic to say that to edit a kickstart you must
>  have permissions to edit all profiles and systems that use it -- this is
>  a bit goofy, IMHO, but we don't have pseudo objects
>  wrapping kickstarts and snippets, and I'm not sure we want them.
>
>  It doesn't control who can reposync/sync/etc... which is I think what we
>  want to work out, how we want that to work.
>  acls.conf is a little rough....
>
>  We might make it so only that admin group users can edit
>  kickstarts/snippets as well.    We really do have the opportunity to figure
>  out exactly what we want to do here, beyond what we have, in trying to
>  make this more self service.
>
>  The idea behind acls was eventually to have it fine grained enough to
>  say what /fields/ someone could access -- if you can edit a MAC, you can
>  effectively
>  make a system represent another physical system, which is crazy bad,
>  because if there isn't already a system with that record there, you can
>  reinstall
>  that system.
>
>  Thus the permissions system in Cobbler is very much "shoot foot"
>  protection versus a really hardcore security system, and various folks
>  who are using
>  it more of a self-service apporach have written their own systems/views
>  on top of it.
>
>  I think, moving forward, I would like to see those self-service views
>  implemented in Cobbler proper.    Doing so on top of the acls.conf
>  system would
>  hamstring our ability to do what we /really/ need to do (whatever that
>  is), which is why I think we need to break from it.
>
>  However the idea of ownership is still important, and will stay.  We
>  just have to figure out that, without the ACLs system, exactly what we
>  want to do
>  with the non-edit actions, as there are now a lot more of them.
>
>  FWIW, all of cobbler is public in terms of read access, and this /can't/
>  be locked down (because by the very nature of installation, this data is
>  eventually
>  public, and we don't attempt to obfuscate that).
>
> > I'm a bit confused.
> >
> > Seems like I shouldn't use acl.conf for many reasons (unsupported,
> > will not be in 2.0, etc.).
> > How do you disable using acl.conf?
> >
>
>  acl.conf in stock configuration really doesn't do anything, so you can
>  just leave it as is.
>
> > Paul
> >
> >
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Michael DeHaan]

>  Well I don't want that.
>  I want to prevent edit/save operations on everything but Systems from
>  users outside admin.
>      
You can't prevent new systems, but you can lock down the ownership of 
existing systems to certain
users/groups.


>  Third, even with the simplest configuration, where I'm a member
> of admins,
>  I can't seem to edit anything.
>      
See previous email on what I think happened there.

[Paul Company]

>  You can't prevent new systems, but ... 
I don't understand this statement.
I want everyone who passes the authentication phase to edit systems.
I just want to lock everyone, but admins, out of distros, profiles, and repos.
I still don't know if that's possible.
I feel like I'm communicating clearly what I want to do.
Here is what I want to do:

Allow users listed in user.conf [admins] section to do everything, but
for everyone else:
    allow
      list on distros, profiles, repos, kickstarts
      list/copy/modify/new/remove/save) on systems
    deny
      everything else (copy/modify/new/remove/save) on distros,
profiles, repos, kickstarts

Can this be done?
Yes or No
If yes, how do you do it?




On Thu, Aug 13, 2009 at 6:13 AM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
> > Well I don't want that.
> > I want to prevent edit/save operations on everything but Systems from
> > users outside admin.
> >
>
>  You can't prevent new systems, but you can lock down the ownership of
>  existing systems to certain
>  users/groups.
>
>
> > Third, even with the simplest configuration, where I'm a member of admins,
> > I can't seem to edit anything.
> >
>
>  See previous email on what I think happened there.
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Michael DeHaan]

On 08/13/2009 12:33 PM, Paul Company wrote:
> > You can't prevent new systems, but ...
> >      
>
>  I don't understand this statement.
>      
You cannot currently prevent authenticated users from creating new 
system records.

>  I want everyone who passes the authentication phase to edit systems.
>      
This is the way it presently works.
>  I just want to lock everyone, but admins, out of distros, profiles,
> and repos.
>      
Yes, this is easy, just assign admin ownership to them and do not list 
other users in the ownership fields
for those things.
>  I still don't know if that's possible.
>      
It is.
>  I feel like I'm communicating clearly what I want to do.
>  Here is what I want to do:
>
>  Allow users listed in user.conf [admins] section to do everything, but
>  for everyone else:
>       allow
>         list on distros, profiles, repos, kickstarts
>         list/copy/modify/new/remove/save) on systems
>       deny
>         everything else (copy/modify/new/remove/save) on distros,
>  profiles, repos, kickstarts
>
>  Can this be done?
>  Yes or No
>      
Yes.


>  If yes, how do you do it?
>      
Assign ownership of the distro/profile/repo objects to your admin group 
only.
Let other people create systems and the ownership of those system 
records will go to them.

[Paul Company]

>  Assign ownership of the distro/profile/repo objects to your admin
> group only. 
Isn't that the default behaviour?

Here's my current config, which I've done nothing to, the owners are
set to admin automatically.
What am I  missing?

# cobbler distro dumpvars --name=5Server-x86_64 | grep owners
 'default_ownership': ['admin'],
 'owners': ['admin'],

# cobbler profile dumpvars --name=5Server-x86_64-profile | grep owners
 'default_ownership': ['admin'],
 'owners': ['admin'],

# cobbler system dumpvars --name=5Server-x86_64-system | grep owners
 'default_ownership': ['admin'],
 'owners': ['admin'],

>  Let other people create systems and the ownership of those system
> records will go to them. 
This is where I'm getting confused.

Can you show me what my modules.conf, users.conf and cobbler.conf
files should look like to implement the following. I'm totally
misunderstanding what you're trying to get me to do.

Allow users listed in user.conf [admins] section to do everything, but
for everyone else:
    allow
      list on distros, profiles, repos, kickstarts
      list/copy/modify/new/remove/save on systems
    deny
      everything else (copy/modify/new/remove/save) on distros,
profiles, repos, kickstarts






On Thu, Aug 13, 2009 at 9:36 AM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>  On 08/13/2009 12:33 PM, Paul Company wrote:
>
>  You can't prevent new systems, but ...
>
>
>  I don't understand this statement.
>
>
>  You cannot currently prevent authenticated users from creating new system
>  records.
>
>  I want everyone who passes the authentication phase to edit systems.
>
>
>  This is the way it presently works.
>
>  I just want to lock everyone, but admins, out of distros, profiles, and
>  repos.
>
>
>  Yes, this is easy, just assign admin ownership to them and do not list other
>  users in the ownership fields
>  for those things.
>
>  I still don't know if that's possible.
>
>
>  It is.
>
>  I feel like I'm communicating clearly what I want to do.
>  Here is what I want to do:
>
>  Allow users listed in user.conf [admins] section to do everything, but
>  for everyone else:
>      allow
>        list on distros, profiles, repos, kickstarts
>        list/copy/modify/new/remove/save) on systems
>      deny
>        everything else (copy/modify/new/remove/save) on distros,
>  profiles, repos, kickstarts
>
>  Can this be done?
>  Yes or No
>
>
>  Yes.
>
>
>  If yes, how do you do it?
>
>
>  Assign ownership of the distro/profile/repo objects to your admin group
>  only.
>  Let other people create systems and the ownership of those system records
>  will go to them.
>
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>

[Michael DeHaan]

On 08/13/2009 01:10 PM, Paul Company wrote:
> > Assign ownership of the distro/profile/repo objects to your admin
> group only.
> >      
>
>  Isn't that the default behaviour?
>
>  Here's my current config, which I've done nothing to, the owners are
>  set to admin automatically.
>  What am I  missing?
>
>  # cobbler distro dumpvars --name=5Server-x86_64 | grep owners
>    'default_ownership': ['admin'],
>    'owners': ['admin'],
>
>  # cobbler profile dumpvars --name=5Server-x86_64-profile | grep owners
>    'default_ownership': ['admin'],
>    'owners': ['admin'],
>
>  # cobbler system dumpvars --name=5Server-x86_64-system | grep owners
>    'default_ownership': ['admin'],
>    'owners': ['admin'],
>
>      
I don't see anything wrong with that. Good.



> > Let other people create systems and the ownership of those system
> records will go to them.
> >      
>
>  This is where I'm getting confused.
>
>  Can you show me what my modules.conf, users.conf and cobbler.conf
>  files should look like to implement the following. I'm totally
>  misunderstanding what you're trying to get me to do.
>      
Let's reset... you keep pasting what you are trying to do. I've read 
that. Let's instead discuss exactly what behavior are you seeing and 
full contents of your /current/ config files for users.conf, 
modules.conf and the Apache config. We can go from there.

Also, if you can, trry to explain without using the phrase "it doesn't 
work", but instead saying exactly what you are seeing and what you 
expect to see in what case...


>  Allow users listed in user.conf [admins] section to do everything,
> but
>  for everyone else:
>       allow
>         list on distros, profiles, repos, kickstarts
>         list/copy/modify/new/remove/save on systems
>       deny
>         everything else (copy/modify/new/remove/save) on distros,
>  profiles, repos, kickstarts
>
>
>
>
>
>
>  On Thu, Aug 13, 2009 at 9:36 AM, Michael DeHaan<mdehaan(a)redhat.com>  wrote:
>     
> > On 08/13/2009 12:33 PM, Paul Company wrote:
> >
> > You can't prevent new systems, but ...
> >
> >
> > I don't understand this statement.
> >
> >
> > You cannot currently prevent authenticated users from creating new system
> > records.
> >
> > I want everyone who passes the authentication phase to edit systems.
> >
> >
> > This is the way it presently works.
> >
> > I just want to lock everyone, but admins, out of distros, profiles, and
> > repos.
> >
> >
> > Yes, this is easy, just assign admin ownership to them and do not list other
> > users in the ownership fields
> > for those things.
> >
> > I still don't know if that's possible.
> >
> >
> > It is.
> >
> > I feel like I'm communicating clearly what I want to do.
> > Here is what I want to do:
> >
> > Allow users listed in user.conf [admins] section to do everything, but
> > for everyone else:
> >      allow
> >        list on distros, profiles, repos, kickstarts
> >        list/copy/modify/new/remove/save) on systems
> >      deny
> >        everything else (copy/modify/new/remove/save) on distros,
> > profiles, repos, kickstarts
> >
> > Can this be done?
> > Yes or No
> >
> >
> > Yes.
> >
> >
> > If yes, how do you do it?
> >
> >
> > Assign ownership of the distro/profile/repo objects to your admin group
> > only.
> > Let other people create systems and the ownership of those system records
> > will go to them.
> >
> >
> >
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
> >
> >      
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>

[Paul Company]

> Let's reset... 
Sounds good. (and thank you for your
patience).

> Let's instead discuss exactly what behavior are you seeing and
> full contents of your /current/
> config files for users.conf, modules.conf and the Apache config.  We can go from there.
I think my other post titled "authz_ownership not working with
authn_passthru + Kerberos"

Probably summarizes what  I want to do.
It also contains teh users.conf, modules.conf and Apache config you're
requesting.




On Thu, Aug 13, 2009 at 10:24 AM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>  On 08/13/2009 01:10 PM, Paul Company wrote:
>
>  Assign ownership of the distro/profile/repo objects to your admin group
>  only.
>
>
>  Isn't that the default behaviour?
>
>  Here's my current config, which I've done nothing to, the owners are
>  set to admin automatically.
>  What am I  missing?
>
>  # cobbler distro dumpvars --name=5Server-x86_64 | grep owners
>   'default_ownership': ['admin'],
>   'owners': ['admin'],
>
>  # cobbler profile dumpvars --name=5Server-x86_64-profile | grep owners
>   'default_ownership': ['admin'],
>   'owners': ['admin'],
>
>  # cobbler system dumpvars --name=5Server-x86_64-system | grep owners
>   'default_ownership': ['admin'],
>   'owners': ['admin'],
>
>
>
>  I don't see anything wrong with that.   Good.
>
>
>
>  Let other people create systems and the ownership of those system records
>  will go to them.
>
>
>  This is where I'm getting confused.
>
>  Can you show me what my modules.conf, users.conf and cobbler.conf
>  files should look like to implement the following. I'm totally
>  misunderstanding what you're trying to get me to do.
>
>
>  Let's reset... you keep pasting what you are trying to do.    I've read
>  that.  Let's instead discuss exactly what behavior are you seeing and full
>  contents of your /current/ config files for users.conf, modules.conf and the
>  Apache config.  We can go from there.
>
>  Also, if you can, trry to explain without using the phrase "it doesn't
>  work", but instead saying exactly what you are seeing and what you expect to
>  see in what case...
>
>
>  Allow users listed in user.conf [admins] section to do everything, but
>  for everyone else:
>      allow
>        list on distros, profiles, repos, kickstarts
>        list/copy/modify/new/remove/save on systems
>      deny
>        everything else (copy/modify/new/remove/save) on distros,
>  profiles, repos, kickstarts
>
>
>
>
>
>
>  On Thu, Aug 13, 2009 at 9:36 AM, Michael DeHaan<mdehaan(a)redhat.com> wrote:
>
>
>  On 08/13/2009 12:33 PM, Paul Company wrote:
>
>  You can't prevent new systems, but ...
>
>
>  I don't understand this statement.
>
>
>  You cannot currently prevent authenticated users from creating new system
>  records.
>
>  I want everyone who passes the authentication phase to edit systems.
>
>
>  This is the way it presently works.
>
>  I just want to lock everyone, but admins, out of distros, profiles, and
>  repos.
>
>
>  Yes, this is easy, just assign admin ownership to them and do not list other
>  users in the ownership fields
>  for those things.
>
>  I still don't know if that's possible.
>
>
>  It is.
>
>  I feel like I'm communicating clearly what I want to do.
>  Here is what I want to do:
>
>  Allow users listed in user.conf [admins] section to do everything, but
>  for everyone else:
>      allow
>        list on distros, profiles, repos, kickstarts
>        list/copy/modify/new/remove/save) on systems
>      deny
>        everything else (copy/modify/new/remove/save) on distros,
>  profiles, repos, kickstarts
>
>  Can this be done?
>  Yes or No
>
>
>  Yes.
>
>
>  If yes, how do you do it?
>
>
>  Assign ownership of the distro/profile/repo objects to your admin group
>  only.
>  Let other people create systems and the ownership of those system records
>  will go to them.
>
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>
>  _______________________________________________
>  cobbler mailing list
>  cobbler(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/cobbler
>
>

[Paul Company]

> Let's instead discuss exactly what behavior are you seeing and
> full contents of your /current/
> config files for users.conf, modules.conf and the Apache config.  We can go from there.
Here's the example with users.conf, modules.conf and Apache config
with described behavior.
(this was not answered in my other post).

The following does NOT work: why?

# vi /etc/cobbler/modules.conf
[authentication]
module = authn_passthru

[authorization]
module = authz_ownership
:wq!

# vi /etc/cobbler/users.conf
[admins]
admin = ""
cobbler = ""
pcompany(a)EXAMPLE.COM = ""
:wq!

# vi /etc/httpd/conf.d/cobbler.conf
<Directory "/var/www/cobbler/web/">
  AllowOverride AuthConfig
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbServiceName HTTP
  Krb5Keytab /etc/httpd/conf.d/HTTP.keytab
  KrbAuthRealms EXAMPLE.COM
  Require valid-user
  SetHandler mod_python
  PythonAuthenHandler index
  PythonHandler index
  PythonPath "sys.path + ['/var/www/cobbler/web/']"
  PythonDebug on
</Directory>
:wq!

# /etc/init.d/cobblerd restart
# /etc/init.d/httpd restart

Browse to the Web UI and login as pcompany(a)EXAMPLE.COM:
(1) Logging in as pcompany(a)EXAMPLE.COM works fine.
BUT
(2) pcompany(a)EXAMPLE.COM can only list things; pcompany(a)EXAMPLE.COM
can't add anything!
    It's almost as if cobbler doesn't see pcompany(a)EXAMPLE.COM in user.conf.

How do I debug this?



On Thu, Aug 13, 2009 at 1:00 PM, Paul Company&lt;pjcster(a)gmail.com&gt; wrote:
> >Let's reset...
>  Sounds good. (and thank you for your patience).
>
> >Let's instead discuss exactly what behavior are you seeing and full contents of
> your /current/
> >config files for users.conf, modules.conf and the Apache config.  We can go from
> there.
>
>  I think my other post titled "authz_ownership not working with
>  authn_passthru + Kerberos"
>
>  Probably summarizes what  I want to do.
>  It also contains teh users.conf, modules.conf and Apache config you're
>  requesting.
>
>
>
>
>  On Thu, Aug 13, 2009 at 10:24 AM, Michael DeHaan&lt;mdehaan(a)redhat.com&gt; wrote:
> > On 08/13/2009 01:10 PM, Paul Company wrote:
> >
> > Assign ownership of the distro/profile/repo objects to your admin group
> > only.
> >
> >
> > Isn't that the default behaviour?
> >
> > Here's my current config, which I've done nothing to, the owners are
> > set to admin automatically.
> > What am I  missing?
> >
> > # cobbler distro dumpvars --name=5Server-x86_64 | grep owners
> >  'default_ownership': ['admin'],
> >  'owners': ['admin'],
> >
> > # cobbler profile dumpvars --name=5Server-x86_64-profile | grep owners
> >  'default_ownership': ['admin'],
> >  'owners': ['admin'],
> >
> > # cobbler system dumpvars --name=5Server-x86_64-system | grep owners
> >  'default_ownership': ['admin'],
> >  'owners': ['admin'],
> >
> >
> >
> > I don't see anything wrong with that.   Good.
> >
> >
> >
> > Let other people create systems and the ownership of those system records
> > will go to them.
> >
> >
> > This is where I'm getting confused.
> >
> > Can you show me what my modules.conf, users.conf and cobbler.conf
> > files should look like to implement the following. I'm totally
> > misunderstanding what you're trying to get me to do.
> >
> >
> > Let's reset... you keep pasting what you are trying to do.    I've read
> > that.  Let's instead discuss exactly what behavior are you seeing and full
> > contents of your /current/ config files for users.conf, modules.conf and the
> > Apache config.  We can go from there.
> >
> > Also, if you can, trry to explain without using the phrase "it doesn't
> > work", but instead saying exactly what you are seeing and what you expect to
> > see in what case...
> >
> >
> > Allow users listed in user.conf [admins] section to do everything, but
> > for everyone else:
> >     allow
> >       list on distros, profiles, repos, kickstarts
> >       list/copy/modify/new/remove/save on systems
> >     deny
> >       everything else (copy/modify/new/remove/save) on distros,
> > profiles, repos, kickstarts
> >
> >
> >
> >
> >
> >
> > On Thu, Aug 13, 2009 at 9:36 AM, Michael DeHaan&lt;mdehaan(a)redhat.com&gt; wrote:
> >
> >
> > On 08/13/2009 12:33 PM, Paul Company wrote:
> >
> > You can't prevent new systems, but ...
> >
> >
> > I don't understand this statement.
> >
> >
> > You cannot currently prevent authenticated users from creating new system
> > records.
> >
> > I want everyone who passes the authentication phase to edit systems.
> >
> >
> > This is the way it presently works.
> >
> > I just want to lock everyone, but admins, out of distros, profiles, and
> > repos.
> >
> >
> > Yes, this is easy, just assign admin ownership to them and do not list other
> > users in the ownership fields
> > for those things.
> >
> > I still don't know if that's possible.
> >
> >
> > It is.
> >
> > I feel like I'm communicating clearly what I want to do.
> > Here is what I want to do:
> >
> > Allow users listed in user.conf [admins] section to do everything, but
> > for everyone else:
> >     allow
> >       list on distros, profiles, repos, kickstarts
> >       list/copy/modify/new/remove/save) on systems
> >     deny
> >       everything else (copy/modify/new/remove/save) on distros,
> > profiles, repos, kickstarts
> >
> > Can this be done?
> > Yes or No
> >
> >
> > Yes.
> >
> >
> > If yes, how do you do it?
> >
> >
> > Assign ownership of the distro/profile/repo objects to your admin group
> > only.
> > Let other people create systems and the ownership of those system records
> > will go to them.
> >
> >
> >
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
> >
> >
> >
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
> >
> > _______________________________________________
> > cobbler mailing list
> > cobbler(a)lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler
> >
> >
>