From pzuna at redhat.com Tue Jan 5 13:10:23 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 05 Jan 2010 14:10:23 +0100 Subject: [Freeipa-devel] [PATCH] Allow creation of new connections by unshared instances of backend.Connectible. Message-ID: <4B433A3F.3080101@redhat.com> The backend.Connectible base class was designed, so that only one instance of each subclass is used at a time. Connectible generates a Connection object for each thread and stores it in thread-local storage (context). Subclasses access this object through the Connectible.conn property. This is a good thing, because one instance of the class can be shared by all threads and each thread has its own connection. Unfortunately, this is also a limitation. If a thread needs a second connection (to a different host for example) - it can't do it. Not even by creating a new instance of the Connectible subclass. Ok, let's move from theory to practice: The LDAP backend is currently only used by the Executioner backend, so that plugins can connect to the IPA DS. In the migration plugin, we need a second connection to the DS we're migrating from. The last version had to use low level python-ldap calls to achieve this. In the installer we're still using legacy code from v1. Using ldap2 would be simpler and we could drop ~1000 lines code. (I already started rewriting a few parts to see if it would work.) Proposed solution: Make it possible to create unshared instances of Connectible subclasses. This would be achieved by passing shared_instance=False (couldn't come up with a better name) to the object constructor explicitly. Normally, Connection objects are stored in thread-local storage under the subclass name (e.g. "ldap2"). Unshared instances would store their Connection objects under subclass name + unique instances ID (e.g. "ldap2_218adsfka7"). This is the only solution I could come up with, that doesn't involve breaking a lot of stuff - it just adds a new way of using the code we already have. The attached patches show how it would be done. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-creation-of-new-connections-by-unshared-instan.patch Type: application/mbox Size: 3924 bytes Desc: not available URL: From pzuna at redhat.com Tue Jan 5 14:01:41 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 05 Jan 2010 15:01:41 +0100 Subject: [Freeipa-devel] [PATCH] Improve modlist generation in ldap2. Some code cleanup as bonus. Message-ID: <4B434645.4060301@redhat.com> ldap2._generate_modlist now uses more sophisticated means to decide when to use MOD_ADD+MOD_DELETE instead of MOD_REPLACE. Before it did MOD_REPLACE only on attributes explicitly specified in ldap2._FORCE_REPLACE_ON_UPDATE_ATTRS. Now it does MOD_REPLACE for all single value attributes and never for multi value. This patch also silently fixes a bug: ldap2 didn't check for the existence of attributes that were being deleted by setting them to None. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-modlist-generation-in-ldap2.-Some-code-clean.patch Type: application/mbox Size: 11523 bytes Desc: not available URL: From pzuna at redhat.com Tue Jan 5 14:19:12 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 05 Jan 2010 15:19:12 +0100 Subject: [Freeipa-devel] [PATCH] Add Kerberos Ticket Policy management plugin. Message-ID: <4B434A60.1090708@redhat.com> Alright, here's my first shot at the Kerberos Ticket Policy management plugin. It is also a "new type" of plugin. What I mean by that is that it takes an optional primary key (username) as its first argument. If used, policy for a specific user is being managed. If not, the global policy is being managed. If there's no value defined for a specific user, the global value is displayed instead. This pattern could also be applied to the pwpolicy plugin. The pwpolicy plugin currently doesn't even use the baseldap classes and is a bit buggy*. So, if nobody minds, I'd like to rewrite it to use this pattern. It should only take a few hours. * minor bugs in pwpolicy plugin: - it says that higher number in cosPriority means higher priority, this isn't true - it is impossible to modify cosPriority using pwpolicy-mod, it throws an exception, because it tries to set it in the wrong entry Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-Kerberos-Ticket-Policy-management-plugin.patch Type: application/mbox Size: 10195 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 5 15:00:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Jan 2010 10:00:54 -0500 Subject: [Freeipa-devel] [PATCH] Improve modlist generation in ldap2. Some code cleanup as bonus. In-Reply-To: <4B434645.4060301@redhat.com> References: <4B434645.4060301@redhat.com> Message-ID: <4B435426.3030608@redhat.com> Pavel Zuna wrote: > ldap2._generate_modlist now uses more sophisticated means to decide when > to use MOD_ADD+MOD_DELETE instead of MOD_REPLACE. Before it did > MOD_REPLACE only on attributes explicitly specified in > ldap2._FORCE_REPLACE_ON_UPDATE_ATTRS. Now it does MOD_REPLACE for all > single value attributes and never for multi value. > > This patch also silently fixes a bug: ldap2 didn't check for the > existence of attributes that were being deleted by setting them to None. > > Pavel I still need to try this patch out but I came up with a few questions. Is schema something that needs to be passed in? This needs to be a python-ldap Schema object, right? Should that be enforced? Will this blow up if the call to self.schema.get_obj(_ldap.schema.AttributeType, k) fails? As an aside, not related to this patch, I noticed that debug_level defaults to 255 which seems wrong. It isn't a problem because this argument isn't used at all. rob From pzuna at redhat.com Tue Jan 5 15:15:20 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 05 Jan 2010 16:15:20 +0100 Subject: [Freeipa-devel] [PATCH] Improve modlist generation in ldap2. Some code cleanup as bonus. In-Reply-To: <4B435426.3030608@redhat.com> References: <4B434645.4060301@redhat.com> <4B435426.3030608@redhat.com> Message-ID: <4B435788.9040403@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> ldap2._generate_modlist now uses more sophisticated means to decide >> when to use MOD_ADD+MOD_DELETE instead of MOD_REPLACE. Before it did >> MOD_REPLACE only on attributes explicitly specified in >> ldap2._FORCE_REPLACE_ON_UPDATE_ATTRS. Now it does MOD_REPLACE for all >> single value attributes and never for multi value. >> >> This patch also silently fixes a bug: ldap2 didn't check for the >> existence of attributes that were being deleted by setting them to None. >> >> Pavel > > I still need to try this patch out but I came up with a few questions. > > Is schema something that needs to be passed in? This needs to be a > python-ldap Schema object, right? Should that be enforced? A schema will only be passed in, if someone wants to connect to an LDAP server that uses a different schema than the IPA DS. We might of course enforce it to be a subclass of the Schema class, but I don't like enforcing stuff, so I'm not used to do it. :) > Will this blow up if the call to > self.schema.get_obj(_ldap.schema.AttributeType, k) fails? No, it will just assume the attribute is multi value. If the schema object is valid, it shouldn't fail unless we try to get an attribute that isn't in the schema. > As an aside, not related to this patch, I noticed that debug_level > defaults to 255 which seems wrong. It isn't a problem because this > argument isn't used at all. That's probably a leftover from long ago. I'll remove it (or use it with a more appropriate value) in the next patch on ldap2. > rob Pavel From rcritten at redhat.com Wed Jan 6 22:22:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Jan 2010 17:22:54 -0500 Subject: [Freeipa-devel] [PATCH] 343 Fix CA installer Message-ID: <4B450D3E.7020607@redhat.com> In the Fedora package reviews the service name was changed from having a separate service for each CA instance to a single pki-cad service. Change the service name and use the instance name more appropriately. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-343-ca.patch Type: application/mbox Size: 1835 bytes Desc: not available URL: From jdennis at redhat.com Wed Jan 6 22:36:40 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 06 Jan 2010 17:36:40 -0500 Subject: [Freeipa-devel] [PATCH] 343 Fix CA installer In-Reply-To: <4B450D3E.7020607@redhat.com> References: <4B450D3E.7020607@redhat.com> Message-ID: <4B451078.6030009@redhat.com> On 01/06/2010 05:22 PM, Rob Crittenden wrote: > In the Fedora package reviews the service name was changed from having a > separate service for each CA instance to a single pki-cad service. > Change the service name and use the instance name more appropriately. ACK -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From t.a.philippova at gmail.com Thu Jan 7 10:44:55 2010 From: t.a.philippova at gmail.com (tatiana philippova) Date: Thu, 7 Jan 2010 23:44:55 +1300 Subject: [Freeipa-devel] ipa-server-install Unable to set admin password Message-ID: Hi , I have an issue with freeipa v 1.9.0.pre1 on Fedora12 (virtual) ..actually - not just one issue, a couple of them. freeipa rpms were built from tarball (downloaded from official site) ipa-server-1.9.0.pre1-0.fc12.x86_64 ipa-client-1.9.0.pre1-0.fc12.x86_64 ipa-server-selinux-1.9.0.pre1-0.fc12.x86_64 ipa-python-1.9.0.pre1-0.fc12.x86_64 ipa-admintools-1.9.0.pre1-0.fc12.x86_64 the first issue appears during server setup: #ipa-server-install -N .. Applying LDAP updates restarting the directory server restarting the KDC Sample zone file for bind has been created in /tmp/sample.zone.xe_hlt.db Unable to set admin password Command '/usr/lib64/mozldap/ldappasswd -D cn=Directory Manager -w pass1 -P /etc/dirsrv/slapd-INTERNAL-MYNET-COM//cert8.db -ZZZ -s pass2 uid=admin,cn=users,cn=accounts,dc=internal,dc=mynet,dc=com' returned non-zero exit status 1 .. when I start ldappasswd manually with the same parametres - ldap_simple_bind: No such object output from ldapsearch: ldapsearch -x -D "cn=Directory Manager" -w pass1 -b cn=users,cn=accounts,dc=internal,dc=mynet,dc=com krbprincipalname=admin krbPrincipalKey # extended LDIF # # LDAPv3 # base with scope subtree # filter: krbprincipalname=admin # requesting: krbPrincipalKey # # search result search: 2 result: 0 Success # numResponses: 1 the second issue: The password for this file is in /etc/dirsrv/slapd-INTERNAL-MYNET-COM/pwdfile.txt but in log file 2010-01-07 21:36:44,054 INFO pk12util: PKCS12 EXPORT SUCCESSFUL 2010-01-07 21:36:44,103 INFO certutil: Could not find: CA certificate : security library: bad database. and my password file pwdfile.txt is empty Could somebody kindly help my with these problems? Many thanks in advance Tatiana From rcritten at redhat.com Thu Jan 7 14:58:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Jan 2010 09:58:54 -0500 Subject: [Freeipa-devel] [PATCH] 343 Fix CA installer In-Reply-To: <4B451078.6030009@redhat.com> References: <4B450D3E.7020607@redhat.com> <4B451078.6030009@redhat.com> Message-ID: <4B45F6AE.7090907@redhat.com> John Dennis wrote: > On 01/06/2010 05:22 PM, Rob Crittenden wrote: >> In the Fedora package reviews the service name was changed from having a >> separate service for each CA instance to a single pki-cad service. >> Change the service name and use the instance name more appropriately. > > ACK > pushed to master From rcritten at redhat.com Thu Jan 7 15:10:09 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Jan 2010 10:10:09 -0500 Subject: [Freeipa-devel] ipa-server-install Unable to set admin password In-Reply-To: References: Message-ID: <4B45F951.6000409@redhat.com> tatiana philippova wrote: > Hi , I have an issue with freeipa v 1.9.0.pre1 on Fedora12 (virtual) > ..actually - not just one issue, a couple of them. > > freeipa rpms were built from tarball (downloaded from official site) > ipa-server-1.9.0.pre1-0.fc12.x86_64 > ipa-client-1.9.0.pre1-0.fc12.x86_64 > ipa-server-selinux-1.9.0.pre1-0.fc12.x86_64 > ipa-python-1.9.0.pre1-0.fc12.x86_64 > ipa-admintools-1.9.0.pre1-0.fc12.x86_64 > > > the first issue appears during server setup: > #ipa-server-install -N > .. > Applying LDAP updates > restarting the directory server > restarting the KDC > Sample zone file for bind has been created in /tmp/sample.zone.xe_hlt.db > Unable to set admin password Command '/usr/lib64/mozldap/ldappasswd -D > cn=Directory Manager -w pass1 -P > /etc/dirsrv/slapd-INTERNAL-MYNET-COM//cert8.db -ZZZ -s pass2 > uid=admin,cn=users,cn=accounts,dc=internal,dc=mynet,dc=com' returned > non-zero exit status 1 > .. > > when I start ldappasswd manually with the same parametres - > ldap_simple_bind: No such object Can you provide a log snippet from the 389ds access log (/var/log/slapd-INTERNAL-MYNET-COM/access) showing these? > > output from ldapsearch: > > ldapsearch -x -D "cn=Directory Manager" -w pass1 -b > cn=users,cn=accounts,dc=internal,dc=mynet,dc=com > krbprincipalname=admin krbPrincipalKey > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: krbprincipalname=admin > # requesting: krbPrincipalKey > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 The krbprinicpalname would be admin at INTERNAL.MYNET.COM > > the second issue: > The password for this file is in > /etc/dirsrv/slapd-INTERNAL-MYNET-COM/pwdfile.txt > > but in log file > 2010-01-07 21:36:44,054 INFO pk12util: PKCS12 EXPORT SUCCESSFUL > 2010-01-07 21:36:44,103 INFO certutil: Could not find: CA certificate > : security library: bad database. Can you see what certificates exist in the database? certutil -L -d /etc/dirsrv/slapd-INTERNAL-MYNET-COM/ > > and my password file pwdfile.txt is empty We weren't setting a password on the 389-ds NSS database, this has been changed since the alpha release. rob > > > Could somebody kindly help my with these problems? > > > > Many thanks in advance > Tatiana > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From nalin at redhat.com Thu Jan 7 17:56:39 2010 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 7 Jan 2010 12:56:39 -0500 Subject: [Freeipa-devel] [PATCH] use %global instead of %define in .spec file Message-ID: <20100107175639.GA5489@redhat.com> The git repo doesn't build against Fedora Raw Hide at the moment, due to https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html Replacing uses of %define with %global in the .spec file seems to be enough to get things going again. The resulting source package still builds correctly on F10. Nalin -------------- next part -------------- diff --git a/ipa.spec.in b/ipa.spec.in index 84884a5..6b5e655 100644 --- a/ipa.spec.in +++ b/ipa.spec.in @@ -1,14 +1,14 @@ # Define ONLY_CLIENT to only make the ipa-client and ipa-python subpackages -%{!?ONLY_CLIENT:%define ONLY_CLIENT 0} +%{!?ONLY_CLIENT:%global ONLY_CLIENT 0} # Define WITH_RADIUS to build the radius packages -%define WITH_RADIUS 0 +%global WITH_RADIUS 0 -%define httpd_conf /etc/httpd/conf.d -%define plugin_dir %{_libdir}/dirsrv/plugins -%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} -%{!?python_sitearch: %define python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} -%define POLICYCOREUTILSVER 1.33.12-1 +%global httpd_conf /etc/httpd/conf.d +%global plugin_dir %{_libdir}/dirsrv/plugins +%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} +%{!?python_sitearch: %global python_sitearch %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib(1)")} +%global POLICYCOREUTILSVER 1.33.12-1 Name: ipa Version: __VERSION__ From rcritten at redhat.com Thu Jan 7 19:14:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Jan 2010 14:14:21 -0500 Subject: [Freeipa-devel] [PATCH] use %global instead of %define in .spec file In-Reply-To: <20100107175639.GA5489@redhat.com> References: <20100107175639.GA5489@redhat.com> Message-ID: <4B46328D.8080109@redhat.com> Nalin Dahyabhai wrote: > The git repo doesn't build against Fedora Raw Hide at the moment, due to > https://www.redhat.com/archives/fedora-devel-list/2010-January/msg00093.html > > Replacing uses of %define with %global in the .spec file seems to be > enough to get things going again. The resulting source package still > builds correctly on F10. > > Nalin ack, pushed to master From rcritten at redhat.com Fri Jan 8 13:43:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Jan 2010 08:43:42 -0500 Subject: [Freeipa-devel] ipa-server-install Unable to set admin password In-Reply-To: References: <4B45F951.6000409@redhat.com> Message-ID: <4B47368E.4060401@redhat.com> tatiana philippova wrote: > Hi Rob, > many thanks for reply, here is information requested > > On Fri, Jan 8, 2010 at 4:10 AM, Rob Crittenden wrote: >> tatiana philippova wrote: >>> Hi , I have an issue with freeipa v 1.9.0.pre1 on Fedora12 (virtual) >>> ..actually - not just one issue, a couple of them. >>> >>> freeipa rpms were built from tarball (downloaded from official site) >>> ipa-server-1.9.0.pre1-0.fc12.x86_64 >>> ipa-client-1.9.0.pre1-0.fc12.x86_64 >>> ipa-server-selinux-1.9.0.pre1-0.fc12.x86_64 >>> ipa-python-1.9.0.pre1-0.fc12.x86_64 >>> ipa-admintools-1.9.0.pre1-0.fc12.x86_64 >>> >>> >>> the first issue appears during server setup: >>> #ipa-server-install -N >>> .. >>> Applying LDAP updates >>> restarting the directory server >>> restarting the KDC >>> Sample zone file for bind has been created in /tmp/sample.zone.xe_hlt.db >>> Unable to set admin password Command '/usr/lib64/mozldap/ldappasswd -D >>> cn=Directory Manager -w pass1 -P >>> /etc/dirsrv/slapd-INTERNAL-MYNET-COM//cert8.db -ZZZ -s pass2 >>> uid=admin,cn=users,cn=accounts,dc=internal,dc=mynet,dc=com' returned >>> non-zero exit status 1 > also noticed next in /var/log/dirsrv/slapd-INTERNAL-BULLETIN-NET/errors : > [08/Jan/2010:10:02:38 +1300] ipa_pwd_extop - krb5_c_string_to_key > failed [Bad encryption type] > [08/Jan/2010:10:02:38 +1300] ipa_pwd_extop - key encryption/encoding failed Well, that explains why the admin password wasn't set. Simo, any thoughts? ipa_pwd_extop is the 389-ds plugin we use to keep the LDAP password and the kerberos principal key in sync. What version of krb5-server do you have installed? rpm -q krb5-server >>> .. >>> >>> when I start ldappasswd manually with the same parametres - >>> ldap_simple_bind: No such object >> Can you provide a log snippet from the 389ds access log >> (/var/log/slapd-INTERNAL-MYNET-COM/access) showing these? > > when command manually started: > /usr/lib64/mozldap/ldappasswd -D cn=Directory Manager -w pass1 -P > /etc/dirsrv/slapd-INTERNAL-MYNET-COM//cert8.db -ZZZ -s pass2 > uid=admin,cn=users,cn=accounts,dc=internal,dc=mynet,dc=com > ldap_simple_bind: No such object > > /var/log/dirsrv/slapd-INTERNAL-MYNET-COM/access: > > [08/Jan/2010:10:24:50 +1300] conn=13 fd=69 slot=69 connection from ::1 to ::1 > [08/Jan/2010:10:24:50 +1300] conn=13 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" name="startTLS" > [08/Jan/2010:10:24:50 +1300] conn=13 op=0 RESULT err=0 tag=120 > nentries=0 etime=0 > [08/Jan/2010:10:24:50 +1300] conn=13 SSL 128-bit RC4 > [08/Jan/2010:10:24:50 +1300] conn=13 op=1 BIND dn="cn=Directory" > method=128 version=3 > [08/Jan/2010:10:24:50 +1300] conn=13 op=2 UNBIND > [08/Jan/2010:10:24:50 +1300] conn=13 op=2 fd=69 closed - U1 > [08/Jan/2010:10:24:51 +1300] conn=13 op=1 RESULT err=32 tag=97 > nentries=0 etime=1 You need to put quotes around "cn=Directory Manager". > >>> output from ldapsearch: >>> >>> ldapsearch -x -D "cn=Directory Manager" -w pass1 -b >>> cn=users,cn=accounts,dc=internal,dc=mynet,dc=com >>> krbprincipalname=admin krbPrincipalKey >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope >>> subtree >>> # filter: krbprincipalname=admin >>> # requesting: krbPrincipalKey >>> # >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 1 >> The krbprinicpalname would be admin at INTERNAL.MYNET.COM > ops, sorry. here is correct output: > > [root at freeipa log]# ldapsearch -x -D "cn=Directory Manager" -w pass1 > -b cn=users,cn=accounts,dc=internal,dc=mynet,dc=com > krbprincipalname=admin at INTERNAL.MYNET.COM krbPrincipalKey > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: krbprincipalname=admin at INTERNAL.MYNET.COM > # requesting: krbPrincipalKey. > # > # admin, users, accounts, internal.MYNET.COM > dn: uid=admin,cn=users,cn=accounts,dc=internal,dc=mynet,dc=com > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 Ok, that is about what I would expect since the password setting failed. > > > and in /var/log/dirsrv/slapd-INTERNAL-MYNET-COM/access: > > [08/Jan/2010:10:27:14 +1300] conn=15 fd=69 slot=69 connection from > 127.0.0.1 to 127.0.0.1 > [08/Jan/2010:10:27:14 +1300] conn=15 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [08/Jan/2010:10:27:14 +1300] conn=15 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [08/Jan/2010:10:27:14 +1300] conn=15 op=1 SRCH > base="cn=users,cn=accounts,dc=internal,dc=mynet,dc=com" scope=2 > filter="(krbPrincipalName=admin at INTERNAL.MYNET.COM)" > attrs="krbPrincipalKey" > [08/Jan/2010:10:27:14 +1300] conn=15 op=1 RESULT err=0 tag=101 > nentries=1 etime=0 > [08/Jan/2010:10:27:14 +1300] conn=15 op=2 UNBIND > [08/Jan/2010:10:27:14 +1300] conn=15 op=2 fd=69 closed - U1 > >>> the second issue: >>> The password for this file is in >>> /etc/dirsrv/slapd-INTERNAL-MYNET-COM/pwdfile.txt >>> >>> but in log file >>> 2010-01-07 21:36:44,054 INFO pk12util: PKCS12 EXPORT SUCCESSFUL >>> 2010-01-07 21:36:44,103 INFO certutil: Could not find: CA certificate >>> : security library: bad database. >> Can you see what certificates exist in the database? >> >> certutil -L -d /etc/dirsrv/slapd-INTERNAL-MYNET-COM/ > > [root at freeipa log]# certutil -L -d /etc/dirsrv/slapd-INTERNAL-MYNET-COM/ > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > Server-Cert u,u,u > CA certificate CT,,C Hmm. How about: certutil -L -d /etc/httpd/alias/ thanks rob > > >>> and my password file pwdfile.txt is empty >> We weren't setting a password on the 389-ds NSS database, this has been >> changed since the alpha release. > thanks for this tip >> rob >> >>> >>> Could somebody kindly help my with these problems? >>> >>> >>> >>> Many thanks in advance >>> Tatiana >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > Kindest regards > Tatiana From rcritten at redhat.com Fri Jan 8 16:03:55 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Jan 2010 11:03:55 -0500 Subject: [Freeipa-devel] [PATCH] Add Kerberos Ticket Policy management plugin. In-Reply-To: <4B434A60.1090708@redhat.com> References: <4B434A60.1090708@redhat.com> Message-ID: <4B47576B.4010004@redhat.com> Pavel Zuna wrote: > Alright, here's my first shot at the Kerberos Ticket Policy management > plugin. > > It is also a "new type" of plugin. What I mean by that is that it takes > an optional primary key (username) as its first argument. If used, > policy for a specific user is being managed. If not, the global policy > is being managed. If there's no value defined for a specific user, the > global value is displayed instead. This pattern could also be applied to > the pwpolicy plugin. > > The pwpolicy plugin currently doesn't even use the baseldap classes and > is a bit buggy*. So, if nobody minds, I'd like to rewrite it to use this > pattern. It should only take a few hours. > > * minor bugs in pwpolicy plugin: > - it says that higher number in cosPriority means higher priority, this > isn't true > - it is impossible to modify cosPriority using pwpolicy-mod, it throws > an exception, because it tries to set it in the wrong entry > > Pavel I'm having a problem getting this to apply to the tip. Does this depend on some other patches? patching file ipalib/plugins/baseldap.py Hunk #5 succeeded at 346 (offset 152 lines). Hunk #6 FAILED at 363. Hunk #7 FAILED at 422. Hunk #8 FAILED at 506. Hunk #9 succeeded at 208 (offset -163 lines). Hunk #10 succeeded at 566 (offset 152 lines). Hunk #11 succeeded at 267 (offset -163 lines). Hunk #12 succeeded at 873 (offset 150 lines). 3 out of 12 hunks FAILED -- saving rejects to file ipalib/plugins/baseldap.py.rej patching file ipalib/plugins/krbtpolicy.py rob From dpal at redhat.com Fri Jan 8 17:06:27 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Jan 2010 12:06:27 -0500 Subject: [Freeipa-devel] ipa-server-install Unable to set admin password In-Reply-To: <4B47368E.4060401@redhat.com> References: <4B45F951.6000409@redhat.com> <4B47368E.4060401@redhat.com> Message-ID: <4B476613.4070002@redhat.com> Rob Crittenden wrote: > tatiana philippova wrote: >> also noticed next in >> /var/log/dirsrv/slapd-INTERNAL-BULLETIN-NET/errors : >> [08/Jan/2010:10:02:38 +1300] ipa_pwd_extop - krb5_c_string_to_key >> failed [Bad encryption type] >> [08/Jan/2010:10:02:38 +1300] ipa_pwd_extop - key encryption/encoding >> failed > > Well, that explains why the admin password wasn't set. Simo, any > thoughts? > > ipa_pwd_extop is the 389-ds plugin we use to keep the LDAP password > and the kerberos principal key in sync. > > What version of krb5-server do you have installed? rpm -q krb5-server If it is F12 the Kerberos version should be 1.7. Can it be that we have an incompatibility with 1.7 in our plugin? From jderose at redhat.com Fri Jan 8 20:51:06 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 08 Jan 2010 13:51:06 -0700 Subject: [Freeipa-devel] [PATCH] 342 control the certificate subject in dogtag In-Reply-To: <4B2BA842.5040305@redhat.com> References: <4B2BA842.5040305@redhat.com> Message-ID: <1262983866.7899.2.camel@jgd-dsk> On Fri, 2009-12-18 at 11:05 -0500, Rob Crittenden wrote: > Use the caIPAserviceCert profile for issuing service certs. > > This profile enables subject validation and ensures that the subject > that the CA issues is uniform. The client can only request a specific > CN, the rest of the subject is fixed. > > This is the first step of allowing the subject to be set at installation > time. > > Also fix 2 more issues related to the return results migration. > > Note that with the selfsign plugin it will still issue the subject that > was in the CSR. > > rob ack. pushed to master. From rcritten at redhat.com Fri Jan 8 21:04:07 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Jan 2010 16:04:07 -0500 Subject: [Freeipa-devel] [PATCH] 344 require fully-qualified hostname in ipa-join Message-ID: <4B479DC7.9060405@redhat.com> Require a fully-qualified hostname in ipa-join. The server side will enforce this as well but better to catch it early. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-344-join.patch Type: application/mbox Size: 922 bytes Desc: not available URL: From rcritten at redhat.com Fri Jan 8 21:05:27 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Jan 2010 16:05:27 -0500 Subject: [Freeipa-devel] [PATCH] 345 fix pwpolicy plugin Message-ID: <4B479E17.5090404@redhat.com> Allow the priority to be updated and fix the description of priority ordering. Lower wins, not higher. I also had to add the option to not normalize to a few more functions in ldap2. I have to craft a very specifically-formatted DN for it to be understood by the krb5 server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-345-pwpolicy.patch Type: application/mbox Size: 7613 bytes Desc: not available URL: From jderose at redhat.com Sat Jan 9 01:38:19 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 08 Jan 2010 18:38:19 -0700 Subject: [Freeipa-devel] [PATCH] Allow creation of new connections by unshared instances of backend.Connectible. In-Reply-To: <4B433A3F.3080101@redhat.com> References: <4B433A3F.3080101@redhat.com> Message-ID: <1263001100.7014.4.camel@jgd-dsk> On Tue, 2010-01-05 at 14:10 +0100, Pavel Zuna wrote: > The backend.Connectible base class was designed, so that only one instance of > each subclass is used at a time. Connectible generates a Connection object for > each thread and stores it in thread-local storage (context). Subclasses access > this object through the Connectible.conn property. > > This is a good thing, because one instance of the class can be shared by all > threads and each thread has its own connection. Unfortunately, this is also a > limitation. If a thread needs a second connection (to a different host for > example) - it can't do it. Not even by creating a new instance of the > Connectible subclass. > > Ok, let's move from theory to practice: > > The LDAP backend is currently only used by the Executioner backend, so that > plugins can connect to the IPA DS. > > In the migration plugin, we need a second connection to the DS we're migrating > from. The last version had to use low level python-ldap calls to achieve this. > > In the installer we're still using legacy code from v1. Using ldap2 would be > simpler and we could drop ~1000 lines code. (I already started rewriting a few > parts to see if it would work.) > > Proposed solution: > > Make it possible to create unshared instances of Connectible subclasses. > > This would be achieved by passing shared_instance=False (couldn't come up with a > better name) to the object constructor explicitly. Normally, Connection objects > are stored in thread-local storage under the subclass name (e.g. "ldap2"). > Unshared instances would store their Connection objects under subclass name + > unique instances ID (e.g. "ldap2_218adsfka7"). > > This is the only solution I could come up with, that doesn't involve breaking a > lot of stuff - it just adds a new way of using the code we already have. > > The attached patches show how it would be done. > > Pavel I'm fine with this approach as the solution you propose is quite unobtrusive. Is this the final patch then, or will you make further changes or bundle it with another patch? From pzuna at redhat.com Mon Jan 11 14:23:28 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 11 Jan 2010 15:23:28 +0100 Subject: [Freeipa-devel] [PATCH] Add --all to LDAPCreate and make LDAP commands always display default attributes. Message-ID: <4B4B3460.1060009@redhat.com> This is actually an old patch that got lost in the depths of freeipa-devel. There was just one issue with it, that it always assumed that the --all parameter is present (because it is required in the baseclass). I fixed it and now use the fail-safe: options.get('all', False) The Kerberos Ticket Policy management plugin depends on it. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-all-to-LDAPCreate-and-make-LDAP-commands-alway.patch Type: application/mbox Size: 7220 bytes Desc: not available URL: From pzuna at redhat.com Mon Jan 11 14:24:52 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 11 Jan 2010 15:24:52 +0100 Subject: [Freeipa-devel] [PATCH] Add Kerberos Ticket Policy management plugin. In-Reply-To: <4B47576B.4010004@redhat.com> References: <4B434A60.1090708@redhat.com> <4B47576B.4010004@redhat.com> Message-ID: <4B4B34B4.7020406@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Alright, here's my first shot at the Kerberos Ticket Policy management >> plugin. >> >> It is also a "new type" of plugin. What I mean by that is that it >> takes an optional primary key (username) as its first argument. If >> used, policy for a specific user is being managed. If not, the global >> policy is being managed. If there's no value defined for a specific >> user, the global value is displayed instead. This pattern could also >> be applied to the pwpolicy plugin. >> >> The pwpolicy plugin currently doesn't even use the baseldap classes >> and is a bit buggy*. So, if nobody minds, I'd like to rewrite it to >> use this pattern. It should only take a few hours. >> >> * minor bugs in pwpolicy plugin: >> - it says that higher number in cosPriority means higher priority, >> this isn't true >> - it is impossible to modify cosPriority using pwpolicy-mod, it throws >> an exception, because it tries to set it in the wrong entry >> >> Pavel > > I'm having a problem getting this to apply to the tip. Does this depend > on some other patches? > > patching file ipalib/plugins/baseldap.py > Hunk #5 succeeded at 346 (offset 152 lines). > Hunk #6 FAILED at 363. > Hunk #7 FAILED at 422. > Hunk #8 FAILED at 506. > Hunk #9 succeeded at 208 (offset -163 lines). > Hunk #10 succeeded at 566 (offset 152 lines). > Hunk #11 succeeded at 267 (offset -163 lines). > Hunk #12 succeeded at 873 (offset 150 lines). > 3 out of 12 hunks FAILED -- saving rejects to file > ipalib/plugins/baseldap.py.rej > patching file ipalib/plugins/krbtpolicy.py > > rob There was a forgotten patch adding --all to LDAPCreate, I reposted it on freeipa devel just now. I also generated a new version of the Kerberos Ticket Policy plugin patch (attached), just in case. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-Kerberos-Ticket-Policy-management-plugin.patch Type: application/mbox Size: 10153 bytes Desc: not available URL: From pzuna at redhat.com Mon Jan 11 15:27:30 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 11 Jan 2010 16:27:30 +0100 Subject: [Freeipa-devel] [PATCH] Allow creation of new connections by unshared instances of backend.Connectible. In-Reply-To: <1263001100.7014.4.camel@jgd-dsk> References: <4B433A3F.3080101@redhat.com> <1263001100.7014.4.camel@jgd-dsk> Message-ID: <4B4B4362.8010800@redhat.com> Jason Gerard DeRose wrote: > On Tue, 2010-01-05 at 14:10 +0100, Pavel Zuna wrote: >> The backend.Connectible base class was designed, so that only one instance of >> each subclass is used at a time. Connectible generates a Connection object for >> each thread and stores it in thread-local storage (context). Subclasses access >> this object through the Connectible.conn property. >> >> This is a good thing, because one instance of the class can be shared by all >> threads and each thread has its own connection. Unfortunately, this is also a >> limitation. If a thread needs a second connection (to a different host for >> example) - it can't do it. Not even by creating a new instance of the >> Connectible subclass. >> >> Ok, let's move from theory to practice: >> >> The LDAP backend is currently only used by the Executioner backend, so that >> plugins can connect to the IPA DS. >> >> In the migration plugin, we need a second connection to the DS we're migrating >> from. The last version had to use low level python-ldap calls to achieve this. >> >> In the installer we're still using legacy code from v1. Using ldap2 would be >> simpler and we could drop ~1000 lines code. (I already started rewriting a few >> parts to see if it would work.) >> >> Proposed solution: >> >> Make it possible to create unshared instances of Connectible subclasses. >> >> This would be achieved by passing shared_instance=False (couldn't come up with a >> better name) to the object constructor explicitly. Normally, Connection objects >> are stored in thread-local storage under the subclass name (e.g. "ldap2"). >> Unshared instances would store their Connection objects under subclass name + >> unique instances ID (e.g. "ldap2_218adsfka7"). >> >> This is the only solution I could come up with, that doesn't involve breaking a >> lot of stuff - it just adds a new way of using the code we already have. >> >> The attached patches show how it would be done. >> >> Pavel > > I'm fine with this approach as the solution you propose is quite > unobtrusive. Is this the final patch then, or will you make further > changes or bundle it with another patch? > Yeah, this is the final patch. Upcoming patches will depend on it. Pavel From rcritten at redhat.com Mon Jan 11 15:29:48 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 10:29:48 -0500 Subject: [Freeipa-devel] [PATCH] 346 add pki-cad support to ipactl Message-ID: <4B4B43EC.10401@redhat.com> Add support for starting/stopping the CA to ipactl rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-346-ipactl.patch Type: application/mbox Size: 921 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 11 15:31:10 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 10:31:10 -0500 Subject: [Freeipa-devel] ipa-server-install Unable to set admin password In-Reply-To: <4B476613.4070002@redhat.com> References: <4B45F951.6000409@redhat.com> <4B47368E.4060401@redhat.com> <4B476613.4070002@redhat.com> Message-ID: <4B4B443E.1010205@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> tatiana philippova wrote: >>> also noticed next in >>> /var/log/dirsrv/slapd-INTERNAL-BULLETIN-NET/errors : >>> [08/Jan/2010:10:02:38 +1300] ipa_pwd_extop - krb5_c_string_to_key >>> failed [Bad encryption type] >>> [08/Jan/2010:10:02:38 +1300] ipa_pwd_extop - key encryption/encoding >>> failed >> Well, that explains why the admin password wasn't set. Simo, any >> thoughts? >> >> ipa_pwd_extop is the 389-ds plugin we use to keep the LDAP password >> and the kerberos principal key in sync. >> >> What version of krb5-server do you have installed? rpm -q krb5-server > > If it is F12 the Kerberos version should be 1.7. > Can it be that we have an incompatibility with 1.7 in our plugin? Perhaps but I've been unable to reproduce this myself. It works fine in F12 for me. rob From pzuna at redhat.com Mon Jan 11 16:19:46 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 11 Jan 2010 17:19:46 +0100 Subject: [Freeipa-devel] [PATCH] 345 fix pwpolicy plugin In-Reply-To: <4B479E17.5090404@redhat.com> References: <4B479E17.5090404@redhat.com> Message-ID: <4B4B4FA2.30401@redhat.com> Rob Crittenden wrote: > Allow the priority to be updated and fix the description of priority > ordering. Lower wins, not higher. > > I also had to add the option to not normalize to a few more functions in > ldap2. I have to craft a very specifically-formatted DN for it to be > understood by the krb5 server. > > rob > The patch is fine and everything seems to work. There's just some leftover debugging calls, that should probably go away. Pavel From rcritten at redhat.com Mon Jan 11 16:46:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 11:46:38 -0500 Subject: [Freeipa-devel] [PATCH] 347 do status on right service in installer Message-ID: <4B4B55EE.9080906@redhat.com> Remove one more hardcoded reference to the pki-ca service and use self.service_name instead. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-347-ca.patch Type: application/mbox Size: 1237 bytes Desc: not available URL: From pzuna at redhat.com Mon Jan 11 18:29:38 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 11 Jan 2010 19:29:38 +0100 Subject: [Freeipa-devel] [PATCH] 347 do status on right service in installer In-Reply-To: <4B4B55EE.9080906@redhat.com> References: <4B4B55EE.9080906@redhat.com> Message-ID: <4B4B6E12.8090802@redhat.com> Rob Crittenden wrote: > Remove one more hardcoded reference to the pki-ca service and use > self.service_name instead. > > rob > ack. Pavel From rcritten at redhat.com Mon Jan 11 18:30:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 13:30:08 -0500 Subject: [Freeipa-devel] [PATCH] Add --all to LDAPCreate and make LDAP commands always display default attributes. In-Reply-To: <4B4B3460.1060009@redhat.com> References: <4B4B3460.1060009@redhat.com> Message-ID: <4B4B6E30.7050904@redhat.com> Pavel Zuna wrote: > This is actually an old patch that got lost in the depths of freeipa-devel. > > There was just one issue with it, that it always assumed that the --all > parameter is present (because it is required in the baseclass). I fixed > it and now use the fail-safe: options.get('all', False) > > The Kerberos Ticket Policy management plugin depends on it. > > Pavel ack, pushed to master From rcritten at redhat.com Mon Jan 11 18:30:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 13:30:38 -0500 Subject: [Freeipa-devel] [PATCH] 347 do status on right service in installer In-Reply-To: <4B4B6E12.8090802@redhat.com> References: <4B4B55EE.9080906@redhat.com> <4B4B6E12.8090802@redhat.com> Message-ID: <4B4B6E4E.5050006@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Remove one more hardcoded reference to the pki-ca service and use >> self.service_name instead. >> >> rob >> > ack. > > Pavel pushed to master From pzuna at redhat.com Mon Jan 11 18:34:34 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 11 Jan 2010 19:34:34 +0100 Subject: [Freeipa-devel] [PATCH] 346 add pki-cad support to ipactl In-Reply-To: <4B4B43EC.10401@redhat.com> References: <4B4B43EC.10401@redhat.com> Message-ID: <4B4B6F3A.80907@redhat.com> Rob Crittenden wrote: > Add support for starting/stopping the CA to ipactl > > rob > ack. Pavel From rcritten at redhat.com Mon Jan 11 18:38:57 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 13:38:57 -0500 Subject: [Freeipa-devel] [PATCH] 346 add pki-cad support to ipactl In-Reply-To: <4B4B6F3A.80907@redhat.com> References: <4B4B43EC.10401@redhat.com> <4B4B6F3A.80907@redhat.com> Message-ID: <4B4B7041.1030606@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Add support for starting/stopping the CA to ipactl >> >> rob >> > ack. > > Pavel pushed to master From jderose at redhat.com Mon Jan 11 18:40:58 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 11 Jan 2010 11:40:58 -0700 Subject: [Freeipa-devel] [PATCH] jderose 033 Fix fuzzy digigits under Fedora12 Message-ID: <1263235258.20456.6.camel@jgd-dsk> I'm not sure why the difference, but the uidnumber, gidnumber, etc. are being returned as `unicode` instead of `str` under Fedora12. Returning as `unicode` is correct, but this patch allows the test to still work under Fedora11 for the time being. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-033-Fix-fuzzy_digits-under-Fedora12.patch Type: text/x-patch Size: 1430 bytes Desc: not available URL: From rcritten at redhat.com Mon Jan 11 18:51:29 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Jan 2010 13:51:29 -0500 Subject: [Freeipa-devel] [PATCH] Allow creation of new connections by unshared instances of backend.Connectible. In-Reply-To: <4B4B4362.8010800@redhat.com> References: <4B433A3F.3080101@redhat.com> <1263001100.7014.4.camel@jgd-dsk> <4B4B4362.8010800@redhat.com> Message-ID: <4B4B7331.8000507@redhat.com> Pavel Zuna wrote: > Jason Gerard DeRose wrote: >> On Tue, 2010-01-05 at 14:10 +0100, Pavel Zuna wrote: >>> The backend.Connectible base class was designed, so that only one >>> instance of each subclass is used at a time. Connectible generates a >>> Connection object for each thread and stores it in thread-local >>> storage (context). Subclasses access this object through the >>> Connectible.conn property. >>> >>> This is a good thing, because one instance of the class can be shared >>> by all threads and each thread has its own connection. Unfortunately, >>> this is also a limitation. If a thread needs a second connection (to >>> a different host for example) - it can't do it. Not even by creating >>> a new instance of the Connectible subclass. >>> >>> Ok, let's move from theory to practice: >>> >>> The LDAP backend is currently only used by the Executioner backend, >>> so that plugins can connect to the IPA DS. >>> >>> In the migration plugin, we need a second connection to the DS we're >>> migrating from. The last version had to use low level python-ldap >>> calls to achieve this. >>> >>> In the installer we're still using legacy code from v1. Using ldap2 >>> would be simpler and we could drop ~1000 lines code. (I already >>> started rewriting a few parts to see if it would work.) >>> >>> Proposed solution: >>> >>> Make it possible to create unshared instances of Connectible subclasses. >>> >>> This would be achieved by passing shared_instance=False (couldn't >>> come up with a better name) to the object constructor explicitly. >>> Normally, Connection objects are stored in thread-local storage under >>> the subclass name (e.g. "ldap2"). Unshared instances would store >>> their Connection objects under subclass name + unique instances ID >>> (e.g. "ldap2_218adsfka7"). >>> >>> This is the only solution I could come up with, that doesn't involve >>> breaking a lot of stuff - it just adds a new way of using the code we >>> already have. >>> >>> The attached patches show how it would be done. >>> >>> Pavel >> >> I'm fine with this approach as the solution you propose is quite >> unobtrusive. Is this the final patch then, or will you make further >> changes or bundle it with another patch? >> > Yeah, this is the final patch. Upcoming patches will depend on it. > > Pavel > pushed to master From jderose at redhat.com Mon Jan 11 19:38:53 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 11 Jan 2010 12:38:53 -0700 Subject: [Freeipa-devel] [PATCH] Improve modlist generation in ldap2. Some code cleanup as bonus. In-Reply-To: <4B434645.4060301@redhat.com> References: <4B434645.4060301@redhat.com> Message-ID: <1263238733.20456.40.camel@jgd-dsk> On Tue, 2010-01-05 at 15:01 +0100, Pavel Zuna wrote: > ldap2._generate_modlist now uses more sophisticated means to decide when to use > MOD_ADD+MOD_DELETE instead of MOD_REPLACE. Before it did MOD_REPLACE only on > attributes explicitly specified in ldap2._FORCE_REPLACE_ON_UPDATE_ATTRS. Now it > does MOD_REPLACE for all single value attributes and never for multi value. > > This patch also silently fixes a bug: ldap2 didn't check for the existence of > attributes that were being deleted by setting them to None. > > Pavel ack. pushed to master. This patch looks fine and doesn't appear to break anything, but we *really* need tests for ldap2. It's low in our stack and almost every plugin uses it, so problems here have a high cost for us time-wise. So, Pavel, please provide tests in subsequent patch. I think this modlist functionality should be split out into functions that can be tested easily without requiring an LDAP connection. From pzuna at redhat.com Tue Jan 12 15:56:46 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 12 Jan 2010 16:56:46 +0100 Subject: [Freeipa-devel] [PATCH] Add default values for krb ticket policy attributes during installation. Message-ID: <4B4C9BBE.2070302@redhat.com> Adds some required attributes and values for kerberos ticket policy. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-default-values-for-krb-ticket-policy-attributes.patch Type: application/mbox Size: 1696 bytes Desc: not available URL: From pzuna at redhat.com Tue Jan 12 15:57:39 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 12 Jan 2010 16:57:39 +0100 Subject: [Freeipa-devel] [PATCH] Make host objects aware of their membership and that l==localityname. Message-ID: <4B4C9BF3.9070000@redhat.com> Re-post of a long forgotten patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-host-objects-aware-of-their-membership-and-that.patch Type: application/mbox Size: 1280 bytes Desc: not available URL: From pzuna at redhat.com Tue Jan 12 18:38:50 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 12 Jan 2010 19:38:50 +0100 Subject: [Freeipa-devel] [PATCHES] IPA to DS migration. Message-ID: <4B4CC1BA.6080403@redhat.com> Ok, here's the latest version of IPA to DS migration "suite". It includes the following: - A fix for a name collision in textui, Jason's big patch added a second method named print_entry. Nobody noticed there was one already. - Patch to the ipa-pwd-extop plugin to allow adding entries with pre-hashed password if migration mode is enabled. - BIND pre-operation plugin to generate Kerberos keys on simple BIND's if missing. - Migration plugin. - Option in config plugin to enable/disable migration mode. - Password migration page. what has changed since the last version: - LDAP backend is used to connect to DS, no more low level python-ldap calls. - The plugin checks if migration is enabled and gives direction on how to enable it. - The plugin can now be extended to support other objects than just users and groups. You just need to create an LDAPObject and add it's name along with a search filter (to find the objects in DS) and optionaly callbacks to handle special cases. There's some inline documentation. - LDAP URI validation. - Better error messages. - Fixed typos. The migration won't be easy to test, so tomorrow I'll setup 2 VMs on the blades. One with IPA + migration "suite" and one with DS along with some scripts to generate objects that I used for testing. Using the migration plugin is really easy, you just point it to the DS server and enter the directory manager password. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Temporary-fix-for-name-collision-of-textui.print_ent.patch Type: application/mbox Size: 1955 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Allow-adding-entries-with-pre-hashed-passwords-but.patch Type: application/mbox Size: 2196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-BIND-pre-op-for-DS-IPA-password-migration-to-ip.patch Type: application/mbox Size: 16390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-enable-migration-option-in-config-plugin.patch Type: application/mbox Size: 2235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-DS-migration-plugin-and-password-migration-page.patch Type: application/mbox Size: 24262 bytes Desc: not available URL: From pzuna at redhat.com Tue Jan 12 19:12:26 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 12 Jan 2010 20:12:26 +0100 Subject: [Freeipa-devel] [PATCH] Use 'l' instead of 'localityname' in host plugin. Message-ID: <4B4CC99A.2050009@redhat.com> It seems that 'localityname' and 'locality' aliases were dropped in newer versions of DS. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-l-instead-of-localityname-in-host-plugin.patch Type: application/mbox Size: 2668 bytes Desc: not available URL: From pzuna at redhat.com Wed Jan 13 16:46:41 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 13 Jan 2010 17:46:41 +0100 Subject: [Freeipa-devel] [PATCH] Fix backend.Executioner unit test. Message-ID: <4B4DF8F1.9060105@redhat.com> Before the patch that allows to create unshared instances of Connectible, all Connection objects were deleted at once in destroy_context(). It made sense at the time, because there was always at most one Connection per Connectible subclass and Connectible.disconnect() was called only interanally by the Executioner class. Now that we can make arbitrary connections, it makes more sense to delete the Connection object when Connectible.disconnect() is called. Long story short: I fixed the Disconnect class in the unit test, so that it behaves like Connectible.disconnect() and deletes the Connection object when called. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-backend.Executioner-unit-test.patch Type: application/mbox Size: 4070 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 13 18:40:04 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Jan 2010 13:40:04 -0500 Subject: [Freeipa-devel] [PATCH] Fix backend.Executioner unit test. In-Reply-To: <4B4DF8F1.9060105@redhat.com> References: <4B4DF8F1.9060105@redhat.com> Message-ID: <4B4E1384.70802@redhat.com> Pavel Zuna wrote: > Before the patch that allows to create unshared instances of > Connectible, all Connection objects were deleted at once in > destroy_context(). It made sense at the time, because there was always > at most one Connection per Connectible subclass and > Connectible.disconnect() was called only interanally by the Executioner > class. Now that we can make arbitrary connections, it makes more sense > to delete the Connection object when Connectible.disconnect() is called. > > Long story short: I fixed the Disconnect class in the unit test, so that > it behaves like Connectible.disconnect() and deletes the Connection > object when called. > > Pavel ack, pushed to master From rcritten at redhat.com Wed Jan 13 18:41:15 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Jan 2010 13:41:15 -0500 Subject: [Freeipa-devel] [PATCH] Add default values for krb ticket policy attributes during installation. In-Reply-To: <4B4C9BBE.2070302@redhat.com> References: <4B4C9BBE.2070302@redhat.com> Message-ID: <4B4E13CB.2000208@redhat.com> Pavel Zuna wrote: > Adds some required attributes and values for kerberos ticket policy. > > Pavel ack, pushed to master David, new plugin to document. From rcritten at redhat.com Wed Jan 13 18:44:06 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Jan 2010 13:44:06 -0500 Subject: [Freeipa-devel] [PATCH] Add default values for krb ticket policy attributes during installation. In-Reply-To: <4B4C9BBE.2070302@redhat.com> References: <4B4C9BBE.2070302@redhat.com> Message-ID: <4B4E1476.6010507@redhat.com> Pavel Zuna wrote: > Adds some required attributes and values for kerberos ticket policy. > > Pavel ack, pushed to master From rcritten at redhat.com Wed Jan 13 18:44:22 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Jan 2010 13:44:22 -0500 Subject: [Freeipa-devel] [PATCH] Add Kerberos Ticket Policy management plugin. In-Reply-To: <4B4B34B4.7020406@redhat.com> References: <4B434A60.1090708@redhat.com> <4B47576B.4010004@redhat.com> <4B4B34B4.7020406@redhat.com> Message-ID: <4B4E1486.2060800@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Alright, here's my first shot at the Kerberos Ticket Policy >>> management plugin. >>> >>> It is also a "new type" of plugin. What I mean by that is that it >>> takes an optional primary key (username) as its first argument. If >>> used, policy for a specific user is being managed. If not, the global >>> policy is being managed. If there's no value defined for a specific >>> user, the global value is displayed instead. This pattern could also >>> be applied to the pwpolicy plugin. >>> >>> The pwpolicy plugin currently doesn't even use the baseldap classes >>> and is a bit buggy*. So, if nobody minds, I'd like to rewrite it to >>> use this pattern. It should only take a few hours. >>> >>> * minor bugs in pwpolicy plugin: >>> - it says that higher number in cosPriority means higher priority, >>> this isn't true >>> - it is impossible to modify cosPriority using pwpolicy-mod, it >>> throws an exception, because it tries to set it in the wrong entry >>> >>> Pavel >> >> I'm having a problem getting this to apply to the tip. Does this >> depend on some other patches? >> >> patching file ipalib/plugins/baseldap.py >> Hunk #5 succeeded at 346 (offset 152 lines). >> Hunk #6 FAILED at 363. >> Hunk #7 FAILED at 422. >> Hunk #8 FAILED at 506. >> Hunk #9 succeeded at 208 (offset -163 lines). >> Hunk #10 succeeded at 566 (offset 152 lines). >> Hunk #11 succeeded at 267 (offset -163 lines). >> Hunk #12 succeeded at 873 (offset 150 lines). >> 3 out of 12 hunks FAILED -- saving rejects to file >> ipalib/plugins/baseldap.py.rej >> patching file ipalib/plugins/krbtpolicy.py >> >> rob > There was a forgotten patch adding --all to LDAPCreate, I reposted it on > freeipa devel just now. I also generated a new version of the Kerberos > Ticket Policy plugin patch (attached), just in case. > > Pavel > ack, pushed to master From rcritten at redhat.com Wed Jan 13 18:48:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Jan 2010 13:48:33 -0500 Subject: [Freeipa-devel] [PATCH] Make host objects aware of their membership and that l==localityname. In-Reply-To: <4B4C9BF3.9070000@redhat.com> References: <4B4C9BF3.9070000@redhat.com> Message-ID: <4B4E1581.4010905@redhat.com> Pavel Zuna wrote: > Re-post of a long forgotten patch. > > Pavel > Not to be too picky but will this conflict with the recent localityname changes? rob From pzuna at redhat.com Thu Jan 14 14:57:52 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 14 Jan 2010 15:57:52 +0100 Subject: [Freeipa-devel] [PATCH] Make host objects aware of their membership and that l==localityname. In-Reply-To: <4B4E1581.4010905@redhat.com> References: <4B4C9BF3.9070000@redhat.com> <4B4E1581.4010905@redhat.com> Message-ID: <4B4F30F0.7080700@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Re-post of a long forgotten patch. >> >> Pavel >> > > Not to be too picky but will this conflict with the recent localityname > changes? No, the changes only tell the plugin that the memberOf attribute of hosts can contain references to certain types of objects and that 'l' should also be renamed to 'locality' when printing entries. > > rob > Pavel From pzuna at redhat.com Thu Jan 14 15:06:57 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 14 Jan 2010 16:06:57 +0100 Subject: [Freeipa-devel] [PATCH] Make DNS plugin support output validation and thus make it work again. Message-ID: <4B4F3311.10705@redhat.com> . Pavel From pzuna at redhat.com Thu Jan 14 15:07:41 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 14 Jan 2010 16:07:41 +0100 Subject: [Freeipa-devel] [PATCH] Make DNS plugin support output validation and thus make it work again. In-Reply-To: <4B4F3311.10705@redhat.com> References: <4B4F3311.10705@redhat.com> Message-ID: <4B4F333D.3060500@redhat.com> Pavel Zuna wrote: > . > > Pavel > Patch attached... here. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-DNS-plugin-support-output-validation-and-thus-m.patch Type: application/mbox Size: 10930 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 14 20:53:55 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Jan 2010 15:53:55 -0500 Subject: [Freeipa-devel] IPAv2, replica installation can be broken Message-ID: <4B4F8463.3080209@redhat.com> I just discovered a problem with replica installation in IPAv2 and wanted to get some additional opinions on it. The scenario is this: You've installed a master, perhaps added some entries on it, everything is working fine. You've got some hosts that you added entries for as well, perhaps even creating some service keytabs. Now you want to make one of those hosts an IPA replica. Things will blow up gloriously because some principals needed for the replica may already exist in the DB. So the question is, do we want to enforce that any replica hosts don't already exist in the database before proceeding? It seems reasonable to me but I'm pretty draconian about such things. Thoughts? rob From rcritten at redhat.com Thu Jan 14 21:00:36 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Jan 2010 16:00:36 -0500 Subject: [Freeipa-devel] [PATCH] Make DNS plugin support output validation and thus make it work again. In-Reply-To: <4B4F333D.3060500@redhat.com> References: <4B4F3311.10705@redhat.com> <4B4F333D.3060500@redhat.com> Message-ID: <4B4F85F4.7030008@redhat.com> Pavel Zuna wrote: > Pavel Zuna wrote: >> . >> >> Pavel >> > Patch attached... here. > > Pavel > This looks ok but do you really want to override output_for_cli? This doesn't seem to do a lot more than the default, but I may be wrong. rob From rcritten at redhat.com Thu Jan 14 21:01:43 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Jan 2010 16:01:43 -0500 Subject: [Freeipa-devel] [PATCH] Make host objects aware of their membership and that l==localityname. In-Reply-To: <4B4C9BF3.9070000@redhat.com> References: <4B4C9BF3.9070000@redhat.com> Message-ID: <4B4F8637.2000703@redhat.com> Pavel Zuna wrote: > Re-post of a long forgotten patch. > > Pavel ack, pushed to master rob From rcritten at redhat.com Thu Jan 14 21:02:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Jan 2010 16:02:42 -0500 Subject: [Freeipa-devel] [PATCH] Use 'l' instead of 'localityname' in host plugin. In-Reply-To: <4B4CC99A.2050009@redhat.com> References: <4B4CC99A.2050009@redhat.com> Message-ID: <4B4F8672.6000008@redhat.com> Pavel Zuna wrote: > It seems that 'localityname' and 'locality' aliases were dropped in > newer versions of DS. > > Pavel ack, pushed to master From dpal at redhat.com Thu Jan 14 21:36:43 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 14 Jan 2010 16:36:43 -0500 Subject: [Freeipa-devel] IPAv2, replica installation can be broken In-Reply-To: <4B4F8463.3080209@redhat.com> References: <4B4F8463.3080209@redhat.com> Message-ID: <4B4F8E6B.808@redhat.com> Rob Crittenden wrote: > I just discovered a problem with replica installation in IPAv2 and > wanted to get some additional opinions on it. > > The scenario is this: You've installed a master, perhaps added some > entries on it, everything is working fine. You've got some hosts that > you added entries for as well, perhaps even creating some service > keytabs. > > Now you want to make one of those hosts an IPA replica. Things will > blow up gloriously because some principals needed for the replica may > already exist in the DB. > > So the question is, do we want to enforce that any replica hosts don't > already exist in the database before proceeding? It seems reasonable > to me but I'm pretty draconian about such things. > It should check anyways. I think this is required. Now if it found a host there are several options what it can do: a) Fail and ask to remove the entry manually b) Delete and recreate the entry as replica c) Convert the host to replica gracefully d) Ask user what he wants to do and proceed depending on his choice. As adept of best usability and flexibility I would say d) but as usual it is most of work. I think the effort incrementally increases from a) to d) so you tell me what we can afford to do for v2. Can we do c)? > Thoughts? > > 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 ssorce at redhat.com Fri Jan 15 17:40:24 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Jan 2010 12:40:24 -0500 Subject: [Freeipa-devel] IPAv2, replica installation can be broken In-Reply-To: <4B4F8463.3080209@redhat.com> References: <4B4F8463.3080209@redhat.com> Message-ID: <20100115124024.5217d0cd@willson.li.ssimo.org> On Thu, 14 Jan 2010 15:53:55 -0500 Rob Crittenden wrote: > I just discovered a problem with replica installation in IPAv2 and > wanted to get some additional opinions on it. > > The scenario is this: You've installed a master, perhaps added some > entries on it, everything is working fine. You've got some hosts that > you added entries for as well, perhaps even creating some service > keytabs. > > Now you want to make one of those hosts an IPA replica. Things will > blow up gloriously because some principals needed for the replica may > already exist in the DB. > > So the question is, do we want to enforce that any replica hosts > don't already exist in the database before proceeding? It seems > reasonable to me but I'm pretty draconian about such things. > > Thoughts? Ok so the best solution would be to detect that and just use the existing entries. Although if it is really just krb keys, I think it is perfectly acceptable to simply delete existing ones at replica-install time and regenerate new ones. (with a warning that some clients may need to refresh their credential cache in the hours right after the operation). It would be probably much easier if we can get to do an online replica install instead of going through the current file based replica. Can we revisit what keeps us from doing that ? With the addition of dogtag in 2.0 are certificates still a problem ? What else do we miss ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Jan 15 18:39:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Jan 2010 13:39:54 -0500 Subject: [Freeipa-devel] IPAv2, replica installation can be broken In-Reply-To: <20100115124024.5217d0cd@willson.li.ssimo.org> References: <4B4F8463.3080209@redhat.com> <20100115124024.5217d0cd@willson.li.ssimo.org> Message-ID: <4B50B67A.6050105@redhat.com> Simo Sorce wrote: > On Thu, 14 Jan 2010 15:53:55 -0500 > Rob Crittenden wrote: > >> I just discovered a problem with replica installation in IPAv2 and >> wanted to get some additional opinions on it. >> >> The scenario is this: You've installed a master, perhaps added some >> entries on it, everything is working fine. You've got some hosts that >> you added entries for as well, perhaps even creating some service >> keytabs. >> >> Now you want to make one of those hosts an IPA replica. Things will >> blow up gloriously because some principals needed for the replica may >> already exist in the DB. >> >> So the question is, do we want to enforce that any replica hosts >> don't already exist in the database before proceeding? It seems >> reasonable to me but I'm pretty draconian about such things. >> >> Thoughts? > > Ok so the best solution would be to detect that and just use the > existing entries. > > Although if it is really just krb keys, I think it is perfectly > acceptable to simply delete existing ones at replica-install time and > regenerate new ones. (with a warning that some clients may need to > refresh their credential cache in the hours right after the operation). > > It would be probably much easier if we can get to do an online replica > install instead of going through the current file based replica. > > Can we revisit what keeps us from doing that ? With the addition of > dogtag in 2.0 are certificates still a problem ? What else do we miss ? > > Simo. > Certs are no problem. One of the hangups was kpasswd.keytab which needs to be the same on all machines. I seem to think that all the problems were related to bootstrapping the KDC. rob From rcritten at redhat.com Mon Jan 18 15:21:01 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Jan 2010 10:21:01 -0500 Subject: [Freeipa-devel] [PATCH] 348, v1.2, explicitly pull schema attributes Message-ID: <4B547C5D.70007@redhat.com> This is an IPA 1.2 fix. 389-ds updated the way you query the schema online to be more RFC-complaint by making many more attributes operational. So we have to explicitly request the attributes we want to look at. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-348-schema.patch Type: application/mbox Size: 1164 bytes Desc: not available URL: From ssorce at redhat.com Mon Jan 18 16:57:09 2010 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 18 Jan 2010 11:57:09 -0500 Subject: [Freeipa-devel] [PATCH] 348, v1.2, explicitly pull schema attributes In-Reply-To: <4B547C5D.70007@redhat.com> References: <4B547C5D.70007@redhat.com> Message-ID: <20100118115709.26f7d05d@willson.li.ssimo.org> On Mon, 18 Jan 2010 10:21:01 -0500 Rob Crittenden wrote: > This is an IPA 1.2 fix. > > 389-ds updated the way you query the schema online to be more > RFC-complaint by making many more attributes operational. So we have > to explicitly request the attributes we want to look at. > > rob Ack -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Mon Jan 18 17:07:45 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 18 Jan 2010 18:07:45 +0100 Subject: [Freeipa-devel] [PATCH] Make DNS plugin support output validation and thus make it work again. In-Reply-To: <4B4F85F4.7030008@redhat.com> References: <4B4F3311.10705@redhat.com> <4B4F333D.3060500@redhat.com> <4B4F85F4.7030008@redhat.com> Message-ID: <4B549561.8060406@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Pavel Zuna wrote: >>> . >>> >>> Pavel >>> >> Patch attached... here. >> >> Pavel >> > > This looks ok but do you really want to override output_for_cli? This > doesn't seem to do a lot more than the default, but I may be wrong. It does a little bit more. Anyway this patch is simply there to make things work again for Martin, I'm planning to re-factor the whole thing in the future. > rob Pavel From jdennis at redhat.com Wed Jan 20 03:04:19 2010 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Jan 2010 22:04:19 -0500 Subject: [Freeipa-devel] [PATCH] pass DER flag to x509.get_serial_number() Message-ID: <1263956659-11411-1-git-send-email-jdennis@redhat.com> From: jdennis --- ipalib/plugins/cert.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py index a22d075..312ad39 100644 --- a/ipalib/plugins/cert.py +++ b/ipalib/plugins/cert.py @@ -58,7 +58,7 @@ def get_serial(certificate): pass try: - serial = x509.get_serial_number(certificate) + serial = x509.get_serial_number(certificate, x509.DER) except PyAsn1Error: raise errors.CertificateOperationError(error=_('Unable to decode certificate in entry')) -- 1.6.6 From rcritten at redhat.com Tue Jan 19 22:02:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Jan 2010 17:02:58 -0500 Subject: [Freeipa-devel] [PATCH] 345 fix pwpolicy plugin In-Reply-To: <4B4B4FA2.30401@redhat.com> References: <4B479E17.5090404@redhat.com> <4B4B4FA2.30401@redhat.com> Message-ID: <4B562C12.4040009@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Allow the priority to be updated and fix the description of priority >> ordering. Lower wins, not higher. >> >> I also had to add the option to not normalize to a few more functions >> in ldap2. I have to craft a very specifically-formatted DN for it to >> be understood by the krb5 server. >> >> rob >> > The patch is fine and everything seems to work. There's just some > leftover debugging calls, that should probably go away. > > Pavel Removed left-over debugging stmts and pushed to master rob From rcritten at redhat.com Tue Jan 19 22:29:12 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Jan 2010 17:29:12 -0500 Subject: [Freeipa-devel] [PATCH] pass DER flag to x509.get_serial_number() In-Reply-To: <1263956659-11411-1-git-send-email-jdennis@redhat.com> References: <1263956659-11411-1-git-send-email-jdennis@redhat.com> Message-ID: <4B563238.8080904@redhat.com> John Dennis wrote: > From: jdennis > > --- > ipalib/plugins/cert.py | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/ipalib/plugins/cert.py b/ipalib/plugins/cert.py > index a22d075..312ad39 100644 > --- a/ipalib/plugins/cert.py > +++ b/ipalib/plugins/cert.py > @@ -58,7 +58,7 @@ def get_serial(certificate): > pass > try: > > - serial = x509.get_serial_number(certificate) > + serial = x509.get_serial_number(certificate, x509.DER) > except PyAsn1Error: > raise errors.CertificateOperationError(error=_('Unable to decode certificate in entry')) > ack, pushed to master From jdennis at redhat.com Wed Jan 20 20:09:00 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Jan 2010 15:09:00 -0500 Subject: [Freeipa-devel] [PATCH] Create pkiuser before calling pkicreate, pkicreate depends on the user existing Message-ID: <1264018140-7627-1-git-send-email-jdennis@redhat.com> --- ipaserver/install/cainstance.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py index a43809c..97ba833 100644 --- a/ipaserver/install/cainstance.py +++ b/ipaserver/install/cainstance.py @@ -445,9 +445,9 @@ class CAInstance(service.Service): self.cert_chain_file=cert_chain_file self.external=2 + self.step("creating certificate server user", self.__create_ca_user) if not ipautil.dir_exists("/var/lib/pki-ca"): self.step("creating pki-ca instance", self.create_instance) - self.step("creating certificate server user", self.__create_ca_user) self.step("configuring certificate server instance", self.__configure_instance) # Step 1 of external is getting a CSR so we don't need to do these # steps until we get a cert back from the external CA. -- 1.6.6 From rcritten at redhat.com Wed Jan 20 16:19:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 11:19:52 -0500 Subject: [Freeipa-devel] [PATCH] 350 improvements to cert plugin Message-ID: <4B572D28.2070700@redhat.com> This makes the cert plugin use the built-in output functions and conform with output validation. It also normalizes an incoming PKCS#10 request to strip any data before or after the BEGIN/END blocks. And finally I added a get_subject() helper so we can include the subject when retrieving a cert with cert_get. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-350-cert.patch Type: application/mbox Size: 5499 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 20 16:31:29 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 11:31:29 -0500 Subject: [Freeipa-devel] [PATCH] 351 configurable certificate subjects Message-ID: <4B572FE1.5050901@redhat.com> Let the user, upon installation, set the certificate subject base for the dogtag CA. Certificate requests will automatically be given this subject base, regardless of what is in the CSR. The selfsign plugin does not currently support this dynamic name re-assignment and will reject any incoming requests that don't conform to the subject base. The certificate subject base is stored in cn=ipaconfig but it does NOT dynamically update the configuration, for dogtag at least. The file /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to be updated and pki-cad restarted. For example: # ipa-server-install --ca --subject="O=Example" If the installed CA is dogtag then the following will happen: 1. request for CN=test.example.com will issue CN=test.example.com, O=Example 2. request for CN=test.example.com, O=Test will issue CN=test.example.com, O=Example 3. request for CN=test.example.com, O=Example will issue CN=test.example.com, O=Example If the installed CA is selfsign then the following will happen: 1. request for CN=test.example.com will be rejected 2. request for CN=test.example.com, O=Test will be rejected 3. request for CN=test.example.com, O=Example will issue CN=test.example.com, O=Example rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-351-subject.patch Type: application/mbox Size: 35534 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 20 16:33:03 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 11:33:03 -0500 Subject: [Freeipa-devel] [PATCH] Create pkiuser before calling pkicreate, pkicreate depends on the user existing In-Reply-To: <1264018140-7627-1-git-send-email-jdennis@redhat.com> References: <1264018140-7627-1-git-send-email-jdennis@redhat.com> Message-ID: <4B57303F.8050306@redhat.com> John Dennis wrote: > --- > ipaserver/install/cainstance.py | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py > index a43809c..97ba833 100644 > --- a/ipaserver/install/cainstance.py > +++ b/ipaserver/install/cainstance.py > @@ -445,9 +445,9 @@ class CAInstance(service.Service): > self.cert_chain_file=cert_chain_file > self.external=2 > > + self.step("creating certificate server user", self.__create_ca_user) > if not ipautil.dir_exists("/var/lib/pki-ca"): > self.step("creating pki-ca instance", self.create_instance) > - self.step("creating certificate server user", self.__create_ca_user) > self.step("configuring certificate server instance", self.__configure_instance) > # Step 1 of external is getting a CSR so we don't need to do these > # steps until we get a cert back from the external CA. ack, pushed to master From rcritten at redhat.com Wed Jan 20 16:50:57 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 11:50:57 -0500 Subject: [Freeipa-devel] [PATCH] 352 fix ipa-rmkeytab Message-ID: <4B573471.6000908@redhat.com> On F-12 I noticed that ipa-rmkeytab failed trying to remove entries. Turned out I needed to suspend looping when doing the removal. I think it was a fluke that this worked on F-11 with an older krb5-server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-352-rmkeytab.patch Type: application/mbox Size: 1075 bytes Desc: not available URL: From jdennis at redhat.com Wed Jan 20 18:06:37 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Jan 2010 13:06:37 -0500 Subject: [Freeipa-devel] [PATCH] 350 improvements to cert plugin In-Reply-To: <4B572D28.2070700@redhat.com> References: <4B572D28.2070700@redhat.com> Message-ID: <4B57462D.2060309@redhat.com> On 01/20/2010 11:19 AM, Rob Crittenden wrote: > This makes the cert plugin use the built-in output functions and conform > with output validation. > > It also normalizes an incoming PKCS#10 request to strip any data before > or after the BEGIN/END blocks. > > And finally I added a get_subject() helper so we can include the subject > when retrieving a cert with cert_get. So now the csr file can be in pem format? Great, I was just about to file a bug for that. You're one step ahead of me. ACK -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Jan 20 18:07:21 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Jan 2010 13:07:21 -0500 Subject: [Freeipa-devel] [PATCH] 352 fix ipa-rmkeytab In-Reply-To: <4B573471.6000908@redhat.com> References: <4B573471.6000908@redhat.com> Message-ID: <4B574659.4090103@redhat.com> On 01/20/2010 11:50 AM, Rob Crittenden wrote: > On F-12 I noticed that ipa-rmkeytab failed trying to remove entries. > Turned out I needed to suspend looping when doing the removal. I think > it was a fluke that this worked on F-11 with an older krb5-server. ACK -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Jan 20 18:21:10 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Jan 2010 13:21:10 -0500 Subject: [Freeipa-devel] [PATCH] 351 configurable certificate subjects In-Reply-To: <4B572FE1.5050901@redhat.com> References: <4B572FE1.5050901@redhat.com> Message-ID: <4B574996.1030308@redhat.com> On 01/20/2010 11:31 AM, Rob Crittenden wrote: > Let the user, upon installation, set the certificate subject base for > the dogtag CA. Certificate requests will automatically be given this > subject base, regardless of what is in the CSR. > > The selfsign plugin does not currently support this dynamic name > re-assignment and will reject any incoming requests that don't conform > to the subject base. > > The certificate subject base is stored in cn=ipaconfig but it does NOT > dynamically update the configuration, for dogtag at least. The file > /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to be > updated and pki-cad restarted. > > For example: > # ipa-server-install --ca --subject="O=Example" > > If the installed CA is dogtag then the following will happen: > > 1. request for CN=test.example.com will issue CN=test.example.com, > O=Example > 2. request for CN=test.example.com, O=Test will issue > CN=test.example.com, O=Example > 3. request for CN=test.example.com, O=Example will issue > CN=test.example.com, O=Example > > If the installed CA is selfsign then the following will happen: > > 1. request for CN=test.example.com will be rejected > 2. request for CN=test.example.com, O=Test will be rejected > 3. request for CN=test.example.com, O=Example will issue > CN=test.example.com, O=Example > > rob ACK -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mnagy at redhat.com Wed Jan 20 18:31:07 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 19:31:07 +0100 Subject: [Freeipa-devel] [PATCH] Make DNS plugin support output validation and thus make it work again. In-Reply-To: <4B549561.8060406@redhat.com> References: <4B4F3311.10705@redhat.com> <4B4F333D.3060500@redhat.com> <4B4F85F4.7030008@redhat.com> <4B549561.8060406@redhat.com> Message-ID: <1264012267.3326.406.camel@wolverine.englab.brq.redhat.com> On Mon, 2010-01-18 at 18:07 +0100, Pavel Zuna wrote: > Rob Crittenden wrote: > > Pavel Zuna wrote: > >> Pavel Zuna wrote: > >>> . > >>> > >>> Pavel > >>> > >> Patch attached... here. > >> > >> Pavel > >> > > > > This looks ok but do you really want to override output_for_cli? This > > doesn't seem to do a lot more than the default, but I may be wrong. > It does a little bit more. Anyway this patch is simply there to make things work > again for Martin, I'm planning to re-factor the whole thing in the future. Yeah, I pretty much need this, thanks. I made a review and tested the patch. Ack & pushed. Martin From mnagy at redhat.com Wed Jan 20 19:16:18 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 20:16:18 +0100 Subject: [Freeipa-devel] [PATCHES] Use the dns plugin during installation In-Reply-To: <1259857519.3326.153.camel@wolverine.englab.brq.redhat.com> References: <1259857519.3326.153.camel@wolverine.englab.brq.redhat.com> Message-ID: <1264014978.3326.407.camel@wolverine.englab.brq.redhat.com> On Thu, 2009-12-03 at 17:25 +0100, Martin Nagy wrote: > Hi, > these three patches should make sure that we add dns records the right > way. It will also serve for the ipa-dns-install command that's almost > ready, patch will be coming soon. > > Thanks > Martin I've rebased the paches and fixed some other things I found later. Attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Move-api-finalization-in-ipa-server-install-after-wr.patch Type: text/x-patch Size: 3577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-the-dns-plug-in-for-addition-of-records-during-i.patch Type: text/x-patch Size: 10851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Only-add-an-NTP-SRV-record-if-we-really-are-setting.patch Type: text/x-patch Size: 4527 bytes Desc: not available URL: From mnagy at redhat.com Wed Jan 20 19:31:29 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 20:31:29 +0100 Subject: [Freeipa-devel] [PATCHES] Use the dns plugin during installation In-Reply-To: <1259857519.3326.153.camel@wolverine.englab.brq.redhat.com> References: <1259857519.3326.153.camel@wolverine.englab.brq.redhat.com> Message-ID: <1264015889.3535.3.camel@wolverine.englab.brq.redhat.com> On Thu, 2009-12-03 at 17:25 +0100, Martin Nagy wrote: > Hi, > these three patches should make sure that we add dns records the right > way. It will also serve for the ipa-dns-install command that's almost > ready, patch will be coming soon. > > Thanks > Martin New patches, rebased + some minor issues in the previous patches fixed, please review. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Move-api-finalization-in-ipa-server-install-after-wr.patch Type: text/x-patch Size: 3577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-the-dns-plug-in-for-addition-of-records-during-i.patch Type: text/x-patch Size: 10851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Only-add-an-NTP-SRV-record-if-we-really-are-setting.patch Type: text/x-patch Size: 4527 bytes Desc: not available URL: From mnagy at redhat.com Wed Jan 20 19:36:33 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 20:36:33 +0100 Subject: [Freeipa-devel] [PATCHES] Add ipa-dns-install Message-ID: <1264016193.3535.9.camel@wolverine.englab.brq.redhat.com> Hi, with these patches, the user will be able to install DNS additionally, after ipa-server-install. No --uninstall yet, however. I do have it in my tree, but it causes a lot of problems. Hopefully, I'll manage to solve them later. Thanks. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-a-custom-file-mode-when-setting-up-debugging.patch Type: text/x-patch Size: 1338 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Move-some-functions-from-ipa-server-install-into-ins.patch Type: text/x-patch Size: 4845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-ipa-dns-install-script.patch Type: text/x-patch Size: 7770 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 20 21:55:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 16:55:02 -0500 Subject: [Freeipa-devel] [PATCHES] IPA to DS migration. In-Reply-To: <4B4CC1BA.6080403@redhat.com> References: <4B4CC1BA.6080403@redhat.com> Message-ID: <4B577BB6.2050705@redhat.com> Pavel Zuna wrote: > Ok, here's the latest version of IPA to DS migration "suite". > > It includes the following: > - A fix for a name collision in textui, Jason's big patch added a second > method named print_entry. Nobody noticed there was one already. > - Patch to the ipa-pwd-extop plugin to allow adding entries with > pre-hashed password if migration mode is enabled. > - BIND pre-operation plugin to generate Kerberos keys on simple BIND's > if missing. > - Migration plugin. > - Option in config plugin to enable/disable migration mode. > - Password migration page. > > what has changed since the last version: > - LDAP backend is used to connect to DS, no more low level python-ldap > calls. > - The plugin checks if migration is enabled and gives direction on how > to enable it. > - The plugin can now be extended to support other objects than just > users and groups. You just need to create an LDAPObject and add it's > name along with a search filter (to find the objects in DS) and > optionaly callbacks to handle special cases. There's some inline > documentation. > - LDAP URI validation. > - Better error messages. > - Fixed typos. > > The migration won't be easy to test, so tomorrow I'll setup 2 VMs on the > blades. One with IPA + migration "suite" and one with DS along with some > scripts to generate objects that I used for testing. > > Using the migration plugin is really easy, you just point it to the DS > server and enter the directory manager password. > > Pavel ack, pushed to master From rcritten at redhat.com Wed Jan 20 22:01:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 17:01:08 -0500 Subject: [Freeipa-devel] [PATCH] 353 enable sssd and certmonger Message-ID: <4B577D24.8010401@redhat.com> Configure sssd and certmonger in ipa-client-install This does a number of things under the hood: - Use authconfig to enable sssd in nss and pam - Configure /etc/sssd/sssd.conf to use our IPA provider - Enable the certmonger process and request a server cert - join the IPA domain and retrieve a principal. The clinet machine *must* exist in IPA to be able to do a join. - And then undo all this on uninstall There are 2 ways to join a host, using a one-time password or a user with the proper privileges. For example, create a host joinable by an admin (must be in the hostadmin role): $ ipa host-add test.example.com To add a host with a OTP: $ ipa host-add --password=Secret123 test2.example.com Then run ipa-client-install on the client and it should basically work the same as before except it will quit if the host has already been enrolled. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-353-sssd.patch Type: application/mbox Size: 7573 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 20 22:03:03 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 17:03:03 -0500 Subject: [Freeipa-devel] [PATCH] 352 fix ipa-rmkeytab In-Reply-To: <4B574659.4090103@redhat.com> References: <4B573471.6000908@redhat.com> <4B574659.4090103@redhat.com> Message-ID: <4B577D97.9060700@redhat.com> John Dennis wrote: > On 01/20/2010 11:50 AM, Rob Crittenden wrote: >> On F-12 I noticed that ipa-rmkeytab failed trying to remove entries. >> Turned out I needed to suspend looping when doing the removal. I think >> it was a fluke that this worked on F-11 with an older krb5-server. > > ACK > pushed to master From rcritten at redhat.com Wed Jan 20 22:03:11 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 17:03:11 -0500 Subject: [Freeipa-devel] [PATCH] 350 improvements to cert plugin In-Reply-To: <4B57462D.2060309@redhat.com> References: <4B572D28.2070700@redhat.com> <4B57462D.2060309@redhat.com> Message-ID: <4B577D9F.7040608@redhat.com> John Dennis wrote: > On 01/20/2010 11:19 AM, Rob Crittenden wrote: >> This makes the cert plugin use the built-in output functions and conform >> with output validation. >> >> It also normalizes an incoming PKCS#10 request to strip any data before >> or after the BEGIN/END blocks. >> >> And finally I added a get_subject() helper so we can include the subject >> when retrieving a cert with cert_get. > > So now the csr file can be in pem format? Great, I was just about to > file a bug for that. You're one step ahead of me. > > ACK > pushed to master From mnagy at redhat.com Wed Jan 20 22:11:42 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 23:11:42 +0100 Subject: [Freeipa-devel] [PATCHES] Add A and PTR records during ipa-replica-prepare Message-ID: <1264025502.3535.14.camel@wolverine.englab.brq.redhat.com> Hi, these patches will allow one to specify an ip address of the replica to ipa-replica-prepare. The dns records will then be added. This should make life better for QA :) Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Get-rid-of-ipapython.config-in-ipa-replica-prepare.patch Type: text/x-patch Size: 9602 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-A-and-PTR-records-during-ipa-replica-prepare.patch Type: text/x-patch Size: 3042 bytes Desc: not available URL: From mnagy at redhat.com Wed Jan 20 22:15:53 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 23:15:53 +0100 Subject: [Freeipa-devel] [PATCH] Set BIND to use ldapi and use fake mname Message-ID: <1264025753.3535.15.camel@wolverine.englab.brq.redhat.com> Hi, some additional comments are in the patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Set-BIND-to-use-ldapi-and-use-fake-mname.patch Type: text/x-patch Size: 1933 bytes Desc: not available URL: From mnagy at redhat.com Wed Jan 20 22:29:37 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 23:29:37 +0100 Subject: [Freeipa-devel] [PATCH] 353 enable sssd and certmonger In-Reply-To: <4B577D24.8010401@redhat.com> References: <4B577D24.8010401@redhat.com> Message-ID: <1264026577.3535.17.camel@wolverine.englab.brq.redhat.com> On Wed, 2010-01-20 at 17:01 -0500, Rob Crittenden wrote: > Configure sssd and certmonger in ipa-client-install > > This does a number of things under the hood: > > - Use authconfig to enable sssd in nss and pam > - Configure /etc/sssd/sssd.conf to use our IPA provider > - Enable the certmonger process and request a server cert > - join the IPA domain and retrieve a principal. The clinet machine > *must* exist in IPA to be able to do a join. > - And then undo all this on uninstall > rob Heh, joining FreeIPA and SSSD at last, cool :-) ACK Martin From mnagy at redhat.com Wed Jan 20 22:33:37 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 23:33:37 +0100 Subject: [Freeipa-devel] [PATCH] jderose 033 Fix fuzzy digigits under Fedora12 In-Reply-To: <1263235258.20456.6.camel@jgd-dsk> References: <1263235258.20456.6.camel@jgd-dsk> Message-ID: <1264026817.3535.18.camel@wolverine.englab.brq.redhat.com> On Mon, 2010-01-11 at 11:40 -0700, Jason Gerard DeRose wrote: > I'm not sure why the difference, but the uidnumber, gidnumber, etc. are > being returned as `unicode` instead of `str` under Fedora12. Returning > as `unicode` is correct, but this patch allows the test to still work > under Fedora11 for the time being. ACK Martin From mnagy at redhat.com Wed Jan 20 22:38:24 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Jan 2010 23:38:24 +0100 Subject: [Freeipa-devel] [PATCH] 344 require fully-qualified hostname in ipa-join In-Reply-To: <4B479DC7.9060405@redhat.com> References: <4B479DC7.9060405@redhat.com> Message-ID: <1264027104.3535.19.camel@wolverine.englab.brq.redhat.com> On Fri, 2010-01-08 at 16:04 -0500, Rob Crittenden wrote: > Require a fully-qualified hostname in ipa-join. The server side will > enforce this as well but better to catch it early. > > rob ACK Martin From rcritten at redhat.com Wed Jan 20 22:44:36 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Jan 2010 17:44:36 -0500 Subject: [Freeipa-devel] [PATCH] 351 configurable certificate subjects In-Reply-To: <4B574996.1030308@redhat.com> References: <4B572FE1.5050901@redhat.com> <4B574996.1030308@redhat.com> Message-ID: <4B578754.1060703@redhat.com> John Dennis wrote: > On 01/20/2010 11:31 AM, Rob Crittenden wrote: >> Let the user, upon installation, set the certificate subject base for >> the dogtag CA. Certificate requests will automatically be given this >> subject base, regardless of what is in the CSR. >> >> The selfsign plugin does not currently support this dynamic name >> re-assignment and will reject any incoming requests that don't conform >> to the subject base. >> >> The certificate subject base is stored in cn=ipaconfig but it does NOT >> dynamically update the configuration, for dogtag at least. The file >> /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to be >> updated and pki-cad restarted. >> >> For example: >> # ipa-server-install --ca --subject="O=Example" >> >> If the installed CA is dogtag then the following will happen: >> >> 1. request for CN=test.example.com will issue CN=test.example.com, >> O=Example >> 2. request for CN=test.example.com, O=Test will issue >> CN=test.example.com, O=Example >> 3. request for CN=test.example.com, O=Example will issue >> CN=test.example.com, O=Example >> >> If the installed CA is selfsign then the following will happen: >> >> 1. request for CN=test.example.com will be rejected >> 2. request for CN=test.example.com, O=Test will be rejected >> 3. request for CN=test.example.com, O=Example will issue >> CN=test.example.com, O=Example >> >> rob > > ACK > pushed to master From jderose at redhat.com Thu Jan 21 16:46:11 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 21 Jan 2010 09:46:11 -0700 Subject: [Freeipa-devel] Announcing wehjit 0.2.0 Message-ID: <1264092371.2686.91.camel@jgd-dsk> Whats new ========= This release adds significant client-side functionality and several new widgets. The Python API remains mostly unchanged, with the exception of one major addition: you can now make any state variable available client-side by simply creating the state descriptor with a `json=True` kwarg. For example, say you have a widget with a state variable called `stuff`: class MyWidget(wehjit.Widget): stuff = wejhit.Static('stuff') To make `stuff` available client-side, just add `json=True` like this: class MyWidget(wehjit.Widget): stuff = wejhit.Static('stuff', json=True) As far as new widgets, highlights include: * Grid: an AJAX table with client-side sorting, row select (click) and activate (double click) events, and asynchronous updates via JSON-RPC. * Dialog: a generic widget for transient client-side dialog boxes. * DialogSet: controls the available Dialogs in a page. * CRUDS: works in combination with Grid, Dialog, and DialogSet for AJAX Create, Retrieve, Update, Delete, and Search operations. There is likewise quite a bit of new supporting JavaScript for the above widgets. The demo has a new "AJAX Demo" example. However, as CRUDS must talk to a live JSON-RPC server, it doesn't work in the statically rendered demo. But you can run the demo from the source tree like this: ./wehjit-demo Then just point your browser to http://127.0.0.1:8080/e4_grid Lastly, the Menu widget has changed and wont display the MenuItems till you click on the Menu (previously it displayed on mouse over). Download ======== The source tarball, API documentation, and statically rendered demo are all available here: http://jderose.fedorapeople.org/wehjit/0.2.0/ Updated packages for Fedora 12 and rawhide will be available in the next several days (yum install python-wehjit). An unofficial Ubuntu Karmic package is available in my PPA (apt-get install python-wehjit): https://edge.launchpad.net/~jderose/+archive/ppa Finally, you can use Bazaar to get my current code from either my fedorapeople page: bzr branch http://jderose.fedorapeople.org/bzr/wehjit/ Or from Launchpad: bzr branch lp:wehjit From rcritten at redhat.com Thu Jan 21 21:52:37 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Jan 2010 16:52:37 -0500 Subject: [Freeipa-devel] [PATCHES] Add ipa-dns-install In-Reply-To: <1264016193.3535.9.camel@wolverine.englab.brq.redhat.com> References: <1264016193.3535.9.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B58CCA5.3000603@redhat.com> Martin Nagy wrote: > Hi, > with these patches, the user will be able to install DNS additionally, > after ipa-server-install. No --uninstall yet, however. I do have it in > my tree, but it causes a lot of problems. Hopefully, I'll manage to > solve them later. Thanks. > > Martin > Nack, it isn't working for me: # ipa-dns-install The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the FreeIPA Server. This includes: * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: y Enter IP address for a DNS forwarder (empty to stop): No DNS forwarders configured Directory Manager password: The following operations may take some minutes to complete. Please wait until the prompt is returned. Unexpected error - see ipaserver-install.log for details: {'info': 'Unauthenticated binds are not allowed', 'desc': 'Server is unwilling to perform'} There is nothing in the install log, 389 access log had: [21/Jan/2010:16:50:37 -0500] conn=22 fd=70 slot=70 connection from localhost to localhost [21/Jan/2010:16:50:37 -0500] conn=22 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [21/Jan/2010:16:50:37 -0500] conn=22 op=0 RESULT err=53 tag=97 nentries=0 etime=0 [21/Jan/2010:16:50:37 -0500] conn=22 op=1 UNBIND [21/Jan/2010:16:50:37 -0500] conn=22 op=1 fd=70 closed - U1 It also throws an exception if you press ^C at the prompts. rob From rcritten at redhat.com Thu Jan 21 22:09:32 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Jan 2010 17:09:32 -0500 Subject: [Freeipa-devel] [PATCHES] Use the dns plugin during installation In-Reply-To: <1264015889.3535.3.camel@wolverine.englab.brq.redhat.com> References: <1259857519.3326.153.camel@wolverine.englab.brq.redhat.com> <1264015889.3535.3.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B58D09C.5030009@redhat.com> Martin Nagy wrote: > On Thu, 2009-12-03 at 17:25 +0100, Martin Nagy wrote: >> Hi, >> these three patches should make sure that we add dns records the right >> way. It will also serve for the ipa-dns-install command that's almost >> ready, patch will be coming soon. >> >> Thanks >> Martin > > New patches, rebased + some minor issues in the previous patches fixed, > please review. > > Martin ack, pushed to master From rcritten at redhat.com Thu Jan 21 22:37:12 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Jan 2010 17:37:12 -0500 Subject: [Freeipa-devel] [PATCHES] Add ipa-dns-install In-Reply-To: <4B58CCA5.3000603@redhat.com> References: <1264016193.3535.9.camel@wolverine.englab.brq.redhat.com> <4B58CCA5.3000603@redhat.com> Message-ID: <4B58D718.6000502@redhat.com> Rob Crittenden wrote: > Martin Nagy wrote: >> Hi, >> with these patches, the user will be able to install DNS additionally, >> after ipa-server-install. No --uninstall yet, however. I do have it in >> my tree, but it causes a lot of problems. Hopefully, I'll manage to >> solve them later. Thanks. >> >> Martin >> > > Nack, it isn't working for me: > > # ipa-dns-install > > The log file for this installation can be found in > /var/log/ipaserver-install.log > ============================================================================== > > This program will setup DNS for the FreeIPA Server. > > This includes: > * Configure DNS (bind) > > To accept the default shown in brackets, press the Enter key. > > Existing BIND configuration detected, overwrite? [no]: y > Enter IP address for a DNS forwarder (empty to stop): > No DNS forwarders configured > Directory Manager password: > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Unexpected error - see ipaserver-install.log for details: > {'info': 'Unauthenticated binds are not allowed', 'desc': 'Server is > unwilling to perform'} > > There is nothing in the install log, 389 access log had: > > [21/Jan/2010:16:50:37 -0500] conn=22 fd=70 slot=70 connection from > localhost to localhost > [21/Jan/2010:16:50:37 -0500] conn=22 op=0 BIND dn="cn=Directory Manager" > method=128 version=3 > [21/Jan/2010:16:50:37 -0500] conn=22 op=0 RESULT err=53 tag=97 > nentries=0 etime=0 > [21/Jan/2010:16:50:37 -0500] conn=22 op=1 UNBIND > [21/Jan/2010:16:50:37 -0500] conn=22 op=1 fd=70 closed - U1 > > It also throws an exception if you press ^C at the prompts. > > rob I had a discussion with Martin in irc about this. The patch actually does work it just doesn't handle the case where you don't get a DM password. I'm still nacking this particular patch due to this but the first two patches are fine, so ack for those and I'm pushing them to master. rob From rcritten at redhat.com Thu Jan 21 22:38:08 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Jan 2010 17:38:08 -0500 Subject: [Freeipa-devel] [PATCH] Set BIND to use ldapi and use fake mname In-Reply-To: <1264025753.3535.15.camel@wolverine.englab.brq.redhat.com> References: <1264025753.3535.15.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B58D750.9010803@redhat.com> Martin Nagy wrote: > Hi, > some additional comments are in the patch. > > Martin > ack, pushed to master From davido at redhat.com Fri Jan 22 01:32:29 2010 From: davido at redhat.com (David O'Brien) Date: Fri, 22 Jan 2010 11:32:29 +1000 Subject: [Freeipa-devel] [PATCHES] Add A and PTR records during ipa-replica-prepare In-Reply-To: <1264025502.3535.14.camel@wolverine.englab.brq.redhat.com> References: <1264025502.3535.14.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B59002D.1010502@redhat.com> Martin Nagy wrote: > Hi, > these patches will allow one to specify an ip address of the replica to > ipa-replica-prepare. The dns records will then be added. This should > make life better for QA :) > > Martin > This looks suspiciously like something to add to the user doc. Can you elaborate a little? I don't have my ipa-server or test machine available atm to check man pages :-\ If necessary pls raise a bugzilla. thanks -- David O'Brien Senior Technical Writer, Engineering Content Services Red Hat Asia Pacific Pty Ltd 193 North Quay, Brisbane +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb From rcritten at redhat.com Fri Jan 22 15:30:26 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Jan 2010 10:30:26 -0500 Subject: [Freeipa-devel] [PATCHES] Add A and PTR records during ipa-replica-prepare In-Reply-To: <1264025502.3535.14.camel@wolverine.englab.brq.redhat.com> References: <1264025502.3535.14.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B59C492.8050801@redhat.com> Martin Nagy wrote: > Hi, > these patches will allow one to specify an ip address of the replica to > ipa-replica-prepare. The dns records will then be added. This should > make life better for QA :) > > Martin nack, it shouldn't allow the option if DNS is not configured, or at least it shouldn't blow up: # ipa-replica-prepare --ip-address=192.168.166.9 replica4.example.com Directory Manager (existing master) password: Preparing replica for replica4.example.com from luna.example.com Creating SSL certificate for the Directory Server Creating SSL certificate for the Web Server Exporting RA certificate Copying additional files Finalizing configuration Packaging replica information into /var/lib/ipa/replica-info-replica4.example.com.gpg Adding DNS records for replica4.example.com preparation of replica failed: no such entry no such entry File "/usr/sbin/ipa-replica-prepare", line 338, in main() File "/usr/sbin/ipa-replica-prepare", line 329, in main zone = add_zone(domain) File "/usr/lib/python2.6/site-packages/ipaserver/install/bindinstance.py", line 73, in add_zone idnsupdatepolicy=unicode(update_policy)) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 412, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 680, in run return self.execute(*args, **options) File "/usr/lib/python2.6/site-packages/ipalib/plugins/dns.py", line 203, in execute ldap.add_entry(dn, entry_attrs) File "/usr/lib/python2.6/site-packages/ipalib/encoder.py", line 188, in new_f return f(*new_args, **kwargs) File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line 334, in add_entry _handle_errors(e, **{}) File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line 71, in _handle_errors raise errors.NotFound(reason='no such entry') rob From rcritten at redhat.com Fri Jan 22 19:42:04 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Jan 2010 14:42:04 -0500 Subject: [Freeipa-devel] [PATCH] jderose 033 Fix fuzzy digigits under Fedora12 In-Reply-To: <1264026817.3535.18.camel@wolverine.englab.brq.redhat.com> References: <1263235258.20456.6.camel@jgd-dsk> <1264026817.3535.18.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B59FF8C.8080402@redhat.com> Martin Nagy wrote: > On Mon, 2010-01-11 at 11:40 -0700, Jason Gerard DeRose wrote: >> I'm not sure why the difference, but the uidnumber, gidnumber, etc. are >> being returned as `unicode` instead of `str` under Fedora12. Returning >> as `unicode` is correct, but this patch allows the test to still work >> under Fedora11 for the time being. > > ACK > > Martin pushed to master From jderose at redhat.com Mon Jan 25 17:59:02 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 25 Jan 2010 10:59:02 -0700 Subject: [Freeipa-devel] Announcing wehjit 0.2.0 In-Reply-To: <1264092371.2686.91.camel@jgd-dsk> References: <1264092371.2686.91.camel@jgd-dsk> Message-ID: <1264442342.2689.1.camel@jgd-dsk> FYI, wehjit 0.2.0 has landed in Fedora 12. Just `yum install python-wehjit`. On Thu, 2010-01-21 at 09:46 -0700, Jason Gerard DeRose wrote: > Whats new > ========= > > This release adds significant client-side functionality and several new > widgets. The Python API remains mostly unchanged, with the exception of > one major addition: you can now make any state variable available > client-side by simply creating the state descriptor with a `json=True` > kwarg. > > For example, say you have a widget with a state variable called `stuff`: > > class MyWidget(wehjit.Widget): > stuff = wejhit.Static('stuff') > > To make `stuff` available client-side, just add `json=True` like this: > > class MyWidget(wehjit.Widget): > stuff = wejhit.Static('stuff', json=True) > > As far as new widgets, highlights include: > > * Grid: an AJAX table with client-side sorting, row select (click) and > activate (double click) events, and asynchronous updates via > JSON-RPC. > > * Dialog: a generic widget for transient client-side dialog boxes. > > * DialogSet: controls the available Dialogs in a page. > > * CRUDS: works in combination with Grid, Dialog, and DialogSet for AJAX > Create, Retrieve, Update, Delete, and Search operations. > > There is likewise quite a bit of new supporting JavaScript for the above > widgets. > > The demo has a new "AJAX Demo" example. However, as CRUDS must talk to > a live JSON-RPC server, it doesn't work in the statically rendered demo. > But you can run the demo from the source tree like this: > > ./wehjit-demo > > Then just point your browser to http://127.0.0.1:8080/e4_grid > > Lastly, the Menu widget has changed and wont display the MenuItems till > you click on the Menu (previously it displayed on mouse over). > > > Download > ======== > > The source tarball, API documentation, and statically rendered demo are > all available here: > > http://jderose.fedorapeople.org/wehjit/0.2.0/ > > Updated packages for Fedora 12 and rawhide will be available in the next > several days (yum install python-wehjit). > > An unofficial Ubuntu Karmic package is available in my PPA (apt-get > install python-wehjit): > > https://edge.launchpad.net/~jderose/+archive/ppa > > Finally, you can use Bazaar to get my current code from either my > fedorapeople page: > > bzr branch http://jderose.fedorapeople.org/bzr/wehjit/ > > Or from Launchpad: > > bzr branch lp:wehjit > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Mon Jan 25 22:13:43 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Jan 2010 17:13:43 -0500 Subject: [Freeipa-devel] [PATCH] 354 removing bogus code Message-ID: <4B5E1797.6070803@redhat.com> Somehow the same block of code got added twice to ipa-rmkeytab causing, not surprisingly, a double-free. This resolves it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-354-rmkeytab.patch Type: application/mbox Size: 1004 bytes Desc: not available URL: From jdennis at redhat.com Mon Jan 25 23:36:36 2010 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Jan 2010 18:36:36 -0500 Subject: [Freeipa-devel] autogen.sh script? Message-ID: <4B5E2B04.1080208@redhat.com> Who wrote our autogen.sh script and why? Why aren't we using autoreconf instead? FWIW autogen.sh is seriously broken, it's getting incorrect results when comparing different versions of tools. It thinks 1.7 is newer than 1.11 because it's doing string comparisons which causes it to run the wrong versions of some of the tools. I can fix the version comparison but my inclination is not to bother since autogen scripts have been replaced by the autoreconf tool. As for testing the minimum required tool version; is there an actual problem being solved by this? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nkinder at redhat.com Mon Jan 25 23:57:21 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 25 Jan 2010 15:57:21 -0800 Subject: [Freeipa-devel] autogen.sh script? In-Reply-To: <4B5E2B04.1080208@redhat.com> References: <4B5E2B04.1080208@redhat.com> Message-ID: <4B5E2FE1.1020508@redhat.com> On 01/25/2010 03:36 PM, John Dennis wrote: > Who wrote our autogen.sh script and why? > > Why aren't we using autoreconf instead? > > FWIW autogen.sh is seriously broken, it's getting incorrect results > when comparing different versions of tools. It thinks 1.7 is newer > than 1.11 because it's doing string comparisons which causes it to run > the wrong versions of some of the tools. I can fix the version > comparison but my inclination is not to bother since autogen scripts > have been replaced by the autoreconf tool. As for testing the minimum > required tool version; is there an actual problem being solved by this? > It was likely inherited from 389 DS, which was inherited from somewhere I don't recall. The main reason for minimum version checking in DS was due to generating a configure that worked across RHEL/Fedora/Solaris/HP-UX without running autoreconf on all of those systems before each build (which didn't work either IIRC). It was found that specific versions were needed to make this work. From nkinder at redhat.com Tue Jan 26 00:00:41 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 25 Jan 2010 16:00:41 -0800 Subject: [Freeipa-devel] autogen.sh script? In-Reply-To: <4B5E2FE1.1020508@redhat.com> References: <4B5E2B04.1080208@redhat.com> <4B5E2FE1.1020508@redhat.com> Message-ID: <4B5E30A9.1020302@redhat.com> On 01/25/2010 03:57 PM, Nathan Kinder wrote: > On 01/25/2010 03:36 PM, John Dennis wrote: >> Who wrote our autogen.sh script and why? >> >> Why aren't we using autoreconf instead? >> >> FWIW autogen.sh is seriously broken, it's getting incorrect results >> when comparing different versions of tools. It thinks 1.7 is newer >> than 1.11 because it's doing string comparisons which causes it to >> run the wrong versions of some of the tools. I can fix the version >> comparison but my inclination is not to bother since autogen scripts >> have been replaced by the autoreconf tool. As for testing the minimum >> required tool version; is there an actual problem being solved by this? >> > It was likely inherited from 389 DS, which was inherited from > somewhere I don't recall. The main reason for minimum version > checking in DS was due to generating a configure that worked across > RHEL/Fedora/Solaris/HP-UX without running autoreconf on all of those > systems before each build (which didn't work either IIRC). It was > found that specific versions were needed to make this work. Actually, I just looked at the FreeIPA autogen.sh, and it's nothing like the 389 DS one. The 389 Ds autogen.sh just does some minimum version checking (in a different way then the FreeIPA script) and then calls autoreconf if those requirements are correct. I'm not sure of the origin of the FreeIPA autogen.sh script. -NGK > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pzuna at redhat.com Tue Jan 26 09:37:25 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 26 Jan 2010 10:37:25 +0100 Subject: [Freeipa-devel] [PATCH] 354 removing bogus code In-Reply-To: <4B5E1797.6070803@redhat.com> References: <4B5E1797.6070803@redhat.com> Message-ID: <4B5EB7D5.5030900@redhat.com> Rob Crittenden wrote: > Somehow the same block of code got added twice to ipa-rmkeytab causing, > not surprisingly, a double-free. This resolves it. > > rob > ack Pavel From jderose at redhat.com Tue Jan 26 13:49:18 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 26 Jan 2010 06:49:18 -0700 Subject: [Freeipa-devel] [PATCH] jderose 034 Enable WebUI CRUDS using wehjit 0.2.0 Message-ID: <1264513758.5729.8.camel@jgd-dsk> This patch enables webUI Create-Retrieve-Updated-Delete-Search operations for all api.Object plugins that: 1. implement all the required CRUDS methods 2. have a primary_key Last night I realized that the upgrade to wehjit 0.2.0 broke the installer, so I hurried this patch a bit, left out some niceties that still need a bit more testing and tweaking. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-034-Enable-webUI-CRUDS.patch Type: text/x-patch Size: 17843 bytes Desc: not available URL: From rcritten at redhat.com Tue Jan 26 14:42:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Jan 2010 09:42:02 -0500 Subject: [Freeipa-devel] autogen.sh script? In-Reply-To: <4B5E2B04.1080208@redhat.com> References: <4B5E2B04.1080208@redhat.com> Message-ID: <4B5EFF39.50905@redhat.com> John Dennis wrote: > Who wrote our autogen.sh script and why? > > Why aren't we using autoreconf instead? > > FWIW autogen.sh is seriously broken, it's getting incorrect results when > comparing different versions of tools. It thinks 1.7 is newer than 1.11 > because it's doing string comparisons which causes it to run the wrong > versions of some of the tools. I can fix the version comparison but my > inclination is not to bother since autogen scripts have been replaced by > the autoreconf tool. As for testing the minimum required tool version; > is there an actual problem being solved by this? > I forget the details but it dates back to the origins of the project, perhaps there was a problem with autoreconf back then. The autotools often blow themselves up which may be the reason for requiring a minimum. I remember a problem in libtool where it didn't work on Solaris 64-bit in something like versions 1.5.10 - 1.5.20, was fixed in 1.5.21, then broke again in 1.5.22. Lots of fun. So if you want to replace it or fix it plesae do. rob From pzuna at redhat.com Tue Jan 26 15:03:06 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 26 Jan 2010 16:03:06 +0100 Subject: [Freeipa-devel] [PATCH] jderose 034 Enable WebUI CRUDS using wehjit 0.2.0 In-Reply-To: <1264513758.5729.8.camel@jgd-dsk> References: <1264513758.5729.8.camel@jgd-dsk> Message-ID: <4B5F042A.8020205@redhat.com> Jason Gerard DeRose wrote: > This patch enables webUI Create-Retrieve-Updated-Delete-Search > operations for all api.Object plugins that: > > 1. implement all the required CRUDS methods > 2. have a primary_key > > Last night I realized that the upgrade to wehjit 0.2.0 broke the > installer, so I hurried this patch a bit, left out some niceties that > still need a bit more testing and tweaking. > Just what I needed - had to switch all my test VMs to F12, because of dependencies and was about to bug someone about the broken installer. :) Looks fine and fixes the installer, so ACK from me. Pavel From rcritten at redhat.com Tue Jan 26 15:33:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Jan 2010 10:33:50 -0500 Subject: [Freeipa-devel] [PATCH] jderose 034 Enable WebUI CRUDS using wehjit 0.2.0 In-Reply-To: <4B5F042A.8020205@redhat.com> References: <1264513758.5729.8.camel@jgd-dsk> <4B5F042A.8020205@redhat.com> Message-ID: <4B5F0B5E.70807@redhat.com> Pavel Zu*na wrote: > Jason Gerard DeRose wrote: >> This patch enables webUI Create-Retrieve-Updated-Delete-Search >> operations for all api.Object plugins that: >> >> 1. implement all the required CRUDS methods >> 2. have a primary_key >> >> Last night I realized that the upgrade to wehjit 0.2.0 broke the >> installer, so I hurried this patch a bit, left out some niceties that >> still need a bit more testing and tweaking. >> > Just what I needed - had to switch all my test VMs to F12, because of > dependencies and was about to bug someone about the broken installer. :) > > Looks fine and fixes the installer, so ACK from me. > > Pavel Works great for me too. Pushed to master. rob From rcritten at redhat.com Tue Jan 26 15:39:47 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Jan 2010 10:39:47 -0500 Subject: [Freeipa-devel] [PATCH] 354 removing bogus code In-Reply-To: <4B5EB7D5.5030900@redhat.com> References: <4B5E1797.6070803@redhat.com> <4B5EB7D5.5030900@redhat.com> Message-ID: <4B5F0CC3.4040405@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Somehow the same block of code got added twice to ipa-rmkeytab >> causing, not surprisingly, a double-free. This resolves it. >> >> rob >> > ack > > Pavel > pushed to master From rcritten at redhat.com Tue Jan 26 15:42:06 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Jan 2010 10:42:06 -0500 Subject: [Freeipa-devel] [PATCH] 344 require fully-qualified hostname in ipa-join In-Reply-To: <1264027104.3535.19.camel@wolverine.englab.brq.redhat.com> References: <4B479DC7.9060405@redhat.com> <1264027104.3535.19.camel@wolverine.englab.brq.redhat.com> Message-ID: <4B5F0D4E.1020807@redhat.com> Martin Nagy wrote: > On Fri, 2010-01-08 at 16:04 -0500, Rob Crittenden wrote: >> Require a fully-qualified hostname in ipa-join. The server side will >> enforce this as well but better to catch it early. >> >> rob > > ACK > > Martin > pushed to master From jdennis at redhat.com Tue Jan 26 22:28:31 2010 From: jdennis at redhat.com (John Dennis) Date: Tue, 26 Jan 2010 17:28:31 -0500 Subject: [Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do? Message-ID: <4B5F6C8F.7050108@redhat.com> I've run into a small problem with xgettext. By default xgettext expects all strings in an input file to be encoded in ascii. It will also allow you to override that by specifying the strings in the input file are utf-8. In ipappython/ipautil.py line 296 is the following string: SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' In it's default ascii mode xgettext throws an error claiming the string is not ascii. In fact xgettext is correct, the string is not ascii. (You may be wondering why xgettext even cares since it's not marked as translatable, but xgettext fully parses the input before deciding what is marked as translatable, bottom line: all strings get parsed and decoded). If I override the default ascii input by telling xgettext the input strings are encoded in utf-8 xgettext stops complaining, the string is properly skipped. But ... the string isn't really utf-8 either and I'm not sure how comfortable I feel about telling xgettext every string in IPA is encoded in utf-8 (when it isn't) just to get around this failure, especially since the offending string isn't even utf-8. (However, maybe we should allow utf-8 as an input format since ascii is a subset of utf-8, we might want to use utf-8 in the future and we can just hold our noses with respect to the above regular expression). Do we have a stake in the ground as to what our input strings are encoded in? Can you think of another way to express the offending string such that it doesn't trigger the non-ascii error? The only thing I could think of and get to work was this: SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) Which is pretty unreadable, but with sufficient comments could be acceptable. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Jan 26 22:46:58 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Jan 2010 17:46:58 -0500 Subject: [Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do? In-Reply-To: <4B5F6C8F.7050108@redhat.com> References: <4B5F6C8F.7050108@redhat.com> Message-ID: <4B5F70E2.5090205@redhat.com> John Dennis wrote: > I've run into a small problem with xgettext. By default xgettext > expects all strings in an input file to be encoded in ascii. It will > also allow you to override that by specifying the strings in the input > file are utf-8. > > In ipappython/ipautil.py line 296 is the following string: > > SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' > > In it's default ascii mode xgettext throws an error claiming the > string is not ascii. In fact xgettext is correct, the string is not > ascii. (You may be wondering why xgettext even cares since it's not > marked as translatable, but xgettext fully parses the input before > deciding what is marked as translatable, bottom line: all strings get > parsed and decoded). > > If I override the default ascii input by telling xgettext the input > strings are encoded in utf-8 xgettext stops complaining, the string is > properly skipped. > > But ... the string isn't really utf-8 either and I'm not sure how > comfortable I feel about telling xgettext every string in IPA is > encoded in utf-8 (when it isn't) just to get around this failure, > especially since the offending string isn't even utf-8. (However, > maybe we should allow utf-8 as an input format since ascii is a subset > of utf-8, we might want to use utf-8 in the future and we can just > hold our noses with respect to the above regular expression). > > Do we have a stake in the ground as to what our input strings are > encoded in? > > Can you think of another way to express the offending string such that > it doesn't trigger the non-ascii error? The only thing I could think > of and get to work was this: > Put a comment and add the original string in the comment. I think that would be sufficient and IMO we can use the representation below. > SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' > % \ > (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) > > > Which is pretty unreadable, but with sufficient comments could be > acceptable. > > -- 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 Tue Jan 26 22:49:51 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 26 Jan 2010 15:49:51 -0700 Subject: [Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do? In-Reply-To: <4B5F6C8F.7050108@redhat.com> References: <4B5F6C8F.7050108@redhat.com> Message-ID: <1264546191.5729.11.camel@jgd-dsk> On Tue, 2010-01-26 at 17:28 -0500, John Dennis wrote: > I've run into a small problem with xgettext. By default xgettext expects > all strings in an input file to be encoded in ascii. It will also allow > you to override that by specifying the strings in the input file are utf-8. > > In ipappython/ipautil.py line 296 is the following string: > > SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' ipapython still has a lot of legacy code, so first thing we should do is check if we even use SAFE_STRING_PATTERN. Rob, do you know off hand? > In it's default ascii mode xgettext throws an error claiming the string > is not ascii. In fact xgettext is correct, the string is not ascii. (You > may be wondering why xgettext even cares since it's not marked as > translatable, but xgettext fully parses the input before deciding what > is marked as translatable, bottom line: all strings get parsed and decoded). > > If I override the default ascii input by telling xgettext the input > strings are encoded in utf-8 xgettext stops complaining, the string is > properly skipped. > > But ... the string isn't really utf-8 either and I'm not sure how > comfortable I feel about telling xgettext every string in IPA is encoded > in utf-8 (when it isn't) just to get around this failure, especially > since the offending string isn't even utf-8. (However, maybe we should > allow utf-8 as an input format since ascii is a subset of utf-8, we > might want to use utf-8 in the future and we can just hold our noses > with respect to the above regular expression). > > Do we have a stake in the ground as to what our input strings are > encoded in? > > Can you think of another way to express the offending string such that > it doesn't trigger the non-ascii error? The only thing I could think of > and get to work was this: > > SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' > % \ > (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) > > Which is pretty unreadable, but with sufficient comments could be > acceptable. > > From hyc at symas.com Tue Jan 26 23:12:40 2010 From: hyc at symas.com (Howard Chu) Date: Tue, 26 Jan 2010 15:12:40 -0800 Subject: [Freeipa-devel] not ascii, not utf-8, what's a parser supposed to do? In-Reply-To: <4B5F6C8F.7050108@redhat.com> References: <4B5F6C8F.7050108@redhat.com> Message-ID: <4B5F76E8.5020607@symas.com> John Dennis wrote: > I've run into a small problem with xgettext. By default xgettext expects > all strings in an input file to be encoded in ascii. It will also allow > you to override that by specifying the strings in the input file are utf-8. Do you ever expect to run this stuff on IBM mainframes (i.e., systems using EBCDIC or some other non-ASCII-related character set) ? > Can you think of another way to express the offending string such that > it doesn't trigger the non-ascii error? The only thing I could think of > and get to work was this: > > SAFE_STRING_PATTERN='%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' > % \ > (40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) > > Which is pretty unreadable, but with sufficient comments could be > acceptable. I had to use similar hacks when porting OpenSSL to z/OS. It kinda sucks, but it has the virtue of being completely independent of the machine's language settings. And frankly, it doesn't take too much explanation in the comments to be understandable. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From jdennis at redhat.com Tue Jan 26 23:55:29 2010 From: jdennis at redhat.com (John Dennis) Date: Tue, 26 Jan 2010 18:55:29 -0500 Subject: [Freeipa-devel] Why do we have so much duplicated code? Message-ID: <4B5F80F1.6000909@redhat.com> I constantly find identical code spread across multiple files. Is there a reason for this code duplication? (Perhaps trying to keep import name spaces isolated?) It seems to me code duplication is bad software practice for obvious reasons. If there isn't a compelling design justification for the duplication can we start moving some of this stuff to common libraries? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Wed Jan 27 09:10:13 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 27 Jan 2010 02:10:13 -0700 Subject: [Freeipa-devel] [PATCH] jderose 035 Update spec to require python-wehjit >= 0.2.0 Message-ID: <1264583414.5729.14.camel@jgd-dsk> The webui now requires wehjit 0.2.0. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-035-update-spec.patch Type: text/x-patch Size: 898 bytes Desc: not available URL: From jderose at redhat.com Wed Jan 27 11:00:18 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 27 Jan 2010 04:00:18 -0700 Subject: [Freeipa-devel] Why do we have so much duplicated code? In-Reply-To: <4B5F80F1.6000909@redhat.com> References: <4B5F80F1.6000909@redhat.com> Message-ID: <1264590018.5729.42.camel@jgd-dsk> On Tue, 2010-01-26 at 18:55 -0500, John Dennis wrote: > I constantly find identical code spread across multiple files. Is there > a reason for this code duplication? (Perhaps trying to keep import name > spaces isolated?) > > It seems to me code duplication is bad software practice for obvious > reasons. > > If there isn't a compelling design justification for the duplication can > we start moving some of this stuff to common libraries? John, where's the duplication you're talking about? We know there's a lot of lingering duplication between the legacy code from v1 (ipapython, the installer) and the new plugable v2 code (ipalib, ipaserver). We've slowly been migrating away from this legacy code, but the process obviously isn't yet complete. AFAIK, there isn't really any duplication within the v2 code itself, but if you've spotted some, I'd like to know about it. From jderose at redhat.com Wed Jan 27 13:07:59 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 27 Jan 2010 06:07:59 -0700 Subject: [Freeipa-devel] [PATCH] jderose 036 Remove PluginProxy hold-overs Message-ID: <1264597679.14486.7.camel@jgd-dsk> This patch removes some cruft left over from when we were still using my ill-fated PluginProxy to wrap Plugin instances. This patch: 1. Removes special __public__ class attribute from Plugin and its descendants 2. Removes special __proxy__ class attribute from same 3. Removes the Plugin.implements() and Plugin.implemented_by() methods 4. Updates unit-tests where they expected any of the above None of these features were being used except by the unit-tests, so this should be a very safe change. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-036-remove-proxy-hold-overs.patch Type: text/x-patch Size: 14418 bytes Desc: not available URL: From jderose at redhat.com Wed Jan 27 14:25:40 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 27 Jan 2010 07:25:40 -0700 Subject: [Freeipa-devel] [PATCH] jderose 037 Fix broken unit tests Message-ID: <1264602340.14486.38.camel@jgd-dsk> This patch gets (almost) all the XML-RPC tests working again under Fedora12. Some may not pass under Fedora11 due to 389 schema changes, but Fedora12 should be our primary test target at this point, IHMO. Does anyone disagree? 3 cert tests still fail, but I'm not familiar enough with the cert plugins to confidently decide whether the tests need to be updated or whether something is broken. Rob or John, could you take a look at these when you get a chance? We really need to get strict about patches with regard to tests. If a patch breaks a test, the test needs to be updated in that same patch (or if the test is correct, the code needs to be updated). If a patch introduces new functionality, it must be accompanied by tests. Rob and Pavel, I'm looking at you. If tests no passy, no acky-acky. ;) I know I've been at fault too, but I've already scolded myself off-list. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-037-fix-broken-tests.patch Type: text/x-patch Size: 10607 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 27 14:34:10 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 09:34:10 -0500 Subject: [Freeipa-devel] Why do we have so much duplicated code? In-Reply-To: <4B5F80F1.6000909@redhat.com> References: <4B5F80F1.6000909@redhat.com> Message-ID: <4B604EE2.5030702@redhat.com> John Dennis wrote: > I constantly find identical code spread across multiple files. Is there > a reason for this code duplication? (Perhaps trying to keep import name > spaces isolated?) No, we don't intentionally add duplicate code. Details would be helpful. > > It seems to me code duplication is bad software practice for obvious > reasons. > > If there isn't a compelling design justification for the duplication can > we start moving some of this stuff to common libraries? > Yes. We did a tremendous amount of code reorganization many months ago, it is possible that some of this duplication is a result of that. There may be some dead code too. We completely replaced the entire XML-RPC subsystem but we didn't do it all at once, we slowly replaced it, so unused code may still exist as a result of that transition. rob From rcritten at redhat.com Wed Jan 27 14:41:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 09:41:50 -0500 Subject: [Freeipa-devel] [PATCH] jderose 035 Update spec to require python-wehjit >= 0.2.0 In-Reply-To: <1264583414.5729.14.camel@jgd-dsk> References: <1264583414.5729.14.camel@jgd-dsk> Message-ID: <4B6050AE.7060704@redhat.com> Jason Gerard DeRose wrote: > The webui now requires wehjit 0.2.0. > ack, pushed to master From pzuna at redhat.com Wed Jan 27 16:06:06 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 27 Jan 2010 17:06:06 +0100 Subject: [Freeipa-devel] [PATCH] Fix schema loading in the ldap backend. Message-ID: <4B60646E.60805@redhat.com> Recent version of DS requires to specify the attributeTypes and objectClasses attributes explicitly when retrieving them. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-schema-loading-in-the-ldap-backend.patch Type: application/mbox Size: 942 bytes Desc: not available URL: From pzuna at redhat.com Wed Jan 27 16:53:44 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 27 Jan 2010 17:53:44 +0100 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. Message-ID: <4B606F98.6030801@redhat.com> cli.prompt_interactively now loads files before validating the parameter value. It also populates a list of already loaded files, so that cli.load_files knows when a parameter already contains the file contents. Fix #557163 Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-File-parameter-validation-when-prompting.patch Type: application/mbox Size: 3608 bytes Desc: not available URL: From jdennis at redhat.com Wed Jan 27 18:32:30 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Jan 2010 13:32:30 -0500 Subject: [Freeipa-devel] Why do we have so much duplicated code? In-Reply-To: <1264590018.5729.42.camel@jgd-dsk> References: <4B5F80F1.6000909@redhat.com> <1264590018.5729.42.camel@jgd-dsk> Message-ID: <4B6086BE.20905@redhat.com> On 01/27/2010 06:00 AM, Jason Gerard DeRose wrote: > On Tue, 2010-01-26 at 18:55 -0500, John Dennis wrote: >> I constantly find identical code spread across multiple files. Is there >> a reason for this code duplication? (Perhaps trying to keep import name >> spaces isolated?) >> >> It seems to me code duplication is bad software practice for obvious >> reasons. >> >> If there isn't a compelling design justification for the duplication can >> we start moving some of this stuff to common libraries? > > John, where's the duplication you're talking about? We know there's a > lot of lingering duplication between the legacy code from v1 (ipapython, > the installer) and the new plugable v2 code (ipalib, ipaserver). We've > slowly been migrating away from this legacy code, but the process > obviously isn't yet complete. > > AFAIK, there isn't really any duplication within the v2 code itself, but > if you've spotted some, I'd like to know about it. Well, you've helped answer one question, ipapython is deprecated, I didn't know that, what else is deprecated? Is the contents of the source tree documented somewhere so one can tell what's supposed to be imported by what, what's the target goal, etc? This isn't a complete list, just off the top of my head: Duplicate functions: client_auth_data_callback() ipapython/nsslib.py ipaserver/install/cainstance.py ipaserver/install/certs.py get_fqdn() ipalib/util.py ipaserver/install/installutils.py get_gsserror() ipapython/ipautil.py ipaserver/ipautil.py get_serial() ipalib/plugins/cert.py ipalib/plugins/service.py needs_base64() ipapython/ipautil.py ipaserver/ipautil.py openLocked() contrib/RHEL4/ipachangeconf.py ipa-client/ipaclient/ipachangeconf.py realm_to_suffix() ipalib/util.py ipapython/ipautil.py ipaserver/ipautil.py unwrap_binary_data() ipapython/ipautil.py ipaserver/ipautil.py utf8_encode_value() ipapython/entity.py ipaserver/ipautil.py utf8_encode_values() ipapython/entity.py ipaserver/ipautil.py validate_host() ipalib/plugins/host.py ipaserver/plugins/join.py wrap_binary_data() ipapython/ipautil.py ipaserver/ipautil.py Duplicate Classes: class CIDict ipapython/ipautil.py ipaserver/ipautil.py class IPAChangeConf contrib/RHEL4/ipachangeconf.py ipa-client/ipaclient/ipachangeconf.py class SSLFile ipalib/rpc.py ipapython/ipasslfile.py ipapython/nsslib.py Logic for HTTP requests duplicated in: nsslib.py rpc.py cainstance.py ipapython/dogtag.py plugins/dogtag.py certs.py -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jan 27 19:53:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 14:53:54 -0500 Subject: [Freeipa-devel] [PATCH] 355 allow named to use ldapi Message-ID: <4B6099D2.7080205@redhat.com> Add SELinux rules so named can communicate to the DS over ldapi. This should fix the installation error when --setup-dns is set and SELinux is enforcing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-355-named.patch Type: application/mbox Size: 1289 bytes Desc: not available URL: From jdennis at redhat.com Wed Jan 27 20:30:44 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Jan 2010 15:30:44 -0500 Subject: [Freeipa-devel] what's deprecated & what's in use in our tree? Message-ID: <4B60A274.8050500@redhat.com> When you check out an IPA tree apparently you get the kitchen sink. I need to figure out what is deprecated in the tree and what is supposed to be "in use installed code". According to Jason everything under ipapython is deprecated right? Is everything under ipaserver/install deprecated too? Is everything under ipaclient deprecated too? Working on the assumption nothing should be importing from ipapython I did a little search. Under ipaserver the only imports for ipapython are in the ipaserver/install directory, which is o.k. because install is deprecated. EXCEPT for ipaserver/plugins/dogtag.py which imports nsslib from ipapython. We seem to have some problems with ipalib importing from ipapython: rpc.py: from ipapython import ipautil rpc.py: from ipapython.ipasslfile import SSLFile rpc.py: from ipapython.ipasslfile import FakeSocket ./plugins/cert.py: from ipapython import dnsclient ./rpc.py: from ipapython import ipautil ./rpc.py: from ipapython.ipasslfile import SSLFile ./rpc.py: from ipapython.ipasslfile import FakeSocket We seem to have some problems with ipaclient importing from ipapython but since ipaclient is deprecated (right?) that's not a problem, right? If ipapython and ipaclient are deprecated why are we still building the ipa-python and ipa-client rpms? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jan 27 20:35:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 15:35:59 -0500 Subject: [Freeipa-devel] [PATCH] 356 update dogtag configuration to work with NSS CVE-2009-3555 fixes Message-ID: <4B60A3AF.8060005@redhat.com> NSS is going to disallow all SSL renegotiation by default. Because of this we need to always use the agent port of the dogtag server which always requires SSL client authentication. The end user port will prompt for a certificate if required but will attempt to re-do the handshake to make this happen which will fail with newer versions of NSS. This fixed version of NSS is currently in Fedora updates-testing but this patch should work with either release. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-356-dogtag.patch Type: application/mbox Size: 4296 bytes Desc: not available URL: From rcritten at redhat.com Wed Jan 27 20:46:27 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 15:46:27 -0500 Subject: [Freeipa-devel] what's deprecated & what's in use in our tree? In-Reply-To: <4B60A274.8050500@redhat.com> References: <4B60A274.8050500@redhat.com> Message-ID: <4B60A623.1060509@redhat.com> John Dennis wrote: > When you check out an IPA tree apparently you get the kitchen sink. I > need to figure out what is deprecated in the tree and what is supposed > to be "in use installed code". The only code that is really deprecated is the radius work you did for v1. It was carried along into the v2 tree to serve as a starting point in case anyone wanted to try to re-add radius support. There is also some code from the old XML-RPC server that seems to be left over. This is, for example, why there are two SSLFile classes. One is for OpenSSL, the other for python-nss. Newer versions of httplib changed enough that made it necessary to pull SSLFile into our tree from older versions because we need to override certain pieces so we can stick in our authorization headers IIRC. A lot of this was written prior to python-nss and may be a candidate for being rewritten/removed. Additional code such as the CIDict and ipaldap are the legacy LDAP code that Pavel is working to replace. We significantly restructed the code at some point and this is explains the one-for-one duplication, some files were simply not removed. > According to Jason everything under ipapython is deprecated right? No. > > Is everything under ipaserver/install deprecated too? No. This is the server installer code. > > Is everything under ipaclient deprecated too? No. This is the client installer. > > Working on the assumption nothing should be importing from ipapython I > did a little search. > > Under ipaserver the only imports for ipapython are in the > ipaserver/install directory, which is o.k. because install is deprecated. No, this is where we put common code that is not part of the framework. > > EXCEPT for ipaserver/plugins/dogtag.py which imports nsslib from ipapython. ipapython is sort of common client/server code that lives outside the management framework that Jason did (ipalib). > > We seem to have some problems with ipalib importing from ipapython: > > rpc.py: from ipapython import ipautil > rpc.py: from ipapython.ipasslfile import SSLFile > rpc.py: from ipapython.ipasslfile import FakeSocket > ./plugins/cert.py: from ipapython import dnsclient > ./rpc.py: from ipapython import ipautil > ./rpc.py: from ipapython.ipasslfile import SSLFile > ./rpc.py: from ipapython.ipasslfile import FakeSocket > > We seem to have some problems with ipaclient importing from ipapython > but since ipaclient is deprecated (right?) that's not a problem, right? > > If ipapython and ipaclient are deprecated why are we still building the > ipa-python and ipa-client rpms? > Because they aren't deprecated. rob From jdennis at redhat.com Wed Jan 27 20:48:50 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Jan 2010 15:48:50 -0500 Subject: [Freeipa-devel] [PATCH] 356 update dogtag configuration to work with NSS CVE-2009-3555 fixes In-Reply-To: <4B60A3AF.8060005@redhat.com> References: <4B60A3AF.8060005@redhat.com> Message-ID: <4B60A6B2.9000304@redhat.com> On 01/27/2010 03:35 PM, Rob Crittenden wrote: > NSS is going to disallow all SSL renegotiation by default. Because of > this we need to always use the agent port of the dogtag server which > always requires SSL client authentication. The end user port will prompt > for a certificate if required but will attempt to re-do the handshake to > make this happen which will fail with newer versions of NSS. > > This fixed version of NSS is currently in Fedora updates-testing but > this patch should work with either release. ACK -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Wed Jan 27 21:05:50 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Jan 2010 16:05:50 -0500 Subject: [Freeipa-devel] what's deprecated & what's in use in our tree? In-Reply-To: <4B60A623.1060509@redhat.com> References: <4B60A274.8050500@redhat.com> <4B60A623.1060509@redhat.com> Message-ID: <4B60AAAE.6030600@redhat.com> Thanks Rob, a couple more questions: >> According to Jason everything under ipapython is deprecated right? > > No. >> >> Is everything under ipaserver/install deprecated too? > > No. This is the server installer code. Earlier today Jason said this: "the legacy code from v1 (ipapython, the installer) and the new plugable v2 code (ipalib, ipaserver)" Then what did Jason mean when he used the term "legacy"? I took that to mean deprecated, or did he mean it's just older vintage? >> Under ipaserver the only imports for ipapython are in the >> ipaserver/install directory, which is o.k. because install is deprecated. > > No, this is where we put common code that is not part of the framework. > > ipapython is sort of common client/server code that lives outside the > management framework that Jason did (ipalib). O.K. I'm still confused :-) Above you state ipaserver/install *and* ipapython is where common code outside the framework belongs. Is there a fine distinction being drawn between the two import areas such that they can't live together? Can you define the term "framework"? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jan 27 21:25:07 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 16:25:07 -0500 Subject: [Freeipa-devel] [PATCH] Fix schema loading in the ldap backend. In-Reply-To: <4B60646E.60805@redhat.com> References: <4B60646E.60805@redhat.com> Message-ID: <4B60AF33.7080100@redhat.com> Pavel Zuna wrote: > Recent version of DS requires to specify the attributeTypes and > objectClasses attributes explicitly when retrieving them. > > Pavel ack, pushed to master It would be nice if there were a way for the server to blow up if no schema was available but this is working for me for now. rob From rcritten at redhat.com Wed Jan 27 22:01:40 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 17:01:40 -0500 Subject: [Freeipa-devel] [PATCH] 356 update dogtag configuration to work with NSS CVE-2009-3555 fixes In-Reply-To: <4B60A6B2.9000304@redhat.com> References: <4B60A3AF.8060005@redhat.com> <4B60A6B2.9000304@redhat.com> Message-ID: <4B60B7C4.50203@redhat.com> John Dennis wrote: > On 01/27/2010 03:35 PM, Rob Crittenden wrote: >> NSS is going to disallow all SSL renegotiation by default. Because of >> this we need to always use the agent port of the dogtag server which >> always requires SSL client authentication. The end user port will prompt >> for a certificate if required but will attempt to re-do the handshake to >> make this happen which will fail with newer versions of NSS. >> >> This fixed version of NSS is currently in Fedora updates-testing but >> this patch should work with either release. > > ACK > pushed to master From rcritten at redhat.com Wed Jan 27 22:06:31 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 17:06:31 -0500 Subject: [Freeipa-devel] what's deprecated & what's in use in our tree? In-Reply-To: <4B60AAAE.6030600@redhat.com> References: <4B60A274.8050500@redhat.com> <4B60A623.1060509@redhat.com> <4B60AAAE.6030600@redhat.com> Message-ID: <4B60B8E7.2010901@redhat.com> John Dennis wrote: > Thanks Rob, a couple more questions: > >>> According to Jason everything under ipapython is deprecated right? >> >> No. >>> >>> Is everything under ipaserver/install deprecated too? >> >> No. This is the server installer code. > > > Earlier today Jason said this: > > "the legacy code from v1 (ipapython, the installer) and the new plugable > v2 code (ipalib, ipaserver)" > > Then what did Jason mean when he used the term "legacy"? I took that to > mean deprecated, or did he mean it's just older vintage? I think he meant "from v1". Huge gobs of code was completely dropped when we transitioned. >>> Under ipaserver the only imports for ipapython are in the >>> ipaserver/install directory, which is o.k. because install is >>> deprecated. >> >> No, this is where we put common code that is not part of the framework. >> >> ipapython is sort of common client/server code that lives outside the >> management framework that Jason did (ipalib). > > O.K. I'm still confused :-) Above you state ipaserver/install *and* > ipapython is where common code outside the framework belongs. Is there a > fine distinction being drawn between the two import areas such that they > can't live together? No ipaserver/install is the server installer, ipapython is the client/server/installer common code. > Can you define the term "framework"? It basically equates to the client/server model for the plugin system. It supports JSON and XML-RPC (though the later is what we mostly use). The core of this is in ipalib. Plugins shared between the client and server are in ipalib/plugins. Things that are server-specific are found in ipaserver. ipaserver/install is used only during installation. rob From rcritten at redhat.com Wed Jan 27 22:27:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 17:27:50 -0500 Subject: [Freeipa-devel] [PATCH] 357 ipa-server-install man updates Message-ID: <4B60BDE6.8050206@redhat.com> Bring ipa-server-install man page up-to-date, fix some syntax errors: Remove a bunch of trailing spaces Add the --ca option Add the --no-host-dns option Add the --subject option Fix the one-character option for --no-ntp, should be -N not -n Add missing line break between --no-ntp and --uninstall rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-357-man.patch Type: application/mbox Size: 4728 bytes Desc: not available URL: From jdennis at redhat.com Thu Jan 28 02:54:33 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 27 Jan 2010 21:54:33 -0500 Subject: [Freeipa-devel] [PATCH] convert SAFE_STRING_PATTERN from string to integer sequence to prevent xgettext from aborting when it sees a non-ascii string Message-ID: <1264647273-2527-1-git-send-email-jdennis@redhat.com> --- ipapython/ipautil.py | 16 +++++++++++++++- ipaserver/ipautil.py | 16 +++++++++++++++- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py index 1399c70..3768fa0 100644 --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -293,7 +293,21 @@ class CIDict(dict): # It was extracted because ipaldap.py is naughtily reaching into the ldif # module and squashing this regexp. # -SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' +# This is the original definition of SAFE_STRING_PATTERN +# SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' +# +# But the regular expression string is neither ASCII nor UTF-8 +# which causes xgettext to fail because xgettext expects all strings it +# finds in a file to be either ASCII or UTF-8. To prevent xgettext from +# aborting when it sees this string we build it from integers using this code: +# +# print "SAFE_STRING_PATTERN = \\\n'%s' %% \\\n(%s)" % \ +# ("%c" * len(SAFE_STRING_PATTERN), +# ",".join(["%d" % ord(c) for c in SAFE_STRING_PATTERN])) + +SAFE_STRING_PATTERN = \ +'%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ +(40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) safe_string_re = re.compile(SAFE_STRING_PATTERN) def needs_base64(s): diff --git a/ipaserver/ipautil.py b/ipaserver/ipautil.py index 7042c1c..968d392 100644 --- a/ipaserver/ipautil.py +++ b/ipaserver/ipautil.py @@ -125,7 +125,21 @@ class CIDict(dict): # It was extracted because ipaldap.py is naughtily reaching into the ldif # module and squashing this regexp. # -SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' +# This is the original definition of SAFE_STRING_PATTERN +# SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' +# +# But the regular expression string is neither ASCII nor UTF-8 +# which causes xgettext to fail because xgettext expects all strings it +# finds in a file to be either ASCII or UTF-8. To prevent xgettext from +# aborting when it sees this string we build it from integers using this code: +# +# print "SAFE_STRING_PATTERN = \\\n'%s' %% \\\n(%s)" % \ +# ("%c" * len(SAFE_STRING_PATTERN), +# ",".join(["%d" % ord(c) for c in SAFE_STRING_PATTERN])) + +SAFE_STRING_PATTERN = \ +'%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ +(40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) safe_string_re = re.compile(SAFE_STRING_PATTERN) def needs_base64(s): -- 1.6.6 From rcritten at redhat.com Thu Jan 28 03:30:07 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Jan 2010 22:30:07 -0500 Subject: [Freeipa-devel] [PATCH] convert SAFE_STRING_PATTERN from string to integer sequence to prevent xgettext from aborting when it sees a non-ascii string In-Reply-To: <1264647273-2527-1-git-send-email-jdennis@redhat.com> References: <1264647273-2527-1-git-send-email-jdennis@redhat.com> Message-ID: <4B6104BF.4070103@redhat.com> John Dennis wrote: > --- > ipapython/ipautil.py | 16 +++++++++++++++- > ipaserver/ipautil.py | 16 +++++++++++++++- > 2 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py > index 1399c70..3768fa0 100644 > --- a/ipapython/ipautil.py > +++ b/ipapython/ipautil.py > @@ -293,7 +293,21 @@ class CIDict(dict): > # It was extracted because ipaldap.py is naughtily reaching into the ldif > # module and squashing this regexp. > # > -SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' > +# This is the original definition of SAFE_STRING_PATTERN > +# SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' > +# > +# But the regular expression string is neither ASCII nor UTF-8 > +# which causes xgettext to fail because xgettext expects all strings it > +# finds in a file to be either ASCII or UTF-8. To prevent xgettext from > +# aborting when it sees this string we build it from integers using this code: > +# > +# print "SAFE_STRING_PATTERN = \\\n'%s' %% \\\n(%s)" % \ > +# ("%c" * len(SAFE_STRING_PATTERN), > +# ",".join(["%d" % ord(c) for c in SAFE_STRING_PATTERN])) > + > +SAFE_STRING_PATTERN = \ > +'%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ > +(40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) > safe_string_re = re.compile(SAFE_STRING_PATTERN) > > def needs_base64(s): > diff --git a/ipaserver/ipautil.py b/ipaserver/ipautil.py > index 7042c1c..968d392 100644 > --- a/ipaserver/ipautil.py > +++ b/ipaserver/ipautil.py > @@ -125,7 +125,21 @@ class CIDict(dict): > # It was extracted because ipaldap.py is naughtily reaching into the ldif > # module and squashing this regexp. > # > -SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' > +# This is the original definition of SAFE_STRING_PATTERN > +# SAFE_STRING_PATTERN = '(^(\000|\n|\r| |:|<)|[\000\n\r\200-\377]+|[ ]+$)' > +# > +# But the regular expression string is neither ASCII nor UTF-8 > +# which causes xgettext to fail because xgettext expects all strings it > +# finds in a file to be either ASCII or UTF-8. To prevent xgettext from > +# aborting when it sees this string we build it from integers using this code: > +# > +# print "SAFE_STRING_PATTERN = \\\n'%s' %% \\\n(%s)" % \ > +# ("%c" * len(SAFE_STRING_PATTERN), > +# ",".join(["%d" % ord(c) for c in SAFE_STRING_PATTERN])) > + > +SAFE_STRING_PATTERN = \ > +'%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c' % \ > +(40,94,40,0,124,10,124,13,124,32,124,58,124,60,41,124,91,0,10,13,128,45,255,93,43,124,91,32,93,43,36,41) > safe_string_re = re.compile(SAFE_STRING_PATTERN) > > def needs_base64(s): Is this code used by anything any more? This was part of the old XML-RPC server. It was used to determine whether a data type needed to be the XML-RPC Binary type or not. In v2 Jason wrote a similar function that bases the output type based on the python type (strings are unicode, binary data is str). So I think this can just be dropped (after testing to confirm, of course). rob From jdennis at redhat.com Thu Jan 28 14:18:49 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 09:18:49 -0500 Subject: [Freeipa-devel] [PATCH] convert SAFE_STRING_PATTERN (was: Why do we have so much duplicated code?) In-Reply-To: <4B6104BF.4070103@redhat.com> References: <1264647273-2527-1-git-send-email-jdennis@redhat.com> <4B6104BF.4070103@redhat.com> Message-ID: <4B619CC9.7080503@redhat.com> On 01/27/2010 10:30 PM, Rob Crittenden wrote: > Is this code used by anything any more? This was part of the old XML-RPC > server. It was used to determine whether a data type needed to be the > XML-RPC Binary type or not. In v2 Jason wrote a similar function that > bases the output type based on the python type (strings are unicode, > binary data is str). > > So I think this can just be dropped (after testing to confirm, of course). That's a great question. In fact this was one of the things which caused me to spend time yesterday trying to figure out what's actually in use, it's also an example of code that is duplicated identically in two places. I don't think it's in use at all. I believe the functionality in ipapython/ipautil.py and ipaserver/ipautil.py has been superseded by xml_wrap and xml_unwrap in ipalib/rpc.py. My vote would be to remove the code and I'll supply a patch which does. FWIW SAFE_STRING_PATTERN can't exist in it's current form or I can't submit my next patch for i18n support because the string causes xgettext to abort. It would be nice if we cleaned some of this legacy cruft out of the source tree. Having not been involved in the code base continuously it makes it confusing to figure out how pieces of the code fit together when code isn't used and/or is defined in multiple places. P.S.: sorry about about the format of the patch I submitted. I was playing around with git send-email and it didn't work quite the way I expected :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Thu Jan 28 17:35:09 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 12:35:09 -0500 Subject: [Freeipa-devel] [PATCH] Remove (un)wrap_binary_data cruft from */ipautil.py Message-ID: <1264700109-20661-1-git-send-email-jdennis@redhat.com> Remove SAFE_STRING_PATTERN, safe_string_re, needs_base64(), wrap_binary_data(), unwrap_binary_data() from both instances of ipautil.py. This code is no longer in use and the SAFE_STRING_PATTERN regular expression string was causing xgettext to abort because it wasn't a valid ASCII string. --- ipapython/ipautil.py | 62 -------------------------------------------------- ipaserver/ipautil.py | 62 -------------------------------------------------- 2 files changed, 0 insertions(+), 124 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-un-wrap_binary_data-cruft-from-ipautil.py.patch Type: text/x-patch Size: 4689 bytes Desc: not available URL: From jdennis at redhat.com Thu Jan 28 17:57:00 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 12:57:00 -0500 Subject: [Freeipa-devel] [PATCH] fix error message to be i18n translator friendly Message-ID: <1264701420-21093-1-git-send-email-jdennis@redhat.com> This error message was producing a warning from xgettext because there were multiple substations in the string. In some languages it may be necessary to reorder the substitutions for a proper translation, this is only possible if the substitutions use named values. --- ipaserver/plugins/selfsign.py | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-error-message-to-be-i18n-translator-friendly.patch Type: text/x-patch Size: 952 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 28 18:32:15 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 13:32:15 -0500 Subject: [Freeipa-devel] [PATCH] jderose 036 Remove PluginProxy hold-overs In-Reply-To: <1264597679.14486.7.camel@jgd-dsk> References: <1264597679.14486.7.camel@jgd-dsk> Message-ID: <4B61D82F.4090008@redhat.com> Jason Gerard DeRose wrote: > This patch removes some cruft left over from when we were still using my > ill-fated PluginProxy to wrap Plugin instances. This patch: > > 1. Removes special __public__ class attribute from Plugin and its > descendants > > 2. Removes special __proxy__ class attribute from same > > 3. Removes the Plugin.implements() and Plugin.implemented_by() > methods > > 4. Updates unit-tests where they expected any of the above > > None of these features were being used except by the unit-tests, so this > should be a very safe change. ack, pushed to master rob From rcritten at redhat.com Thu Jan 28 19:24:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 14:24:52 -0500 Subject: [Freeipa-devel] [PATCH] 358 remove files on uninstall Message-ID: <4B61E484.9080900@redhat.com> Remove some IPA configuration files when doing an uninstallation. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-358-remove.patch Type: application/mbox Size: 2060 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 28 19:27:00 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 14:27:00 -0500 Subject: [Freeipa-devel] [PATCH] Remove (un)wrap_binary_data cruft from */ipautil.py In-Reply-To: <1264700109-20661-1-git-send-email-jdennis@redhat.com> References: <1264700109-20661-1-git-send-email-jdennis@redhat.com> Message-ID: <4B61E504.2030807@redhat.com> John Dennis wrote: > Remove SAFE_STRING_PATTERN, safe_string_re, needs_base64(), > wrap_binary_data(), unwrap_binary_data() from both instances > of ipautil.py. This code is no longer in use and the > SAFE_STRING_PATTERN regular expression string was causing xgettext > to abort because it wasn't a valid ASCII string. > --- > ipapython/ipautil.py | 62 -------------------------------------------------- > ipaserver/ipautil.py | 62 -------------------------------------------------- > 2 files changed, 0 insertions(+), 124 deletions(-) > > > > ack, pushed to master rob From rcritten at redhat.com Thu Jan 28 21:13:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 16:13:50 -0500 Subject: [Freeipa-devel] [PATCH] 359 be smarter about decoding certs Message-ID: <4B61FE0E.5000501@redhat.com> Be a bit smarter about decoding certificates that might be base64 encoded. First see if it only contains those characters allowed before trying to decode it. This reduces the number of false positives. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-359-cert.patch Type: application/mbox Size: 2862 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 28 21:15:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 16:15:21 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs Message-ID: <4B61FE69.9060107@redhat.com> Gah, got the description mixed up with the last patch :-( Be a bit smarter about decoding certificates that might be base64 encoded. First see if it only contains those characters allowed before trying to decode it. This reduces the number of false positives. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-360-service.patch Type: application/mbox Size: 1699 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 28 21:16:39 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 16:16:39 -0500 Subject: [Freeipa-devel] [PATCH] 359 allow cert renewal In-Reply-To: <4B61FE0E.5000501@redhat.com> References: <4B61FE0E.5000501@redhat.com> Message-ID: <4B61FEB7.80001@redhat.com> Rob Crittenden wrote: > Be a bit smarter about decoding certificates that might be base64 > encoded. First see if it only contains those characters allowed before > trying to decode it. This reduces the number of false positives. > > rob Er, duh, I got this description goofed up. This patch is related to certificate renewal/issuing a new certificate for a service that already has one. We used to reject inserting a new certificate altogether. This patch adds a new flag, --renew, that lets you replace a certificate. The existing certificate is revoked. rob From rcritten at redhat.com Thu Jan 28 21:18:29 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 16:18:29 -0500 Subject: [Freeipa-devel] [PATCH] 361 fix cert tests Message-ID: <4B61FF25.2070507@redhat.com> This fixes some problems with the cert plugin tests. - It checks to see if a self-signed CA is available in ~/.ipa/alias. If not the tests are skipped - Be a bit smarter about cleaning up by moving it to a separate test - This relies on patch the service fix in 360. Some binary certs were being decoded as base64 resulting in an unparsable cert for the ASN.1 parser. I also added a bit of documentation on how to set up the self-signed CA. It is a one-time thing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-361-tests.patch Type: application/mbox Size: 3902 bytes Desc: not available URL: From jdennis at redhat.com Thu Jan 28 21:33:05 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 16:33:05 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B61FE69.9060107@redhat.com> References: <4B61FE69.9060107@redhat.com> Message-ID: <4B620291.2010901@redhat.com> On 01/28/2010 04:15 PM, Rob Crittenden wrote: > Gah, got the description mixed up with the last patch :-( > > Be a bit smarter about decoding certificates that might be base64 > encoded. First see if it only contains those characters allowed before > trying to decode it. This reduces the number of false positives. I'm not sure the test is doing what you want or even if it's the right test. The test is saying "If there is one or more characters in the bas64 alphabet then try and decode. That means just about anything will match, which doesn't seem like a very strong test. Why not just try and decode it and let the decoder decide if it's really base64, the decoder has much strong rules about the input, including assuring the padding is correct. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Thu Jan 28 21:35:21 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 16:35:21 -0500 Subject: [Freeipa-devel] [PATCH] 359 allow cert renewal In-Reply-To: <4B61FEB7.80001@redhat.com> References: <4B61FE0E.5000501@redhat.com> <4B61FEB7.80001@redhat.com> Message-ID: <4B620319.6050209@redhat.com> On 01/28/2010 04:16 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Be a bit smarter about decoding certificates that might be base64 >> encoded. First see if it only contains those characters allowed before >> trying to decode it. This reduces the number of false positives. >> >> rob > > > Er, duh, I got this description goofed up. ACK to the correct patch -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Jan 28 22:22:20 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 17:22:20 -0500 Subject: [Freeipa-devel] [PATCH] 362 remove group pwd policy on group deletion Message-ID: <4B620E1C.8080401@redhat.com> Try to remove a group password policy when a group is deleted. No need to leave that hanging around. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-362-group.patch Type: application/mbox Size: 828 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 28 22:26:10 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 17:26:10 -0500 Subject: [Freeipa-devel] [PATCH 363 find all group pwd policy Message-ID: <4B620F02.4090908@redhat.com> Provide pwpolicy-find command to display all group-specific password policies. find is a bit of a misnomer since you can't provide any terms to limit the search scope, but it's a start. I'm not sure this is the kind of thing we need/want to be able to query things like "give me all the policies where the max lifetime is > 20 days". But I could be wrong. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-363-pwpolicy.patch Type: application/mbox Size: 1805 bytes Desc: not available URL: From jderose at redhat.com Thu Jan 28 23:56:09 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 28 Jan 2010 16:56:09 -0700 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <4B606F98.6030801@redhat.com> References: <4B606F98.6030801@redhat.com> Message-ID: <1264722969.20071.2.camel@jgd-dsk> On Wed, 2010-01-27 at 17:53 +0100, Pavel Zuna wrote: > cli.prompt_interactively now loads files before validating the parameter value. > It also populates a list of already loaded files, so that cli.load_files knows > when a parameter already contains the file contents. > > Fix #557163 > > Pavel ack. This looks reasonable to me, but I'd really like you to add some tests for this, especially testing that it works correctly for a command with multiple File params. Rob and John, do you see any problems with this approach? Does this address the needs of the cert plugins? From jdennis at redhat.com Fri Jan 29 00:40:58 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 19:40:58 -0500 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <1264722969.20071.2.camel@jgd-dsk> References: <4B606F98.6030801@redhat.com> <1264722969.20071.2.camel@jgd-dsk> Message-ID: <4B622E9A.2070504@redhat.com> On 01/28/2010 06:56 PM, Jason Gerard DeRose wrote: > On Wed, 2010-01-27 at 17:53 +0100, Pavel Zuna wrote: >> cli.prompt_interactively now loads files before validating the parameter value. >> It also populates a list of already loaded files, so that cli.load_files knows >> when a parameter already contains the file contents. >> >> Fix #557163 >> >> Pavel > > ack. > > This looks reasonable to me, but I'd really like you to add some tests > for this, especially testing that it works correctly for a command with > multiple File params. > > Rob and John, do you see any problems with this approach? Does this > address the needs of the cert plugins? nck Maybe I'm reading the code wrong but it seems like there are cases where the already_loaded_files list is not updated. If load_files() is called then the file is loaded but already_loaded_files is not updated to reflect that. Shouldn't the function load_file() update the already_loaded_files list to assure already_loaded_files is always in sync? Also, wouldn't already_loaded_files be better implemented as a set rather than a list? Aside from the above state consistency issue I think it fixes the problem, but I'll be honest I'm not in love with it because it's kind of a hack to get around deficiencies in the command parameter framework. I always get nervous when I see special case exceptions surgically inserted into select pieces of code rather than conforming to a regular and consistent framework. Also this only works because the cli object is short lived and single use. If that assumption is ever violated the persistent state in the object will present a consistency problem. Bottom line, I'll ack it if the first issue is resolved or Pavel explains why load_files() can't produce an inconsistent state. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Jan 29 03:00:04 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Jan 2010 22:00:04 -0500 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <4B622E9A.2070504@redhat.com> References: <4B606F98.6030801@redhat.com> <1264722969.20071.2.camel@jgd-dsk> <4B622E9A.2070504@redhat.com> Message-ID: <4B624F34.5040608@redhat.com> I've been thinking about this a bit more. I wonder if part of the inelegance is due to the fact we're trying to shoehorn two distinct concepts into one item when a proper relationship does not exist. It does not seem logical that a file is a subclass of a string which is how this is set up now. Files simply do not derive from strings, they are two entirely distinct concepts. Consider any typical command line program you're familiar with. You might pass string data as an argument or it might be read from stdin. But if you want that command to read from a file you have to pass it a different argument specifying the filename to open. Take the case of sed for example. If you pass a script on the command line you use the -e arg, however, if you want to pass the script as a file you use the -f arg. They aren't the same at the point of invocation, internally the program maps one to the other. Maybe that's why the proposed mechanism is awkward, we're trying to conflate one concept with another. Perhaps there should be distinct arguments available for the user to the use, one arg passes a string, a different arg passes a filename. The filename parameter opens the file, reads the content and then assigns the value to the appropriate keyword parameter. For the file arg you would have: kw[param.alias] = value instead of: kw[param.name] = value where param.alias is the name of the "destination" parameter associated with an alternative arg for supplying the same value. In this scheme the you don't need to keep state, you don't need to special case any code, you can use the existing normalize and validate mechanisms. Thoughts? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Jan 29 03:30:13 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Jan 2010 22:30:13 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B620291.2010901@redhat.com> References: <4B61FE69.9060107@redhat.com> <4B620291.2010901@redhat.com> Message-ID: <4B625645.2020004@redhat.com> John Dennis wrote: > On 01/28/2010 04:15 PM, Rob Crittenden wrote: >> Gah, got the description mixed up with the last patch :-( >> >> Be a bit smarter about decoding certificates that might be base64 >> encoded. First see if it only contains those characters allowed before >> trying to decode it. This reduces the number of false positives. > > I'm not sure the test is doing what you want or even if it's the right > test. > > The test is saying "If there is one or more characters in the bas64 > alphabet then try and decode. That means just about anything will match, > which doesn't seem like a very strong test. > > Why not just try and decode it and let the decoder decide if it's really > base64, the decoder has much strong rules about the input, including > assuring the padding is correct. > The reason is I had a binary cert that was correctly decoded by the base64 encoder. I don't know the why's and wherefores but there it is. I see what you mean about my regex being a bit weak though, it really should require that the entire string conform. I'll see what I can do. rob From jderose at redhat.com Fri Jan 29 04:27:43 2010 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 28 Jan 2010 21:27:43 -0700 Subject: [Freeipa-devel] [PATCH] 355 allow named to use ldapi In-Reply-To: <4B6099D2.7080205@redhat.com> References: <4B6099D2.7080205@redhat.com> Message-ID: <1264739263.20071.4.camel@jgd-dsk> On Wed, 2010-01-27 at 14:53 -0500, Rob Crittenden wrote: > Add SELinux rules so named can communicate to the DS over ldapi. > > This should fix the installation error when --setup-dns is set and > SELinux is enforcing. > > rob I'm trying to test this out, but I'm not sure what I need to enter for the DNS forwarder: """ Enter IP address for a DNS forwarder (empty to stop): """ Any advice? From jdennis at redhat.com Fri Jan 29 05:13:19 2010 From: jdennis at redhat.com (John Dennis) Date: Fri, 29 Jan 2010 00:13:19 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B625645.2020004@redhat.com> References: <4B61FE69.9060107@redhat.com> <4B620291.2010901@redhat.com> <4B625645.2020004@redhat.com> Message-ID: <4B626E6F.8070800@redhat.com> On 01/28/2010 10:30 PM, Rob Crittenden wrote: > John Dennis wrote: >> On 01/28/2010 04:15 PM, Rob Crittenden wrote: >>> Gah, got the description mixed up with the last patch :-( >>> >>> Be a bit smarter about decoding certificates that might be base64 >>> encoded. First see if it only contains those characters allowed before >>> trying to decode it. This reduces the number of false positives. >> >> I'm not sure the test is doing what you want or even if it's the right >> test. >> >> The test is saying "If there is one or more characters in the bas64 >> alphabet then try and decode. That means just about anything will >> match, which doesn't seem like a very strong test. >> >> Why not just try and decode it and let the decoder decide if it's >> really base64, the decoder has much strong rules about the input, >> including assuring the padding is correct. >> > > The reason is I had a binary cert that was correctly decoded by the > base64 encoder. I don't know the why's and wherefores but there it is. Then testing to see if each byte is in the base64 alphabet would not have prevented this error. For a while now I've been feeling like we need to associate a format attribute to the certificate (e.g. DER, PEM, BASE64, etc.). Or we need to adopt a convention that certs are always in one canonical format and the interface is responsible for assuring what it accepts as input is converted to the canonical form. > I see what you mean about my regex being a bit weak though, it really > should require that the entire string conform. I'll see what I can do. > > rob -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pzuna at redhat.com Fri Jan 29 12:20:11 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 29 Jan 2010 13:20:11 +0100 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <4B622E9A.2070504@redhat.com> References: <4B606F98.6030801@redhat.com> <1264722969.20071.2.camel@jgd-dsk> <4B622E9A.2070504@redhat.com> Message-ID: <4B62D27B.7040907@redhat.com> John Dennis wrote: > On 01/28/2010 06:56 PM, Jason Gerard DeRose wrote: >> On Wed, 2010-01-27 at 17:53 +0100, Pavel Zuna wrote: >>> cli.prompt_interactively now loads files before validating the >>> parameter value. >>> It also populates a list of already loaded files, so that >>> cli.load_files knows >>> when a parameter already contains the file contents. >>> >>> Fix #557163 >>> >>> Pavel >> >> ack. >> >> This looks reasonable to me, but I'd really like you to add some tests >> for this, especially testing that it works correctly for a command with >> multiple File params. >> >> Rob and John, do you see any problems with this approach? Does this >> address the needs of the cert plugins? > > nck > > Maybe I'm reading the code wrong but it seems like there are cases where > the already_loaded_files list is not updated. If load_files() is called > then the file is loaded but already_loaded_files is not updated to > reflect that. Shouldn't the function load_file() update the > already_loaded_files list to assure already_loaded_files is always in > sync? Also, wouldn't already_loaded_files be better implemented as a set > rather than a list? The already_loaded_files list is only updated when the file was loaded, its contents were validated and stored in kw[param.name] (this is later passed to the command being executed). It isn't updated in load_file, because this method can be called several times for each File parameter (for example when a user has really fat fingers and can't type properly :)). If we did update the list in load_file, then we would have to make already_loaded_files a set, but since we don't and we iterate over parameters in a way that guarantees that no parameter is iterated over twice, we're fine with using the list type. > Aside from the above state consistency issue I think it fixes the > problem, but I'll be honest I'm not in love with it because it's kind of > a hack to get around deficiencies in the command parameter framework. I > always get nervous when I see special case exceptions surgically > inserted into select pieces of code rather than conforming to a regular > and consistent framework. I'm not in love with it either. There's this girl at school I like and... :D Seriously, you could call it a hack, but as you said yourself in your second post at https://bugzilla.redhat.com/show_bug.cgi?id=557163: "I just don't see anyway to support the concept of File parameters using the existing parameter mechanism without a lot of special case hacks spread through the code." This "hack", while not the most elegant (I'm all about code elegance), only lives in one place, is pretty short and understandable. Also, I think the place this lives in is actually the right one. Loading files is going to be different in the webUI and CLI, so it makes sense to implement it in UI specific classes. I'll elaborate more about the command parameter framework in a response to your second email. > Also this only works because the cli object is short lived and single > use. If that assumption is ever violated the persistent state in the > object will present a consistency problem. Yes, IF. But it's never going happen unless we rewrite pretty much everything - that's just how the cli class was designed. Also, I don't know what persistent state you're talking about and how is it related to the already_loaded_files list - it is a short lived local variable. > Bottom line, I'll ack it if the first issue is resolved or Pavel > explains why load_files() can't produce an inconsistent state. > Pavel From pzuna at redhat.com Fri Jan 29 12:53:04 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 29 Jan 2010 13:53:04 +0100 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <4B624F34.5040608@redhat.com> References: <4B606F98.6030801@redhat.com> <1264722969.20071.2.camel@jgd-dsk> <4B622E9A.2070504@redhat.com> <4B624F34.5040608@redhat.com> Message-ID: <4B62DA30.4040603@redhat.com> John Dennis wrote: > I've been thinking about this a bit more. I wonder if part of the > inelegance is due to the fact we're trying to shoehorn two distinct > concepts into one item when a proper relationship does not exist. > > It does not seem logical that a file is a subclass of a string which is > how this is set up now. Files simply do not derive from strings, they > are two entirely distinct concepts. I think our parameter classes follow a different logic. They don't provide any functionality (except for calling validation/normalization routines) and are pretty much separated from the rest of the ipalib code. They *describe* the type of value a command expects to receive on the command line (or in a field in the webUI). In other words the parameter classes define syntax of what a command expects as parameters, but they don't say anything about semantics. This is why the File parameter extends the Str class - the command expects a string. Maybe we should rename it to Filename. > Consider any typical command line program you're familiar with. You > might pass string data as an argument or it might be read from stdin. > But if you want that command to read from a file you have to pass it a > different argument specifying the filename to open. > > Take the case of sed for example. If you pass a script on the command > line you use the -e arg, however, if you want to pass the script as a > file you use the -f arg. They aren't the same at the point of > invocation, internally the program maps one to the other. > > Maybe that's why the proposed mechanism is awkward, we're trying to > conflate one concept with another. Perhaps there should be distinct > arguments available for the user to the use, one arg passes a string, a > different arg passes a filename. The filename parameter opens the file, > reads the content and then assigns the value to the appropriate keyword > parameter. For the file arg you would have: > > kw[param.alias] = value > > instead of: > > kw[param.name] = value > > where param.alias is the name of the "destination" parameter associated > with an alternative arg for supplying the same value. I think there are two distinct cases for typical command line programs I know: 1) File is specified as an argument/option or contents are loaded from stdin. 2) String data are entered as an argument/option or loaded from a file specified with another argument/option. Both of them are used by sed and are doable with what we have. We don't have mutual exclusion for parameters, but it's easy to make one parameter override another one. > In this scheme the you don't need to keep state, you don't need to > special case any code, you can use the existing normalize and validate > mechanisms. The problem here is that validate/normalize can only be used on final values passed to commands. Both validate and normalize are called on the client and then again on the server. Files need to be loaded on the client, so you can't do it in a method that is shared. > Thoughts? > Pavel From pzuna at redhat.com Fri Jan 29 12:57:17 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 29 Jan 2010 13:57:17 +0100 Subject: [Freeipa-devel] [PATCH] 362 remove group pwd policy on group deletion In-Reply-To: <4B620E1C.8080401@redhat.com> References: <4B620E1C.8080401@redhat.com> Message-ID: <4B62DB2D.2010703@redhat.com> Rob Crittenden wrote: > Try to remove a group password policy when a group is deleted. No need > to leave that hanging around. > > rob > The self parameter is missing in the post_callback, it's not a static method. auto-ack when this is fixed. :) Pavel From pzuna at redhat.com Fri Jan 29 13:15:04 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 29 Jan 2010 14:15:04 +0100 Subject: [Freeipa-devel] [PATCH 363 find all group pwd policy In-Reply-To: <4B620F02.4090908@redhat.com> References: <4B620F02.4090908@redhat.com> Message-ID: <4B62DF58.3010600@redhat.com> Rob Crittenden wrote: > Provide pwpolicy-find command to display all group-specific password > policies. > > find is a bit of a misnomer since you can't provide any terms to limit > the search scope, but it's a start. I'm not sure this is the kind of > thing we need/want to be able to query things like "give me all the > policies where the max lifetime is > 20 days". But I could be wrong. > > rob > entries = tuple(e for (dn, e) in entries) for entry in xrange(len(entries)): _convert_time_for_output(entries[entry]) Should be: for e in entries: _convert_time_for_output(e[1]) e[1]['dn'] = e[0] entries = tuple(e for (dn, e) in entries) Otherwise DNs is lost in the conversion from (dn, entry_attrs) to entry_with_dn_as_dict. Also, there's no need for xrange - I'm using it myself in LDAPSearch.execute(), but that's because I overwrite elements in the entries list. (And as I think about it now, overwriting elements there is also unnecessary, so it will be removed in a future patch.) Everything else about the patch is fine. Pavel From jdennis at redhat.com Fri Jan 29 13:23:02 2010 From: jdennis at redhat.com (John Dennis) Date: Fri, 29 Jan 2010 08:23:02 -0500 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <4B62DA30.4040603@redhat.com> References: <4B606F98.6030801@redhat.com> <1264722969.20071.2.camel@jgd-dsk> <4B622E9A.2070504@redhat.com> <4B624F34.5040608@redhat.com> <4B62DA30.4040603@redhat.com> Message-ID: <4B62E136.7060400@redhat.com> On 01/29/2010 07:53 AM, Pavel Zuna wrote: > John Dennis wrote: >> In this scheme the you don't need to keep state, you don't need to >> special case any code, you can use the existing normalize and validate >> mechanisms. > The problem here is that validate/normalize can only be used on final > values passed to commands. Both validate and normalize are called on the > client and then again on the server. Files need to be loaded on the > client, so you can't do it in a method that is shared. A File Command class validates by assuring the file is readable, it's normalize reads the contents. Then it calls the matching Str command class with the data it read. The Str class validate and normalizes the string data unaware it originated from a file. On the server side it never sees the File Command parameter, only Str parameter. Think of the File Command as a temporary command parameter which generates the resulting Str parameter. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pzuna at redhat.com Fri Jan 29 13:27:26 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 29 Jan 2010 14:27:26 +0100 Subject: [Freeipa-devel] [PATCH] Fix File parameter validation when prompting. In-Reply-To: <4B62E136.7060400@redhat.com> References: <4B606F98.6030801@redhat.com> <1264722969.20071.2.camel@jgd-dsk> <4B622E9A.2070504@redhat.com> <4B624F34.5040608@redhat.com> <4B62DA30.4040603@redhat.com> <4B62E136.7060400@redhat.com> Message-ID: <4B62E23E.2030405@redhat.com> John Dennis wrote: > On 01/29/2010 07:53 AM, Pavel Zuna wrote: >> John Dennis wrote: >>> In this scheme the you don't need to keep state, you don't need to >>> special case any code, you can use the existing normalize and validate >>> mechanisms. >> The problem here is that validate/normalize can only be used on final >> values passed to commands. Both validate and normalize are called on the >> client and then again on the server. Files need to be loaded on the >> client, so you can't do it in a method that is shared. > > A File Command class validates by assuring the file is readable, it's > normalize reads the contents. Then it calls the matching Str command > class with the data it read. The Str class validate and normalizes the > string data unaware it originated from a file. On the server side it > never sees the File Command parameter, only Str parameter. Think of the > File Command as a temporary command parameter which generates the > resulting Str parameter. I think we've been through this before. It would definitely be nice, but it would require a redesign and rewrite of the parameter framework and that's probably not worth it at this point. Pavel From jgalipea at redhat.com Fri Jan 29 14:07:19 2010 From: jgalipea at redhat.com (Jenny Galipeau) Date: Fri, 29 Jan 2010 09:07:19 -0500 Subject: [Freeipa-devel] [PATCH] 355 allow named to use ldapi In-Reply-To: <1264739263.20071.4.camel@jgd-dsk> References: <4B6099D2.7080205@redhat.com> <1264739263.20071.4.camel@jgd-dsk> Message-ID: <4B62EB97.6060409@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=558984 :-) Jason Gerard DeRose wrote: > On Wed, 2010-01-27 at 14:53 -0500, Rob Crittenden wrote: > >> Add SELinux rules so named can communicate to the DS over ldapi. >> >> This should fix the installation error when --setup-dns is set and >> SELinux is enforcing. >> >> rob >> > > I'm trying to test this out, but I'm not sure what I need to enter for > the DNS forwarder: > > """ > Enter IP address for a DNS forwarder (empty to stop): > """ > > Any advice? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From rcritten at redhat.com Fri Jan 29 14:28:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 29 Jan 2010 09:28:33 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B626E6F.8070800@redhat.com> References: <4B61FE69.9060107@redhat.com> <4B620291.2010901@redhat.com> <4B625645.2020004@redhat.com> <4B626E6F.8070800@redhat.com> Message-ID: <4B62F091.7060808@redhat.com> John Dennis wrote: > On 01/28/2010 10:30 PM, Rob Crittenden wrote: >> John Dennis wrote: >>> On 01/28/2010 04:15 PM, Rob Crittenden wrote: >>>> Gah, got the description mixed up with the last patch :-( >>>> >>>> Be a bit smarter about decoding certificates that might be base64 >>>> encoded. First see if it only contains those characters allowed before >>>> trying to decode it. This reduces the number of false positives. >>> >>> I'm not sure the test is doing what you want or even if it's the right >>> test. >>> >>> The test is saying "If there is one or more characters in the bas64 >>> alphabet then try and decode. That means just about anything will >>> match, which doesn't seem like a very strong test. >>> >>> Why not just try and decode it and let the decoder decide if it's >>> really base64, the decoder has much strong rules about the input, >>> including assuring the padding is correct. >>> >> >> The reason is I had a binary cert that was correctly decoded by the >> base64 encoder. I don't know the why's and wherefores but there it is. > > Then testing to see if each byte is in the base64 alphabet would not > have prevented this error. And yet it did in practice. I think you're assuming too much about the input testing in base64.b64decode(). It gladly takes binary data, as long as it fits the expected padding. > > For a while now I've been feeling like we need to associate a format > attribute to the certificate (e.g. DER, PEM, BASE64, etc.). There is simply no good way to carry that extra data when all you have is a blob of data. We'd still need some mechanism to look at it and ask "what are you?" That or we simply reject some types of input. > Or we need to adopt a convention that certs are always in one canonical > format and the interface is responsible for assuring what it accepts as > input is converted to the canonical form. Again, something would need to do that and base64.b64decode() is not sufficient. I know this seems rather hacky, I thought as much when I coded it, just trying to make it robust. rob > >> I see what you mean about my regex being a bit weak though, it really >> should require that the entire string conform. I'll see what I can do. >> >> rob > > From rcritten at redhat.com Fri Jan 29 14:44:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 29 Jan 2010 09:44:02 -0500 Subject: [Freeipa-devel] [PATCH] 362 remove group pwd policy on group deletion In-Reply-To: <4B62DB2D.2010703@redhat.com> References: <4B620E1C.8080401@redhat.com> <4B62DB2D.2010703@redhat.com> Message-ID: <4B62F432.90407@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Try to remove a group password policy when a group is deleted. No need >> to leave that hanging around. >> >> rob >> > The self parameter is missing in the post_callback, it's not a static > method. > > auto-ack when this is fixed. :) > > Pavel Wow, great catch. Amazing that this worked at all with a bad function signature, guess I was just lucky. Fixed and pushed to master rob From rcritten at redhat.com Fri Jan 29 14:57:32 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 29 Jan 2010 09:57:32 -0500 Subject: [Freeipa-devel] [PATCH] 355 allow named to use ldapi In-Reply-To: <4B62EB97.6060409@redhat.com> References: <4B6099D2.7080205@redhat.com> <1264739263.20071.4.camel@jgd-dsk> <4B62EB97.6060409@redhat.com> Message-ID: <4B62F75C.4060003@redhat.com> Jenny Galipeau wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=558984 :-) > Jason Gerard DeRose wrote: >> On Wed, 2010-01-27 at 14:53 -0500, Rob Crittenden wrote: >> >>> Add SELinux rules so named can communicate to the DS over ldapi. >>> >>> This should fix the installation error when --setup-dns is set and >>> SELinux is enforcing. >>> >>> rob >>> >> >> I'm trying to test this out, but I'm not sure what I need to enter for >> the DNS forwarder: >> >> """ >> Enter IP address for a DNS forwarder (empty to stop): >> """ >> >> Any advice? Yeah, you probably don't need to enter anything here. David, basically with a forwarder it skips the local DNS server and instead forwards the request to the specified server(s) to do the DNS resolution work for it. You can also do per-domain forwarding but we don't supply a configuration option for that, at least during installation. I assume we could set that up post-installation. This is handy in a VPN situation. You run a local caching nameserver with DNS forwards across the VPN for your company domain(s). Everything else gets resolved using the standard public roots. rob From jdennis at redhat.com Fri Jan 29 15:06:08 2010 From: jdennis at redhat.com (John Dennis) Date: Fri, 29 Jan 2010 10:06:08 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B62F091.7060808@redhat.com> References: <4B61FE69.9060107@redhat.com> <4B620291.2010901@redhat.com> <4B625645.2020004@redhat.com> <4B626E6F.8070800@redhat.com> <4B62F091.7060808@redhat.com> Message-ID: <4B62F960.1080004@redhat.com> On 01/29/2010 09:28 AM, Rob Crittenden wrote: > John Dennis wrote: >> On 01/28/2010 10:30 PM, Rob Crittenden wrote: >>> John Dennis wrote: >>>> On 01/28/2010 04:15 PM, Rob Crittenden wrote: >>>>> Gah, got the description mixed up with the last patch :-( >>>>> >>>>> Be a bit smarter about decoding certificates that might be base64 >>>>> encoded. First see if it only contains those characters allowed before >>>>> trying to decode it. This reduces the number of false positives. >>>> >>>> I'm not sure the test is doing what you want or even if it's the right >>>> test. >>>> >>>> The test is saying "If there is one or more characters in the bas64 >>>> alphabet then try and decode. That means just about anything will >>>> match, which doesn't seem like a very strong test. >>>> >>>> Why not just try and decode it and let the decoder decide if it's >>>> really base64, the decoder has much strong rules about the input, >>>> including assuring the padding is correct. >>>> >>> >>> The reason is I had a binary cert that was correctly decoded by the >>> base64 encoder. I don't know the why's and wherefores but there it is. >> >> Then testing to see if each byte is in the base64 alphabet would not >> have prevented this error. > > And yet it did in practice. I think you're assuming too much about the > input testing in base64.b64decode(). It gladly takes binary data, as > long as it fits the expected padding. You're right, I just went and checked the code, it skips any char not in the base64 alphabet :-( >> >> For a while now I've been feeling like we need to associate a format >> attribute to the certificate (e.g. DER, PEM, BASE64, etc.). > > There is simply no good way to carry that extra data when all you have > is a blob of data. We'd still need some mechanism to look at it and ask > "what are you?" That or we simply reject some types of input. My concern is that correctly deducing what an object is just by scanning it's contents is not robust. As you've seen it's easy to draw the wrong conclusion. Rather if the convention is "it must be an object in this format" (e.g. canonical) then there is no reason to even ask the question, it's simpler and more robust for most of our (internal) code, we only have to worry about it at the interface boundaries. So who enforces the canonical format? The only place we have to be concerned is when it's user provided, any item we produce will be guaranteed to be in the canonical format (hopefully :-). That just means at our interface boundaries we *must* specify the canonical format. If we're taking input from the user on the command line we offer them the option of "input as pem", "input as der", "input as base64", try to validate as best we can trusting the user has told us the correct format and then convert to the canonical format. Think about the openssl x509 utilities, with those you must specify the input format. If we're taking input through an exposed API we do essentially the same thing. Require the format be passed along with the data, validate as best we can, and convert to the canonical format as it enters our system. BTW, by having the user/caller indicate the format they're providing will make the validation more robust, for example if it's stated the data is in DER format then there is no reason to even try to see if it can be base64 decoded which might lead to a false positive. Likewise if it's stated it's in pem format it must have the header and footer. Bottom line, I'm leery of trying to guess at random points what the format is, it's too easy for the guessing logic to draw the wrong conclusion, I'd much rather see it be explicit. > >> Or we need to adopt a convention that certs are always in one >> canonical format and the interface is responsible for assuring what it >> accepts as input is converted to the canonical form. > > Again, something would need to do that and base64.b64decode() is not > sufficient. > > I know this seems rather hacky, I thought as much when I coded it, just > trying to make it robust. > > rob > >> >>> I see what you mean about my regex being a bit weak though, it really >>> should require that the entire string conform. I'll see what I can do. >>> >>> rob >> >> > -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Jan 29 16:26:43 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 29 Jan 2010 11:26:43 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B62F960.1080004@redhat.com> References: <4B61FE69.9060107@redhat.com> <4B620291.2010901@redhat.com> <4B625645.2020004@redhat.com> <4B626E6F.8070800@redhat.com> <4B62F091.7060808@redhat.com> <4B62F960.1080004@redhat.com> Message-ID: <4B630C43.1040206@redhat.com> John Dennis wrote: > On 01/29/2010 09:28 AM, Rob Crittenden wrote: >> John Dennis wrote: >>> On 01/28/2010 10:30 PM, Rob Crittenden wrote: >>>> John Dennis wrote: >>>>> On 01/28/2010 04:15 PM, Rob Crittenden wrote: >>>>>> Gah, got the description mixed up with the last patch :-( >>>>>> >>>>>> Be a bit smarter about decoding certificates that might be base64 >>>>>> encoded. First see if it only contains those characters allowed >>>>>> before >>>>>> trying to decode it. This reduces the number of false positives. >>>>> >>>>> I'm not sure the test is doing what you want or even if it's the right >>>>> test. >>>>> >>>>> The test is saying "If there is one or more characters in the bas64 >>>>> alphabet then try and decode. That means just about anything will >>>>> match, which doesn't seem like a very strong test. >>>>> >>>>> Why not just try and decode it and let the decoder decide if it's >>>>> really base64, the decoder has much strong rules about the input, >>>>> including assuring the padding is correct. >>>>> >>>> >>>> The reason is I had a binary cert that was correctly decoded by the >>>> base64 encoder. I don't know the why's and wherefores but there it is. >>> >>> Then testing to see if each byte is in the base64 alphabet would not >>> have prevented this error. >> >> And yet it did in practice. I think you're assuming too much about the >> input testing in base64.b64decode(). It gladly takes binary data, as >> long as it fits the expected padding. > > You're right, I just went and checked the code, it skips any char not in > the base64 alphabet :-( > >>> >>> For a while now I've been feeling like we need to associate a format >>> attribute to the certificate (e.g. DER, PEM, BASE64, etc.). >> >> There is simply no good way to carry that extra data when all you have >> is a blob of data. We'd still need some mechanism to look at it and ask >> "what are you?" That or we simply reject some types of input. > > My concern is that correctly deducing what an object is just by scanning > it's contents is not robust. As you've seen it's easy to draw the wrong > conclusion. Rather if the convention is "it must be an object in this > format" (e.g. canonical) then there is no reason to even ask the > question, it's simpler and more robust for most of our (internal) code, > we only have to worry about it at the interface boundaries. > > So who enforces the canonical format? The only place we have to be > concerned is when it's user provided, any item we produce will be > guaranteed to be in the canonical format (hopefully :-). That just means > at our interface boundaries we *must* specify the canonical format. > > If we're taking input from the user on the command line we offer them > the option of "input as pem", "input as der", "input as base64", try to > validate as best we can trusting the user has told us the correct format > and then convert to the canonical format. > > Think about the openssl x509 utilities, with those you must specify the > input format. > > If we're taking input through an exposed API we do essentially the same > thing. Require the format be passed along with the data, validate as > best we can, and convert to the canonical format as it enters our system. > > BTW, by having the user/caller indicate the format they're providing > will make the validation more robust, for example if it's stated the > data is in DER format then there is no reason to even try to see if it > can be base64 decoded which might lead to a false positive. Likewise if > it's stated it's in pem format it must have the header and footer. > > Bottom line, I'm leery of trying to guess at random points what the > format is, it's too easy for the guessing logic to draw the wrong > conclusion, I'd much rather see it be explicit. Perhaps but validators take a single argument so there is no way to pass in type. rob From jdennis at redhat.com Fri Jan 29 16:37:38 2010 From: jdennis at redhat.com (John Dennis) Date: Fri, 29 Jan 2010 11:37:38 -0500 Subject: [Freeipa-devel] [PATCH] 360 be smarter about decoding certs In-Reply-To: <4B630C43.1040206@redhat.com> References: <4B61FE69.9060107@redhat.com> <4B620291.2010901@redhat.com> <4B625645.2020004@redhat.com> <4B626E6F.8070800@redhat.com> <4B62F091.7060808@redhat.com> <4B62F960.1080004@redhat.com> <4B630C43.1040206@redhat.com> Message-ID: <4B630ED2.8060206@redhat.com> On 01/29/2010 11:26 AM, Rob Crittenden wrote: > John Dennis wrote: >> On 01/29/2010 09:28 AM, Rob Crittenden wrote: >>> John Dennis wrote: >>>> On 01/28/2010 10:30 PM, Rob Crittenden wrote: >>>>> John Dennis wrote: >>>>>> On 01/28/2010 04:15 PM, Rob Crittenden wrote: >>>>>>> Gah, got the description mixed up with the last patch :-( >>>>>>> >>>>>>> Be a bit smarter about decoding certificates that might be base64 >>>>>>> encoded. First see if it only contains those characters allowed >>>>>>> before >>>>>>> trying to decode it. This reduces the number of false positives. >>>>>> >>>>>> I'm not sure the test is doing what you want or even if it's the >>>>>> right >>>>>> test. >>>>>> >>>>>> The test is saying "If there is one or more characters in the bas64 >>>>>> alphabet then try and decode. That means just about anything will >>>>>> match, which doesn't seem like a very strong test. >>>>>> >>>>>> Why not just try and decode it and let the decoder decide if it's >>>>>> really base64, the decoder has much strong rules about the input, >>>>>> including assuring the padding is correct. >>>>>> >>>>> >>>>> The reason is I had a binary cert that was correctly decoded by the >>>>> base64 encoder. I don't know the why's and wherefores but there it is. >>>> >>>> Then testing to see if each byte is in the base64 alphabet would not >>>> have prevented this error. >>> >>> And yet it did in practice. I think you're assuming too much about the >>> input testing in base64.b64decode(). It gladly takes binary data, as >>> long as it fits the expected padding. >> >> You're right, I just went and checked the code, it skips any char not >> in the base64 alphabet :-( >> >>>> >>>> For a while now I've been feeling like we need to associate a format >>>> attribute to the certificate (e.g. DER, PEM, BASE64, etc.). >>> >>> There is simply no good way to carry that extra data when all you have >>> is a blob of data. We'd still need some mechanism to look at it and ask >>> "what are you?" That or we simply reject some types of input. >> >> My concern is that correctly deducing what an object is just by >> scanning it's contents is not robust. As you've seen it's easy to draw >> the wrong conclusion. Rather if the convention is "it must be an >> object in this format" (e.g. canonical) then there is no reason to >> even ask the question, it's simpler and more robust for most of our >> (internal) code, we only have to worry about it at the interface >> boundaries. >> >> So who enforces the canonical format? The only place we have to be >> concerned is when it's user provided, any item we produce will be >> guaranteed to be in the canonical format (hopefully :-). That just >> means at our interface boundaries we *must* specify the canonical format. >> >> If we're taking input from the user on the command line we offer them >> the option of "input as pem", "input as der", "input as base64", try >> to validate as best we can trusting the user has told us the correct >> format and then convert to the canonical format. >> >> Think about the openssl x509 utilities, with those you must specify >> the input format. >> >> If we're taking input through an exposed API we do essentially the >> same thing. Require the format be passed along with the data, validate >> as best we can, and convert to the canonical format as it enters our >> system. >> >> BTW, by having the user/caller indicate the format they're providing >> will make the validation more robust, for example if it's stated the >> data is in DER format then there is no reason to even try to see if it >> can be base64 decoded which might lead to a false positive. Likewise >> if it's stated it's in pem format it must have the header and footer. >> >> Bottom line, I'm leery of trying to guess at random points what the >> format is, it's too easy for the guessing logic to draw the wrong >> conclusion, I'd much rather see it be explicit. > > Perhaps but validators take a single argument so there is no way to pass > in type. I wasn't thinking the validator would take a type, rather there would be a unique validators associated with the pem arg, the der arg, and the base64 arg. I think we're back at the same issue I was discussing with Pavel concerning having a different arg to pass for files. It seems like we're hit a real issue with the command parameter mechanism. Namely there doesn't seem to be a way to have multiple args that map onto a single command parameter. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Sat Jan 30 18:42:23 2010 From: jdennis at redhat.com (John Dennis) Date: Sat, 30 Jan 2010 13:42:23 -0500 Subject: [Freeipa-devel] [PATCH] add l10n support Message-ID: <4B647D8F.4000306@redhat.com> There are 2 patches attached which add internationalized message catalog support (l10n, i.e. localization). The patch was split into 2 pieces for easier review. The first patch contains only the modifications to build components and the new framework. The second patch adds all the translation files which really don't need review because they're generated files but must be kept in our source code repository for translators to update. The primary patch has two major changes: * modification of our existing build mechanism * a new directory install/po which contains the l10n framework and translation catalogs. The first major change to the build mechanism was replacing the autogen.sh script. I had discovered it was buggy, in particular it's logic for comparing the version of tools was flawed (used just string comparison so it thought version 7 of a tool was newer than version 11). Also there didn't seem to be a reason for this script since the autoregen tool is the preferred mechanism to bootstrap an autotools build. Older OS's do not have autoregen but We only need to bootstrap when we generate a distribution which can always be done on a current Fedora system. The second part of the changes to the build mechanism were the necessary modifications to build the l10n components. * edit Makefile.am to add the new subdir to descent into * Add new files to generate to configure.ac * Add new macros to configure.ac to find the gettext tools and set the message catalog name. * Edit the spec file to add a build dependency on gettext and add the translation files. Then add the l10n framework in install/po. There is a README there you might want to peruse. The initial set of languages we'll provide translations for is in the install/po/LINGUAS file. The set of files to scan for translatable strings is in install/po/Makefile.in, we'll need to manually update this file when we add or remove source files containing translatable strings. We provide one message catalog for all strings in IPA. Message catalogs are referred to as "domains". This means we have just one domain for IPA and it's installed under the name "ipa". The message catalogs are not partitioned by rpm component. The message catalogs are provided in the ipapython rpm which all other rpms depend on. Please note, there is now a build dependency on gettext, most you should already have this package installed. This patch does alter the way the build runs and it's possible it might introduce a build failure. I have tested builds in clean trees on F12 and did not have any problems. I wanted to do a scratch build for Fedora just to bullet proof but I couldn't figure out how to do it. I'll of course fix any build issue which might arise that I didn't catch earlier. Jason and I did discuss adding a "test" language to test translations in our test framework. This patch does not include that, but it's not hard to add once this patch is in place. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-i18n-framework-update-build-procedure.patch Type: text/x-patch Size: 25106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Initial-set-of-files-for-translators.patch Type: text/x-patch Size: 757285 bytes Desc: not available URL: