From natxo.asenjo at gmail.com Fri Apr 1 07:01:55 2011 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 1 Apr 2011 09:01:55 +0200 Subject: [Freeipa-users] IPA Client join [OT] Message-ID: On Fri, Apr 1, 2011 at 1:21 AM, Steven Jones wrote: > Hi, > > Just a note...on compatibility....yes I know IPA isnt fit yet but....... > > If your POC environment is Vmware based F14 isnt supported for vmtools and you cant install vmware tools either it barfs at kernel detection, not good. I feel your pain but that's why tools like cfengine or puppet are for. Just compile the vmware tools in one vm and distribute them to the rest. Or just make a clone of that vm with the self compiled tools if you feel having a configuration management tool is too much overhead (IMO when having more than 10 hosts to manage, you will be glad you have decided to use some config management). We have waited so long for v2 of the freeipa project to come that we no longer can wait for the long term support in rhel, it seems :-). It really fills in a gap. -- natxo From roland.kaeser at intersoft-networks.ch Fri Apr 1 07:05:35 2011 From: roland.kaeser at intersoft-networks.ch (Roland Kaeser) Date: Fri, 01 Apr 2011 09:05:35 +0200 (CEST) Subject: [Freeipa-users] IPA Client join In-Reply-To: <4D94CC03.30406@redhat.com> Message-ID: Hello >The next update will be in 6.1. I can probably cobble together a srpm >that would work on 6.0 until 6.1 is released if you'd like. Is there a definitive release date for 6.1? I would like to have srpm for 6.0, if possible, to start building up my pilot. Thanks Roland ----- Urspr?ngliche Mail ----- Von: "Rob Crittenden" An: "Roland K?ser" CC: freeipa-users at redhat.com Gesendet: Donnerstag, 31. M?rz 2011 20:46:27 Betreff: Re: [Freeipa-users] IPA Client join Roland Kaeser wrote: > Hello > >> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? The next update will be in 6.1. I can probably cobble together a srpm that would work on 6.0 until 6.1 is released if you'd like. > > So which is the software stack to use for my pilot and the later production environment? > I wouldn't like to use Fedora in company production environments. I would be really prefer to use RHEL6/6.1 > I also checked the latest avialable fedora 15 version. I only can find a alpha version iso from february, 28. > > I would really like to have a software stack which works with freeipa (client/server) and afs-server. Yeah, this is a bit of a grey area right now. IPA does a lot of cat herding and keeping all the various versions of the packages we require in sync is very tedious. For a pilot I think you'd be fine using Fedora 14 though I would recommend doing some amount of re-testing in F-15 once it is released. We've done 80% of our development in F-14 and it works very well. The dogtag project built F-14 packages for us as a favor. They don't want to support deployments of it because they've done zero testing of their own on F-14. You'd need to build the packages yourself though, we haven't pushed this to F-14 because of the dogtag issue. mock should be able to build it fairly painlessly. What I've done for my F-15 installations is to install F-14 and then upgrade to Fedora-15 from there. It has been fairly painless. The GA IPA release is in the stable repo of F-15 now. regards rob > > > ----- Urspr?ngliche Mail ----- > Von: "Sigbjorn Lie" > An: "Rob Crittenden" > CC: "Roland K??ser", freeipa-users at redhat.com > Gesendet: Donnerstag, 31. M?rz 2011 16:14:34 > Betreff: Re: [Freeipa-users] IPA Client join > >> >> In rc2 we had to make a change to the OID used for some operations >> because they were duplicated. The OID for the ipa-getkeytab operation was one of them, so older >> clients don't work with newer servers. IIRC the EL6 ipa-client was based on the alpha 3 release. >> >> I attached a patch that gives the general idea of what needs to change. >> It was originally for the EL 5 branch but it may work with few changes >> in EL6. >> > > Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? > > > Rgds, > Siggi > > > -- InterSoft Networks Roland K?ser, Systems Engineer OpenSource Fulachstr. 197, 8200 Schaffhausen Tel: +41 77 415 79 11 ------------------------------------------------------------------------------------------------------------------------------ Diejenigen, die ihre Freiheit zugunsten der Sicherheit aufgeben, werden am Ende keines von beiden haben - und verdienen es auch nicht. (Benjamin Franklin) ------------------------------------------------------------------------------------------------------------------------------ From dpal at redhat.com Fri Apr 1 13:38:16 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 01 Apr 2011 09:38:16 -0400 Subject: [Freeipa-users] IPA Client join In-Reply-To: References: Message-ID: <4D95D548.4080700@redhat.com> On 04/01/2011 03:05 AM, Roland Kaeser wrote: > Hello > >> The next update will be in 6.1. I can probably cobble together a srpm >> that would work on 6.0 until 6.1 is released if you'd like. > Is there a definitive release date for 6.1? I would like to have srpm for 6.0, if possible, to start building up my pilot. > Thanks > > Roland > > > ----- Urspr?ngliche Mail ----- > Von: "Rob Crittenden" > An: "Roland K?ser" > CC: freeipa-users at redhat.com > Gesendet: Donnerstag, 31. M?rz 2011 20:46:27 > Betreff: Re: [Freeipa-users] IPA Client join > > Roland Kaeser wrote: >> Hello >> >>> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? > The next update will be in 6.1. I can probably cobble together a srpm > that would work on 6.0 until 6.1 is released if you'd like. > >> So which is the software stack to use for my pilot and the later production environment? >> I wouldn't like to use Fedora in company production environments. I would be really prefer to use RHEL6/6.1 >> I also checked the latest avialable fedora 15 version. I only can find a alpha version iso from february, 28. >> >> I would really like to have a software stack which works with freeipa (client/server) and afs-server. > Yeah, this is a bit of a grey area right now. IPA does a lot of cat > herding and keeping all the various versions of the packages we require > in sync is very tedious. > > For a pilot I think you'd be fine using Fedora 14 though I would > recommend doing some amount of re-testing in F-15 once it is released. > We've done 80% of our development in F-14 and it works very well. The > dogtag project built F-14 packages for us as a favor. They don't want to > support deployments of it because they've done zero testing of their own > on F-14. You'd need to build the packages yourself though, we haven't > pushed this to F-14 because of the dogtag issue. mock should be able to > build it fairly painlessly. > > What I've done for my F-15 installations is to install F-14 and then > upgrade to Fedora-15 from there. It has been fairly painless. The GA IPA > release is in the stable repo of F-15 now. > > regards > > rob > >> >> ----- Urspr?ngliche Mail ----- >> Von: "Sigbjorn Lie" >> An: "Rob Crittenden" >> CC: "Roland K??ser", freeipa-users at redhat.com >> Gesendet: Donnerstag, 31. M?rz 2011 16:14:34 >> Betreff: Re: [Freeipa-users] IPA Client join >> >>> In rc2 we had to make a change to the OID used for some operations >>> because they were duplicated. The OID for the ipa-getkeytab operation was one of them, so older >>> clients don't work with newer servers. IIRC the EL6 ipa-client was based on the alpha 3 release. >>> >>> I attached a patch that gives the general idea of what needs to change. >>> It was originally for the EL 5 branch but it may work with few changes >>> in EL6. >>> >> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? RHEL update releases are coming at about every 6-7 months. The 6.0 release was in November. 6.1 beta is out. You can do your math. Keep in mind that IPA in RHEL 6.1 will be in tech preview. This means that it will work but it is not in the state when we are confident that it meets all usual RHEL related quality expectations of our customers. So we will be stabilizing it in upcoming months so that we can declare full support in 6.2 later this year. >> >> Rgds, >> Siggi >> >> >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Apr 1 14:54:24 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 01 Apr 2011 10:54:24 -0400 Subject: [Freeipa-users] IPA Client join In-Reply-To: References: Message-ID: <4D95E720.5010802@redhat.com> Roland Kaeser wrote: > Hello > >> The next update will be in 6.1. I can probably cobble together a srpm >> that would work on 6.0 until 6.1 is released if you'd like. > > Is there a definitive release date for 6.1? I would like to have srpm for 6.0, if possible, to start building up my pilot. > Thanks Attached is a srpm that updates the OIDs. I did a very brief smoke-test and was able to join a 6.0 client to a F-15 server. The tarball is still alpha 3. rob > > Roland > > > ----- Urspr?ngliche Mail ----- > Von: "Rob Crittenden" > An: "Roland K?ser" > CC: freeipa-users at redhat.com > Gesendet: Donnerstag, 31. M?rz 2011 20:46:27 > Betreff: Re: [Freeipa-users] IPA Client join > > Roland Kaeser wrote: >> Hello >> >>> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? > > The next update will be in 6.1. I can probably cobble together a srpm > that would work on 6.0 until 6.1 is released if you'd like. > >> >> So which is the software stack to use for my pilot and the later production environment? >> I wouldn't like to use Fedora in company production environments. I would be really prefer to use RHEL6/6.1 >> I also checked the latest avialable fedora 15 version. I only can find a alpha version iso from february, 28. >> >> I would really like to have a software stack which works with freeipa (client/server) and afs-server. > > Yeah, this is a bit of a grey area right now. IPA does a lot of cat > herding and keeping all the various versions of the packages we require > in sync is very tedious. > > For a pilot I think you'd be fine using Fedora 14 though I would > recommend doing some amount of re-testing in F-15 once it is released. > We've done 80% of our development in F-14 and it works very well. The > dogtag project built F-14 packages for us as a favor. They don't want to > support deployments of it because they've done zero testing of their own > on F-14. You'd need to build the packages yourself though, we haven't > pushed this to F-14 because of the dogtag issue. mock should be able to > build it fairly painlessly. > > What I've done for my F-15 installations is to install F-14 and then > upgrade to Fedora-15 from there. It has been fairly painless. The GA IPA > release is in the stable repo of F-15 now. > > regards > > rob > >> >> >> ----- Urspr?ngliche Mail ----- >> Von: "Sigbjorn Lie" >> An: "Rob Crittenden" >> CC: "Roland K??ser", freeipa-users at redhat.com >> Gesendet: Donnerstag, 31. M?rz 2011 16:14:34 >> Betreff: Re: [Freeipa-users] IPA Client join >> >>> >>> In rc2 we had to make a change to the OID used for some operations >>> because they were duplicated. The OID for the ipa-getkeytab operation was one of them, so older >>> clients don't work with newer servers. IIRC the EL6 ipa-client was based on the alpha 3 release. >>> >>> I attached a patch that gives the general idea of what needs to change. >>> It was originally for the EL 5 branch but it may work with few changes >>> in EL6. >>> >> >> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? >> >> >> Rgds, >> Siggi >> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-client-2.0-9.1.el6.src.rpm Type: application/x-rpm Size: 1899540 bytes Desc: not available URL: From Steven.Jones at vuw.ac.nz Sun Apr 3 21:29:54 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 3 Apr 2011 21:29:54 +0000 Subject: [Freeipa-users] 6.1 beta Message-ID: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, This has IPA 2.0 rcX server and client in it? regards Steven From Steven.Jones at vuw.ac.nz Sun Apr 3 21:39:47 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 3 Apr 2011 21:39:47 +0000 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E400366A6@STAWINCOX10MBX1.staff.vuw.ac.nz> ooohhh Think I can answer that myself! ipa-server-2.0.0-16.el6.x86_64 :D regards ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Monday, 4 April 2011 9:29 a.m. To: dpal at redhat.com; freeipa-users at redhat.com Subject: [Freeipa-users] 6.1 beta Hi, This has IPA 2.0 rcX server and client in it? regards Steven _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Sun Apr 3 21:41:24 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sun, 03 Apr 2011 23:41:24 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4D98E984.3070201@nixtra.com> According to Red Hat Network it does: ipa-server-2.0.0-16.el6.x86_64 Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) ipa-server-2.0.0-16.el6.i686 Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) Rgds, Siggi On 04/03/2011 11:29 PM, Steven Jones wrote: > Hi, > > This has IPA 2.0 rcX server and client in it? > > regards > > Steven > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Mon Apr 4 02:58:56 2011 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 3 Apr 2011 22:58:56 -0400 Subject: [Freeipa-users] NIS/local files to IPA migration In-Reply-To: <50965.213.225.75.97.1301319798.squirrel@www.nixtra.com> References: <4D8FB6E1.1080806@nixtra.com> <4D907FBF.2090709@redhat.com> <45284.213.225.75.97.1301317295.squirrel@www.nixtra.com> <4D908C11.7080502@redhat.com> <50965.213.225.75.97.1301319798.squirrel@www.nixtra.com> Message-ID: <20110403225856.730b35e6@willson.li.ssimo.org> On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) "Sigbjorn Lie" wrote: > On Mon, March 28, 2011 15:24, Dmitri Pal wrote: > > On 03/28/2011 09:01 AM, Sigbjorn Lie wrote: > > > >> On Mon, March 28, 2011 14:31, Dmitri Pal wrote: > >> > >>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> I have written some scripts for migration from NIS/local files > >>>> to IPA. They will import the passwd, group, netgroup, and hosts > >>>> maps. > >>>> > >>>> > >>>> > >>>> This is the first version, be aware of bugs. :) > >>>> > >>>> > >>>> > >>>> Please read the README file before using. > >>>> > >>>> > >>>> > >>>> You can download them from here if you are interested: > >>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php > >>>> > >>>> > >>> Thank you for the contribution! > >>> I see that it is under GPL v2. Would you mind relicensing it > >>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html > >>> > >>> > >>> > >>> Would you be interested in these scripts being incorporated into > >>> the project source? Rob, can you please take a look into this? > >>> Should we consider rewriting them in Python and incorporating > >>> into the main tool set or leave and use as is? > >>> > >>> > >>> > >> Sure I can relicense to GPL v3. All I care about is the scripts > >> staying open and free to use. :) > >> > >> > >> You can include as a part of IPA if you would like. I was planning > >> to re-write them all into perl, as my initial efforts to write > >> them in bash for maximum portability didn't work out, and the > >> netgroup and hosts import scripts ended up written in perl. > >> > >> I cannot help re-writing to python, I don't know the language. > >> > >> > > > > Ok, thank you! > > > > > > Can you elaborate a bit about the constraints you have regarding > > migration. As far as I understand you have users and groups with > > colliding gids and you have to resolve things manually to make > > things exactly as they were and IPA as is does not allow you to do > > so as it always creates a privite group with the same GID. > > > > I have a stupid question: what is the implication of actually not > > doing things exactly as they were but rather embracing the IPA > > model of the unified UID/GID namespace? Is the reason that there > > are some applications scattered in the enterprise that might have > > gids configured explicitly in the configuration files (like SUDO > > for example) and updating those would be a challenge or there is > > something else? > > > > That question is not stupid. However...:) > > Migrating group id's is possible, but quite a job. We just moved a > few users's uid's as they had been in the enterprise for very many > years, and had a dangerously low UID's. Searching trough the file > servers for files belonging to these few users using a "find -exec > chown ..." took 3 days. Migrating GID's would also take a very long > time. > > Secondly, any files restored from backup would have the wrong > uid/gid. Several of our clients have a rentention time of 10 years > for backups. That's quite some time to keep a mapping table over > new/old uids/gids. > > Third, we would need to map our applications to see if any of them > store or use the GID. > > As you can see, migrating to IPA just became a much more time > consuming and higher risk project than it could be. > > Is there a reason for why the approach with a private group per user > is forcibly chosen? As a default it gives us the maximum compatibility with other directory services (like AD). Plus when we did freeipa v1 we got a lot of push back when we choose a single group (ipausers) to be the primary group due to traditional umask use for users. So we decided to make it a default and let admins that really do not want it to remove the groups. I guess we could add a switch somewhere to turn off UPG groups creation completely, if you think that is something really important you may want to open an RFE, although I am not sure when we will have cycles to get to implement such a switch for the moment. Simo. -- Simo Sorce * Red Hat, Inc * New York From janfrode at tanso.net Mon Apr 4 08:12:26 2011 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Mon, 4 Apr 2011 10:12:26 +0200 Subject: [Freeipa-users] migrate from LDAP to FreeIPA ? In-Reply-To: <4D8D059A.4000307@redhat.com> References: <4D8D059A.4000307@redhat.com> Message-ID: <20110404081226.GA15381@oc1046828364.ibm.com> On Fri, Mar 25, 2011 at 05:14:02PM -0400, Rob Crittenden wrote: > > Shouldn't be too bad. Here is our beta documentation on migration: > > http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#chap-Enterprise_Identity_Management_Guide-Migrating_from_a_Directory_Server_to_IPA Ok, good, that looks like it should cover the bulk of our migration. The other problems I'm looking at are probably more of design issues. Are there a deployment guide somewhere as well ? Currently we use netgroups for servers and users, mainly to manage who can log in to which server trough pam_access/access.conf plus for sudo rules. Should we continue using netgroups, or will the "user groups" and "host groups" in IPA cover this ? Does the user groups allow nesting of posix groups ? I.e. user1 is member of group1 which automatically make him member of group2 and group3? Some guides for configuring roles/privileges would be very interesting. We want to have "group admins" who are allowed to add/remove members of the groups this admin admins... Also we might want to allow team leaders to add new users.. Oh.. and are there any training available/planned for IPA (v2)? -jf From dpal at redhat.com Mon Apr 4 13:43:50 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 Apr 2011 09:43:50 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D98E984.3070201@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> Message-ID: <4D99CB16.5040603@redhat.com> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: > According to Red Hat Network it does: > > ipa-server-2.0.0-16.el6.x86_64 > > Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) > ipa-server-2.0.0-16.el6.i686 > > Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) > > > Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) > It is not the final bits though. There have done several bug fixes since then that will show up in the final 6.1 release. > > > Rgds, > Siggi > > > > On 04/03/2011 11:29 PM, Steven Jones wrote: >> Hi, >> >> This has IPA 2.0 rcX server and client in it? >> >> regards >> >> Steven >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Apr 4 13:49:55 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 Apr 2011 09:49:55 -0400 Subject: [Freeipa-users] NIS/local files to IPA migration In-Reply-To: <20110403225856.730b35e6@willson.li.ssimo.org> References: <4D8FB6E1.1080806@nixtra.com> <4D907FBF.2090709@redhat.com> <45284.213.225.75.97.1301317295.squirrel@www.nixtra.com> <4D908C11.7080502@redhat.com> <50965.213.225.75.97.1301319798.squirrel@www.nixtra.com> <20110403225856.730b35e6@willson.li.ssimo.org> Message-ID: <4D99CC83.7030303@redhat.com> On 04/03/2011 10:58 PM, Simo Sorce wrote: > On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) > "Sigbjorn Lie" wrote: > >> On Mon, March 28, 2011 15:24, Dmitri Pal wrote: >>> On 03/28/2011 09:01 AM, Sigbjorn Lie wrote: >>> >>>> On Mon, March 28, 2011 14:31, Dmitri Pal wrote: >>>> >>>>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> I have written some scripts for migration from NIS/local files >>>>>> to IPA. They will import the passwd, group, netgroup, and hosts >>>>>> maps. >>>>>> >>>>>> >>>>>> >>>>>> This is the first version, be aware of bugs. :) >>>>>> >>>>>> >>>>>> >>>>>> Please read the README file before using. >>>>>> >>>>>> >>>>>> >>>>>> You can download them from here if you are interested: >>>>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php >>>>>> >>>>>> >>>>> Thank you for the contribution! >>>>> I see that it is under GPL v2. Would you mind relicensing it >>>>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html >>>>> >>>>> >>>>> >>>>> Would you be interested in these scripts being incorporated into >>>>> the project source? Rob, can you please take a look into this? >>>>> Should we consider rewriting them in Python and incorporating >>>>> into the main tool set or leave and use as is? >>>>> >>>>> >>>>> >>>> Sure I can relicense to GPL v3. All I care about is the scripts >>>> staying open and free to use. :) >>>> >>>> >>>> You can include as a part of IPA if you would like. I was planning >>>> to re-write them all into perl, as my initial efforts to write >>>> them in bash for maximum portability didn't work out, and the >>>> netgroup and hosts import scripts ended up written in perl. >>>> >>>> I cannot help re-writing to python, I don't know the language. >>>> >>>> >>> Ok, thank you! >>> >>> >>> Can you elaborate a bit about the constraints you have regarding >>> migration. As far as I understand you have users and groups with >>> colliding gids and you have to resolve things manually to make >>> things exactly as they were and IPA as is does not allow you to do >>> so as it always creates a privite group with the same GID. >>> >>> I have a stupid question: what is the implication of actually not >>> doing things exactly as they were but rather embracing the IPA >>> model of the unified UID/GID namespace? Is the reason that there >>> are some applications scattered in the enterprise that might have >>> gids configured explicitly in the configuration files (like SUDO >>> for example) and updating those would be a challenge or there is >>> something else? >>> >> That question is not stupid. However...:) >> >> Migrating group id's is possible, but quite a job. We just moved a >> few users's uid's as they had been in the enterprise for very many >> years, and had a dangerously low UID's. Searching trough the file >> servers for files belonging to these few users using a "find -exec >> chown ..." took 3 days. Migrating GID's would also take a very long >> time. >> >> Secondly, any files restored from backup would have the wrong >> uid/gid. Several of our clients have a rentention time of 10 years >> for backups. That's quite some time to keep a mapping table over >> new/old uids/gids. >> >> Third, we would need to map our applications to see if any of them >> store or use the GID. >> >> As you can see, migrating to IPA just became a much more time >> consuming and higher risk project than it could be. >> >> Is there a reason for why the approach with a private group per user >> is forcibly chosen? > As a default it gives us the maximum compatibility with other directory > services (like AD). Plus when we did freeipa v1 we got a lot of push > back when we choose a single group (ipausers) to be the primary group > due to traditional umask use for users. > > So we decided to make it a default and let admins that really do not > want it to remove the groups. > I guess we could add a switch somewhere to turn off UPG groups creation > completely, if you think that is something really important you may > want to open an RFE, although I am not sure when we will have cycles to > get to implement such a switch for the moment. > > Simo. > Opened ticket: https://fedorahosted.org/freeipa/ticket/1154 -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Apr 4 13:59:27 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 Apr 2011 09:59:27 -0400 Subject: [Freeipa-users] migrate from LDAP to FreeIPA ? In-Reply-To: <20110404081226.GA15381@oc1046828364.ibm.com> References: <4D8D059A.4000307@redhat.com> <20110404081226.GA15381@oc1046828364.ibm.com> Message-ID: <4D99CEBF.3070109@redhat.com> On 04/04/2011 04:12 AM, Jan-Frode Myklebust wrote: > On Fri, Mar 25, 2011 at 05:14:02PM -0400, Rob Crittenden wrote: >> Shouldn't be too bad. Here is our beta documentation on migration: >> >> http://obriend.fedorapeople.org/freeIPA2.0/Identity_and_Policy_Management_Guide/html-single/#chap-Enterprise_Identity_Management_Guide-Migrating_from_a_Directory_Server_to_IPA > Ok, good, that looks like it should cover the bulk of our migration. > > The other problems I'm looking at are probably more of design issues. > Are there a deployment guide somewhere as well ? No not yet. This manual is what we have. But we will be very interested in hearing your opinion on what topics other than those we already have in the manual we should cover. > Currently we use netgroups for servers and users, mainly to manage who > can log in to which server trough pam_access/access.conf plus for sudo > rules. Should we continue using netgroups, or will the "user groups" and > "host groups" in IPA cover this ? We recommend using groups and host groups. Both support nesting. For the migration purposes a netgroup with the same name is created by default for any host group you create. This netgroup is jusr a pointer to the host group sort of a shell. This would allow you to use host groups in the admin model while the clients can continue to leverage notgroups until they get smart to use host groups directly. At that moment you would be able to turn off the automatic creation of the netgroups. But this will be a quite distant future. > Does the user groups allow nesting of > posix groups ? I.e. user1 is member of group1 which automatically make him > member of group2 and group3? Yes the groups are nested and you can mix posix and nonposix groups. > Some guides for configuring roles/privileges would be very interesting. > We want to have "group admins" who are allowed to add/remove members of > the groups this admin admins... Also we might want to allow team leaders > to add new users.. We do not have enough "solutions" worked out yet. Any contributions about your experience with IPA will be valuable. > Oh.. and are there any training available/planned for IPA (v2)? We will be giving presentation on the Summit. The training schedule is not yet worked out. > > -jf > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Mon Apr 4 14:34:16 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 4 Apr 2011 16:34:16 +0200 (CEST) Subject: [Freeipa-users] NIS/local files to IPA migration In-Reply-To: <20110403225856.730b35e6@willson.li.ssimo.org> References: <4D8FB6E1.1080806@nixtra.com> <4D907FBF.2090709@redhat.com> <45284.213.225.75.97.1301317295.squirrel@www.nixtra.com> <4D908C11.7080502@redhat.com> <50965.213.225.75.97.1301319798.squirrel@www.nixtra.com> <20110403225856.730b35e6@willson.li.ssimo.org> Message-ID: <47902.213.225.75.97.1301927656.squirrel@www.nixtra.com> On Mon, April 4, 2011 04:58, Simo Sorce wrote: > On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) > "Sigbjorn Lie" wrote: > > >> On Mon, March 28, 2011 15:24, Dmitri Pal wrote: >> >>> On 03/28/2011 09:01 AM, Sigbjorn Lie wrote: >>> >>> >>>> On Mon, March 28, 2011 14:31, Dmitri Pal wrote: >>>> >>>> >>>>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I have written some scripts for migration from NIS/local files >>>>>> to IPA. They will import the passwd, group, netgroup, and hosts maps. >>>>>> >>>>>> >>>>>> >>>>>> This is the first version, be aware of bugs. :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please read the README file before using. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> You can download them from here if you are interested: >>>>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php >>>>>> >>>>>> >>>>>> >>>>> Thank you for the contribution! >>>>> I see that it is under GPL v2. Would you mind relicensing it >>>>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html >>>>> >>>>> >>>>> >>>>> Would you be interested in these scripts being incorporated into >>>>> the project source? Rob, can you please take a look into this? Should we consider rewriting >>>>> them in Python and incorporating into the main tool set or leave and use as is? >>>>> >>>>> >>>>> >>>> Sure I can relicense to GPL v3. All I care about is the scripts >>>> staying open and free to use. :) >>>> >>>> >>>> You can include as a part of IPA if you would like. I was planning >>>> to re-write them all into perl, as my initial efforts to write them in bash for maximum >>>> portability didn't work out, and the netgroup and hosts import scripts ended up written in >>>> perl. >>>> >>>> I cannot help re-writing to python, I don't know the language. >>>> >>>> >>>> >>> >>> Ok, thank you! >>> >>> >>> >>> Can you elaborate a bit about the constraints you have regarding >>> migration. As far as I understand you have users and groups with colliding gids and you have to >>> resolve things manually to make things exactly as they were and IPA as is does not allow you >>> to do so as it always creates a privite group with the same GID. >>> >>> I have a stupid question: what is the implication of actually not >>> doing things exactly as they were but rather embracing the IPA model of the unified UID/GID >>> namespace? Is the reason that there are some applications scattered in the enterprise that >>> might have gids configured explicitly in the configuration files (like SUDO for example) and >>> updating those would be a challenge or there is something else? >>> >> >> That question is not stupid. However...:) >> >> >> Migrating group id's is possible, but quite a job. We just moved a >> few users's uid's as they had been in the enterprise for very many years, and had a dangerously >> low UID's. Searching trough the file servers for files belonging to these few users using a >> "find -exec >> chown ..." took 3 days. Migrating GID's would also take a very long time. >> >> Secondly, any files restored from backup would have the wrong >> uid/gid. Several of our clients have a rentention time of 10 years for backups. That's quite some >> time to keep a mapping table over new/old uids/gids. >> >> Third, we would need to map our applications to see if any of them >> store or use the GID. >> >> As you can see, migrating to IPA just became a much more time >> consuming and higher risk project than it could be. >> >> Is there a reason for why the approach with a private group per user >> is forcibly chosen? > > As a default it gives us the maximum compatibility with other directory > services (like AD). Plus when we did freeipa v1 we got a lot of push back when we choose a single > group (ipausers) to be the primary group due to traditional umask use for users. > > So we decided to make it a default and let admins that really do not > want it to remove the groups. I guess we could add a switch somewhere to turn off UPG groups > creation completely, if you think that is something really important you may want to open an RFE, > although I am not sure when we will have cycles to get to implement such a switch for the moment. > I see your point from a security point of view. So for new installations I agree this would be the way to go. Why can't I see the user private group listed as a group? Also I'm allowed to create a new public group with the same GID as the user's private group without a warning. I should be getting a warning and a force option? Rgds, Siggi From sigbjorn at nixtra.com Mon Apr 4 16:22:06 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 04 Apr 2011 18:22:06 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D99CB16.5040603@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> Message-ID: <4D99F02E.3050401@nixtra.com> On 04/04/2011 03:43 PM, Dmitri Pal wrote: > On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >> According to Red Hat Network it does: >> >> ipa-server-2.0.0-16.el6.x86_64 >> >> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >> ipa-server-2.0.0-16.el6.i686 >> >> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >> >> >> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >> > > It is not the final bits though. There have done several bug fixes > since then that will show up in the final 6.1 release. Ok, thanks. I'll keep that in mind. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Apr 4 17:34:10 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 04 Apr 2011 19:34:10 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D99F02E.3050401@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> Message-ID: <4D9A0112.1000102@nixtra.com> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: > On 04/04/2011 03:43 PM, Dmitri Pal wrote: >> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>> According to Red Hat Network it does: >>> >>> ipa-server-2.0.0-16.el6.x86_64 >>> >>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>> ipa-server-2.0.0-16.el6.i686 >>> >>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>> >>> >>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>> >> >> It is not the final bits though. There have done several bug fixes >> since then that will show up in the final 6.1 release. > > Ok, thanks. I'll keep that in mind. I think I might have a found a few bugs in the RHEL 6.1 beta release. Please correct me if you're already aware of these. Unless FQDN of the host is returned when running `hostname`, the IPA services will fail to start as they return "No such object" when querying the IPA LDAP for services. Shouldn't this be changed to use `hostname -f` ? ipa-replica-prepare fails with the error message below. I cannot find the plugin mentioned as a seperate RPM. # ipa-replica-prepare The 389-ds replication plug-in was not found on this system Rgds, Siggi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Apr 4 18:32:11 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Apr 2011 14:32:11 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A0112.1000102@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> Message-ID: <4D9A0EAB.7070803@redhat.com> Sigbjorn Lie wrote: > On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>> According to Red Hat Network it does: >>>> >>>> ipa-server-2.0.0-16.el6.x86_64 >>>> >>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>> ipa-server-2.0.0-16.el6.i686 >>>> >>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>> >>>> >>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>> >>> >>> It is not the final bits though. There have done several bug fixes >>> since then that will show up in the final 6.1 release. >> >> Ok, thanks. I'll keep that in mind. > > > I think I might have a found a few bugs in the RHEL 6.1 beta release. > Please correct me if you're already aware of these. > > > Unless FQDN of the host is returned when running `hostname`, the IPA > services will fail to start as they return "No such object" when > querying the IPA LDAP for services. Shouldn't this be changed to use > `hostname -f` ? AFAIK we don't call `hostname` in our script, it may be that another part of init does. We have a ticket open on this, #1035. > > > ipa-replica-prepare fails with the error message below. I cannot find > the plugin mentioned as a seperate RPM. > # ipa-replica-prepare > The 389-ds replication plug-in was not found on this system The package is named ds-replication. I'll open a ticket to make this more explicit. thanks rob From dpal at redhat.com Mon Apr 4 19:00:54 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 Apr 2011 15:00:54 -0400 Subject: [Freeipa-users] NIS/local files to IPA migration In-Reply-To: <47902.213.225.75.97.1301927656.squirrel@www.nixtra.com> References: <4D8FB6E1.1080806@nixtra.com> <4D907FBF.2090709@redhat.com> <45284.213.225.75.97.1301317295.squirrel@www.nixtra.com> <4D908C11.7080502@redhat.com> <50965.213.225.75.97.1301319798.squirrel@www.nixtra.com> <20110403225856.730b35e6@willson.li.ssimo.org> <47902.213.225.75.97.1301927656.squirrel@www.nixtra.com> Message-ID: <4D9A1566.7050906@redhat.com> On 04/04/2011 10:34 AM, Sigbjorn Lie wrote: > On Mon, April 4, 2011 04:58, Simo Sorce wrote: >> On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) >> "Sigbjorn Lie" wrote: >> >> >>> On Mon, March 28, 2011 15:24, Dmitri Pal wrote: >>> >>>> On 03/28/2011 09:01 AM, Sigbjorn Lie wrote: >>>> >>>> >>>>> On Mon, March 28, 2011 14:31, Dmitri Pal wrote: >>>>> >>>>> >>>>>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have written some scripts for migration from NIS/local files >>>>>>> to IPA. They will import the passwd, group, netgroup, and hosts maps. >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is the first version, be aware of bugs. :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please read the README file before using. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> You can download them from here if you are interested: >>>>>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php >>>>>>> >>>>>>> >>>>>>> >>>>>> Thank you for the contribution! >>>>>> I see that it is under GPL v2. Would you mind relicensing it >>>>>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html >>>>>> >>>>>> >>>>>> >>>>>> Would you be interested in these scripts being incorporated into >>>>>> the project source? Rob, can you please take a look into this? Should we consider rewriting >>>>>> them in Python and incorporating into the main tool set or leave and use as is? >>>>>> >>>>>> >>>>>> >>>>> Sure I can relicense to GPL v3. All I care about is the scripts >>>>> staying open and free to use. :) >>>>> >>>>> >>>>> You can include as a part of IPA if you would like. I was planning >>>>> to re-write them all into perl, as my initial efforts to write them in bash for maximum >>>>> portability didn't work out, and the netgroup and hosts import scripts ended up written in >>>>> perl. >>>>> >>>>> I cannot help re-writing to python, I don't know the language. >>>>> >>>>> >>>>> >>>> Ok, thank you! >>>> >>>> >>>> >>>> Can you elaborate a bit about the constraints you have regarding >>>> migration. As far as I understand you have users and groups with colliding gids and you have to >>>> resolve things manually to make things exactly as they were and IPA as is does not allow you >>>> to do so as it always creates a privite group with the same GID. >>>> >>>> I have a stupid question: what is the implication of actually not >>>> doing things exactly as they were but rather embracing the IPA model of the unified UID/GID >>>> namespace? Is the reason that there are some applications scattered in the enterprise that >>>> might have gids configured explicitly in the configuration files (like SUDO for example) and >>>> updating those would be a challenge or there is something else? >>>> >>> That question is not stupid. However...:) >>> >>> >>> Migrating group id's is possible, but quite a job. We just moved a >>> few users's uid's as they had been in the enterprise for very many years, and had a dangerously >>> low UID's. Searching trough the file servers for files belonging to these few users using a >>> "find -exec >>> chown ..." took 3 days. Migrating GID's would also take a very long time. >>> >>> Secondly, any files restored from backup would have the wrong >>> uid/gid. Several of our clients have a rentention time of 10 years for backups. That's quite some >>> time to keep a mapping table over new/old uids/gids. >>> >>> Third, we would need to map our applications to see if any of them >>> store or use the GID. >>> >>> As you can see, migrating to IPA just became a much more time >>> consuming and higher risk project than it could be. >>> >>> Is there a reason for why the approach with a private group per user >>> is forcibly chosen? >> As a default it gives us the maximum compatibility with other directory >> services (like AD). Plus when we did freeipa v1 we got a lot of push back when we choose a single >> group (ipausers) to be the primary group due to traditional umask use for users. >> >> So we decided to make it a default and let admins that really do not >> want it to remove the groups. I guess we could add a switch somewhere to turn off UPG groups >> creation completely, if you think that is something really important you may want to open an RFE, >> although I am not sure when we will have cycles to get to implement such a switch for the moment. >> > I see your point from a security point of view. So for new installations I agree this would be the > way to go. > > Why can't I see the user private group listed as a group? Because it is implied. They are filtered out unless you explicitly want to see them. We thought that by default we do not want to spam your group lists with those groups. > Also I'm allowed to create a new public > group with the same GID as the user's private group without a warning. I should be getting a > warning and a force option? Yes, if this is not the case it is a bug. Please log one then. > > Rgds, > Siggi > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Mon Apr 4 19:01:56 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 04 Apr 2011 21:01:56 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A0EAB.7070803@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> Message-ID: <4D9A15A4.4010206@nixtra.com> On 04/04/2011 08:32 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>>> According to Red Hat Network it does: >>>>> >>>>> ipa-server-2.0.0-16.el6.x86_64 >>>>> >>>>> >>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>>> ipa-server-2.0.0-16.el6.i686 >>>>> >>>>> >>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>>> >>>>> >>>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>>> >>>> >>>> It is not the final bits though. There have done several bug fixes >>>> since then that will show up in the final 6.1 release. >>> >>> Ok, thanks. I'll keep that in mind. >> >> >> I think I might have a found a few bugs in the RHEL 6.1 beta release. >> Please correct me if you're already aware of these. >> >> >> Unless FQDN of the host is returned when running `hostname`, the IPA >> services will fail to start as they return "No such object" when >> querying the IPA LDAP for services. Shouldn't this be changed to use >> `hostname -f` ? > > AFAIK we don't call `hostname` in our script, it may be that another > part of init does. We have a ticket open on this, #1035. > >> >> >> ipa-replica-prepare fails with the error message below. I cannot find >> the plugin mentioned as a seperate RPM. >> # ipa-replica-prepare >> The 389-ds replication plug-in was not found on this system > > The package is named ds-replication. I'll open a ticket to make this > more explicit. > > thanks > > rob I could not find any ds-replication package in RHN. I also noticed that in /etc/sssd/sssd.conf the ipa server is specified with: ipa_server = _srv_, ipa01.ix.test.com sssd doesn't resolve anything from IPA until I remove "_srv_," Rgds Siggi From dpal at redhat.com Mon Apr 4 19:06:07 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 04 Apr 2011 15:06:07 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A15A4.4010206@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> Message-ID: <4D9A169F.9030205@redhat.com> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: > On 04/04/2011 08:32 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >>>> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>>>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>>>> According to Red Hat Network it does: >>>>>> >>>>>> ipa-server-2.0.0-16.el6.x86_64 >>>>>> >>>>>> >>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>>>> ipa-server-2.0.0-16.el6.i686 >>>>>> >>>>>> >>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>>>> >>>>>> >>>>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>>>> >>>>> >>>>> It is not the final bits though. There have done several bug fixes >>>>> since then that will show up in the final 6.1 release. >>>> >>>> Ok, thanks. I'll keep that in mind. >>> >>> >>> I think I might have a found a few bugs in the RHEL 6.1 beta release. >>> Please correct me if you're already aware of these. >>> >>> >>> Unless FQDN of the host is returned when running `hostname`, the IPA >>> services will fail to start as they return "No such object" when >>> querying the IPA LDAP for services. Shouldn't this be changed to use >>> `hostname -f` ? >> >> AFAIK we don't call `hostname` in our script, it may be that another >> part of init does. We have a ticket open on this, #1035. >> >>> >>> >>> ipa-replica-prepare fails with the error message below. I cannot find >>> the plugin mentioned as a seperate RPM. >>> # ipa-replica-prepare >>> The 389-ds replication plug-in was not found on this system >> >> The package is named ds-replication. I'll open a ticket to make this >> more explicit. >> >> thanks >> >> rob > > I could not find any ds-replication package in RHN. We are working on making it available. > > I also noticed that in /etc/sssd/sssd.conf the ipa server is specified > with: > ipa_server = _srv_, ipa01.ix.test.com > > sssd doesn't resolve anything from IPA until I remove "_srv_," > Stephen, was there a recent bug on this matter in SSSD? > > Rgds > Siggi > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Mon Apr 4 19:29:27 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 04 Apr 2011 21:29:27 +0200 Subject: [Freeipa-users] NIS/local files to IPA migration In-Reply-To: <4D9A1566.7050906@redhat.com> References: <4D8FB6E1.1080806@nixtra.com> <4D907FBF.2090709@redhat.com> <45284.213.225.75.97.1301317295.squirrel@www.nixtra.com> <4D908C11.7080502@redhat.com> <50965.213.225.75.97.1301319798.squirrel@www.nixtra.com> <20110403225856.730b35e6@willson.li.ssimo.org> <47902.213.225.75.97.1301927656.squirrel@www.nixtra.com> <4D9A1566.7050906@redhat.com> Message-ID: <4D9A1C17.60502@nixtra.com> On 04/04/2011 09:00 PM, Dmitri Pal wrote: > On 04/04/2011 10:34 AM, Sigbjorn Lie wrote: >> On Mon, April 4, 2011 04:58, Simo Sorce wrote: >>> On Mon, 28 Mar 2011 15:43:18 +0200 (CEST) >>> "Sigbjorn Lie" wrote: >>> >>> >>>> On Mon, March 28, 2011 15:24, Dmitri Pal wrote: >>>> >>>>> On 03/28/2011 09:01 AM, Sigbjorn Lie wrote: >>>>> >>>>> >>>>>> On Mon, March 28, 2011 14:31, Dmitri Pal wrote: >>>>>> >>>>>> >>>>>>> On 03/27/2011 06:14 PM, Sigbjorn Lie wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have written some scripts for migration from NIS/local files >>>>>>>> to IPA. They will import the passwd, group, netgroup, and hosts maps. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This is the first version, be aware of bugs. :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please read the README file before using. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You can download them from here if you are interested: >>>>>>>> http://www.nixtra.com/ipa/NIS-TO-IPA-current.php >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thank you for the contribution! >>>>>>> I see that it is under GPL v2. Would you mind relicensing it >>>>>>> under GPL v3? http://www.gnu.org/licenses/gpl-3.0.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> Would you be interested in these scripts being incorporated into >>>>>>> the project source? Rob, can you please take a look into this? Should we consider rewriting >>>>>>> them in Python and incorporating into the main tool set or leave and use as is? >>>>>>> >>>>>>> >>>>>>> >>>>>> Sure I can relicense to GPL v3. All I care about is the scripts >>>>>> staying open and free to use. :) >>>>>> >>>>>> >>>>>> You can include as a part of IPA if you would like. I was planning >>>>>> to re-write them all into perl, as my initial efforts to write them in bash for maximum >>>>>> portability didn't work out, and the netgroup and hosts import scripts ended up written in >>>>>> perl. >>>>>> >>>>>> I cannot help re-writing to python, I don't know the language. >>>>>> >>>>>> >>>>>> >>>>> Ok, thank you! >>>>> >>>>> >>>>> >>>>> Can you elaborate a bit about the constraints you have regarding >>>>> migration. As far as I understand you have users and groups with colliding gids and you have to >>>>> resolve things manually to make things exactly as they were and IPA as is does not allow you >>>>> to do so as it always creates a privite group with the same GID. >>>>> >>>>> I have a stupid question: what is the implication of actually not >>>>> doing things exactly as they were but rather embracing the IPA model of the unified UID/GID >>>>> namespace? Is the reason that there are some applications scattered in the enterprise that >>>>> might have gids configured explicitly in the configuration files (like SUDO for example) and >>>>> updating those would be a challenge or there is something else? >>>>> >>>> That question is not stupid. However...:) >>>> >>>> >>>> Migrating group id's is possible, but quite a job. We just moved a >>>> few users's uid's as they had been in the enterprise for very many years, and had a dangerously >>>> low UID's. Searching trough the file servers for files belonging to these few users using a >>>> "find -exec >>>> chown ..." took 3 days. Migrating GID's would also take a very long time. >>>> >>>> Secondly, any files restored from backup would have the wrong >>>> uid/gid. Several of our clients have a rentention time of 10 years for backups. That's quite some >>>> time to keep a mapping table over new/old uids/gids. >>>> >>>> Third, we would need to map our applications to see if any of them >>>> store or use the GID. >>>> >>>> As you can see, migrating to IPA just became a much more time >>>> consuming and higher risk project than it could be. >>>> >>>> Is there a reason for why the approach with a private group per user >>>> is forcibly chosen? >>> As a default it gives us the maximum compatibility with other directory >>> services (like AD). Plus when we did freeipa v1 we got a lot of push back when we choose a single >>> group (ipausers) to be the primary group due to traditional umask use for users. >>> >>> So we decided to make it a default and let admins that really do not >>> want it to remove the groups. I guess we could add a switch somewhere to turn off UPG groups >>> creation completely, if you think that is something really important you may want to open an RFE, >>> although I am not sure when we will have cycles to get to implement such a switch for the moment. >>> >> I see your point from a security point of view. So for new installations I agree this would be the >> way to go. >> >> Why can't I see the user private group listed as a group? > Because it is implied. They are filtered out unless you explicitly want > to see them. > We thought that by default we do not want to spam your group lists with > those groups. > > >> Also I'm allowed to create a new public >> group with the same GID as the user's private group without a warning. I should be getting a >> warning and a force option? > > Yes, if this is not the case it is a bug. Please log one then. > Done. :) https://bugzilla.redhat.com/show_bug.cgi?id=693483 From sgallagh at redhat.com Mon Apr 4 19:36:44 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 15:36:44 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A169F.9030205@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> Message-ID: <4D9A1DCC.5070709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 03:06 PM, Dmitri Pal wrote: > On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >> >> I also noticed that in /etc/sssd/sssd.conf the ipa server is specified >> with: >> ipa_server = _srv_, ipa01.ix.test.com >> >> sssd doesn't resolve anything from IPA until I remove "_srv_," >> > > Stephen, was there a recent bug on this matter in SSSD? > The purpose of _srv_ is to check DNS for IPA server addresses first. The idea is that if you have more than one IPA server in service, then you can use DNS to list all of them. Otherwise, the ipa-client-install can only specify a static list of servers at the time of install. This would mean that if the IPA servers changed IP addresses or new ones entered production, it would be necessary to change all of the client configuration files. I'm puzzled why you would need to remove this, unless your DNS server is returning something other than FreeIPA servers for a SRV request directed at _ldap.tcp - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aHcsACgkQeiVVYja6o6Pj1wCdFscY1K0TAohkhClctipBSFbJ kHcAnAkeZkrRRGcalwHy/56dxA7nVQVS =nxbk -----END PGP SIGNATURE----- From sigbjorn at nixtra.com Mon Apr 4 19:52:03 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 04 Apr 2011 21:52:03 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A1DCC.5070709@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> Message-ID: <4D9A2163.5090903@nixtra.com> On 04/04/2011 09:36 PM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/04/2011 03:06 PM, Dmitri Pal wrote: >> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>> I also noticed that in /etc/sssd/sssd.conf the ipa server is specified >>> with: >>> ipa_server = _srv_, ipa01.ix.test.com >>> >>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>> >> Stephen, was there a recent bug on this matter in SSSD? >> > The purpose of _srv_ is to check DNS for IPA server addresses first. The > idea is that if you have more than one IPA server in service, then you > can use DNS to list all of them. Otherwise, the ipa-client-install can > only specify a static list of servers at the time of install. This would > mean that if the IPA servers changed IP addresses or new ones entered > production, it would be necessary to change all of the client > configuration files. > > I'm puzzled why you would need to remove this, unless your DNS server is > returning something other than FreeIPA servers for a SRV request > directed at _ldap.tcp > I have verfied that the _ldap._tcp is resolving correctly. DNS was set up using "ipa-server-install --setup-dns". I discovered this at the IPA server. This is a newly installed IPA server at RH 6.1 beta installed a few hours ago. No IP addresses changed. # host -t srv _ldap._tcp _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. Rgds, Siggi From sgallagh at redhat.com Mon Apr 4 20:12:53 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 16:12:53 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A2163.5090903@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> Message-ID: <4D9A2645.4030000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 03:52 PM, Sigbjorn Lie wrote: > On 04/04/2011 09:36 PM, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 04/04/2011 03:06 PM, Dmitri Pal wrote: >>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is specified >>>> with: >>>> ipa_server = _srv_, ipa01.ix.test.com >>>> >>>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>>> >>> Stephen, was there a recent bug on this matter in SSSD? >>> >> The purpose of _srv_ is to check DNS for IPA server addresses first. The >> idea is that if you have more than one IPA server in service, then you >> can use DNS to list all of them. Otherwise, the ipa-client-install can >> only specify a static list of servers at the time of install. This would >> mean that if the IPA servers changed IP addresses or new ones entered >> production, it would be necessary to change all of the client >> configuration files. >> >> I'm puzzled why you would need to remove this, unless your DNS server is >> returning something other than FreeIPA servers for a SRV request >> directed at _ldap.tcp >> > I have verfied that the _ldap._tcp is resolving correctly. DNS was set > up using "ipa-server-install --setup-dns". I discovered this at the IPA > server. This is a newly installed IPA server at RH 6.1 beta installed a > few hours ago. No IP addresses changed. > > > # host -t srv _ldap._tcp > _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. Is the domain part of the client machine also ix.test.com? The way we determine which SRV record to use is as follows: 1) If dns_discovery_domain exists in the config file, it is always used. 2) If not, first try the domain part of the machine's hostname (aka hostname -d) 3) If that fails, try the name of the SSSD domain (in sssd.conf [domain/] IIRC ipa-client-install should set [domain/] so if that's not the same as your DNS domain, we could be having problems. Can we see your sssd.conf please? (feel free to sanitize as needed) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aJkUACgkQeiVVYja6o6POQACgoNBjoMy6Gs5aRrlmG9F1qcAm CUUAniJBVpW/FPJA2gFKh/Zox/aSp4Qb =iNep -----END PGP SIGNATURE----- From sigbjorn at nixtra.com Mon Apr 4 20:20:55 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 04 Apr 2011 22:20:55 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A2645.4030000@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> Message-ID: <4D9A2827.2020406@nixtra.com> On 04/04/2011 10:12 PM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/04/2011 03:52 PM, Sigbjorn Lie wrote: >> On 04/04/2011 09:36 PM, Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 04/04/2011 03:06 PM, Dmitri Pal wrote: >>>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is specified >>>>> with: >>>>> ipa_server = _srv_, ipa01.ix.test.com >>>>> >>>>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>>>> >>>> Stephen, was there a recent bug on this matter in SSSD? >>>> >>> The purpose of _srv_ is to check DNS for IPA server addresses first. The >>> idea is that if you have more than one IPA server in service, then you >>> can use DNS to list all of them. Otherwise, the ipa-client-install can >>> only specify a static list of servers at the time of install. This would >>> mean that if the IPA servers changed IP addresses or new ones entered >>> production, it would be necessary to change all of the client >>> configuration files. >>> >>> I'm puzzled why you would need to remove this, unless your DNS server is >>> returning something other than FreeIPA servers for a SRV request >>> directed at _ldap.tcp >>> >> I have verfied that the _ldap._tcp is resolving correctly. DNS was set >> up using "ipa-server-install --setup-dns". I discovered this at the IPA >> server. This is a newly installed IPA server at RH 6.1 beta installed a >> few hours ago. No IP addresses changed. >> >> >> # host -t srv _ldap._tcp >> _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. > > Is the domain part of the client machine also ix.test.com? > > The way we determine which SRV record to use is as follows: > 1) If dns_discovery_domain exists in the config file, it is always used. > 2) If not, first try the domain part of the machine's hostname (aka > hostname -d) > 3) If that fails, try the name of the SSSD domain (in sssd.conf > [domain/] > > IIRC ipa-client-install should set [domain/] so if > that's not the same as your DNS domain, we could be having problems. > > Can we see your sssd.conf please? (feel free to sanitize as needed) > Please see the requested output below. This is taken from the IPA server, which had the issue. DNS servers in resolv.conf set to the IP of the IPA server. # hostname -d ix.test.com # more sssd.conf [sssd] services = nss, pam config_file_version = 2 domains = ix.test.com [nss] [pam] [domain/ix.test.com] cache_credentials = True ipa_domain = ix.test.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa #ipa_server = _srv_, ipa01.ix.test.com ipa_server = ipa01.ix.test.com [domain/default] cache_credentials = True krb5_realm = IX.TEST.COM krb5_kdcip = ipa01.ix.test.com:88 auth_provider = krb5 chpass_provider = krb5 krb5_kpasswd = ipa01.ix.test.com:749 From sgallagh at redhat.com Mon Apr 4 20:28:06 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 16:28:06 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A2827.2020406@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> <4D9A2827.2020406@nixtra.com> Message-ID: <4D9A29D6.2080003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 04:20 PM, Sigbjorn Lie wrote: > On 04/04/2011 10:12 PM, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 04/04/2011 03:52 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 09:36 PM, Stephen Gallagher wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 04/04/2011 03:06 PM, Dmitri Pal wrote: >>>>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>>>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is >>>>>> specified >>>>>> with: >>>>>> ipa_server = _srv_, ipa01.ix.test.com >>>>>> >>>>>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>>>>> >>>>> Stephen, was there a recent bug on this matter in SSSD? >>>>> >>>> The purpose of _srv_ is to check DNS for IPA server addresses first. >>>> The >>>> idea is that if you have more than one IPA server in service, then you >>>> can use DNS to list all of them. Otherwise, the ipa-client-install can >>>> only specify a static list of servers at the time of install. This >>>> would >>>> mean that if the IPA servers changed IP addresses or new ones entered >>>> production, it would be necessary to change all of the client >>>> configuration files. >>>> >>>> I'm puzzled why you would need to remove this, unless your DNS >>>> server is >>>> returning something other than FreeIPA servers for a SRV request >>>> directed at _ldap.tcp >>>> >>> I have verfied that the _ldap._tcp is resolving correctly. DNS was set >>> up using "ipa-server-install --setup-dns". I discovered this at the IPA >>> server. This is a newly installed IPA server at RH 6.1 beta installed a >>> few hours ago. No IP addresses changed. >>> >>> >>> # host -t srv _ldap._tcp >>> _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. >> >> Is the domain part of the client machine also ix.test.com? >> >> The way we determine which SRV record to use is as follows: >> 1) If dns_discovery_domain exists in the config file, it is always used. >> 2) If not, first try the domain part of the machine's hostname (aka >> hostname -d) >> 3) If that fails, try the name of the SSSD domain (in sssd.conf >> [domain/] >> >> IIRC ipa-client-install should set [domain/] so if >> that's not the same as your DNS domain, we could be having problems. >> >> Can we see your sssd.conf please? (feel free to sanitize as needed) >> > Please see the requested output below. This is taken from the IPA > server, which had the issue. DNS servers in resolv.conf set to the IP of > the IPA server. > > > # hostname -d > ix.test.com > > # more sssd.conf > [sssd] > services = nss, pam > config_file_version = 2 > > domains = ix.test.com > [nss] > > [pam] > > [domain/ix.test.com] > cache_credentials = True > ipa_domain = ix.test.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > chpass_provider = ipa > #ipa_server = _srv_, ipa01.ix.test.com > ipa_server = ipa01.ix.test.com > > [domain/default] > cache_credentials = True > krb5_realm = IX.TEST.COM > krb5_kdcip = ipa01.ix.test.com:88 > auth_provider = krb5 > chpass_provider = krb5 > krb5_kpasswd = ipa01.ix.test.com:749 > That's very strange. There should be no issue with using _srv_ in this configuration. Would you mind setting 'debug_level = 9' in [domain/ix.test.com], turning _srv_ back on, restarting SSSD, trying a request and then send me /var/log/sssd/sssd_ix.test.com.log to look at? I'd like to know why we're failing to resolve it. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aKdYACgkQeiVVYja6o6OwGQCbBW3SRhGnW3CYGL5IHU8VszHX NrwAnRRzvqLUxDrmdxDs1nOuF+eQ+Evg =Z3lV -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Apr 4 21:07:59 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 04 Apr 2011 17:07:59 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A2D7C.706@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> <4D9A2827.2020406@nixtra.com> <4D9A29D6.2080003@redhat.com> <4D9A2D7C.706@nixtra.com> Message-ID: <4D9A332F.802@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 04:43 PM, Sigbjorn Lie wrote: > On 04/04/2011 10:28 PM, Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 04/04/2011 04:20 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 10:12 PM, Stephen Gallagher wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 04/04/2011 03:52 PM, Sigbjorn Lie wrote: >>>>> On 04/04/2011 09:36 PM, Stephen Gallagher wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 04/04/2011 03:06 PM, Dmitri Pal wrote: >>>>>>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>>>>>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is >>>>>>>> specified >>>>>>>> with: >>>>>>>> ipa_server = _srv_, ipa01.ix.test.com >>>>>>>> >>>>>>>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>>>>>>> >>>>>>> Stephen, was there a recent bug on this matter in SSSD? >>>>>>> >>>>>> The purpose of _srv_ is to check DNS for IPA server addresses first. >>>>>> The >>>>>> idea is that if you have more than one IPA server in service, then >>>>>> you >>>>>> can use DNS to list all of them. Otherwise, the ipa-client-install >>>>>> can >>>>>> only specify a static list of servers at the time of install. This >>>>>> would >>>>>> mean that if the IPA servers changed IP addresses or new ones entered >>>>>> production, it would be necessary to change all of the client >>>>>> configuration files. >>>>>> >>>>>> I'm puzzled why you would need to remove this, unless your DNS >>>>>> server is >>>>>> returning something other than FreeIPA servers for a SRV request >>>>>> directed at _ldap.tcp >>>>>> >>>>> I have verfied that the _ldap._tcp is resolving correctly. DNS was set >>>>> up using "ipa-server-install --setup-dns". I discovered this at the >>>>> IPA >>>>> server. This is a newly installed IPA server at RH 6.1 beta >>>>> installed a >>>>> few hours ago. No IP addresses changed. >>>>> >>>>> >>>>> # host -t srv _ldap._tcp >>>>> _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. >>>> Is the domain part of the client machine also ix.test.com? >>>> >>>> The way we determine which SRV record to use is as follows: >>>> 1) If dns_discovery_domain exists in the config file, it is always >>>> used. >>>> 2) If not, first try the domain part of the machine's hostname (aka >>>> hostname -d) >>>> 3) If that fails, try the name of the SSSD domain (in sssd.conf >>>> [domain/] >>>> >>>> IIRC ipa-client-install should set [domain/] so if >>>> that's not the same as your DNS domain, we could be having problems. >>>> >>>> Can we see your sssd.conf please? (feel free to sanitize as needed) >>>> >>> Please see the requested output below. This is taken from the IPA >>> server, which had the issue. DNS servers in resolv.conf set to the IP of >>> the IPA server. >>> >>> >>> # hostname -d >>> ix.test.com >>> >>> # more sssd.conf >>> [sssd] >>> services = nss, pam >>> config_file_version = 2 >>> >>> domains = ix.test.com >>> [nss] >>> >>> [pam] >>> >>> [domain/ix.test.com] >>> cache_credentials = True >>> ipa_domain = ix.test.com >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> chpass_provider = ipa >>> #ipa_server = _srv_, ipa01.ix.test.com >>> ipa_server = ipa01.ix.test.com >>> >>> [domain/default] >>> cache_credentials = True >>> krb5_realm = IX.TEST.COM >>> krb5_kdcip = ipa01.ix.test.com:88 >>> auth_provider = krb5 >>> chpass_provider = krb5 >>> krb5_kpasswd = ipa01.ix.test.com:749 >>> >> That's very strange. There should be no issue with using _srv_ in this >> configuration. Would you mind setting 'debug_level = 9' in >> [domain/ix.test.com], turning _srv_ back on, restarting SSSD, trying a >> request and then send me /var/log/sssd/sssd_ix.test.com.log to look at? >> I'd like to know why we're failing to resolve it. >> > Sure, see the attached file. I'm sending private, unscrambeled. > > For some reason it started working now, sluggish, but working. Takes > 0.488s to look up a new user account using "# id username" > > The log file is too much to read for me just now, it's getting late. :) Can you show me the output from 'dig' instead of SRV? The logs you sent seem to be telling me that the TTL is set to something extremely short, because we're marking it as expired pretty much instantly. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aMy8ACgkQeiVVYja6o6PNoACfayD4eb68HdfpEAuSoI4XTn5X sWgAnjnFg0LaHvRiQ/gHsK07qHFr2NRL =6mby -----END PGP SIGNATURE----- From kevinu at redhat.com Mon Apr 4 23:25:12 2011 From: kevinu at redhat.com (Kevin Unthank) Date: Mon, 04 Apr 2011 16:25:12 -0700 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A169F.9030205@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> Message-ID: <4D9A5358.50208@redhat.com> On 04/04/2011 12:06 PM, Dmitri Pal wrote: > On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >> On 04/04/2011 08:32 PM, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>>> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >>>>> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>>>>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>>>>> According to Red Hat Network it does: >>>>>>> >>>>>>> ipa-server-2.0.0-16.el6.x86_64 >>>>>>> >>>>>>> >>>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>>>>> ipa-server-2.0.0-16.el6.i686 >>>>>>> >>>>>>> >>>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>>>>> >>>>>>> >>>>>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>>>>> >>>>>> >>>>>> It is not the final bits though. There have done several bug fixes >>>>>> since then that will show up in the final 6.1 release. >>>>> >>>>> Ok, thanks. I'll keep that in mind. >>>> >>>> >>>> I think I might have a found a few bugs in the RHEL 6.1 beta release. >>>> Please correct me if you're already aware of these. >>>> >>>> >>>> Unless FQDN of the host is returned when running `hostname`, the IPA >>>> services will fail to start as they return "No such object" when >>>> querying the IPA LDAP for services. Shouldn't this be changed to use >>>> `hostname -f` ? >>> >>> AFAIK we don't call `hostname` in our script, it may be that another >>> part of init does. We have a ticket open on this, #1035. >>> >>>> >>>> >>>> ipa-replica-prepare fails with the error message below. I cannot find >>>> the plugin mentioned as a seperate RPM. >>>> # ipa-replica-prepare >>>> The 389-ds replication plug-in was not found on this system >>> >>> The package is named ds-replication. I'll open a ticket to make this >>> more explicit. >>> >>> thanks >>> >>> rob >> >> I could not find any ds-replication package in RHN. > > We are working on making it available. Just to elaborate on Dmitri's comments. In addition to the IPA client and server packages that are included in the RHEL6.1 beta channel, there will be a separate RHEL add-on channel, Enterprise Identity Replication. That add-on channel will contain ds-replication and the Windows sync packages. If you wish to use IPA during the beta or when it is a tech preview feature of RHEL 6.1 you should request an eval entitlement to the Enterprise Identity Replication channel from your Red Hat account rep. Cheers, Kev From davido at redhat.com Tue Apr 5 02:26:24 2011 From: davido at redhat.com (David O'Brien) Date: Tue, 05 Apr 2011 12:26:24 +1000 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A0EAB.7070803@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> Message-ID: <4D9A7DD0.9030208@redhat.com> Rob Crittenden wrote: > Sigbjorn Lie wrote: >> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>>> According to Red Hat Network it does: >>>>> >>>>> ipa-server-2.0.0-16.el6.x86_64 >>>>> >>>>> >>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>>> ipa-server-2.0.0-16.el6.i686 >>>>> >>>>> >>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>>> >>>>> >>>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>>> >>>> >>>> It is not the final bits though. There have done several bug fixes >>>> since then that will show up in the final 6.1 release. >>> >>> Ok, thanks. I'll keep that in mind. >> >> >> I think I might have a found a few bugs in the RHEL 6.1 beta release. >> Please correct me if you're already aware of these. >> >> >> Unless FQDN of the host is returned when running `hostname`, the IPA >> services will fail to start as they return "No such object" when >> querying the IPA LDAP for services. Shouldn't this be changed to use >> `hostname -f` ? > > AFAIK we don't call `hostname` in our script, it may be that another > part of init does. We have a ticket open on this, #1035. > >> >> >> ipa-replica-prepare fails with the error message below. I cannot find >> the plugin mentioned as a seperate RPM. >> # ipa-replica-prepare >> The 389-ds replication plug-in was not found on this system > > The package is named ds-replication. I'll open a ticket to make this > more explicit. > This requirement is mentioned in the revised doc, due to be published very soon (next few days). Under "Software Requirements", it states that "If you are going to use replication, install the ds-replication package, available from the Enterprise Identity Replication channel" Apologies that it missed the initial cut. See also Kevin Unthank's reply about requesting an eval entitlement. David > thanks > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- David O'Brien Senior Content Author Engineering Content Services (ECS) Red Hat Asia Pacific Pty Ltd +61 7 3514 8189 "We couldn't care less about comfort. We make you feel good." ~ Federico Minoli CEO Ducati Motor S.p.A. From sigbjorn at nixtra.com Tue Apr 5 04:45:09 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 05 Apr 2011 06:45:09 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A5358.50208@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> Message-ID: <4D9A9E55.8090006@nixtra.com> On 04/05/2011 01:25 AM, Kevin Unthank wrote: > > > On 04/04/2011 12:06 PM, Dmitri Pal wrote: >> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 08:32 PM, Rob Crittenden wrote: >>>> Sigbjorn Lie wrote: >>>>> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >>>>>> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>>>>>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>>>>>> According to Red Hat Network it does: >>>>>>>> >>>>>>>> ipa-server-2.0.0-16.el6.x86_64 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>>>>>> ipa-server-2.0.0-16.el6.i686 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>>>>>> >>>>>>>> >>>>>>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>>>>>> >>>>>>> >>>>>>> It is not the final bits though. There have done several bug fixes >>>>>>> since then that will show up in the final 6.1 release. >>>>>> >>>>>> Ok, thanks. I'll keep that in mind. >>>>> >>>>> >>>>> I think I might have a found a few bugs in the RHEL 6.1 beta release. >>>>> Please correct me if you're already aware of these. >>>>> >>>>> >>>>> Unless FQDN of the host is returned when running `hostname`, the IPA >>>>> services will fail to start as they return "No such object" when >>>>> querying the IPA LDAP for services. Shouldn't this be changed to use >>>>> `hostname -f` ? >>>> >>>> AFAIK we don't call `hostname` in our script, it may be that another >>>> part of init does. We have a ticket open on this, #1035. >>>> >>>>> >>>>> >>>>> ipa-replica-prepare fails with the error message below. I cannot find >>>>> the plugin mentioned as a seperate RPM. >>>>> # ipa-replica-prepare >>>>> The 389-ds replication plug-in was not found on this system >>>> >>>> The package is named ds-replication. I'll open a ticket to make this >>>> more explicit. >>>> >>>> thanks >>>> >>>> rob >>> >>> I could not find any ds-replication package in RHN. >> >> We are working on making it available. > > Just to elaborate on Dmitri's comments. In addition to the IPA client > and server packages that are included in the RHEL6.1 beta channel, there > will be a separate RHEL add-on channel, Enterprise Identity Replication. > That add-on channel will contain ds-replication and the Windows sync > packages. > > If you wish to use IPA during the beta or when it is a tech preview > feature of RHEL 6.1 you should request an eval entitlement to the > Enterprise Identity Replication channel from your Red Hat account > rep. > > Cheers, > Kev I will request the channel to be added to our account. Thanks. Rgds, Siggi From tomasz.napierala at allegro.pl Tue Apr 5 09:28:53 2011 From: tomasz.napierala at allegro.pl (tomasz.napierala at allegro.pl) Date: Tue, 5 Apr 2011 11:28:53 +0200 Subject: [Freeipa-users] RC3 Install fails with " Unable to connect to LDAP server " In-Reply-To: <4D7E092D.70001@redhat.com> References: <4D7CF2A2.9060205@nixtra.com> <9FD291BB-880A-4B8B-87CB-999D6C11EC3C@allegro.pl> <4D7E092D.70001@redhat.com> Message-ID: <6D370E84-FD03-4964-A56D-63DDBF91E40A@allegro.pl> On 2011-03-14, at 13:25, Dmitri Pal wrote: > On 03/14/2011 04:57 AM, tomasz.napierala at allegro.pl wrote: >> On 2011-03-13, at 17:36, Sigbjorn Lie wrote: >> >>> On 03/12/2011 09:58 PM, tomasz.napierala at allegro.pl wrote: >>>> On 2011-03-12, at 20:06, tomasz.napierala at allegro.pl wrote: >>>> >>>>> Hi, >>>>> I'm trying to install FreeIPA 2.0. RC3 on fresh, minimal F14 box, but it fails for some reason: >>>> Looks like the problem is that my realm is different than domain name (QXLTEST vs. DC2). After accepting defaults installation was completed succesfully. Can anybody confirm? >>>> >>>> Regards, >>> Hi, >>> >>> I reinstalled and found the same to be the problem for me. >> Filled bug 684690 >> >> Regards, > Thanks! One quick question: is there a package with this bug fixed available for Fedora 15? Seems to be fixed in RHEL , but I'm not sure if it's fixed in freeipa-server.2.0.0.1.fc15 Regards, -- Tomasz Z. Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ Grupa Allegro Sp. z o.o. z siedzib? w Poznaniu, 60-324 Pozna?, przy ul. Marceli?skiej 90, wpisana do rejestru przedsi?biorc?w prowadzonego przez S?d Rejonowy Pozna? - Nowe Miasto i Wilda, Wydzia? VIII Gospodarczy Krajowego Rejestru S?dowego pod numerem KRS 0000268796, o kapitale zak?adowym w wysoko?ci 33 474 500 z?, posiadaj?ca numer identyfikacji podatkowej NIP: 5272525995. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4565 bytes Desc: not available URL: From sgallagh at redhat.com Tue Apr 5 11:56:18 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 05 Apr 2011 07:56:18 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A354E.6030200@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> <4D9A2827.2020406@nixtra.com> <4D9A29D6.2080003@redhat.com> <4D9A2D7C.706@nixtra.com> <4D9A31F6.8080708@redhat.com> <4D9A354E.6030200@nixtra.com> Message-ID: <4D9B0362.2040908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2011 05:17 PM, Sigbjorn Lie wrote: > The first dig is taken on the ipa server, using it's own IPA configured > test DNS. However I have a F14 client successfully connected using my > prod DNS (my DHCP default). Prod DNS is serving the same _ldap._tcp > records for the same IPA server. My prod dns is serving TTL 1 second for > the same records. > > I presume what happened was that I started the SSSD on the IPA server > while it was still being served by the PROD dns. Then I changed the > nameserver entries after. > > What gets to me is that I've used the prod DNS setup for testing with > F14 for months now, without any issue. This first became an issue when I > reinstalled the IPA server with RHEL 6.1 beta. > > Was that really it? Too low TTL on the DNS entries? > If I remember correctly, the change that added _srv_ by default to sssd.conf went in during one of the later release candidates for FreeIPA. So it's likely that for most of your time testing it, you only had the explicit server address in the config file. I do encourage you to keep the _srv_ entry, as it really does make life a lot easier later on (if you want to add a replica or move the FreeIPA server) since you only have to update DNS instead of every client. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bA1sACgkQeiVVYja6o6NYZgCfcA514qCLAJbM4LtK07CPtQpX ahcAoIbO/X0+LuQYPz9emtOajlwej+1B =0uQY -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Apr 5 12:20:11 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 05 Apr 2011 08:20:11 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <50377.213.225.75.97.1302005799.squirrel@www.nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> <4D9A2827.2020406@nixtra.com> <4D9A29D6.2080003@redhat.com> <4D9A2D7C.706@nixtra.com> <4D9A31F6.8080708@redhat.com> <4D9A354E.6030200@nixtra.com> <4D9B0362.2040908@redhat.com> <50377.213.225.75.97.1302005799.squirrel@www.nixtra.com> Message-ID: <4D9B08FB.7080106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2011 08:16 AM, Sigbjorn Lie wrote: >> >> On 04/04/2011 05:17 PM, Sigbjorn Lie wrote: >> >>> The first dig is taken on the ipa server, using it's own IPA configured >>> test DNS. However I have a F14 client successfully connected using my prod DNS (my DHCP default). >>> Prod DNS is serving the same _ldap._tcp >>> records for the same IPA server. My prod dns is serving TTL 1 second for the same records. >>> >>> I presume what happened was that I started the SSSD on the IPA server >>> while it was still being served by the PROD dns. Then I changed the nameserver entries after. >>> >>> What gets to me is that I've used the prod DNS setup for testing with >>> F14 for months now, without any issue. This first became an issue when I >>> reinstalled the IPA server with RHEL 6.1 beta. >>> >>> Was that really it? Too low TTL on the DNS entries? >>> >>> >> >> >> If I remember correctly, the change that added _srv_ by default to >> sssd.conf went in during one of the later release candidates for FreeIPA. So it's likely that for >> most of your time testing it, you only had the explicit server address in the config file. >> >> I do encourage you to keep the _srv_ entry, as it really does make life >> a lot easier later on (if you want to add a replica or move the FreeIPA server) since you only have >> to update DNS instead of every client. >> > > I see your point. I'll increase the TTL of my production zone and see what happends then. What do > you think of having only the _srv_ entry, no named hosts at all in sssd.conf ? The reason the install script sets one named host is just to be extra cautious. If DNS is not resolving for some reason (BIND crashed, or someone accidentally blocked port 53, etc.) then SSSD will still attempt to reach the named host before giving up and going offline. It's not strictly necessary, but neither should it ever be harmful. Obviously if DNS is resolving correctly at all times the named host will never be used. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bCPsACgkQeiVVYja6o6O0ogCghoLoQ7d8NajVD3p7bgfgfIxH RDAAoJx6JXaijE7etQF2faP4g3xm6fC6 =bej9 -----END PGP SIGNATURE----- From dpal at redhat.com Tue Apr 5 13:06:42 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 05 Apr 2011 09:06:42 -0400 Subject: [Freeipa-users] RC3 Install fails with " Unable to connect to LDAP server " In-Reply-To: <6D370E84-FD03-4964-A56D-63DDBF91E40A@allegro.pl> References: <4D7CF2A2.9060205@nixtra.com> <9FD291BB-880A-4B8B-87CB-999D6C11EC3C@allegro.pl> <4D7E092D.70001@redhat.com> <6D370E84-FD03-4964-A56D-63DDBF91E40A@allegro.pl> Message-ID: <4D9B13E2.5050108@redhat.com> On 04/05/2011 05:28 AM, tomasz.napierala at allegro.pl wrote: > On 2011-03-14, at 13:25, Dmitri Pal wrote: > >> On 03/14/2011 04:57 AM, tomasz.napierala at allegro.pl wrote: >>> On 2011-03-13, at 17:36, Sigbjorn Lie wrote: >>> >>>> On 03/12/2011 09:58 PM, tomasz.napierala at allegro.pl wrote: >>>>> On 2011-03-12, at 20:06, tomasz.napierala at allegro.pl wrote: >>>>> >>>>>> Hi, >>>>>> I'm trying to install FreeIPA 2.0. RC3 on fresh, minimal F14 box, but it fails for some reason: >>>>> Looks like the problem is that my realm is different than domain name (QXLTEST vs. DC2). After accepting defaults installation was completed succesfully. Can anybody confirm? >>>>> >>>>> Regards, >>>> Hi, >>>> >>>> I reinstalled and found the same to be the problem for me. >>> Filled bug 684690 >>> >>> Regards, >> Thanks! > > One quick question: is there a package with this bug fixed available for Fedora 15? Seems to be fixed in RHEL , but I'm not sure if it's fixed in freeipa-server.2.0.0.1.fc15 > Should be in the GA bits. > Regards, > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Tue Apr 5 14:00:50 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 05 Apr 2011 10:00:50 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <50450.213.225.75.97.1302011662.squirrel@www.nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A1DCC.5070709@redhat.com> <4D9A2163.5090903@nixtra.com> <4D9A2645.4030000@redhat.com> <4D9A2827.2020406@nixtra.com> <4D9A29D6.2080003@redhat.com> <4D9A2D7C.706@nixtra.com> <4D9A31F6.8080708@redhat.com> <4D9A354E.6030200@nixtra.com> <4D9B0362.2040908@redhat.com> <50377.213.225.75.97.1302005799.squirrel@www.nixtra.com> <4D9B08FB.7080106@redhat.com> <50450.213.225.75.97.1302011662.squirrel@www.nixtra.com> Message-ID: <4D9B2092.6050806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2011 09:54 AM, Sigbjorn Lie wrote: >> >> On 04/05/2011 08:16 AM, Sigbjorn Lie wrote: >> >>>> >>>> On 04/04/2011 05:17 PM, Sigbjorn Lie wrote: >>>> >>>> >>>>> The first dig is taken on the ipa server, using it's own IPA configured >>>>> test DNS. However I have a F14 client successfully connected using my prod DNS (my DHCP >>>>> default). Prod DNS is serving the same _ldap._tcp >>>>> records for the same IPA server. My prod dns is serving TTL 1 second for the same records. >>>>> >>>>> I presume what happened was that I started the SSSD on the IPA server >>>>> while it was still being served by the PROD dns. Then I changed the nameserver entries >>>>> after. >>>>> >>>>> What gets to me is that I've used the prod DNS setup for testing with >>>>> F14 for months now, without any issue. This first became an issue when I >>>>> reinstalled the IPA server with RHEL 6.1 beta. >>>>> >>>>> Was that really it? Too low TTL on the DNS entries? >>>>> >>>>> >>>>> >>>> >>>> >>>> If I remember correctly, the change that added _srv_ by default to >>>> sssd.conf went in during one of the later release candidates for FreeIPA. So it's likely that >>>> for most of your time testing it, you only had the explicit server address in the config file. >>>> >>>> >>>> I do encourage you to keep the _srv_ entry, as it really does make life >>>> a lot easier later on (if you want to add a replica or move the FreeIPA server) since you only >>>> have to update DNS instead of every client. >>>> >>> >>> I see your point. I'll increase the TTL of my production zone and see what happends then. What >>> do you think of having only the _srv_ entry, no named hosts at all in sssd.conf ? >> >> >> The reason the install script sets one named host is just to be extra >> cautious. If DNS is not resolving for some reason (BIND crashed, or someone accidentally blocked >> port 53, etc.) then SSSD will still attempt to reach the named host before giving up and going >> offline. >> >> It's not strictly necessary, but neither should it ever be harmful. >> Obviously if DNS is resolving correctly at all times the named host will >> never be used. >> > > > Ok. I see. > > Why is the _srv_ records not used in the domain/default as well? And what exactly is the > difference between domain/ix.nixtra.com and domain/default? [domain/default] is not in use. It's put there by authconfig (which we use to bootstrap the SSSD setup process) but we disable that domain. Only domains listed in the domains = , , ... line of the [sssd] section are active. We leave it in there to be a good citizen (in case it actually was configured previously). That way we don't wipe out any settings that the user may have had in it. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2bIJIACgkQeiVVYja6o6NR6ACdFp0PHQ3vz4G+KC850mn2+fL2 QaUAnA6W3hfNokCtOqlwTpriZfN/yK1n =kDvn -----END PGP SIGNATURE----- From sigbjorn at nixtra.com Thu Apr 7 20:35:15 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 07 Apr 2011 22:35:15 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9A5358.50208@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> Message-ID: <4D9E2003.9030401@nixtra.com> On 04/05/2011 01:25 AM, Kevin Unthank wrote: > > > On 04/04/2011 12:06 PM, Dmitri Pal wrote: >> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 08:32 PM, Rob Crittenden wrote: >>>> Sigbjorn Lie wrote: >>>>> On 04/04/2011 06:22 PM, Sigbjorn Lie wrote: >>>>>> On 04/04/2011 03:43 PM, Dmitri Pal wrote: >>>>>>> On 04/03/2011 05:41 PM, Sigbjorn Lie wrote: >>>>>>>> According to Red Hat Network it does: >>>>>>>> >>>>>>>> ipa-server-2.0.0-16.el6.x86_64 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 64-bit x86_64) >>>>>>>> ipa-server-2.0.0-16.el6.i686 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Red Hat Enterprise Linux Server Beta (v. 6 for 32-bit x86) >>>>>>>> >>>>>>>> >>>>>>>> Thanks for pointing this out, I'm installing RHEL 6.1 beta now. :) >>>>>>>> >>>>>>> >>>>>>> It is not the final bits though. There have done several bug fixes >>>>>>> since then that will show up in the final 6.1 release. >>>>>> >>>>>> Ok, thanks. I'll keep that in mind. >>>>> >>>>> >>>>> I think I might have a found a few bugs in the RHEL 6.1 beta release. >>>>> Please correct me if you're already aware of these. >>>>> >>>>> >>>>> Unless FQDN of the host is returned when running `hostname`, the IPA >>>>> services will fail to start as they return "No such object" when >>>>> querying the IPA LDAP for services. Shouldn't this be changed to use >>>>> `hostname -f` ? >>>> >>>> AFAIK we don't call `hostname` in our script, it may be that another >>>> part of init does. We have a ticket open on this, #1035. >>>> >>>>> >>>>> >>>>> ipa-replica-prepare fails with the error message below. I cannot find >>>>> the plugin mentioned as a seperate RPM. >>>>> # ipa-replica-prepare >>>>> The 389-ds replication plug-in was not found on this system >>>> >>>> The package is named ds-replication. I'll open a ticket to make this >>>> more explicit. >>>> >>>> thanks >>>> >>>> rob >>> >>> I could not find any ds-replication package in RHN. >> >> We are working on making it available. > > Just to elaborate on Dmitri's comments. In addition to the IPA client > and server packages that are included in the RHEL6.1 beta channel, there > will be a separate RHEL add-on channel, Enterprise Identity Replication. > That add-on channel will contain ds-replication and the Windows sync > packages. > > If you wish to use IPA during the beta or when it is a tech preview > feature of RHEL 6.1 you should request an eval entitlement to the > Enterprise Identity Replication channel from your Red Hat account > rep. > > Cheers, > Kev Hi Kevin, I have requested the replication channel as you recommended from our account manager. I am curious to why such an important feature as replication is put in it's own channel. I see IPA is trying to compete with Active Directory to service Unix/Linux machines, however with Active Directory all features is included in the base package of the operating system. Why does Red Hat put the replication feature of IPA into a seperate channel from the operating system? Rgds, Siggi From Steven.Jones at vuw.ac.nz Thu Apr 7 21:32:26 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 7 Apr 2011 21:32:26 +0000 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9E2003.9030401@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com>,<4D9E2003.9030401@nixtra.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E400729CF@STAWINCOX10MBX3.staff.vuw.ac.nz> 8><----- > Just to elaborate on Dmitri's comments. In addition to the IPA client > and server packages that are included in the RHEL6.1 beta channel, there > will be a separate RHEL add-on channel, Enterprise Identity Replication. > That add-on channel will contain ds-replication and the Windows sync > packages. > > If you wish to use IPA during the beta or when it is a tech preview > feature of RHEL 6.1 you should request an eval entitlement to the > Enterprise Identity Replication channel from your Red Hat account > rep. > > Cheers, > Kev Hi Kevin, I have requested the replication channel as you recommended from our account manager. I am curious to why such an important feature as replication is put in it's own channel. I see IPA is trying to compete with Active Directory to service Unix/Linux machines, however with Active Directory all features is included in the base package of the operating system. Why does Red Hat put the replication feature of IPA into a seperate channel from the operating system? Rgds, Siggi ========== Silly question.....they want to make money and lock out the "easy" possibility of you not paying them. There is a very good reason RedHat is nick named the Microsoft of the Linux world......but they are all pretty much the same. You have to go into this with open eyes......this project isnt a real open source project with real open source ppl from all walks of life.....its a Red Hat project....that they let you see into on their terms, Sun and oracle for instance have done the same thing.....their projects splutter along with little OSS community support. Example, so if you went to say mailman (like I do) that's a real open source product and I can get first class support via that....I would think that this will never be a place for open source support for IPA it will be "please go to red hat and pay if you want help". I dont know Ive even seen a single contributor who doesnt have a @redhat.com address, that set off warning lights for me......probably why the FDS project still has so many contributors and users.... I hadnt noticed this wrinkle as I'm busy building a total virtual copy of prod to run a huge proof of concept / pre-prod setup which will take me another week at least....given we dont have much money and its going to take me more than 6months to do, paying $ isnt practical/possible and we dont know the cost when 6.2 comes out. So I suspect that if you dont want or cant afford a support contract bailing to CENTOS 6.1 or using CENTOS rpms to finish the glue (on RHEL) will be the way to go. Given we will be using shibboleth and everyone around us with shibboleth is on CENTOS its probably where we will go..... Its not all bad, bear in mind of course an Identity / LDAP product off anyone else eg Oracle will cost you mega bucks to buy (think numbers ending in 5 0's), is bloody awful (2 of us spent 6 weeks trying to make its virtual front end LDAP server even start let alone do anything of use and I failed).....and costly to look after (think 1 FTE and a highly paid one to boot).....I really wonder if the business case stacks up at all.... regards _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Thu Apr 7 22:21:59 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 07 Apr 2011 18:21:59 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <833D8E48405E064EBC54C84EC6B36E400729CF@STAWINCOX10MBX3.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com>, <4D9E2003.9030401@nixtra.com> <833D8E48405E064EBC54C84EC6B36E400729CF@STAWINCOX10MBX3.staff.vuw.ac.nz> Message-ID: <4D9E3907.9050007@redhat.com> On 04/07/2011 05:32 PM, Steven Jones wrote: > 8><----- > > >> Just to elaborate on Dmitri's comments. In addition to the IPA client >> and server packages that are included in the RHEL6.1 beta channel, there >> will be a separate RHEL add-on channel, Enterprise Identity Replication. >> That add-on channel will contain ds-replication and the Windows sync >> packages. >> >> If you wish to use IPA during the beta or when it is a tech preview >> feature of RHEL 6.1 you should request an eval entitlement to the >> Enterprise Identity Replication channel from your Red Hat account >> rep. >> >> Cheers, >> Kev > Hi Kevin, > > I have requested the replication channel as you recommended from our > account manager. > > I am curious to why such an important feature as replication is put in > it's own channel. I see IPA is trying to compete with Active Directory > to service Unix/Linux machines, however with Active Directory all > features is included in the base package of the operating system. > > Why does Red Hat put the replication feature of IPA into a seperate > channel from the operating system? > > > Rgds, > Siggi > > ========== > > Silly question.....they want to make money and lock out the "easy" possibility of you not paying them. > > There is a very good reason RedHat is nick named the Microsoft of the Linux world......but they are all pretty much the same. > > You have to go into this with open eyes......this project isnt a real open source project with real open source ppl from all walks of life.....its a Red Hat project....that they let you see into on their terms, Sun and oracle for instance have done the same thing.....their projects splutter along with little OSS community support. > > Example, so if you went to say mailman (like I do) that's a real open source product and I can get first class support via that....I would think that this will never be a place for open source support for IPA it will be "please go to red hat and pay if you want help". > > I dont know Ive even seen a single contributor who doesnt have a @redhat.com address, that set off warning lights for me......probably why the FDS project still has so many contributors and users.... > > I hadnt noticed this wrinkle as I'm busy building a total virtual copy of prod to run a huge proof of concept / pre-prod setup which will take me another week at least....given we dont have much money and its going to take me more than 6months to do, paying $ isnt practical/possible and we dont know the cost when 6.2 comes out. So I suspect that if you dont want or cant afford a support contract bailing to CENTOS 6.1 or using CENTOS rpms to finish the glue (on RHEL) will be the way to go. Given we will be using shibboleth and everyone around us with shibboleth is on CENTOS its probably where we will go..... > > Its not all bad, bear in mind of course an Identity / LDAP product off anyone else eg Oracle will cost you mega bucks to buy (think numbers ending in 5 0's), is bloody awful (2 of us spent 6 weeks trying to make its virtual front end LDAP server even start let alone do anything of use and I failed).....and costly to look after (think 1 FTE and a highly paid one to boot).....I really wonder if the business case stacks up at all.... > > regards > > Hello Siggi, Hello Steven It is true that we are human and we sometimes need to eat (just sometimes...). It is true that the project was sponsored by Red Hat and most of the contributors are from Red Hat. It is not rue that all of them are. There are other contributors. Not many but there are. And we hope that there will be more over time. All the bits are available in Fedora at no cost and we do our best to support Fedora community since we treasure anyone who provides any feedback (better negative as we can learn from it). We are going to continue keeping lights on this project so that people who value the Red Hat platform for its stability can enjoy the reasonably priced IDM solution but it does not prevent other distributions from enjoying the fruits of our work. The same team of engineers works on SSSD. SSSD has been adopted by SUSE, Debian & Ubuntu and has several active non Red Hat contributors. This did not happen over time but it did. And the main reason is that we are ready to work with anyone who cares. I hope that this clarifies things a bit. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Thu Apr 7 22:45:14 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 7 Apr 2011 22:45:14 +0000 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9E3907.9050007@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com>, <4D9E2003.9030401@nixtra.com> <833D8E48405E064EBC54C84EC6B36E400729CF@STAWINCOX10MBX3.staff.vuw.ac.nz>, <4D9E3907.9050007@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40073202@STAWINCOX10MBX3.staff.vuw.ac.nz> Hi, I think I get a bit peeved when I go on a RH course and the trainer spends too much time telling us about the licencing changes for rhel6 and all the hoops and caveats we have to now consider....this is propriety territory....where licencing becomes a costly and a time consuming headache. Yes, everyone has to eat....so moderately priced, hopefully it will be no worse than RDS but when Im sitting in front of managers convincing them to buy an "Open Source" product I kind of feel I'm selling my soul, its not why I took up Linux 12 years ago. I think the guy who wrote the Linux network stack summed it up well several years ago when asked why he hadn't charged for his work, his answer was (paraphrase) I write a network stack and in return I get a complete OS in return for my work, why isnt that a great deal? NB Actually for OS licencing we run twice if not three times the Microsoft servers on our site as Linux...it costs us less to run MS than RH in annual fees I find that really weird. regards Steven ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Friday, 8 April 2011 10:21 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] 6.1 beta On 04/07/2011 05:32 PM, Steven Jones wrote: > 8><----- > > >> Just to elaborate on Dmitri's comments. In addition to the IPA client >> and server packages that are included in the RHEL6.1 beta channel, there >> will be a separate RHEL add-on channel, Enterprise Identity Replication. >> That add-on channel will contain ds-replication and the Windows sync >> packages. >> >> If you wish to use IPA during the beta or when it is a tech preview >> feature of RHEL 6.1 you should request an eval entitlement to the >> Enterprise Identity Replication channel from your Red Hat account >> rep. >> >> Cheers, >> Kev > Hi Kevin, > > I have requested the replication channel as you recommended from our > account manager. > > I am curious to why such an important feature as replication is put in > it's own channel. I see IPA is trying to compete with Active Directory > to service Unix/Linux machines, however with Active Directory all > features is included in the base package of the operating system. > > Why does Red Hat put the replication feature of IPA into a seperate > channel from the operating system? > > > Rgds, > Siggi > > ========== > > Silly question.....they want to make money and lock out the "easy" possibility of you not paying them. > > There is a very good reason RedHat is nick named the Microsoft of the Linux world......but they are all pretty much the same. > > You have to go into this with open eyes......this project isnt a real open source project with real open source ppl from all walks of life.....its a Red Hat project....that they let you see into on their terms, Sun and oracle for instance have done the same thing.....their projects splutter along with little OSS community support. > > Example, so if you went to say mailman (like I do) that's a real open source product and I can get first class support via that....I would think that this will never be a place for open source support for IPA it will be "please go to red hat and pay if you want help". > > I dont know Ive even seen a single contributor who doesnt have a @redhat.com address, that set off warning lights for me......probably why the FDS project still has so many contributors and users.... > > I hadnt noticed this wrinkle as I'm busy building a total virtual copy of prod to run a huge proof of concept / pre-prod setup which will take me another week at least....given we dont have much money and its going to take me more than 6months to do, paying $ isnt practical/possible and we dont know the cost when 6.2 comes out. So I suspect that if you dont want or cant afford a support contract bailing to CENTOS 6.1 or using CENTOS rpms to finish the glue (on RHEL) will be the way to go. Given we will be using shibboleth and everyone around us with shibboleth is on CENTOS its probably where we will go..... > > Its not all bad, bear in mind of course an Identity / LDAP product off anyone else eg Oracle will cost you mega bucks to buy (think numbers ending in 5 0's), is bloody awful (2 of us spent 6 weeks trying to make its virtual front end LDAP server even start let alone do anything of use and I failed).....and costly to look after (think 1 FTE and a highly paid one to boot).....I really wonder if the business case stacks up at all.... > > regards > > Hello Siggi, Hello Steven It is true that we are human and we sometimes need to eat (just sometimes...). It is true that the project was sponsored by Red Hat and most of the contributors are from Red Hat. It is not rue that all of them are. There are other contributors. Not many but there are. And we hope that there will be more over time. All the bits are available in Fedora at no cost and we do our best to support Fedora community since we treasure anyone who provides any feedback (better negative as we can learn from it). We are going to continue keeping lights on this project so that people who value the Red Hat platform for its stability can enjoy the reasonably priced IDM solution but it does not prevent other distributions from enjoying the fruits of our work. The same team of engineers works on SSSD. SSSD has been adopted by SUSE, Debian & Ubuntu and has several active non Red Hat contributors. This did not happen over time but it did. And the main reason is that we are ready to work with anyone who cares. I hope that this clarifies things a bit. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From kevinu at redhat.com Thu Apr 7 23:03:22 2011 From: kevinu at redhat.com (Kevin Unthank) Date: Thu, 07 Apr 2011 16:03:22 -0700 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9E2003.9030401@nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> Message-ID: <4D9E42BA.2080505@redhat.com> >> Just to elaborate on Dmitri's comments. In addition to the IPA client >> and server packages that are included in the RHEL6.1 beta channel, there >> will be a separate RHEL add-on channel, Enterprise Identity Replication. >> That add-on channel will contain ds-replication and the Windows sync >> packages. >> >> If you wish to use IPA during the beta or when it is a tech preview >> feature of RHEL 6.1 you should request an eval entitlement to the >> Enterprise Identity Replication channel from your Red Hat account >> rep. >> >> Cheers, >> Kev > Hi Kevin, > > I have requested the replication channel as you recommended from our account manager. > > I am curious to why such an important feature as replication is put in it's own channel. I see IPA is trying to compete with Active Directory to service Unix/Linux machines, however with Active Directory all features is included in the base package of the operating system. > > Why does Red Hat put the replication feature of IPA into a seperate channel from the operating system? > > > Rgds, > Siggi Hi Siggi, With RHEL6 we are striving to have more flexibility with packaging and features. From the website: http://www.redhat.com/rhel/add-ons/ "Add-Ons to Red Hat Enterprise Linux allow you to tailor your application environment with workload extensions to suit your particular computing requirements." For RHEL6.2 we are planning to have an Enterprise Identity Replication add-on. Until then, free evaluations will be available for customers who wish to play with IPA while it is a technology preview. Cheers, Kev From sbingram at gmail.com Thu Apr 7 23:13:38 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Thu, 7 Apr 2011 16:13:38 -0700 Subject: [Freeipa-users] register ipa directory server with register-ds-admin.pl Message-ID: I'm trying to register the ipa directory server with register-ds-admin.pl so that I may use the ds-console to view the directory. As I see that the ipa portion of the directory is meant to be managed by ipa, I don't intend on touching that part of the tree. However, it would be really nice to be able to view the directory configuration and maybe make configuration changes (if allowed) using the 389-ds-console. I found an earlier post about automating this process, but it apparently dealt with only version 1. Running register-ds-admin.pl, I have successfully created an admin server as well as another directory to store the configuration into. However, when I try to register the ipa directory server, I get the error: The map value 'ServerAdminID' for key 'as_uid' did not map to a value in any of the given information files. I see this error referenced in earlier 389-ds bug reports, but it is supposed to have already been fixed. Is this error message another bug with 389-ds that I should discuss on that list and/or file a bug report with them, or is it a ipa server issue that could be solved if I simply knew what to do? Steve From rmeggins at redhat.com Thu Apr 7 23:23:01 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 07 Apr 2011 17:23:01 -0600 Subject: [Freeipa-users] register ipa directory server with register-ds-admin.pl In-Reply-To: References: Message-ID: <4D9E4755.90509@redhat.com> On 04/07/2011 05:13 PM, Stephen Ingram wrote: > I'm trying to register the ipa directory server with > register-ds-admin.pl so that I may use the ds-console to view the > directory. As I see that the ipa portion of the directory is meant to > be managed by ipa, I don't intend on touching that part of the tree. > However, it would be really nice to be able to view the directory > configuration and maybe make configuration changes (if allowed) using > the 389-ds-console. I found an earlier post about automating this > process, but it apparently dealt with only version 1. > > Running register-ds-admin.pl, I have successfully created an admin > server as well as another directory to store the configuration into. > However, when I try to register the ipa directory server, I get the > error: > > The map value 'ServerAdminID' for key 'as_uid' did not map to a value > in any of the given information files. > > I see this error referenced in earlier 389-ds bug reports, but it is > supposed to have already been fixed. Is this error message another bug > with 389-ds that I should discuss on that list and/or file a bug > report with them, or is it a ipa server issue that could be solved if > I simply knew what to do? It is not an ipa issue. It is a 389 issue. If you are using the version in which the fix you referred to is in, then this is probably a new issue. You can follow up to 389-users at lists.fedoraproject.org or just file a bug in bugzilla.redhat.com against product 389. > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Fri Apr 8 06:29:29 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 8 Apr 2011 08:29:29 +0200 (CEST) Subject: [Freeipa-users] 6.1 beta In-Reply-To: <833D8E48405E064EBC54C84EC6B36E400729CF@STAWINCOX10MBX3.staff.vuw.ac.n z> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com>,<4D9E2003.9030401@nixtra.com> <833D8E48405E064EBC54C84EC6B36E400729CF@STAWINCOX10MBX3.staff.vuw.ac.nz> Message-ID: <47313.213.225.75.97.1302244169.squirrel@www.nixtra.com> > > > >> Just to elaborate on Dmitri's comments. In addition to the IPA client >> and server packages that are included in the RHEL6.1 beta channel, there will be a separate RHEL >> add-on channel, Enterprise Identity Replication. That add-on channel will contain ds-replication >> and the Windows sync packages. >> >> If you wish to use IPA during the beta or when it is a tech preview >> feature of RHEL 6.1 you should request an eval entitlement to the Enterprise Identity Replication >> channel from your Red Hat account rep. >> >> Cheers, >> Kev >> > Hi Kevin, > > > I have requested the replication channel as you recommended from our > account manager. > > I am curious to why such an important feature as replication is put in > it's own channel. I see IPA is trying to compete with Active Directory to service Unix/Linux > machines, however with Active Directory all features is included in the base package of the > operating system. > > Why does Red Hat put the replication feature of IPA into a seperate > channel from the operating system? > > > Rgds, > Siggi > > > ========== > > > Silly question.....they want to make money and lock out the "easy" possibility of you not paying > them. > > There is a very good reason RedHat is nick named the Microsoft of the Linux world......but they > are all pretty much the same. > > You have to go into this with open eyes......this project isnt a real open source project with > real open source ppl from all walks of life.....its a Red Hat project....that they let you see > into on their terms, Sun and oracle for instance have done the same thing.....their projects > splutter along with little OSS community support. > > Example, so if you went to say mailman (like I do) that's a real open source product and I can > get first class support via that....I would think that this will never be a place for open source > support for IPA it will be "please go to red hat and pay if you want help". > > I dont know Ive even seen a single contributor who doesnt have a @redhat.com address, that set > off warning lights for me......probably why the FDS project still has so many contributors and > users.... > > I hadnt noticed this wrinkle as I'm busy building a total virtual copy of prod to run a huge > proof of concept / pre-prod setup which will take me another week at least....given we dont have > much money and its going to take me more than 6months to do, paying $ isnt practical/possible and > we dont know the cost when 6.2 comes out. So I suspect that if you dont want or cant afford a > support contract bailing to CENTOS 6.1 or using CENTOS rpms to finish the glue (on RHEL) will be > the way to go. Given we will be using shibboleth and everyone around us with shibboleth is on > CENTOS its probably where we will go..... > > > Its not all bad, bear in mind of course an Identity / LDAP product off anyone else eg Oracle will > cost you mega bucks to buy (think numbers ending in 5 0's), is bloody awful (2 of us spent 6 > weeks trying to make its virtual front end LDAP server even start let alone do anything of use > and I failed).....and costly to look after (think 1 FTE and a highly paid one to boot).....I > really wonder if the business case stacks up at all.... > > regards > Hello Steven, I do not agree with you. You can download the source for IPA at any time for using, forking or creating and supporting your own distribution, that to me is an open source project. Doesn't matter how many of the contributers have or does not have a @redhat address. Rgds, Siggi From sigbjorn at nixtra.com Fri Apr 8 06:38:37 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 8 Apr 2011 08:38:37 +0200 (CEST) Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9E42BA.2080505@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> Message-ID: <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> mvh, Sigbjorn Lie 's/windows/unix/g' - "Ubuntu" - an African word, meaning "Slackware is too hard for me" On Fri, April 8, 2011 01:03, Kevin Unthank wrote: > > >>> Just to elaborate on Dmitri's comments. In addition to the IPA client >>> and server packages that are included in the RHEL6.1 beta channel, there will be a separate >>> RHEL add-on channel, Enterprise Identity Replication. >>> That add-on channel will contain ds-replication and the Windows sync >>> packages. >>> >>> If you wish to use IPA during the beta or when it is a tech preview >>> feature of RHEL 6.1 you should request an eval entitlement to the Enterprise Identity >>> Replication channel from your Red Hat account >>> rep. >>> >>> Cheers, >>> Kev >>> >> Hi Kevin, >> >> >> I have requested the replication channel as you recommended from our account manager. >> >> >> I am curious to why such an important feature as replication is put in it's own channel. I see >> IPA is trying to compete with Active Directory to service Unix/Linux machines, however with >> Active Directory all features is included in the base package of the operating system. >> >> >> Why does Red Hat put the replication feature of IPA into a seperate channel from the operating >> system? >> >> >> Rgds, >> Siggi >> > > Hi Siggi, > > > With RHEL6 we are striving to have more flexibility with packaging and > features. From the website: http://www.redhat.com/rhel/add-ons/ > > "Add-Ons to Red Hat Enterprise Linux allow you to tailor your application > environment with workload extensions to suit your particular computing requirements." > > For RHEL6.2 we are planning to have an Enterprise Identity Replication > add-on. Until then, free evaluations will be available for customers who wish to play with IPA > while it is a technology preview. > Hi Kevin, Please disregards Steven Jones' ranting, this was not the kind of feedback I was looking for. Ok, I do like the wider options for channels in Red Hat, but this bring me to my next question: Will there be an extra charge for this add on channel, or will this be included in the base subscription? If $answer = yes { Why does Red Hat think they can charge more for a feature that is included in it's competitors base license for the equivalent product? } Else if $answer = no { Great! :) } Rgds, Siggi From sigbjorn at nixtra.com Fri Apr 8 06:45:59 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 8 Apr 2011 08:45:59 +0200 (CEST) Subject: [Freeipa-users] 6.1 beta In-Reply-To: <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> Message-ID: <49541.213.225.75.97.1302245159.squirrel@www.nixtra.com> Right, forgot to remove autosignature. :) See my post at the bottom of my last email. Rgds, Siggi On Fri, April 8, 2011 08:38, Sigbjorn Lie wrote: > > mvh, Sigbjorn Lie > > > 's/windows/unix/g' > - "Ubuntu" - an African word, meaning "Slackware is too hard for me" > > > > On Fri, April 8, 2011 01:03, Kevin Unthank wrote: > >> >> >> >>>> Just to elaborate on Dmitri's comments. In addition to the IPA client >>>> and server packages that are included in the RHEL6.1 beta channel, there will be a separate >>>> RHEL add-on channel, Enterprise Identity Replication. >>>> That add-on channel will contain ds-replication and the Windows sync >>>> packages. >>>> >>>> If you wish to use IPA during the beta or when it is a tech preview >>>> feature of RHEL 6.1 you should request an eval entitlement to the Enterprise Identity >>>> Replication channel from your Red Hat account >>>> rep. >>>> >>>> Cheers, >>>> Kev >>>> >>>> >>> Hi Kevin, >>> >>> >>> >>> I have requested the replication channel as you recommended from our account manager. >>> >>> >>> >>> I am curious to why such an important feature as replication is put in it's own channel. I >>> see IPA is trying to compete with Active Directory to service Unix/Linux machines, however >>> with Active Directory all features is included in the base package of the operating system. >>> >>> >>> >>> Why does Red Hat put the replication feature of IPA into a seperate channel from the >>> operating system? >>> >>> >>> Rgds, >>> Siggi >>> >>> >> >> Hi Siggi, >> >> >> >> With RHEL6 we are striving to have more flexibility with packaging and >> features. From the website: http://www.redhat.com/rhel/add-ons/ >> >> "Add-Ons to Red Hat Enterprise Linux allow you to tailor your application >> environment with workload extensions to suit your particular computing requirements." >> >> For RHEL6.2 we are planning to have an Enterprise Identity Replication >> add-on. Until then, free evaluations will be available for customers who wish to play with IPA >> while it is a technology preview. >> > > Hi Kevin, > > > Please disregards Steven Jones' ranting, this was not the kind of feedback I was looking for. > > > Ok, I do like the wider options for channels in Red Hat, but this bring me to my next question: > Will there be an extra charge for this add on channel, or will this be included in the base > subscription? > > If $answer = yes { Why does Red Hat think they can charge more for a feature that is included in > it's competitors base license for the equivalent product? } > > Else if $answer = no { Great! :) } > > > > > Rgds, > Siggi > > > > > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > From natxo.asenjo at gmail.com Fri Apr 8 07:48:08 2011 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 8 Apr 2011 09:48:08 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> Message-ID: On Fri, Apr 8, 2011 at 8:38 AM, Sigbjorn Lie wrote: > Ok, I do like the wider options for channels in Red Hat, but this bring me to my next question: > Will there be an extra charge for this add on channel, or will this be included in the base > subscription? > > If $answer = yes { Why does Red Hat think they can charge more for a feature that is included in > it's competitors base license for the equivalent product? } does Microsoft include a synchronization plugin to RHDS? They do have a synchronization package between different servers (sql and possibly other ldap servers) into AD, but iirc not free (sorry, I forgot its name, I saw it in the pile of cd/dvds we get from MS just in case we bite and use it :-) ). The synchronization between RHDS and Windows AD is as far as I see it, just like the one from 389 directory server: http://directory.fedoraproject.org/wiki/Howto:WindowsSync ; if there is a supported module for freeipa, then great. Otherwise, one can always try to get it working on its own. Or am I absolutely wrong about this? -- natxo From sigbjorn at nixtra.com Fri Apr 8 09:08:42 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 8 Apr 2011 11:08:42 +0200 (CEST) Subject: [Freeipa-users] 6.1 beta In-Reply-To: References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> Message-ID: <46001.213.225.75.97.1302253722.squirrel@www.nixtra.com> On Fri, April 8, 2011 09:48, Natxo Asenjo wrote: > On Fri, Apr 8, 2011 at 8:38 AM, Sigbjorn Lie wrote: > > >> Ok, I do like the wider options for channels in Red Hat, but this bring me to my next question: >> Will there be an extra charge for this add on channel, or will this be included in the base >> subscription? >> >> If $answer = yes { Why does Red Hat think they can charge more for a feature that is included >> in it's competitors base license for the equivalent product? } > > does Microsoft include a synchronization plugin to RHDS? They do have a synchronization package > between different servers (sql and possibly other ldap servers) into AD, but iirc not free (sorry, > I forgot its > name, I saw it in the pile of cd/dvds we get from MS just in case we bite and use it :-) ). > > The synchronization between RHDS and Windows AD is as far as I see it, > just like the one from 389 directory server: > http://directory.fedoraproject.org/wiki/Howto:WindowsSync ; if there > is a supported module for freeipa, then great. Otherwise, one can always try to get it working on > its own. > > Or am I absolutely wrong about this? > -- Hi, Sync between Windows and IPA is included. I am asking about the replication between IPA servers. Rgds, Siggi From roland.kaeser at intersoft-networks.ch Fri Apr 8 13:13:00 2011 From: roland.kaeser at intersoft-networks.ch (Roland Kaeser) Date: Fri, 08 Apr 2011 15:13:00 +0200 (CEST) Subject: [Freeipa-users] IPA Client join In-Reply-To: <4D95E720.5010802@redhat.com> Message-ID: <615b0863-91a6-43b0-9480-7bb1542fe369@nethanja.intersoft-networks.ch> Hello Rob Thanks for the srpm. Sorry but I just had time now to compile and test it. While installing and testing ipa-client-install, I found a small installation dependency problem in the spec. To install the rpm the package nss-tools should be required. This provides /usr/bin/certutil which is executed by the ipa-client-install while joining the realm and getting the certificate. You eventually can add this additional installation dependency to the spec file. Thanks Roland ----- Urspr?ngliche Mail ----- Von: "Rob Crittenden" An: "Roland K?ser" CC: freeipa-users at redhat.com Gesendet: Freitag, 1. April 2011 16:54:24 Betreff: Re: [Freeipa-users] IPA Client join Roland Kaeser wrote: > Hello > >> The next update will be in 6.1. I can probably cobble together a srpm >> that would work on 6.0 until 6.1 is released if you'd like. > > Is there a definitive release date for 6.1? I would like to have srpm for 6.0, if possible, to start building up my pilot. > Thanks Attached is a srpm that updates the OIDs. I did a very brief smoke-test and was able to join a 6.0 client to a F-15 server. The tarball is still alpha 3. rob > > Roland > > > ----- Urspr?ngliche Mail ----- > Von: "Rob Crittenden" > An: "Roland K?ser" > CC: freeipa-users at redhat.com > Gesendet: Donnerstag, 31. M?rz 2011 20:46:27 > Betreff: Re: [Freeipa-users] IPA Client join > > Roland Kaeser wrote: >> Hello >> >>> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? > > The next update will be in 6.1. I can probably cobble together a srpm > that would work on 6.0 until 6.1 is released if you'd like. > >> >> So which is the software stack to use for my pilot and the later production environment? >> I wouldn't like to use Fedora in company production environments. I would be really prefer to use RHEL6/6.1 >> I also checked the latest avialable fedora 15 version. I only can find a alpha version iso from february, 28. >> >> I would really like to have a software stack which works with freeipa (client/server) and afs-server. > > Yeah, this is a bit of a grey area right now. IPA does a lot of cat > herding and keeping all the various versions of the packages we require > in sync is very tedious. > > For a pilot I think you'd be fine using Fedora 14 though I would > recommend doing some amount of re-testing in F-15 once it is released. > We've done 80% of our development in F-14 and it works very well. The > dogtag project built F-14 packages for us as a favor. They don't want to > support deployments of it because they've done zero testing of their own > on F-14. You'd need to build the packages yourself though, we haven't > pushed this to F-14 because of the dogtag issue. mock should be able to > build it fairly painlessly. > > What I've done for my F-15 installations is to install F-14 and then > upgrade to Fedora-15 from there. It has been fairly painless. The GA IPA > release is in the stable repo of F-15 now. > > regards > > rob > >> >> >> ----- Urspr?ngliche Mail ----- >> Von: "Sigbjorn Lie" >> An: "Rob Crittenden" >> CC: "Roland K??ser", freeipa-users at redhat.com >> Gesendet: Donnerstag, 31. M?rz 2011 16:14:34 >> Betreff: Re: [Freeipa-users] IPA Client join >> >>> >>> In rc2 we had to make a change to the OID used for some operations >>> because they were duplicated. The OID for the ipa-getkeytab operation was one of them, so older >>> clients don't work with newer servers. IIRC the EL6 ipa-client was based on the alpha 3 release. >>> >>> I attached a patch that gives the general idea of what needs to change. >>> It was originally for the EL 5 branch but it may work with few changes >>> in EL6. >>> >> >> Will there be an update to the ipa-client package in RHEL 6.0, or do we have to wait for RHEL 6.1? >> >> >> Rgds, >> Siggi >> >> >> > > -- InterSoft Networks Roland K?ser, Systems Engineer OpenSource Fulachstr. 197, 8200 Schaffhausen Tel: +41 77 415 79 11 ------------------------------------------------------------------------------------------------------------------------------ Diejenigen, die ihre Freiheit zugunsten der Sicherheit aufgeben, werden am Ende keines von beiden haben - und verdienen es auch nicht. (Benjamin Franklin) ------------------------------------------------------------------------------------------------------------------------------ From dpal at redhat.com Fri Apr 8 13:26:42 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Apr 2011 09:26:42 -0400 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> Message-ID: <4D9F0D12.1040707@redhat.com> On 04/08/2011 02:38 AM, Sigbjorn Lie wrote: > Hi Kevin, > > Please disregards Steven Jones' ranting, this was not the kind of feedback I was looking for. > > Ok, I do like the wider options for channels in Red Hat, but this bring me to my next question: > Will there be an extra charge for this add on channel, or will this be included in the base > subscription? > > If $answer = yes { Why does Red Hat think they can charge more for a feature that is included in > it's competitors base license for the equivalent product? } > > Else if $answer = no { Great! :) } > > > > Rgds, > Siggi I will leave to Kevin to describe details but in a nutshell the replication and or synchronization with AD (same channel) is not free. Red Hat worked out a competitive pricing model for this product and some of the cost is attached to the replication bits. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From janfrode at tanso.net Fri Apr 8 13:37:10 2011 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Fri, 8 Apr 2011 15:37:10 +0200 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9F0D12.1040707@redhat.com> References: <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> <4D9F0D12.1040707@redhat.com> Message-ID: <20110408133710.GB19714@oc1046828364.ibm.com> On Fri, Apr 08, 2011 at 09:26:42AM -0400, Dmitri Pal wrote: > I will leave to Kevin to describe details but in a nutshell the > replication and or synchronization with AD (same channel) is not free. > Red Hat worked out a competitive pricing model for this product and some > of the cost is attached to the replication bits. /me thinks this looks great. I've been afraid IPA would turn out too expensive.. Being an part of standard RHEL hopefully means that the tiny replication feature woun't be prohibitly expensive :-) -jf From JR.Aquino at citrix.com Fri Apr 8 15:49:32 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 8 Apr 2011 15:49:32 +0000 Subject: [Freeipa-users] Auto membership plugin In-Reply-To: <4D94DE14.5010604@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> Message-ID: Is there any way to capture a description associated with the regex -> group mapping? I was thinking that after time, it would be important to look back on rules and know why they were put there. Particularly in the case of regex, since it may not be completely obvious by looking back at alphabet soup. From dpal at redhat.com Fri Apr 8 16:07:15 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Apr 2011 12:07:15 -0400 Subject: [Freeipa-users] Auto membership plugin In-Reply-To: References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> Message-ID: <4D9F32B3.1070501@redhat.com> On 04/08/2011 11:49 AM, JR Aquino wrote: > Is there any way to capture a description associated with the regex -> group mapping? > > I was thinking that after time, it would be important to look back on rules and know why they were put there. > > Particularly in the case of regex, since it may not be completely obvious by looking back at alphabet soup. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > The more I think about current design the more I want to normalize things. I would rather instead of: dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberExclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com autoMemberInclusiveRegex: cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn Have something like: dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition objectclass: cnContainer autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberRegexRule: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config autoMemberRegexRule: cn=Mailserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinitionRegexRule cn: Webserver Inclusion Rule description: Rule contains regular expression to include webserver hosts into the webserver group. include: yes <- include or exclude memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com arrtibuteToMath: fgdn expressionToMatch: ^www[1-9]+\.example\.com Or something along those lines... -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kevinu at redhat.com Fri Apr 8 18:32:25 2011 From: kevinu at redhat.com (Kevin Unthank) Date: Fri, 08 Apr 2011 11:32:25 -0700 Subject: [Freeipa-users] 6.1 beta In-Reply-To: <4D9F0D12.1040707@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40035E94@STAWINCOX10MBX1.staff.vuw.ac.nz> <4D98E984.3070201@nixtra.com> <4D99CB16.5040603@redhat.com> <4D99F02E.3050401@nixtra.com> <4D9A0112.1000102@nixtra.com> <4D9A0EAB.7070803@redhat.com> <4D9A15A4.4010206@nixtra.com> <4D9A169F.9030205@redhat.com> <4D9A5358.50208@redhat.com> <4D9E2003.9030401@nixtra.com> <4D9E42BA.2080505@redhat.com> <48473.213.225.75.97.1302244717.squirrel@www.nixtra.com> <4D9F0D12.1040707@redhat.com> Message-ID: <4D9F54B9.10709@redhat.com> On 04/08/2011 06:26 AM, Dmitri Pal wrote: > On 04/08/2011 02:38 AM, Sigbjorn Lie wrote: >> Hi Kevin, >> >> Please disregards Steven Jones' ranting, this was not the kind of feedback I was looking for. >> >> Ok, I do like the wider options for channels in Red Hat, but this bring me to my next question: >> Will there be an extra charge for this add on channel, or will this be included in the base >> subscription? >> >> If $answer = yes { Why does Red Hat think they can charge more for a feature that is included in >> it's competitors base license for the equivalent product? } >> >> Else if $answer = no { Great! :) } >> >> >> >> Rgds, >> Siggi > I will leave to Kevin to describe details but in a nutshell the > replication and or synchronization with AD (same channel) is not free. > Red Hat worked out a competitive pricing model for this product and some > of the cost is attached to the replication bits. > There aren't many more details to fill in because the final pricing decisions have not been, erm... finalised. As Dmitri said, we have been working on models to ensure the pricing is competitive and flexible. One additional parameter that we have to take into consideration are the pricing models for other Red Hat offerings such as virtualization, systems management and middleware offerings. We want an easy to understand pricing model that provides the best value for our customers. Just to reiterate, the upstream community supported packages remain freely available in both binary and source form. Cheers, Kev From sbingram at gmail.com Fri Apr 8 20:51:12 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 8 Apr 2011 13:51:12 -0700 Subject: [Freeipa-users] packages for Fedora 14 Message-ID: Will ipa-v2 packages be released for Fedora 14 since Fedora 15 final is not yet available? Steve From dpal at redhat.com Fri Apr 8 20:56:11 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Apr 2011 16:56:11 -0400 Subject: [Freeipa-users] packages for Fedora 14 In-Reply-To: References: Message-ID: <4D9F766B.9060508@redhat.com> On 04/08/2011 04:51 PM, Stephen Ingram wrote: > Will ipa-v2 packages be released for Fedora 14 since Fedora 15 final > is not yet available? The issue with F14 is that it still has an older version of the Certificate System (Dogtag). We can't release as there will be collisions but the upstream bits are installable on Fedora 14. > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbingram at gmail.com Fri Apr 8 21:03:04 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 8 Apr 2011 14:03:04 -0700 Subject: [Freeipa-users] Fwd: packages for Fedora 14 In-Reply-To: References: <4D9F766B.9060508@redhat.com> Message-ID: ---------- Forwarded message ---------- From: Stephen Ingram Date: Fri, Apr 8, 2011 at 2:02 PM Subject: Re: [Freeipa-users] packages for Fedora 14 To: dpal at redhat.com I installed the rc2 version and used the f14-testing repo to accommodate. Would this work for v2 or has dogtag been revved again? Steve On Fri, Apr 8, 2011 at 1:56 PM, Dmitri Pal wrote: > On 04/08/2011 04:51 PM, Stephen Ingram wrote: >> Will ipa-v2 packages be released for Fedora 14 since Fedora 15 final >> is not yet available? > > The issue with F14 is that it still has an older version of the > Certificate System (Dogtag). > We can't release as there will be collisions but the upstream bits are > installable on Fedora 14. > >> Steve >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From ide4you at gmail.com Sat Apr 9 12:46:15 2011 From: ide4you at gmail.com (Uzor Ide) Date: Sat, 9 Apr 2011 08:46:15 -0400 Subject: [Freeipa-users] SCEP support Message-ID: I'd like to know if freeipa v2 supports SCEP. If so, is it enabled and at what port can I access it. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Apr 11 13:25:06 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Apr 2011 09:25:06 -0400 Subject: [Freeipa-users] SCEP support In-Reply-To: References: Message-ID: <4DA30132.10800@redhat.com> On 04/09/2011 08:46 AM, Uzor Ide wrote: > I'd like to know if freeipa v2 supports SCEP. If so, is it enabled and > at what port can I access it. > > Thanks > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Officially not at the moment. Dogtag certificate system does but I am not sure if the component responsible for SCEP has been integrated with IPA. Even if it is, it has not been tried. I added Andrew Wnuk to the thread who is a SME. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ lly -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Mon Apr 11 15:27:31 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 11 Apr 2011 08:27:31 -0700 Subject: [Freeipa-users] Auto membership plugin In-Reply-To: <4D9F32B3.1070501@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> Message-ID: <4DA31DE3.8070608@redhat.com> On 04/08/2011 09:07 AM, Dmitri Pal wrote: > On 04/08/2011 11:49 AM, JR Aquino wrote: >> Is there any way to capture a description associated with the regex -> group mapping? >> >> I was thinking that after time, it would be important to look back on rules and know why they were put there. >> >> Particularly in the case of regex, since it may not be completely obvious by looking back at alphabet soup. >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > The more I think about current design the more I want to normalize things. > I would rather instead of: > > dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberDefinition > autoMemberScope: dc=example,dc=com > autoMemberFilter: objectclass=ipaHost > autoMemberExclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com > autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com > autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com > autoMemberInclusiveRegex: cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com > autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com > autoMemberGroupingAttr: member:dn > > > Have something like: > > dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberDefinition > objectclass: cnContainer > autoMemberScope: dc=example,dc=com > autoMemberFilter: objectclass=ipaHost > autoMemberRegexRule: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > autoMemberRegexRule: cn=Mailserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com > autoMemberGroupingAttr: member:dn > > > dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config > objectclass: autoMemberDefinitionRegexRule > cn: Webserver Inclusion Rule > description: Rule contains regular expression to include webserver hosts into the webserver group. > include: yes<- include or exclude > memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com > arrtibuteToMath: fgdn > expressionToMatch: ^www[1-9]+\.example\.com > > > Or something along those lines... It's a nice logical layout, but it would be hard for an administrator to figure out what exactly would happen if they were to add a host with a specific hostname. Since the config is spread over so many entries, one would have to look at the top level config entry to find each rule DN, fetch each rule DN to look at the regexes. All of the information is so spread out that you can't just look in one place to see the rules that will be used. This could make things difficult from a troubleshooting perspective. The description issue is a tough one to deal with if we have the config in the form that is currently described in the design doc. Since we want a description per regex rule, we should need to make the description be a part of the regex rule value instead of a separate description attribute. I don't necessarily like this approach, as the readability of the config will not be nice. From dpal at redhat.com Mon Apr 11 17:25:10 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Apr 2011 13:25:10 -0400 Subject: [Freeipa-users] Auto membership plugin In-Reply-To: <4DA31DE3.8070608@redhat.com> References: <4D93295E.1030507@redhat.com> <4D935DF6.9060408@redhat.com> <4D93663C.3000109@redhat.com> <4D94A08E.9050804@redhat.com> <4D94D5E9.4020900@redhat.com> <4D94DE14.5010604@redhat.com> <4D9F32B3.1070501@redhat.com> <4DA31DE3.8070608@redhat.com> Message-ID: <4DA33976.2010201@redhat.com> On 04/11/2011 11:27 AM, Nathan Kinder wrote: > On 04/08/2011 09:07 AM, Dmitri Pal wrote: >> On 04/08/2011 11:49 AM, JR Aquino wrote: >>> Is there any way to capture a description associated with the regex >>> -> group mapping? >>> >>> I was thinking that after time, it would be important to look back >>> on rules and know why they were put there. >>> >>> Particularly in the case of regex, since it may not be completely >>> obvious by looking back at alphabet soup. >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> The more I think about current design the more I want to normalize >> things. >> I would rather instead of: >> >> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> objectclass: autoMemberDefinition >> autoMemberScope: dc=example,dc=com >> autoMemberFilter: objectclass=ipaHost >> autoMemberExclusiveRegex: >> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com >> autoMemberInclusiveRegex: >> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com >> autoMemberInclusiveRegex: >> cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com >> autoMemberInclusiveRegex: >> cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com >> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >> autoMemberGroupingAttr: member:dn >> >> >> Have something like: >> >> dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> objectclass: autoMemberDefinition >> objectclass: cnContainer >> autoMemberScope: dc=example,dc=com >> autoMemberFilter: objectclass=ipaHost >> autoMemberRegexRule: cn=Webserver Inclusion >> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> autoMemberRegexRule: cn=Mailserver Inclusion >> Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config >> autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto >> Membership Plugin,cn=plugins,cn=config >> autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com >> autoMemberGroupingAttr: member:dn >> >> >> dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership >> Plugin,cn=plugins,cn=config >> objectclass: autoMemberDefinitionRegexRule >> cn: Webserver Inclusion Rule >> description: Rule contains regular expression to include webserver >> hosts into the webserver group. >> include: yes<- include or exclude >> memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com >> arrtibuteToMath: fgdn >> expressionToMatch: ^www[1-9]+\.example\.com >> >> >> Or something along those lines... > It's a nice logical layout, but it would be hard for an administrator > to figure out what exactly would happen if they were to add a host > with a specific hostname. Since the config is spread over so many > entries, one would have to look at the top level config entry to find > each rule DN, fetch each rule DN to look at the regexes. All of the > information is so spread out that you can't just look in one place to > see the rules that will be used. This could make things difficult > from a troubleshooting perspective. This should not be viewed in raw. THe UI and CLi should come to the rescue. I am not sure that this is a right approach to mix readability and normalization. To follow this logic no-one would ever normalize data in any DB due to the claim that it would be hard to join tables. > > The description issue is a tough one to deal with if we have the > config in the form that is currently described in the design doc. > Since we want a description per regex rule, we should need to make the > description be a part of the regex rule value instead of a separate > description attribute. I don't necessarily like this approach, as the > readability of the config will not be nice. > I think this tips the scale towards the approach I proposed. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From awnuk at redhat.com Mon Apr 11 18:42:26 2011 From: awnuk at redhat.com (Andrew Wnuk) Date: Mon, 11 Apr 2011 11:42:26 -0700 Subject: [Freeipa-users] SCEP support In-Reply-To: <4DA30132.10800@redhat.com> References: <4DA30132.10800@redhat.com> Message-ID: <4DA34B92.4080807@redhat.com> On 04/11/2011 06:25 AM, Dmitri Pal wrote: > On 04/09/2011 08:46 AM, Uzor Ide wrote: >> I'd like to know if freeipa v2 supports SCEP. If so, is it enabled >> and at what port can I access it. >> >> Thanks >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > Officially not at the moment. > Dogtag certificate system does but I am not sure if the component > responsible for SCEP has been integrated with IPA. > Even if it is, it has not been tried. > I added Andrew Wnuk to the thread who is a SME. > > Yes, SCEP is not integrated with IPA and therefore has not been tested with IPA, but it is available directly through Dogtag and it has been tested as a Dogtag component. Please note that SCEP has to be enabled in Dogtag CA since it is disabled by default. Thank you, Andrew > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > lly -------------- next part -------------- An HTML attachment was scrubbed... URL: From ide4you at gmail.com Mon Apr 11 18:54:22 2011 From: ide4you at gmail.com (ide4you at gmail.com) Date: Mon, 11 Apr 2011 18:54:22 +0000 Subject: [Freeipa-users] SCEP support In-Reply-To: <4DA34B92.4080807@redhat.com> References: <4DA30132.10800@redhat.com><4DA34B92.4080807@redhat.com> Message-ID: <582734481-1302548066-cardhu_decombobulator_blackberry.rim.net-2003976422-@bda057.bisx.prod.on.blackberry> Please how do I enable SCEP in IPA? Thanks Sent on the TELUS Mobility network with BlackBerry -----Original Message----- From: Andrew Wnuk Sender: freeipa-users-bounces at redhat.com Date: Mon, 11 Apr 2011 11:42:26 To: Subject: Re: [Freeipa-users] SCEP support _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Mon Apr 11 19:12:43 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Apr 2011 15:12:43 -0400 Subject: [Freeipa-users] SCEP support In-Reply-To: <582734481-1302548066-cardhu_decombobulator_blackberry.rim.net-2003976422-@bda057.bisx.prod.on.blackberry> References: <4DA30132.10800@redhat.com><4DA34B92.4080807@redhat.com> <582734481-1302548066-cardhu_decombobulator_blackberry.rim.net-2003976422-@bda057.bisx.prod.on.blackberry> Message-ID: <4DA352AB.2010005@redhat.com> On 04/11/2011 02:54 PM, ide4you at gmail.com wrote: > Please how do I enable SCEP in IPA? > > Thanks It is a part of the CS but it is disabled now and not integrated with the IPA objects in any way. We suspect it will take some amount of work to make it usable. However this is not a priority for IPA at the moment. You can definitely log an enhancement request but if you are looking for this functionality sooner rather than later would you be interested in contributing to the project? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From gavin at urbanairship.com Tue Apr 12 20:57:33 2011 From: gavin at urbanairship.com (Gavin McQuillan) Date: Tue, 12 Apr 2011 13:57:33 -0700 Subject: [Freeipa-users] Installing on CentOS 5.X? Message-ID: Hi, We're moving to a vendor which only supports servers with CentOS or RHEL. I see a 2 1/2 year old document for building SRC RPMs to get an older version of ipa-server running: http://howtoforge.com/how-to-build-rhel-ipa-rpms-for-centos-5. However there are problems with it. - It's missing several steps and/or or the package names have changed since 5.2. - Some people hint that 'centos-ds' located in the testing should serve the same purpose, but it looks like it only supports basic LDAP administration. - Naturally, this repo config doesn't work: http://freeipa.org/downloads/freeipa-devel.repo Has anybody in the community successfully gotten a relatively recent version of FreeIPA installed on CentOS 5.X? Thanks in advance, -Gavin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Apr 12 21:37:26 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Apr 2011 17:37:26 -0400 Subject: [Freeipa-users] Installing on CentOS 5.X? In-Reply-To: References: Message-ID: <4DA4C616.3010704@redhat.com> Gavin McQuillan wrote: > Hi, > > We're moving to a vendor which only supports servers with CentOS or RHEL. > > I see a 2 1/2 year old document for building SRC RPMs to get an older > version of ipa-server running: > http://howtoforge.com/how-to-build-rhel-ipa-rpms-for-centos-5. However > there are problems with it. > > - It's missing several steps and/or or the package names have changed > since 5.2. > - Some people hint that 'centos-ds' located in the testing should serve > the same purpose, but it looks like it only supports basic LDAP > administration. > - Naturally, this repo config doesn't work: > http://freeipa.org/downloads/freeipa-devel.repo > > Has anybody in the community successfully gotten a relatively recent > version of FreeIPA installed on CentOS 5.X? > > Thanks in advance, > -Gavin > The server portion of freeIPA v2 server will not work on a 5.x-based system. It would be a tremendous amount of work to back port things. freeIPA v1 should work fine on 5.x. I'm not all that familiar with CentOS but I would guess that centos-ds is the equivalent of the RHDS packages so that is what you need. regards rob From prjctgeek at gmail.com Tue Apr 12 22:34:04 2011 From: prjctgeek at gmail.com (Doug Chapman) Date: Tue, 12 Apr 2011 15:34:04 -0700 Subject: [Freeipa-users] Installing on CentOS 5.X? In-Reply-To: References: Message-ID: Recent builds, no. FreeIPA 1.2 will build on Centos5 with some work (as in mucking with spec files). We're using the 389-ds (1.2.4) package from Fedora. At this juncture I would not invest the time to get this working on Centos5. On Tue, Apr 12, 2011 at 1:57 PM, Gavin McQuillan wrote: > Hi, > > We're moving to a vendor which only supports servers with CentOS or RHEL. > > I see a 2 1/2 year old document for building SRC RPMs to get an older > version of ipa-server running: > http://howtoforge.com/how-to-build-rhel-ipa-rpms-for-centos-5. However > there are problems with it. > > - It's missing several steps and/or or the package names have changed since > 5.2. > - Some people hint that 'centos-ds' located in the testing should serve the > same purpose, but it looks like it only supports basic LDAP administration. > - Naturally, this repo config doesn't work: > http://freeipa.org/downloads/freeipa-devel.repo > > Has anybody in the community successfully gotten a relatively recent > version of FreeIPA installed on CentOS 5.X? > > Thanks in advance, > -Gavin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Doug Chapman -------------- next part -------------- An HTML attachment was scrubbed... URL: From gavin at urbanairship.com Wed Apr 13 20:18:55 2011 From: gavin at urbanairship.com (Gavin McQuillan) Date: Wed, 13 Apr 2011 13:18:55 -0700 Subject: [Freeipa-users] Installing on CentOS 5.X? In-Reply-To: References: Message-ID: I did manage to get the 1.0.0 version compiled and running on CentOS 5.6, using the aforementioned spec file mucking. But the suggested course would be to wait for CentOS 6.X, change to RHEL 6, or is Fedora really the only distribution still being targeted? Cheers, -Gavin On Tue, Apr 12, 2011 at 3:34 PM, Doug Chapman wrote: > Recent builds, no. > > FreeIPA 1.2 will build on Centos5 with some work (as in mucking with spec > files). We're using the 389-ds (1.2.4) package from Fedora. > > At this juncture I would not invest the time to get this working on > Centos5. > > On Tue, Apr 12, 2011 at 1:57 PM, Gavin McQuillan wrote: > >> Hi, >> >> We're moving to a vendor which only supports servers with CentOS or RHEL. >> >> I see a 2 1/2 year old document for building SRC RPMs to get an older >> version of ipa-server running: >> http://howtoforge.com/how-to-build-rhel-ipa-rpms-for-centos-5. However >> there are problems with it. >> >> - It's missing several steps and/or or the package names have changed >> since 5.2. >> - Some people hint that 'centos-ds' located in the testing should serve >> the same purpose, but it looks like it only supports basic LDAP >> administration. >> - Naturally, this repo config doesn't work: >> http://freeipa.org/downloads/freeipa-devel.repo >> >> Has anybody in the community successfully gotten a relatively recent >> version of FreeIPA installed on CentOS 5.X? >> >> Thanks in advance, >> -Gavin >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > -- > Doug Chapman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Apr 13 20:40:13 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Apr 2011 16:40:13 -0400 Subject: [Freeipa-users] Installing on CentOS 5.X? In-Reply-To: References: Message-ID: <4DA60A2D.60708@redhat.com> On 04/13/2011 04:18 PM, Gavin McQuillan wrote: > I did manage to get the 1.0.0 version compiled and running on CentOS > 5.6, using the aforementioned spec file mucking. > > But the suggested course would be to wait for CentOS 6.X, change to > RHEL 6, or is Fedora really the only distribution still being targeted? Red Hat will prvide a tech preview version in 6.1 and fully supported in 6.2. You can try beta bits now, they are already available for several weeks. > > Cheers, > -Gavin > > On Tue, Apr 12, 2011 at 3:34 PM, Doug Chapman > wrote: > > Recent builds, no. > > FreeIPA 1.2 will build on Centos5 with some work (as in mucking > with spec files). We're using the 389-ds (1.2.4) package from Fedora. > > At this juncture I would not invest the time to get this working > on Centos5. > > On Tue, Apr 12, 2011 at 1:57 PM, Gavin McQuillan > > wrote: > > Hi, > > We're moving to a vendor which only supports servers with > CentOS or RHEL. > > I see a 2 1/2 year old document for building SRC RPMs to get > an older version of ipa-server > running: http://howtoforge.com/how-to-build-rhel-ipa-rpms-for-centos-5. > However there are problems with it. > > - It's missing several steps and/or or the package names have > changed since 5.2. > - Some people hint that 'centos-ds' located in the testing > should serve the same purpose, but it looks like it only > supports basic LDAP administration. > - Naturally, this repo config doesn't > work: http://freeipa.org/downloads/freeipa-devel.repo > > Has anybody in the community successfully gotten a relatively > recent version of FreeIPA installed on CentOS 5.X? > > Thanks in advance, > -Gavin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Doug Chapman > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Apr 13 20:52:07 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 13 Apr 2011 20:52:07 +0000 Subject: [Freeipa-users] Installing on CentOS 5.X? In-Reply-To: References: , Message-ID: <833D8E48405E064EBC54C84EC6B36E40093F63@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Its no where near a full IdM from what I can see so far but if you want to glue a straight forward but mixed environment together ie with MS AD and linux and get one password say across the lot plus some control then it looks good enough. So if you know what your goals are and want to see if it meets them a fedora testbed would be good enough I suspect. Ive gone through that, now I want 6 months of extended trial. You need a decent period, we bought Oracle's IdM and its still not working in #+ years and well past the odd million $.... regards Steven ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Gavin McQuillan [gavin at urbanairship.com] Sent: Thursday, 14 April 2011 8:18 a.m. To: Doug Chapman Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Installing on CentOS 5.X? I did manage to get the 1.0.0 version compiled and running on CentOS 5.6, using the aforementioned spec file mucking. But the suggested course would be to wait for CentOS 6.X, change to RHEL 6, or is Fedora really the only distribution still being targeted? Cheers, -Gavin On Tue, Apr 12, 2011 at 3:34 PM, Doug Chapman > wrote: Recent builds, no. FreeIPA 1.2 will build on Centos5 with some work (as in mucking with spec files). We're using the 389-ds (1.2.4) package from Fedora. At this juncture I would not invest the time to get this working on Centos5. On Tue, Apr 12, 2011 at 1:57 PM, Gavin McQuillan > wrote: Hi, We're moving to a vendor which only supports servers with CentOS or RHEL. I see a 2 1/2 year old document for building SRC RPMs to get an older version of ipa-server running: http://howtoforge.com/how-to-build-rhel-ipa-rpms-for-centos-5. However there are problems with it. - It's missing several steps and/or or the package names have changed since 5.2. - Some people hint that 'centos-ds' located in the testing should serve the same purpose, but it looks like it only supports basic LDAP administration. - Naturally, this repo config doesn't work: http://freeipa.org/downloads/freeipa-devel.repo Has anybody in the community successfully gotten a relatively recent version of FreeIPA installed on CentOS 5.X? Thanks in advance, -Gavin _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Doug Chapman From ide4you at gmail.com Wed Apr 13 23:45:01 2011 From: ide4you at gmail.com (Uzor Ide) Date: Wed, 13 Apr 2011 19:45:01 -0400 Subject: [Freeipa-users] SCEP support In-Reply-To: <4DA352AB.2010005@redhat.com> References: <4DA30132.10800@redhat.com> <4DA34B92.4080807@redhat.com> <582734481-1302548066-cardhu_decombobulator_blackberry.rim.net-2003976422-@bda057.bisx.prod.on.blackberry> <4DA352AB.2010005@redhat.com> Message-ID: I'd love to Dmitri, but I have a lot on my plate right now. Ide On Mon, Apr 11, 2011 at 3:12 PM, Dmitri Pal wrote: > On 04/11/2011 02:54 PM, ide4you at gmail.com wrote: > > Please how do I enable SCEP in IPA? > > > > Thanks > > It is a part of the CS but it is disabled now and not integrated with > the IPA objects in any way. > We suspect it will take some amount of work to make it usable. > However this is not a priority for IPA at the moment. You can definitely > log an enhancement request but if you are looking for this functionality > sooner rather than later would you be interested in contributing to the > project? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Thu Apr 14 00:26:15 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 13 Apr 2011 17:26:15 -0700 Subject: [Freeipa-users] allowing anonymous access to ipa directory Message-ID: This question might be better posed on a general directory server list, however, as ipa obviously contains very sensitive data, I'm curious as to what ipa users think. Although ipa uses extensive acl's to shield the most important directory attributes from general view, it does allow anonymous access to many of the general entries. I notice that many directories do this to allow outside firms to view addressbook-type information of the company from their directories and referrals also depend on this functionality. I'm wondering though, if you have users from multiple domains in your directory with say name and email address information available, wouldn't this just be a free-for-all for some enterprising spammer or such? Or, if hosting dns from ipa, host records available to aid potential attackers to map network systems? Shouldn't this be controlled further in some instances and perhaps require at least a user bind (if not a TLS/SSL layer) to access this information? Steve From dpal at redhat.com Thu Apr 14 00:43:27 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Apr 2011 20:43:27 -0400 Subject: [Freeipa-users] allowing anonymous access to ipa directory In-Reply-To: References: Message-ID: <4DA6432F.2080709@redhat.com> On 04/13/2011 08:26 PM, Stephen Ingram wrote: > This question might be better posed on a general directory server > list, however, as ipa obviously contains very sensitive data, I'm > curious as to what ipa users think. Although ipa uses extensive acl's > to shield the most important directory attributes from general view, > it does allow anonymous access to many of the general entries. I > notice that many directories do this to allow outside firms to view > addressbook-type information of the company from their directories and > referrals also depend on this functionality. I'm wondering though, if > you have users from multiple domains in your directory with say name > and email address information available, wouldn't this just be a > free-for-all for some enterprising spammer or such? Or, if hosting dns > from ipa, host records available to aid potential attackers to map > network systems? Shouldn't this be controlled further in some > instances and perhaps require at least a user bind (if not a TLS/SSL > layer) to access this information? I know that DS team has implemented the functionality to disallow anonymous bind. I just do not recall whether this functionality is already in the bits used by ipa. Nathan, can you help with this one? > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From JR.Aquino at citrix.com Thu Apr 14 01:20:43 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Thu, 14 Apr 2011 01:20:43 +0000 Subject: [Freeipa-users] allowing anonymous access to ipa directory In-Reply-To: References: Message-ID: <9CC3E10C-7BC0-4F4D-84A8-D54E238CCE33@citrixonline.com> On Apr 13, 2011, at 5:26 PM, Stephen Ingram wrote: > This question might be better posed on a general directory server > list, however, as ipa obviously contains very sensitive data, I'm > curious as to what ipa users think. Although ipa uses extensive acl's > to shield the most important directory attributes from general view, > it does allow anonymous access to many of the general entries. I > notice that many directories do this to allow outside firms to view > addressbook-type information of the company from their directories and > referrals also depend on this functionality. I'm wondering though, if > you have users from multiple domains in your directory with say name > and email address information available, wouldn't this just be a > free-for-all for some enterprising spammer or such? Or, if hosting dns > from ipa, host records available to aid potential attackers to map > network systems? Shouldn't this be controlled further in some > instances and perhaps require at least a user bind (if not a TLS/SSL > layer) to access this information? > > Steve This question has come up before Stephen. A conscious effort has been made to provide FreeIPA with a balance of security minded and usable defaults. There are circumstances with other Distributions/OS's and nss_ldap situations which require anonymous binds. It is for this reason that the default for FreeIPA permits read access to a limited scope of the LDAP directory. You will note that areas of the directory responsible for mapping security authorization controls have been deliberately protected with ACLs. That being said, there has been an ongoing effort to verify that the FreeIPA framework all functions correctly with ldap security features turned on: Always Encrypt/Disable Anonymous or Unauthenticated Binds. To turn on these features: You will want to look to: /etc/dirsrv/slapd-DOMAIN-COM/dse.ldif: nsslapd-allow-anonymous-access: on/off (This toggles anonymous / unauthenticated binds) and nsslapd-minssf: 56 (This enforces the encryption minimum security strength factor and prevents unencrypted communications) service dirsrv restart will be required for the features to take effect. -JR From nkinder at redhat.com Thu Apr 14 22:41:07 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 14 Apr 2011 15:41:07 -0700 Subject: [Freeipa-users] allowing anonymous access to ipa directory In-Reply-To: <4DA6432F.2080709@redhat.com> References: <4DA6432F.2080709@redhat.com> Message-ID: <4DA77803.6090302@redhat.com> On 04/13/2011 05:43 PM, Dmitri Pal wrote: > On 04/13/2011 08:26 PM, Stephen Ingram wrote: >> This question might be better posed on a general directory server >> list, however, as ipa obviously contains very sensitive data, I'm >> curious as to what ipa users think. Although ipa uses extensive acl's >> to shield the most important directory attributes from general view, >> it does allow anonymous access to many of the general entries. I >> notice that many directories do this to allow outside firms to view >> addressbook-type information of the company from their directories and >> referrals also depend on this functionality. I'm wondering though, if >> you have users from multiple domains in your directory with say name >> and email address information available, wouldn't this just be a >> free-for-all for some enterprising spammer or such? Or, if hosting dns >> from ipa, host records available to aid potential attackers to map >> network systems? Shouldn't this be controlled further in some >> instances and perhaps require at least a user bind (if not a TLS/SSL >> layer) to access this information? > I know that DS team has implemented the functionality to disallow > anonymous bind. > I just do not recall whether this functionality is already in the bits > used by ipa. > Nathan, can you help with this one? I believe you are referring to the nsslapd-allow-anonymous-access setting in cn=config. This is set to "on" by default, but setting it to "off" will deny access to anonymous users. This was added in the 389-ds-base-1.2.7 timeframe if I recall correctly, so it should be available for use by IPA. >> Steve >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > From Steven.Jones at vuw.ac.nz Thu Apr 21 08:11:03 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 21 Apr 2011 08:11:03 +0000 Subject: [Freeipa-users] Word of warning on freeipa availability Message-ID: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Anybody contemplating using Free-ipa should check with Redhat sales in their region before getting interested. It seems freeipa wont be sold in all regions, as an example in Asia Pacfic like RDS it may never be sold....or at least it may years away. So without access to the replication/AD sync channel and no support envisaged I would think its of limited use.... Oops..... regards From dpal at redhat.com Thu Apr 21 15:23:39 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 21 Apr 2011 11:23:39 -0400 Subject: [Freeipa-users] Word of warning on freeipa availability In-Reply-To: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4DB04BFB.3040208@redhat.com> On 04/21/2011 04:11 AM, Steven Jones wrote: > Hi, > > > > Anybody contemplating using Free-ipa should check with Redhat sales in their region before getting interested. It seems freeipa wont be sold in all regions, as an example in Asia Pacfic like RDS it may never be sold....or at least it may years away. So without access to the replication/AD sync channel and no support envisaged I would think its of limited use.... > > > I am not sure this is the accurate information. It was true regarding v1 but it most likely will be different with v2. I do not think the information you are commenting on is even shaped internally as the official sales of IPA will start only with 6.2. IPA is in tech preview in 6.1. The access to replication bits is in fact needed via Red Hat contact. I am really not sure what you are trying to say with this post? "IPA is bad, do not use it?" It seems that supporting something requires knowledge and right people. It might be very well possible that Red Hat would not be able to ramp up the right support resources for all geographies day 1. It is the question of time and demand. FreeIPA - community release is available and supported using the standard "best effort" model across the globe. It is unclear what other expectations are not met. > Oops..... > > > > regards > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Thu Apr 21 19:52:43 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 21 Apr 2011 19:52:43 +0000 Subject: [Freeipa-users] Word of warning on freeipa availability In-Reply-To: <4DB04BFB.3040208@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4DB04BFB.3040208@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E400CF861@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Im not saying its bad....actually the opposite. We looked at RDS 18months ago and I bust a gut trying to get my management interested in buying it....I finally got an agreement but were told by Redhat sales AP that it was no longer being sold as they couldnt support it but to look at freeIPA 2 because this was a great product and would be supported. So Ive gone and persuaded my line managers to take a good look at IPA, I get them interested on me doing a POC but AP Sales are now telling me the same thing for IPA as they did RDS....they dont foresee selling it in AP for the foreseeable future if ever....mainly because they tell me they cant support it. Now its possible they dont have a clue...but I cant keep waiting for ever and based on past actions that doesnt seem wise. So my point is if someone joins this "open-source" group with the intention of using this next year they should be aware there is a risk it wont be commercially supported by Redhat in their region....so in effect they could be wasting their time. In terms of a product Im not saying its rubbish, Im actually so pissed because I think from its overall design, its easy to use and simple interface and to its nuts and bolts it will be a good product and do exactly what we need.....Im annoyed because I will probably not be able to use it! regards === From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Friday, 22 April 2011 3:23 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Word of warning on freeipa availability On 04/21/2011 04:11 AM, Steven Jones wrote: > Hi, > > > > Anybody contemplating using Free-ipa should check with Redhat sales in their region before getting interested. It seems freeipa wont be sold in all regions, as an example in Asia Pacfic like RDS it may never be sold....or at least it may years away. So without access to the replication/AD sync channel and no support envisaged I would think its of limited use.... > > > I am not sure this is the accurate information. It was true regarding v1 but it most likely will be different with v2. I do not think the information you are commenting on is even shaped internally as the official sales of IPA will start only with 6.2. IPA is in tech preview in 6.1. The access to replication bits is in fact needed via Red Hat contact. I am really not sure what you are trying to say with this post? "IPA is bad, do not use it?" It seems that supporting something requires knowledge and right people. It might be very well possible that Red Hat would not be able to ramp up the right support resources for all geographies day 1. It is the question of time and demand. FreeIPA - community release is available and supported using the standard "best effort" model across the globe. It is unclear what other expectations are not met. > Oops..... > > > > regards > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From kevinu at redhat.com Wed Apr 27 22:31:10 2011 From: kevinu at redhat.com (Kevin Unthank) Date: Wed, 27 Apr 2011 15:31:10 -0700 Subject: [Freeipa-users] Word of warning on freeipa availability In-Reply-To: <833D8E48405E064EBC54C84EC6B36E400CF861@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4DB04BFB.3040208@redhat.com> <833D8E48405E064EBC54C84EC6B36E400CF861@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4DB8992E.3070708@redhat.com> We have no plans to limit the availability of Red Hat supported IPA by geographic region. This applies to both the core packages that are part of RHEL, as well as any add-ons such as replication. For the RHEL6.1 release the functionality is a tech preview. We will not offer full support in any geographic region and access to the replication add-on will require a, no cost, unsupported evaluation entitlement. Anyone with access to the RHEL6.1 beta channel can request the replication add-on from their Red Hat account rep. It is our intention to support all IPA functionality, globally, in the RHEL6.2 time frame. Cheers, Kev (Product Manager for IPA and DS and CS) On 04/21/2011 12:52 PM, Steven Jones wrote: > Hi, > > Im not saying its bad....actually the opposite. > > We looked at RDS 18months ago and I bust a gut trying to get my management interested in buying it....I finally got an agreement but were told by Redhat sales AP that it was no longer being sold as they couldnt support it but to look at freeIPA 2 because this was a great product and would be supported. > > So Ive gone and persuaded my line managers to take a good look at IPA, I get them interested on me doing a POC but AP Sales are now telling me the same thing for IPA as they did RDS....they dont foresee selling it in AP for the foreseeable future if ever....mainly because they tell me they cant support it. Now its possible they dont have a clue...but I cant keep waiting for ever and based on past actions that doesnt seem wise. > > So my point is if someone joins this "open-source" group with the intention of using this next year they should be aware there is a risk it wont be commercially supported by Redhat in their region....so in effect they could be wasting their time. > > In terms of a product Im not saying its rubbish, Im actually so pissed because I think from its overall design, its easy to use and simple interface and to its nuts and bolts it will be a good product and do exactly what we need.....Im annoyed because I will probably not be able to use it! > > regards > > > === > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Friday, 22 April 2011 3:23 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Word of warning on freeipa availability > > On 04/21/2011 04:11 AM, Steven Jones wrote: >> Hi, >> >> >> >> Anybody contemplating using Free-ipa should check with Redhat sales in their region before getting interested. It seems freeipa wont be sold in all regions, as an example in Asia Pacfic like RDS it may never be sold....or at least it may years away. So without access to the replication/AD sync channel and no support envisaged I would think its of limited use.... >> >> >> > > I am not sure this is the accurate information. > It was true regarding v1 but it most likely will be different with v2. > I do not think the information you are commenting on is even shaped > internally as the official sales of IPA will start only with 6.2. IPA is > in tech preview in 6.1. > The access to replication bits is in fact needed via Red Hat contact. > > I am really not sure what you are trying to say with this post? > "IPA is bad, do not use it?" > > It seems that supporting something requires knowledge and right people. > It might be very well possible that Red Hat would not be able to ramp up > the right support resources for all geographies day 1. It is the > question of time and demand. > > FreeIPA - community release is available and supported using the > standard "best effort" model across the globe. > It is unclear what other expectations are not met. > >> Oops..... >> >> >> >> regards >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Thu Apr 28 10:06:55 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 28 Apr 2011 12:06:55 +0200 (CEST) Subject: [Freeipa-users] IPA replication in RHEL In-Reply-To: <4DB8992E.3070708@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4DB04BFB.3040208@redhat.com> <833D8E48405E064EBC54C84EC6B36E400CF861@STAWINCOX10MBX1.staff.vuw.ac.nz> <4DB8992E.3070708@redhat.com> Message-ID: <12737.62.148.39.180.1303985215.squirrel@www.nixtra.com> Hi Kevin, I requested the add-on replication channel from our RH account rep, however I was advised they we're unable to find any IPA Replication channel. Is this channel ready in RHN yet? If so, what is the name of this channel? Rgds, Siggi On Thu, April 28, 2011 00:31, Kevin Unthank wrote: > We have no plans to limit the availability of Red Hat > supported IPA by geographic region. This applies to both the core packages that are part of RHEL, > as well as any add-ons such as replication. > > For the RHEL6.1 release the functionality is a tech preview. > We will not offer full support in any geographic region > and access to the replication add-on will require a, no cost, unsupported evaluation entitlement. > Anyone with access to the RHEL6.1 beta channel can > request the replication add-on from their Red Hat account rep. > > It is our intention to support all IPA functionality, > globally, in the RHEL6.2 time frame. > > Cheers, > Kev (Product Manager for IPA and DS and CS) > > From dpal at redhat.com Thu Apr 28 12:28:38 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 28 Apr 2011 08:28:38 -0400 Subject: [Freeipa-users] IPA replication in RHEL In-Reply-To: <12737.62.148.39.180.1303985215.squirrel@www.nixtra.com> References: <833D8E48405E064EBC54C84EC6B36E400CE4B8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4DB04BFB.3040208@redhat.com> <833D8E48405E064EBC54C84EC6B36E400CF861@STAWINCOX10MBX1.staff.vuw.ac.nz> <4DB8992E.3070708@redhat.com> <12737.62.148.39.180.1303985215.squirrel@www.nixtra.com> Message-ID: <4DB95D76.8010907@redhat.com> On 04/28/2011 06:06 AM, Sigbjorn Lie wrote: > Hi Kevin, > > I requested the add-on replication channel from our RH account rep, however I was advised they > we're unable to find any IPA Replication channel. Is this channel ready in RHN yet? If so, what is > the name of this channel? "Enterprise Identity Replication" > > Rgds, > Siggi > > > > > On Thu, April 28, 2011 00:31, Kevin Unthank wrote: >> We have no plans to limit the availability of Red Hat >> supported IPA by geographic region. This applies to both the core packages that are part of RHEL, >> as well as any add-ons such as replication. >> >> For the RHEL6.1 release the functionality is a tech preview. >> We will not offer full support in any geographic region >> and access to the replication add-on will require a, no cost, unsupported evaluation entitlement. >> Anyone with access to the RHEL6.1 beta channel can >> request the replication add-on from their Red Hat account rep. >> >> It is our intention to support all IPA functionality, >> globally, in the RHEL6.2 time frame. >> >> Cheers, >> Kev (Product Manager for IPA and DS and CS) >> >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kollathodi at yahoo.com Sat Apr 30 06:41:02 2011 From: kollathodi at yahoo.com (nasir nasir) Date: Fri, 29 Apr 2011 23:41:02 -0700 (PDT) Subject: [Freeipa-users] FreeIPA for Linux desktop deployment Message-ID: <764971.44560.qm@web161302.mail.bf1.yahoo.com> Hi All, First of all, many thanks indeed to the developers and community for making some great strides in the open source IPA world ! I am planning for a Linux deployment with the following requirements. ? ?-- About 50 Linux clients running Kubuntu (can change this to ubuntu if necessary)? ?-- Centralized authentication? ?-- Centralized storage with iSCSI for /home folder for each user by means of a dedicated storage? ?-- NO Windows or other users? ?-- Admin should be able to create and modify the accounts of all the users? ?-- Admin should be able to set password policies? ?-- Allocate /home folder for each user from the storage through iSCSI? ?-- Server can be CentOS/RHEL (or even Fedora if absolutely required)? ?-- Any other administration of users if possible ! I was wondering whether FreeIPA makes sense to me in this scenario ? can it satisfy all these or at least some of these ? if not, can anyone suggest me some alternative solutions which are open source ? I am flexible on the requirements and can make modifications if that is required. I would really appreciate any feedback on this. Thanks in advance and regards,Nidal -------------- next part -------------- An HTML attachment was scrubbed... URL: From JR.Aquino at citrix.com Sat Apr 30 16:10:14 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Sat, 30 Apr 2011 16:10:14 +0000 Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <764971.44560.qm@web161302.mail.bf1.yahoo.com> References: <764971.44560.qm@web161302.mail.bf1.yahoo.com> Message-ID: On Apr 29, 2011, at 11:45 PM, "nasir nasir" > wrote: Hi All, First of all, many thanks indeed to the developers and community for making some great strides in the open source IPA world ! I am planning for a Linux deployment with the following requirements. -- About 50 Linux clients running Kubuntu (can change this to ubuntu if necessary) -- Centralized authentication -- Centralized storage with iSCSI for /home folder for each user by means of a dedicated storage -- NO Windows or other users -- Admin should be able to create and modify the accounts of all the users -- Admin should be able to set password policies -- Allocate /home folder for each user from the storage through iSCSI -- Server can be CentOS/RHEL (or even Fedora if absolutely required) -- Any other administration of users if possible ! I was wondering whether FreeIPA makes sense to me in this scenario ? can it satisfy all these or at least some of these ? if not, can anyone suggest me some alternative solutions which are open source ? I am flexible on the requirements and can make modifications if that is required. I would really appreciate any feedback on this. Thanks in advance and regards, Nidal ______________________________ Yes Nidal, you will find that FreeIPA satisfies almost all of these requirements. iSCSI managment is not a feature of FreeIPA. If you are looking to begin now, I would recommend that you start with Fedora as your base server distro. IPA will be available for RHEL as a Feature preview in 6.1 with plans to be fully supported and integrated by 6.2. -JR