From pzuna at redhat.com Tue Jun 1 09:58:20 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 01 Jun 2010 11:58:20 +0200 Subject: [Freeipa-devel] [PATCH] 455 upgrade over ldapi In-Reply-To: <4BFEA623.4010807@redhat.com> References: <4BFEA623.4010807@redhat.com> Message-ID: <4C04D9BC.8030306@redhat.com> On 05/27/2010 07:04 PM, Rob Crittenden wrote: > For v2 upgrades we want the LDAP server to be quiet so we will shut it > down, disable its TCP listeners and bring it back up to update over > ldapi. This also enables autobind so we can bind as root and perform > operations as Directory Manager and not require a password. > > To use this mode run ipa-ldap-updater --upgrade. > > rob > ack. Pavel From pzuna at redhat.com Tue Jun 1 10:14:23 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 01 Jun 2010 12:14:23 +0200 Subject: [Freeipa-devel] [PATCH] 456 replica creation In-Reply-To: <4BFEE964.4040507@redhat.com> References: <4BFEE964.4040507@redhat.com> Message-ID: <4C04DD7F.80600@redhat.com> On 05/27/2010 11:51 PM, Rob Crittenden wrote: > If a host is already enrolled (either as a client or a former replica) > then ipa-replica-install will fail spectacularly with an error about a > missing keytab. This is because some entries already exist and it > totally confuses things. We need to start this host from scratch, so > catch this condition and give the admin some hints on how to fix it. > > rob > It seems to work, but this: except Exception, e: pass is a very bad practice, because it catches everything (even the KeyboardInterrupt exception) and makes code very hard to debug if something really unexpected happens. I've already replaced a few things like this in the installer, but there are probably more left. Catch errors.ExecutionError instead or in this case errors.NotFound. auto-ack when this is fixed. Pavel From pzuna at redhat.com Tue Jun 1 11:44:05 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 01 Jun 2010 13:44:05 +0200 Subject: [Freeipa-devel] [PATCH] 457 fall back to DM password in ipa-replica-manage In-Reply-To: <4BFEE9B2.9070906@redhat.com> References: <4BFEE9B2.9070906@redhat.com> Message-ID: <4C04F285.2040803@redhat.com> On 05/27/2010 11:52 PM, Rob Crittenden wrote: > ipa-replica-manage can use the current kerberos credentials for some > commands now. To make it a bit nicer to use fall back to prompt for the > DM password if there are no credentials. I've found it handy to have > this in development. > > I also fix up the errors when deleting a replica too (my test case for > the fallback). The error message was a bit mis-formatted. > > rob > ack. Pavel From pzuna at redhat.com Tue Jun 1 11:48:34 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 01 Jun 2010 13:48:34 +0200 Subject: [Freeipa-devel] [PATCH] 458 catch no CA preop.pin In-Reply-To: <4BFFDFAF.70001@redhat.com> References: <4BFFDFAF.70001@redhat.com> Message-ID: <4C04F392.9010205@redhat.com> On 05/28/2010 05:22 PM, Rob Crittenden wrote: > The preop.pin is used to authenticate the admin when doing CA > enrollment. We were assuming it would be available and things blow up > badly if not (we end up passing None as an argument to exec). If there > isn't a preop pin there is no need to do anything, so raise an error. > > rob > It looks like the patch message is missing a part, it ends with: "To remove an existing instance run:" and then nothing, but that's just a detail :) ack. Pavel From rcritten at redhat.com Tue Jun 1 13:53:26 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jun 2010 09:53:26 -0400 Subject: [Freeipa-devel] [PATCH] 455 upgrade over ldapi In-Reply-To: <4C04D9BC.8030306@redhat.com> References: <4BFEA623.4010807@redhat.com> <4C04D9BC.8030306@redhat.com> Message-ID: <4C0510D6.8060304@redhat.com> Pavel Zuna wrote: > On 05/27/2010 07:04 PM, Rob Crittenden wrote: >> For v2 upgrades we want the LDAP server to be quiet so we will shut it >> down, disable its TCP listeners and bring it back up to update over >> ldapi. This also enables autobind so we can bind as root and perform >> operations as Directory Manager and not require a password. >> >> To use this mode run ipa-ldap-updater --upgrade. >> >> rob >> > > ack. > > Pavel pushed to master From rcritten at redhat.com Tue Jun 1 13:53:47 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jun 2010 09:53:47 -0400 Subject: [Freeipa-devel] [PATCH] 456 replica creation In-Reply-To: <4C04DD7F.80600@redhat.com> References: <4BFEE964.4040507@redhat.com> <4C04DD7F.80600@redhat.com> Message-ID: <4C0510EB.9090302@redhat.com> Pavel Zuna wrote: > On 05/27/2010 11:51 PM, Rob Crittenden wrote: >> If a host is already enrolled (either as a client or a former replica) >> then ipa-replica-install will fail spectacularly with an error about a >> missing keytab. This is because some entries already exist and it >> totally confuses things. We need to start this host from scratch, so >> catch this condition and give the admin some hints on how to fix it. >> >> rob >> > It seems to work, but this: > > except Exception, e: > pass > > is a very bad practice, because it catches everything (even the > KeyboardInterrupt exception) and makes code very hard to debug if > something really unexpected happens. I've already replaced a few things > like this in the installer, but there are probably more left. Catch > errors.ExecutionError instead or in this case errors.NotFound. > > auto-ack when this is fixed. > > Pavel Ok, switched to errors.NotFound. pushed to master From rcritten at redhat.com Tue Jun 1 13:53:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jun 2010 09:53:56 -0400 Subject: [Freeipa-devel] [PATCH] 457 fall back to DM password in ipa-replica-manage In-Reply-To: <4C04F285.2040803@redhat.com> References: <4BFEE9B2.9070906@redhat.com> <4C04F285.2040803@redhat.com> Message-ID: <4C0510F4.2050206@redhat.com> Pavel Zuna wrote: > On 05/27/2010 11:52 PM, Rob Crittenden wrote: >> ipa-replica-manage can use the current kerberos credentials for some >> commands now. To make it a bit nicer to use fall back to prompt for the >> DM password if there are no credentials. I've found it handy to have >> this in development. >> >> I also fix up the errors when deleting a replica too (my test case for >> the fallback). The error message was a bit mis-formatted. >> >> rob >> > ack. > > Pavel pushed to master From rcritten at redhat.com Tue Jun 1 13:54:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jun 2010 09:54:49 -0400 Subject: [Freeipa-devel] [PATCH] 458 catch no CA preop.pin In-Reply-To: <4C04F392.9010205@redhat.com> References: <4BFFDFAF.70001@redhat.com> <4C04F392.9010205@redhat.com> Message-ID: <4C051129.8010604@redhat.com> Pavel Zuna wrote: > On 05/28/2010 05:22 PM, Rob Crittenden wrote: >> The preop.pin is used to authenticate the admin when doing CA >> enrollment. We were assuming it would be available and things blow up >> badly if not (we end up passing None as an argument to exec). If there >> isn't a preop pin there is no need to do anything, so raise an error. >> >> rob >> > It looks like the patch message is missing a part, it ends with: > "To remove an existing instance run:" and then nothing, but that's just > a detail :) > > ack. > > Pavel Heh, in this case I was demonstrating something that needed to be run as root, so I included the # shell prompt. Of course git helpfully dropped this. I added the pkiremove example back in. pushed to master From rcritten at redhat.com Tue Jun 1 18:43:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jun 2010 14:43:21 -0400 Subject: [Freeipa-devel] [PATCH] 459 remove Requires on python-krbV Message-ID: <4C0554C9.9030707@redhat.com> I used python-krbV to get the configured kerberos realm so we could clean up /etc/krb5.keytab. This is a bit heavy-weight for one line of code. We can instead parse /etc/ipa/default.conf to get the same thing without an additional Requires. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-459-client.patch Type: application/mbox Size: 2474 bytes Desc: not available URL: From sgallagh at redhat.com Tue Jun 1 19:06:22 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 01 Jun 2010 15:06:22 -0400 Subject: [Freeipa-devel] [PATCH] 459 remove Requires on python-krbV In-Reply-To: <4C0554C9.9030707@redhat.com> References: <4C0554C9.9030707@redhat.com> Message-ID: <4C055A2E.1030106@redhat.com> On 06/01/2010 02:43 PM, Rob Crittenden wrote: > I used python-krbV to get the configured kerberos realm so we could > clean up /etc/krb5.keytab. This is a bit heavy-weight for one line of > code. We can instead parse /etc/ipa/default.conf to get the same thing > without an additional Requires. > > rob Patch looks good to me. Ack. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From rcritten at redhat.com Wed Jun 2 18:34:49 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jun 2010 14:34:49 -0400 Subject: [Freeipa-devel] [PATCH] 460 an enrollment role Message-ID: <4C06A449.6070609@redhat.com> Add a new role specifically for delegating enrollment. Previously you had to delegate two tasks, this simplifies things. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-460-enroll.patch Type: application/mbox Size: 1621 bytes Desc: not available URL: From rcritten at redhat.com Wed Jun 2 18:35:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jun 2010 14:35:56 -0400 Subject: [Freeipa-devel] [PATCH] 461 ignore no_* options in Virtual class Message-ID: <4C06A48C.4000502@redhat.com> The Virtual base class is used for doing non-LDAP operations, right not just for certificate commands. It wasn't honoring the no_* option flags. Add support for that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-461-virtual.patch Type: application/mbox Size: 1005 bytes Desc: not available URL: From rcritten at redhat.com Wed Jun 2 18:36:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jun 2010 14:36:38 -0400 Subject: [Freeipa-devel] [PATCH] 462 add per-command documentation Message-ID: <4C06A4B6.4060505@redhat.com> First pass at adding per-command documentation for each plugin. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-462-docs.patch Type: application/mbox Size: 21605 bytes Desc: not available URL: From rcritten at redhat.com Wed Jun 2 18:41:40 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jun 2010 14:41:40 -0400 Subject: [Freeipa-devel] [PATCH] 459 remove Requires on python-krbV In-Reply-To: <4C055A2E.1030106@redhat.com> References: <4C0554C9.9030707@redhat.com> <4C055A2E.1030106@redhat.com> Message-ID: <4C06A5E4.5060801@redhat.com> Stephen Gallagher wrote: > On 06/01/2010 02:43 PM, Rob Crittenden wrote: >> I used python-krbV to get the configured kerberos realm so we could >> clean up /etc/krb5.keytab. This is a bit heavy-weight for one line of >> code. We can instead parse /etc/ipa/default.conf to get the same thing >> without an additional Requires. >> >> rob > > Patch looks good to me. Ack. > pushed to master From rcritten at redhat.com Wed Jun 2 18:57:13 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jun 2010 14:57:13 -0400 Subject: [Freeipa-devel] [PATCH] 463 drop --with-openldap option in client Message-ID: <4C06A989.7090707@redhat.com> Drop the --with-openldap option in the client and require the openldap client libraries. This has been required for quite some time but we always just passed in --with-openldap. This will remove the illusion that this isn't explicitly required. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-463-client.patch Type: application/mbox Size: 7251 bytes Desc: not available URL: From rcritten at redhat.com Wed Jun 2 19:01:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jun 2010 15:01:52 -0400 Subject: [Freeipa-devel] [PATCH] 451 fix i18n test In-Reply-To: <4BFE81B2.80604@redhat.com> References: <4BF6FC9A.4010307@redhat.com> <4BFE81B2.80604@redhat.com> Message-ID: <4C06AAA0.7070502@redhat.com> Pavel Zuna wrote: > On 05/21/2010 11:35 PM, Rob Crittenden wrote: >> Fix this test to work from source tree root >> >> It would work if you ran the test from its location in tests/test_ipalib >> but this isn't the most common method. If you want to run it individually >> you can do: >> >> $ ./make-test tests/test_ipalib/test_text.py >> >> rob >> > Maybe I'm doing something wrong, but I'm still getting this one error: > > ====================================================================== > ERROR: Test gettext translation > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, in > runTest > self.test(*self.arg) > File "/root/freeipa/tests/test_ipalib/test_text.py", line 89, in > test_gettext > msgid = get_msgid(test_file) > File "/root/freeipa/tests/test_ipalib/test_text.py", line 43, in > get_msgid > f = open(po_file) > IOError: [Errno 2] No such file or directory: 'install/po/test.po' > > > Pavel I finally got around to figuring this out. The problem is that your test language hasn't been built yet. Try this: $ make -C install/po test_lang $ ./make-test tests/test_ipalib/test_text.py Normally one executes this via 'make test' which will ensure that this dependency exists, I was using the 'run one test' option to demonstrate that it works. rob From pzuna at redhat.com Thu Jun 3 09:54:02 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 03 Jun 2010 11:54:02 +0200 Subject: [Freeipa-devel] [PATCH] 439 spec file cleanups In-Reply-To: <4BE84C64.4090205@redhat.com> References: <4BE84C64.4090205@redhat.com> Message-ID: <4C077BBA.5010402@redhat.com> On 2010-05-10 20:11, Rob Crittenden wrote: > Remove references to Fedora < 10 and add some tests for RHEL 6. > > rob > ack. Pavel From pzuna at redhat.com Thu Jun 3 09:58:46 2010 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Thu, 03 Jun 2010 11:58:46 +0200 Subject: [Freeipa-devel] [PATCH] 451 fix i18n test In-Reply-To: <4C06AAA0.7070502@redhat.com> References: <4BF6FC9A.4010307@redhat.com> <4BFE81B2.80604@redhat.com> <4C06AAA0.7070502@redhat.com> Message-ID: <4C077CD6.3060406@redhat.com> On 2010-06-02 21:01, Rob Crittenden wrote: > Pavel Zuna wrote: >> On 05/21/2010 11:35 PM, Rob Crittenden wrote: >>> Fix this test to work from source tree root >>> >>> It would work if you ran the test from its location in tests/test_ipalib >>> but this isn't the most common method. If you want to run it >>> individually >>> you can do: >>> >>> $ ./make-test tests/test_ipalib/test_text.py >>> >>> rob >>> >> Maybe I'm doing something wrong, but I'm still getting this one error: >> >> ====================================================================== >> ERROR: Test gettext translation >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.6/site-packages/nose/case.py", line 183, in >> runTest >> self.test(*self.arg) >> File "/root/freeipa/tests/test_ipalib/test_text.py", line 89, in >> test_gettext >> msgid = get_msgid(test_file) >> File "/root/freeipa/tests/test_ipalib/test_text.py", line 43, in >> get_msgid >> f = open(po_file) >> IOError: [Errno 2] No such file or directory: 'install/po/test.po' >> >> >> Pavel > > I finally got around to figuring this out. The problem is that your test > language hasn't been built yet. > > Try this: > > $ make -C install/po test_lang > $ ./make-test tests/test_ipalib/test_text.py > > Normally one executes this via 'make test' which will ensure that this > dependency exists, I was using the 'run one test' option to demonstrate > that it works. > > rob ack. Pavel From rcritten at redhat.com Thu Jun 3 13:39:32 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jun 2010 09:39:32 -0400 Subject: [Freeipa-devel] [PATCH] fix weeks in months Message-ID: <4C07B094.20901@redhat.com> I pushed tis out under the 1-liner rule. There can be as many as 6 weeks in a month (see May of this year as an example). rob -------------- next part -------------- An embedded message was scrubbed... From: rcritten Subject: ipalib/parameters.py Date: Thu, 3 Jun 2010 13:26:10 +0000 (UTC) Size: 3497 URL: From rcritten at redhat.com Thu Jun 3 21:08:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jun 2010 17:08:42 -0400 Subject: [Freeipa-devel] [PATCH] 396 with verbose print XML-RPC output In-Reply-To: <1271743021.7366.446.camel@wolverine.englab.brq.redhat.com> References: <4B915132.9060804@redhat.com> <4B939073.1030108@redhat.com> <4B950AF8.6050405@redhat.com> <4BCCBEEE.3070607@redhat.com> <1271743021.7366.446.camel@wolverine.englab.brq.redhat.com> Message-ID: <4C0819DA.8090106@redhat.com> Martin Nagy wrote: > On Mon, 2010-04-19 at 16:37 -0400, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Martin Nagy wrote: >>>> On 03/05/2010 07:45 PM, Rob Crittenden wrote: >>>>> Connect the -v flag in the ipa command to including the XML-RPC >>>>> conversation in the output: >>>>> >>>>> % ipa -v user-show admin >>>> [snip] >>>> >>>> Rob, do you think we could use something like -vv for this? The >>>> XML-RPC conversation seems to be a little bit too verbose. >>>> >>>> Martin >>> Hmm, maybe. verbose is currently a boolean. We could switch the option >>> to be a 'count' and return the number of v's. So 0 is still False, 1 is >>> still True and anything higher we can compare against a number. I think >>> that would work, I'll take a look. >>> >>> >> I switched the boolean -v to a counter. >> >> A single -v enables more verbose logging >> Two -v's enables printing the XML-RPC request >> >> rob > > The patch looks good, but I think you should also modify the default in > constants.py > > Martin > Good catch. Fixed and pushed. rob From ayoung at redhat.com Tue Jun 8 19:55:19 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 08 Jun 2010 15:55:19 -0400 Subject: [Freeipa-devel] Before we add these as Trac tasks Message-ID: <4C0EA027.30409@redhat.com> Here's my first, very broad stab at breaking down a reasonable chunk of work. This means nothing until Pavel has had a chance to hack at them. https://fedorahosted.org/freeipa/wiki/UITasks From rcritten at redhat.com Tue Jun 8 20:23:14 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Jun 2010 16:23:14 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups Message-ID: <4C0EA6B2.2070904@redhat.com> Add support for User-Private Groups This uses a new 389-ds plugin, Managed Entries, to automatically create a group entry when a user is created. The DNA plugin ensures that the group has a gidNumber that matches the users uidNumber. When the user is removed the group is automatically removed as well. If the managed entries plugin is not available or if a specific, separate range for gidNumber is passed in at install time then User-Private Groups will not be configured. The code checking for the Managed Entries plugin may be removed at some point. This is there because this plugin is only available in a 389-ds alpha release currently (1.2.6-a4). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-464-upg.patch Type: application/mbox Size: 12174 bytes Desc: not available URL: From ayoung at redhat.com Wed Jun 9 20:11:46 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 09 Jun 2010 16:11:46 -0400 Subject: [Freeipa-devel] Templating for the Web UI Message-ID: <4C0FF582.6040301@redhat.com> Pavel and I have come to the same conclusion: JQuery seems to have the mindshare of Javascript developers. Looks like we aren't the only ones: http://stephenwalther.com/blog/archive/2010/03/16/microsoft-jquery-and-templating.aspx Perhaps I'm being blindly optimistic about the potentail for MS to poison the pool here, but I think this actually makes sense for them. I'm not a super fan of the Templating approach, but it does have its uses, so this looks to be a potential tool in our toolkit. From jdennis at redhat.com Wed Jun 9 20:47:39 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 09 Jun 2010 16:47:39 -0400 Subject: [Freeipa-devel] Templating for the Web UI In-Reply-To: <4C0FF582.6040301@redhat.com> References: <4C0FF582.6040301@redhat.com> Message-ID: <4C0FFDEB.6000208@redhat.com> On 06/09/2010 04:11 PM, Adam Young wrote: > Pavel and I have come to the same conclusion: JQuery seems to have the > mindshare of Javascript developers. Cool > I'm not a super fan of the Templating approach, but it does have its > uses, so this looks to be a potential tool in our toolkit. Question: Are not a fan of templating, or not a fan of the proposed JQuery templating? If you're not a fan of templating can you give your reasons why and what you believe to be the better approach. Mostly just curious, I'm not a Web GUI guru, but it did seem like templating was all the rage not too long ago. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Jun 11 15:04:11 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jun 2010 11:04:11 -0400 Subject: [Freeipa-devel] [PATCH] 465 fix client bulk enrollment Message-ID: <4C12506B.8050708@redhat.com> We need to fetch the CA cert so our ldaps connection will succeed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-465-client.patch Type: application/mbox Size: 1721 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 11 15:45:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jun 2010 11:45:50 -0400 Subject: [Freeipa-devel] [PATCH] 466 drop serviceName schema Message-ID: <4C125A2E.2060203@redhat.com> Drop the serviceName attribute from the schema. We replaced this with memberService. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-466-schema.patch Type: application/mbox Size: 5178 bytes Desc: not available URL: From dpal at redhat.com Fri Jun 11 16:04:58 2010 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Jun 2010 12:04:58 -0400 Subject: [Freeipa-devel] [PATCH] 466 drop serviceName schema In-Reply-To: <4C125A2E.2060203@redhat.com> References: <4C125A2E.2060203@redhat.com> Message-ID: <4C125EAA.30502@redhat.com> Rob Crittenden wrote: > Drop the serviceName attribute from the schema. We replaced this with > memberService. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Visual ack. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Jun 11 16:16:23 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jun 2010 12:16:23 -0400 Subject: [Freeipa-devel] [PATCH] 467 fix aci-mod command Message-ID: <4C126157.4090409@redhat.com> Convert the ACI back into keywords so we can merge in any changes, then re-create the ACI. This is a much safer method of doing it. I also switched to use the declarative test mechanism and tripled the number of aci tests we perform. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-467-aci.patch Type: application/mbox Size: 14771 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 11 20:16:32 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jun 2010 16:16:32 -0400 Subject: [Freeipa-devel] [PATCH] 468 don't run through pre-bind code on enrollment Message-ID: <4C1299A0.8030108@redhat.com> Don't try to convert a host's password into a keytab. The migration plugin uses a pre-op function to automatically create kerberos credentials when binding using a password. The problem is that we do a simple bind when doing password-base host enrollment. This was causing krbPasswordExpiration to be set which isn't what we want for hosts. They really shouldn't go through this code at all. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-468-enroll.patch Type: application/mbox Size: 1885 bytes Desc: not available URL: From ssorce at redhat.com Fri Jun 11 20:35:19 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Jun 2010 16:35:19 -0400 Subject: [Freeipa-devel] [PATCH] 467 fix aci-mod command In-Reply-To: <4C126157.4090409@redhat.com> References: <4C126157.4090409@redhat.com> Message-ID: <20100611163519.1dcd93e9@willson.li.ssimo.org> On Fri, 11 Jun 2010 12:16:23 -0400 Rob Crittenden wrote: > Convert the ACI back into keywords so we can merge in any changes, > then re-create the ACI. This is a much safer method of doing it. > > I also switched to use the declarative test mechanism and tripled the > number of aci tests we perform. While the patch as is will work, I'd like to NACK and ask to check if the ipaHost objectClass is present instead. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jun 11 20:37:12 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Jun 2010 16:37:12 -0400 Subject: [Freeipa-devel] [PATCH] 468 don't run through pre-bind code on enrollment In-Reply-To: <4C1299A0.8030108@redhat.com> References: <4C1299A0.8030108@redhat.com> Message-ID: <20100611163712.1c36b88c@willson.li.ssimo.org> On Fri, 11 Jun 2010 16:16:32 -0400 Rob Crittenden wrote: > Don't try to convert a host's password into a keytab. > > The migration plugin uses a pre-op function to automatically create > kerberos credentials when binding using a password. > > The problem is that we do a simple bind when doing password-base host > enrollment. This was causing krbPasswordExpiration to be set which > isn't what we want for hosts. They really shouldn't go through this > code at all. I'd like to NACK and ask to check for the ipaHost objectClass instead of strncmp()aring the principal with "host/" Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jun 11 20:38:13 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Jun 2010 16:38:13 -0400 Subject: [Freeipa-devel] [PATCH] 467 fix aci-mod command In-Reply-To: <4C126157.4090409@redhat.com> References: <4C126157.4090409@redhat.com> Message-ID: <20100611163813.01b975cd@willson.li.ssimo.org> On Fri, 11 Jun 2010 12:16:23 -0400 Rob Crittenden wrote: > Convert the ACI back into keywords so we can merge in any changes, > then re-create the ACI. This is a much safer method of doing it. > > I also switched to use the declarative test mechanism and tripled the > number of aci tests we perform. > > rob Please ignore my previous comment on this patch, I hit reply against the wrong mail in my folder. Simo. -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Fri Jun 11 21:44:13 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 11 Jun 2010 17:44:13 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups In-Reply-To: <4C0EA6B2.2070904@redhat.com> References: <4C0EA6B2.2070904@redhat.com> Message-ID: <4C12AE2D.9030205@redhat.com> When the patch was applied, and the packages were installed on a clean system, ipa-server-install kicked directly into the debugger afterthe line: [7/21]: configuring user private groups stack trace showed dsinstance.py(124)has_managed_entries() ->try On 06/08/2010 04:23 PM, Rob Crittenden wrote: > Add support for User-Private Groups > > This uses a new 389-ds plugin, Managed Entries, to automatically > create a group entry when a user is created. The DNA plugin ensures > that the group has a gidNumber that matches the users uidNumber. When > the user is removed the group is automatically removed as well. > > If the managed entries plugin is not available or if a specific, > separate range for gidNumber is passed in at install time then > User-Private Groups will not be configured. > > The code checking for the Managed Entries plugin may be removed at > some point. This is there because this plugin is only available in a > 389-ds alpha release currently (1.2.6-a4). > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jun 14 12:44:23 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jun 2010 08:44:23 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups In-Reply-To: <4C12AE2D.9030205@redhat.com> References: <4C0EA6B2.2070904@redhat.com> <4C12AE2D.9030205@redhat.com> Message-ID: <4C162427.2060206@redhat.com> Adam Young wrote: > When the patch was applied, and the packages were installed on a clean > system, ipa-server-install kicked directly into the debugger afterthe line: > > [7/21]: configuring user private groups > > > stack trace showed > > dsinstance.py(124)has_managed_entries() > ->try Looks like I left a debug statement in the patch. You can press 'c' here to continue (it'll prompt you again later). I can remove these statements before I push the patch if it is otherwise ok. rob > > > > > On 06/08/2010 04:23 PM, Rob Crittenden wrote: >> Add support for User-Private Groups >> >> This uses a new 389-ds plugin, Managed Entries, to automatically >> create a group entry when a user is created. The DNA plugin ensures >> that the group has a gidNumber that matches the users uidNumber. When >> the user is removed the group is automatically removed as well. >> >> If the managed entries plugin is not available or if a specific, >> separate range for gidNumber is passed in at install time then >> User-Private Groups will not be configured. >> >> The code checking for the Managed Entries plugin may be removed at >> some point. This is there because this plugin is only available in a >> 389-ds alpha release currently (1.2.6-a4). >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Mon Jun 14 15:42:00 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jun 2010 11:42:00 -0400 Subject: [Freeipa-devel] [PATCH] 468 don't run through pre-bind code on enrollment In-Reply-To: <20100611163712.1c36b88c@willson.li.ssimo.org> References: <4C1299A0.8030108@redhat.com> <20100611163712.1c36b88c@willson.li.ssimo.org> Message-ID: <4C164DC8.9050802@redhat.com> Simo Sorce wrote: > On Fri, 11 Jun 2010 16:16:32 -0400 > Rob Crittenden wrote: > >> Don't try to convert a host's password into a keytab. >> >> The migration plugin uses a pre-op function to automatically create >> kerberos credentials when binding using a password. >> >> The problem is that we do a simple bind when doing password-base host >> enrollment. This was causing krbPasswordExpiration to be set which >> isn't what we want for hosts. They really shouldn't go through this >> code at all. > > I'd like to NACK and ask to check for the ipaHost objectClass instead > of strncmp()aring the principal with "host/" > > Simo. > Updated patch attached. I took the opportunity to fix another instance of comparing to host/ in the principal name as well. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-468-2-enroll.patch Type: application/mbox Size: 3366 bytes Desc: not available URL: From jdennis at redhat.com Mon Jun 14 18:35:23 2010 From: jdennis at redhat.com (John Dennis) Date: Mon, 14 Jun 2010 14:35:23 -0400 Subject: [Freeipa-devel] [PATCH 16/16] use NSS for SSL operations Message-ID: <4C16766B.3010102@redhat.com> This patch removes the use of OpenSSL (via Python's native libraries) for SSL operations and substitutes NSS for SSL. We were already using NSS in some places, now it's consistently universal. Be aware that this patch depends on a an upgrade of python-nss to 0.9. The patch also fixes a problem with certification validation, previously we had not been fully validating a certificate and as such it was a security vulnerability. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-use-NSS-for-SSL-operations.patch Type: text/x-patch Size: 28109 bytes Desc: not available URL: From davido at redhat.com Tue Jun 15 01:08:24 2010 From: davido at redhat.com (David O'Brien) Date: Tue, 15 Jun 2010 11:08:24 +1000 Subject: [Freeipa-devel] [PATCH] 462 add per-command documentation In-Reply-To: <4C06A4B6.4060505@redhat.com> References: <4C06A4B6.4060505@redhat.com> Message-ID: <4C16D288.20604@redhat.com> Rob Crittenden wrote: > First pass at adding per-command documentation for each plugin. > > rob Rob, How would you like edits to this? I _could_ edit the patch, or I could wait until you commit what you have and then run ipa help and send edited files for each topic. This was posted almost two weeks ago; what's the status? cheers -- David O'Brien Senior Technical Writer, Engineering Content Services Red Hat Asia Pacific Pty Ltd 193 North Quay, Brisbane "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. From rcritten at redhat.com Tue Jun 15 13:09:00 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Jun 2010 09:09:00 -0400 Subject: [Freeipa-devel] [PATCH] 462 add per-command documentation In-Reply-To: <4C16D288.20604@redhat.com> References: <4C06A4B6.4060505@redhat.com> <4C16D288.20604@redhat.com> Message-ID: <4C177B6C.7030909@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: >> First pass at adding per-command documentation for each plugin. >> >> rob > Rob, > How would you like edits to this? > > I _could_ edit the patch, or I could wait until you commit what you have > and then run ipa help and send edited files for each topic. This > was posted almost two weeks ago; what's the status? > > cheers > I'd prefer it if the patch got committed so you could review the final text assuming my stuff isn't too far off. Some plugins already have some text and those need to be reviewed as well. I'll see abuot getting this reviewed. rob From rcritten at redhat.com Tue Jun 15 19:21:44 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Jun 2010 15:21:44 -0400 Subject: [Freeipa-devel] [PATCH 16/16] use NSS for SSL operations In-Reply-To: <4C16766B.3010102@redhat.com> References: <4C16766B.3010102@redhat.com> Message-ID: <4C17D2C8.5070703@redhat.com> John Dennis wrote: > This patch removes the use of OpenSSL (via Python's native libraries) > for SSL operations and substitutes NSS for SSL. We were already using > NSS in some places, now it's consistently universal. > > Be aware that this patch depends on a an upgrade of python-nss to 0.9. > > The patch also fixes a problem with certification validation, previously > we had not been fully validating a certificate and as such it was a > security vulnerability. ack, pushed to master. Note that the new python-nss is only in our own repo right now (http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo) rob From dpal at redhat.com Tue Jun 15 19:31:07 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Jun 2010 15:31:07 -0400 Subject: [Freeipa-devel] Process improvements in the IPA project Message-ID: <4C17D4FB.8090304@redhat.com> Hello, We had some delay with the implementation of the UI for v2. Now when the problems are cleared we are marching forward towards the end of the project cycle. As we dive more and more into the details of the implementation related to the UI we get more and more questions. Since the UI is the most user facing component of the project we want to have a broader discussion and hear your opinion. Sorry that we have not been that open in the past. We should have been but that slipped through the cracks a bit. Also recently we started to track our remaining work using trac instance connected to the project. If you are interested in where we are and what we are doing or have an issue you would like to report please use trac instance at: https://fedorahosted.org/freeipa -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Jun 15 19:59:34 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Jun 2010 15:59:34 -0400 Subject: [Freeipa-devel] Process improvements in the IPA project In-Reply-To: <4C17D4FB.8090304@redhat.com> References: <4C17D4FB.8090304@redhat.com> Message-ID: <4C17DBA6.1080000@redhat.com> Dmitri Pal wrote: > Hello, > > We had some delay with the implementation of the UI for v2. Now when the > problems are cleared we are marching forward towards the end of the > project cycle. > As we dive more and more into the details of the implementation related > to the UI we get more and more questions. Since the UI is the most user > facing component of the project we want to have a broader discussion and > hear your opinion. Sorry that we have not been that open in the past. We > should have been but that slipped through the cracks a bit. > > Also recently we started to track our remaining work using trac instance > connected to the project. > If you are interested in where we are and what we are doing or have an > issue you would like to report please use trac instance at: > https://fedorahosted.org/freeipa > > > The new UI screens and site roadmap are published here: http://www.freeipa.org/page/Second_Round_Of_UI_design -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Jun 15 20:28:23 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 15 Jun 2010 16:28:23 -0400 Subject: [Freeipa-devel] Question about administrative granularity Message-ID: <4C17E267.8050408@redhat.com> Hello, Please join the discussion around the following ticket: https://fedorahosted.org/freeipa/ticket/47 Instead of adding a comment there I would comment here: Approach 1: Identify privileged and non privileged uses by dynamically looking at their ACIs, show the UI that is applicable to the user based on this dynamic evaluation Pros: Most dynamic approach Cons: can get too complex and performance costly Approach 2: Create fixed views of the items in the system (that can in future be adjusted) Unprivileged view - brings user right to sef service screen. In future it can be extended to other screens like: what hosts I am allowed to access; search for user contact information etc. Low level privileged user - this user probably can mange some identities (users, user groups, hosts, host groups, and netgroups) but he will not see other menu choices so he will be brought to choose an item under the "identities" panel right away. Top level choices will not be available to him. Medium level privileged user - will see identities and policies High level user - sees everything. Now we can say this actually each of the 4 described UI views can be represented by a configuration entry in the back end that would describe which menu items are available in each of the four views. We can come up with the schema - it is not a problem. If we go this route we will have 4 configurable layouts that can be adjusted by admins based on the specific deployment use cases. The actual fields that will be shown to the users depend on his ACI. This is a separate discussion. If we go this route we will need some smarts around the cases when the top level menu has just one item or there is just one item left in the sub menu panel but I think we can work it out. Next step is to say that we in future would allow creation of the new configurations so that we are not limited to just 4 predefined. May be we should allow it right away? It is a separate topic that can be deferred. Next we need to associate the user with the view. There are traditionally two ways of doing it: * Via groups * Via attributes In the case of groups we would effectively have to create a corresponding group for each of the configuration entries we have. The view config entry will have a reference to the DN of the corresponding group. Placing the user into the group will relate him to the corresponding view. The logic of the resolution which view to use will be the following: * Get current user based on his kerberos ticket * Get the list of views in the ascending priority order * For each view get a referenced group entry * Check if user is a member of the group * The first group he is found in will identify the view to use * If user is not found in any group assume lowest level view The group entry can be created automatically using managed entry plugin when the view config entry is created. If we decide to use the attributes we have to add an attribute to each user entry (or to some and assume absence as unprivileged) . We would have to invent the method of doing bulk assignments in UI and CLI. This approach seems less straightforward than using groups. So I would vote for the config entry + managed group approach described above. If there are no objections I will come up with the schema for those. Comments welcome! -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Wed Jun 16 21:02:13 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Jun 2010 17:02:13 -0400 Subject: [Freeipa-devel] Fields currently available for the user object Message-ID: <4C193BD5.4060201@redhat.com> I was comparing what we have in the LDAP schema versus what we are coming up with for the UI. These are the fields that the user object returns if you request -all: We should either keep the UI to only showing a subset of these fields, or expand the default schema to have the fields that we want to show in the UI. user login First name Last name Home directory GECOS field Login shell Kerberos principal Email address Password UID Street address Groups Netgroups Rolegroups Taskgroups From rcritten at redhat.com Wed Jun 16 21:09:48 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Jun 2010 17:09:48 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C193BD5.4060201@redhat.com> References: <4C193BD5.4060201@redhat.com> Message-ID: <4C193D9C.7000005@redhat.com> Adam Young wrote: > I was comparing what we have in the LDAP schema versus what we are > coming up with for the UI. These are the fields that the user object > returns if you request -all: > > We should either keep the UI to only showing a subset of these fields, > or expand the default schema to have the fields that we want to show in > the UI. > > user login > First name > Last name > Home directory > GECOS field > Login shell > Kerberos principal > Email address > Password > UID > Street address > Groups > Netgroups > Rolegroups > Taskgroups We'll need to add Params() for any additional fields we want to capture (mobile number, fax, etc). The attributes in the UI designs are all available in the LDAP schema, we just haven't necessarily created Params for them yet. rob From ayoung at redhat.com Wed Jun 16 23:03:44 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Jun 2010 19:03:44 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C193D9C.7000005@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> Message-ID: <4C195850.8090704@redhat.com> On 06/16/2010 05:09 PM, Rob Crittenden wrote: > Adam Young wrote: >> I was comparing what we have in the LDAP schema versus what we are >> coming up with for the UI. These are the fields that the user object >> returns if you request -all: >> >> We should either keep the UI to only showing a subset of these >> fields, or expand the default schema to have the fields that we want >> to show in the UI. >> >> user login >> First name >> Last name >> Home directory >> GECOS field >> Login shell >> Kerberos principal >> Email address >> Password >> UID >> Street address >> Groups >> Netgroups >> Rolegroups >> Taskgroups > > We'll need to add Params() for any additional fields we want to > capture (mobile number, fax, etc). The attributes in the UI designs > are all available in the LDAP schema, we just haven't necessarily > created Params for them yet. > > rob I'm guessing that means additional objects defined in freeipa/ipalib/parameters.py? From ayoung at redhat.com Wed Jun 16 23:13:05 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Jun 2010 19:13:05 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C195850.8090704@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> Message-ID: <4C195A81.9000201@redhat.com> On 06/16/2010 07:03 PM, Adam Young wrote: > On 06/16/2010 05:09 PM, Rob Crittenden wrote: >> Adam Young wrote: >>> I was comparing what we have in the LDAP schema versus what we are >>> coming up with for the UI. These are the fields that the user >>> object returns if you request -all: >>> >>> We should either keep the UI to only showing a subset of these >>> fields, or expand the default schema to have the fields that we want >>> to show in the UI. >>> >>> user login >>> First name >>> Last name >>> Home directory >>> GECOS field >>> Login shell >>> Kerberos principal >>> Email address >>> Password >>> UID >>> Street address >>> Groups >>> Netgroups >>> Rolegroups >>> Taskgroups >> >> We'll need to add Params() for any additional fields we want to >> capture (mobile number, fax, etc). The attributes in the UI designs >> are all available in the LDAP schema, we just haven't necessarily >> created Params for them yet. >> >> rob > > > I'm guessing that means additional objects defined in > freeipa/ipalib/parameters.py? Ah, a little more research and I see that I have to extend plugins/user.py > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From ayoung at redhat.com Thu Jun 17 01:23:26 2010 From: ayoung at redhat.com (Adam Young) Date: Wed, 16 Jun 2010 21:23:26 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C195A81.9000201@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> Message-ID: <4C19790E.8010500@redhat.com> On 06/16/2010 07:13 PM, Adam Young wrote: > On 06/16/2010 07:03 PM, Adam Young wrote: >> On 06/16/2010 05:09 PM, Rob Crittenden wrote: >>> Adam Young wrote: >>>> I was comparing what we have in the LDAP schema versus what we are >>>> coming up with for the UI. These are the fields that the user >>>> object returns if you request -all: >>>> >>>> We should either keep the UI to only showing a subset of these >>>> fields, or expand the default schema to have the fields that we >>>> want to show in the UI. >>>> >>>> user login >>>> First name >>>> Last name >>>> Home directory >>>> GECOS field >>>> Login shell >>>> Kerberos principal >>>> Email address >>>> Password >>>> UID >>>> Street address >>>> Groups >>>> Netgroups >>>> Rolegroups >>>> Taskgroups >>> >>> We'll need to add Params() for any additional fields we want to >>> capture (mobile number, fax, etc). The attributes in the UI designs >>> are all available in the LDAP schema, we just haven't necessarily >>> created Params for them yet. >>> >>> rob >> >> >> I'm guessing that means additional objects defined in >> freeipa/ipalib/parameters.py? > > Ah, a little more research and I see that I have to extend > plugins/user.py Is there any documentation on how to write plugins, or extend existing plugins? > >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Thu Jun 17 02:49:39 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Jun 2010 22:49:39 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C19790E.8010500@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> <4C19790E.8010500@redhat.com> Message-ID: <4C198D43.3080204@redhat.com> Adam Young wrote: > On 06/16/2010 07:13 PM, Adam Young wrote: >> On 06/16/2010 07:03 PM, Adam Young wrote: >>> On 06/16/2010 05:09 PM, Rob Crittenden wrote: >>>> Adam Young wrote: >>>>> I was comparing what we have in the LDAP schema versus what we are >>>>> coming up with for the UI. These are the fields that the user >>>>> object returns if you request -all: >>>>> >>>>> We should either keep the UI to only showing a subset of these >>>>> fields, or expand the default schema to have the fields that we >>>>> want to show in the UI. >>>>> >>>>> user login >>>>> First name >>>>> Last name >>>>> Home directory >>>>> GECOS field >>>>> Login shell >>>>> Kerberos principal >>>>> Email address >>>>> Password >>>>> UID >>>>> Street address >>>>> Groups >>>>> Netgroups >>>>> Rolegroups >>>>> Taskgroups >>>> >>>> We'll need to add Params() for any additional fields we want to >>>> capture (mobile number, fax, etc). The attributes in the UI designs >>>> are all available in the LDAP schema, we just haven't necessarily >>>> created Params for them yet. >>>> >>>> rob >>> >>> >>> I'm guessing that means additional objects defined in >>> freeipa/ipalib/parameters.py? >> >> Ah, a little more research and I see that I have to extend >> plugins/user.py > > > Is there any documentation on how to write plugins, or extend existing > plugins? > Pavel annotated a sample plugin: https://fedorahosted.org/freeipa/browser/doc/examples/examples.py rob From jdennis at redhat.com Thu Jun 17 10:32:57 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 17 Jun 2010 06:32:57 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C198D43.3080204@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> <4C19790E.8010500@redhat.com> <4C198D43.3080204@redhat.com> Message-ID: <4C19F9D9.2090306@redhat.com> On 06/16/2010 10:49 PM, Rob Crittenden wrote: > Adam Young wrote: >> Is there any documentation on how to write plugins, or extend existing >> plugins? > > Pavel annotated a sample plugin: > > https://fedorahosted.org/freeipa/browser/doc/examples/examples.py ipalib/__init__.py has a fair amount of documentation in it including a section called: Tutorial for Plugin Authors One of the things Jason was very good at doing was including documentation. It's always inline in the source code which is common Python practice and is in rst (reStructuredText) format. This is so epydoc (and other tools) can extract it and format it. Thus you might find it easier to read the generated doc rather than the inline, however rst is designed to be readable on it's own, plus you get to see the actual source next to it. But on the other hand the generated doc does have hyperlinks which can be a real help. HTH, John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Thu Jun 17 10:58:47 2010 From: jdennis at redhat.com (John Dennis) Date: Thu, 17 Jun 2010 06:58:47 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C19F9D9.2090306@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> <4C19790E.8010500@redhat.com> <4C198D43.3080204@redhat.com> <4C19F9D9.2090306@redhat.com> Message-ID: <4C19FFE7.2040504@redhat.com> On 06/17/2010 06:32 AM, John Dennis wrote: > One of the things Jason was very good at doing was including > documentation. It's always inline in the source code which is common > Python practice and is in rst (reStructuredText) format. This is so > epydoc (and other tools) can extract it and format it. Oh, I should have pointed out since you're new to the project that the project team has selected rst as it's documentation format (at least for code documentation). When you add code documentation it should be in rst format. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Jun 17 12:10:50 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 17 Jun 2010 08:10:50 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C19FFE7.2040504@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> <4C19790E.8010500@redhat.com> <4C198D43.3080204@redhat.com> <4C19F9D9.2090306@redhat.com> <4C19FFE7.2040504@redhat.com> Message-ID: <20100617081050.014879fb@willson.li.ssimo.org> On Thu, 17 Jun 2010 06:58:47 -0400 John Dennis wrote: > On 06/17/2010 06:32 AM, John Dennis wrote: > > > One of the things Jason was very good at doing was including > > documentation. It's always inline in the source code which is common > > Python practice and is in rst (reStructuredText) format. This is so > > epydoc (and other tools) can extract it and format it. > > Oh, I should have pointed out since you're new to the project that > the project team has selected rst as it's documentation format (at > least for code documentation). When you add code documentation it > should be in rst format. > More info on style and tools also available here: http://freeipa.org/page/Contribute#Development_Process Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jun 17 20:37:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Jun 2010 16:37:52 -0400 Subject: [Freeipa-devel] [PATCH] 470 maintainer-clean change Message-ID: <4C1A87A0.5020403@redhat.com> I almost pushed this under the one-liner rule but what the heck. Add a maintainer-clean target to install/po. All the heavy lifting is already done in distclean so just depend on that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-470-clean.patch Type: application/mbox Size: 776 bytes Desc: not available URL: From ayoung at redhat.com Thu Jun 17 23:39:23 2010 From: ayoung at redhat.com (Adam Young) Date: Thu, 17 Jun 2010 19:39:23 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups In-Reply-To: <4C162427.2060206@redhat.com> References: <4C0EA6B2.2070904@redhat.com> <4C12AE2D.9030205@redhat.com> <4C162427.2060206@redhat.com> Message-ID: <4C1AB22B.7070905@redhat.com> On 06/14/2010 08:44 AM, Rob Crittenden wrote: > Adam Young wrote: >> When the patch was applied, and the packages were installed on a >> clean system, ipa-server-install kicked directly into the debugger >> afterthe line: >> >> [7/21]: configuring user private groups >> >> >> stack trace showed >> >> dsinstance.py(124)has_managed_entries() >> ->try > > Looks like I left a debug statement in the patch. You can press 'c' > here to continue (it'll prompt you again later). I can remove these > statements before I push the patch if it is otherwise ok. > > rob OK, I think this is a legit problem: I have a version of the the DS that has /usr/lib64/dirsrv/plugins/libmanagedentries-plugin.so [root at ipa patchedrpms]# rpmquery 389-ds-base 389-ds-base-1.2.6-0.6.rc1.fc13.x86_64 The following fails. I think the error message is either failing at I18N or has a typo in the URL, due to the u' in it. [root at ipa patchedrpms]# ipa user-add --first Count --last VonCount User login [cvoncount]: count123ahahah ipa: ERROR: cannot connect to u'https://ipa.ayoung.boston.devel.redhat.com/ipa/xml': Internal Server Error > >> >> >> >> >> On 06/08/2010 04:23 PM, Rob Crittenden wrote: >>> Add support for User-Private Groups >>> >>> This uses a new 389-ds plugin, Managed Entries, to automatically >>> create a group entry when a user is created. The DNA plugin ensures >>> that the group has a gidNumber that matches the users uidNumber. >>> When the user is removed the group is automatically removed as well. >>> >>> If the managed entries plugin is not available or if a specific, >>> separate range for gidNumber is passed in at install time then >>> User-Private Groups will not be configured. >>> >>> The code checking for the Managed Entries plugin may be removed at >>> some point. This is there because this plugin is only available in a >>> 389-ds alpha release currently (1.2.6-a4). >>> >>> rob >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > From rcritten at redhat.com Fri Jun 18 12:38:53 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jun 2010 08:38:53 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups In-Reply-To: <4C1AB22B.7070905@redhat.com> References: <4C0EA6B2.2070904@redhat.com> <4C12AE2D.9030205@redhat.com> <4C162427.2060206@redhat.com> <4C1AB22B.7070905@redhat.com> Message-ID: <4C1B68DD.9030100@redhat.com> Adam Young wrote: > On 06/14/2010 08:44 AM, Rob Crittenden wrote: >> Adam Young wrote: >>> When the patch was applied, and the packages were installed on a >>> clean system, ipa-server-install kicked directly into the debugger >>> afterthe line: >>> >>> [7/21]: configuring user private groups >>> >>> >>> stack trace showed >>> >>> dsinstance.py(124)has_managed_entries() >>> ->try >> >> Looks like I left a debug statement in the patch. You can press 'c' >> here to continue (it'll prompt you again later). I can remove these >> statements before I push the patch if it is otherwise ok. >> >> rob > > OK, I think this is a legit problem: I have a version of the the DS > that has /usr/lib64/dirsrv/plugins/libmanagedentries-plugin.so > > [root at ipa patchedrpms]# rpmquery 389-ds-base > 389-ds-base-1.2.6-0.6.rc1.fc13.x86_64 > > The following fails. I think the error message is either failing at > I18N or has a typo in the URL, due to the u' in it. > > [root at ipa patchedrpms]# ipa user-add --first Count --last VonCount > User login [cvoncount]: count123ahahah > ipa: ERROR: cannot connect to > u'https://ipa.ayoung.boston.devel.redhat.com/ipa/xml': Internal Server > Error > There should be a backtrace in /var/log/httpd/error_log. Can you provide that? thanks rob From ayoung at redhat.com Fri Jun 18 20:30:55 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 18 Jun 2010 16:30:55 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ Message-ID: <4C1BD77F.6070601@redhat.com> Pavel's current code base tries to write to /var/cache/ipa/assets/ from within httpd, which is forbidden by SELinux. I suspect the code in the mainline might be doing this as well. The work around is: chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets semanage fcontext -a -t httpd_sys_content_rw_t 'assets' If we are going to do this kind of code generation, we might want to do it at install time, or as part of something like /etc/init.d/ipa-server start From rcritten at redhat.com Fri Jun 18 20:51:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jun 2010 16:51:52 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <4C1BD77F.6070601@redhat.com> References: <4C1BD77F.6070601@redhat.com> Message-ID: <4C1BDC68.8030608@redhat.com> Adam Young wrote: > Pavel's current code base tries to write to /var/cache/ipa/assets/ from > within httpd, which is forbidden by SELinux. I suspect the code in the > mainline might be doing this as well. The work around is: > > chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets > semanage fcontext -a -t httpd_sys_content_rw_t 'assets' > > If we are going to do this kind of code generation, we might want to do > it at install time, or as part of something like > /etc/init.d/ipa-server start > I'd think this rule would cover it in ipa_httpd.fc: /var/cache/ipa/assets(/.*)? gen_context(system_u:object_r:httpd_sys_content_t,s0) rob From ayoung at redhat.com Fri Jun 18 21:28:19 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 18 Jun 2010 17:28:19 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <4C1BDC68.8030608@redhat.com> References: <4C1BD77F.6070601@redhat.com> <4C1BDC68.8030608@redhat.com> Message-ID: <4C1BE4F3.9030605@redhat.com> On 06/18/2010 04:51 PM, Rob Crittenden wrote: > Adam Young wrote: >> Pavel's current code base tries to write to /var/cache/ipa/assets/ >> from within httpd, which is forbidden by SELinux. I suspect the code >> in the mainline might be doing this as well. The work around is: >> >> chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets >> semanage fcontext -a -t httpd_sys_content_rw_t 'assets' >> >> If we are going to do this kind of code generation, we might want to >> do it at install time, or as part of something like >> /etc/init.d/ipa-server start >> > > I'd think this rule would cover it in ipa_httpd.fc: > > /var/cache/ipa/assets(/.*)? > gen_context(system_u:object_r:httpd_sys_content_t,s0) > > rob Before I open a bug I want to review with Pavel. I wasn't seeing this before I merged in his changes, and it wasn't for code in the main git repo, so no bug yet. From ssorce at redhat.com Fri Jun 18 21:53:02 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Jun 2010 17:53:02 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <4C1BE4F3.9030605@redhat.com> References: <4C1BD77F.6070601@redhat.com> <4C1BDC68.8030608@redhat.com> <4C1BE4F3.9030605@redhat.com> Message-ID: <20100618175302.5e301331@willson.li.ssimo.org> On Fri, 18 Jun 2010 17:28:19 -0400 Adam Young wrote: > On 06/18/2010 04:51 PM, Rob Crittenden wrote: > > Adam Young wrote: > >> Pavel's current code base tries to write > >> to /var/cache/ipa/assets/ from within httpd, which is forbidden > >> by SELinux. I suspect the code in the mainline might be doing > >> this as well. The work around is: > >> > >> chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets > >> semanage fcontext -a -t httpd_sys_content_rw_t 'assets' > >> > >> If we are going to do this kind of code generation, we might want > >> to do it at install time, or as part of something like > >> /etc/init.d/ipa-server start > >> > > > > I'd think this rule would cover it in ipa_httpd.fc: > > > > /var/cache/ipa/assets(/.*)? > > gen_context(system_u:object_r:httpd_sys_content_t,s0) > > > > rob > Before I open a bug I want to review with Pavel. I wasn't seeing > this before I merged in his changes, and it wasn't for code in the > main git repo, so no bug yet. As a general rule I don't like that apache gets to write to the file system, esp if that means changing code that different users use at the same time. It's a too big risk. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Fri Jun 18 22:02:18 2010 From: jdennis at redhat.com (John Dennis) Date: Fri, 18 Jun 2010 18:02:18 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <20100618175302.5e301331@willson.li.ssimo.org> References: <4C1BD77F.6070601@redhat.com> <4C1BDC68.8030608@redhat.com> <4C1BE4F3.9030605@redhat.com> <20100618175302.5e301331@willson.li.ssimo.org> Message-ID: <4C1BECEA.40405@redhat.com> On 06/18/2010 05:53 PM, Simo Sorce wrote: > As a general rule I don't like that apache gets to write to the file > system +1 -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Fri Jun 18 22:22:37 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 18 Jun 2010 18:22:37 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <20100618175302.5e301331@willson.li.ssimo.org> References: <4C1BD77F.6070601@redhat.com> <4C1BDC68.8030608@redhat.com> <4C1BE4F3.9030605@redhat.com> <20100618175302.5e301331@willson.li.ssimo.org> Message-ID: <4C1BF1AD.3030108@redhat.com> On 06/18/2010 05:53 PM, Simo Sorce wrote: > On Fri, 18 Jun 2010 17:28:19 -0400 > Adam Young wrote: > > >> On 06/18/2010 04:51 PM, Rob Crittenden wrote: >> >>> Adam Young wrote: >>> >>>> Pavel's current code base tries to write >>>> to /var/cache/ipa/assets/ from within httpd, which is forbidden >>>> by SELinux. I suspect the code in the mainline might be doing >>>> this as well. The work around is: >>>> >>>> chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets >>>> semanage fcontext -a -t httpd_sys_content_rw_t 'assets' >>>> >>>> If we are going to do this kind of code generation, we might want >>>> to do it at install time, or as part of something like >>>> /etc/init.d/ipa-server start >>>> >>>> >>> I'd think this rule would cover it in ipa_httpd.fc: >>> >>> /var/cache/ipa/assets(/.*)? >>> gen_context(system_u:object_r:httpd_sys_content_t,s0) >>> >>> rob >>> >> Before I open a bug I want to review with Pavel. I wasn't seeing >> this before I merged in his changes, and it wasn't for code in the >> main git repo, so no bug yet. >> > As a general rule I don't like that apache gets to write to the file > system, esp if that means changing code that different users use at > the same time. It's a too big risk. > > Simo. > > Simo, I agree. I'm thinking that anything doing one time code generation should be done outside the apache process. I'm not sure we are even going to take this approach long term. The code doing the generatrion is, I think left over from Jason's last effort. This is a possibility that we will want to script code based on the meta data of the plugins. We have three points we could do this: at plugin deploiy time, inside the server at http fetch , or in the broswer (via javascript). I suspect that the code that is currently writing to /var.... should be done at plugin deploy time instead, or should be done completely dynamically. From mnagy at redhat.com Mon Jun 21 12:44:03 2010 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 21 Jun 2010 14:44:03 +0200 Subject: [Freeipa-devel] [PATCH] 463 drop --with-openldap option in client In-Reply-To: <4C06A989.7090707@redhat.com> References: <4C06A989.7090707@redhat.com> Message-ID: <1277124243.2809.0.camel@wolverine.englab.brq.redhat.com> On Wed, 2010-06-02 at 14:57 -0400, Rob Crittenden wrote: > Drop the --with-openldap option in the client and require the openldap > client libraries. This has been required for quite some time but we > always just passed in --with-openldap. This will remove the illusion > that this isn't explicitly required. > > rob Ack. Martin From mnagy at redhat.com Mon Jun 21 12:47:17 2010 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 21 Jun 2010 14:47:17 +0200 Subject: [Freeipa-devel] [PATCH] 465 fix client bulk enrollment In-Reply-To: <4C12506B.8050708@redhat.com> References: <4C12506B.8050708@redhat.com> Message-ID: <1277124437.2809.1.camel@wolverine.englab.brq.redhat.com> On Fri, 2010-06-11 at 11:04 -0400, Rob Crittenden wrote: > We need to fetch the CA cert so our ldaps connection will succeed. > > rob Ack. Martin From rcritten at redhat.com Mon Jun 21 13:52:30 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Jun 2010 09:52:30 -0400 Subject: [Freeipa-devel] [PATCH] 463 drop --with-openldap option in client In-Reply-To: <1277124243.2809.0.camel@wolverine.englab.brq.redhat.com> References: <4C06A989.7090707@redhat.com> <1277124243.2809.0.camel@wolverine.englab.brq.redhat.com> Message-ID: <4C1F6E9E.1070500@redhat.com> Martin Nagy wrote: > On Wed, 2010-06-02 at 14:57 -0400, Rob Crittenden wrote: >> Drop the --with-openldap option in the client and require the openldap >> client libraries. This has been required for quite some time but we >> always just passed in --with-openldap. This will remove the illusion >> that this isn't explicitly required. >> >> rob > > Ack. > > Martin > pushed to master From rcritten at redhat.com Mon Jun 21 13:52:38 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Jun 2010 09:52:38 -0400 Subject: [Freeipa-devel] [PATCH] 465 fix client bulk enrollment In-Reply-To: <1277124437.2809.1.camel@wolverine.englab.brq.redhat.com> References: <4C12506B.8050708@redhat.com> <1277124437.2809.1.camel@wolverine.englab.brq.redhat.com> Message-ID: <4C1F6EA6.7050903@redhat.com> Martin Nagy wrote: > On Fri, 2010-06-11 at 11:04 -0400, Rob Crittenden wrote: >> We need to fetch the CA cert so our ldaps connection will succeed. >> >> rob > > Ack. > > Martin > pushed to master From rcritten at redhat.com Mon Jun 21 13:53:15 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Jun 2010 09:53:15 -0400 Subject: [Freeipa-devel] [PATCH] 466 drop serviceName schema In-Reply-To: <4C125EAA.30502@redhat.com> References: <4C125A2E.2060203@redhat.com> <4C125EAA.30502@redhat.com> Message-ID: <4C1F6ECB.8060402@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> Drop the serviceName attribute from the schema. We replaced this with >> memberService. >> >> rob >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Visual ack. > pushed to master From mnagy at redhat.com Mon Jun 21 16:40:59 2010 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 21 Jun 2010 18:40:59 +0200 Subject: [Freeipa-devel] [PATCH] 470 maintainer-clean change In-Reply-To: <4C1A87A0.5020403@redhat.com> References: <4C1A87A0.5020403@redhat.com> Message-ID: <4C1F961B.40306@redhat.com> On 06/17/2010 10:37 PM, Rob Crittenden wrote: > I almost pushed this under the one-liner rule but what the heck. Add a > maintainer-clean target to install/po. All the heavy lifting is already > done in distclean so just depend on that. > > rob Ack. Martin From pzuna at redhat.com Tue Jun 22 09:38:09 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 22 Jun 2010 11:38:09 +0200 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C19790E.8010500@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> <4C19790E.8010500@redhat.com> Message-ID: <4C208481.1090703@redhat.com> On 06/17/2010 03:23 AM, Adam Young wrote: > Is there any documentation on how to write plugins, or extend existing > plugins? > As Rob pointed out, there are example plugins in ipalib/plugins/example.py. They should give you a good overview of the plugin framework, parameters, etc. Unfortunately, the file doesn't cover baseldap.py classes used by 95% of the plugins. baseldap.py classes are described in the internal wiki, search for the article named "HOWTO Write IPA command plugins". Pavel From pzuna at redhat.com Tue Jun 22 09:45:55 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 22 Jun 2010 11:45:55 +0200 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <4C1BF1AD.3030108@redhat.com> References: <4C1BD77F.6070601@redhat.com> <4C1BDC68.8030608@redhat.com> <4C1BE4F3.9030605@redhat.com> <20100618175302.5e301331@willson.li.ssimo.org> <4C1BF1AD.3030108@redhat.com> Message-ID: <4C208653.8080906@redhat.com> On 06/19/2010 12:22 AM, Adam Young wrote: > On 06/18/2010 05:53 PM, Simo Sorce wrote: >> On Fri, 18 Jun 2010 17:28:19 -0400 >> Adam Young wrote: >> >>> On 06/18/2010 04:51 PM, Rob Crittenden wrote: >>>> Adam Young wrote: >>>>> Pavel's current code base tries to write >>>>> to /var/cache/ipa/assets/ from within httpd, which is forbidden >>>>> by SELinux. I suspect the code in the mainline might be doing >>>>> this as well. The work around is: >>>>> >>>>> chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets >>>>> semanage fcontext -a -t httpd_sys_content_rw_t 'assets' >>>>> >>>>> If we are going to do this kind of code generation, we might want >>>>> to do it at install time, or as part of something like >>>>> /etc/init.d/ipa-server start >>>>> >>>> I'd think this rule would cover it in ipa_httpd.fc: >>>> >>>> /var/cache/ipa/assets(/.*)? >>>> gen_context(system_u:object_r:httpd_sys_content_t,s0) >>>> >>>> rob >>> Before I open a bug I want to review with Pavel. I wasn't seeing >>> this before I merged in his changes, and it wasn't for code in the >>> main git repo, so no bug yet. >> As a general rule I don't like that apache gets to write to the file >> system, esp if that means changing code that different users use at >> the same time. It's a too big risk. >> >> Simo. >> > > > Simo, I agree. I'm thinking that anything doing one time code generation > should be done outside the apache process. I'm not sure we are even > going to take this approach long term. The code doing the generatrion > is, I think left over from Jason's last effort. > > This is a possibility that we will want to script code based on the meta > data of the plugins. We have three points we could do this: at plugin > deploiy time, inside the server at http fetch , or in the broswer (via > javascript). I suspect that the code that is currently writing to > /var.... should be done at plugin deploy time instead, or should be done > completely dynamically. > This has nothing to do with code generation. /var/cache/ipa/assets is the IPA location managed by Jason's assetslib (python-assets). It's used to store static data like images, css, etc. linked by the webUI. All normal files are copied there at installation time and only symbolic links are created "on the fly" when something changes. The goal is to achieve maximum caching. You can read more about the concept here: http://jderose.fedorapeople.org/assets/current/apidoc/assetslib-module.html We're going to drop this code. Jason wrote it a long time ago, it has some issues and I don't want to maintain it anymore (it's misunderstood and causes more trouble than it saves). Pavel From pzuna at redhat.com Tue Jun 22 13:17:15 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 22 Jun 2010 15:17:15 +0200 Subject: [Freeipa-devel] [PATCH] 460 an enrollment role In-Reply-To: <4C06A449.6070609@redhat.com> References: <4C06A449.6070609@redhat.com> Message-ID: <4C20B7DB.7050908@redhat.com> On 06/02/2010 08:34 PM, Rob Crittenden wrote: > Add a new role specifically for delegating enrollment. Previously you > had to delegate two tasks, this simplifies things. > > rob > ack. Pavel From pzuna at redhat.com Tue Jun 22 14:14:53 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 22 Jun 2010 16:14:53 +0200 Subject: [Freeipa-devel] [PATCH] 461 ignore no_* options in Virtual class In-Reply-To: <4C06A48C.4000502@redhat.com> References: <4C06A48C.4000502@redhat.com> Message-ID: <4C20C55D.8000209@redhat.com> On 06/02/2010 08:35 PM, Rob Crittenden wrote: > The Virtual base class is used for doing non-LDAP operations, right not > just for certificate commands. It wasn't honoring the no_* option flags. > Add support for that. > > rob > NACK. I think I do understand what this patch is trying to do and it works, but I also think it builds over the misuse of the 'no_*' option flags. These flags were added, so that we can specify a common list of Params in Object.takes_params and mark those that are inappropriate for Add/Update/Search methods. It doesn't make sense to use these flags in cert.py commands, because they aren't linked to any Object. If you want to add Params just for output purpose, use Command.has_output_params. EXAMPLE: WRONG: class cert_status(VirtualCommand): takes_args = ( Str('request_id', label=_('Request id'), # pzuna: the next line has no effect flags=['no_create', 'no_update', 'no_search'], ), ) # pzuna: ipa cert-status doesn't TAKE the cert-request-status option takes_options = ( Str('cert_request_status?', label=_('Request status'), flags=['no_create', 'no_update', 'no_search'], ), ) EXAMPLE: RIGHT: class cert_status(VirtualCommand): takes_args = ( Str('request_id', label=_('Request id'), ), ) has_output_params = ( Str('cert_request_status?', label=_('Request status'), ), ) Pavel From pzuna at redhat.com Tue Jun 22 14:17:10 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 22 Jun 2010 16:17:10 +0200 Subject: [Freeipa-devel] [PATCH] 462 add per-command documentation In-Reply-To: <4C06A4B6.4060505@redhat.com> References: <4C06A4B6.4060505@redhat.com> Message-ID: <4C20C5E6.20004@redhat.com> On 06/02/2010 08:36 PM, Rob Crittenden wrote: > First pass at adding per-command documentation for each plugin. > > rob > ack. Pavel From pzuna at redhat.com Tue Jun 22 14:24:41 2010 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 22 Jun 2010 16:24:41 +0200 Subject: [Freeipa-devel] [PATCH] 462 add per-command documentation In-Reply-To: <4C16D288.20604@redhat.com> References: <4C06A4B6.4060505@redhat.com> <4C16D288.20604@redhat.com> Message-ID: <4C20C7A9.70700@redhat.com> On 06/15/2010 03:08 AM, David O'Brien wrote: > Rob Crittenden wrote: >> First pass at adding per-command documentation for each plugin. >> >> rob > Rob, > How would you like edits to this? > > I _could_ edit the patch, or I could wait until you commit what you have > and then run ipa help and send edited files for each topic. This > was posted almost two weeks ago; what's the status? > > cheers > I think the best approach would be for you to send edited files. It's better if you see it in action than in a patch and it's less prone to mistakes. Pavel From ayoung at redhat.com Tue Jun 22 15:01:39 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 22 Jun 2010 11:01:39 -0400 Subject: [Freeipa-devel] Fields currently available for the user object In-Reply-To: <4C208481.1090703@redhat.com> References: <4C193BD5.4060201@redhat.com> <4C193D9C.7000005@redhat.com> <4C195850.8090704@redhat.com> <4C195A81.9000201@redhat.com> <4C19790E.8010500@redhat.com> <4C208481.1090703@redhat.com> Message-ID: <4C20D053.8020400@redhat.com> On 06/22/2010 05:38 AM, Pavel Zuna wrote: > On 06/17/2010 03:23 AM, Adam Young wrote: >> Is there any documentation on how to write plugins, or extend existing >> plugins? >> > As Rob pointed out, there are example plugins in > ipalib/plugins/example.py. They should give you a good overview of the > plugin framework, parameters, etc. Unfortunately, the file doesn't > cover baseldap.py classes used by 95% of the plugins. > > baseldap.py classes are described in the internal wiki, search for the > article named "HOWTO Write IPA command plugins". > > Pavel When I wrote this, I had done "everything correct" and still didn't see the value I was adding (Title) turns out that values that are not set just don't show up. Once I modified a user to have a title, I saw it. Thanks From ayoung at redhat.com Tue Jun 22 15:02:46 2010 From: ayoung at redhat.com (Adam Young) Date: Tue, 22 Jun 2010 11:02:46 -0400 Subject: [Freeipa-devel] Writing to /var/cache/ipa/assets/ In-Reply-To: <4C208653.8080906@redhat.com> References: <4C1BD77F.6070601@redhat.com> <4C1BDC68.8030608@redhat.com> <4C1BE4F3.9030605@redhat.com> <20100618175302.5e301331@willson.li.ssimo.org> <4C1BF1AD.3030108@redhat.com> <4C208653.8080906@redhat.com> Message-ID: <4C20D096.60107@redhat.com> On 06/22/2010 05:45 AM, Pavel Zuna wrote: > On 06/19/2010 12:22 AM, Adam Young wrote: >> On 06/18/2010 05:53 PM, Simo Sorce wrote: >>> On Fri, 18 Jun 2010 17:28:19 -0400 >>> Adam Young wrote: >>> >>>> On 06/18/2010 04:51 PM, Rob Crittenden wrote: >>>>> Adam Young wrote: >>>>>> Pavel's current code base tries to write >>>>>> to /var/cache/ipa/assets/ from within httpd, which is forbidden >>>>>> by SELinux. I suspect the code in the mainline might be doing >>>>>> this as well. The work around is: >>>>>> >>>>>> chcon -R -t httpd_sys_content_rw_t /var/cache/ipa/assets >>>>>> semanage fcontext -a -t httpd_sys_content_rw_t 'assets' >>>>>> >>>>>> If we are going to do this kind of code generation, we might want >>>>>> to do it at install time, or as part of something like >>>>>> /etc/init.d/ipa-server start >>>>>> >>>>> I'd think this rule would cover it in ipa_httpd.fc: >>>>> >>>>> /var/cache/ipa/assets(/.*)? >>>>> gen_context(system_u:object_r:httpd_sys_content_t,s0) >>>>> >>>>> rob >>>> Before I open a bug I want to review with Pavel. I wasn't seeing >>>> this before I merged in his changes, and it wasn't for code in the >>>> main git repo, so no bug yet. >>> As a general rule I don't like that apache gets to write to the file >>> system, esp if that means changing code that different users use at >>> the same time. It's a too big risk. >>> >>> Simo. >>> >> >> >> Simo, I agree. I'm thinking that anything doing one time code generation >> should be done outside the apache process. I'm not sure we are even >> going to take this approach long term. The code doing the generatrion >> is, I think left over from Jason's last effort. >> >> This is a possibility that we will want to script code based on the meta >> data of the plugins. We have three points we could do this: at plugin >> deploiy time, inside the server at http fetch , or in the broswer (via >> javascript). I suspect that the code that is currently writing to >> /var.... should be done at plugin deploy time instead, or should be done >> completely dynamically. >> > This has nothing to do with code generation. > > /var/cache/ipa/assets is the IPA location managed by Jason's assetslib > (python-assets). It's used to store static data like images, css, etc. > linked by the webUI. All normal files are copied there at installation > time and only symbolic links are created "on the fly" when something > changes. The goal is to achieve maximum caching. You can read more > about the concept here: > http://jderose.fedorapeople.org/assets/current/apidoc/assetslib-module.html > > > We're going to drop this code. Jason wrote it a long time ago, it has > some issues and I don't want to maintain it anymore (it's > misunderstood and causes more trouble than it saves). > > Pavel Pavel, I think some of that is generated, not at install time, but at apache start time, which is why SE Linux stopped it. From rcritten at redhat.com Tue Jun 22 17:56:23 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jun 2010 13:56:23 -0400 Subject: [Freeipa-devel] [PATCH] 460 an enrollment role In-Reply-To: <4C20B7DB.7050908@redhat.com> References: <4C06A449.6070609@redhat.com> <4C20B7DB.7050908@redhat.com> Message-ID: <4C20F947.5000405@redhat.com> Pavel Zuna wrote: > On 06/02/2010 08:34 PM, Rob Crittenden wrote: >> Add a new role specifically for delegating enrollment. Previously you >> had to delegate two tasks, this simplifies things. >> >> rob >> > ack. > > Pavel pushed to master From rcritten at redhat.com Tue Jun 22 17:57:54 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jun 2010 13:57:54 -0400 Subject: [Freeipa-devel] [PATCH] 461 ignore no_* options in Virtual class In-Reply-To: <4C20C55D.8000209@redhat.com> References: <4C06A48C.4000502@redhat.com> <4C20C55D.8000209@redhat.com> Message-ID: <4C20F9A2.6090700@redhat.com> Pavel Zuna wrote: > On 06/02/2010 08:35 PM, Rob Crittenden wrote: >> The Virtual base class is used for doing non-LDAP operations, right not >> just for certificate commands. It wasn't honoring the no_* option flags. >> Add support for that. >> >> rob >> > NACK. > > I think I do understand what this patch is trying to do and it works, > but I also think it builds over the misuse of the 'no_*' option flags. > > These flags were added, so that we can specify a common list of Params > in Object.takes_params and mark those that are inappropriate for > Add/Update/Search methods. > > It doesn't make sense to use these flags in cert.py commands, because > they aren't linked to any Object. > > If you want to add Params just for output purpose, use > Command.has_output_params. > > EXAMPLE: WRONG: > > class cert_status(VirtualCommand): > takes_args = ( > Str('request_id', > label=_('Request id'), > # pzuna: the next line has no effect > flags=['no_create', 'no_update', 'no_search'], > ), > ) > # pzuna: ipa cert-status doesn't TAKE the cert-request-status option > takes_options = ( > Str('cert_request_status?', > label=_('Request status'), > flags=['no_create', 'no_update', 'no_search'], > ), > ) > > > EXAMPLE: RIGHT: > > class cert_status(VirtualCommand): > takes_args = ( > Str('request_id', > label=_('Request id'), > ), > ) > has_output_params = ( > Str('cert_request_status?', > label=_('Request status'), > ), > ) > > > Pavel Okay, I see you're point. We can fix the cert plugin with has_output_params, but it still is an incompatibility with other classes. rob From rcritten at redhat.com Tue Jun 22 17:58:23 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jun 2010 13:58:23 -0400 Subject: [Freeipa-devel] [PATCH] 462 add per-command documentation In-Reply-To: <4C20C5E6.20004@redhat.com> References: <4C06A4B6.4060505@redhat.com> <4C20C5E6.20004@redhat.com> Message-ID: <4C20F9BF.3060400@redhat.com> Pavel Zuna wrote: > On 06/02/2010 08:36 PM, Rob Crittenden wrote: >> First pass at adding per-command documentation for each plugin. >> >> rob >> > ack. > > Pavel pushed to master. From rcritten at redhat.com Tue Jun 22 18:03:43 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jun 2010 14:03:43 -0400 Subject: [Freeipa-devel] [PATCH] 469 replication versioning Message-ID: <4C20FAFF.2070609@redhat.com> This patch relies on some features that 389-ds will be adding in 1.2.6. It will let us break replication between two IPA servers not running the same version. This will let us upgrade a group of servers one at a time and as they all get upgraded they can again replicate. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-469-version.patch Type: application/mbox Size: 16570 bytes Desc: not available URL: From nkinder at redhat.com Tue Jun 22 19:22:30 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 22 Jun 2010 12:22:30 -0700 Subject: [Freeipa-devel] [PATCH] 469 replication versioning In-Reply-To: <4C20FAFF.2070609@redhat.com> References: <4C20FAFF.2070609@redhat.com> Message-ID: <4C210D76.2000606@redhat.com> On 06/22/2010 11:03 AM, Rob Crittenden wrote: > This patch relies on some features that 389-ds will be adding in > 1.2.6. It will let us break replication between two IPA servers not > running the same version. This will let us upgrade a group of servers > one at a time and as they all get upgraded they can again replicate. nack. You should change repl_version_plugin_name to be a more descriptive IPA specific name. This name string will be used when the plugin logs messages in the 389-ds errors log. Everything else looks good. -NGK > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jun 23 14:08:41 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jun 2010 10:08:41 -0400 Subject: [Freeipa-devel] [PATCH] 469 replication versioning In-Reply-To: <4C210D76.2000606@redhat.com> References: <4C20FAFF.2070609@redhat.com> <4C210D76.2000606@redhat.com> Message-ID: <4C221569.4000004@redhat.com> Nathan Kinder wrote: > On 06/22/2010 11:03 AM, Rob Crittenden wrote: >> This patch relies on some features that 389-ds will be adding in >> 1.2.6. It will let us break replication between two IPA servers not >> running the same version. This will let us upgrade a group of servers >> one at a time and as they all get upgraded they can again replicate. > nack. > > You should change repl_version_plugin_name to be a more descriptive IPA > specific name. This name string will be used when the plugin logs > messages in the 389-ds errors log. Everything else looks good. Acceptable if I change the string to "ipa_replication_version" in the patch and commit? rob From nkinder at redhat.com Wed Jun 23 15:01:36 2010 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 23 Jun 2010 08:01:36 -0700 Subject: [Freeipa-devel] [PATCH] 469 replication versioning In-Reply-To: <4C221569.4000004@redhat.com> References: <4C20FAFF.2070609@redhat.com> <4C210D76.2000606@redhat.com> <4C221569.4000004@redhat.com> Message-ID: <4C2221D0.6050409@redhat.com> On 06/23/2010 07:08 AM, Rob Crittenden wrote: > Nathan Kinder wrote: >> On 06/22/2010 11:03 AM, Rob Crittenden wrote: >>> This patch relies on some features that 389-ds will be adding in >>> 1.2.6. It will let us break replication between two IPA servers not >>> running the same version. This will let us upgrade a group of >>> servers one at a time and as they all get upgraded they can again >>> replicate. >> nack. >> >> You should change repl_version_plugin_name to be a more descriptive >> IPA specific name. This name string will be used when the plugin >> logs messages in the 389-ds errors log. Everything else looks good. > > Acceptable if I change the string to "ipa_replication_version" in the > patch and commit? Yes. > > rob From mnagy at redhat.com Wed Jun 23 15:11:19 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 23 Jun 2010 17:11:19 +0200 Subject: [Freeipa-devel] [PATCH] 467 fix aci-mod command In-Reply-To: <4C126157.4090409@redhat.com> References: <4C126157.4090409@redhat.com> Message-ID: <4C222417.8040804@redhat.com> On 06/11/2010 06:16 PM, Rob Crittenden wrote: > Convert the ACI back into keywords so we can merge in any changes, then > re-create the ACI. This is a much safer method of doing it. > > I also switched to use the declarative test mechanism and tripled the > number of aci tests we perform. > > rob Ack. Martin From rcritten at redhat.com Thu Jun 24 14:27:40 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 10:27:40 -0400 Subject: [Freeipa-devel] [PATCH] 467 fix aci-mod command In-Reply-To: <4C222417.8040804@redhat.com> References: <4C126157.4090409@redhat.com> <4C222417.8040804@redhat.com> Message-ID: <4C236B5C.1030209@redhat.com> Martin Nagy wrote: > On 06/11/2010 06:16 PM, Rob Crittenden wrote: >> Convert the ACI back into keywords so we can merge in any changes, then >> re-create the ACI. This is a much safer method of doing it. >> >> I also switched to use the declarative test mechanism and tripled the >> number of aci tests we perform. >> >> rob > > Ack. > > Martin pushed to master From rcritten at redhat.com Thu Jun 24 14:34:13 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 10:34:13 -0400 Subject: [Freeipa-devel] [PATCH] 469 replication versioning In-Reply-To: <4C2221D0.6050409@redhat.com> References: <4C20FAFF.2070609@redhat.com> <4C210D76.2000606@redhat.com> <4C221569.4000004@redhat.com> <4C2221D0.6050409@redhat.com> Message-ID: <4C236CE5.5030404@redhat.com> Nathan Kinder wrote: > On 06/23/2010 07:08 AM, Rob Crittenden wrote: >> Nathan Kinder wrote: >>> On 06/22/2010 11:03 AM, Rob Crittenden wrote: >>>> This patch relies on some features that 389-ds will be adding in >>>> 1.2.6. It will let us break replication between two IPA servers not >>>> running the same version. This will let us upgrade a group of >>>> servers one at a time and as they all get upgraded they can again >>>> replicate. >>> nack. >>> >>> You should change repl_version_plugin_name to be a more descriptive >>> IPA specific name. This name string will be used when the plugin >>> logs messages in the 389-ds errors log. Everything else looks good. >> >> Acceptable if I change the string to "ipa_replication_version" in the >> patch and commit? > Yes. >> >> rob > Done, pushed to master From rcritten at redhat.com Thu Jun 24 15:45:16 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 11:45:16 -0400 Subject: [Freeipa-devel] [PATCH] 471 crypto cleanup Message-ID: <4C237D8C.4040608@redhat.com> Drop our x509v3 asn.1 parser and use the new capabilities of python-nss. Include a lot more information when returning a certificate. I'm including an API change here too. I'm renaming cert-get to cert-show to be more consistent with other plugins. I don't know of any external apps that use cert-get so we should be ok there. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-471-cert.patch Type: application/mbox Size: 28264 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 24 15:46:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 11:46:02 -0400 Subject: [Freeipa-devel] [PATCH] 472 cleanup imports of hbacsvc plugin Message-ID: <4C237DBA.4040507@redhat.com> I ran pylint against the hbacsvc plugin and identified a slew of unused imports. I removed them and pulled only the classes we need out of baseldap. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-472-hbacsvc.patch Type: application/mbox Size: 1030 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 24 18:17:05 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 14:17:05 -0400 Subject: [Freeipa-devel] [PATCH] 473 fix aci update summary Message-ID: <4C23A121.1040203@redhat.com> Seems I changed the summary message for updating hosts which breaks a few of the aci tests. This should bring it back in line. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-473-aci.patch Type: application/mbox Size: 2659 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 24 18:23:56 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 14:23:56 -0400 Subject: [Freeipa-devel] [PATCH] 470 maintainer-clean change In-Reply-To: <4C1F961B.40306@redhat.com> References: <4C1A87A0.5020403@redhat.com> <4C1F961B.40306@redhat.com> Message-ID: <4C23A2BC.5070609@redhat.com> Martin Nagy wrote: > On 06/17/2010 10:37 PM, Rob Crittenden wrote: >> I almost pushed this under the one-liner rule but what the heck. Add a >> maintainer-clean target to install/po. All the heavy lifting is already >> done in distclean so just depend on that. >> >> rob > > Ack. > > Martin pushed to master From rcritten at redhat.com Thu Jun 24 18:24:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 14:24:58 -0400 Subject: [Freeipa-devel] [PATCH] 468 don't run through pre-bind code on enrollment In-Reply-To: <20100622141534.59a5e1a3@willson.li.ssimo.org> References: <4C1299A0.8030108@redhat.com> <20100611163712.1c36b88c@willson.li.ssimo.org> <4C164DC8.9050802@redhat.com> <20100622141534.59a5e1a3@willson.li.ssimo.org> Message-ID: <4C23A2FA.5070000@redhat.com> Simo Sorce wrote: > On Mon, 14 Jun 2010 11:42:00 -0400 > Rob Crittenden wrote: > >> Updated patch attached. I took the opportunity to fix another >> instance of comparing to host/ in the principal name as well. > > Looks good to me. > > Ack. > > Simo. > pushed to master From rcritten at redhat.com Thu Jun 24 21:30:58 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jun 2010 17:30:58 -0400 Subject: [Freeipa-devel] [PATCH] 474 add missing version file Message-ID: <4C23CE92.1030803@redhat.com> I missed adding a new file in the replication version plugin. I went ahead and pushed it to fix the build. I also updated the minimum level of 389-ds-base to 1.2.6. This is still in testing but the versioning plugin won't work without it. To pull this from Fedora do: # yum --enablerepo=updates-testing update 389-ds-base rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-474-version.patch Type: application/mbox Size: 4445 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 25 13:44:05 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jun 2010 09:44:05 -0400 Subject: [Freeipa-devel] [PATCH] use time and search limit values from cn=ipaconfig Message-ID: <4C24B2A5.2080805@redhat.com> Use the cn=ipaconfig time and search limit values, and cache cn=ipaconfig This reads cn=ipaconfig just once and uses that same entry for all future requests. It gets re-read only if the entry is updated by our config plugin. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-475-config.patch Type: application/mbox Size: 3913 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 25 13:46:28 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jun 2010 09:46:28 -0400 Subject: [Freeipa-devel] [PATCH] 476 fix bad API call in selfsign Message-ID: <4C24B334.9040503@redhat.com> Use newer API in selfsign plugin. Fix missing import when running in the in-tree lite-server. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-476-cert.patch Type: application/mbox Size: 1457 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 25 13:47:45 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jun 2010 09:47:45 -0400 Subject: [Freeipa-devel] [PATCH] 477 add tests for ipalib/x509 Message-ID: <4C24B381.4040405@redhat.com> Add some basic tests for loading certs and retrieving the data we use. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-477-x509.patch Type: application/mbox Size: 5785 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 25 17:52:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jun 2010 13:52:52 -0400 Subject: [Freeipa-devel] [PATCH] 478 better startup error handling Message-ID: <4C24ECF4.8030707@redhat.com> This patch will limit the amount of output in the Apache error log by default. It should suppress the traceback and just display the exception. This is mostly to handle LDAP connection issues during startup where we retrieve the schema but it could have other implications as well. I've added a new config file directive, startup_traceback, defaulting to False. If you want the full traceback you can add this to /etc/ipa/default.conf (or ~/.ipa/default.conf) and get full tracebacks. In lite-server.py this defaults to True. I was looking for a way to cause Apache startup to fail if something blew up in IPA but I couldn't find anything in mod_wsgi to support that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-478-traceback.patch Type: application/mbox Size: 6470 bytes Desc: not available URL: From rcritten at redhat.com Fri Jun 25 20:17:29 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jun 2010 16:17:29 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups In-Reply-To: <4C1B68DD.9030100@redhat.com> References: <4C0EA6B2.2070904@redhat.com> <4C12AE2D.9030205@redhat.com> <4C162427.2060206@redhat.com> <4C1AB22B.7070905@redhat.com> <4C1B68DD.9030100@redhat.com> Message-ID: <4C250ED9.4050800@redhat.com> Rob Crittenden wrote: > Adam Young wrote: >> On 06/14/2010 08:44 AM, Rob Crittenden wrote: >>> Adam Young wrote: >>>> When the patch was applied, and the packages were installed on a >>>> clean system, ipa-server-install kicked directly into the debugger >>>> afterthe line: >>>> >>>> [7/21]: configuring user private groups >>>> >>>> >>>> stack trace showed >>>> >>>> dsinstance.py(124)has_managed_entries() >>>> ->try >>> >>> Looks like I left a debug statement in the patch. You can press 'c' >>> here to continue (it'll prompt you again later). I can remove these >>> statements before I push the patch if it is otherwise ok. >>> >>> rob >> >> OK, I think this is a legit problem: I have a version of the the DS >> that has /usr/lib64/dirsrv/plugins/libmanagedentries-plugin.so >> >> [root at ipa patchedrpms]# rpmquery 389-ds-base >> 389-ds-base-1.2.6-0.6.rc1.fc13.x86_64 >> >> The following fails. I think the error message is either failing at >> I18N or has a typo in the URL, due to the u' in it. >> >> [root at ipa patchedrpms]# ipa user-add --first Count --last VonCount >> User login [cvoncount]: count123ahahah >> ipa: ERROR: cannot connect to >> u'https://ipa.ayoung.boston.devel.redhat.com/ipa/xml': Internal Server >> Error >> > > There should be a backtrace in /var/log/httpd/error_log. Can you provide > that? > > thanks I rebased the patch, should apply cleanly now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-464-2-upg.patch Type: application/mbox Size: 12153 bytes Desc: not available URL: From ayoung at redhat.com Fri Jun 25 20:56:46 2010 From: ayoung at redhat.com (Adam Young) Date: Fri, 25 Jun 2010 16:56:46 -0400 Subject: [Freeipa-devel] [PATCH] 464 User-Private groups In-Reply-To: <4C250ED9.4050800@redhat.com> References: <4C0EA6B2.2070904@redhat.com> <4C12AE2D.9030205@redhat.com> <4C162427.2060206@redhat.com> <4C1AB22B.7070905@redhat.com> <4C1B68DD.9030100@redhat.com> <4C250ED9.4050800@redhat.com> Message-ID: <4C25180E.1050305@redhat.com> On 06/25/2010 04:17 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Adam Young wrote: >>> On 06/14/2010 08:44 AM, Rob Crittenden wrote: >>>> Adam Young wrote: >>>>> When the patch was applied, and the packages were installed on a >>>>> clean system, ipa-server-install kicked directly into the debugger >>>>> afterthe line: >>>>> >>>>> [7/21]: configuring user private groups >>>>> >>>>> >>>>> stack trace showed >>>>> >>>>> dsinstance.py(124)has_managed_entries() >>>>> ->try >>>> >>>> Looks like I left a debug statement in the patch. You can press 'c' >>>> here to continue (it'll prompt you again later). I can remove these >>>> statements before I push the patch if it is otherwise ok. >>>> >>>> rob >>> >>> OK, I think this is a legit problem: I have a version of the the DS >>> that has /usr/lib64/dirsrv/plugins/libmanagedentries-plugin.so >>> >>> [root at ipa patchedrpms]# rpmquery 389-ds-base >>> 389-ds-base-1.2.6-0.6.rc1.fc13.x86_64 >>> >>> The following fails. I think the error message is either failing at >>> I18N or has a typo in the URL, due to the u' in it. >>> >>> [root at ipa patchedrpms]# ipa user-add --first Count --last VonCount >>> User login [cvoncount]: count123ahahah >>> ipa: ERROR: cannot connect to >>> u'https://ipa.ayoung.boston.devel.redhat.com/ipa/xml': Internal >>> Server Error >>> >> >> There should be a backtrace in /var/log/httpd/error_log. Can you >> provide that? >> >> thanks > > I rebased the patch, should apply cleanly now. > > rob > > ACK Tested out with review board, but the patch seems pretty straight forward. I should have added to the "testing" section that I applied it to a DS instance that did not support the lugin and it worked fine as well. From ayoung at redhat.com Mon Jun 28 15:54:36 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 28 Jun 2010 11:54:36 -0400 Subject: [Freeipa-devel] New web directory Message-ID: <4C28C5BC.7030708@redhat.com> I think we need a new web directory, something similar to /usr/share/ipa/html, but that shows up in the web url. The wsgi code chops off the file extension, so user.html becomes user. THis will break the javascript. I'm assuming that was why we're currently putting the .js files into /var/lib/cache/assets. I think the simplest appraoch would be to create a directory in /var/www/html For static content. Then, the stuff that I have checked into freeipa/web (minus the sample data sub dir) would be deployed to there. Of course, the problem is that the /ipa URL path gets redirected to WSGI, but I think we can put an explicit excludes in for it. As I said before, one of my goals is to be able to do development completly offline, with no round trips to the server, to ease both development and to allow for automated testing of the javascript code. If people want to continue to put the static code into /usr/share/ipa/html then the current html directory should probably be renamed to 'errors' or something so the good name can be used for the main html. From ayoung at redhat.com Mon Jun 28 19:17:29 2010 From: ayoung at redhat.com (Adam Young) Date: Mon, 28 Jun 2010 15:17:29 -0400 Subject: [Freeipa-devel] Development approach. Message-ID: <4C28F549.6040904@redhat.com> I've attempted to document what I think our approach should be for the FreeIPA Web UI. THe document is here: https://fedorahosted.org/freeipa/wiki/UIApproach For those adverse to clicking links, I'll inline it below as well. Please comment on specific section. This page is just a draft, pending approval of the rest of the FreeIPA team. The general approach to Web UI development for IPA springs from the fact that Javascript is a fundamental aspect of web programming. Instead of using a Server side scripting language to drive development, and then attempting to shoehorn Javascript into that language, we are using Javascript as the primary programming language of the site. The command line interface (CLI) has already specified a large body of xml-rpc based APIs. We will focus on the Web UI and using same API, called via JSON-RPC, a format somewhat friendlier to the Javascript language. The current state of the art in Web design has embraced a concept called Progressive Enhancement (PE). Under Progressive Enhancement, a site is first developed with no Javascript and minimal Cascading Style Sheet (CSS) support. The goal is to build a fully functioning site that works on the widest away of browsers, with the trade off that it will have only the most rudimentary of features. While we are diverging a little bit from this approach, our default requirement for a minimal subset of Javascript will support all major browsers, and has been tested on such a minimal browser as is supported on the Palm Pre wireless device. From this baseline, we will then follow the recommendations of PE, testing the browsers for any capabilities we will require for features such as auto-complete, tabbed browsing, and enhanced text editing. This approach should maximize the number of browsers capable of using the web UI. The landing page should have a simple name, such as *ipa.xhtml*. The file requires no servers side scripting to render. Instead, all dynamic content, including navigation, is driven by Javascript in the browser. Each of the subordinate pages are currently implemented as HTML fragments that are included into the main page using $('#content').load(bodycontent); where content is the id for the DIV tag that contains the main content area, under the menu, and *bodycontent* is a string that names the page to be loaded. The page fragments are not in themselves valid xhtml, as that would require additional parsing in order to get them to render. They have the extension of .inc. For the most part, they are completely static HTML, coupled with a simple script tag that knows how to populate the fragment. Because common functions should be shared across multiple pages, the main body of work should not be inside the page fragments. Constant refactoring should occur to keep the fragments as light as possible. The menu for the site is a custom component based on the concept of a dynamic site map. In short, the site map is a tree structure, where each node maps to a page. This tree is used to generate the tabs that are the navigational structure of the site, as well as the links on these tabs. The nodes of the site map May be hided or reordered based on the role of the logged in user. The links map to the page fragments discussed above. IPA has a plugin architecture that allows the site deployer to customize the objects managed by IPA. This poses an interesting challenge for the UI. For basic functionality, it is relatively simple to specify the set of fields presented for managing one of the base objects (user, host, group). Once the user starts modifying the field set, we have several potential scenarios. 1. The user may add additional fields that they want to see on the web UI. 2. The user may modify one of the existing fields such that default validation rules no longer hold true 3. The user may remove fields from the objects. A first approximation would be to generate the UI based on the Plugin Data itself. The drawbacks of this approach are: splitting UI development over two languages, and forcing the CLI to conform to rules that may only make sense for the web UI. In addition, this approach was attempted in the past, and ended up with a very "data drive, CRUD style" approach that didn't map to the work flow users really need to make the site usable. We will take a page from the Progressive Enhancement book, and test the JSON returned from the server in order to see what values are accepted. This will help solve problems 1 and 3 above. For deleted fields, we can determine if a given field is essential. If an essential field has been removed, we will report a meaningful error message to the end user, and disable either the entire site, or some subset of functionality, based on business rules. For fields added but not exposed by the UI, we will add a single warning message to the log upon first access. After this, we will set a cookie in the browser and ignore these warnings, except perhaps to have some indicator on the page the there are unhandled fields. A validation rule is a business rule, and thus spans both the UI and business-logic layers. For field that have validation rules that have changed, the best approach is to share the validation between the browser and the back end scripting language. As such, validation rules should be represented in a subset of Regular Expressions supported both by the server side language (Python) and by Javascript. The validation rules themselves are then exposed via JSON-RPC to the Browser. For development and unit testing, all content that is fetched from JSON-RPC calls can be replaced with canned responses from files in a subdirectory named *sampledata*. To switch between sampledata and live JSON calls, alternately create or remove a file from the web root directory named *ipadebug.js* that contains the single value "ipadebug=true". This file is tracked via gitignore so that no-one accidentally checks it in. The Makefile that assembles the files from the web directories will ignore the files in sampledata. If we wish to deploy the sample data files for unit testing purposes, we can always create a separate RPM for them that does not get built or deployed be default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnagy at redhat.com Wed Jun 30 15:21:23 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 30 Jun 2010 17:21:23 +0200 Subject: [Freeipa-devel] [PATCH] 472 cleanup imports of hbacsvc plugin In-Reply-To: <4C237DBA.4040507@redhat.com> References: <4C237DBA.4040507@redhat.com> Message-ID: <1277911283.7788.6.camel@wolverine.englab.brq.redhat.com> On Thu, 2010-06-24 at 11:46 -0400, Rob Crittenden wrote: > I ran pylint against the hbacsvc plugin and identified a slew of unused > imports. I removed them and pulled only the classes we need out of baseldap. > > rob Ack Martin From mnagy at redhat.com Wed Jun 30 15:21:54 2010 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 30 Jun 2010 17:21:54 +0200 Subject: [Freeipa-devel] [PATCH] 473 fix aci update summary In-Reply-To: <4C23A121.1040203@redhat.com> References: <4C23A121.1040203@redhat.com> Message-ID: <1277911314.7788.7.camel@wolverine.englab.brq.redhat.com> On Thu, 2010-06-24 at 14:17 -0400, Rob Crittenden wrote: > Seems I changed the summary message for updating hosts which breaks a > few of the aci tests. This should bring it back in line. > > rob Ack. Martin