From rcritten at redhat.com Thu Oct 1 21:40:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Oct 2009 17:40:58 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add HBAC plugin and introduce GeneralizedTime parameter type. In-Reply-To: <4AC36E87.2080804@redhat.com> References: <4AC36E87.2080804@redhat.com> Message-ID: <4AC521EA.90204@redhat.com> Pavel Zuna wrote: > Sumit noticed, that the HBAC plugin didn't make it into the tree and the > patch got lost in the depths of freeipa-devel. > > I reworked the plugin to meet the current standards and changed > GeneraliSedTime to GeneraliZedTime. For now, I put the new parameter > type into a separate file in ipalib/plugins/generalizedtime.py. When > it's tested enough, we're going to move it to ipalib/parameters.py. > > The patch also modifies bootstrap-template.ldif to create a cn=hbac > container after installing IPA. > > Pavel Shouldn't GeneralizedTime be in ipalib? I think GeneralizedTime should have some unit tests, same for hbac. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 2 13:35:08 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 09:35:08 -0400 Subject: [Freeipa-devel] [PATCH] 280 add option to not normalize on adds/updates Message-ID: <4AC6018C.6010603@redhat.com> Add an option to not run the normalizer against the DN on adds/updates. The MIT ldap plugin is extremely picky about the format of DNs it adds and it does not like the way we normalize things so I need to set it up right in the plugin and commit it that way. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-280-normalize.patch Type: application/mbox Size: 1570 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 2 13:35:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 09:35:50 -0400 Subject: [Freeipa-devel] [PATCH] 281 minor fix for updater Message-ID: <4AC601B6.1030803@redhat.com> Robustness fix for ipa-ldap-updater to not blow up if no updates are set yet. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-281-updater.patch Type: application/mbox Size: 874 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 2 13:37:54 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 09:37:54 -0400 Subject: [Freeipa-devel] [PATCH] 282 update the KDC aci Message-ID: <4AC60232.2060901@redhat.com> The API protecting the kerberos master key was a bit broad, also preventing adds and deletes to its subtree. I've relaxed that so I can add password policy entries which must be stored under the realm entry. I also changed the formatting of the code. It was getting written to the DS with leading and trailing \n causing DS to base64-encode the value when displaying it. I'm hoping this wasn't done on purpose :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-282-aci.patch Type: application/mbox Size: 1248 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 2 13:38:53 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 09:38:53 -0400 Subject: [Freeipa-devel] [PATCH] 283 allow no primary key in crud classes Message-ID: <4AC6026D.2090509@redhat.com> The crud classes required a primary key to be set in order to work. I've relaxed that as the pwpolicy plugin has no primary key but I still want to take advantage of other aspects of it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-283-crud.patch Type: application/mbox Size: 1097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 2 13:40:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 09:40:39 -0400 Subject: [Freeipa-devel] [PATCH] 284 per-group password policy Message-ID: <4AC602D7.6010903@redhat.com> Add support for per-group kerberos password policy. This uses a Class of Service to based on group membership to determine which policy should apply. The design doc called for non-overlapping groups but we can support that with cospriority. You can pass a user to the pwpolicy plugin to see what policy applies to them to help debug overlapping issues if they come up. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-284-pwpolicy.patch Type: application/mbox Size: 21184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Fri Oct 2 14:02:22 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 16:02:22 +0200 Subject: [Freeipa-devel] [PATCH] 280 add option to not normalize on adds/updates In-Reply-To: <4AC6018C.6010603@redhat.com> References: <4AC6018C.6010603@redhat.com> Message-ID: <4AC607EE.3080604@redhat.com> Rob Crittenden wrote: > Add an option to not run the normalizer against the DN on adds/updates. > > The MIT ldap plugin is extremely picky about the format of DNs it adds > and it does not like the way we normalize things so I need to set it up > right in the plugin and commit it that way. > > rob ack. Although I would rather have the param called 'normalize_dn' instead of 'normalize', so everyone knows what is being normalized. Pavel From pzuna at redhat.com Fri Oct 2 14:02:39 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 16:02:39 +0200 Subject: [Freeipa-devel] [PATCH] 281 minor fix for updater In-Reply-To: <4AC601B6.1030803@redhat.com> References: <4AC601B6.1030803@redhat.com> Message-ID: <4AC607FF.3040702@redhat.com> Rob Crittenden wrote: > Robustness fix for ipa-ldap-updater to not blow up if no updates are set > yet. > > rob ack. Pavel From pzuna at redhat.com Fri Oct 2 14:04:53 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 16:04:53 +0200 Subject: [Freeipa-devel] [PATCH] 283 allow no primary key in crud classes In-Reply-To: <4AC6026D.2090509@redhat.com> References: <4AC6026D.2090509@redhat.com> Message-ID: <4AC60885.4030805@redhat.com> Rob Crittenden wrote: > The crud classes required a primary key to be set in order to work. I've > relaxed that as the pwpolicy plugin has no primary key but I still want > to take advantage of other aspects of it. > > rob ack. LDAP* base classes already have this, but I guess it can't hurt to also have it on a lower level. Pavel From pzuna at redhat.com Fri Oct 2 14:07:39 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 16:07:39 +0200 Subject: [Freeipa-devel] [PATCH] 284 per-group password policy In-Reply-To: <4AC602D7.6010903@redhat.com> References: <4AC602D7.6010903@redhat.com> Message-ID: <4AC6092B.8060800@redhat.com> Rob Crittenden wrote: > Add support for per-group kerberos password policy. > > This uses a Class of Service to based on group membership to determine > which policy should apply. The design doc called for non-overlapping > groups but we can support that with cospriority. > > You can pass a user to the pwpolicy plugin to see what policy applies to > them to help debug overlapping issues if they come up. > > rob ack. You could have taken my latest pwpolicy plugin as a base for this, but no big deal - I'll merge the changes and post an updated version. :) Pavel From pzuna at redhat.com Fri Oct 2 14:29:06 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 16:29:06 +0200 Subject: [Freeipa-devel] Re: [PATCH] Add HBAC plugin and introduce GeneralizedTime parameter type. In-Reply-To: <4AC521EA.90204@redhat.com> References: <4AC36E87.2080804@redhat.com> <4AC521EA.90204@redhat.com> Message-ID: <4AC60E32.3010302@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Sumit noticed, that the HBAC plugin didn't make it into the tree and >> the patch got lost in the depths of freeipa-devel. >> >> I reworked the plugin to meet the current standards and changed >> GeneraliSedTime to GeneraliZedTime. For now, I put the new parameter >> type into a separate file in ipalib/plugins/generalizedtime.py. When >> it's tested enough, we're going to move it to ipalib/parameters.py. >> >> The patch also modifies bootstrap-template.ldif to create a cn=hbac >> container after installing IPA. >> >> Pavel > > Shouldn't GeneralizedTime be in ipalib? > > I think GeneralizedTime should have some unit tests, same for hbac. > > rob Update: - Now includes extensive unit test for HBAC plugin. - GeneralizedTime was moved to ipalib/parameters. - Minor updated to HBAC plugin, mostly esthetics. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-HBAC-plugin-and-introduce-GeneralizedTime-parame.patch Type: application/mbox Size: 27425 bytes Desc: not available URL: From pzuna at redhat.com Fri Oct 2 14:31:07 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 16:31:07 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC36F19.2040703@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> Message-ID: <4AC60EAB.1080304@redhat.com> Pavel Zuna wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> Rob Crittenden wrote: >>>>>> Pavel Z?na wrote: >>>>>>> This is a series of patches that depends on patches: >>>>>>> - Improve attribute printing in the CLI. >>>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>>> >>>>>>> All plugins are converted to extend baseldap classes. This makes >>>>>>> things more consistent, fixes some general bugs (with return >>>>>>> values for example) and it also makes plugins easier to maintain >>>>>>> (as it removes a lot of duplicate code). >>>>>>> >>>>>>> Because baseldap classes have features that enable us to define >>>>>>> relationships between plugins, I thought it might be best to >>>>>>> submit all of the conversions at once and have all the >>>>>>> relationships fully defined. >>>>>>> >>>>>>> Affected plugins: >>>>>>> config >>>>>>> user >>>>>>> host >>>>>>> service >>>>>>> group >>>>>>> hostgroup >>>>>>> netgroup >>>>>>> rolegroup >>>>>>> taskgroup >>>>>>> pwpolicy >>>>>>> >>>>>>> There's also a patch that fixes all unit tests. >>>>>>> >>>>>>> Jenny, I included you to Cc, because the patch introduces a lot >>>>>>> of changes to the UI (and you're probably not going to like me >>>>>>> for this). >>>>>>> >>>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>>> option. Without it, data from LDAP is formated and translated to >>>>>>> human readable. For example: >>>>>>> >>>>>>> # ipa user-show admin --all >>>>>>> ---------- >>>>>>> user-show: >>>>>>> ---------- >>>>>>> User: admin >>>>>>> user id: admin >>>>>>> full name: Administrator >>>>>>> last name: Administrator >>>>>>> home directory: /home/admin >>>>>>> login shell: /bin/bash >>>>>>> uid number: 999 >>>>>>> gid number: 1001 >>>>>>> gecos: Administrator >>>>>>> kerberos principal: admin at PZUNA >>>>>>> last password change: 20090904122852Z >>>>>>> password expiration: 20091203122852Z >>>>>>> member of groups: admins >>>>>>> >>>>>>> # ipa user-show admin --all --raw >>>>>>> ---------- >>>>>>> user-show: >>>>>>> ---------- >>>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>>> uid: admin >>>>>>> cn: Administrator >>>>>>> sn: Administrator >>>>>>> homedirectory: /home/admin >>>>>>> loginshell: /bin/bash >>>>>>> uidnumber: 999 >>>>>>> gidnumber: 1001 >>>>>>> gecos: Administrator >>>>>>> krbprincipalname: admin at PZUNA >>>>>>> krblastpwdchange: 20090904122852Z >>>>>>> krbpasswordexpiration: 20091203122852Z >>>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>>> objectclass: top >>>>>>> objectclass: person >>>>>>> objectclass: posixaccount >>>>>>> objectclass: krbprincipalaux >>>>>>> objectclass: inetuser >>>>>>> >>>>>>> Advantages: more user friendly, allows for easy localization, >>>>>>> translation of DNs to primary keys (immediately usable as input >>>>>>> to other plugin commands) >>>>>>> >>>>>>> I recommend, that you use the --raw flag for testing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>>> >>>>>>> It should be up-to-date with master and all my patches are >>>>>>> applied there. I hope it makes reviewing them at least a bit easier. >>>>>>> >>>>>>> Pavel >>>>>> >>>>>> Why are you using a pre_callback() to define default values >>>>>> instead of using default_from? It seems clearer to use that. >>>>> You're probably referring to the user plugin, where gecos and >>>>> krbprincipalname defaults are set inside pre_callback. It's a >>>>> residue from some time ago when we didn't use autofill=True with >>>>> default_from and it didn't have any effect on optional parameters. >>>>> It's a small change, but I included an updated version of the patch >>>>> with this email. >>>> >>>> Ok. I gather you've moved a lot of logic into the pre_callback >>>> plugin to avoid overriding execute? One other goal we wanted was to >>>> allow plugins to extend other plugins and this may be good step on >>>> the way there. So for example, a user wants to be able to set some >>>> extra objectclass, they could do it with a similar pre_callback >>>> extension to the user plugin (once we do the plumbing for it, that is). >> Right. The goal is to have a common execute in the baseclass, that >> does most of the dirty work and let the user/plugin author add the >> specifics of his plugin in the pre/post callbacks. All the data >> generated by the base (before calling python-ldap) is available for >> modification in the pre-callbacks and all data coming out of >> python-ldap is made available in the post-callback. >> >> And yes, the plugins could be almost endlessly extended this way. For >> example, someone could do this: >> >> from ipalib.plugins.user import user_add >> >> class user_add_extended(user_add): >> def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): >> # let the original user_add plugin do its job >> super(user_add_extended, self).pre_callback( >> ldap, dn, entry_attrs, *keys, **options) >> # add an extra object class >> entry_attrs['objectclass'].append('new_object_class') >> return dn >> >> api.register(user_add_extended) >> >>>>>> This also duplicates some values in the attribute_names() >>>>>> dictionary. I wonder if this can be either created from the >>>>>> parameters or define a global set somewhere that covers all plugins. >>>>> I know, but I couldn't find a better solution. I thought we could >>>>> add something like a 'real_name' kwarg to params, but this has 2 >>>>> main disadvantages: >>>>> 1) it only makes sense with parameters that refer to an LDAP attribute >>>>> 2) it doesn't work for attributes with no param counterparts >>>>> >>>>> The global set is a good idea as long as we consider only our own >>>>> plugins. 3rd party plugins would have to modify this set to add >>>>> their own attributes. Also, attributes might have a different >>>>> meaning for different objects. They usually don't, but take 'cn' >>>>> for example. We use it as an ID, name, full name (for users), etc. >>>> >>>> Ok, that's a good point. I'm wondering if its overkill to write a >>>> registration system for this, something like: >>>> >>>> def set_label(attr, label, context='') >>>> >>>> def get_label(attr, context='') >>>> >>>> In this we'd store a dict that would be keyed on attr+context. Some >>>> examples might be: >>>> >>>> set_label('uid', 'Login') >>>> set_label('gn', 'First Name') >>>> set_label('cn', 'Full Name', context='user') >>>> set_label('cn', 'Group Name', context='group') >>>> >>>> The lookup would first look for a context-specific entry and fall >>>> back to a non-context specific, something like: >>>> >>>> if attr+context in labeldict: return labeldict[attr+context] >>>> elif attr in labeldict: return labeldict[attr] >>>> else return "woop" >>>> >>>> Like I said, might be overkill ;-) >>>> >>>> But still, the alarms go off when we're putting the same things in >>>> multiple places. >>>> >> Yeah, the registration system sounds like overkill all right. :D >> >> Seriously, I was thinking about several ways on how to resolve this >> issue. Ideally, all information about attributes should be retrieved >> from the schema. Unfortunately, it cannot be done. There's just very >> little information in there. >> >> Another idea was to have an LDAPAttribute base class, that we would >> extend for each attribute. We could then have a ldapattribute.py >> module in ipalib/plugins with all the attributes we use defined there. >> If 3rd parties require a new attribute, they just create their own >> LDAPAttribute subclass in their plugins. I think that this would be >> the best and cleanest approach. LDAPObjects would have a set of >> LDAPAttribute references and do all attribute manipulation using them. >> Also, attribute parameters could be automatically generated, so they >> wouldn't mix with control parameters in takes_params (like --all, >> --raw, --posix for groups, etc.). This is probably the way we'll be >> going in the future, but there's still a few problems I have to >> resolve before implementing it. >> >> By the way, my goal is to move all this LDAP infrastructure from the >> plugin layer into the core library itself once it's mature (and >> documented) enough. Probably not going to happen in v2, but we'll see >> how it goes. >> >>>>>> In the user plugin 'ou' is in the default attributes. We don't use >>>>>> this attribute. >>>>> Since we don't use it, it's not going to get displayed anyway. >>>>> >>>>> All the values in attribute_names, default_attribute and >>>>> attribute_order are subject to change. I set them to initial values >>>>> I thought are acceptable, but I don't think I'm the right person to >>>>> decide what's going to be there. Ideally, someone with more >>>>> UI/text/user friendliness experience should review it (there's not >>>>> programming knowledge required to change the values). >>>> >>>> Ok, this particular attribute brings up DIT issues which is why I >>>> flagged it. >>>> >>>>>> I think that in general baseldap needs to be documented to explain >>>>>> how things work. There is no explanation for object_class_config, >>>>>> for example, that it defines the attribute in cn=ipaConfig that >>>>>> contains the default list of objectclasses for the object. >>>>> Yeah, there's no documentation at this point, but I'm working on it >>>>> as we "speak". >>>>> >>>>>> rob >>>>>> >>>>> >>>>> One more thing, I reviewed your latest patches and they make change >>>>> to host and service plugins. Your patches should be pushed first, >>>>> because they are more complex and also more important, so I posted >>>>> updated versions to the corresponding email threads on freeipa-devel. >>>>> >>>>> Pavel >>>> >>>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>>> >>> >>> I've found another problem with the attribute map. I like your idea >>> of breaking out memberof by different type but as it is now doesn't >>> work, it only prints group membership. You'd have to parse the DN to >>> distinguish between groups, taskgroups, etc. >> >> And that's exactly what I'm doing in >> LDAPObject.convert_attribute_members. I mean the DN parsing. It just >> doesn't work for users at the moment, because I forgot to add the >> other types of groups in users attribute_members['memberof']. >> >> in ipalib/plugins/user.py: >> >> class user(LDAPObject): >> # ... >> attribute_members = { >> # add other groups here >> # example 'memberof': ['group', 'taskgroup'] >> 'memberof': ['group'] >> } >> # ... >> >> try: >> >> ipa user-add test --first=first --last=last >> ipa taskgroup-add tasktest --desc=desc >> ipa taskgroup-add-member tasktest --users=test >> ipa user-show test --all >> >> Should work. >> >> Note: Just noticed it won't work for netgroups, because I forgot to >> override LDAPObject.get_primary_key_from_dn in the netgroup class. >> Normally get_primary_key_from_dn just returns the value of RDN, but >> for netgroups we have to do a search to retrieve the primary key. >> >> class netgroup(LDAPObject): >> # ... >> def get_primary_key_from_dn(self, dn): >> (dn, entry_attrs) = self.backend.get_entry( >> dn, [self.primary_key.name] >> ) >> return entry_attrs.get(self.primary_key.name, '') >> # ... >> >>> I think for the short-term we can make a note to do this and just >>> print all memberships so we can get this committed. I'm still not a >>> fan of the attribute_names within each plugin though, I need more >>> convincing. >>> >>> rob >>> >> >> By the way, I'm going on vacation next week. So, I think we should >> wait anyway before committing this. >> >> Pavel >> > I'm sending an updated version of all the patches. They should apply on > the current master. I think they should now address most of your > concerns and I also fixed some bugs I found on my own. > > Pavel I found a bug in the netgroup plugin, here's an update. Also, the pwpolicy plugin patch needs update to included your latest changes. Should be done by monday. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-netgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 17015 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 2 14:33:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 10:33:50 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC36F19.2040703@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> Message-ID: <4AC60F4E.400@redhat.com> Pavel Zuna wrote: > Pavel Z?na wrote: >> Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> Rob Crittenden wrote: >>>>>> Pavel Z?na wrote: >>>>>>> This is a series of patches that depends on patches: >>>>>>> - Improve attribute printing in the CLI. >>>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>>> >>>>>>> All plugins are converted to extend baseldap classes. This makes >>>>>>> things more consistent, fixes some general bugs (with return >>>>>>> values for example) and it also makes plugins easier to maintain >>>>>>> (as it removes a lot of duplicate code). >>>>>>> >>>>>>> Because baseldap classes have features that enable us to define >>>>>>> relationships between plugins, I thought it might be best to >>>>>>> submit all of the conversions at once and have all the >>>>>>> relationships fully defined. >>>>>>> >>>>>>> Affected plugins: >>>>>>> config >>>>>>> user >>>>>>> host >>>>>>> service >>>>>>> group >>>>>>> hostgroup >>>>>>> netgroup >>>>>>> rolegroup >>>>>>> taskgroup >>>>>>> pwpolicy >>>>>>> >>>>>>> There's also a patch that fixes all unit tests. >>>>>>> >>>>>>> Jenny, I included you to Cc, because the patch introduces a lot >>>>>>> of changes to the UI (and you're probably not going to like me >>>>>>> for this). >>>>>>> >>>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>>> option. Without it, data from LDAP is formated and translated to >>>>>>> human readable. For example: >>>>>>> >>>>>>> # ipa user-show admin --all >>>>>>> ---------- >>>>>>> user-show: >>>>>>> ---------- >>>>>>> User: admin >>>>>>> user id: admin >>>>>>> full name: Administrator >>>>>>> last name: Administrator >>>>>>> home directory: /home/admin >>>>>>> login shell: /bin/bash >>>>>>> uid number: 999 >>>>>>> gid number: 1001 >>>>>>> gecos: Administrator >>>>>>> kerberos principal: admin at PZUNA >>>>>>> last password change: 20090904122852Z >>>>>>> password expiration: 20091203122852Z >>>>>>> member of groups: admins >>>>>>> >>>>>>> # ipa user-show admin --all --raw >>>>>>> ---------- >>>>>>> user-show: >>>>>>> ---------- >>>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>>> uid: admin >>>>>>> cn: Administrator >>>>>>> sn: Administrator >>>>>>> homedirectory: /home/admin >>>>>>> loginshell: /bin/bash >>>>>>> uidnumber: 999 >>>>>>> gidnumber: 1001 >>>>>>> gecos: Administrator >>>>>>> krbprincipalname: admin at PZUNA >>>>>>> krblastpwdchange: 20090904122852Z >>>>>>> krbpasswordexpiration: 20091203122852Z >>>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>>> objectclass: top >>>>>>> objectclass: person >>>>>>> objectclass: posixaccount >>>>>>> objectclass: krbprincipalaux >>>>>>> objectclass: inetuser >>>>>>> >>>>>>> Advantages: more user friendly, allows for easy localization, >>>>>>> translation of DNs to primary keys (immediately usable as input >>>>>>> to other plugin commands) >>>>>>> >>>>>>> I recommend, that you use the --raw flag for testing. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>>> >>>>>>> It should be up-to-date with master and all my patches are >>>>>>> applied there. I hope it makes reviewing them at least a bit easier. >>>>>>> >>>>>>> Pavel >>>>>> >>>>>> Why are you using a pre_callback() to define default values >>>>>> instead of using default_from? It seems clearer to use that. >>>>> You're probably referring to the user plugin, where gecos and >>>>> krbprincipalname defaults are set inside pre_callback. It's a >>>>> residue from some time ago when we didn't use autofill=True with >>>>> default_from and it didn't have any effect on optional parameters. >>>>> It's a small change, but I included an updated version of the patch >>>>> with this email. >>>> >>>> Ok. I gather you've moved a lot of logic into the pre_callback >>>> plugin to avoid overriding execute? One other goal we wanted was to >>>> allow plugins to extend other plugins and this may be good step on >>>> the way there. So for example, a user wants to be able to set some >>>> extra objectclass, they could do it with a similar pre_callback >>>> extension to the user plugin (once we do the plumbing for it, that is). >> Right. The goal is to have a common execute in the baseclass, that >> does most of the dirty work and let the user/plugin author add the >> specifics of his plugin in the pre/post callbacks. All the data >> generated by the base (before calling python-ldap) is available for >> modification in the pre-callbacks and all data coming out of >> python-ldap is made available in the post-callback. >> >> And yes, the plugins could be almost endlessly extended this way. For >> example, someone could do this: >> >> from ipalib.plugins.user import user_add >> >> class user_add_extended(user_add): >> def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): >> # let the original user_add plugin do its job >> super(user_add_extended, self).pre_callback( >> ldap, dn, entry_attrs, *keys, **options) >> # add an extra object class >> entry_attrs['objectclass'].append('new_object_class') >> return dn >> >> api.register(user_add_extended) >> >>>>>> This also duplicates some values in the attribute_names() >>>>>> dictionary. I wonder if this can be either created from the >>>>>> parameters or define a global set somewhere that covers all plugins. >>>>> I know, but I couldn't find a better solution. I thought we could >>>>> add something like a 'real_name' kwarg to params, but this has 2 >>>>> main disadvantages: >>>>> 1) it only makes sense with parameters that refer to an LDAP attribute >>>>> 2) it doesn't work for attributes with no param counterparts >>>>> >>>>> The global set is a good idea as long as we consider only our own >>>>> plugins. 3rd party plugins would have to modify this set to add >>>>> their own attributes. Also, attributes might have a different >>>>> meaning for different objects. They usually don't, but take 'cn' >>>>> for example. We use it as an ID, name, full name (for users), etc. >>>> >>>> Ok, that's a good point. I'm wondering if its overkill to write a >>>> registration system for this, something like: >>>> >>>> def set_label(attr, label, context='') >>>> >>>> def get_label(attr, context='') >>>> >>>> In this we'd store a dict that would be keyed on attr+context. Some >>>> examples might be: >>>> >>>> set_label('uid', 'Login') >>>> set_label('gn', 'First Name') >>>> set_label('cn', 'Full Name', context='user') >>>> set_label('cn', 'Group Name', context='group') >>>> >>>> The lookup would first look for a context-specific entry and fall >>>> back to a non-context specific, something like: >>>> >>>> if attr+context in labeldict: return labeldict[attr+context] >>>> elif attr in labeldict: return labeldict[attr] >>>> else return "woop" >>>> >>>> Like I said, might be overkill ;-) >>>> >>>> But still, the alarms go off when we're putting the same things in >>>> multiple places. >>>> >> Yeah, the registration system sounds like overkill all right. :D >> >> Seriously, I was thinking about several ways on how to resolve this >> issue. Ideally, all information about attributes should be retrieved >> from the schema. Unfortunately, it cannot be done. There's just very >> little information in there. >> >> Another idea was to have an LDAPAttribute base class, that we would >> extend for each attribute. We could then have a ldapattribute.py >> module in ipalib/plugins with all the attributes we use defined there. >> If 3rd parties require a new attribute, they just create their own >> LDAPAttribute subclass in their plugins. I think that this would be >> the best and cleanest approach. LDAPObjects would have a set of >> LDAPAttribute references and do all attribute manipulation using them. >> Also, attribute parameters could be automatically generated, so they >> wouldn't mix with control parameters in takes_params (like --all, >> --raw, --posix for groups, etc.). This is probably the way we'll be >> going in the future, but there's still a few problems I have to >> resolve before implementing it. >> >> By the way, my goal is to move all this LDAP infrastructure from the >> plugin layer into the core library itself once it's mature (and >> documented) enough. Probably not going to happen in v2, but we'll see >> how it goes. >> >>>>>> In the user plugin 'ou' is in the default attributes. We don't use >>>>>> this attribute. >>>>> Since we don't use it, it's not going to get displayed anyway. >>>>> >>>>> All the values in attribute_names, default_attribute and >>>>> attribute_order are subject to change. I set them to initial values >>>>> I thought are acceptable, but I don't think I'm the right person to >>>>> decide what's going to be there. Ideally, someone with more >>>>> UI/text/user friendliness experience should review it (there's not >>>>> programming knowledge required to change the values). >>>> >>>> Ok, this particular attribute brings up DIT issues which is why I >>>> flagged it. >>>> >>>>>> I think that in general baseldap needs to be documented to explain >>>>>> how things work. There is no explanation for object_class_config, >>>>>> for example, that it defines the attribute in cn=ipaConfig that >>>>>> contains the default list of objectclasses for the object. >>>>> Yeah, there's no documentation at this point, but I'm working on it >>>>> as we "speak". >>>>> >>>>>> rob >>>>>> >>>>> >>>>> One more thing, I reviewed your latest patches and they make change >>>>> to host and service plugins. Your patches should be pushed first, >>>>> because they are more complex and also more important, so I posted >>>>> updated versions to the corresponding email threads on freeipa-devel. >>>>> >>>>> Pavel >>>> >>>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>>> >>> >>> I've found another problem with the attribute map. I like your idea >>> of breaking out memberof by different type but as it is now doesn't >>> work, it only prints group membership. You'd have to parse the DN to >>> distinguish between groups, taskgroups, etc. >> >> And that's exactly what I'm doing in >> LDAPObject.convert_attribute_members. I mean the DN parsing. It just >> doesn't work for users at the moment, because I forgot to add the >> other types of groups in users attribute_members['memberof']. >> >> in ipalib/plugins/user.py: >> >> class user(LDAPObject): >> # ... >> attribute_members = { >> # add other groups here >> # example 'memberof': ['group', 'taskgroup'] >> 'memberof': ['group'] >> } >> # ... >> >> try: >> >> ipa user-add test --first=first --last=last >> ipa taskgroup-add tasktest --desc=desc >> ipa taskgroup-add-member tasktest --users=test >> ipa user-show test --all >> >> Should work. >> >> Note: Just noticed it won't work for netgroups, because I forgot to >> override LDAPObject.get_primary_key_from_dn in the netgroup class. >> Normally get_primary_key_from_dn just returns the value of RDN, but >> for netgroups we have to do a search to retrieve the primary key. >> >> class netgroup(LDAPObject): >> # ... >> def get_primary_key_from_dn(self, dn): >> (dn, entry_attrs) = self.backend.get_entry( >> dn, [self.primary_key.name] >> ) >> return entry_attrs.get(self.primary_key.name, '') >> # ... >> >>> I think for the short-term we can make a note to do this and just >>> print all memberships so we can get this committed. I'm still not a >>> fan of the attribute_names within each plugin though, I need more >>> convincing. >>> >>> rob >>> >> >> By the way, I'm going on vacation next week. So, I think we should >> wait anyway before committing this. >> >> Pavel >> > I'm sending an updated version of all the patches. They should apply on > the current master. I think they should now address most of your > concerns and I also fixed some bugs I found on my own. > > Pavel Some are good to go, others need some more work: 0001-config: ack 0002-group: ack 0003-hostgroups: nack, hostgroups-show doesn't show members by default. 0004-netgroup: nack, fails a ton of unit tests 0005-rolgroup: nack, rolegroup-find doesn't work (try serviceadmin). rolegroup-show doesn't include members by default. 0006-taskgroup: nack, taskgroup-find doesn't work (try ipa addhosts) taskgroup-show doesn't include members by default. 0007-tests: ack though we should do some non-raw tests as well IMHO. In test-hostgroup looks like there is some leftover debug output that should be removed before committing. 0008-pwpolicy: nack, have another patch floating around that covers most of this. I'll try to incorporate some of your ideas into my patch once committed. 0009 missing? 0010-service: ack, but we should try to avoid shadowing built-in names (filter) 0011-user: ack but changes like this seem to make it less readable: - textui.print_dashed('Unlocked user "%s".' % uid) + textui.print_dashed('Unlocked user "%s".' % keys[-1]) I realize that *keys is more generic than specifying one argument but there is no documentation saying was keys means. Some general observations that don't necessarily need to be addressed here but do need to be done: - adding/removing member failures should return non-zero return code (so you can test $? on cmd-line) - add/remove-member should probably prompt for things if not provided on command-line (and allow empty values). Right now if you do an add-member it prompts for group to modify and then submits an empty request Let me know if it is safe to push these patches individually. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Fri Oct 2 16:00:08 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 18:00:08 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC60F4E.400@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> <4AC60F4E.400@redhat.com> Message-ID: <4AC62388.9040805@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Zuna wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Pavel Z?na wrote: >>>>>>>> This is a series of patches that depends on patches: >>>>>>>> - Improve attribute printing in the CLI. >>>>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>>>> >>>>>>>> All plugins are converted to extend baseldap classes. This makes >>>>>>>> things more consistent, fixes some general bugs (with return >>>>>>>> values for example) and it also makes plugins easier to maintain >>>>>>>> (as it removes a lot of duplicate code). >>>>>>>> >>>>>>>> Because baseldap classes have features that enable us to define >>>>>>>> relationships between plugins, I thought it might be best to >>>>>>>> submit all of the conversions at once and have all the >>>>>>>> relationships fully defined. >>>>>>>> >>>>>>>> Affected plugins: >>>>>>>> config >>>>>>>> user >>>>>>>> host >>>>>>>> service >>>>>>>> group >>>>>>>> hostgroup >>>>>>>> netgroup >>>>>>>> rolegroup >>>>>>>> taskgroup >>>>>>>> pwpolicy >>>>>>>> >>>>>>>> There's also a patch that fixes all unit tests. >>>>>>>> >>>>>>>> Jenny, I included you to Cc, because the patch introduces a lot >>>>>>>> of changes to the UI (and you're probably not going to like me >>>>>>>> for this). >>>>>>>> >>>>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>>>> option. Without it, data from LDAP is formated and translated to >>>>>>>> human readable. For example: >>>>>>>> >>>>>>>> # ipa user-show admin --all >>>>>>>> ---------- >>>>>>>> user-show: >>>>>>>> ---------- >>>>>>>> User: admin >>>>>>>> user id: admin >>>>>>>> full name: Administrator >>>>>>>> last name: Administrator >>>>>>>> home directory: /home/admin >>>>>>>> login shell: /bin/bash >>>>>>>> uid number: 999 >>>>>>>> gid number: 1001 >>>>>>>> gecos: Administrator >>>>>>>> kerberos principal: admin at PZUNA >>>>>>>> last password change: 20090904122852Z >>>>>>>> password expiration: 20091203122852Z >>>>>>>> member of groups: admins >>>>>>>> >>>>>>>> # ipa user-show admin --all --raw >>>>>>>> ---------- >>>>>>>> user-show: >>>>>>>> ---------- >>>>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>>>> uid: admin >>>>>>>> cn: Administrator >>>>>>>> sn: Administrator >>>>>>>> homedirectory: /home/admin >>>>>>>> loginshell: /bin/bash >>>>>>>> uidnumber: 999 >>>>>>>> gidnumber: 1001 >>>>>>>> gecos: Administrator >>>>>>>> krbprincipalname: admin at PZUNA >>>>>>>> krblastpwdchange: 20090904122852Z >>>>>>>> krbpasswordexpiration: 20091203122852Z >>>>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>>>> objectclass: top >>>>>>>> objectclass: person >>>>>>>> objectclass: posixaccount >>>>>>>> objectclass: krbprincipalaux >>>>>>>> objectclass: inetuser >>>>>>>> >>>>>>>> Advantages: more user friendly, allows for easy localization, >>>>>>>> translation of DNs to primary keys (immediately usable as input >>>>>>>> to other plugin commands) >>>>>>>> >>>>>>>> I recommend, that you use the --raw flag for testing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>>>> >>>>>>>> It should be up-to-date with master and all my patches are >>>>>>>> applied there. I hope it makes reviewing them at least a bit >>>>>>>> easier. >>>>>>>> >>>>>>>> Pavel >>>>>>> >>>>>>> Why are you using a pre_callback() to define default values >>>>>>> instead of using default_from? It seems clearer to use that. >>>>>> You're probably referring to the user plugin, where gecos and >>>>>> krbprincipalname defaults are set inside pre_callback. It's a >>>>>> residue from some time ago when we didn't use autofill=True with >>>>>> default_from and it didn't have any effect on optional parameters. >>>>>> It's a small change, but I included an updated version of the >>>>>> patch with this email. >>>>> >>>>> Ok. I gather you've moved a lot of logic into the pre_callback >>>>> plugin to avoid overriding execute? One other goal we wanted was to >>>>> allow plugins to extend other plugins and this may be good step on >>>>> the way there. So for example, a user wants to be able to set some >>>>> extra objectclass, they could do it with a similar pre_callback >>>>> extension to the user plugin (once we do the plumbing for it, that >>>>> is). >>> Right. The goal is to have a common execute in the baseclass, that >>> does most of the dirty work and let the user/plugin author add the >>> specifics of his plugin in the pre/post callbacks. All the data >>> generated by the base (before calling python-ldap) is available for >>> modification in the pre-callbacks and all data coming out of >>> python-ldap is made available in the post-callback. >>> >>> And yes, the plugins could be almost endlessly extended this way. For >>> example, someone could do this: >>> >>> from ipalib.plugins.user import user_add >>> >>> class user_add_extended(user_add): >>> def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> # let the original user_add plugin do its job >>> super(user_add_extended, self).pre_callback( >>> ldap, dn, entry_attrs, *keys, **options) >>> # add an extra object class >>> entry_attrs['objectclass'].append('new_object_class') >>> return dn >>> >>> api.register(user_add_extended) >>> >>>>>>> This also duplicates some values in the attribute_names() >>>>>>> dictionary. I wonder if this can be either created from the >>>>>>> parameters or define a global set somewhere that covers all plugins. >>>>>> I know, but I couldn't find a better solution. I thought we could >>>>>> add something like a 'real_name' kwarg to params, but this has 2 >>>>>> main disadvantages: >>>>>> 1) it only makes sense with parameters that refer to an LDAP >>>>>> attribute >>>>>> 2) it doesn't work for attributes with no param counterparts >>>>>> >>>>>> The global set is a good idea as long as we consider only our own >>>>>> plugins. 3rd party plugins would have to modify this set to add >>>>>> their own attributes. Also, attributes might have a different >>>>>> meaning for different objects. They usually don't, but take 'cn' >>>>>> for example. We use it as an ID, name, full name (for users), etc. >>>>> >>>>> Ok, that's a good point. I'm wondering if its overkill to write a >>>>> registration system for this, something like: >>>>> >>>>> def set_label(attr, label, context='') >>>>> >>>>> def get_label(attr, context='') >>>>> >>>>> In this we'd store a dict that would be keyed on attr+context. Some >>>>> examples might be: >>>>> >>>>> set_label('uid', 'Login') >>>>> set_label('gn', 'First Name') >>>>> set_label('cn', 'Full Name', context='user') >>>>> set_label('cn', 'Group Name', context='group') >>>>> >>>>> The lookup would first look for a context-specific entry and fall >>>>> back to a non-context specific, something like: >>>>> >>>>> if attr+context in labeldict: return labeldict[attr+context] >>>>> elif attr in labeldict: return labeldict[attr] >>>>> else return "woop" >>>>> >>>>> Like I said, might be overkill ;-) >>>>> >>>>> But still, the alarms go off when we're putting the same things in >>>>> multiple places. >>>>> >>> Yeah, the registration system sounds like overkill all right. :D >>> >>> Seriously, I was thinking about several ways on how to resolve this >>> issue. Ideally, all information about attributes should be retrieved >>> from the schema. Unfortunately, it cannot be done. There's just very >>> little information in there. >>> >>> Another idea was to have an LDAPAttribute base class, that we would >>> extend for each attribute. We could then have a ldapattribute.py >>> module in ipalib/plugins with all the attributes we use defined >>> there. If 3rd parties require a new attribute, they just create their >>> own LDAPAttribute subclass in their plugins. I think that this would >>> be the best and cleanest approach. LDAPObjects would have a set of >>> LDAPAttribute references and do all attribute manipulation using >>> them. Also, attribute parameters could be automatically generated, so >>> they wouldn't mix with control parameters in takes_params (like >>> --all, --raw, --posix for groups, etc.). This is probably the way >>> we'll be going in the future, but there's still a few problems I have >>> to resolve before implementing it. >>> >>> By the way, my goal is to move all this LDAP infrastructure from the >>> plugin layer into the core library itself once it's mature (and >>> documented) enough. Probably not going to happen in v2, but we'll see >>> how it goes. >>> >>>>>>> In the user plugin 'ou' is in the default attributes. We don't >>>>>>> use this attribute. >>>>>> Since we don't use it, it's not going to get displayed anyway. >>>>>> >>>>>> All the values in attribute_names, default_attribute and >>>>>> attribute_order are subject to change. I set them to initial >>>>>> values I thought are acceptable, but I don't think I'm the right >>>>>> person to decide what's going to be there. Ideally, someone with >>>>>> more UI/text/user friendliness experience should review it >>>>>> (there's not programming knowledge required to change the values). >>>>> >>>>> Ok, this particular attribute brings up DIT issues which is why I >>>>> flagged it. >>>>> >>>>>>> I think that in general baseldap needs to be documented to >>>>>>> explain how things work. There is no explanation for >>>>>>> object_class_config, for example, that it defines the attribute >>>>>>> in cn=ipaConfig that contains the default list of objectclasses >>>>>>> for the object. >>>>>> Yeah, there's no documentation at this point, but I'm working on >>>>>> it as we "speak". >>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> One more thing, I reviewed your latest patches and they make >>>>>> change to host and service plugins. Your patches should be pushed >>>>>> first, because they are more complex and also more important, so I >>>>>> posted updated versions to the corresponding email threads on >>>>>> freeipa-devel. >>>>>> >>>>>> Pavel >>>>> >>>>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>>>> >>>> >>>> I've found another problem with the attribute map. I like your idea >>>> of breaking out memberof by different type but as it is now doesn't >>>> work, it only prints group membership. You'd have to parse the DN to >>>> distinguish between groups, taskgroups, etc. >>> >>> And that's exactly what I'm doing in >>> LDAPObject.convert_attribute_members. I mean the DN parsing. It just >>> doesn't work for users at the moment, because I forgot to add the >>> other types of groups in users attribute_members['memberof']. >>> >>> in ipalib/plugins/user.py: >>> >>> class user(LDAPObject): >>> # ... >>> attribute_members = { >>> # add other groups here >>> # example 'memberof': ['group', 'taskgroup'] >>> 'memberof': ['group'] >>> } >>> # ... >>> >>> try: >>> >>> ipa user-add test --first=first --last=last >>> ipa taskgroup-add tasktest --desc=desc >>> ipa taskgroup-add-member tasktest --users=test >>> ipa user-show test --all >>> >>> Should work. >>> >>> Note: Just noticed it won't work for netgroups, because I forgot to >>> override LDAPObject.get_primary_key_from_dn in the netgroup class. >>> Normally get_primary_key_from_dn just returns the value of RDN, but >>> for netgroups we have to do a search to retrieve the primary key. >>> >>> class netgroup(LDAPObject): >>> # ... >>> def get_primary_key_from_dn(self, dn): >>> (dn, entry_attrs) = self.backend.get_entry( >>> dn, [self.primary_key.name] >>> ) >>> return entry_attrs.get(self.primary_key.name, '') >>> # ... >>> >>>> I think for the short-term we can make a note to do this and just >>>> print all memberships so we can get this committed. I'm still not a >>>> fan of the attribute_names within each plugin though, I need more >>>> convincing. >>>> >>>> rob >>>> >>> >>> By the way, I'm going on vacation next week. So, I think we should >>> wait anyway before committing this. >>> >>> Pavel >>> >> I'm sending an updated version of all the patches. They should apply >> on the current master. I think they should now address most of your >> concerns and I also fixed some bugs I found on my own. >> >> Pavel > > Some are good to go, others need some more work: > > 0001-config: ack > > 0002-group: ack > > 0003-hostgroups: nack, hostgroups-show doesn't show members by default. Fixed in attached patch. > 0004-netgroup: nack, fails a ton of unit tests Fixed in patch I sent previously today. > 0005-rolgroup: nack, rolegroup-find doesn't work (try serviceadmin). > rolegroup-show doesn't include members by default. > > 0006-taskgroup: nack, taskgroup-find doesn't work (try ipa addhosts) > taskgroup-show doesn't include members by default. Both "member thing" fixed, but *-find seems to work for me. Can you post the exact commands that fail? > 0007-tests: ack though we should do some non-raw tests as well IMHO. In > test-hostgroup looks like there is some leftover debug output that > should be removed before committing. Removed the leftover debug output in attached patch. > 0008-pwpolicy: nack, have another patch floating around that covers most > of this. I'll try to incorporate some of your ideas into my patch once > committed. Ok. > 0009 missing? Not missing, just wrong numbering. There was an unrelated patch that got in between the plugin patches. > 0010-service: ack, but we should try to avoid shadowing built-in names > (filter) Sometimes it might be justified, but in this case we really should avoid it, because it's actually in the base class and what if someone wants to use python's filter function inside the callback? (They would have to rename the param or do some hacking around.) It doesn't hurt anything for now, but this will have to be patched at several places - I'll post a patch on Monday. > 0011-user: ack but changes like this seem to make it less readable: > > - textui.print_dashed('Unlocked user "%s".' % uid) > + textui.print_dashed('Unlocked user "%s".' % keys[-1]) > > I realize that *keys is more generic than specifying one argument but > there is no documentation saying was keys means. I'm really slow at documenting things, but it's in the works. > Some general observations that don't necessarily need to be addressed > here but do need to be done: > > - adding/removing member failures should return non-zero return code (so > you can test $? on cmd-line) > - add/remove-member should probably prompt for things if not provided on > command-line (and allow empty values). Right now if you do an add-member > it prompts for group to modify and then submits an empty request Ok, I'll try to address these issues as soon as possible. > Let me know if it is safe to push these patches individually. The user and *group plugins should be pushed at once. Everything else should be safe individually. > rob > Pavel From pzuna at redhat.com Fri Oct 2 16:02:17 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 02 Oct 2009 18:02:17 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC62388.9040805@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> <4AC60F4E.400@redhat.com> <4AC62388.9040805@redhat.com> Message-ID: <4AC62409.2020703@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Pavel Z?na wrote: >>>> Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Pavel Zuna wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Pavel Z?na wrote: >>>>>>>>> This is a series of patches that depends on patches: >>>>>>>>> - Improve attribute printing in the CLI. >>>>>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>>>>> >>>>>>>>> All plugins are converted to extend baseldap classes. This >>>>>>>>> makes things more consistent, fixes some general bugs (with >>>>>>>>> return values for example) and it also makes plugins easier to >>>>>>>>> maintain (as it removes a lot of duplicate code). >>>>>>>>> >>>>>>>>> Because baseldap classes have features that enable us to define >>>>>>>>> relationships between plugins, I thought it might be best to >>>>>>>>> submit all of the conversions at once and have all the >>>>>>>>> relationships fully defined. >>>>>>>>> >>>>>>>>> Affected plugins: >>>>>>>>> config >>>>>>>>> user >>>>>>>>> host >>>>>>>>> service >>>>>>>>> group >>>>>>>>> hostgroup >>>>>>>>> netgroup >>>>>>>>> rolegroup >>>>>>>>> taskgroup >>>>>>>>> pwpolicy >>>>>>>>> >>>>>>>>> There's also a patch that fixes all unit tests. >>>>>>>>> >>>>>>>>> Jenny, I included you to Cc, because the patch introduces a lot >>>>>>>>> of changes to the UI (and you're probably not going to like me >>>>>>>>> for this). >>>>>>>>> >>>>>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>>>>> option. Without it, data from LDAP is formated and translated >>>>>>>>> to human readable. For example: >>>>>>>>> >>>>>>>>> # ipa user-show admin --all >>>>>>>>> ---------- >>>>>>>>> user-show: >>>>>>>>> ---------- >>>>>>>>> User: admin >>>>>>>>> user id: admin >>>>>>>>> full name: Administrator >>>>>>>>> last name: Administrator >>>>>>>>> home directory: /home/admin >>>>>>>>> login shell: /bin/bash >>>>>>>>> uid number: 999 >>>>>>>>> gid number: 1001 >>>>>>>>> gecos: Administrator >>>>>>>>> kerberos principal: admin at PZUNA >>>>>>>>> last password change: 20090904122852Z >>>>>>>>> password expiration: 20091203122852Z >>>>>>>>> member of groups: admins >>>>>>>>> >>>>>>>>> # ipa user-show admin --all --raw >>>>>>>>> ---------- >>>>>>>>> user-show: >>>>>>>>> ---------- >>>>>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>>>>> uid: admin >>>>>>>>> cn: Administrator >>>>>>>>> sn: Administrator >>>>>>>>> homedirectory: /home/admin >>>>>>>>> loginshell: /bin/bash >>>>>>>>> uidnumber: 999 >>>>>>>>> gidnumber: 1001 >>>>>>>>> gecos: Administrator >>>>>>>>> krbprincipalname: admin at PZUNA >>>>>>>>> krblastpwdchange: 20090904122852Z >>>>>>>>> krbpasswordexpiration: 20091203122852Z >>>>>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>>>>> objectclass: top >>>>>>>>> objectclass: person >>>>>>>>> objectclass: posixaccount >>>>>>>>> objectclass: krbprincipalaux >>>>>>>>> objectclass: inetuser >>>>>>>>> >>>>>>>>> Advantages: more user friendly, allows for easy localization, >>>>>>>>> translation of DNs to primary keys (immediately usable as input >>>>>>>>> to other plugin commands) >>>>>>>>> >>>>>>>>> I recommend, that you use the --raw flag for testing. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>>>>> >>>>>>>>> It should be up-to-date with master and all my patches are >>>>>>>>> applied there. I hope it makes reviewing them at least a bit >>>>>>>>> easier. >>>>>>>>> >>>>>>>>> Pavel >>>>>>>> >>>>>>>> Why are you using a pre_callback() to define default values >>>>>>>> instead of using default_from? It seems clearer to use that. >>>>>>> You're probably referring to the user plugin, where gecos and >>>>>>> krbprincipalname defaults are set inside pre_callback. It's a >>>>>>> residue from some time ago when we didn't use autofill=True with >>>>>>> default_from and it didn't have any effect on optional >>>>>>> parameters. It's a small change, but I included an updated >>>>>>> version of the patch with this email. >>>>>> >>>>>> Ok. I gather you've moved a lot of logic into the pre_callback >>>>>> plugin to avoid overriding execute? One other goal we wanted was >>>>>> to allow plugins to extend other plugins and this may be good step >>>>>> on the way there. So for example, a user wants to be able to set >>>>>> some extra objectclass, they could do it with a similar >>>>>> pre_callback extension to the user plugin (once we do the plumbing >>>>>> for it, that is). >>>> Right. The goal is to have a common execute in the baseclass, that >>>> does most of the dirty work and let the user/plugin author add the >>>> specifics of his plugin in the pre/post callbacks. All the data >>>> generated by the base (before calling python-ldap) is available for >>>> modification in the pre-callbacks and all data coming out of >>>> python-ldap is made available in the post-callback. >>>> >>>> And yes, the plugins could be almost endlessly extended this way. >>>> For example, someone could do this: >>>> >>>> from ipalib.plugins.user import user_add >>>> >>>> class user_add_extended(user_add): >>>> def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): >>>> # let the original user_add plugin do its job >>>> super(user_add_extended, self).pre_callback( >>>> ldap, dn, entry_attrs, *keys, **options) >>>> # add an extra object class >>>> entry_attrs['objectclass'].append('new_object_class') >>>> return dn >>>> >>>> api.register(user_add_extended) >>>> >>>>>>>> This also duplicates some values in the attribute_names() >>>>>>>> dictionary. I wonder if this can be either created from the >>>>>>>> parameters or define a global set somewhere that covers all >>>>>>>> plugins. >>>>>>> I know, but I couldn't find a better solution. I thought we could >>>>>>> add something like a 'real_name' kwarg to params, but this has 2 >>>>>>> main disadvantages: >>>>>>> 1) it only makes sense with parameters that refer to an LDAP >>>>>>> attribute >>>>>>> 2) it doesn't work for attributes with no param counterparts >>>>>>> >>>>>>> The global set is a good idea as long as we consider only our own >>>>>>> plugins. 3rd party plugins would have to modify this set to add >>>>>>> their own attributes. Also, attributes might have a different >>>>>>> meaning for different objects. They usually don't, but take 'cn' >>>>>>> for example. We use it as an ID, name, full name (for users), etc. >>>>>> >>>>>> Ok, that's a good point. I'm wondering if its overkill to write a >>>>>> registration system for this, something like: >>>>>> >>>>>> def set_label(attr, label, context='') >>>>>> >>>>>> def get_label(attr, context='') >>>>>> >>>>>> In this we'd store a dict that would be keyed on attr+context. >>>>>> Some examples might be: >>>>>> >>>>>> set_label('uid', 'Login') >>>>>> set_label('gn', 'First Name') >>>>>> set_label('cn', 'Full Name', context='user') >>>>>> set_label('cn', 'Group Name', context='group') >>>>>> >>>>>> The lookup would first look for a context-specific entry and fall >>>>>> back to a non-context specific, something like: >>>>>> >>>>>> if attr+context in labeldict: return labeldict[attr+context] >>>>>> elif attr in labeldict: return labeldict[attr] >>>>>> else return "woop" >>>>>> >>>>>> Like I said, might be overkill ;-) >>>>>> >>>>>> But still, the alarms go off when we're putting the same things in >>>>>> multiple places. >>>>>> >>>> Yeah, the registration system sounds like overkill all right. :D >>>> >>>> Seriously, I was thinking about several ways on how to resolve this >>>> issue. Ideally, all information about attributes should be retrieved >>>> from the schema. Unfortunately, it cannot be done. There's just very >>>> little information in there. >>>> >>>> Another idea was to have an LDAPAttribute base class, that we would >>>> extend for each attribute. We could then have a ldapattribute.py >>>> module in ipalib/plugins with all the attributes we use defined >>>> there. If 3rd parties require a new attribute, they just create >>>> their own LDAPAttribute subclass in their plugins. I think that this >>>> would be the best and cleanest approach. LDAPObjects would have a >>>> set of LDAPAttribute references and do all attribute manipulation >>>> using them. Also, attribute parameters could be automatically >>>> generated, so they wouldn't mix with control parameters in >>>> takes_params (like --all, --raw, --posix for groups, etc.). This is >>>> probably the way we'll be going in the future, but there's still a >>>> few problems I have to resolve before implementing it. >>>> >>>> By the way, my goal is to move all this LDAP infrastructure from the >>>> plugin layer into the core library itself once it's mature (and >>>> documented) enough. Probably not going to happen in v2, but we'll >>>> see how it goes. >>>> >>>>>>>> In the user plugin 'ou' is in the default attributes. We don't >>>>>>>> use this attribute. >>>>>>> Since we don't use it, it's not going to get displayed anyway. >>>>>>> >>>>>>> All the values in attribute_names, default_attribute and >>>>>>> attribute_order are subject to change. I set them to initial >>>>>>> values I thought are acceptable, but I don't think I'm the right >>>>>>> person to decide what's going to be there. Ideally, someone with >>>>>>> more UI/text/user friendliness experience should review it >>>>>>> (there's not programming knowledge required to change the values). >>>>>> >>>>>> Ok, this particular attribute brings up DIT issues which is why I >>>>>> flagged it. >>>>>> >>>>>>>> I think that in general baseldap needs to be documented to >>>>>>>> explain how things work. There is no explanation for >>>>>>>> object_class_config, for example, that it defines the attribute >>>>>>>> in cn=ipaConfig that contains the default list of objectclasses >>>>>>>> for the object. >>>>>>> Yeah, there's no documentation at this point, but I'm working on >>>>>>> it as we "speak". >>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> One more thing, I reviewed your latest patches and they make >>>>>>> change to host and service plugins. Your patches should be pushed >>>>>>> first, because they are more complex and also more important, so >>>>>>> I posted updated versions to the corresponding email threads on >>>>>>> freeipa-devel. >>>>>>> >>>>>>> Pavel >>>>>> >>>>>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>>>>> >>>>> >>>>> I've found another problem with the attribute map. I like your idea >>>>> of breaking out memberof by different type but as it is now doesn't >>>>> work, it only prints group membership. You'd have to parse the DN >>>>> to distinguish between groups, taskgroups, etc. >>>> >>>> And that's exactly what I'm doing in >>>> LDAPObject.convert_attribute_members. I mean the DN parsing. It just >>>> doesn't work for users at the moment, because I forgot to add the >>>> other types of groups in users attribute_members['memberof']. >>>> >>>> in ipalib/plugins/user.py: >>>> >>>> class user(LDAPObject): >>>> # ... >>>> attribute_members = { >>>> # add other groups here >>>> # example 'memberof': ['group', 'taskgroup'] >>>> 'memberof': ['group'] >>>> } >>>> # ... >>>> >>>> try: >>>> >>>> ipa user-add test --first=first --last=last >>>> ipa taskgroup-add tasktest --desc=desc >>>> ipa taskgroup-add-member tasktest --users=test >>>> ipa user-show test --all >>>> >>>> Should work. >>>> >>>> Note: Just noticed it won't work for netgroups, because I forgot to >>>> override LDAPObject.get_primary_key_from_dn in the netgroup class. >>>> Normally get_primary_key_from_dn just returns the value of RDN, but >>>> for netgroups we have to do a search to retrieve the primary key. >>>> >>>> class netgroup(LDAPObject): >>>> # ... >>>> def get_primary_key_from_dn(self, dn): >>>> (dn, entry_attrs) = self.backend.get_entry( >>>> dn, [self.primary_key.name] >>>> ) >>>> return entry_attrs.get(self.primary_key.name, '') >>>> # ... >>>> >>>>> I think for the short-term we can make a note to do this and just >>>>> print all memberships so we can get this committed. I'm still not a >>>>> fan of the attribute_names within each plugin though, I need more >>>>> convincing. >>>>> >>>>> rob >>>>> >>>> >>>> By the way, I'm going on vacation next week. So, I think we should >>>> wait anyway before committing this. >>>> >>>> Pavel >>>> >>> I'm sending an updated version of all the patches. They should apply >>> on the current master. I think they should now address most of your >>> concerns and I also fixed some bugs I found on my own. >>> >>> Pavel >> >> Some are good to go, others need some more work: >> >> 0001-config: ack >> >> 0002-group: ack >> >> 0003-hostgroups: nack, hostgroups-show doesn't show members by default. > Fixed in attached patch. > >> 0004-netgroup: nack, fails a ton of unit tests > Fixed in patch I sent previously today. > >> 0005-rolgroup: nack, rolegroup-find doesn't work (try serviceadmin). >> rolegroup-show doesn't include members by default. >> >> 0006-taskgroup: nack, taskgroup-find doesn't work (try ipa addhosts) >> taskgroup-show doesn't include members by default. > Both "member thing" fixed, but *-find seems to work for me. Can you post > the exact commands that fail? > >> 0007-tests: ack though we should do some non-raw tests as well IMHO. >> In test-hostgroup looks like there is some leftover debug output that >> should be removed before committing. > Removed the leftover debug output in attached patch. > >> 0008-pwpolicy: nack, have another patch floating around that covers >> most of this. I'll try to incorporate some of your ideas into my patch >> once committed. > Ok. > >> 0009 missing? > Not missing, just wrong numbering. There was an unrelated patch that got > in between the plugin patches. > >> 0010-service: ack, but we should try to avoid shadowing built-in names >> (filter) > Sometimes it might be justified, but in this case we really should avoid > it, because it's actually in the base class and what if someone wants to > use python's filter function inside the callback? (They would have to > rename the param or do some hacking around.) It doesn't hurt anything > for now, but this will have to be patched at several places - I'll post > a patch on Monday. > >> 0011-user: ack but changes like this seem to make it less readable: >> >> - textui.print_dashed('Unlocked user "%s".' % uid) >> + textui.print_dashed('Unlocked user "%s".' % keys[-1]) >> >> I realize that *keys is more generic than specifying one argument but >> there is no documentation saying was keys means. > I'm really slow at documenting things, but it's in the works. > >> Some general observations that don't necessarily need to be addressed >> here but do need to be done: >> >> - adding/removing member failures should return non-zero return code >> (so you can test $? on cmd-line) >> - add/remove-member should probably prompt for things if not provided >> on command-line (and allow empty values). Right now if you do an >> add-member it prompts for group to modify and then submits an empty >> request > Ok, I'll try to address these issues as soon as possible. > >> Let me know if it is safe to push these patches individually. > The user and *group plugins should be pushed at once. Everything else > should be safe individually. > >> rob >> > > Pavel Awwww. Forgot to attach the patches... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-hostgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 8715 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Make-the-rolegroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 4295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-unit-tests-for-plugins-using-baseldap-classes.patch Type: application/mbox Size: 47063 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 2 17:43:45 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Oct 2009 13:43:45 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC62388.9040805@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> <4AC60F4E.400@redhat.com> <4AC62388.9040805@redhat.com> Message-ID: <4AC63BD1.90109@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Some are good to go, others need some more work: >> >> 0001-config: ack >> >> 0002-group: ack >> >> 0003-hostgroups: nack, hostgroups-show doesn't show members by default. > Fixed in attached patch. > >> 0004-netgroup: nack, fails a ton of unit tests > Fixed in patch I sent previously today. > >> 0005-rolgroup: nack, rolegroup-find doesn't work (try serviceadmin). >> rolegroup-show doesn't include members by default. >> >> 0006-taskgroup: nack, taskgroup-find doesn't work (try ipa addhosts) >> taskgroup-show doesn't include members by default. > Both "member thing" fixed, but *-find seems to work for me. Can you post > the exact commands that fail? % ipa rolegroup-find serviceadmin Looks like it is failing because nestedgroup isn't an objectclass in rolegroups. [02/Oct/2009:13:22:05 -0400] conn=1271 op=3 SRCH base="cn=rolegroups,cn=accounts,dc=example,dc=com" scope=1 filter="(&(|(memberOf=*serviceadmin*)(cn=*serviceadmin*)(description=*serviceadmin*))(&(objectClass=ipaobject)(objectClass=groupofnames)(objectClass=nestedgroup)))" attrs="cn description memberOf" [02/Oct/2009:13:22:05 -0400] conn=1271 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [02/Oct/2009:13:22:07 -0400] conn=1271 op=3 RESULT err=3 tag=101 nentries=0 etime=2 notes=U > >> 0007-tests: ack though we should do some non-raw tests as well IMHO. >> In test-hostgroup looks like there is some leftover debug output that >> should be removed before committing. > Removed the leftover debug output in attached patch. > >> 0008-pwpolicy: nack, have another patch floating around that covers >> most of this. I'll try to incorporate some of your ideas into my patch >> once committed. > Ok. > >> 0009 missing? > Not missing, just wrong numbering. There was an unrelated patch that got > in between the plugin patches. > >> 0010-service: ack, but we should try to avoid shadowing built-in names >> (filter) > Sometimes it might be justified, but in this case we really should avoid > it, because it's actually in the base class and what if someone wants to > use python's filter function inside the callback? (They would have to > rename the param or do some hacking around.) It doesn't hurt anything > for now, but this will have to be patched at several places - I'll post > a patch on Monday. > >> 0011-user: ack but changes like this seem to make it less readable: >> >> - textui.print_dashed('Unlocked user "%s".' % uid) >> + textui.print_dashed('Unlocked user "%s".' % keys[-1]) >> >> I realize that *keys is more generic than specifying one argument but >> there is no documentation saying was keys means. > I'm really slow at documenting things, but it's in the works. > >> Some general observations that don't necessarily need to be addressed >> here but do need to be done: >> >> - adding/removing member failures should return non-zero return code >> (so you can test $? on cmd-line) >> - add/remove-member should probably prompt for things if not provided >> on command-line (and allow empty values). Right now if you do an >> add-member it prompts for group to modify and then submits an empty >> request > Ok, I'll try to address these issues as soon as possible. > >> Let me know if it is safe to push these patches individually. > The user and *group plugins should be pushed at once. Everything else > should be safe individually. Ok, I'll review the new patches and get the acked ones pushed out. rob > >> rob >> > > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sbose at redhat.com Mon Oct 5 15:20:57 2009 From: sbose at redhat.com (Sumit Bose) Date: Mon, 5 Oct 2009 17:20:57 +0200 Subject: [Freeipa-devel] [PATCH] Fix sasl mappings In-Reply-To: <1254242595.3017.10.camel@localhost.localdomain> References: <1254242595.3017.10.camel@localhost.localdomain> Message-ID: <20091005152057.GH3006@localhost.localdomain> On Tue, Sep 29, 2009 at 12:43:15PM -0400, Simo Sorce wrote: > Sasl mappings never worked properly with full principal names. > This patch fixes the problem. > > See bug#526284 > > Should probably commit this patch also against v1. > > Simo. this patch works for me with v1 and v2. ACK bye, Sumit From jderose at redhat.com Mon Oct 5 18:58:38 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 05 Oct 2009 12:58:38 -0600 Subject: [Freeipa-devel] [PATCH] 280 add option to not normalize on adds/updates In-Reply-To: <4AC607EE.3080604@redhat.com> References: <4AC6018C.6010603@redhat.com> <4AC607EE.3080604@redhat.com> Message-ID: <1254769118.4643.0.camel@jgd-dsk> ack. pushed to master. On Fri, 2009-10-02 at 16:02 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > Add an option to not run the normalizer against the DN on adds/updates. > > > > The MIT ldap plugin is extremely picky about the format of DNs it adds > > and it does not like the way we normalize things so I need to set it up > > right in the plugin and commit it that way. > > > > rob > ack. > > Although I would rather have the param called 'normalize_dn' instead of > 'normalize', so everyone knows what is being normalized. > > Pavel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Mon Oct 5 19:19:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2009 15:19:04 -0400 Subject: [Freeipa-devel] [PATCH] 272 Add delete option to LDAP updater, unit tests Message-ID: <4ACA46A8.4070509@redhat.com> This gives the updater the ability to delete entries and adds some unit test cases. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-272-updater.patch Type: application/mbox Size: 19110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Mon Oct 5 19:26:15 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 05 Oct 2009 13:26:15 -0600 Subject: [Freeipa-devel] [PATCH] 272 Add delete option to LDAP updater, unit tests In-Reply-To: <4ACA46A8.4070509@redhat.com> References: <4ACA46A8.4070509@redhat.com> Message-ID: <1254770776.4643.1.camel@jgd-dsk> ack. pushed to master. On Mon, 2009-10-05 at 15:19 -0400, Rob Crittenden wrote: > This gives the updater the ability to delete entries and adds some unit > test cases. > > rob From jderose at redhat.com Mon Oct 5 19:27:20 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 05 Oct 2009 13:27:20 -0600 Subject: [Freeipa-devel] [PATCH] 281 minor fix for updater In-Reply-To: <4AC607FF.3040702@redhat.com> References: <4AC601B6.1030803@redhat.com> <4AC607FF.3040702@redhat.com> Message-ID: <1254770840.4643.2.camel@jgd-dsk> ack too. pushed to master. On Fri, 2009-10-02 at 16:02 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > Robustness fix for ipa-ldap-updater to not blow up if no updates are set > > yet. > > > > rob > ack. > > Pavel From jderose at redhat.com Mon Oct 5 19:28:13 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 05 Oct 2009 13:28:13 -0600 Subject: [Freeipa-devel] [PATCH] 282 update the KDC aci In-Reply-To: <4AC60232.2060901@redhat.com> References: <4AC60232.2060901@redhat.com> Message-ID: <1254770893.4643.3.camel@jgd-dsk> On Fri, 2009-10-02 at 09:37 -0400, Rob Crittenden wrote: > The API protecting the kerberos master key was a bit broad, also > preventing adds and deletes to its subtree. I've relaxed that so I can > add password policy entries which must be stored under the realm entry. > > I also changed the formatting of the code. It was getting written to the > DS with leading and trailing \n causing DS to base64-encode the value > when displaying it. I'm hoping this wasn't done on purpose :-) > > rob ack. pushed to master. From jderose at redhat.com Mon Oct 5 19:29:39 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 05 Oct 2009 13:29:39 -0600 Subject: [Freeipa-devel] [PATCH] 283 allow no primary key in crud classes In-Reply-To: <4AC60885.4030805@redhat.com> References: <4AC6026D.2090509@redhat.com> <4AC60885.4030805@redhat.com> Message-ID: <1254770979.4643.4.camel@jgd-dsk> On Fri, 2009-10-02 at 16:04 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > The crud classes required a primary key to be set in order to work. I've > > relaxed that as the pwpolicy plugin has no primary key but I still want > > to take advantage of other aspects of it. > > > > rob > ack. > > LDAP* base classes already have this, but I guess it can't hurt to also have it > on a lower level. > > Pavel ack too. pushed to master. From jderose at redhat.com Mon Oct 5 19:37:27 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 05 Oct 2009 13:37:27 -0600 Subject: [Freeipa-devel] [PATCH] 284 per-group password policy In-Reply-To: <4AC6092B.8060800@redhat.com> References: <4AC602D7.6010903@redhat.com> <4AC6092B.8060800@redhat.com> Message-ID: <1254771447.4643.5.camel@jgd-dsk> On Fri, 2009-10-02 at 16:07 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > Add support for per-group kerberos password policy. > > > > This uses a Class of Service to based on group membership to determine > > which policy should apply. The design doc called for non-overlapping > > groups but we can support that with cospriority. > > > > You can pass a user to the pwpolicy plugin to see what policy applies to > > them to help debug overlapping issues if they come up. > > > > rob > ack. > > You could have taken my latest pwpolicy plugin as a base for this, but no big > deal - I'll merge the changes and post an updated version. :) > > Pavel ack. pushed to master. From rcritten at redhat.com Mon Oct 5 19:56:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2009 15:56:09 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add HBAC plugin and introduce GeneralizedTime parameter type. In-Reply-To: <4AC60E32.3010302@redhat.com> References: <4AC36E87.2080804@redhat.com> <4AC521EA.90204@redhat.com> <4AC60E32.3010302@redhat.com> Message-ID: <4ACA4F59.7050102@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Sumit noticed, that the HBAC plugin didn't make it into the tree and >>> the patch got lost in the depths of freeipa-devel. >>> >>> I reworked the plugin to meet the current standards and changed >>> GeneraliSedTime to GeneraliZedTime. For now, I put the new parameter >>> type into a separate file in ipalib/plugins/generalizedtime.py. When >>> it's tested enough, we're going to move it to ipalib/parameters.py. >>> >>> The patch also modifies bootstrap-template.ldif to create a cn=hbac >>> container after installing IPA. >>> >>> Pavel >> >> Shouldn't GeneralizedTime be in ipalib? >> >> I think GeneralizedTime should have some unit tests, same for hbac. >> >> rob > > Update: > - Now includes extensive unit test for HBAC plugin. > - GeneralizedTime was moved to ipalib/parameters. > - Minor updated to HBAC plugin, mostly esthetics. > > Pavel pushed to master. It would be nice if GeneralizedTime had its own unit tests but I don't want that to hold up this patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 5 19:59:54 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2009 15:59:54 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC60F4E.400@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> <4AC60F4E.400@redhat.com> Message-ID: <4ACA503A.4060107@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Zuna wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Pavel Z?na wrote: >>>>>>>> This is a series of patches that depends on patches: >>>>>>>> - Improve attribute printing in the CLI. >>>>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>>>> >>>>>>>> All plugins are converted to extend baseldap classes. This makes >>>>>>>> things more consistent, fixes some general bugs (with return >>>>>>>> values for example) and it also makes plugins easier to maintain >>>>>>>> (as it removes a lot of duplicate code). >>>>>>>> >>>>>>>> Because baseldap classes have features that enable us to define >>>>>>>> relationships between plugins, I thought it might be best to >>>>>>>> submit all of the conversions at once and have all the >>>>>>>> relationships fully defined. >>>>>>>> >>>>>>>> Affected plugins: >>>>>>>> config >>>>>>>> user >>>>>>>> host >>>>>>>> service >>>>>>>> group >>>>>>>> hostgroup >>>>>>>> netgroup >>>>>>>> rolegroup >>>>>>>> taskgroup >>>>>>>> pwpolicy >>>>>>>> >>>>>>>> There's also a patch that fixes all unit tests. >>>>>>>> >>>>>>>> Jenny, I included you to Cc, because the patch introduces a lot >>>>>>>> of changes to the UI (and you're probably not going to like me >>>>>>>> for this). >>>>>>>> >>>>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>>>> option. Without it, data from LDAP is formated and translated to >>>>>>>> human readable. For example: >>>>>>>> >>>>>>>> # ipa user-show admin --all >>>>>>>> ---------- >>>>>>>> user-show: >>>>>>>> ---------- >>>>>>>> User: admin >>>>>>>> user id: admin >>>>>>>> full name: Administrator >>>>>>>> last name: Administrator >>>>>>>> home directory: /home/admin >>>>>>>> login shell: /bin/bash >>>>>>>> uid number: 999 >>>>>>>> gid number: 1001 >>>>>>>> gecos: Administrator >>>>>>>> kerberos principal: admin at PZUNA >>>>>>>> last password change: 20090904122852Z >>>>>>>> password expiration: 20091203122852Z >>>>>>>> member of groups: admins >>>>>>>> >>>>>>>> # ipa user-show admin --all --raw >>>>>>>> ---------- >>>>>>>> user-show: >>>>>>>> ---------- >>>>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>>>> uid: admin >>>>>>>> cn: Administrator >>>>>>>> sn: Administrator >>>>>>>> homedirectory: /home/admin >>>>>>>> loginshell: /bin/bash >>>>>>>> uidnumber: 999 >>>>>>>> gidnumber: 1001 >>>>>>>> gecos: Administrator >>>>>>>> krbprincipalname: admin at PZUNA >>>>>>>> krblastpwdchange: 20090904122852Z >>>>>>>> krbpasswordexpiration: 20091203122852Z >>>>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>>>> objectclass: top >>>>>>>> objectclass: person >>>>>>>> objectclass: posixaccount >>>>>>>> objectclass: krbprincipalaux >>>>>>>> objectclass: inetuser >>>>>>>> >>>>>>>> Advantages: more user friendly, allows for easy localization, >>>>>>>> translation of DNs to primary keys (immediately usable as input >>>>>>>> to other plugin commands) >>>>>>>> >>>>>>>> I recommend, that you use the --raw flag for testing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>>>> >>>>>>>> It should be up-to-date with master and all my patches are >>>>>>>> applied there. I hope it makes reviewing them at least a bit >>>>>>>> easier. >>>>>>>> >>>>>>>> Pavel >>>>>>> >>>>>>> Why are you using a pre_callback() to define default values >>>>>>> instead of using default_from? It seems clearer to use that. >>>>>> You're probably referring to the user plugin, where gecos and >>>>>> krbprincipalname defaults are set inside pre_callback. It's a >>>>>> residue from some time ago when we didn't use autofill=True with >>>>>> default_from and it didn't have any effect on optional parameters. >>>>>> It's a small change, but I included an updated version of the >>>>>> patch with this email. >>>>> >>>>> Ok. I gather you've moved a lot of logic into the pre_callback >>>>> plugin to avoid overriding execute? One other goal we wanted was to >>>>> allow plugins to extend other plugins and this may be good step on >>>>> the way there. So for example, a user wants to be able to set some >>>>> extra objectclass, they could do it with a similar pre_callback >>>>> extension to the user plugin (once we do the plumbing for it, that >>>>> is). >>> Right. The goal is to have a common execute in the baseclass, that >>> does most of the dirty work and let the user/plugin author add the >>> specifics of his plugin in the pre/post callbacks. All the data >>> generated by the base (before calling python-ldap) is available for >>> modification in the pre-callbacks and all data coming out of >>> python-ldap is made available in the post-callback. >>> >>> And yes, the plugins could be almost endlessly extended this way. For >>> example, someone could do this: >>> >>> from ipalib.plugins.user import user_add >>> >>> class user_add_extended(user_add): >>> def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> # let the original user_add plugin do its job >>> super(user_add_extended, self).pre_callback( >>> ldap, dn, entry_attrs, *keys, **options) >>> # add an extra object class >>> entry_attrs['objectclass'].append('new_object_class') >>> return dn >>> >>> api.register(user_add_extended) >>> >>>>>>> This also duplicates some values in the attribute_names() >>>>>>> dictionary. I wonder if this can be either created from the >>>>>>> parameters or define a global set somewhere that covers all plugins. >>>>>> I know, but I couldn't find a better solution. I thought we could >>>>>> add something like a 'real_name' kwarg to params, but this has 2 >>>>>> main disadvantages: >>>>>> 1) it only makes sense with parameters that refer to an LDAP >>>>>> attribute >>>>>> 2) it doesn't work for attributes with no param counterparts >>>>>> >>>>>> The global set is a good idea as long as we consider only our own >>>>>> plugins. 3rd party plugins would have to modify this set to add >>>>>> their own attributes. Also, attributes might have a different >>>>>> meaning for different objects. They usually don't, but take 'cn' >>>>>> for example. We use it as an ID, name, full name (for users), etc. >>>>> >>>>> Ok, that's a good point. I'm wondering if its overkill to write a >>>>> registration system for this, something like: >>>>> >>>>> def set_label(attr, label, context='') >>>>> >>>>> def get_label(attr, context='') >>>>> >>>>> In this we'd store a dict that would be keyed on attr+context. Some >>>>> examples might be: >>>>> >>>>> set_label('uid', 'Login') >>>>> set_label('gn', 'First Name') >>>>> set_label('cn', 'Full Name', context='user') >>>>> set_label('cn', 'Group Name', context='group') >>>>> >>>>> The lookup would first look for a context-specific entry and fall >>>>> back to a non-context specific, something like: >>>>> >>>>> if attr+context in labeldict: return labeldict[attr+context] >>>>> elif attr in labeldict: return labeldict[attr] >>>>> else return "woop" >>>>> >>>>> Like I said, might be overkill ;-) >>>>> >>>>> But still, the alarms go off when we're putting the same things in >>>>> multiple places. >>>>> >>> Yeah, the registration system sounds like overkill all right. :D >>> >>> Seriously, I was thinking about several ways on how to resolve this >>> issue. Ideally, all information about attributes should be retrieved >>> from the schema. Unfortunately, it cannot be done. There's just very >>> little information in there. >>> >>> Another idea was to have an LDAPAttribute base class, that we would >>> extend for each attribute. We could then have a ldapattribute.py >>> module in ipalib/plugins with all the attributes we use defined >>> there. If 3rd parties require a new attribute, they just create their >>> own LDAPAttribute subclass in their plugins. I think that this would >>> be the best and cleanest approach. LDAPObjects would have a set of >>> LDAPAttribute references and do all attribute manipulation using >>> them. Also, attribute parameters could be automatically generated, so >>> they wouldn't mix with control parameters in takes_params (like >>> --all, --raw, --posix for groups, etc.). This is probably the way >>> we'll be going in the future, but there's still a few problems I have >>> to resolve before implementing it. >>> >>> By the way, my goal is to move all this LDAP infrastructure from the >>> plugin layer into the core library itself once it's mature (and >>> documented) enough. Probably not going to happen in v2, but we'll see >>> how it goes. >>> >>>>>>> In the user plugin 'ou' is in the default attributes. We don't >>>>>>> use this attribute. >>>>>> Since we don't use it, it's not going to get displayed anyway. >>>>>> >>>>>> All the values in attribute_names, default_attribute and >>>>>> attribute_order are subject to change. I set them to initial >>>>>> values I thought are acceptable, but I don't think I'm the right >>>>>> person to decide what's going to be there. Ideally, someone with >>>>>> more UI/text/user friendliness experience should review it >>>>>> (there's not programming knowledge required to change the values). >>>>> >>>>> Ok, this particular attribute brings up DIT issues which is why I >>>>> flagged it. >>>>> >>>>>>> I think that in general baseldap needs to be documented to >>>>>>> explain how things work. There is no explanation for >>>>>>> object_class_config, for example, that it defines the attribute >>>>>>> in cn=ipaConfig that contains the default list of objectclasses >>>>>>> for the object. >>>>>> Yeah, there's no documentation at this point, but I'm working on >>>>>> it as we "speak". >>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> One more thing, I reviewed your latest patches and they make >>>>>> change to host and service plugins. Your patches should be pushed >>>>>> first, because they are more complex and also more important, so I >>>>>> posted updated versions to the corresponding email threads on >>>>>> freeipa-devel. >>>>>> >>>>>> Pavel >>>>> >>>>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>>>> >>>> >>>> I've found another problem with the attribute map. I like your idea >>>> of breaking out memberof by different type but as it is now doesn't >>>> work, it only prints group membership. You'd have to parse the DN to >>>> distinguish between groups, taskgroups, etc. >>> >>> And that's exactly what I'm doing in >>> LDAPObject.convert_attribute_members. I mean the DN parsing. It just >>> doesn't work for users at the moment, because I forgot to add the >>> other types of groups in users attribute_members['memberof']. >>> >>> in ipalib/plugins/user.py: >>> >>> class user(LDAPObject): >>> # ... >>> attribute_members = { >>> # add other groups here >>> # example 'memberof': ['group', 'taskgroup'] >>> 'memberof': ['group'] >>> } >>> # ... >>> >>> try: >>> >>> ipa user-add test --first=first --last=last >>> ipa taskgroup-add tasktest --desc=desc >>> ipa taskgroup-add-member tasktest --users=test >>> ipa user-show test --all >>> >>> Should work. >>> >>> Note: Just noticed it won't work for netgroups, because I forgot to >>> override LDAPObject.get_primary_key_from_dn in the netgroup class. >>> Normally get_primary_key_from_dn just returns the value of RDN, but >>> for netgroups we have to do a search to retrieve the primary key. >>> >>> class netgroup(LDAPObject): >>> # ... >>> def get_primary_key_from_dn(self, dn): >>> (dn, entry_attrs) = self.backend.get_entry( >>> dn, [self.primary_key.name] >>> ) >>> return entry_attrs.get(self.primary_key.name, '') >>> # ... >>> >>>> I think for the short-term we can make a note to do this and just >>>> print all memberships so we can get this committed. I'm still not a >>>> fan of the attribute_names within each plugin though, I need more >>>> convincing. >>>> >>>> rob >>>> >>> >>> By the way, I'm going on vacation next week. So, I think we should >>> wait anyway before committing this. >>> >>> Pavel >>> >> I'm sending an updated version of all the patches. They should apply >> on the current master. I think they should now address most of your >> concerns and I also fixed some bugs I found on my own. >> >> Pavel > > Some are good to go, others need some more work: > > 0001-config: ack > > 0002-group: ack > > 0003-hostgroups: nack, hostgroups-show doesn't show members by default. > > 0004-netgroup: nack, fails a ton of unit tests > > 0005-rolgroup: nack, rolegroup-find doesn't work (try serviceadmin). > rolegroup-show doesn't include members by default. > > 0006-taskgroup: nack, taskgroup-find doesn't work (try ipa addhosts) > taskgroup-show doesn't include members by default. > > 0007-tests: ack though we should do some non-raw tests as well IMHO. In > test-hostgroup looks like there is some leftover debug output that > should be removed before committing. > > 0008-pwpolicy: nack, have another patch floating around that covers most > of this. I'll try to incorporate some of your ideas into my patch once > committed. > > 0009 missing? > > 0010-service: ack, but we should try to avoid shadowing built-in names > (filter) > > 0011-user: ack but changes like this seem to make it less readable: > > - textui.print_dashed('Unlocked user "%s".' % uid) > + textui.print_dashed('Unlocked user "%s".' % keys[-1]) > > I realize that *keys is more generic than specifying one argument but > there is no documentation saying was keys means. > > Some general observations that don't necessarily need to be addressed > here but do need to be done: > > - adding/removing member failures should return non-zero return code (so > you can test $? on cmd-line) > - add/remove-member should probably prompt for things if not provided on > command-line (and allow empty values). Right now if you do an add-member > it prompts for group to modify and then submits an empty request > > Let me know if it is safe to push these patches individually. > > rob Pushed the acked patches to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 5 20:01:26 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2009 16:01:26 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC60EAB.1080304@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> <4AC60EAB.1080304@redhat.com> Message-ID: <4ACA5096.3000101@redhat.com> Pavel Zuna wrote: > Pavel Zuna wrote: >> Pavel Z?na wrote: >>> Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Zuna wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Pavel Z?na wrote: >>>>>>>> This is a series of patches that depends on patches: >>>>>>>> - Improve attribute printing in the CLI. >>>>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>>>> >>>>>>>> All plugins are converted to extend baseldap classes. This makes >>>>>>>> things more consistent, fixes some general bugs (with return >>>>>>>> values for example) and it also makes plugins easier to maintain >>>>>>>> (as it removes a lot of duplicate code). >>>>>>>> >>>>>>>> Because baseldap classes have features that enable us to define >>>>>>>> relationships between plugins, I thought it might be best to >>>>>>>> submit all of the conversions at once and have all the >>>>>>>> relationships fully defined. >>>>>>>> >>>>>>>> Affected plugins: >>>>>>>> config >>>>>>>> user >>>>>>>> host >>>>>>>> service >>>>>>>> group >>>>>>>> hostgroup >>>>>>>> netgroup >>>>>>>> rolegroup >>>>>>>> taskgroup >>>>>>>> pwpolicy >>>>>>>> >>>>>>>> There's also a patch that fixes all unit tests. >>>>>>>> >>>>>>>> Jenny, I included you to Cc, because the patch introduces a lot >>>>>>>> of changes to the UI (and you're probably not going to like me >>>>>>>> for this). >>>>>>>> >>>>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>>>> option. Without it, data from LDAP is formated and translated to >>>>>>>> human readable. For example: >>>>>>>> >>>>>>>> # ipa user-show admin --all >>>>>>>> ---------- >>>>>>>> user-show: >>>>>>>> ---------- >>>>>>>> User: admin >>>>>>>> user id: admin >>>>>>>> full name: Administrator >>>>>>>> last name: Administrator >>>>>>>> home directory: /home/admin >>>>>>>> login shell: /bin/bash >>>>>>>> uid number: 999 >>>>>>>> gid number: 1001 >>>>>>>> gecos: Administrator >>>>>>>> kerberos principal: admin at PZUNA >>>>>>>> last password change: 20090904122852Z >>>>>>>> password expiration: 20091203122852Z >>>>>>>> member of groups: admins >>>>>>>> >>>>>>>> # ipa user-show admin --all --raw >>>>>>>> ---------- >>>>>>>> user-show: >>>>>>>> ---------- >>>>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>>>> uid: admin >>>>>>>> cn: Administrator >>>>>>>> sn: Administrator >>>>>>>> homedirectory: /home/admin >>>>>>>> loginshell: /bin/bash >>>>>>>> uidnumber: 999 >>>>>>>> gidnumber: 1001 >>>>>>>> gecos: Administrator >>>>>>>> krbprincipalname: admin at PZUNA >>>>>>>> krblastpwdchange: 20090904122852Z >>>>>>>> krbpasswordexpiration: 20091203122852Z >>>>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>>>> objectclass: top >>>>>>>> objectclass: person >>>>>>>> objectclass: posixaccount >>>>>>>> objectclass: krbprincipalaux >>>>>>>> objectclass: inetuser >>>>>>>> >>>>>>>> Advantages: more user friendly, allows for easy localization, >>>>>>>> translation of DNs to primary keys (immediately usable as input >>>>>>>> to other plugin commands) >>>>>>>> >>>>>>>> I recommend, that you use the --raw flag for testing. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>>>> >>>>>>>> It should be up-to-date with master and all my patches are >>>>>>>> applied there. I hope it makes reviewing them at least a bit >>>>>>>> easier. >>>>>>>> >>>>>>>> Pavel >>>>>>> >>>>>>> Why are you using a pre_callback() to define default values >>>>>>> instead of using default_from? It seems clearer to use that. >>>>>> You're probably referring to the user plugin, where gecos and >>>>>> krbprincipalname defaults are set inside pre_callback. It's a >>>>>> residue from some time ago when we didn't use autofill=True with >>>>>> default_from and it didn't have any effect on optional parameters. >>>>>> It's a small change, but I included an updated version of the >>>>>> patch with this email. >>>>> >>>>> Ok. I gather you've moved a lot of logic into the pre_callback >>>>> plugin to avoid overriding execute? One other goal we wanted was to >>>>> allow plugins to extend other plugins and this may be good step on >>>>> the way there. So for example, a user wants to be able to set some >>>>> extra objectclass, they could do it with a similar pre_callback >>>>> extension to the user plugin (once we do the plumbing for it, that >>>>> is). >>> Right. The goal is to have a common execute in the baseclass, that >>> does most of the dirty work and let the user/plugin author add the >>> specifics of his plugin in the pre/post callbacks. All the data >>> generated by the base (before calling python-ldap) is available for >>> modification in the pre-callbacks and all data coming out of >>> python-ldap is made available in the post-callback. >>> >>> And yes, the plugins could be almost endlessly extended this way. For >>> example, someone could do this: >>> >>> from ipalib.plugins.user import user_add >>> >>> class user_add_extended(user_add): >>> def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): >>> # let the original user_add plugin do its job >>> super(user_add_extended, self).pre_callback( >>> ldap, dn, entry_attrs, *keys, **options) >>> # add an extra object class >>> entry_attrs['objectclass'].append('new_object_class') >>> return dn >>> >>> api.register(user_add_extended) >>> >>>>>>> This also duplicates some values in the attribute_names() >>>>>>> dictionary. I wonder if this can be either created from the >>>>>>> parameters or define a global set somewhere that covers all plugins. >>>>>> I know, but I couldn't find a better solution. I thought we could >>>>>> add something like a 'real_name' kwarg to params, but this has 2 >>>>>> main disadvantages: >>>>>> 1) it only makes sense with parameters that refer to an LDAP >>>>>> attribute >>>>>> 2) it doesn't work for attributes with no param counterparts >>>>>> >>>>>> The global set is a good idea as long as we consider only our own >>>>>> plugins. 3rd party plugins would have to modify this set to add >>>>>> their own attributes. Also, attributes might have a different >>>>>> meaning for different objects. They usually don't, but take 'cn' >>>>>> for example. We use it as an ID, name, full name (for users), etc. >>>>> >>>>> Ok, that's a good point. I'm wondering if its overkill to write a >>>>> registration system for this, something like: >>>>> >>>>> def set_label(attr, label, context='') >>>>> >>>>> def get_label(attr, context='') >>>>> >>>>> In this we'd store a dict that would be keyed on attr+context. Some >>>>> examples might be: >>>>> >>>>> set_label('uid', 'Login') >>>>> set_label('gn', 'First Name') >>>>> set_label('cn', 'Full Name', context='user') >>>>> set_label('cn', 'Group Name', context='group') >>>>> >>>>> The lookup would first look for a context-specific entry and fall >>>>> back to a non-context specific, something like: >>>>> >>>>> if attr+context in labeldict: return labeldict[attr+context] >>>>> elif attr in labeldict: return labeldict[attr] >>>>> else return "woop" >>>>> >>>>> Like I said, might be overkill ;-) >>>>> >>>>> But still, the alarms go off when we're putting the same things in >>>>> multiple places. >>>>> >>> Yeah, the registration system sounds like overkill all right. :D >>> >>> Seriously, I was thinking about several ways on how to resolve this >>> issue. Ideally, all information about attributes should be retrieved >>> from the schema. Unfortunately, it cannot be done. There's just very >>> little information in there. >>> >>> Another idea was to have an LDAPAttribute base class, that we would >>> extend for each attribute. We could then have a ldapattribute.py >>> module in ipalib/plugins with all the attributes we use defined >>> there. If 3rd parties require a new attribute, they just create their >>> own LDAPAttribute subclass in their plugins. I think that this would >>> be the best and cleanest approach. LDAPObjects would have a set of >>> LDAPAttribute references and do all attribute manipulation using >>> them. Also, attribute parameters could be automatically generated, so >>> they wouldn't mix with control parameters in takes_params (like >>> --all, --raw, --posix for groups, etc.). This is probably the way >>> we'll be going in the future, but there's still a few problems I have >>> to resolve before implementing it. >>> >>> By the way, my goal is to move all this LDAP infrastructure from the >>> plugin layer into the core library itself once it's mature (and >>> documented) enough. Probably not going to happen in v2, but we'll see >>> how it goes. >>> >>>>>>> In the user plugin 'ou' is in the default attributes. We don't >>>>>>> use this attribute. >>>>>> Since we don't use it, it's not going to get displayed anyway. >>>>>> >>>>>> All the values in attribute_names, default_attribute and >>>>>> attribute_order are subject to change. I set them to initial >>>>>> values I thought are acceptable, but I don't think I'm the right >>>>>> person to decide what's going to be there. Ideally, someone with >>>>>> more UI/text/user friendliness experience should review it >>>>>> (there's not programming knowledge required to change the values). >>>>> >>>>> Ok, this particular attribute brings up DIT issues which is why I >>>>> flagged it. >>>>> >>>>>>> I think that in general baseldap needs to be documented to >>>>>>> explain how things work. There is no explanation for >>>>>>> object_class_config, for example, that it defines the attribute >>>>>>> in cn=ipaConfig that contains the default list of objectclasses >>>>>>> for the object. >>>>>> Yeah, there's no documentation at this point, but I'm working on >>>>>> it as we "speak". >>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> One more thing, I reviewed your latest patches and they make >>>>>> change to host and service plugins. Your patches should be pushed >>>>>> first, because they are more complex and also more important, so I >>>>>> posted updated versions to the corresponding email threads on >>>>>> freeipa-devel. >>>>>> >>>>>> Pavel >>>>> >>>>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>>>> >>>> >>>> I've found another problem with the attribute map. I like your idea >>>> of breaking out memberof by different type but as it is now doesn't >>>> work, it only prints group membership. You'd have to parse the DN to >>>> distinguish between groups, taskgroups, etc. >>> >>> And that's exactly what I'm doing in >>> LDAPObject.convert_attribute_members. I mean the DN parsing. It just >>> doesn't work for users at the moment, because I forgot to add the >>> other types of groups in users attribute_members['memberof']. >>> >>> in ipalib/plugins/user.py: >>> >>> class user(LDAPObject): >>> # ... >>> attribute_members = { >>> # add other groups here >>> # example 'memberof': ['group', 'taskgroup'] >>> 'memberof': ['group'] >>> } >>> # ... >>> >>> try: >>> >>> ipa user-add test --first=first --last=last >>> ipa taskgroup-add tasktest --desc=desc >>> ipa taskgroup-add-member tasktest --users=test >>> ipa user-show test --all >>> >>> Should work. >>> >>> Note: Just noticed it won't work for netgroups, because I forgot to >>> override LDAPObject.get_primary_key_from_dn in the netgroup class. >>> Normally get_primary_key_from_dn just returns the value of RDN, but >>> for netgroups we have to do a search to retrieve the primary key. >>> >>> class netgroup(LDAPObject): >>> # ... >>> def get_primary_key_from_dn(self, dn): >>> (dn, entry_attrs) = self.backend.get_entry( >>> dn, [self.primary_key.name] >>> ) >>> return entry_attrs.get(self.primary_key.name, '') >>> # ... >>> >>>> I think for the short-term we can make a note to do this and just >>>> print all memberships so we can get this committed. I'm still not a >>>> fan of the attribute_names within each plugin though, I need more >>>> convincing. >>>> >>>> rob >>>> >>> >>> By the way, I'm going on vacation next week. So, I think we should >>> wait anyway before committing this. >>> >>> Pavel >>> >> I'm sending an updated version of all the patches. They should apply >> on the current master. I think they should now address most of your >> concerns and I also fixed some bugs I found on my own. >> >> Pavel > I found a bug in the netgroup plugin, here's an update. > > Also, the pwpolicy plugin patch needs update to included your latest > changes. Should be done by monday. > > Pavel ack, pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 5 20:04:29 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Oct 2009 16:04:29 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AC62409.2020703@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> <4AC36F19.2040703@redhat.com> <4AC60F4E.400@redhat.com> <4AC62388.9040805@redhat.com> <4AC62409.2020703@redhat.com> Message-ID: <4ACA514D.6010908@redhat.com> Pavel Zuna wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>>> I'm sending an updated version of all the patches. They should apply >>>> on the current master. I think they should now address most of your >>>> concerns and I also fixed some bugs I found on my own. >>>> >>>> Pavel >>> >>> Some are good to go, others need some more work: >>> >>> 0001-config: ack >>> >>> 0002-group: ack >>> >>> 0003-hostgroups: nack, hostgroups-show doesn't show members by default. >> Fixed in attached patch. >> >>> 0004-netgroup: nack, fails a ton of unit tests >> Fixed in patch I sent previously today. >> >>> 0005-rolgroup: nack, rolegroup-find doesn't work (try serviceadmin). >>> rolegroup-show doesn't include members by default. >>> >>> 0006-taskgroup: nack, taskgroup-find doesn't work (try ipa addhosts) >>> taskgroup-show doesn't include members by default. >> Both "member thing" fixed, but *-find seems to work for me. Can you >> post the exact commands that fail? >> >>> 0007-tests: ack though we should do some non-raw tests as well IMHO. >>> In test-hostgroup looks like there is some leftover debug output that >>> should be removed before committing. >> Removed the leftover debug output in attached patch. >> >>> 0008-pwpolicy: nack, have another patch floating around that covers >>> most of this. I'll try to incorporate some of your ideas into my >>> patch once committed. >> Ok. >> >>> 0009 missing? >> Not missing, just wrong numbering. There was an unrelated patch that >> got in between the plugin patches. >> >>> 0010-service: ack, but we should try to avoid shadowing built-in >>> names (filter) >> Sometimes it might be justified, but in this case we really should >> avoid it, because it's actually in the base class and what if someone >> wants to use python's filter function inside the callback? (They would >> have to rename the param or do some hacking around.) It doesn't hurt >> anything for now, but this will have to be patched at several places - >> I'll post a patch on Monday. >> >>> 0011-user: ack but changes like this seem to make it less readable: >>> >>> - textui.print_dashed('Unlocked user "%s".' % uid) >>> + textui.print_dashed('Unlocked user "%s".' % keys[-1]) >>> >>> I realize that *keys is more generic than specifying one argument but >>> there is no documentation saying was keys means. >> I'm really slow at documenting things, but it's in the works. >> >>> Some general observations that don't necessarily need to be addressed >>> here but do need to be done: >>> >>> - adding/removing member failures should return non-zero return code >>> (so you can test $? on cmd-line) >>> - add/remove-member should probably prompt for things if not provided >>> on command-line (and allow empty values). Right now if you do an >>> add-member it prompts for group to modify and then submits an empty >>> request >> Ok, I'll try to address these issues as soon as possible. >> >>> Let me know if it is safe to push these patches individually. >> The user and *group plugins should be pushed at once. Everything else >> should be safe individually. >> >>> rob >>> >> >> Pavel > > Awwww. Forgot to attach the patches... > > Pavel Pushed patch 0001 and 0002. Patch 0003 does not apply rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Tue Oct 6 11:52:28 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 06 Oct 2009 13:52:28 +0200 Subject: [Freeipa-devel] Re: check your patches In-Reply-To: <4ACA5279.5010203@redhat.com> References: <4ACA5279.5010203@redhat.com> Message-ID: <4ACB2F7C.4040804@redhat.com> Rob Crittenden wrote: > Pavel, I pushed a slew of your patches today but there were so many > patches flying around that e-mail thread I may have missed something > (and the tests patch doesn't apply). > > Can you check your patches to make sure I've applied everything? > > git has a kinda neat feature so you can compare your tree with the > "master": git diff origin/master. > > rob Yeah, it was a real mess. Only the taskgroup patch is missing now - I attached it to this e-mail, so you don't have to go through the giant thread again. It seems the first tests patch was applied already and that's why the second one won't apply. I did some rebasing and attached a new patch, although it only removes some debugging output. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-taskgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 7596 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-unit-tests-for-plugins-using-baseldap-classes.patch Type: application/mbox Size: 986 bytes Desc: not available URL: From pzuna at redhat.com Tue Oct 6 13:56:29 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 06 Oct 2009 15:56:29 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in HBAC and netgroup plugin get_primary_key_from_dn methods. Message-ID: <4ACB4C8D.7020504@redhat.com> The method was returning tuples instead of strings in both plugins causing a mess in other plugins, when displaying netgroup/HBAC information. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-in-HBAC-and-netgroup-plugin-get_primary_key_.patch Type: application/mbox Size: 1449 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 7 14:00:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2009 10:00:46 -0400 Subject: [Freeipa-devel] Re: check your patches In-Reply-To: <4ACB2F7C.4040804@redhat.com> References: <4ACA5279.5010203@redhat.com> <4ACB2F7C.4040804@redhat.com> Message-ID: <4ACC9F0E.5010406@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel, I pushed a slew of your patches today but there were so many >> patches flying around that e-mail thread I may have missed something >> (and the tests patch doesn't apply). >> >> Can you check your patches to make sure I've applied everything? >> >> git has a kinda neat feature so you can compare your tree with the >> "master": git diff origin/master. >> >> rob > Yeah, it was a real mess. Only the taskgroup patch is missing now - I > attached it to this e-mail, so you don't have to go through the giant > thread again. > > It seems the first tests patch was applied already and that's why the > second one won't apply. I did some rebasing and attached a new patch, > although it only removes some debugging output. > > Pavel Ack and pushed both. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 7 14:03:47 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2009 10:03:47 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in HBAC and netgroup plugin get_primary_key_from_dn methods. In-Reply-To: <4ACB4C8D.7020504@redhat.com> References: <4ACB4C8D.7020504@redhat.com> Message-ID: <4ACC9FC3.6040601@redhat.com> Pavel Zuna wrote: > The method was returning tuples instead of strings in both plugins > causing a mess in other plugins, when displaying netgroup/HBAC information. > > Pavel Assuming that the primary key doesn't exist, what meaning does returning '' have? For these 2 plugins shouldn't it always have a primary key? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 7 14:57:56 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2009 10:57:56 -0400 Subject: [Freeipa-devel] [PATCH] 286 cache installer questions Message-ID: <4ACCAC74.1080204@redhat.com> Installing a CA that is signed by another CA is a 2-step process. The first step is to generate a CSR for the CA and the second step is to install the certificate issued by the external CA. To avoid asking questions over and over (and potentially getting different answers) the answers are cached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-286-cache.patch Type: application/mbox Size: 5138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 7 20:51:07 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Oct 2009 16:51:07 -0400 Subject: [Freeipa-devel] [PATCH] 287 improve ipa-join Message-ID: <4ACCFF3B.8070400@redhat.com> I ran ipa-join on some not properly-configured clients and found a bunch of corner cases that are fixed here. This improves debugging and standard output considerably. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-287-join.patch Type: application/mbox Size: 4214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Wed Oct 7 23:48:52 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Oct 2009 19:48:52 -0400 Subject: [Freeipa-devel] validating return values in XML-RPC Message-ID: <4ACD28E4.1080108@redhat.com> Sorry to harp on this :-) But the more I work with the XML-RPC interface from non-python code the more I think we've got a problem. The first problem is what was discussed in the team meeting. You don't know what a function is going to return and nothing enforces the consistency of return values. Jason has done an awesome job of enforcing the consistency of input arguments, but that's only half the battle. What gets returned is purely a function of what the plugin author happens to stuff into the plugin's return statement. There is no enforcement of how many values get returned, what their types are, what is optional, what is mandatory, etc. In other words everything which is enforced on the input side of the call is absent on the output side, it should be obvious why this is a problem, especially for any callers of XML-RPC which are *not* in the python plugin framework. The second problem I've run into with return values is especially pernicious because the plugin framework is hiding a very fundamental and apparently common error. Here is the issue: * We've adopted the convention that *all* strings will be unicode objects. * str objects will be treated as binary data * Python will in many instances freely convert between str objects and unicode objects. * If a plugin wants to return a string it *must* return a unicode object. If the plugin mistakenly returns a str object (a very very easy mistake to make) then what gets returned through XML-RPC is a *binary* base64 encoded blob, not an XML-RPC *string* value! The above is so critical let me repeat it: FAILING TO ASSURE A RETURNED STRING IS UNICODE AND NOT STR RESULTS IN BINARY BLOBS ON THE RECEIVING END INSTEAD OF A STRING. * However, the python framework *hides* the error on the return side because it decodes the base64 binary value back into a str object. Because str objects and unicode objects are often interchangeable the python code receiving the return value thinks it sees the right result even though it's not. If we're going to have other clients of the XML-RPC interface then that client *must* know what the return values are and what their type is. It can't (or shouldn't) do things like: * I was expecting a string but I got a binary blob so that must have been a mistake so I'll treat the binary blob as a string and hope it's correct. -or- * I was expecting an integer but I actually got a string (yes there are plugins which do this), so I'll try to read an integer value out of the string. But wait, suppose the plugin author who returned the integer as a string forget to assure that the string representing the integer was a unicode object and not a str object, then the receiver really has to start guessing because he's gotten back a binary blob. Is that binary blob a 2's compliment representation of a signed integer, is it unsigned integer, or is the binary blob a string representation of the integer? Clearly this doesn't work. Now let's suppose another common scenario. The plugin author discovers he has mistakenly returned a str object when it should have been a unicode object and corrects his mistake, seemingly innocent because everything continues to work (but only in python). We have a non-python client of the XML-RPC interface who has corrected for the mistake by expecting binary data for the string, now that client fails! Or let's say the plugin was correctly returning a unicode object but some seemingly innocent change is made and the value ends up being a str object instead. Once again the python code continues to work correctly but the non-python code fails. So how easy it for Python programmers to make the mistake between str and unicode? *VERY VERY EASY!* In fact it's so easy even Jason's documentation and examples sometimes make the mistake. It's especially easy mistake to make when calling another function because the vast majority of existing Python libraries return str objects for strings. If we don't validate the return values from the plugin's I don't see how we'll ever have non-python XML-RPC clients which are robust. I'm happy to work with Jason to get the return validation implemented. I now know the insides of the plugin rpc mechanism in gory detail :-) I don't think we should postpone this, I think there are all sorts of errors lurking in the code, or will get introduced in the code in the future. For robustness sake it's better to fix this sooner rather than later IMHO. Of course the other option is to do away with the rule that str objects will get converted into binary blobs in XML-RPC. I think there is a good argument for treating both str objects and unicode objects as strings in XML-RPC. How often do we really need to pass binary data back in XLM-RPC? I'm thinking it's not very often. For those limited cases wouldn't it be better to require the plugin to return a Binary object instead of a str?. This has the advantage that's it's explicit and removes the dangerous practice of automatic conversion of conventional python strings into binary blobs when 99% of the time that's not the intention of the programmer. BTW, removing the automatic conversion of str to binary is a simple one line change which would have a huge impact on robustness without any loss of functionality. However that still does not address the issue of return value validation, but it does remove the single most common error we have with return values at the moment. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Oct 8 00:00:49 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 Oct 2009 20:00:49 -0400 Subject: [Freeipa-devel] validating return values in XML-RPC In-Reply-To: <4ACD28E4.1080108@redhat.com> References: <4ACD28E4.1080108@redhat.com> Message-ID: <4ACD2BB1.1010501@redhat.com> John Dennis wrote: > Sorry to harp on this :-) But the more I work with the XML-RPC > interface from non-python code the more I think we've got a problem. > > The first problem is what was discussed in the team meeting. You don't > know what a function is going to return and nothing enforces the > consistency of return values. Jason has done an awesome job of > enforcing the consistency of input arguments, but that's only half the > battle. What gets returned is purely a function of what the plugin > author happens to stuff into the plugin's return statement. There is > no enforcement of how many values get returned, what their types are, > what is optional, what is mandatory, etc. In other words everything > which is enforced on the input side of the call is absent on the > output side, it should be obvious why this is a problem, especially > for any callers of XML-RPC which are *not* in the python plugin > framework. > > The second problem I've run into with return values is especially > pernicious because the plugin framework is hiding a very fundamental > and apparently common error. Here is the issue: > > * We've adopted the convention that *all* strings will be unicode > objects. > > * str objects will be treated as binary data > > * Python will in many instances freely convert between str objects and > unicode objects. > > * If a plugin wants to return a string it *must* return a unicode > object. If the plugin mistakenly returns a str object (a very very > easy mistake to make) then what gets returned through XML-RPC is a > *binary* base64 encoded blob, not an XML-RPC *string* value! > > The above is so critical let me repeat it: FAILING TO ASSURE A > RETURNED STRING IS UNICODE AND NOT STR RESULTS IN BINARY BLOBS ON THE > RECEIVING END INSTEAD OF A STRING. > > * However, the python framework *hides* the error on the return side > because it decodes the base64 binary value back into a str object. > Because str objects and unicode objects are often interchangeable the > python code receiving the return value thinks it sees the right result > even though it's not. > > If we're going to have other clients of the XML-RPC interface then > that client *must* know what the return values are and what their type > is. It can't (or shouldn't) do things like: > > * I was expecting a string but I got a binary blob so that must have > been a mistake so I'll treat the binary blob as a string and hope it's > correct. > > -or- > > * I was expecting an integer but I actually got a string (yes there > are plugins which do this), so I'll try to read an integer value out > of the string. But wait, suppose the plugin author who returned the > integer as a string forget to assure that the string representing the > integer was a unicode object and not a str object, then the receiver > really has to start guessing because he's gotten back a binary blob. > Is that binary blob a 2's compliment representation of a signed > integer, is it unsigned integer, or is the binary blob a string > representation of the integer? Clearly this doesn't work. > > Now let's suppose another common scenario. The plugin author discovers > he has mistakenly returned a str object when it should have been a > unicode object and corrects his mistake, seemingly innocent because > everything continues to work (but only in python). We have a > non-python client of the XML-RPC interface who has corrected for the > mistake by expecting binary data for the string, now that client > fails! Or let's say the plugin was correctly returning a unicode > object but some seemingly innocent change is made and the value ends > up being a str object instead. Once again the python code continues to > work correctly but the non-python code fails. > > So how easy it for Python programmers to make the mistake between str > and unicode? *VERY VERY EASY!* In fact it's so easy even Jason's > documentation and examples sometimes make the mistake. It's especially > easy mistake to make when calling another function because the vast > majority of existing Python libraries return str objects for strings. > > If we don't validate the return values from the plugin's I don't see > how we'll ever have non-python XML-RPC clients which are robust. > > I'm happy to work with Jason to get the return validation implemented. > I now know the insides of the plugin rpc mechanism in gory detail :-) > > I don't think we should postpone this, I think there are all sorts of > errors lurking in the code, or will get introduced in the code in the > future. For robustness sake it's better to fix this sooner rather than > later IMHO. > > Of course the other option is to do away with the rule that str > objects will get converted into binary blobs in XML-RPC. I think there > is a good argument for treating both str objects and unicode objects > as strings in XML-RPC. How often do we really need to pass binary data > back in XLM-RPC? I'm thinking it's not very often. For those limited > cases wouldn't it be better to require the plugin to return a Binary > object instead of a str?. This has the advantage that's it's explicit > and removes the dangerous practice of automatic conversion of > conventional python strings into binary blobs when 99% of the time > that's not the intention of the programmer. > > BTW, removing the automatic conversion of str to binary is a simple > one line change which would have a huge impact on robustness without > any loss of functionality. However that still does not address the > issue of return value validation, but it does remove the single most > common error we have with return values at the moment. > DO IT! :-) -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pzuna at redhat.com Thu Oct 8 10:59:04 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 08 Oct 2009 12:59:04 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in group plugin. Was using wrong variable for attributes. Message-ID: <4ACDC5F8.1010704@redhat.com> Fixes bug #527537: https://bugzilla.redhat.com/show_bug.cgi?id=527537 Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-in-group-plugin.-Was-using-wrong-variable-fo.patch Type: application/mbox Size: 840 bytes Desc: not available URL: From pzuna at redhat.com Thu Oct 8 11:05:14 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 08 Oct 2009 13:05:14 +0200 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in HBAC and netgroup plugin get_primary_key_from_dn methods. In-Reply-To: <4ACC9FC3.6040601@redhat.com> References: <4ACB4C8D.7020504@redhat.com> <4ACC9FC3.6040601@redhat.com> Message-ID: <4ACDC76A.4030200@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> The method was returning tuples instead of strings in both plugins >> causing a mess in other plugins, when displaying netgroup/HBAC >> information. >> >> Pavel > > Assuming that the primary key doesn't exist, what meaning does returning > '' have? For these 2 plugins shouldn't it always have a primary key? > > rob In most plugins, retrieving the primary key from DN is easy, because it is part of the DN (RDN attribute == primary key attribute). With netgroups and HBAC it is a bit more complicated, because the RDN attribute is 'ipauniqueid' and the primary key is 'cn' - we have to do a search to retrieve it. If the search fails for some reason (someone deletes the entry in parallel for example), we return an empty string, which is fail-safe. Pavel From rcritten at redhat.com Thu Oct 8 14:10:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2009 10:10:15 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in group plugin. Was using wrong variable for attributes. In-Reply-To: <4ACDC5F8.1010704@redhat.com> References: <4ACDC5F8.1010704@redhat.com> Message-ID: <4ACDF2C7.1090302@redhat.com> Pavel Zuna wrote: > Fixes bug #527537: https://bugzilla.redhat.com/show_bug.cgi?id=527537 > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Oct 8 14:11:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2009 10:11:50 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in HBAC and netgroup plugin get_primary_key_from_dn methods. In-Reply-To: <4ACDC76A.4030200@redhat.com> References: <4ACB4C8D.7020504@redhat.com> <4ACC9FC3.6040601@redhat.com> <4ACDC76A.4030200@redhat.com> Message-ID: <4ACDF326.7010506@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> The method was returning tuples instead of strings in both plugins >>> causing a mess in other plugins, when displaying netgroup/HBAC >>> information. >>> >>> Pavel >> >> Assuming that the primary key doesn't exist, what meaning does >> returning '' have? For these 2 plugins shouldn't it always have a >> primary key? >> >> rob > In most plugins, retrieving the primary key from DN is easy, because it > is part of the DN (RDN attribute == primary key attribute). With > netgroups and HBAC it is a bit more complicated, because the RDN > attribute is 'ipauniqueid' and the primary key is 'cn' - we have to do a > search to retrieve it. If the search fails for some reason (someone > deletes the entry in parallel for example), we return an empty string, > which is fail-safe. > > Pavel Ok, pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Oct 8 15:11:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2009 11:11:22 -0400 Subject: [Freeipa-devel] [PATCH] 288 man page for ipa-join Message-ID: <4ACE011A.8090205@redhat.com> Add a man page for the new ipa-join command. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-288-man.patch Type: application/mbox Size: 3736 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Oct 8 20:49:32 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2009 16:49:32 -0400 Subject: [Freeipa-devel] [PATCH] 289 fix host admin acis Message-ID: <4ACE505C.6010208@redhat.com> It appears I missed a couple of ACI's when we changed the DN format of hosts. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-289-aci.patch Type: application/mbox Size: 1370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Oct 8 21:11:12 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2009 17:11:12 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin Message-ID: <4ACE5570.2070505@redhat.com> I missed this file when I did the last CA patch :-( This sets the cert_t context on some files needed for the selfsign plugin to work. It needs to let httpd write the serial number file and open the NSS database. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-290-selinux.patch Type: application/mbox Size: 866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Thu Oct 8 21:18:14 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Oct 2009 17:18:14 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACE5570.2070505@redhat.com> References: <4ACE5570.2070505@redhat.com> Message-ID: <4ACE5716.5010200@redhat.com> On 10/08/2009 05:11 PM, Rob Crittenden wrote: > I missed this file when I did the last CA patch :-( > > This sets the cert_t context on some files needed for the selfsign > plugin to work. It needs to let httpd write the serial number file and > open the NSS database. Thanks Rob. BTW, I was going to add a try/except block around that code in selfsign and return a non-zero status if it fails. Do we have predefined status codes I should be using? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Oct 8 21:22:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Oct 2009 17:22:41 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACE5716.5010200@redhat.com> References: <4ACE5570.2070505@redhat.com> <4ACE5716.5010200@redhat.com> Message-ID: <4ACE5821.3040509@redhat.com> John Dennis wrote: > On 10/08/2009 05:11 PM, Rob Crittenden wrote: >> I missed this file when I did the last CA patch :-( >> >> This sets the cert_t context on some files needed for the selfsign >> plugin to work. It needs to let httpd write the serial number file and >> open the NSS database. > > Thanks Rob. BTW, I was going to add a try/except block around that code > in selfsign and return a non-zero status if it fails. Do we have > predefined status codes I should be using? > I'm assuming you mean around the certs.next_serial() call? Not really sure. This is really a "server blew up" sort of error, I'm not sure what the best thing to return to the client is in this case. I think something that says "the server is hosed, you can't fix it from there" sort of error would be nice. AFAIK we don't currently define such a beastie. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Thu Oct 8 21:59:54 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Oct 2009 17:59:54 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACE5821.3040509@redhat.com> References: <4ACE5570.2070505@redhat.com> <4ACE5716.5010200@redhat.com> <4ACE5821.3040509@redhat.com> Message-ID: <4ACE60DA.4050605@redhat.com> On 10/08/2009 05:22 PM, Rob Crittenden wrote: > John Dennis wrote: >> Thanks Rob. BTW, I was going to add a try/except block around that >> code in selfsign and return a non-zero status if it fails. Do we have >> predefined status codes I should be using? >> > > I'm assuming you mean around the certs.next_serial() call? yes > Not really sure. This is really a "server blew up" sort of error, I'm > not sure what the best thing to return to the client is in this case. I > think something that says "the server is hosed, you can't fix it from > there" sort of error would be nice. AFAIK we don't currently define such > a beastie. Well, looking at errors.py it looks like it should be an ExecutionError in the 4000-4999 range. How about adding UnableToCompleteCertificateOperation as a generic error for any certificate operation we can't run to completion, then do a log.error message with the specific failure. The errno associated with UnableToCompleteCertificateOperation can be returned whenever we hit some unexpected error related to certificate operations, it will be generic enough to cover a range of cases without exposing the reason for the fault and the server log file will contain the detail. How does that sound? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jgalipea at redhat.com Fri Oct 9 13:30:27 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Fri, 09 Oct 2009 09:30:27 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACE60DA.4050605@redhat.com> References: <4ACE5570.2070505@redhat.com> <4ACE5716.5010200@redhat.com> <4ACE5821.3040509@redhat.com> <4ACE60DA.4050605@redhat.com> Message-ID: <4ACF3AF3.3000908@redhat.com> John Dennis wrote: > On 10/08/2009 05:22 PM, Rob Crittenden wrote: >> John Dennis wrote: >>> Thanks Rob. BTW, I was going to add a try/except block around that >>> code in selfsign and return a non-zero status if it fails. Do we have >>> predefined status codes I should be using? >>> >> >> I'm assuming you mean around the certs.next_serial() call? > > yes > >> Not really sure. This is really a "server blew up" sort of error, I'm >> not sure what the best thing to return to the client is in this case. I >> think something that says "the server is hosed, you can't fix it from >> there" sort of error would be nice. AFAIK we don't currently define such >> a beastie. > > Well, looking at errors.py it looks like it should be an > ExecutionError in the 4000-4999 range. How about adding > UnableToCompleteCertificateOperation as a generic error for any > certificate operation we can't run to completion, It would also be nice to reference the log, as in "Please see mylog.log for details." > then do a log.error message with the specific failure. The errno > associated with UnableToCompleteCertificateOperation can be returned > whenever we hit some unexpected error related to certificate > operations, it will be generic enough to cover a range of cases > without exposing the reason for the fault and the server log file will > contain the detail. How does that sound? -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering From rcritten at redhat.com Fri Oct 9 13:40:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Oct 2009 09:40:37 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACF3AF3.3000908@redhat.com> References: <4ACE5570.2070505@redhat.com> <4ACE5716.5010200@redhat.com> <4ACE5821.3040509@redhat.com> <4ACE60DA.4050605@redhat.com> <4ACF3AF3.3000908@redhat.com> Message-ID: <4ACF3D55.5040800@redhat.com> Jenny Galipeau wrote: > John Dennis wrote: >> On 10/08/2009 05:22 PM, Rob Crittenden wrote: >>> John Dennis wrote: >>>> Thanks Rob. BTW, I was going to add a try/except block around that >>>> code in selfsign and return a non-zero status if it fails. Do we have >>>> predefined status codes I should be using? >>>> >>> >>> I'm assuming you mean around the certs.next_serial() call? >> >> yes >> >>> Not really sure. This is really a "server blew up" sort of error, I'm >>> not sure what the best thing to return to the client is in this case. I >>> think something that says "the server is hosed, you can't fix it from >>> there" sort of error would be nice. AFAIK we don't currently define such >>> a beastie. >> >> Well, looking at errors.py it looks like it should be an >> ExecutionError in the 4000-4999 range. How about adding >> UnableToCompleteCertificateOperation as a generic error for any >> certificate operation we can't run to completion, > It would also be nice to reference the log, as in "Please see mylog.log > for details." Well, this is a pretty common, generic problem. We don't want to give too many specifics to a client. The assumption is that they'll go bug their administrator. We could add the "See your system administrator" but that is truly annoying when you're the administrator trying to debug the problem. I myself have shouted any number of time "But I *am* the %#$@!@ system administrator" when presented with similar messages on other systems. What we'll have to do is document somewhere that tracebacks can be found in the Apache error log. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jgalipea at redhat.com Fri Oct 9 13:48:50 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Fri, 09 Oct 2009 09:48:50 -0400 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACF3D55.5040800@redhat.com> References: <4ACE5570.2070505@redhat.com> <4ACE5716.5010200@redhat.com> <4ACE5821.3040509@redhat.com> <4ACE60DA.4050605@redhat.com> <4ACF3AF3.3000908@redhat.com> <4ACF3D55.5040800@redhat.com> Message-ID: <4ACF3F42.2030100@redhat.com> Rob Crittenden wrote: > Jenny Galipeau wrote: >> John Dennis wrote: >>> On 10/08/2009 05:22 PM, Rob Crittenden wrote: >>>> John Dennis wrote: >>>>> Thanks Rob. BTW, I was going to add a try/except block around that >>>>> code in selfsign and return a non-zero status if it fails. Do we have >>>>> predefined status codes I should be using? >>>>> >>>> >>>> I'm assuming you mean around the certs.next_serial() call? >>> >>> yes >>> >>>> Not really sure. This is really a "server blew up" sort of error, I'm >>>> not sure what the best thing to return to the client is in this >>>> case. I >>>> think something that says "the server is hosed, you can't fix it from >>>> there" sort of error would be nice. AFAIK we don't currently define >>>> such >>>> a beastie. >>> >>> Well, looking at errors.py it looks like it should be an >>> ExecutionError in the 4000-4999 range. How about adding >>> UnableToCompleteCertificateOperation as a generic error for any >>> certificate operation we can't run to completion, >> It would also be nice to reference the log, as in "Please see >> mylog.log for details." > > Well, this is a pretty common, generic problem. We don't want to give > too many specifics to a client. The assumption is that they'll go bug > their administrator. Ah yes ... forgot it was the client! > > We could add the "See your system administrator" but that is truly > annoying when you're the administrator trying to debug the problem. > I myself have shouted any number of time "But I *am* the %#$@!@ system > administrator" when presented with similar messages on other systems. :-) hehe ... I guess it is most likely that an admin will be running the ipa join command - true? > > What we'll have to do is document somewhere that tracebacks can be > found in the Apache error log. > > rob -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering From nkinder at redhat.com Fri Oct 9 14:26:51 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 09 Oct 2009 07:26:51 -0700 Subject: [Freeipa-devel] [PATCH] 290 set cert_t context on some files for selfsign plugin In-Reply-To: <4ACF3F42.2030100@redhat.com> References: <4ACE5570.2070505@redhat.com> <4ACE5716.5010200@redhat.com> <4ACE5821.3040509@redhat.com> <4ACE60DA.4050605@redhat.com> <4ACF3AF3.3000908@redhat.com> <4ACF3D55.5040800@redhat.com> <4ACF3F42.2030100@redhat.com> Message-ID: <4ACF482B.1090905@redhat.com> On 10/09/2009 06:48 AM, Jenny Galipeau wrote: > Rob Crittenden wrote: >> Jenny Galipeau wrote: >>> John Dennis wrote: >>>> On 10/08/2009 05:22 PM, Rob Crittenden wrote: >>>>> John Dennis wrote: >>>>>> Thanks Rob. BTW, I was going to add a try/except block around that >>>>>> code in selfsign and return a non-zero status if it fails. Do we >>>>>> have >>>>>> predefined status codes I should be using? >>>>>> >>>>> >>>>> I'm assuming you mean around the certs.next_serial() call? >>>> >>>> yes >>>> >>>>> Not really sure. This is really a "server blew up" sort of error, I'm >>>>> not sure what the best thing to return to the client is in this >>>>> case. I >>>>> think something that says "the server is hosed, you can't fix it from >>>>> there" sort of error would be nice. AFAIK we don't currently >>>>> define such >>>>> a beastie. >>>> >>>> Well, looking at errors.py it looks like it should be an >>>> ExecutionError in the 4000-4999 range. How about adding >>>> UnableToCompleteCertificateOperation as a generic error for any >>>> certificate operation we can't run to completion, >>> It would also be nice to reference the log, as in "Please see >>> mylog.log for details." >> >> Well, this is a pretty common, generic problem. We don't want to give >> too many specifics to a client. The assumption is that they'll go bug >> their administrator. > Ah yes ... forgot it was the client! >> >> We could add the "See your system administrator" but that is truly >> annoying when you're the administrator trying to debug the problem. I >> myself have shouted any number of time "But I *am* the %#$@!@ system >> administrator" when presented with similar messages on other systems. > :-) hehe ... I guess it is most likely that an admin will be running > the ipa join command - true? Some places may have lower-level helpdesk folks go around to install and join systems. These helpdesk techs would not have privileged access to the IPA system usually. >> >> What we'll have to do is document somewhere that tracebacks can be >> found in the Apache error log. >> >> rob > > From jdennis at redhat.com Fri Oct 9 16:15:39 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Oct 2009 12:15:39 -0400 Subject: [Freeipa-devel] fedora-ds problem with kickstart in virtlab for F11 Message-ID: <4ACF61AB.3010207@redhat.com> I just noticed a problem when trying to create an F11 IPA virtual machine in our virtlab. I happened to be using the profile Fedora-11-i386-freeipa. The cobbler install pauses because it can't find the fedora-ds-* packages. That makes sense (possibly) because the packages are now 389-ds-* But I happened to notice, and Nathan confirmed the F11 repo has both fedora-ds and 389-ds. I'm presuming 389-ds obsoletes fedora-ds but fedora-ds continues to live in the repo because if someone initially installed fedora-ds in F11 then a yum upgrade won't automatically move them over to 389-ds. Does anybody know if that's true? Anyway I'm confused, if both fedora-ds and 389-ds are in the F11 repo why did the kickstart fail to find fedora-ds? Should we edit the profiles to change fedora-ds to 389-ds on F11 and rawhide? I found the profiles on gordo but I didn't want touch them yet. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Fri Oct 9 16:27:49 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 09 Oct 2009 10:27:49 -0600 Subject: [Freeipa-devel] fedora-ds problem with kickstart in virtlab for F11 In-Reply-To: <4ACF61AB.3010207@redhat.com> References: <4ACF61AB.3010207@redhat.com> Message-ID: <4ACF6485.8040206@redhat.com> John Dennis wrote: > I just noticed a problem when trying to create an F11 IPA virtual > machine in our virtlab. I happened to be using the profile > Fedora-11-i386-freeipa. > > The cobbler install pauses because it can't find the fedora-ds-* > packages. That makes sense (possibly) because the packages are now > 389-ds-* > > But I happened to notice, and Nathan confirmed the F11 repo has both > fedora-ds and 389-ds. I'm presuming 389-ds obsoletes fedora-ds but > fedora-ds continues to live in the repo because if someone initially > installed fedora-ds in F11 then a yum upgrade won't automatically move > them over to 389-ds. Does anybody know if that's true? I'm pretty sure that if you have installed the fedora-ds packages, doing a "yum upgrade" will replace them with the 389 packages. All of the 389 packages are designed to both Provides: and Obsoletes: their fedora ds counterparts. > > Anyway I'm confused, if both fedora-ds and 389-ds are in the F11 repo > why did the kickstart fail to find fedora-ds? Good question. > > Should we edit the profiles to change fedora-ds to 389-ds on F11 and > rawhide? I found the profiles on gordo but I didn't want touch them yet. Yes. Everything should be using 389 instead of fedora ds. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Fri Oct 9 17:09:02 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 09 Oct 2009 19:09:02 +0200 Subject: [Freeipa-devel] fedora-ds problem with kickstart in virtlab for F11 In-Reply-To: <4ACF61AB.3010207@redhat.com> References: <4ACF61AB.3010207@redhat.com> Message-ID: <4ACF6E2E.2040802@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/09/2009 06:15 PM, John Dennis wrote: > Should we edit the profiles to change fedora-ds to 389-ds on F11 and > rawhide? I found the profiles on gordo but I didn't want touch them yet. Done and tested on able. Sorry for the confusion, I didn't realize the change happened also in released Fedoras, as opposed to Rawhide. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrPbicACgkQHsardTLnvCWuaQCgor1dHIoesicHxM/zzEJ/CDb7 G1wAoJAsQE1vKiof6TqHN1b5b4SBBD5r =0l4w -----END PGP SIGNATURE----- From rcritten at redhat.com Fri Oct 9 21:29:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Oct 2009 17:29:31 -0400 Subject: [Freeipa-devel] [PATCH] 291 use DS memberof plugin Message-ID: <4ACFAB3B.4030907@redhat.com> Use the DS memberof plugin instead of the one contained in the IPA source. I'm not removing that source yet, simply not building or configuring it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-291-memberof.patch Type: application/mbox Size: 2411 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 9 21:30:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Oct 2009 17:30:37 -0400 Subject: [Freeipa-devel] [PATCH] 292 use proper objectclass for rolegroups Message-ID: <4ACFAB7D.7030501@redhat.com> I was using groupofnames for rolegroups but trying to add memberof to it (bad). Use nestedgroup instead. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-292-rolegroups.patch Type: application/mbox Size: 14722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Mon Oct 12 06:22:37 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 12 Oct 2009 08:22:37 +0200 Subject: [Freeipa-devel] [PATCH] 286 cache installer questions In-Reply-To: <4ACCAC74.1080204@redhat.com> References: <4ACCAC74.1080204@redhat.com> Message-ID: <1255328557.29221.35.camel@wolverine.englab.brq.redhat.com> Hi Rob, On Wed, 2009-10-07 at 10:57 -0400, Rob Crittenden wrote: > Installing a CA that is signed by another CA is a 2-step process. The > first step is to generate a CSR for the CA and the second step is to > install the certificate issued by the external CA. To avoid asking > questions over and over (and potentially getting different answers) the > answers are cached. > > rob - try: - from ipaserver.install import cainstance - except ImportError: - print >> sys.stderr, "Import failed: %s" % sys.exc_value - sys.exit(1) What's this? From just a quick look, it seems to me that this will cause troubles. Martin From mnagy at redhat.com Mon Oct 12 06:30:22 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 12 Oct 2009 08:30:22 +0200 Subject: [Freeipa-devel] [PATCH] 287 improve ipa-join In-Reply-To: <4ACCFF3B.8070400@redhat.com> References: <4ACCFF3B.8070400@redhat.com> Message-ID: <1255329022.29221.36.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-10-07 at 16:51 -0400, Rob Crittenden wrote: > I ran ipa-join on some not properly-configured clients and found a bunch > of corner cases that are fixed here. This improves debugging and > standard output considerably. > > rob Ack. Martin From mnagy at redhat.com Mon Oct 12 06:41:25 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 12 Oct 2009 08:41:25 +0200 Subject: [Freeipa-devel] [PATCH] 288 man page for ipa-join In-Reply-To: <4ACE011A.8090205@redhat.com> References: <4ACE011A.8090205@redhat.com> Message-ID: <1255329685.29221.41.camel@wolverine.englab.brq.redhat.com> On Thu, 2009-10-08 at 11:11 -0400, Rob Crittenden wrote: > Add a man page for the new ipa-join command. > > rob +ipa\-join [ \fB\-h\fR hostname ] [ \fB\-k\fR keytab\-file ] [ \fB\-w\fR bulk bind password ] [ \fB\-d\fR ] [ \fB\-q\fR ] Can you use something like bulk-bind-password instead? (with dashes) There is also some trailing white-space in the copyright notice and after all .TP commands. Martin From mnagy at redhat.com Mon Oct 12 06:44:33 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 12 Oct 2009 08:44:33 +0200 Subject: [Freeipa-devel] [PATCH] 291 use DS memberof plugin In-Reply-To: <4ACFAB3B.4030907@redhat.com> References: <4ACFAB3B.4030907@redhat.com> Message-ID: <1255329873.29221.42.camel@wolverine.englab.brq.redhat.com> On Fri, 2009-10-09 at 17:29 -0400, Rob Crittenden wrote: > Use the DS memberof plugin instead of the one contained in the IPA > source. I'm not removing that source yet, simply not building or > configuring it. > > rob Looks good to me. Ack. Martin From rcritten at redhat.com Mon Oct 12 13:02:23 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 09:02:23 -0400 Subject: [Freeipa-devel] [PATCH] 286 cache installer questions In-Reply-To: <1255328557.29221.35.camel@wolverine.englab.brq.redhat.com> References: <4ACCAC74.1080204@redhat.com> <1255328557.29221.35.camel@wolverine.englab.brq.redhat.com> Message-ID: <4AD328DF.4090106@redhat.com> Martin Nagy wrote: > Hi Rob, > > On Wed, 2009-10-07 at 10:57 -0400, Rob Crittenden wrote: >> Installing a CA that is signed by another CA is a 2-step process. The >> first step is to generate a CSR for the CA and the second step is to >> install the certificate issued by the external CA. To avoid asking >> questions over and over (and potentially getting different answers) the >> answers are cached. >> >> rob > > - try: > - from ipaserver.install import cainstance > - except ImportError: > - print >> sys.stderr, "Import failed: %s" % sys.exc_value > - sys.exit(1) > > What's this? From just a quick look, it seems to me that this will cause > troubles. > > Martin > It was duplicated code, we check for that elsewhere. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 12 13:03:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 09:03:39 -0400 Subject: [Freeipa-devel] [PATCH] 288 man page for ipa-join In-Reply-To: <1255329685.29221.41.camel@wolverine.englab.brq.redhat.com> References: <4ACE011A.8090205@redhat.com> <1255329685.29221.41.camel@wolverine.englab.brq.redhat.com> Message-ID: <4AD3292B.501@redhat.com> Martin Nagy wrote: > On Thu, 2009-10-08 at 11:11 -0400, Rob Crittenden wrote: >> Add a man page for the new ipa-join command. >> >> rob > > +ipa\-join [ \fB\-h\fR hostname ] [ \fB\-k\fR keytab\-file ] [ \fB\-w\fR > bulk bind password ] [ \fB\-d\fR ] [ \fB\-q\fR ] > > Can you use something like bulk-bind-password instead? (with dashes) I picked -w since that is common to the openldap clients. I can add a long version too. > There is also some trailing white-space in the copyright notice and > after all .TP commands. I think that the manpage editor I use, manedit, adds those. I can get those cleaned up as well. Do you want another patch or just a promise that I'll fix these up? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Mon Oct 12 13:03:52 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 12 Oct 2009 15:03:52 +0200 Subject: [Freeipa-devel] [PATCH] 292 use proper objectclass for rolegroups In-Reply-To: <4ACFAB7D.7030501@redhat.com> References: <4ACFAB7D.7030501@redhat.com> Message-ID: <4AD32938.8090405@redhat.com> Rob Crittenden wrote: > I was using groupofnames for rolegroups but trying to add memberof to it > (bad). Use nestedgroup instead. > > rob ack. Pavel From pzuna at redhat.com Mon Oct 12 13:05:28 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 12 Oct 2009 15:05:28 +0200 Subject: [Freeipa-devel] [PATCH] 289 fix host admin acis In-Reply-To: <4ACE505C.6010208@redhat.com> References: <4ACE505C.6010208@redhat.com> Message-ID: <4AD32998.9010306@redhat.com> Rob Crittenden wrote: > It appears I missed a couple of ACI's when we changed the DN format of > hosts. > > rob ack. Pavel From rcritten at redhat.com Mon Oct 12 13:37:24 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 09:37:24 -0400 Subject: [Freeipa-devel] [PATCH] 287 improve ipa-join In-Reply-To: <1255329022.29221.36.camel@wolverine.englab.brq.redhat.com> References: <4ACCFF3B.8070400@redhat.com> <1255329022.29221.36.camel@wolverine.englab.brq.redhat.com> Message-ID: <4AD33114.7050401@redhat.com> Martin Nagy wrote: > On Wed, 2009-10-07 at 16:51 -0400, Rob Crittenden wrote: >> I ran ipa-join on some not properly-configured clients and found a bunch >> of corner cases that are fixed here. This improves debugging and >> standard output considerably. >> >> rob > > Ack. > Martin > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 12 13:38:21 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 09:38:21 -0400 Subject: [Freeipa-devel] [PATCH] 291 use DS memberof plugin In-Reply-To: <1255329873.29221.42.camel@wolverine.englab.brq.redhat.com> References: <4ACFAB3B.4030907@redhat.com> <1255329873.29221.42.camel@wolverine.englab.brq.redhat.com> Message-ID: <4AD3314D.2070509@redhat.com> Martin Nagy wrote: > On Fri, 2009-10-09 at 17:29 -0400, Rob Crittenden wrote: >> Use the DS memberof plugin instead of the one contained in the IPA >> source. I'm not removing that source yet, simply not building or >> configuring it. >> >> rob > > Looks good to me. Ack. > Martin > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 12 13:41:16 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 09:41:16 -0400 Subject: [Freeipa-devel] [PATCH] 292 use proper objectclass for rolegroups In-Reply-To: <4AD32938.8090405@redhat.com> References: <4ACFAB7D.7030501@redhat.com> <4AD32938.8090405@redhat.com> Message-ID: <4AD331FC.5060802@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> I was using groupofnames for rolegroups but trying to add memberof to >> it (bad). Use nestedgroup instead. >> >> rob > ack. > > Pavel pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 12 14:22:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 10:22:31 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in HBAC and netgroup plugin get_primary_key_from_dn methods. In-Reply-To: <4ACDC76A.4030200@redhat.com> References: <4ACB4C8D.7020504@redhat.com> <4ACC9FC3.6040601@redhat.com> <4ACDC76A.4030200@redhat.com> Message-ID: <4AD33BA7.501@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> The method was returning tuples instead of strings in both plugins >>> causing a mess in other plugins, when displaying netgroup/HBAC >>> information. >>> >>> Pavel >> >> Assuming that the primary key doesn't exist, what meaning does >> returning '' have? For these 2 plugins shouldn't it always have a >> primary key? >> >> rob > In most plugins, retrieving the primary key from DN is easy, because it > is part of the DN (RDN attribute == primary key attribute). With > netgroups and HBAC it is a bit more complicated, because the RDN > attribute is 'ipauniqueid' and the primary key is 'cn' - we have to do a > search to retrieve it. If the search fails for some reason (someone > deletes the entry in parallel for example), we return an empty string, > which is fail-safe. > > Pavel Ok, Jason does 11 ET work for you, say on Wed and Fri? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 12 15:32:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 11:32:22 -0400 Subject: [Freeipa-devel] [PATCH] 293 use fqdn Message-ID: <4AD34C06.3010700@redhat.com> Use getfqdn() instead of the gethostname(). self.ca_host could end up as the same value as self.host and if this isn't fully-qualified then SSL client requests won't work (we query the CA over SSL). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-293-fqdn.patch Type: application/mbox Size: 1028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Oct 12 17:56:32 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 13:56:32 -0400 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task Message-ID: <4AD36DD0.4010307@redhat.com> One of the last steps of an install is to run through any updates. This change adds a sleep() prior to calling tasks to ensure postop writes are done We were seeing a rare deadlock of DS when creating the memberOf task because one thread was adding memberOf in a postop while another was trying to create an index and this was causing a PRLock deadlock. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-294-task.patch Type: application/mbox Size: 1093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Mon Oct 12 18:10:59 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 12 Oct 2009 12:10:59 -0600 Subject: [Freeipa-devel] Re: [PATCH] Fix bug in HBAC and netgroup plugin get_primary_key_from_dn methods. In-Reply-To: <4AD33BA7.501@redhat.com> References: <4ACB4C8D.7020504@redhat.com> <4ACC9FC3.6040601@redhat.com> <4ACDC76A.4030200@redhat.com> <4AD33BA7.501@redhat.com> Message-ID: <1255371059.11189.0.camel@jgd-dsk> On Mon, 2009-10-12 at 10:22 -0400, Rob Crittenden wrote: > Pavel Zuna wrote: > > Rob Crittenden wrote: > >> Pavel Zuna wrote: > >>> The method was returning tuples instead of strings in both plugins > >>> causing a mess in other plugins, when displaying netgroup/HBAC > >>> information. > >>> > >>> Pavel > >> > >> Assuming that the primary key doesn't exist, what meaning does > >> returning '' have? For these 2 plugins shouldn't it always have a > >> primary key? > >> > >> rob > > In most plugins, retrieving the primary key from DN is easy, because it > > is part of the DN (RDN attribute == primary key attribute). With > > netgroups and HBAC it is a bit more complicated, because the RDN > > attribute is 'ipauniqueid' and the primary key is 'cn' - we have to do a > > search to retrieve it. If the search fails for some reason (someone > > deletes the entry in parallel for example), we return an empty string, > > which is fail-safe. > > > > Pavel > > Ok, Jason does 11 ET work for you, say on Wed and Fri? > > rob Yep, sounds good. From mnagy at redhat.com Mon Oct 12 18:46:17 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 12 Oct 2009 20:46:17 +0200 Subject: [Freeipa-devel] [PATCH] 288 man page for ipa-join In-Reply-To: <4AD3292B.501@redhat.com> References: <4ACE011A.8090205@redhat.com> <1255329685.29221.41.camel@wolverine.englab.brq.redhat.com> <4AD3292B.501@redhat.com> Message-ID: <20091012204617.1eecd079@notas> Rob Crittenden wrote: > Martin Nagy wrote: > > On Thu, 2009-10-08 at 11:11 -0400, Rob Crittenden wrote: > >> Add a man page for the new ipa-join command. > >> > >> rob > > > > +ipa\-join [ \fB\-h\fR hostname ] [ \fB\-k\fR keytab\-file ] [ \fB\-w\fR > > bulk bind password ] [ \fB\-d\fR ] [ \fB\-q\fR ] > > > > Can you use something like bulk-bind-password instead? (with dashes) Ah, I didn't mean that you should change -w. But rather, I would change [ \fB\-w\fR bulk bind password ] to something like this: [ \fB\-w\fR bulk\-bind\-password ] Similarly as we use "keytab\-file" and not "keytab file". > I picked -w since that is common to the openldap clients. I can add a > long version too. > > > There is also some trailing white-space in the copyright notice and > > after all .TP commands. > > I think that the manpage editor I use, manedit, adds those. I can get > those cleaned up as well. > > Do you want another patch or just a promise that I'll fix these up? > > rob Yes, if you do the changes you have an Ack. Martin From rcritten at redhat.com Mon Oct 12 18:50:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 14:50:19 -0400 Subject: [Freeipa-devel] [PATCH] 288 man page for ipa-join In-Reply-To: <20091012204617.1eecd079@notas> References: <4ACE011A.8090205@redhat.com> <1255329685.29221.41.camel@wolverine.englab.brq.redhat.com> <4AD3292B.501@redhat.com> <20091012204617.1eecd079@notas> Message-ID: <4AD37A6B.3@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> Martin Nagy wrote: >>> On Thu, 2009-10-08 at 11:11 -0400, Rob Crittenden wrote: >>>> Add a man page for the new ipa-join command. >>>> >>>> rob >>> +ipa\-join [ \fB\-h\fR hostname ] [ \fB\-k\fR keytab\-file ] [ \fB\-w\fR >>> bulk bind password ] [ \fB\-d\fR ] [ \fB\-q\fR ] >>> >>> Can you use something like bulk-bind-password instead? (with dashes) > > Ah, I didn't mean that you should change -w. But rather, I would change > [ \fB\-w\fR bulk bind password ] > to something like this: > [ \fB\-w\fR bulk\-bind\-password ] > > Similarly as we use "keytab\-file" and not "keytab file". > >> I picked -w since that is common to the openldap clients. I can add a >> long version too. >> >>> There is also some trailing white-space in the copyright notice and >>> after all .TP commands. >> I think that the manpage editor I use, manedit, adds those. I can get >> those cleaned up as well. >> >> Do you want another patch or just a promise that I'll fix these up? >> >> rob > > Yes, if you do the changes you have an Ack. > Martin Done and pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Mon Oct 12 18:52:20 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 12 Oct 2009 20:52:20 +0200 Subject: [Freeipa-devel] [PATCH] 286 cache installer questions In-Reply-To: <4AD328DF.4090106@redhat.com> References: <4ACCAC74.1080204@redhat.com> <1255328557.29221.35.camel@wolverine.englab.brq.redhat.com> <4AD328DF.4090106@redhat.com> Message-ID: <20091012205220.3e65a09a@notas> Rob Crittenden wrote: > Martin Nagy wrote: > > Hi Rob, > > > > On Wed, 2009-10-07 at 10:57 -0400, Rob Crittenden wrote: > >> Installing a CA that is signed by another CA is a 2-step process. The > >> first step is to generate a CSR for the CA and the second step is to > >> install the certificate issued by the external CA. To avoid asking > >> questions over and over (and potentially getting different answers) the > >> answers are cached. > >> > >> rob > > > > - try: > > - from ipaserver.install import cainstance > > - except ImportError: > > - print >> sys.stderr, "Import failed: %s" % sys.exc_value > > - sys.exit(1) > > > > What's this? From just a quick look, it seems to me that this will cause > > troubles. > > > > Martin > > > > It was duplicated code, we check for that elsewhere. > > rob Ah, right. Not thrilled that it's not in a separate patch but what the heck. Ack. Martin From rcritten at redhat.com Mon Oct 12 20:01:42 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Oct 2009 16:01:42 -0400 Subject: [Freeipa-devel] [PATCH] 295 client Makefile target Message-ID: <4AD38B26.9070104@redhat.com> This adds a few new targets to the top-level Makefile, most notably client and client-rpms. Using this you can more easily build just the client pieces of IPA. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-295-client.patch Type: application/mbox Size: 11310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Tue Oct 13 04:17:21 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 12 Oct 2009 22:17:21 -0600 Subject: [Freeipa-devel] Fedora12: Looping detected inside krb5_get_in_tkt Message-ID: <1255407441.11621.7.camel@jgd-dsk> To help ensure that my new UI patch wont break our daily builds, I've tried building it under Fedora 12 as it has python-assets and python-wehjit. It builds fine, but when I kinit, I get this error: [root at fedora12 ~]# kinit admin at EXAMPLE.COM Password for admin at EXAMPLE.COM: kinit: Looping detected inside krb5_get_in_tkt while getting initial credentials Anyone have any ideas? From jderose at redhat.com Tue Oct 13 17:53:59 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 13 Oct 2009 17:53:59 +0000 Subject: [Freeipa-devel] [PATCH] jderose 017-2 Giant webui patch take 2 Message-ID: <1255456439.11621.64.camel@jgd-dsk> Okay, finally here is the revised webui patch. Since the last version, I: * Ported to various API changed between wehjit 0.0.1 and 0.1.0 * Removed the session.py stuff, which will be in a separate patch * Added the plugin browser to help developers inspect the plugins The webui is still in a similar "dumb" state till I extend various meta-data in ipalib, which I will work on this week and will quickly get the UI into a more impressive state. I just can't let this patch get any larger... stop the madness! ;) There currently isn't a top-level webui-page at /ipa/ui, but pages exist for each command plugin, i.e., /ipa/ui/user_add This patch is big, but tries to be non-intrusive: the new webui stuff only runs from the new lite-server.py script, not for the installed version running under Apache. As far as I know, no existing functionality is disrupted by this patch. After making the meta-data changes, I will enable the new functionality under Apache also. I hope everyone will find the plugin-browser quite helpful. To run it, launch lite-server.py like this: ./lite-server.py And then point your browser to: http://127.0.0.1:8888/ipa/ui/Command All plugins in all namespaces are available in the browser, but details are currently only available for the Command and Object namespaces. I will also soon add an easy way to render the plugin browser to static pages to put on freeipa.org. This patch requires python-wehjit and python-assets, which are in Fedora12 and rawhide. Or you can install from tarballs here: http://jderose.fedorapeople.org/assets/current/ http://jderose.fedorapeople.org/wehjit/current/ A couple of weekends ago I also packaged assets and wehjit for Debian/Ubuntu. Karmic packages are available in my PPA: https://launchpad.net/~jderose/+archive/ppa Sorry the patch is so large, subsequent ones wont be. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-017-2-Giant-webui-patch-take-2.patch Type: text/x-patch Size: 156895 bytes Desc: not available URL: From jdennis at redhat.com Tue Oct 13 17:59:16 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 13 Oct 2009 13:59:16 -0400 Subject: [Freeipa-devel] why doesn't ipapython.ipautil.run() log what it's running? Message-ID: <4AD4BFF4.2080009@redhat.com> Is there a reason why the run command (ipapython.ipautil.run()) does not log what command it's running? It logs the stdout and stderr output of the command (but without indicating what the log output is, so a lot of time it just shows up as a blank line if there was no output). Shouldn't it do something like this: logging.info("args=%s" % " ".join(args)) logging.info("stdout=%s" % stdout) logging.info("stderr=%s" % stderr) instead of: logging.info(stdout) logging.info(stderr) Without knowing what was run and what it's arguments were the stdout and stderr messages are almost useless. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Oct 13 18:11:43 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Oct 2009 14:11:43 -0400 Subject: [Freeipa-devel] [PATCH] jderose 017-2 Giant webui patch take 2 In-Reply-To: <1255456439.11621.64.camel@jgd-dsk> References: <1255456439.11621.64.camel@jgd-dsk> Message-ID: <4AD4C2DF.4040405@redhat.com> Jason Gerard DeRose wrote: > Okay, finally here is the revised webui patch. Since the last version, > I: > > * Ported to various API changed between wehjit 0.0.1 and 0.1.0 > > * Removed the session.py stuff, which will be in a separate patch > > * Added the plugin browser to help developers inspect the plugins > > The webui is still in a similar "dumb" state till I extend various > meta-data in ipalib, which I will work on this week and will quickly get > the UI into a more impressive state. I just can't let this patch get > any larger... stop the madness! ;) There currently isn't a top-level > webui-page at /ipa/ui, but pages exist for each command plugin, > i.e., /ipa/ui/user_add > > This patch is big, but tries to be non-intrusive: the new webui stuff > only runs from the new lite-server.py script, not for the installed > version running under Apache. As far as I know, no existing > functionality is disrupted by this patch. After making the meta-data > changes, I will enable the new functionality under Apache also. > > I hope everyone will find the plugin-browser quite helpful. To run it, > launch lite-server.py like this: > > ./lite-server.py > > And then point your browser to: > > http://127.0.0.1:8888/ipa/ui/Command > > All plugins in all namespaces are available in the browser, but details > are currently only available for the Command and Object namespaces. I > will also soon add an easy way to render the plugin browser to static > pages to put on freeipa.org. > > This patch requires python-wehjit and python-assets, which are in > Fedora12 and rawhide. Or you can install from tarballs here: > > http://jderose.fedorapeople.org/assets/current/ > > http://jderose.fedorapeople.org/wehjit/current/ > > A couple of weekends ago I also packaged assets and wehjit for > Debian/Ubuntu. Karmic packages are available in my PPA: > > https://launchpad.net/~jderose/+archive/ppa > > Sorry the patch is so large, subsequent ones wont be. > > > > > Jason, The patch removes 4300 lines and adds 1000. Is this correct or we are missing something? > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Oct 13 18:25:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2009 14:25:49 -0400 Subject: [Freeipa-devel] why doesn't ipapython.ipautil.run() log what it's running? In-Reply-To: <4AD4BFF4.2080009@redhat.com> References: <4AD4BFF4.2080009@redhat.com> Message-ID: <4AD4C62D.6030201@redhat.com> John Dennis wrote: > Is there a reason why the run command (ipapython.ipautil.run()) does not > log what command it's running? It logs the stdout and stderr output of > the command (but without indicating what the log output is, so a lot of > time it just shows up as a blank line if there was no output). Shouldn't > it do something like this: > > logging.info("args=%s" % " ".join(args)) > logging.info("stdout=%s" % stdout) > logging.info("stderr=%s" % stderr) > > instead of: > > logging.info(stdout) > logging.info(stderr) > > Without knowing what was run and what it's arguments were the stdout and > stderr messages are almost useless. > Guess it never came up before. Seems to make sense to be more explicit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Tue Oct 13 18:34:44 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 13 Oct 2009 14:34:44 -0400 Subject: [Freeipa-devel] why doesn't ipapython.ipautil.run() log what it's running? In-Reply-To: <4AD4C62D.6030201@redhat.com> References: <4AD4BFF4.2080009@redhat.com> <4AD4C62D.6030201@redhat.com> Message-ID: <4AD4C844.7020601@redhat.com> On 10/13/2009 02:25 PM, Rob Crittenden wrote: > John Dennis wrote: >> Is there a reason why the run command (ipapython.ipautil.run()) does >> not log what command it's running? It logs the stdout and stderr >> output of the command (but without indicating what the log output is, >> so a lot of time it just shows up as a blank line if there was no >> output). Shouldn't it do something like this: >> >> logging.info("args=%s" % " ".join(args)) >> logging.info("stdout=%s" % stdout) >> logging.info("stderr=%s" % stderr) >> >> instead of: >> >> logging.info(stdout) >> logging.info(stderr) >> >> Without knowing what was run and what it's arguments were the stdout >> and stderr messages are almost useless. >> > > Guess it never came up before. Seems to make sense to be more explicit. > Well, it occurred to me that one reason might be because the command might contain sensitive information such as passwords. I did notice that some code will do a logging.debug(args) before calling ipautil.run(), it's not clear to me why this pattern exists. Also, for some reason with ipa-server-install *no* debug messages are appearing even though standard_logging_setup() is being called which sets the log level to debug. I'm investigating the reason now (perhaps using the wrong logger instance?) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Oct 13 18:50:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2009 14:50:22 -0400 Subject: [Freeipa-devel] [PATCH] jderose 017-2 Giant webui patch take 2 In-Reply-To: <4AD4C2DF.4040405@redhat.com> References: <1255456439.11621.64.camel@jgd-dsk> <4AD4C2DF.4040405@redhat.com> Message-ID: <4AD4CBEE.8040607@redhat.com> Dmitri Pal wrote: > Jason Gerard DeRose wrote: >> Okay, finally here is the revised webui patch. Since the last version, >> I: >> >> * Ported to various API changed between wehjit 0.0.1 and 0.1.0 >> >> * Removed the session.py stuff, which will be in a separate patch >> >> * Added the plugin browser to help developers inspect the plugins >> >> The webui is still in a similar "dumb" state till I extend various >> meta-data in ipalib, which I will work on this week and will quickly get >> the UI into a more impressive state. I just can't let this patch get >> any larger... stop the madness! ;) There currently isn't a top-level >> webui-page at /ipa/ui, but pages exist for each command plugin, >> i.e., /ipa/ui/user_add >> >> This patch is big, but tries to be non-intrusive: the new webui stuff >> only runs from the new lite-server.py script, not for the installed >> version running under Apache. As far as I know, no existing >> functionality is disrupted by this patch. After making the meta-data >> changes, I will enable the new functionality under Apache also. >> >> I hope everyone will find the plugin-browser quite helpful. To run it, >> launch lite-server.py like this: >> >> ./lite-server.py >> >> And then point your browser to: >> >> http://127.0.0.1:8888/ipa/ui/Command >> >> All plugins in all namespaces are available in the browser, but details >> are currently only available for the Command and Object namespaces. I >> will also soon add an easy way to render the plugin browser to static >> pages to put on freeipa.org. >> >> This patch requires python-wehjit and python-assets, which are in >> Fedora12 and rawhide. Or you can install from tarballs here: >> >> http://jderose.fedorapeople.org/assets/current/ >> >> http://jderose.fedorapeople.org/wehjit/current/ >> >> A couple of weekends ago I also packaged assets and wehjit for >> Debian/Ubuntu. Karmic packages are available in my PPA: >> >> https://launchpad.net/~jderose/+archive/ppa >> >> Sorry the patch is so large, subsequent ones wont be. >> >> >> >> >> > Jason, > > The patch removes 4300 lines and adds 1000. Is this correct or we are > missing something? > The majority of that 4300 is a single file, mootools-core.js. I'm guessing he is planning to use a different javascript toolkit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Oct 13 18:51:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2009 14:51:06 -0400 Subject: [Freeipa-devel] why doesn't ipapython.ipautil.run() log what it's running? In-Reply-To: <4AD4C844.7020601@redhat.com> References: <4AD4BFF4.2080009@redhat.com> <4AD4C62D.6030201@redhat.com> <4AD4C844.7020601@redhat.com> Message-ID: <4AD4CC1A.8030004@redhat.com> John Dennis wrote: > On 10/13/2009 02:25 PM, Rob Crittenden wrote: >> John Dennis wrote: >>> Is there a reason why the run command (ipapython.ipautil.run()) does >>> not log what command it's running? It logs the stdout and stderr >>> output of the command (but without indicating what the log output is, >>> so a lot of time it just shows up as a blank line if there was no >>> output). Shouldn't it do something like this: >>> >>> logging.info("args=%s" % " ".join(args)) >>> logging.info("stdout=%s" % stdout) >>> logging.info("stderr=%s" % stderr) >>> >>> instead of: >>> >>> logging.info(stdout) >>> logging.info(stderr) >>> >>> Without knowing what was run and what it's arguments were the stdout >>> and stderr messages are almost useless. >>> >> >> Guess it never came up before. Seems to make sense to be more explicit. >> > > Well, it occurred to me that one reason might be because the command > might contain sensitive information such as passwords. I did notice that > some code will do a logging.debug(args) before calling ipautil.run(), > it's not clear to me why this pattern exists. > > Also, for some reason with ipa-server-install *no* debug messages are > appearing even though standard_logging_setup() is being called which > sets the log level to debug. I'm investigating the reason now (perhaps > using the wrong logger instance?) > If I were to guess I'd look at ipalib, I think it creates its own loggers. Perhaps it is redirecting them. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Oct 13 19:21:55 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Oct 2009 15:21:55 -0400 Subject: [Freeipa-devel] [PATCH] jderose 017-2 Giant webui patch take 2 In-Reply-To: <1255456439.11621.64.camel@jgd-dsk> References: <1255456439.11621.64.camel@jgd-dsk> Message-ID: <4AD4D353.30508@redhat.com> Jason Gerard DeRose wrote: > Okay, finally here is the revised webui patch. Since the last version, > I: > > * Ported to various API changed between wehjit 0.0.1 and 0.1.0 > > * Removed the session.py stuff, which will be in a separate patch > > * Added the plugin browser to help developers inspect the plugins > > The webui is still in a similar "dumb" state till I extend various > meta-data in ipalib, which I will work on this week and will quickly get > the UI into a more impressive state. I just can't let this patch get > any larger... stop the madness! ;) There currently isn't a top-level > webui-page at /ipa/ui, but pages exist for each command plugin, > i.e., /ipa/ui/user_add > > This patch is big, but tries to be non-intrusive: the new webui stuff > only runs from the new lite-server.py script, not for the installed > version running under Apache. As far as I know, no existing > functionality is disrupted by this patch. After making the meta-data > changes, I will enable the new functionality under Apache also. > > I hope everyone will find the plugin-browser quite helpful. To run it, > launch lite-server.py like this: > > ./lite-server.py > > And then point your browser to: > > http://127.0.0.1:8888/ipa/ui/Command > > All plugins in all namespaces are available in the browser, but details > are currently only available for the Command and Object namespaces. I > will also soon add an easy way to render the plugin browser to static > pages to put on freeipa.org. > > This patch requires python-wehjit and python-assets, which are in > Fedora12 and rawhide. Or you can install from tarballs here: > > http://jderose.fedorapeople.org/assets/current/ > > http://jderose.fedorapeople.org/wehjit/current/ > > A couple of weekends ago I also packaged assets and wehjit for > Debian/Ubuntu. Karmic packages are available in my PPA: > > https://launchpad.net/~jderose/+archive/ppa > > Sorry the patch is so large, subsequent ones wont be. ack. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Tue Oct 13 20:08:46 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 13 Oct 2009 20:08:46 +0000 Subject: [Freeipa-devel] [PATCH] jderose 017-2 Giant webui patch take 2 In-Reply-To: <4AD4C2DF.4040405@redhat.com> References: <1255456439.11621.64.camel@jgd-dsk> <4AD4C2DF.4040405@redhat.com> Message-ID: <1255464526.11621.67.camel@jgd-dsk> On Tue, 2009-10-13 at 14:11 -0400, Dmitri Pal wrote: > Jason Gerard DeRose wrote: > > Okay, finally here is the revised webui patch. Since the last version, > > I: > > > > * Ported to various API changed between wehjit 0.0.1 and 0.1.0 > > > > * Removed the session.py stuff, which will be in a separate patch > > > > * Added the plugin browser to help developers inspect the plugins > > > > The webui is still in a similar "dumb" state till I extend various > > meta-data in ipalib, which I will work on this week and will quickly get > > the UI into a more impressive state. I just can't let this patch get > > any larger... stop the madness! ;) There currently isn't a top-level > > webui-page at /ipa/ui, but pages exist for each command plugin, > > i.e., /ipa/ui/user_add > > > > This patch is big, but tries to be non-intrusive: the new webui stuff > > only runs from the new lite-server.py script, not for the installed > > version running under Apache. As far as I know, no existing > > functionality is disrupted by this patch. After making the meta-data > > changes, I will enable the new functionality under Apache also. > > > > I hope everyone will find the plugin-browser quite helpful. To run it, > > launch lite-server.py like this: > > > > ./lite-server.py > > > > And then point your browser to: > > > > http://127.0.0.1:8888/ipa/ui/Command > > > > All plugins in all namespaces are available in the browser, but details > > are currently only available for the Command and Object namespaces. I > > will also soon add an easy way to render the plugin browser to static > > pages to put on freeipa.org. > > > > This patch requires python-wehjit and python-assets, which are in > > Fedora12 and rawhide. Or you can install from tarballs here: > > > > http://jderose.fedorapeople.org/assets/current/ > > > > http://jderose.fedorapeople.org/wehjit/current/ > > > > A couple of weekends ago I also packaged assets and wehjit for > > Debian/Ubuntu. Karmic packages are available in my PPA: > > > > https://launchpad.net/~jderose/+archive/ppa > > > > Sorry the patch is so large, subsequent ones wont be. > > > > > > > > > > > Jason, > > The patch removes 4300 lines and adds 1000. Is this correct or we are > missing something? This is correct... the big deletion is because the MooTools JavaScript library is now delivered in wehjit (the widget library). So I guess this patch isn't crazy big, but it touches a bunch of files. From jderose at redhat.com Tue Oct 13 20:35:49 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 13 Oct 2009 14:35:49 -0600 Subject: [Freeipa-devel] [PATCH] jderose 017-2 Giant webui patch take 2 In-Reply-To: <4AD4D353.30508@redhat.com> References: <1255456439.11621.64.camel@jgd-dsk> <4AD4D353.30508@redhat.com> Message-ID: <1255466149.11621.69.camel@jgd-dsk> On Tue, 2009-10-13 at 15:21 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > Okay, finally here is the revised webui patch. Since the last version, > > I: > > > > * Ported to various API changed between wehjit 0.0.1 and 0.1.0 > > > > * Removed the session.py stuff, which will be in a separate patch > > > > * Added the plugin browser to help developers inspect the plugins > > > > The webui is still in a similar "dumb" state till I extend various > > meta-data in ipalib, which I will work on this week and will quickly get > > the UI into a more impressive state. I just can't let this patch get > > any larger... stop the madness! ;) There currently isn't a top-level > > webui-page at /ipa/ui, but pages exist for each command plugin, > > i.e., /ipa/ui/user_add > > > > This patch is big, but tries to be non-intrusive: the new webui stuff > > only runs from the new lite-server.py script, not for the installed > > version running under Apache. As far as I know, no existing > > functionality is disrupted by this patch. After making the meta-data > > changes, I will enable the new functionality under Apache also. > > > > I hope everyone will find the plugin-browser quite helpful. To run it, > > launch lite-server.py like this: > > > > ./lite-server.py > > > > And then point your browser to: > > > > http://127.0.0.1:8888/ipa/ui/Command > > > > All plugins in all namespaces are available in the browser, but details > > are currently only available for the Command and Object namespaces. I > > will also soon add an easy way to render the plugin browser to static > > pages to put on freeipa.org. > > > > This patch requires python-wehjit and python-assets, which are in > > Fedora12 and rawhide. Or you can install from tarballs here: > > > > http://jderose.fedorapeople.org/assets/current/ > > > > http://jderose.fedorapeople.org/wehjit/current/ > > > > A couple of weekends ago I also packaged assets and wehjit for > > Debian/Ubuntu. Karmic packages are available in my PPA: > > > > https://launchpad.net/~jderose/+archive/ppa > > > > Sorry the patch is so large, subsequent ones wont be. > > ack. > > rob That's the ol' pepper. Pushed to master. From jdennis at redhat.com Tue Oct 13 21:58:00 2009 From: jdennis at redhat.com (John Dennis) Date: Tue, 13 Oct 2009 17:58:00 -0400 Subject: [Freeipa-devel] add_global_options() vs. build_global_parser() Message-ID: <4AD4F7E8.4040302@redhat.com> ipalib.util defines the function add_global_options() which is never called but seems nearly identical to API.build_global_parser(). Why? Should API.build_global_parser() be calling util.add_global_options() or should util.add_global_options() be nuked as cruft? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Tue Oct 13 22:05:07 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 13 Oct 2009 16:05:07 -0600 Subject: [Freeipa-devel] add_global_options() vs. build_global_parser() In-Reply-To: <4AD4F7E8.4040302@redhat.com> References: <4AD4F7E8.4040302@redhat.com> Message-ID: <1255471507.11621.70.camel@jgd-dsk> On Tue, 2009-10-13 at 17:58 -0400, John Dennis wrote: > ipalib.util defines the function add_global_options() which is never > called but seems nearly identical to API.build_global_parser(). Why? > > Should API.build_global_parser() be calling util.add_global_options() or > should util.add_global_options() be nuked as cruft? It should be nuked as cruft. From jderose at redhat.com Wed Oct 14 04:45:43 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 13 Oct 2009 22:45:43 -0600 Subject: [Freeipa-devel] [PATCH] jderose 019 remove some cruft Message-ID: <1255495543.24227.1.camel@jgd-dsk> This removes the util.add_global_options() function and the frontend.Application class, neither of which are now needed. From jderose at redhat.com Wed Oct 14 04:50:05 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 13 Oct 2009 22:50:05 -0600 Subject: [Freeipa-devel] [PATCH] jderose 019 remove some cruft In-Reply-To: <1255495543.24227.1.camel@jgd-dsk> References: <1255495543.24227.1.camel@jgd-dsk> Message-ID: <1255495805.24227.2.camel@jgd-dsk> On Tue, 2009-10-13 at 22:45 -0600, Jason Gerard DeRose wrote: > This removes the util.add_global_options() function and the > frontend.Application class, neither of which are now needed. And *this* actually attaches the patch. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-019-remove-some-cruft.patch Type: text/x-patch Size: 6697 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 14 15:53:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Oct 2009 11:53:58 -0400 Subject: [Freeipa-devel] [PATCH] 296 work with newer schema layout of 389-DS Message-ID: <4AD5F416.6080906@redhat.com> The HEAD branch of upstream of 389-DS has lots new schema stuff. We have to work around some incompatibilities with the DNS schema in 05rfc2247.ldif but this isn't required in the HEAD, so don't fail if we can't replace this file. It isn't needed in newer versions of DS. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-296-ds.patch Type: application/mbox Size: 1804 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Wed Oct 14 21:16:41 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 14 Oct 2009 15:16:41 -0600 Subject: [Freeipa-devel] [PATCH] jderose 020 Make plugin browser show plugin parent class Message-ID: <1255555001.24227.5.camel@jgd-dsk> It's very helpful if the plugin browser shows the parent class (or classes) that a plugin subclasses from. This small patch adds this feature. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-020-Make-plugin-browser-show-plugin-parent-class.patch Type: text/x-patch Size: 1333 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 14 21:21:00 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Oct 2009 17:21:00 -0400 Subject: [Freeipa-devel] [PATCH] jderose 020 Make plugin browser show plugin parent class In-Reply-To: <1255555001.24227.5.camel@jgd-dsk> References: <1255555001.24227.5.camel@jgd-dsk> Message-ID: <4AD640BC.3080604@redhat.com> Jason Gerard DeRose wrote: > It's very helpful if the plugin browser shows the parent class (or > classes) that a plugin subclasses from. This small patch adds this > feature. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 14 21:21:24 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Oct 2009 17:21:24 -0400 Subject: [Freeipa-devel] [PATCH] jderose 019 remove some cruft In-Reply-To: <1255495805.24227.2.camel@jgd-dsk> References: <1255495543.24227.1.camel@jgd-dsk> <1255495805.24227.2.camel@jgd-dsk> Message-ID: <4AD640D4.2000301@redhat.com> Jason Gerard DeRose wrote: > On Tue, 2009-10-13 at 22:45 -0600, Jason Gerard DeRose wrote: >> This removes the util.add_global_options() function and the >> frontend.Application class, neither of which are now needed. > > And *this* actually attaches the patch. ;) > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Thu Oct 15 06:29:58 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 15 Oct 2009 00:29:58 -0600 Subject: [Freeipa-devel] [PATCH] jderose 020 Make plugin browser show plugin parent class In-Reply-To: <4AD640BC.3080604@redhat.com> References: <1255555001.24227.5.camel@jgd-dsk> <4AD640BC.3080604@redhat.com> Message-ID: <1255588198.24227.6.camel@jgd-dsk> On Wed, 2009-10-14 at 17:21 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > It's very helpful if the plugin browser shows the parent class (or > > classes) that a plugin subclasses from. This small patch adds this > > feature. > > ack pushed to master. From jderose at redhat.com Thu Oct 15 06:30:07 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 15 Oct 2009 00:30:07 -0600 Subject: [Freeipa-devel] [PATCH] jderose 019 remove some cruft In-Reply-To: <4AD640D4.2000301@redhat.com> References: <1255495543.24227.1.camel@jgd-dsk> <1255495805.24227.2.camel@jgd-dsk> <4AD640D4.2000301@redhat.com> Message-ID: <1255588207.24227.7.camel@jgd-dsk> On Wed, 2009-10-14 at 17:21 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > On Tue, 2009-10-13 at 22:45 -0600, Jason Gerard DeRose wrote: > >> This removes the util.add_global_options() function and the > >> frontend.Application class, neither of which are now needed. > > > > And *this* actually attaches the patch. ;) > > > > ack pushed to master. From ssorce at redhat.com Thu Oct 15 12:18:34 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Oct 2009 08:18:34 -0400 Subject: [Freeipa-devel] [PATCH] 296 work with newer schema layout of 389-DS In-Reply-To: <4AD5F416.6080906@redhat.com> References: <4AD5F416.6080906@redhat.com> Message-ID: <1255609114.22793.41.camel@localhost.localdomain> On Wed, 2009-10-14 at 11:53 -0400, Rob Crittenden wrote: > The HEAD branch of upstream of 389-DS has lots new schema stuff. We have > to work around some incompatibilities with the DNS schema in > 05rfc2247.ldif but this isn't required in the HEAD, so don't fail if we > can't replace this file. It isn't needed in newer versions of DS. Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Oct 15 12:20:14 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Oct 2009 08:20:14 -0400 Subject: [Freeipa-devel] [PATCH] 293 use fqdn In-Reply-To: <4AD34C06.3010700@redhat.com> References: <4AD34C06.3010700@redhat.com> Message-ID: <1255609214.22793.42.camel@localhost.localdomain> On Mon, 2009-10-12 at 11:32 -0400, Rob Crittenden wrote: > Use getfqdn() instead of the gethostname(). self.ca_host could end up > as > the same value as self.host and if this isn't fully-qualified then > SSL > client requests won't work (we query the CA over SSL). Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Thu Oct 15 13:28:05 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 15 Oct 2009 15:28:05 +0200 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task In-Reply-To: <4AD36DD0.4010307@redhat.com> References: <4AD36DD0.4010307@redhat.com> Message-ID: <4AD72365.7040900@redhat.com> Rob Crittenden wrote: > One of the last steps of an install is to run through any updates. This > change adds a sleep() prior to calling tasks to ensure postop writes are > done > > We were seeing a rare deadlock of DS when creating the memberOf task > because one thread was adding memberOf in a postop while another was > trying to create an index and this was causing a PRLock deadlock. > > rob > sleep might not be the best synchronization mechanism out there, but I think that in this case it is pretty much the only one available and it gets the job done, so ack. Pavel From ssorce at redhat.com Thu Oct 15 13:40:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Oct 2009 09:40:15 -0400 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task In-Reply-To: <4AD72365.7040900@redhat.com> References: <4AD36DD0.4010307@redhat.com> <4AD72365.7040900@redhat.com> Message-ID: <1255614015.22793.56.camel@localhost.localdomain> On Thu, 2009-10-15 at 15:28 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > One of the last steps of an install is to run through any updates. This > > change adds a sleep() prior to calling tasks to ensure postop writes are > > done > > > > We were seeing a rare deadlock of DS when creating the memberOf task > > because one thread was adding memberOf in a postop while another was > > trying to create an index and this was causing a PRLock deadlock. > > > > rob > > > sleep might not be the best synchronization mechanism out there, but I think > that in this case it is pretty much the only one available and it gets the job > done, so ack. So are we covering a DS bug here ? Or are we doing an asynchronous ldap request when we should do a synchronous one and wait for it to finish (I've fixed another place where we were doing that and racing against our own requests) ? Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Thu Oct 15 15:15:59 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 15 Oct 2009 08:15:59 -0700 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task In-Reply-To: <1255614015.22793.56.camel@localhost.localdomain> References: <4AD36DD0.4010307@redhat.com> <4AD72365.7040900@redhat.com> <1255614015.22793.56.camel@localhost.localdomain> Message-ID: <4AD73CAF.3000606@redhat.com> On 10/15/2009 06:40 AM, Simo Sorce wrote: > On Thu, 2009-10-15 at 15:28 +0200, Pavel Zuna wrote: > >> Rob Crittenden wrote: >> >>> One of the last steps of an install is to run through any updates. This >>> change adds a sleep() prior to calling tasks to ensure postop writes are >>> done >>> >>> We were seeing a rare deadlock of DS when creating the memberOf task >>> because one thread was adding memberOf in a postop while another was >>> trying to create an index and this was causing a PRLock deadlock. >>> >>> rob >>> >>> >> sleep might not be the best synchronization mechanism out there, but I think >> that in this case it is pretty much the only one available and it gets the job >> done, so ack. >> > So are we covering a DS bug here ? Or are we doing an asynchronous ldap > request when we should do a synchronous one and wait for it to finish > (I've fixed another place where we were doing that and racing against > our own requests) ? > It has nothing to do with the way you are performing your LDAP operations. The issue really stems from what I consider to be a bug in NSPR's implementation of reader-writer locks. It is documented that a single thread can hold multiple reader locks safely, but I've found that to not exactly be the case. The NSPR implementation favors writers, so a thread waiting for the writer lock will block attempts by other threads to get a reader lock. The problem is that we use reader locks in a re-entrant fashion, so a thread that already has a reader lock can be blocked when attempting to get a second reader lock due to a waiting writer. This thread in turn blocks the writer thread since it already holds a reader lock. I have proposed a solution to the NSPR developers that would allow an attempt to get a reader lock to go through even if a writer is waiting if the requesting thread already has another reader lock. I'm hoping that this can be resolved in NSPR, otherwise we may have to change DS to use the pthread_rwlock_* interfaces instead. The sleep is a temporary workaround. This issue should not arise in normal operation since the lock in question is around the backend struct, which is only modified when there is some sort of database maintenance operation (such as the reindexing task that Rob triggered it with). > Simo. > > From ssorce at redhat.com Thu Oct 15 16:08:38 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Oct 2009 12:08:38 -0400 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task In-Reply-To: <4AD73CAF.3000606@redhat.com> References: <4AD36DD0.4010307@redhat.com> <4AD72365.7040900@redhat.com> <1255614015.22793.56.camel@localhost.localdomain> <4AD73CAF.3000606@redhat.com> Message-ID: <1255622918.22793.64.camel@localhost.localdomain> On Thu, 2009-10-15 at 08:15 -0700, Nathan Kinder wrote: > On 10/15/2009 06:40 AM, Simo Sorce wrote: > > On Thu, 2009-10-15 at 15:28 +0200, Pavel Zuna wrote: > > > >> Rob Crittenden wrote: > >> > >>> One of the last steps of an install is to run through any updates. This > >>> change adds a sleep() prior to calling tasks to ensure postop writes are > >>> done > >>> > >>> We were seeing a rare deadlock of DS when creating the memberOf task > >>> because one thread was adding memberOf in a postop while another was > >>> trying to create an index and this was causing a PRLock deadlock. > >>> > >>> rob > >>> > >>> > >> sleep might not be the best synchronization mechanism out there, but I think > >> that in this case it is pretty much the only one available and it gets the job > >> done, so ack. > >> > > So are we covering a DS bug here ? Or are we doing an asynchronous ldap > > request when we should do a synchronous one and wait for it to finish > > (I've fixed another place where we were doing that and racing against > > our own requests) ? > > > It has nothing to do with the way you are performing your LDAP operations. > > The issue really stems from what I consider to be a bug in NSPR's > implementation of reader-writer locks. It is documented that a single > thread can hold multiple reader locks safely, but I've found that to not > exactly be the case. The NSPR implementation favors writers, so a > thread waiting for the writer lock will block attempts by other threads > to get a reader lock. The problem is that we use reader locks in a > re-entrant fashion, so a thread that already has a reader lock can be > blocked when attempting to get a second reader lock due to a waiting > writer. This thread in turn blocks the writer thread since it already > holds a reader lock. > > I have proposed a solution to the NSPR developers that would allow an > attempt to get a reader lock to go through even if a writer is waiting > if the requesting thread already has another reader lock. I'm hoping > that this can be resolved in NSPR, otherwise we may have to change DS to > use the pthread_rwlock_* interfaces instead. > > The sleep is a temporary workaround. This issue should not arise in > normal operation since the lock in question is around the backend > struct, which is only modified when there is some sort of database > maintenance operation (such as the reindexing task that Rob triggered it > with). Nathan, thanks for the explanation, very much appreciated. Simo. -- Simo Sorce * Red Hat, Inc * New York From jderose at redhat.com Thu Oct 15 21:04:41 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 15 Oct 2009 15:04:41 -0600 Subject: [Freeipa-devel] [PATCH] jderose 021 Fixed try/except/finally for Python 2.4 compatability Message-ID: <1255640681.9769.4.camel@jgd-dsk> This should fix the build failure in the daily build. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-021-Fixed-try-except-finally-for-Python-2.4-compatabilit.patch Type: text/x-patch Size: 2485 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 16 00:53:51 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Oct 2009 20:53:51 -0400 Subject: [Freeipa-devel] [PATCH] jderose 021 Fixed try/except/finally for Python 2.4 compatability In-Reply-To: <1255640681.9769.4.camel@jgd-dsk> References: <1255640681.9769.4.camel@jgd-dsk> Message-ID: <4AD7C41F.7090808@redhat.com> Jason Gerard DeRose wrote: > This should fix the build failure in the daily build. > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 16 13:14:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 09:14:33 -0400 Subject: [Freeipa-devel] [PATCH] fix for python < 2.6 Message-ID: <4AD871B9.7010906@redhat.com> parse_qs is in cgi on Python < 2.6, use that instead. Python 2.6's cgi module calls the parse_qs in urlparse for backwards compatibility. I had originally done a try/except ImportError but since this is already specifically handled for backwards compatibility by the cgi module I went with that instead. I pushed this out under the 1-liner rule. >From b8cadd90bd4af57108c9ef2e4d7a450987ded8aa Mon Sep 17 00:00:00 2001 From: Rob Crittenden Date: Fri, 16 Oct 2009 09:12:17 -0400 Subject: [PATCH] parse_qs is in cgi on Python < 2.6, use that instead Python 2.6's cgi module calls the parse_qs in urlparse for backwards compatibility --- ipaserver/rpcserver.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py index 72f2219..e57246f 100644 --- a/ipaserver/rpcserver.py +++ b/ipaserver/rpcserver.py @@ -23,7 +23,7 @@ RPC server. Also see the `ipalib.rpc` module. """ -from urlparse import parse_qs +from cgi import parse_qs from xmlrpclib import Fault from ipalib.backend import Executioner from ipalib.errors import PublicError, InternalError, CommandError, JSONError -- 1.6.2.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 16 13:59:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 09:59:15 -0400 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task In-Reply-To: <1255614015.22793.56.camel@localhost.localdomain> References: <4AD36DD0.4010307@redhat.com> <4AD72365.7040900@redhat.com> <1255614015.22793.56.camel@localhost.localdomain> Message-ID: <4AD87C33.5000601@redhat.com> Simo Sorce wrote: > On Thu, 2009-10-15 at 15:28 +0200, Pavel Zuna wrote: >> Rob Crittenden wrote: >>> One of the last steps of an install is to run through any updates. This >>> change adds a sleep() prior to calling tasks to ensure postop writes are >>> done >>> >>> We were seeing a rare deadlock of DS when creating the memberOf task >>> because one thread was adding memberOf in a postop while another was >>> trying to create an index and this was causing a PRLock deadlock. >>> >>> rob >>> >> sleep might not be the best synchronization mechanism out there, but I think >> that in this case it is pretty much the only one available and it gets the job >> done, so ack. > > So are we covering a DS bug here ? Or are we doing an asynchronous ldap > request when we should do a synchronous one and wait for it to finish > (I've fixed another place where we were doing that and racing against > our own requests) ? > > Simo. > This works around a bug in DS that was causing a deadlock. We are adding entries that write memberOf which is done in a postop. We then create an index for memberof and it is deadlocking. Updates are all done synchronously so the sleep should give the postop writes plenty of time to finish up (hoping this isn't famous last words). I think that given that this updater code has been around for quite some time and nobody has noticed until now means that the problem probably isn't that big so sleep() should work fine. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Fri Oct 16 18:02:05 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 16 Oct 2009 12:02:05 -0600 Subject: [Freeipa-devel] [PATCH] jderose 023 Fixed 'import json' for simplejson compatability Message-ID: <1255716125.13239.1.camel@jgd-dsk> This fixes `import json` for Python < 2.6. I'm just using the same compat.py from wehjit. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-023-Fixed-import-json-for-simplejson-compatability.patch Type: text/x-patch Size: 3821 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 16 18:49:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 14:49:59 -0400 Subject: [Freeipa-devel] [PATCH] jderose 023 Fixed 'import json' for simplejson compatability In-Reply-To: <1255716125.13239.1.camel@jgd-dsk> References: <1255716125.13239.1.camel@jgd-dsk> Message-ID: <4AD8C057.7070708@redhat.com> Jason Gerard DeRose wrote: > This fixes `import json` for Python < 2.6. I'm just using the same > compat.py from wehjit. > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Fri Oct 16 18:54:40 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 16 Oct 2009 12:54:40 -0600 Subject: [Freeipa-devel] [PATCH] jderose 023 Fixed 'import json' for simplejson compatability In-Reply-To: <4AD8C057.7070708@redhat.com> References: <1255716125.13239.1.camel@jgd-dsk> <4AD8C057.7070708@redhat.com> Message-ID: <1255719280.13239.2.camel@jgd-dsk> On Fri, 2009-10-16 at 14:49 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > This fixes `import json` for Python < 2.6. I'm just using the same > > compat.py from wehjit. > > > > > > ack pushed to master with incorrect copyright year fixed in compat.py From rcritten at redhat.com Fri Oct 16 18:55:55 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 14:55:55 -0400 Subject: [Freeipa-devel] [PATCH] 296 work with newer schema layout of 389-DS In-Reply-To: <1255609114.22793.41.camel@localhost.localdomain> References: <4AD5F416.6080906@redhat.com> <1255609114.22793.41.camel@localhost.localdomain> Message-ID: <4AD8C1BB.8030000@redhat.com> Simo Sorce wrote: > On Wed, 2009-10-14 at 11:53 -0400, Rob Crittenden wrote: >> The HEAD branch of upstream of 389-DS has lots new schema stuff. We have >> to work around some incompatibilities with the DNS schema in >> 05rfc2247.ldif but this isn't required in the HEAD, so don't fail if we >> can't replace this file. It isn't needed in newer versions of DS. > > Ack > Simo. > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 16 18:56:38 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 14:56:38 -0400 Subject: [Freeipa-devel] [PATCH] 293 use fqdn In-Reply-To: <1255609214.22793.42.camel@localhost.localdomain> References: <4AD34C06.3010700@redhat.com> <1255609214.22793.42.camel@localhost.localdomain> Message-ID: <4AD8C1E6.5050408@redhat.com> Simo Sorce wrote: > On Mon, 2009-10-12 at 11:32 -0400, Rob Crittenden wrote: >> Use getfqdn() instead of the gethostname(). self.ca_host could end up >> as >> the same value as self.host and if this isn't fully-qualified then >> SSL >> client requests won't work (we query the CA over SSL). > > Ack > > Simo. > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 16 18:56:57 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 14:56:57 -0400 Subject: [Freeipa-devel] [PATCH] 294 sleep before doing a task In-Reply-To: <4AD72365.7040900@redhat.com> References: <4AD36DD0.4010307@redhat.com> <4AD72365.7040900@redhat.com> Message-ID: <4AD8C1F9.8000001@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> One of the last steps of an install is to run through any updates. >> This change adds a sleep() prior to calling tasks to ensure postop >> writes are done >> >> We were seeing a rare deadlock of DS when creating the memberOf task >> because one thread was adding memberOf in a postop while another was >> trying to create an index and this was causing a PRLock deadlock. >> >> rob >> > sleep might not be the best synchronization mechanism out there, but I > think that in this case it is pretty much the only one available and it > gets the job done, so ack. > > Pavel pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 16 20:21:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Oct 2009 16:21:05 -0400 Subject: [Freeipa-devel] [PATCH] 297 use proper template string Message-ID: <4AD8D5B1.8050003@redhat.com> I goofed and didn't replace my test domain with a template string for some virtual operations. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-297-template.patch Type: application/mbox Size: 3031 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Fri Oct 16 20:36:17 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 16 Oct 2009 14:36:17 -0600 Subject: [Freeipa-devel] [PATCH] jderose 022 Change Password param Message-ID: <1255725377.13239.7.camel@jgd-dsk> This patch allows you do provide a Password as a two item tuple or list (the password plus the password confirmation). This is the most natural way for this to work through the UI. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-022-Change-Password-param.patch Type: text/x-patch Size: 2815 bytes Desc: not available URL: From jdennis at redhat.com Sat Oct 17 15:04:28 2009 From: jdennis at redhat.com (John Dennis) Date: Sat, 17 Oct 2009 11:04:28 -0400 Subject: [Freeipa-devel] Integer parameters Message-ID: <4AD9DCFC.1030200@redhat.com> I wanted to assure myself if a command was expecting an integer value, it could be input in whatever radix the user desires and be correctly converted. If I understand correctly this code is in parameters.py and is implemented by the _convert_scalar member function. The Int and Float classes derive from the Number class and inherit Number._convert_scalar which attempts to call the type (e.g. constructor). However the int class only supports base 10 radix strings in it's constructor, it will not do radix conversion. Shouldn't the Int parameter class have it's own _convert_scalar which invokes int(value, 0)? (Note: the second argument to the int constructor is the radix base, with 0 being a special value indicating the radix is to be derived from the prefix) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Sun Oct 18 00:59:21 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sat, 17 Oct 2009 18:59:21 -0600 Subject: [Freeipa-devel] [PATCH] jderose 024 Fixed compatability break in rpcserver.py Message-ID: <1255827561.2503.5.camel@jgd-dsk> This fixes an oops I missed that broke the IPA server when running under Apache. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-024-Fixed-compatability-break-in-rpcserver.patch Type: text/x-patch Size: 1143 bytes Desc: not available URL: From rcritten at redhat.com Sun Oct 18 01:12:48 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 17 Oct 2009 21:12:48 -0400 Subject: [Freeipa-devel] [PATCH] jderose 024 Fixed compatability break in rpcserver.py In-Reply-To: <1255827561.2503.5.camel@jgd-dsk> References: <1255827561.2503.5.camel@jgd-dsk> Message-ID: <4ADA6B90.5010802@redhat.com> Jason Gerard DeRose wrote: > This fixes an oops I missed that broke the IPA server when running under > Apache. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Sun Oct 18 01:28:03 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sat, 17 Oct 2009 19:28:03 -0600 Subject: [Freeipa-devel] [PATCH] jderose 024 Fixed compatability break in rpcserver.py In-Reply-To: <4ADA6B90.5010802@redhat.com> References: <1255827561.2503.5.camel@jgd-dsk> <4ADA6B90.5010802@redhat.com> Message-ID: <1255829283.2503.7.camel@jgd-dsk> On Sat, 2009-10-17 at 21:12 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > This fixes an oops I missed that broke the IPA server when running under > > Apache. > > ack pushed to master. From jderose at redhat.com Sun Oct 18 04:27:19 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sat, 17 Oct 2009 22:27:19 -0600 Subject: [Freeipa-devel] [PATCH] 297 use proper template string In-Reply-To: <4AD8D5B1.8050003@redhat.com> References: <4AD8D5B1.8050003@redhat.com> Message-ID: <1255840039.2503.8.camel@jgd-dsk> On Fri, 2009-10-16 at 16:21 -0400, Rob Crittenden wrote: > I goofed and didn't replace my test domain with a template string for > some virtual operations. > > rob ack. pushed to master. From jderose at redhat.com Sun Oct 18 05:52:01 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sat, 17 Oct 2009 23:52:01 -0600 Subject: [Freeipa-devel] [PATCH] 289 fix host admin acis In-Reply-To: <4AD32998.9010306@redhat.com> References: <4ACE505C.6010208@redhat.com> <4AD32998.9010306@redhat.com> Message-ID: <1255845121.2503.9.camel@jgd-dsk> On Mon, 2009-10-12 at 15:05 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > It appears I missed a couple of ACI's when we changed the DN format of > > hosts. > > > > rob > ack. > > Pavel ack. pushed to master. From jderose at redhat.com Sun Oct 18 05:54:03 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sat, 17 Oct 2009 23:54:03 -0600 Subject: [Freeipa-devel] [PATCH] 295 client Makefile target In-Reply-To: <4AD38B26.9070104@redhat.com> References: <4AD38B26.9070104@redhat.com> Message-ID: <1255845243.2503.11.camel@jgd-dsk> On Mon, 2009-10-12 at 16:01 -0400, Rob Crittenden wrote: > This adds a few new targets to the top-level Makefile, most notably > client and client-rpms. Using this you can more easily build just the > client pieces of IPA. > > rob ack. pushed to master. Did you mean to leave the `ipa` script out of setup-client.py? Isn't it handy to have it available on clients with Python available? From pzuna at redhat.com Mon Oct 19 13:06:27 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 19 Oct 2009 15:06:27 +0200 Subject: [Freeipa-devel] [PATCH] Allow adding entries with pre-hashed passwords, but don't generate keys for them. Message-ID: <4ADC6453.5050004@redhat.com> Fix bug #528922. https://bugzilla.redhat.com/show_bug.cgi?id=528922 Simo Sorce wrote: > On Thu, 2009-10-15 at 16:43 +0200, Pavel Zuna wrote: >> What Nalin said is exactly what I meant in my last email in this >> discussion (add >> -> hashed passwords fine, don't generate keys; modify -> hashed >> passwords bad, >> fail operation), but he explained it much better than I could ever do. >> I think >> that's the approach we should take. > > ack, > although I would also allow admins to always add pre-hashed passwords > even with modify operations. > > Simo. > This patch only fixes the ADD operation - I'll make a second one for modify next. Just to make sure: If we allow admins to modify passwords with pre-hashed ones, we also need to delete kerberos keys (and possibly other related attributes) if present, right? Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-adding-entries-with-pre-hashed-passwords-but.patch Type: application/mbox Size: 2196 bytes Desc: not available URL: From pzuna at redhat.com Mon Oct 19 13:12:57 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 19 Oct 2009 15:12:57 +0200 Subject: [Freeipa-devel] Integer parameters In-Reply-To: <4AD9DCFC.1030200@redhat.com> References: <4AD9DCFC.1030200@redhat.com> Message-ID: <4ADC65D9.20102@redhat.com> John Dennis wrote: > I wanted to assure myself if a command was expecting an integer value, > it could be input in whatever radix the user desires and be correctly > converted. If I understand correctly this code is in parameters.py and > is implemented by the _convert_scalar member function. The Int and Float > classes derive from the Number class and inherit Number._convert_scalar > which attempts to call the type (e.g. constructor). However the int > class only supports base 10 radix strings in it's constructor, it will > not do radix conversion. Shouldn't the Int parameter class have it's own > _convert_scalar which invokes int(value, 0)? (Note: the second argument > to the int constructor is the radix base, with 0 being a special value > indicating the radix is to be derived from the prefix) > Int only accepts base 10. As you say, we could extend _convert_scalar and have it accept different bases. The question is, do we need/want it to? If we do, then it shouldn't be too hard to implement (and I volunteer to do it). Pavel From pzuna at redhat.com Mon Oct 19 13:14:36 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 19 Oct 2009 15:14:36 +0200 Subject: [Freeipa-devel] [PATCH] jderose 022 Change Password param In-Reply-To: <1255725377.13239.7.camel@jgd-dsk> References: <1255725377.13239.7.camel@jgd-dsk> Message-ID: <4ADC663C.6030004@redhat.com> Jason Gerard DeRose wrote: > This patch allows you do provide a Password as a two item tuple or list > (the password plus the password confirmation). This is the most natural > way for this to work through the UI. > ack. Pavel From ssorce at redhat.com Mon Oct 19 13:31:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 19 Oct 2009 09:31:15 -0400 Subject: [Freeipa-devel] Re: [PATCH] Allow adding entries with pre-hashed passwords, but don't generate keys for them. In-Reply-To: <4ADC6453.5050004@redhat.com> References: <4ADC6453.5050004@redhat.com> Message-ID: <1255959075.8426.8.camel@localhost.localdomain> On Mon, 2009-10-19 at 15:06 +0200, Pavel Zuna wrote: > This patch only fixes the ADD operation - I'll make a second one for > modify > next. Just to make sure: If we allow admins to modify passwords with > pre-hashed > ones, we also need to delete kerberos keys (and possibly other > related > attributes) if present, right? Only KrbPrincipalKey I'd say. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Mon Oct 19 14:24:27 2009 From: jdennis at redhat.com (John Dennis) Date: Mon, 19 Oct 2009 10:24:27 -0400 Subject: [Freeipa-devel] Integer parameters In-Reply-To: <4ADC65D9.20102@redhat.com> References: <4AD9DCFC.1030200@redhat.com> <4ADC65D9.20102@redhat.com> Message-ID: <4ADC769B.5070606@redhat.com> On 10/19/2009 09:12 AM, Pavel Zuna wrote: > John Dennis wrote: >> I wanted to assure myself if a command was expecting an integer value, >> it could be input in whatever radix the user desires and be correctly >> converted. If I understand correctly this code is in parameters.py and >> is implemented by the _convert_scalar member function. The Int and >> Float classes derive from the Number class and inherit >> Number._convert_scalar which attempts to call the type (e.g. >> constructor). However the int class only supports base 10 radix >> strings in it's constructor, it will not do radix conversion. >> Shouldn't the Int parameter class have it's own _convert_scalar which >> invokes int(value, 0)? (Note: the second argument to the int >> constructor is the radix base, with 0 being a special value indicating >> the radix is to be derived from the prefix) >> > Int only accepts base 10. As you say, we could extend _convert_scalar > and have it accept different bases. The question is, do we need/want it > to? If we do, then it shouldn't be too hard to implement (and I > volunteer to do it). Thanks, but I've already made the code change and it will show up in a patch shortly. My main concern was this would alter the UI (accepting a radix other than base 10) and I wanted to make sure this did not occur without some discussion and/or awareness of the change. My personal feeling is the desired behavior for our interfaces is: * By default all integers are accepted as base 10 and presented in the UI as base 10. * However to be friendly and to conform to some other external conventions, it should be possible to supply a value in hex and have the UI properly handle it. It's less clear to me whether the UI should ever present an integral value in hex even if there is some president for that particular value being presented in hex. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Mon Oct 19 18:27:16 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 19 Oct 2009 12:27:16 -0600 Subject: [Freeipa-devel] [PATCH] jderose 022 Change Password param In-Reply-To: <4ADC663C.6030004@redhat.com> References: <1255725377.13239.7.camel@jgd-dsk> <4ADC663C.6030004@redhat.com> Message-ID: <1255976836.11279.0.camel@jgd-dsk> On Mon, 2009-10-19 at 15:14 +0200, Pavel Zuna wrote: > Jason Gerard DeRose wrote: > > This patch allows you do provide a Password as a two item tuple or list > > (the password plus the password confirmation). This is the most natural > > way for this to work through the UI. > > > ack. > > Pavel pushed to master. From jderose at redhat.com Mon Oct 19 18:38:56 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 19 Oct 2009 12:38:56 -0600 Subject: [Freeipa-devel] Integer parameters In-Reply-To: <4ADC769B.5070606@redhat.com> References: <4AD9DCFC.1030200@redhat.com> <4ADC65D9.20102@redhat.com> <4ADC769B.5070606@redhat.com> Message-ID: <1255977536.11279.5.camel@jgd-dsk> On Mon, 2009-10-19 at 10:24 -0400, John Dennis wrote: > On 10/19/2009 09:12 AM, Pavel Zuna wrote: > > John Dennis wrote: > >> I wanted to assure myself if a command was expecting an integer value, > >> it could be input in whatever radix the user desires and be correctly > >> converted. If I understand correctly this code is in parameters.py and > >> is implemented by the _convert_scalar member function. The Int and > >> Float classes derive from the Number class and inherit > >> Number._convert_scalar which attempts to call the type (e.g. > >> constructor). However the int class only supports base 10 radix > >> strings in it's constructor, it will not do radix conversion. > >> Shouldn't the Int parameter class have it's own _convert_scalar which > >> invokes int(value, 0)? (Note: the second argument to the int > >> constructor is the radix base, with 0 being a special value indicating > >> the radix is to be derived from the prefix) > >> > > Int only accepts base 10. As you say, we could extend _convert_scalar > > and have it accept different bases. The question is, do we need/want it > > to? If we do, then it shouldn't be too hard to implement (and I > > volunteer to do it). > > Thanks, but I've already made the code change and it will show up in a > patch shortly. My main concern was this would alter the UI (accepting a > radix other than base 10) and I wanted to make sure this did not occur > without some discussion and/or awareness of the change. > > My personal feeling is the desired behavior for our interfaces is: > > * By default all integers are accepted as base 10 and presented in the > UI as base 10. > > * However to be friendly and to conform to some other external > conventions, it should be possible to supply a value in hex and have the > UI properly handle it. It's less clear to me whether the UI should ever > present an integral value in hex even if there is some president for > that particular value being presented in hex. > I think this sounds reasonable: allow int's to be specified in any base for which a Python literal repr exist (so I think that's base 10, 16, 8, and 2), but always display base 10 to the user. From rcritten at redhat.com Tue Oct 20 15:58:10 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Oct 2009 11:58:10 -0400 Subject: [Freeipa-devel] [PATCH] 298 more GER helpers Message-ID: <4ADDDE12.2020901@redhat.com> Add 2 new Get Effective Rights helpers for adding and deleting entries. These will be useful in the UI for determining what things a user can do. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-298-ger.patch Type: application/mbox Size: 1759 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Oct 20 16:02:44 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Oct 2009 12:02:44 -0400 Subject: [Freeipa-devel] [PATCH] 299 request certs for other hosts Message-ID: <4ADDDF24.2040103@redhat.com> First pass at enforcing certificates be requested from same host We want to only allow a machine to request a certificate for itself, not for other machines. I've added a new taksgroup which will allow this. The requesting IP is resolved and compared to the subject of the CSR to determine if they are the same host. The same is done with the service principal. Subject alt names are not queried yet. This does not yet grant machines actual permission to request certificates yet, that is still limited to the taskgroup request_certs. This also fixes some minor typos I discovered. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-299-cert.patch Type: application/mbox Size: 15851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Oct 20 20:46:03 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Oct 2009 16:46:03 -0400 Subject: [Freeipa-devel] access control for cert generation Message-ID: <4ADE218B.60602@redhat.com> I touched on this a little in IRC, figured I'd move it to the list for a fuller conversation. I'm in the process of adding access controls to machines requesting certificates for themselves. Let me first show what happens when a certificate request occurs: - Some authenticated entity generates a CSR and submits a request. This request consists of a service principal name and the CSR - If the hostname of the CSR matches the hostname of the requestor it is passed to the CA (optionally an entity may be granted to issue certs for any host) - the CA automatically issues a certificate and returns the cert blob - If the service already exists, the cert blob is added to the entry - If not and it was requested, a service record is created for the service principal - Finally the cert text is returned to the client So a couple of things here: - Do we want any machine to be able to generate certificates for itself? Steve was a bit nervous about this. - If not, do we want a group to specify which machines can do requests? Could get cumbersome to manage at some point but otherwise it would be a manual process to say "Steve's laptop can't request certs". - machines will need permission to write service entries. Do we want to grant this access to all machines? I might need some help from the 389 team to write an ACI that lets us control machines only writing service principals for themselves. I'd essentially need to pull out the hostname part of the krbprincipalname and somehow use that to limit write access to host/hostname at REALM. I can do it in code but then someone could do an ldapmodify to add a service and go around our XML-RPC interface (very naughty). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Tue Oct 20 21:02:10 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 20 Oct 2009 17:02:10 -0400 Subject: [Freeipa-devel] access control for cert generation In-Reply-To: <4ADE218B.60602@redhat.com> References: <4ADE218B.60602@redhat.com> Message-ID: <4ADE2552.3030702@redhat.com> Rob Crittenden wrote: > I touched on this a little in IRC, figured I'd move it to the list for > a fuller conversation. > > I'm in the process of adding access controls to machines requesting > certificates for themselves. > > Let me first show what happens when a certificate request occurs: > > - Some authenticated entity generates a CSR and submits a request. > This request consists of a service principal name and the CSR > - If the hostname of the CSR matches the hostname of the requestor it > is passed to the CA (optionally an entity may be granted to issue > certs for any host) > - the CA automatically issues a certificate and returns the cert blob > - If the service already exists, the cert blob is added to the entry > - If not and it was requested, a service record is created for the > service principal > - Finally the cert text is returned to the client > > So a couple of things here: > > - Do we want any machine to be able to generate certificates for > itself? Steve was a bit nervous about this. I think there is a difference between host cert for the system and service cert for the same host. Issuance or tracking of the service certs needs to be initiated by the user that has rights to request tracking or creation of a specific service cert. So without this initial authorization I do not thin the host can do anything with the cert for the service running on the host. This means that the initial cert tracking issuance request should create some kind of the attribute that will be used in the ACI rule to check if this cert can then later on be re-requested by the host. Does this approach make sense? > - If not, do we want a group to specify which machines can do > requests? Could get cumbersome to manage at some point but otherwise > it would be a manual process to say "Steve's laptop can't request certs". > - machines will need permission to write service entries. Do we want > to grant this access to all machines? I might need some help from the > 389 team to write an ACI that lets us control machines only writing > service principals for themselves. I'd essentially need to pull out > the hostname part of the krbprincipalname and somehow use that to > limit write access to host/hostname at REALM. I can do it in code but > then someone could do an ldapmodify to add a service and go around our > XML-RPC interface (very naughty). > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Oct 20 21:28:03 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Oct 2009 17:28:03 -0400 Subject: [Freeipa-devel] access control for cert generation In-Reply-To: <4ADE2552.3030702@redhat.com> References: <4ADE218B.60602@redhat.com> <4ADE2552.3030702@redhat.com> Message-ID: <4ADE2B63.3050704@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> I touched on this a little in IRC, figured I'd move it to the list for >> a fuller conversation. >> >> I'm in the process of adding access controls to machines requesting >> certificates for themselves. >> >> Let me first show what happens when a certificate request occurs: >> >> - Some authenticated entity generates a CSR and submits a request. >> This request consists of a service principal name and the CSR >> - If the hostname of the CSR matches the hostname of the requestor it >> is passed to the CA (optionally an entity may be granted to issue >> certs for any host) >> - the CA automatically issues a certificate and returns the cert blob >> - If the service already exists, the cert blob is added to the entry >> - If not and it was requested, a service record is created for the >> service principal >> - Finally the cert text is returned to the client >> >> So a couple of things here: >> >> - Do we want any machine to be able to generate certificates for >> itself? Steve was a bit nervous about this. > > I think there is a difference between host cert for the system and > service cert for the same host. Not really. What is this host cert going to be used for? The only kind of cert we currently issue is for SSL servers, not for identity (e.g. no client certs). > Issuance or tracking of the service certs needs to be initiated by the > user that has rights to request tracking or creation of a specific > service cert. Ok, that's fine, but it precludes generating an SSL cert in a kickstart without providing some sort of credential. I was planning on using the host keytab to get the certificate. If that is out then my life becomes much, much simpler. > So without this initial authorization I do not thin the host can do > anything with the cert for the service running on the host. > This means that the initial cert tracking issuance request should create > some kind of the attribute that will be used in the ACI rule to check if > this cert can then later on be re-requested by the host. > > Does this approach make sense? We currently have access controls for users to request certs for hosts. That should be adequate to cover this. So it sounds like there is nothing to do here, move along :-) rob >> - If not, do we want a group to specify which machines can do >> requests? Could get cumbersome to manage at some point but otherwise >> it would be a manual process to say "Steve's laptop can't request certs". >> - machines will need permission to write service entries. Do we want >> to grant this access to all machines? I might need some help from the >> 389 team to write an ACI that lets us control machines only writing >> service principals for themselves. I'd essentially need to pull out >> the hostname part of the krbprincipalname and somehow use that to >> limit write access to host/hostname at REALM. I can do it in code but >> then someone could do an ldapmodify to add a service and go around our >> XML-RPC interface (very naughty). >> >> rob >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 21 02:24:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Oct 2009 22:24:20 -0400 Subject: [Freeipa-devel] [PATCH] 300 fix hostname in dns lookup Message-ID: <4ADE70D4.8060109@redhat.com> When looking up the hostname for doing cert comparisons I wasn't removing the trailing dot (so nothing matched). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-300-cert.patch Type: application/mbox Size: 1056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 21 02:24:57 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Oct 2009 22:24:57 -0400 Subject: [Freeipa-devel] [PATCH] 301 require host before service Message-ID: <4ADE70F9.9070506@redhat.com> Require that a host exist before trying to add a service for it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-301-service.patch Type: application/mbox Size: 1030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Wed Oct 21 10:43:03 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 21 Oct 2009 04:43:03 -0600 Subject: [Freeipa-devel] [PATCH] 298 more GER helpers In-Reply-To: <4ADDDE12.2020901@redhat.com> References: <4ADDDE12.2020901@redhat.com> Message-ID: <1256121783.17079.30.camel@jgd-dsk> On Tue, 2009-10-20 at 11:58 -0400, Rob Crittenden wrote: > Add 2 new Get Effective Rights helpers for adding and deleting entries. > These will be useful in the UI for determining what things a user can do. > > rob ack. pushed to master. From jderose at redhat.com Wed Oct 21 10:50:53 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 21 Oct 2009 04:50:53 -0600 Subject: [Freeipa-devel] [PATCH] 299 request certs for other hosts In-Reply-To: <4ADDDF24.2040103@redhat.com> References: <4ADDDF24.2040103@redhat.com> Message-ID: <1256122253.23051.0.camel@jgd-dsk> On Tue, 2009-10-20 at 12:02 -0400, Rob Crittenden wrote: > First pass at enforcing certificates be requested from same host > > We want to only allow a machine to request a certificate for itself, not > for other machines. I've added a new taksgroup which will allow this. > > The requesting IP is resolved and compared to the subject of the CSR to > determine if they are the same host. The same is done with the service > principal. Subject alt names are not queried yet. > > This does not yet grant machines actual permission to request > certificates yet, that is still limited to the taskgroup request_certs. > > This also fixes some minor typos I discovered. > > rob ack. pushed to master. From jderose at redhat.com Wed Oct 21 10:51:10 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 21 Oct 2009 04:51:10 -0600 Subject: [Freeipa-devel] [PATCH] 300 fix hostname in dns lookup In-Reply-To: <4ADE70D4.8060109@redhat.com> References: <4ADE70D4.8060109@redhat.com> Message-ID: <1256122271.23051.1.camel@jgd-dsk> On Tue, 2009-10-20 at 22:24 -0400, Rob Crittenden wrote: > When looking up the hostname for doing cert comparisons I wasn't > removing the trailing dot (so nothing matched). > > rob ack. pushed to master. From jderose at redhat.com Wed Oct 21 10:51:18 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 21 Oct 2009 04:51:18 -0600 Subject: [Freeipa-devel] [PATCH] 301 require host before service In-Reply-To: <4ADE70F9.9070506@redhat.com> References: <4ADE70F9.9070506@redhat.com> Message-ID: <1256122278.23051.2.camel@jgd-dsk> On Tue, 2009-10-20 at 22:24 -0400, Rob Crittenden wrote: > Require that a host exist before trying to add a service for it. > > rob ack. pushed to master. From ssorce at redhat.com Tue Oct 20 22:31:47 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 20 Oct 2009 18:31:47 -0400 Subject: [Freeipa-devel] [PATCH] 299 request certs for other hosts In-Reply-To: <4ADDDF24.2040103@redhat.com> References: <4ADDDF24.2040103@redhat.com> Message-ID: <1256077907.2965.28.camel@localhost.localdomain> On Tue, 2009-10-20 at 12:02 -0400, Rob Crittenden wrote: > First pass at enforcing certificates be requested from same host > > We want to only allow a machine to request a certificate for itself, not > for other machines. I've added a new taksgroup which will allow this. > > The requesting IP is resolved and compared to the subject of the CSR to > determine if they are the same host. The same is done with the service > principal. Subject alt names are not queried yet. Why do you check the IP address? That would prevent any machine behind a NAT to work. It also doesn't work if the DNS doesn't resolve PTR addresses. Finally it doesn't really grant you who made the request (any user on that machine will come from the same IP address. I'd think you use the kerberos principal name you can find in the authentication ticket of the machine to determine what machine is contacting you. So for me this is a NACK (I know Jason acked and pushed, up to you whether to revert or just patch on top to remove the DNS checks). Simo. From dpal at redhat.com Wed Oct 21 14:12:33 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 21 Oct 2009 10:12:33 -0400 Subject: [Freeipa-devel] access control for cert generation In-Reply-To: <4ADE2B63.3050704@redhat.com> References: <4ADE218B.60602@redhat.com> <4ADE2552.3030702@redhat.com> <4ADE2B63.3050704@redhat.com> Message-ID: <4ADF16D1.5050007@redhat.com> Rob Crittenden wrote: > Dmitri Pal wrote: >> Rob Crittenden wrote: >>> I touched on this a little in IRC, figured I'd move it to the list for >>> a fuller conversation. >>> >>> I'm in the process of adding access controls to machines requesting >>> certificates for themselves. >>> >>> Let me first show what happens when a certificate request occurs: >>> >>> - Some authenticated entity generates a CSR and submits a request. >>> This request consists of a service principal name and the CSR >>> - If the hostname of the CSR matches the hostname of the requestor it >>> is passed to the CA (optionally an entity may be granted to issue >>> certs for any host) >>> - the CA automatically issues a certificate and returns the cert blob >>> - If the service already exists, the cert blob is added to the entry >>> - If not and it was requested, a service record is created for the >>> service principal >>> - Finally the cert text is returned to the client >>> >>> So a couple of things here: >>> >>> - Do we want any machine to be able to generate certificates for >>> itself? Steve was a bit nervous about this. >> >> I think there is a difference between host cert for the system and >> service cert for the same host. > > Not really. What is this host cert going to be used for? The only kind > of cert we currently issue is for SSL servers, not for identity (e.g. > no client certs). > Well I think this is the problem. In my mind there is a cert for the host that is created during enrollment that is used for the host itself and not bound to any service running on the host. This cert is used only for SSL communication with IPA server in cases when the keytab can't be used or for host to host authentication in the VPN case for example. And then there are certs that are bound to specific services. They have some specific attribute that binds it to the service. >> Issuance or tracking of the service certs needs to be initiated by the >> user that has rights to request tracking or creation of a specific >> service cert. > > Ok, that's fine, but it precludes generating an SSL cert in a > kickstart without providing some sort of credential. I was planning on > using the host keytab to get the certificate. If that is out then my > life becomes much, much simpler. I thought that it is either user's credential or OTP is required to initiate the sequence. I think we need a quick call about these things to sort out the assumptions. I will set up something for tomorrow. > >> So without this initial authorization I do not thin the host can do >> anything with the cert for the service running on the host. >> This means that the initial cert tracking issuance request should create >> some kind of the attribute that will be used in the ACI rule to check if >> this cert can then later on be re-requested by the host. >> >> Does this approach make sense? > > We currently have access controls for users to request certs for > hosts. That should be adequate to cover this. > > So it sounds like there is nothing to do here, move along :-) I am not sure. I think we are missing something. > > rob > >>> - If not, do we want a group to specify which machines can do >>> requests? Could get cumbersome to manage at some point but otherwise >>> it would be a manual process to say "Steve's laptop can't request >>> certs". >>> - machines will need permission to write service entries. Do we want >>> to grant this access to all machines? I might need some help from the >>> 389 team to write an ACI that lets us control machines only writing >>> service principals for themselves. I'd essentially need to pull out >>> the hostname part of the krbprincipalname and somehow use that to >>> limit write access to host/hostname at REALM. I can do it in code but >>> then someone could do an ldapmodify to add a service and go around our >>> XML-RPC interface (very naughty). >>> >>> rob >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pzuna at redhat.com Wed Oct 21 14:16:45 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Wed, 21 Oct 2009 16:16:45 +0200 Subject: [Freeipa-devel] [PATCH] Display membership attributes (member, memberOf) by default in show/find. In-Reply-To: <4ADF0509.3090102@redhat.com> References: <200910211007.n9LA7Fkj005566@apoc.dsdev.sjc.redhat.com> <4ADF0509.3090102@redhat.com> Message-ID: <4ADF17CD.6010207@redhat.com> Rob Crittenden wrote: > The 10% failure is really just 1 test failing: > > ++ '[' 0 '!=' 0 ']' > ++ ssh root at iparhel5-64vmb.dsdev.sjc.redhat.com 'ipa group-find > testgroup1 | grep testusr1' > ++ '[' 1 '!=' 0 ']' > ++ echo 'ERROR - ipa testusr1 not found in testgroup1 failed on > iparhel5-64vmb.dsdev.sjc.redhat.com' > ERROR - ipa testusr1 not found in testgroup1 failed on > iparhel5-64vmb.dsdev.sjc.redhat.com > ++ tet_result FAIL > > https://bugzilla.redhat.com/show_bug.cgi?id=528207 > > Basically group show/find no longer includes membership by default. Do > you think you could look at this today or tomorrow so we can get the > tests passing again? > > rob Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Display-membership-attributes-member-memberOf-by.patch Type: application/mbox Size: 2112 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 21 14:35:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Oct 2009 10:35:15 -0400 Subject: [Freeipa-devel] Re: [PATCH] Display membership attributes (member, memberOf) by default in show/find. In-Reply-To: <4ADF17CD.6010207@redhat.com> References: <200910211007.n9LA7Fkj005566@apoc.dsdev.sjc.redhat.com> <4ADF0509.3090102@redhat.com> <4ADF17CD.6010207@redhat.com> Message-ID: <4ADF1C23.5090505@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> The 10% failure is really just 1 test failing: >> >> ++ '[' 0 '!=' 0 ']' >> ++ ssh root at iparhel5-64vmb.dsdev.sjc.redhat.com 'ipa group-find >> testgroup1 | grep testusr1' >> ++ '[' 1 '!=' 0 ']' >> ++ echo 'ERROR - ipa testusr1 not found in testgroup1 failed on >> iparhel5-64vmb.dsdev.sjc.redhat.com' >> ERROR - ipa testusr1 not found in testgroup1 failed on >> iparhel5-64vmb.dsdev.sjc.redhat.com >> ++ tet_result FAIL >> >> https://bugzilla.redhat.com/show_bug.cgi?id=528207 >> >> Basically group show/find no longer includes membership by default. Do >> you think you could look at this today or tomorrow so we can get the >> tests passing again? >> >> rob > > Pavel > ack, pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 21 15:15:03 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Oct 2009 11:15:03 -0400 Subject: [Freeipa-devel] [PATCH] 274 detect whether to uninstall the CA or not In-Reply-To: <4AC36C03.2000508@redhat.com> References: <4AB00828.1000005@redhat.com> <4AC36C03.2000508@redhat.com> Message-ID: <4ADF2577.20500@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> You had to pass --ca when uninstalling if you wanted the CA >> uninstalled. This was nuts, auto-detect it. >> >> rob > ack. > > Pavel pushed rebased patch to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From davido at redhat.com Thu Oct 22 02:02:34 2009 From: davido at redhat.com (David O'Brien) Date: Thu, 22 Oct 2009 12:02:34 +1000 Subject: [Freeipa-devel] [PATCH] 274 detect whether to uninstall the CA or not In-Reply-To: <4ADF2577.20500@redhat.com> References: <4AB00828.1000005@redhat.com> <4AC36C03.2000508@redhat.com> <4ADF2577.20500@redhat.com> Message-ID: <4ADFBD3A.7000000@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>> You had to pass --ca when uninstalling if you wanted the CA >>> uninstalled. This was nuts, auto-detect it. >>> >>> rob >> ack. >> >> Pavel > > pushed rebased patch to master > > rob > do you mean when uninstalling ipa-server you had to pass --ca as well to get rid of the CA? if so, maybe we could add this to the --uninstall description on the help page (i.e., this will automatically remove any CA that was installed using the --ca option) if not so, what? Is there any case for not removing the CA when uninstalling the IPA server? -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson From jderose at redhat.com Thu Oct 22 14:16:50 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 22 Oct 2009 14:16:50 +0000 Subject: [Freeipa-devel] [PATCH] jderose 025 Add mod_python adapter and some UI tuning Message-ID: <1256221010.4182.8.camel@jgd-dsk> This patch fixes the depreciated mod_proxy config (was used for TurboGears) and lays a bit of related ground work for my turning patch, which I still have a few days of work on. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-025-Add-mod_python-adapter-some-UI-tuning.patch Type: text/x-patch Size: 15513 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 22 14:28:08 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Oct 2009 10:28:08 -0400 Subject: [Freeipa-devel] [PATCH] 274 detect whether to uninstall the CA or not In-Reply-To: <4ADFBD3A.7000000@redhat.com> References: <4AB00828.1000005@redhat.com> <4AC36C03.2000508@redhat.com> <4ADF2577.20500@redhat.com> <4ADFBD3A.7000000@redhat.com> Message-ID: <4AE06BF8.1040808@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Rob Crittenden wrote: >>>> You had to pass --ca when uninstalling if you wanted the CA >>>> uninstalled. This was nuts, auto-detect it. >>>> >>>> rob >>> ack. >>> >>> Pavel >> >> pushed rebased patch to master >> >> rob >> > > do you mean when uninstalling ipa-server you had to pass --ca as well to > get rid of the CA? Yes. > if so, maybe we could add this to the --uninstall description on the > help page (i.e., this will automatically remove any CA that was > installed using the --ca option) > if not so, what? I don't think so. Uninstalling removes everything else, I don't see why we would treat this differently. > Is there any case for not removing the CA when uninstalling the IPA server? No because it isn't like you can re-use it with another IPA install later. Even if you wanted to maintain the data you just wouldn't uninstall IPA then, just disable all its services. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Thu Oct 22 14:45:43 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 22 Oct 2009 14:45:43 +0000 Subject: [Freeipa-devel] validating return values in XML-RPC In-Reply-To: <4ACD28E4.1080108@redhat.com> References: <4ACD28E4.1080108@redhat.com> Message-ID: <1256222743.4182.46.camel@jgd-dsk> So I've been thinking about this as I've been doing the UI "tuning" (extending meta-data and making the engine smarter). I agree with John that we need to describe the return values programatically. We can also kill two birds with one stone here because the description of the return values is a great way to provide some of the meta-data the UI needs (and the CLI... there is something in place now, but it's not easily plugable). I personally feel the design of the Param system has held up pretty well (Rob and Pavel, speak now or forever hold your peace), so I think we should use the Param classes to describe the return values. This will really help us reduce code duplication and allow for good plugability because, as usual, most of our commands are CRUD operations, so we can generally use some auto-magic to deduce the return values from the corresponding Object params. Thoughts? On Wed, 2009-10-07 at 19:48 -0400, John Dennis wrote: > Sorry to harp on this :-) But the more I work with the XML-RPC interface > from non-python code the more I think we've got a problem. > > The first problem is what was discussed in the team meeting. You don't > know what a function is going to return and nothing enforces the > consistency of return values. Jason has done an awesome job of enforcing > the consistency of input arguments, but that's only half the battle. > What gets returned is purely a function of what the plugin author > happens to stuff into the plugin's return statement. There is no > enforcement of how many values get returned, what their types are, what > is optional, what is mandatory, etc. In other words everything which is > enforced on the input side of the call is absent on the output side, it > should be obvious why this is a problem, especially for any callers of > XML-RPC which are *not* in the python plugin framework. > > The second problem I've run into with return values is especially > pernicious because the plugin framework is hiding a very fundamental and > apparently common error. Here is the issue: > > * We've adopted the convention that *all* strings will be unicode objects. > > * str objects will be treated as binary data > > * Python will in many instances freely convert between str objects and > unicode objects. > > * If a plugin wants to return a string it *must* return a unicode > object. If the plugin mistakenly returns a str object (a very very easy > mistake to make) then what gets returned through XML-RPC is a *binary* > base64 encoded blob, not an XML-RPC *string* value! > > The above is so critical let me repeat it: FAILING TO ASSURE A RETURNED > STRING IS UNICODE AND NOT STR RESULTS IN BINARY BLOBS ON THE RECEIVING > END INSTEAD OF A STRING. > > * However, the python framework *hides* the error on the return side > because it decodes the base64 binary value back into a str object. > Because str objects and unicode objects are often interchangeable the > python code receiving the return value thinks it sees the right result > even though it's not. > > If we're going to have other clients of the XML-RPC interface then that > client *must* know what the return values are and what their type is. It > can't (or shouldn't) do things like: > > * I was expecting a string but I got a binary blob so that must have > been a mistake so I'll treat the binary blob as a string and hope it's > correct. > > -or- > > * I was expecting an integer but I actually got a string (yes there are > plugins which do this), so I'll try to read an integer value out of the > string. But wait, suppose the plugin author who returned the integer as > a string forget to assure that the string representing the integer was a > unicode object and not a str object, then the receiver really has to > start guessing because he's gotten back a binary blob. Is that binary > blob a 2's compliment representation of a signed integer, is it unsigned > integer, or is the binary blob a string representation of the integer? > Clearly this doesn't work. > > Now let's suppose another common scenario. The plugin author discovers > he has mistakenly returned a str object when it should have been a > unicode object and corrects his mistake, seemingly innocent because > everything continues to work (but only in python). We have a non-python > client of the XML-RPC interface who has corrected for the mistake by > expecting binary data for the string, now that client fails! Or let's > say the plugin was correctly returning a unicode object but some > seemingly innocent change is made and the value ends up being a str > object instead. Once again the python code continues to work correctly > but the non-python code fails. > > So how easy it for Python programmers to make the mistake between str > and unicode? *VERY VERY EASY!* In fact it's so easy even Jason's > documentation and examples sometimes make the mistake. It's especially > easy mistake to make when calling another function because the vast > majority of existing Python libraries return str objects for strings. > > If we don't validate the return values from the plugin's I don't see how > we'll ever have non-python XML-RPC clients which are robust. > > I'm happy to work with Jason to get the return validation implemented. I > now know the insides of the plugin rpc mechanism in gory detail :-) > > I don't think we should postpone this, I think there are all sorts of > errors lurking in the code, or will get introduced in the code in the > future. For robustness sake it's better to fix this sooner rather than > later IMHO. > > Of course the other option is to do away with the rule that str objects > will get converted into binary blobs in XML-RPC. I think there is a good > argument for treating both str objects and unicode objects as strings in > XML-RPC. How often do we really need to pass binary data back in > XLM-RPC? I'm thinking it's not very often. For those limited cases > wouldn't it be better to require the plugin to return a Binary object > instead of a str?. This has the advantage that's it's explicit and > removes the dangerous practice of automatic conversion of conventional > python strings into binary blobs when 99% of the time that's not the > intention of the programmer. > > BTW, removing the automatic conversion of str to binary is a simple one > line change which would have a huge impact on robustness without any > loss of functionality. However that still does not address the issue of > return value validation, but it does remove the single most common error > we have with return values at the moment. > From pzuna at redhat.com Thu Oct 22 15:00:47 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 22 Oct 2009 17:00:47 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in print_attribute. Message-ID: <4AE0739F.8010607@redhat.com> When a multi-value attribute had no values, and exception was generated while trying to word-wrap it. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-bug-in-print_attribute.patch Type: application/mbox Size: 847 bytes Desc: not available URL: From pzuna at redhat.com Thu Oct 22 15:01:55 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 22 Oct 2009 17:01:55 +0200 Subject: [Freeipa-devel] [PATCH] Remove ipalib/plugins/basegroup.py. It's become obsolete. Message-ID: <4AE073E3.7030109@redhat.com> It's not used anymore. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-ipalib-plugins-basegroup.py.-It-s-become-obso.patch Type: application/mbox Size: 17158 bytes Desc: not available URL: From jdennis at redhat.com Thu Oct 22 15:32:41 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 22 Oct 2009 11:32:41 -0400 Subject: [Freeipa-devel] validating return values in XML-RPC In-Reply-To: <1256222743.4182.46.camel@jgd-dsk> References: <4ACD28E4.1080108@redhat.com> <1256222743.4182.46.camel@jgd-dsk> Message-ID: <4AE07B19.6050805@redhat.com> On 10/22/2009 10:45 AM, Jason Gerard DeRose wrote: > So I've been thinking about this as I've been doing the UI > "tuning" (extending meta-data and making the engine smarter). I agree > with John that we need to describe the return values programatically. > We can also kill two birds with one stone here because the description > of the return values is a great way to provide some of the meta-data the > UI needs (and the CLI... there is something in place now, but it's not > easily plugable). > > I personally feel the design of the Param system has held up pretty well > (Rob and Pavel, speak now or forever hold your peace), so I think we > should use the Param classes to describe the return values. This will > really help us reduce code duplication and allow for good plugability > because, as usual, most of our commands are CRUD operations, so we can > generally use some auto-magic to deduce the return values from the > corresponding Object params. > > Thoughts? If you're asking if the description of the return values should be expressed using the same Param classes as the input values then yes I agree. I had pretty much expected we would reuse the Param declarations for the return values. However if you're asking should the description of the return values be magically deduced from the input parameters then no I don't agree, I think both the input and output parameters should be explicitly declared so a programmer can look at the code and see what they are just like in any typed language. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nalin at redhat.com Thu Oct 22 23:57:21 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 22 Oct 2009 19:57:21 -0400 Subject: [Freeipa-devel] Fedora12: Looping detected inside krb5_get_in_tkt In-Reply-To: <1255407441.11621.7.camel@jgd-dsk> References: <1255407441.11621.7.camel@jgd-dsk> Message-ID: <20091022235721.GA2323@redhat.com> On Mon, Oct 12, 2009 at 10:17:21PM -0600, Jason Gerard DeRose wrote: > To help ensure that my new UI patch wont break our daily builds, I've > tried building it under Fedora 12 as it has python-assets and > python-wehjit. It builds fine, but when I kinit, I get this error: > > [root at fedora12 ~]# kinit admin at EXAMPLE.COM > Password for admin at EXAMPLE.COM: > kinit: Looping detected inside krb5_get_in_tkt while getting initial > credentials > > Anyone have any ideas? This came up on the upstream list recently; I haven't reproduced it myself, but it looks like it'll happen if you fail to preauthenticate in a number of ways where the KDC doesn't return a more-specific error code. Does the database entry for admin at EXAMPLE.COM have keys in it? Did you type the right password? Is there anything in the KDC logs that provides more detail? Do you have a packet capture? The size and contents of the e-data returned with the error can help narrow it down. HTH, Nalin From rcritten at redhat.com Fri Oct 23 00:38:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 22 Oct 2009 20:38:04 -0400 Subject: [Freeipa-devel] validating return values in XML-RPC In-Reply-To: <4AE07B19.6050805@redhat.com> References: <4ACD28E4.1080108@redhat.com> <1256222743.4182.46.camel@jgd-dsk> <4AE07B19.6050805@redhat.com> Message-ID: <4AE0FAEC.3000107@redhat.com> John Dennis wrote: > On 10/22/2009 10:45 AM, Jason Gerard DeRose wrote: >> So I've been thinking about this as I've been doing the UI >> "tuning" (extending meta-data and making the engine smarter). I agree >> with John that we need to describe the return values programatically. >> We can also kill two birds with one stone here because the description >> of the return values is a great way to provide some of the meta-data the >> UI needs (and the CLI... there is something in place now, but it's not >> easily plugable). >> >> I personally feel the design of the Param system has held up pretty well >> (Rob and Pavel, speak now or forever hold your peace), so I think we >> should use the Param classes to describe the return values. This will >> really help us reduce code duplication and allow for good plugability >> because, as usual, most of our commands are CRUD operations, so we can >> generally use some auto-magic to deduce the return values from the >> corresponding Object params. >> >> Thoughts? > > If you're asking if the description of the return values should be > expressed using the same Param classes as the input values then yes I > agree. I had pretty much expected we would reuse the Param declarations > for the return values. > > However if you're asking should the description of the return values be > magically deduced from the input parameters then no I don't agree, I > think both the input and output parameters should be explicitly declared > so a programmer can look at the code and see what they are just like in > any typed language. > I'm not entirely sure this is going to be possible, at least not at this level. The attributes returned will not be this predictable. At best it could include just some possible attributes returned and some vague data type information. Take the group plugin for an example. ipa group-show will return something like a string and a dict. The string is the DN of the entry and the dict is the list of attributes returned. Within the dict are any number of attributes, some of which we can define in advance. So we know that a group requires a cn and a description, so we can define that. But what about members? That is an optional attribute, do we define that? And a group can be a member of other groups, so I guess the same would apply. I guess that's fine, we can define optional incoming options, we can do outgoing ones in the same way. Ok, now the interesting part. One can also pass --all to the function which returns every attribute in the object. What do we do with these unexpected attributes? Now imagine a much more complex object and you can see how this quickly becomes unmanageable. Once you start allowing unknown things to be returned we are in pretty much the same boat we are now only with the false impression that we have control. On the bright side once the output of show gets defined the rest becomes a bit easier. add will return the same type of thing (it calls show on the newly added object and returns that). find will return a list of these things. delete I believe delete just returns the dn of the entry deleted, that's easy too. There are other commands that can return all kinds of other wacky stuff, see the env plugin for that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Fri Oct 23 13:24:05 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 23 Oct 2009 09:24:05 -0400 Subject: [Freeipa-devel] validating return values in XML-RPC In-Reply-To: <4AE0FAEC.3000107@redhat.com> References: <4ACD28E4.1080108@redhat.com> <1256222743.4182.46.camel@jgd-dsk> <4AE07B19.6050805@redhat.com> <4AE0FAEC.3000107@redhat.com> Message-ID: <4AE1AE75.3000603@redhat.com> Rob Crittenden wrote: > John Dennis wrote: >> On 10/22/2009 10:45 AM, Jason Gerard DeRose wrote: >>> So I've been thinking about this as I've been doing the UI >>> "tuning" (extending meta-data and making the engine smarter). I agree >>> with John that we need to describe the return values programatically. >>> We can also kill two birds with one stone here because the description >>> of the return values is a great way to provide some of the meta-data >>> the >>> UI needs (and the CLI... there is something in place now, but it's not >>> easily plugable). >>> >>> I personally feel the design of the Param system has held up pretty >>> well >>> (Rob and Pavel, speak now or forever hold your peace), so I think we >>> should use the Param classes to describe the return values. This will >>> really help us reduce code duplication and allow for good plugability >>> because, as usual, most of our commands are CRUD operations, so we can >>> generally use some auto-magic to deduce the return values from the >>> corresponding Object params. >>> >>> Thoughts? >> >> If you're asking if the description of the return values should be >> expressed using the same Param classes as the input values then yes I >> agree. I had pretty much expected we would reuse the Param >> declarations for the return values. >> >> However if you're asking should the description of the return values >> be magically deduced from the input parameters then no I don't agree, >> I think both the input and output parameters should be explicitly >> declared so a programmer can look at the code and see what they are >> just like in any typed language. >> > > I'm not entirely sure this is going to be possible, at least not at > this level. The attributes returned will not be this predictable. At > best it could include just some possible attributes returned and some > vague data type information. > > Take the group plugin for an example. > > ipa group-show will return something like a string and a dict. The > string is the DN of the entry and the dict is the list of attributes > returned. Within the dict are any number of attributes, some of which > we can define in advance. So we know that a group requires a cn and a > description, so we can define that. But what about members? That is an > optional attribute, do we define that? And a group can be a member of > other groups, so I guess the same would apply. I guess that's fine, we > can define optional incoming options, we can do outgoing ones in the > same way. > > Ok, now the interesting part. One can also pass --all to the function > which returns every attribute in the object. What do we do with these > unexpected attributes? Now imagine a much more complex object and you > can see how this quickly becomes unmanageable. Once you start allowing > unknown things to be returned we are in pretty much the same boat we > are now only with the false impression that we have control. > > On the bright side once the output of show gets defined the rest > becomes a bit easier. add will return the same type of thing (it calls > show on the newly added object and returns that). find will return a > list of these things. delete I believe delete just returns the dn of > the entry deleted, that's easy too. > > There are other commands that can return all kinds of other wacky > stuff, see the env plugin for that. May be it is a too big of a stretch but the DS has syntaxes in schema so can we derive data type of the returned value from the syntax of the unknown attribute? There should be a pretty simple mapping of DS syntaxes to the return value types. This way we would be able to handle the specific attributes we know about in a way we define but would be able to pass back and process the unknown attributes in a generic way. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Oct 23 13:31:59 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 23 Oct 2009 09:31:59 -0400 Subject: [Freeipa-devel] validating return values in XML-RPC In-Reply-To: <4AE0FAEC.3000107@redhat.com> References: <4ACD28E4.1080108@redhat.com> <1256222743.4182.46.camel@jgd-dsk> <4AE07B19.6050805@redhat.com> <4AE0FAEC.3000107@redhat.com> Message-ID: <4AE1B04F.5000305@redhat.com> On 10/22/2009 08:38 PM, Rob Crittenden wrote: > John Dennis wrote: >> On 10/22/2009 10:45 AM, Jason Gerard DeRose wrote: >>> So I've been thinking about this as I've been doing the UI >>> "tuning" (extending meta-data and making the engine smarter). I agree >>> with John that we need to describe the return values programatically. >>> We can also kill two birds with one stone here because the description >>> of the return values is a great way to provide some of the meta-data the >>> UI needs (and the CLI... there is something in place now, but it's not >>> easily plugable). >>> >>> I personally feel the design of the Param system has held up pretty well >>> (Rob and Pavel, speak now or forever hold your peace), so I think we >>> should use the Param classes to describe the return values. This will >>> really help us reduce code duplication and allow for good plugability >>> because, as usual, most of our commands are CRUD operations, so we can >>> generally use some auto-magic to deduce the return values from the >>> corresponding Object params. >>> >>> Thoughts? >> >> If you're asking if the description of the return values should be >> expressed using the same Param classes as the input values then yes I >> agree. I had pretty much expected we would reuse the Param >> declarations for the return values. >> >> However if you're asking should the description of the return values >> be magically deduced from the input parameters then no I don't agree, >> I think both the input and output parameters should be explicitly >> declared so a programmer can look at the code and see what they are >> just like in any typed language. >> > > I'm not entirely sure this is going to be possible, at least not at this > level. The attributes returned will not be this predictable. At best it > could include just some possible attributes returned and some vague data > type information. > > Take the group plugin for an example. > > ipa group-show will return something like a string and a dict. The > string is the DN of the entry and the dict is the list of attributes > returned. Within the dict are any number of attributes, some of which we > can define in advance. So we know that a group requires a cn and a > description, so we can define that. But what about members? That is an > optional attribute, do we define that? And a group can be a member of > other groups, so I guess the same would apply. I guess that's fine, we > can define optional incoming options, we can do outgoing ones in the > same way. > > Ok, now the interesting part. One can also pass --all to the function > which returns every attribute in the object. What do we do with these > unexpected attributes? Now imagine a much more complex object and you > can see how this quickly becomes unmanageable. Once you start allowing > unknown things to be returned we are in pretty much the same boat we are > now only with the false impression that we have control. > > On the bright side once the output of show gets defined the rest becomes > a bit easier. add will return the same type of thing (it calls show on > the newly added object and returns that). find will return a list of > these things. delete I believe delete just returns the dn of the entry > deleted, that's easy too. > > There are other commands that can return all kinds of other wacky stuff, > see the env plugin for that. O.K. There may be a subset of return values which are difficult to declare, in particular those which are the result of an ldap query. However in this specific instance we do know the types of the attributes because they're defined in the schema. This might be an example of where automatic checking makes sense (however for performance reasons we might only want to enable such checking during testing). I have not looked at the ldap extraction code, but I presume it automatically handles types correctly so the likelyhood the types returned in an ldap query dict would be wrong are low. Perhaps we can have a flag to mark such return values as "pre-validated" if we have the belief the return values are algorithmically generated. However, that's not the primary case I'm concerned about. I'm concerned about when the programmer manually decides what is going to be returned. What are the permissible "top level" values? In other words at the top level what are the possible keys and the types of the matching values? If it's an ordered list of values (e.g. an arg list) then what is each member of the list supposed to be? I think it's possible to check every item at the top level. As you point out recursive validation might be too much. Although it should be easy to recursively visit each value in a dict and make sure none of the values are str objects because we never return binary data (at least yet, and if we do it would be easy to add a rule which says this particular value has an exception). So in your example you can certainly check that the return values consist of two items, the DN which must be a unicode object, and a dict. Neither one can be absent nor can there be anything else if so it's an error (unless the the top level has "optional" parameters of course). The most serious problem we face at the moment is the ease with which we can incorrectly return a str object instead of unicode. Next is when a value is supposed to be integral that it's actually an integer and not a string representation of the integer (which works when the only use of the returned value is for presentation, but fails when it's used programmatically). Finally, at the top level, the plugin must return the set of values (no more, no less) of what it declares it will return (e.g. honor it's interface contract). -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 23 13:36:43 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Oct 2009 09:36:43 -0400 Subject: [Freeipa-devel] [PATCH] 302 clean up join plugin Message-ID: <4AE1B16B.2070204@redhat.com> Remove a bunch of unused imports, add some docstrings, etc. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-302-cleanup.patch Type: application/mbox Size: 1503 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 23 13:37:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Oct 2009 09:37:33 -0400 Subject: [Freeipa-devel] [PATCH] Fix bug in print_attribute. In-Reply-To: <4AE0739F.8010607@redhat.com> References: <4AE0739F.8010607@redhat.com> Message-ID: <4AE1B19D.7040808@redhat.com> Pavel Z?na wrote: > When a multi-value attribute had no values, and exception was generated > while trying to word-wrap it. > > Pavel > ack, pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 23 13:38:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Oct 2009 09:38:14 -0400 Subject: [Freeipa-devel] [PATCH] Remove ipalib/plugins/basegroup.py. It's become obsolete. In-Reply-To: <4AE073E3.7030109@redhat.com> References: <4AE073E3.7030109@redhat.com> Message-ID: <4AE1B1C6.4070002@redhat.com> Pavel Z?na wrote: > It's not used anymore. > > Pavel > ack, pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Fri Oct 23 13:49:22 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 23 Oct 2009 09:49:22 -0400 Subject: [Freeipa-devel] adding a new dependency (python-lxml) Message-ID: <4AE1B462.6020508@redhat.com> Do we have a procedure to follow when we want to add a new dependency on a package? In this particular instance I would like to add a dependency on python-lxml to the ipaserver package. python-lxml is a python binding to the very popular and high performance libxml2 package by our own Daniel Veillard. FWIW there are already a lot of packages being shipped which depend on libxml2. Why? We already have a need to parse xml and we're using minidom. However minidom has a lot of limitations, foremost amongst them is it's inability to parse HTML (it also lacks support for things like xpath). python-lxml gives us the ability to do things we need to do but is absent in minidom. So are there any issues with pulling in libxml2 via python-lxml? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Oct 23 13:55:27 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 Oct 2009 09:55:27 -0400 Subject: [Freeipa-devel] adding a new dependency (python-lxml) In-Reply-To: <4AE1B462.6020508@redhat.com> References: <4AE1B462.6020508@redhat.com> Message-ID: <1256306127.2914.23.camel@localhost.localdomain> On Fri, 2009-10-23 at 09:49 -0400, John Dennis wrote: > Do we have a procedure to follow when we want to add a new dependency on > a package? > > In this particular instance I would like to add a dependency on > python-lxml to the ipaserver package. python-lxml is a python binding to > the very popular and high performance libxml2 package by our own Daniel > Veillard. FWIW there are already a lot of packages being shipped which > depend on libxml2. > > Why? We already have a need to parse xml and we're using minidom. > However minidom has a lot of limitations, foremost amongst them is it's > inability to parse HTML (it also lacks support for things like xpath). > python-lxml gives us the ability to do things we need to do but is > absent in minidom. > > So are there any issues with pulling in libxml2 via python-lxml? I don't see any issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Fri Oct 23 14:35:57 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 23 Oct 2009 16:35:57 +0200 Subject: [Freeipa-devel] [PATCH] Filter all NULL values in ldap2.add_entry. python-ldap doesn't like'em. Message-ID: <4AE1BF4D.9030905@redhat.com> Previously we only filtered None values, but it turns out that's not enough. For example, empty lists/tuples generate ProtocolErrors. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Filter-all-NULL-values-in-ldap2.add_entry.-python-ld.patch Type: application/mbox Size: 990 bytes Desc: not available URL: From pzuna at redhat.com Fri Oct 23 16:40:27 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 23 Oct 2009 18:40:27 +0200 Subject: [Freeipa-devel] [PATCH] 302 clean up join plugin In-Reply-To: <4AE1B16B.2070204@redhat.com> References: <4AE1B16B.2070204@redhat.com> Message-ID: <4AE1DC7B.9080807@redhat.com> Rob Crittenden wrote: > Remove a bunch of unused imports, add some docstrings, etc. > > rob > ack. Pavel From pzuna at redhat.com Fri Oct 23 16:46:43 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 23 Oct 2009 18:46:43 +0200 Subject: [Freeipa-devel] [PATCH] Change checks in List.normalize to filter out illegal values. Message-ID: <4AE1DDF3.2030502@redhat.com> As we started converting NULL values to None a while back, List.normalize blows up if we set an empty tuple default value. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-checks-in-List.normalize-to-filter-out-illega.patch Type: application/mbox Size: 912 bytes Desc: not available URL: From rcritten at redhat.com Fri Oct 23 18:36:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 23 Oct 2009 14:36:15 -0400 Subject: [Freeipa-devel] [PATCH] jderose 025 Add mod_python adapter and some UI tuning In-Reply-To: <1256221010.4182.8.camel@jgd-dsk> References: <1256221010.4182.8.camel@jgd-dsk> Message-ID: <4AE1F79F.7070403@redhat.com> Jason Gerard DeRose wrote: > This patch fixes the depreciated mod_proxy config (was used for > TurboGears) and lays a bit of related ground work for my turning patch, > which I still have a few days of work on. > > The ipa-rewrite stuff is actually needed. It does a couple of things: - routes from / to /ipa/ui so we can helpfully send users to the right place but also allow other things to co-exist - redirects to the FQDN so that kerberos will work as expected - forces SSL That said, I haven't been able to get the UI working with this patch. I'm using curl: % curl -kv --negotiate -u : https://luna.example.com/ipa/ui/Command The authentication works ok but when it goes to fetch the page I get: HTTP/1.1 405 Method Not Allowed Date: Fri, 23 Oct 2009 18:34:39 GMT Server: Apache/2.2.11 (Fedora) Allow: POST,TRACE Content-Length: 318 Connection: close Content-Type: text/html; charset=iso-8859-1 405 Method Not Allowed

Method Not Allowed

The requested method GET is not allowed for the URL /ipa/ui/Command.

Apache/2.2.11 (Fedora) Server at luna.example.com Port 443
rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Sat Oct 24 10:04:55 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Sat, 24 Oct 2009 12:04:55 +0200 Subject: [Freeipa-devel] [PATCH] Change checks in List.normalize to filter out illegal values. In-Reply-To: <4AE1DDF3.2030502@redhat.com> References: <4AE1DDF3.2030502@redhat.com> Message-ID: <4AE2D147.6080301@redhat.com> Pavel Z?na wrote: > As we started converting NULL values to None a while back, > List.normalize blows up if we set an empty tuple default value. > > Pavel > nack! This actually introduces a bigger problem than it solves, my mistake. Fixed version attached. To demonstrate the bug this (was) is supposed to solve, try this before applying the patch: ipa group-add-member ipausers --users="" Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-checks-in-List.normalize-to-filter-out-illega.patch Type: application/mbox Size: 919 bytes Desc: not available URL: From jderose at redhat.com Mon Oct 26 04:10:08 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sun, 25 Oct 2009 22:10:08 -0600 Subject: [Freeipa-devel] Fedora12: Looping detected inside krb5_get_in_tkt In-Reply-To: <20091022235721.GA2323@redhat.com> References: <1255407441.11621.7.camel@jgd-dsk> <20091022235721.GA2323@redhat.com> Message-ID: <1256530208.8459.6.camel@jgd-dsk> On Thu, 2009-10-22 at 19:57 -0400, Nalin Dahyabhai wrote: > On Mon, Oct 12, 2009 at 10:17:21PM -0600, Jason Gerard DeRose wrote: > > To help ensure that my new UI patch wont break our daily builds, I've > > tried building it under Fedora 12 as it has python-assets and > > python-wehjit. It builds fine, but when I kinit, I get this error: > > > > [root at fedora12 ~]# kinit admin at EXAMPLE.COM > > Password for admin at EXAMPLE.COM: > > kinit: Looping detected inside krb5_get_in_tkt while getting initial > > credentials > > > > Anyone have any ideas? > > This came up on the upstream list recently; I haven't reproduced it > myself, but it looks like it'll happen if you fail to preauthenticate in > a number of ways where the KDC doesn't return a more-specific error > code. > > Does the database entry for admin at EXAMPLE.COM have keys in it? > Did you type the right password? > Is there anything in the KDC logs that provides more detail? > Do you have a packet capture? The size and contents of the e-data > returned with the error can help narrow it down. > > HTH, > > Nalin How do I check whether the database entry for admin at EXAMPLE.COM has keys in it? Yes, I'm typing the password correctly, and I get the same error even when I deliberately type the wrong password. The /var/log/krb5kdc.log file has this repeated over and over again: Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): preauth (timestamp) verify failure: No matching key in entry Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.122.12: PREAUTH_FAILED: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Preauthentication failed Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): preauth (timestamp) verify failure: No matching key in entry Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.122.12: PREAUTH_FAILED: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Preauthentication failed Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): preauth (timestamp) verify failure: No matching key in entry Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.122.12: PREAUTH_FAILED: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Preauthentication failed Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): preauth (timestamp) verify failure: No matching key in entry Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.122.12: PREAUTH_FAILED: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Preauthentication failed I'm running this on a VM that I installed from Fedora 12 alpha, but have updated since. I snapshot prior to building and installing freeipa, so this is a fairly clean setup. ipa-server-install appears to succeed, but upon trying to kinit as admin at EXAMPLE.COM, I get the above error. From jderose at redhat.com Mon Oct 26 05:30:04 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Sun, 25 Oct 2009 23:30:04 -0600 Subject: [Freeipa-devel] [PATCH] 302 clean up join plugin In-Reply-To: <4AE1DC7B.9080807@redhat.com> References: <4AE1B16B.2070204@redhat.com> <4AE1DC7B.9080807@redhat.com> Message-ID: <1256535004.8459.7.camel@jgd-dsk> On Fri, 2009-10-23 at 18:40 +0200, Pavel Z?na wrote: > Rob Crittenden wrote: > > Remove a bunch of unused imports, add some docstrings, etc. > > > > rob > > > ack. > > Pavel ack. pushed to master. From jderose at redhat.com Mon Oct 26 11:29:40 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 26 Oct 2009 05:29:40 -0600 Subject: [Freeipa-devel] [PATCH] jderose 025 Add mod_python adapter and some UI tuning In-Reply-To: <4AE1F79F.7070403@redhat.com> References: <1256221010.4182.8.camel@jgd-dsk> <4AE1F79F.7070403@redhat.com> Message-ID: <1256556580.8459.14.camel@jgd-dsk> On Fri, 2009-10-23 at 14:36 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > This patch fixes the depreciated mod_proxy config (was used for > > TurboGears) and lays a bit of related ground work for my turning patch, > > which I still have a few days of work on. > > > > > > The ipa-rewrite stuff is actually needed. It does a couple of things: Oops, missed that. That's what I get for sending off patches when I'm too tired. Here's a revised version that I actually put through some decent testing. The only plumbing problem remaining with the UI is the assets aren't getting registered. I image this would be easiest to in ipa-server-install. > - routes from / to /ipa/ui so we can helpfully send users to the right > place but also allow other things to co-exist > - redirects to the FQDN so that kerberos will work as expected > - forces SSL > > That said, I haven't been able to get the UI working with this patch. > I'm using curl: > > % curl -kv --negotiate -u : https://luna.example.com/ipa/ui/Command > > The authentication works ok but when it goes to fetch the page I get: > > HTTP/1.1 405 Method Not Allowed > Date: Fri, 23 Oct 2009 18:34:39 GMT > Server: Apache/2.2.11 (Fedora) > Allow: POST,TRACE > Content-Length: 318 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > > > 405 Method Not Allowed > >

Method Not Allowed

>

The requested method GET is not allowed for the URL /ipa/ui/Command.

>
>
Apache/2.2.11 (Fedora) Server at luna.example.com Port > 443
> > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-025-2-Add-mod_python-adapter-some-UI-tuning.patch Type: text/x-patch Size: 14021 bytes Desc: not available URL: From nalin at redhat.com Mon Oct 26 15:38:31 2009 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 26 Oct 2009 11:38:31 -0400 Subject: [Freeipa-devel] Fedora12: Looping detected inside krb5_get_in_tkt In-Reply-To: <1256530208.8459.6.camel@jgd-dsk> References: <1255407441.11621.7.camel@jgd-dsk> <20091022235721.GA2323@redhat.com> <1256530208.8459.6.camel@jgd-dsk> Message-ID: <20091026153831.GA20867@redhat.com> On Sun, Oct 25, 2009 at 10:10:08PM -0600, Jason Gerard DeRose wrote: > How do I check whether the database entry for admin at EXAMPLE.COM has keys > in it? Check the user's entry in the directory server for 'krbPrincipalKey' values. The attribute isn't going to be world-readable, so you'll need to search as the KDC or the directory manager, like this: ldapsearch -x -D "cn=Directory Manager" -W \ -h ipaserverhostname -b cn=users,cn=accounts,dc=example,dc=com \ krbPrincipalName=admin at EXAMPLE.COM krbPrincipalKey > Yes, I'm typing the password correctly, and I get the same error > even when I deliberately type the wrong password. Yup, the log confirms that the password isn't a factor here. > The /var/log/krb5kdc.log file has this repeated over and over again: > > Oct 25 21:59:21 fedora12.example.com krb5kdc[27434](info): preauth > (timestamp) verify failure: No matching key in entry If you can retrieve the 'krbPrincipalKey' value and pipe it through something like 'openssl asn1parse' or 'derdump', we can check which kinds of keys you have on file for that user. A packet capture of the traffic between the client and the server will show us which kind of key the client is expecting the server to have. Between those two, we should be able to figure out where the problem is. HTH, Nalin From rcritten at redhat.com Tue Oct 27 21:17:13 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Oct 2009 17:17:13 -0400 Subject: [Freeipa-devel] [PATCH] jderose 025 Add mod_python adapter and some UI tuning In-Reply-To: <1256556580.8459.14.camel@jgd-dsk> References: <1256221010.4182.8.camel@jgd-dsk> <4AE1F79F.7070403@redhat.com> <1256556580.8459.14.camel@jgd-dsk> Message-ID: <4AE76359.3060900@redhat.com> Jason Gerard DeRose wrote: > On Fri, 2009-10-23 at 14:36 -0400, Rob Crittenden wrote: >> Jason Gerard DeRose wrote: >>> This patch fixes the depreciated mod_proxy config (was used for >>> TurboGears) and lays a bit of related ground work for my turning patch, >>> which I still have a few days of work on. >>> >>> >> The ipa-rewrite stuff is actually needed. It does a couple of things: > > Oops, missed that. That's what I get for sending off patches when I'm > too tired. > > Here's a revised version that I actually put through some decent > testing. The only plumbing problem remaining with the UI is the assets > aren't getting registered. I image this would be easiest to in > ipa-server-install. Ok, I didn't put this through tremendous paces but I was able to bring up pieces of the UI protected by kerberos. ack rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Oct 28 01:56:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Oct 2009 21:56:05 -0400 Subject: [Freeipa-devel] [PATCH] 303 proper syntax for fqdn Message-ID: <4AE7A4B5.9090706@redhat.com> The schema defined the syntax for the fqdn attribute as using DN syntax. It should use Directory String syntax. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-303-syntax.patch Type: application/mbox Size: 1889 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Wed Oct 28 04:21:14 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 27 Oct 2009 22:21:14 -0600 Subject: [Freeipa-devel] [PATCH] jderose 025 Add mod_python adapter and some UI tuning In-Reply-To: <4AE76359.3060900@redhat.com> References: <1256221010.4182.8.camel@jgd-dsk> <4AE1F79F.7070403@redhat.com> <1256556580.8459.14.camel@jgd-dsk> <4AE76359.3060900@redhat.com> Message-ID: <1256703674.8278.4.camel@jgd-dsk> On Tue, 2009-10-27 at 17:17 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > On Fri, 2009-10-23 at 14:36 -0400, Rob Crittenden wrote: > >> Jason Gerard DeRose wrote: > >>> This patch fixes the depreciated mod_proxy config (was used for > >>> TurboGears) and lays a bit of related ground work for my turning patch, > >>> which I still have a few days of work on. > >>> > >>> > >> The ipa-rewrite stuff is actually needed. It does a couple of things: > > > > Oops, missed that. That's what I get for sending off patches when I'm > > too tired. > > > > Here's a revised version that I actually put through some decent > > testing. The only plumbing problem remaining with the UI is the assets > > aren't getting registered. I image this would be easiest to in > > ipa-server-install. > > Ok, I didn't put this through tremendous paces but I was able to bring > up pieces of the UI protected by kerberos. > > ack > > rob I beat up on it a bit more and haven't encountered any problems, so I pushed it to master. From dpal at redhat.com Wed Oct 28 14:58:19 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Oct 2009 10:58:19 -0400 Subject: [Freeipa-devel] Announcing FreeIPA v2 Server Alpha 1 Release Message-ID: <4AE85C0B.80501@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Alpha 1 release of the long-awaited freeIPA 2.0 server [1]. This version of the server includes: * Optionally installable DNS server * Optionally installable Certificate Authority to manage server certificates * NIS compatibility plug-in The freeIPA 2.0 server is capable of: * Managing host identities * Defining host-based access control rules that will be enforced on the client side by the IPA back end for SSSD (not provided yet) * Serving netgroups based on user and host objects stored in IPA * Serving sets of automount maps to different clients * Finer-grained management delegation * Group-based password policies The freeIPA 2.0 release provides: * Pluggable and extensible framework for UI/CLI * Rich CLI * Certificate provisioning capabilities Current version of the server does not include web based user interface. FreeIPA 2.0 clients can be configured in the same way as freeIPA 1.2 clients, using ipa-client install. For richer functionality freeIPA can be used with SSSD (System Security Services Daemon). The special freeIPA back end for SSSD developed by the SSSD project is not ready yet, however, the freeIPA 2.0 server can still be configured as a generic LDAP + Kerberos back end for SSSD. For more information about features delivered in this release, see documentation [2] on the freeIPA web site. For information on how to configure client systems to use freeIPA without SSSD, see freeIPA 1.2 documentation [3]. For information on how freeIPA can be used in conjunction with SSSD, see the SSSD documentation [4]. For all other freeIPA-related documentation [5], see freeIPA web site. [1] http://www.freeipa.org/page/Downloads/ [2] http://www.freeipa.org/page/IPAv2_development_status#Documentation [3] http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/ [4] https://fedorahosted.org/sssd/ [5] http://www.freeipa.org/page/DocumentationPortal -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Oct 28 15:11:17 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Oct 2009 11:11:17 -0400 Subject: [Freeipa-devel] Announcing FreeIPA v2 Server Alpha 1 Release In-Reply-To: <4AE85C0B.80501@redhat.com> References: <4AE85C0B.80501@redhat.com> Message-ID: <4AE85F15.6010504@redhat.com> Dmitri Pal wrote: > To all freeipa-interest, freeipa-users and freeipa-devel list members, > > The FreeIPA project team is pleased to announce the availability of the > Alpha 1 release of the long-awaited freeIPA 2.0 server [1]. > > This version of the server includes: > * Optionally installable DNS server > * Optionally installable Certificate Authority to manage server certificates > * NIS compatibility plug-in > > The freeIPA 2.0 server is capable of: > * Managing host identities > * Defining host-based access control rules that will be enforced > on the client side by the IPA back end for SSSD (not provided yet) > * Serving netgroups based on user and host objects stored in IPA > * Serving sets of automount maps to different clients > * Finer-grained management delegation > * Group-based password policies > > The freeIPA 2.0 release provides: > * Pluggable and extensible framework for UI/CLI > * Rich CLI > * Certificate provisioning capabilities > > Current version of the server does not include web based user interface. > > FreeIPA 2.0 clients can be configured in the same way as freeIPA 1.2 > clients, using ipa-client install. For richer functionality freeIPA > can be used with SSSD (System Security Services Daemon). > The special freeIPA back end for SSSD developed by the SSSD project is > not ready yet, however, the freeIPA 2.0 server can still be configured > as a generic LDAP + Kerberos back end for SSSD. > > For more information about features delivered in this release, see > documentation [2] on the freeIPA web site. > For information on how to configure client systems to use freeIPA > without SSSD, see freeIPA 1.2 documentation [3]. > For information on how freeIPA can be used in conjunction with SSSD, > see the SSSD documentation [4]. > For all other freeIPA-related documentation [5], see freeIPA web site. > > [1] http://www.freeipa.org/page/Downloads/ > A quick correction to the link: [1] http://www.freeipa.org/page/Downloads Sorry for confusion. > [2] http://www.freeipa.org/page/IPAv2_development_status#Documentation > [3] http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/ > [4] https://fedorahosted.org/sssd/ > [5] http://www.freeipa.org/page/DocumentationPortal > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Wed Oct 28 17:30:04 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 28 Oct 2009 11:30:04 -0600 Subject: [Freeipa-devel] [PATCH] 303 proper syntax for fqdn In-Reply-To: <4AE7A4B5.9090706@redhat.com> References: <4AE7A4B5.9090706@redhat.com> Message-ID: <1256751004.8278.12.camel@jgd-dsk> On Tue, 2009-10-27 at 21:56 -0400, Rob Crittenden wrote: > The schema defined the syntax for the fqdn attribute as using DN syntax. > It should use Directory String syntax. > > rob ack from me. simple patch, doesn't break anything as far as I can tell. but maybe we should also get at ack from someone with more LDAP knowledge. From jderose at redhat.com Wed Oct 28 20:57:00 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 28 Oct 2009 14:57:00 -0600 Subject: [Freeipa-devel] [PATCH] 303 proper syntax for fqdn In-Reply-To: <1256751004.8278.12.camel@jgd-dsk> References: <4AE7A4B5.9090706@redhat.com> <1256751004.8278.12.camel@jgd-dsk> Message-ID: <1256763420.8278.13.camel@jgd-dsk> On Wed, 2009-10-28 at 11:30 -0600, Jason Gerard DeRose wrote: > On Tue, 2009-10-27 at 21:56 -0400, Rob Crittenden wrote: > > The schema defined the syntax for the fqdn attribute as using DN syntax. > > It should use Directory String syntax. > > > > rob > > ack from me. simple patch, doesn't break anything as far as I can tell. > but maybe we should also get at ack from someone with more LDAP > knowledge. > as there were no objections, i pushed this to master. From rcritten at redhat.com Wed Oct 28 21:41:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Oct 2009 17:41:14 -0400 Subject: [Freeipa-devel] [PATCH] 304 hosts requesting certificates Message-ID: <4AE8BA7A.6070700@redhat.com> I had originally implemented allowing a host to request certificates for other hosts using the requesting IP address. That was a pretty lousy way to do it. This patch uses the DS ACI system instead. We came up with a clever ACI that lets hosts listed in the managedBy attribute in the service modify the userCertificate attribute. So you can use this to delegate which hosts can request certificates for which services, even for other machines. I also re-ordered the request_certificate() method a bit. We want all the service work done before we do the certificate request. It was previously adding the service after the cert request was done. This could mean a failed request if the requestor isn't allowed to add services. But it is also too late because the cert had already been issued. I documented how this works a bit at http://www.freeipa.org/page/Certificate_Authority rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-304-cert.patch Type: application/mbox Size: 12393 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Thu Oct 29 16:31:50 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 29 Oct 2009 17:31:50 +0100 Subject: [Freeipa-devel] [PATCH] Make ldap2.convert_attr_synonyms more robust against schema lookup fails. Message-ID: <4AE9C376.9090906@redhat.com> Rob Crittenden wrote: > The user plugin is crapping out on line 317 of ldap2.py because attr is coming back None. The attribute it is looking for is member. > > I think the fix involves setting member_attributes = ['member'] to the user plugin. > > I wonder if we need to make the ldap2 plugin a bit more robust too so it can handle it better if the schema lookup returns None. > > rob This should fix the issue. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-ldap2.convert_attr_synonyms-more-robust-against.patch Type: application/mbox Size: 894 bytes Desc: not available URL: From pzuna at redhat.com Thu Oct 29 17:20:03 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 29 Oct 2009 18:20:03 +0100 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. Message-ID: <4AE9CEC3.5060905@redhat.com> Example output of migration plugin: I have a DS server setup on a VM at 192.168.122.4 and I made a few tweaks to show how errors are reported. # ipa migrate-ds ldap://192.168.122.4:389 Password: Enter password again to verify: ----------- migrate-ds: ----------- Migrated: users: pzuna, mnagy groups: skupina1, skupina2, skupina3 Errors: user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use 'ipa user-mod' to set it manually. group: accounting managers: This entry already exists group: hr managers: This entry already exists group: qa managers: This entry already exists group: pd managers: This entry already exists ---------- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clean text passwords. All migrated users need to login at http://your.domain/ipa/migration/ before they can use their Kerberos accounts. I didn't try it yet, but this might also work for IPAv1->IPAv2 migration. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-DS-migration-plugin-and-password-migration-page.patch Type: application/mbox Size: 17285 bytes Desc: not available URL: From pzuna at redhat.com Thu Oct 29 17:29:57 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 29 Oct 2009 18:29:57 +0100 Subject: [Freeipa-devel] [PATCH] Remove 'ipaObject' objectClass from rolegroups and taskgroups. Message-ID: <4AE9D115.9000006@redhat.com> We don't need it there and rolegroups/taskgroup created on installation don't have it, so they didn't show up in *-find output before this patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-ipaObject-objectClass-from-rolegroups-and-t.patch Type: application/mbox Size: 1634 bytes Desc: not available URL: From dpal at redhat.com Thu Oct 29 17:33:29 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 29 Oct 2009 13:33:29 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AE9CEC3.5060905@redhat.com> References: <4AE9CEC3.5060905@redhat.com> Message-ID: <4AE9D1E9.3060504@redhat.com> Pavel Zuna wrote: > Example output of migration plugin: > > I have a DS server setup on a VM at 192.168.122.4 and I made a few > tweaks to show how errors are reported. > > # ipa migrate-ds ldap://192.168.122.4:389 > Password: > Enter password again to verify: > ----------- > migrate-ds: > ----------- > Migrated: > users: pzuna, mnagy > groups: skupina1, skupina2, skupina3 > Errors: > user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use 'ipa > user-mod' to set it manually. > group: accounting managers: This entry already exists > group: hr managers: This entry already exists > group: qa managers: This entry already exists > group: pd managers: This entry already exists > ---------- > Passwords have been migrated in pre-hashed format. IPA is unable to > generate Kerberos keys unless provided with clean text passwords. All > migrated users need to login at http://your.domain/ipa/migration/ > before they can use their Kerberos accounts. > > I didn't try it yet, but this might also work for IPAv1->IPAv2 migration. > > Pavel > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nice. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 30 14:24:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 10:24:19 -0400 Subject: [Freeipa-devel] [PATCH] Change checks in List.normalize to filter out illegal values. In-Reply-To: <4AE1DDF3.2030502@redhat.com> References: <4AE1DDF3.2030502@redhat.com> Message-ID: <4AEAF713.3000408@redhat.com> Pavel Z?na wrote: > As we started converting NULL values to None a while back, > List.normalize blows up if we set an empty tuple default value. > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 30 14:24:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 10:24:58 -0400 Subject: [Freeipa-devel] [PATCH] Change checks in List.normalize to filter out illegal values. In-Reply-To: <4AE2D147.6080301@redhat.com> References: <4AE1DDF3.2030502@redhat.com> <4AE2D147.6080301@redhat.com> Message-ID: <4AEAF73A.4010008@redhat.com> Pavel Z?na wrote: > Pavel Z?na wrote: >> As we started converting NULL values to None a while back, >> List.normalize blows up if we set an empty tuple default value. >> >> Pavel >> > nack! > > This actually introduces a bigger problem than it solves, my mistake. > > Fixed version attached. > > To demonstrate the bug this (was) is supposed to solve, try this before > applying the patch: > > ipa group-add-member ipausers --users="" > > Pavel > Ok, I actually did push the right patch, just responded to the wrong e-mail :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 30 14:27:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 10:27:15 -0400 Subject: [Freeipa-devel] [PATCH] Make ldap2.convert_attr_synonyms more robust against schema lookup fails. In-Reply-To: <4AE9C376.9090906@redhat.com> References: <4AE9C376.9090906@redhat.com> Message-ID: <4AEAF7C3.8000102@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> The user plugin is crapping out on line 317 of ldap2.py because attr >> is coming back None. The attribute it is looking for is member. >> >> I think the fix involves setting member_attributes = ['member'] to the >> user plugin. >> >> I wonder if we need to make the ldap2 plugin a bit more robust too so >> it can handle it better if the schema lookup returns None. >> >> rob > This should fix the issue. > I wonder if we should log something too. This affects the member attribute used in member commands and this blowing up helped me figure out how to set it up. In theory this could send an unknown attribute to LDAP, right? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 30 14:54:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 10:54:31 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AE9CEC3.5060905@redhat.com> References: <4AE9CEC3.5060905@redhat.com> Message-ID: <4AEAFE27.8000305@redhat.com> Pavel Zuna wrote: > Example output of migration plugin: > > I have a DS server setup on a VM at 192.168.122.4 and I made a few > tweaks to show how errors are reported. > > # ipa migrate-ds ldap://192.168.122.4:389 > Password: > Enter password again to verify: > ----------- > migrate-ds: > ----------- > Migrated: > users: pzuna, mnagy > groups: skupina1, skupina2, skupina3 > Errors: > user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use 'ipa > user-mod' to set it manually. > group: accounting managers: This entry already exists > group: hr managers: This entry already exists > group: qa managers: This entry already exists > group: pd managers: This entry already exists > ---------- > Passwords have been migrated in pre-hashed format. IPA is unable to > generate Kerberos keys unless provided with clean text passwords. All > migrated users need to login at http://your.domain/ipa/migration/ before > they can use their Kerberos accounts. > > I didn't try it yet, but this might also work for IPAv1->IPAv2 migration. > > Pavel I have some concerns with this. Rather than presenting a user password change page this enables basic-auth like kerberos negotiate fallback and uses the username/password presented there to do the password reset. I thought we had discussed actually presenting a form to the user to prompt for this information. One of our goals is to promote the usage of single sign-on using kerberos. Enabling the password fallback can be practical and needed in some cases but I think by default we want to leave it off. The function get_base_dn() needs some error handling. I'm not sure how this will blow up if the LDAP server is down but it won't be pretty, it assumes that a namingcontext is returned, etc. For the migration there is a typo in pwd_migration_msg, "clean text" instead of "clear text". Why are you duplicating the user_add functionality instead of calling api.Command['user_add']? Same with groups, why not user the gropu_add and group_add_member methods? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Fri Oct 30 15:33:31 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 30 Oct 2009 16:33:31 +0100 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEAFE27.8000305@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> Message-ID: <4AEB074B.6030809@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Example output of migration plugin: >> >> I have a DS server setup on a VM at 192.168.122.4 and I made a few >> tweaks to show how errors are reported. >> >> # ipa migrate-ds ldap://192.168.122.4:389 >> Password: >> Enter password again to verify: >> ----------- >> migrate-ds: >> ----------- >> Migrated: >> users: pzuna, mnagy >> groups: skupina1, skupina2, skupina3 >> Errors: >> user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use 'ipa >> user-mod' to set it manually. >> group: accounting managers: This entry already exists >> group: hr managers: This entry already exists >> group: qa managers: This entry already exists >> group: pd managers: This entry already exists >> ---------- >> Passwords have been migrated in pre-hashed format. IPA is unable to >> generate Kerberos keys unless provided with clean text passwords. All >> migrated users need to login at http://your.domain/ipa/migration/ >> before they can use their Kerberos accounts. >> >> I didn't try it yet, but this might also work for IPAv1->IPAv2 migration. >> >> Pavel > > I have some concerns with this. Rather than presenting a user password > change page this enables basic-auth like kerberos negotiate fallback and > uses the username/password presented there to do the password reset. I > thought we had discussed actually presenting a form to the user to > prompt for this information. > > One of our goals is to promote the usage of single sign-on using > kerberos. Enabling the password fallback can be practical and needed in > some cases but I think by default we want to leave it off. > According to this page, we need to use form base authentication to replay the password: https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA At first, I thought that "form base authentication" is a normal HTML form, but the term is actually pretty ambiguous and there is no way to replay HTML form data. Without the kerberos negotiate fallback on, replaying the password is useless. There's no replaying going on actually. So, either: 1) we set negotiate fallback ON and use password replaying, after migration page, the user is redirected to his kerberos protected self-service page without the need to enter his password twice 2) we only use the password migration page to generate kerberos keys and tell users to use kinit from then on. > The function get_base_dn() needs some error handling. I'm not sure how > this will blow up if the LDAP server is down but it won't be pretty, it > assumes that a namingcontext is returned, etc. > > For the migration there is a typo in pwd_migration_msg, "clean text" > instead of "clear text". > Ok, I'm going to fix those asap. > Why are you duplicating the user_add functionality instead of calling > api.Command['user_add']? > > Same with groups, why not user the gropu_add and group_add_member methods? Because it would be too much overhead. Migrating a single user would mean: - extract data from DS and convert it to the format accepted by IPA commands - user_add (2 ldap operations: RETRIEVE ipaConfig, ADD) - user_mod (2 ldap operations: RETRIEVE, MODIFY) Now that's 4 operations instead of 1 and a lot of needless processing. It's even worst for groups, because we also have to do group_add_member. On the other hand, migration is a one-shot process, so we don't have to be concerned about speed/server load that much and using IPA commands has its advantages. > > rob Pavel From ssorce at redhat.com Fri Oct 30 16:17:39 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 12:17:39 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEAFE27.8000305@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> Message-ID: <1256919459.2813.2.camel@willson> On Fri, 2009-10-30 at 10:54 -0400, Rob Crittenden wrote: > > One of our goals is to promote the usage of single sign-on using > kerberos. Enabling the password fallback can be practical and needed > in > some cases but I think by default we want to leave it off. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 16:35:55 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 12:35:55 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB074B.6030809@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> Message-ID: <4AEB15EB.8090602@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Example output of migration plugin: >>> >>> I have a DS server setup on a VM at 192.168.122.4 and I made a few >>> tweaks to show how errors are reported. >>> >>> # ipa migrate-ds ldap://192.168.122.4:389 >>> Password: >>> Enter password again to verify: >>> ----------- >>> migrate-ds: >>> ----------- >>> Migrated: >>> users: pzuna, mnagy >>> groups: skupina1, skupina2, skupina3 >>> Errors: >>> user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use >>> 'ipa user-mod' to set it manually. >>> group: accounting managers: This entry already exists >>> group: hr managers: This entry already exists >>> group: qa managers: This entry already exists >>> group: pd managers: This entry already exists >>> ---------- >>> Passwords have been migrated in pre-hashed format. IPA is unable to >>> generate Kerberos keys unless provided with clean text passwords. >>> All migrated users need to login at >>> http://your.domain/ipa/migration/ before they can use their Kerberos >>> accounts. >>> >>> I didn't try it yet, but this might also work for IPAv1->IPAv2 >>> migration. >>> >>> Pavel >> >> I have some concerns with this. Rather than presenting a user >> password change page this enables basic-auth like kerberos negotiate >> fallback and uses the username/password presented there to do the >> password reset. I thought we had discussed actually presenting a form >> to the user to prompt for this information. > > > > One of our goals is to promote the usage of single sign-on using > > kerberos. Enabling the password fallback can be practical and needed in > > some cases but I think by default we want to leave it off. > > > > According to this page, we need to use form base authentication to > replay the password: > https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA > > > At first, I thought that "form base authentication" is a normal HTML > form, but the term is actually pretty ambiguous and there is no way to > replay HTML form data. > > Without the kerberos negotiate fallback on, replaying the password is > useless. There's no replaying going on actually. > > So, either: > 1) we set negotiate fallback ON and use password replaying, after > migration page, the user is redirected to his kerberos protected > self-service page without the need to enter his password twice But this should be done once during his migration. Next time he gets to this page if he does not have a ticket and tries to log in using password the server should say: you already migrated use use kinit to obtain kerberos ticket. Next time he tries to get to this page already having a ticket the page should not be displayed at all and he should be redirected to to the self service screen. Agree? > 2) we only use the password migration page to generate kerberos keys > and tell users to use kinit from then on. > >> The function get_base_dn() needs some error handling. I'm not sure >> how this will blow up if the LDAP server is down but it won't be >> pretty, it assumes that a namingcontext is returned, etc. > > >> For the migration there is a typo in pwd_migration_msg, "clean text" >> instead of "clear text". >> > > Ok, I'm going to fix those asap. > >> Why are you duplicating the user_add functionality instead of calling >> api.Command['user_add']? >> >> Same with groups, why not user the gropu_add and group_add_member >> methods? > > Because it would be too much overhead. > > Migrating a single user would mean: > - extract data from DS and convert it to the format accepted by IPA > commands > - user_add (2 ldap operations: RETRIEVE ipaConfig, ADD) > - user_mod (2 ldap operations: RETRIEVE, MODIFY) > > Now that's 4 operations instead of 1 and a lot of needless processing. > It's even worst for groups, because we also have to do group_add_member. > > On the other hand, migration is a one-shot process, so we don't have > to be concerned about speed/server load that much and using IPA > commands has its advantages. > >> >> rob > > Pavel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 30 18:13:14 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 14:13:14 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB074B.6030809@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> Message-ID: <4AEB2CBA.8040207@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Example output of migration plugin: >>> >>> I have a DS server setup on a VM at 192.168.122.4 and I made a few >>> tweaks to show how errors are reported. >>> >>> # ipa migrate-ds ldap://192.168.122.4:389 >>> Password: >>> Enter password again to verify: >>> ----------- >>> migrate-ds: >>> ----------- >>> Migrated: >>> users: pzuna, mnagy >>> groups: skupina1, skupina2, skupina3 >>> Errors: >>> user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use >>> 'ipa user-mod' to set it manually. >>> group: accounting managers: This entry already exists >>> group: hr managers: This entry already exists >>> group: qa managers: This entry already exists >>> group: pd managers: This entry already exists >>> ---------- >>> Passwords have been migrated in pre-hashed format. IPA is unable to >>> generate Kerberos keys unless provided with clean text passwords. All >>> migrated users need to login at http://your.domain/ipa/migration/ >>> before they can use their Kerberos accounts. >>> >>> I didn't try it yet, but this might also work for IPAv1->IPAv2 >>> migration. >>> >>> Pavel >> >> I have some concerns with this. Rather than presenting a user password >> change page this enables basic-auth like kerberos negotiate fallback >> and uses the username/password presented there to do the password >> reset. I thought we had discussed actually presenting a form to the >> user to prompt for this information. > > > > One of our goals is to promote the usage of single sign-on using > > kerberos. Enabling the password fallback can be practical and needed in > > some cases but I think by default we want to leave it off. > > > > According to this page, we need to use form base authentication to > replay the password: > https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA > > > At first, I thought that "form base authentication" is a normal HTML > form, but the term is actually pretty ambiguous and there is no way to > replay HTML form data. > > Without the kerberos negotiate fallback on, replaying the password is > useless. There's no replaying going on actually. > > So, either: > 1) we set negotiate fallback ON and use password replaying, after > migration page, the user is redirected to his kerberos protected > self-service page without the need to enter his password twice > 2) we only use the password migration page to generate kerberos keys and > tell users to use kinit from then on. #2 is the way to go. We need to put up a simple form that has fields for username, old password and 2 new passwords and a submit button. We can't redirect them to the UI once we're done, as you point out. This is fine IMHO as it is unlikely their browser is set up to use kerberos anyway. We could redirect them to the login page, which will fail and contain instructions on how to set up their browser and do a kinit. We may need to modify the message on that page to contain specific info for those migrating. >> The function get_base_dn() needs some error handling. I'm not sure how >> this will blow up if the LDAP server is down but it won't be pretty, >> it assumes that a namingcontext is returned, etc. > > >> For the migration there is a typo in pwd_migration_msg, "clean text" >> instead of "clear text". >> > > Ok, I'm going to fix those asap. > >> Why are you duplicating the user_add functionality instead of calling >> api.Command['user_add']? >> >> Same with groups, why not user the gropu_add and group_add_member >> methods? > > Because it would be too much overhead. > > Migrating a single user would mean: > - extract data from DS and convert it to the format accepted by IPA > commands > - user_add (2 ldap operations: RETRIEVE ipaConfig, ADD) > - user_mod (2 ldap operations: RETRIEVE, MODIFY) > > Now that's 4 operations instead of 1 and a lot of needless processing. > It's even worst for groups, because we also have to do group_add_member. > > On the other hand, migration is a one-shot process, so we don't have to > be concerned about speed/server load that much and using IPA commands > has its advantages. The risk is maintaining the same code in 2 places. If we end up finding some critical bug in user_add it is very likely to get overlooked here. Might be worth knowing how much this will really affect things. I think we should generate a ton of LDAP entries (say several thousand, if not more) and migrate using both methods to see what overhead is involved. Unless it is significantly faster I think I'd rather go with code re-use. I'd guess that the guys in 389 have a script to auto-generate entries. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Fri Oct 30 18:28:38 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 14:28:38 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB2CBA.8040207@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> Message-ID: <4AEB3056.1050401@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> Example output of migration plugin: >>>> >>>> I have a DS server setup on a VM at 192.168.122.4 and I made a few >>>> tweaks to show how errors are reported. >>>> >>>> # ipa migrate-ds ldap://192.168.122.4:389 >>>> Password: >>>> Enter password again to verify: >>>> ----------- >>>> migrate-ds: >>>> ----------- >>>> Migrated: >>>> users: pzuna, mnagy >>>> groups: skupina1, skupina2, skupina3 >>>> Errors: >>>> user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use >>>> 'ipa user-mod' to set it manually. >>>> group: accounting managers: This entry already exists >>>> group: hr managers: This entry already exists >>>> group: qa managers: This entry already exists >>>> group: pd managers: This entry already exists >>>> ---------- >>>> Passwords have been migrated in pre-hashed format. IPA is unable to >>>> generate Kerberos keys unless provided with clean text passwords. >>>> All migrated users need to login at >>>> http://your.domain/ipa/migration/ before they can use their >>>> Kerberos accounts. >>>> >>>> I didn't try it yet, but this might also work for IPAv1->IPAv2 >>>> migration. >>>> >>>> Pavel >>> >>> I have some concerns with this. Rather than presenting a user >>> password change page this enables basic-auth like kerberos negotiate >>> fallback and uses the username/password presented there to do the >>> password reset. I thought we had discussed actually presenting a >>> form to the user to prompt for this information. >> > >> > One of our goals is to promote the usage of single sign-on using >> > kerberos. Enabling the password fallback can be practical and >> needed in >> > some cases but I think by default we want to leave it off. >> > >> >> According to this page, we need to use form base authentication to >> replay the password: >> https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA >> >> >> At first, I thought that "form base authentication" is a normal HTML >> form, but the term is actually pretty ambiguous and there is no way >> to replay HTML form data. >> >> Without the kerberos negotiate fallback on, replaying the password is >> useless. There's no replaying going on actually. >> >> So, either: >> 1) we set negotiate fallback ON and use password replaying, after >> migration page, the user is redirected to his kerberos protected >> self-service page without the need to enter his password twice >> 2) we only use the password migration page to generate kerberos keys >> and tell users to use kinit from then on. > > #2 is the way to go. We need to put up a simple form that has fields > for username, old password and 2 new passwords and a submit button. We > can't redirect them to the UI once we're done, as you point out. This > is fine IMHO as it is unlikely their browser is set up to use kerberos > anyway. We could redirect them to the login page, which will fail and > contain instructions on how to set up their browser and do a kinit. We > may need to modify the message on that page to contain specific info > for those migrating. Why we can't call kinit (or equivalent) on their behalf as soon as we migrated them right away ourselves and then redirect then to the right place - self service page? Why make them fail? I assume that things like cfengine or puppet can be used to already precofigure browsers to know about IPA. So failing them and forcing them to use kinit manually sounds like a bad user experience approach to me. Do browsers support this? I understand that we would need to pass the ticket back so that the browser can store it in the key store on the client for future use? If it is not possible I would suggest filing an RFE so that the browser can get the ticket from the application and store it on the user's machine. With kerberos now supporting S4U this might be a very valuable feature to have. Am I smoking something? > >>> The function get_base_dn() needs some error handling. I'm not sure >>> how this will blow up if the LDAP server is down but it won't be >>> pretty, it assumes that a namingcontext is returned, etc. >> > >>> For the migration there is a typo in pwd_migration_msg, "clean text" >>> instead of "clear text". >>> >> >> Ok, I'm going to fix those asap. >> >>> Why are you duplicating the user_add functionality instead of >>> calling api.Command['user_add']? >>> >>> Same with groups, why not user the gropu_add and group_add_member >>> methods? >> >> Because it would be too much overhead. >> >> Migrating a single user would mean: >> - extract data from DS and convert it to the format accepted by IPA >> commands >> - user_add (2 ldap operations: RETRIEVE ipaConfig, ADD) >> - user_mod (2 ldap operations: RETRIEVE, MODIFY) >> >> Now that's 4 operations instead of 1 and a lot of needless >> processing. It's even worst for groups, because we also have to do >> group_add_member. >> >> On the other hand, migration is a one-shot process, so we don't have >> to be concerned about speed/server load that much and using IPA >> commands has its advantages. > > The risk is maintaining the same code in 2 places. If we end up > finding some critical bug in user_add it is very likely to get > overlooked here. > > Might be worth knowing how much this will really affect things. I > think we should generate a ton of LDAP entries (say several thousand, > if not more) and migrate using both methods to see what overhead is > involved. Unless it is significantly faster I think I'd rather go with > code re-use. > > I'd guess that the guys in 389 have a script to auto-generate entries. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 30 18:52:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 14:52:22 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB3056.1050401@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> Message-ID: <4AEB35E6.3090401@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Rob Crittenden wrote: >>>> Pavel Zuna wrote: >>>>> Example output of migration plugin: >>>>> >>>>> I have a DS server setup on a VM at 192.168.122.4 and I made a few >>>>> tweaks to show how errors are reported. >>>>> >>>>> # ipa migrate-ds ldap://192.168.122.4:389 >>>>> Password: >>>>> Enter password again to verify: >>>>> ----------- >>>>> migrate-ds: >>>>> ----------- >>>>> Migrated: >>>>> users: pzuna, mnagy >>>>> groups: skupina1, skupina2, skupina3 >>>>> Errors: >>>>> user: mnagy: Kerberos principal mnagy at PZUNA already exists. Use >>>>> 'ipa user-mod' to set it manually. >>>>> group: accounting managers: This entry already exists >>>>> group: hr managers: This entry already exists >>>>> group: qa managers: This entry already exists >>>>> group: pd managers: This entry already exists >>>>> ---------- >>>>> Passwords have been migrated in pre-hashed format. IPA is unable to >>>>> generate Kerberos keys unless provided with clean text passwords. >>>>> All migrated users need to login at >>>>> http://your.domain/ipa/migration/ before they can use their >>>>> Kerberos accounts. >>>>> >>>>> I didn't try it yet, but this might also work for IPAv1->IPAv2 >>>>> migration. >>>>> >>>>> Pavel >>>> I have some concerns with this. Rather than presenting a user >>>> password change page this enables basic-auth like kerberos negotiate >>>> fallback and uses the username/password presented there to do the >>>> password reset. I thought we had discussed actually presenting a >>>> form to the user to prompt for this information. >>> > >>> > One of our goals is to promote the usage of single sign-on using >>> > kerberos. Enabling the password fallback can be practical and >>> needed in >>> > some cases but I think by default we want to leave it off. >>> > >>> >>> According to this page, we need to use form base authentication to >>> replay the password: >>> https://wiki.idm.lab.bos.redhat.com/export/idmwiki/Migration_from_DS_server_to_IPA >>> >>> >>> At first, I thought that "form base authentication" is a normal HTML >>> form, but the term is actually pretty ambiguous and there is no way >>> to replay HTML form data. >>> >>> Without the kerberos negotiate fallback on, replaying the password is >>> useless. There's no replaying going on actually. >>> >>> So, either: >>> 1) we set negotiate fallback ON and use password replaying, after >>> migration page, the user is redirected to his kerberos protected >>> self-service page without the need to enter his password twice >>> 2) we only use the password migration page to generate kerberos keys >>> and tell users to use kinit from then on. >> #2 is the way to go. We need to put up a simple form that has fields >> for username, old password and 2 new passwords and a submit button. We >> can't redirect them to the UI once we're done, as you point out. This >> is fine IMHO as it is unlikely their browser is set up to use kerberos >> anyway. We could redirect them to the login page, which will fail and >> contain instructions on how to set up their browser and do a kinit. We >> may need to modify the message on that page to contain specific info >> for those migrating. > > Why we can't call kinit (or equivalent) on their behalf as soon as we > migrated them right away ourselves and then redirect then to the right > place - self service page? There is no way to trigger this AFAIK. > Why make them fail? True, it isn't ideal but all users fail the first time in the browser as it is. There isn't a stable way to pre-configure the browser currently. It either involves directly modifying files in the firefox rpm which will both cause rpm verification issues and be lost when an upgrade is done. Or we have to run something on the client to fix their browser profile when we run ipa-client-install and this will only affect existing profiles (and won't take effect until any running browser is restarted). There is a browser bug filed so one can configure a directory of additional settings to be read as sort of a global configuration cache. Once this is available we can write to one spot and pre-configure kerberos settings. Similarly once the global NSS database is in place we can put the IPA CA cert there and be trusted by all browsers on the system. > I assume that things like cfengine or puppet can be used to already > precofigure browsers to know about IPA. Probably but again it's a client-side issue and the browser profile needs to be updated. Definitely a possibility. > So failing them and forcing them to use kinit manually sounds like a bad > user experience approach to me. Yup. But this is close to what happens with new users now. They kinit (or not), try to hit the UI and in FF 3.5 fail with a nasty error message about untrusted CA's. If they decide to continue they get a kerberos failed page and can run a little javascript program to configure the browser. This little program causes a hair-on-fire warning to pop up. Then they need to restart the browser to work. > Do browsers support this? I understand that we would need to pass the > ticket back so that the browser can store it in the key store on the > client for future use? No, and I don't think I want my browser to be writing to my ccache to be honest. > If it is not possible I would suggest filing an RFE so that the browser > can get the ticket from the application and store it on the user's machine. > With kerberos now supporting S4U this might be a very valuable feature > to have. You can always file one and see what they say. > Am I smoking something? Well, wanting a nice user experience isn't a bad thing. I sure could use a drink right now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Oct 30 18:59:58 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 14:59:58 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB3056.1050401@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> Message-ID: <1256929198.2813.6.camel@willson> On Fri, 2009-10-30 at 14:28 -0400, Dmitri Pal wrote: > > Am I smoking something? Sorry but I think so :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Oct 30 19:12:07 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 15:12:07 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB3056.1050401@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> Message-ID: <1256929927.2813.16.camel@willson> Ok now on a more serious note ... On Fri, 2009-10-30 at 14:28 -0400, Dmitri Pal wrote: > Why we can't call kinit (or equivalent) on their behalf as soon as we > migrated them right away ourselves and then redirect then to the right > place - self service page? We could call kinit and store the credentials in the server cache for the time the user is connected like we do with forwarded credentials, but we want to go toward S4U to avoid forwarding TGTs in the first place. > Why make them fail? > I assume that things like cfengine or puppet can be used to already > precofigure browsers to know about IPA. In general the browser configuration is kept in the user home directory, and is not something puppet or cfengine should touch (they may have no access to the user home directory until the user is logged in anyway). > So failing them and forcing them to use kinit manually sounds like a > bad > user experience approach to me. We could simply tell them to log off and log on again as an alternative, or to lock the screen and unlock it, if telling the user to run "kinit" is too difficult. > Do browsers support this? No, browsers are built to prevent websites from being able to interact with users files, certainly you can't do a behind the scenes manipulation of users files. At most you can send the user a ccache file and tell him to store it in some place. For some reason I don't think this is any better then telling the user to log off and log in again. > I understand that we would need to pass the > ticket back so that the browser can store it in the key store on the > client for future use? > If it is not possible I would suggest filing an RFE so that the > browser > can get the ticket from the application and store it on the user's > machine. I don't think you want to give website access to the credential cache, really, no. > With kerberos now supporting S4U this might be a very valuable feature > to have. No, S4U is useful exactly to *avoid* having the browser forward around (and therefore expose) user's TGTs ... Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 19:43:24 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 15:43:24 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <1256929927.2813.16.camel@willson> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> Message-ID: <4AEB41DC.5050701@redhat.com> Ok I buy this. Just have questions below... Simo Sorce wrote: > Ok now on a more serious note ... > > On Fri, 2009-10-30 at 14:28 -0400, Dmitri Pal wrote: > >> Why we can't call kinit (or equivalent) on their behalf as soon as we >> migrated them right away ourselves and then redirect then to the right >> place - self service page? >> > > We could call kinit and store the credentials in the server cache for > the time the user is connected like we do with forwarded credentials, > but we want to go toward S4U to avoid forwarding TGTs in the first > place. > So if we have the user TGT on server haw we can use it to improve user experience? > >> Why make them fail? >> I assume that things like cfengine or puppet can be used to already >> precofigure browsers to know about IPA. >> > > In general the browser configuration is kept in the user home directory, > and is not something puppet or cfengine should touch (they may have no > access to the user home directory until the user is logged in anyway). > > We already have the RFE to make FF to be able to configure kerberos more friendly. We can add specifics to it and make this configuration be stored outside of the user home directory so that it can be centrally configured. https://bugzilla.redhat.com/show_bug.cgi?id=526824 Upsteam https://bugzilla.mozilla.org/show_bug.cgi?id=520668 May be we should add it to the bug. But back to the point of user. What is that the browser carries that allows it to access the pages? Is it a cookie of some kind that is created as a result of the authentication using ticket or what? Can we create such cookie on behalf of the user. I understand that it will solve the problem of only this session and if user closes browser he will have to do kinit so may be it is not worth it. I guess asking user to log out and log in will only work if the system is configured to use same IPA with kerberos via SSSD or directly. Is this something that can be checked? If the user's machine is not configured for kerberos with the same domain asking user to log off and log on will not help. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Oct 30 19:49:30 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 15:49:30 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB35E6.3090401@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> Message-ID: <4AEB434A.2080001@redhat.com> > >> Why make them fail? > > True, it isn't ideal but all users fail the first time in the browser > as it is. There isn't a stable way to pre-configure the browser > currently. It either involves directly modifying files in the firefox > rpm which will both cause rpm verification issues and be lost when an > upgrade is done. Or we have to run something on the client to fix > their browser profile when we run ipa-client-install and this will > only affect existing profiles (and won't take effect until any running > browser is restarted). > This should be filed as an RFE with FF. > There is a browser bug filed so one can configure a directory of > additional settings to be read as sort of a global configuration > cache. Once this is available we can write to one spot and > pre-configure kerberos settings. Can you point me to it? > > Similarly once the global NSS database is in place we can put the IPA > CA cert there and be trusted by all browsers on the system. > >> I assume that things like cfengine or puppet can be used to already >> precofigure browsers to know about IPA. > > Probably but again it's a client-side issue and the browser profile > needs to be updated. Definitely a possibility. > >> So failing them and forcing them to use kinit manually sounds like a bad >> user experience approach to me. > > Yup. But this is close to what happens with new users now. They kinit > (or not), try to hit the UI and in FF 3.5 fail with a nasty error > message about untrusted CA's. If they decide to continue they get a > kerberos failed page and can run a little javascript program to > configure the browser. This little program causes a hair-on-fire > warning to pop up. Then they need to restart the browser to work. > They need to accept the cert first time right? Ok I understand why. And where this little javascript program comes from? Do we provide it or it is a part of something standard? Why it causes hair-on-fire? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Oct 30 19:52:32 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 15:52:32 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB41DC.5050701@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> Message-ID: <1256932352.2813.25.camel@willson> On Fri, 2009-10-30 at 15:43 -0400, Dmitri Pal wrote: > Ok I buy this. > Just have questions below... > > Simo Sorce wrote: > > Ok now on a more serious note ... > > > > On Fri, 2009-10-30 at 14:28 -0400, Dmitri Pal wrote: > > > >> Why we can't call kinit (or equivalent) on their behalf as soon as we > >> migrated them right away ourselves and then redirect then to the right > >> place - self service page? > >> > > > > We could call kinit and store the credentials in the server cache for > > the time the user is connected like we do with forwarded credentials, > > but we want to go toward S4U to avoid forwarding TGTs in the first > > place. > > > So if we have the user TGT on server haw we can use it to improve user > experience? The user will be able to access the other UI pages w/o having to pass a kerberos ticket for the duration of the session (will have to get a ticket once it timeouts). > > > >> Why make them fail? > >> I assume that things like cfengine or puppet can be used to already > >> precofigure browsers to know about IPA. > >> > > > > In general the browser configuration is kept in the user home directory, > > and is not something puppet or cfengine should touch (they may have no > > access to the user home directory until the user is logged in anyway). > > > > > We already have the RFE to make FF to be able to configure kerberos more > friendly. I think we already had a page where all you need to do is press a few buttons although that (correctly) shows some warnings and a request to authorize the remote website to set the configuration. > We can add specifics to it and make this configuration be stored outside > of the user home directory > so that it can be centrally configured. > https://bugzilla.redhat.com/show_bug.cgi?id=526824 > > Upsteam > https://bugzilla.mozilla.org/show_bug.cgi?id=520668 > > May be we should add it to the bug. I don't see much care for that bug from upstream :-) > But back to the point of user. > What is that the browser carries that allows it to access the pages? It depends, in freeipa v1 it would send krb credentials for each http connection. In freeipa v2 we should be using a cookie (also sent for each http request) generated after the first kerberos authentication against a special auth page. > Is it a cookie of some kind that is created as a result of the > authentication using ticket or what? yes. > Can we create such cookie on behalf of the user. yes, that's what I meant above. > I understand that it will solve the problem of only this session and if > user closes browser > he will have to do kinit so may be it is not worth it. It should be easy to do, although I wouldn't rate it as a priority, for me it is fine to ask the user to logoff/login, it is a one-time thing anyway. > I guess asking user to log out and log in will only work if the system > is configured to use same IPA with kerberos via SSSD or directly. > Is this something that can be checked? Not from the browser of course, but if the system is not set up for that then the only way is to use kinit manually every time. > If the user's machine is not configured for kerberos with the same > domain asking user to log off and log on will not help. Neither anything else :) I guess the best thing is to allow each site to put up a customize message with instructions on what to do next and by default set a message valid for a fully kerberized machine. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 19:52:48 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 15:52:48 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB41DC.5050701@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> Message-ID: <4AEB4410.5020505@redhat.com> Dmitri Pal wrote: > Ok I buy this. > Just have questions below... > > Simo Sorce wrote: > >> Ok now on a more serious note ... >> >> On Fri, 2009-10-30 at 14:28 -0400, Dmitri Pal wrote: >> >> >>> Why we can't call kinit (or equivalent) on their behalf as soon as we >>> migrated them right away ourselves and then redirect then to the right >>> place - self service page? >>> >>> >> We could call kinit and store the credentials in the server cache for >> the time the user is connected like we do with forwarded credentials, >> but we want to go toward S4U to avoid forwarding TGTs in the first >> place. >> >> > So if we have the user TGT on server haw we can use it to improve user > experience? > > > >> >> >>> Why make them fail? >>> I assume that things like cfengine or puppet can be used to already >>> precofigure browsers to know about IPA. >>> >>> >> In general the browser configuration is kept in the user home directory, >> and is not something puppet or cfengine should touch (they may have no >> access to the user home directory until the user is logged in anyway). >> >> >> > We already have the RFE to make FF to be able to configure kerberos more > friendly. > We can add specifics to it and make this configuration be stored outside > of the user home directory > so that it can be centrally configured. > https://bugzilla.redhat.com/show_bug.cgi?id=526824 > > Upsteam > https://bugzilla.mozilla.org/show_bug.cgi?id=520668 > > May be we should add it to the bug. > > But back to the point of user. > What is that the browser carries that allows it to access the pages? > Is it a cookie of some kind that is created as a result of the > authentication using ticket or what? > Can we create such cookie on behalf of the user. > I understand that it will solve the problem of only this session and if > user closes browser > he will have to do kinit so may be it is not worth it. > > I guess asking user to log out and log in will only work if the system > is configured to use same IPA with kerberos via SSSD or directly. > Is this something that can be checked? > If the user's machine is not configured for kerberos with the same > domain asking user to log off and log on will not help. > > I guess if we put the message into an attribute somewhere in the cn=config and pull it from DS instead of making it a part of the page itself we would give the admin choice what to tell user to do in this case. "Kinit" or "logoff/login" or "check this ... if you are then ... otherwise ..." this together with migration instructions would help a lot. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Oct 30 19:54:45 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 15:54:45 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4410.5020505@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> Message-ID: <1256932485.2813.27.camel@willson> On Fri, 2009-10-30 at 15:52 -0400, Dmitri Pal wrote: > I guess if we put the message into an attribute somewhere in the > cn=config and pull it from DS instead of making it a part of the page > itself > we would give the admin choice what to tell user to do in this case. > "Kinit" or "logoff/login" or "check this ... if you are then ... > otherwise ..." this together with migration instructions would help a > lot. Yes, except I'd lean toward a file on the server, it's a static configuration and it seem too much to have to go through hoops to store/retrieve it from ldap just to show a one-off message. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 19:55:01 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 15:55:01 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <1256932352.2813.25.camel@willson> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <1256932352.2813.25.camel@willson> Message-ID: <4AEB4495.50304@redhat.com> > Neither anything else :) > I guess the best thing is to allow each site to put up a customize > message with instructions on what to do next and by default set a > message valid for a fully kerberized machine. > > Simo. > > We agree :-) -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Oct 30 19:56:08 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 15:56:08 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <1256932485.2813.27.camel@willson> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> <1256932485.2813.27.camel@willson> Message-ID: <4AEB44D8.2000902@redhat.com> Simo Sorce wrote: > On Fri, 2009-10-30 at 15:52 -0400, Dmitri Pal wrote: > >> I guess if we put the message into an attribute somewhere in the >> cn=config and pull it from DS instead of making it a part of the page >> itself >> we would give the admin choice what to tell user to do in this case. >> "Kinit" or "logoff/login" or "check this ... if you are then ... >> otherwise ..." this together with migration instructions would help a >> lot. >> > > Yes, except I'd lean toward a file on the server, it's a static > configuration and it seem too much to have to go through hoops to > store/retrieve it from ldap just to show a one-off message. > > Simo. > > But then you have to update it on all replicas and will definitely forget to do it. Is it really a hassle to have it in the DS? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Oct 30 19:57:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 15:57:37 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB434A.2080001@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> Message-ID: <4AEB4531.3060802@redhat.com> Dmitri Pal wrote: >>> Why make them fail? >> True, it isn't ideal but all users fail the first time in the browser >> as it is. There isn't a stable way to pre-configure the browser >> currently. It either involves directly modifying files in the firefox >> rpm which will both cause rpm verification issues and be lost when an >> upgrade is done. Or we have to run something on the client to fix >> their browser profile when we run ipa-client-install and this will >> only affect existing profiles (and won't take effect until any running >> browser is restarted). >> > This should be filed as an RFE with FF. This would be handled by the bug below. > > >> There is a browser bug filed so one can configure a directory of >> additional settings to be read as sort of a global configuration >> cache. Once this is available we can write to one spot and >> pre-configure kerberos settings. > > Can you point me to it? https://bugzilla.redhat.com/show_bug.cgi?id=516200 > >> Similarly once the global NSS database is in place we can put the IPA >> CA cert there and be trusted by all browsers on the system. >> >>> I assume that things like cfengine or puppet can be used to already >>> precofigure browsers to know about IPA. >> Probably but again it's a client-side issue and the browser profile >> needs to be updated. Definitely a possibility. >> >>> So failing them and forcing them to use kinit manually sounds like a bad >>> user experience approach to me. >> Yup. But this is close to what happens with new users now. They kinit >> (or not), try to hit the UI and in FF 3.5 fail with a nasty error >> message about untrusted CA's. If they decide to continue they get a >> kerberos failed page and can run a little javascript program to >> configure the browser. This little program causes a hair-on-fire >> warning to pop up. Then they need to restart the browser to work. >> > > They need to accept the cert first time right? Ok I understand why. Yes but beginning with FF 3.5 they have to go through a 2-step process where they accept the CA, add an exception etc. > And where this little javascript program comes from? > Do we provide it or it is a part of something standard? We provide it on the IPA server. It modified the user preferences to configure kerberos. In order to modify user preferences the javascript needs to be signed by a trusted CA (we use the IPA CA) and the user must agree to it. The dialog that asks has a several second pause before Ok is ungreyed. > Why it causes hair-on-fire? The message is not configurable, it just says that something is trying to modify your user preferences. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Oct 30 20:00:20 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 16:00:20 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB44D8.2000902@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> <1256932485.2813.27.camel@willson> <4AEB44D8.2000902@redhat.com> Message-ID: <1256932820.2813.31.camel@willson> On Fri, 2009-10-30 at 15:56 -0400, Dmitri Pal wrote: > But then you have to update it on all replicas and will definitely > forget to do it. > Is it really a hassle to have it in the DS? Yes it means you have to build a UI to manage that attribute, create it, find a place where to store it in the tree etc.. and adds cruft to the tree. A file is a simple drop in and admins can easily change it at any time. True, if they forget to replicate it on other servers it will get out of sync, but it is also easy to fix that if it happens. We can put a comment in the template that reminds admins to always replicate it to all servers. However do you think admins will set it up on all servers ? I was thinking they would set up the migration stuff only on one server and give out only one server URL, so I don't think we should care about replicating it to other servers normally. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Oct 30 20:03:19 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 16:03:19 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4531.3060802@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> <4AEB4531.3060802@redhat.com> Message-ID: <1256932999.2813.33.camel@willson> On Fri, 2009-10-30 at 15:57 -0400, Rob Crittenden wrote: > > The message is not configurable, it just says that something is > trying > to modify your user preferences. And rightly so, this is a security warning. If it were modifiable a rogue server could change the message to ask: "do you like bacon ?" To which *everyone* would have to answer Yes :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 20:10:46 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 16:10:46 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4531.3060802@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> <4AEB4531.3060802@redhat.com> Message-ID: <4AEB4846.1070106@redhat.com> Rob Crittenden wrote: > Dmitri Pal wrote: >>>> Why make them fail? >>> True, it isn't ideal but all users fail the first time in the browser >>> as it is. There isn't a stable way to pre-configure the browser >>> currently. It either involves directly modifying files in the firefox >>> rpm which will both cause rpm verification issues and be lost when an >>> upgrade is done. Or we have to run something on the client to fix >>> their browser profile when we run ipa-client-install and this will >>> only affect existing profiles (and won't take effect until any running >>> browser is restarted). >>> >> This should be filed as an RFE with FF. > > This would be handled by the bug below. > >> >> >>> There is a browser bug filed so one can configure a directory of >>> additional settings to be read as sort of a global configuration >>> cache. Once this is available we can write to one spot and >>> pre-configure kerberos settings. >> >> Can you point me to it? > > https://bugzilla.redhat.com/show_bug.cgi?id=516200 >> >>> Similarly once the global NSS database is in place we can put the IPA >>> CA cert there and be trusted by all browsers on the system. >>> >>>> I assume that things like cfengine or puppet can be used to already >>>> precofigure browsers to know about IPA. >>> Probably but again it's a client-side issue and the browser profile >>> needs to be updated. Definitely a possibility. >>> >>>> So failing them and forcing them to use kinit manually sounds like >>>> a bad >>>> user experience approach to me. >>> Yup. But this is close to what happens with new users now. They kinit >>> (or not), try to hit the UI and in FF 3.5 fail with a nasty error >>> message about untrusted CA's. If they decide to continue they get a >>> kerberos failed page and can run a little javascript program to >>> configure the browser. This little program causes a hair-on-fire >>> warning to pop up. Then they need to restart the browser to work. >>> >> >> They need to accept the cert first time right? Ok I understand why. > > Yes but beginning with FF 3.5 they have to go through a 2-step process > where they accept the CA, add an exception etc. > >> And where this little javascript program comes from? >> Do we provide it or it is a part of something standard? > > We provide it on the IPA server. It modified the user preferences to > configure kerberos. In order to modify user preferences the javascript > needs to be signed by a trusted CA (we use the IPA CA) and the user > must agree to it. The dialog that asks has a several second pause > before Ok is ungreyed. > >> Why it causes hair-on-fire? > > The message is not configurable, it just says that something is trying > to modify your user preferences. > > rob Anything we think might improve user experience let us log a bug for it. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Oct 30 20:21:26 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 16:21:26 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <1256932820.2813.31.camel@willson> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> <1256932485.2813.27.camel@willson> <4AEB44D8.2000902@redhat.com> <1256932820.2813.31.camel@willson> Message-ID: <4AEB4AC6.9030504@redhat.com> Simo Sorce wrote: > On Fri, 2009-10-30 at 15:56 -0400, Dmitri Pal wrote: > >> But then you have to update it on all replicas and will definitely >> forget to do it. >> Is it really a hassle to have it in the DS? >> > > Yes it means you have to build a UI to manage that attribute, create it, > find a place where to store it in the tree etc.. and adds cruft to the > tree. > > There are a lot of other things that we put in the cn=config replicate but do not provide UI. Admin will just run ldapmodify command for this attribute and this is it. > A file is a simple drop in and admins can easily change it at any time. > > True, if they forget to replicate it on other servers it will get out of > sync, but it is also easy to fix that if it happens. We can put a > comment in the template that reminds admins to always replicate it to > all servers. > Why it should be limited to a server. This IMO will be an artificaial limitation. Any server can perform migration and replicate the created kerberos keys so why limit? > However do you think admins will set it up on all servers ? Yes. I do not see "set". Functionality is just there available from any server. They do not need to do anything to set it up. > I was > thinking they would set up the migration stuff only on one server and > give out only one server URL, so I don't think we should care about > replicating it to other servers normally. > > Simo. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Oct 30 20:25:02 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 16:25:02 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <1256932999.2813.33.camel@willson> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> <4AEB4531.3060802@redhat.com> <1256932999.2813.33.camel@willson> Message-ID: <4AEB4B9E.4010606@redhat.com> Simo Sorce wrote: > On Fri, 2009-10-30 at 15:57 -0400, Rob Crittenden wrote: > >> The message is not configurable, it just says that something is >> trying >> to modify your user preferences. >> > > And rightly so, this is a security warning. If it were modifiable a > rogue server could change the message to ask: "do you like bacon ?" > To which *everyone* would have to answer Yes :-) > > Simo. > > Modifiable by the program no, I agree. But configurable centrally on per server basis why not? I would say that it would be nice to be able to configure FF centrally to: * Automatically accept cert from IPA. * Have a right configuration in the preferences for kerberos I think it all boils down to enhancements to FF. Let me see what I can do about it. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Oct 30 20:29:52 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 16:29:52 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4AC6.9030504@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> <1256932485.2813.27.camel@willson> <4AEB44D8.2000902@redhat.com> <1256932820.2813.31.camel@willson> <4AEB4AC6.9030504@redhat.com> Message-ID: <1256934592.2813.38.camel@willson> On Fri, 2009-10-30 at 16:21 -0400, Dmitri Pal wrote: > Simo Sorce wrote: > > On Fri, 2009-10-30 at 15:56 -0400, Dmitri Pal wrote: > > > >> But then you have to update it on all replicas and will definitely > >> forget to do it. > >> Is it really a hassle to have it in the DS? > >> > > > > Yes it means you have to build a UI to manage that attribute, create it, > > find a place where to store it in the tree etc.. and adds cruft to the > > tree. > > > > > There are a lot of other things that we put in the cn=config replicate > but do not provide UI. > Admin will just run ldapmodify command for this attribute and this is it. It's really not easy at all to put formatted text in an attribute in an ldif file, I wouldn't recommend something lie that. > > A file is a simple drop in and admins can easily change it at any time. > > > > True, if they forget to replicate it on other servers it will get out of > > sync, but it is also easy to fix that if it happens. We can put a > > comment in the template that reminds admins to always replicate it to > > all servers. > > > Why it should be limited to a server. This IMO will be an artificaial > limitation. It's not a limitation you can set up multiple servers if you want, but most likely you will send out just one URL organization wide. Remember it's a one-time thing. > Any server can perform migration and replicate the created kerberos keys > so why limit? Limit? Copying one file over hardly looks like a limit. What I think is that admins will "limit themselves", it make no sense for them to send out URLs to multiple servers etc for something like a one-off. > > However do you think admins will set it up on all servers ? > Yes. I do not see "set". Functionality is just there available from any > server. > They do not need to do anything to set it up. Surely we will need to configure this stuff only if there is a migration, do we want to expose this stuff if there is no migration to perform at all ? At the very least I would expect a global switch to turn this on and off ... Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Oct 30 20:29:57 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 16:29:57 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4AC6.9030504@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> <1256932485.2813.27.camel@willson> <4AEB44D8.2000902@redhat.com> <1256932820.2813.31.camel@willson> <4AEB4AC6.9030504@redhat.com> Message-ID: <4AEB4CC5.3080007@redhat.com> Dmitri Pal wrote: > Simo Sorce wrote: >> On Fri, 2009-10-30 at 15:56 -0400, Dmitri Pal wrote: >> >>> But then you have to update it on all replicas and will definitely >>> forget to do it. >>> Is it really a hassle to have it in the DS? >>> >> Yes it means you have to build a UI to manage that attribute, create it, >> find a place where to store it in the tree etc.. and adds cruft to the >> tree. >> >> > There are a lot of other things that we put in the cn=config replicate > but do not provide UI. > Admin will just run ldapmodify command for this attribute and this is it. I agree with Simo. I think it would require more development time than user's would benefit. We can always include this static file when we create replicas (just won't help those replica's already created). It is simple enough to copy a file around. Plus in order to store it in an LDAP attribute it means that whatever page displays the message needs to be a separate server-side program that reads and displays the data. Not difficult, again just seems like overkill. > >> A file is a simple drop in and admins can easily change it at any time. >> >> True, if they forget to replicate it on other servers it will get out of >> sync, but it is also easy to fix that if it happens. We can put a >> comment in the template that reminds admins to always replicate it to >> all servers. >> > Why it should be limited to a server. This IMO will be an artificaial > limitation. > Any server can perform migration and replicate the created kerberos keys > so why limit? I agree with you here. No reason any IPA server can't assist with the migration. > >> However do you think admins will set it up on all servers ? > Yes. I do not see "set". Functionality is just there available from any > server. > They do not need to do anything to set it up. I agree. rob > >> I was >> thinking they would set up the migration stuff only on one server and >> give out only one server URL, so I don't think we should care about >> replicating it to other servers normally. >> >> Simo. >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Oct 30 20:30:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Oct 2009 16:30:09 -0400 Subject: [Freeipa-devel] [PATCH] 305 remove a principal from a keytab Message-ID: <4AEB4CD1.9010707@redhat.com> I wasn't able to find a command-line program to remove principals from a keytab so I wrote my own. ktutil can do it but it doesn't take command-line arguments. Java ships a utility named ktab but adding a huge dependency for one app seem a bit much :-) In any case, this program has 2 modes: 1. Given a keytab and a principal, remove all entries of that principal from the keytab. This removes all versions and encryption types. 2. Given a realm remove all principals in that realm. I cheat a little and insert an @ before the principal name because all this really does is a strstr() to see if the principal in the keytab is in the realm provided. This utility will be added to the ipa-client-uninstall script at some point to clean up /etc/krb5.keytab. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-305-keytab.patch Type: application/mbox Size: 13126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Oct 30 20:32:06 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 16:32:06 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4B9E.4010606@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> <4AEB4531.3060802@redhat.com> <1256932999.2813.33.camel@willson> <4AEB4B9E.4010606@redhat.com> Message-ID: <1256934726.2813.40.camel@willson> On Fri, 2009-10-30 at 16:25 -0400, Dmitri Pal wrote: > Simo Sorce wrote: > > On Fri, 2009-10-30 at 15:57 -0400, Rob Crittenden wrote: > > > >> The message is not configurable, it just says that something is > >> trying > >> to modify your user preferences. > >> > > > > And rightly so, this is a security warning. If it were modifiable a > > rogue server could change the message to ask: "do you like bacon ?" > > To which *everyone* would have to answer Yes :-) > > > > Simo. > > > > > Modifiable by the program no, I agree. But configurable centrally on per > server basis why not? Dmitri, this is a message the *client* shows the user, and the job of the client is to prevent servers to play with it ... > I would say that it would be nice to be able to configure FF centrally to: > > * Automatically accept cert from IPA. > * Have a right configuration in the preferences for kerberos Certainly, but out of band, you can't do this from a Web Server you are connecting to. This is a job for puppet/cfengine/etc... > I think it all boils down to enhancements to FF. > Let me see what I can do about it. Nothing, you'd be asking to break a security feature of the browser ... Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 20:36:03 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 16:36:03 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <1256934726.2813.40.camel@willson> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> <4AEB4531.3060802@redhat.com> <1256932999.2813.33.camel@willson> <4AEB4B9E.4010606@redhat.com> <1256934726.2813.40.camel@willson> Message-ID: <4AEB4E33.3080407@redhat.com> Simo Sorce wrote: > On Fri, 2009-10-30 at 16:25 -0400, Dmitri Pal wrote: > >> Simo Sorce wrote: >> >>> On Fri, 2009-10-30 at 15:57 -0400, Rob Crittenden wrote: >>> >>> >>>> The message is not configurable, it just says that something is >>>> trying >>>> to modify your user preferences. >>>> >>>> >>> And rightly so, this is a security warning. If it were modifiable a >>> rogue server could change the message to ask: "do you like bacon ?" >>> To which *everyone* would have to answer Yes :-) >>> >>> Simo. >>> >>> >>> >> Modifiable by the program no, I agree. But configurable centrally on per >> server basis why not? >> > > Dmitri, this is a message the *client* shows the user, and the job of > the client is to prevent servers to play with it ... > > >> I would say that it would be nice to be able to configure FF centrally to: >> >> * Automatically accept cert from IPA. >> * Have a right configuration in the preferences for kerberos >> > > Certainly, but out of band, you can't do this from a Web Server you are > connecting to. This is a job for puppet/cfengine/etc... > > >> I think it all boils down to enhancements to FF. >> Let me see what I can do about it. >> > > Nothing, you'd be asking to break a security feature of the browser ... > > No. No. No. You got me totally wrong. Of cause out of band by puppet/cfengine/etc... It is just FF needs to store these properties somewhere these engines actually can reach. An d this is what we need to make sure that FF guys address. > Simo. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Oct 30 20:37:55 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 16:37:55 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4E33.3080407@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <4AEB35E6.3090401@redhat.com> <4AEB434A.2080001@redhat.com> <4AEB4531.3060802@redhat.com> <1256932999.2813.33.camel@willson> <4AEB4B9E.4010606@redhat.com> <1256934726.2813.40.camel@willson> <4AEB4E33.3080407@redhat.com> Message-ID: <1256935075.2813.44.camel@willson> On Fri, 2009-10-30 at 16:36 -0400, Dmitri Pal wrote: > No. No. No. > You got me totally wrong. > Of cause out of band by puppet/cfengine/etc... > It is just FF needs to store these properties somewhere these engines > actually can reach. > An d this is what we need to make sure that FF guys address. Ok this is a different thing I can agree with. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 30 20:40:35 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 30 Oct 2009 16:40:35 -0400 Subject: [Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page. In-Reply-To: <4AEB4CC5.3080007@redhat.com> References: <4AE9CEC3.5060905@redhat.com> <4AEAFE27.8000305@redhat.com> <4AEB074B.6030809@redhat.com> <4AEB2CBA.8040207@redhat.com> <4AEB3056.1050401@redhat.com> <1256929927.2813.16.camel@willson> <4AEB41DC.5050701@redhat.com> <4AEB4410.5020505@redhat.com> <1256932485.2813.27.camel@willson> <4AEB44D8.2000902@redhat.com> <1256932820.2813.31.camel@willson> <4AEB4AC6.9030504@redhat.com> <4AEB4CC5.3080007@redhat.com> Message-ID: <4AEB4F43.8030702@redhat.com> Rob Crittenden wrote: > Dmitri Pal wrote: >> Simo Sorce wrote: >>> On Fri, 2009-10-30 at 15:56 -0400, Dmitri Pal wrote: >>> >>>> But then you have to update it on all replicas and will definitely >>>> forget to do it. >>>> Is it really a hassle to have it in the DS? >>>> >>> Yes it means you have to build a UI to manage that attribute, create >>> it, >>> find a place where to store it in the tree etc.. and adds cruft to the >>> tree. >>> >>> >> There are a lot of other things that we put in the cn=config replicate >> but do not provide UI. >> Admin will just run ldapmodify command for this attribute and this is >> it. > > I agree with Simo. I think it would require more development time than > user's would benefit. > > We can always include this static file when we create replicas (just > won't help those replica's already created). It is simple enough to > copy a file around. > > Plus in order to store it in an LDAP attribute it means that whatever > page displays the message needs to be a separate server-side program > that reads and displays the data. Not difficult, again just seems like > overkill. > I agree that file is easier. But I though that on the grand scale of things we want to reduce the amount of things that are configured in the files and not natively replicated by DS. We talked about moving part of the kdc configuration into the DS for example so I was thinking that if we plan to do it eventually why create other pieces scattered around that we would have to put into DS later. Why not do it right away. A bit of upfront work now, not huge though, but paves a road for better config param centralization and elimination of the scattered config files. But if you say it is not worth it and too much a can understand. >> >>> A file is a simple drop in and admins can easily change it at any time. >>> >>> True, if they forget to replicate it on other servers it will get >>> out of >>> sync, but it is also easy to fix that if it happens. We can put a >>> comment in the template that reminds admins to always replicate it to >>> all servers. >>> >> Why it should be limited to a server. This IMO will be an artificaial >> limitation. >> Any server can perform migration and replicate the created kerberos keys >> so why limit? > > I agree with you here. No reason any IPA server can't assist with the > migration. > >> >>> However do you think admins will set it up on all servers ? >> Yes. I do not see "set". Functionality is just there available from any >> server. >> They do not need to do anything to set it up. > > I agree. > > rob > >> >>> I was >>> thinking they would set up the migration stuff only on one server and >>> give out only one server URL, so I don't think we should care about >>> replicating it to other servers normally. >>> >>> Simo. >>> >>> >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/