From rmeggins at redhat.com Tue Sep 1 00:50:59 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Aug 2009 18:50:59 -0600 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <1251757114.10449.13.camel@localhost.localdomain> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> <1251757114.10449.13.camel@localhost.localdomain> Message-ID: <4A9C6FF3.4010500@redhat.com> Simo Sorce wrote: > On Mon, 2009-08-31 at 13:23 -0700, Karsten Wade wrote: > >> Richard looked at the license-specific version, made some suggestions, >> then asked if there is a reason for being GPLv2 only as a project and >> codebase. For example, many projects are licensed "GPLv2 or later", >> yet there was some confusion around the time that GPLv3 came out if >> that was advisable. Is this project GPLv2-specific on purpose? >> > > No there isn't a specific reason IPA is GPLv2 Only, at the time when we > started I actually proposed to use the brand new GPLv3 or later diction, > but legal was not yet comfortable with GPLv3 so we went the default RH > license at the time which was GPLv2 only. > > I would actually like to move to GPLv2 or later or even GPLv3 or later > if our external code dependencies allows it without trouble. > > I think the only code that we may not be able to move to GPLv3 is the > directory server plugins as DS is GPLv2+exceptions, but I have no > problem in clearly spelling out that plugins have a different license > because of their dependency and move on with the rest of the code. > The directory server license allows for plugins to be released under different licenses, provided the plugin uses only the public API (defined in slapi-plugin.h). > Simo. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Tue Sep 1 05:54:06 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 01 Sep 2009 05:54:06 +0000 Subject: [Freeipa-devel] [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hates'em. In-Reply-To: <4A9B9FF3.5050405@redhat.com> References: <4A980543.6020402@redhat.com> <4A981229.9020404@redhat.com> <4A9B9FF3.5050405@redhat.com> Message-ID: <1251784446.2988.56.camel@jgd-dsk> On Mon, 2009-08-31 at 12:03 +0200, Pavel Zuna wrote: > Rob Crittenden wrote: > > Pavel Zuna wrote: > >> python-ldap seems to hate None values when adding an entry and raises > >> an exception instead ignoring them, so we need to filter them ourselves. > >> > >> Pavel > > > > Couldn't updates contain None as well? > > > > rob > > Updates can and it's valid. None is used in update_entry for deleting attributes. > > Pavel I thought it was a good idea to normalize all "empty" values to None to simplify the special cases the Command and Backend plugins have to deal with. So empty strings, empty lists, empty dicts, and lists containing only empty values all get converted to None by Command.__call__() before Command.run() is called. If this is a bad idea, I'm open to suggestions (assuming they don't cause an explosion of special cases). In create operations, None means the attribute wasn't supplied, and I think we can just filter them away. But in update operations, None means unset the attribute value (if it had one set previously). So my question is, what value do when set an ldap attribute to when: 1. unsetting scalar attribute? 2. unsetting a multivalue attribute? Also, do we have to check if the attribute previously had a value before unsetting? In other words, will an exception be raised if we unset an attribute that wasn't set to begin with? From pzuna at redhat.com Tue Sep 1 10:13:24 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 01 Sep 2009 12:13:24 +0200 Subject: [Freeipa-devel] [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hates'em. In-Reply-To: <1251784446.2988.56.camel@jgd-dsk> References: <4A980543.6020402@redhat.com> <4A981229.9020404@redhat.com> <4A9B9FF3.5050405@redhat.com> <1251784446.2988.56.camel@jgd-dsk> Message-ID: <4A9CF3C4.1030709@redhat.com> Jason Gerard DeRose wrote: > On Mon, 2009-08-31 at 12:03 +0200, Pavel Zuna wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> python-ldap seems to hate None values when adding an entry and raises >>>> an exception instead ignoring them, so we need to filter them ourselves. >>>> >>>> Pavel >>> Couldn't updates contain None as well? >>> >>> rob >> Updates can and it's valid. None is used in update_entry for deleting attributes. >> >> Pavel > > I thought it was a good idea to normalize all "empty" values to None to > simplify the special cases the Command and Backend plugins have to deal > with. So empty strings, empty lists, empty dicts, and lists containing > only empty values all get converted to None by Command.__call__() before > Command.run() is called. If this is a bad idea, I'm open to suggestions > (assuming they don't cause an explosion of special cases). > > In create operations, None means the attribute wasn't supplied, and I > think we can just filter them away. But in update operations, None > means unset the attribute value (if it had one set previously). > > So my question is, what value do when set an ldap attribute to when: > > 1. unsetting scalar attribute? > 2. unsetting a multivalue attribute? > > Also, do we have to check if the attribute previously had a value before > unsetting? In other words, will an exception be raised if we unset an > attribute that wasn't set to begin with? > After the last patch, None values are filtered out when creating a new entry. When updating an entry, there are 3 cases: 1) the new value is None -> the whole attribute is unset 2) the new is a scalar -> the attribute is set to the scalar value (all previous values are deleted) 3) the new value is a list of values -> None values are filtered out and the attribute is set to what's left in the list (all previous values not in the new list are lost) When it comes to positional arguments, I think it's fair to convert them to None if not present, but options are passed as kwargs, so I think we should just leave them out and not force them to None. One more thing - currently users have no way to delete an attribute. Just set it to an empty string (unless it is converted to None). Maybe we should allow them to do so. Pavel From ssorce at redhat.com Tue Sep 1 12:02:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Sep 2009 08:02:15 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <4A9C6FF3.4010500@redhat.com> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> <1251757114.10449.13.camel@localhost.localdomain> <4A9C6FF3.4010500@redhat.com> Message-ID: <1251806535.10449.15.camel@localhost.localdomain> On Mon, 2009-08-31 at 18:50 -0600, Rich Megginson wrote: > Simo Sorce wrote: > > On Mon, 2009-08-31 at 13:23 -0700, Karsten Wade wrote: > > > >> Richard looked at the license-specific version, made some suggestions, > >> then asked if there is a reason for being GPLv2 only as a project and > >> codebase. For example, many projects are licensed "GPLv2 or later", > >> yet there was some confusion around the time that GPLv3 came out if > >> that was advisable. Is this project GPLv2-specific on purpose? > >> > > > > No there isn't a specific reason IPA is GPLv2 Only, at the time when we > > started I actually proposed to use the brand new GPLv3 or later diction, > > but legal was not yet comfortable with GPLv3 so we went the default RH > > license at the time which was GPLv2 only. > > > > I would actually like to move to GPLv2 or later or even GPLv3 or later > > if our external code dependencies allows it without trouble. > > > > I think the only code that we may not be able to move to GPLv3 is the > > directory server plugins as DS is GPLv2+exceptions, but I have no > > problem in clearly spelling out that plugins have a different license > > because of their dependency and move on with the rest of the code. > > > The directory server license allows for plugins to be released under > different licenses, provided the plugin uses only the public API > (defined in slapi-plugin.h). Yes, but that not what I am concerned about. I am not sure a plugin licensed under the GPLvX can be linked to the Directory Server without any exception. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Sep 1 12:14:01 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 01 Sep 2009 08:14:01 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <1251806535.10449.15.camel@localhost.localdomain> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> <1251757114.10449.13.camel@localhost.localdomain> <4A9C6FF3.4010500@redhat.com> <1251806535.10449.15.camel@localhost.localdomain> Message-ID: <4A9D1009.5020007@redhat.com> Simo Sorce wrote: > On Mon, 2009-08-31 at 18:50 -0600, Rich Megginson wrote: > >> Simo Sorce wrote: >> >>> On Mon, 2009-08-31 at 13:23 -0700, Karsten Wade wrote: >>> >>> >>>> Richard looked at the license-specific version, made some suggestions, >>>> then asked if there is a reason for being GPLv2 only as a project and >>>> codebase. For example, many projects are licensed "GPLv2 or later", >>>> yet there was some confusion around the time that GPLv3 came out if >>>> that was advisable. Is this project GPLv2-specific on purpose? >>>> >>>> >>> No there isn't a specific reason IPA is GPLv2 Only, at the time when we >>> started I actually proposed to use the brand new GPLv3 or later diction, >>> but legal was not yet comfortable with GPLv3 so we went the default RH >>> license at the time which was GPLv2 only. >>> >>> I would actually like to move to GPLv2 or later or even GPLv3 or later >>> if our external code dependencies allows it without trouble. >>> >>> I think the only code that we may not be able to move to GPLv3 is the >>> directory server plugins as DS is GPLv2+exceptions, but I have no >>> problem in clearly spelling out that plugins have a different license >>> because of their dependency and move on with the rest of the code. >>> >>> >> The directory server license allows for plugins to be released under >> different licenses, provided the plugin uses only the public API >> (defined in slapi-plugin.h). >> > > Yes, but that not what I am concerned about. > I am not sure a plugin licensed under the GPLvX can be linked to the > Directory Server without any exception. > > Simo. > > I think what Rich said means that DS plugins can be licensed as we think appropriate without any special exception for DS itself. -- 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 Tue Sep 1 12:18:07 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Sep 2009 08:18:07 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <4A9D1009.5020007@redhat.com> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> <1251757114.10449.13.camel@localhost.localdomain> <4A9C6FF3.4010500@redhat.com> <1251806535.10449.15.camel@localhost.localdomain> <4A9D1009.5020007@redhat.com> Message-ID: <1251807487.10449.18.camel@localhost.localdomain> On Tue, 2009-09-01 at 08:14 -0400, Dmitri Pal wrote: > I think what Rich said means that DS plugins can be licensed as we > think > appropriate without any special exception for DS itself. No, I a don't think so, but I'll let Rich comment on that. In any case interaction between reciprocal licenses is not that easy. It is true that the DS core is arguably not derived from any of its plugins, but still I'd like legal's opinion on what license a plugin can have to be compatible in the other direction. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Sep 1 12:22:52 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 01 Sep 2009 08:22:52 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <1251807487.10449.18.camel@localhost.localdomain> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> <1251757114.10449.13.camel@localhost.localdomain> <4A9C6FF3.4010500@redhat.com> <1251806535.10449.15.camel@localhost.localdomain> <4A9D1009.5020007@redhat.com> <1251807487.10449.18.camel@localhost.localdomain> Message-ID: <4A9D121C.4040702@redhat.com> Simo Sorce wrote: > On Tue, 2009-09-01 at 08:14 -0400, Dmitri Pal wrote: > >> I think what Rich said means that DS plugins can be licensed as we >> think >> appropriate without any special exception for DS itself. >> > > No, I a don't think so, but I'll let Rich comment on that. > In any case interaction between reciprocal licenses is not that easy. > > At least this is what Nathan told me some time ago when we talked about licenses for plugins. Rich said the same thing. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Tue Sep 1 14:33:38 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 01 Sep 2009 08:33:38 -0600 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <4A9D121C.4040702@redhat.com> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> <1251757114.10449.13.camel@localhost.localdomain> <4A9C6FF3.4010500@redhat.com> <1251806535.10449.15.camel@localhost.localdomain> <4A9D1009.5020007@redhat.com> <1251807487.10449.18.camel@localhost.localdomain> <4A9D121C.4040702@redhat.com> Message-ID: <4A9D30C2.50509@redhat.com> Dmitri Pal wrote: > Simo Sorce wrote: > >> On Tue, 2009-09-01 at 08:14 -0400, Dmitri Pal wrote: >> >> >>> I think what Rich said means that DS plugins can be licensed as we >>> think >>> appropriate without any special exception for DS itself. >>> >>> >> No, I a don't think so, but I'll let Rich comment on that. >> In any case interaction between reciprocal licenses is not that easy. >> >> >> > At least this is what Nathan told me some time ago when we talked about > licenses for plugins. > Rich said the same thing. > The DS license is primarily concerned about what source code you can distribute with the directory server, and what plugin code you can link into the directory server, from the standpoint of the directory server. I think Simo is concerned about the other direction - if you have a plugin that has a certain license, does that license permit the plugin code to be distributed with the directory server, and does the plugin license allow it to run in the same process as the directory server. This is certainly a question for legal to answer. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Wed Sep 2 00:36:07 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 2 Sep 2009 02:36:07 +0200 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf Message-ID: <20090902023607.69dccbb2@notas> Hi, This patch adds options --forwarder and --no-forwarders. At least one of them must be used if you are doing a setup with DNS server. They are also mutually exclusive. The --forwarder option can be used more than once to specify more servers. If the installer runs in interactive mode, it will prompt the user if none of these option was given at the command Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-DNS-forwarders-in-etc-named.conf.patch Type: text/x-patch Size: 8349 bytes Desc: not available URL: From mnagy at redhat.com Wed Sep 2 00:37:21 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 2 Sep 2009 02:37:21 +0200 Subject: [Freeipa-devel] [PATCH] Start bind only after restarting kdc and dirsrv Message-ID: <20090902023721.19f4369d@notas> BIND starting before we apply LDAP updates and restart kdc and directory server causes trouble. We resolve this for now by postponing BIND start to the end of installation. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Start-bind-only-after-restarting-kdc-and-dirsrv.patch Type: text/x-patch Size: 2930 bytes Desc: not available URL: From mnagy at redhat.com Wed Sep 2 01:16:58 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 2 Sep 2009 03:16:58 +0200 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <20090902023607.69dccbb2@notas> References: <20090902023607.69dccbb2@notas> Message-ID: <20090902031658.0d692dd5@notas> Martin Nagy wrote: > Hi, > This patch adds options --forwarder and --no-forwarders. At least one of > them must be used if you are doing a setup with DNS server. They are > also mutually exclusive. The --forwarder option can be used more than > once to specify more servers. If the installer runs in interactive mode, > it will prompt the user if none of these option was given at the command > > Martin Actually, I forgot on the replica installer. Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-DNS-forwarders-in-etc-named.conf.patch Type: text/x-patch Size: 12047 bytes Desc: not available URL: From ssorce at redhat.com Wed Sep 2 12:41:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2009 08:41:00 -0400 Subject: [Freeipa-devel] [PATCH] Start bind only after restarting kdc and dirsrv In-Reply-To: <20090902023721.19f4369d@notas> References: <20090902023721.19f4369d@notas> Message-ID: <1251895260.3111.16.camel@localhost.localdomain> On Wed, 2009-09-02 at 02:37 +0200, Martin Nagy wrote: > BIND starting before we apply LDAP updates and restart kdc and > directory > server causes trouble. We resolve this for now by postponing BIND > start > to the end of installation. Ack, Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Sep 2 12:41:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Sep 2009 08:41:15 -0400 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <20090902031658.0d692dd5@notas> References: <20090902023607.69dccbb2@notas> <20090902031658.0d692dd5@notas> Message-ID: <1251895275.3111.17.camel@localhost.localdomain> On Wed, 2009-09-02 at 03:16 +0200, Martin Nagy wrote: > Martin Nagy wrote: > > Hi, > > This patch adds options --forwarder and --no-forwarders. At least > one of > > them must be used if you are doing a setup with DNS server. They are > > also mutually exclusive. The --forwarder option can be used more > than > > once to specify more servers. If the installer runs in interactive > mode, > > it will prompt the user if none of these option was given at the > command > > > > Martin > > Actually, I forgot on the replica installer. Updated patch attached. Ack, Simo. -- Simo Sorce * Red Hat, Inc * New York From mnagy at redhat.com Wed Sep 2 13:06:36 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 02 Sep 2009 15:06:36 +0200 Subject: [Freeipa-devel] [PATCH] Start bind only after restarting kdc and dirsrv In-Reply-To: <1251895260.3111.16.camel@localhost.localdomain> References: <20090902023721.19f4369d@notas> <1251895260.3111.16.camel@localhost.localdomain> Message-ID: <1251896796.32049.47.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-09-02 at 08:41 -0400, Simo Sorce wrote: > On Wed, 2009-09-02 at 02:37 +0200, Martin Nagy wrote: > > BIND starting before we apply LDAP updates and restart kdc and > > directory > > server causes trouble. We resolve this for now by postponing BIND > > start > > to the end of installation. > > Ack, > Simo. Self-nack. I will need to use the xmlrpc plug-ins and decided that it will be better to move the whole installation of bind after kdc and directory server are restarted. I'll post the new patch after some testing. Martin From mnagy at redhat.com Wed Sep 2 17:03:58 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 02 Sep 2009 19:03:58 +0200 Subject: [Freeipa-devel] [PATCH 1/3] Setup bind only after restarting kdc and dirsrv Message-ID: <1251911038.32049.51.camel@wolverine.englab.brq.redhat.com> BIND starting before we apply LDAP updates and restart kdc and directory server causes trouble. We resolve this for now by postponing BIND setup to the end of installation. Another reason is that we will be using xml-rpc during the setup in the future. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Setup-bind-only-after-restarting-kdc-and-dirsrv.patch Type: text/x-patch Size: 2634 bytes Desc: not available URL: From mnagy at redhat.com Wed Sep 2 17:04:27 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 02 Sep 2009 19:04:27 +0200 Subject: [Freeipa-devel] [PATCH 2/3] Remove old --setup-bind option Message-ID: <1251911067.32049.52.camel@wolverine.englab.brq.redhat.com> Since we are changing the behaviour of the --setup-dns option substantially, we might as well remove the old --setup-bind option. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-old-setup-bind-option.patch Type: text/x-patch Size: 1342 bytes Desc: not available URL: From mnagy at redhat.com Wed Sep 2 17:05:17 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 02 Sep 2009 19:05:17 +0200 Subject: [Freeipa-devel] [PATCH 3/3] Add A and PTR records of ourselves during installation Message-ID: <1251911117.32049.53.camel@wolverine.englab.brq.redhat.com> If the DNS zones already exist but don't contain our own records, add them. This patch introduces the ipalib.api into the installers. For now, the code is still little messy. Later patches will abandon the way we create zones now and use ipalib.api exclusively. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-A-and-PTR-records-of-ourselves-during-installati.patch Type: text/x-patch Size: 4815 bytes Desc: not available URL: From mnagy at redhat.com Wed Sep 2 17:10:25 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 02 Sep 2009 19:10:25 +0200 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <1251895275.3111.17.camel@localhost.localdomain> References: <20090902023607.69dccbb2@notas> <20090902031658.0d692dd5@notas> <1251895275.3111.17.camel@localhost.localdomain> Message-ID: <1251911425.32049.54.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-09-02 at 08:41 -0400, Simo Sorce wrote: > On Wed, 2009-09-02 at 03:16 +0200, Martin Nagy wrote: > > Martin Nagy wrote: > > > Hi, > > > This patch adds options --forwarder and --no-forwarders. At least > > one of > > > them must be used if you are doing a setup with DNS server. They are > > > also mutually exclusive. The --forwarder option can be used more > > than > > > once to specify more servers. If the installer runs in interactive > > mode, > > > it will prompt the user if none of these option was given at the > > command > > > > > > Martin > > > > Actually, I forgot on the replica installer. Updated patch attached. > > Ack, > Simo. Pushed. Martin From rcritten at redhat.com Wed Sep 2 18:04:27 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Sep 2009 14:04:27 -0400 Subject: [Freeipa-devel] [PATCH 1/3] Setup bind only after restarting kdc and dirsrv In-Reply-To: <1251911038.32049.51.camel@wolverine.englab.brq.redhat.com> References: <1251911038.32049.51.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A9EB3AB.8020607@redhat.com> Martin Nagy wrote: > BIND starting before we apply LDAP updates and restart kdc and directory > server causes trouble. We resolve this for now by postponing BIND setup > to the end of installation. Another reason is that we will be using > xml-rpc during the setup in the future. > > Martin ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 2 18:04:35 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Sep 2009 14:04:35 -0400 Subject: [Freeipa-devel] [PATCH 2/3] Remove old --setup-bind option In-Reply-To: <1251911067.32049.52.camel@wolverine.englab.brq.redhat.com> References: <1251911067.32049.52.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A9EB3B3.80600@redhat.com> Martin Nagy wrote: > Since we are changing the behaviour of the --setup-dns option > substantially, we might as well remove the old --setup-bind option. > > Martin > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 2 18:04:45 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Sep 2009 14:04:45 -0400 Subject: [Freeipa-devel] [PATCH 3/3] Add A and PTR records of ourselves during installation In-Reply-To: <1251911117.32049.53.camel@wolverine.englab.brq.redhat.com> References: <1251911117.32049.53.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A9EB3BD.1070403@redhat.com> Martin Nagy wrote: > If the DNS zones already exist but don't contain our own records, add > them. This patch introduces the ipalib.api into the installers. For now, > the code is still little messy. Later patches will abandon the way we > create zones now and use ipalib.api exclusively. > > Martin ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Wed Sep 2 20:06:05 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 2 Sep 2009 22:06:05 +0200 Subject: [Freeipa-devel] [PATCH 1/3] Setup bind only after restarting kdc and dirsrv In-Reply-To: <4A9EB3AB.8020607@redhat.com> References: <1251911038.32049.51.camel@wolverine.englab.brq.redhat.com> <4A9EB3AB.8020607@redhat.com> Message-ID: <20090902220605.56220999@notas> Rob Crittenden wrote: > Martin Nagy wrote: > > BIND starting before we apply LDAP updates and restart kdc and directory > > server causes trouble. We resolve this for now by postponing BIND setup > > to the end of installation. Another reason is that we will be using > > xml-rpc during the setup in the future. > > > > Martin > > ack Pushed From mnagy at redhat.com Wed Sep 2 20:06:17 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 2 Sep 2009 22:06:17 +0200 Subject: [Freeipa-devel] [PATCH 2/3] Remove old --setup-bind option In-Reply-To: <4A9EB3B3.80600@redhat.com> References: <1251911067.32049.52.camel@wolverine.englab.brq.redhat.com> <4A9EB3B3.80600@redhat.com> Message-ID: <20090902220617.309a39dc@notas> Rob Crittenden wrote: > Martin Nagy wrote: > > Since we are changing the behaviour of the --setup-dns option > > substantially, we might as well remove the old --setup-bind option. > > > > Martin > > > > ack Pushed From mnagy at redhat.com Wed Sep 2 20:06:31 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 2 Sep 2009 22:06:31 +0200 Subject: [Freeipa-devel] [PATCH 3/3] Add A and PTR records of ourselves during installation In-Reply-To: <4A9EB3BD.1070403@redhat.com> References: <1251911117.32049.53.camel@wolverine.englab.brq.redhat.com> <4A9EB3BD.1070403@redhat.com> Message-ID: <20090902220631.23ec45ad@notas> Rob Crittenden wrote: > Martin Nagy wrote: > > If the DNS zones already exist but don't contain our own records, add > > them. This patch introduces the ipalib.api into the installers. For now, > > the code is still little messy. Later patches will abandon the way we > > create zones now and use ipalib.api exclusively. > > > > Martin > > ack Pushed From rcritten at redhat.com Wed Sep 2 20:51:40 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Sep 2009 16:51:40 -0400 Subject: [Freeipa-devel] [PATCH] 260 allow a CA to be regenerated In-Reply-To: <1251499791.10114.19.camel@localhost.localdomain> References: <4A981625.8080203@redhat.com> <1251499791.10114.19.camel@localhost.localdomain> Message-ID: <4A9EDADC.1060202@redhat.com> Simo Sorce wrote: > On Fri, 2009-08-28 at 13:38 -0400, Rob Crittenden wrote: >> Add an option so we can generate a new cert for a CA. This is so we >> can >> ultimately fix the missing CA basic constraint but it will also allow >> the CA to be renewed. >> >> This also fixes a small bug when generating the CA basic constraint. >> It >> wasn't getting set as Critical because somehow I had it sending a 7 >> instead of a y :-( > > Ack. > > Simo. > Pushed to ipa-1-2 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 2 22:03:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Sep 2009 18:03:20 -0400 Subject: [Freeipa-devel] [PATCH] 263 Tighten up upgrade detection Message-ID: <4A9EEBA8.9010709@redhat.com> We have an upgrade script that runs in rpm %post to see if an existing installation needs to be updated. This sometimes printed spurious error messages that were confusing. This patch attempts to tighten things up a bit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-263-upgrade.patch Type: application/mbox Size: 3462 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 2 22:04:03 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Sep 2009 18:04:03 -0400 Subject: [Freeipa-devel] [PATCH] 264 own IPA httpd conf files Message-ID: <4A9EEBD3.6060407@redhat.com> For IPA 1-2 Have our spec file own the Apache configuration files we create. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-264-spec.patch Type: application/mbox Size: 1780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Sep 3 20:13:01 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Sep 2009 16:13:01 -0400 Subject: [Freeipa-devel] [PATCH] 264 own IPA httpd conf files In-Reply-To: <4A9EEBD3.6060407@redhat.com> References: <4A9EEBD3.6060407@redhat.com> Message-ID: <1252008781.15238.41.camel@localhost.localdomain> On Wed, 2009-09-02 at 18:04 -0400, Rob Crittenden wrote: > For IPA 1-2 > > Have our spec file own the Apache configuration files we create. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Sep 3 20:13:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Sep 2009 16:13:12 -0400 Subject: [Freeipa-devel] [PATCH] 263 Tighten up upgrade detection In-Reply-To: <4A9EEBA8.9010709@redhat.com> References: <4A9EEBA8.9010709@redhat.com> Message-ID: <1252008792.15238.42.camel@localhost.localdomain> On Wed, 2009-09-02 at 18:03 -0400, Rob Crittenden wrote: > We have an upgrade script that runs in rpm %post to see if an > existing > installation needs to be updated. This sometimes printed spurious > error > messages that were confusing. This patch attempts to tighten things up > a > bit. ACK SImo. -- Simo Sorce * Red Hat, Inc * New York From davido at redhat.com Thu Sep 3 23:50:26 2009 From: davido at redhat.com (David O'Brien) Date: Fri, 04 Sep 2009 09:50:26 +1000 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <20090902023607.69dccbb2@notas> References: <20090902023607.69dccbb2@notas> Message-ID: <4AA05642.6020101@redhat.com> Martin Nagy wrote: > Hi, > This patch adds options --forwarder and --no-forwarders. At least one of > them must be used if you are doing a setup with DNS server. They are > also mutually exclusive. The --forwarder option can be used more than > once to specify more servers. If the installer runs in interactive mode, > it will prompt the user if none of these option was given at the command > > Martin > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Something like ipa-server-install --setup-dns --forwarder --forwarder ? You can't use a separated list of IP addresses to save space and typing? That may go against coding style or practice, I don't know... /me has user hat on :-) -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb From mnagy at redhat.com Fri Sep 4 09:28:22 2009 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 04 Sep 2009 11:28:22 +0200 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <4AA05642.6020101@redhat.com> References: <20090902023607.69dccbb2@notas> <4AA05642.6020101@redhat.com> Message-ID: <1252056502.32049.99.camel@wolverine.englab.brq.redhat.com> On Fri, 2009-09-04 at 09:50 +1000, David O'Brien wrote: > Martin Nagy wrote: > > Hi, > > This patch adds options --forwarder and --no-forwarders. At least one of > > them must be used if you are doing a setup with DNS server. They are > > also mutually exclusive. The --forwarder option can be used more than > > once to specify more servers. If the installer runs in interactive mode, > > it will prompt the user if none of these option was given at the command > > > > Martin > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Something like ipa-server-install --setup-dns --forwarder > --forwarder ? > You can't use a separated list of IP addresses to save space and typing? > > That may go against coding style or practice, I don't know... > > /me has user hat on :-) Hm, well, we use a python module to handle option parsing [1] and this is the way it handles lists. We could allow the IP addresses to be separated by, say, ',' but this also has the risk that the user will do "--forwarder 1.2.3.4, 2.3.4.5" which of course wouldn't work (the last IP is treated as a positional argument). Martin [1] http://docs.python.org/library/optparse.html From jderose at redhat.com Fri Sep 4 17:00:09 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Fri, 04 Sep 2009 17:00:09 +0000 Subject: [Freeipa-devel] wehjit - a Python web-widget library Message-ID: <1252083609.2854.26.camel@jgd-dsk> So here's my somewhat informal 0.0.1 release of the widget library. This is needed by my big upcoming IPA webui patch, which I'll send sometime this evening. It's still pretty short on the documentation side, but you can build the epydoc documentation with the ./make-doc script. There's a small interactive demo as well, launch it with the ./wehjit-demo script. Each page has a "Source Code" item in the menu, click on it to see the source for that demo. Under Python2.6, you can install it in ~/.local/ like this: ./setup.py install --user Add ~/.local/bin to your PATH to use widget-demo from your ~/.local/ install. But before you can run setup.py, you will have to install the python-devel package as unfortunately Fedora doesn't install distutils by default: yum install python-devel I have a Bazaar repo quietly sitting on my fedorapeople page, so if anyone wants to track the repo: bzr branch http://jderose.fedorapeople.org/bzr/wehjit/ Cheers, Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: wehjit-0.0.1.tar.gz Type: application/x-compressed-tar Size: 77397 bytes Desc: not available URL: From dpal at redhat.com Fri Sep 4 17:10:06 2009 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Sep 2009 13:10:06 -0400 Subject: [Freeipa-devel] wehjit - a Python web-widget library In-Reply-To: <1252083609.2854.26.camel@jgd-dsk> References: <1252083609.2854.26.camel@jgd-dsk> Message-ID: <4AA149EE.30708@redhat.com> Jason Gerard DeRose wrote: > So here's my somewhat informal 0.0.1 release of the widget library. > This is needed by my big upcoming IPA webui patch, which I'll send > sometime this evening. > > It's still pretty short on the documentation side, but you can build the > epydoc documentation with the ./make-doc script. There's a small > interactive demo as well, launch it with the ./wehjit-demo script. Each > page has a "Source Code" item in the menu, click on it to see the source > for that demo. > > Under Python2.6, you can install it in ~/.local/ like this: > > ./setup.py install --user > > Add ~/.local/bin to your PATH to use widget-demo from your ~/.local/ > install. But before you can run setup.py, you will have to install the > python-devel package as unfortunately Fedora doesn't install distutils > by default: > > yum install python-devel > > I have a Bazaar repo quietly sitting on my fedorapeople page, so if > anyone wants to track the repo: > > bzr branch http://jderose.fedorapeople.org/bzr/wehjit/ > > Cheers, > Jason > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Congratulations Jason! Log hours for many days... -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jgalipea at redhat.com Fri Sep 4 17:13:45 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Fri, 04 Sep 2009 13:13:45 -0400 Subject: [Freeipa-devel] wehjit - a Python web-widget library In-Reply-To: <4AA149EE.30708@redhat.com> References: <1252083609.2854.26.camel@jgd-dsk> <4AA149EE.30708@redhat.com> Message-ID: <4AA14AC9.5050900@redhat.com> Dmitri Pal wrote: > Jason Gerard DeRose wrote: > >> So here's my somewhat informal 0.0.1 release of the widget library. >> This is needed by my big upcoming IPA webui patch, which I'll send >> sometime this evening. >> >> It's still pretty short on the documentation side, but you can build the >> epydoc documentation with the ./make-doc script. There's a small >> interactive demo as well, launch it with the ./wehjit-demo script. Each >> page has a "Source Code" item in the menu, click on it to see the source >> for that demo. >> >> Under Python2.6, you can install it in ~/.local/ like this: >> >> ./setup.py install --user >> >> Add ~/.local/bin to your PATH to use widget-demo from your ~/.local/ >> install. But before you can run setup.py, you will have to install the >> python-devel package as unfortunately Fedora doesn't install distutils >> by default: >> >> yum install python-devel >> >> I have a Bazaar repo quietly sitting on my fedorapeople page, so if >> anyone wants to track the repo: >> >> bzr branch http://jderose.fedorapeople.org/bzr/wehjit/ >> >> Cheers, >> Jason >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > Congratulations Jason! > Log hours for many days... > Exciting - Thanks Jason!! > > -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering From rcritten at redhat.com Fri Sep 4 18:33:19 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Sep 2009 14:33:19 -0400 Subject: [Freeipa-devel] [PATCH] 263 Tighten up upgrade detection In-Reply-To: <1252008792.15238.42.camel@localhost.localdomain> References: <4A9EEBA8.9010709@redhat.com> <1252008792.15238.42.camel@localhost.localdomain> Message-ID: <4AA15D6F.2040305@redhat.com> Simo Sorce wrote: > On Wed, 2009-09-02 at 18:03 -0400, Rob Crittenden wrote: >> We have an upgrade script that runs in rpm %post to see if an >> existing >> installation needs to be updated. This sometimes printed spurious >> error >> messages that were confusing. This patch attempts to tighten things up >> a >> bit. > > ACK > > SImo. > pushed to ipa-1-2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Sep 4 18:33:28 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Sep 2009 14:33:28 -0400 Subject: [Freeipa-devel] [PATCH] 264 own IPA httpd conf files In-Reply-To: <1252008781.15238.41.camel@localhost.localdomain> References: <4A9EEBD3.6060407@redhat.com> <1252008781.15238.41.camel@localhost.localdomain> Message-ID: <4AA15D78.5090305@redhat.com> Simo Sorce wrote: > On Wed, 2009-09-02 at 18:04 -0400, Rob Crittenden wrote: >> For IPA 1-2 >> >> Have our spec file own the Apache configuration files we create. > > ACK > > Simo. > pushed to ipa-1-2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From davido at redhat.com Sun Sep 6 21:54:04 2009 From: davido at redhat.com (David O'Brien) Date: Mon, 07 Sep 2009 07:54:04 +1000 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <1252056502.32049.99.camel@wolverine.englab.brq.redhat.com> References: <20090902023607.69dccbb2@notas> <4AA05642.6020101@redhat.com> <1252056502.32049.99.camel@wolverine.englab.brq.redhat.com> Message-ID: <4AA42F7C.2050903@redhat.com> Martin Nagy wrote: > On Fri, 2009-09-04 at 09:50 +1000, David O'Brien wrote: > >> Martin Nagy wrote: >> >>> Hi, >>> This patch adds options --forwarder and --no-forwarders. At least one of >>> them must be used if you are doing a setup with DNS server. They are >>> also mutually exclusive. The --forwarder option can be used more than >>> once to specify more servers. If the installer runs in interactive mode, >>> it will prompt the user if none of these option was given at the command >>> >>> Martin >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> Something like ipa-server-install --setup-dns --forwarder >> --forwarder ? >> You can't use a separated list of IP addresses to save space and typing? >> >> That may go against coding style or practice, I don't know... >> >> /me has user hat on :-) >> > > Hm, well, we use a python module to handle option parsing [1] and this > is the way it handles lists. We could allow the IP addresses to be > separated by, say, ',' but this also has the risk that the user will do > "--forwarder 1.2.3.4, 2.3.4.5" which of course wouldn't work (the last > IP is treated as a positional argument). > > Martin > > [1] http://docs.python.org/library/optparse.html > > ok, well if it's SOP to handle options this way I'm not about to suggest otherwise[1], but if there were a user-friendly way of doing it that didn't bend or break any rules I'd make more noise. cheers David [1] One of the goals in ECS' style guide is to adhere as much as possible to industry standards and standard practice, not invent new ones that Red Hat likes better. -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb From mnagy at redhat.com Mon Sep 7 07:17:40 2009 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 07 Sep 2009 09:17:40 +0200 Subject: [Freeipa-devel] [PATCH] Use DNS forwarders in /etc/named.conf In-Reply-To: <4AA42F7C.2050903@redhat.com> References: <20090902023607.69dccbb2@notas> <4AA05642.6020101@redhat.com> <1252056502.32049.99.camel@wolverine.englab.brq.redhat.com> <4AA42F7C.2050903@redhat.com> Message-ID: <1252307860.32049.135.camel@wolverine.englab.brq.redhat.com> On Mon, 2009-09-07 at 07:54 +1000, David O'Brien wrote: > Martin Nagy wrote: > > On Fri, 2009-09-04 at 09:50 +1000, David O'Brien wrote: > > > >> Martin Nagy wrote: > >> > >>> Hi, > >>> This patch adds options --forwarder and --no-forwarders. At least one of > >>> them must be used if you are doing a setup with DNS server. They are > >>> also mutually exclusive. The --forwarder option can be used more than > >>> once to specify more servers. If the installer runs in interactive mode, > >>> it will prompt the user if none of these option was given at the command > >>> > >>> Martin > >>> > >> Something like ipa-server-install --setup-dns --forwarder > >> --forwarder ? > >> You can't use a separated list of IP addresses to save space and typing? > >> > >> That may go against coding style or practice, I don't know... > >> > >> /me has user hat on :-) > >> > > > > Hm, well, we use a python module to handle option parsing [1] and this > > is the way it handles lists. We could allow the IP addresses to be > > separated by, say, ',' but this also has the risk that the user will do > > "--forwarder 1.2.3.4, 2.3.4.5" which of course wouldn't work (the last > > IP is treated as a positional argument). > > > > Martin > > > > [1] http://docs.python.org/library/optparse.html > > > > > ok, well if it's SOP to handle options this way I'm not about to suggest > otherwise[1], but if there were a user-friendly way of doing it that > didn't bend or break any rules I'd make more noise. > > cheers > David > > [1] One of the goals in ECS' style guide is to adhere as much as > possible to industry standards and standard practice, not invent new > ones that Red Hat likes better. I'll patch it to also accept comma-separated IP addresses, it's not that big a deal :) Martin From jderose at redhat.com Tue Sep 8 07:12:04 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 08 Sep 2009 01:12:04 -0600 Subject: [Freeipa-devel] [PATCH] jderose 016 Fixed undefined `dns_forwarders` in ipa-server-install Message-ID: <1252393924.2527.20.camel@jgd-dsk> In ipa-server-install, if options.setup_dns is False, the `dns_forwarders` variable doesn't get defined, and so things crap out when bind.setup() is called in line 649. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-016-Fixed-undefined-dns_forwarders.patch Type: text/x-patch Size: 786 bytes Desc: not available URL: From jderose at redhat.com Tue Sep 8 10:37:26 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 08 Sep 2009 04:37:26 -0600 Subject: [Freeipa-devel] [PATCH] jderose 017 Giant WebUI patch part 1 Message-ID: <1252406246.2527.99.camel@jgd-dsk> This is a big patch to get everyone synced up with what I'm doing on the webUI. The Engine is currently *very* dumb because I need to tare through a bunch of plugin metadata, make a lot of changes, but doing that is likely going to make merging any outstanding patches too difficult, break any work in progress. I even I backed out some crazier changes I had made, realizing the headache I was inviting. So what I propose is acking this and acking any other outstanding patches, and then quickly making the needed metadata changes in a coordinated fashion (read: Rob, Pavel, and I staying pretty much lock-step for a few days). The metadata changes aren't a lot of work, but they are very disruptive as they will change the plugin API slightly and will affect every Command and Object plugin we have (which by my count is currently 108 plugins). Some highlights: * lite-xmlrpc.py and lite-webui.py have been replaced by the new lite-server.py script, which mounts XML-RPC, JSON-RPC, and the WebUI all on the same paths as they would be under Apache (but on a different port). * Per above, the default xmlrpc_uri is now http://localhost:8888/ipa/xml * The IPA server is now a WSGI application. A few pieces still are missing, most notably running all this under Apache, but it's 90% there. Currently under Apache things will still run the same as before, just XML-RPC and not through the new Backend.xmlserver WSGI interface. Because IPA is a WSGI app, I think we should strongly consider running IPA under mod_wsgi instead of mod_python, although running under mod_python is still possible with a mod_python <=> WSGI adapter. * For flexibility and to ease debugging, the XML-RPC and JSON-RPC services can now also be called via GET or POST query strings. For example: http://localhost:8888/ipa/json/user_add?givenname=Jason&sn=DeRose Or http://localhost:8888/ipa/xml/user_add?givenname=Jason&sn=DeRose Is the same as: api.Command.user_add(givenname='Jason', sn='DeRose') * In theory, lite-server.py supports SSL, but there is a bug in paste 1.7.2 that prevents it from working under Python 2.6. To turn on SSL, just place a PEM format cert at ~/.ipa/lite.pem Anyway, this gives everyone something to play with/review till I get back from PTO on Thursday. Cheers, Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-017-Giant-WebUI-patch-part-1.patch Type: text/x-patch Size: 166266 bytes Desc: not available URL: From mnagy at redhat.com Tue Sep 8 11:09:57 2009 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 08 Sep 2009 13:09:57 +0200 Subject: [Freeipa-devel] [PATCH] jderose 016 Fixed undefined `dns_forwarders` in ipa-server-install In-Reply-To: <1252393924.2527.20.camel@jgd-dsk> References: <1252393924.2527.20.camel@jgd-dsk> Message-ID: <1252408197.32049.189.camel@wolverine.englab.brq.redhat.com> On Tue, 2009-09-08 at 01:12 -0600, Jason Gerard DeRose wrote: > In ipa-server-install, if options.setup_dns is False, the > `dns_forwarders` variable doesn't get defined, and so things crap out > when bind.setup() is called in line 649. Ack and pushed. Martin From mnagy at redhat.com Tue Sep 8 11:13:26 2009 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 08 Sep 2009 13:13:26 +0200 Subject: [Freeipa-devel] [PATCH] Add forgotten chunks from commit 4e5a68397a102f0be Message-ID: <1252408406.32049.190.camel@wolverine.englab.brq.redhat.com> I accidentally pushed the older patch that didn't contain bits for ipa-replica-install. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-forgotten-chunks-from-commit-4e5a68397a102f0be.patch Type: text/x-patch Size: 3814 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:01:33 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:01:33 +0200 Subject: [Freeipa-devel] [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hate'em. Message-ID: <4AA655AD.2090607@redhat.com> I posted this patch on freeipa-devel a while ago. We had a discussion with Jason about converting unused parameter values to None, but it died for some reason. Anyway this patch is required if we want to prevent things from blowing up when someone accidentally passes a None value to ldap2.add_entry (python-ldap doesn't like Nones). Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-ldap2.add_entry-proof-to-None-values-because-p.patch Type: application/mbox Size: 963 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:08:01 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:08:01 +0200 Subject: [Freeipa-devel] [PATCH] Fix bug in dns_find - execute() returned different value than expected. Message-ID: <4AA65731.70407@redhat.com> dns_find.execute() wasn't returning the truncated (truncated search results) flag. It threw an exception when invoked. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-bug-in-dns_find-execute-returned-different-v.patch Type: application/mbox Size: 784 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:12:50 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:12:50 +0200 Subject: [Freeipa-devel] [PATCH] Improve attribute printing in the CLI. Message-ID: <4AA65852.3060106@redhat.com> This patch makes printing of LDAP attributes more versatile. The caller can now choose if attributes with more than one value should be printed on one line (each value separated by ', ') or on several lines (each value on its own line). In the later case, the patch also introduces smart word wrapping. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Improve-attribute-printing-in-the-CLI.patch Type: application/mbox Size: 2767 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:17:11 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:17:11 +0200 Subject: [Freeipa-devel] [PATCH] Remove obsolete CRUD base classes as they aren't used anymore. Message-ID: <4AA65957.8080900@redhat.com> This removes legacy CRUD base classes (Add, Get, Del, Mod, Find) that aren't (and won't be) used anymore. They have been replaced by Create, Retrieve, Update, Delete and Search (and their LDAP oriented extensions). Note: This patch doesn't remove unit tests associated with these classes, but I'll be posting a patch soon that does. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Remove-obsolete-CRUD-base-classes-as-they-aren-t-use.patch Type: application/mbox Size: 1849 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:25:35 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:25:35 +0200 Subject: [Freeipa-devel] [PATCHES] Improve ipalib.plugins.baseldap classes. Message-ID: <4AA65B4F.4000009@redhat.com> - remove obsolete code related to PluginProxy - remove parent_key attribute, for the purpose of nested objects the parent's primary key is retrieved automatically - added support for auto-generating UUIDs - make use of the improved attribute printing in CLI !!! depends on previous patch !!! - make LDAPDelete delete all sub-entries, not just one-level - minor bug fixes This patch is pretty important, it makes little functional difference to IPA by itself, but it is going to be required by subsequent patches that make plugins use the baseldap classes. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Improve-ipalib.plugins.baseldap-classes.patch Type: application/mbox Size: 13074 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:30:48 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:30:48 +0200 Subject: [Freeipa-devel] [PATCH] Fix: Object.params_minus_pk was invalid when there was no primary_key. Message-ID: <4AA65C88.9060902@redhat.com> params_minus_pk was set to None when there was no primary_key=True parameter. This patch changes this, so that params_minus_pk is set to a reference to params. It makes special cases easier to handle and I think it makes sense that: C - 0 = C Anyway I did it, because there were some blow ups when testing plugins and this fixed it without having to do checks everywhere. (And it doesn't hurt anything as far as I checked.) Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Fix-Object.params_minus_pk-was-invalid-when-there-w.patch Type: application/mbox Size: 857 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:39:49 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:39:49 +0200 Subject: [Freeipa-devel] [PATCHES] Add support for different automount maps per location. Message-ID: <4AA65EA5.5030409@redhat.com> 0007: Add support for different automount maps per location. This patch enabled us to have a different set of automount maps per location and to manage those locations via command plugins. To add a new location: ipa automountlocation-add Brno To add a map to this location: ipa automountmap-add Brno foo To add a key to this map: ipa automountkey-add Brno foomap barkey 0008: Remove parent_key parameter kwarg. I bundled this patch here, because parent_key was only used in the automount plugin. If patch 0007 gets acked, this can get acked too. parent_key won't be used anymore, instead parent_object is used in LDAPObject to define this kind of relation. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Add-support-for-different-automount-maps-per-locatio.patch Type: application/mbox Size: 8550 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Remove-parent_key-parameter-kwarg.patch Type: application/mbox Size: 1464 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:45:04 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:45:04 +0200 Subject: [Freeipa-devel] [PATCH] Fix typos and minor bugs in baseldap. Add --all to LDAPUpdate. Message-ID: <4AA65FE0.2050900@redhat.com> Fixes some minor things in baseldap. It also add the --all options (to display all attribute) to LDAPUpdate. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Fix-typos-and-minor-bugs-in-baseldap.-Add-all-to-L.patch Type: application/mbox Size: 3707 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 13:46:59 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 15:46:59 +0200 Subject: [Freeipa-devel] [PATCH] Automatically generate an auto.master map for new automount location. Message-ID: <4AA66053.4090900@redhat.com> I thought that it might be a good idea to automatically generate the auto.master map for new locations. It depends on my previous automount patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Automatically-generate-an-auto.master-map-for-new-au.patch Type: application/mbox Size: 1290 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 8 14:03:19 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Tue, 08 Sep 2009 16:03:19 +0200 Subject: [Freeipa-devel] [PATCHES] Make plugins use baseldap classes. Message-ID: <4AA66427.1050404@redhat.com> This is a series of patches that depends on patches: - Improve attribute printing in the CLI. - Improve ipalib.plugins.baseldap classes. All plugins are converted to extend baseldap classes. This makes things more consistent, fixes some general bugs (with return values for example) and it also makes plugins easier to maintain (as it removes a lot of duplicate code). Because baseldap classes have features that enable us to define relationships between plugins, I thought it might be best to submit all of the conversions at once and have all the relationships fully defined. Affected plugins: config user host service group hostgroup netgroup rolegroup taskgroup pwpolicy There's also a patch that fixes all unit tests. Jenny, I included you to Cc, because the patch introduces a lot of changes to the UI (and you're probably not going to like me for this). Each command extending the LDAP* base classes now has a --raw option. Without it, data from LDAP is formated and translated to human readable. For example: # ipa user-show admin --all ---------- user-show: ---------- User: admin user id: admin full name: Administrator last name: Administrator home directory: /home/admin login shell: /bin/bash uid number: 999 gid number: 1001 gecos: Administrator kerberos principal: admin at PZUNA last password change: 20090904122852Z password expiration: 20091203122852Z member of groups: admins # ipa user-show admin --all --raw ---------- user-show: ---------- dn: uid=admin,cn=users,cn=accounts,dc=pzuna uid: admin cn: Administrator sn: Administrator homedirectory: /home/admin loginshell: /bin/bash uidnumber: 999 gidnumber: 1001 gecos: Administrator krbprincipalname: admin at PZUNA krblastpwdchange: 20090904122852Z krbpasswordexpiration: 20091203122852Z memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna objectclass: top objectclass: person objectclass: posixaccount objectclass: krbprincipalaux objectclass: inetuser Advantages: more user friendly, allows for easy localization, translation of DNs to primary keys (immediately usable as input to other plugin commands) I recommend, that you use the --raw flag for testing. I know it's a lot of changes, so I setup a git repo at: git://fedorapeople.org/~pzuna/freeipa.git It should be up-to-date with master and all my patches are applied there. I hope it makes reviewing them at least a bit easier. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0021-Make-pwpolicy-plugin-use-baseldap-classes.patch Type: application/mbox Size: 6254 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Make-the-config-plugin-use-baseldap-classes.patch Type: application/mbox Size: 7037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Make-the-user-plugin-use-baseldap-classes.patch Type: application/mbox Size: 13494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Make-the-host-plugin-use-baseldap-classes.patch Type: application/mbox Size: 12719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Make-the-service-plugin-use-baseldap-classes.patch Type: application/mbox Size: 12291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Make-the-group-plugin-use-baseldap-classes.patch Type: application/mbox Size: 8398 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Make-the-hostgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 8568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-Make-the-netgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 16597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-Make-the-rolegroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 4147 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019-Make-the-taskgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 7463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0020-Fix-unit-tests-for-plugins-using-baseldap-classes.patch Type: application/mbox Size: 47143 bytes Desc: not available URL: From rcritten at redhat.com Tue Sep 8 17:33:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 13:33:04 -0400 Subject: [Freeipa-devel] [PATCH] jderose 017 Giant WebUI patch part 1 In-Reply-To: <1252406246.2527.99.camel@jgd-dsk> References: <1252406246.2527.99.camel@jgd-dsk> Message-ID: <4AA69550.5030506@redhat.com> Jason Gerard DeRose wrote: > This is a big patch to get everyone synced up with what I'm doing on the webUI. > The Engine is currently *very* dumb because I need to tare through a bunch of > plugin metadata, make a lot of changes, but doing that is likely going to make > merging any outstanding patches too difficult, break any work in progress. I > even I backed out some crazier changes I had made, realizing the headache I was > inviting. > > So what I propose is acking this and acking any other outstanding patches, and > then quickly making the needed metadata changes in a coordinated fashion (read: > Rob, Pavel, and I staying pretty much lock-step for a few days). The metadata > changes aren't a lot of work, but they are very disruptive as they will change > the plugin API slightly and will affect every Command and Object plugin we have > (which by my count is currently 108 plugins). > > Some highlights: > > * lite-xmlrpc.py and lite-webui.py have been replaced by the new lite-server.py > script, which mounts XML-RPC, JSON-RPC, and the WebUI all on the same paths > as they would be under Apache (but on a different port). > > * Per above, the default xmlrpc_uri is now http://localhost:8888/ipa/xml > > * The IPA server is now a WSGI application. A few pieces still are missing, most > notably running all this under Apache, but it's 90% there. Currently under > Apache things will still run the same as before, just XML-RPC and not through > the new Backend.xmlserver WSGI interface. Because IPA is a WSGI app, I think > we should strongly consider running IPA under mod_wsgi instead of mod_python, > although running under mod_python is still possible with a mod_python <=> WSGI > adapter. > > * For flexibility and to ease debugging, the XML-RPC and JSON-RPC services can > now also be called via GET or POST query strings. For example: > > http://localhost:8888/ipa/json/user_add?givenname=Jason&sn=DeRose > > Or > > http://localhost:8888/ipa/xml/user_add?givenname=Jason&sn=DeRose > > Is the same as: > > api.Command.user_add(givenname='Jason', sn='DeRose') > > * In theory, lite-server.py supports SSL, but there is a bug in paste 1.7.2 that > prevents it from working under Python 2.6. To turn on SSL, just place a PEM > format cert at ~/.ipa/lite.pem > > > Anyway, this gives everyone something to play with/review till I get back from > PTO on Thursday. > > Cheers, > Jason Have a bunch of questions/issues before I can ack this: - We need to get the wehjit library accepted into Fedora ASAP - There is a change to ipa-server-install that reverts your previous patch, 016 - This patch includes the previous SSO patch that we can't commit until we get an alternative for the Crypto package on some distros - Is it going to be confusing to register the jsonserver in a file named xmlserver.py? - in rpcserver.py::extract_query(environ) should an error be raised if these conditions aren't met? For example, you do a POST and the content-type isn't application/x-www-form-urlencoded Otherwise looks ok. I'm not opposed to switching to WSGI as long as we have feature parity. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 8 17:38:37 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 13:38:37 -0400 Subject: [Freeipa-devel] Re: [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hate'em. In-Reply-To: <4AA655AD.2090607@redhat.com> References: <4AA655AD.2090607@redhat.com> Message-ID: <4AA6969D.205@redhat.com> Pavel Z?na wrote: > I posted this patch on freeipa-devel a while ago. We had a discussion > with Jason about converting unused parameter values to None, but it died > for some reason. Anyway this patch is required if we want to prevent > things from blowing up when someone accidentally passes a None value to > ldap2.add_entry (python-ldap doesn't like Nones). > > Pavel ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 8 17:39:17 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 13:39:17 -0400 Subject: [Freeipa-devel] [PATCH] Fix bug in dns_find - execute() returned different value than expected. In-Reply-To: <4AA65731.70407@redhat.com> References: <4AA65731.70407@redhat.com> Message-ID: <4AA696C5.6060105@redhat.com> Pavel Z?na wrote: > dns_find.execute() wasn't returning the truncated (truncated search > results) flag. It threw an exception when invoked. > ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Sep 8 17:39:38 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Sep 2009 13:39:38 -0400 Subject: [Freeipa-devel] [PATCH] Add forgotten chunks from commit 4e5a68397a102f0be In-Reply-To: <1252408406.32049.190.camel@wolverine.englab.brq.redhat.com> References: <1252408406.32049.190.camel@wolverine.englab.brq.redhat.com> Message-ID: <1252431578.9745.16.camel@localhost.localdomain> On Tue, 2009-09-08 at 13:13 +0200, Martin Nagy wrote: > I accidentally pushed the older patch that didn't contain bits for > ipa-replica-install. ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Sep 8 17:42:10 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 13:42:10 -0400 Subject: [Freeipa-devel] [PATCH] Improve attribute printing in the CLI. In-Reply-To: <4AA65852.3060106@redhat.com> References: <4AA65852.3060106@redhat.com> Message-ID: <4AA69772.9060703@redhat.com> Pavel Z?na wrote: > This patch makes printing of LDAP attributes more versatile. > > The caller can now choose if attributes with more than one value should > be printed on one line (each value separated by ', ') or on several > lines (each value on its own line). In the later case, the patch also > introduces smart word wrapping. > ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 8 17:44:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 13:44:04 -0400 Subject: [Freeipa-devel] [PATCH] Remove obsolete CRUD base classes as they aren't used anymore. In-Reply-To: <4AA65957.8080900@redhat.com> References: <4AA65957.8080900@redhat.com> Message-ID: <4AA697E4.2010002@redhat.com> Pavel Z?na wrote: > This removes legacy CRUD base classes (Add, Get, Del, Mod, Find) that > aren't (and won't be) used anymore. They have been replaced by Create, > Retrieve, Update, Delete and Search (and their LDAP oriented extensions). > > Note: This patch doesn't remove unit tests associated with these > classes, but I'll be posting a patch soon that does. > ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 8 17:54:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 13:54:05 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Improve ipalib.plugins.baseldap classes. In-Reply-To: <4AA65B4F.4000009@redhat.com> References: <4AA65B4F.4000009@redhat.com> Message-ID: <4AA69A3D.6060208@redhat.com> Pavel Z?na wrote: > - remove obsolete code related to PluginProxy > - remove parent_key attribute, for the purpose of nested objects the > parent's primary key is retrieved automatically > - added support for auto-generating UUIDs > - make use of the improved attribute printing in CLI > !!! depends on previous patch !!! > - make LDAPDelete delete all sub-entries, not just one-level > - minor bug fixes > > This patch is pretty important, it makes little functional difference to > IPA by itself, but it is going to be required by subsequent patches that > make plugins use the baseldap classes. > > Pavel nack I don't think we want the user to be able to set their own uuid. We want this assigned by the system. Otherwise I think it looks fine. Deleting a subtree still makes me nervous but since it is called within the framework I think it should be ok. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Tue Sep 8 20:51:17 2009 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 8 Sep 2009 22:51:17 +0200 Subject: [Freeipa-devel] [PATCH] Add forgotten chunks from commit 4e5a68397a102f0be In-Reply-To: <1252431578.9745.16.camel@localhost.localdomain> References: <1252408406.32049.190.camel@wolverine.englab.brq.redhat.com> <1252431578.9745.16.camel@localhost.localdomain> Message-ID: <20090908225117.7026966e@notas> Simo Sorce wrote: > On Tue, 2009-09-08 at 13:13 +0200, Martin Nagy wrote: > > I accidentally pushed the older patch that didn't contain bits for > > ipa-replica-install. > > ack. > Simo. Pushed to master. Martin From dpal at redhat.com Tue Sep 8 21:43:09 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 08 Sep 2009 17:43:09 -0400 Subject: [Freeipa-devel] [PATCH] jderose 017 Giant WebUI patch part 1 In-Reply-To: <4AA69550.5030506@redhat.com> References: <1252406246.2527.99.camel@jgd-dsk> <4AA69550.5030506@redhat.com> Message-ID: <4AA6CFED.9030107@redhat.com> Rob Crittenden wrote: > Jason Gerard DeRose wrote: >> This is a big patch to get everyone synced up with what I'm doing on >> the webUI. >> The Engine is currently *very* dumb because I need to tare through a >> bunch of >> plugin metadata, make a lot of changes, but doing that is likely >> going to make >> merging any outstanding patches too difficult, break any work in >> progress. I >> even I backed out some crazier changes I had made, realizing the >> headache I was >> inviting. >> >> So what I propose is acking this and acking any other outstanding >> patches, and >> then quickly making the needed metadata changes in a coordinated >> fashion (read: >> Rob, Pavel, and I staying pretty much lock-step for a few days). The >> metadata >> changes aren't a lot of work, but they are very disruptive as they >> will change >> the plugin API slightly and will affect every Command and Object >> plugin we have >> (which by my count is currently 108 plugins). >> >> Some highlights: >> >> * lite-xmlrpc.py and lite-webui.py have been replaced by the new >> lite-server.py >> script, which mounts XML-RPC, JSON-RPC, and the WebUI all on the >> same paths >> as they would be under Apache (but on a different port). >> >> * Per above, the default xmlrpc_uri is now http://localhost:8888/ipa/xml >> >> * The IPA server is now a WSGI application. A few pieces still are >> missing, most >> notably running all this under Apache, but it's 90% there. >> Currently under >> Apache things will still run the same as before, just XML-RPC and >> not through >> the new Backend.xmlserver WSGI interface. Because IPA is a WSGI >> app, I think >> we should strongly consider running IPA under mod_wsgi instead of >> mod_python, >> although running under mod_python is still possible with a >> mod_python <=> WSGI >> adapter. >> >> * For flexibility and to ease debugging, the XML-RPC and JSON-RPC >> services can >> now also be called via GET or POST query strings. For example: >> >> http://localhost:8888/ipa/json/user_add?givenname=Jason&sn=DeRose >> >> Or >> >> http://localhost:8888/ipa/xml/user_add?givenname=Jason&sn=DeRose >> >> Is the same as: >> >> api.Command.user_add(givenname='Jason', sn='DeRose') >> >> * In theory, lite-server.py supports SSL, but there is a bug in paste >> 1.7.2 that >> prevents it from working under Python 2.6. To turn on SSL, just >> place a PEM >> format cert at ~/.ipa/lite.pem >> >> >> Anyway, this gives everyone something to play with/review till I get >> back from >> PTO on Thursday. >> >> Cheers, >> Jason > > Have a bunch of questions/issues before I can ack this: > > - We need to get the wehjit library accepted into Fedora ASAP > - There is a change to ipa-server-install that reverts your previous > patch, 016 > - This patch includes the previous SSO patch that we can't commit > until we get an alternative for the Crypto package on some distros > - Is it going to be confusing to register the jsonserver in a file > named xmlserver.py? > - in rpcserver.py::extract_query(environ) should an error be raised if > these conditions aren't met? For example, you do a POST and the > content-type isn't application/x-www-form-urlencoded > > Otherwise looks ok. I'm not opposed to switching to WSGI as long as we > have feature parity. > > rob How the addition of the wehjit library affects our ability to run on RHEL 5.5? > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Sep 8 23:51:24 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Sep 2009 19:51:24 -0400 Subject: [Freeipa-devel] [PATCH] 265 fix dnaMaxValue Message-ID: <4AA6EDFC.7080901@redhat.com> Ensure that dnaMaxValue is higher than dnaNextValue at install time. If you don't specify a specific uid/gid start value then a random one gets set. We need to be sure that the max value is more than this. I picked a 100000 range to ensure that there is some headroom for replicas. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-265-maxvalue.patch Type: application/mbox Size: 1006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From davido at redhat.com Wed Sep 9 01:03:37 2009 From: davido at redhat.com (David O'Brien) Date: Wed, 09 Sep 2009 11:03:37 +1000 Subject: [Freeipa-devel] [PATCH] jderose 016 Fixed undefined `dns_forwarders` in ipa-server-install In-Reply-To: <1252393924.2527.20.camel@jgd-dsk> References: <1252393924.2527.20.camel@jgd-dsk> Message-ID: <4AA6FEE9.1090304@redhat.com> Jason Gerard DeRose wrote: > In ipa-server-install, if options.setup_dns is False, the > `dns_forwarders` variable doesn't get defined, and so things crap out > when bind.setup() is called in line 649. > I'm assuming this is what causes the "local variable 'dns_forwarders' referenced before assignment" error in the install process? Can I work around this just by using --no-forwarders? (I'm about to find out...) -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 "The most valuable of all talents is that of never using two words when one will do." Thomas Jefferson From pzuna at redhat.com Wed Sep 9 12:42:30 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 09 Sep 2009 14:42:30 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Improve ipalib.plugins.baseldap classes. In-Reply-To: <4AA69A3D.6060208@redhat.com> References: <4AA65B4F.4000009@redhat.com> <4AA69A3D.6060208@redhat.com> Message-ID: <4AA7A2B6.7060905@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> - remove obsolete code related to PluginProxy >> - remove parent_key attribute, for the purpose of nested objects the >> parent's primary key is retrieved automatically >> - added support for auto-generating UUIDs >> - make use of the improved attribute printing in CLI >> !!! depends on previous patch !!! >> - make LDAPDelete delete all sub-entries, not just one-level >> - minor bug fixes >> >> This patch is pretty important, it makes little functional difference >> to IPA by itself, but it is going to be required by subsequent patches >> that make plugins use the baseldap classes. >> >> Pavel > > nack > > I don't think we want the user to be able to set their own uuid. We want > this assigned by the system. None of the LDAP* commands base classes allow the user to set their own uuid. If uuid_attribute is set in LDAPObject, LDAPCreate generates the uuid automatically (using `str(uuid.uuid1())`) and LDAPSearch allows searching by uuid. > Otherwise I think it looks fine. Deleting a subtree still makes me > nervous but since it is called within the framework I think it should be > ok. > > rob Pavel From rcritten at redhat.com Wed Sep 9 13:54:56 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Sep 2009 09:54:56 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Improve ipalib.plugins.baseldap classes. In-Reply-To: <4AA7A2B6.7060905@redhat.com> References: <4AA65B4F.4000009@redhat.com> <4AA69A3D.6060208@redhat.com> <4AA7A2B6.7060905@redhat.com> Message-ID: <4AA7B3B0.3050008@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> - remove obsolete code related to PluginProxy >>> - remove parent_key attribute, for the purpose of nested objects the >>> parent's primary key is retrieved automatically >>> - added support for auto-generating UUIDs >>> - make use of the improved attribute printing in CLI >>> !!! depends on previous patch !!! >>> - make LDAPDelete delete all sub-entries, not just one-level >>> - minor bug fixes >>> >>> This patch is pretty important, it makes little functional difference >>> to IPA by itself, but it is going to be required by subsequent >>> patches that make plugins use the baseldap classes. >>> >>> Pavel >> >> nack >> >> I don't think we want the user to be able to set their own uuid. We >> want this assigned by the system. > None of the LDAP* commands base classes allow the user to set their own > uuid. If uuid_attribute is set in LDAPObject, LDAPCreate generates the > uuid automatically (using `str(uuid.uuid1())`) and LDAPSearch allows > searching by uuid. Ok, I missed where it was limited to searching. ack, pushed to master rob > >> Otherwise I think it looks fine. Deleting a subtree still makes me >> nervous but since it is called within the framework I think it should >> be ok. >> >> rob > > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 9 13:56:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Sep 2009 09:56:50 -0400 Subject: [Freeipa-devel] [PATCH] Fix: Object.params_minus_pk was invalid when there was no primary_key. In-Reply-To: <4AA65C88.9060902@redhat.com> References: <4AA65C88.9060902@redhat.com> Message-ID: <4AA7B422.10200@redhat.com> Pavel Z?na wrote: > params_minus_pk was set to None when there was no primary_key=True > parameter. > > This patch changes this, so that params_minus_pk is set to a reference > to params. It makes special cases easier to handle and I think it makes > sense that: > > C - 0 = C > > Anyway I did it, because there were some blow ups when testing plugins > and this fixed it without having to do checks everywhere. (And it > doesn't hurt anything as far as I checked.) > ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 9 13:59:02 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Sep 2009 09:59:02 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for different automount maps per location. In-Reply-To: <4AA65EA5.5030409@redhat.com> References: <4AA65EA5.5030409@redhat.com> Message-ID: <4AA7B4A6.8000004@redhat.com> Pavel Z?na wrote: > 0007: Add support for different automount maps per location. > > This patch enabled us to have a different set of automount maps per > location and to manage those locations via command plugins. > > To add a new location: > > ipa automountlocation-add Brno > > To add a map to this location: > > ipa automountmap-add Brno foo > > To add a key to this map: > > ipa automountkey-add Brno foomap barkey > > > 0008: Remove parent_key parameter kwarg. > I bundled this patch here, because parent_key was only used in the > automount plugin. If patch 0007 gets acked, this can get acked too. > > parent_key won't be used anymore, instead parent_object is used in > LDAPObject to define this kind of relation. > > Pavel Can you provide some examples of how location will be used on the command-line (e.g. show how 2 new maps with a key would be added to 2 locations). thanks rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 9 14:00:25 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Sep 2009 10:00:25 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for different automount maps per location. In-Reply-To: <4AA7B4A6.8000004@redhat.com> References: <4AA65EA5.5030409@redhat.com> <4AA7B4A6.8000004@redhat.com> Message-ID: <4AA7B4F9.2030000@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> 0007: Add support for different automount maps per location. >> >> This patch enabled us to have a different set of automount maps per >> location and to manage those locations via command plugins. >> >> To add a new location: >> >> ipa automountlocation-add Brno >> >> To add a map to this location: >> >> ipa automountmap-add Brno foo >> >> To add a key to this map: >> >> ipa automountkey-add Brno foomap barkey >> >> >> 0008: Remove parent_key parameter kwarg. >> I bundled this patch here, because parent_key was only used in the >> automount plugin. If patch 0007 gets acked, this can get acked too. >> >> parent_key won't be used anymore, instead parent_object is used in >> LDAPObject to define this kind of relation. >> >> Pavel > > Can you provide some examples of how location will be used on the > command-line (e.g. show how 2 new maps with a key would be added to 2 > locations). And to be clear, I did read your previous example :-) I just don't see where the key comes from. I'm wondering if it is really going to be a multi-step process to add new maps. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Wed Sep 9 14:36:51 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 09 Sep 2009 16:36:51 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Add support for different automount maps per location. In-Reply-To: <4AA7B4F9.2030000@redhat.com> References: <4AA65EA5.5030409@redhat.com> <4AA7B4A6.8000004@redhat.com> <4AA7B4F9.2030000@redhat.com> Message-ID: <4AA7BD83.3060208@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> 0007: Add support for different automount maps per location. >>> >>> This patch enabled us to have a different set of automount maps per >>> location and to manage those locations via command plugins. >>> >>> To add a new location: >>> >>> ipa automountlocation-add Brno >>> >>> To add a map to this location: >>> >>> ipa automountmap-add Brno foo >>> >>> To add a key to this map: >>> >>> ipa automountkey-add Brno foomap barkey >>> >>> >>> 0008: Remove parent_key parameter kwarg. >>> I bundled this patch here, because parent_key was only used in the >>> automount plugin. If patch 0007 gets acked, this can get acked too. >>> >>> parent_key won't be used anymore, instead parent_object is used in >>> LDAPObject to define this kind of relation. >>> >>> Pavel >> >> Can you provide some examples of how location will be used on the >> command-line (e.g. show how 2 new maps with a key would be added to 2 >> locations). > > And to be clear, I did read your previous example :-) I just don't see > where the key comes from. I'm wondering if it is really going to be a > multi-step process to add new maps. > > rob > I'm not sure if this is what you want to see, but: # ipa automountlocation-add Brno # ipa automountlocation-add Baltimore # ipa automountmap-add-indirect Brno auto.mnt --mount="/mnt" # ipa automountmap-add-indirect Baltimore auto.media --mount="/media" # ipa automountkey-add Brno auto.mnt stuff --info="-ro,soft,rsize=8192,wsize=8192 nfs.example.com:/vol/archive/stuff" # ipa automountkey-add Baltimore auto.media stuff --info="-ro,soft,rsize=8192,wsize=8192 nfs.example.com:/vol/archive/stuff" # ipa automountlocation-tofiles Brno /etc/auto.master: /mnt /etc/auto.mnt --------------------------- /etc/auto.mnt: stuff -ro,soft,rsize=8192,wsize=8192 nfs.example.com:/vol/archive/stuff # ipa automountlocation-tofiles Baltimore /etc/auto.master: /media /etc/auto.media --------------------------- /etc/auto.mnt: stuff -ro,soft,rsize=8192,wsize=8192 nfs.example.com:/vol/archive/stuff Pavel From mnagy at redhat.com Wed Sep 9 23:48:40 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 10 Sep 2009 01:48:40 +0200 Subject: [Freeipa-devel] [PATCH] 265 fix dnaMaxValue In-Reply-To: <4AA6EDFC.7080901@redhat.com> References: <4AA6EDFC.7080901@redhat.com> Message-ID: <20090910014840.272136ba@notas> Rob Crittenden wrote: > Ensure that dnaMaxValue is higher than dnaNextValue at install time. If > you don't specify a specific uid/gid start value then a random one gets > set. We need to be sure that the max value is more than this. > > I picked a 100000 range to ensure that there is some headroom for replicas. > > rob Ack. Martin From mnagy at redhat.com Wed Sep 9 23:52:35 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 10 Sep 2009 01:52:35 +0200 Subject: [Freeipa-devel] [PATCH] jderose 016 Fixed undefined `dns_forwarders` in ipa-server-install In-Reply-To: <4AA6FEE9.1090304@redhat.com> References: <1252393924.2527.20.camel@jgd-dsk> <4AA6FEE9.1090304@redhat.com> Message-ID: <20090910015235.27693427@notas> David O'Brien wrote: > Jason Gerard DeRose wrote: > > In ipa-server-install, if options.setup_dns is False, the > > `dns_forwarders` variable doesn't get defined, and so things crap out > > when bind.setup() is called in line 649. > > > > I'm assuming this is what causes the "local variable 'dns_forwarders' > referenced before assignment" error in the install process? Can I work > around this just by using --no-forwarders? (I'm about to find out...) Yes, but then you have to also use --setup-dns. You can try to apply the patch, or simply just apply the changes by hand. But this is already pushed in git, so.. Martin From rcritten at redhat.com Thu Sep 10 02:06:32 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Sep 2009 22:06:32 -0400 Subject: [Freeipa-devel] [PATCH] 265 fix dnaMaxValue In-Reply-To: <20090910014840.272136ba@notas> References: <4AA6EDFC.7080901@redhat.com> <20090910014840.272136ba@notas> Message-ID: <4AA85F28.5020607@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> Ensure that dnaMaxValue is higher than dnaNextValue at install time. If >> you don't specify a specific uid/gid start value then a random one gets >> set. We need to be sure that the max value is more than this. >> >> I picked a 100000 range to ensure that there is some headroom for replicas. >> >> rob > > Ack. > Martin pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Thu Sep 10 13:28:36 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 10 Sep 2009 15:28:36 +0200 Subject: [Freeipa-devel] [PATCH] Fix incorrect imports in ipa-server-certinstall. [Was: consistent use of --help on CLI?] In-Reply-To: <4AA8F86C.6020902@redhat.com> References: <4AA886BD.5050006@redhat.com> <4AA8F472.3080501@redhat.com> <4AA8F86C.6020902@redhat.com> Message-ID: <4AA8FF04.1000304@redhat.com> Fixed. Pavel Zuna wrote: > Dmitri Pal wrote: >> Pavel, Rob, >> >> What do the CLI utils do when someone uses "--help" parameter? >> Is there a consistent behavior about this? >> >> Thanks >> Dmitri > Yes there is, we use OptionParser from python optparse module everywhere > as far as I know and it handles -h/--help by default. > >> >> >> David O'Brien wrote: >>> Is this achievable or desirable? Instead of the results below, display >>> the man page (like ipa-server-install --help does) or at least not >>> crap out... >>> >>> [root at cairo ~]# ipa-server-certinstall --help >>> Traceback (most recent call last): >>> File "/usr/sbin/ipa-server-certinstall", line 31, in ? >>> from ipaserver import certs, dsinstance, httpinstance, ipaldap, >>> installutils >>> ImportError: cannot import name certs >>> >>> cheers > The problem here, is that python cannot import the certs modules from > ipaserver/install. It has nothing to do with options (--help). If you > run it without it - same results. The rule of thumb in these situations > is to actually read the error message, it might give a hint about where > the problem is. ;-) > > Anyway, I'll try to fix it. > >>> >>> [root at cairo ~]# rpm -qi ipa-server >>> Name : ipa-server Relocations: (not >>> relocatable) >>> Version : 2.0 Vendor: Red Hat, Inc. >>> Release : 3.20090908.el5ipa Build Date: Tue 08 Sep >>> 2009 06:04:31 PM EST >>> Install Date: Wed 09 Sep 2009 10:32:56 AM EST Build Host: >>> x86-005.build.bos.redhat.com >>> Group : System Environment/Base Source RPM: >>> ipa-2.0-3.20090908.el5ipa.src.rpm >>> Size : 2768258 License: GPLv2 >>> >> >> > > Pavel > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-incorrect-imports-in-ipa-server-certinstall.patch Type: application/mbox Size: 979 bytes Desc: not available URL: From rcritten at redhat.com Thu Sep 10 14:02:53 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 10:02:53 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Add support for different automount maps per location. In-Reply-To: <4AA65EA5.5030409@redhat.com> References: <4AA65EA5.5030409@redhat.com> Message-ID: <4AA9070D.4000801@redhat.com> Pavel Z?na wrote: > 0007: Add support for different automount maps per location. > > This patch enabled us to have a different set of automount maps per > location and to manage those locations via command plugins. > > To add a new location: > > ipa automountlocation-add Brno > > To add a map to this location: > > ipa automountmap-add Brno foo > > To add a key to this map: > > ipa automountkey-add Brno foomap barkey > > > 0008: Remove parent_key parameter kwarg. > I bundled this patch here, because parent_key was only used in the > automount plugin. If patch 0007 gets acked, this can get acked too. > > parent_key won't be used anymore, instead parent_object is used in > LDAPObject to define this kind of relation. > > Pavel I'm still not convinced that this should be done as separate classes but I'm not going to hold things up for now (I think this may be problematic in the GUI). Ack for both and pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 14:05:21 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 10:05:21 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix typos and minor bugs in baseldap. Add --all to LDAPUpdate. In-Reply-To: <4AA65FE0.2050900@redhat.com> References: <4AA65FE0.2050900@redhat.com> Message-ID: <4AA907A1.2060705@redhat.com> Pavel Z?na wrote: > Fixes some minor things in baseldap. It also add the --all options (to > display all attribute) to LDAPUpdate. > > Pavel Why are you not returning failed anymore with post_callback? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 14:07:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 10:07:01 -0400 Subject: [Freeipa-devel] Re: [PATCH] Automatically generate an auto.master map for new automount location. In-Reply-To: <4AA66053.4090900@redhat.com> References: <4AA66053.4090900@redhat.com> Message-ID: <4AA90805.6000504@redhat.com> Pavel Z?na wrote: > I thought that it might be a good idea to automatically generate the > auto.master map for new locations. > > It depends on my previous automount patch. > > Pavel Question: do we need a method to return all maps? Jason might need this in the UI. ack and pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Thu Sep 10 14:12:48 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 10 Sep 2009 16:12:48 +0200 Subject: [Freeipa-devel] Re: [PATCH] Automatically generate an auto.master map for new automount location. In-Reply-To: <4AA90805.6000504@redhat.com> References: <4AA66053.4090900@redhat.com> <4AA90805.6000504@redhat.com> Message-ID: <4AA90960.1020509@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> I thought that it might be a good idea to automatically generate the >> auto.master map for new locations. >> >> It depends on my previous automount patch. >> >> Pavel > > Question: do we need a method to return all maps? Jason might need this > in the UI. All maps for a specific location (e.g. Brno) can be retrieved by: # ipa automountmap-find Brno > ack and pushed to master > Pavel From pzuna at redhat.com Thu Sep 10 14:16:44 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Thu, 10 Sep 2009 16:16:44 +0200 Subject: [Freeipa-devel] Re: [PATCH] Fix typos and minor bugs in baseldap. Add --all to LDAPUpdate. In-Reply-To: <4AA907A1.2060705@redhat.com> References: <4AA65FE0.2050900@redhat.com> <4AA907A1.2060705@redhat.com> Message-ID: <4AA90A4C.5080900@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Fixes some minor things in baseldap. It also add the --all options (to >> display all attribute) to LDAPUpdate. >> >> Pavel > > Why are you not returning failed anymore with post_callback? Because that was a mistake, I meant to return dn, but wrote failed for some reason. We only need to return immutable types in callbacks, because everything else can be changed "in place". > rob > Pavel From rcritten at redhat.com Thu Sep 10 14:20:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 10:20:41 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <4A980FF4.3050005@redhat.com> References: <4A980FF4.3050005@redhat.com> Message-ID: <4AA90B39.4080404@redhat.com> Rob Crittenden wrote: > The management framework wasn't working with SELinux over ldapi because > it lacked permission to access the unix socket. This patch grants > permission. > Probably easier to review with the patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-259-selinux.patch Type: application/mbox Size: 1303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Sep 10 14:34:52 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Sep 2009 10:34:52 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <4AA90B39.4080404@redhat.com> References: <4A980FF4.3050005@redhat.com> <4AA90B39.4080404@redhat.com> Message-ID: <1252593292.3046.34.camel@localhost.localdomain> On Thu, 2009-09-10 at 10:20 -0400, Rob Crittenden wrote: > Rob Crittenden wrote: > > The management framework wasn't working with SELinux over ldapi because > > it lacked permission to access the unix socket. This patch grants > > permission. > > > > Probably easier to review with the patch attached. The patch was attached :-) One question comes to mind though, you are giving access to any socket labeled initrc_t (if my selinux policy reading skills are good enough, which may not be). Shouldn't we discuss with the DS team to have a more specific label for this socket ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jgalipea at redhat.com Thu Sep 10 14:40:53 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Thu, 10 Sep 2009 10:40:53 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <1252593292.3046.34.camel@localhost.localdomain> References: <4A980FF4.3050005@redhat.com> <4AA90B39.4080404@redhat.com> <1252593292.3046.34.camel@localhost.localdomain> Message-ID: <4AA90FF5.5060108@redhat.com> Simo Sorce wrote: > On Thu, 2009-09-10 at 10:20 -0400, Rob Crittenden wrote: > >> Rob Crittenden wrote: >> >>> The management framework wasn't working with SELinux over ldapi because >>> it lacked permission to access the unix socket. This patch grants >>> permission. >>> >>> >> Probably easier to review with the patch attached. >> > > The patch was attached :-) > > One question comes to mind though, you are giving access to any socket > labeled initrc_t (if my selinux policy reading skills are good enough, > which may not be). > > Shouldn't we discuss with the DS team to have a more specific label for > this socket ? > Nathan is currently working on the DS SELinux policy ... > Simo. > > -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering From nkinder at redhat.com Thu Sep 10 15:16:24 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 10 Sep 2009 08:16:24 -0700 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <4AA90FF5.5060108@redhat.com> References: <4A980FF4.3050005@redhat.com> <4AA90B39.4080404@redhat.com> <1252593292.3046.34.camel@localhost.localdomain> <4AA90FF5.5060108@redhat.com> Message-ID: <4AA91848.5030509@redhat.com> On 09/10/2009 07:40 AM, Jenny Galipeau wrote: > Simo Sorce wrote: >> On Thu, 2009-09-10 at 10:20 -0400, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> The management framework wasn't working with SELinux over ldapi >>>> because it lacked permission to access the unix socket. This patch >>>> grants permission. >>>> >>> Probably easier to review with the patch attached. >> >> The patch was attached :-) >> >> One question comes to mind though, you are giving access to any socket >> labeled initrc_t (if my selinux policy reading skills are good enough, >> which may not be). >> >> Shouldn't we discuss with the DS team to have a more specific label for >> this socket ? > Nathan is currently working on the DS SELinux policy ... There is no SELinux policy for currently released DS versions, so the context can not be anything DS specific. I would have guessed that the label would be var_run_t since the ldapi socket should be in /var/run/dirsrv, which would inherit the label from the parent directory. In the policy that I'm working on, the ldapi socket has a label of dirsrv_var_run_t. >> Simo. >> > > From ssorce at redhat.com Thu Sep 10 15:22:33 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Sep 2009 11:22:33 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <4A980FF4.3050005@redhat.com> References: <4A980FF4.3050005@redhat.com> Message-ID: <1252596154.3046.35.camel@localhost.localdomain> On Fri, 2009-08-28 at 13:12 -0400, Rob Crittenden wrote: > The management framework wasn't working with SELinux over ldapi > because > it lacked permission to access the unix socket. This patch grants > permission. The patch itself looks good anyway, so it's an ACK for me. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Sep 10 15:24:40 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Sep 2009 11:24:40 -0400 Subject: [Freeipa-devel] [PATCH] 261 Many SELinux fixes In-Reply-To: <4A9854E4.9080801@redhat.com> References: <4A9854E4.9080801@redhat.com> Message-ID: <1252596280.3046.37.camel@localhost.localdomain> On Fri, 2009-08-28 at 18:06 -0400, Rob Crittenden wrote: > The ldapi code I committed yesterday didn't work with SELinux > enabled. > This patch addresses that. ACK, although the same question as for the other patch wrt initrd_t context for the socket remains. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Sep 10 15:41:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 11:41:41 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <1252596154.3046.35.camel@localhost.localdomain> References: <4A980FF4.3050005@redhat.com> <1252596154.3046.35.camel@localhost.localdomain> Message-ID: <4AA91E35.7000808@redhat.com> Simo Sorce wrote: > On Fri, 2009-08-28 at 13:12 -0400, Rob Crittenden wrote: >> The management framework wasn't working with SELinux over ldapi >> because >> it lacked permission to access the unix socket. This patch grants >> permission. > > The patch itself looks good anyway, so it's an ACK for me. > > Simo. > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 15:42:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 11:42:06 -0400 Subject: [Freeipa-devel] [PATCH] 261 Many SELinux fixes In-Reply-To: <1252596280.3046.37.camel@localhost.localdomain> References: <4A9854E4.9080801@redhat.com> <1252596280.3046.37.camel@localhost.localdomain> Message-ID: <4AA91E4E.1060403@redhat.com> Simo Sorce wrote: > On Fri, 2009-08-28 at 18:06 -0400, Rob Crittenden wrote: >> The ldapi code I committed yesterday didn't work with SELinux >> enabled. >> This patch addresses that. > > ACK, > although the same question as for the other patch wrt initrd_t context > for the socket remains. > > Simo. > Ok, pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Sep 10 16:03:30 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Sep 2009 12:03:30 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <4AA91848.5030509@redhat.com> References: <4A980FF4.3050005@redhat.com> <4AA90B39.4080404@redhat.com> <1252593292.3046.34.camel@localhost.localdomain> <4AA90FF5.5060108@redhat.com> <4AA91848.5030509@redhat.com> Message-ID: <1252598610.3046.49.camel@localhost.localdomain> On Thu, 2009-09-10 at 08:16 -0700, Nathan Kinder wrote: > On 09/10/2009 07:40 AM, Jenny Galipeau wrote: > > Simo Sorce wrote: > >> On Thu, 2009-09-10 at 10:20 -0400, Rob Crittenden wrote: > >>> Rob Crittenden wrote: > >>>> The management framework wasn't working with SELinux over ldapi > >>>> because it lacked permission to access the unix socket. This patch > >>>> grants permission. > >>>> > >>> Probably easier to review with the patch attached. > >> > >> The patch was attached :-) > >> > >> One question comes to mind though, you are giving access to any socket > >> labeled initrc_t (if my selinux policy reading skills are good enough, > >> which may not be). > >> > >> Shouldn't we discuss with the DS team to have a more specific label for > >> this socket ? > > Nathan is currently working on the DS SELinux policy ... > There is no SELinux policy for currently released DS versions, so the > context can not be anything DS specific. I would have guessed that the > label would be var_run_t since the ldapi socket should be in > /var/run/dirsrv, which would inherit the label from the parent directory. > > In the policy that I'm working on, the ldapi socket has a label of > dirsrv_var_run_t. Thanks, this is what I was looking for. We will deal with distributing an updated selinux policy once the DS policy is ready and shipped. Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Thu Sep 10 16:50:56 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 10 Sep 2009 09:50:56 -0700 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi In-Reply-To: <4AA91848.5030509@redhat.com> References: <4A980FF4.3050005@redhat.com> <4AA90B39.4080404@redhat.com> <1252593292.3046.34.camel@localhost.localdomain> <4AA90FF5.5060108@redhat.com> <4AA91848.5030509@redhat.com> Message-ID: <4AA92E70.2060300@redhat.com> On 09/10/2009 08:16 AM, Nathan Kinder wrote: > On 09/10/2009 07:40 AM, Jenny Galipeau wrote: >> Simo Sorce wrote: >>> On Thu, 2009-09-10 at 10:20 -0400, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> The management framework wasn't working with SELinux over ldapi >>>>> because it lacked permission to access the unix socket. This patch >>>>> grants permission. >>>>> >>>> Probably easier to review with the patch attached. >>> >>> The patch was attached :-) >>> >>> One question comes to mind though, you are giving access to any socket >>> labeled initrc_t (if my selinux policy reading skills are good enough, >>> which may not be). >>> >>> Shouldn't we discuss with the DS team to have a more specific label for >>> this socket ? >> Nathan is currently working on the DS SELinux policy ... > There is no SELinux policy for currently released DS versions, so the > context can not be anything DS specific. I would have guessed that > the label would be var_run_t since the ldapi socket should be in > /var/run/dirsrv, which would inherit the label from the parent directory. I want to correct myself just to avoid confusion. The ldapi socket will be in /var/run, not /var/run/dirsrv. It was moved a while back to be in a more standard location. I'm pretty sure that Rob has already encountered this, but I didn't want to spread any incorrect information. > > In the policy that I'm working on, the ldapi socket has a label of > dirsrv_var_run_t. >>> Simo. >>> >> >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Thu Sep 10 18:38:52 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 14:38:52 -0400 Subject: [Freeipa-devel] Re: [PATCH] Automatically generate an auto.master map for new automount location. In-Reply-To: <4AA90960.1020509@redhat.com> References: <4AA66053.4090900@redhat.com> <4AA90805.6000504@redhat.com> <4AA90960.1020509@redhat.com> Message-ID: <4AA947BC.30602@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> I thought that it might be a good idea to automatically generate the >>> auto.master map for new locations. >>> >>> It depends on my previous automount patch. >>> >>> Pavel >> >> Question: do we need a method to return all maps? Jason might need >> this in the UI. > > All maps for a specific location (e.g. Brno) can be retrieved by: > > # ipa automountmap-find Brno Sorry, I meant locations. > >> ack and pushed to master >> > > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 20:27:34 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 16:27:34 -0400 Subject: [Freeipa-devel] [PATCH] 266 remove deprecated comment Message-ID: <4AA96136.3010800@redhat.com> Remove comment about plugin naming conventions. We've dumped this convention. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-266-deprecated.patch Type: application/mbox Size: 707 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 20:28:40 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 16:28:40 -0400 Subject: [Freeipa-devel] [PATCH] 267 fix virtual plugin Message-ID: <4AA96178.7080201@redhat.com> Fix the virtual access plugin to work with the new backend. Also do a more explicit objectviolation catch. We will switch this to use GER when that is completed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-267-virtual.patch Type: application/mbox Size: 3077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 20:29:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 16:29:39 -0400 Subject: [Freeipa-devel] [PATCH] 268 explicitly set verbose to false in RPC client Message-ID: <4AA961B3.9030804@redhat.com> I've needed to set verbose to True in the rpc client and every time I have to do this I hunt around trying to figure out where to put it. This will make it easier to find next time :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-268-rpc.patch Type: application/mbox Size: 861 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Sep 10 20:35:16 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Sep 2009 16:35:16 -0400 Subject: [Freeipa-devel] [PATCH] 269 external CA signing, abstract RA Message-ID: <4AA96304.4090903@redhat.com> The RA plugin originally only supported dogtag. At some point I want to be able to do on-line replica creation and this means we need to be able to do remote cert requests. To support this I've abstracted the RA plugin and added basic self-signed CA support. To do this I had to move the CA private key from the DS NSS database to the Apache NSS database. The bulk of the patch adds support for an externally-signed dogtag CA. This is a 2-step process. You run the IPA installer to create the CA instance and generate a CSR. You take this CSR to your primary CA and get it signed, then re-run the IPA installer and pass it this new cert. A lot of our cert functions assumed 1 cert-per-file. I had to remove that assumption and add in a sort of generic nickname generator. It assumes that the certs will be in some sort of order in the file. It doesn't really matter as long as the nicknames are unique. A replica created with a self-signed CA will not be able to issue certs yet. I started this work by enhancing the file used to store the next serial number to also store the next serial number to be used by a replica. The idea is that we ship this to the replica then bump it up by some value so that all replicas are unique. I think we'll have to enforce that replicas can't create other replicas. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-269-external.patch Type: application/mbox Size: 93054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Sep 11 13:20:13 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Sep 2009 09:20:13 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix incorrect imports in ipa-server-certinstall. [Was: consistent use of --help on CLI?] In-Reply-To: <4AA8FF04.1000304@redhat.com> References: <4AA886BD.5050006@redhat.com> <4AA8F472.3080501@redhat.com> <4AA8F86C.6020902@redhat.com> <4AA8FF04.1000304@redhat.com> Message-ID: <4AAA4E8D.7040900@redhat.com> Pavel Zuna wrote: > Fixed. > > Pavel Zuna wrote: >> Dmitri Pal wrote: >>> Pavel, Rob, >>> >>> What do the CLI utils do when someone uses "--help" parameter? >>> Is there a consistent behavior about this? Ack, pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Sep 11 13:22:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Sep 2009 09:22:49 -0400 Subject: [Freeipa-devel] Re: [PATCH] Fix typos and minor bugs in baseldap. Add --all to LDAPUpdate. In-Reply-To: <4AA90A4C.5080900@redhat.com> References: <4AA65FE0.2050900@redhat.com> <4AA907A1.2060705@redhat.com> <4AA90A4C.5080900@redhat.com> Message-ID: <4AAA4F29.2080203@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> Fixes some minor things in baseldap. It also add the --all options >>> (to display all attribute) to LDAPUpdate. >>> >>> Pavel >> >> Why are you not returning failed anymore with post_callback? > Because that was a mistake, I meant to return dn, but wrote failed for > some reason. We only need to return immutable types in callbacks, > because everything else can be changed "in place". > >> rob >> > > Pavel Ok, ack and pushed to master. I wonder if --all and --raw should be global options instead so they don't show show up in help. It is a little odd to see "print entries as they are stored in LDAP" in add help. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Sep 11 14:00:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Sep 2009 10:00:50 -0400 Subject: [Freeipa-devel] [PATCH] 270 handle all exceptions in XML-RPC server Message-ID: <4AAA5812.7030102@redhat.com> Add a fail-safe exception handler to ensure that we destroy the request context and don't return dirty laundry to a client. If we don't do this then this process/thread will blow up the next time it handles a request because a context already exists. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-270-exception.patch Type: application/mbox Size: 1142 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Sep 11 14:14:21 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Sep 2009 10:14:21 -0400 Subject: [Freeipa-devel] [PATCH] 271 handle certificate decode errors in service Message-ID: <4AAA5B3D.3010600@redhat.com> In the service plugin we will attempt to revoke a server cert when a service is deleted. Add some error handling around that effort. This fixes the self-tests. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-271-service.patch Type: application/mbox Size: 1448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Sep 11 14:35:26 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Sep 2009 10:35:26 -0400 Subject: [Freeipa-devel] [PATCH] 270 handle all exceptions in XML-RPC server In-Reply-To: <4AAA5812.7030102@redhat.com> References: <4AAA5812.7030102@redhat.com> Message-ID: <1252679726.3046.76.camel@localhost.localdomain> On Fri, 2009-09-11 at 10:00 -0400, Rob Crittenden wrote: > Add a fail-safe exception handler to ensure that we destroy the > request > context and don't return dirty laundry to a client. If we don't do > this > then this process/thread will blow up the next time it handles a > request > because a context already exists. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Sep 11 14:39:12 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Sep 2009 10:39:12 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AA66427.1050404@redhat.com> References: <4AA66427.1050404@redhat.com> Message-ID: <4AAA6110.9090402@redhat.com> Pavel Z?na wrote: > This is a series of patches that depends on patches: > - Improve attribute printing in the CLI. > - Improve ipalib.plugins.baseldap classes. > > All plugins are converted to extend baseldap classes. This makes things > more consistent, fixes some general bugs (with return values for > example) and it also makes plugins easier to maintain (as it removes a > lot of duplicate code). > > Because baseldap classes have features that enable us to define > relationships between plugins, I thought it might be best to submit all > of the conversions at once and have all the relationships fully defined. > > Affected plugins: > config > user > host > service > group > hostgroup > netgroup > rolegroup > taskgroup > pwpolicy > > There's also a patch that fixes all unit tests. > > Jenny, I included you to Cc, because the patch introduces a lot of > changes to the UI (and you're probably not going to like me for this). > > Each command extending the LDAP* base classes now has a --raw option. > Without it, data from LDAP is formated and translated to human readable. > For example: > > # ipa user-show admin --all > ---------- > user-show: > ---------- > User: admin > user id: admin > full name: Administrator > last name: Administrator > home directory: /home/admin > login shell: /bin/bash > uid number: 999 > gid number: 1001 > gecos: Administrator > kerberos principal: admin at PZUNA > last password change: 20090904122852Z > password expiration: 20091203122852Z > member of groups: admins > > # ipa user-show admin --all --raw > ---------- > user-show: > ---------- > dn: uid=admin,cn=users,cn=accounts,dc=pzuna > uid: admin > cn: Administrator > sn: Administrator > homedirectory: /home/admin > loginshell: /bin/bash > uidnumber: 999 > gidnumber: 1001 > gecos: Administrator > krbprincipalname: admin at PZUNA > krblastpwdchange: 20090904122852Z > krbpasswordexpiration: 20091203122852Z > memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna > objectclass: top > objectclass: person > objectclass: posixaccount > objectclass: krbprincipalaux > objectclass: inetuser > > Advantages: more user friendly, allows for easy localization, > translation of DNs to primary keys (immediately usable as input to other > plugin commands) > > I recommend, that you use the --raw flag for testing. > > > > I know it's a lot of changes, so I setup a git repo at: > git://fedorapeople.org/~pzuna/freeipa.git > > It should be up-to-date with master and all my patches are applied > there. I hope it makes reviewing them at least a bit easier. > > Pavel Why are you using a pre_callback() to define default values instead of using default_from? It seems clearer to use that. This also duplicates some values in the attribute_names() dictionary. I wonder if this can be either created from the parameters or define a global set somewhere that covers all plugins. In the user plugin 'ou' is in the default attributes. We don't use this attribute. I think that in general baseldap needs to be documented to explain how things work. There is no explanation for object_class_config, for example, that it defines the attribute in cn=ipaConfig that contains the default list of objectclasses for the object. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Sep 11 15:01:48 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Sep 2009 11:01:48 -0400 Subject: [Freeipa-devel] IPA v1.2.2 in Fedora updates-testing Message-ID: <4AAA665C.8050402@redhat.com> IPA v1.2.2 has been released into the Fedora updates-testing repository (not quite pushed to all the mirrors yet). I'm putting it into testing so we can get some feedback on it before pushing it out to the masses. It primarily addresses the following bugs: * Fix group deletion in the web UI. 484050 * Make the web UI work when both python-cherrypy and python-cherrypy2 are installed. 505686 * Fix some Python 2.6 deprecation warnings * Change method used to determine CAs to trust. 509111 * Add the CA constraint to the self-signed CA IPA generates. 514027 If you are upgrading an existing IPA installation see http://freeipa.org/page/NewCA for details on re-issuing the CA so it will work with FF 3.5 The Fedora update entries where feedback can be provided are at: https://admin.fedoraproject.org/updates/ipa-1.2.2-1.fc10 https://admin.fedoraproject.org/updates/ipa-1.2.2-1.fc11 Once the update gets pushed out to the mirrors you can install it with something like: # yum --enablerepo updates-testing install ipa-server I'll make a more official announcement once we push it out to the Fedora updates repository. I'll also post the tarball on the freeipa.org wiki at that time. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Mon Sep 14 11:03:34 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 14 Sep 2009 13:03:34 +0200 Subject: [Freeipa-devel] [PATCH] 266 remove deprecated comment In-Reply-To: <4AA96136.3010800@redhat.com> References: <4AA96136.3010800@redhat.com> Message-ID: <4AAE2306.8050709@redhat.com> Rob Crittenden wrote: > Remove comment about plugin naming conventions. We've dumped this > convention. > > rob > ack Pavel From pzuna at redhat.com Mon Sep 14 11:57:11 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 14 Sep 2009 13:57:11 +0200 Subject: [Freeipa-devel] [PATCH] 267 fix virtual plugin In-Reply-To: <4AA96178.7080201@redhat.com> References: <4AA96178.7080201@redhat.com> Message-ID: <4AAE2F97.5070505@redhat.com> Rob Crittenden wrote: > Fix the virtual access plugin to work with the new backend. Also do a > more explicit objectviolation catch. We will switch this to use GER when > that is completed. > > rob ack Pavel From pzuna at redhat.com Mon Sep 14 12:02:18 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Mon, 14 Sep 2009 14:02:18 +0200 Subject: [Freeipa-devel] [PATCH] 268 explicitly set verbose to false in RPC client In-Reply-To: <4AA961B3.9030804@redhat.com> References: <4AA961B3.9030804@redhat.com> Message-ID: <4AAE30CA.8050804@redhat.com> Rob Crittenden wrote: > I've needed to set verbose to True in the rpc client and every time I > have to do this I hunt around trying to figure out where to put it. This > will make it easier to find next time :-) > > rob ack Pavel From rcritten at redhat.com Mon Sep 14 13:47:25 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Sep 2009 09:47:25 -0400 Subject: [Freeipa-devel] [PATCH] 266 remove deprecated comment In-Reply-To: <4AAE2306.8050709@redhat.com> References: <4AA96136.3010800@redhat.com> <4AAE2306.8050709@redhat.com> Message-ID: <4AAE496D.1000605@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Remove comment about plugin naming conventions. We've dumped this >> convention. >> >> rob >> > ack > > Pavel > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Sep 14 13:47:34 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Sep 2009 09:47:34 -0400 Subject: [Freeipa-devel] [PATCH] 267 fix virtual plugin In-Reply-To: <4AAE2F97.5070505@redhat.com> References: <4AA96178.7080201@redhat.com> <4AAE2F97.5070505@redhat.com> Message-ID: <4AAE4976.50404@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Fix the virtual access plugin to work with the new backend. Also do a >> more explicit objectviolation catch. We will switch this to use GER >> when that is completed. >> >> rob > ack > > Pavel Pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Sep 14 13:47:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Sep 2009 09:47:46 -0400 Subject: [Freeipa-devel] [PATCH] 268 explicitly set verbose to false in RPC client In-Reply-To: <4AAE30CA.8050804@redhat.com> References: <4AA961B3.9030804@redhat.com> <4AAE30CA.8050804@redhat.com> Message-ID: <4AAE4982.7080109@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> I've needed to set verbose to True in the rpc client and every time I >> have to do this I hunt around trying to figure out where to put it. >> This will make it easier to find next time :-) >> >> rob > ack > > Pavel Push to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Mon Sep 14 19:58:38 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 14 Sep 2009 13:58:38 -0600 Subject: [Freeipa-devel] [PATCH] jderose 017 Giant WebUI patch part 1 In-Reply-To: <4AA6CFED.9030107@redhat.com> References: <1252406246.2527.99.camel@jgd-dsk> <4AA69550.5030506@redhat.com> <4AA6CFED.9030107@redhat.com> Message-ID: <1252958318.8373.15.camel@jgd-dsk> On Tue, 2009-09-08 at 17:43 -0400, Dmitri Pal wrote: > Rob Crittenden wrote: > > Jason Gerard DeRose wrote: > >> This is a big patch to get everyone synced up with what I'm doing on > >> the webUI. > >> The Engine is currently *very* dumb because I need to tare through a > >> bunch of > >> plugin metadata, make a lot of changes, but doing that is likely > >> going to make > >> merging any outstanding patches too difficult, break any work in > >> progress. I > >> even I backed out some crazier changes I had made, realizing the > >> headache I was > >> inviting. > >> > >> So what I propose is acking this and acking any other outstanding > >> patches, and > >> then quickly making the needed metadata changes in a coordinated > >> fashion (read: > >> Rob, Pavel, and I staying pretty much lock-step for a few days). The > >> metadata > >> changes aren't a lot of work, but they are very disruptive as they > >> will change > >> the plugin API slightly and will affect every Command and Object > >> plugin we have > >> (which by my count is currently 108 plugins). > >> > >> Some highlights: > >> > >> * lite-xmlrpc.py and lite-webui.py have been replaced by the new > >> lite-server.py > >> script, which mounts XML-RPC, JSON-RPC, and the WebUI all on the > >> same paths > >> as they would be under Apache (but on a different port). > >> > >> * Per above, the default xmlrpc_uri is now http://localhost:8888/ipa/xml > >> > >> * The IPA server is now a WSGI application. A few pieces still are > >> missing, most > >> notably running all this under Apache, but it's 90% there. > >> Currently under > >> Apache things will still run the same as before, just XML-RPC and > >> not through > >> the new Backend.xmlserver WSGI interface. Because IPA is a WSGI > >> app, I think > >> we should strongly consider running IPA under mod_wsgi instead of > >> mod_python, > >> although running under mod_python is still possible with a > >> mod_python <=> WSGI > >> adapter. > >> > >> * For flexibility and to ease debugging, the XML-RPC and JSON-RPC > >> services can > >> now also be called via GET or POST query strings. For example: > >> > >> http://localhost:8888/ipa/json/user_add?givenname=Jason&sn=DeRose > >> > >> Or > >> > >> http://localhost:8888/ipa/xml/user_add?givenname=Jason&sn=DeRose > >> > >> Is the same as: > >> > >> api.Command.user_add(givenname='Jason', sn='DeRose') > >> > >> * In theory, lite-server.py supports SSL, but there is a bug in paste > >> 1.7.2 that > >> prevents it from working under Python 2.6. To turn on SSL, just > >> place a PEM > >> format cert at ~/.ipa/lite.pem > >> > >> > >> Anyway, this gives everyone something to play with/review till I get > >> back from > >> PTO on Thursday. > >> > >> Cheers, > >> Jason > > > > Have a bunch of questions/issues before I can ack this: > > > > - We need to get the wehjit library accepted into Fedora ASAP > > - There is a change to ipa-server-install that reverts your previous > > patch, 016 > > - This patch includes the previous SSO patch that we can't commit > > until we get an alternative for the Crypto package on some distros > > - Is it going to be confusing to register the jsonserver in a file > > named xmlserver.py? > > - in rpcserver.py::extract_query(environ) should an error be raised if > > these conditions aren't met? For example, you do a POST and the > > content-type isn't application/x-www-form-urlencoded > > > > Otherwise looks ok. I'm not opposed to switching to WSGI as long as we > > have feature parity. > > > > rob > > How the addition of the wehjit library affects our ability to run on > RHEL 5.5? It wont be a problem as long as the python-genshi package is available. It has been in Fedora for a while, but I'm not sure about RHEL 5.4/5.5. Last week I removed the dependency on python-sqlalchemy (which seemed a point of contention) and am now using symlinks instead of a DB for the asset manager (which is a better, simpler design anyway). I'll need to test a bit more under Python2.4, but I definitely designed it with Python2.4 compatibility in mind. From rcritten at redhat.com Mon Sep 14 20:15:36 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Sep 2009 16:15:36 -0400 Subject: [Freeipa-devel] [PATCH] 271 Enhance updater, add tests Message-ID: <4AAEA468.3020201@redhat.com> This patch lets the updater delete entire entries and adds a basic unit test harness. To have these tests run you need to have IPA installed locally and put the DM password into ~/.ipa/.dmpw. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-272-updater.patch Type: application/mbox Size: 19110 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Sep 14 21:07:33 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Sep 2009 17:07:33 -0400 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain Message-ID: <4AAEB095.6000005@redhat.com> NOTE, this patch replaces a previous patch to do the same thing. I fixed a few problems Simo pointed out and re-based it against the current master. This largish patch adds host enrollment. There are several scenarios that are covered. All of these assume that the IPA client machine has already been set up (ipa-client-install): 1. Full admin enrollment. This will create the host entry, a host/ service principal and a keytab for that principal in /etc/krb5.keytab. 2. Junior admin enrollment. There are lots of levels of delegation possible here, but at a minimum they would be able to enroll an existing host by creating the service principal and keytab. Additional rights such as adding a host could be added as well. 3. Bulk enrollment. If a host entry is pre-created by another admin and it contains an enrollment password (in the userPassword attribute) then an LDAP-based enrollment can take place. The client binds as the host and generates a keytab for itself. One really significant change is I've switch to openldap as the LDAP client. Doing SSL with mozldap would have required a significant amount of more code (because we can't assume there is already an NSS db lying around that trusts the IPA CA). I didn't completely disable the mozldap option but by default things will build with openldap now. This also adds a first pass at Get Effective Rights support. This is so we can know in advance if an operation would succeed and makes things generally nicer. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-273-join.patch Type: application/mbox Size: 79093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Mon Sep 14 22:02:12 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 14 Sep 2009 18:02:12 -0400 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain In-Reply-To: <4AAEB095.6000005@redhat.com> References: <4AAEB095.6000005@redhat.com> Message-ID: <4AAEBD64.4000204@redhat.com> Rob Crittenden wrote: > NOTE, this patch replaces a previous patch to do the same thing. I > fixed a few problems Simo pointed out and re-based it against the > current master. > > This largish patch adds host enrollment. There are several scenarios > that are covered. All of these assume that the IPA client machine has > already been set up (ipa-client-install): > > 1. Full admin enrollment. This will create the host entry, a host/ > service principal and a keytab for that principal in /etc/krb5.keytab. > > 2. Junior admin enrollment. There are lots of levels of delegation > possible here, but at a minimum they would be able to enroll an > existing host by creating the service principal and keytab. Additional > rights such as adding a host could be added as well. > > 3. Bulk enrollment. If a host entry is pre-created by another admin > and it contains an enrollment password (in the userPassword attribute) > then an LDAP-based enrollment can take place. The client binds as the > host and generates a keytab for itself. > > One really significant change is I've switch to openldap as the LDAP > client. Doing SSL with mozldap would have required a significant > amount of more code (because we can't assume there is already an NSS > db lying around that trusts the IPA CA). > > I didn't completely disable the mozldap option but by default things > will build with openldap now. > > This also adds a first pass at Get Effective Rights support. This is > so we can know in advance if an operation would succeed and makes > things generally nicer. > > rob > > GREAT!!! > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pzuna at redhat.com Tue Sep 15 11:25:25 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 15 Sep 2009 13:25:25 +0200 Subject: [Freeipa-devel] [PATCH] 269 external CA signing, abstract RA In-Reply-To: <4AA96304.4090903@redhat.com> References: <4AA96304.4090903@redhat.com> Message-ID: <4AAF79A5.6020807@redhat.com> Rob Crittenden wrote: > The RA plugin originally only supported dogtag. At some point I want to > be able to do on-line replica creation and this means we need to be able > to do remote cert requests. To support this I've abstracted the RA > plugin and added basic self-signed CA support. To do this I had to move > the CA private key from the DS NSS database to the Apache NSS database. > > The bulk of the patch adds support for an externally-signed dogtag CA. > This is a 2-step process. You run the IPA installer to create the CA > instance and generate a CSR. You take this CSR to your primary CA and > get it signed, then re-run the IPA installer and pass it this new cert. > A lot of our cert functions assumed 1 cert-per-file. I had to remove > that assumption and add in a sort of generic nickname generator. It > assumes that the certs will be in some sort of order in the file. It > doesn't really matter as long as the nicknames are unique. > > A replica created with a self-signed CA will not be able to issue certs > yet. I started this work by enhancing the file used to store the next > serial number to also store the next serial number to be used by a > replica. The idea is that we ship this to the replica then bump it up by > some value so that all replicas are unique. I think we'll have to > enforce that replicas can't create other replicas. > > rob > I didn't do extensive functionality tests, but the code looks really fine. I think we should push this. If something doesn't work exactly the way expected, we can always patch it later. ack. This patch makes some changes to the service plugin that aren't compatible with my latest service plugin patch (Make the service plugin use baseldap classes.) Since this is probably going to get pushed first, I already made a replacement patch that merges changes from both. It's attached. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-service-plugin-use-baseldap-classes.patch Type: application/mbox Size: 12808 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 15 11:37:29 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 15 Sep 2009 13:37:29 +0200 Subject: [Freeipa-devel] [PATCH] 271 handle certificate decode errors in service In-Reply-To: <4AAA5B3D.3010600@redhat.com> References: <4AAA5B3D.3010600@redhat.com> Message-ID: <4AAF7C79.9020906@redhat.com> Rob Crittenden wrote: > In the service plugin we will attempt to revoke a server cert when a > service is deleted. Add some error handling around that effort. > > This fixes the self-tests. > > rob nack. Your "269 external CA signing, abstract RA" already handles them inside get_serial(). However, there is a difference. This patch allows the entry to be deleted even if the it fails to revoke the certificate. If that is the main purpose, we still need to rewrite it to apply against your 269 patch (in which case I will probably have to do some small fixes to my service patch, but don't worry about that). Pavel From pzuna at redhat.com Tue Sep 15 12:09:42 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 15 Sep 2009 14:09:42 +0200 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain In-Reply-To: <4AAEB095.6000005@redhat.com> References: <4AAEB095.6000005@redhat.com> Message-ID: <4AAF8406.3070905@redhat.com> Rob Crittenden wrote: > NOTE, this patch replaces a previous patch to do the same thing. I fixed > a few problems Simo pointed out and re-based it against the current master. > > This largish patch adds host enrollment. There are several scenarios > that are covered. All of these assume that the IPA client machine has > already been set up (ipa-client-install): > > 1. Full admin enrollment. This will create the host entry, a host/ > service principal and a keytab for that principal in /etc/krb5.keytab. > > 2. Junior admin enrollment. There are lots of levels of delegation > possible here, but at a minimum they would be able to enroll an existing > host by creating the service principal and keytab. Additional rights > such as adding a host could be added as well. > > 3. Bulk enrollment. If a host entry is pre-created by another admin and > it contains an enrollment password (in the userPassword attribute) then > an LDAP-based enrollment can take place. The client binds as the host > and generates a keytab for itself. > > One really significant change is I've switch to openldap as the LDAP > client. Doing SSL with mozldap would have required a significant amount > of more code (because we can't assume there is already an NSS db lying > around that trusts the IPA CA). > > I didn't completely disable the mozldap option but by default things > will build with openldap now. > > This also adds a first pass at Get Effective Rights support. This is so > we can know in advance if an operation would succeed and makes things > generally nicer. > > rob Looking good! I noticed it makes changes to the host plugin and since this is probably going to get into the tree first: here's an updated version of my host plugin patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-host-plugin-use-baseldap-classes.patch Type: application/mbox Size: 14146 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 15 12:41:27 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 15 Sep 2009 14:41:27 +0200 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain In-Reply-To: <4AAF8406.3070905@redhat.com> References: <4AAEB095.6000005@redhat.com> <4AAF8406.3070905@redhat.com> Message-ID: <4AAF8B77.8070704@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> NOTE, this patch replaces a previous patch to do the same thing. I >> fixed a few problems Simo pointed out and re-based it against the >> current master. >> >> This largish patch adds host enrollment. There are several scenarios >> that are covered. All of these assume that the IPA client machine has >> already been set up (ipa-client-install): >> >> 1. Full admin enrollment. This will create the host entry, a host/ >> service principal and a keytab for that principal in /etc/krb5.keytab. >> >> 2. Junior admin enrollment. There are lots of levels of delegation >> possible here, but at a minimum they would be able to enroll an >> existing host by creating the service principal and keytab. Additional >> rights such as adding a host could be added as well. >> >> 3. Bulk enrollment. If a host entry is pre-created by another admin >> and it contains an enrollment password (in the userPassword attribute) >> then an LDAP-based enrollment can take place. The client binds as the >> host and generates a keytab for itself. >> >> One really significant change is I've switch to openldap as the LDAP >> client. Doing SSL with mozldap would have required a significant >> amount of more code (because we can't assume there is already an NSS >> db lying around that trusts the IPA CA). >> >> I didn't completely disable the mozldap option but by default things >> will build with openldap now. >> >> This also adds a first pass at Get Effective Rights support. This is >> so we can know in advance if an operation would succeed and makes >> things generally nicer. >> >> rob > Looking good! > > I noticed it makes changes to the host plugin and since this is probably > going to get into the tree first: here's an updated version of my host > plugin patch. > > Pavel Oops! Bad patch. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-host-plugin-use-baseldap-classes.patch Type: application/mbox Size: 14026 bytes Desc: not available URL: From pzuna at redhat.com Tue Sep 15 12:59:28 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 15 Sep 2009 14:59:28 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AAA6110.9090402@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> Message-ID: <4AAF8FB0.7030508@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> This is a series of patches that depends on patches: >> - Improve attribute printing in the CLI. >> - Improve ipalib.plugins.baseldap classes. >> >> All plugins are converted to extend baseldap classes. This makes >> things more consistent, fixes some general bugs (with return values >> for example) and it also makes plugins easier to maintain (as it >> removes a lot of duplicate code). >> >> Because baseldap classes have features that enable us to define >> relationships between plugins, I thought it might be best to submit >> all of the conversions at once and have all the relationships fully >> defined. >> >> Affected plugins: >> config >> user >> host >> service >> group >> hostgroup >> netgroup >> rolegroup >> taskgroup >> pwpolicy >> >> There's also a patch that fixes all unit tests. >> >> Jenny, I included you to Cc, because the patch introduces a lot of >> changes to the UI (and you're probably not going to like me for this). >> >> Each command extending the LDAP* base classes now has a --raw option. >> Without it, data from LDAP is formated and translated to human >> readable. For example: >> >> # ipa user-show admin --all >> ---------- >> user-show: >> ---------- >> User: admin >> user id: admin >> full name: Administrator >> last name: Administrator >> home directory: /home/admin >> login shell: /bin/bash >> uid number: 999 >> gid number: 1001 >> gecos: Administrator >> kerberos principal: admin at PZUNA >> last password change: 20090904122852Z >> password expiration: 20091203122852Z >> member of groups: admins >> >> # ipa user-show admin --all --raw >> ---------- >> user-show: >> ---------- >> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >> uid: admin >> cn: Administrator >> sn: Administrator >> homedirectory: /home/admin >> loginshell: /bin/bash >> uidnumber: 999 >> gidnumber: 1001 >> gecos: Administrator >> krbprincipalname: admin at PZUNA >> krblastpwdchange: 20090904122852Z >> krbpasswordexpiration: 20091203122852Z >> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >> objectclass: top >> objectclass: person >> objectclass: posixaccount >> objectclass: krbprincipalaux >> objectclass: inetuser >> >> Advantages: more user friendly, allows for easy localization, >> translation of DNs to primary keys (immediately usable as input to >> other plugin commands) >> >> I recommend, that you use the --raw flag for testing. >> >> >> >> I know it's a lot of changes, so I setup a git repo at: >> git://fedorapeople.org/~pzuna/freeipa.git >> >> It should be up-to-date with master and all my patches are applied >> there. I hope it makes reviewing them at least a bit easier. >> >> Pavel > > Why are you using a pre_callback() to define default values instead of > using default_from? It seems clearer to use that. You're probably referring to the user plugin, where gecos and krbprincipalname defaults are set inside pre_callback. It's a residue from some time ago when we didn't use autofill=True with default_from and it didn't have any effect on optional parameters. It's a small change, but I included an updated version of the patch with this email. > This also duplicates some values in the attribute_names() dictionary. I > wonder if this can be either created from the parameters or define a > global set somewhere that covers all plugins. I know, but I couldn't find a better solution. I thought we could add something like a 'real_name' kwarg to params, but this has 2 main disadvantages: 1) it only makes sense with parameters that refer to an LDAP attribute 2) it doesn't work for attributes with no param counterparts The global set is a good idea as long as we consider only our own plugins. 3rd party plugins would have to modify this set to add their own attributes. Also, attributes might have a different meaning for different objects. They usually don't, but take 'cn' for example. We use it as an ID, name, full name (for users), etc. > In the user plugin 'ou' is in the default attributes. We don't use this > attribute. Since we don't use it, it's not going to get displayed anyway. All the values in attribute_names, default_attribute and attribute_order are subject to change. I set them to initial values I thought are acceptable, but I don't think I'm the right person to decide what's going to be there. Ideally, someone with more UI/text/user friendliness experience should review it (there's not programming knowledge required to change the values). > I think that in general baseldap needs to be documented to explain how > things work. There is no explanation for object_class_config, for > example, that it defines the attribute in cn=ipaConfig that contains the > default list of objectclasses for the object. Yeah, there's no documentation at this point, but I'm working on it as we "speak". > rob > One more thing, I reviewed your latest patches and they make change to host and service plugins. Your patches should be pushed first, because they are more complex and also more important, so I posted updated versions to the corresponding email threads on freeipa-devel. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Make-the-user-plugin-use-baseldap-classes.patch Type: application/mbox Size: 13829 bytes Desc: not available URL: From rcritten at redhat.com Tue Sep 15 13:46:56 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 09:46:56 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AAF8FB0.7030508@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> Message-ID: <4AAF9AD0.7090204@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> Pavel Z?na wrote: >>> This is a series of patches that depends on patches: >>> - Improve attribute printing in the CLI. >>> - Improve ipalib.plugins.baseldap classes. >>> >>> All plugins are converted to extend baseldap classes. This makes >>> things more consistent, fixes some general bugs (with return values >>> for example) and it also makes plugins easier to maintain (as it >>> removes a lot of duplicate code). >>> >>> Because baseldap classes have features that enable us to define >>> relationships between plugins, I thought it might be best to submit >>> all of the conversions at once and have all the relationships fully >>> defined. >>> >>> Affected plugins: >>> config >>> user >>> host >>> service >>> group >>> hostgroup >>> netgroup >>> rolegroup >>> taskgroup >>> pwpolicy >>> >>> There's also a patch that fixes all unit tests. >>> >>> Jenny, I included you to Cc, because the patch introduces a lot of >>> changes to the UI (and you're probably not going to like me for this). >>> >>> Each command extending the LDAP* base classes now has a --raw option. >>> Without it, data from LDAP is formated and translated to human >>> readable. For example: >>> >>> # ipa user-show admin --all >>> ---------- >>> user-show: >>> ---------- >>> User: admin >>> user id: admin >>> full name: Administrator >>> last name: Administrator >>> home directory: /home/admin >>> login shell: /bin/bash >>> uid number: 999 >>> gid number: 1001 >>> gecos: Administrator >>> kerberos principal: admin at PZUNA >>> last password change: 20090904122852Z >>> password expiration: 20091203122852Z >>> member of groups: admins >>> >>> # ipa user-show admin --all --raw >>> ---------- >>> user-show: >>> ---------- >>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>> uid: admin >>> cn: Administrator >>> sn: Administrator >>> homedirectory: /home/admin >>> loginshell: /bin/bash >>> uidnumber: 999 >>> gidnumber: 1001 >>> gecos: Administrator >>> krbprincipalname: admin at PZUNA >>> krblastpwdchange: 20090904122852Z >>> krbpasswordexpiration: 20091203122852Z >>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>> objectclass: top >>> objectclass: person >>> objectclass: posixaccount >>> objectclass: krbprincipalaux >>> objectclass: inetuser >>> >>> Advantages: more user friendly, allows for easy localization, >>> translation of DNs to primary keys (immediately usable as input to >>> other plugin commands) >>> >>> I recommend, that you use the --raw flag for testing. >>> >>> >>> >>> I know it's a lot of changes, so I setup a git repo at: >>> git://fedorapeople.org/~pzuna/freeipa.git >>> >>> It should be up-to-date with master and all my patches are applied >>> there. I hope it makes reviewing them at least a bit easier. >>> >>> Pavel >> >> Why are you using a pre_callback() to define default values instead of >> using default_from? It seems clearer to use that. > You're probably referring to the user plugin, where gecos and > krbprincipalname defaults are set inside pre_callback. It's a residue > from some time ago when we didn't use autofill=True with default_from > and it didn't have any effect on optional parameters. It's a small > change, but I included an updated version of the patch with this email. Ok. I gather you've moved a lot of logic into the pre_callback plugin to avoid overriding execute? One other goal we wanted was to allow plugins to extend other plugins and this may be good step on the way there. So for example, a user wants to be able to set some extra objectclass, they could do it with a similar pre_callback extension to the user plugin (once we do the plumbing for it, that is). >> This also duplicates some values in the attribute_names() dictionary. >> I wonder if this can be either created from the parameters or define a >> global set somewhere that covers all plugins. > I know, but I couldn't find a better solution. I thought we could add > something like a 'real_name' kwarg to params, but this has 2 main > disadvantages: > 1) it only makes sense with parameters that refer to an LDAP attribute > 2) it doesn't work for attributes with no param counterparts > > The global set is a good idea as long as we consider only our own > plugins. 3rd party plugins would have to modify this set to add their > own attributes. Also, attributes might have a different meaning for > different objects. They usually don't, but take 'cn' for example. We use > it as an ID, name, full name (for users), etc. Ok, that's a good point. I'm wondering if its overkill to write a registration system for this, something like: def set_label(attr, label, context='') def get_label(attr, context='') In this we'd store a dict that would be keyed on attr+context. Some examples might be: set_label('uid', 'Login') set_label('gn', 'First Name') set_label('cn', 'Full Name', context='user') set_label('cn', 'Group Name', context='group') The lookup would first look for a context-specific entry and fall back to a non-context specific, something like: if attr+context in labeldict: return labeldict[attr+context] elif attr in labeldict: return labeldict[attr] else return "woop" Like I said, might be overkill ;-) But still, the alarms go off when we're putting the same things in multiple places. >> In the user plugin 'ou' is in the default attributes. We don't use >> this attribute. > Since we don't use it, it's not going to get displayed anyway. > > All the values in attribute_names, default_attribute and attribute_order > are subject to change. I set them to initial values I thought are > acceptable, but I don't think I'm the right person to decide what's > going to be there. Ideally, someone with more UI/text/user friendliness > experience should review it (there's not programming knowledge required > to change the values). Ok, this particular attribute brings up DIT issues which is why I flagged it. >> I think that in general baseldap needs to be documented to explain how >> things work. There is no explanation for object_class_config, for >> example, that it defines the attribute in cn=ipaConfig that contains >> the default list of objectclasses for the object. > Yeah, there's no documentation at this point, but I'm working on it as > we "speak". > >> rob >> > > One more thing, I reviewed your latest patches and they make change to > host and service plugins. Your patches should be pushed first, because > they are more complex and also more important, so I posted updated > versions to the corresponding email threads on freeipa-devel. > > Pavel Ok, I'm not too worried about that, its always a game of catch-up :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 15 14:01:24 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 10:01:24 -0400 Subject: [Freeipa-devel] [PATCH] 269 external CA signing, abstract RA In-Reply-To: <4AAF79A5.6020807@redhat.com> References: <4AA96304.4090903@redhat.com> <4AAF79A5.6020807@redhat.com> Message-ID: <4AAF9E34.1050102@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> The RA plugin originally only supported dogtag. At some point I want >> to be able to do on-line replica creation and this means we need to be >> able to do remote cert requests. To support this I've abstracted the >> RA plugin and added basic self-signed CA support. To do this I had to >> move the CA private key from the DS NSS database to the Apache NSS >> database. >> >> The bulk of the patch adds support for an externally-signed dogtag CA. >> This is a 2-step process. You run the IPA installer to create the CA >> instance and generate a CSR. You take this CSR to your primary CA and >> get it signed, then re-run the IPA installer and pass it this new >> cert. A lot of our cert functions assumed 1 cert-per-file. I had to >> remove that assumption and add in a sort of generic nickname >> generator. It assumes that the certs will be in some sort of order in >> the file. It doesn't really matter as long as the nicknames are unique. >> >> A replica created with a self-signed CA will not be able to issue >> certs yet. I started this work by enhancing the file used to store the >> next serial number to also store the next serial number to be used by >> a replica. The idea is that we ship this to the replica then bump it >> up by some value so that all replicas are unique. I think we'll have >> to enforce that replicas can't create other replicas. >> >> rob >> > I didn't do extensive functionality tests, but the code looks really > fine. I think we should push this. If something doesn't work exactly the > way expected, we can always patch it later. ack. > > This patch makes some changes to the service plugin that aren't > compatible with my latest service plugin patch (Make the service plugin > use baseldap classes.) Since this is probably going to get pushed first, > I already made a replacement patch that merges changes from both. It's > attached. > > Pavel Pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 15 14:04:10 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 10:04:10 -0400 Subject: [Freeipa-devel] [PATCH] 271 handle certificate decode errors in service In-Reply-To: <4AAF7C79.9020906@redhat.com> References: <4AAA5B3D.3010600@redhat.com> <4AAF7C79.9020906@redhat.com> Message-ID: <4AAF9EDA.3090605@redhat.com> Pavel Zuna wrote: > Rob Crittenden wrote: >> In the service plugin we will attempt to revoke a server cert when a >> service is deleted. Add some error handling around that effort. >> >> This fixes the self-tests. >> >> rob > nack. > > Your "269 external CA signing, abstract RA" already handles them inside > get_serial(). However, there is a difference. This patch allows the > entry to be deleted even if the it fails to revoke the certificate. If > that is the main purpose, we still need to rewrite it to apply against > your 269 patch (in which case I will probably have to do some small > fixes to my service patch, but don't worry about that). Ok, good catch and good point. Upon further reflection, I'm not sure what we should do if we can't decode a certificate, may need to ask Andrew. Remember that this deletion can take place in the context of deleting a host. I'm not sure if stopping the whole process should be stopped or not. I think we should probably catch different levels of errors. If we simply can't decode the cert then perhaps, as in the case of my bogus test case, we stick junk in there. If we can't decode the cert then there is no chance of revoking it. We also need a separate catch around the revocation so we can catch errors there, such as "you are not allowed to perform this operation". This could easily happen if someone that can create/delete hosts and services but not manage certificates removes a host. Seems like this opens a pretty big bag of worms. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 15 17:58:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 13:58:22 -0400 Subject: [Freeipa-devel] FreeIPA v1.2.2 released Message-ID: <4AAFD5BE.4080008@redhat.com> The FreeIPA Project (http://freeipa.org) is proud to present FreeIPA version 1.22. FreeIPA is an integrated security information management solution combining Linux (Fedora), Fedora Directory Server, MIT Kerberos and NTP. FreeIPA binds together a number of technologies and adds a web interface and command-line administration tools. Currently it supports identity management with plans to support policy and auditing management. This is a bugfix release. The main bugs addressed are: * Fix group deletion in the web UI. 484050 * Make the web UI work when both python-cherrypy and python-cherrypy2 are installed. 505686 * Fix some Python 2.6 deprecation warnings * Change method used to determine CAs to trust. 509111 * Add the CA constraint to the self-signed CA IPA generates. 514027 If you are upgrading an existing IPA installation see http://freeipa.org/page/NewCA for details on re-issuing the CA so it will work with FF 3.5 The Fedora packages are currently in updates-testing and will be moved to updates on Thursday, Sept 17. You can install/upgrade from the Fedora testing repository with: # yum --enablerepo updates-testing install ipa-server The FreeIPA Project Team. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Tue Sep 15 19:55:24 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Sep 2009 15:55:24 -0400 Subject: [Freeipa-devel] IPA license Message-ID: <4AAFF12C.50107@redhat.com> Hello, We are considering to release freeIPA v2 under a less restrictive license than we used in IPA v1. It was "GPLv2 only" in v1.x and we think about "GPLv2 and later" or "GPLv3 and later". Please respond to this mail if there are any suggestions, comments or concerns. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From amrossi at linux.it Tue Sep 15 20:59:42 2009 From: amrossi at linux.it (Andrea Modesto Rossi) Date: Tue, 15 Sep 2009 22:59:42 +0200 (CEST) Subject: [Freeipa-devel] Re: [Freeipa-users] IPA license In-Reply-To: <4AAFF12C.50107@redhat.com> References: <4AAFF12C.50107@redhat.com> Message-ID: <54027.79.30.159.52.1253048382.squirrel@picard.linux.it> On Mar, 15 Settembre 2009 9:55 pm, Dmitri Pal wrote: > > We are considering to release freeIPA v2 under a less restrictive > license than we used in IPA v1. > It was "GPLv2 only" in v1.x and we think about "GPLv2 and later" or > "GPLv3 and later". > Please respond to this mail if there are any suggestions, comments or > concerns. Well, GPL3 is a good idea but ts there a particular reason to change license policy? -- Andrea Modesto Rossi Fedora Ambassador +---------------------------------------------------------------------+ | Bello. Che gli diciamo? Che sono tutti stronzi monopolisti di merda,| | con i loro protocolli brevettati e i loro driver finestrosi? | | Ci sono! | | Alessandro Rubini | +---------------------------------------------------------------------+ From rcritten at redhat.com Tue Sep 15 21:28:28 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 17:28:28 -0400 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AAF9AD0.7090204@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> Message-ID: <4AB006FC.4070008@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> Rob Crittenden wrote: >>> Pavel Z?na wrote: >>>> This is a series of patches that depends on patches: >>>> - Improve attribute printing in the CLI. >>>> - Improve ipalib.plugins.baseldap classes. >>>> >>>> All plugins are converted to extend baseldap classes. This makes >>>> things more consistent, fixes some general bugs (with return values >>>> for example) and it also makes plugins easier to maintain (as it >>>> removes a lot of duplicate code). >>>> >>>> Because baseldap classes have features that enable us to define >>>> relationships between plugins, I thought it might be best to submit >>>> all of the conversions at once and have all the relationships fully >>>> defined. >>>> >>>> Affected plugins: >>>> config >>>> user >>>> host >>>> service >>>> group >>>> hostgroup >>>> netgroup >>>> rolegroup >>>> taskgroup >>>> pwpolicy >>>> >>>> There's also a patch that fixes all unit tests. >>>> >>>> Jenny, I included you to Cc, because the patch introduces a lot of >>>> changes to the UI (and you're probably not going to like me for this). >>>> >>>> Each command extending the LDAP* base classes now has a --raw >>>> option. Without it, data from LDAP is formated and translated to >>>> human readable. For example: >>>> >>>> # ipa user-show admin --all >>>> ---------- >>>> user-show: >>>> ---------- >>>> User: admin >>>> user id: admin >>>> full name: Administrator >>>> last name: Administrator >>>> home directory: /home/admin >>>> login shell: /bin/bash >>>> uid number: 999 >>>> gid number: 1001 >>>> gecos: Administrator >>>> kerberos principal: admin at PZUNA >>>> last password change: 20090904122852Z >>>> password expiration: 20091203122852Z >>>> member of groups: admins >>>> >>>> # ipa user-show admin --all --raw >>>> ---------- >>>> user-show: >>>> ---------- >>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>> uid: admin >>>> cn: Administrator >>>> sn: Administrator >>>> homedirectory: /home/admin >>>> loginshell: /bin/bash >>>> uidnumber: 999 >>>> gidnumber: 1001 >>>> gecos: Administrator >>>> krbprincipalname: admin at PZUNA >>>> krblastpwdchange: 20090904122852Z >>>> krbpasswordexpiration: 20091203122852Z >>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>> objectclass: top >>>> objectclass: person >>>> objectclass: posixaccount >>>> objectclass: krbprincipalaux >>>> objectclass: inetuser >>>> >>>> Advantages: more user friendly, allows for easy localization, >>>> translation of DNs to primary keys (immediately usable as input to >>>> other plugin commands) >>>> >>>> I recommend, that you use the --raw flag for testing. >>>> >>>> >>>> >>>> I know it's a lot of changes, so I setup a git repo at: >>>> git://fedorapeople.org/~pzuna/freeipa.git >>>> >>>> It should be up-to-date with master and all my patches are applied >>>> there. I hope it makes reviewing them at least a bit easier. >>>> >>>> Pavel >>> >>> Why are you using a pre_callback() to define default values instead >>> of using default_from? It seems clearer to use that. >> You're probably referring to the user plugin, where gecos and >> krbprincipalname defaults are set inside pre_callback. It's a residue >> from some time ago when we didn't use autofill=True with default_from >> and it didn't have any effect on optional parameters. It's a small >> change, but I included an updated version of the patch with this email. > > Ok. I gather you've moved a lot of logic into the pre_callback plugin to > avoid overriding execute? One other goal we wanted was to allow plugins > to extend other plugins and this may be good step on the way there. So > for example, a user wants to be able to set some extra objectclass, they > could do it with a similar pre_callback extension to the user plugin > (once we do the plumbing for it, that is). > >>> This also duplicates some values in the attribute_names() dictionary. >>> I wonder if this can be either created from the parameters or define >>> a global set somewhere that covers all plugins. >> I know, but I couldn't find a better solution. I thought we could add >> something like a 'real_name' kwarg to params, but this has 2 main >> disadvantages: >> 1) it only makes sense with parameters that refer to an LDAP attribute >> 2) it doesn't work for attributes with no param counterparts >> >> The global set is a good idea as long as we consider only our own >> plugins. 3rd party plugins would have to modify this set to add their >> own attributes. Also, attributes might have a different meaning for >> different objects. They usually don't, but take 'cn' for example. We >> use it as an ID, name, full name (for users), etc. > > Ok, that's a good point. I'm wondering if its overkill to write a > registration system for this, something like: > > def set_label(attr, label, context='') > > def get_label(attr, context='') > > In this we'd store a dict that would be keyed on attr+context. Some > examples might be: > > set_label('uid', 'Login') > set_label('gn', 'First Name') > set_label('cn', 'Full Name', context='user') > set_label('cn', 'Group Name', context='group') > > The lookup would first look for a context-specific entry and fall back > to a non-context specific, something like: > > if attr+context in labeldict: return labeldict[attr+context] > elif attr in labeldict: return labeldict[attr] > else return "woop" > > Like I said, might be overkill ;-) > > But still, the alarms go off when we're putting the same things in > multiple places. > >>> In the user plugin 'ou' is in the default attributes. We don't use >>> this attribute. >> Since we don't use it, it's not going to get displayed anyway. >> >> All the values in attribute_names, default_attribute and >> attribute_order are subject to change. I set them to initial values I >> thought are acceptable, but I don't think I'm the right person to >> decide what's going to be there. Ideally, someone with more >> UI/text/user friendliness experience should review it (there's not >> programming knowledge required to change the values). > > Ok, this particular attribute brings up DIT issues which is why I > flagged it. > >>> I think that in general baseldap needs to be documented to explain >>> how things work. There is no explanation for object_class_config, for >>> example, that it defines the attribute in cn=ipaConfig that contains >>> the default list of objectclasses for the object. >> Yeah, there's no documentation at this point, but I'm working on it as >> we "speak". >> >>> rob >>> >> >> One more thing, I reviewed your latest patches and they make change to >> host and service plugins. Your patches should be pushed first, because >> they are more complex and also more important, so I posted updated >> versions to the corresponding email threads on freeipa-devel. >> >> Pavel > > Ok, I'm not too worried about that, its always a game of catch-up :-) > I've found another problem with the attribute map. I like your idea of breaking out memberof by different type but as it is now doesn't work, it only prints group membership. You'd have to parse the DN to distinguish between groups, taskgroups, etc. I think for the short-term we can make a note to do this and just print all memberships so we can get this committed. I'm still not a fan of the attribute_names within each plugin though, I need more convincing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 15 21:33:28 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 17:33:28 -0400 Subject: [Freeipa-devel] [PATCH] 274 detect whether to uninstall the CA or not Message-ID: <4AB00828.1000005@redhat.com> You had to pass --ca when uninstalling if you wanted the CA uninstalled. This was nuts, auto-detect it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-274-uninstall.patch Type: application/mbox Size: 884 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Sep 15 21:43:00 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Sep 2009 17:43:00 -0400 Subject: [Freeipa-devel] [PATCH] 263 Tighten up upgrade detection In-Reply-To: <4AA15D6F.2040305@redhat.com> References: <4A9EEBA8.9010709@redhat.com> <1252008792.15238.42.camel@localhost.localdomain> <4AA15D6F.2040305@redhat.com> Message-ID: <4AB00A64.4090700@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2009-09-02 at 18:03 -0400, Rob Crittenden wrote: >>> We have an upgrade script that runs in rpm %post to see if an >>> existing installation needs to be updated. This sometimes printed >>> spurious >>> error messages that were confusing. This patch attempts to tighten >>> things up >>> a bit. >> >> ACK >> >> SImo. >> > > pushed to ipa-1-2 Pushed a slightly modified version (different imports, location of CA) to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Tue Sep 15 22:09:28 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Sep 2009 18:09:28 -0400 Subject: [Freeipa-devel] Re: [Freeipa-users] IPA license In-Reply-To: <54027.79.30.159.52.1253048382.squirrel@picard.linux.it> References: <4AAFF12C.50107@redhat.com> <54027.79.30.159.52.1253048382.squirrel@picard.linux.it> Message-ID: <4AB01098.8030604@redhat.com> Andrea Modesto Rossi wrote: > On Mar, 15 Settembre 2009 9:55 pm, Dmitri Pal wrote: > >> We are considering to release freeIPA v2 under a less restrictive >> license than we used in IPA v1. >> It was "GPLv2 only" in v1.x and we think about "GPLv2 and later" or >> "GPLv3 and later". >> Please respond to this mail if there are any suggestions, comments or >> concerns. >> > > > Well, GPL3 is a good idea but ts there a particular reason to change > license policy? > > > It is just the fact that we came up with other components that we want to treat independently. It makes sense to license them with more flexible license for better adoption but exiting freeIPA license would create obstacles for it. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jderose at redhat.com Wed Sep 16 04:00:41 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 15 Sep 2009 22:00:41 -0600 Subject: [Freeipa-devel] Re: [Freeipa-users] IPA license In-Reply-To: <4AB01098.8030604@redhat.com> References: <4AAFF12C.50107@redhat.com> <54027.79.30.159.52.1253048382.squirrel@picard.linux.it> <4AB01098.8030604@redhat.com> Message-ID: <1253073641.7182.30.camel@jgd-dsk> On Tue, 2009-09-15 at 18:09 -0400, Dmitri Pal wrote: > Andrea Modesto Rossi wrote: > > On Mar, 15 Settembre 2009 9:55 pm, Dmitri Pal wrote: > > > >> We are considering to release freeIPA v2 under a less restrictive > >> license than we used in IPA v1. > >> It was "GPLv2 only" in v1.x and we think about "GPLv2 and later" or > >> "GPLv3 and later". > >> Please respond to this mail if there are any suggestions, comments or > >> concerns. > >> > > > > > > Well, GPL3 is a good idea but ts there a particular reason to change > > license policy? > > > > > > > It is just the fact that we came up with other components that we want > to treat > independently. It makes sense to license them with more flexible license > for better adoption but exiting freeIPA license would create obstacles > for it. Andrea, To elaborate on what Dmitri said, I would like to license the widget library used for the IPAv2 WebUI under GPLv3+ or LGPLv3+, but unfortunately there's a weird gotcha that prevents IPA under "GPLv2 only" from using any (L)GPLv3 libraries. This wouldn't be a problem if IPA was "GPLv2 or later" instead of "GPLv2 only", but I think the consensus is that as long as we make any change to the IPA license, we might as well migrate to "GPLv3 or later" (or at least that's my opinion). Although the widget library is the first place we encountered this gotcha with "GPLv2 only", I'm sure it will come up again in the near future, especially as IPA has such a plugin-focused architecture. If I understand the situation correctly, as it stands now you can't write an IPA plugin that links to (um, imports) any (L)GPLv3 libraries/modules, which is obviously far too restrictive and really limits what the community can do with the code. So sooner or later we're going to have to make this change. In an internal email conversation, Simo pointed me to this helpful chart: http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility Thoughts? Cheers, Jason From rcritten at redhat.com Wed Sep 16 17:03:23 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Sep 2009 13:03:23 -0400 Subject: [Freeipa-devel] [PATCH] 275 Fix deprecation warning Message-ID: <4AB11A5B.10600@redhat.com> This warning was logged in the Apache error log: /usr/lib/python2.6/site-packages/mod_python/importer.py:32: DeprecationWarning: the md5 module is deprecated; use hashlib instead Try to import hashlib for md5 and if it fails, fall back to the deprecated version. Tested on Python 2.4 and 2.6. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-276-deprecated.patch Type: application/mbox Size: 921 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Sep 16 17:05:50 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Sep 2009 13:05:50 -0400 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files Message-ID: <4AB11AEE.3040609@redhat.com> I goofed on the paths in the original patch I sent on this a while back. This corrects it. I know it looks like we're creating 0-length files here but with the %ghost directive it won't create the files, just own them. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-277-spec.patch Type: application/mbox Size: 1590 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Thu Sep 17 12:45:10 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 17 Sep 2009 14:45:10 +0200 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files In-Reply-To: <4AB11AEE.3040609@redhat.com> References: <4AB11AEE.3040609@redhat.com> Message-ID: <1253191510.3195.217.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-09-16 at 13:05 -0400, Rob Crittenden wrote: > I goofed on the paths in the original patch I sent on this a while back. > This corrects it. > > I know it looks like we're creating 0-length files here but with the > %ghost directive it won't create the files, just own them. > > rob Why do you create all the directories and 'touch' the files in the %install section when we own them using %ghost? I'm not 100% sure, but I believe this isn't required. What is the difference between /etc/ipa/ and /etc/httpd/conf.d/ ? Martin From mnagy at redhat.com Thu Sep 17 12:48:17 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 17 Sep 2009 14:48:17 +0200 Subject: [Freeipa-devel] [PATCH] 275 Fix deprecation warning In-Reply-To: <4AB11A5B.10600@redhat.com> References: <4AB11A5B.10600@redhat.com> Message-ID: <1253191697.3195.218.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-09-16 at 13:03 -0400, Rob Crittenden wrote: > This warning was logged in the Apache error log: > > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: > DeprecationWarning: the md5 module is deprecated; use hashlib instead > > Try to import hashlib for md5 and if it fails, fall back to the > deprecated version. Tested on Python 2.4 and 2.6. > > rob Ack. Martin From rcritten at redhat.com Thu Sep 17 13:06:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Sep 2009 09:06:05 -0400 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files In-Reply-To: <1253191510.3195.217.camel@wolverine.englab.brq.redhat.com> References: <4AB11AEE.3040609@redhat.com> <1253191510.3195.217.camel@wolverine.englab.brq.redhat.com> Message-ID: <4AB2343D.2080004@redhat.com> Martin Nagy wrote: > On Wed, 2009-09-16 at 13:05 -0400, Rob Crittenden wrote: >> I goofed on the paths in the original patch I sent on this a while back. >> This corrects it. >> >> I know it looks like we're creating 0-length files here but with the >> %ghost directive it won't create the files, just own them. >> >> rob > > Why do you create all the directories and 'touch' the files in the > %install section when we own them using %ghost? I'm not 100% sure, but I > believe this isn't required. These files are created by ipa-server-install, we don't provide empty templates, but I don't want IPA to leave orphaned files. In order to reference a file in %files, even with %ghost, the file needs to exist: http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html > What is the difference between /etc/ipa/ and /etc/httpd/conf.d/ ? /etc/ipa holds configuration files for IPA (the server, admin tools, etc). /etc/httpd/conf.d holds the IPA configuration file for Apache. So yes, we have 2 files named ipa.conf that do completely different things. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Sep 17 13:44:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 17 Sep 2009 09:44:12 -0400 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files In-Reply-To: <4AB2343D.2080004@redhat.com> References: <4AB11AEE.3040609@redhat.com> <1253191510.3195.217.camel@wolverine.englab.brq.redhat.com> <4AB2343D.2080004@redhat.com> Message-ID: <1253195052.28922.19.camel@localhost.localdomain> On Thu, 2009-09-17 at 09:06 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Wed, 2009-09-16 at 13:05 -0400, Rob Crittenden wrote: > >> I goofed on the paths in the original patch I sent on this a while back. > >> This corrects it. > >> > >> I know it looks like we're creating 0-length files here but with the > >> %ghost directive it won't create the files, just own them. > >> > >> rob > > > > Why do you create all the directories and 'touch' the files in the > > %install section when we own them using %ghost? I'm not 100% sure, but I > > believe this isn't required. > > These files are created by ipa-server-install, we don't provide empty > templates, but I don't want IPA to leave orphaned files. > > In order to reference a file in %files, even with %ghost, the file needs > to exist: > http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html > > > What is the difference between /etc/ipa/ and /etc/httpd/conf.d/ ? > > /etc/ipa holds configuration files for IPA (the server, admin tools, etc). > > /etc/httpd/conf.d holds the IPA configuration file for Apache. So yes, > we have 2 files named ipa.conf that do completely different things. Should we rename the second to something like ipa-http.conf ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Sep 17 13:47:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Sep 2009 09:47:20 -0400 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files In-Reply-To: <1253195052.28922.19.camel@localhost.localdomain> References: <4AB11AEE.3040609@redhat.com> <1253191510.3195.217.camel@wolverine.englab.brq.redhat.com> <4AB2343D.2080004@redhat.com> <1253195052.28922.19.camel@localhost.localdomain> Message-ID: <4AB23DE8.9080705@redhat.com> Simo Sorce wrote: > On Thu, 2009-09-17 at 09:06 -0400, Rob Crittenden wrote: >> Martin Nagy wrote: >>> On Wed, 2009-09-16 at 13:05 -0400, Rob Crittenden wrote: >>>> I goofed on the paths in the original patch I sent on this a while back. >>>> This corrects it. >>>> >>>> I know it looks like we're creating 0-length files here but with the >>>> %ghost directive it won't create the files, just own them. >>>> >>>> rob >>> Why do you create all the directories and 'touch' the files in the >>> %install section when we own them using %ghost? I'm not 100% sure, but I >>> believe this isn't required. >> These files are created by ipa-server-install, we don't provide empty >> templates, but I don't want IPA to leave orphaned files. >> >> In order to reference a file in %files, even with %ghost, the file needs >> to exist: >> http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html >> >>> What is the difference between /etc/ipa/ and /etc/httpd/conf.d/ ? >> /etc/ipa holds configuration files for IPA (the server, admin tools, etc). >> >> /etc/httpd/conf.d holds the IPA configuration file for Apache. So yes, >> we have 2 files named ipa.conf that do completely different things. > > Should we rename the second to something like ipa-http.conf ? > > Simo. > We could (in a separate patch) but AFAIK we've never had any confusion over one file vs the other. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Thu Sep 17 13:49:04 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 17 Sep 2009 15:49:04 +0200 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files In-Reply-To: <4AB2343D.2080004@redhat.com> References: <4AB11AEE.3040609@redhat.com> <1253191510.3195.217.camel@wolverine.englab.brq.redhat.com> <4AB2343D.2080004@redhat.com> Message-ID: <1253195344.3661.2.camel@wolverine.englab.brq.redhat.com> On Thu, 2009-09-17 at 09:06 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Wed, 2009-09-16 at 13:05 -0400, Rob Crittenden wrote: > >> I goofed on the paths in the original patch I sent on this a while back. > >> This corrects it. > >> > >> I know it looks like we're creating 0-length files here but with the > >> %ghost directive it won't create the files, just own them. > >> > >> rob > > > > Why do you create all the directories and 'touch' the files in the > > %install section when we own them using %ghost? I'm not 100% sure, but I > > believe this isn't required. > > These files are created by ipa-server-install, we don't provide empty > templates, but I don't want IPA to leave orphaned files. > > In order to reference a file in %files, even with %ghost, the file needs > to exist: > http://www.rpm.org/max-rpm-snapshot/s1-rpm-inside-files-list-directives.html > > > What is the difference between /etc/ipa/ and /etc/httpd/conf.d/ ? > > /etc/ipa holds configuration files for IPA (the server, admin tools, etc). > > /etc/httpd/conf.d holds the IPA configuration file for Apache. So yes, > we have 2 files named ipa.conf that do completely different things. > > rob Ack. I was looking at the same page but didn't notice the example that actually uses touch, sorry. Martin From pzuna at redhat.com Fri Sep 18 06:34:20 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Fri, 18 Sep 2009 08:34:20 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AB006FC.4070008@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> Message-ID: <4AB329EC.8040703@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Pavel Zuna wrote: >>> Rob Crittenden wrote: >>>> Pavel Z?na wrote: >>>>> This is a series of patches that depends on patches: >>>>> - Improve attribute printing in the CLI. >>>>> - Improve ipalib.plugins.baseldap classes. >>>>> >>>>> All plugins are converted to extend baseldap classes. This makes >>>>> things more consistent, fixes some general bugs (with return values >>>>> for example) and it also makes plugins easier to maintain (as it >>>>> removes a lot of duplicate code). >>>>> >>>>> Because baseldap classes have features that enable us to define >>>>> relationships between plugins, I thought it might be best to submit >>>>> all of the conversions at once and have all the relationships fully >>>>> defined. >>>>> >>>>> Affected plugins: >>>>> config >>>>> user >>>>> host >>>>> service >>>>> group >>>>> hostgroup >>>>> netgroup >>>>> rolegroup >>>>> taskgroup >>>>> pwpolicy >>>>> >>>>> There's also a patch that fixes all unit tests. >>>>> >>>>> Jenny, I included you to Cc, because the patch introduces a lot of >>>>> changes to the UI (and you're probably not going to like me for this). >>>>> >>>>> Each command extending the LDAP* base classes now has a --raw >>>>> option. Without it, data from LDAP is formated and translated to >>>>> human readable. For example: >>>>> >>>>> # ipa user-show admin --all >>>>> ---------- >>>>> user-show: >>>>> ---------- >>>>> User: admin >>>>> user id: admin >>>>> full name: Administrator >>>>> last name: Administrator >>>>> home directory: /home/admin >>>>> login shell: /bin/bash >>>>> uid number: 999 >>>>> gid number: 1001 >>>>> gecos: Administrator >>>>> kerberos principal: admin at PZUNA >>>>> last password change: 20090904122852Z >>>>> password expiration: 20091203122852Z >>>>> member of groups: admins >>>>> >>>>> # ipa user-show admin --all --raw >>>>> ---------- >>>>> user-show: >>>>> ---------- >>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>> uid: admin >>>>> cn: Administrator >>>>> sn: Administrator >>>>> homedirectory: /home/admin >>>>> loginshell: /bin/bash >>>>> uidnumber: 999 >>>>> gidnumber: 1001 >>>>> gecos: Administrator >>>>> krbprincipalname: admin at PZUNA >>>>> krblastpwdchange: 20090904122852Z >>>>> krbpasswordexpiration: 20091203122852Z >>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>> objectclass: top >>>>> objectclass: person >>>>> objectclass: posixaccount >>>>> objectclass: krbprincipalaux >>>>> objectclass: inetuser >>>>> >>>>> Advantages: more user friendly, allows for easy localization, >>>>> translation of DNs to primary keys (immediately usable as input to >>>>> other plugin commands) >>>>> >>>>> I recommend, that you use the --raw flag for testing. >>>>> >>>>> >>>>> >>>>> I know it's a lot of changes, so I setup a git repo at: >>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>> >>>>> It should be up-to-date with master and all my patches are applied >>>>> there. I hope it makes reviewing them at least a bit easier. >>>>> >>>>> Pavel >>>> >>>> Why are you using a pre_callback() to define default values instead >>>> of using default_from? It seems clearer to use that. >>> You're probably referring to the user plugin, where gecos and >>> krbprincipalname defaults are set inside pre_callback. It's a residue >>> from some time ago when we didn't use autofill=True with default_from >>> and it didn't have any effect on optional parameters. It's a small >>> change, but I included an updated version of the patch with this email. >> >> Ok. I gather you've moved a lot of logic into the pre_callback plugin >> to avoid overriding execute? One other goal we wanted was to allow >> plugins to extend other plugins and this may be good step on the way >> there. So for example, a user wants to be able to set some extra >> objectclass, they could do it with a similar pre_callback extension to >> the user plugin (once we do the plumbing for it, that is). Right. The goal is to have a common execute in the baseclass, that does most of the dirty work and let the user/plugin author add the specifics of his plugin in the pre/post callbacks. All the data generated by the base (before calling python-ldap) is available for modification in the pre-callbacks and all data coming out of python-ldap is made available in the post-callback. And yes, the plugins could be almost endlessly extended this way. For example, someone could do this: from ipalib.plugins.user import user_add class user_add_extended(user_add): def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): # let the original user_add plugin do its job super(user_add_extended, self).pre_callback( ldap, dn, entry_attrs, *keys, **options) # add an extra object class entry_attrs['objectclass'].append('new_object_class') return dn api.register(user_add_extended) >>>> This also duplicates some values in the attribute_names() >>>> dictionary. I wonder if this can be either created from the >>>> parameters or define a global set somewhere that covers all plugins. >>> I know, but I couldn't find a better solution. I thought we could add >>> something like a 'real_name' kwarg to params, but this has 2 main >>> disadvantages: >>> 1) it only makes sense with parameters that refer to an LDAP attribute >>> 2) it doesn't work for attributes with no param counterparts >>> >>> The global set is a good idea as long as we consider only our own >>> plugins. 3rd party plugins would have to modify this set to add their >>> own attributes. Also, attributes might have a different meaning for >>> different objects. They usually don't, but take 'cn' for example. We >>> use it as an ID, name, full name (for users), etc. >> >> Ok, that's a good point. I'm wondering if its overkill to write a >> registration system for this, something like: >> >> def set_label(attr, label, context='') >> >> def get_label(attr, context='') >> >> In this we'd store a dict that would be keyed on attr+context. Some >> examples might be: >> >> set_label('uid', 'Login') >> set_label('gn', 'First Name') >> set_label('cn', 'Full Name', context='user') >> set_label('cn', 'Group Name', context='group') >> >> The lookup would first look for a context-specific entry and fall back >> to a non-context specific, something like: >> >> if attr+context in labeldict: return labeldict[attr+context] >> elif attr in labeldict: return labeldict[attr] >> else return "woop" >> >> Like I said, might be overkill ;-) >> >> But still, the alarms go off when we're putting the same things in >> multiple places. >> Yeah, the registration system sounds like overkill all right. :D Seriously, I was thinking about several ways on how to resolve this issue. Ideally, all information about attributes should be retrieved from the schema. Unfortunately, it cannot be done. There's just very little information in there. Another idea was to have an LDAPAttribute base class, that we would extend for each attribute. We could then have a ldapattribute.py module in ipalib/plugins with all the attributes we use defined there. If 3rd parties require a new attribute, they just create their own LDAPAttribute subclass in their plugins. I think that this would be the best and cleanest approach. LDAPObjects would have a set of LDAPAttribute references and do all attribute manipulation using them. Also, attribute parameters could be automatically generated, so they wouldn't mix with control parameters in takes_params (like --all, --raw, --posix for groups, etc.). This is probably the way we'll be going in the future, but there's still a few problems I have to resolve before implementing it. By the way, my goal is to move all this LDAP infrastructure from the plugin layer into the core library itself once it's mature (and documented) enough. Probably not going to happen in v2, but we'll see how it goes. >>>> In the user plugin 'ou' is in the default attributes. We don't use >>>> this attribute. >>> Since we don't use it, it's not going to get displayed anyway. >>> >>> All the values in attribute_names, default_attribute and >>> attribute_order are subject to change. I set them to initial values I >>> thought are acceptable, but I don't think I'm the right person to >>> decide what's going to be there. Ideally, someone with more >>> UI/text/user friendliness experience should review it (there's not >>> programming knowledge required to change the values). >> >> Ok, this particular attribute brings up DIT issues which is why I >> flagged it. >> >>>> I think that in general baseldap needs to be documented to explain >>>> how things work. There is no explanation for object_class_config, >>>> for example, that it defines the attribute in cn=ipaConfig that >>>> contains the default list of objectclasses for the object. >>> Yeah, there's no documentation at this point, but I'm working on it >>> as we "speak". >>> >>>> rob >>>> >>> >>> One more thing, I reviewed your latest patches and they make change >>> to host and service plugins. Your patches should be pushed first, >>> because they are more complex and also more important, so I posted >>> updated versions to the corresponding email threads on freeipa-devel. >>> >>> Pavel >> >> Ok, I'm not too worried about that, its always a game of catch-up :-) >> > > I've found another problem with the attribute map. I like your idea of > breaking out memberof by different type but as it is now doesn't work, > it only prints group membership. You'd have to parse the DN to > distinguish between groups, taskgroups, etc. And that's exactly what I'm doing in LDAPObject.convert_attribute_members. I mean the DN parsing. It just doesn't work for users at the moment, because I forgot to add the other types of groups in users attribute_members['memberof']. in ipalib/plugins/user.py: class user(LDAPObject): # ... attribute_members = { # add other groups here # example 'memberof': ['group', 'taskgroup'] 'memberof': ['group'] } # ... try: ipa user-add test --first=first --last=last ipa taskgroup-add tasktest --desc=desc ipa taskgroup-add-member tasktest --users=test ipa user-show test --all Should work. Note: Just noticed it won't work for netgroups, because I forgot to override LDAPObject.get_primary_key_from_dn in the netgroup class. Normally get_primary_key_from_dn just returns the value of RDN, but for netgroups we have to do a search to retrieve the primary key. class netgroup(LDAPObject): # ... def get_primary_key_from_dn(self, dn): (dn, entry_attrs) = self.backend.get_entry( dn, [self.primary_key.name] ) return entry_attrs.get(self.primary_key.name, '') # ... > I think for the short-term we can make a note to do this and just print > all memberships so we can get this committed. I'm still not a fan of the > attribute_names within each plugin though, I need more convincing. > > rob > By the way, I'm going on vacation next week. So, I think we should wait anyway before committing this. Pavel From jderose at redhat.com Mon Sep 21 22:39:45 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 21 Sep 2009 16:39:45 -0600 Subject: [Freeipa-devel] Annoucing assets 0.1.0 Message-ID: <1253572785.14684.46.camel@jgd-dsk> The widget library previously had a `wehjit.assets` module for managing JavaScript and CSS assets. This module automatically named the assets using a content hash (sha1sum), while allowing the application to retrieve the current filename using a human readable key. But this module also was using SQLAlchemy to maintain the key to content-hash-name mapping in a Sqlite database, which was way overkill and introducing an otherwise unneeded dependency (SQLAlchemy). So I re-implemented the assets functionality using symlinks to store the key to content-hash-name mapping (instead of a database). As long as I was at it, I split this functionality into a separate tree/project. I did this because it was little work and the assets functionality is widely useful for many different projects. The 0.1.0 tarball and gpg sig are available here: http://jderose.fedorapeople.org/assets/0.1.0/ And there is API documentation here: http://jderose.fedorapeople.org/assets/0.1.0/apidoc/ This type of asset management is important for scalability and performance, but also in order to avoid the dreaded "Did you try clearing your cache?" syndrome. Naming the assets by their content-hash allows us to tightly couple a page with the exact asset versions it's intended to work with. From jderose at redhat.com Wed Sep 23 06:32:35 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 23 Sep 2009 06:32:35 +0000 Subject: [Freeipa-devel] Announcing wehjit 0.1.0 Message-ID: <1253687555.21204.26.camel@jgd-dsk> Between my informal 0.0.1 release and this formal 0.1.0 release, I added a short tutorial and fleshed out the documentation, expanded the unit test coverage, and improved many areas where the API was either awkward or had limitations. There are also a number of new features, the most notable being: 1) proper support for rendering an application to static files; and 2) the option to serialize to HTML instead of XHTML. The built-in demo can be rendered to static files using the --static option like this: ./wehjit-demo --static The wehjit 0.1.0 tarball and gpg sig are available here: http://jderose.fedorapeople.org/wehjit/0.1.0/ The built-in demo is available in static form here: http://jderose.fedorapeople.org/wehjit/0.1.0/demo/ The tutorial and API documentation are available here: http://jderose.fedorapeople.org/wehjit/0.1.0/apidoc/ And you can get my bzr branch like this: bzr branch http://jderose.fedorapeople.org/bzr/wehjit/ Cheers, Jason From jderose at redhat.com Wed Sep 23 07:15:18 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 23 Sep 2009 01:15:18 -0600 Subject: [Freeipa-devel] spec files for assets and wehjit Message-ID: <1253690118.2467.1.camel@jgd-dsk> These spec files are working for me under Fedora 11. Comments welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: python-assets.spec Type: text/x-rpm-spec Size: 1473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: python-wehjit.spec Type: text/x-rpm-spec Size: 1455 bytes Desc: not available URL: From jderose at redhat.com Thu Sep 24 23:58:25 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 24 Sep 2009 17:58:25 -0600 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain In-Reply-To: <4AAEB095.6000005@redhat.com> References: <4AAEB095.6000005@redhat.com> Message-ID: <1253836705.20551.12.camel@jgd-dsk> ack. pushed to master. This patch was missing a "BuildRequires: xmlrpc-c-devel", which I fixed in my attached patch. I pushed it to master under 1-line rule. On Mon, 2009-09-14 at 17:07 -0400, Rob Crittenden wrote: > NOTE, this patch replaces a previous patch to do the same thing. I fixed > a few problems Simo pointed out and re-based it against the current master. > > This largish patch adds host enrollment. There are several scenarios > that are covered. All of these assume that the IPA client machine has > already been set up (ipa-client-install): > > 1. Full admin enrollment. This will create the host entry, a host/ > service principal and a keytab for that principal in /etc/krb5.keytab. > > 2. Junior admin enrollment. There are lots of levels of delegation > possible here, but at a minimum they would be able to enroll an existing > host by creating the service principal and keytab. Additional rights > such as adding a host could be added as well. > > 3. Bulk enrollment. If a host entry is pre-created by another admin and > it contains an enrollment password (in the userPassword attribute) then > an LDAP-based enrollment can take place. The client binds as the host > and generates a keytab for itself. > > One really significant change is I've switch to openldap as the LDAP > client. Doing SSL with mozldap would have required a significant amount > of more code (because we can't assume there is already an NSS db lying > around that trusts the IPA CA). > > I didn't completely disable the mozldap option but by default things > will build with openldap now. > > This also adds a first pass at Get Effective Rights support. This is so > we can know in advance if an operation would succeed and makes things > generally nicer. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-018-BuildRequires-xmlrpc-c-devel.patch Type: text/x-patch Size: 705 bytes Desc: not available URL: From rcritten at redhat.com Fri Sep 25 15:13:12 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Sep 2009 11:13:12 -0400 Subject: [Freeipa-devel] [PATCH] 278 Only initialize API once in the installer Message-ID: <4ABCDE08.20004@redhat.com> Two patches crossed in the night, both added a call to initialize the API. There can be only one. Also need to make the ldap2 plugin more flexible and not require the schema to be loaded at startup so we can initialize the API before IPA has been installed. Addresses bug 525303. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-278-installer.patch Type: application/mbox Size: 8493 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Fri Sep 25 15:43:53 2009 From: jdennis at redhat.com (John Dennis) Date: Fri, 25 Sep 2009 11:43:53 -0400 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain In-Reply-To: <1253836705.20551.12.camel@jgd-dsk> References: <4AAEB095.6000005@redhat.com> <1253836705.20551.12.camel@jgd-dsk> Message-ID: <4ABCE539.8070702@redhat.com> On 09/24/2009 07:58 PM, Jason Gerard DeRose wrote: > ack. pushed to master. Opps, perhaps too late, but I'd like to NAK this patch. I've been using the code in ipa-join.c as an example and have discovered several problems with the use of the xmlrpc-c library, which by the way I truly dislike. I'm going to wait until I've got my xmlrpc-c code working to my satisfaction before I post the issues. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Sep 25 22:23:30 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Sep 2009 18:23:30 -0400 Subject: [Freeipa-devel] [PATCH] 279 Fix/enhance the aci plugin Message-ID: <4ABD42E2.3040600@redhat.com> The aci plugin didn't quite work with the new ldap2 backend, fix that. We already walk through the target part of the ACI syntax so skip that in the regex altogether. This now lets us handle all current ACIs in IPA (some used to be ignored/skipped) Add support for user groups so one can do v1-style delegation (group A can write attributes x,y,z in group B). It is actually quite a lot more flexible than that but you get the idea. I'm not sure yet but it might be better to split this out into a separate plugin, or to make a simple mode or something. Improve error messages in the aci library (so you can better know what broke, not just that it is broken). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-279-aci.patch Type: application/mbox Size: 11128 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Sat Sep 26 02:25:26 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Sep 2009 22:25:26 -0400 Subject: [Freeipa-devel] [PATCH] 279 Fix/enhance the aci plugin In-Reply-To: <4ABD42E2.3040600@redhat.com> References: <4ABD42E2.3040600@redhat.com> Message-ID: <4ABD7B96.3060708@redhat.com> Rob Crittenden wrote: > The aci plugin didn't quite work with the new ldap2 backend, fix that. > > We already walk through the target part of the ACI syntax so skip that > in the regex altogether. This now lets us handle all current ACIs in IPA > (some used to be ignored/skipped) > > Add support for user groups so one can do v1-style delegation (group A > can write attributes x,y,z in group B). It is actually quite a lot more > flexible than that but you get the idea. I'm not sure yet but it might > be better to split this out into a separate plugin, or to make a simple > mode or something. > > Improve error messages in the aci library (so you can better know what > broke, not just that it is broken). > > rob As odd as it sounds, I'm going to nack my own patch. I see some places that need more work. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Sep 28 14:15:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Sep 2009 10:15:04 -0400 Subject: [Freeipa-devel] [PATCH] 279 Updated patch to fix/enhance the aci plugin Message-ID: <4AC0C4E8.9050203@redhat.com> Here is an updated patch with a bit of documentation added. The aci plugin didn't quite work with the new ldap2 backend, fix that. We already walk through the target part of the ACI syntax so skip that in the regex altogether. This now lets us handle all current ACIs in IPA (some used to be ignored/skipped) Add support for user groups so one can do v1-style delegation (group A can write attributes x,y,z in group B). It is actually quite a lot more flexible than that but you get the idea. I'm not sure yet but it might be better to split this out into a separate plugin, or to make a simple mode or something. Improve error messages in the aci library (so you can better know what broke, not just that it is broken). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-279-aci.patch Type: application/mbox Size: 15608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Mon Sep 28 21:11:15 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 28 Sep 2009 15:11:15 -0600 Subject: [Freeipa-devel] [PATCH] 273 join a host to an IPA domain In-Reply-To: <4AAF8B77.8070704@redhat.com> References: <4AAEB095.6000005@redhat.com> <4AAF8406.3070905@redhat.com> <4AAF8B77.8070704@redhat.com> Message-ID: <1254172275.5498.0.camel@jgd-dsk> ack. pushed to master. On Tue, 2009-09-15 at 14:41 +0200, Pavel Zuna wrote: > Pavel Zuna wrote: > > Rob Crittenden wrote: > >> NOTE, this patch replaces a previous patch to do the same thing. I > >> fixed a few problems Simo pointed out and re-based it against the > >> current master. > >> > >> This largish patch adds host enrollment. There are several scenarios > >> that are covered. All of these assume that the IPA client machine has > >> already been set up (ipa-client-install): > >> > >> 1. Full admin enrollment. This will create the host entry, a host/ > >> service principal and a keytab for that principal in /etc/krb5.keytab. > >> > >> 2. Junior admin enrollment. There are lots of levels of delegation > >> possible here, but at a minimum they would be able to enroll an > >> existing host by creating the service principal and keytab. Additional > >> rights such as adding a host could be added as well. > >> > >> 3. Bulk enrollment. If a host entry is pre-created by another admin > >> and it contains an enrollment password (in the userPassword attribute) > >> then an LDAP-based enrollment can take place. The client binds as the > >> host and generates a keytab for itself. > >> > >> One really significant change is I've switch to openldap as the LDAP > >> client. Doing SSL with mozldap would have required a significant > >> amount of more code (because we can't assume there is already an NSS > >> db lying around that trusts the IPA CA). > >> > >> I didn't completely disable the mozldap option but by default things > >> will build with openldap now. > >> > >> This also adds a first pass at Get Effective Rights support. This is > >> so we can know in advance if an operation would succeed and makes > >> things generally nicer. > >> > >> rob > > Looking good! > > > > I noticed it makes changes to the host plugin and since this is probably > > going to get into the tree first: here's an updated version of my host > > plugin patch. > > > > Pavel > Oops! Bad patch. > > Pavel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jderose at redhat.com Mon Sep 28 21:35:09 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 28 Sep 2009 15:35:09 -0600 Subject: [Freeipa-devel] [PATCH] 275 Fix deprecation warning In-Reply-To: <4AB11A5B.10600@redhat.com> References: <4AB11A5B.10600@redhat.com> Message-ID: <1254173709.5498.1.camel@jgd-dsk> ack. pushed to master. On Wed, 2009-09-16 at 13:03 -0400, Rob Crittenden wrote: > This warning was logged in the Apache error log: > > /usr/lib/python2.6/site-packages/mod_python/importer.py:32: > DeprecationWarning: the md5 module is deprecated; use hashlib instead > > Try to import hashlib for md5 and if it fails, fall back to the > deprecated version. Tested on Python 2.4 and 2.6. > > rob > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jderose at redhat.com Mon Sep 28 21:36:29 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 28 Sep 2009 15:36:29 -0600 Subject: [Freeipa-devel] [PATCH] 277 properly own Apache config files In-Reply-To: <4AB11AEE.3040609@redhat.com> References: <4AB11AEE.3040609@redhat.com> Message-ID: <1254173789.5498.2.camel@jgd-dsk> ack. pushed to master. On Wed, 2009-09-16 at 13:05 -0400, Rob Crittenden wrote: > I goofed on the paths in the original patch I sent on this a while back. > This corrects it. > > I know it looks like we're creating 0-length files here but with the > %ghost directive it won't create the files, just own them. > > rob > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jderose at redhat.com Tue Sep 29 04:26:15 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 29 Sep 2009 04:26:15 +0000 Subject: [Freeipa-devel] Re: new 278 patch In-Reply-To: <4AC180BB.8040302@redhat.com> References: <4AC180BB.8040302@redhat.com> Message-ID: <1254198375.5498.3.camel@jgd-dsk> ack. pushed to master. On Mon, 2009-09-28 at 23:36 -0400, Rob Crittenden wrote: > See if this one works better. Just be sure to commit the right one :-) > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-278-2-installer.patch Type: text/x-patch Size: 8443 bytes Desc: not available URL: From jderose at redhat.com Tue Sep 29 04:29:31 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 28 Sep 2009 22:29:31 -0600 Subject: [Freeipa-devel] [PATCH] 279 Updated patch to fix/enhance the aci plugin In-Reply-To: <4AC0C4E8.9050203@redhat.com> References: <4AC0C4E8.9050203@redhat.com> Message-ID: <1254198571.5498.4.camel@jgd-dsk> On Mon, 2009-09-28 at 10:15 -0400, Rob Crittenden wrote: > Here is an updated patch with a bit of documentation added. > > The aci plugin didn't quite work with the new ldap2 backend, fix that. > > We already walk through the target part of the ACI syntax so skip that > in the regex altogether. This now lets us handle all current ACIs in IPA > (some used to be ignored/skipped) > > Add support for user groups so one can do v1-style delegation (group A > can write attributes x,y,z in group B). It is actually quite a lot more > flexible than that but you get the idea. I'm not sure yet but it might > be better to split this out into a separate plugin, or to make a simple > mode or something. > > Improve error messages in the aci library (so you can better know what > broke, not just that it is broken). > > rob ack. pushed to master. From ssorce at redhat.com Tue Sep 29 16:43:15 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 29 Sep 2009 12:43:15 -0400 Subject: [Freeipa-devel] [PATCH] Fix sasl mappings Message-ID: <1254242595.3017.10.camel@localhost.localdomain> Sasl mappings never worked properly with full principal names. This patch fixes the problem. See bug#526284 Should probably commit this patch also against v1. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-SASL-mappings.patch Type: application/mbox Size: 1149 bytes Desc: not available URL: From pzuna at redhat.com Wed Sep 30 14:32:35 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 30 Sep 2009 16:32:35 +0200 Subject: [Freeipa-devel] [PATCH] 274 detect whether to uninstall the CA or not In-Reply-To: <4AB00828.1000005@redhat.com> References: <4AB00828.1000005@redhat.com> Message-ID: <4AC36C03.2000508@redhat.com> Rob Crittenden wrote: > You had to pass --ca when uninstalling if you wanted the CA uninstalled. > This was nuts, auto-detect it. > > rob ack. Pavel From pzuna at redhat.com Wed Sep 30 14:43:19 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 30 Sep 2009 16:43:19 +0200 Subject: [Freeipa-devel] [PATCH] Add HBAC plugin and introduce GeneralizedTime parameter type. Message-ID: <4AC36E87.2080804@redhat.com> Sumit noticed, that the HBAC plugin didn't make it into the tree and the patch got lost in the depths of freeipa-devel. I reworked the plugin to meet the current standards and changed GeneraliSedTime to GeneraliZedTime. For now, I put the new parameter type into a separate file in ipalib/plugins/generalizedtime.py. When it's tested enough, we're going to move it to ipalib/parameters.py. The patch also modifies bootstrap-template.ldif to create a cn=hbac container after installing IPA. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Add-HBAC-plugin-and-introduce-GeneralizedTime-parame.patch Type: application/mbox Size: 15654 bytes Desc: not available URL: From pzuna at redhat.com Wed Sep 30 14:45:45 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 30 Sep 2009 16:45:45 +0200 Subject: [Freeipa-devel] Re: [PATCHES] Make plugins use baseldap classes. In-Reply-To: <4AB329EC.8040703@redhat.com> References: <4AA66427.1050404@redhat.com> <4AAA6110.9090402@redhat.com> <4AAF8FB0.7030508@redhat.com> <4AAF9AD0.7090204@redhat.com> <4AB006FC.4070008@redhat.com> <4AB329EC.8040703@redhat.com> Message-ID: <4AC36F19.2040703@redhat.com> Pavel Z?na wrote: > Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Pavel Zuna wrote: >>>> Rob Crittenden wrote: >>>>> Pavel Z?na wrote: >>>>>> This is a series of patches that depends on patches: >>>>>> - Improve attribute printing in the CLI. >>>>>> - Improve ipalib.plugins.baseldap classes. >>>>>> >>>>>> All plugins are converted to extend baseldap classes. This makes >>>>>> things more consistent, fixes some general bugs (with return >>>>>> values for example) and it also makes plugins easier to maintain >>>>>> (as it removes a lot of duplicate code). >>>>>> >>>>>> Because baseldap classes have features that enable us to define >>>>>> relationships between plugins, I thought it might be best to >>>>>> submit all of the conversions at once and have all the >>>>>> relationships fully defined. >>>>>> >>>>>> Affected plugins: >>>>>> config >>>>>> user >>>>>> host >>>>>> service >>>>>> group >>>>>> hostgroup >>>>>> netgroup >>>>>> rolegroup >>>>>> taskgroup >>>>>> pwpolicy >>>>>> >>>>>> There's also a patch that fixes all unit tests. >>>>>> >>>>>> Jenny, I included you to Cc, because the patch introduces a lot of >>>>>> changes to the UI (and you're probably not going to like me for >>>>>> this). >>>>>> >>>>>> Each command extending the LDAP* base classes now has a --raw >>>>>> option. Without it, data from LDAP is formated and translated to >>>>>> human readable. For example: >>>>>> >>>>>> # ipa user-show admin --all >>>>>> ---------- >>>>>> user-show: >>>>>> ---------- >>>>>> User: admin >>>>>> user id: admin >>>>>> full name: Administrator >>>>>> last name: Administrator >>>>>> home directory: /home/admin >>>>>> login shell: /bin/bash >>>>>> uid number: 999 >>>>>> gid number: 1001 >>>>>> gecos: Administrator >>>>>> kerberos principal: admin at PZUNA >>>>>> last password change: 20090904122852Z >>>>>> password expiration: 20091203122852Z >>>>>> member of groups: admins >>>>>> >>>>>> # ipa user-show admin --all --raw >>>>>> ---------- >>>>>> user-show: >>>>>> ---------- >>>>>> dn: uid=admin,cn=users,cn=accounts,dc=pzuna >>>>>> uid: admin >>>>>> cn: Administrator >>>>>> sn: Administrator >>>>>> homedirectory: /home/admin >>>>>> loginshell: /bin/bash >>>>>> uidnumber: 999 >>>>>> gidnumber: 1001 >>>>>> gecos: Administrator >>>>>> krbprincipalname: admin at PZUNA >>>>>> krblastpwdchange: 20090904122852Z >>>>>> krbpasswordexpiration: 20091203122852Z >>>>>> memberof: cn=admins,cn=groups,cn=accounts,dc=pzuna >>>>>> objectclass: top >>>>>> objectclass: person >>>>>> objectclass: posixaccount >>>>>> objectclass: krbprincipalaux >>>>>> objectclass: inetuser >>>>>> >>>>>> Advantages: more user friendly, allows for easy localization, >>>>>> translation of DNs to primary keys (immediately usable as input to >>>>>> other plugin commands) >>>>>> >>>>>> I recommend, that you use the --raw flag for testing. >>>>>> >>>>>> >>>>>> >>>>>> I know it's a lot of changes, so I setup a git repo at: >>>>>> git://fedorapeople.org/~pzuna/freeipa.git >>>>>> >>>>>> It should be up-to-date with master and all my patches are applied >>>>>> there. I hope it makes reviewing them at least a bit easier. >>>>>> >>>>>> Pavel >>>>> >>>>> Why are you using a pre_callback() to define default values instead >>>>> of using default_from? It seems clearer to use that. >>>> You're probably referring to the user plugin, where gecos and >>>> krbprincipalname defaults are set inside pre_callback. It's a >>>> residue from some time ago when we didn't use autofill=True with >>>> default_from and it didn't have any effect on optional parameters. >>>> It's a small change, but I included an updated version of the patch >>>> with this email. >>> >>> Ok. I gather you've moved a lot of logic into the pre_callback plugin >>> to avoid overriding execute? One other goal we wanted was to allow >>> plugins to extend other plugins and this may be good step on the way >>> there. So for example, a user wants to be able to set some extra >>> objectclass, they could do it with a similar pre_callback extension >>> to the user plugin (once we do the plumbing for it, that is). > Right. The goal is to have a common execute in the baseclass, that does > most of the dirty work and let the user/plugin author add the specifics > of his plugin in the pre/post callbacks. All the data generated by the > base (before calling python-ldap) is available for modification in the > pre-callbacks and all data coming out of python-ldap is made available > in the post-callback. > > And yes, the plugins could be almost endlessly extended this way. For > example, someone could do this: > > from ipalib.plugins.user import user_add > > class user_add_extended(user_add): > def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): > # let the original user_add plugin do its job > super(user_add_extended, self).pre_callback( > ldap, dn, entry_attrs, *keys, **options) > # add an extra object class > entry_attrs['objectclass'].append('new_object_class') > return dn > > api.register(user_add_extended) > >>>>> This also duplicates some values in the attribute_names() >>>>> dictionary. I wonder if this can be either created from the >>>>> parameters or define a global set somewhere that covers all plugins. >>>> I know, but I couldn't find a better solution. I thought we could >>>> add something like a 'real_name' kwarg to params, but this has 2 >>>> main disadvantages: >>>> 1) it only makes sense with parameters that refer to an LDAP attribute >>>> 2) it doesn't work for attributes with no param counterparts >>>> >>>> The global set is a good idea as long as we consider only our own >>>> plugins. 3rd party plugins would have to modify this set to add >>>> their own attributes. Also, attributes might have a different >>>> meaning for different objects. They usually don't, but take 'cn' for >>>> example. We use it as an ID, name, full name (for users), etc. >>> >>> Ok, that's a good point. I'm wondering if its overkill to write a >>> registration system for this, something like: >>> >>> def set_label(attr, label, context='') >>> >>> def get_label(attr, context='') >>> >>> In this we'd store a dict that would be keyed on attr+context. Some >>> examples might be: >>> >>> set_label('uid', 'Login') >>> set_label('gn', 'First Name') >>> set_label('cn', 'Full Name', context='user') >>> set_label('cn', 'Group Name', context='group') >>> >>> The lookup would first look for a context-specific entry and fall >>> back to a non-context specific, something like: >>> >>> if attr+context in labeldict: return labeldict[attr+context] >>> elif attr in labeldict: return labeldict[attr] >>> else return "woop" >>> >>> Like I said, might be overkill ;-) >>> >>> But still, the alarms go off when we're putting the same things in >>> multiple places. >>> > Yeah, the registration system sounds like overkill all right. :D > > Seriously, I was thinking about several ways on how to resolve this > issue. Ideally, all information about attributes should be retrieved > from the schema. Unfortunately, it cannot be done. There's just very > little information in there. > > Another idea was to have an LDAPAttribute base class, that we would > extend for each attribute. We could then have a ldapattribute.py module > in ipalib/plugins with all the attributes we use defined there. If 3rd > parties require a new attribute, they just create their own > LDAPAttribute subclass in their plugins. I think that this would be the > best and cleanest approach. LDAPObjects would have a set of > LDAPAttribute references and do all attribute manipulation using them. > Also, attribute parameters could be automatically generated, so they > wouldn't mix with control parameters in takes_params (like --all, --raw, > --posix for groups, etc.). This is probably the way we'll be going in > the future, but there's still a few problems I have to resolve before > implementing it. > > By the way, my goal is to move all this LDAP infrastructure from the > plugin layer into the core library itself once it's mature (and > documented) enough. Probably not going to happen in v2, but we'll see > how it goes. > >>>>> In the user plugin 'ou' is in the default attributes. We don't use >>>>> this attribute. >>>> Since we don't use it, it's not going to get displayed anyway. >>>> >>>> All the values in attribute_names, default_attribute and >>>> attribute_order are subject to change. I set them to initial values >>>> I thought are acceptable, but I don't think I'm the right person to >>>> decide what's going to be there. Ideally, someone with more >>>> UI/text/user friendliness experience should review it (there's not >>>> programming knowledge required to change the values). >>> >>> Ok, this particular attribute brings up DIT issues which is why I >>> flagged it. >>> >>>>> I think that in general baseldap needs to be documented to explain >>>>> how things work. There is no explanation for object_class_config, >>>>> for example, that it defines the attribute in cn=ipaConfig that >>>>> contains the default list of objectclasses for the object. >>>> Yeah, there's no documentation at this point, but I'm working on it >>>> as we "speak". >>>> >>>>> rob >>>>> >>>> >>>> One more thing, I reviewed your latest patches and they make change >>>> to host and service plugins. Your patches should be pushed first, >>>> because they are more complex and also more important, so I posted >>>> updated versions to the corresponding email threads on freeipa-devel. >>>> >>>> Pavel >>> >>> Ok, I'm not too worried about that, its always a game of catch-up :-) >>> >> >> I've found another problem with the attribute map. I like your idea of >> breaking out memberof by different type but as it is now doesn't work, >> it only prints group membership. You'd have to parse the DN to >> distinguish between groups, taskgroups, etc. > > And that's exactly what I'm doing in > LDAPObject.convert_attribute_members. I mean the DN parsing. It just > doesn't work for users at the moment, because I forgot to add the other > types of groups in users attribute_members['memberof']. > > in ipalib/plugins/user.py: > > class user(LDAPObject): > # ... > attribute_members = { > # add other groups here > # example 'memberof': ['group', 'taskgroup'] > 'memberof': ['group'] > } > # ... > > try: > > ipa user-add test --first=first --last=last > ipa taskgroup-add tasktest --desc=desc > ipa taskgroup-add-member tasktest --users=test > ipa user-show test --all > > Should work. > > Note: Just noticed it won't work for netgroups, because I forgot to > override LDAPObject.get_primary_key_from_dn in the netgroup class. > Normally get_primary_key_from_dn just returns the value of RDN, but for > netgroups we have to do a search to retrieve the primary key. > > class netgroup(LDAPObject): > # ... > def get_primary_key_from_dn(self, dn): > (dn, entry_attrs) = self.backend.get_entry( > dn, [self.primary_key.name] > ) > return entry_attrs.get(self.primary_key.name, '') > # ... > >> I think for the short-term we can make a note to do this and just >> print all memberships so we can get this committed. I'm still not a >> fan of the attribute_names within each plugin though, I need more >> convincing. >> >> rob >> > > By the way, I'm going on vacation next week. So, I think we should wait > anyway before committing this. > > Pavel > I'm sending an updated version of all the patches. They should apply on the current master. I think they should now address most of your concerns and I also fixed some bugs I found on my own. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-the-config-plugin-use-baseldap-classes.patch Type: application/mbox Size: 7037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Make-the-group-plugin-use-baseldap-classes.patch Type: application/mbox Size: 8680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Make-the-hostgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 8705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Make-the-netgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 17017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Make-the-rolegroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 4285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Make-the-taskgroup-plugin-use-baseldap-classes.patch Type: application/mbox Size: 7596 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Fix-unit-tests-for-plugins-using-baseldap-classes.patch Type: application/mbox Size: 47143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Make-pwpolicy-plugin-use-baseldap-classes.patch Type: application/mbox Size: 6254 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Make-the-service-plugin-use-baseldap-classes.patch Type: application/mbox Size: 12808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Make-the-user-plugin-use-baseldap-classes.patch Type: application/mbox Size: 13867 bytes Desc: not available URL: