From jhrozek at redhat.com Sat Aug 1 15:27:26 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sat, 01 Aug 2009 17:27:26 +0200 Subject: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names Message-ID: <4A745EDE.5080601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Attached are two patches that allow the tools to operate on fully qualified names, that is, names in the form of user at DOMAIN. [PATCH 1/2] Move parsing of names and domains into util/ I used the already existing facility for parsing names from the responder. This patch moves it into util/ for general consumption. [PATCH 2/2] Parse fully qualified names in tools Allow adding users into different domains not only by specifying ID directly but also by specifying fully qualified name. Exit when both specifications are used in conflict. Thanks, Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp0XscACgkQHsardTLnvCXhGgCg2wRdt6h54obbb1PVUfK7swCh JfUAoMQqC2PbmgFamH5r0TtcH7i5/k4L =5v0C -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Move-parsing-of-names-and-domains-into-util.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0002-Parse-fully-qualified-names-in-tools.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Move-parsing-of-names-and-domains-into-util.patch.sig Type: application/pgp-signature Size: 72 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Parse-fully-qualified-names-in-tools.patch.sig Type: application/pgp-signature Size: 72 bytes Desc: not available URL: From kwade at redhat.com Sat Aug 1 18:57:16 2009 From: kwade at redhat.com (Karsten Wade) Date: Sat, 1 Aug 2009 11:57:16 -0700 Subject: [Freeipa-devel] contribution policy draft In-Reply-To: <4A66F139.3060309@redhat.com> References: <20090715044601.GB29035@calliope.phig.org> <4A5DB003.3030404@redhat.com> <20090722052036.GG12672@calliope.phig.org> <4A66F139.3060309@redhat.com> Message-ID: <20090801185716.GZ7063@calliope.phig.org> On Wed, Jul 22, 2009 at 07:00:09AM -0400, Stephen Gallagher wrote: > > I have not yet had a chance to do so. Please, by all means, start the > ball rolling on this. I can be available for a phone call between 0700- > 1800 EDT almost any weekday. BTW, I followed up with a request for meetings about the contribution policy draft for FreeIPA and SSSD overall discussion; no news yet. - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jhrozek at redhat.com Mon Aug 3 11:08:12 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 03 Aug 2009 13:08:12 +0200 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies Message-ID: <4A76C51C.705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached patch addresses ticket #84. The implementation is unfortunately Linux-specific as it uses the prctl(2) syscall. Ideas how to accomplish this in a cross-platform manner are welcome. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp2xRwACgkQHsardTLnvCXTywCfasymEPbxk4Bxw0E0QHOD2lam f2wAoNL9Kwu/OgenxPSAeKnQ5TypGStx =LgoS -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-child-processes-exit-when-parent-dies.patch Type: text/x-patch Size: 5159 bytes Desc: not available URL: From jhrozek at redhat.com Mon Aug 3 15:05:19 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 03 Aug 2009 17:05:19 +0200 Subject: [Freeipa-devel] [PATCH] Consolidate tevent helpers Message-ID: <4A76FCAF.2080703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We use several macros that substitute tevent functions not available in the current F11 release. The attached patch just moves these definitions to one place in util/util.h to avoid unnecessary duplication. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp2/K8ACgkQHsardTLnvCW27QCfRdpEdMiPQpAVk3ZlkJeSqlys gygAoMlSEFHCfhC5IWIRX4Vtusds1t0I =WMjK -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Consolidate-tevent-helpers.patch Type: text/x-patch Size: 6417 bytes Desc: not available URL: From mpcolino at gmail.com Mon Aug 3 15:48:38 2009 From: mpcolino at gmail.com (Miguel P.C.) Date: Mon, 03 Aug 2009 17:48:38 +0200 Subject: [Freeipa-devel] Files to builde SSSD package 0.4.1 (not working yet) Message-ID: <1249314518.3646.17.camel@crow> Sorry for the delay ... -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd-0.4.1_debian_files.tar.gz Type: application/x-compressed-tar Size: 15247 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From sgallagh at redhat.com Mon Aug 3 16:05:12 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 03 Aug 2009 12:05:12 -0400 Subject: [Freeipa-devel] Files to builde SSSD package 0.4.1 (not working yet) In-Reply-To: <1249314518.3646.17.camel@crow> References: <1249314518.3646.17.camel@crow> Message-ID: <4A770AB8.3000306@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 11:48 AM, Miguel P.C. wrote: > Sorry for the delay ... > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Miguel, we currently have https://fedorahosted.org/sssd/ticket/90 open against build issues with the current HEAD revision of the git repository. Do you have any other known issues with the HEAD revision? One of my goals is to have builds functional on Karmic as of SSSD 0.5.0 (exact release as yet determined, but hopefully soon) - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3CrAACgkQeiVVYja6o6PhDwCgojVAxJ85jbtcxJPrxJuLDWOe 7kMAnAjf5wQlsiLq5DqG/q6I9nOT9DXb =qci3 -----END PGP SIGNATURE----- From ssorce at redhat.com Mon Aug 3 17:18:46 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 03 Aug 2009 13:18:46 -0400 Subject: [Freeipa-devel] PATCH: fixes LDAP driver searches Message-ID: <1249319926.3040.10.camel@localhost.localdomain> Stupid typo was making all searches just vanish in thin air. Should work fine with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-search-replies-getting-ignored.patch Type: application/mbox Size: 831 bytes Desc: not available URL: From jhrozek at redhat.com Mon Aug 3 17:23:33 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 03 Aug 2009 19:23:33 +0200 Subject: [Freeipa-devel] [PATCH] Fix adding to groups on user creation Message-ID: <4A771D15.2020504@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fixes a copy-paste error that prevented the -G/--groups parameter of useradd from working. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3HRUACgkQHsardTLnvCVhXwCfQQGP5UqyIfWlPN0CeByxKEIq f3gAoMSi4kx0m6F/dO60OZc9ObiUkxWW =5mtH -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-adding-to-groups-on-user-creation.patch Type: text/x-patch Size: 857 bytes Desc: not available URL: From sgallagh at redhat.com Mon Aug 3 17:34:32 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 03 Aug 2009 13:34:32 -0400 Subject: [Freeipa-devel] PATCH: fixes LDAP driver searches In-Reply-To: <1249319926.3040.10.camel@localhost.localdomain> References: <1249319926.3040.10.camel@localhost.localdomain> Message-ID: <4A771FA8.8020003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 01:18 PM, Simo Sorce wrote: > Stupid typo was making all searches just vanish in thin air. > Should work fine with this patch. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nack. You're testing if(ret==EOK) below the switch statement, but it's not initialized, and it's only set for case LDAP_RES_BIND: case LDAP_RES_SEARCH_RESULT: case LDAP_RES_MODIFY: case LDAP_RES_ADD: case LDAP_RES_DELETE: case LDAP_RES_MODDN: case LDAP_RES_COMPARE: case LDAP_RES_EXTENDED: case LDAP_RES_INTERMEDIATE: - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3H5oACgkQeiVVYja6o6MO2gCglSqE5aHp9WSpT/U26BzzUFz8 0+sAoIz4hnJDYOIu/aj4gNyQLY/LnMH5 =k9em -----END PGP SIGNATURE----- From ssorce at redhat.com Mon Aug 3 17:44:50 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 03 Aug 2009 13:44:50 -0400 Subject: [Freeipa-devel] PATCH: fixes LDAP driver searches In-Reply-To: <4A771FA8.8020003@redhat.com> References: <1249319926.3040.10.camel@localhost.localdomain> <4A771FA8.8020003@redhat.com> Message-ID: <1249321490.3040.13.camel@localhost.localdomain> On Mon, 2009-08-03 at 13:34 -0400, Stephen Gallagher wrote: > On 08/03/2009 01:18 PM, Simo Sorce wrote: > > Stupid typo was making all searches just vanish in thin air. > > Should work fine with this patch. > Nack. > > You're testing if(ret==EOK) below the switch statement, but it's not > initialized, and it's only set for > case LDAP_RES_BIND: > case LDAP_RES_SEARCH_RESULT: > case LDAP_RES_MODIFY: > case LDAP_RES_ADD: > case LDAP_RES_DELETE: > case LDAP_RES_MODDN: > case LDAP_RES_COMPARE: > case LDAP_RES_EXTENDED: > case LDAP_RES_INTERMEDIATE: Right, that check is actually not really needed anymore. Attached patch that changes the code so that the useless check is removed. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-search-replies-getting-ignored.patch Type: application/mbox Size: 1995 bytes Desc: not available URL: From sgallagh at redhat.com Mon Aug 3 17:55:20 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 03 Aug 2009 13:55:20 -0400 Subject: [Freeipa-devel] PATCH: fixes LDAP driver searches In-Reply-To: <1249321490.3040.13.camel@localhost.localdomain> References: <1249319926.3040.10.camel@localhost.localdomain> <4A771FA8.8020003@redhat.com> <1249321490.3040.13.camel@localhost.localdomain> Message-ID: <4A772488.3010509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 01:44 PM, Simo Sorce wrote: > On Mon, 2009-08-03 at 13:34 -0400, Stephen Gallagher wrote: >> On 08/03/2009 01:18 PM, Simo Sorce wrote: >>> Stupid typo was making all searches just vanish in thin air. >>> Should work fine with this patch. > >> Nack. >> >> You're testing if(ret==EOK) below the switch statement, but it's not >> initialized, and it's only set for >> case LDAP_RES_BIND: >> case LDAP_RES_SEARCH_RESULT: >> case LDAP_RES_MODIFY: >> case LDAP_RES_ADD: >> case LDAP_RES_DELETE: >> case LDAP_RES_MODDN: >> case LDAP_RES_COMPARE: >> case LDAP_RES_EXTENDED: >> case LDAP_RES_INTERMEDIATE: > > Right, that check is actually not really needed anymore. > Attached patch that changes the code so that the useless check is > removed. > > Simo. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack and pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3JIMACgkQeiVVYja6o6OZ2gCfUjXDB7qJTwqSLmQ6HZbDiczM 4fsAoKiS1pvS76ItQCFNl3Hu17NlKIPb =m1Dm -----END PGP SIGNATURE----- From jderose at redhat.com Tue Aug 4 05:38:51 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 03 Aug 2009 23:38:51 -0600 Subject: [Freeipa-devel] [PATCHES] All-around improvements to baseldap.py classes. In-Reply-To: <4A731AFB.50209@redhat.com> References: <4A731AFB.50209@redhat.com> Message-ID: <1249364331.5191.0.camel@jgd-flap> ack to all 4. pushed to master. On Fri, 2009-07-31 at 18:25 +0200, Pavel Z?na wrote: > 0001: Enable attribute re-mapping and ordering when printing entries. > > Also print multiple values on one line separated by commas. > > ----------------------------------------------------------------------- > 0002: Prevent double encoding/decoding when processing compound types. > > ----------------------------------------------------------------------- > 0003: Fix bug in _get_syntax (it was always returning None). > > Also prevent a few cases of double processing of arguments. > > ----------------------------------------------------------------------- > 0004: All-around improvements to baseldap.py classes. > > - attribute re-mapping, ordering and hiding > (Enables plugins to completely hide LDAP internals from users > and full localization of command output.) > - translation of member DNs into object names > (No more DNs when listing group members etc.) > - support for "singleton" LDAP objects > (Objects like "pwpolicy"; not accessed by primary key.) > - new base classes for commands: LDAPModMember, LDAPAddMember > and LDAPRemoveMember > (Providing support for objects with 'member'-like attributes.) > - LDAPSearch implicit exit code changed to 1 when nothing is found > > > Pavel > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jderose at redhat.com Tue Aug 4 06:29:32 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 04 Aug 2009 06:29:32 +0000 Subject: [Freeipa-devel] [PATCH] jderose 014 Fix three broken unit tests Message-ID: <1249367372.5191.7.camel@jgd-flap> This fixes two unit tests and 1 doctest, all pretty trivial breaks. I hope no one minds too much, but I self-acked this and pushed it to master because these broken tests are holding up my UI work a bit. """ Looks great, Jason! ack, pushed to master. -Jason """ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-014-Fix-three-broken-unit-tests.patch Type: text/x-patch Size: 2702 bytes Desc: not available URL: From jderose at redhat.com Tue Aug 4 08:54:35 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 04 Aug 2009 02:54:35 -0600 Subject: [Freeipa-devel] [PATCH] jderose 015 Remove PluginProxy Message-ID: <1249376075.5191.29.camel@jgd-flap> For the UI work I needed to stop wrapping commands in PluginProxy so I can check if a command is an instance of crud.Create, crud.Retrieve, and so on. Plus, PluginProxy just wasn't as good an idea as I first thought. ;) This patch removes the PluginProxy class and all it's uses. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-015-Removed-PluginProxy.patch Type: text/x-patch Size: 17168 bytes Desc: not available URL: From jhrozek at redhat.com Tue Aug 4 11:47:37 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 04 Aug 2009 13:47:37 +0200 Subject: [Freeipa-devel] [PATCH] Fix typo in function call in pamsrv_cmd.c Message-ID: <4A781FD9.6070901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was looking into how negative cache is implemented and used in sssd and spotted a typo in function call name that would break compilation if HAVE_NEG_CACHE was defined. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4H9gACgkQHsardTLnvCUrpgCeI762B0dGRKyLoEwXycb8dbMI tIIAnj3vhj6xu4OCB5UDGsskMAI4t1Vu =n3c5 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-typo-in-function-call-in-pamsrv_cmd.c.patch Type: text/x-patch Size: 932 bytes Desc: not available URL: From mpcolino at gmail.com Tue Aug 4 13:47:58 2009 From: mpcolino at gmail.com (Miguel P.C.) Date: Tue, 04 Aug 2009 15:47:58 +0200 Subject: [Freeipa-devel] Files to builde SSSD package 0.4.1 (not working yet) In-Reply-To: <4A770AB8.3000306@redhat.com> References: <1249314518.3646.17.camel@crow> <4A770AB8.3000306@redhat.com> Message-ID: <1249393678.3856.5.camel@crow> Hi Stephen, hola everyone, > Miguel, we currently have https://fedorahosted.org/sssd/ticket/90 open > against build issues with the current HEAD revision of the git repository. > > Do you have any other known issues with the HEAD revision? One of my > goals is to have builds functional on Karmic as of SSSD 0.5.0 (exact > release as yet determined, but hopefully soon) I'm working with a computer that is not my usual "build computer" so I'm trying to get all I need installed and give it a try. Now I'm on holidays so I'm spending as little time on anything that makes me think as possible. (I need a break, you know!). Anyway, I'm finding time to finish some little things left from work this week, as next two I won't have internet access. I'll try to give you a bit of a report on how sssd builds on Karmic B4 friday (... if possible). BTW I'll use SSSD HEAD and Karmic with the latest updates. Is that OK? M* -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From pzuna at redhat.com Tue Aug 4 14:22:27 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 04 Aug 2009 16:22:27 +0200 Subject: [Freeipa-devel] [PATCHES] All-around improvements to baseldap.py classes. In-Reply-To: <4A733787.5020303@redhat.com> References: <4A731AFB.50209@redhat.com> <4A733787.5020303@redhat.com> Message-ID: <4A784423.6010306@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> 0001: Enable attribute re-mapping and ordering when printing entries. >> >> Also print multiple values on one line separated by commas. > > Ok, though we'll have to see what that looks like on very large values. > > One thing I'm thinking is memberOf. In v1 when showing a user you'd also > get the list of groups they are a member of. All one one line would be > really hard to grok. > Actually I made the change because of attributes like 'member' and 'memberOf'. For 100 users in a groups, we had a 100 lines of output. On the other hand, if the users don't fit on one line, the output isn't very nice. Anyway I made another patch that improves this - it word wraps and indents the values like this: Password policy maximum lifetime (in days): 90 minimum lifetime (in hours): 1 history size: 0 minimum number of characters classes: 0 minimum length: 8 test: a, a, aa, aaa, aaaa, aaaaa, aaaaaa, aaaaaaa, aaaaaaaa, aaaaaaaaa, aaaaaaaaaa, aaaaaaaaaaa, aaaaaaaaaaaa, aaaaaaaaaaaaa, aaaaaaaaaaaaaa, aaaaaaaaaaaaaaa, Since this patch was already pushed, I'll submit the improvement in a separate one. >> ----------------------------------------------------------------------- >> 0002: Prevent double encoding/decoding when processing compound types. >> > > ack > >> ----------------------------------------------------------------------- >> 0003: Fix bug in _get_syntax (it was always returning None). >> >> Also prevent a few cases of double processing of arguments. > > ack > >> >> ----------------------------------------------------------------------- >> 0004: All-around improvements to baseldap.py classes. >> >> - attribute re-mapping, ordering and hiding >> (Enables plugins to completely hide LDAP internals from users >> and full localization of command output.) >> - translation of member DNs into object names >> (No more DNs when listing group members etc.) >> - support for "singleton" LDAP objects >> (Objects like "pwpolicy"; not accessed by primary key.) >> - new base classes for commands: LDAPModMember, LDAPAddMember >> and LDAPRemoveMember >> (Providing support for objects with 'member'-like attributes.) >> - LDAPSearch implicit exit code changed to 1 when nothing is found > > Why the switch to ONELEVEL as the scope? Otherwise looks ok. I don't remember the situation exactly, but I had the parent (container) entry returned by some search commands. Normally, it should never happen since the search filter includes object classes, but I accidentally left it there and it doesn't hurt anything (at least for now). > > rob > Pavel From pzuna at redhat.com Tue Aug 4 15:23:08 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 04 Aug 2009 17:23:08 +0200 Subject: [Freeipa-devel] [PATCH] Rewrite pwpolicy plugin based on baseldap.py. In-Reply-To: <4A7339B4.7090907@redhat.com> References: <4A731B56.7060408@redhat.com> <4A7339B4.7090907@redhat.com> Message-ID: <4A78525C.9090104@redhat.com> Rob Crittenden wrote: > Pavel Z?na wrote: >> Fix bugs: 510740, 510739, 510735, 510733, 510532 >> >> Pavel > > A couple of issues with the max values. I checked DS and I think the > maxes should shadow it. > > krbpwdhistorylength: 24 > krbpwdmindiffchars: 6 Ok, I picked most of the max values at random. I'm changing history length max to 24, but I left mindiffchars at 5, because according to `man kpasswd` there's only 5 different character classes. > > And I have some further questions for the team. > > Do we want to limit password validity to 1 year max? Do we need a limit > at all other than maxInt? > > Is 30 big enough for a password? > > This doesn't seem to enforce that maxlife > minlife. It does now. :) > rob > Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Rewrite-pwpolicy-plugin-based-on-baseldap.py.patch Type: application/mbox Size: 6256 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 4 16:32:12 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 04 Aug 2009 18:32:12 +0200 Subject: [Freeipa-devel] [PATCH] Add wrapping when printing multi-value attributes that don't fit on one line. Message-ID: <4A78628C.8050804@redhat.com> This is how it looks like in practice: ./ipa user-show pzuna --all --raw ---------- user-show: ---------- ... memberof: cn=ipausers,cn=groups,cn=accounts,dc=pzuna, cn=dr??ci,cn=groups,cn=accounts,dc=pzuna objectclass: top, person, organizationalPerson, inetOrgPerson, inetUser, posixAccount, krbPrincipalAux, radiusprofile The wrapping works the same way as textui.print_paragraph does - it depends on terminal settings. When priting to file, the line is considered infinite. (Although redirecting output to file doesn't work when there are unicode characters present - an issue I'm currently looking into.) I'm also posting this to Jenny, because this patch changes the output of most ipa plugins. I hope it won't make testing much harder. Anyway if there's a problem I can add an option that would bring back the multi-line output... Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-wraping-when-printing-multi-value-attributes-tha.patch Type: application/mbox Size: 1370 bytes Desc: not available URL: From sgallagh at redhat.com Tue Aug 4 16:49:36 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 04 Aug 2009 12:49:36 -0400 Subject: [Freeipa-devel] Files to builde SSSD package 0.4.1 (not working yet) In-Reply-To: <1249393678.3856.5.camel@crow> References: <1249314518.3646.17.camel@crow> <4A770AB8.3000306@redhat.com> <1249393678.3856.5.camel@crow> Message-ID: <4A7866A0.1050307@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2009 09:47 AM, Miguel P.C. wrote: > Hi Stephen, hola everyone, > > > I'm working with a computer that is not my usual "build computer" so I'm > trying to get all I need installed and give it a try. > Now I'm on holidays so I'm spending as little time on anything that > makes me think as possible. (I need a break, you know!). > Anyway, I'm finding time to finish some little things left from work > this week, as next two I won't have internet access. > I'll try to give you a bit of a report on how sssd builds on Karmic B4 > friday (... if possible). > > BTW I'll use SSSD HEAD and Karmic with the latest updates. Is that OK? > > M* > Yeah, that's preferable. As I've said, we want to support Ubuntu with the 0.5.0 release. We're not really planning to attempt to get 0.4.1 to work (too much has changed/improved since then that it would be difficult and backwards to try and work from there) > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4ZpsACgkQeiVVYja6o6NuUACdGau8cwzuBW+ywLAL3qpJGQmB ALIAnjALFwb5L9oPuhwlFR23RczoEJWI =A6O+ -----END PGP SIGNATURE----- From ssorce at redhat.com Tue Aug 4 16:54:09 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Aug 2009 12:54:09 -0400 Subject: [Freeipa-devel] PATCH: fix race condition in ldap driver Message-ID: <1249404849.3316.6.camel@localhost.localdomain> Jenny found that on her machine a race condition could prevent operation to happen in the right order. Interestingly this never happened on my machine that has a somewhat higher latency vs the ldap server. This patch simply serializes handling replies from ldap using a store and forward technique. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-race-condition-in-sdap-code.patch Type: application/mbox Size: 29297 bytes Desc: not available URL: From pzuna at redhat.com Tue Aug 4 16:55:11 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Tue, 04 Aug 2009 18:55:11 +0200 Subject: [Freeipa-devel] [PATCH] Add option in baseldap classes to display unaltered LDAP entries. Message-ID: <4A7867EF.8010607@redhat.com> The option in question is '--raw'. In the future all plugins (extending classes in baseldap) will have 2 types of output - one "human-readable" and one "raw" (as stored in LDAP). It's going to look something like this: # ./ipa user-show pzuna --all ---------- user-show: ---------- User: pzuna user id: pzuna full name: Pavel Z?na first name: Pavel last name: Z?na home directory: /home/pzuna login shell: /bin/sh uid number: 1224 gid number: 1002 gecos: pzuna kerberos principal: pzuna at PZUNA member of groups: ipausers, dr??ci # ./ipa user-show pzuna --all --raw ---------- user-show: ---------- dn: uid=pzuna,cn=users,cn=accounts,dc=pzuna uid: pzuna cn: Pavel Z?na givenname: Pavel sn: Z?na homedirectory: /home/pzuna loginshell: /bin/sh uidnumber: 1224 gidnumber: 1002 gecos: pzuna krbprincipalname: pzuna at PZUNA memberof: cn=ipausers,cn=groups,cn=accounts,dc=pzuna, cn=dr??ci,cn=groups,cn=accounts,dc=pzuna objectclass: top, person, organizationalPerson, inetOrgPerson, inetUser, posixAccount, krbPrincipalAux, radiusprofile I'm also thinking about removing the text surrounded with --------- with the "raw" option. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-options-in-baseldap-classes-to-display-unaltered.patch Type: application/mbox Size: 5675 bytes Desc: not available URL: From sgallagh at redhat.com Tue Aug 4 17:41:59 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 04 Aug 2009 13:41:59 -0400 Subject: [Freeipa-devel] PATCH: fix race condition in ldap driver In-Reply-To: <1249404849.3316.6.camel@localhost.localdomain> References: <1249404849.3316.6.camel@localhost.localdomain> Message-ID: <4A7872E7.3050800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2009 12:54 PM, Simo Sorce wrote: > Jenny found that on her machine a race condition could prevent operation > to happen in the right order. > Interestingly this never happened on my machine that has a somewhat > higher latency vs the ldap server. > > This patch simply serializes handling replies from ldap using a store > and forward technique. > > Simo. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack and pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4cuAACgkQeiVVYja6o6PozwCfZseaaFZ0pqhdFmdvx0ju9X8Y +3AAnjsOppLvmJ1hgcRR8VTn1B8CMJ0P =QuMU -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Aug 4 19:17:45 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 04 Aug 2009 15:17:45 -0400 Subject: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names In-Reply-To: <4A745EDE.5080601@redhat.com> References: <4A745EDE.5080601@redhat.com> Message-ID: <4A788959.7090900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/2009 11:27 AM, Jakub Hrozek wrote: > Hello, > Attached are two patches that allow the tools to operate on fully > qualified names, that is, names in the form of user at DOMAIN. > > [PATCH 1/2] Move parsing of names and domains into util/ > I used the already existing facility for parsing names from the > responder. This patch moves it into util/ for general consumption. > > [PATCH 2/2] Parse fully qualified names in tools > Allow adding users into different domains not only by specifying > ID directly but also by specifying fully qualified name. Exit when > both specifications are used in conflict. > > Thanks, > Jakub > Patch 1: Ack. Patch 2: Nack. In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c: if (data->domain && data->uid && data->domain != dom) { should be data->gid instead. - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4iVMACgkQeiVVYja6o6PuCACdFPR0VlvjIhhkAY5ORtxMlGnl X2IAni33p4SF6L2IcKbv1j8eMveJZ6eG =DU86 -----END PGP SIGNATURE----- From kwade at redhat.com Tue Aug 4 21:58:24 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 4 Aug 2009 14:58:24 -0700 Subject: [Freeipa-devel] contribution policy update, what's next Message-ID: <20090804215824.GC7063@calliope.phig.org> Yesterday I lurked on a call with Stephen Gallagher and Richard Fontana, legal expert on FLOSS licensing. Due to audio problems, I wasn't able to fully participate, but I did hear an implicit agreement to the contribution policy draft I wrote up. I think it may need a few tweaks; I'm going to propose some and get Richard back on the phone to get an explicit OK from him. Stephen -- since SSSD has it's own upstream space, do you want me to work up a draft contribution policy for there? That is, I know your licensing questions are still open, but we can get a draft with alternate endings depending on potential outcomes. == What's next == With the CLA requirement removed, next I have to enumerate exactly where it stands as a barrier and figure out how to remove it. There are some other technological barriers to reconsider. For any system we require a CLA for e.g. fedorahosted.org access, that is just a human check process, right? We remove the CLA requirement when considering people for SCM access. For patches, we need to figure out how to structure it so that people can contribute patches via this list with it clear the patch is submitted under the contribution policy. Perhaps a single sentence + URL at the beginning of each patch email? It seems to me we could also have people add themselves to a list via the wiki (history proves the real user did it), and if you are on there, you don't need to include the sentence in your patches. Obviously a better solution is needed, meaning we need to run our own directory or rely more upon an external (e.g. Fedora Account System). We might be able to get by with OpenID, for example. For the wiki, we can remove the human requirement, but we still have a technical barrier for entry. It would be smoothest if people could: 1. Sign up for an account 2. In that sign-up they read the contribution policy and agree to it as part of signing up 3. They get wiki edit access All automatic with no human intervention required. Figuring out solutions there is my next important task once we have a solid contribution policy to refer to. Meanwhile, if we can widen the field of people with "Create wiki users upon request", that would be good. I volunteer. Maybe for now an email request for access to a freeipa-* list would suffice? - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nkinder at redhat.com Wed Aug 5 00:52:24 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 04 Aug 2009 17:52:24 -0700 Subject: [Freeipa-devel] [PATCH] Add wrapping when printing multi-value attributes that don't fit on one line. In-Reply-To: <4A78628C.8050804@redhat.com> References: <4A78628C.8050804@redhat.com> Message-ID: <4A78D7C8.3010608@redhat.com> On 08/04/2009 09:32 AM, Pavel Zuna wrote: > This is how it looks like in practice: > > ./ipa user-show pzuna --all --raw > ---------- > user-show: > ---------- > ... > memberof: cn=ipausers,cn=groups,cn=accounts,dc=pzuna, > cn=dr??ci,cn=groups,cn=accounts,dc=pzuna For an attribute that uses the Distinguished Name syntax, such as memberOf, it may be difficult to read if the values are separated by commas and on the same line. This would especially be the case if the value has a space in it, which your example above doesn't illustrate. > objectclass: top, person, organizationalPerson, inetOrgPerson, > inetUser, posixAccount, krbPrincipalAux, > radiusprofile > > The wrapping works the same way as textui.print_paragraph does - it > depends on terminal settings. When priting to file, the line is > considered infinite. (Although redirecting output to file doesn't work > when there are unicode characters present - an issue I'm currently > looking into.) > > I'm also posting this to Jenny, because this patch changes the output > of most ipa plugins. I hope it won't make testing much harder. Anyway > if there's a problem I can add an option that would bring back the > multi-line output... > > Pavel > ------------------------------------------------------------------------ > > _______________________________________________ > 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 pzuna at redhat.com Wed Aug 5 08:16:54 2009 From: pzuna at redhat.com (=?UTF-8?B?UGF2ZWwgWsWvbmE=?=) Date: Wed, 05 Aug 2009 10:16:54 +0200 Subject: [Freeipa-devel] [PATCH] Add wrapping when printing multi-value attributes that don't fit on one line. In-Reply-To: <4A78D7C8.3010608@redhat.com> References: <4A78628C.8050804@redhat.com> <4A78D7C8.3010608@redhat.com> Message-ID: <4A793FF6.4080605@redhat.com> Nathan Kinder wrote: > On 08/04/2009 09:32 AM, Pavel Zuna wrote: >> This is how it looks like in practice: >> >> ./ipa user-show pzuna --all --raw >> ---------- >> user-show: >> ---------- >> ... >> memberof: cn=ipausers,cn=groups,cn=accounts,dc=pzuna, >> cn=dr??ci,cn=groups,cn=accounts,dc=pzuna > For an attribute that uses the Distinguished Name syntax, such as > memberOf, it may be difficult to read if the values are separated by > commas and on the same line. This would especially be the case if the > value has a space in it, which your example above doesn't illustrate. True, I'm thinking about making the raw option use the good ol' multi-line output. Without --raw there's no DNs displayed and I think it's more practical to have several values on one line. Let's say we have a group with (only) 100 members => 100 lines just to print them. >> objectclass: top, person, organizationalPerson, inetOrgPerson, >> inetUser, posixAccount, krbPrincipalAux, >> radiusprofile >> >> The wrapping works the same way as textui.print_paragraph does - it >> depends on terminal settings. When priting to file, the line is >> considered infinite. (Although redirecting output to file doesn't work >> when there are unicode characters present - an issue I'm currently >> looking into.) >> >> I'm also posting this to Jenny, because this patch changes the output >> of most ipa plugins. I hope it won't make testing much harder. Anyway >> if there's a problem I can add an option that would bring back the >> multi-line output... Pavel From jhrozek at redhat.com Wed Aug 5 08:51:11 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 05 Aug 2009 10:51:11 +0200 Subject: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names In-Reply-To: <4A788959.7090900@redhat.com> References: <4A745EDE.5080601@redhat.com> <4A788959.7090900@redhat.com> Message-ID: <4A7947FF.6030506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2009 09:17 PM, Stephen Gallagher wrote: > Patch 1: Ack. > > Patch 2: Nack. > In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c: > if (data->domain && data->uid && data->domain != dom) { > should be data->gid instead. Thanks, I really need an editor plugin that will give me an electric shock anytime I copy-n-paste code.. New patches attached. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5R/8ACgkQHsardTLnvCU5xgCeM0ey/LeZ2fxkogi+QiobgVt9 HagAnRUMGanbaG1et+lPQEihGet77F3b =Y9fF -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Move-parsing-of-names-and-domains-into-util.patch Type: text/x-patch Size: 9413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Parse-fully-qualified-names-in-tools.patch Type: text/x-patch Size: 23968 bytes Desc: not available URL: From sgallagh at redhat.com Wed Aug 5 11:50:12 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 07:50:12 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <20090804215824.GC7063@calliope.phig.org> References: <20090804215824.GC7063@calliope.phig.org> Message-ID: <4A7971F4.2050606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2009 05:58 PM, Karsten Wade wrote: > Yesterday I lurked on a call with Stephen Gallagher and Richard > Fontana, legal expert on FLOSS licensing. > > Due to audio problems, I wasn't able to fully participate, but I did > hear an implicit agreement to the contribution policy draft I wrote > up. > > I think it may need a few tweaks; I'm going to propose some and get > Richard back on the phone to get an explicit OK from him. > > Stephen -- since SSSD has it's own upstream space, do you want me to > work up a draft contribution policy for there? That is, I know your > licensing questions are still open, but we can get a draft with > alternate endings depending on potential outcomes. > Yes, that would be a good next step. > == What's next == > > With the CLA requirement removed, next I have to enumerate exactly > where it stands as a barrier and figure out how to remove it. There > are some other technological barriers to reconsider. > > For any system we require a CLA for e.g. fedorahosted.org access, that > is just a human check process, right? We remove the CLA requirement > when considering people for SCM access. > > For patches, we need to figure out how to structure it so that people > can contribute patches via this list with it clear the patch is > submitted under the contribution policy. Perhaps a single sentence + > URL at the beginning of each patch email? It seems to me we could > also have people add themselves to a list via the wiki (history proves > the real user did it), and if you are on there, you don't need to > include the sentence in your patches. Obviously a better solution is > needed, meaning we need to run our own directory or rely more upon an > external (e.g. Fedora Account System). We might be able to get by > with OpenID, for example. Editing the SSSD wiki already requires a Fedora account, so if we go with the "adding your name to a wiki page" idea, I think that's probably completely sufficient. On the other hand, having a Fedora account already implies that you have signed the Fedora CLA. > > For the wiki, we can remove the human requirement, but we still have a > technical barrier for entry. It would be smoothest if people could: > > 1. Sign up for an account > 2. In that sign-up they read the contribution policy and agree to it > as part of signing up > 3. They get wiki edit access > > All automatic with no human intervention required. > > Figuring out solutions there is my next important task once we have a > solid contribution policy to refer to. > > Meanwhile, if we can widen the field of people with "Create wiki users > upon request", that would be good. I volunteer. Maybe for now an > email request for access to a freeipa-* list would suffice? > > - Karsten > Our present wiki comes to us through the Fedorahosted servers, and as such relies on the users having a Fedora account themselves. Do you feel that this restriction is to severe? > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5cfAACgkQeiVVYja6o6Mm7ACgnl2VCh61h6aTb/KrRFJxHlfO ttwAniGdVQruGif/D0lfVwyaPOj/OUS5 =ZFt7 -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 12:03:47 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 08:03:47 -0400 Subject: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names In-Reply-To: <4A7947FF.6030506@redhat.com> References: <4A745EDE.5080601@redhat.com> <4A788959.7090900@redhat.com> <4A7947FF.6030506@redhat.com> Message-ID: <4A797523.3010109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/05/2009 04:51 AM, Jakub Hrozek wrote: > On 08/04/2009 09:17 PM, Stephen Gallagher wrote: >> Patch 1: Ack. > >> Patch 2: Nack. >> In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c: >> if (data->domain && data->uid && data->domain != dom) { >> should be data->gid instead. > > Thanks, I really need an editor plugin that will give me an electric > shock anytime I copy-n-paste code.. > > New patches attached. > > Jakub Ack. - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5dR8ACgkQeiVVYja6o6OHhQCdGjEnAhY8xug8ILQemkgm7n8X KcAAoJdITm9UhWvuEqaXEY4lDD3Xcb7i =VsSW -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 12:07:11 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 08:07:11 -0400 Subject: [Freeipa-devel] [PATCH] Consolidate tevent helpers In-Reply-To: <4A76FCAF.2080703@redhat.com> References: <4A76FCAF.2080703@redhat.com> Message-ID: <4A7975EF.5070501@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 11:05 AM, Jakub Hrozek wrote: > We use several macros that substitute tevent functions not available in > the current F11 release. The attached patch just moves these definitions > to one place in util/util.h to avoid unnecessary duplication. > > Jakub > Looks fine to me. Ack. - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5de8ACgkQeiVVYja6o6O7GwCfap/oC4x3Rq59UTrIx4EoL+Aw boAAniEfs9wZPq6QxvMIIUItbgsfzu4v =QfXk -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Aug 5 12:52:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Aug 2009 08:52:20 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <4A7971F4.2050606@redhat.com> References: <20090804215824.GC7063@calliope.phig.org> <4A7971F4.2050606@redhat.com> Message-ID: <4A798084.70504@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/04/2009 05:58 PM, Karsten Wade wrote: >> Yesterday I lurked on a call with Stephen Gallagher and Richard >> Fontana, legal expert on FLOSS licensing. >> >> Due to audio problems, I wasn't able to fully participate, but I did >> hear an implicit agreement to the contribution policy draft I wrote >> up. >> >> I think it may need a few tweaks; I'm going to propose some and get >> Richard back on the phone to get an explicit OK from him. >> >> Stephen -- since SSSD has it's own upstream space, do you want me to >> work up a draft contribution policy for there? That is, I know your >> licensing questions are still open, but we can get a draft with >> alternate endings depending on potential outcomes. >> > > Yes, that would be a good next step. > >> == What's next == >> >> With the CLA requirement removed, next I have to enumerate exactly >> where it stands as a barrier and figure out how to remove it. There >> are some other technological barriers to reconsider. >> >> For any system we require a CLA for e.g. fedorahosted.org access, that >> is just a human check process, right? We remove the CLA requirement >> when considering people for SCM access. >> >> For patches, we need to figure out how to structure it so that people >> can contribute patches via this list with it clear the patch is >> submitted under the contribution policy. Perhaps a single sentence + >> URL at the beginning of each patch email? It seems to me we could >> also have people add themselves to a list via the wiki (history proves >> the real user did it), and if you are on there, you don't need to >> include the sentence in your patches. Obviously a better solution is >> needed, meaning we need to run our own directory or rely more upon an >> external (e.g. Fedora Account System). We might be able to get by >> with OpenID, for example. > > Editing the SSSD wiki already requires a Fedora account, so if we go > with the "adding your name to a wiki page" idea, I think that's probably > completely sufficient. On the other hand, having a Fedora account > already implies that you have signed the Fedora CLA. > >> For the wiki, we can remove the human requirement, but we still have a >> technical barrier for entry. It would be smoothest if people could: >> >> 1. Sign up for an account >> 2. In that sign-up they read the contribution policy and agree to it >> as part of signing up >> 3. They get wiki edit access >> >> All automatic with no human intervention required. >> >> Figuring out solutions there is my next important task once we have a >> solid contribution policy to refer to. >> >> Meanwhile, if we can widen the field of people with "Create wiki users >> upon request", that would be good. I volunteer. Maybe for now an >> email request for access to a freeipa-* list would suffice? >> >> - Karsten >> > > Our present wiki comes to us through the Fedorahosted servers, and as > such relies on the users having a Fedora account themselves. Do you feel > that this restriction is to severe? > I think he's referring to the freeIPA wiki. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Aug 5 13:21:18 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Aug 2009 09:21:18 -0400 Subject: [Freeipa-devel] Re: [PATCH] Add option in baseldap classes to display unaltered LDAP entries. In-Reply-To: <4A7867EF.8010607@redhat.com> References: <4A7867EF.8010607@redhat.com> Message-ID: <4A79874E.1070903@redhat.com> Pavel Zuna wrote: > The option in question is '--raw'. > > In the future all plugins (extending classes in baseldap) will have 2 > types of output - one "human-readable" and one "raw" (as stored in LDAP). > > It's going to look something like this: > > # ./ipa user-show pzuna --all > ---------- > user-show: > ---------- > User: pzuna > user id: pzuna > full name: Pavel Z?na > first name: Pavel > last name: Z?na > home directory: /home/pzuna > login shell: /bin/sh > uid number: 1224 > gid number: 1002 > gecos: pzuna > kerberos principal: pzuna at PZUNA > member of groups: ipausers, dr??ci > > # ./ipa user-show pzuna --all --raw > ---------- > user-show: > ---------- > dn: uid=pzuna,cn=users,cn=accounts,dc=pzuna > uid: pzuna > cn: Pavel Z?na > givenname: Pavel > sn: Z?na > homedirectory: /home/pzuna > loginshell: /bin/sh > uidnumber: 1224 > gidnumber: 1002 > gecos: pzuna > krbprincipalname: pzuna at PZUNA > memberof: cn=ipausers,cn=groups,cn=accounts,dc=pzuna, > cn=dr??ci,cn=groups,cn=accounts,dc=pzuna > objectclass: top, person, organizationalPerson, inetOrgPerson, > inetUser, posixAccount, krbPrincipalAux, radiusprofile > > I'm also thinking about removing the text surrounded with --------- with > the "raw" option. > > Pavel ack, pushed to master. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Wed Aug 5 13:30:13 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Wed, 05 Aug 2009 15:30:13 +0200 Subject: [Freeipa-devel] [PATCH] jderose 015 Remove PluginProxy In-Reply-To: <1249376075.5191.29.camel@jgd-flap> References: <1249376075.5191.29.camel@jgd-flap> Message-ID: <4A798965.4080109@redhat.com> Jason Gerard DeRose wrote: > For the UI work I needed to stop wrapping commands in PluginProxy so I > can check if a command is an instance of crud.Create, crud.Retrieve, and > so on. Plus, PluginProxy just wasn't as good an idea as I first > thought. ;) > > This patch removes the PluginProxy class and all it's uses. Looks and works great - no more workarounds required. :) ack! Pavel From sgallagh at redhat.com Wed Aug 5 13:43:40 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 09:43:40 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A76C51C.705@redhat.com> References: <4A76C51C.705@redhat.com> Message-ID: <4A798C8C.4040509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 07:08 AM, Jakub Hrozek wrote: > The attached patch addresses ticket #84. > > The implementation is unfortunately Linux-specific as it uses the > prctl(2) syscall. Ideas how to accomplish this in a cross-platform > manner are welcome. > > Jakub Nack. Why are you creating a new configure test for prctl? Just change AC_CHECK_FUNCS(sigprocmask sigblock sigaction getpgrp) to AC_CHECK_FUNCS(sigprocmask sigblock sigaction getpgrp prctl) The effect is identical. (It produces HAVE_PRCTL in config.h) - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jIgACgkQeiVVYja6o6PK+wCfadFuewMcWcdZWyXhdQ20gyvC X0QAoKQSZ+2OJ2lXsI57vLJn61iRSphs =WKik -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 13:48:38 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 09:48:38 -0400 Subject: [Freeipa-devel] [PATCH] Fix adding to groups on user creation In-Reply-To: <4A771D15.2020504@redhat.com> References: <4A771D15.2020504@redhat.com> Message-ID: <4A798DB6.9000907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 01:23 PM, Jakub Hrozek wrote: > Fixes a copy-paste error that prevented the -G/--groups parameter of > useradd from working. > > Jakub Ack - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jbYACgkQeiVVYja6o6PumgCdHEPGxSWt0urnBQGyoNJVbZvn +wIAoIn8HRscXsO7g7TCGxtDYKCxOT/1 =aT79 -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 13:50:54 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 09:50:54 -0400 Subject: [Freeipa-devel] [PATCH] Fix typo in function call in pamsrv_cmd.c In-Reply-To: <4A781FD9.6070901@redhat.com> References: <4A781FD9.6070901@redhat.com> Message-ID: <4A798E3E.1060700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/04/2009 07:47 AM, Jakub Hrozek wrote: > I was looking into how negative cache is implemented and used in sssd > and spotted a typo in function call name that would break compilation if > HAVE_NEG_CACHE was defined. > > Jakub Nack. This code will all be changing soon, and this may not actually be a typo. - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jj4ACgkQeiVVYja6o6PmdwCdGrQeiB+PAvNDQR7/nhMK03uD pZcAoJhNLXuDvQ76pKCyqgUlB8Bs1whU =Yged -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 14:24:59 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 10:24:59 -0400 Subject: [Freeipa-devel] [PATCH] Consolidate tevent helpers] Message-ID: <4A79963B.6050406@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 11:05 AM, Jakub Hrozek wrote: > We use several macros that substitute tevent functions not available in > the current F11 release. The attached patch just moves these definitions > to one place in util/util.h to avoid unnecessary duplication. > > Jakub > - ------------------------------------------------------------------------ Pushed to master - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5ljsACgkQeiVVYja6o6OSbwCfdY0tCVDTamx6HuVm/8AF8Pg/ LckAn3NsMqiRRkfsI9N8SewAYZSO8XEg =zknU -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 14:25:29 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 10:25:29 -0400 Subject: [Freeipa-devel] [PATCH] Fix adding to groups on user creation Message-ID: <4A799659.3090107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2009 01:23 PM, Jakub Hrozek wrote: > Fixes a copy-paste error that prevented the -G/--groups parameter of > useradd from working. > > Jakub - ------------------------------------------------------------------------ Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5llkACgkQeiVVYja6o6PoDQCglrLPEpuxOGICzegeaBKu9xEH IIMAmQGJDHwXw6CBDECTr/zdhmr09rf+ =ryPh -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Aug 5 14:25:50 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 10:25:50 -0400 Subject: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names Message-ID: <4A79966E.9090908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/05/2009 04:51 AM, Jakub Hrozek wrote: > On 08/04/2009 09:17 PM, Stephen Gallagher wrote: >> Patch 1: Ack. > >> Patch 2: Nack. >> In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c: >> if (data->domain && data->uid && data->domain != dom) { >> should be data->gid instead. > > Thanks, I really need an editor plugin that will give me an electric > shock anytime I copy-n-paste code.. > > New patches attached. > > Jakub Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5lm0ACgkQeiVVYja6o6MMPwCeOgvh8mmh/jxGDMM2VoTS/+xo pNwAoKuTD+mDxputCGVferhvA1FwG7Un =aclU -----END PGP SIGNATURE----- From mpcolino at gmail.com Wed Aug 5 14:30:03 2009 From: mpcolino at gmail.com (Miguel P.C.) Date: Wed, 05 Aug 2009 16:30:03 +0200 Subject: [Freeipa-devel] Building SSSD HEAD in Karmic (updated 2009.08.04) In-Reply-To: <1249393678.3856.5.camel@crow> References: <1249314518.3646.17.camel@crow> <4A770AB8.3000306@redhat.com> <1249393678.3856.5.camel@crow> Message-ID: <1249482603.3891.37.camel@crow> Hola everyone. Hi Stephen, > Yeah, that's preferable. As I've said, we want to support Ubuntu with > the 0.5.0 release. We're not really planning to attempt to get 0.4.1 to > work (too much has changed/improved since then that it would be > difficult and backwards to try and work from there) I'm building SSSD in Karmic as I said, and I stopped updating the system and SSSD on 2009.08.04 to have a homogeneus These are the Deps that I needed to install (plus their own deps) in order to build SSSD: * libtalloc-dev * tdb-dev * libtevent-dev * libldb-dev * cvs * libpopt-dev * libpam-dev * libldap2-dev * libpcre3-dev * krb5-config * libkrb5-dev * libc-ares-dev * libdbus-1-dev * libnss3-dev I attach the logs as appeared on screen while building SSSD. Logs attached are the last ones after getting to the next part. Configure was launched with the following options: ./configure --prefix=/opt/sssd | tee ../configure.10.log When running make I found an error related to LDAP. [snip] providers/ldap/ldap_id.c: In function ?sdap_id_connect_send?: providers/ldap/ldap_id.c:145: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:145: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?sdap_id_connect_done?: providers/ldap/ldap_id.c:172: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:172: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?users_get_send?: providers/ldap/ldap_id.c:291: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:291: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:304: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:304: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?users_get_connect_done?: providers/ldap/ldap_id.c:337: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:337: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?groups_get_send?: providers/ldap/ldap_id.c:448: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:448: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:461: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:461: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?groups_get_connect_done?: providers/ldap/ldap_id.c:494: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:494: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?groups_by_user_send?: providers/ldap/ldap_id.c:580: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:580: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:593: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:593: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?groups_by_user_connect_done?: providers/ldap/ldap_id.c:626: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:626: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c: In function ?sdap_get_account_info?: providers/ldap/ldap_id.c:696: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:696: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:711: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:711: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:737: error: dereferencing pointer to incomplete type providers/ldap/ldap_id.c:737: error: dereferencing pointer to incomplete type make[3]: *** [providers/ldap/libsss_ldap_la-ldap_id.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[3]: se sale del directorio `/home/migpc/Temporal/sssd/server' make[2]: se sale del directorio `/home/migpc/Temporal/sssd/server' make[1]: *** [all] Error 2 make[1]: se sale del directorio `/home/migpc/Temporal/sssd/server' make: *** [all-recursive] Error 1 [snip] Now I have to go. If you want me to send any other info, I'll probably be able to do so on friday. CU M* -------------- next part -------------- A non-text attachment was scrubbed... Name: SSSD_Karmic_build_logs.tar.bz2 Type: application/x-bzip-compressed-tar Size: 8029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From ssorce at redhat.com Wed Aug 5 16:03:01 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Aug 2009 12:03:01 -0400 Subject: [Freeipa-devel] New List: sssd development moves Message-ID: <1249488181.3075.15.camel@localhost.localdomain> Hello Freeipa and sssd developers and followers, we've decided to move sssd development to its own mailing list so that freeipa proper development and sssd are not intermixed. sssd is not simply a component of Freeipa although it will be a key piece of the client functionality, sssd works on its own in contexts that do not involve Freeipa servers. So to avoid confusion and to let the 2 projects have a better mail flow we decided to create a development list for sssd at: sssd-devel at list.fedorahosted.org If you are interested in following sssd development we advice you to subscribe to this new list. Any new patch review and sssd related discussion will be moved to this new list starting now. Have fun, Simo. From sgallagh at redhat.com Wed Aug 5 16:07:12 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 05 Aug 2009 12:07:12 -0400 Subject: [Freeipa-devel] New List: sssd development moves In-Reply-To: <1249488181.3075.15.camel@localhost.localdomain> References: <1249488181.3075.15.camel@localhost.localdomain> Message-ID: <4A79AE30.80303@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/05/2009 12:03 PM, Simo Sorce wrote: > Hello Freeipa and sssd developers and followers, > we've decided to move sssd development to its own mailing list so that > freeipa proper development and sssd are not intermixed. > > sssd is not simply a component of Freeipa although it will be a key > piece of the client functionality, sssd works on its own in contexts > that do not involve Freeipa servers. > So to avoid confusion and to let the 2 projects have a better mail flow > we decided to create a development list for sssd at: > sssd-devel at list.fedorahosted.org > > If you are interested in following sssd development we advice you to > subscribe to this new list. > > Any new patch review and sssd related discussion will be moved to this > new list starting now. > > Have fun, > Simo. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Correction: the list is at sssd-devel at lists.fedorahosted.org (note the plural lists) You can subscribe here: https://fedorahosted.org/mailman/listinfo/sssd-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5risACgkQeiVVYja6o6PXJgCgoyeh7zXKzCANXxjKr1GeA7cp cHYAoKuD5UZ06cx2hzeIB95zCeba/00g =wo+D -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Aug 5 16:19:05 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Aug 2009 12:19:05 -0400 Subject: [Freeipa-devel] [PATCH] jderose 015 Remove PluginProxy In-Reply-To: <4A798965.4080109@redhat.com> References: <1249376075.5191.29.camel@jgd-flap> <4A798965.4080109@redhat.com> Message-ID: <4A79B0F9.1020305@redhat.com> Pavel Zuna wrote: > Jason Gerard DeRose wrote: >> For the UI work I needed to stop wrapping commands in PluginProxy so I >> can check if a command is an instance of crud.Create, crud.Retrieve, and >> so on. Plus, PluginProxy just wasn't as good an idea as I first >> thought. ;) >> >> This patch removes the PluginProxy class and all it's uses. > Looks and works great - no more workarounds required. :) ack! > > Pavel pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jhrozek at redhat.com Wed Aug 5 16:20:06 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 05 Aug 2009 18:20:06 +0200 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A798C8C.4040509@redhat.com> References: <4A76C51C.705@redhat.com> <4A798C8C.4040509@redhat.com> Message-ID: <4A79B136.5060602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/05/2009 03:43 PM, Stephen Gallagher wrote: > Nack. > > Why are you creating a new configure test for prctl? Just change > AC_CHECK_FUNCS(sigprocmask sigblock sigaction getpgrp) > to > AC_CHECK_FUNCS(sigprocmask sigblock sigaction getpgrp prctl) > > The effect is identical. (It produces HAVE_PRCTL in config.h) True, fixed patch attached. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5sTYACgkQHsardTLnvCWEygCfXbon/1FxxnFlrUL9O3jc+dJT ZiUAn3VfL0g1bljktIN3GnDNkC2fQrro =OQEv -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-child-processes-exit-when-parent-dies.patch Type: text/x-patch Size: 5095 bytes Desc: not available URL: From dpal at redhat.com Wed Aug 5 22:25:48 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 05 Aug 2009 18:25:48 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A76C51C.705@redhat.com> References: <4A76C51C.705@redhat.com> Message-ID: <4A7A06EC.4050207@redhat.com> Jakub Hrozek wrote: > The attached patch addresses ticket #84. > > The implementation is unfortunately Linux-specific as it uses the > prctl(2) syscall. Ideas how to accomplish this in a cross-platform > manner are welcome. > > Jakub How do we fork processes? If we just fork and do not daemonize then children should just die (system sends sigterm to children AFAIR) when the parent process exits. At least that is what used to happen in old days on Solaris, HP and AIX. If we fork and then make the process a new process group leader by using setpgrp() then it terns into a service. It PPID becomes 1 (AFAIR - have done it many years ago). If our children are independent processes there is no good way other than pass in the IP of the parent at the initialization and periodically check if the process is still around and its start time is before child's. If the problem we are trying to solve is to exit back ends when monitor dies we should either keep the children as members of the same group or use the periodic check approach. ------------------------- _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Aug 6 09:53:35 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Aug 2009 05:53:35 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A7A06EC.4050207@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> Message-ID: <1249552415.6387.22.camel@localhost.localdomain> On Wed, 2009-08-05 at 18:25 -0400, Dmitri Pal wrote: > Jakub Hrozek wrote: > > The attached patch addresses ticket #84. > > > > The implementation is unfortunately Linux-specific as it uses the > > prctl(2) syscall. Ideas how to accomplish this in a cross-platform > > manner are welcome. > > > > Jakub > How do we fork processes? > If we just fork and do not daemonize then children should just die > (system sends sigterm to children AFAIR) when the parent process exits. > At least that is what used to happen in old days on Solaris, HP and AIX. > If we fork and then make the process a new process group leader by using > setpgrp() then it terns into a service. It PPID becomes 1 (AFAIR - have > done it many years ago). > If our children are independent processes there is no good way other > than pass in the IP of the parent at the initialization and periodically > check if the process is still around and its start time is before child's. > > If the problem we are trying to solve is to exit back ends when monitor > dies we should either keep the children as members of the same group or > use the periodic check approach. I have to say I am a bit surprised about this patch too. Last time I put my hands on it we were using process groups exactly so that when monitor is killed all other process die as well. In my experience this works fine in master. In what cases do this fail ? Simo. From sgallagh at redhat.com Thu Aug 6 13:39:21 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 06 Aug 2009 09:39:21 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <1249552415.6387.22.camel@localhost.localdomain> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> Message-ID: <4A7ADD09.7040800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2009 05:53 AM, Simo Sorce wrote: > On Wed, 2009-08-05 at 18:25 -0400, Dmitri Pal wrote: >> Jakub Hrozek wrote: >>> The attached patch addresses ticket #84. >>> >>> The implementation is unfortunately Linux-specific as it uses the >>> prctl(2) syscall. Ideas how to accomplish this in a cross-platform >>> manner are welcome. >>> >>> Jakub >> How do we fork processes? >> If we just fork and do not daemonize then children should just die >> (system sends sigterm to children AFAIR) when the parent process exits. >> At least that is what used to happen in old days on Solaris, HP and AIX. >> If we fork and then make the process a new process group leader by using >> setpgrp() then it terns into a service. It PPID becomes 1 (AFAIR - have >> done it many years ago). >> If our children are independent processes there is no good way other >> than pass in the IP of the parent at the initialization and periodically >> check if the process is still around and its start time is before child's. >> >> If the problem we are trying to solve is to exit back ends when monitor >> dies we should either keep the children as members of the same group or >> use the periodic check approach. > > I have to say I am a bit surprised about this patch too. > Last time I put my hands on it we were using process groups exactly so > that when monitor is killed all other process die as well. In my > experience this works fine in master. In what cases do this fail ? > > Simo. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel In the event that the monitor segfaults or is killed with SIGKILL, it terminates immediately and does not signal the children to exit. That is what this is meant to address. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp63QUACgkQeiVVYja6o6NXsgCeJz2quGG9L6u8yjGJu9UBoodZ sUIAnRf4S1nypddjLUKPBg9JzzwHSOlO =UMKV -----END PGP SIGNATURE----- From jhrozek at redhat.com Thu Aug 6 15:13:05 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 06 Aug 2009 17:13:05 +0200 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <1249552415.6387.22.camel@localhost.localdomain> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> Message-ID: <4A7AF301.3030903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2009 11:53 AM, Simo Sorce wrote: >> How do we fork processes? >> > If we just fork and do not daemonize then children should just die >> > (system sends sigterm to children AFAIR) when the parent process exits. >> > At least that is what used to happen in old days on Solaris, HP and AIX. >> > If we fork and then make the process a new process group leader by using >> > setpgrp() then it terns into a service. It PPID becomes 1 (AFAIR - have >> > done it many years ago). >> > If our children are independent processes there is no good way other >> > than pass in the IP of the parent at the initialization and periodically >> > check if the process is still around and its start time is before child's. >> > >> > If the problem we are trying to solve is to exit back ends when monitor >> > dies we should either keep the children as members of the same group or >> > use the periodic check approach. > > I have to say I am a bit surprised about this patch too. > Last time I put my hands on it we were using process groups exactly so > that when monitor is killed all other process die as well. In my > experience this works fine in master. In what cases do this fail ? > > Simo. > (We discussed this with Simo and Martin on IRC, I'm capturing the discussion also here) The way we use process groups works OK for normal situations - if, for example, the monitor gets SIGTERM from an initscript, it passes it on to its child processes in a signal handler. The patch tries to solve a situation where monitor crashes, either with something like SIGSEGV or the admin kills it with SIGKILL. We could catch most signals the way we do catch SIGTERM and relay them to children. This still wouldn't cover the SIGKILL case where the admin shoots down monitor. This is cross-platform which is of course huge advantage. But in my opinion, we should still use prctl() where available, because it is much cleaner solution -- you don't have to explicitly enumerate all the signals to handle and you can also cover the SIGKILL case. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp68vYACgkQHsardTLnvCUV8wCg5o0BtIGLkiobcBosAxWZhemW pE4AniOJuvKKzt2ErY4OJkoQkRqPaSpX =+x7i -----END PGP SIGNATURE----- From dpal at redhat.com Thu Aug 6 16:55:24 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 06 Aug 2009 12:55:24 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A7AF301.3030903@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> <4A7AF301.3030903@redhat.com> Message-ID: <4A7B0AFC.4050404@redhat.com> Jakub Hrozek wrote: > On 08/06/2009 11:53 AM, Simo Sorce wrote: > >> How do we fork processes? > >>> If we just fork and do not daemonize then children should just die > >>> (system sends sigterm to children AFAIR) when the parent process > exits. > >>> At least that is what used to happen in old days on Solaris, HP > and AIX. > >>> If we fork and then make the process a new process group leader by > using > >>> setpgrp() then it terns into a service. It PPID becomes 1 (AFAIR - > have > >>> done it many years ago). > >>> If our children are independent processes there is no good way other > >>> than pass in the IP of the parent at the initialization and > periodically > >>> check if the process is still around and its start time is before > child's. > >>> > >>> If the problem we are trying to solve is to exit back ends when > monitor > >>> dies we should either keep the children as members of the same > group or > >>> use the periodic check approach. > > I have to say I am a bit surprised about this patch too. > > Last time I put my hands on it we were using process groups exactly so > > that when monitor is killed all other process die as well. In my > > experience this works fine in master. In what cases do this fail ? > > > Simo. > > > (We discussed this with Simo and Martin on IRC, I'm capturing the > discussion also here) > > The way we use process groups works OK for normal situations - if, for > example, the monitor gets SIGTERM from an initscript, it passes it on to > its child processes in a signal handler. The patch tries to solve a > situation where monitor crashes, either with something like SIGSEGV or > the admin kills it with SIGKILL. > > We could catch most signals the way we do catch SIGTERM and relay them > to children. This still wouldn't cover the SIGKILL case where the admin > shoots down monitor. This is cross-platform which is of course huge > advantage. > > But in my opinion, we should still use prctl() where available, because > it is much cleaner solution -- you don't have to explicitly enumerate > all the signals to handle and you can also cover the SIGKILL case. > > Jakub > May be I have false memories but I was under the impression that OS takes care of the orphan children and terminates them automatically by sending them a signal if it detects that parent process goes away. Am I wrong? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sgallagh at redhat.com Thu Aug 6 17:02:27 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 06 Aug 2009 13:02:27 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A7B0AFC.4050404@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> <4A7AF301.3030903@redhat.com> <4A7B0AFC.4050404@redhat.com> Message-ID: <4A7B0CA3.8020900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2009 12:55 PM, Dmitri Pal wrote: > if it detects that parent process goes away. Am I wrong? Yes. Orphan children become children of init instead. This is in fact how daemonizing works. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp7DJ8ACgkQeiVVYja6o6OBvACffsiv8YjXvB/tEQ804VZY3a2B kgUAn0qdM4X84Ix3WxgC9XfJFjt498bt =IFJL -----END PGP SIGNATURE----- From kwade at redhat.com Fri Aug 7 16:54:36 2009 From: kwade at redhat.com (Karsten Wade) Date: Fri, 7 Aug 2009 09:54:36 -0700 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <4A7971F4.2050606@redhat.com> References: <20090804215824.GC7063@calliope.phig.org> <4A7971F4.2050606@redhat.com> Message-ID: <20090807165436.GH11443@calliope.phig.org> On Wed, Aug 05, 2009 at 07:50:12AM -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/04/2009 05:58 PM, Karsten Wade wrote: > > Yesterday I lurked on a call with Stephen Gallagher and Richard > > Stephen -- since SSSD has it's own upstream space, do you want me to > > work up a draft contribution policy for there? That is, I know your > > licensing questions are still open, but we can get a draft with > > alternate endings depending on potential outcomes. > > > > Yes, that would be a good next step. OK, I'll propose it to sssd-devel so the discussion sticks with the active developers. > Editing the SSSD wiki already requires a Fedora account, so if we go > with the "adding your name to a wiki page" idea, I think that's probably > completely sufficient. On the other hand, having a Fedora account > already implies that you have signed the Fedora CLA. Actually, the Fedora account system (FAS) only requires username, real name, email address, and a check for "I am 13 years of age or older." This is why Fedora Hosted works as a true upstream hosting solution. Your contributor policy is entirely in your project's hands. In a different scenario, if SSSD were to have it's own, stand-alone CLA, we could create an 'sssd_cla' group in FAS. People who had signed the SSSD CLA would be added to that group, and not even need to be in the Fedora Project CLA group 'cla_done'. Back to this scenario, if we have a clear contribution policy page on the wiki, that could cover the wiki potentially. In MediaWiki, you can change the template for the content that appears in 'edit page' mode. In the Fedora wiki, it reaffirms that the content is covered by the CLA. In Wikipedia, the wording is very similar to that of the FreeIPA contrib policy I wrote up; I borrowed liberally. :) > Our present wiki comes to us through the Fedorahosted servers, and as > such relies on the users having a Fedora account themselves. Do you feel > that this restriction is to severe? The only potential barrier is mental. Interestingly, this is the third or so conversation I've had in the last few days where folks thought Fedora Hosted required a Fedora CLA - we may need to do some marketing fixing there. :) As long as SSSD participants know the facts, it should be an appropriate restriction, IMO. - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Fri Aug 7 16:56:41 2009 From: kwade at redhat.com (Karsten Wade) Date: Fri, 7 Aug 2009 09:56:41 -0700 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <4A798084.70504@redhat.com> References: <20090804215824.GC7063@calliope.phig.org> <4A7971F4.2050606@redhat.com> <4A798084.70504@redhat.com> Message-ID: <20090807165641.GI11443@calliope.phig.org> On Wed, Aug 05, 2009 at 08:52:20AM -0400, Rob Crittenden wrote: > Stephen Gallagher wrote: >> >> Our present wiki comes to us through the Fedorahosted servers, and as >> such relies on the users having a Fedora account themselves. Do you feel >> that this restriction is to severe? >> > > I think he's referring to the freeIPA wiki. As a matter of fact, I was. Similar concept might work for the SSSD wiki. Perhaps it's not really a burden to people to include their contribution details with each patch, but it can be a hassle on the wiki. A page of "I agree to the [[Contribution policy]]" would just be for reducing that hassle all around. - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 10 14:41:18 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Aug 2009 10:41:18 -0400 Subject: [Freeipa-devel] [PATCH] 247 Key management schema Message-ID: <4A80318E.2030208@redhat.com> Include schema for key escrow management as defined at https://fedoraproject.org/wiki/Disk_encryption_key_escrow_in_IPA rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-247-keymgmt.patch Type: application/mbox Size: 4967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nswith at gmail.com Mon Aug 10 17:31:55 2009 From: nswith at gmail.com (NWith) Date: Mon, 10 Aug 2009 10:31:55 -0700 Subject: [Freeipa-devel] CRITICAL failed to add Full Principal Sasl mapping Message-ID: Hi Everyone, I'm new to the forums, but I've already searched for my problem and found this page: http://www.redhat.com/archives/freeipa-devel/2008-June/msg00109.html My problem is that I keep getting [1/16]: creating directory server user [2/16]: creating directory server instance [3/16]: adding default schema [4/16]: enabling memberof plugin [5/16]: enabling referential integrity plugin [6/16]: enabling distributed numeric assignment plugin [7/16]: configuring uniqueness plugin [8/16]: creating indices [9/16]: configuring ssl for ds instance [10/16]: configuring certmap.conf [11/16]: restarting directory server [12/16]: adding default layout [13/16]: configuring Posix uid/gid generation as first master [14/16]: adding master entry as first master [15/16]: initializing group membership [16/16]: configuring directory to start on boot done configuring dirsrv. Configuring Kerberos KDC [1/13]: setting KDC account password [2/13]: adding sasl mappings to the directory root : CRITICAL failed to add Full Principal Sasl mapping Unexpected error - see ipaserver-install.log for details: local variable 'e' referenced before assignment So far, I've used CentOS 5.2, RHEL 5, and Fedora 11 on a brand-new, clean virtual machine, but despite following the other methods discussed in the thread, I still come to this error. Can anyone who has experienced (and hopefully solved) this error please point me in the right direction as to what to do? -Nicholas With From rcritten at redhat.com Mon Aug 10 18:08:48 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Aug 2009 14:08:48 -0400 Subject: [Freeipa-devel] CRITICAL failed to add Full Principal Sasl mapping In-Reply-To: References: Message-ID: <4A806230.2040804@redhat.com> NWith wrote: > Hi Everyone, > > I'm new to the forums, but I've already searched for my problem and > found this page: > http://www.redhat.com/archives/freeipa-devel/2008-June/msg00109.html > > My problem is that I keep getting > > [1/16]: creating directory server user > [2/16]: creating directory server instance > [3/16]: adding default schema > [4/16]: enabling memberof plugin > [5/16]: enabling referential integrity plugin > [6/16]: enabling distributed numeric assignment plugin > [7/16]: configuring uniqueness plugin > [8/16]: creating indices > [9/16]: configuring ssl for ds instance > [10/16]: configuring certmap.conf > [11/16]: restarting directory server > [12/16]: adding default layout > [13/16]: configuring Posix uid/gid generation as first master > [14/16]: adding master entry as first master > [15/16]: initializing group membership > [16/16]: configuring directory to start on boot > done configuring dirsrv. > Configuring Kerberos KDC > [1/13]: setting KDC account password > [2/13]: adding sasl mappings to the directory > root : CRITICAL failed to add Full Principal Sasl mapping > Unexpected error - see ipaserver-install.log for details: > local variable 'e' referenced before assignment > > So far, I've used CentOS 5.2, RHEL 5, and Fedora 11 on a brand-new, > clean virtual machine, but despite following the other methods > discussed in the thread, I still > come to this error. Can anyone who has experienced (and hopefully > solved) this error please point me in the right direction as to what > to do? Look in /var/log/ipaserver-install.log for more details. The error message you're seeing is because there appears to be a bug in it trying to report the actual failure. In other words, the installer failed for some reason and because of a bug isn't really giving you the right reason. The install log should have the details we need. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dmalcolm at redhat.com Mon Aug 10 18:13:24 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 10 Aug 2009 14:13:24 -0400 Subject: [Freeipa-devel] CRITICAL failed to add Full Principal Sasl mapping In-Reply-To: <4A806230.2040804@redhat.com> References: <4A806230.2040804@redhat.com> Message-ID: <1249928004.22896.109.camel@radiator.bos.redhat.com> On Mon, 2009-08-10 at 14:08 -0400, Rob Crittenden wrote: > NWith wrote: > > Hi Everyone, > > > > I'm new to the forums, but I've already searched for my problem and > > found this page: > > http://www.redhat.com/archives/freeipa-devel/2008-June/msg00109.html > > > > My problem is that I keep getting > > > > [1/16]: creating directory server user > > [2/16]: creating directory server instance > > [3/16]: adding default schema > > [4/16]: enabling memberof plugin > > [5/16]: enabling referential integrity plugin > > [6/16]: enabling distributed numeric assignment plugin > > [7/16]: configuring uniqueness plugin > > [8/16]: creating indices > > [9/16]: configuring ssl for ds instance > > [10/16]: configuring certmap.conf > > [11/16]: restarting directory server > > [12/16]: adding default layout > > [13/16]: configuring Posix uid/gid generation as first master > > [14/16]: adding master entry as first master > > [15/16]: initializing group membership > > [16/16]: configuring directory to start on boot > > done configuring dirsrv. > > Configuring Kerberos KDC > > [1/13]: setting KDC account password > > [2/13]: adding sasl mappings to the directory > > root : CRITICAL failed to add Full Principal Sasl mapping > > Unexpected error - see ipaserver-install.log for details: > > local variable 'e' referenced before assignment > > > > So far, I've used CentOS 5.2, RHEL 5, and Fedora 11 on a brand-new, > > clean virtual machine, but despite following the other methods > > discussed in the thread, I still > > come to this error. Can anyone who has experienced (and hopefully > > solved) this error please point me in the right direction as to what > > to do? > > Look in /var/log/ipaserver-install.log for more details. The error > message you're seeing is because there appears to be a bug in it trying > to report the actual failure. In other words, the installer failed for > some reason and because of a bug isn't really giving you the right > reason. The install log should have the details we need. > Couple of random thoughts from a lurker: (i) does freeipa upstream run pylint or pychecker e.g. during the rpmbuild process? That might help catch this kind of issue. (ii) have you looked at "python-meh"? it's a Python module for submitting bug reports from Python exceptions, originally written for Anaconda: http://git.fedoraproject.org/git/python-meh.git Hope this is helpful; I'll go back to lurking now :-) Dave From rcritten at redhat.com Mon Aug 10 20:30:09 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Aug 2009 16:30:09 -0400 Subject: [Freeipa-devel] [PATCH] 248 add ipaObject and require more object types to have a UUID Message-ID: <4A808351.2030505@redhat.com> Add a new objectclass, ipaObject, that will add a UUID to many IPA objects. ipaObject is defined as an auxiliary objectclass so it is up to the plugin author to ensure that the objectclass is included an a UUID generated. ipaUniqueId is a MUST attribute so if you include the objectclass you must ensure that the uuid is generated. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-248-object.patch Type: application/mbox Size: 19295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Mon Aug 10 23:01:41 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 10 Aug 2009 17:01:41 -0600 Subject: [Freeipa-devel] [PATCH] 247 Key management schema In-Reply-To: <4A80318E.2030208@redhat.com> References: <4A80318E.2030208@redhat.com> Message-ID: <1249945301.7228.0.camel@jgd-flap> On Mon, 2009-08-10 at 10:41 -0400, Rob Crittenden wrote: > Include schema for key escrow management as defined at > https://fedoraproject.org/wiki/Disk_encryption_key_escrow_in_IPA > > rob ack. pushed to master. From jderose at redhat.com Mon Aug 10 23:01:57 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 10 Aug 2009 17:01:57 -0600 Subject: [Freeipa-devel] [PATCH] 248 add ipaObject and require more object types to have a UUID In-Reply-To: <4A808351.2030505@redhat.com> References: <4A808351.2030505@redhat.com> Message-ID: <1249945318.7228.1.camel@jgd-flap> On Mon, 2009-08-10 at 16:30 -0400, Rob Crittenden wrote: > Add a new objectclass, ipaObject, that will add a UUID to many IPA objects. > > ipaObject is defined as an auxiliary objectclass so it is up to the > plugin author to ensure that the objectclass is included an a UUID > generated. ipaUniqueId is a MUST attribute so if you include the > objectclass you must ensure that the uuid is generated. > > > rob ack. pushed to master. From ssorce at redhat.com Tue Aug 11 11:40:29 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 11 Aug 2009 07:40:29 -0400 Subject: [Freeipa-devel] [PATCH] Use correct return codes In-Reply-To: <4A71D1E6.40500@redhat.com> References: <4A71CF34.1030402@redhat.com> <4A71D1E6.40500@redhat.com> Message-ID: <1249990829.3922.48.camel@localhost.localdomain> On Thu, 2009-07-30 at 13:01 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/30/2009 12:49 PM, Jakub Hrozek wrote: > > A copy-paste-error caused that some code paths which should exit with an > > error used potentionally incorrect return code. > > > > Jakub > > > > Ack For the record, this patch was also pushed. Simo. From jhrozek at redhat.com Tue Aug 11 14:44:32 2009 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 11 Aug 2009 16:44:32 +0200 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A7AF301.3030903@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> <4A7AF301.3030903@redhat.com> Message-ID: <4A8183D0.30307@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2009 05:13 PM, Jakub Hrozek wrote: > We could catch most signals the way we do catch SIGTERM and relay them > to children. This still wouldn't cover the SIGKILL case where the admin > shoots down monitor. This is cross-platform which is of course huge > advantage. > > But in my opinion, we should still use prctl() where available, because > it is much cleaner solution -- you don't have to explicitly enumerate > all the signals to handle and you can also cover the SIGKILL case. > Attached is a patch that says the same in C. Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBg9AACgkQHsardTLnvCVgbACgiRfGHqtEXzTKw1VO1rk15PJp RYIAoI7c/zqImOxM5g9GgBlRfmF+m+UN =2z7H -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-child-processes-exit-when-parent-dies.patch Type: text/x-patch Size: 5988 bytes Desc: not available URL: From sgallagh at redhat.com Tue Aug 11 15:43:07 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 11 Aug 2009 11:43:07 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A8183D0.30307@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> <4A7AF301.3030903@redhat.com> <4A8183D0.30307@redhat.com> Message-ID: <4A81918B.7080505@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2009 10:44 AM, Jakub Hrozek wrote: > On 08/06/2009 05:13 PM, Jakub Hrozek wrote: >> We could catch most signals the way we do catch SIGTERM and relay them >> to children. This still wouldn't cover the SIGKILL case where the admin >> shoots down monitor. This is cross-platform which is of course huge >> advantage. > >> But in my opinion, we should still use prctl() where available, because >> it is much cleaner solution -- you don't have to explicitly enumerate >> all the signals to handle and you can also cover the SIGKILL case. > > > Attached is a patch that says the same in C. > > Jakub Ack - ------------------------------------------------------------------------ _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBkYcACgkQeiVVYja6o6Nw2wCfe1mA+9hzZbsbDOdQqj/0K64S SwMAn0+X7+blI3d/WcFEQ7KYh94ccGg0 =ITeU -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Aug 11 16:32:34 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 11 Aug 2009 12:32:34 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A81918B.7080505@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> <4A7AF301.3030903@redhat.com> <4A8183D0.30307@redhat.com> <4A81918B.7080505@redhat.com> Message-ID: <4A819D22.3040806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2009 11:43 AM, Stephen Gallagher wrote: > On 08/11/2009 10:44 AM, Jakub Hrozek wrote: >> On 08/06/2009 05:13 PM, Jakub Hrozek wrote: >>> We could catch most signals the way we do catch SIGTERM and relay them >>> to children. This still wouldn't cover the SIGKILL case where the admin >>> shoots down monitor. This is cross-platform which is of course huge >>> advantage. >>> But in my opinion, we should still use prctl() where available, because >>> it is much cleaner solution -- you don't have to explicitly enumerate >>> all the signals to handle and you can also cover the SIGKILL case. > >> Attached is a patch that says the same in C. > >> Jakub > > Ack > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Pushed to master. _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBnSIACgkQeiVVYja6o6N3dgCfUYdGUV63W9BBBkeoZH+CRQb8 hJIAn1SPtm0KuDu27Gx+4UJUFV6jyXve =+GZt -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Aug 11 16:56:10 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Aug 2009 12:56:10 -0400 Subject: [Freeipa-devel] [PATCH] 249 host enrollment Message-ID: <4A81A2AA.2070401@redhat.com> This largish patch adds host enrollment. There are several scenarios that are covered. All of these assume that the IPA client machine has already been set up (ipa-client-install): 1. Full admin enrollment. This will create the host entry, a host/ service principal and a keytab for that principal in /etc/krb5.keytab. 2. Junior admin enrollment. There are lots of levels of delegation possible here, but at a minimum they would be able to enroll an existing host by creating the service principal and keytab. Additional rights such as adding a host could be added as well. 3. Bulk enrollment. If a host entry is pre-created by another admin and it contains an enrollment password (in the userPassword attribute) then an LDAP-based enrollment can take place. The client binds as the host and generates a keytab for itself. One really significant change is I've switch to openldap as the LDAP client. Doing SSL with mozldap would have required a significant amount of more code (because we can't assume there is already an NSS db lying around that trusts the IPA CA). I didn't completely disable the mozldap option but by default things will build with openldap now. This also adds a first pass at Get Effective Rights support. This is so we can know in advance if an operation would succeed and makes things generally nicer. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-249-join.patch Type: application/mbox Size: 83390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Aug 11 17:06:41 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 11 Aug 2009 13:06:41 -0400 Subject: [Freeipa-devel] [PATCH] Make child processes exit when parent dies In-Reply-To: <4A8183D0.30307@redhat.com> References: <4A76C51C.705@redhat.com> <4A7A06EC.4050207@redhat.com> <1249552415.6387.22.camel@localhost.localdomain> <4A7AF301.3030903@redhat.com> <4A8183D0.30307@redhat.com> Message-ID: <1250010401.3922.80.camel@localhost.localdomain> In general patch is fine, just a minor nitpick on the following bit of code. On Tue, 2009-08-11 at 16:44 +0200, Jakub Hrozek wrote: > > +int die_if_parent_died(void) > +{ > +#ifdef HAVE_PRCTL > + int ret; > + > + errno = 0; > + ret = prctl(PR_SET_PDEATHSIG, SIGTERM, 0, 0, 0); > + if (ret != 0) { > + ret = errno; > + DEBUG(2, ("prctl failed [%d]: %s", ret, strerror(ret))); > + return ret; > + } > +#endif > + return EOK; > +} > + When the whole function have a different behavior depending on an #ifdef I very much prefer an approach like the following: #ifdef HAVE_PRCTL int die_if_parent_died(void) { return EOK; } #else int die_if_parent_died(void) { DEBUG(1, ("PRCTL Unsupported on this platform\n!")); return EOK; } #endif Simo. From dpal at redhat.com Tue Aug 11 17:11:33 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 11 Aug 2009 13:11:33 -0400 Subject: [Freeipa-devel] [PATCH] 249 host enrollment In-Reply-To: <4A81A2AA.2070401@redhat.com> References: <4A81A2AA.2070401@redhat.com> Message-ID: <4A81A645.7060400@redhat.com> Rob Crittenden wrote: > This largish patch adds host enrollment. There are several scenarios > that are covered. All of these assume that the IPA client machine has > already been set up (ipa-client-install): > Does ipa-client-install bring admin utils? What is its purpose? I though the sequence of operations would be somewhat (do not look at the names, I do not expect them to be exactly as I put them): yum install ipa-client-enrollment ipa-enroll ... The enroll will also do some configuration as it used to do in v1 but other than that I expected the mentioned sequence. I scanned quickly through the patch but was not able to see whether things work as I expect or not. > 1. Full admin enrollment. This will create the host entry, a host/ > service principal and a keytab for that principal in /etc/krb5.keytab. > > 2. Junior admin enrollment. There are lots of levels of delegation > possible here, but at a minimum they would be able to enroll an > existing host by creating the service principal and keytab. Additional > rights such as adding a host could be added as well. > > 3. Bulk enrollment. If a host entry is pre-created by another admin > and it contains an enrollment password (in the userPassword attribute) > then an LDAP-based enrollment can take place. The client binds as the > host and generates a keytab for itself. > > One really significant change is I've switch to openldap as the LDAP > client. Doing SSL with mozldap would have required a significant > amount of more code (because we can't assume there is already an NSS > db lying around that trusts the IPA CA). > > I didn't completely disable the mozldap option but by default things > will build with openldap now. > > This also adds a first pass at Get Effective Rights support. This is > so we can know in advance if an operation would succeed and makes > things generally nicer. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jgalipea at redhat.com Tue Aug 11 17:16:20 2009 From: jgalipea at redhat.com (Jenny Galipeau) Date: Tue, 11 Aug 2009 13:16:20 -0400 Subject: [Freeipa-devel] [PATCH] 249 host enrollment In-Reply-To: <4A81A2AA.2070401@redhat.com> References: <4A81A2AA.2070401@redhat.com> Message-ID: <4A81A764.3020009@redhat.com> Hey Rob: I'll probably be writing a test plan and automating this soon. Can you direct me to all available design, configuration, implementation documentation for host enrollment and the join utility? This is all I have right now ... https://wiki.idm.lab.bos.redhat.com/export/idmwiki/images/1/11/Machine_Authentication_Usage_Scenarios_rev3.pdf Thanks Jenny Rob Crittenden wrote: > This largish patch adds host enrollment. There are several scenarios > that are covered. All of these assume that the IPA client machine has > already been set up (ipa-client-install): > > 1. Full admin enrollment. This will create the host entry, a host/ > service principal and a keytab for that principal in /etc/krb5.keytab. > > 2. Junior admin enrollment. There are lots of levels of delegation > possible here, but at a minimum they would be able to enroll an > existing host by creating the service principal and keytab. Additional > rights such as adding a host could be added as well. > > 3. Bulk enrollment. If a host entry is pre-created by another admin > and it contains an enrollment password (in the userPassword attribute) > then an LDAP-based enrollment can take place. The client binds as the > host and generates a keytab for itself. > > One really significant change is I've switch to openldap as the LDAP > client. Doing SSL with mozldap would have required a significant > amount of more code (because we can't assume there is already an NSS > db lying around that trusts the IPA CA). > > I didn't completely disable the mozldap option but by default things > will build with openldap now. > > This also adds a first pass at Get Effective Rights support. This is > so we can know in advance if an operation would succeed and makes > things generally nicer. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering From rcritten at redhat.com Tue Aug 11 17:16:26 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Aug 2009 13:16:26 -0400 Subject: [Freeipa-devel] [PATCH] 249 host enrollment In-Reply-To: <4A81A645.7060400@redhat.com> References: <4A81A2AA.2070401@redhat.com> <4A81A645.7060400@redhat.com> Message-ID: <4A81A76A.2030104@redhat.com> Dmitri Pal wrote: > Rob Crittenden wrote: >> This largish patch adds host enrollment. There are several scenarios >> that are covered. All of these assume that the IPA client machine has >> already been set up (ipa-client-install): >> > Does ipa-client-install bring admin utils? > What is its purpose? It configures the machine to be an IPA client. It configures nss_ldap, etc. It also creates some configuration files we need such as what IPA server to talk to and the CA cert for that server. > I though the sequence of operations would be somewhat (do not look at > the names, I do not expect them to be exactly as I put them): > yum install ipa-client-enrollment > ipa-enroll ... > > The enroll will also do some configuration as it used to do in v1 but > other than that I expected the mentioned sequence. > I scanned quickly through the patch but was not able to see whether > things work as I expect or not. I did this as a separate step. It can be included in the ipa-client-install sequence though it currently is not. > >> 1. Full admin enrollment. This will create the host entry, a host/ >> service principal and a keytab for that principal in /etc/krb5.keytab. >> >> 2. Junior admin enrollment. There are lots of levels of delegation >> possible here, but at a minimum they would be able to enroll an >> existing host by creating the service principal and keytab. Additional >> rights such as adding a host could be added as well. >> >> 3. Bulk enrollment. If a host entry is pre-created by another admin >> and it contains an enrollment password (in the userPassword attribute) >> then an LDAP-based enrollment can take place. The client binds as the >> host and generates a keytab for itself. >> >> One really significant change is I've switch to openldap as the LDAP >> client. Doing SSL with mozldap would have required a significant >> amount of more code (because we can't assume there is already an NSS >> db lying around that trusts the IPA CA). >> >> I didn't completely disable the mozldap option but by default things >> will build with openldap now. >> >> This also adds a first pass at Get Effective Rights support. This is >> so we can know in advance if an operation would succeed and makes >> things generally nicer. >> >> rob >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Tue Aug 11 18:33:57 2009 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 11 Aug 2009 14:33:57 -0400 Subject: [Freeipa-devel] [PATCH] 249 host enrollment In-Reply-To: <4A81A76A.2030104@redhat.com> References: <4A81A2AA.2070401@redhat.com> <4A81A645.7060400@redhat.com> <4A81A76A.2030104@redhat.com> Message-ID: <4A81B995.6030406@redhat.com> >> Does ipa-client-install bring admin utils? >> What is its purpose? > > It configures the machine to be an IPA client. It configures nss_ldap, > etc. It also creates some configuration files we need such as what IPA > server to talk to and the CA cert for that server. > >> I though the sequence of operations would be somewhat (do not look at >> the names, I do not expect them to be exactly as I put them): >> yum install ipa-client-enrollment >> ipa-enroll ... >> >> The enroll will also do some configuration as it used to do in v1 but >> other than that I expected the mentioned sequence. >> I scanned quickly through the patch but was not able to see whether >> things work as I expect or not. > > I did this as a separate step. It can be included in the > ipa-client-install sequence though it currently is not. IMO the logic should be a bit reverse. The enrollment script should invoke the old IPA client installation script (somewhere at the beginning of the enrollment process) internally if SSSD is not detected. If SSSD is detected it should configure IPA back end as a part of the enrollment and not touch nss_ldap in this case. Optionally we probably can configure automount or some other maps (but I am not sure that was/is a requirement at the moment). -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Aug 11 19:01:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Aug 2009 15:01:22 -0400 Subject: [Freeipa-devel] [PATCH] 249 host enrollment In-Reply-To: <4A81B995.6030406@redhat.com> References: <4A81A2AA.2070401@redhat.com> <4A81A645.7060400@redhat.com> <4A81A76A.2030104@redhat.com> <4A81B995.6030406@redhat.com> Message-ID: <4A81C002.6000800@redhat.com> Dmitri Pal wrote: >>> Does ipa-client-install bring admin utils? >>> What is its purpose? >> It configures the machine to be an IPA client. It configures nss_ldap, >> etc. It also creates some configuration files we need such as what IPA >> server to talk to and the CA cert for that server. >> >>> I though the sequence of operations would be somewhat (do not look at >>> the names, I do not expect them to be exactly as I put them): >>> yum install ipa-client-enrollment >>> ipa-enroll ... >>> >>> The enroll will also do some configuration as it used to do in v1 but >>> other than that I expected the mentioned sequence. >>> I scanned quickly through the patch but was not able to see whether >>> things work as I expect or not. >> I did this as a separate step. It can be included in the >> ipa-client-install sequence though it currently is not. > > IMO the logic should be a bit reverse. The enrollment script should > invoke the old IPA client installation script (somewhere at the > beginning of the enrollment process) internally if SSSD is not detected. > If SSSD is detected it should configure IPA back end as a part of the > enrollment and not touch nss_ldap in this case. Optionally we probably > can configure automount or some other maps (but I am not sure that > was/is a requirement at the moment). > This patch covers just host enrollment, no other settings. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Aug 11 21:12:49 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 11 Aug 2009 17:12:49 -0400 Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors Message-ID: <4A81DED1.8040601@redhat.com> Taking David Malcolm's advice I ran pylint and pychecker against a lot of the IPA code. Much of what it turned up was warnings/complaints about variable names, minor formatting, things like that. But it did also turn up a few bugs (using undefined exceptions, some references to non-existent variables, etc). There are still a lot of places where we shadow built-in functions (filter is a common one). I see this as a first-pass at it. I'll consider trying to come up with a config file we can pass to this so we can do some sort of 'make check' to catch errors. Right now the output is so copious it is difficult to tell wheat from chaff without reading carefully. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-250-lint.patch Type: application/mbox Size: 23115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dmalcolm at redhat.com Tue Aug 11 21:22:51 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 11 Aug 2009 17:22:51 -0400 Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors In-Reply-To: <4A81DED1.8040601@redhat.com> References: <4A81DED1.8040601@redhat.com> Message-ID: <1250025771.1052.22.camel@radiator.bos.redhat.com> On Tue, 2009-08-11 at 17:12 -0400, Rob Crittenden wrote: > Taking David Malcolm's advice I ran pylint and pychecker against a lot > of the IPA code. Much of what it turned up was warnings/complaints about > variable names, minor formatting, things like that. But it did also turn > up a few bugs (using undefined exceptions, some references to > non-existent variables, etc). > > There are still a lot of places where we shadow built-in functions > (filter is a common one). I see this as a first-pass at it. > > I'll consider trying to come up with a config file we can pass to this > so we can do some sort of 'make check' to catch errors. Right now the > output is so copious it is difficult to tell wheat from chaff without > reading carefully. In case this is helpful, in another project, I had something like this in the specfile (having created a pylintrc to suppress the various warnings that I felt weren't important within that code)... %define use_pylint 1 %if %{use_pylint} BuildRequires: pylint %endif and within the %build section: %if %{use_pylint} # Run pylint. Halt the build if there are errors # There doesn't seem to be a good way to get the result of pylint as an # exit code. (upstream bug: http://www.logilab.org/ticket/4691 ) # Capture the output: pylint --rcfile=pylintrc . > pylint.log # Ensure the pylint log makes it to the rpm build log: cat pylint.log # Analyse the "Messages by category" part of the report, looking for # non-zero results: # The table should look like this: # +-----------+-------+---------+-----------+ # |type |number |previous |difference | # +===========+=======+=========+===========+ # |convention |0 |0 |= | # +-----------+-------+---------+-----------+ # |refactor |0 |0 |= | # +-----------+-------+---------+-----------+ # |warning |0 |0 |= | # +-----------+-------+---------+-----------+ # |error |0 |0 |= | # +-----------+-------+---------+-----------+ # # Halt the build if any are non-zero: grep -E "^\|convention[ ]*\|0[ ]*\|" pylint.log || exit 1 grep -E "^\|refactor[ ]*\|0[ ]*\|" pylint.log || exit 1 grep -E "^\|warning[ ]*\|0[ ]*\|" pylint.log || exit 1 grep -E "^\|error[ ]*\|0[ ]*\|" pylint.log || exit 1 %endif (Suggestions for improvements welcome) From mnagy at redhat.com Wed Aug 12 06:17:13 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 12 Aug 2009 02:17:13 -0400 (EDT) Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors In-Reply-To: <4A81DED1.8040601@redhat.com> Message-ID: <936144118.1806301250057833094.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> ----- Original Message ----- From: "Rob Crittenden" To: "freeipa-devel" Sent: Tuesday, August 11, 2009 11:12:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors Taking David Malcolm's advice I ran pylint and pychecker against a lot of the IPA code. Much of what it turned up was warnings/complaints about variable names, minor formatting, things like that. But it did also turn up a few bugs (using undefined exceptions, some references to non-existent variables, etc). There are still a lot of places where we shadow built-in functions (filter is a common one). I see this as a first-pass at it. I'll consider trying to come up with a config file we can pass to this so we can do some sort of 'make check' to catch errors. Right now the output is so copious it is difficult to tell wheat from chaff without reading carefully. rob Ack. Martin From rcritten at redhat.com Wed Aug 12 14:31:57 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Aug 2009 10:31:57 -0400 Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors In-Reply-To: <1250025771.1052.22.camel@radiator.bos.redhat.com> References: <4A81DED1.8040601@redhat.com> <1250025771.1052.22.camel@radiator.bos.redhat.com> Message-ID: <4A82D25D.5070602@redhat.com> David Malcolm wrote: > On Tue, 2009-08-11 at 17:12 -0400, Rob Crittenden wrote: >> Taking David Malcolm's advice I ran pylint and pychecker against a lot >> of the IPA code. Much of what it turned up was warnings/complaints about >> variable names, minor formatting, things like that. But it did also turn >> up a few bugs (using undefined exceptions, some references to >> non-existent variables, etc). >> >> There are still a lot of places where we shadow built-in functions >> (filter is a common one). I see this as a first-pass at it. >> >> I'll consider trying to come up with a config file we can pass to this >> so we can do some sort of 'make check' to catch errors. Right now the >> output is so copious it is difficult to tell wheat from chaff without >> reading carefully. > > In case this is helpful, in another project, I had something like this > in the specfile (having created a pylintrc to suppress the various > warnings that I felt weren't important within that code)... > > > > %define use_pylint 1 > > %if %{use_pylint} > BuildRequires: pylint > %endif > > > and within the %build section: > > %if %{use_pylint} > # Run pylint. Halt the build if there are errors > # There doesn't seem to be a good way to get the result of pylint as an > # exit code. (upstream bug: http://www.logilab.org/ticket/4691 ) > > # Capture the output: > pylint --rcfile=pylintrc . > pylint.log > > # Ensure the pylint log makes it to the rpm build log: > cat pylint.log > > # Analyse the "Messages by category" part of the report, looking for > # non-zero results: > # The table should look like this: > # +-----------+-------+---------+-----------+ > # |type |number |previous |difference | > # +===========+=======+=========+===========+ > # |convention |0 |0 |= | > # +-----------+-------+---------+-----------+ > # |refactor |0 |0 |= | > # +-----------+-------+---------+-----------+ > # |warning |0 |0 |= | > # +-----------+-------+---------+-----------+ > # |error |0 |0 |= | > # +-----------+-------+---------+-----------+ > # > # Halt the build if any are non-zero: > grep -E "^\|convention[ ]*\|0[ ]*\|" pylint.log || exit 1 > grep -E "^\|refactor[ ]*\|0[ ]*\|" pylint.log || exit 1 > grep -E "^\|warning[ ]*\|0[ ]*\|" pylint.log || exit 1 > grep -E "^\|error[ ]*\|0[ ]*\|" pylint.log || exit 1 > %endif > > > (Suggestions for improvements welcome) > I was wondering if pylint -e would be enough for automated tools. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dmalcolm at redhat.com Wed Aug 12 14:31:50 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 12 Aug 2009 10:31:50 -0400 Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors In-Reply-To: <4A82D25D.5070602@redhat.com> References: <4A81DED1.8040601@redhat.com> <1250025771.1052.22.camel@radiator.bos.redhat.com> <4A82D25D.5070602@redhat.com> Message-ID: <1250087510.1052.56.camel@radiator.bos.redhat.com> On Wed, 2009-08-12 at 10:31 -0400, Rob Crittenden wrote: > David Malcolm wrote: > > On Tue, 2009-08-11 at 17:12 -0400, Rob Crittenden wrote: [snip] > > # There doesn't seem to be a good way to get the result of pylint as > an > > # exit code. (upstream bug: http://www.logilab.org/ticket/4691 ) > > [snip] > I was wondering if pylint -e would be enough for automated tools. IIRC it always exits with exit code 0, so it's hard to autodetect success vs failure from the invoking script. I may be wrong though. From rcritten at redhat.com Wed Aug 12 17:16:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Aug 2009 13:16:59 -0400 Subject: [Freeipa-devel] [PATCH] 251 additional pylint fixes Message-ID: <4A82F90B.8090809@redhat.com> I fixed a few more issues discovered by pylint. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-251-lint.patch Type: application/mbox Size: 6989 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Aug 12 17:23:34 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Aug 2009 13:23:34 -0400 Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors In-Reply-To: <936144118.1806301250057833094.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> References: <936144118.1806301250057833094.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Message-ID: <4A82FA96.2080209@redhat.com> Martin Nagy wrote: > ----- Original Message ----- > From: "Rob Crittenden" > To: "freeipa-devel" > Sent: Tuesday, August 11, 2009 11:12:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: [Freeipa-devel] [PATCH] 250 fix some pylint/pychecker errors > > Taking David Malcolm's advice I ran pylint and pychecker against a lot > of the IPA code. Much of what it turned up was warnings/complaints about > variable names, minor formatting, things like that. But it did also turn > up a few bugs (using undefined exceptions, some references to > non-existent variables, etc). > > There are still a lot of places where we shadow built-in functions > (filter is a common one). I see this as a first-pass at it. > > I'll consider trying to come up with a config file we can pass to this > so we can do some sort of 'make check' to catch errors. Right now the > output is so copious it is difficult to tell wheat from chaff without > reading carefully. > > rob > > Ack. > Martin thanks, pushed to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Thu Aug 13 08:28:57 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 13 Aug 2009 10:28:57 +0200 Subject: [Freeipa-devel] [PATCH] 251 additional pylint fixes In-Reply-To: <4A82F90B.8090809@redhat.com> References: <4A82F90B.8090809@redhat.com> Message-ID: <1250152137.22905.15.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-08-12 at 13:16 -0400, Rob Crittenden wrote: > I fixed a few more issues discovered by pylint. > > rob [snip] --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -605,10 +605,11 @@ def user_input_path(prompt, default = None, allow_empty = True): prompt += " (enter \"none\" for empty)" while True: ret = user_input(prompt, default, allow_empty) - if allow_empty and ret.lower() == "none": - return "" - if ipavalidate.Path(ret, not allow_empty): - return ret + if isinstance(ret, basestring): + if allow_empty and ret.lower() == "none": + return "" + if ipavalidate.Path(ret, not allow_empty): + return ret I don't like this piece. The return of user_input() should always be a string unless the default parameter of user_input_path() is a bool or int. Assert at the beginning of user_input_path() would be better. But anyway, it seems we don't use this function anyway (probably after we changed to the plug-in framework), so I'd vote to completely remove it instead. Martin From rcritten at redhat.com Thu Aug 13 13:27:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Aug 2009 09:27:01 -0400 Subject: [Freeipa-devel] [PATCH] 251 additional pylint fixes In-Reply-To: <1250152137.22905.15.camel@wolverine.englab.brq.redhat.com> References: <4A82F90B.8090809@redhat.com> <1250152137.22905.15.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A8414A5.8020603@redhat.com> Martin Nagy wrote: > On Wed, 2009-08-12 at 13:16 -0400, Rob Crittenden wrote: >> I fixed a few more issues discovered by pylint. >> >> rob > > [snip] > --- a/ipapython/ipautil.py > +++ b/ipapython/ipautil.py > @@ -605,10 +605,11 @@ def user_input_path(prompt, default = None, > allow_empty = True): > prompt += " (enter \"none\" for empty)" > while True: > ret = user_input(prompt, default, allow_empty) > - if allow_empty and ret.lower() == "none": > - return "" > - if ipavalidate.Path(ret, not allow_empty): > - return ret > + if isinstance(ret, basestring): > + if allow_empty and ret.lower() == "none": > + return "" > + if ipavalidate.Path(ret, not allow_empty): > + return ret > > I don't like this piece. The return of user_input() should always be a > string unless the default parameter of user_input_path() is a bool or > int. Assert at the beginning of user_input_path() would be better. > > But anyway, it seems we don't use this function anyway (probably after > we changed to the plug-in framework), so I'd vote to completely remove > it instead. > > Martin > Yup, good call. Revised patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-251-2-lint.patch Type: application/mbox Size: 7058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Thu Aug 13 13:46:00 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 13 Aug 2009 15:46:00 +0200 Subject: [Freeipa-devel] [PATCH] 251 additional pylint fixes In-Reply-To: <4A8414A5.8020603@redhat.com> References: <4A82F90B.8090809@redhat.com> <1250152137.22905.15.camel@wolverine.englab.brq.redhat.com> <4A8414A5.8020603@redhat.com> Message-ID: <1250171160.22905.118.camel@wolverine.englab.brq.redhat.com> On Thu, 2009-08-13 at 09:27 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Wed, 2009-08-12 at 13:16 -0400, Rob Crittenden wrote: > >> I fixed a few more issues discovered by pylint. > >> > >> rob > > > > [snip] > > --- a/ipapython/ipautil.py > > +++ b/ipapython/ipautil.py > > @@ -605,10 +605,11 @@ def user_input_path(prompt, default = None, > > allow_empty = True): > > prompt += " (enter \"none\" for empty)" > > while True: > > ret = user_input(prompt, default, allow_empty) > > - if allow_empty and ret.lower() == "none": > > - return "" > > - if ipavalidate.Path(ret, not allow_empty): > > - return ret > > + if isinstance(ret, basestring): > > + if allow_empty and ret.lower() == "none": > > + return "" > > + if ipavalidate.Path(ret, not allow_empty): > > + return ret > > > > I don't like this piece. The return of user_input() should always be a > > string unless the default parameter of user_input_path() is a bool or > > int. Assert at the beginning of user_input_path() would be better. > > > > But anyway, it seems we don't use this function anyway (probably after > > we changed to the plug-in framework), so I'd vote to completely remove > > it instead. > > > > Martin > > > > Yup, good call. Revised patch attached. > > rob Ack. Martin From rcritten at redhat.com Mon Aug 17 13:59:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Aug 2009 09:59:39 -0400 Subject: [Freeipa-devel] [PATCH] 252 Add the CA constraint to the self-signed CA we generate Message-ID: <4A89624B.2080605@redhat.com> This patch is for the ipa-1-2 branch. It adds the CA constraint to the self-signed CA we generate. Otherwise FF 3.5+ won't talk to an IPA-generated web cert. This should resolve bug 514027. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-252-ca.patch Type: application/mbox Size: 2375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Aug 20 13:20:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Aug 2009 09:20:06 -0400 Subject: [Freeipa-devel] [PATCH] 251 additional pylint fixes In-Reply-To: <1250171160.22905.118.camel@wolverine.englab.brq.redhat.com> References: <4A82F90B.8090809@redhat.com> <1250152137.22905.15.camel@wolverine.englab.brq.redhat.com> <4A8414A5.8020603@redhat.com> <1250171160.22905.118.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A8D4D86.5060300@redhat.com> Martin Nagy wrote: > On Thu, 2009-08-13 at 09:27 -0400, Rob Crittenden wrote: >> Martin Nagy wrote: >>> On Wed, 2009-08-12 at 13:16 -0400, Rob Crittenden wrote: >>>> I fixed a few more issues discovered by pylint. >>>> >>>> rob >>> [snip] >>> --- a/ipapython/ipautil.py >>> +++ b/ipapython/ipautil.py >>> @@ -605,10 +605,11 @@ def user_input_path(prompt, default = None, >>> allow_empty = True): >>> prompt += " (enter \"none\" for empty)" >>> while True: >>> ret = user_input(prompt, default, allow_empty) >>> - if allow_empty and ret.lower() == "none": >>> - return "" >>> - if ipavalidate.Path(ret, not allow_empty): >>> - return ret >>> + if isinstance(ret, basestring): >>> + if allow_empty and ret.lower() == "none": >>> + return "" >>> + if ipavalidate.Path(ret, not allow_empty): >>> + return ret >>> >>> I don't like this piece. The return of user_input() should always be a >>> string unless the default parameter of user_input_path() is a bool or >>> int. Assert at the beginning of user_input_path() would be better. >>> >>> But anyway, it seems we don't use this function anyway (probably after >>> we changed to the plug-in framework), so I'd vote to completely remove >>> it instead. >>> >>> Martin >>> >> Yup, good call. Revised patch attached. >> >> rob > > Ack. > Martin > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Aug 20 14:17:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Aug 2009 10:17:06 -0400 Subject: [Freeipa-devel] [PATCH] 253 fix BaseException.message deprecation warning Message-ID: <4A8D5AE2.4020305@redhat.com> Fix a Python 2.6 deprecation warning in the master branch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-253-warning.patch Type: application/mbox Size: 2018 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Thu Aug 20 21:17:57 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Thu, 20 Aug 2009 15:17:57 -0600 Subject: [Freeipa-devel] [PATCH] 253 fix BaseException.message deprecation warning In-Reply-To: <4A8D5AE2.4020305@redhat.com> References: <4A8D5AE2.4020305@redhat.com> Message-ID: <1250803077.2706.1.camel@jgd-flap> On Thu, 2009-08-20 at 10:17 -0400, Rob Crittenden wrote: > Fix a Python 2.6 deprecation warning in the master branch. > > rob ack. pushed to master. From rcritten at redhat.com Thu Aug 20 22:18:10 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Aug 2009 18:18:10 -0400 Subject: [Freeipa-devel] [PATCH] 254 Fix service_mod and add test case Message-ID: <4A8DCBA2.2060100@redhat.com> service_mod wasn't working after being ported to the new ldap module. This fixes it and adds a unit test case. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-254-service.patch Type: application/mbox Size: 2795 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Aug 24 17:44:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Aug 2009 13:44:31 -0400 Subject: [Freeipa-devel] [PATCH] 255 publish CRLs Message-ID: <4A92D17F.3070500@redhat.com> This patch configures the CA to publish CRLs and makes that directory available via Apache so one can retrieve them. The URI will be /ipa/crl/ I made that directory indexable so one can pull delta CRLs or older ones if desired. There is always a symbolic link to the latest named MasterCRL.bin. I had to add some SELinux permissions to let Apache read these files. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-255-crl.patch Type: application/mbox Size: 9101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Aug 24 18:14:12 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Aug 2009 14:14:12 -0400 Subject: [Freeipa-devel] [PATCH] 255 publish CRLs In-Reply-To: <4A92D17F.3070500@redhat.com> References: <4A92D17F.3070500@redhat.com> Message-ID: <1251137652.27952.0.camel@localhost.localdomain> On Mon, 2009-08-24 at 13:44 -0400, Rob Crittenden wrote: > > This patch configures the CA to publish CRLs and makes that directory > available via Apache so one can retrieve them. The URI will > be /ipa/crl/ > > I made that directory indexable so one can pull delta CRLs or older > ones > if desired. There is always a symbolic link to the latest named > MasterCRL.bin. I had to add some SELinux permissions to let Apache > read > these files. ack, awesome and so simple. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Aug 24 18:14:50 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Aug 2009 14:14:50 -0400 Subject: [Freeipa-devel] [PATCH] 254 Fix service_mod and add test case In-Reply-To: <4A8DCBA2.2060100@redhat.com> References: <4A8DCBA2.2060100@redhat.com> Message-ID: <1251137690.27952.1.camel@localhost.localdomain> On Thu, 2009-08-20 at 18:18 -0400, Rob Crittenden wrote: > service_mod wasn't working after being ported to the new ldap module. > This fixes it and adds a unit test case. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Aug 25 20:39:08 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Aug 2009 16:39:08 -0400 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set Message-ID: <4A944BEC.4030409@redhat.com> This adds 2 new options to the installer so the user can select the numeric starting point for uidnumbers and gidnumbers. This also adds a new option to the template system, eval(). You can have the python interpreter evaluate a statement and include the result in the template output. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-256-number.patch Type: application/mbox Size: 7954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Wed Aug 26 06:34:02 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 26 Aug 2009 08:34:02 +0200 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <4A944BEC.4030409@redhat.com> References: <4A944BEC.4030409@redhat.com> Message-ID: <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> On Tue, 2009-08-25 at 16:39 -0400, Rob Crittenden wrote: > This adds 2 new options to the installer so the user can select the > numeric starting point for uidnumbers and gidnumbers. > > This also adds a new option to the template system, eval(). You can have > the python interpreter evaluate a statement and include the result in > the template output. > > rob So, first I see this: > -uidNumber: 999 > -gidNumber: 1001 > +uidNumber: $UIDSTART > +gidNumber: $GIDSTART And then later I see this: > -dnaNextValue: 1100 > +dnaNextValue: eval($UIDSTART+1) [snip] > -dnaNextValue: 1100 > +dnaNextValue: eval($GIDSTART+3) This seems to be inconsistent, is this intentional? More inconsistencies I can see are in the command line option parser where you use 1100 as default for both UIDSTART and GIDSTART. In the man page you state the default is 1000 for both. For the evaluation code, I feel it is a tad more complex than it has to be. Also, the pattern seems to be too greedy. I'd suggest that you use the sub() function instead, here's an example: >>> str = "Something, something, something, eval(foo). Something, something, something, eval(bar)." >>> foo = "dark side" >>> bar = "complete" >>> pattern = re.compile('(eval\s*\(([^)]*)\))') >>> pattern.sub(lambda x: eval(x.group(2)), str) 'Something, something, something, dark side. Something, something, something, complete.' This also allows eval() to work more times on one line (also notice the [^)]* which makes sure we don't accept something like "eval(foo) bar)". I'm also of the opinion that we do abort the installation if the eval() fails, because that would be a clear bug. If we keep it quiet we might see a more cryptic error instead. Martin From rcritten at redhat.com Wed Aug 26 13:29:36 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Aug 2009 09:29:36 -0400 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A9538C0.3090005@redhat.com> Martin Nagy wrote: > On Tue, 2009-08-25 at 16:39 -0400, Rob Crittenden wrote: >> This adds 2 new options to the installer so the user can select the >> numeric starting point for uidnumbers and gidnumbers. >> >> This also adds a new option to the template system, eval(). You can have >> the python interpreter evaluate a statement and include the result in >> the template output. >> >> rob > > So, first I see this: >> -uidNumber: 999 >> -gidNumber: 1001 >> +uidNumber: $UIDSTART >> +gidNumber: $GIDSTART > > And then later I see this: >> -dnaNextValue: 1100 >> +dnaNextValue: eval($UIDSTART+1) Right, $UIDSTART is the uid for the admin user. > [snip] >> -dnaNextValue: 1100 >> +dnaNextValue: eval($GIDSTART+3) $GIDSTART = admins group $GIDSTART+1 = ipauserse group $GIDSTART+2 = editors group So the next available gid is $GIDSTART+3. Now we could leave it as $GIDSTART in the dna config and it would do the right thing at runtime if that would be less confusing. > > This seems to be inconsistent, is this intentional? More inconsistencies > I can see are in the command line option parser where you use 1100 as > default for both UIDSTART and GIDSTART. In the man page you state the > default is 1000 for both. Yeah, that is a goof. It should be 1000. > For the evaluation code, I feel it is a tad more complex than it has to > be. Also, the pattern seems to be too greedy. I'd suggest that you use > the sub() function instead, here's an example: > >>>> str = "Something, something, something, eval(foo). Something, > something, something, eval(bar)." >>>> foo = "dark side" >>>> bar = "complete" >>>> pattern = re.compile('(eval\s*\(([^)]*)\))') >>>> pattern.sub(lambda x: eval(x.group(2)), str) > 'Something, something, something, dark side. Something, something, > something, complete.' > > This also allows eval() to work more times on one line (also notice the > [^)]* which makes sure we don't accept something like "eval(foo) bar)". > I'm also of the opinion that we do abort the installation if the eval() > fails, because that would be a clear bug. If we keep it quiet we might > see a more cryptic error instead. I see what you are getting at but your code doesn't work. It doesn't actually evaluate the lines (I specifically want to do math). I should also note that the re module doesn't count parenthesis so it will almost always not do the right thing with nested parens, this is why I do it line-by-line. Sure, we can quit the install if you'd prefer. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Aug 26 13:51:10 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Aug 2009 09:51:10 -0400 Subject: [Freeipa-devel] [PATCH] 254 Fix service_mod and add test case In-Reply-To: <1251137690.27952.1.camel@localhost.localdomain> References: <4A8DCBA2.2060100@redhat.com> <1251137690.27952.1.camel@localhost.localdomain> Message-ID: <4A953DCE.8030205@redhat.com> Simo Sorce wrote: > On Thu, 2009-08-20 at 18:18 -0400, Rob Crittenden wrote: >> service_mod wasn't working after being ported to the new ldap module. >> This fixes it and adds a unit test case. > > ack > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Aug 26 13:51:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Aug 2009 09:51:22 -0400 Subject: [Freeipa-devel] [PATCH] 255 publish CRLs In-Reply-To: <1251137652.27952.0.camel@localhost.localdomain> References: <4A92D17F.3070500@redhat.com> <1251137652.27952.0.camel@localhost.localdomain> Message-ID: <4A953DDA.6050205@redhat.com> Simo Sorce wrote: > On Mon, 2009-08-24 at 13:44 -0400, Rob Crittenden wrote: >> This patch configures the CA to publish CRLs and makes that directory >> available via Apache so one can retrieve them. The URI will >> be /ipa/crl/ >> >> I made that directory indexable so one can pull delta CRLs or older >> ones >> if desired. There is always a symbolic link to the latest named >> MasterCRL.bin. I had to add some SELinux permissions to let Apache >> read >> these files. > > ack, awesome and so simple. > > Simo. pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Wed Aug 26 14:00:26 2009 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 26 Aug 2009 16:00:26 +0200 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <4A9538C0.3090005@redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> Message-ID: <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-08-26 at 09:29 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Tue, 2009-08-25 at 16:39 -0400, Rob Crittenden wrote: > >> This adds 2 new options to the installer so the user can select the > >> numeric starting point for uidnumbers and gidnumbers. > >> > >> This also adds a new option to the template system, eval(). You can have > >> the python interpreter evaluate a statement and include the result in > >> the template output. > >> > >> rob > > > > So, first I see this: > >> -uidNumber: 999 > >> -gidNumber: 1001 > >> +uidNumber: $UIDSTART > >> +gidNumber: $GIDSTART > > > > And then later I see this: > >> -dnaNextValue: 1100 > >> +dnaNextValue: eval($UIDSTART+1) > > Right, $UIDSTART is the uid for the admin user. > > > [snip] > >> -dnaNextValue: 1100 > >> +dnaNextValue: eval($GIDSTART+3) > > $GIDSTART = admins group > $GIDSTART+1 = ipauserse group > $GIDSTART+2 = editors group > > So the next available gid is $GIDSTART+3. Now we could leave it as > $GIDSTART in the dna config and it would do the right thing at runtime > if that would be less confusing. > > > > > This seems to be inconsistent, is this intentional? More inconsistencies > > I can see are in the command line option parser where you use 1100 as > > default for both UIDSTART and GIDSTART. In the man page you state the > > default is 1000 for both. > > Yeah, that is a goof. It should be 1000. > > > For the evaluation code, I feel it is a tad more complex than it has to > > be. Also, the pattern seems to be too greedy. I'd suggest that you use > > the sub() function instead, here's an example: > > > >>>> str = "Something, something, something, eval(foo). Something, > > something, something, eval(bar)." > >>>> foo = "dark side" > >>>> bar = "complete" > >>>> pattern = re.compile('(eval\s*\(([^)]*)\))') > >>>> pattern.sub(lambda x: eval(x.group(2)), str) > > 'Something, something, something, dark side. Something, something, > > something, complete.' > > > > This also allows eval() to work more times on one line (also notice the > > [^)]* which makes sure we don't accept something like "eval(foo) bar)". > > I'm also of the opinion that we do abort the installation if the eval() > > fails, because that would be a clear bug. If we keep it quiet we might > > see a more cryptic error instead. > > I see what you are getting at but your code doesn't work. It doesn't > actually evaluate the lines (I specifically want to do math). I should > also note that the re module doesn't count parenthesis so it will almost > always not do the right thing with nested parens, this is why I do it > line-by-line. Ah, sorry, had a bug in there. The sub function should have been called like this: >>> pattern.sub(lambda x: str(eval(x.group(2))), string) and the math will work (you have to use a variable with a different name than I used before). I forgot to wrap the eval() statement into str(). Since you mentioned the paren counting, I also realized that a better pattern would be '(eval\s*\(([^()]*)\))'. But this still creates a problem, if you use "eval(foo + (2 * 4))" then the code will try to evaluate "foo + ". This is really a messy business. I'm not sure how to solve this simply without the use of a parser. But still, your code would be IMO even more dangerous. > > Sure, we can quit the install if you'd prefer. > > rob Martin From rcritten at redhat.com Wed Aug 26 14:53:15 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Aug 2009 10:53:15 -0400 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A954C5B.5050607@redhat.com> Martin Nagy wrote: > > Ah, sorry, had a bug in there. The sub function should have been called > like this: >>>> pattern.sub(lambda x: str(eval(x.group(2))), string) > and the math will work (you have to use a variable with a different name > than I used before). I forgot to wrap the eval() statement into str(). > Since you mentioned the paren counting, I also realized that a better > pattern would be '(eval\s*\(([^()]*)\))'. But this still creates a > problem, if you use "eval(foo + (2 * 4))" then the code will try to > evaluate "foo + ". This is really a messy business. I'm not sure how to > solve this simply without the use of a parser. But still, your code > would be IMO even more dangerous. > Ok, it is important to note that there will be no variables in there. We are passing this through a template so any variable substitution will already be done. For example, if in sub_dict we have GIDSTART set to 1100 the template might look like: gitNumber: eval($GIDSTART+1) This will get passed to the eval as: gidNumber: eval(1100+1) I have no problem at all severely limiting the capabilities of this, so saying "no nested parens" is fine by me, at least until I need them ;-) And speaking of dangerous, using eval at all could be bad because it will evaluate any valid python statement. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Aug 26 15:20:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Aug 2009 11:20:46 -0400 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A9552CE.5020205@redhat.com> Ok, I think I've addressed all the issues raised. I've included Martin's cleaner lambda-based evaluator and the default uid/gid is now a random value between 1,000,000 and (2^31 - 1,000,000). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-256-2-number.patch Type: application/mbox Size: 8347 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Aug 26 18:13:45 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Aug 2009 14:13:45 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework Message-ID: <4A957B59.5010802@redhat.com> This enables an ldapi listening socket in the LDAP server and configures the management framework to use it instead of ldap://localhost:389/ To disable this remove the ldap_uri line from /etc/default/ipa.conf. It will fall back to TCP/IP sockets. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-257-ldapi.patch Type: application/mbox Size: 7243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Aug 27 04:41:00 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Aug 2009 00:41:00 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <4A957B59.5010802@redhat.com> References: <4A957B59.5010802@redhat.com> Message-ID: <1251348060.7914.34.camel@localhost.localdomain> On Wed, 2009-08-26 at 14:13 -0400, Rob Crittenden wrote: > This enables an ldapi listening socket in the LDAP server and > configures > the management framework to use it instead of ldap://localhost:389/ > > To disable this remove the ldap_uri line from /etc/default/ipa.conf. > It > will fall back to TCP/IP sockets. Ah thanks for this, nice to see we finally get to use ldapi. ACK! Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Aug 27 04:42:41 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Aug 2009 00:42:41 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <1251348060.7914.34.camel@localhost.localdomain> References: <4A957B59.5010802@redhat.com> <1251348060.7914.34.camel@localhost.localdomain> Message-ID: <1251348161.7914.35.camel@localhost.localdomain> On Thu, 2009-08-27 at 00:41 -0400, Simo Sorce wrote: > On Wed, 2009-08-26 at 14:13 -0400, Rob Crittenden wrote: > > This enables an ldapi listening socket in the LDAP server and > > configures > > the management framework to use it instead of ldap://localhost:389/ > > > > To disable this remove the ldap_uri line from /etc/default/ipa.conf. > > It > > will fall back to TCP/IP sockets. > > Ah thanks for this, nice to see we finally get to use ldapi. > > ACK! > > Simo. P.S: Shouldn't we enable ldapi also for the kerberos ldap driver ? -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Aug 27 12:23:01 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 08:23:01 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <1251348161.7914.35.camel@localhost.localdomain> References: <4A957B59.5010802@redhat.com> <1251348060.7914.34.camel@localhost.localdomain> <1251348161.7914.35.camel@localhost.localdomain> Message-ID: <4A967AA5.8030808@redhat.com> Simo Sorce wrote: > On Thu, 2009-08-27 at 00:41 -0400, Simo Sorce wrote: >> On Wed, 2009-08-26 at 14:13 -0400, Rob Crittenden wrote: >>> This enables an ldapi listening socket in the LDAP server and >>> configures >>> the management framework to use it instead of ldap://localhost:389/ >>> >>> To disable this remove the ldap_uri line from /etc/default/ipa.conf. >>> It >>> will fall back to TCP/IP sockets. >> Ah thanks for this, nice to see we finally get to use ldapi. >> >> ACK! >> >> Simo. > > P.S: Shouldn't we enable ldapi also for the kerberos ldap driver ? > Bleh, I had meant to do that as well but forgot. It should be a one-liner, I'll work on a patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Thu Aug 27 13:08:39 2009 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 27 Aug 2009 15:08:39 +0200 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <4A9552CE.5020205@redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> <4A9552CE.5020205@redhat.com> Message-ID: <1251378519.25826.55.camel@wolverine.englab.brq.redhat.com> On Wed, 2009-08-26 at 11:20 -0400, Rob Crittenden wrote: > Ok, I think I've addressed all the issues raised. I've included Martin's > cleaner lambda-based evaluator and the default uid/gid is now a random > value between 1,000,000 and (2^31 - 1,000,000). > > rob > + parser.add_option("--uidstart", dest="uidstart", default=namespace, type=int, > + help="The starting uid value (default %default)") > + parser.add_option("--gidstart", dest="gidstart", default=namespace, type=int, > + help="The starting gid value (default %default)") Please make the help message something like "(default random)" instead of "(default %default)". This can be misleading because the number is different on each invocation. The manpage still says that the default is 1000. Conditional Ack if these remaining issues are addressed. Martin From rcritten at redhat.com Thu Aug 27 13:08:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 09:08:31 -0400 Subject: [Freeipa-devel] [PATCH] 258 Enable ldapi in kerberos backend Message-ID: <4A96854F.5090203@redhat.com> This enables ldapi in the kerberos backend. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-258-ldapi.patch Type: application/mbox Size: 2345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Aug 27 13:09:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 09:09:39 -0400 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <1251378519.25826.55.camel@wolverine.englab.brq.redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> <4A9552CE.5020205@redhat.com> <1251378519.25826.55.camel@wolverine.englab.brq.redhat.com> Message-ID: <4A968593.4090307@redhat.com> Martin Nagy wrote: > On Wed, 2009-08-26 at 11:20 -0400, Rob Crittenden wrote: >> Ok, I think I've addressed all the issues raised. I've included Martin's >> cleaner lambda-based evaluator and the default uid/gid is now a random >> value between 1,000,000 and (2^31 - 1,000,000). >> >> rob > >> + parser.add_option("--uidstart", dest="uidstart", default=namespace, type=int, >> + help="The starting uid value (default %default)") >> + parser.add_option("--gidstart", dest="gidstart", default=namespace, type=int, >> + help="The starting gid value (default %default)") > > Please make the help message something like "(default random)" instead > of "(default %default)". This can be misleading because the number is > different on each invocation. > Ah, good point. The next time you run it you'll get a different number, and here I thought I was being so clever :-( > The manpage still says that the default is 1000. > > Conditional Ack if these remaining issues are addressed. > > Martin > Ok, I'll get these fixed up and push it later today. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Aug 27 17:37:17 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 13:37:17 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <1251348161.7914.35.camel@localhost.localdomain> References: <4A957B59.5010802@redhat.com> <1251348060.7914.34.camel@localhost.localdomain> <1251348161.7914.35.camel@localhost.localdomain> Message-ID: <4A96C44D.2020808@redhat.com> Simo Sorce wrote: > On Thu, 2009-08-27 at 00:41 -0400, Simo Sorce wrote: >> On Wed, 2009-08-26 at 14:13 -0400, Rob Crittenden wrote: >>> This enables an ldapi listening socket in the LDAP server and >>> configures >>> the management framework to use it instead of ldap://localhost:389/ >>> >>> To disable this remove the ldap_uri line from /etc/default/ipa.conf. >>> It >>> will fall back to TCP/IP sockets. >> Ah thanks for this, nice to see we finally get to use ldapi. >> >> ACK! >> >> Simo. > > P.S: Shouldn't we enable ldapi also for the kerberos ldap driver ? > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Aug 27 18:11:28 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Aug 2009 14:11:28 -0400 Subject: [Freeipa-devel] [PATCH] 258 Enable ldapi in kerberos backend In-Reply-To: <4A96854F.5090203@redhat.com> References: <4A96854F.5090203@redhat.com> Message-ID: <1251396688.7914.75.camel@localhost.localdomain> On Thu, 2009-08-27 at 09:08 -0400, Rob Crittenden wrote: > This enables ldapi in the kerberos backend. ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Aug 27 18:12:35 2009 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Aug 2009 14:12:35 -0400 Subject: [Freeipa-devel] [PATCH] 252 Add the CA constraint to the self-signed CA we generate In-Reply-To: <4A89624B.2080605@redhat.com> References: <4A89624B.2080605@redhat.com> Message-ID: <1251396755.7914.76.camel@localhost.localdomain> On Mon, 2009-08-17 at 09:59 -0400, Rob Crittenden wrote: > This patch is for the ipa-1-2 branch. It adds the CA constraint to > the > self-signed CA we generate. Otherwise FF 3.5+ won't talk to an > IPA-generated web cert. This should resolve bug 514027. Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Aug 27 18:16:29 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 14:16:29 -0400 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <4A968593.4090307@redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> <4A9552CE.5020205@redhat.com> <1251378519.25826.55.camel@wolverine.englab.brq.redhat.com> <4A968593.4090307@redhat.com> Message-ID: <4A96CD7D.3050901@redhat.com> Rob Crittenden wrote: > Martin Nagy wrote: >> On Wed, 2009-08-26 at 11:20 -0400, Rob Crittenden wrote: >>> Ok, I think I've addressed all the issues raised. I've included >>> Martin's cleaner lambda-based evaluator and the default uid/gid is >>> now a random value between 1,000,000 and (2^31 - 1,000,000). >>> >>> rob >> >>> + parser.add_option("--uidstart", dest="uidstart", >>> default=namespace, type=int, >>> + help="The starting uid value (default %default)") >>> + parser.add_option("--gidstart", dest="gidstart", >>> default=namespace, type=int, >>> + help="The starting gid value (default %default)") >> >> Please make the help message something like "(default random)" instead >> of "(default %default)". This can be misleading because the number is >> different on each invocation. >> > > Ah, good point. The next time you run it you'll get a different number, > and here I thought I was being so clever :-( > >> The manpage still says that the default is 1000. >> >> Conditional Ack if these remaining issues are addressed. >> >> Martin >> > > Ok, I'll get these fixed up and push it later today. > > rob Issues resolved, pushed to master. David, the default value for uidnumber and gidnumber is now a random value between 1,000,000 and (2^31 - 1,000,000). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Aug 27 20:49:26 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 16:49:26 -0400 Subject: [Freeipa-devel] [PATCH] 252 Add the CA constraint to the self-signed CA we generate In-Reply-To: <1251396755.7914.76.camel@localhost.localdomain> References: <4A89624B.2080605@redhat.com> <1251396755.7914.76.camel@localhost.localdomain> Message-ID: <4A96F156.6080108@redhat.com> Simo Sorce wrote: > On Mon, 2009-08-17 at 09:59 -0400, Rob Crittenden wrote: >> This patch is for the ipa-1-2 branch. It adds the CA constraint to >> the >> self-signed CA we generate. Otherwise FF 3.5+ won't talk to an >> IPA-generated web cert. This should resolve bug 514027. > > Ack. > > Simo. > Pushed to ipa-1-2, rebased for master and pushed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From davido at redhat.com Thu Aug 27 22:29:20 2009 From: davido at redhat.com (David O'Brien) Date: Fri, 28 Aug 2009 08:29:20 +1000 Subject: [Freeipa-devel] [PATCH] 256 allow uid/gid starting number to be set In-Reply-To: <4A96CD7D.3050901@redhat.com> References: <4A944BEC.4030409@redhat.com> <1251268442.25826.28.camel@wolverine.englab.brq.redhat.com> <4A9538C0.3090005@redhat.com> <1251295226.25826.48.camel@wolverine.englab.brq.redhat.com> <4A9552CE.5020205@redhat.com> <1251378519.25826.55.camel@wolverine.englab.brq.redhat.com> <4A968593.4090307@redhat.com> <4A96CD7D.3050901@redhat.com> Message-ID: <4A9708C0.5070804@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Martin Nagy wrote: >>> On Wed, 2009-08-26 at 11:20 -0400, Rob Crittenden wrote: >>>> Ok, I think I've addressed all the issues raised. I've included >>>> Martin's cleaner lambda-based evaluator and the default uid/gid is >>>> now a random value between 1,000,000 and (2^31 - 1,000,000). >>>> >>>> rob >>> >>>> + parser.add_option("--uidstart", dest="uidstart", >>>> default=namespace, type=int, >>>> + help="The starting uid value (default >>>> %default)") >>>> + parser.add_option("--gidstart", dest="gidstart", >>>> default=namespace, type=int, >>>> + help="The starting gid value (default >>>> %default)") >>> >>> Please make the help message something like "(default random)" instead >>> of "(default %default)". This can be misleading because the number is >>> different on each invocation. >>> >> >> Ah, good point. The next time you run it you'll get a different >> number, and here I thought I was being so clever :-( >> >>> The manpage still says that the default is 1000. >>> >>> Conditional Ack if these remaining issues are addressed. >>> >>> Martin >>> >> >> Ok, I'll get these fixed up and push it later today. >> >> rob > > Issues resolved, pushed to master. > > David, the default value for uidnumber and gidnumber is now a random > value between 1,000,000 and (2^31 - 1,000,000). > > rob Thanks. It's been updated in the BZ (519418) David -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb From davido at redhat.com Thu Aug 27 22:39:57 2009 From: davido at redhat.com (David O'Brien) Date: Fri, 28 Aug 2009 08:39:57 +1000 Subject: [Freeipa-devel] [PATCH] 252 Add the CA constraint to the self-signed CA we generate In-Reply-To: <1251396755.7914.76.camel@localhost.localdomain> References: <4A89624B.2080605@redhat.com> <1251396755.7914.76.camel@localhost.localdomain> Message-ID: <4A970B3D.9040201@redhat.com> Simo Sorce wrote: > On Mon, 2009-08-17 at 09:59 -0400, Rob Crittenden wrote: > >> This patch is for the ipa-1-2 branch. It adds the CA constraint to >> the >> self-signed CA we generate. Otherwise FF 3.5+ won't talk to an >> IPA-generated web cert. This should resolve bug 514027. >> > > Ack. > > Simo. > > I'm not sure how to treat this. The Release Notes for freeIPA 1.2 only listed FF 1.5, 2.0, and 3.0 as supported versions. Should I update the Release Notes to include 3.5+? Should we just post something on freeipa.org as "News"? What happens when FF 4.0 comes out and (maybe) the problem reappears? This sounds like a dumb question but I just haven't come across it before :-\ Thanks. -- David O'Brien IPA Content Author Red Hat Asia Pacific +61 7 3514 8189 http://freeipa.org/page/DocumentationPortal http://git.fedorahosted.org/git/ipadocs.git "He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb From dpal at redhat.com Thu Aug 27 22:54:53 2009 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 27 Aug 2009 18:54:53 -0400 Subject: [Freeipa-devel] [PATCH] 252 Add the CA constraint to the self-signed CA we generate In-Reply-To: <4A970B3D.9040201@redhat.com> References: <4A89624B.2080605@redhat.com> <1251396755.7914.76.camel@localhost.localdomain> <4A970B3D.9040201@redhat.com> Message-ID: <4A970EBD.6040603@redhat.com> David O'Brien wrote: > Simo Sorce wrote: >> On Mon, 2009-08-17 at 09:59 -0400, Rob Crittenden wrote: >> >>> This patch is for the ipa-1-2 branch. It adds the CA constraint to >>> the self-signed CA we generate. Otherwise FF 3.5+ won't talk to an >>> IPA-generated web cert. This should resolve bug 514027. >>> >> >> Ack. >> >> Simo. >> >> > I'm not sure how to treat this. The Release Notes for freeIPA 1.2 only > listed FF 1.5, 2.0, and 3.0 as supported versions. Should I update the > Release Notes to include 3.5+? Should we just post something on > freeipa.org as "News"? What happens when FF 4.0 comes out and (maybe) > the problem reappears? > > This sounds like a dumb question but I just haven't come across it > before :-\ > > Thanks. > Well, I am not sure either but with the model OSS has it seems that we are on hook with fixing cases like this if a newer version of something we rely upon breaks us. In case of this bug it is pure our bug that was obscured by bug in FF. Now when FF fixed their bug we should fix ours. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From loris at lgs.com.ve Fri Aug 28 01:25:05 2009 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 27 Aug 2009 20:55:05 -0430 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <4A957B59.5010802@redhat.com> References: <4A957B59.5010802@redhat.com> Message-ID: <1251422705.4702.4013.camel@arepa.pzo.lgs.com.ve> El mi?, 26-08-2009 a las 14:13 -0400, Rob Crittenden escribi?: > This enables an ldapi listening socket in the LDAP server and configures > the management framework to use it instead of ldap://localhost:389/ > > To disable this remove the ldap_uri line from /etc/default/ipa.conf. It > will fall back to TCP/IP sockets. Hi, I think there is a small problem with the patch: In my system (389 DS 1.2.1) if I enable ldapi, the socket path is /var/run/dirsrv/slapd-INSTANCE.socket. There is no socket in /var/run/slapd-INSTANCE.socket. -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ -O9 -omg-optimize -fomit-instructions -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3149 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 28 01:31:26 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Aug 2009 21:31:26 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <1251422705.4702.4013.camel@arepa.pzo.lgs.com.ve> References: <4A957B59.5010802@redhat.com> <1251422705.4702.4013.camel@arepa.pzo.lgs.com.ve> Message-ID: <4A97336E.60001@redhat.com> Loris Santamaria wrote: > El mi?, 26-08-2009 a las 14:13 -0400, Rob Crittenden escribi?: >> This enables an ldapi listening socket in the LDAP server and configures >> the management framework to use it instead of ldap://localhost:389/ >> >> To disable this remove the ldap_uri line from /etc/default/ipa.conf. It >> will fall back to TCP/IP sockets. > > Hi, I think there is a small problem with the patch: In my system (389 > DS 1.2.1) if I enable ldapi, the socket path > is /var/run/dirsrv/slapd-INSTANCE.socket. There is no socket > in /var/run/slapd-INSTANCE.socket. Strange. What version of IPA did you install? Is this an upgrade from a previous version of DS? On my system it is definitely in /var/run, though this is a fresh 389-ds install. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From loris at lgs.com.ve Fri Aug 28 01:49:11 2009 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 27 Aug 2009 21:19:11 -0430 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <4A97336E.60001@redhat.com> References: <4A957B59.5010802@redhat.com> <1251422705.4702.4013.camel@arepa.pzo.lgs.com.ve> <4A97336E.60001@redhat.com> Message-ID: <1251424151.4702.4086.camel@arepa.pzo.lgs.com.ve> El jue, 27-08-2009 a las 21:31 -0400, Rob Crittenden escribi?: > Loris Santamaria wrote: > > El mi?, 26-08-2009 a las 14:13 -0400, Rob Crittenden escribi?: > >> This enables an ldapi listening socket in the LDAP server and configures > >> the management framework to use it instead of ldap://localhost:389/ > >> > >> To disable this remove the ldap_uri line from /etc/default/ipa.conf. It > >> will fall back to TCP/IP sockets. > > > > Hi, I think there is a small problem with the patch: In my system (389 > > DS 1.2.1) if I enable ldapi, the socket path > > is /var/run/dirsrv/slapd-INSTANCE.socket. There is no socket > > in /var/run/slapd-INSTANCE.socket. > > Strange. What version of IPA did you install? Is this an upgrade from a > previous version of DS? It was first installed as fedora-ds-1.1.0, then updated with every new release... > On my system it is definitely in /var/run, though this is a fresh 389-ds > install. > > rob > -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ -O9 -omg-optimize -fomit-instructions -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3149 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 28 13:22:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 09:22:41 -0400 Subject: [Freeipa-devel] [PATCH] 257 Enable ldapi in the management framework In-Reply-To: <1251424151.4702.4086.camel@arepa.pzo.lgs.com.ve> References: <4A957B59.5010802@redhat.com> <1251422705.4702.4013.camel@arepa.pzo.lgs.com.ve> <4A97336E.60001@redhat.com> <1251424151.4702.4086.camel@arepa.pzo.lgs.com.ve> Message-ID: <4A97DA21.3000701@redhat.com> Loris Santamaria wrote: > El jue, 27-08-2009 a las 21:31 -0400, Rob Crittenden escribi?: >> Loris Santamaria wrote: >>> El mi?, 26-08-2009 a las 14:13 -0400, Rob Crittenden escribi?: >>>> This enables an ldapi listening socket in the LDAP server and configures >>>> the management framework to use it instead of ldap://localhost:389/ >>>> >>>> To disable this remove the ldap_uri line from /etc/default/ipa.conf. It >>>> will fall back to TCP/IP sockets. >>> Hi, I think there is a small problem with the patch: In my system (389 >>> DS 1.2.1) if I enable ldapi, the socket path >>> is /var/run/dirsrv/slapd-INSTANCE.socket. There is no socket >>> in /var/run/slapd-INSTANCE.socket. >> Strange. What version of IPA did you install? Is this an upgrade from a >> previous version of DS? > > It was first installed as fedora-ds-1.1.0, then updated with every new > release... > Ah, ok. The ldapi path changed (https://bugzilla.redhat.com/show_bug.cgi?id=436397) I'll have to add some code to set it to what we expect. Great catch, thanks! rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From pzuna at redhat.com Fri Aug 28 16:26:43 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 28 Aug 2009 18:26:43 +0200 Subject: [Freeipa-devel] [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hates'em. Message-ID: <4A980543.6020402@redhat.com> python-ldap seems to hate None values when adding an entry and raises an exception instead ignoring them, so we need to filter them ourselves. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-ldap2.add_entry-proof-to-None-values-because-p.patch Type: application/mbox Size: 963 bytes Desc: not available URL: From pzuna at redhat.com Fri Aug 28 16:28:40 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Fri, 28 Aug 2009 18:28:40 +0200 Subject: [Freeipa-devel] [PATCH] Introduce a list of attributes for which only MOD_REPLACE operations are generated. Message-ID: <4A9805B8.50501@redhat.com> Fixes bug 519481. Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Introduce-a-list-of-attributes-for-which-only-MOD_RE.patch Type: application/mbox Size: 1704 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 28 17:12:20 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 13:12:20 -0400 Subject: [Freeipa-devel] [PATCH] 259 Fix selinux issue with ldapi Message-ID: <4A980FF4.3050005@redhat.com> The management framework wasn't working with SELinux over ldapi because it lacked permission to access the unix socket. This patch grants permission. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-259-selinux.patch Type: application/mbox Size: 1303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Aug 28 17:19:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 13:19:04 -0400 Subject: [Freeipa-devel] [PATCH] Introduce a list of attributes for which only MOD_REPLACE operations are generated. In-Reply-To: <4A9805B8.50501@redhat.com> References: <4A9805B8.50501@redhat.com> Message-ID: <4A981188.20409@redhat.com> Pavel Zuna wrote: > Fixes bug 519481. > > Pavel > ack, pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Aug 28 17:21:45 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 13:21:45 -0400 Subject: [Freeipa-devel] [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hates'em. In-Reply-To: <4A980543.6020402@redhat.com> References: <4A980543.6020402@redhat.com> Message-ID: <4A981229.9020404@redhat.com> Pavel Zuna wrote: > python-ldap seems to hate None values when adding an entry and raises an > exception instead ignoring them, so we need to filter them ourselves. > > Pavel Couldn't updates contain None as well? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Aug 28 17:38:45 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 13:38:45 -0400 Subject: [Freeipa-devel] [PATCH] 260 allow a CA to be regenerated Message-ID: <4A981625.8080203@redhat.com> Add an option so we can generate a new cert for a CA. This is so we can ultimately fix the missing CA basic constraint but it will also allow the CA to be renewed. This also fixes a small bug when generating the CA basic constraint. It wasn't getting set as Critical because somehow I had it sending a 7 instead of a y :-( rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-260-ca.patch Type: application/mbox Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Aug 28 21:06:59 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 17:06:59 -0400 Subject: [Freeipa-devel] [QUASI-PATCH] issue new CA certificate Message-ID: <4A9846F3.5080108@redhat.com> Here is just a proposed solution. The problem is that the CA we created up until now lacked the CA basic constraint which means that newer releases of NSS don't consider it a valid CA. This also means that Firefox 3.5 won't work with IPA 1.x. What this script does is generates a certificate with the right extensions using the existing key. This means that we don't need to re-issue all the server certs as well. It also means that once the new cert is issued it needs to be distributed to the 4 winds. On replicas it shouldn't be a big deal but any user that has connected to the web interface will need to trust the new certificate. Note that this program depends on an unapproved patch, [PATCH] 260 allow a CA to be regenerated. Anyway, if you could give this a look-see I'll try to figure out how we want to deliver it. I'm not sure I want to include it in the IPA distribution since it only applies to existing installs. I'd appreciate any thoughts on that as well. rob -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ipa-newca URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Aug 28 22:06:28 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Aug 2009 18:06:28 -0400 Subject: [Freeipa-devel] [PATCH] 261 Many SELinux fixes Message-ID: <4A9854E4.9080801@redhat.com> The ldapi code I committed yesterday didn't work with SELinux enabled. This patch addresses that. On Python 2.5+ systems the mgmt framework didn't work with SELinux enabled because of the ctypes module. It does all sorts of crazy stuff which makes SELinux absolutely freak out (it tries to execute things in /tmp, for example). This is used by uuid but we have our own local copy any because this isn't included in Python 2.4. ctypes is optional anyway so just disable it. Finally have to disable the SELinux rules for dogtag CRL file publishing. The module would blow up if you don't have dogtag installed. Need to find another way. Disabling for now so the server can once again work in enforcing mode. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-261-selinux.patch Type: application/mbox Size: 4217 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Aug 28 22:49:51 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Aug 2009 18:49:51 -0400 Subject: [Freeipa-devel] [PATCH] 260 allow a CA to be regenerated In-Reply-To: <4A981625.8080203@redhat.com> References: <4A981625.8080203@redhat.com> Message-ID: <1251499791.10114.19.camel@localhost.localdomain> On Fri, 2009-08-28 at 13:38 -0400, Rob Crittenden wrote: > Add an option so we can generate a new cert for a CA. This is so we > can > ultimately fix the missing CA basic constraint but it will also allow > the CA to be renewed. > > This also fixes a small bug when generating the CA basic constraint. > It > wasn't getting set as Critical because somehow I had it sending a 7 > instead of a y :-( Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From pzuna at redhat.com Mon Aug 31 10:03:31 2009 From: pzuna at redhat.com (Pavel Zuna) Date: Mon, 31 Aug 2009 12:03:31 +0200 Subject: [Freeipa-devel] [PATCH] Make ldap2.add_entry proof to None values, because python-ldap hates'em. In-Reply-To: <4A981229.9020404@redhat.com> References: <4A980543.6020402@redhat.com> <4A981229.9020404@redhat.com> Message-ID: <4A9B9FF3.5050405@redhat.com> Rob Crittenden wrote: > Pavel Zuna wrote: >> python-ldap seems to hate None values when adding an entry and raises >> an exception instead ignoring them, so we need to filter them ourselves. >> >> Pavel > > Couldn't updates contain None as well? > > rob Updates can and it's valid. None is used in update_entry for deleting attributes. Pavel From kwade at redhat.com Mon Aug 31 20:23:46 2009 From: kwade at redhat.com (Karsten Wade) Date: Mon, 31 Aug 2009 13:23:46 -0700 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <20090804215824.GC7063@calliope.phig.org> References: <20090804215824.GC7063@calliope.phig.org> Message-ID: <20090831202346.GL4804@calliope.phig.org> On Tue, Aug 04, 2009 at 02:58:24PM -0700, Karsten Wade wrote: > Yesterday I lurked on a call with Stephen Gallagher and Richard > Fontana, legal expert on FLOSS licensing. > > Due to audio problems, I wasn't able to fully participate, but I did > hear an implicit agreement to the contribution policy draft I wrote > up. > > I think it may need a few tweaks; I'm going to propose some and get > Richard back on the phone to get an explicit OK from him. Got some stuff back from Richard a few weeks ago, and came up with a few thoughts. Below are Richard's questions and thoughts (quoted with permission) that lead to these two versions of a contribution policy. http://freeipa.org/page/User:Quaid/Contribution_policy_(draft)#License-specific_version http://freeipa.org/page/User:Quaid/Contribution_policy_(draft)#License-agnostic_version Richard looked at the license-specific version, made some suggestions, then asked if there is a reason for being GPLv2 only as a project and codebase. For example, many projects are licensed "GPLv2 or later", yet there was some confusion around the time that GPLv3 came out if that was advisable. Is this project GPLv2-specific on purpose? He went on with these obsverations: There could be difficulties with any selection of a specific license. E.g. suppose FreeIPA has some code under GPLv2 but later on decides it wants to license some of it under LGPL, and suppose that code incorporates some contributed code. Under this policy, FreeIPA will have to go back and get permission from the contributor (assume the contribution isn't so trivial as to be uncopyrightable). That may be something a project ought to be okay to live with. There are other solutions - e.g. contributions could come in under LGPL, or even a more permissive license. But then you get into the problem of possibly discouraging potential contributors, the problem that is at its extreme with a (bad) CLA or copyright assignment scheme. I guess I'm just saying - FreeIPA should think about possible ways in which it might want licensing flexibility for the future. If it's okay being limited to GPLv2 (for incoming contributions) or else having to re-gain permission, that's fine. Plenty of projects operate in that way. For that reason I wrote up two versions of the policy, one of which calls out the GPLv2 specifically, the other calls for contributions to be under the license of the code/content contributed to, or otherwise be deemed acceptable by the project. As for the 'deemed acceptable' part, we could reference the Fedora list of licenses[1] and call out which ones in particular you would call acceptable. Alternately, we could cross that bridge if it happens; people who contribute may not care to use an alternate license, and if they do, the policy would point them in the direction of asking. [1] http://fedoraproject.org/wiki/Licensing - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jderose at redhat.com Mon Aug 31 21:49:25 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 31 Aug 2009 15:49:25 -0600 Subject: [Freeipa-devel] [PATCH] jderose 011 Fleshed out krb plugin and added example of scripting against Python API In-Reply-To: <1246950430.6198.55.camel@jgd-flap> References: <1246950430.6198.55.camel@jgd-flap> Message-ID: <1251755365.4973.1.camel@jgd-flap> Attached is an updated to this patch that now correctly applies. On Tue, 2009-07-07 at 07:07 +0000, Jason Gerard DeRose wrote: > This patch adds the first example of scripting against the IPA Python > API in doc/examples/python-api.py. > > It also finally fleshes out the ipalib.plugins.kerberos.krb plugin. It > wraps the krbV bindings and does correct Unicode encoding/decoding. > More work will be coming shortly with some exception handling cleanup > and porting code to use Backend.krb instead of krbV, but this is a > start. > > I'm still trying to decide on a good solution for implementing the > connection creation in a generic and plugable way (to replace the > hard-coded Executioner.create_context() method). The difficulty is 1) > we need it to be plugable, we want to be able to add new backends that > authenticate using their own mechanisms, while at the same time 2) we > only want to expose connections (but not credentials of any kind) on > request.context, and to make things worse, we 3) want to lazily create > connections whenever possible. > > I took a couple of stabs at the above, but didn't like any of them, so > for now doc/examples/python-api.py just uses a similar hard-coded > connection setup to what Executioner.create_context() uses, specifically > it does this: > > if api.env.in_server: > api.Backend.ldap2.connect( > ccache=api.Backend.krb.default_ccname() > ) > else: > api.Backend.xmlclient.connect() > > This will be replaced eventually with some common method, but this works > for now. > > One last thing: to be consisted with the Kerberos library (right?) and > SASL, I think we should consistently use `ccname` to mean the path of > the file containing the credential cache. We use `ccache` a lot > instead, which can also be confused with the krbV.CCache object. What > does everyone think about this? > > Cheers, > Jason > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jderose-011-2-krb-plugin-plus-api-example.patch Type: text/x-patch Size: 5016 bytes Desc: not available URL: From rcritten at redhat.com Mon Aug 31 21:56:16 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Aug 2009 17:56:16 -0400 Subject: [Freeipa-devel] [PATCH] jderose 011 Fleshed out krb plugin and added example of scripting against Python API In-Reply-To: <1251755365.4973.1.camel@jgd-flap> References: <1246950430.6198.55.camel@jgd-flap> <1251755365.4973.1.camel@jgd-flap> Message-ID: <4A9C4700.4090501@redhat.com> Jason Gerard DeRose wrote: > Attached is an updated to this patch that now correctly applies. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Mon Aug 31 22:05:11 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Mon, 31 Aug 2009 16:05:11 -0600 Subject: [Freeipa-devel] [PATCH] jderose 011 Fleshed out krb plugin and added example of scripting against Python API In-Reply-To: <4A9C4700.4090501@redhat.com> References: <1246950430.6198.55.camel@jgd-flap> <1251755365.4973.1.camel@jgd-flap> <4A9C4700.4090501@redhat.com> Message-ID: <1251756311.4973.2.camel@jgd-flap> On Mon, 2009-08-31 at 17:56 -0400, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > Attached is an updated to this patch that now correctly applies. > > > ack pushed to master. From ssorce at redhat.com Mon Aug 31 22:18:34 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Aug 2009 18:18:34 -0400 Subject: [Freeipa-devel] contribution policy update, what's next In-Reply-To: <20090831202346.GL4804@calliope.phig.org> References: <20090804215824.GC7063@calliope.phig.org> <20090831202346.GL4804@calliope.phig.org> Message-ID: <1251757114.10449.13.camel@localhost.localdomain> On Mon, 2009-08-31 at 13:23 -0700, Karsten Wade wrote: > Richard looked at the license-specific version, made some suggestions, > then asked if there is a reason for being GPLv2 only as a project and > codebase. For example, many projects are licensed "GPLv2 or later", > yet there was some confusion around the time that GPLv3 came out if > that was advisable. Is this project GPLv2-specific on purpose? No there isn't a specific reason IPA is GPLv2 Only, at the time when we started I actually proposed to use the brand new GPLv3 or later diction, but legal was not yet comfortable with GPLv3 so we went the default RH license at the time which was GPLv2 only. I would actually like to move to GPLv2 or later or even GPLv3 or later if our external code dependencies allows it without trouble. I think the only code that we may not be able to move to GPLv3 is the directory server plugins as DS is GPLv2+exceptions, but I have no problem in clearly spelling out that plugins have a different license because of their dependency and move on with the rest of the code. Simo. -- Simo Sorce * Red Hat, Inc * New York