Hiroyuki Kaguchi | 1 Apr 08:26

[PATCH] remove showing incorrect partition size on guest OS installation

When we install guest OS to a partition by virt-manager,
the "Ready to begin installation" window shows
the size of "Simple File", NOT the size of the partition.

I make a patch that it displays "-" as the size of the storage-partition
for this partition case.

Signed-off-by: Hiroyuki Kaguchi <fj7025cf@...>

---
diff -r 2ea7f77b0339 src/virtManager/create.py
--- a/src/virtManager/create.py Fri Mar 28 13:37:27 2008 -0400
+++ b/src/virtManager/create.py Mon Mar 31 17:51:32 2008 +0900
@@ -392,6 +392,8 @@ class vmmCreate(gobject.GObject):
             return self.window.get_widget("storage-file-address").get_text()

     def get_config_disk_size(self):
+        if not self.window.get_widget("storage-file-backed").get_active():
+            return None
         if not self.window.get_widget("storage-file-size").get_editable():
             return None
         else:
Picon
Gravatar

Re: Cobbler and the ownership module, question about policies?


Michael DeHaan wrote:

| Possible Answer2 -- If you're not in the admin group, you can't edit
| kickstart template files at all.

Would users not in Admin Group require editing rights ? Or, should they
be allowed to edit ?

| Possible Answer3 -- Remove kickstart editing from the WebUI, and
| encourage users to create kickstart templates where they have filesystem
| access (i..e their home directories)

Possibly the best option if the answer is Yes to above.

| Answer?   I think the answer is Subprofile B is promoted to a full
| profile with all of the inherited fields set to the values of Profile A.
| However this is complicated and confusing so "No deletion allowed" may
| be the better route.

No deletion allowed seems saner.

| Any thoughts on the above from those who have a vested interest in
| controlling access to cobbler objects through the WebUI?

i don't have a vested interest yet ;) but would sure be watching the
responses to these interesting questions

--

(Continue reading)

Bryan Kearney | 1 Apr 14:39
Picon
Favicon
Gravatar

Re: Cobbler and the ownership module, question about policies?


Michael DeHaan wrote:
> So,
> 
> Warning -- technical email :)
> 
> I have a pretty good ownership module going for Cobbler now 
> (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), that 
> allows you to say that objects are owned by certain users and/or groups, 
> and prevents users not in those groups (except for an admin group) to be 
> able to edit those objects.   This is designed for very large 
> organizations that may want lab admins to control certain profiles, but 
> not all of them (for instance, a build lab versus a test lab versus a 
> production datacenter, etc).
> In this implementation, users in the admin group have access to all 
> objects always, and by default all objects are created with no editing 
> restrictions unless the creator decides to lock them down.      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.   (It's also coded up so you can't use the WebUI to remove 
> your own access from an object).
> 
> There are a couple of policy questions for this dealing with some of the 
> corner cases.
> 
> (A) What to do about kickstart editing in the WebUI.   This is the "fun" 
> corner case to figure out.
> 
> The WebUI contains a very basic kickstart template editor (it's just a 
> text field for now). 
(Continue reading)

Slinky | 1 Apr 14:53
Picon

Re: Cobbler and the ownership module, question about policies?



On 31/03/2008, Michael DeHaan <mdehaan-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.


(It's also coded up so you can't use the WebUI to remove
your own access from an object).

^ see above




_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Michael DeHaan | 1 Apr 18:05
Picon
Favicon

Re: Cobbler and the ownership module, question about policies?

Sankarshan Mukhopadhyay wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael DeHaan wrote:
>
> | Possible Answer2 -- If you're not in the admin group, you can't edit
> | kickstart template files at all.
>
> Would users not in Admin Group require editing rights ? Or, should they
> be allowed to edit ?
Any user in an admin group would have rights to everything, automatically.

>
> | Possible Answer3 -- Remove kickstart editing from the WebUI, and
> | encourage users to create kickstart templates where they have 
> filesystem
> | access (i..e their home directories)
>
> Possibly the best option if the answer is Yes to above.
>
> | Answer?   I think the answer is Subprofile B is promoted to a full
> | profile with all of the inherited fields set to the values of 
> Profile A.
> | However this is complicated and confusing so "No deletion allowed" may
> | be the better route.
>
> No deletion allowed seems saner.

Probably.

>
>
> | Any thoughts on the above from those who have a vested interest in
> | controlling access to cobbler objects through the WebUI?
>
> i don't have a vested interest yet ;) but would sure be watching the
> responses to these interesting questions
>
Perfectly valid :)

>
>
>
> - --
>
> http://www.gutenberg.net - Fine literature digitally re-published
> http://www.plos.org - Public Library of Science
> http://www.creativecommons.org - Flexible copyright for creative work
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFH8fVdXQZpNTcrCzMRAqJQAKCien3eJsMFO14ZehgmoDj4oJeyjQCeLHn1
> OwUSw1UEw1fPkfA0xJXtI44=
> =oESY
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@...
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Michael DeHaan | 1 Apr 18:08
Picon
Favicon

Re: Cobbler and the ownership module, question about policies?

Bryan Kearney wrote:
>
>
> Michael DeHaan wrote:
>> So,
>>
>> Warning -- technical email :)
>>
>> I have a pretty good ownership module going for Cobbler now 
>> (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), 
>> that allows you to say that objects are owned by certain users and/or 
>> groups, and prevents users not in those groups (except for an admin 
>> group) to be able to edit those objects.   This is designed for very 
>> large organizations that may want lab admins to control certain 
>> profiles, but not all of them (for instance, a build lab versus a 
>> test lab versus a production datacenter, etc).
>> In this implementation, users in the admin group have access to all 
>> objects always, and by default all objects are created with no 
>> editing restrictions unless the creator decides to lock them 
>> down.      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.   (It's also coded up so you can't use 
>> the WebUI to remove your own access from an object).
>>
>> There are a couple of policy questions for this dealing with some of 
>> the corner cases.
>>
>> (A) What to do about kickstart editing in the WebUI.   This is the 
>> "fun" corner case to figure out.
>>
>> The WebUI contains a very basic kickstart template editor (it's just 
>> a text field for now). Possible Answer1? I think the solution is that 
>> a kickstart template file can be edited if the user editing it is 
>> allowed to edit ALL profiles/systems making use of it.  This is a bit 
>> of a catch 22 as it would be possible to create a system using a 
>> template file, just for the purpose of making that user not be able 
>> to edit it.  This shouldn't happen but is technically possible.
>> Possible Answer2 -- If you're not in the admin group, you can't edit 
>> kickstart template files at all.
>>
>> Possible Answer3 -- Remove kickstart editing from the WebUI, and 
>> encourage users to create kickstart templates where they have 
>> filesystem access (i..e their home directories)
>
> For testing, I have liked the ability to edit he ks file and not need 
> to log into the box. If possible, please keep it. It may be heinous, 
> but is there a model where each ks has a security item associated to 
> it (e.g. a role) or ks files can be grouped and a role associated to 
> the group?

The ownership module is off by default, so if we removed it, it might 
only be for that.    I think we can find a workable solution though :)

I'm trying to avoid creating an additional cobbler object wrapping the 
kickstarts -- as that ends up creating too many Cobbler objects and 
makes things less simpler for newer users (who have this feature turned 
off by default, anyway).

>>
>> ----
>>
>> (B) What do to about "orphanage".
>>
>> If UserA owns ProfileA, and UserB owns SystemB, which depends on 
>> ProfileB, what happens if UserA wants to delete ProfileA?
>>
>> Answer?   The profile cannot be deleted.
>>
>> If UserA owns ProfileA, and UserB owns SubprofileB, what happens when 
>> UserA wants to delete ProfileA?
>>
>> Answer?   I think the answer is Subprofile B is promoted to a full 
>> profile with all of the inherited fields set to the values of Profile A.
>> However this is complicated and confusing so "No deletion allowed" 
>> may be the better route.
>
> First cut, no delete. Every time i have used nested profiles it was 
> becuase I had nested logic in the kickstart file. So. promoting a 
> subprofile would cause the subprofile to break.

I agree.   Though it might not cause breakage if we promote the 
attributes that are marked "inherit", it's clearly non-obvious behavior 
to the user.
The admin could always intervene and blow away all objects below it if 
required.

>>
>> ---
>>
>> (C) FYI...
>>
>> Everyone is allowed to run "cobbler sync" if they can authenticate.  
>> I don't think this should be a problem.
>>
>> Also, if you're in, you can read everything, you just might not be 
>> able to /write/ everything.   This also should not be a problem as 
>> provisioning
>> data is basically public if you want to use it in a Fully Automated 
>> Context anyway.
>>
>> Currently settings, modules.conf, and users.conf can't be edited 
>> through the WebUI as that's a really good way to lock yourself out of 
>> the WebUI
>> altogether :)
>>
>> ---
>>
>> Any thoughts on the above from those who have a vested interest in 
>> controlling access to cobbler objects through the WebUI?
>> Remember this is all off by default and is only there if you want it 
>> -- but if you want it, I want to make sure this fits your 
>> organizational needs.
>>
>> --Michael
>>
>> _______________________________________________
>> et-mgmt-tools mailing list
>> et-mgmt-tools@...
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@...
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Michael DeHaan | 1 Apr 18:24
Picon
Favicon

Re: Cobbler and the ownership module, question about policies?

Slinky wrote:
>
>
> On 31/03/2008, *Michael DeHaan* <mdehaan@... 
> <mailto:mdehaan@...>> 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?

>
>
>     (It's also coded up so you can't use the WebUI to remove
>     your own access from an object).
>
>
> ^ see above
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@...
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Michael DeHaan | 1 Apr 18:34
Picon
Favicon

Re: Cobbler and the ownership module, question about policies?

Michael DeHaan wrote:
> Slinky wrote:
>>
>>
>> On 31/03/2008, *Michael DeHaan* <mdehaan@... 
>> <mailto:mdehaan@...>> 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
Bjorn Oglefjorn | 1 Apr 20:46
Picon

[Cobbler] [PATCH] Cleaning up the authn_ldap module

Issues addressed in the attached patch:
  - allow anonymous or bind'ed searches to obtain a user's full DN
  - allow for a configurable user search prefix (eg: 'uid=', 'cn=', etc...)

The following items (and their proposed defaults) are needed in /var/lib/cobbler/settings to accommodate this patch:
ldap_anonymous_bind: 1
ldap_search_bind_dn: ''
ldap_search_passwd: ''
ldap_search_prefix: 'uid='

So if your LDAP server does not allow anonymous binds, you would need to set:
ldap_anonymous_bind: 0
ldap_search_bind_dn: '<full_bind_user_dn_with_full_read_access_to_base_dn>'
ldap_search_passwd: '<passwd>'

Questions?  See me in #cobbler.

--Vito Laurenza

diff --git a/cobbler/modules/authn_ldap.py b/cobbler/modules/authn_ldap.py
index 6d190bd..36d4054 100644
--- a/cobbler/modules/authn_ldap.py
+++ b/cobbler/modules/authn_ldap.py
@@ -1,6 +1,6 @@
 """
 Authentication module that uses ldap
-Settings in /etc/cobbler/authn_ldap.conf
+Settings in /var/lib/cobbler/settings (ldap_*)
 Choice of authentication module is in /etc/cobbler/modules.conf

 This software may be freely redistributed under the terms of the GNU
@@ -12,14 +12,12 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 """

 import distutils.sysconfig
-#import ConfigParser
 import sys
 import os
 from rhpl.translate import _, N_, textdomain, utf8
 import md5
 import traceback
 import ldap
-import traceback

 plib = distutils.sysconfig.get_python_lib()
 mod_path="%s/cobbler" % plib
@@ -29,8 +27,6 @@ import cexceptions
 import utils
 import api as cobbler_api

-#CONFIG_FILE='/etc/cobbler/auth_ldap.conf'
-
 def register():
     """
     The mandatory cobbler module registration hook.
@@ -43,13 +39,12 @@ def authenticate(api_handle,username,password):
     Validate an ldap bind, returning True/False
     """

-    server = api_handle.settings().ldap_server
-    basedn = api_handle.settings().ldap_base_dn
-    port   = api_handle.settings().ldap_port
-    tls    = api_handle.settings().ldap_tls
-
-    # parse CONFIG_FILE
-    # server,basedn,port,tls = __parse_config()
+    server    = api_handle.settings().ldap_server
+    basedn    = api_handle.settings().ldap_base_dn
+    port      = api_handle.settings().ldap_port
+    tls       = api_handle.settings().ldap_tls
+    anon_bind = api_handle.settings().ldap_anonymous_bind
+    prefix    = api_handle.settings().ldap_search_prefix

     # form our ldap uri based on connection port
     if port == '389':
@@ -73,17 +68,32 @@ def authenticate(api_handle,username,password):
                 traceback.print_exc()
                 return False

+    # if we're not allowed to search anonymously,
+    # grok the search bind settings and attempt to bind
+    anon_bind = str(anon_bind).lower()
+    if anon_bind not in [ "on", "true", "yes", "1" ]:
+        searchdn = api_handle.settings().ldap_search_bind_dn
+        searchpw = api_handle.settings().ldap_search_passwd
+
+        if searchdn == '' or searchpw == '':
+            raise "Missing search bind settings"
+
+        try:
+            dir.simple_bind_s(searchdn, searchpw)
+        except:
+            traceback.print_exc()
+            return False
+
     # perform a subtree search in basedn to find the full dn of the user
     # TODO: what if username is a CN?  maybe it goes into the config file as well?
-    filter = "uid=" + username
+    filter = prefix + username
     result = dir.search_s(basedn, ldap.SCOPE_SUBTREE, filter, [])
     if result:
         for dn,entry in result:
-            # uid should be unique so we should only have one result
+            # username _should_ be unique so we should only have one result
             # ignore entry; we don't need it
             pass
     else:
-        print "FAIL 2"
         return False

     try:
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
Michael DeHaan | 1 Apr 21:26
Picon
Favicon

Re: [Cobbler] [PATCH] Cleaning up the authn_ldap module

Bjorn Oglefjorn wrote:
> Issues addressed in the attached patch:
>   - allow anonymous or bind'ed searches to obtain a user's full DN
>   - allow for a configurable user search prefix (eg: 'uid=', 'cn=', 
> etc...)
>
> The following items (and their proposed defaults) are needed in 
> /var/lib/cobbler/settings to accommodate this patch:
> ldap_anonymous_bind: 1
> ldap_search_bind_dn: ''
> ldap_search_passwd: ''
> ldap_search_prefix: 'uid='
>
> So if your LDAP server does not allow anonymous binds, you would need 
> to set:
> ldap_anonymous_bind: 0
> ldap_search_bind_dn: 
> '<full_bind_user_dn_with_full_read_access_to_base_dn>'
> ldap_search_passwd: '<passwd>'
>
> Questions?  See me in #cobbler.
>
> --Vito Laurenza
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools@...
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Applied with some tweaks -- added the new variables to the settings 
file, etc.

Thanks!

Vito mentioned on IRC the Wiki is going to be updated with details later 
(https://fedorahosted.org/cobbler/wiki/CobblerWithLdap), if anyone with 
an LDAP config would like to test this, please do.

The default values in the config file should be right for most installs 
(other than the basedn and server), if you need the others they will be 
up on the Wiki.

--Michael

Gmane