From rcritten at redhat.com Mon Mar 3 19:16:19 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Mar 2008 14:16:19 -0500 Subject: [Freeipa-devel] [PATCH] Fix some AVCs, relocate install logs Message-ID: <47CC4E83.9060303@redhat.com> We were seeing a ton of AVCs during installation. This is because we had the log file open but were forking, causing SELinux to not like that open file descriptor. I set close_fds on the Popen() call and that fixed it. I've also relocated the logs to root's $HOME. If that can't be determined put them in /var/log. Both are much better than the current working directory. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-700-selinux.patch Type: text/x-patch Size: 2527 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 Mar 3 19:42:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 03 Mar 2008 14:42:18 -0500 Subject: [Freeipa-devel] [PATCH] Fix some AVCs, relocate install logs In-Reply-To: <47CC4E83.9060303@redhat.com> References: <47CC4E83.9060303@redhat.com> Message-ID: <1204573339.3612.26.camel@localhost.localdomain> On Mon, 2008-03-03 at 14:16 -0500, Rob Crittenden wrote: > We were seeing a ton of AVCs during installation. This is because we > had > the log file open but were forking, causing SELinux to not like that > open file descriptor. I set close_fds on the Popen() call and that > fixed it. > > I've also relocated the logs to root's $HOME. If that can't be > determined put them in /var/log. Both are much better than the > current > working directory. Nak-ing only because of log location, let's just use only /var/log as Dan recommends it also for SeLinux compliance. Simo. -- Simo Sorce * Red Hat, Inc * New York From felix.schwarz at web.de Mon Mar 3 20:03:07 2008 From: felix.schwarz at web.de (Felix Schwarz) Date: Mon, 03 Mar 2008 21:03:07 +0100 Subject: [Freeipa-devel] Re: FreeIPA and mobile users In-Reply-To: <20080229111613.GA15636@imp.flyn.org> References: <20080229111613.GA15636@imp.flyn.org> Message-ID: <47CC597B.3010200@web.de> An offline cache will be probably useful for servers, too. What happens if the main LDAP server goes away (network died) and you have to log in onto another server? At least it should be possible to do some basic system administration. Or is that scenario solved by FreeIPA already? fs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3299 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Mar 3 20:14:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 03 Mar 2008 15:14:25 -0500 Subject: [Freeipa-devel] Re: FreeIPA and mobile users In-Reply-To: <47CC597B.3010200@web.de> References: <20080229111613.GA15636@imp.flyn.org> <47CC597B.3010200@web.de> Message-ID: <1204575265.3612.28.camel@localhost.localdomain> On Mon, 2008-03-03 at 21:03 +0100, Felix Schwarz wrote: > An offline cache will be probably useful for servers, too. What happens if > the main LDAP server goes away (network died) and you have to log in onto > another server? At least it should be possible to do some basic system > administration. Or is that scenario solved by FreeIPA already? This is something we have already planned to do for v2.0, still in the works, but offline operations are intended to be supported by then. Right now they are not. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 3 21:12:20 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Mar 2008 16:12:20 -0500 Subject: [Freeipa-devel] [PATCH] hostname validation at install Message-ID: <47CC69B4.50706@redhat.com> This adds some additional checking at install time. It ensures that the IPA server name is a DNS A record and that its reverse matches its forward address. I also found a bug in the dnsclient where the address data wasn't being returned for PTR records. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-701-dns.patch Type: text/x-patch Size: 2168 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 Mar 3 22:13:00 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 03 Mar 2008 17:13:00 -0500 Subject: [Freeipa-devel] [PATCH] filter service principals Message-ID: <47CC77EC.2010407@redhat.com> Filter out K/M and krbtgt principals from the list of service principals. These don't need to be visible and are generally confusing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-702-filter.patch Type: text/x-patch Size: 1420 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 mike at flyn.org Tue Mar 4 08:57:32 2008 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 4 Mar 2008 13:27:32 +0430 Subject: [Freeipa-devel] FreeIPA and mobile users In-Reply-To: <47C8227A.3090002@redhat.com> References: <20080229111613.GA15636@imp.flyn.org> <47C8227A.3090002@redhat.com> Message-ID: <20080304085731.GA5133@imp.flyn.org> >> Is anyone thinking about how to integrate mobile users into a FreeIPA >> network? > > Absolutely, this is very much a goal of IPA, although not in the very first > release. The functionality will be provided by a component called BlueBox. > The name derives from white board architectural discussions in which the > functionality was contained in a blue box on the white board. I went > looking for a current public document on BlueBox, but I didn't find one of > much merit, I believe Simo has a task on his plate to update the BlueBox > design so stay tuned. Will we be integrating existing components like pam_ccreds or will BlueBox be completely new? -- Mike :wq From rcritten at redhat.com Tue Mar 4 19:31:29 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Mar 2008 14:31:29 -0500 Subject: [Freeipa-devel] [PATCH] remove group edit on self-service Message-ID: <47CDA391.3060508@redhat.com> If a user isn't in admins or editors groups in the UI remove the add/remove group links. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-703-group.patch Type: text/x-patch Size: 1984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Mar 4 20:34:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 04 Mar 2008 15:34:11 -0500 Subject: [Freeipa-devel] [PATCH] pushed patch for SELinux Message-ID: <47CDB243.8@redhat.com> Saw a failure of ipa_webgui on recent selinux-policy versions. This patch fixes them. I've pushed this. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-704-selinux.patch Type: text/x-patch Size: 865 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 Wed Mar 5 04:32:44 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2008 23:32:44 -0500 Subject: [Freeipa-devel] [PATCH] hostname validation at install In-Reply-To: <47CC69B4.50706@redhat.com> References: <47CC69B4.50706@redhat.com> Message-ID: <1204691564.380.46.camel@localhost.localdomain> On Mon, 2008-03-03 at 16:12 -0500, Rob Crittenden wrote: > This adds some additional checking at install time. It ensures that > the > IPA server name is a DNS A record and that its reverse matches its > forward address. > > I also found a bug in the dnsclient where the address data wasn't > being > returned for PTR records. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 5 04:32:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2008 23:32:56 -0500 Subject: [Freeipa-devel] [PATCH] filter service principals In-Reply-To: <47CC77EC.2010407@redhat.com> References: <47CC77EC.2010407@redhat.com> Message-ID: <1204691576.380.48.camel@localhost.localdomain> On Mon, 2008-03-03 at 17:13 -0500, Rob Crittenden wrote: > Filter out K/M and krbtgt principals from the list of service > principals. These don't need to be visible and are generally > confusing. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 5 04:33:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2008 23:33:14 -0500 Subject: [Freeipa-devel] [PATCH] remove group edit on self-service In-Reply-To: <47CDA391.3060508@redhat.com> References: <47CDA391.3060508@redhat.com> Message-ID: <1204691594.380.50.camel@localhost.localdomain> On Tue, 2008-03-04 at 14:31 -0500, Rob Crittenden wrote: > If a user isn't in admins or editors groups in the UI remove the > add/remove group links. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 5 04:39:58 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2008 23:39:58 -0500 Subject: [Freeipa-devel] FreeIPA and mobile users In-Reply-To: <20080304085731.GA5133@imp.flyn.org> References: <20080229111613.GA15636@imp.flyn.org> <47C8227A.3090002@redhat.com> <20080304085731.GA5133@imp.flyn.org> Message-ID: <1204691998.380.52.camel@localhost.localdomain> On Tue, 2008-03-04 at 13:27 +0430, W. Michael Petullo wrote: > >> Is anyone thinking about how to integrate mobile users into a FreeIPA > >> network? > > > > Absolutely, this is very much a goal of IPA, although not in the very first > > release. The functionality will be provided by a component called BlueBox. > > The name derives from white board architectural discussions in which the > > functionality was contained in a blue box on the white board. I went > > looking for a current public document on BlueBox, but I didn't find one of > > much merit, I believe Simo has a task on his plate to update the BlueBox > > design so stay tuned. > > Will we be integrating existing components like pam_ccreds or will > BlueBox be completely new? We want to build a more sophisticated system based on a daemon, I don;t think pam_ccreds fits the picture. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Mar 5 15:36:54 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Mar 2008 10:36:54 -0500 Subject: [Freeipa-devel] [PATCH] hostname validation at install In-Reply-To: <1204691564.380.46.camel@localhost.localdomain> References: <47CC69B4.50706@redhat.com> <1204691564.380.46.camel@localhost.localdomain> Message-ID: <47CEBE16.2000704@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-03 at 16:12 -0500, Rob Crittenden wrote: >> This adds some additional checking at install time. It ensures that >> the >> IPA server name is a DNS A record and that its reverse matches its >> forward address. >> >> I also found a bug in the dnsclient where the address data wasn't >> being >> returned for PTR records. > > ack > pushed -------------- 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 Mar 5 15:37:01 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Mar 2008 10:37:01 -0500 Subject: [Freeipa-devel] [PATCH] filter service principals In-Reply-To: <1204691576.380.48.camel@localhost.localdomain> References: <47CC77EC.2010407@redhat.com> <1204691576.380.48.camel@localhost.localdomain> Message-ID: <47CEBE1D.1030308@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-03 at 17:13 -0500, Rob Crittenden wrote: >> Filter out K/M and krbtgt principals from the list of service >> principals. These don't need to be visible and are generally >> confusing. > > ack > pushed -------------- 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 Mar 5 15:37:09 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Mar 2008 10:37:09 -0500 Subject: [Freeipa-devel] [PATCH] remove group edit on self-service In-Reply-To: <1204691594.380.50.camel@localhost.localdomain> References: <47CDA391.3060508@redhat.com> <1204691594.380.50.camel@localhost.localdomain> Message-ID: <47CEBE25.40408@redhat.com> Simo Sorce wrote: > On Tue, 2008-03-04 at 14:31 -0500, Rob Crittenden wrote: >> If a user isn't in admins or editors groups in the UI remove the >> add/remove group links. > > ack > pushed -------------- 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 Wed Mar 5 19:57:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Mar 2008 14:57:18 -0500 Subject: [Freeipa-devel] [PATCH] Enhance ipa-getkeytab Message-ID: <47CEFB1E.4060006@redhat.com> $SUBJECT -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-720-getkeytab-enhancements.patch Type: text/x-patch Size: 4592 bytes Desc: not available URL: From rcritten at redhat.com Wed Mar 5 21:34:17 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 05 Mar 2008 16:34:17 -0500 Subject: [Freeipa-devel] [PATCH] improve ipa-client-install error handling Message-ID: <47CF11D9.6010907@redhat.com> Prevent server and domain from being undefined or blank when we need them Improve LDAP error reporting Don't return the str() of discovery values because it can return "None" rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-721-client.patch Type: text/x-patch Size: 3683 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 Wed Mar 5 22:22:33 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 05 Mar 2008 17:22:33 -0500 Subject: [Freeipa-devel] [PATCH] improve ipa-client-install error handling In-Reply-To: <47CF11D9.6010907@redhat.com> References: <47CF11D9.6010907@redhat.com> Message-ID: <1204755753.380.85.camel@localhost.localdomain> On Wed, 2008-03-05 at 16:34 -0500, Rob Crittenden wrote: > Prevent server and domain from being undefined or blank when we need > them > Improve LDAP error reporting > Don't return the str() of discovery values because it can return > "None" ack -- Simo Sorce * Red Hat, Inc * New York From mike at flyn.org Thu Mar 6 06:34:41 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 6 Mar 2008 11:04:41 +0430 Subject: [Freeipa-devel] Question about XML/RPC backend Message-ID: <20080306063441.GB22612@imp.flyn.org> I am trying to learn the FreeIPA architecture. Most of it makes sense. I do have one question. How does the XML/RPC backend manipulate system configuration files when the Apache process is not run as root? -- Mike :wq From rcritten at redhat.com Thu Mar 6 14:20:40 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 06 Mar 2008 09:20:40 -0500 Subject: [Freeipa-devel] Question about XML/RPC backend In-Reply-To: <20080306063441.GB22612@imp.flyn.org> References: <20080306063441.GB22612@imp.flyn.org> Message-ID: <47CFFDB8.3070701@redhat.com> W. Michael Petullo wrote: > I am trying to learn the FreeIPA architecture. Most of it makes sense. I > do have one question. How does the XML/RPC backend manipulate system > configuration files when the Apache process is not run as root? > The XML-RPC backend doesn't write any configuration files. At most it writes to LDAP, binding as the user that made the XML-RPC request. Apache does not run as root, it runs as apache (or nobody or something else) on most systems. It starts as root so it can bind ports < 1024 then drops privs. See the User directive in httpd.conf. The Apache configuration files are created/modified during the ipa-server-install step which needs to be done as root. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Mar 6 14:31:33 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 06 Mar 2008 09:31:33 -0500 Subject: [Freeipa-devel] Question about XML/RPC backend In-Reply-To: <20080306063441.GB22612@imp.flyn.org> References: <20080306063441.GB22612@imp.flyn.org> Message-ID: <1204813893.380.98.camel@localhost.localdomain> On Thu, 2008-03-06 at 11:04 +0430, W. Michael Petullo wrote: > I am trying to learn the FreeIPA architecture. Most of it makes sense. I > do have one question. How does the XML/RPC backend manipulate system > configuration files when the Apache process is not run as root? It does not. At the moment all we change is LDAP entries, anything that requires configuration changes need to be run via the CLI on the servers. For the future I expect to move most of the configuration still in files to LDAP, and for the few things we need to do on the machine to have a smaller daemon/setuid helper to run commands as root/appropriate user. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 6 18:19:47 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 06 Mar 2008 13:19:47 -0500 Subject: [Freeipa-devel] [PATCH] verify sanity of /etc/hosts Message-ID: <47D035C3.7080403@redhat.com> During ipa-server-install compare the hostname that DNS returned to the hostname found in /etc/hosts. This should catch the cases where the non-fully-qualified version appears first. Also fix a bitness issue on 64-bit platforms and don't ignore exceptions when getting the hostname from the user. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-722-host.patch Type: text/x-patch Size: 2984 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 Mar 6 21:52:35 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 06 Mar 2008 16:52:35 -0500 Subject: [Freeipa-devel] [PATCH] restart replication agreement Message-ID: <47D067A3.4090503@redhat.com> Add ability to initialize a replication agreement Clean up a lot of unused code in ipaldap.py. This lets us do a simple bind without being root (it used to try to read dse.ldif) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-723-replication.patch Type: text/x-patch Size: 7587 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 Mar 7 15:57:30 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 07 Mar 2008 10:57:30 -0500 Subject: [Freeipa-devel] [PATCH] restart replication agreement In-Reply-To: <47D067A3.4090503@redhat.com> References: <47D067A3.4090503@redhat.com> Message-ID: <47D165EA.6080703@redhat.com> Rob Crittenden wrote: > Add ability to initialize a replication agreement > Clean up a lot of unused code in ipaldap.py. This lets us do a simple > bind without being root (it used to try to read dse.ldif) > Here is a new patch based on some out-of-band comments from one of the FDS developers. This also adds a 'sync' command so you can tell the DS to do a sync right now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-723-replication.patch Type: text/x-patch Size: 9232 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 Mar 7 20:40:31 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 07 Mar 2008 15:40:31 -0500 Subject: [Freeipa-devel] [PATCH] Enhance ipa-getkeytab In-Reply-To: <47CEFB1E.4060006@redhat.com> References: <47CEFB1E.4060006@redhat.com> Message-ID: <47D1A83F.4000705@redhat.com> Simo Sorce wrote: > $SUBJECT > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Mar 7 20:41:40 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 07 Mar 2008 15:41:40 -0500 Subject: [Freeipa-devel] [PATCH] improve ipa-client-install error handling In-Reply-To: <1204755753.380.85.camel@localhost.localdomain> References: <47CF11D9.6010907@redhat.com> <1204755753.380.85.camel@localhost.localdomain> Message-ID: <47D1A884.8020704@redhat.com> Simo Sorce wrote: > On Wed, 2008-03-05 at 16:34 -0500, Rob Crittenden wrote: >> Prevent server and domain from being undefined or blank when we need >> them >> Improve LDAP error reporting >> Don't return the str() of discovery values because it can return >> "None" > > ack > pushed -------------- 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 Mar 7 22:14:20 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 07 Mar 2008 17:14:20 -0500 Subject: [Freeipa-devel] [PATCH] Enhance ipa-getkeytab In-Reply-To: <47D1A83F.4000705@redhat.com> References: <47CEFB1E.4060006@redhat.com> <47D1A83F.4000705@redhat.com> Message-ID: <47D1BE3C.3010702@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> $SUBJECT >> > > ack I went ahead and pushed this. 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 mike at flyn.org Sun Mar 9 19:45:55 2008 From: mike at flyn.org (mike) Date: Mon, 10 Mar 2008 00:15:55 +0430 Subject: [Freeipa-devel] Question about pam_krb5 and FreeIPA Message-ID: <20080309194555.GA17859@imp.flyn.org> Unlike Apache, pam_krb5 does not seem to require a service key. My understanding is that the service key is used to ensure that the Kerberos server is not being spoofed. Could anyone explain why pam_krb5 does not seem to require a service key? Is this optional? Thank you. Mike From ssorce at redhat.com Sun Mar 9 21:06:35 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 09 Mar 2008 17:06:35 -0400 Subject: [Freeipa-devel] Question about pam_krb5 and FreeIPA In-Reply-To: <20080309194555.GA17859@imp.flyn.org> References: <20080309194555.GA17859@imp.flyn.org> Message-ID: <47D4515B.5050303@redhat.com> mike wrote: > Unlike Apache, pam_krb5 does not seem to require a service key. My > understanding is that the service key is used to ensure that the Kerberos > server is not being spoofed. Could anyone explain why pam_krb5 does not > seem to require a service key? Is this optional? pam_krb5 can do that using the keyword validate in [appdefaults] pam section. Simo. From mike at flyn.org Mon Mar 10 08:20:59 2008 From: mike at flyn.org (mike) Date: Mon, 10 Mar 2008 12:50:59 +0430 Subject: [Freeipa-devel] Question about pam_krb5 and FreeIPA In-Reply-To: <47D4515B.5050303@redhat.com> References: <20080309194555.GA17859@imp.flyn.org> <47D4515B.5050303@redhat.com> Message-ID: <20080310082059.GA8469@imp.flyn.org> >> Unlike Apache, pam_krb5 does not seem to require a service key. My >> understanding is that the service key is used to ensure that the Kerberos >> server is not being spoofed. Could anyone explain why pam_krb5 does not >> seem to require a service key? Is this optional? > > pam_krb5 can do that using the keyword validate in [appdefaults] pam > section. Shouldn't validation be enabled by default by ipa-client-install? Mike From rcritten at redhat.com Mon Mar 10 14:06:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Mar 2008 10:06:04 -0400 Subject: [Freeipa-devel] [PATCH] remove ACI preventing RDN change Message-ID: <47D5404C.60802@redhat.com> As a side-effect of this ACI, RDN changes were failing. It may be a bug in FDS (they are looking into it). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-724-rdn.patch Type: text/x-patch Size: 2589 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 Mar 10 15:38:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Mar 2008 11:38:41 -0400 Subject: [Freeipa-devel] [PATCH] uniq_list() needs to ignore all case Message-ID: <47D55601.1010103@redhat.com> The uniq_list function lets you create a unique list by casting it into a Set. The problem is that the set wasn't being populated with lower-case values so it was possible to end up with mixed-case duplicates. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-725-lower.patch Type: text/x-patch Size: 928 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 nalin at redhat.com Mon Mar 10 18:30:13 2008 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 10 Mar 2008 14:30:13 -0400 Subject: [Freeipa-devel] Question about pam_krb5 and FreeIPA In-Reply-To: <20080309194555.GA17859@imp.flyn.org> References: <20080309194555.GA17859@imp.flyn.org> Message-ID: <20080310183013.GB12368@redhat.com> On Mon, Mar 10, 2008 at 12:15:55AM +0430, mike wrote: > Unlike Apache, pam_krb5 does not seem to require a service key. My > understanding is that the service key is used to ensure that the Kerberos > server is not being spoofed. Could anyone explain why pam_krb5 does not > seem to require a service key? Is this optional? Generally, yes, you want to validate against a local key. More often, though, there is no such key available, so the module uses a local key it if it can read the configured keytab file, and otherwise it can only hope that the local administrators know what they're doing. HTH, Nalin From jim at meyering.net Mon Mar 10 21:39:55 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 10 Mar 2008 22:39:55 +0100 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server Message-ID: <87pru28dhw.fsf@rho.meyering.net> Hello, I'm a total freeipa newbie and have only just subscribed to this list. Sorry if anything here is a FAQ. On a rawhide-based system, updated a day or two ago, I ran ipa-server-install, and dir-server steps 4..9 each got CRITICAL failures, before it bailed out: # rpm -q ipa-server ipa-server-0.99-11.fc9.i386 Note that I already have a kerberos principal set up, and it's not the "MEYERING.NET" I used in this process. Does that matter? Here's the tail of it's output: Please wait until the prompt is returned. Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server: [1/16]: creating directory server user [2/16]: creating directory server instance [3/16]: adding default schema [4/16]: enabling memberof plugin root : CRITICAL Failed to load memberof-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 [5/16]: enabling referential integrity plugin root : CRITICAL Failed to load referint-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49 [6/16]: enabling distributed numeric assignment plugin root : CRITICAL Failed to load dna-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49 [7/16]: configuring uniqueness plugin root : CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /dev/shm/tmp4dWkvF' returned non-zero exit status 49 [8/16]: creating indices root : CRITICAL Failed to load indices.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/indices.ldif' returned non-zero exit status 49 [9/16]: configuring ssl for ds instance Unexpected error - see ipaserver-install.log for details: {'desc': 'Invalid credentials'} -------------------------- When I ran that ldapmodify command manually, it did this: root at iota# ldapmodify -h 127.0.0.1 -xv -D 'cn=Directory Manager' \ -w xxx -f /usr/share/ipa/memberof-conf.ldif ldap_initialize( ldap://127.0.0.1 ) ldap_bind: Invalid credentials (49) [Exit 49] ------------------------------------- Here's the ipaserver-install.log file ipa-server-install created: 2008-03-10 21:16:01,362 INFO Shutting down dirsrv: MEYERING-NET...[60G[[0;32m OK [0;39m] 2008-03-10 21:16:01,363 INFO 2008-03-10 21:17:49,038 DEBUG Configuring ntpd 2008-03-10 21:17:49,039 DEBUG [1/4]: stopping ntpd 2008-03-10 21:17:49,280 INFO ntpd (pid 8143) is running... 2008-03-10 21:17:49,281 INFO 2008-03-10 21:17:49,282 DEBUG Loading StateFile from '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,285 DEBUG Saving StateFile to '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,552 INFO Shutting down ntpd: [60G[[0;32m OK [0;39m] 2008-03-10 21:17:49,552 INFO 2008-03-10 21:17:49,552 DEBUG [2/4]: writing configuration 2008-03-10 21:17:49,553 DEBUG Backing up system configuration file '/etc/ntp.conf' 2008-03-10 21:17:49,554 DEBUG -> Not backing up - already have a copy of '/etc/ntp.conf' 2008-03-10 21:17:49,554 DEBUG Backing up system configuration file '/etc/sysconfig/ntpd' 2008-03-10 21:17:49,554 DEBUG -> Not backing up - already have a copy of '/etc/sysconfig/ntpd' 2008-03-10 21:17:49,555 DEBUG [3/4]: configuring ntpd to start on boot 2008-03-10 21:17:49,565 INFO ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off 2008-03-10 21:17:49,566 INFO 2008-03-10 21:17:49,566 DEBUG Loading StateFile from '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,567 DEBUG Saving StateFile to '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,819 INFO 2008-03-10 21:17:49,820 INFO 2008-03-10 21:17:49,820 DEBUG [4/4]: starting ntpd 2008-03-10 21:17:49,890 INFO Starting ntpd: [60G[[0;32m OK [0;39m] 2008-03-10 21:17:49,891 INFO 2008-03-10 21:17:49,891 DEBUG done configuring ntpd. 2008-03-10 21:17:49,891 DEBUG Configuring directory server: 2008-03-10 21:17:49,892 DEBUG [1/16]: creating directory server user 2008-03-10 21:17:49,892 DEBUG ds user dirsrv exists 2008-03-10 21:17:49,892 DEBUG Loading StateFile from '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,893 DEBUG Saving StateFile to '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,893 DEBUG Loading StateFile from '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,895 DEBUG Saving StateFile to '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,896 DEBUG [2/16]: creating directory server instance 2008-03-10 21:17:49,963 INFO 2008-03-10 21:17:49,964 INFO 2008-03-10 21:17:49,964 DEBUG Loading StateFile from '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,964 DEBUG Saving StateFile to '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,965 DEBUG Loading StateFile from '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,966 DEBUG Saving StateFile to '/var/cache/ipa/sysrestore.state' 2008-03-10 21:17:49,966 DEBUG writing inf template 2008-03-10 21:17:49,968 DEBUG [General] FullMachineName= iota.meyering.net SuiteSpotUserID= dirsrv ServerRoot= /usr/lib/dirsrv [slapd] ServerPort= 389 ServerIdentifier= MEYERING-NET Suffix= dc=meyering,dc=net RootDN= cn=Directory Manager 2008-03-10 21:17:49,968 DEBUG calling setup-ds.pl 2008-03-10 21:17:53,753 INFO [08/03/10:21:17:53] - [Setup] Info Your new DS instance 'MEYERING-NET' was successfully created. Your new DS instance 'MEYERING-NET' was successfully created. [08/03/10:21:17:53] - [Setup] Success Exiting . . . Log file is '-' Exiting . . . Log file is '-' 2008-03-10 21:17:53,754 INFO 2008-03-10 21:17:53,754 DEBUG completed creating ds instance 2008-03-10 21:17:53,755 DEBUG restarting ds instance 2008-03-10 21:17:56,624 INFO Shutting down dirsrv: MEYERING-NET...[60G[[0;32m OK [0;39m] Starting dirsrv: MEYERING-NET...[60G[[0;32m OK [0;39m] 2008-03-10 21:17:56,626 INFO 2008-03-10 21:17:56,627 DEBUG done restarting ds instance 2008-03-10 21:17:56,628 DEBUG [3/16]: adding default schema 2008-03-10 21:17:56,637 DEBUG [4/16]: enabling memberof plugin 2008-03-10 21:17:56,664 INFO 2008-03-10 21:17:56,665 INFO ldap_initialize( ldap://127.0.0.1 ) ldap_bind: Invalid credentials (49) 2008-03-10 21:17:56,666 CRITICAL Failed to load memberof-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 2008-03-10 21:17:56,669 DEBUG [5/16]: enabling referential integrity plugin 2008-03-10 21:17:56,696 INFO 2008-03-10 21:17:56,698 INFO ldap_initialize( ldap://127.0.0.1 ) ldap_bind: Invalid credentials (49) 2008-03-10 21:17:56,698 CRITICAL Failed to load referint-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49 2008-03-10 21:17:56,700 DEBUG [6/16]: enabling distributed numeric assignment plugin 2008-03-10 21:17:56,728 INFO 2008-03-10 21:17:56,729 INFO ldap_initialize( ldap://127.0.0.1 ) ldap_bind: Invalid credentials (49) 2008-03-10 21:17:56,730 CRITICAL Failed to load dna-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49 2008-03-10 21:17:56,732 DEBUG [7/16]: configuring uniqueness plugin 2008-03-10 21:17:56,759 INFO 2008-03-10 21:17:56,760 INFO ldap_initialize( ldap://127.0.0.1 ) ldap_bind: Invalid credentials (49) 2008-03-10 21:17:56,761 CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /dev/shm/tmp4dWkvF' returned non-zero exit status 49 2008-03-10 21:17:56,763 DEBUG [8/16]: creating indices 2008-03-10 21:17:56,791 INFO 2008-03-10 21:17:56,792 INFO ldap_initialize( ldap://127.0.0.1 ) ldap_bind: Invalid credentials (49) 2008-03-10 21:17:56,793 CRITICAL Failed to load indices.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/indices.ldif' returned non-zero exit status 49 2008-03-10 21:17:56,796 DEBUG [9/16]: configuring ssl for ds instance 2008-03-10 21:17:56,854 INFO 2008-03-10 21:17:56,855 INFO 2008-03-10 21:17:57,414 INFO 2008-03-10 21:17:57,415 INFO Generating key. This may take a few moments... 2008-03-10 21:17:57,916 INFO 2008-03-10 21:17:57,917 INFO Generating key. This may take a few moments... 2008-03-10 21:17:57,933 INFO 2008-03-10 21:17:57,934 INFO 2008-03-10 21:17:57,955 INFO pk12util: PKCS12 EXPORT SUCCESSFUL 2008-03-10 21:17:57,955 INFO 2008-03-10 21:17:58,207 INFO 2008-03-10 21:17:58,208 INFO Generating key. This may take a few moments... 2008-03-10 21:17:58,253 INFO 2008-03-10 21:17:58,254 INFO 2008-03-10 21:17:58,261 DEBUG {'desc': 'Invalid credentials'} File "/usr/sbin/ipa-server-install", line 542, in main() File "/usr/sbin/ipa-server-install", line 459, in main ds.create_instance(ds_user, realm_name, host_name, domain_name, dm_password) File "/usr/lib/python2.5/site-packages/ipaserver/dsinstance.py", line 146, in create_instance self.start_creation("Configuring directory server:") File "/usr/lib/python2.5/site-packages/ipaserver/service.py", line 134, in start_creation method() File "/usr/lib/python2.5/site-packages/ipaserver/dsinstance.py", line 272, in __enable_ssl conn.simple_bind_s("cn=directory manager", self.dm_password) File "/usr/lib/python2.5/site-packages/ipaserver/ipaldap.py", line 175, in inner return f(*args, **kargs) File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 199, in simple_bind_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.5/site-packages/ipaserver/ipaldap.py", line 152, in inner type, data = f(*args, **kargs) File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 428, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.5/site-packages/ipaserver/ipaldap.py", line 175, in inner return f(*args, **kargs) File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 432, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.5/site-packages/ipaserver/ipaldap.py", line 175, in inner return f(*args, **kargs) File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 438, in result3 rtype, rdata, rmsgid, serverctrls = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.5/site-packages/ipaserver/ipaldap.py", line 175, in inner return f(*args, **kargs) File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 97, in _ldap_call result = func(*args,**kwargs) From rcritten at redhat.com Tue Mar 11 01:50:57 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Mar 2008 21:50:57 -0400 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <87pru28dhw.fsf@rho.meyering.net> References: <87pru28dhw.fsf@rho.meyering.net> Message-ID: <47D5E581.3070204@redhat.com> Jim Meyering wrote: > Hello, > > I'm a total freeipa newbie and have only just subscribed to this list. > Sorry if anything here is a FAQ. > > On a rawhide-based system, updated a day or two ago, I ran > ipa-server-install, and dir-server steps 4..9 each got > CRITICAL failures, before it bailed out: > > # rpm -q ipa-server > ipa-server-0.99-11.fc9.i386 > > Note that I already have a kerberos principal set up, > and it's not the "MEYERING.NET" I used in this process. > Does that matter? > > Here's the tail of it's output: > > Please wait until the prompt is returned. > Configuring ntpd > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > done configuring ntpd. > Configuring directory server: > [1/16]: creating directory server user > [2/16]: creating directory server instance > [3/16]: adding default schema > [4/16]: enabling memberof plugin > root : CRITICAL Failed to load memberof-conf.ldif: Command > '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 > [5/16]: enabling referential integrity plugin > root : CRITICAL Failed to load referint-conf.ldif: Command > '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49 > [6/16]: enabling distributed numeric assignment plugin > root : CRITICAL Failed to load dna-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49 > [7/16]: configuring uniqueness plugin > root : CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /dev/shm/tmp4dWkvF' returned non-zero exit status 49 > [8/16]: creating indices > root : CRITICAL Failed to load indices.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/indices.ldif' returned non-zero exit status 49 > [9/16]: configuring ssl for ds instance > Unexpected error - see ipaserver-install.log for details: > {'desc': 'Invalid credentials'} Hmm, very strange. Can you look in /var/log/dirsrv/slapd-MEYERING-NET/errors to see if it has anything? I'm not sure how this could happen. The Directory Server install shouldn't have happened if you already had a server running there (like openldap) so I'm not sure how it isn't authenticating the directory manager. 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 jim at meyering.net Tue Mar 11 07:55:11 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 11 Mar 2008 08:55:11 +0100 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <47D5E581.3070204@redhat.com> (Rob Crittenden's message of "Mon, 10 Mar 2008 21:50:57 -0400") References: <87pru28dhw.fsf@rho.meyering.net> <47D5E581.3070204@redhat.com> Message-ID: <873aqx8zkw.fsf@rho.meyering.net> Rob Crittenden wrote: ... >> Configuring directory server: >> [1/16]: creating directory server user >> [2/16]: creating directory server instance >> [3/16]: adding default schema >> [4/16]: enabling memberof plugin >> root : CRITICAL Failed to load memberof-conf.ldif: Command >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 ... >> Unexpected error - see ipaserver-install.log for details: >> {'desc': 'Invalid credentials'} > > Hmm, very strange. Can you look in > /var/log/dirsrv/slapd-MEYERING-NET/errors to see if it has anything? Sure. No trace of errors or anything suspicious in that file. > I'm not sure how this could happen. The Directory Server install > shouldn't have happened if you already had a server running there > (like openldap) so I'm not sure how it isn't authenticating the > directory manager. Unfortunately, after upgrading to latest rawhide, now it's failing even earlier. 2008-03-10 22:30:54,049 DEBUG [2/16]: creating directory server instance 2008-03-10 22:30:54,114 INFO 2008-03-10 22:30:54,114 INFO 2008-03-10 22:30:54,115 DEBUG Loading StateFile from \ '/var/cache/ipa/sysrestore.state' ... 2008-03-10 22:30:54,119 DEBUG calling setup-ds.pl 2008-03-10 22:30:54,223 INFO 2008-03-10 22:30:54,224 INFO Can't locate Mozilla/LDAP/Conn.pm in @INC (@INC contains: /usr/lib/dirsrv/perl /usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl .) at /usr/lib/dirsrv/perl/Setup.pm line 62. BEGIN failed--compilation aborted at /usr/lib/dirsrv/perl/Setup.pm line 62. Compilation failed in require at /usr/sbin/setup-ds.pl line 44. BEGIN failed--compilation aborted at /usr/sbin/setup-ds.pl line 44. 2008-03-10 22:30:54,224 CRITICAL failed to restart ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /dev/shm/tmpWAoNMK' returned non-zero exit status 2 The trouble is that the only Conn.pm available here is this: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Mozilla/LDAP/Conn.pm yet, that directory is not in @INC. When I added the required directory manually, by adding this line to setup-ds.pl, use lib qw(/usr/lib/perl5/5.8.8/i386-linux-thread-multi); it fails differently: 2008-03-10 22:22:24,384 INFO perl: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Mozilla/LDAP/API/API.so: undefined symbol: Perl_Tstack_sp_ptr From rmeggins at redhat.com Tue Mar 11 13:01:18 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Mar 2008 07:01:18 -0600 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <873aqx8zkw.fsf@rho.meyering.net> References: <87pru28dhw.fsf@rho.meyering.net> <47D5E581.3070204@redhat.com> <873aqx8zkw.fsf@rho.meyering.net> Message-ID: <47D6829E.2090402@redhat.com> Jim Meyering wrote: > Rob Crittenden wrote: > ... > >>> Configuring directory server: >>> [1/16]: creating directory server user >>> [2/16]: creating directory server instance >>> [3/16]: adding default schema >>> [4/16]: enabling memberof plugin >>> root : CRITICAL Failed to load memberof-conf.ldif: Command >>> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 >>> > ... > >>> Unexpected error - see ipaserver-install.log for details: >>> {'desc': 'Invalid credentials'} >>> >> Hmm, very strange. Can you look in >> /var/log/dirsrv/slapd-MEYERING-NET/errors to see if it has anything? >> > > Sure. > No trace of errors or anything suspicious in that file. > > >> I'm not sure how this could happen. The Directory Server install >> shouldn't have happened if you already had a server running there >> (like openldap) so I'm not sure how it isn't authenticating the >> directory manager. >> > > Unfortunately, after upgrading to latest rawhide, now it's failing > even earlier. > > 2008-03-10 22:30:54,049 DEBUG [2/16]: creating directory server instance > 2008-03-10 22:30:54,114 INFO > 2008-03-10 22:30:54,114 INFO > 2008-03-10 22:30:54,115 DEBUG Loading StateFile from \ > '/var/cache/ipa/sysrestore.state' > ... > 2008-03-10 22:30:54,119 DEBUG calling setup-ds.pl > 2008-03-10 22:30:54,223 INFO > 2008-03-10 22:30:54,224 INFO Can't locate Mozilla/LDAP/Conn.pm in @INC (@INC contains: /usr/lib/dirsrv/perl /usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl .) at /usr/lib/dirsrv/perl/Setup.pm line 62. > BEGIN failed--compilation aborted at /usr/lib/dirsrv/perl/Setup.pm line 62. > Compilation failed in require at /usr/sbin/setup-ds.pl line 44. > BEGIN failed--compilation aborted at /usr/sbin/setup-ds.pl line 44. > > 2008-03-10 22:30:54,224 CRITICAL failed to restart ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /dev/shm/tmpWAoNMK' returned non-zero exit status 2 > > The trouble is that the only Conn.pm available here is this: > > /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Mozilla/LDAP/Conn.pm > > yet, that directory is not in @INC. > When I added the required directory manually, by adding this > line to setup-ds.pl, > > use lib qw(/usr/lib/perl5/5.8.8/i386-linux-thread-multi); > > it fails differently: > > 2008-03-10 22:22:24,384 INFO perl: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Mozilla/LDAP/API/API.so: undefined symbol: Perl_Tstack_sp_ptr > Looks like the perl-Mozilla-LDAP package needs to be rebuilt in rawhide - they just pushed a new version of perl I believe. > _______________________________________________ > 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 jim at meyering.net Tue Mar 11 13:11:36 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 11 Mar 2008 14:11:36 +0100 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <47D6829E.2090402@redhat.com> (Rich Megginson's message of "Tue, 11 Mar 2008 07:01:18 -0600") References: <87pru28dhw.fsf@rho.meyering.net> <47D5E581.3070204@redhat.com> <873aqx8zkw.fsf@rho.meyering.net> <47D6829E.2090402@redhat.com> Message-ID: <87abl576d3.fsf@rho.meyering.net> [Hi Margaret, Just a heads-up that we probably need perl-Mozilla-LDAP to be rebuilt in rawhide, no doubt along with lots of other Perl packages. ] Rich Megginson wrote: > Jim Meyering wrote: >> Rob Crittenden wrote: >> ... ... >> Unfortunately, after upgrading to latest rawhide, now it's failing >> even earlier. >> >> 2008-03-10 22:30:54,049 DEBUG [2/16]: creating directory server instance >> 2008-03-10 22:30:54,114 INFO >> 2008-03-10 22:30:54,114 INFO >> 2008-03-10 22:30:54,115 DEBUG Loading StateFile from \ >> '/var/cache/ipa/sysrestore.state' >> ... >> 2008-03-10 22:30:54,119 DEBUG calling setup-ds.pl >> 2008-03-10 22:30:54,223 INFO >> 2008-03-10 22:30:54,224 INFO Can't locate Mozilla/LDAP/Conn.pm in @INC (@INC contains: /usr/lib/dirsrv/perl /usr/lib/perl5/5.10.0/i386-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl .) at /usr/lib/dirsrv/perl/Setup.pm line 62. >> BEGIN failed--compilation aborted at /usr/lib/dirsrv/perl/Setup.pm line 62. >> Compilation failed in require at /usr/sbin/setup-ds.pl line 44. >> BEGIN failed--compilation aborted at /usr/sbin/setup-ds.pl line 44. >> >> 2008-03-10 22:30:54,224 CRITICAL failed to restart ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /dev/shm/tmpWAoNMK' returned non-zero exit status 2 >> >> The trouble is that the only Conn.pm available here is this: >> >> /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Mozilla/LDAP/Conn.pm >> >> yet, that directory is not in @INC. >> When I added the required directory manually, by adding this >> line to setup-ds.pl, >> >> use lib qw(/usr/lib/perl5/5.8.8/i386-linux-thread-multi); >> >> it fails differently: >> >> 2008-03-10 22:22:24,384 INFO perl: symbol lookup error: /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/auto/Mozilla/LDAP/API/API.so: undefined symbol: Perl_Tstack_sp_ptr >> > Looks like the perl-Mozilla-LDAP package needs to be rebuilt in > rawhide - they just pushed a new version of perl I believe. Sounds like it. In which case it's probably already in progress. Just in case, I've Cc'd Margaret Lum. Thanks, Jim From rmeggins at redhat.com Tue Mar 11 15:42:30 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Mar 2008 09:42:30 -0600 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <87abl576d3.fsf@rho.meyering.net> References: <87pru28dhw.fsf@rho.meyering.net> <47D5E581.3070204@redhat.com> <873aqx8zkw.fsf@rho.meyering.net> <47D6829E.2090402@redhat.com> <87abl576d3.fsf@rho.meyering.net> Message-ID: <47D6A866.4010302@redhat.com> Jim Meyering wrote: > >> Looks like the perl-Mozilla-LDAP package needs to be rebuilt in >> rawhide - they just pushed a new version of perl I believe. >> > > Sounds like it. > In which case it's probably already in progress. > It didn't look like it, so I went ahead and built it. You should get it as soon as it's pushed out to your favorite mirror. > Just in case, I've Cc'd Margaret Lum. > > Thanks, > > Jim > -------------- 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 jim at meyering.net Tue Mar 11 16:33:37 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 11 Mar 2008 17:33:37 +0100 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <47D6A866.4010302@redhat.com> (Rich Megginson's message of "Tue, 11 Mar 2008 09:42:30 -0600") References: <87pru28dhw.fsf@rho.meyering.net> <47D5E581.3070204@redhat.com> <873aqx8zkw.fsf@rho.meyering.net> <47D6829E.2090402@redhat.com> <87abl576d3.fsf@rho.meyering.net> <47D6A866.4010302@redhat.com> Message-ID: <87abl55ify.fsf@rho.meyering.net> Rich Megginson wrote: > Jim Meyering wrote: >> >>> Looks like the perl-Mozilla-LDAP package needs to be rebuilt in >>> rawhide - they just pushed a new version of perl I believe. >>> >> >> Sounds like it. >> In which case it's probably already in progress. >> > It didn't look like it, so I went ahead and built it. You should get > it as soon as it's pushed out to your favorite mirror. Thanks! From mdehaan at redhat.com Thu Mar 13 22:20:33 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 13 Mar 2008 18:20:33 -0400 Subject: [Freeipa-devel] Building FreeIPA from Source Message-ID: <47D9A8B1.1040806@redhat.com> Hi, I'm trying to build FreeIPA from source because the F8 FreeIPA installer do not create a working configuration on my box (as I mentioned to rcrit, my box hung trying to speak to ldap at boot when run with the self-detected settings, and providing other values for realm caused it to crash). So, I did a checkout (fresh as of the time of sending this email), and am doing "make local-dist" with all the deps I need installed to generate the RPMs I need. I get this: http://freeipa.pastebin.com/m68ce17d6 RPM build errors: Bad owner/group: /cg/freeipa/ipa-server/ipa-server.spec make: *** [rpm-ipa-server] Error 1 I've grepped through all the specfiles and do not see any defattr's to anything other than "-" so I should have all of the users I need. Can someone please help me get around this? --Michael From mdehaan at redhat.com Fri Mar 14 17:25:35 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 14 Mar 2008 13:25:35 -0400 Subject: [Freeipa-devel] List of packages needed to be detected by configure Message-ID: <47DAB50F.1070603@redhat.com> I'm told there's a BZ on this, but here's my (possibly incomplete) list: "Development Tools" group + openldap-devel mozldap-devel fedora-ds-base-devel openssl-devel kr5-devel libcap-devel TurboGears popt-devel popt selinux-policy-devel The build seemed to like being run better as root originally, but now it seems to prefer non-root (good), and the error from yesterday has gone away. --Michael From ssorce at redhat.com Fri Mar 14 17:28:12 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 14 Mar 2008 13:28:12 -0400 Subject: [Freeipa-devel] [PATCH] Allow to pass an ntp server at client installation time Message-ID: <47DAB5AC.6040601@redhat.com> This allows to specify an ntp server name at installation time. Ideally it is a local DNS CNAME that points to multiple servers. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-721-config-ntp.patch Type: text/x-patch Size: 1442 bytes Desc: not available URL: From dqarras at yahoo.com Sun Mar 16 11:07:47 2008 From: dqarras at yahoo.com (Daniel Qarras) Date: Sun, 16 Mar 2008 04:07:47 -0700 (PDT) Subject: [Freeipa-devel] FreeIPA / Bandit Message-ID: <405308.76968.qm@web36802.mail.mud.yahoo.com> Hi all, just a quick innocent question from a lowly end-user: what do you think about the Bandit project(1)? To me it seems to be at least somewhat "overlapping" with FreeIPA. From their web page: Bandit is a set of components that provide consistent identity services for Authentication, Authorization, and Auditing. The Bandit project creates a community that organizes and standardizes identity-related technologies in an open way, promoting both interoperability and collaboration. 1) http://www.bandit-project.org/index.php/Welcome_to_Bandit Thanks! ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From ssorce at redhat.com Mon Mar 17 14:04:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Mar 2008 10:04:36 -0400 Subject: [Freeipa-devel] FreeIPA / Bandit In-Reply-To: <405308.76968.qm@web36802.mail.mud.yahoo.com> References: <405308.76968.qm@web36802.mail.mud.yahoo.com> Message-ID: <1205762676.29600.15.camel@localhost.localdomain> On Sun, 2008-03-16 at 04:07 -0700, Daniel Qarras wrote: > Hi all, > > just a quick innocent question from a lowly end-user: what do you think > about the Bandit project(1)? To me it seems to be at least somewhat > "overlapping" with FreeIPA. From their web page: > > Bandit is a set of components that provide consistent identity services > for Authentication, Authorization, and Auditing. The Bandit project > creates a community that organizes and standardizes identity-related > technologies in an open way, promoting both interoperability and > collaboration. > > 1) http://www.bandit-project.org/index.php/Welcome_to_Bandit >From what I can see Bandit is more concerned about "Web" Identity, or public Identity, FreeIPA instead is currently more focused on internal Enterprise Identity. I can see that there may be overlap in the future once FreeIPA will start looking into things like Federation. I guess we will keep an eye on Bandit and see if we can play well with each other at some point. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 17 16:24:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 12:24:15 -0400 Subject: [Freeipa-devel] [PATCH] verify sanity of /etc/hosts In-Reply-To: <47D035C3.7080403@redhat.com> References: <47D035C3.7080403@redhat.com> Message-ID: <47DE9B2F.3060105@redhat.com> Rob Crittenden wrote: > During ipa-server-install compare the hostname that DNS returned to the > hostname found in /etc/hosts. This should catch the cases where the > non-fully-qualified version appears first. > > Also fix a bitness issue on 64-bit platforms and don't ignore exceptions > when getting the hostname from the user. > > rob > I went ahead and pushed this. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Mar 17 16:24:33 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 12:24:33 -0400 Subject: [Freeipa-devel] [PATCH] restart replication agreement In-Reply-To: <47D067A3.4090503@redhat.com> References: <47D067A3.4090503@redhat.com> Message-ID: <47DE9B41.4060500@redhat.com> Rob Crittenden wrote: > Add ability to initialize a replication agreement > Clean up a lot of unused code in ipaldap.py. This lets us do a simple > bind without being root (it used to try to read dse.ldif) > This was reviewed by Rich M, pushed. -------------- 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 Mar 17 16:24:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 12:24:49 -0400 Subject: [Freeipa-devel] [PATCH] remove ACI preventing RDN change In-Reply-To: <47D5404C.60802@redhat.com> References: <47D5404C.60802@redhat.com> Message-ID: <47DE9B51.20009@redhat.com> Rob Crittenden wrote: > As a side-effect of this ACI, RDN changes were failing. It may be a bug > in FDS (they are looking into it). > > rob I pushed this. -------------- 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 Mar 17 16:25:00 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 12:25:00 -0400 Subject: [Freeipa-devel] [PATCH] uniq_list() needs to ignore all case In-Reply-To: <47D55601.1010103@redhat.com> References: <47D55601.1010103@redhat.com> Message-ID: <47DE9B5C.6080902@redhat.com> Rob Crittenden wrote: > The uniq_list function lets you create a unique list by casting it into > a Set. The problem is that the set wasn't being populated with > lower-case values so it was possible to end up with mixed-case duplicates. > > rob I pushed this. -------------- 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 Mar 17 17:19:46 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 13:19:46 -0400 Subject: [Freeipa-devel] [PATCH] Play nice with unconfigured systems Message-ID: <47DEA832.4010603@redhat.com> One can install the IPA client and admin tools onto a system but never run ipa-client-install. While not a good idea we need to handle this case. The problem starts with bogus values by default in /etc/ipa/ipa.conf. We need to remove them. This will end up causing a backtrace in the admin tools because we don't handle that kind of exception. I've put in a default Exception printer so we will never crap out like this. Finally, I tried to improve the error message returned. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-720-client.patch Type: text/x-patch Size: 8639 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 Mar 17 18:12:00 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 14:12:00 -0400 Subject: [Freeipa-devel] [PATCH] allow realm in call to add_service_principal() Message-ID: <47DEB470.3010509@redhat.com> Go ahead and allow @REALM to be included in the name sent into add_service_principal(). Just enforce that the realm is our own. This makes ipa-addservice a little more kerberos-like where one would expect the realm to be included. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-721-realm.patch Type: text/x-patch Size: 1757 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 Mar 17 19:01:46 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Mar 2008 15:01:46 -0400 Subject: [Freeipa-devel] [PATCH] Play nice with unconfigured systems In-Reply-To: <47DEA832.4010603@redhat.com> References: <47DEA832.4010603@redhat.com> Message-ID: <1205780506.29600.86.camel@localhost.localdomain> On Mon, 2008-03-17 at 13:19 -0400, Rob Crittenden wrote: > One can install the IPA client and admin tools onto a system but > never > run ipa-client-install. While not a good idea we need to handle this > case. The problem starts with bogus values by default in > /etc/ipa/ipa.conf. We need to remove them. > > This will end up causing a backtrace in the admin tools because we > don't > handle that kind of exception. I've put in a default Exception > printer > so we will never crap out like this. > > Finally, I tried to improve the error message returned. Ack! Very well done. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 17 19:02:35 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 17 Mar 2008 15:02:35 -0400 Subject: [Freeipa-devel] [PATCH] allow realm in call to add_service_principal() In-Reply-To: <47DEB470.3010509@redhat.com> References: <47DEB470.3010509@redhat.com> Message-ID: <1205780555.29600.88.camel@localhost.localdomain> On Mon, 2008-03-17 at 14:12 -0400, Rob Crittenden wrote: > Go ahead and allow @REALM to be included in the name sent into > add_service_principal(). Just enforce that the realm is our own. > > This makes ipa-addservice a little more kerberos-like where one would > expect the realm to be included. Ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 17 22:06:20 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 18:06:20 -0400 Subject: [Freeipa-devel] [PATCH] add some missing man pages Message-ID: <47DEEB5C.5020003@redhat.com> The install, replica and daemon programs were missing man pages. Here is a first cut at them. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-726-man.patch Type: text/x-patch Size: 22008 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 Mar 17 22:08:18 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 18:08:18 -0400 Subject: [Freeipa-devel] [PATCH] Allow to pass an ntp server at client installation time In-Reply-To: <47DAB5AC.6040601@redhat.com> References: <47DAB5AC.6040601@redhat.com> Message-ID: <47DEEBD2.9000304@redhat.com> Simo Sorce wrote: > This allows to specify an ntp server name at installation time. > Ideally it is a local DNS CNAME that points to multiple servers. > > Simo. > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Mar 17 22:08:47 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Mar 2008 18:08:47 -0400 Subject: [Freeipa-devel] [PATCH] allow realm in call to add_service_principal() In-Reply-To: <1205780555.29600.88.camel@localhost.localdomain> References: <47DEB470.3010509@redhat.com> <1205780555.29600.88.camel@localhost.localdomain> Message-ID: <47DEEBEF.2060206@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-17 at 14:12 -0400, Rob Crittenden wrote: >> Go ahead and allow @REALM to be included in the name sent into >> add_service_principal(). Just enforce that the realm is our own. >> >> This makes ipa-addservice a little more kerberos-like where one would >> expect the realm to be included. > > Ack. > Simo. > Pushed -------------- 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 Mar 19 17:27:26 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Mar 2008 13:27:26 -0400 Subject: [Freeipa-devel] [PATCH] Don't take over entire web root Message-ID: <47E14CFE.4080909@redhat.com> Set URL to /ipa for the web ui. This still takes over the whole root, so going to https://ipa.example.com/ will take you to our web UI, but this is easily disabled in /etc/httpd/conf.d/ipa-rewrite.conf. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-727-root.patch Type: text/x-patch Size: 4372 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 Mar 19 17:55:03 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 19 Mar 2008 13:55:03 -0400 Subject: [Freeipa-devel] [PATCH] Don't take over entire web root In-Reply-To: <47E14CFE.4080909@redhat.com> References: <47E14CFE.4080909@redhat.com> Message-ID: <47E15377.7060606@redhat.com> Rob Crittenden wrote: > Set URL to /ipa for the web ui. This still takes over the whole root, so > going to https://ipa.example.com/ will take you to our web UI, but this > is easily disabled in /etc/httpd/conf.d/ipa-rewrite.conf. > > rob Sigh. I had originally set the URI to /freeipa and it tested out just fine but at the last minute switched it to /ipa. This of course conflicts with the URI we have for the XML-RPC layer. I think I'll stick with /ipa for the UI and go to something else for XML-RPC. New patch forthcoming. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Mar 20 20:06:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 20 Mar 2008 16:06:14 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore Message-ID: <47E2C3B6.90906@redhat.com> This is in preparation to move it into ipa-python so that I can use sysrestore to make a client --uninstall option. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-734-better-sysrestore.patch Type: text/x-patch Size: 33355 bytes Desc: not available URL: From ssorce at redhat.com Thu Mar 20 20:29:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 20 Mar 2008 16:29:15 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <47E2C3B6.90906@redhat.com> References: <47E2C3B6.90906@redhat.com> Message-ID: <1206044955.9494.64.camel@localhost.localdomain> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: > This is in preparation to move it into ipa-python so that I can use > sysrestore to make a client --uninstall option. Arghh this one does not merge properly with latest code, let me fix it and resend. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Mar 20 20:19:39 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 20 Mar 2008 16:19:39 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <1206044955.9494.64.camel@localhost.localdomain> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> Message-ID: <47E2C6DB.20006@redhat.com> Simo Sorce wrote: > On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: >> This is in preparation to move it into ipa-python so that I can use >> sysrestore to make a client --uninstall option. > > Arghh this one does not merge properly with latest code, let me fix it > and resend. New patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-723-better-sysrestore.patch Type: text/x-patch Size: 33409 bytes Desc: not available URL: From rcritten at redhat.com Thu Mar 20 21:00:23 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Mar 2008 17:00:23 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <47E2C6DB.20006@redhat.com> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> <47E2C6DB.20006@redhat.com> Message-ID: <47E2D067.5020500@redhat.com> Simo Sorce wrote: > Simo Sorce wrote: >> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: >>> This is in preparation to move it into ipa-python so that I can use >>> sysrestore to make a client --uninstall option. >> >> Arghh this one does not merge properly with latest code, let me fix it >> and resend. > > New patch attached. > You are completely doing away with these restores? @@ -188,9 +192,6 @@ class HTTPInstance(service.Service): if not enabled is None and not enabled: self.chkconfig_off() - for f in ["/etc/httpd/conf.d/ipa.conf", SSL_CONF, NSS_CONF]: - sysrestore.restore_file(f) - sebool_state = self.restore_state("httpd_can_network_connect") if not sebool_state is None: try: @@ -389,18 +394,5 @@ class KrbInstance(service.Service): if not enabled is None and not enabled: self.chkconfig_off() - for f in ["/var/kerberos/krb5kdc/ldappwd", - "/var/kerberos/krb5kdc/kdc.conf", - "/etc/krb5.conf", - "/usr/share/ipa/html/krb5.ini", - "/usr/share/ipa/html/krb.con", - "/usr/share/ipa/html/krbrealm.con", - "/etc/dirsrv/ds.keytab", - "/etc/sysconfig/dirsrv", - "/etc/krb5.keytab", - "/var/kerberos/krb5kdc/kpasswd.keytab", - "/etc/sysconfig/ipa_kpasswd"]: - sysrestore.restore_file(f) -------------- 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 Mar 20 21:50:44 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Mar 2008 17:50:44 -0400 Subject: [Freeipa-devel] [PATCH] Don't take over entire web root In-Reply-To: <47E15377.7060606@redhat.com> References: <47E14CFE.4080909@redhat.com> <47E15377.7060606@redhat.com> Message-ID: <47E2DC34.4080501@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Set URL to /ipa for the web ui. This still takes over the whole root, >> so going to https://ipa.example.com/ will take you to our web UI, but >> this is easily disabled in /etc/httpd/conf.d/ipa-rewrite.conf. >> >> rob > > Sigh. I had originally set the URI to /freeipa and it tested out just > fine but at the last minute switched it to /ipa. This of course > conflicts with the URI we have for the XML-RPC layer. I think I'll stick > with /ipa for the UI and go to something else for XML-RPC. New patch > forthcoming. New patch attached. The XML-RPC API moved to /ipaxml. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-727-webroot.patch Type: text/x-patch Size: 6991 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 Mar 20 23:39:42 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 20 Mar 2008 19:39:42 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <47E2D067.5020500@redhat.com> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> <47E2C6DB.20006@redhat.com> <47E2D067.5020500@redhat.com> Message-ID: <1206056383.9494.66.camel@localhost.localdomain> On Thu, 2008-03-20 at 17:00 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Simo Sorce wrote: > >> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: > >>> This is in preparation to move it into ipa-python so that I can use > >>> sysrestore to make a client --uninstall option. > >> > >> Arghh this one does not merge properly with latest code, let me fix it > >> and resend. > > > > New patch attached. > > > > > You are completely doing away with these restores? There is one big restore in the main script now, as we keep track of every file it made little sense to me to do the restores one by one. Simo. -- Simo Sorce * Red Hat, Inc * New York From mike at flyn.org Mon Mar 24 08:49:31 2008 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 24 Mar 2008 13:19:31 +0430 Subject: [Freeipa-devel] Question about pam_krb5 and FreeIPA In-Reply-To: <20080310183013.GB12368@redhat.com> References: <20080309194555.GA17859@imp.flyn.org> <20080310183013.GB12368@redhat.com> Message-ID: <20080324084931.GA20039@imp.flyn.org> >> Unlike Apache, pam_krb5 does not seem to require a service key. My >> understanding is that the service key is used to ensure that the Kerberos >> server is not being spoofed. Could anyone explain why pam_krb5 does not >> seem to require a service key? Is this optional? > Generally, yes, you want to validate against a local key. > > More often, though, there is no such key available, so the module uses a > local key it if it can read the configured keytab file, and otherwise it > can only hope that the local administrators know what they're doing. I've submitted a patch to pam_krb5, https://bugzilla.redhat.com/show_bug.cgi?id=436747. This patch allows pam_krb5 to use a SUID helper application to validate credentials using a keytab, even when the application itself is not running as root (e.g., xscreensaver). -- Mike :wq From rcritten at redhat.com Mon Mar 24 13:02:56 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 09:02:56 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <1206056383.9494.66.camel@localhost.localdomain> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> <47E2C6DB.20006@redhat.com> <47E2D067.5020500@redhat.com> <1206056383.9494.66.camel@localhost.localdomain> Message-ID: <47E7A680.6020504@redhat.com> Simo Sorce wrote: > On Thu, 2008-03-20 at 17:00 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> Simo Sorce wrote: >>>> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: >>>>> This is in preparation to move it into ipa-python so that I can use >>>>> sysrestore to make a client --uninstall option. >>>> Arghh this one does not merge properly with latest code, let me fix it >>>> and resend. >>> New patch attached. >>> >> >> You are completely doing away with these restores? > > There is one big restore in the main script now, as we keep track of > every file it made little sense to me to do the restores one by one. > > Simo. > Ok, ack then. -------------- 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 Mar 24 13:21:31 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 09:21:31 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <47E7A680.6020504@redhat.com> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> <47E2C6DB.20006@redhat.com> <47E2D067.5020500@redhat.com> <1206056383.9494.66.camel@localhost.localdomain> <47E7A680.6020504@redhat.com> Message-ID: <1206364891.29938.8.camel@localhost.localdomain> On Mon, 2008-03-24 at 09:02 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2008-03-20 at 17:00 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> Simo Sorce wrote: > >>>> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: > >>>>> This is in preparation to move it into ipa-python so that I can use > >>>>> sysrestore to make a client --uninstall option. > >>>> Arghh this one does not merge properly with latest code, let me fix it > >>>> and resend. > >>> New patch attached. > >>> > >> > >> You are completely doing away with these restores? > > > > There is one big restore in the main script now, as we keep track of > > every file it made little sense to me to do the restores one by one. > > > > Simo. > > > > Ok, ack then. I have been thinking about this during the weekend, and it came to mind that we may be restarting some daemon during uninstall. Should we delay restarts after files are restored ? I guess daemons may want to see the original files. what do you think? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 24 13:24:50 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 09:24:50 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <1206364891.29938.8.camel@localhost.localdomain> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> <47E2C6DB.20006@redhat.com> <47E2D067.5020500@redhat.com> <1206056383.9494.66.camel@localhost.localdomain> <47E7A680.6020504@redhat.com> <1206364891.29938.8.camel@localhost.localdomain> Message-ID: <47E7ABA2.9070700@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-24 at 09:02 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2008-03-20 at 17:00 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> Simo Sorce wrote: >>>>>> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: >>>>>>> This is in preparation to move it into ipa-python so that I can use >>>>>>> sysrestore to make a client --uninstall option. >>>>>> Arghh this one does not merge properly with latest code, let me fix it >>>>>> and resend. >>>>> New patch attached. >>>>> >>>> You are completely doing away with these restores? >>> There is one big restore in the main script now, as we keep track of >>> every file it made little sense to me to do the restores one by one. >>> >>> Simo. >>> >> Ok, ack then. > > I have been thinking about this during the weekend, and it came to mind > that we may be restarting some daemon during uninstall. Should we delay > restarts after files are restored ? I guess daemons may want to see the > original files. > > what do you think? > > Simo. > Yes, I think that the current running process should match the config on disk. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Mar 24 13:33:57 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 09:33:57 -0400 Subject: [Freeipa-devel] [PATCH] enhance sysrestore In-Reply-To: <47E7ABA2.9070700@redhat.com> References: <47E2C3B6.90906@redhat.com> <1206044955.9494.64.camel@localhost.localdomain> <47E2C6DB.20006@redhat.com> <47E2D067.5020500@redhat.com> <1206056383.9494.66.camel@localhost.localdomain> <47E7A680.6020504@redhat.com> <1206364891.29938.8.camel@localhost.localdomain> <47E7ABA2.9070700@redhat.com> Message-ID: <1206365637.29938.10.camel@localhost.localdomain> On Mon, 2008-03-24 at 09:24 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2008-03-24 at 09:02 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Thu, 2008-03-20 at 17:00 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> Simo Sorce wrote: > >>>>>> On Thu, 2008-03-20 at 16:06 -0400, Simo Sorce wrote: > >>>>>>> This is in preparation to move it into ipa-python so that I can use > >>>>>>> sysrestore to make a client --uninstall option. > >>>>>> Arghh this one does not merge properly with latest code, let me fix it > >>>>>> and resend. > >>>>> New patch attached. > >>>>> > >>>> You are completely doing away with these restores? > >>> There is one big restore in the main script now, as we keep track of > >>> every file it made little sense to me to do the restores one by one. > >>> > >>> Simo. > >>> > >> Ok, ack then. > > > > I have been thinking about this during the weekend, and it came to mind > > that we may be restarting some daemon during uninstall. Should we delay > > restarts after files are restored ? I guess daemons may want to see the > > original files. > > > > what do you think? > > > > Simo. > > > > Yes, I think that the current running process should match the config on > disk. Ok In this case I'll put back 1 by 1 restore of files for daemons we restart, and leave a global restore in the main only for stuff that is not affected by a restart. New patch soon. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 24 14:54:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 10:54:16 -0400 Subject: [Freeipa-devel] [PATCH] allow password changes to be delegated Message-ID: <47E7C098.20805@redhat.com> We are really changing the kerberos principal key and not the password when we do updates, so use the right terminology internally. Also fix the actual field we update (and grant permission appropriately in delegations). The DS password handles updating userPassword and any Samba passwords as necessary. This was driven from the fact that a delegated password change would fail because of incorrect permissions. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-728-password.patch Type: text/x-patch Size: 13877 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 Mar 24 15:03:56 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 11:03:56 -0400 Subject: [Freeipa-devel] [PATCH] startup order in ipactl Message-ID: <47E7C2DC.8070100@redhat.com> Start ntpd after FDS so that the ntp user can be found. Start httpd after ipa_webgui becuse otherwise mod_proxy may not like it if it can't connect to the UI listening port rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-729-ipactl.patch Type: text/x-patch Size: 906 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 Mar 24 15:34:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 11:34:18 -0400 Subject: [Freeipa-devel] [PATCH] startup order in ipactl In-Reply-To: <47E7C2DC.8070100@redhat.com> References: <47E7C2DC.8070100@redhat.com> Message-ID: <1206372858.29938.22.camel@localhost.localdomain> On Mon, 2008-03-24 at 11:03 -0400, Rob Crittenden wrote: > Start ntpd after FDS so that the ntp user can be found. > Start httpd after ipa_webgui becuse otherwise mod_proxy may not like > it > if it can't connect to the UI listening port ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 24 15:34:37 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 11:34:37 -0400 Subject: [Freeipa-devel] [PATCH] allow password changes to be delegated In-Reply-To: <47E7C098.20805@redhat.com> References: <47E7C098.20805@redhat.com> Message-ID: <1206372877.29938.24.camel@localhost.localdomain> On Mon, 2008-03-24 at 10:54 -0400, Rob Crittenden wrote: > We are really changing the kerberos principal key and not the > password > when we do updates, so use the right terminology internally. Also fix > the actual field we update (and grant permission appropriately in > delegations). > > The DS password handles updating userPassword and any Samba passwords > as necessary. > > This was driven from the fact that a delegated password change would > fail because of incorrect permissions. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 24 16:34:47 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 12:34:47 -0400 Subject: [Freeipa-devel] [PATCH] Don't take over entire web root In-Reply-To: <47E2DC34.4080501@redhat.com> References: <47E14CFE.4080909@redhat.com> <47E15377.7060606@redhat.com> <47E2DC34.4080501@redhat.com> Message-ID: <1206376487.29938.35.camel@localhost.localdomain> On Thu, 2008-03-20 at 17:50 -0400, Rob Crittenden wrote: > Rob Crittenden wrote: > > Rob Crittenden wrote: > >> Set URL to /ipa for the web ui. This still takes over the whole root, > >> so going to https://ipa.example.com/ will take you to our web UI, but > >> this is easily disabled in /etc/httpd/conf.d/ipa-rewrite.conf. > >> > >> rob > > > > Sigh. I had originally set the URI to /freeipa and it tested out just > > fine but at the last minute switched it to /ipa. This of course > > conflicts with the URI we have for the XML-RPC layer. I think I'll stick > > with /ipa for the UI and go to something else for XML-RPC. New patch > > forthcoming. > > New patch attached. The XML-RPC API moved to /ipaxml. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 24 16:59:12 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 12:59:12 -0400 Subject: [Freeipa-devel] [PATCH] Use different log file for uninstall Message-ID: <47E7DDE0.4050308@redhat.com> This patch makes ipa-server-install use a different file for uninstall logs so that we do not overwrite the installation one and can compare the info contained in both. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-725-uninst-own-log.patch Type: text/x-patch Size: 1171 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 24 17:19:43 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 13:19:43 -0400 Subject: [Freeipa-devel] [PATCH] Use different log file for uninstall In-Reply-To: <47E7DDE0.4050308@redhat.com> References: <47E7DDE0.4050308@redhat.com> Message-ID: <47E7E2AF.8000404@redhat.com> Simo Sorce wrote: > This patch makes ipa-server-install use a different file for uninstall > logs so that we do not overwrite the installation one and can compare > the info contained in both. > > Simo. > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Mar 24 19:47:12 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 15:47:12 -0400 Subject: [Freeipa-devel] [PATCH] editors can update objectclass Message-ID: <47E80540.2050307@redhat.com> We have a set of default objectclasses for users and groups. When a user/group is updated their current set of OC's is compared against the one stored in ipaconfig and if different it is updated. The problem is that delegated users may be requesting the change which will fail due to insufficient permissions on the objectclass attribute. This ACI will let them write. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-730-objectclass.patch Type: text/x-patch Size: 1198 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 Mar 24 19:59:00 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 15:59:00 -0400 Subject: [Freeipa-devel] [PATCH] add some missing man pages In-Reply-To: <47DEEB5C.5020003@redhat.com> References: <47DEEB5C.5020003@redhat.com> Message-ID: <47E80804.4060603@redhat.com> Rob Crittenden wrote: > The install, replica and daemon programs were missing man pages. Here is > a first cut at them. > > rob Pushed. These are just man pages, I see it as relatively low risk. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Mar 24 20:45:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 24 Mar 2008 16:45:03 -0400 Subject: [Freeipa-devel] [PATCH] editors can update objectclass In-Reply-To: <47E80540.2050307@redhat.com> References: <47E80540.2050307@redhat.com> Message-ID: <1206391503.29938.230.camel@localhost.localdomain> On Mon, 2008-03-24 at 15:47 -0400, Rob Crittenden wrote: > We have a set of default objectclasses for users and groups. When a > user/group is updated their current set of OC's is compared against > the > one stored in ipaconfig and if different it is updated. > > The problem is that delegated users may be requesting the change > which > will fail due to insufficient permissions on the objectclass > attribute. > This ACI will let them write. This is exactly the problem I anticipated when we discussed this "auto-update" feature. I'd like to NACK this way of solving the problem because it will solve it only for a subset of all possible situations. In fact if the missing objectclass has a MUST attribute the delegated user do not have access to (say a special password or something like that), we are back to the same problem. Personally I think we should not "auto-update" user entries, as I see legitimate cases when someone may want to have "exceptions", and auto-updates are very bad in this case as they do not understand what an exception is. I see that it might be useful to have the option of being able to update a user entry with new default objectclasses but I think this should be intentional, and can be done by adding a checkbox or something like that an editor can select. If the editor has enough rights it will be able to add the new stuff otherwise it's not in his rights anyway. Maybe we can check if the specific user has access to the objectclass using GRE and show/not show the checkbox depending on that. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 24 21:04:47 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 17:04:47 -0400 Subject: [Freeipa-devel] [PATCH] Don't require Find when editing delegations Message-ID: <47E8176F.1010205@redhat.com> When adding a delegation you can just enter the CN of the group without doing a Find. The edit page required a Find. This makes them both work the same way. Also fixed a bug where on errors it was returning to the new screen rather than update. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-731-delegation.patch Type: text/x-patch Size: 3087 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 Mar 24 21:14:40 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 24 Mar 2008 17:14:40 -0400 Subject: [Freeipa-devel] [PATCH] editors can update objectclass In-Reply-To: <1206391503.29938.230.camel@localhost.localdomain> References: <47E80540.2050307@redhat.com> <1206391503.29938.230.camel@localhost.localdomain> Message-ID: <47E819C0.7040002@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-24 at 15:47 -0400, Rob Crittenden wrote: >> We have a set of default objectclasses for users and groups. When a >> user/group is updated their current set of OC's is compared against >> the >> one stored in ipaconfig and if different it is updated. >> >> The problem is that delegated users may be requesting the change >> which >> will fail due to insufficient permissions on the objectclass >> attribute. >> This ACI will let them write. > > This is exactly the problem I anticipated when we discussed this > "auto-update" feature. > > I'd like to NACK this way of solving the problem because it will solve > it only for a subset of all possible situations. In fact if the missing > objectclass has a MUST attribute the delegated user do not have access > to (say a special password or something like that), we are back to the > same problem. Well, at least we aren't at the 11th hour on this. > Personally I think we should not "auto-update" user entries, as I see > legitimate cases when someone may want to have "exceptions", and > auto-updates are very bad in this case as they do not understand what an > exception is. > > I see that it might be useful to have the option of being able to update > a user entry with new default objectclasses but I think this should be > intentional, and can be done by adding a checkbox or something like that > an editor can select. > > If the editor has enough rights it will be able to add the new stuff > otherwise it's not in his rights anyway. > > Maybe we can check if the specific user has access to the objectclass > using GRE and show/not show the checkbox depending on that. We can do that in the future but I'm not prepared to add that for v1.0. 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 Mar 25 13:48:48 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Mar 2008 09:48:48 -0400 Subject: [Freeipa-devel] [PATCH] more detail on errors in UI Message-ID: <47E902C0.8070906@redhat.com> Add additional detail to error messages. This runs the risk of showing too much and confusing users but on the other hand it often includes required information detailing why the error occurred such as what attribute the user lacks write access too and why changing a password failed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-732-errors.patch Type: text/x-patch Size: 15504 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 Mar 25 18:09:51 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 25 Mar 2008 14:09:51 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files Message-ID: <47E93FEF.9020703@redhat.com> This patch adds configure, makefile and spec files so that a RHEL4 package can be built. It also fixes a bug in the local copy of ipachangeconf.py -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-727-rhel4-setup.patch Type: text/x-patch Size: 46842 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 25 19:03:35 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Mar 2008 15:03:35 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <47E93FEF.9020703@redhat.com> References: <47E93FEF.9020703@redhat.com> Message-ID: <47E94C87.8090502@redhat.com> Simo Sorce wrote: > This patch adds configure, makefile and spec files so that a RHEL4 > package can be built. > It also fixes a bug in the local copy of ipachangeconf.py I don't think we need to include aclocal.m4. Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? It generally looks ok but why did you remove the /etc/hosts check? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Mar 25 19:19:59 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 25 Mar 2008 15:19:59 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <47E94C87.8090502@redhat.com> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> Message-ID: <1206472799.29938.1717.camel@localhost.localdomain> On Tue, 2008-03-25 at 15:03 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > This patch adds configure, makefile and spec files so that a RHEL4 > > package can be built. > > It also fixes a bug in the local copy of ipachangeconf.py > > I don't think we need to include aclocal.m4. autoconf on RHEL4 was complaining, I had to run aclocal (which generated aclocal.m4) to make it work. I am not expert so if you say it is ok not put that in I will remove it. > Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? No idea, it depends only on how you build the tarball from which the psec file builds the package I guess. > It generally looks ok but why did you remove the /etc/hosts check? Arrghh, that part was not supposed to be in this patch, sorry, I will re-send without aclocal.m4 and without that part which is part of another patch I am preparing. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Mar 25 19:41:22 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Mar 2008 15:41:22 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <1206472799.29938.1717.camel@localhost.localdomain> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> <1206472799.29938.1717.camel@localhost.localdomain> Message-ID: <47E95562.1060804@redhat.com> Simo Sorce wrote: > On Tue, 2008-03-25 at 15:03 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> This patch adds configure, makefile and spec files so that a RHEL4 >>> package can be built. >>> It also fixes a bug in the local copy of ipachangeconf.py >> I don't think we need to include aclocal.m4. > > autoconf on RHEL4 was complaining, I had to run aclocal (which generated > aclocal.m4) to make it work. I am not expert so if you say it is ok not > put that in I will remove it. > >> Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? > > No idea, it depends only on how you build the tarball from which the > psec file builds the package I guess. > >> It generally looks ok but why did you remove the /etc/hosts check? > > Arrghh, that part was not supposed to be in this patch, sorry, I will > re-send without aclocal.m4 and without that part which is part of > another patch I am preparing. I pointed out aclocal.m4 only because it wasn't included in the other directories not out of some great well of auto* knowledge :-) I do think one can run aclocal and get the file created though. I'll see if I can dig up a RHEL 4 server somewhere and verify. 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 Mar 25 19:56:05 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 25 Mar 2008 15:56:05 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <47E95562.1060804@redhat.com> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> <1206472799.29938.1717.camel@localhost.localdomain> <47E95562.1060804@redhat.com> Message-ID: <47E958D5.7020906@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> On Tue, 2008-03-25 at 15:03 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> This patch adds configure, makefile and spec files so that a RHEL4 >>>> package can be built. >>>> It also fixes a bug in the local copy of ipachangeconf.py >>> I don't think we need to include aclocal.m4. >> >> autoconf on RHEL4 was complaining, I had to run aclocal (which generated >> aclocal.m4) to make it work. I am not expert so if you say it is ok not >> put that in I will remove it. >> >>> Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? >> >> No idea, it depends only on how you build the tarball from which the >> psec file builds the package I guess. >> >>> It generally looks ok but why did you remove the /etc/hosts check? >> >> Arrghh, that part was not supposed to be in this patch, sorry, I will >> re-send without aclocal.m4 and without that part which is part of >> another patch I am preparing. > > I pointed out aclocal.m4 only because it wasn't included in the other > directories not out of some great well of auto* knowledge :-) > > I do think one can run aclocal and get the file created though. I'll see > if I can dig up a RHEL 4 server somewhere and verify. > > rob Ok, here is what I did: % aclocal % automake --foreign -ac % autoconf I didn't test much beyond that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Mar 25 19:44:04 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 25 Mar 2008 15:44:04 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <1206472799.29938.1717.camel@localhost.localdomain> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> <1206472799.29938.1717.camel@localhost.localdomain> Message-ID: <47E95604.6040603@redhat.com> Simo Sorce wrote: > On Tue, 2008-03-25 at 15:03 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> This patch adds configure, makefile and spec files so that a RHEL4 >>> package can be built. >>> It also fixes a bug in the local copy of ipachangeconf.py >> I don't think we need to include aclocal.m4. > > autoconf on RHEL4 was complaining, I had to run aclocal (which generated > aclocal.m4) to make it work. I am not expert so if you say it is ok not > put that in I will remove it. > >> Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? > > No idea, it depends only on how you build the tarball from which the > psec file builds the package I guess. > >> It generally looks ok but why did you remove the /etc/hosts check? > > Arrghh, that part was not supposed to be in this patch, sorry, I will > re-send without aclocal.m4 and without that part which is part of > another patch I am preparing. > > Simo. > New patch -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-727-rhel4-setup.patch Type: text/x-patch Size: 7077 bytes Desc: not available URL: From ssorce at redhat.com Tue Mar 25 20:16:10 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 25 Mar 2008 16:16:10 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <47E958D5.7020906@redhat.com> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> <1206472799.29938.1717.camel@localhost.localdomain> <47E95562.1060804@redhat.com> <47E958D5.7020906@redhat.com> Message-ID: <1206476170.29938.1777.camel@localhost.localdomain> On Tue, 2008-03-25 at 15:56 -0400, Rob Crittenden wrote: > Rob Crittenden wrote: > > Simo Sorce wrote: > >> On Tue, 2008-03-25 at 15:03 -0400, Rob Crittenden wrote: > >>> Simo Sorce wrote: > >>>> This patch adds configure, makefile and spec files so that a RHEL4 > >>>> package can be built. > >>>> It also fixes a bug in the local copy of ipachangeconf.py > >>> I don't think we need to include aclocal.m4. > >> > >> autoconf on RHEL4 was complaining, I had to run aclocal (which generated > >> aclocal.m4) to make it work. I am not expert so if you say it is ok not > >> put that in I will remove it. > >> > >>> Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? > >> > >> No idea, it depends only on how you build the tarball from which the > >> psec file builds the package I guess. > >> > >>> It generally looks ok but why did you remove the /etc/hosts check? > >> > >> Arrghh, that part was not supposed to be in this patch, sorry, I will > >> re-send without aclocal.m4 and without that part which is part of > >> another patch I am preparing. > > > > I pointed out aclocal.m4 only because it wasn't included in the other > > directories not out of some great well of auto* knowledge :-) > > > > I do think one can run aclocal and get the file created though. I'll see > > if I can dig up a RHEL 4 server somewhere and verify. > > > > rob > > Ok, here is what I did: > > % aclocal > % automake --foreign -ac > % autoconf This is what I did on the RHEL4 system as well. I guess we can put it into the README eventually. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Mar 26 15:37:02 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Mar 2008 11:37:02 -0400 Subject: [Freeipa-devel] [PATCH] more flexible group membership querying Message-ID: <47EA6D9E.3020708@redhat.com> When getting members let user indicate what type of member they want. The memberOf attribute includes members that are directly in the group via the "member" attribute and those that are included as a result of being in a group that is in the group. The UI needs to be able to distinguish between the two so it can determine whether a user/group can be removed or not. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-733-members.patch Type: text/x-patch Size: 13693 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 Mar 26 20:37:26 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Mar 2008 16:37:26 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <47E95604.6040603@redhat.com> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> <1206472799.29938.1717.camel@localhost.localdomain> <47E95604.6040603@redhat.com> Message-ID: <47EAB406.1000506@redhat.com> Simo Sorce wrote: > Simo Sorce wrote: >> On Tue, 2008-03-25 at 15:03 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> This patch adds configure, makefile and spec files so that a RHEL4 >>>> package can be built. >>>> It also fixes a bug in the local copy of ipachangeconf.py >>> I don't think we need to include aclocal.m4. >> >> autoconf on RHEL4 was complaining, I had to run aclocal (which generated >> aclocal.m4) to make it work. I am not expert so if you say it is ok not >> put that in I will remove it. >> >>> Is there a way to pull in ipa.conf from freeipa/ipa-python/ipa.conf? >> >> No idea, it depends only on how you build the tarball from which the >> psec file builds the package I guess. >> >>> It generally looks ok but why did you remove the /etc/hosts check? >> >> Arrghh, that part was not supposed to be in this patch, sorry, I will >> re-send without aclocal.m4 and without that part which is part of >> another patch I am preparing. >> >> Simo. >> > > New patch > Looks good 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 Mar 26 20:43:31 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Mar 2008 16:43:31 -0400 Subject: [Freeipa-devel] [PATCH] make memberof task public Message-ID: <47EAB573.8020600@redhat.com> We need to run the memberof task whenever we initialize a replica database so I've made memberof public. We also need to be able to instantiate a DSinstance without running the whole installer. And I've added a new item to the dictionary, TIME, so we can guarantee RDN uniqueness. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-735-memberof.patch Type: text/x-patch Size: 6713 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 Wed Mar 26 21:28:00 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 Mar 2008 17:28:00 -0400 Subject: [Freeipa-devel] [PATCH] rhel4 package files In-Reply-To: <47EAB406.1000506@redhat.com> References: <47E93FEF.9020703@redhat.com> <47E94C87.8090502@redhat.com> <1206472799.29938.1717.camel@localhost.localdomain> <47E95604.6040603@redhat.com> <47EAB406.1000506@redhat.com> Message-ID: <1206566880.29938.3310.camel@localhost.localdomain> On Wed, 2008-03-26 at 16:37 -0400, Rob Crittenden wrote: > > New patch > Looks good Pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 26 21:29:41 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 Mar 2008 17:29:41 -0400 Subject: [Freeipa-devel] [PATCH] Use different log file for uninstall In-Reply-To: <47E7E2AF.8000404@redhat.com> References: <47E7DDE0.4050308@redhat.com> <47E7E2AF.8000404@redhat.com> Message-ID: <1206566981.29938.3314.camel@localhost.localdomain> On Mon, 2008-03-24 at 13:19 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > This patch makes ipa-server-install use a different file for uninstall > > logs so that we do not overwrite the installation one and can compare > > the info contained in both. > > > > Simo. > > > > > ack pushed. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 26 21:30:55 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 Mar 2008 17:30:55 -0400 Subject: [Freeipa-devel] [PATCH] more detail on errors in UI In-Reply-To: <47E902C0.8070906@redhat.com> References: <47E902C0.8070906@redhat.com> Message-ID: <1206567055.29938.3317.camel@localhost.localdomain> On Tue, 2008-03-25 at 09:48 -0400, Rob Crittenden wrote: > Add additional detail to error messages. > > This runs the risk of showing too much and confusing users but on the > other hand it often includes required information detailing why the > error occurred such as what attribute the user lacks write access too > and why changing a password failed. ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 26 21:40:52 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 Mar 2008 17:40:52 -0400 Subject: [Freeipa-devel] [PATCH] more flexible group membership querying In-Reply-To: <47EA6D9E.3020708@redhat.com> References: <47EA6D9E.3020708@redhat.com> Message-ID: <1206567652.29938.3331.camel@localhost.localdomain> On Wed, 2008-03-26 at 11:37 -0400, Rob Crittenden wrote: > + if e.dn not in real_members: > + if membertype == 2: > + entries.append(self.convert_entry(e)) > + else: > + if membertype == 1: > + entries.append(self.convert_entry(e)) > + Shouldn't the second be a removal ? You defined 1 as: "only direct members" so indirect ones should be removed right ? Also it would be a bit less confusing to use direct_members instead of real_members, but this is just taste. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Mar 26 21:44:02 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 Mar 2008 17:44:02 -0400 Subject: [Freeipa-devel] [PATCH] make memberof task public In-Reply-To: <47EAB573.8020600@redhat.com> References: <47EAB573.8020600@redhat.com> Message-ID: <1206567842.29938.3336.camel@localhost.localdomain> On Wed, 2008-03-26 at 16:43 -0400, Rob Crittenden wrote: > We need to run the memberof task whenever we initialize a replica > database so I've made memberof public. > > We also need to be able to instantiate a DSinstance without running > the > whole installer. > > And I've added a new item to the dictionary, TIME, so we can > guarantee > RDN uniqueness. ack -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Wed Mar 26 22:11:56 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 26 Mar 2008 15:11:56 -0700 Subject: [Freeipa-devel] [PATCH] Make memberOf handle group renames properly for indirect members Message-ID: <47EACA2C.8060007@redhat.com> The memberOf attribute was not being properly updated for indirect members of a group when it is renamed. The old name would be removed, but a new memberOf attribute using the new group name was not being added. This was being caused by not calling the appropriate function to perform the replace operation. -NGK -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-731-memberof.patch Type: text/x-patch Size: 1267 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Mar 26 22:15:55 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 26 Mar 2008 18:15:55 -0400 Subject: [Freeipa-devel] [PATCH] Make memberOf handle group renames properly for indirect members In-Reply-To: <47EACA2C.8060007@redhat.com> References: <47EACA2C.8060007@redhat.com> Message-ID: <1206569755.29938.3370.camel@localhost.localdomain> On Wed, 2008-03-26 at 15:11 -0700, Nathan Kinder wrote: > The memberOf attribute was not being properly updated for indirect > members of a group when it is renamed. The old name would be > removed, > but a new memberOf attribute using the new group name was not being > added. > > This was being caused by not calling the appropriate function to > perform > the replace operation. well spotted, ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Wed Mar 26 22:30:30 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 26 Mar 2008 15:30:30 -0700 Subject: [Freeipa-devel] [PATCH] Make memberOf handle group renames properly for indirect members In-Reply-To: <1206569755.29938.3370.camel@localhost.localdomain> References: <47EACA2C.8060007@redhat.com> <1206569755.29938.3370.camel@localhost.localdomain> Message-ID: <47EACE86.7030905@redhat.com> Simo Sorce wrote: > On Wed, 2008-03-26 at 15:11 -0700, Nathan Kinder wrote: > >> The memberOf attribute was not being properly updated for indirect >> members of a group when it is renamed. The old name would be >> removed, >> but a new memberOf attribute using the new group name was not being >> added. >> >> This was being caused by not calling the appropriate function to >> perform >> the replace operation. >> > > well spotted, > ack. > I don't have access to push this. Would you or Rob kindly push it? I've checked this in upstream in the Fedora DS CVS repo. -NGK > Simo. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Mar 27 03:21:52 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Mar 2008 23:21:52 -0400 Subject: [Freeipa-devel] [PATCH] normalize RDNs when considering group membership Message-ID: <47EB12D0.1050707@redhat.com> When we are displaying the group membership, normalize the RDN before figuring out if they are a direct or inherited member. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-737-normalize.patch Type: text/x-patch Size: 1100 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 Mar 27 12:44:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 08:44:04 -0400 Subject: [Freeipa-devel] [PATCH] more flexible group membership querying In-Reply-To: <1206567652.29938.3331.camel@localhost.localdomain> References: <47EA6D9E.3020708@redhat.com> <1206567652.29938.3331.camel@localhost.localdomain> Message-ID: <47EB9694.3000206@redhat.com> Simo Sorce wrote: > On Wed, 2008-03-26 at 11:37 -0400, Rob Crittenden wrote: >> + if e.dn not in real_members: >> + if membertype == 2: >> + entries.append(self.convert_entry(e)) >> + else: >> + if membertype == 1: >> + entries.append(self.convert_entry(e)) >> + > > Shouldn't the second be a removal ? > You defined 1 as: "only direct members" so indirect ones should be > removed right ? No, the list starts out as empty. If they are not a real/direct member and we're only looking for the inherited/indirect members then they get appended to the list in the first case. Otherwise if the are in the list and those are what we're looking for, we append them. > > Also it would be a bit less confusing to use direct_members instead of > real_members, but this is just taste. Yeah, I had a hard time coming up with a concise word. I think I'm going to stick with direct though. 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 Mar 27 13:34:10 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 09:34:10 -0400 Subject: [Freeipa-devel] [PATCH] more detail on errors in UI In-Reply-To: <1206567055.29938.3317.camel@localhost.localdomain> References: <47E902C0.8070906@redhat.com> <1206567055.29938.3317.camel@localhost.localdomain> Message-ID: <47EBA252.5030107@redhat.com> Simo Sorce wrote: > On Tue, 2008-03-25 at 09:48 -0400, Rob Crittenden wrote: >> Add additional detail to error messages. >> >> This runs the risk of showing too much and confusing users but on the >> other hand it often includes required information detailing why the >> error occurred such as what attribute the user lacks write access too >> and why changing a password failed. > > ack. > Simo. > pushed -------------- 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 Mar 27 13:34:26 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 09:34:26 -0400 Subject: [Freeipa-devel] [PATCH] make memberof task public In-Reply-To: <1206567842.29938.3336.camel@localhost.localdomain> References: <47EAB573.8020600@redhat.com> <1206567842.29938.3336.camel@localhost.localdomain> Message-ID: <47EBA262.2080009@redhat.com> Simo Sorce wrote: > On Wed, 2008-03-26 at 16:43 -0400, Rob Crittenden wrote: >> We need to run the memberof task whenever we initialize a replica >> database so I've made memberof public. >> >> We also need to be able to instantiate a DSinstance without running >> the >> whole installer. >> >> And I've added a new item to the dictionary, TIME, so we can >> guarantee >> RDN uniqueness. > > ack > pushed -------------- 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 Mar 27 13:36:19 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 09:36:19 -0400 Subject: [Freeipa-devel] [PATCH] Make memberOf handle group renames properly for indirect members In-Reply-To: <47EACE86.7030905@redhat.com> References: <47EACA2C.8060007@redhat.com> <1206569755.29938.3370.camel@localhost.localdomain> <47EACE86.7030905@redhat.com> Message-ID: <47EBA2D3.9080405@redhat.com> Nathan Kinder wrote: > Simo Sorce wrote: >> On Wed, 2008-03-26 at 15:11 -0700, Nathan Kinder wrote: >> >>> The memberOf attribute was not being properly updated for indirect >>> members of a group when it is renamed. The old name would be >>> removed, but a new memberOf attribute using the new group name was >>> not being >>> added. >>> >>> This was being caused by not calling the appropriate function to >>> perform the replace operation. >>> >> >> well spotted, >> ack. >> > I don't have access to push this. Would you or Rob kindly push it? > I've checked this in upstream in the Fedora DS CVS repo. 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 ssorce at redhat.com Thu Mar 27 13:36:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 09:36:36 -0400 Subject: [Freeipa-devel] [PATCH] more flexible group membership querying In-Reply-To: <47EB9694.3000206@redhat.com> References: <47EA6D9E.3020708@redhat.com> <1206567652.29938.3331.camel@localhost.localdomain> <47EB9694.3000206@redhat.com> Message-ID: <1206624996.3533.2.camel@localhost.localdomain> On Thu, 2008-03-27 at 08:44 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2008-03-26 at 11:37 -0400, Rob Crittenden wrote: > >> + if e.dn not in real_members: > >> + if membertype == 2: > >> + entries.append(self.convert_entry(e)) > >> + else: > >> + if membertype == 1: > >> + entries.append(self.convert_entry(e)) > >> + > > > > Shouldn't the second be a removal ? > > You defined 1 as: "only direct members" so indirect ones should be > > removed right ? > > No, the list starts out as empty. If they are not a real/direct member > and we're only looking for the inherited/indirect members then they get > appended to the list in the first case. > > Otherwise if the are in the list and those are what we're looking for, > we append them. Right I see it so clearly now (/me takes mental note not to review patches ion the evening or when tired anyway :/) So this is an ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 27 13:55:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 09:55:15 -0400 Subject: [Freeipa-devel] [PATCH] more flexible group membership querying In-Reply-To: <1206624996.3533.2.camel@localhost.localdomain> References: <47EA6D9E.3020708@redhat.com> <1206567652.29938.3331.camel@localhost.localdomain> <47EB9694.3000206@redhat.com> <1206624996.3533.2.camel@localhost.localdomain> Message-ID: <47EBA743.7020003@redhat.com> Simo Sorce wrote: > On Thu, 2008-03-27 at 08:44 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Wed, 2008-03-26 at 11:37 -0400, Rob Crittenden wrote: >>>> + if e.dn not in real_members: >>>> + if membertype == 2: >>>> + entries.append(self.convert_entry(e)) >>>> + else: >>>> + if membertype == 1: >>>> + entries.append(self.convert_entry(e)) >>>> + >>> Shouldn't the second be a removal ? >>> You defined 1 as: "only direct members" so indirect ones should be >>> removed right ? >> No, the list starts out as empty. If they are not a real/direct member >> and we're only looking for the inherited/indirect members then they get >> appended to the list in the first case. >> >> Otherwise if the are in the list and those are what we're looking for, >> we append them. > > Right I see it so clearly now (/me takes mental note not to review > patches ion the evening or when tired anyway :/) > > So this is an ack. > > Simo. > pushed -------------- 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 Mar 27 14:21:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 10:21:25 -0400 Subject: [Freeipa-devel] [PATCH] put replica files into /etc/ipa Message-ID: <47EBAD65.2020206@redhat.com> Rather than putting the replica file into the cwd, put it into /etc/ipa. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-738-replica.patch Type: text/x-patch Size: 1015 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 Mar 27 14:22:08 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 10:22:08 -0400 Subject: [Freeipa-devel] [PATCH] grok the hostname properly Message-ID: <47EBAD90.9090703@redhat.com> I tried to add a test to be sure that the replica file being installed matched the current hostname but blew it on dashes. This fixes that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-739-replica.patch Type: text/x-patch Size: 1121 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 Mar 27 14:26:40 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 10:26:40 -0400 Subject: [Freeipa-devel] [PATCH] normalize RDNs when considering group membership In-Reply-To: <47EB12D0.1050707@redhat.com> References: <47EB12D0.1050707@redhat.com> Message-ID: <1206628000.3533.12.camel@localhost.localdomain> On Wed, 2008-03-26 at 23:21 -0400, Rob Crittenden wrote: > When we are displaying the group membership, normalize the RDN before > figuring out if they are a direct or inherited member. ack. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Mar 27 15:02:38 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 11:02:38 -0400 Subject: [Freeipa-devel] [PATCH] put replica files into /etc/ipa In-Reply-To: <47EBAD65.2020206@redhat.com> References: <47EBAD65.2020206@redhat.com> Message-ID: <1206630158.3533.14.camel@localhost.localdomain> On Thu, 2008-03-27 at 10:21 -0400, Rob Crittenden wrote: > Rather than putting the replica file into the cwd, put it into /etc/ipa. Nack, as discussed on IRC. /var/lib/ipa is probably more appropriate. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Mar 27 15:03:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 11:03:25 -0400 Subject: [Freeipa-devel] [PATCH] grok the hostname properly In-Reply-To: <47EBAD90.9090703@redhat.com> References: <47EBAD90.9090703@redhat.com> Message-ID: <1206630205.3533.16.camel@localhost.localdomain> On Thu, 2008-03-27 at 10:22 -0400, Rob Crittenden wrote: > I tried to add a test to be sure that the replica file being > installed > matched the current hostname but blew it on dashes. This fixes that. ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Mar 27 15:34:48 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 11:34:48 -0400 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBBA3D.6040300@redhat.com> References: <47EBBA3D.6040300@redhat.com> Message-ID: <1206632088.3533.22.camel@localhost.localdomain> CCing freeipa-devel to make sure I am saying the right thing as Rob is the one sending patches for it. On Thu, 2008-03-27 at 11:16 -0400, Perry N. Myers wrote: > In looking at the apache configuration for the ipa server and the > ovirt-wui, I had a few questions... > > Right now the assumption being made is that the FreeIPA instance always > gets installed on the same host as the ovirt-wui. And because of this, we > have to run the FreeIPA server on a non-standard port (8089) because it > currently does not coexist well with other apps on the same port. FYI: We are working on fixing this. > Another configuration exists where the FreeIPA server is already installed > elsewhere in the network (maybe someone is already using it for other > purposes) and in this case it'll likely be running on port 80 on that server. > > Since by default FreeIPA runs on port 80, it makes more sense to always > keep it on port 80 so that the configuration is the same whether it is > hosted with the oVirt WUI or standalone. It would make sense yes. > If we agree on that (I'm open to objections here) then the next question > is how to run FreeIPA and oVirt on the same box without conflicts. A few > options exist: > 1. Run oVirt on a different port instead of FreeIPA > 2. Use name virtual hosting so that IPA runs on the base hostname and > oVirt runs on something like ovirt.domain.com. For the developer > install, this can be accomplished by mucking with /etc/hosts and > for prod installs it'll involve DNS, but we already require that for > other things. This is tricky because once we start using https and > FreeIPA does as well, NameVirtualHosting sort of breaks down... > 3. Relocate the ipa server so that it's not at the root URL We are pursuing this solution in freeIPA itself. Hopefully, with some help, we will have this soon. > 4. Relocate the ovirt server so that it's not at the root URL In general it would be wise to be able to use something like http://server/service so that multiple services can be used on the same server without clashes. THe patches I've seen from Rob move all to http(s)://server.name/ipa(xml), I guess ovirt could do something similar and move to http(s)://server.name/ovirt ? > I don't like option 3, since that also changes the default configuration > for FreeIPA. Option 2 will work for now, but we know it'll break later > when we start using https. > > Option 1 is the easiest way to get things working, as long as people don't > object to running the mgmt ui on something other than port 80. > > Option 4 might solve the problem, but I'm not sure if it'll work since > FreeIPA does URL rewriting (we can comment this out, but I'd like to not > muck with their stuff and leave things default if possible) > > Thoughts? I think opt 3 is the solution and should be adopted by both freeipa and ovirt so that we can all be good citizens. Simo. -- Simo Sorce * Red Hat, Inc * New York From pmyers at redhat.com Thu Mar 27 15:40:24 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 27 Mar 2008 11:40:24 -0400 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <1206632088.3533.22.camel@localhost.localdomain> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> Message-ID: <47EBBFE8.4080205@redhat.com> Simo Sorce wrote: > I think opt 3 is the solution and should be adopted by both freeipa and > ovirt so that we can all be good citizens. > > Simo. Ok. I think we're all in agreement then. :) We'll change ovirt to be in /ovirt, and we'll wait to hear when new rpms are in rawhide to fix this in ipa. Thanks everyone. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From berrange at redhat.com Thu Mar 27 15:42:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 27 Mar 2008 15:42:41 +0000 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBBFE8.4080205@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> Message-ID: <20080327154241.GE22443@redhat.com> On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: > Simo Sorce wrote: > > I think opt 3 is the solution and should be adopted by both freeipa and > > ovirt so that we can all be good citizens. > > > > Simo. > > Ok. I think we're all in agreement then. :) > > We'll change ovirt to be in /ovirt, and we'll wait to hear when new rpms > are in rawhide to fix this in ipa. We should sync up with Rob to test his config changes for IPA to verify that they work for us before they get pushed to rawhide. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ssorce at redhat.com Thu Mar 27 17:40:05 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 13:40:05 -0400 Subject: [Freeipa-devel] freeipa: changeset 9282aa7a3c64 Message-ID: <1206639605.3533.28.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/9282aa7a3c64 Pushed this directly under the trivial fix rule. Simo. From ssorce at redhat.com Thu Mar 27 17:54:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 13:54:43 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname Message-ID: <47EBDF63.7020700@redhat.com> This change checks the machine can resolve address using nsswitch host name resolution, this means we are also checking that /etc/hosts is not broken. It uses IPv6 aware system functions, so this should make it also IPv6 compatible. It does not force to have a DNS set up correctly, but that's intentional as we might want to install DNS as part of the installation (--setup-bind) and checking DNS before installing it wouldn't really work :-) It still do try to check the DNS but currently it just exists silently if DNS is not configured. I am not sure how to raise a warning without throwing an exception that would make the install script abort in this case. It does error out if DNS is setup incorrectly. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-729-hostname-check.patch Type: text/x-patch Size: 4041 bytes Desc: not available URL: From ssorce at redhat.com Thu Mar 27 18:06:12 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 14:06:12 -0400 Subject: [Freeipa-devel] Changeset 736:4a3042264474 - freeipa - Trac Message-ID: <1206641172.3533.30.camel@localhost.localdomain> https://fedorahosted.org/freeipa/changeset/736%3A4a3042264474 Another push under the trivial fix rule. From rcritten at redhat.com Thu Mar 27 19:35:06 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 15:35:06 -0400 Subject: [Freeipa-devel] [PATCH] finally detect when ports are not free Message-ID: <47EBF6EA.7040702@redhat.com> I think I've finally found the bug where an ipa-install will crap out early in the DS installation due to ports that aren't available. I discovered that perl, which the DS installer uses, sets FD_CLOEXEC on sockets and python does not. When I enable that then our installer catches the ports not being free too. Nothing is actually listening to the port but there may be connections in WAIT, and that's enough. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-740-ports.patch Type: text/x-patch Size: 1608 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 Mar 27 19:43:07 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2008 15:43:07 -0400 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <20080327154241.GE22443@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> <20080327154241.GE22443@redhat.com> Message-ID: <47EBF8CB.4010606@redhat.com> Daniel P. Berrange wrote: > On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: >> Simo Sorce wrote: >>> I think opt 3 is the solution and should be adopted by both freeipa and >>> ovirt so that we can all be good citizens. >>> >>> Simo. >> Ok. I think we're all in agreement then. :) >> >> We'll change ovirt to be in /ovirt, and we'll wait to hear when new rpms >> are in rawhide to fix this in ipa. > > We should sync up with Rob to test his config changes for IPA to verify > that they work for us before they get pushed to rawhide. > > Dan. The patch is in: https://www.redhat.com/archives/freeipa-devel/2008-March/msg00063.html You can probably apply this by-hand to an existing IPA install, just some of the paths will change. We discussed in IRC to change this even further and put everything that IPA uses into the /ipa namespace. Simo suggested: /ipa/ui /ipa/xml /ipa/errors /ipa/static /ipa/config I'll look into that next. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Mar 27 19:48:10 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 15:48:10 -0400 Subject: [Freeipa-devel] [PATCH] finally detect when ports are not free In-Reply-To: <47EBF6EA.7040702@redhat.com> References: <47EBF6EA.7040702@redhat.com> Message-ID: <1206647290.3533.37.camel@localhost.localdomain> On Thu, 2008-03-27 at 15:35 -0400, Rob Crittenden wrote: > I think I've finally found the bug where an ipa-install will crap out > early in the DS installation due to ports that aren't available. I > discovered that perl, which the DS installer uses, sets FD_CLOEXEC on > sockets and python does not. When I enable that then our installer > catches the ports not being free too. > > Nothing is actually listening to the port but there may be > connections > in WAIT, and that's enough. ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Mar 27 23:18:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2008 19:18:25 -0400 Subject: [Freeipa-devel] [PATCH] sysrestore changes Message-ID: <47EC2B41.3020401@redhat.com> move it to ipa-python so it is usable by all components changes in the way backup files are handled Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-737-sysrestore-in-ipa-python.patch Type: text/x-patch Size: 44403 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 28 13:22:10 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 09:22:10 -0400 Subject: [Freeipa-devel] [PATCH] normalize RDNs when considering group membership In-Reply-To: <1206628000.3533.12.camel@localhost.localdomain> References: <47EB12D0.1050707@redhat.com> <1206628000.3533.12.camel@localhost.localdomain> Message-ID: <47ECF102.5000202@redhat.com> Simo Sorce wrote: > On Wed, 2008-03-26 at 23:21 -0400, Rob Crittenden wrote: >> When we are displaying the group membership, normalize the RDN before >> figuring out if they are a direct or inherited member. > > ack. > pushed -------------- 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 Mar 28 13:23:14 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 09:23:14 -0400 Subject: [Freeipa-devel] [PATCH] grok the hostname properly In-Reply-To: <1206630205.3533.16.camel@localhost.localdomain> References: <47EBAD90.9090703@redhat.com> <1206630205.3533.16.camel@localhost.localdomain> Message-ID: <47ECF142.7000604@redhat.com> Simo Sorce wrote: > On Thu, 2008-03-27 at 10:22 -0400, Rob Crittenden wrote: >> I tried to add a test to be sure that the replica file being >> installed >> matched the current hostname but blew it on dashes. This fixes that. > > ack > > Simo. > pushed -------------- 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 Mar 28 13:23:28 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 09:23:28 -0400 Subject: [Freeipa-devel] [PATCH] finally detect when ports are not free In-Reply-To: <1206647290.3533.37.camel@localhost.localdomain> References: <47EBF6EA.7040702@redhat.com> <1206647290.3533.37.camel@localhost.localdomain> Message-ID: <47ECF150.2000305@redhat.com> Simo Sorce wrote: > On Thu, 2008-03-27 at 15:35 -0400, Rob Crittenden wrote: >> I think I've finally found the bug where an ipa-install will crap out >> early in the DS installation due to ports that aren't available. I >> discovered that perl, which the DS installer uses, sets FD_CLOEXEC on >> sockets and python does not. When I enable that then our installer >> catches the ports not being free too. >> >> Nothing is actually listening to the port but there may be >> connections >> in WAIT, and that's enough. > > ack > > Simo. > pushed -------------- 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 daobrien at redhat.com Fri Mar 28 15:14:24 2008 From: daobrien at redhat.com (David O'Brien) Date: Sat, 29 Mar 2008 01:14:24 +1000 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47EBF8CB.4010606@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> <20080327154241.GE22443@redhat.com> <47EBF8CB.4010606@redhat.com> Message-ID: <47ED0B50.7020704@redhat.com> Rob Crittenden wrote: > Daniel P. Berrange wrote: >> On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: >>> Simo Sorce wrote: >>>> I think opt 3 is the solution and should be adopted by both freeipa >>>> and >>>> ovirt so that we can all be good citizens. >>>> >>>> Simo. >>> Ok. I think we're all in agreement then. :) >>> >>> We'll change ovirt to be in /ovirt, and we'll wait to hear when new >>> rpms >>> are in rawhide to fix this in ipa. >> >> We should sync up with Rob to test his config changes for IPA to verify >> that they work for us before they get pushed to rawhide. >> >> Dan. > > The patch is in: > > https://www.redhat.com/archives/freeipa-devel/2008-March/msg00063.html > > You can probably apply this by-hand to an existing IPA install, just > some of the paths will change. > > We discussed in IRC to change this even further and put everything > that IPA uses into the /ipa namespace. > > Simo suggested: /ipa/ui /ipa/xml /ipa/errors /ipa/static /ipa/config > > I'll look into that next. > > rob Will you also use this for the replica info files that we were thinking of putting in /var/lib/ipa ? /dob -- David O'Brien IPA Content Author Red Hat Asia Pacific "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. From rcritten at redhat.com Fri Mar 28 15:18:56 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 11:18:56 -0400 Subject: [Freeipa-devel] Re: [Ovirt-devel] ports and hostnames for the ovirt server In-Reply-To: <47ED0B50.7020704@redhat.com> References: <47EBBA3D.6040300@redhat.com> <1206632088.3533.22.camel@localhost.localdomain> <47EBBFE8.4080205@redhat.com> <20080327154241.GE22443@redhat.com> <47EBF8CB.4010606@redhat.com> <47ED0B50.7020704@redhat.com> Message-ID: <47ED0C60.7080006@redhat.com> David O'Brien wrote: > Rob Crittenden wrote: >> Daniel P. Berrange wrote: >>> On Thu, Mar 27, 2008 at 11:40:24AM -0400, Perry N. Myers wrote: >>>> Simo Sorce wrote: >>>>> I think opt 3 is the solution and should be adopted by both freeipa >>>>> and >>>>> ovirt so that we can all be good citizens. >>>>> >>>>> Simo. >>>> Ok. I think we're all in agreement then. :) >>>> >>>> We'll change ovirt to be in /ovirt, and we'll wait to hear when new >>>> rpms >>>> are in rawhide to fix this in ipa. >>> >>> We should sync up with Rob to test his config changes for IPA to verify >>> that they work for us before they get pushed to rawhide. >>> >>> Dan. >> >> The patch is in: >> >> https://www.redhat.com/archives/freeipa-devel/2008-March/msg00063.html >> >> You can probably apply this by-hand to an existing IPA install, just >> some of the paths will change. >> >> We discussed in IRC to change this even further and put everything >> that IPA uses into the /ipa namespace. >> >> Simo suggested: /ipa/ui /ipa/xml /ipa/errors /ipa/static /ipa/config >> >> I'll look into that next. >> >> rob > Will you also use this for the replica info files that we were thinking > of putting in /var/lib/ipa ? > These aren't directories, the are the proposed URI's for the web server. 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 nkinder at redhat.com Fri Mar 28 16:00:17 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 28 Mar 2008 09:00:17 -0700 Subject: [Freeipa-devel] [PATCH] Make memberOf handle delete mods that specify no values Message-ID: <47ED1611.4010302@redhat.com> The memberOf plug-in was having problems with delete modify operations that didn't specify any member values to delete (all member values should be deleted in this case). See the commit message in the patch for more details. -NGK -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-742-memberof.patch Type: text/x-patch Size: 1612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Mar 28 17:08:35 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 13:08:35 -0400 Subject: [Freeipa-devel] [PATCH] don't let admin user be removed Message-ID: <47ED2613.7060909@redhat.com> admin is our super-user, don't let it be removed over XML-RPC. It can be removed over LDAP if you really want it gone. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-741-nodelete.patch Type: text/x-patch Size: 1521 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 Mar 28 18:34:40 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 14:34:40 -0400 Subject: [Freeipa-devel] [PATCH] Make memberOf handle delete mods that specify no values In-Reply-To: <47ED1611.4010302@redhat.com> References: <47ED1611.4010302@redhat.com> Message-ID: <47ED3A40.6090707@redhat.com> Nathan Kinder wrote: > The memberOf plug-in was having problems with delete modify operations > that didn't specify any member values to delete (all member values > should be deleted in this case). See the commit message in the patch > for more details. Ack. Simo. From ssorce at redhat.com Fri Mar 28 18:37:48 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 14:37:48 -0400 Subject: [Freeipa-devel] [PATCH] don't let admin user be removed In-Reply-To: <47ED2613.7060909@redhat.com> References: <47ED2613.7060909@redhat.com> Message-ID: <47ED3AFC.5060704@redhat.com> Rob Crittenden wrote: > admin is our super-user, don't let it be removed over XML-RPC. It can be > removed over LDAP if you really want it gone. ack! Simo. From rcritten at redhat.com Fri Mar 28 18:48:39 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 14:48:39 -0400 Subject: [Freeipa-devel] [PATCH] better objectclass uniqueness check Message-ID: <47ED3D87.9000806@redhat.com> So we store in cn=ipaconfig the list of default objectclasses that users and groups get (so we can avoid hardcoding). The problem is that if this changes it presents issues when updating a user for another reason. So this fixes several things. First, it does caseless comparisons when considering objectclass but stores the current value to prevent unnecessary LPAP updates. Secondly it disables this call altogether on updated entries. I fix the first problem so that when/if we do re-enable it then it will work as expected. New users/groups will still get the default list. I've disabled the ability to update these values in the UI as well so we don't run into issues where I've created 10 users, I update the values and create 10 more and their objectclasses are not the same. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-742-objectclass.patch Type: text/x-patch Size: 3523 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 Mar 28 19:08:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 15:08:03 -0400 Subject: [Freeipa-devel] [PATCH] better objectclass uniqueness check In-Reply-To: <47ED3D87.9000806@redhat.com> References: <47ED3D87.9000806@redhat.com> Message-ID: <47ED4213.5000900@redhat.com> Rob Crittenden wrote: > So we store in cn=ipaconfig the list of default objectclasses that users > and groups get (so we can avoid hardcoding). > > The problem is that if this changes it presents issues when updating a > user for another reason. > > So this fixes several things. First, it does caseless comparisons when > considering objectclass but stores the current value to prevent > unnecessary LPAP updates. > > Secondly it disables this call altogether on updated entries. I fix the > first problem so that when/if we do re-enable it then it will work as > expected. New users/groups will still get the default list. > > I've disabled the ability to update these values in the UI as well so we > don't run into issues where I've created 10 users, I update the values > and create 10 more and their objectclasses are not the same. ack Simo. From rcritten at redhat.com Fri Mar 28 19:13:48 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 15:13:48 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname In-Reply-To: <47EBDF63.7020700@redhat.com> References: <47EBDF63.7020700@redhat.com> Message-ID: <47ED436C.6070804@redhat.com> Simo Sorce wrote: > This change checks the machine can resolve address using nsswitch host > name resolution, this means we are also checking that /etc/hosts is not > broken. > > It uses IPv6 aware system functions, so this should make it also IPv6 > compatible. > > It does not force to have a DNS set up correctly, but that's intentional > as we might want to install DNS as part of the installation > (--setup-bind) and checking DNS before installing it wouldn't really > work :-) > > It still do try to check the DNS but currently it just exists silently > if DNS is not configured. I am not sure how to raise a warning without > throwing an exception that would make the install script abort in this > case. > > It does error out if DNS is setup incorrectly. > + + rev = None + for rsn in rs: + if rsn.dns_type == dnsclient.DNS_T_A: + rev = rsn + break + + if rev == None: + raise RuntimeError("Cannot find PTR record for %s" % addr) + + reverse = rev.rdata.ptrdname Should you be looking for DNS_T_PTR here instead? If you have an A record you won't have a ptrdname. You need to add a try/except around socket.getaddrinfo() to catch errors if the hostname isn't found so a more useful error message can be returned than 'Name or service not known' gethostbyaddr may need a try/except around it too. 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 Mar 28 19:16:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 15:16:11 -0400 Subject: [Freeipa-devel] [PATCH] sysrestore changes In-Reply-To: <47EC2B41.3020401@redhat.com> References: <47EC2B41.3020401@redhat.com> Message-ID: <47ED43FB.4060403@redhat.com> Simo Sorce wrote: > move it to ipa-python so it is usable by all components > changes in the way backup files are handled > > Simo. > 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 ssorce at redhat.com Fri Mar 28 19:39:54 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 15:39:54 -0400 Subject: [Freeipa-devel] [PATCH] sysrestore changes In-Reply-To: <47ED43FB.4060403@redhat.com> References: <47EC2B41.3020401@redhat.com> <47ED43FB.4060403@redhat.com> Message-ID: <47ED498A.7000206@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> move it to ipa-python so it is usable by all components >> changes in the way backup files are handled >> >> Simo. >> > > ack pushed From rcritten at redhat.com Fri Mar 28 19:57:09 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 15:57:09 -0400 Subject: [Freeipa-devel] [PATCH] put replica files into /etc/ipa In-Reply-To: <1206630158.3533.14.camel@localhost.localdomain> References: <47EBAD65.2020206@redhat.com> <1206630158.3533.14.camel@localhost.localdomain> Message-ID: <47ED4D95.9000307@redhat.com> Simo Sorce wrote: > On Thu, 2008-03-27 at 10:21 -0400, Rob Crittenden wrote: >> Rather than putting the replica file into the cwd, put it into /etc/ipa. > > Nack, as discussed on IRC. > /var/lib/ipa is probably more appropriate. > > Simo. > Switched to Simo's suggestion and pushed the 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 nkinder at redhat.com Fri Mar 28 21:22:17 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 28 Mar 2008 14:22:17 -0700 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself Message-ID: <47ED6189.8030708@redhat.com> If you create a circular grouping, a group will be listed as a memberOf itself. We just need to do a check when processing any type of operation to see if we're attempting to use a group's DN as the value of memberOf on itself. We had a check like that for a fixup operation, but it needed to be moved up in the code so it's used for any operations. -NGK -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-745-memberof.patch Type: text/x-patch Size: 2406 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Mar 28 21:22:57 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 17:22:57 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname In-Reply-To: <47ED436C.6070804@redhat.com> References: <47EBDF63.7020700@redhat.com> <47ED436C.6070804@redhat.com> Message-ID: <47ED61B1.1020204@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> This change checks the machine can resolve address using nsswitch host >> name resolution, this means we are also checking that /etc/hosts is >> not broken. >> >> It uses IPv6 aware system functions, so this should make it also IPv6 >> compatible. >> >> It does not force to have a DNS set up correctly, but that's >> intentional as we might want to install DNS as part of the >> installation (--setup-bind) and checking DNS before installing it >> wouldn't really work :-) >> >> It still do try to check the DNS but currently it just exists silently >> if DNS is not configured. I am not sure how to raise a warning without >> throwing an exception that would make the install script abort in this >> case. >> >> It does error out if DNS is setup incorrectly. >> > > + > + rev = None > + for rsn in rs: > + if rsn.dns_type == dnsclient.DNS_T_A: > + rev = rsn > + break > + > + if rev == None: > + raise RuntimeError("Cannot find PTR record for %s" % addr) > + > + reverse = rev.rdata.ptrdname > > Should you be looking for DNS_T_PTR here instead? If you have an A > record you won't have a ptrdname. > > You need to add a try/except around socket.getaddrinfo() to catch errors > if the hostname isn't found so a more useful error message can be > returned than 'Name or service not known' > > gethostbyaddr may need a try/except around it too. > > rob > Good points, new patch attached. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-743-hostname-check.patch Type: text/x-patch Size: 4285 bytes Desc: not available URL: From ssorce at redhat.com Fri Mar 28 21:33:19 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 17:33:19 -0400 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47ED6189.8030708@redhat.com> References: <47ED6189.8030708@redhat.com> Message-ID: <47ED641F.4090603@redhat.com> Nathan Kinder wrote: > If you create a circular grouping, a group will be listed as a memberOf > itself. > > We just need to do a check when processing any type of operation to see if > we're attempting to use a group's DN as the value of memberOf on > itself. We > had a check like that for a fixup operation, but it needed to be moved > up in the > code so it's used for any operations. > Ack, looks reasonable. Simo. From rcritten at redhat.com Fri Mar 28 21:34:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 28 Mar 2008 17:34:41 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname In-Reply-To: <47ED61B1.1020204@redhat.com> References: <47EBDF63.7020700@redhat.com> <47ED436C.6070804@redhat.com> <47ED61B1.1020204@redhat.com> Message-ID: <47ED6471.7010805@redhat.com> Simo Sorce wrote: > Rob Crittenden wrote: >> Simo Sorce wrote: >>> This change checks the machine can resolve address using nsswitch >>> host name resolution, this means we are also checking that /etc/hosts >>> is not broken. >>> >>> It uses IPv6 aware system functions, so this should make it also IPv6 >>> compatible. >>> >>> It does not force to have a DNS set up correctly, but that's >>> intentional as we might want to install DNS as part of the >>> installation (--setup-bind) and checking DNS before installing it >>> wouldn't really work :-) >>> >>> It still do try to check the DNS but currently it just exists >>> silently if DNS is not configured. I am not sure how to raise a >>> warning without throwing an exception that would make the install >>> script abort in this case. >>> >>> It does error out if DNS is setup incorrectly. >>> >> >> + >> + rev = None >> + for rsn in rs: >> + if rsn.dns_type == dnsclient.DNS_T_A: >> + rev = rsn >> + break >> + >> + if rev == None: >> + raise RuntimeError("Cannot find PTR record for %s" % addr) >> + >> + reverse = rev.rdata.ptrdname >> >> Should you be looking for DNS_T_PTR here instead? If you have an A >> record you won't have a ptrdname. >> >> You need to add a try/except around socket.getaddrinfo() to catch >> errors if the hostname isn't found so a more useful error message can >> be returned than 'Name or service not known' >> >> gethostbyaddr may need a try/except around it too. >> >> rob >> > > > > Good points, new patch attached. I have just a couple more comments (sorry, should have included these in the first patch): - We should say why 127.0.0.1/::1 is an Invalid IP address. Or rather, just say that the hostname needs to resolve to a real address or something. - When are you planning on filling in the #TODO raise a warning? What happens if the hostname is a CNAME, will it work? It kinda looks like it will still be accepted. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Mar 28 21:36:00 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 28 Mar 2008 17:36:00 -0400 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47ED641F.4090603@redhat.com> References: <47ED6189.8030708@redhat.com> <47ED641F.4090603@redhat.com> Message-ID: <47ED64C0.6010404@redhat.com> Simo Sorce wrote: > Nathan Kinder wrote: >> If you create a circular grouping, a group will be listed as a >> memberOf itself. >> >> We just need to do a check when processing any type of operation to >> see if >> we're attempting to use a group's DN as the value of memberOf on >> itself. We >> had a check like that for a fixup operation, but it needed to be moved >> up in the >> code so it's used for any operations. >> > > > Ack, > looks reasonable. > And pushed. Simo. From pmyers at redhat.com Sat Mar 29 10:08:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Sat, 29 Mar 2008 06:08:20 -0400 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <87pru28dhw.fsf@rho.meyering.net> References: <87pru28dhw.fsf@rho.meyering.net> Message-ID: <47EE1514.9080501@redhat.com> Jim Meyering wrote: > Please wait until the prompt is returned. > Configuring ntpd > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > done configuring ntpd. > Configuring directory server: > [1/16]: creating directory server user > [2/16]: creating directory server instance > [3/16]: adding default schema > [4/16]: enabling memberof plugin > root : CRITICAL Failed to load memberof-conf.ldif: Command > '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 > [5/16]: enabling referential integrity plugin > root : CRITICAL Failed to load referint-conf.ldif: Command > '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49 > [6/16]: enabling distributed numeric assignment plugin > root : CRITICAL Failed to load dna-conf.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49 > [7/16]: configuring uniqueness plugin > root : CRITICAL Failed to load unique-attributes.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /dev/shm/tmp4dWkvF' returned non-zero exit status 49 > [8/16]: creating indices > root : CRITICAL Failed to load indices.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx -f /usr/share/ipa/indices.ldif' returned non-zero exit status 49 > [9/16]: configuring ssl for ds instance > Unexpected error - see ipaserver-install.log for details: > {'desc': 'Invalid credentials'} > > -------------------------- > When I ran that ldapmodify command manually, it did this: > > root at iota# ldapmodify -h 127.0.0.1 -xv -D 'cn=Directory Manager' \ > -w xxx -f /usr/share/ipa/memberof-conf.ldif > ldap_initialize( ldap://127.0.0.1 ) > ldap_bind: Invalid credentials (49) > [Exit 49] This problem still exists in rawhide and as far as I can tell it is not ipa related. The problem is actually with the fedora directory server. What I've discovered is that if you run ns-slapd with the -d flag (runs the server in the foreground) things work fine. If you run the server without the -d flag, you get the Invalid credentials messages even with the correct CN and password. I've been able to reproduce this in fedora-ds-base-1.1.0.1-3.fc9.x86_64. If anyone has any ideas let me know... I did some searching to see if there is an existing bug for this and I didn't see one. Perry From kranidiotis at hilonsys.com Sat Mar 29 17:45:01 2008 From: kranidiotis at hilonsys.com (Panagiotis Kranidiotis) Date: Sat, 29 Mar 2008 19:45:01 +0200 Subject: [Freeipa-devel] hostname % is not found or is not a DNS A record Message-ID: <1206812701.7264.2.camel@anaximandros> I am trying to install ipa-server on f8 and i am getting the following error. hostname % is not found or is not a DNS A record where % my hostname Any ideas? From ssorce at redhat.com Sun Mar 30 19:56:48 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 30 Mar 2008 19:56:48 +0000 Subject: [Freeipa-devel] hostname % is not found or is not a DNS A record In-Reply-To: <1206812701.7264.2.camel@anaximandros> References: <1206812701.7264.2.camel@anaximandros> Message-ID: <1206907008.3533.60.camel@localhost.localdomain> On Sat, 2008-03-29 at 19:45 +0200, Panagiotis Kranidiotis wrote: > I am trying to install ipa-server on f8 and i am getting the following > error. > > hostname % is not found or is not a DNS A record > > where % my hostname > > > Any ideas? Your machine hostname must resolve to a valid "public" (ie not 127.0.0.1) IP address. You can set it correctly in /etc/hosts (F8 may have put your hostname in your 127.0.0.1 line instead of putting it on an entry of his own with your NIC interface IP address), or create an entry in the DNS you are using to serve your server. Note that if your hostname is associated to 127.0.0.1 in /etc/hosts, the installation cannot proceed and you must correct it even if you use DNS to publish the correct name<->IP association. Simo. -- Simo Sorce * Red Hat, Inc * New York From daobrien at redhat.com Sun Mar 30 22:50:10 2008 From: daobrien at redhat.com (David O'Brien) Date: Mon, 31 Mar 2008 08:50:10 +1000 Subject: [Freeipa-devel] hostname % is not found or is not a DNS A record In-Reply-To: <1206812701.7264.2.camel@anaximandros> References: <1206812701.7264.2.camel@anaximandros> Message-ID: <47F01922.1010509@redhat.com> Panagiotis Kranidiotis wrote: > I am trying to install ipa-server on f8 and i am getting the following > error. > > hostname % is not found or is not a DNS A record > > where % my hostname > > > Any ideas? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > You might like to refer to http://www.freeipa.com/page/InstallAndDeploy#Introduction for more info on this and related topics. cheers -- David O'Brien IPA Content Author Red Hat Asia Pacific "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. From ssorce at redhat.com Mon Mar 31 00:03:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 30 Mar 2008 20:03:18 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname In-Reply-To: <47ED6471.7010805@redhat.com> References: <47EBDF63.7020700@redhat.com> <47ED436C.6070804@redhat.com> <47ED61B1.1020204@redhat.com> <47ED6471.7010805@redhat.com> Message-ID: <1206921798.3533.95.camel@localhost.localdomain> On Fri, 2008-03-28 at 17:34 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> This change checks the machine can resolve address using nsswitch > >>> host name resolution, this means we are also checking that /etc/hosts > >>> is not broken. > >>> > >>> It uses IPv6 aware system functions, so this should make it also IPv6 > >>> compatible. > >>> > >>> It does not force to have a DNS set up correctly, but that's > >>> intentional as we might want to install DNS as part of the > >>> installation (--setup-bind) and checking DNS before installing it > >>> wouldn't really work :-) > >>> > >>> It still do try to check the DNS but currently it just exists > >>> silently if DNS is not configured. I am not sure how to raise a > >>> warning without throwing an exception that would make the install > >>> script abort in this case. > >>> > >>> It does error out if DNS is setup incorrectly. > >>> > >> > >> + > >> + rev = None > >> + for rsn in rs: > >> + if rsn.dns_type == dnsclient.DNS_T_A: > >> + rev = rsn > >> + break > >> + > >> + if rev == None: > >> + raise RuntimeError("Cannot find PTR record for %s" % addr) > >> + > >> + reverse = rev.rdata.ptrdname > >> > >> Should you be looking for DNS_T_PTR here instead? If you have an A > >> record you won't have a ptrdname. > >> > >> You need to add a try/except around socket.getaddrinfo() to catch > >> errors if the hostname isn't found so a more useful error message can > >> be returned than 'Name or service not known' > >> > >> gethostbyaddr may need a try/except around it too. > >> > >> rob > >> > > > > > > > > Good points, new patch attached. > > I have just a couple more comments (sorry, should have included these in > the first patch): > > - We should say why 127.0.0.1/::1 is an Invalid IP address. Or rather, > just say that the hostname needs to resolve to a real address or something. > - When are you planning on filling in the #TODO raise a warning? What > happens if the hostname is a CNAME, will it work? It kinda looks like it > will still be accepted. Good points again, newer patch attached. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-743-hostname-check.patch Type: text/x-patch Size: 4949 bytes Desc: not available URL: From ssorce at redhat.com Mon Mar 31 00:48:13 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 00:48:13 +0000 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? Message-ID: <1206924493.3533.115.camel@localhost.localdomain> Hello list, today I was working on something unrelated to computers and IT and I found myself thinking about how we should support Cross realm trusts in FreeIPA (yeah what was I doing? can't remember ... :-). Dealing with them at the Kerberos level is quite simple, mostly because it is already implemented :-) But when we talk about identity and Posix attributes we hit the sore point. So while I was thinking of some possible technical solutions I came up with 9 questions instead that need to ne answered. I have some answers I am considering in my mind, but I'd like to seek for opinions from interested people. So here they are. They are not necessarily in a good order as some answers may depend on later questions, feel free to reorder them if you think of such dependencies. Also they may have different answers if you think of one-way vs two-way trusts. So far MIT Kerberos Trusts (afaik) are always transitive, so we do not have to concern ourselves with intransitive trusts (or should we?) - How do we get user and group info (posix attributes and other stuff) from the trusted realm ? - How to uniquely assign UIDs/GIDs to foreign objects (think of MMR problems) ? - "when" do we get/refresh information ? - "where" do we store information (also think in terms of client/server) ? - "who" (think in terms of credentials too) will access information in the trusted realm ? - should we allow groups to be "global" and be shared between realms ? - can we allow a machine in realm-a to see the groups in realm-b ? (and set an ACL in a file with such group ID ?) - can we make a user of realm-a part of a group in realm-b ? - can we support 1 way trusts ? - How to avoid too much traffic between servers (caching, validation, etc..)? - should we distinguish between Realm/DNS Domain based hierarchies and other kind of trusts ? (At the client level we have to because kerberos libraries can try to use trusts walking a realm/dns domain hierarchy but otherwise they have to be configured using the capaths configuration option, if we want to make this dynamically discoverable we may need to modify kerberos libraries so that they can fetch this information from elsewhere) Though questions, if they are too technical here there is a simpler question: How much important do you think cross realm trust will be ? good thinking, Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Mar 31 01:26:46 2008 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 30 Mar 2008 21:26:46 -0400 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <1206924493.3533.115.camel@localhost.localdomain> References: <1206924493.3533.115.camel@localhost.localdomain> Message-ID: <47F03DD6.9090904@redhat.com> Simo Sorce wrote: > Hello list, > today I was working on something unrelated to computers and IT and I > found myself thinking about how we should support Cross realm trusts in > FreeIPA (yeah what was I doing? can't remember ... :-). > > Dealing with them at the Kerberos level is quite simple, mostly because > it is already implemented :-) > > But when we talk about identity and Posix attributes we hit the sore > point. > > So while I was thinking of some possible technical solutions I came up > with 9 questions instead that need to ne answered. I have some answers I > am considering in my mind, but I'd like to seek for opinions from > interested people. > > So here they are. > They are not necessarily in a good order as some answers may depend on > later questions, feel free to reorder them if you think of such > dependencies. > Also they may have different answers if you think of one-way vs two-way > trusts. > So far MIT Kerberos Trusts (afaik) are always transitive, so we do not > have to concern ourselves with intransitive trusts (or should we?) > > - How do we get user and group info (posix attributes and other stuff) > from the trusted realm ? > > - How to uniquely assign UIDs/GIDs to foreign objects (think of MMR > problems) ? > > - "when" do we get/refresh information ? > > - "where" do we store information (also think in terms of > client/server) ? > > - "who" (think in terms of credentials too) will access information in > the trusted realm ? > > - should we allow groups to be "global" and be shared between realms ? > - can we allow a machine in realm-a to see the groups in realm-b ? > (and set an ACL in a file with such group ID ?) > - can we make a user of realm-a part of a group in realm-b ? > > - can we support 1 way trusts ? > > - How to avoid too much traffic between servers (caching, validation, > etc..)? > > - should we distinguish between Realm/DNS Domain based hierarchies and > other kind of trusts ? > (At the client level we have to because kerberos libraries can > try to use trusts walking a realm/dns domain hierarchy but > otherwise they have to be configured using the capaths > configuration option, if we want to make this dynamically > discoverable we may need to modify kerberos libraries so that > they can fetch this information from elsewhere) > > > Though questions, if they are too technical here there is a simpler > question: > > How much important do you think cross realm trust will be ? > > good thinking, > Simo. > > Simo, Great questions but I agree that they are a bit technical. The last one, however, is the question about use cases. I think that is where we should start. I might be wrong but user traveling with his laptop from realm a to realm b is probably the biggest case. Any other major ones? Thanks, Dmitri From email.ahmedkamal at googlemail.com Mon Mar 31 07:23:12 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 31 Mar 2008 09:23:12 +0200 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <47F03DD6.9090904@redhat.com> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> Message-ID: <3da3b5b40803310023yaace44fo2ce56ed7bed2248b@mail.gmail.com> recently I've been studying Microsoft's active directory, and I have to say I am kind of impressed .. I hope someone is analyzing the work they've done :) Things like different kinds of groups, group nesting, and uid/gid clashes .. etc, hmm Perhaps the old posix model is showing its age now! On Mon, Mar 31, 2008 at 3:26 AM, Dmitri Pal wrote: > Simo Sorce wrote: > > Hello list, > > today I was working on something unrelated to computers and IT and I > > found myself thinking about how we should support Cross realm trusts in > > FreeIPA (yeah what was I doing? can't remember ... :-). > > > > Dealing with them at the Kerberos level is quite simple, mostly because > > it is already implemented :-) > > > > But when we talk about identity and Posix attributes we hit the sore > > point. > > > > So while I was thinking of some possible technical solutions I came up > > with 9 questions instead that need to ne answered. I have some answers I > > am considering in my mind, but I'd like to seek for opinions from > > interested people. > > > > So here they are. > > They are not necessarily in a good order as some answers may depend on > > later questions, feel free to reorder them if you think of such > > dependencies. > > Also they may have different answers if you think of one-way vs two-way > > trusts. > > So far MIT Kerberos Trusts (afaik) are always transitive, so we do not > > have to concern ourselves with intransitive trusts (or should we?) > > > > - How do we get user and group info (posix attributes and other stuff) > > from the trusted realm ? > > > > - How to uniquely assign UIDs/GIDs to foreign objects (think of MMR > > problems) ? > > > > - "when" do we get/refresh information ? > > > > - "where" do we store information (also think in terms of > > client/server) ? > > > > - "who" (think in terms of credentials too) will access information in > > the trusted realm ? > > > > - should we allow groups to be "global" and be shared between realms ? > > - can we allow a machine in realm-a to see the groups in realm-b ? > > (and set an ACL in a file with such group ID ?) > > - can we make a user of realm-a part of a group in realm-b ? > > > > - can we support 1 way trusts ? > > > > - How to avoid too much traffic between servers (caching, validation, > > etc..)? > > > > - should we distinguish between Realm/DNS Domain based hierarchies and > > other kind of trusts ? > > (At the client level we have to because kerberos libraries can > > try to use trusts walking a realm/dns domain hierarchy but > > otherwise they have to be configured using the capaths > > configuration option, if we want to make this dynamically > > discoverable we may need to modify kerberos libraries so that > > they can fetch this information from elsewhere) > > > > > > Though questions, if they are too technical here there is a simpler > > question: > > > > How much important do you think cross realm trust will be ? > > > > good thinking, > > Simo. > > > > > Simo, > > Great questions but I agree that they are a bit technical. > The last one, however, is the question about use cases. > I think that is where we should start. > I might be wrong but user traveling with his laptop from realm a to > realm b is probably the biggest case. > Any other major ones? > > Thanks, > Dmitri > > _______________________________________________ > 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 ssorce at redhat.com Mon Mar 31 12:12:37 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 12:12:37 +0000 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <3da3b5b40803310023yaace44fo2ce56ed7bed2248b@mail.gmail.com> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> <3da3b5b40803310023yaace44fo2ce56ed7bed2248b@mail.gmail.com> Message-ID: <1206965557.3533.124.camel@localhost.localdomain> On Mon, 2008-03-31 at 09:23 +0200, Ahmed Kamal wrote: > recently I've been studying Microsoft's active directory, and I have > to say I am kind of impressed .. I hope someone is analyzing the work > they've done :) Things like different kinds of groups, group nesting, > and uid/gid clashes .. etc, hmm Perhaps the old posix model is showing > its age now! There some key differences indeed, and AD has some neat solutions. But the fact is that Linux and other Unices are tied to the POSIX model,a nd that's what we have to deal with. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 31 13:29:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 09:29:49 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname In-Reply-To: <1206921798.3533.95.camel@localhost.localdomain> References: <47EBDF63.7020700@redhat.com> <47ED436C.6070804@redhat.com> <47ED61B1.1020204@redhat.com> <47ED6471.7010805@redhat.com> <1206921798.3533.95.camel@localhost.localdomain> Message-ID: <47F0E74D.2090706@redhat.com> Simo Sorce wrote: > On Fri, 2008-03-28 at 17:34 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> This change checks the machine can resolve address using nsswitch >>>>> host name resolution, this means we are also checking that /etc/hosts >>>>> is not broken. >>>>> >>>>> It uses IPv6 aware system functions, so this should make it also IPv6 >>>>> compatible. >>>>> >>>>> It does not force to have a DNS set up correctly, but that's >>>>> intentional as we might want to install DNS as part of the >>>>> installation (--setup-bind) and checking DNS before installing it >>>>> wouldn't really work :-) >>>>> >>>>> It still do try to check the DNS but currently it just exists >>>>> silently if DNS is not configured. I am not sure how to raise a >>>>> warning without throwing an exception that would make the install >>>>> script abort in this case. >>>>> >>>>> It does error out if DNS is setup incorrectly. >>>>> >>>> + >>>> + rev = None >>>> + for rsn in rs: >>>> + if rsn.dns_type == dnsclient.DNS_T_A: >>>> + rev = rsn >>>> + break >>>> + >>>> + if rev == None: >>>> + raise RuntimeError("Cannot find PTR record for %s" % addr) >>>> + >>>> + reverse = rev.rdata.ptrdname >>>> >>>> Should you be looking for DNS_T_PTR here instead? If you have an A >>>> record you won't have a ptrdname. >>>> >>>> You need to add a try/except around socket.getaddrinfo() to catch >>>> errors if the hostname isn't found so a more useful error message can >>>> be returned than 'Name or service not known' >>>> >>>> gethostbyaddr may need a try/except around it too. >>>> >>>> rob >>>> >>> >>> >>> Good points, new patch attached. >> I have just a couple more comments (sorry, should have included these in >> the first patch): >> >> - We should say why 127.0.0.1/::1 is an Invalid IP address. Or rather, >> just say that the hostname needs to resolve to a real address or something. >> - When are you planning on filling in the #TODO raise a warning? What >> happens if the hostname is a CNAME, will it work? It kinda looks like it >> will still be accepted. > > Good points again, newer patch attached. > > Looks great, ack. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Mar 31 13:50:51 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 09:50:51 -0400 Subject: [Freeipa-devel] [PATCH] ipv6 compatible way to check the hostname In-Reply-To: <47F0E74D.2090706@redhat.com> References: <47EBDF63.7020700@redhat.com> <47ED436C.6070804@redhat.com> <47ED61B1.1020204@redhat.com> <47ED6471.7010805@redhat.com> <1206921798.3533.95.camel@localhost.localdomain> <47F0E74D.2090706@redhat.com> Message-ID: <1206971451.3533.133.camel@localhost.localdomain> On Mon, 2008-03-31 at 09:29 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2008-03-28 at 17:34 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> This change checks the machine can resolve address using nsswitch > >>>>> host name resolution, this means we are also checking that /etc/hosts > >>>>> is not broken. > >>>>> > >>>>> It uses IPv6 aware system functions, so this should make it also IPv6 > >>>>> compatible. > >>>>> > >>>>> It does not force to have a DNS set up correctly, but that's > >>>>> intentional as we might want to install DNS as part of the > >>>>> installation (--setup-bind) and checking DNS before installing it > >>>>> wouldn't really work :-) > >>>>> > >>>>> It still do try to check the DNS but currently it just exists > >>>>> silently if DNS is not configured. I am not sure how to raise a > >>>>> warning without throwing an exception that would make the install > >>>>> script abort in this case. > >>>>> > >>>>> It does error out if DNS is setup incorrectly. > >>>>> > >>>> + > >>>> + rev = None > >>>> + for rsn in rs: > >>>> + if rsn.dns_type == dnsclient.DNS_T_A: > >>>> + rev = rsn > >>>> + break > >>>> + > >>>> + if rev == None: > >>>> + raise RuntimeError("Cannot find PTR record for %s" % addr) > >>>> + > >>>> + reverse = rev.rdata.ptrdname > >>>> > >>>> Should you be looking for DNS_T_PTR here instead? If you have an A > >>>> record you won't have a ptrdname. > >>>> > >>>> You need to add a try/except around socket.getaddrinfo() to catch > >>>> errors if the hostname isn't found so a more useful error message can > >>>> be returned than 'Name or service not known' > >>>> > >>>> gethostbyaddr may need a try/except around it too. > >>>> > >>>> rob > >>>> > >>> > >>> > >>> Good points, new patch attached. > >> I have just a couple more comments (sorry, should have included these in > >> the first patch): > >> > >> - We should say why 127.0.0.1/::1 is an Invalid IP address. Or rather, > >> just say that the hostname needs to resolve to a real address or something. > >> - When are you planning on filling in the #TODO raise a warning? What > >> happens if the hostname is a CNAME, will it work? It kinda looks like it > >> will still be accepted. > > > > Good points again, newer patch attached. > > > > > > Looks great, ack. Pushed. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 31 14:14:42 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 14:14:42 +0000 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <47F03DD6.9090904@redhat.com> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> Message-ID: <1206972882.3533.146.camel@localhost.localdomain> On Sun, 2008-03-30 at 21:26 -0400, Dmitri Pal wrote: > Great questions but I agree that they are a bit technical. > The last one, however, is the question about use cases. > I think that is where we should start. > I might be wrong but user traveling with his laptop from realm a to > realm b is probably the biggest case. > Any other major ones? I am not actually interested much in the mobility problem, given kerberos trusts are an all or nothing thing (all services of realm-a will trust all users of realm-b), it is highly unlikely a trust is created just for a "visiting" laptop. I am more interested in the cases where someone one to actually trust another Realm in its entirety. Possible use cases are merger between 2 companies or 2 divisions each one with their own IPA realm. Some cases may be about resource separation (like segregation of machines in a DMZ and use of a 1 way trust to let users use the resources), although I am not convinced this is a really good idea to support. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 31 15:36:50 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 11:36:50 -0400 Subject: [Freeipa-devel] [PATCH] fix account activation Message-ID: <47F10512.8050702@redhat.com> Fix account activation. We do account activation by using a Class of Service based on group membership. A problem can happen if the entry itself has an nsaccountlock attribute and you try doing Class of Service work as well because the local attribute has priority. So try to detect that the entry has a local nsAccountLock attribute and report an appropriate error. Don't allow the admins or editors groups to be de-activated. Return a better error message if account [in]activation fails. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-772-activation.patch Type: text/x-patch Size: 8393 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Mon Mar 31 15:38:02 2008 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 31 Mar 2008 11:38:02 -0400 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <1206972882.3533.146.camel@localhost.localdomain> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> <1206972882.3533.146.camel@localhost.localdomain> Message-ID: <47F1055A.9070702@redhat.com> Simo Sorce wrote: > On Sun, 2008-03-30 at 21:26 -0400, Dmitri Pal wrote: > >> Great questions but I agree that they are a bit technical. >> The last one, however, is the question about use cases. >> I think that is where we should start. >> I might be wrong but user traveling with his laptop from realm a to >> realm b is probably the biggest case. >> Any other major ones? >> > > I am not actually interested much in the mobility problem, given > kerberos trusts are an all or nothing thing (all services of realm-a > will trust all users of realm-b), it is highly unlikely a trust is > created just for a "visiting" laptop. > > I am more interested in the cases where someone one to actually trust > another Realm in its entirety. > Possible use cases are merger between 2 companies or 2 divisions each > one with their own IPA realm. Some cases may be about resource > separation (like segregation of machines in a DMZ and use of a 1 way > trust to let users use the resources), although I am not convinced this > is a really good idea to support. > > Simo. > > I look at the trust between two API domains as more than just kerberos SSO. Trust is not only about authentication but about policies, access control and audit. While kerberos trust to some extent takes care of the authentication it does not take care about policies and access control. For those some mechanisms and rules need to be defined based on the use cases that we identify. So far I see two main use cases: 1) "Visiting user" - this is the use case of visiting user or merger. If you have different departments with different IPA servers and you want a traveling user to take advantage of the resources (print services, disk mounts, portals etc.) you need a trust. Similar situation happens during merger. There just more users to be worried about. 2) "Resource Isolation". The realm trust have been a way of solving thisissue to some extent. If we are asking questions about "how important the realm trust is" a would also ask the question "is the realm trust the only right solution to resource isolation"? Definitely resource isolation requirements are derived from security and compliance requirements and are extremely important for the customers but is setting realm and trusts between different realms the only solution? May be the problem can be solved by setting one realm in a specific way. This is our task to suggest different approaches and verify which ones will be accepted by the customers before implementing a specific approach and diving into technical details. How Microsoft does it? They have a lot of experience there. What are the good and the bad things about how they suggest doing resource separation? Any other use cases? Dmitri From rmeggins at redhat.com Mon Mar 31 15:52:54 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Mar 2008 09:52:54 -0600 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <47EE1514.9080501@redhat.com> References: <87pru28dhw.fsf@rho.meyering.net> <47EE1514.9080501@redhat.com> Message-ID: <47F108D6.6080203@redhat.com> Perry N. Myers wrote: > Jim Meyering wrote: >> Please wait until the prompt is returned. >> Configuring ntpd >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> done configuring ntpd. >> Configuring directory server: >> [1/16]: creating directory server user >> [2/16]: creating directory server instance >> [3/16]: adding default schema >> [4/16]: enabling memberof plugin >> root : CRITICAL Failed to load memberof-conf.ldif: Command >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx >> -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 >> [5/16]: enabling referential integrity plugin >> root : CRITICAL Failed to load referint-conf.ldif: Command >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx >> -f /usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49 >> [6/16]: enabling distributed numeric assignment plugin >> root : CRITICAL Failed to load dna-conf.ldif: Command >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx >> -f /usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49 >> [7/16]: configuring uniqueness plugin >> root : CRITICAL Failed to load unique-attributes.ldif: Command >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx >> -f /dev/shm/tmp4dWkvF' returned non-zero exit status 49 >> [8/16]: creating indices >> root : CRITICAL Failed to load indices.ldif: Command >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx >> -f /usr/share/ipa/indices.ldif' returned non-zero exit status 49 >> [9/16]: configuring ssl for ds instance >> Unexpected error - see ipaserver-install.log for details: >> {'desc': 'Invalid credentials'} >> >> -------------------------- >> When I ran that ldapmodify command manually, it did this: >> >> root at iota# ldapmodify -h 127.0.0.1 -xv -D 'cn=Directory Manager' \ >> -w xxx -f /usr/share/ipa/memberof-conf.ldif >> ldap_initialize( ldap://127.0.0.1 ) >> ldap_bind: Invalid credentials (49) >> [Exit 49] > > This problem still exists in rawhide and as far as I can tell it is > not ipa related. The problem is actually with the fedora directory > server. > > What I've discovered is that if you run ns-slapd with the -d flag > (runs the server in the foreground) things work fine. If you run the > server without the -d flag, you get the Invalid credentials messages > even with the correct CN and password. > > I've been able to reproduce this in fedora-ds-base-1.1.0.1-3.fc9.x86_64. > > If anyone has any ideas let me know... I did some searching to see if > there is an existing bug for this and I didn't see one. Can you install a standalone Fedora DS? Does setup-ds.pl work? If so, does ldapmodify work? > Perry > > _______________________________________________ > 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 ssorce at redhat.com Mon Mar 31 16:01:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 12:01:32 -0400 Subject: [Freeipa-devel] [PATCH] fix account activation In-Reply-To: <47F10512.8050702@redhat.com> References: <47F10512.8050702@redhat.com> Message-ID: <1206979292.3533.159.camel@localhost.localdomain> On Mon, 2008-03-31 at 11:36 -0400, Rob Crittenden wrote: > Fix account activation. > > We do account activation by using a Class of Service based on group > membership. A problem can happen if the entry itself has an > nsaccountlock attribute and you try doing Class of Service work as > well > because the local attribute has priority. So try to detect that the > entry has a local nsAccountLock attribute and report an appropriate > error. > > Don't allow the admins or editors groups to be de-activated. > > Return a better error message if account [in]activation fails. Ack! Good Job Rob. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 31 16:04:47 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 12:04:47 -0400 Subject: [Freeipa-devel] [PATCH] Don't require Find when editing delegations In-Reply-To: <47E8176F.1010205@redhat.com> References: <47E8176F.1010205@redhat.com> Message-ID: <1206979487.3533.161.camel@localhost.localdomain> On Mon, 2008-03-24 at 17:04 -0400, Rob Crittenden wrote: > When adding a delegation you can just enter the CN of the group > without > doing a Find. The edit page required a Find. This makes them both > work > the same way. > > Also fixed a bug where on errors it was returning to the new screen > rather than update. Ack! -- Simo Sorce * Red Hat, Inc * New York From gdk at redhat.com Mon Mar 31 16:10:08 2008 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 31 Mar 2008 12:10:08 -0400 (EDT) Subject: [Freeipa-devel] Getting publicity for Free IPA Message-ID: So I've looked through the Free IPA archives, and 95% of the traffic on this list is from @redhat.com addresses. I'd like to help change that. :) Now that FreeIPA is packaged in Fedora, and is one of the "new features" of Fedora 9, we've clearly got a big opportunity. How do we get the word out? I've got a number of contacts with various Linux-y publications and so forth, and could also help write a story for Red Hat Magazine or Dev Fu. Is there anyone from the FreeIPA team who would be a good contact for this kind of story? It might be time-consuming, but I think *now* is the time to raise your visibility. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From kranidiotis at hilonsys.com Mon Mar 31 16:15:34 2008 From: kranidiotis at hilonsys.com (Panagiotis Kranidiotis) Date: Mon, 31 Mar 2008 19:15:34 +0300 Subject: [Freeipa-devel] rawhide's ipa-server-install fails to configure directory server In-Reply-To: <47F108D6.6080203@redhat.com> References: <87pru28dhw.fsf@rho.meyering.net> <47EE1514.9080501@redhat.com> <47F108D6.6080203@redhat.com> Message-ID: <1206980134.6841.1.camel@anaximandros> I have the same problem. Actually is there any fedora build that ipa-server package is working smoothly so i can test it? ???? 31-03-2008, ????? ???, ??? ??? 09:52 -0600, ?/? Rich Megginson ??????: > Perry N. Myers wrote: > > Jim Meyering wrote: > >> Please wait until the prompt is returned. > >> Configuring ntpd > >> [1/4]: stopping ntpd > >> [2/4]: writing configuration > >> [3/4]: configuring ntpd to start on boot > >> [4/4]: starting ntpd > >> done configuring ntpd. > >> Configuring directory server: > >> [1/16]: creating directory server user > >> [2/16]: creating directory server instance > >> [3/16]: adding default schema > >> [4/16]: enabling memberof plugin > >> root : CRITICAL Failed to load memberof-conf.ldif: Command > >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx > >> -f /usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49 > >> [5/16]: enabling referential integrity plugin > >> root : CRITICAL Failed to load referint-conf.ldif: Command > >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx > >> -f /usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49 > >> [6/16]: enabling distributed numeric assignment plugin > >> root : CRITICAL Failed to load dna-conf.ldif: Command > >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx > >> -f /usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49 > >> [7/16]: configuring uniqueness plugin > >> root : CRITICAL Failed to load unique-attributes.ldif: Command > >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx > >> -f /dev/shm/tmp4dWkvF' returned non-zero exit status 49 > >> [8/16]: creating indices > >> root : CRITICAL Failed to load indices.ldif: Command > >> '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w xxx > >> -f /usr/share/ipa/indices.ldif' returned non-zero exit status 49 > >> [9/16]: configuring ssl for ds instance > >> Unexpected error - see ipaserver-install.log for details: > >> {'desc': 'Invalid credentials'} > >> > >> -------------------------- > >> When I ran that ldapmodify command manually, it did this: > >> > >> root at iota# ldapmodify -h 127.0.0.1 -xv -D 'cn=Directory Manager' \ > >> -w xxx -f /usr/share/ipa/memberof-conf.ldif > >> ldap_initialize( ldap://127.0.0.1 ) > >> ldap_bind: Invalid credentials (49) > >> [Exit 49] > > > > This problem still exists in rawhide and as far as I can tell it is > > not ipa related. The problem is actually with the fedora directory > > server. > > > > What I've discovered is that if you run ns-slapd with the -d flag > > (runs the server in the foreground) things work fine. If you run the > > server without the -d flag, you get the Invalid credentials messages > > even with the correct CN and password. > > > > I've been able to reproduce this in fedora-ds-base-1.1.0.1-3.fc9.x86_64. > > > > If anyone has any ideas let me know... I did some searching to see if > > there is an existing bug for this and I didn't see one. > Can you install a standalone Fedora DS? Does setup-ds.pl work? If so, > does ldapmodify work? > > Perry > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mdehaan at redhat.com Mon Mar 31 16:51:44 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 31 Mar 2008 12:51:44 -0400 Subject: [Freeipa-devel] Getting publicity for Free IPA In-Reply-To: References: Message-ID: <47F116A0.40806@redhat.com> Greg DeKoenigsberg wrote: > write a story for Red Hat Magazine or Dev Fu. Is there anyone from the > FreeIPA team who would be a good contact for this kind of story? > +1 Red Hat Magazine landed Cobbler about 1000 hits a month for several months, and still provides traffic. It's really worth it. If you guys are on Fedora planet, blogging there seems to help too. If you're not and want to get your blogs added, ask someone in #fedora-admin and they can add you. I also don't see FreeIPA on Freshmeat -- while Freshmeat itself isn't a /huge/ traffic source directly (I don't even read it), it is heavily aggregated by sites all over the place and isn't too hard to set up. It helps with Pagerank too. --Michael From ssorce at redhat.com Mon Mar 31 17:08:38 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 13:08:38 -0400 Subject: [Freeipa-devel] freeipa: changeset 1c82d79f24f9 Message-ID: <1206983318.3533.165.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/1c82d79f24f9 pushed under the trivial fix rule. Simo. From duffy at redhat.com Mon Mar 31 17:29:04 2008 From: duffy at redhat.com (=?ISO-8859-1?Q?M=E1ir=EDn_Duffy?=) Date: Mon, 31 Mar 2008 13:29:04 -0400 Subject: [Freeipa-devel] Getting publicity for Free IPA In-Reply-To: <47F116A0.40806@redhat.com> References: <47F116A0.40806@redhat.com> Message-ID: <47F11F60.2000007@redhat.com> Michael DeHaan wrote: > Greg DeKoenigsberg wrote: >> write a story for Red Hat Magazine or Dev Fu. Is there anyone from the >> FreeIPA team who would be a good contact for this kind of story? >> > > +1 > > Red Hat Magazine landed Cobbler about 1000 hits a month for several > months, and still provides traffic. It's really worth it. > > If you guys are on Fedora planet, blogging there seems to help too. If > you're not and want to get your blogs added, ask someone in #fedora-admin > and they can add you. > > I also don't see FreeIPA on Freshmeat -- while Freshmeat itself isn't a > /huge/ traffic source directly (I don't even read it), it is heavily > aggregated by sites all over the place and isn't too hard to set up. It > helps with Pagerank too. If it hasn't been done already the Fedora marketing team could interview one of the devels and post the interview on digg.... we had some pretty good responses to these leading up to F8. ~m From gdk at redhat.com Mon Mar 31 17:33:51 2008 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 31 Mar 2008 13:33:51 -0400 (EDT) Subject: [Freeipa-devel] Getting publicity for Free IPA In-Reply-To: <47F11F60.2000007@redhat.com> References: <47F116A0.40806@redhat.com> <47F11F60.2000007@redhat.com> Message-ID: On Mon, 31 Mar 2008, M?ir?n Duffy wrote: > Michael DeHaan wrote: >> Greg DeKoenigsberg wrote: >>> write a story for Red Hat Magazine or Dev Fu. Is there anyone from the >>> FreeIPA team who would be a good contact for this kind of story? >>> >> >> +1 >> >> Red Hat Magazine landed Cobbler about 1000 hits a month for several months, >> and still provides traffic. It's really worth it. >> >> If you guys are on Fedora planet, blogging there seems to help too. If >> you're not and want to get your blogs added, ask someone in #fedora-admin >> and they can add you. >> >> I also don't see FreeIPA on Freshmeat -- while Freshmeat itself isn't a >> /huge/ traffic source directly (I don't even read it), it is heavily >> aggregated by sites all over the place and isn't too hard to set up. It >> helps with Pagerank too. > > If it hasn't been done already the Fedora marketing team could interview one > of the devels and post the interview on digg.... we had some pretty good > responses to these leading up to F8. Agreed. My real goal here is to find "The Spokesmodel" of the FreeIPA team, to whom we can funnel these kinds of opportunities. Maybe that's Karl Wirth. :) --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From rcritten at redhat.com Mon Mar 31 18:12:38 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 14:12:38 -0400 Subject: [Freeipa-devel] Getting publicity for Free IPA In-Reply-To: <47F11F60.2000007@redhat.com> References: <47F116A0.40806@redhat.com> <47F11F60.2000007@redhat.com> Message-ID: <47F12996.4060205@redhat.com> M?ir?n Duffy wrote: > Michael DeHaan wrote: >> Greg DeKoenigsberg wrote: >>> write a story for Red Hat Magazine or Dev Fu. Is there anyone from >>> the FreeIPA team who would be a good contact for this kind of story? >>> >> >> +1 >> >> Red Hat Magazine landed Cobbler about 1000 hits a month for several >> months, and still provides traffic. It's really worth it. >> >> If you guys are on Fedora planet, blogging there seems to help too. If >> you're not and want to get your blogs added, ask someone in #fedora-admin >> and they can add you. >> >> I also don't see FreeIPA on Freshmeat -- while Freshmeat itself isn't >> a /huge/ traffic source directly (I don't even read it), it is heavily >> aggregated by sites all over the place and isn't too hard to set up. >> It helps with Pagerank too. > > If it hasn't been done already the Fedora marketing team could interview > one of the devels and post the interview on digg.... we had some pretty > good responses to these leading up to F8. > That is in the works, I just need to finish it up. They have been very patient with me. 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 email.ahmedkamal at googlemail.com Mon Mar 31 18:41:03 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 31 Mar 2008 20:41:03 +0200 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <1206965557.3533.124.camel@localhost.localdomain> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> <3da3b5b40803310023yaace44fo2ce56ed7bed2248b@mail.gmail.com> <1206965557.3533.124.camel@localhost.localdomain> Message-ID: <3da3b5b40803311141t36f8471ay5db89920425ba20e@mail.gmail.com> > > There some key differences indeed, and AD has some neat solutions. > But the fact is that Linux and other Unices are tied to the POSIX > model,a nd that's what we have to deal with. > *why* does GNU/Linux always has to stick to Ancient And Broken (AAB) designs! M$ had AAB designs too in the NT era, but they refreshed the design, introduced very neat solutions, and also introduced a "compatibility" mode for those who want to stick with older boxes. After around a decade (which is now) no one is running WinNT in production, no one simply needs it! Why doesn't GNU/Linux get a chance to brush off old skin and "evolve" in such ways? For example, the flat user/group namespace is not a different design, it's a plain broken design as mentioned multiple times by Jeremy Allison AFAIR, why aren't we trying to improve the situation while maintaining compatibility for those who need it for now, instead of sticking to "that's what we have to deal with"! Does everyone agree I am wrong :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 31 19:19:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 15:19:04 -0400 Subject: [Freeipa-devel] [PATCH] remove default group from list when adding a user in UI Message-ID: <47F13928.5040105@redhat.com> When adding a user in the UI if you put the default user group in the list of groups for the user then the add will fail because we already do that. So remove the default group before proceeding. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-773-adduser.patch Type: text/x-patch Size: 1895 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 Mar 31 19:53:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 15:53:01 -0400 Subject: [Freeipa-devel] [PATCH] remove default group from list when adding a user in UI In-Reply-To: <47F13928.5040105@redhat.com> References: <47F13928.5040105@redhat.com> Message-ID: <1206993181.3533.169.camel@localhost.localdomain> On Mon, 2008-03-31 at 15:19 -0400, Rob Crittenden wrote: > When adding a user in the UI if you put the default user group in the > list of groups for the user then the add will fail because we already > do > that. So remove the default group before proceeding. ack. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 31 20:14:35 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 16:14:35 -0400 Subject: [Freeipa-devel] [PATCH] fix account activation In-Reply-To: <1206979292.3533.159.camel@localhost.localdomain> References: <47F10512.8050702@redhat.com> <1206979292.3533.159.camel@localhost.localdomain> Message-ID: <47F1462B.10203@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-31 at 11:36 -0400, Rob Crittenden wrote: >> Fix account activation. >> >> We do account activation by using a Class of Service based on group >> membership. A problem can happen if the entry itself has an >> nsaccountlock attribute and you try doing Class of Service work as >> well >> because the local attribute has priority. So try to detect that the >> entry has a local nsAccountLock attribute and report an appropriate >> error. >> >> Don't allow the admins or editors groups to be de-activated. >> >> Return a better error message if account [in]activation fails. > > Ack! > Good Job Rob. > > Simo. > thanks pushed -------------- 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 Mar 31 20:14:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 16:14:41 -0400 Subject: [Freeipa-devel] [PATCH] Don't require Find when editing delegations In-Reply-To: <1206979487.3533.161.camel@localhost.localdomain> References: <47E8176F.1010205@redhat.com> <1206979487.3533.161.camel@localhost.localdomain> Message-ID: <47F14631.6000700@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-24 at 17:04 -0400, Rob Crittenden wrote: >> When adding a delegation you can just enter the CN of the group >> without >> doing a Find. The edit page required a Find. This makes them both >> work >> the same way. >> >> Also fixed a bug where on errors it was returning to the new screen >> rather than update. > > Ack! > pushed -------------- 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 Mar 31 20:14:48 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 16:14:48 -0400 Subject: [Freeipa-devel] [PATCH] remove default group from list when adding a user in UI In-Reply-To: <1206993181.3533.169.camel@localhost.localdomain> References: <47F13928.5040105@redhat.com> <1206993181.3533.169.camel@localhost.localdomain> Message-ID: <47F14638.3030501@redhat.com> Simo Sorce wrote: > On Mon, 2008-03-31 at 15:19 -0400, Rob Crittenden wrote: >> When adding a user in the UI if you put the default user group in the >> list of groups for the user then the add will fail because we already >> do >> that. So remove the default group before proceeding. > > ack. > pushed -------------- 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 Mar 31 21:26:30 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 17:26:30 -0400 Subject: [Freeipa-devel] freeipa: changeset 5a2e7eee6d7e Message-ID: <1206998790.3533.171.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/5a2e7eee6d7e pushed directly under the trivial patch rule Simo. From ssorce at redhat.com Mon Mar 31 21:41:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 17:41:32 -0400 Subject: [Freeipa-devel] [PATCH] Sysrestore fixes Message-ID: <47F15A8C.7000009@redhat.com> last sysrestore patch did work correctly but was putting files in the wrong path, fix it and uniform also StateFile class to use the same model. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-749-syrestore-tmp-fix.patch Type: text/x-patch Size: 7765 bytes Desc: not available URL: From ssorce at redhat.com Mon Mar 31 21:43:57 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 17:43:57 -0400 Subject: [Freeipa-devel] [PATCH] implement client uninstall Message-ID: <47F15B1D.2050104@redhat.com> 3 patches: - Client bits (this uses syrestore and puts stuff in /var/lib/ipa-client/sysrestore) - RHEL4 contrib script bits - Server install script call to uninstall client bits Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-750-client-uninstall.patch Type: text/x-patch Size: 6902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-751-rhel4-uninstall.patch Type: text/x-patch Size: 1345 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-752-server-client-uninstall.patch Type: text/x-patch Size: 1693 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 31 21:48:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 17:48:04 -0400 Subject: [Freeipa-devel] [PATCH] Sysrestore fixes In-Reply-To: <47F15A8C.7000009@redhat.com> References: <47F15A8C.7000009@redhat.com> Message-ID: <47F15C14.4090207@redhat.com> Simo Sorce wrote: > last sysrestore patch did work correctly but was putting files in the > wrong path, fix it and uniform also StateFile class to use the same model. > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Mar 31 21:59:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 17:59:25 -0400 Subject: [Freeipa-devel] [PATCH] implement client uninstall In-Reply-To: <47F15B1D.2050104@redhat.com> References: <47F15B1D.2050104@redhat.com> Message-ID: <47F15EBD.9000504@redhat.com> Simo Sorce wrote: > 3 patches: > - Client bits > (this uses syrestore and puts stuff in /var/lib/ipa-client/sysrestore) > > - RHEL4 contrib script bits > > - Server install script call to uninstall client bits > > > Simo. > > Ack. Note, we need to put a check in to be sure that ipa-client-install is being run by root. But that can come later. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Mar 31 22:02:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 18:02:56 -0400 Subject: [Freeipa-devel] [PATCH] Sysrestore fixes In-Reply-To: <47F15C14.4090207@redhat.com> References: <47F15A8C.7000009@redhat.com> <47F15C14.4090207@redhat.com> Message-ID: <1207000976.3533.173.camel@localhost.localdomain> On Mon, 2008-03-31 at 17:48 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > last sysrestore patch did work correctly but was putting files in > the > > wrong path, fix it and uniform also StateFile class to use the same > model. > > > > > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 31 22:03:30 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 18:03:30 -0400 Subject: [Freeipa-devel] [PATCH] implement client uninstall In-Reply-To: <47F15EBD.9000504@redhat.com> References: <47F15B1D.2050104@redhat.com> <47F15EBD.9000504@redhat.com> Message-ID: <1207001010.3533.175.camel@localhost.localdomain> On Mon, 2008-03-31 at 17:59 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > 3 patches: > > - Client bits > > (this uses syrestore and puts stuff > in /var/lib/ipa-client/sysrestore) > > > > - RHEL4 contrib script bits > > > > - Server install script call to uninstall client bits > > > > > > Simo. > > > > > > Ack. pushed > Note, we need to put a check in to be sure that ipa-client-install is > being run by root. But that can come later. ok -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 31 22:29:38 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2008 18:29:38 -0400 Subject: [Freeipa-devel] [PATCH] Don't use funky regex Message-ID: <47F165D2.2060806@redhat.com> A regex was used to identify the remote host in replication agreements. This isn't necessary, we have the host in an attribute, use that instead. Pushed under the one-liner rule. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-774-replica.patch Type: text/x-patch Size: 910 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 Mar 31 22:41:52 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 18:41:52 -0400 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <3da3b5b40803311141t36f8471ay5db89920425ba20e@mail.gmail.com> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> <3da3b5b40803310023yaace44fo2ce56ed7bed2248b@mail.gmail.com> <1206965557.3533.124.camel@localhost.localdomain> <3da3b5b40803311141t36f8471ay5db89920425ba20e@mail.gmail.com> Message-ID: <1207003312.3533.189.camel@localhost.localdomain> On Mon, 2008-03-31 at 20:41 +0200, Ahmed Kamal wrote: > There some key differences indeed, and AD has some neat > solutions. > But the fact is that Linux and other Unices are tied to the > POSIX > model,a nd that's what we have to deal with. > > > *why* does GNU/Linux always has to stick to Ancient And Broken (AAB) > designs! M$ had AAB designs too in the NT era, but they refreshed the > design, introduced very neat solutions, and also introduced a > "compatibility" mode for those who want to stick with older boxes. > After around a decade (which is now) no one is running WinNT in > production, no one simply needs it! Why doesn't GNU/Linux get a chance > to brush off old skin and "evolve" in such ways? Eehh, to be honest the core of NT is still what powers current Windows stuff, very few changes were made in the kernel semantics. > For example, the flat user/group namespace is not a different design, > it's a plain broken design as mentioned multiple times by Jeremy > Allison AFAIR, why aren't we trying to improve the situation while > maintaining compatibility for those who need it for now, instead of > sticking to "that's what we have to deal with"! Because you cannot easily maintain compatibility when you break semantics I guess :-) And also because you need to prove that something is indeed need for well defined use cases before breaking with a very well established set of *standards* like POSIX, SUS and countless others. A change in these core components is not trivial as it has a rippling effect on almost the whole system, not something you can do lightly or quickly. But don't worry I have evil plans to conquer the world and change the situation eventually > Does everyone agree I am wrong :) No, but recognizing a problem is only the very first step to start implementing a solution, and many still do not see or recognize this as a problem. There is a long road to a decent solution for network wide identities. I hope we will be able to implement part of the solution within FreeIPA in the next years and slowly help others help us into getting what is needed in the right places. Now, what about getting back to v2 planning and discussion about how to deal with cross-realm trust relationship in the given framework ? :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Mar 31 22:55:58 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2008 18:55:58 -0400 Subject: [Freeipa-devel] [PATCH] Don't use funky regex In-Reply-To: <47F165D2.2060806@redhat.com> References: <47F165D2.2060806@redhat.com> Message-ID: <1207004158.3533.191.camel@localhost.localdomain> On Mon, 2008-03-31 at 18:29 -0400, Rob Crittenden wrote: > A regex was used to identify the remote host in replication > agreements. > This isn't necessary, we have the host in an attribute, use that > instead. > > Pushed under the one-liner rule. ack, very good. -- Simo Sorce * Red Hat, Inc * New York From email.ahmedkamal at googlemail.com Mon Mar 31 23:37:32 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 1 Apr 2008 01:37:32 +0200 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <1207003312.3533.189.camel@localhost.localdomain> References: <1206924493.3533.115.camel@localhost.localdomain> <47F03DD6.9090904@redhat.com> <3da3b5b40803310023yaace44fo2ce56ed7bed2248b@mail.gmail.com> <1206965557.3533.124.camel@localhost.localdomain> <3da3b5b40803311141t36f8471ay5db89920425ba20e@mail.gmail.com> <1207003312.3533.189.camel@localhost.localdomain> Message-ID: <3da3b5b40803311637w68479e6ftf871545063ac2d23@mail.gmail.com> May the force be with you :) FreeIPA is surely very interesting, and is very much needed. Regards On Tue, Apr 1, 2008 at 12:41 AM, Simo Sorce wrote: > > On Mon, 2008-03-31 at 20:41 +0200, Ahmed Kamal wrote: > > There some key differences indeed, and AD has some neat > > solutions. > > But the fact is that Linux and other Unices are tied to the > > POSIX > > model,a nd that's what we have to deal with. > > > > > > *why* does GNU/Linux always has to stick to Ancient And Broken (AAB) > > designs! M$ had AAB designs too in the NT era, but they refreshed the > > design, introduced very neat solutions, and also introduced a > > "compatibility" mode for those who want to stick with older boxes. > > After around a decade (which is now) no one is running WinNT in > > production, no one simply needs it! Why doesn't GNU/Linux get a chance > > to brush off old skin and "evolve" in such ways? > > Eehh, to be honest the core of NT is still what powers current Windows > stuff, very few changes were made in the kernel semantics. > > > For example, the flat user/group namespace is not a different design, > > it's a plain broken design as mentioned multiple times by Jeremy > > Allison AFAIR, why aren't we trying to improve the situation while > > maintaining compatibility for those who need it for now, instead of > > sticking to "that's what we have to deal with"! > > Because you cannot easily maintain compatibility when you break > semantics I guess :-) > And also because you need to prove that something is indeed need for > well defined use cases before breaking with a very well established set > of *standards* like POSIX, SUS and countless others. > A change in these core components is not trivial as it has a rippling > effect on almost the whole system, not something you can do lightly or > quickly. > > But don't worry I have evil plans to conquer the world and change the > situation eventually > > > Does everyone agree I am wrong :) > > No, but recognizing a problem is only the very first step to start > implementing a solution, and many still do not see or recognize this as > a problem. There is a long road to a decent solution for network wide > identities. I hope we will be able to implement part of the solution > within FreeIPA in the next years and slowly help others help us into > getting what is needed in the right places. > > Now, what about getting back to v2 planning and discussion about how to > deal with cross-realm trust relationship in the given framework ? :-) > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: