From doherty at hkl.hms.harvard.edu Tue Feb 1 17:38:50 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 1 Feb 2011 12:38:50 -0500 Subject: [Freeipa-users] IPA server certificate update and "Directory Manager" password In-Reply-To: <4D38B7E8.4010202@redhat.com> References: <4D38A275.4010908@hkl.hms.harvard.edu> <4D38A89D.4030305@redhat.com> <4D38ACE2.1000303@hkl.hms.harvard.edu> <4D38B7E8.4010202@redhat.com> Message-ID: <70496D57-5A22-4726-AC15-48099BD1008B@hkl.hms.harvard.edu> On Jan 20, 2011, at 17:32 , Rob Crittenden wrote: > > Yes, that was going to be my next question. While throwing any old > self-signed cert in there might get the server up other things won't > work, notably replication. > > Ok, here are some steps I worked out that I think will get you back > in business. I'm going to try to renew your 389-ds certificate using > IPA. > > First we need to get 389-ds back up and running. > > I'm going to use REALM in place of the instance name for your 399-ds > install. > > 1. Make a backup of /etc/dirsrv.slapd-REALM/dse.ldif > 2. Make a backup of your dirsrv NSS database (so /etc/dirsrv/slapd- > REALM/*.db) > 2. Edit dse.ldif and set nsslapd-security to off > 3. Try starting dirsrv: service start dirsrv REALM > 4. Get a kerberos ticket for admin: kinit admin > 5. Generate a new CSR for your directory server: > certutil -R -k 'NSS Certificate DB:Server-Cert' -s 'cn=nebio- > directory.in.hwlab,O=IPA' -d /etc/dirsrv/slapd-REALM/ -f /etc/dirsrv/ > slapd-REALM/pwdfile.txt -a > renew.csr > 6. Get a new certificate: > ipa cert-request renew.csr --principal=ldap/nebio-directory.in.hwlab > > 7. Paste the value in the output for Certificate into a file. This > is a base64-encoded blob of text probably starting with MII and > ending with ==. > 8. Add this new cert to your 389-ds database > certutil -A -d /etc/dirsrv/slapd-REALM -n Server-Cert -t u,u,u -a < > cert.txt > 9. service dirsrv stop REALM > 10. edit dse.ldif and set nsslapd-security to on > 11. service dirsrv start REALM > > I ran the majority of these steps against my own IPA installation > and nothing caught on fire. I hope you have equal success. Rob, any more advice on this? Step 5 fails, but it works if I remove the "NSS Cert...." part or of I use "IPA..." something or other that I figured out. But then step 6 fails, I get a "No Modification Requried" result when I run the command, and nothing I did could get past that. If I want to start from scratch with the new Beta release, how would I dump the entire LDAP/KRB database so that I could import it into a new server? The Docs mention doing regular backups, but they don't even tell how to backup the data, whether to backups files (which ones?!) or to dump the data into a file, and backup that. Can I convert from the 1.9 alpha to a 2.0beta freeipa instance? Best, Peter From doherty at hkl.hms.harvard.edu Tue Feb 1 19:30:03 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 1 Feb 2011 14:30:03 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host Message-ID: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> I hope someone can help with this. I've got a freeipa server running the 1.9 alpha release. It's broken, (the x509 cert expired and can't be renewed) and I want to just abandon it. I set up a new host and installed the 2.0 beta release (from the git archives, because the regular archive includes a broken version, it won't install) Is there anyway to get all the user data, passwords, groups, automount maps, etc...from the old freeipa server on to the new one? Thanks! Peter From dpal at redhat.com Tue Feb 1 19:43:23 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 01 Feb 2011 14:43:23 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> Message-ID: <4D48625B.2070807@redhat.com> On 02/01/2011 02:30 PM, Peter Doherty wrote: > I hope someone can help with this. > I've got a freeipa server running the 1.9 alpha release. > It's broken, (the x509 cert expired and can't be renewed) and I want > to just abandon it. > > I set up a new host and installed the 2.0 beta release (from the git > archives, because the regular archive includes a broken version, it > won't install) > Is there anyway to get all the user data, passwords, groups, automount > maps, etc...from the old freeipa server on to the new one? > Is it Ok to reset all passwords or you want to try to preserve those? > Thanks! > > Peter > > _______________________________________________ > 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 doherty at hkl.hms.harvard.edu Tue Feb 1 19:51:20 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 1 Feb 2011 14:51:20 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D48625B.2070807@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> Message-ID: <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> On Feb 1, 2011, at 14:43 , Dmitri Pal wrote: > On 02/01/2011 02:30 PM, Peter Doherty wrote: >> I hope someone can help with this. >> I've got a freeipa server running the 1.9 alpha release. >> It's broken, (the x509 cert expired and can't be renewed) and I want >> to just abandon it. >> >> I set up a new host and installed the 2.0 beta release (from the git >> archives, because the regular archive includes a broken version, it >> won't install) >> Is there anyway to get all the user data, passwords, groups, >> automount >> maps, etc...from the old freeipa server on to the new one? >> > Is it Ok to reset all passwords or you want to try to preserve those? > I want to preserve them. But at this point, i'd take just about anything. I just discovered the "migrate-ds" tool. But I can't make it work. Peter From dpal at redhat.com Tue Feb 1 20:00:55 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 01 Feb 2011 15:00:55 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> Message-ID: <4D486677.1060805@redhat.com> On 02/01/2011 02:51 PM, Peter Doherty wrote: > > On Feb 1, 2011, at 14:43 , Dmitri Pal wrote: > >> On 02/01/2011 02:30 PM, Peter Doherty wrote: >>> I hope someone can help with this. >>> I've got a freeipa server running the 1.9 alpha release. >>> It's broken, (the x509 cert expired and can't be renewed) and I want >>> to just abandon it. >>> >>> I set up a new host and installed the 2.0 beta release (from the git >>> archives, because the regular archive includes a broken version, it >>> won't install) >>> Is there anyway to get all the user data, passwords, groups, automount >>> maps, etc...from the old freeipa server on to the new one? >>> >> Is it Ok to reset all passwords or you want to try to preserve those? >> > > > I want to preserve them. > > But at this point, i'd take just about anything. > > I just discovered the "migrate-ds" tool. But I can't make it work. > 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 May be the writeup will help. It is not final but at least this portion has been reviewed. > Peter > > _______________________________________________ > 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 doherty at crystal.harvard.edu Tue Feb 1 19:51:06 2011 From: doherty at crystal.harvard.edu (Peter Doherty) Date: Tue, 1 Feb 2011 14:51:06 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D48625B.2070807@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> Message-ID: <5AFBF536-0F35-4962-B5F3-881A461D18ED@crystal.harvard.edu> On Feb 1, 2011, at 14:43 , Dmitri Pal wrote: > On 02/01/2011 02:30 PM, Peter Doherty wrote: >> I hope someone can help with this. >> I've got a freeipa server running the 1.9 alpha release. >> It's broken, (the x509 cert expired and can't be renewed) and I want >> to just abandon it. >> >> I set up a new host and installed the 2.0 beta release (from the git >> archives, because the regular archive includes a broken version, it >> won't install) >> Is there anyway to get all the user data, passwords, groups, >> automount >> maps, etc...from the old freeipa server on to the new one? >> > Is it Ok to reset all passwords or you want to try to preserve those? > I want to preserve them. But at this point, i'd take just about anything. I just discovered the "migrate-ds" tool. But I can't make it work. Peter From ssorce at redhat.com Tue Feb 1 20:01:25 2011 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 1 Feb 2011 15:01:25 -0500 Subject: [Freeipa-users] IPA server certificate update and "Directory Manager" password In-Reply-To: <70496D57-5A22-4726-AC15-48099BD1008B@hkl.hms.harvard.edu> References: <4D38A275.4010908@hkl.hms.harvard.edu> <4D38A89D.4030305@redhat.com> <4D38ACE2.1000303@hkl.hms.harvard.edu> <4D38B7E8.4010202@redhat.com> <70496D57-5A22-4726-AC15-48099BD1008B@hkl.hms.harvard.edu> Message-ID: <20110201150125.25dedbc8@willson.li.ssimo.org> On Tue, 1 Feb 2011 12:38:50 -0500 Peter Doherty wrote: > If I want to start from scratch with the new Beta release, how would > I dump the entire LDAP/KRB database so that I could import it into a > new server? > The Docs mention doing regular backups, but they don't even tell how > to backup the data, whether to backups files (which ones?!) or to > dump the data into a file, and backup that. database dumps + filesystem backups > Can I convert from the 1.9 alpha to a 2.0beta freeipa instance? Not easy, and it depends on what you mean by convert. A simple rpm update will give you issues because we still made minor changes to the DIT and schema between the 1.9 alpha and the beta. If you have many keys in your kerberos database I can describe a procedure that *should* work to dump the keys and reload them in a new server where you manually/script migrate the users/host/services data by using the ipa user-add/host-add/srvice-add commands. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Tue Feb 1 20:00:33 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 01 Feb 2011 13:00:33 -0700 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> Message-ID: <4D486661.1050406@redhat.com> On 02/01/2011 12:51 PM, Peter Doherty wrote: > > On Feb 1, 2011, at 14:43 , Dmitri Pal wrote: > >> On 02/01/2011 02:30 PM, Peter Doherty wrote: >>> I hope someone can help with this. >>> I've got a freeipa server running the 1.9 alpha release. >>> It's broken, (the x509 cert expired and can't be renewed) and I want >>> to just abandon it. >>> >>> I set up a new host and installed the 2.0 beta release (from the git >>> archives, because the regular archive includes a broken version, it >>> won't install) >>> Is there anyway to get all the user data, passwords, groups, automount >>> maps, etc...from the old freeipa server on to the new one? >>> >> Is it Ok to reset all passwords or you want to try to preserve those? >> > > > I want to preserve them. > > But at this point, i'd take just about anything. > > I just discovered the "migrate-ds" tool. But I can't make it work. That definitely won't work. migrate-ds is used to migrate very old 389-ds-base servers to the latest version. There is no tool to migrate/upgrade from an ipa alpha release to an ipa beta release. > > Peter > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Tue Feb 1 20:02:19 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 01 Feb 2011 15:02:19 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D486661.1050406@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486661.1050406@redhat.com> Message-ID: <4D4866CB.8080308@redhat.com> On 02/01/2011 03:00 PM, Rich Megginson wrote: > On 02/01/2011 12:51 PM, Peter Doherty wrote: >> >> On Feb 1, 2011, at 14:43 , Dmitri Pal wrote: >> >>> On 02/01/2011 02:30 PM, Peter Doherty wrote: >>>> I hope someone can help with this. >>>> I've got a freeipa server running the 1.9 alpha release. >>>> It's broken, (the x509 cert expired and can't be renewed) and I want >>>> to just abandon it. >>>> >>>> I set up a new host and installed the 2.0 beta release (from the git >>>> archives, because the regular archive includes a broken version, it >>>> won't install) >>>> Is there anyway to get all the user data, passwords, groups, automount >>>> maps, etc...from the old freeipa server on to the new one? >>>> >>> Is it Ok to reset all passwords or you want to try to preserve those? >>> >> >> >> I want to preserve them. >> >> But at this point, i'd take just about anything. >> >> I just discovered the "migrate-ds" tool. But I can't make it work. > That definitely won't work. migrate-ds is used to migrate very old > 389-ds-base servers to the latest version. There is no tool to > migrate/upgrade from an ipa alpha release to an ipa beta release. It might work. It will just loose the keys. > >> >> Peter >> >> _______________________________________________ >> 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 dpal at redhat.com Tue Feb 1 20:04:47 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 01 Feb 2011 15:04:47 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D486677.1060805@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> Message-ID: <4D48675F.4080802@redhat.com> On 02/01/2011 03:00 PM, Dmitri Pal wrote: > On 02/01/2011 02:51 PM, Peter Doherty wrote: >> On Feb 1, 2011, at 14:43 , Dmitri Pal wrote: >> >>> On 02/01/2011 02:30 PM, Peter Doherty wrote: >>>> I hope someone can help with this. >>>> I've got a freeipa server running the 1.9 alpha release. >>>> It's broken, (the x509 cert expired and can't be renewed) and I want >>>> to just abandon it. >>>> >>>> I set up a new host and installed the 2.0 beta release (from the git >>>> archives, because the regular archive includes a broken version, it >>>> won't install) >>>> Is there anyway to get all the user data, passwords, groups, automount >>>> maps, etc...from the old freeipa server on to the new one? >>>> >>> Is it Ok to reset all passwords or you want to try to preserve those? >>> >> >> I want to preserve them. >> >> But at this point, i'd take just about anything. >> >> I just discovered the "migrate-ds" tool. But I can't make it work. >> > 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 > > May be the writeup will help. It is not final but at least this portion > has been reviewed. > Also it is worth mentioning that we are planning to come up with Beta 2 later this week so may be it makes sense to wait couple days and move to the latest bits. >> Peter >> >> _______________________________________________ >> 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 doherty at hkl.hms.harvard.edu Wed Feb 2 03:30:50 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 1 Feb 2011 22:30:50 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D48675F.4080802@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> Message-ID: <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: > > Also it is worth mentioning that we are planning to come up with Beta 2 > later this week so may be it makes sense to wait couple days and move to > the latest bits. Can I upgrade from Beta-1 to Beta-2, or are they incompatible? Peter From ssorce at redhat.com Wed Feb 2 14:09:42 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 2 Feb 2011 09:09:42 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> Message-ID: <20110202090942.5119a44c@willson.li.ssimo.org> On Tue, 1 Feb 2011 22:30:50 -0500 Peter Doherty wrote: > > On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: > > > > Also it is worth mentioning that we are planning to come up with > > Beta 2 later this week so may be it makes sense to wait couple days > > and move to the latest bits. > > Can I upgrade from Beta-1 to Beta-2, or are they incompatible? There are small incompatibilities, some new schema and some changes to the DIT. Simo. -- Simo Sorce * Red Hat, Inc * New York From doherty at hkl.hms.harvard.edu Wed Feb 2 14:28:38 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Wed, 2 Feb 2011 09:28:38 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <20110202090942.5119a44c@willson.li.ssimo.org> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> Message-ID: <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> On Feb 2, 2011, at 09:09 , Simo Sorce wrote: > On Tue, 1 Feb 2011 22:30:50 -0500 > Peter Doherty wrote: > >> >> On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: >>> >>> Also it is worth mentioning that we are planning to come up with >>> Beta 2 later this week so may be it makes sense to wait couple days >>> and move to the latest bits. >> >> Can I upgrade from Beta-1 to Beta-2, or are they incompatible? > > There are small incompatibilities, some new schema and some changes to > the DIT. > So you can't upgrade from 1.2 to 1.9 and you can't go from 1.9 to 2.0 and you can't go from 2.0 beta-1 to 2.0 beta-2? So why would I want to use a product like that? Peter From dpal at redhat.com Wed Feb 2 14:46:37 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 02 Feb 2011 09:46:37 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> Message-ID: <4D496E4D.8080304@redhat.com> On 02/02/2011 09:28 AM, Peter Doherty wrote: > On Feb 2, 2011, at 09:09 , Simo Sorce wrote: > >> On Tue, 1 Feb 2011 22:30:50 -0500 >> Peter Doherty wrote: >> >>> On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: >>>> Also it is worth mentioning that we are planning to come up with >>>> Beta 2 later this week so may be it makes sense to wait couple days >>>> and move to the latest bits. >>> Can I upgrade from Beta-1 to Beta-2, or are they incompatible? >> There are small incompatibilities, some new schema and some changes to >> the DIT. >> > So you can't upgrade from 1.2 to 1.9 and you can't go from 1.9 to 2.0 > and you can't go from 2.0 beta-1 to 2.0 beta-2? > > So why would I want to use a product like that? The version 1.2 is the version that had very limited functionality. When we started working on v2 it became apparent that we will not be able to maintain backward compatibility and the migration from IPA v1 to V2 will be similar to migration for a different LDAP server. Out goal for v2 and beyond to be compatible and to allow smooth migration. However this means that we need to fix as many schema inconstancies and data storage issues before we release v2 otherwise we will be stuck with those forever. This means that the schema is changing in the beta cycle to address issues we find. It is really unfortunate that you are caught in this situation. We are on the verge of releasing beta 2 so everybody is head down fixing issues. We will try to carve some time to come up with a better strategy for you next week if that would help so that you can move to beta2. We hear your frustration and really sorry about the bad experience you have with the project. Thank you Dmitri > Peter > > > _______________________________________________ > 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 ssorce at redhat.com Wed Feb 2 15:10:05 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 2 Feb 2011 10:10:05 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> Message-ID: <20110202101005.3a6af851@willson.li.ssimo.org> On Wed, 2 Feb 2011 09:28:38 -0500 Peter Doherty wrote: > > On Feb 2, 2011, at 09:09 , Simo Sorce wrote: > > > On Tue, 1 Feb 2011 22:30:50 -0500 > > Peter Doherty wrote: > > > >> > >> On Feb 1, 2011, at 15:04 , Dmitri Pal wrote: > >>> > >>> Also it is worth mentioning that we are planning to come up with > >>> Beta 2 later this week so may be it makes sense to wait couple > >>> days and move to the latest bits. > >> > >> Can I upgrade from Beta-1 to Beta-2, or are they incompatible? > > > > There are small incompatibilities, some new schema and some changes > > to the DIT. > > > > So you can't upgrade from 1.2 to 1.9 and you can't go from 1.9 to 2.0 > and you can't go from 2.0 beta-1 to 2.0 beta-2? > > So why would I want to use a product like that? Upgrades will be possible within stable releases. Handling upgrades in development versions would cost too much development time w/o any real benefit as schema and DIT will be fixed in stone once 2.0 final will be released. Alpha and Beta release are not meant for production but only for testing environments. Simo. -- Simo Sorce * Red Hat, Inc * New York From ijstokes at hkl.hms.harvard.edu Wed Feb 2 17:30:16 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 02 Feb 2011 12:30:16 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <20110202101005.3a6af851@willson.li.ssimo.org> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> Message-ID: <4D4994A8.5060409@hkl.hms.harvard.edu> >> So you can't upgrade from 1.2 to 1.9 and you can't go from 1.9 to 2.0 >> and you can't go from 2.0 beta-1 to 2.0 beta-2? >> >> So why would I want to use a product like that? > Upgrades will be possible within stable releases. > > Handling upgrades in development versions would cost too much > development time w/o any real benefit as schema and DIT will be fixed > in stone once 2.0 final will be released. > > Alpha and Beta release are not meant for production but only for > testing environments. Hi, I'm part of the same team that is stuck in this situation. I think you guys (FreeIPA team) need to make it really clear to current adopters that they are going to have to start from scratch if they go with the current v2 releases (1.9, 2.0-beta, etc.) and want to "upgrade" later. Of course there is no definition of what "beta" means, but really I think we're your *ideal* beta testers and you should put in some effort to make it possible for us to use the beta releases of FreeIPA. We are a research computing group, so our service level standards are "we can live with a 24-36 hours of down time M-F every couple of months, and 1 week of down time every year". We have a handful of real users, want to integrate apache httpd into using LDAP, want to utilize the web i/f for account management, use FreeIPA for NFS mounts, "real" X.509 certificates, etc. Even if an automated/smooth transition between beta versions or from beta to final release is impossible, then some guidance on strategies to transition systems "manually" (and a very rough estimate of the time commitment to do that) would be useful. I wish I understood LDAP better, but I don't see why we cant just dump the current FreeIPA LDIF files, tweak the entries as necessary, and import them to the latest version of FreeIPA. We're pretty close right now (as in, the next 4-24 hours) of abandoning FreeIPA, so some encouraging words on this front could make a difference and keep us with you. Ian -- Ian Stokes-Rees, PhD W: http://portal.nebiogrid.org ijstokes at hkl.hms.harvard.edu T: +1.617.432.5608 x75 NEBioGrid, Harvard Medical School C: +1.617.331.5993 -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From dpal at redhat.com Wed Feb 2 19:13:50 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 02 Feb 2011 14:13:50 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D4994A8.5060409@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> Message-ID: <4D49ACEE.4030705@redhat.com> On 02/02/2011 12:30 PM, Ian Stokes-Rees wrote: >>> So you can't upgrade from 1.2 to 1.9 and you can't go from 1.9 to 2.0 >>> and you can't go from 2.0 beta-1 to 2.0 beta-2? >>> >>> So why would I want to use a product like that? >> Upgrades will be possible within stable releases. >> >> Handling upgrades in development versions would cost too much >> development time w/o any real benefit as schema and DIT will be fixed >> in stone once 2.0 final will be released. >> >> Alpha and Beta release are not meant for production but only for >> testing environments. > Hi, > > I'm part of the same team that is stuck in this situation. I think you > guys (FreeIPA team) need to make it really clear to current adopters > that they are going to have to start from scratch if they go with the > current v2 releases (1.9, 2.0-beta, etc.) and want to "upgrade" later. It is our mistake that we did not realize that there is an expectation that there will be an easy migration between alphas and betas. We always thought of them as of preparation steps for the actual release and that none would try to use them in producution or load data that would be someothing other than a test set. So expectation was that no migration would be needed. This is why your situation caught us by surprise. I guess you had a lot of faith in the project and this is great. I also completely understand your frustration and desire to abandon it in the current situation. I think it would be mutually beneficial to avoid that and find a solution that would help you to move on. Yes you are ideal testers and we want to continue working with you. We also ask for understanding that such migration requirement was not expected on our side. We reinstall the system every day and run tests with new functionality on a fresh system. During last month between previous beta the team addressed more than 200 issues across the whole project. Some major issues have been addressed that required schema changes. We are planning to release IPA beta2 today or tomorrow this is why we are little bit less responsive than we want to be. But this is all lyrics. The main issue with the migration between betas (as in any case) is passwords and keys. Simo knows the details but in a nutshell the problem is that if you dump and load the LDIF (even if you adjust the records to accommodate schema changes manually) your keys would not match. You need to carry the master key over and may be more than that. We need to sit down and think through the recommendations for a manual procedure like this. We will try to do it ASAP but given that we are releasing any day now it is not realistic to expect it happening today. Can this wait till next week? If not it would be a real pity. We are working hard to deliver the project to research groups like yours and we will do our best to help you to migrate your data forward. To reduce the scope of the effort let me recap the goal: 1) You want to install IPA and load the users (is there anything else?) from the previous installation and abandon the old installation 2) You do not want to loose passwords 3) You are Ok with manual procedure 4) You are Ok to try different approaches (some of which might not work out) and work with us on formulating a procedure that would help other deployments like yours to overcome this situation. Again sorry for all the trouble. If we knew the requirement to be able to migrate between betas earlier we might have done some things differently. Hope to find understanding on your side and willingness to work with us on a solution. Thank you Dmitri > Of course there is no definition of what "beta" means, but really I > think we're your *ideal* beta testers and you should put in some effort > to make it possible for us to use the beta releases of FreeIPA. We are > a research computing group, so our service level standards are "we can > live with a 24-36 hours of down time M-F every couple of months, and 1 > week of down time every year". We have a handful of real users, want to > integrate apache httpd into using LDAP, want to utilize the web i/f for > account management, use FreeIPA for NFS mounts, "real" X.509 > certificates, etc. Even if an automated/smooth transition between beta > versions or from beta to final release is impossible, then some guidance > on strategies to transition systems "manually" (and a very rough > estimate of the time commitment to do that) would be useful. > > I wish I understood LDAP better, but I don't see why we cant just dump > the current FreeIPA LDIF files, tweak the entries as necessary, and > import them to the latest version of FreeIPA. > > We're pretty close right now (as in, the next 4-24 hours) of abandoning > FreeIPA, so some encouraging words on this front could make a difference > and keep us with you. > > Ian > > > > _______________________________________________ > 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 ijstokes at hkl.hms.harvard.edu Wed Feb 2 21:02:58 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 02 Feb 2011 16:02:58 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D49ACEE.4030705@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> Message-ID: <4D49C682.2090406@hkl.hms.harvard.edu> > > Can this wait till next week? If not it would be a real pity. We are > working hard to deliver the project to research groups like yours and > we will do our best to help you to migrate your data forward. We will probably decide what path to take tomorrow. I'm not sure if we're prepared to wait, since waiting 1 week will probably only get us using the new Beta-2, and won't solve any problems for Beta-3 or official release of 2.0. > To reduce the scope of the effort let me recap the goal: > 1) You want to install IPA and load the users (is there anything > else?) from the previous installation and abandon the old installation I'm not sure the details of everything that is in FreeIPA, but I think right now it is at least user information and NFS mounts. Possible more. We have 10-20 accounts, so not much. > 2) You do not want to loose passwords I don't really care about this. We can loose all passwords as far as I'm concerned. Peter, the other person who has been on this thread and the one who has done all the work, may have a different opinion. > 3) You are Ok with manual procedure > 4) You are Ok to try different approaches (some of which might not > work out) and work with us on formulating a procedure that would help > other deployments like yours to overcome this situation. Yes, we're OK to try manual procedures and different approaches, *if* we decide it is worth sticking with FreeIPA. > Again sorry for all the trouble. If we knew the requirement to be able > to migrate between betas earlier we might have done some things > differently. > Hope to find understanding on your side and willingness to work with > us on a solution. How did you expect anyone to seriously try to use FreeIPA if they couldn't migrate between versions? Surely installation and extended use (weeks/months) by non-developers is part of any beta-testing plan. Regards, Ian -- Ian Stokes-Rees, PhD W: http://portal.nebiogrid.org ijstokes at hkl.hms.harvard.edu T: +1.617.432.5608 x75 NEBioGrid, Harvard Medical School C: +1.617.331.5993 -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From dpal at redhat.com Wed Feb 2 21:23:54 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 02 Feb 2011 16:23:54 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D49C682.2090406@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> Message-ID: <4D49CB6A.5050407@redhat.com> On 02/02/2011 04:02 PM, Ian Stokes-Rees wrote: >> Can this wait till next week? If not it would be a real pity. We are >> working hard to deliver the project to research groups like yours and >> we will do our best to help you to migrate your data forward. > We will probably decide what path to take tomorrow. I'm not sure if > we're prepared to wait, since waiting 1 week will probably only get us > using the new Beta-2, and won't solve any problems for Beta-3 or > official release of 2.0. > >> To reduce the scope of the effort let me recap the goal: >> 1) You want to install IPA and load the users (is there anything >> else?) from the previous installation and abandon the old installation > I'm not sure the details of everything that is in FreeIPA, but I think > right now it is at least user information and NFS mounts. Possible > more. We have 10-20 accounts, so not much. NFS mount schema is the same and standard 2307bis so there is no difference between the versions. The only issue can be the location of the container since we did some rearrangement of the tree recently. But there is no crypto or hashes there so dumping the cn=automount and loading it into the new version should be straightforward exercise. For the users migrate-ds should be used then. It will take user accounts from the old installation and move to the new one. If you use SSSD on the client in the migration mode then it will recreated migrated kerberos hashes behind the scenes as soon as you log into a client machine using SSSD after migration. If migrate-ds does not work for you then we need to know all the details and logs of what went wrong so that we can fix the issue. >> 2) You do not want to loose passwords > I don't really care about this. We can loose all passwords as far as > I'm concerned. Peter, the other person who has been on this thread and > the one who has done all the work, may have a different opinion. The procedure described above, i.e. using SSSD on the client will solve the problem of the password migration if you care. >> 3) You are Ok with manual procedure >> 4) You are Ok to try different approaches (some of which might not >> work out) and work with us on formulating a procedure that would help >> other deployments like yours to overcome this situation. > Yes, we're OK to try manual procedures and different approaches, *if* we > decide it is worth sticking with FreeIPA. This is your decision to make. >> Again sorry for all the trouble. If we knew the requirement to be able >> to migrate between betas earlier we might have done some things >> differently. >> Hope to find understanding on your side and willingness to work with >> us on a solution. > How did you expect anyone to seriously try to use FreeIPA if they > couldn't migrate between versions? Surely installation and extended use > (weeks/months) by non-developers is part of any beta-testing plan. > They are not "migratable" versions. Frankly I have not heard of any product of such complexity that would support migration between the alpha-beta-rc drops. Sorry but your expectation is wrong. It is our fault that we have not clearly stated it but this is the case. And yes, just to set expectations straight, when we release IPA v2 we expect it to be a fresh install and users migrated to it using migrate-ds and passwords migrated using SSSD or a special migration page we provide. Other parts of the tree can be migrated piecemeal and we will be happy to help you do it if migrating this part of information is possible. For example migrating hosts and service will not be possible but sudo, HBAC, DNS etc. will be, so discretion should be used depending upon what you have in your deployment. However if we are talking about 10-20 accounts it might be easier to recreate them manually or with a simple script. Overall we appreciate your business and would be glad to help within the reasonable expectations. Thank you, Dmitri > Regards, > > Ian > > > > _______________________________________________ > 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 natxo.asenjo at gmail.com Wed Feb 2 21:35:45 2011 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 2 Feb 2011 22:35:45 +0100 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D49C682.2090406@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> Message-ID: On Wed, Feb 2, 2011 at 10:02 PM, Ian Stokes-Rees wrote: > How did you expect anyone to seriously try to use FreeIPA if they > couldn't migrate between versions? ?Surely installation and extended use > (weeks/months) by non-developers is part of any beta-testing plan. If you read the release notes (http://freeipa.org/page/IPAv2_beta), in the paragraph 'migration' it is quite clearly stated that migration from v1 to v2 of freeipa is not possible. You are right that it is not clearly stated that migrations between 1.9.whatever and 2 are not possible but ... ... as a sysadmin, whenever I read 'alpha|beta', all alarms go off :-). I do follow the project, but I would never run any kind of production on it just yet. I think that blaming redhat for your using a beta version of software in production is a bit harsh. I understand you are under stress and upset, but this was not supposed to be running in a production environment. Do not blame redhat for something that clearly is not their fault. This project is going to be awesome for unix networks. All the pieces of the puzzle were out there, but these guys are putting them together in a nice package. Having dealt with a share of ldap+kerberos environments, I can tell you this is it. It is not there yet, but it is getting there. It is your choice to not use it. -- groeten, natxo From jgalipea at redhat.com Wed Feb 2 21:59:52 2011 From: jgalipea at redhat.com (Jenny Galipeau) Date: Wed, 02 Feb 2011 16:59:52 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> Message-ID: <4D49D3D8.1010301@redhat.com> Thank you Natxo. We are working hard to get it there and when we do .. it will awesome! Jenny Natxo Asenjo wrote: > On Wed, Feb 2, 2011 at 10:02 PM, Ian Stokes-Rees > wrote: > > >> How did you expect anyone to seriously try to use FreeIPA if they >> couldn't migrate between versions? Surely installation and extended use >> (weeks/months) by non-developers is part of any beta-testing plan. >> > > If you read the release notes (http://freeipa.org/page/IPAv2_beta), in > the paragraph 'migration' it is quite clearly stated that migration from > v1 to v2 of freeipa is not possible. You are right that it is not > clearly stated that migrations between 1.9.whatever and 2 are not > possible but ... > > ... as a sysadmin, whenever I read 'alpha|beta', all alarms go off > :-). I do follow the project, but I would never run any kind of > production on it just yet. > > I think that blaming redhat for your using a beta version of software in > production is a bit harsh. I understand you are under stress and upset, > but this was not supposed to be running in a production environment. Do > not blame redhat for something that clearly is not their fault. > > This project is going to be awesome for unix networks. All the pieces of > the puzzle were out there, but these guys are putting them together in a > nice package. Having dealt with a share of ldap+kerberos environments, I > can tell you this is it. It is not there yet, but it is getting there. > > It is your choice to not use it. > > -- > groeten, > natxo > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Jenny Galipeau Principal Software QA Engineer Red Hat, Inc. Security Engineering Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ From ijstokes at hkl.hms.harvard.edu Wed Feb 2 22:15:19 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 02 Feb 2011 17:15:19 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> Message-ID: <4D49D777.8070807@hkl.hms.harvard.edu> > ... as a sysadmin, whenever I read 'alpha|beta', all alarms go off > :-). I do follow the project, but I would never run any kind of > production on it just yet. Our whole group thinks FreeIPA looks really exciting. We really do *want* to use it. We want the project to succeed, and we'd be happy to be part of the (non-developer) community that helps get you guys there. We are just disappointed that right now it doesn't look like we can stick with you to make this happen, which is particularly frustrating because we've invested a lot of time (at least several weeks at this point) into getting to know and use FreeIPA. We have 4 active users, and about a dozen others. This is part of a research computing cluster infrastructure and does not hold "home" directories for anyone (no mail, no critical files, etc). As I've said, it seems like we have an ideal environment for "beta" testing. Are you only planning on testing version migration/upgrade abilities in the final release? Or perhaps there is a very long road of "beta" versions that will come out over the next several years before a final 2.0 release appears. It did not seem unreasonable for us to assume that some kind of migration capability would be part of (at least) the beta releases. > I think that blaming redhat for your using a beta version of software in > production is a bit harsh. I understand you are under stress and upset, We're not blaming the FreeIPA team. We are surprised that for such a significant project where clearly so much time and work *has* been invested (even into things like documentation) that something so critical as migration didn't get more attention sooner. I appreciate the issues that arise with developing good schemas, and the complexities of being able to translate data between different schemas. The backup plan I'm now considering (but it isn't just my decision) is OpenLDAP or Dir-389 + WebMin + UserMin (not sure if Dir-389 will work well with WebMin LDAP module). Cheers, Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From sgallagh at redhat.com Thu Feb 3 13:01:13 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 03 Feb 2011 08:01:13 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D49D777.8070807@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> <4D49D777.8070807@hkl.hms.harvard.edu> Message-ID: <4D4AA719.5030908@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/02/2011 05:15 PM, Ian Stokes-Rees wrote: > Or perhaps there is a very long road of "beta" versions > that will come out over the next several years before a final 2.0 > release appears. > While I can't comment on the final release schedule for FreeIPA v2, I would like to point you at http://fedoraproject.org/wiki/Features/FreeIPAv2 What you should take away from this is that FreeIPA v2 is expected to be feature-complete by the Fedora 15 Feature Freeze date (February 8th) and must be in its final state by March 22nd in order to be released in Fedora 15. So it's probably safe to assume that 2.0 is not "several years" away. I'd say we're looking at weeks, not months or years at this point. - -- 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/ iEYEARECAAYFAk1KpxkACgkQeiVVYja6o6O8cgCfZANts75bzbj6A5NVYsVtfAi1 2FsAn3sAhotQ/ehHQ6wJ3jgSXEhQoUbv =3uiC -----END PGP SIGNATURE----- From ijstokes at hkl.hms.harvard.edu Thu Feb 3 15:29:25 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Thu, 03 Feb 2011 10:29:25 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D4AA719.5030908@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> <4D49D777.8070807@hkl.hms.harvard.edu> <4D4AA719.5030908@redhat.com> Message-ID: <4D4AC9D5.5000403@hkl.hms.harvard.edu> An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Thu Feb 3 15:35:10 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 03 Feb 2011 10:35:10 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D4AC9D5.5000403@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> <4D49D777.8070807@hkl.hms.harvard.edu> <4D4AA719.5030908@redhat.com> <4D4AC9D5.5000403@hkl.hms.harvard.edu> Message-ID: <4D4ACB2E.7000905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/03/2011 10:29 AM, Ian Stokes-Rees wrote: > >> While I can't comment on the final release schedule for FreeIPA v2, I >> would like to point you at >> http://fedoraproject.org/wiki/Features/FreeIPAv2 >> >> What you should take away from this is that FreeIPA v2 is expected to be >> feature-complete by the Fedora 15 Feature Freeze date (February 8th) and >> must be in its final state by March 22nd in order to be released in >> Fedora 15. So it's probably safe to assume that 2.0 is not "several >> years" away. I'd say we're looking at weeks, not months or years at this >> point. > > Thanks for that link. I see: > > * Targeted release: Fedora 15 > > * Last updated: 01/12/11 > * Percentage of completion: 80% > > In a way, I find this even more worrying since it sounds like FreeIPA > will either be pushed out too early (can schema migration be left out, > or be implemented but untested?) or will miss Fedora 15 and we won't see > it until Fedora 16 (end of summer or autumn). - From the earlier points of the discussion, schema migration is planned for upgrades from 2.0.0 to future versions. It's only something that was left out of the alpha/beta process because things were still in churn and those releases were never intended to be in production. Once 2.0.0 is baked, obviously the upgrade path will need to be clean. > > I don't see how something as fundamental as a directory server can be > mostly finalized (feature freeze, and bug fix only state) in a few weeks > when the developers themselves say "we reset our FreeIPA DS from scratch > every day", suggesting that no one (?) has tested it in an operational > state with real users and systems for an extended period (at least days, > but really for weeks or more). If you think one frustrated group (us) > right now is annoying, just wait to see what happens if FreeIPA v2.0 > *does* go out with Fedora 15 in a few months and lots of people eagerly > install it only to discover in the following months that it wasn't ready > or that they can't upgrade/migrate their DS contents. > Feature freeze means that FreeIPA will not be adding new functionality after this point (which includes schema changes) and will be focusing only on stability and bugfixes until final release. > Ian > > As a postscript, a few weeks ago FreeIPA had 20% left to complete before > v2.0 was ready. Even if we are kind and estimate that this last 20% > will take only 20% of the effort (rather than 80% which we're all > familiar with is much more common by the 80/20 rule) it would suggest > that about 2 months are required to complete it. Does it suggest that > everything that has ever been done to produce FreeIPA v2.0 has been done > in the past 10 months (starting March 2010)? Or has the team working on > it grown substantially over the past year? That 80% is the amount of Fedora-related effort, not the upstream completion effort. It hasn't been updated, but I'd ballpark us at nearly about 95% now. - -- 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/ iEYEARECAAYFAk1Kyy4ACgkQeiVVYja6o6MuZACfXboYMLY9Ur/Qai2xxkId5/xe OvUAmgJdwxG0aKHQKPRsiZ0lLb3HINBQ =H6hd -----END PGP SIGNATURE----- From doherty at hkl.hms.harvard.edu Thu Feb 3 15:51:29 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Thu, 3 Feb 2011 10:51:29 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D4ACB2E.7000905@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> <4D49D777.8070807@hkl.hms.harvard.edu> <4D4AA719.5030908@redhat.com> <4D4AC9D5.5000403@hkl.hms.harvard.edu> <4D4ACB2E.7000905@redhat.com> Message-ID: <32A11848-7A9F-44A7-B111-FEB8FC72D299@hkl.hms.harvard.edu> On Feb 3, 2011, at 10:35 , Stephen Gallagher wrote: > > - From the earlier points of the discussion, schema migration is > planned > for upgrades from 2.0.0 to future versions. It's only something that > was > left out of the alpha/beta process because things were still in churn > and those releases were never intended to be in production. Once 2.0.0 > is baked, obviously the upgrade path will need to be clean. Is there a plan to include the ability for users of 1.2 to migrate to 2.0? I'd consider setting up and using 1.2 right now if I know that I can migrate to 2.0 when the stable release comes out. -Peter From dpal at redhat.com Thu Feb 3 16:41:07 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Feb 2011 11:41:07 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <32A11848-7A9F-44A7-B111-FEB8FC72D299@hkl.hms.harvard.edu> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> <4D49D777.8070807@hkl.hms.harvard.edu> <4D4AA719.5030908@redhat.com> <4D4AC9D5.5000403@hkl.hms.harvard.edu> <4D4ACB2E.7000905@redhat.com> <32A11848-7A9F-44A7-B111-FEB8FC72D299@hkl.hms.harvard.edu> Message-ID: <4D4ADAA3.9070504@redhat.com> On 02/03/2011 10:51 AM, Peter Doherty wrote: > > On Feb 3, 2011, at 10:35 , Stephen Gallagher wrote: > >> >> - From the earlier points of the discussion, schema migration is planned >> for upgrades from 2.0.0 to future versions. It's only something that was >> left out of the alpha/beta process because things were still in churn >> and those releases were never intended to be in production. Once 2.0.0 >> is baked, obviously the upgrade path will need to be clean. > > > Is there a plan to include the ability for users of 1.2 to migrate to > 2.0? > I'd consider setting up and using 1.2 right now if I know that I can > migrate to 2.0 when the stable release comes out. > This is a use case that we have in mind. v1 is treated as an external DS thought. This migration is planned through the migrate-ds + SSSD or special page to migrate passwords. The v1 and v2 schemas are drastically different but v1 just has users and groups and migrate-ds script takes care of it. This is well covered in the migration guide. The in place update are planned starting v2 meaning that either the bits just can be refreshed on each of the replicas gradually (if schema or related logic is not affected) or will require a rolling upgrade. The rolling upgrade is needed for the cases when there are schema changes and newer replicas can't talk to the old replicas due to potential data corruption cause by schema mismatch. The rolling upgrade procedure will effectively cause a split of the domain. Replicas that still carry old bits and schema will talk to each other and updated replicas will talk to each other. The rolling upgrade procedure fill involve updating replicas one by one so that they move from one set to another. Finally when all replicas are updated they all will be talking to each other again. The changes caused by the client and administrative activity will be propagated to the set of updated replicas as any new converted replica will carry the chunk of changes it already knows about. Upgrades are very complex procedures especially in the replicated environments. There is no silver bullet technology that will make things simple. We though this part through but do not plan supporting rolling upgrades till the next version of IPA (probably 2.1). The foundation for such approach is there. But the tools to actually update in place are not yet implemented. They are a part of the subsequent release. Thanks Dmitri > -Peter > > _______________________________________________ > 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 dpal at redhat.com Fri Feb 4 04:31:57 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 03 Feb 2011 23:31:57 -0500 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Beta 2 Release Message-ID: <4D4B813D.9050809@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Beta 2 release of freeIPA 2.0 server [1]. * Binaries are available for F-14. * With the release of this Beta, freeIPA moves into the Release Candidate cycle. * Please do not hesitate to share feedback, criticism or bugs with us on our mailing list: freeipa-users at redhat.com Main Highlights of the Beta This beta has a set of significant improvements across all areas of the project. Modifications include but are not limited to: * Support of the latest Dogtag packages. * Installation fixes. * Changes in the DIT structure. * New permissions defined against different elements of the tree. * Better startup and shutdown handling. * Replication improvements. * Incremental improvements in IPv6 support. * DNS improvements. * The package name has been changed to "freeipa" to avoid collision with IPA v1.x and many others. Focus of the Beta Testing * There is a Fedora test day for FreeIPA coming on Feb 10th [3]. Please join us in testing FreeIPA. The exact instructions will be provided later and will be available off the link on the page. * The following section outlines the areas that we are mostly interested to test [4]. Significant Changes Since Beta 1 To see all the tickets addressed between the two beta releases see [2]. Repositories and Installation * Use the following link to install the beta 2 packages [5]. * On Fedora-14 FreeIPA relies on the latest versions of the packages currently available from the updates-testing repository. Please make sure to enable this repository before you proceed with installation. Known Issues: * There are known issues that currently prevent FreeIPA from successfully installing on F-15 [6]. We will send a separate message when these issues are resolved. * Server-generated error messages are not translated yet. * IPv6 support is not complete. * The 'ipa help' command does not support localization. We plan to address all the outstanding tickets before the final 2.0 release. For the complete list see [7]. Thank you, The FreeIPA development team [1] http://www.freeipa.org/page/Downloads [2] https://fedorahosted.org/freeipa/milestone/0.8%20iteration%20-%20January%20%28cleanup%29 [3] https://fedoraproject.org/wiki/QA/Fedora_15_test_days [4] https://fedoraproject.org/wiki/Features/FreeIPAv2#How_To_Test [5] http://freeipa.org/downloads/freeipa-devel.repo [6] https://bugzilla.redhat.com/show_bug.cgi?id=674916 [7] https://fedorahosted.org/freeipa/milestone/2.0.1%20Bug%20fixing From heco0701 at stcloudstate.edu Fri Feb 4 21:00:46 2011 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Fri, 4 Feb 2011 15:00:46 -0600 Subject: [Freeipa-users] FreeIPA future releases. Message-ID: <28D2327D43A0C84D89CF661F17B0D3A0168C425C17@SCSU81.campus.stcloudstate.edu> I have 2 questions. First is a possible idea of when FreeIPA v2 will go gold and have the final stable release? This will help me with my lab and small data center planning. Also second is more of a suggestion, and that you guys should look at incorporating DHCP into IPA like you did DNS. Also for it to be able to dynamically update the DNS with machines that connect to the network. I work inside but separate from a college campus network and we have laptops coming and going from our network and being a research lab we are always tearing machines down and rebuilding them and renaming them. Thanks, Corey Hemminger SCSU - BCRL/HPCG Systems/Networking Administrator From sgallagh at redhat.com Fri Feb 4 21:36:06 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 04 Feb 2011 16:36:06 -0500 Subject: [Freeipa-users] FreeIPA future releases. In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A0168C425C17@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A0168C425C17@SCSU81.campus.stcloudstate.edu> Message-ID: <4D4C7146.4060401@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/04/2011 04:00 PM, Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > Also for it to be able to dynamically update > the DNS with machines that connect to the network. Just commenting on this: if the client machines use SSSD and are enrolled with FreeIPA, then they can automatically update their DNS entries by using the ipa_dyndns_update = True setting in sssd.conf - -- 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/ iEYEARECAAYFAk1McUYACgkQeiVVYja6o6MKNwCeKNS33lh9K/JYyBRX0X2IHZpm wmcAn10NRogtDkPrcVO7VhIDdeBDabhd =vS7z -----END PGP SIGNATURE----- From ssorce at redhat.com Fri Feb 4 22:03:50 2011 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 4 Feb 2011 17:03:50 -0500 Subject: [Freeipa-users] FreeIPA future releases. In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A0168C425C17@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A0168C425C17@SCSU81.campus.stcloudstate.edu> Message-ID: <20110204170350.43c1b7a7@willson.li.ssimo.org> On Fri, 4 Feb 2011 15:00:46 -0600 "Hemminger, Corey Lee. [heco0701 at stcloudstate.edu]" wrote: > I have 2 questions. First is a possible idea of when FreeIPA v2 will > go gold and have the final stable release? This will help me with my > lab and small data center planning. Also second is more of a > suggestion, and that you guys should look at incorporating DHCP into > IPA like you did DNS. Also for it to be able to dynamically update > the DNS with machines that connect to the network. I work inside but > separate from a college campus network and we have laptops coming and > going from our network and being a research lab we are always tearing > machines down and rebuilding them and renaming them. You should be able to configure named to accept DNS updates from your dhcp server adding configuration to allow a specific IP (that of the dhcp) to update any entry. However we will evaluate whether integrating DHCP is something we can do for a future release, or maybe something people are willing to contribute. Simo. -- Simo Sorce * Red Hat, Inc * New York From doherty at hkl.hms.harvard.edu Tue Feb 8 14:49:31 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 8 Feb 2011 09:49:31 -0500 Subject: [Freeipa-users] export entire ldap/kerberos/etc onto a new host In-Reply-To: <4D4ADAA3.9070504@redhat.com> References: <0CFB823A-DEBD-44D6-BA36-E27315B584B3@hkl.hms.harvard.edu> <4D48625B.2070807@redhat.com> <8062395C-274F-4166-956B-B2B975B56B20@hkl.hms.harvard.edu> <4D486677.1060805@redhat.com> <4D48675F.4080802@redhat.com> <17BD3185-DBED-40EA-BEAB-B60C4262B8C7@hkl.hms.harvard.edu> <20110202090942.5119a44c@willson.li.ssimo.org> <2BA5E282-F7FF-4AFC-BB13-C26B59C1883D@hkl.hms.harvard.edu> <20110202101005.3a6af851@willson.li.ssimo.org> <4D4994A8.5060409@hkl.hms.harvard.edu> <4D49ACEE.4030705@redhat.com> <4D49C682.2090406@hkl.hms.harvard.edu> <4D49D777.8070807@hkl.hms.harvard.edu> <4D4AA719.5030908@redhat.com> <4D4AC9D5.5000403@hkl.hms.harvard.edu> <4D4ACB2E.7000905@redhat.com> <32A11848-7A9F-44A7-B111-FEB8FC72D299@hkl.hms.harvard.edu> <4D4ADAA3.9070504@redhat.com> Message-ID: On Feb 3, 2011, at 11:41 , Dmitri Pal wrote: > On 02/03/2011 10:51 AM, Peter Doherty wrote: >> >> On Feb 3, 2011, at 10:35 , Stephen Gallagher wrote: >> >>> >>> - From the earlier points of the discussion, schema migration is >>> planned >>> for upgrades from 2.0.0 to future versions. It's only something >>> that was >>> left out of the alpha/beta process because things were still in >>> churn >>> and those releases were never intended to be in production. Once >>> 2.0.0 >>> is baked, obviously the upgrade path will need to be clean. >> >> >> Is there a plan to include the ability for users of 1.2 to migrate to >> 2.0? >> I'd consider setting up and using 1.2 right now if I know that I can >> migrate to 2.0 when the stable release comes out. >> > > This is a use case that we have in mind. v1 is treated as an > external DS > thought. > This migration is planned through the migrate-ds + SSSD or special > page > to migrate passwords. The v1 and v2 schemas are drastically different > but v1 just has users and groups and migrate-ds script takes care of > it. > This is well covered in the migration guide. > > > > Thanks > Dmitri For the curious out there, I set up a FreeIPA 1.2 server and recreated all the users and groups, and dumped and imported the other LDAP info (mostly automount maps) User passwords were reset. It took most of a day, but things are running again. If/when there's a migration path into v2 I'll look into it. From what I've seen the feature set in v2 is nice, I'm looking forward to seeing the final product. Peter From matonb at ltresources.co.uk Wed Feb 9 16:13:39 2011 From: matonb at ltresources.co.uk (Brett Maton) Date: Wed, 9 Feb 2011 16:13:39 +0000 Subject: [Freeipa-users] Freeipa Windows 7 client authentication Message-ID: Hi, I can't get a Windows 7 client to authenticate against Freeipa (ver 2.0.0.pre2) running on Fedora 14. Feb 09 16:03:22 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: NEEDED_PREAUTH: matonb at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required Feb 09 16:03:22 krb5kdc[32355](info): preauth (timestamp) verify failure: Decrypt integrity check failed Feb 09 16:03:22 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: PREAUTH_FAILED: matonb at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Feb 09 16:03:23 krb5kdc[32355](info): preauth (timestamp) verify failure: Decrypt integrity check failed Feb 09 16:03:23 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: PREAUTH_FAILED: matonb at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Any help with where to start looking or what might be wrong would be greatly appreciated. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 9 20:58:43 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Feb 2011 15:58:43 -0500 Subject: [Freeipa-users] Fedora 15 test day is moved to Feb 15th. Message-ID: <4D530003.1020208@redhat.com> Hello, Please join us in testing FreeIPA v2 on Tuesday Feb 15th as a part of the Fedora 15 Test Day. Originally we planned to have a test day on Thursday February 10th (tomorrow) but for different reasons we had to delay this effort. The details of what to test and how to test will be published later this week. Please follow the changes on the Fedora test page [1] and on the FreeIPA wiki [2]. [1] https://fedoraproject.org/wiki/Test_Day:2011-02-15_FreeIPAv2 (incomplete as of Feb 9th) [2] www.freeipa.org -- 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 Wed Feb 9 21:30:19 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Feb 2011 16:30:19 -0500 Subject: [Freeipa-users] Freeipa Windows 7 client authentication In-Reply-To: References: Message-ID: <4D53076B.2040207@redhat.com> On 02/09/2011 11:13 AM, Brett Maton wrote: > Decrypt integrity check failed > What kind of setup you did on the client? Can you please provide a little bit more details? Have you done something this (it was written for V1 and Windows 7 was not around but the concepts should be the same): http://freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Feb 10 05:32:38 2011 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Feb 2011 00:32:38 -0500 Subject: [Freeipa-users] Freeipa Windows 7 client authentication In-Reply-To: References: Message-ID: <20110210003238.28c58d28@willson.li.ssimo.org> On Wed, 9 Feb 2011 16:13:39 +0000 Brett Maton wrote: > Hi, > > I can't get a Windows 7 client to authenticate against Freeipa (ver > 2.0.0.pre2) running on Fedora 14. > > Feb 09 16:03:22 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 > 24 -135}) 192.168.0.2: NEEDED_PREAUTH: matonb at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication > required Feb 09 16:03:22 krb5kdc[32355](info): preauth (timestamp) > verify failure: Decrypt integrity check failed Feb 09 16:03:22 > krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) > 192.168.0.2: PREAUTH_FAILED: matonb at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Feb 09 > 16:03:23 krb5kdc[32355](info): preauth (timestamp) verify failure: > Decrypt integrity check failed Feb 09 16:03:23 krb5kdc[32355](info): > AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: PREAUTH_FAILED: > matonb at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt > integrity check failed > > Any help with where to start looking or what might be wrong would be > greatly appreciated. Either the password is wrong or the time on your client is not within 5 min. of the time on the KDC. Simo. -- Simo Sorce * Red Hat, Inc * New York From matonb at ltresources.co.uk Thu Feb 10 10:30:36 2011 From: matonb at ltresources.co.uk (Brett Maton) Date: Thu, 10 Feb 2011 10:30:36 -0000 Subject: [Freeipa-users] Freeipa Windows 7 client authentication In-Reply-To: <20110210003238.28c58d28@willson.li.ssimo.org> References: <20110210003238.28c58d28@willson.li.ssimo.org> Message-ID: <007b01cbc90d$8f286c60$ad794520$@co.uk> Thanks for the replies, Simo, I know the password is correct as I can kinit from other linux boxes. All machines are using the same time source, and I checked the time on each machine so unfortunately it's neither of those this time round. Dimitri, I did run through the "Configuring Windows Client" section on that web page, although I didn't install any additional software (ksetup / klist / kinit tools already installed). The client is connecting correctly as I get "Your password has expired, please change it" as a response when I login. It appears that the password change from the Windows Client fails with the "Decrypt integrity check" errors. If I change the password on a linux server when requested by kinit, I get the same Decrypt errors when trying to login to the Windows 7 client (Windows 7 Professional). I did change the local security policy to Accept all Kerberos Encryption types, except "Future encryption types". Thanks, Brett -----Original Message----- From: Simo Sorce Sent: 10 February 2011 05:33 To: Brett Maton Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Freeipa Windows 7 client authentication On Wed, 9 Feb 2011 16:13:39 +0000 Brett Maton wrote: > Hi, > > I can't get a Windows 7 client to authenticate against Freeipa (ver > 2.0.0.pre2) running on Fedora 14. > > Feb 09 16:03:22 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 > 24 -135}) 192.168.0.2: NEEDED_PREAUTH: matonb at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication > required Feb 09 16:03:22 krb5kdc[32355](info): preauth (timestamp) > verify failure: Decrypt integrity check failed Feb 09 16:03:22 > krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) > 192.168.0.2: PREAUTH_FAILED: matonb at EXAMPLE.COM for > krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Feb 09 > 16:03:23 krb5kdc[32355](info): preauth (timestamp) verify failure: > Decrypt integrity check failed Feb 09 16:03:23 krb5kdc[32355](info): > AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: PREAUTH_FAILED: > matonb at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt > integrity check failed > > Any help with where to start looking or what might be wrong would be > greatly appreciated. Either the password is wrong or the time on your client is not within 5 min. of the time on the KDC. Simo. -- Simo Sorce * Red Hat, Inc * New York __________ Information from ESET NOD32 Antivirus, version of virus signature database 5860 (20110209) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5860 (20110209) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From dpal at redhat.com Fri Feb 11 20:34:04 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Feb 2011 15:34:04 -0500 Subject: [Freeipa-users] Freeipa Windows 7 client authentication In-Reply-To: <007b01cbc90d$8f286c60$ad794520$@co.uk> References: <20110210003238.28c58d28@willson.li.ssimo.org> <007b01cbc90d$8f286c60$ad794520$@co.uk> Message-ID: <4D559D3C.1070009@redhat.com> On 02/10/2011 05:30 AM, Brett Maton wrote: > Thanks for the replies, > > Simo, I know the password is correct as I can kinit from other > linux boxes. > All machines are using the same time source, and I checked the time on each > machine so unfortunately it's neither of those this time round. > > Dimitri, > I did run through the "Configuring Windows Client" section on that web > page, although I didn't install any additional software (ksetup / klist / > kinit tools already installed). > > The client is connecting correctly as I get "Your password has expired, > please change it" as a response when I login. > It appears that the password change from the Windows Client fails with the > "Decrypt integrity check" errors. > If I change the password on a linux server when requested by kinit, I get > the same Decrypt errors when trying to login to the Windows 7 client > (Windows 7 Professional). > > I did change the local security policy to Accept all Kerberos Encryption > types, except "Future encryption types". > > Thanks, > Brett > > -----Original Message----- > From: Simo Sorce > Sent: 10 February 2011 05:33 > To: Brett Maton > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Freeipa Windows 7 client authentication > > On Wed, 9 Feb 2011 16:13:39 +0000 > Brett Maton wrote: > >> Hi, >> >> I can't get a Windows 7 client to authenticate against Freeipa (ver >> 2.0.0.pre2) running on Fedora 14. >> >> Feb 09 16:03:22 krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 >> 24 -135}) 192.168.0.2: NEEDED_PREAUTH: matonb at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication >> required Feb 09 16:03:22 krb5kdc[32355](info): preauth (timestamp) >> verify failure: Decrypt integrity check failed Feb 09 16:03:22 >> krb5kdc[32355](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) >> 192.168.0.2: PREAUTH_FAILED: matonb at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt integrity check failed Feb 09 >> 16:03:23 krb5kdc[32355](info): preauth (timestamp) verify failure: >> Decrypt integrity check failed Feb 09 16:03:23 krb5kdc[32355](info): >> AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.0.2: PREAUTH_FAILED: >> matonb at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Decrypt >> integrity check failed >> >> Any help with where to start looking or what might be wrong would be >> greatly appreciated. > Either the password is wrong or the time on your client is not within 5 > min. of the time on the KDC. > > Simo. > Can you please log a bug then and we will try to check this scenario? You might be the first person who tries this scenario and something can be wrong on either side. I am not sure we would be able to jump on this right away but the bug would at least give us a way to get to it in due time. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jlaska at redhat.com Fri Feb 11 20:47:17 2011 From: jlaska at redhat.com (James Laska) Date: Fri, 11 Feb 2011 15:47:17 -0500 Subject: [Freeipa-users] Tuesday, February 15, 2011 - FreeIPA v2 Test Day Message-ID: <1297457238.2878.61.camel@flatline> Greetings folks, I'm passing along an announcement from the freeipa-users mailing list [1] regarding the first of two Test Days next week. On Tuesday, we'll be hosting a test day focused on FreeIPA v2. The FreeIPA project implements an identity server. IPA stands for Identity, Policy and Audit. The first version of IPA was introduced three years ago and was focused on the user identity and authentication. This version is a significant revision of the IPA server adding multiple new features and capabilities. The test day wiki is still coming online, we expect it to be finalized on Monday. For more information on the upcoming Fedora 15 feature, checkout the feature page [2]. [1] https://www.redhat.com/archives/freeipa-users/2011-February/msg00033.html [2] https://fedoraproject.org/wiki/Features/FreeIPAv2 > Please join us in testing FreeIPA v2 on Tuesday Feb 15th as a part of > the Fedora 15 Test Day. Originally we planned to have a test day on > Thursday February 10th (tomorrow) but for different reasons we had to > delay this effort. > > The details of what to test and how to test will be published later > this week. Please follow the changes on the Fedora test page [1] and > on the FreeIPA wiki [2]. > > [1] https://fedoraproject.org/wiki/Test_Day:2011-02-15_FreeIPAv2 > (incomplete as of Feb 9th) > [2] http://www.freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Fri Feb 11 21:08:21 2011 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Feb 2011 16:08:21 -0500 Subject: [Freeipa-users] Freeipa Windows 7 client authentication In-Reply-To: References: Message-ID: <20110211160821.4dc53937@willson.li.ssimo.org> On Wed, 9 Feb 2011 16:13:39 +0000 Brett Maton wrote: > I can't get a Windows 7 client to authenticate against Freeipa (ver > 2.0.0.pre2) running on Fedora 14. Brett, can you tell me what krb5-server package do you have installed ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Feb 15 04:08:42 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Feb 2011 23:08:42 -0500 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA v2 Server Release Candidate 1 Release Message-ID: <4D59FC4A.5050603@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Release Candidate 1 release of freeIPA 2.0 server [1]. * Binaries are available for F-14 and F-15 [2]. * Please do not hesitate to share feedback, criticism or bugs with us on our mailing list: freeipa-users at redhat.com Main Highlights of the Release Candidate. This release consists primarily of bug fixes and polish across all areas ofthe project. Modifications include but are not limited to: * Installation fixes. * DNS improvements. * WebUI improvements. Focus of the Release Candidate Testing * There is a Fedora test day for FreeIPA on Feb 15th [3]. Please join us in testing FreeIPA. The exact instructions will be provided later and will be available off the link on the page. * The following section outlines the areas that we are mostly interested to test [4]. Significant Changes Since Beta 2 To see all the tickets addressed since the beta 2 release see [6]. Repositories and Installation * Use the following link to install the beta 2 packages [5]. * On Fedora-14 FreeIPA relies on the latest versions of the packages currently available from the updates-testing repository. Please make sure to enable this repository before you proceed with installation. Known Issues: * There are known issues that currently prevent FreeIPA from successfully installing with dogtag on F-15 [2]. We will send a separate message when this issue is resolved. The FreeIPA server is installable with the --selfsign option on F-15, or with dogtag on F-14. * Server-generated error messages are not translated yet. * IPv6 support is not complete. * The 'ipa help' command does not support localization. We plan to address all the outstanding tickets before the final 2.0 release. For the complete list see [7]. Thank you, The FreeIPA development team [1] http://www.freeipa.org/page/Downloads [2] dogtag is having issues with systemd: https://bugzilla.redhat.com/show_bug.cgi?id=676330 [3] https://fedoraproject.org/wiki/QA/Fedora_15_test_days [4] https://fedoraproject.org/wiki/Features/FreeIPAv2#How_To_Test [5] http://freeipa.org/downloads/freeipa-devel.repo [6] https://fedorahosted.org/freeipa/query?status=closed&milestone=2.0.1+Bug+fixing+(RC) [7] https://fedorahosted.org/freeipa/milestone/2.0.2%20Bug%20fixing%20%28RC2%29 From doherty at hkl.hms.harvard.edu Tue Feb 15 18:05:24 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 15 Feb 2011 13:05:24 -0500 Subject: [Freeipa-users] limit access to a specific CN Message-ID: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) and then create an account that can edit that cn as much as they want, but can't edit the other ones (ie: accounts, groups...)? Any pointers to documentation would be useful. Unfortunately I'm not 100% clear on my terminology, so google searches are leading me a bit astray. Thanks, Peter From rcritten at redhat.com Tue Feb 15 19:02:20 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Feb 2011 14:02:20 -0500 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> Message-ID: <4D5ACDBC.8030600@redhat.com> Peter Doherty wrote: > Hello, I'm running Fedora 14 and freeipa 1.2.2-6 > > > Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) > and then create an account that can edit that cn as much as they want, > but can't edit the other ones (ie: accounts, groups...)? > Any pointers to documentation would be useful. Unfortunately I'm not > 100% clear on my terminology, so google searches are leading me a bit > astray. What would you put into this container? 389-ds certainly supports doing this, depending on what exactly you want to do IPA may or may not support it. For example, we look for a type of entry only within a given container, so you can't put users into another location. rob From doherty at hkl.hms.harvard.edu Tue Feb 15 19:09:07 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 15 Feb 2011 14:09:07 -0500 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <4D5ACDBC.8030600@redhat.com> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> Message-ID: On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: > Peter Doherty wrote: >> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 >> >> >> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) >> and then create an account that can edit that cn as much as they >> want, >> but can't edit the other ones (ie: accounts, groups...)? >> Any pointers to documentation would be useful. Unfortunately I'm not >> 100% clear on my terminology, so google searches are leading me a bit >> astray. > > What would you put into this container? > > 389-ds certainly supports doing this, depending on what exactly you > want to do IPA may or may not support it. For example, we look for a > type of entry only within a given container, so you can't put users > into another location. > > rob The first thing I'm looking to do with it is have a web server that has account information stored in LDAP, and to allow users to to ldap authentication. The users logging into the web server would be different from the posix groups that are managed by FreeIPA. I want to replace htaccess and htpasswd files and use LDAP instead. It seems like I could create a subsection in LDAP and set up apache to bind and auth against that. But I also want a seperate ldap admin account that can only edit this section, and not the rest of the FreeIPA data. Thanks. Peter From ssorce at redhat.com Tue Feb 15 19:45:35 2011 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 Feb 2011 14:45:35 -0500 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> Message-ID: <20110215144535.4054d1c4@willson.li.ssimo.org> On Tue, 15 Feb 2011 14:09:07 -0500 Peter Doherty wrote: > > On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: > > > Peter Doherty wrote: > >> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 > >> > >> > >> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) > >> and then create an account that can edit that cn as much as they > >> want, > >> but can't edit the other ones (ie: accounts, groups...)? > >> Any pointers to documentation would be useful. Unfortunately I'm > >> not 100% clear on my terminology, so google searches are leading > >> me a bit astray. > > > > What would you put into this container? > > > > 389-ds certainly supports doing this, depending on what exactly > > you want to do IPA may or may not support it. For example, we look > > for a type of entry only within a given container, so you can't put > > users into another location. > > > > rob > > The first thing I'm looking to do with it is have a web server that > has account information stored in LDAP, and to allow users to to > ldap authentication. The users logging into the web server would be > different from the posix groups that are managed by FreeIPA. I want > to replace htaccess and htpasswd files and use LDAP instead. > It seems like I could create a subsection in LDAP and set up apache > to bind and auth against that. But I also want a seperate ldap > admin account that can only edit this section, and not the rest of > the FreeIPA data. > Thanks. It is possible to do using LDAP tools and then setting an ACI on the container to give the user you want full control on that container. Simo. -- Simo Sorce * Red Hat, Inc * New York From benjamin.vogt at serv24.biz Tue Feb 15 20:26:47 2011 From: benjamin.vogt at serv24.biz (Benjamin Vogt) Date: Tue, 15 Feb 2011 21:26:47 +0100 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <20110215144535.4054d1c4@willson.li.ssimo.org> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> <20110215144535.4054d1c4@willson.li.ssimo.org> Message-ID: <000001cbcd4e$aba5e3f0$02f1abd0$@serv24.biz> You can put your users into LDAP groups and have Apache check that the user exists in the specified group. I do this for subversion access (f14 & freeipa 1.2.2). This way I can manage everything over the freeipa webgui without resorting to external tools. - Ben -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Simo Sorce Sent: Tuesday, February 15, 2011 20:46 To: Peter Doherty Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] limit access to a specific CN On Tue, 15 Feb 2011 14:09:07 -0500 Peter Doherty wrote: > > On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: > > > Peter Doherty wrote: > >> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 > >> > >> > >> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) > >> and then create an account that can edit that cn as much as they > >> want, but can't edit the other ones (ie: accounts, groups...)? > >> Any pointers to documentation would be useful. Unfortunately I'm > >> not 100% clear on my terminology, so google searches are leading me > >> a bit astray. > > > > What would you put into this container? > > > > 389-ds certainly supports doing this, depending on what exactly you > > want to do IPA may or may not support it. For example, we look for a > > type of entry only within a given container, so you can't put users > > into another location. > > > > rob > > The first thing I'm looking to do with it is have a web server that > has account information stored in LDAP, and to allow users to to ldap > authentication. The users logging into the web server would be > different from the posix groups that are managed by FreeIPA. I want > to replace htaccess and htpasswd files and use LDAP instead. > It seems like I could create a subsection in LDAP and set up apache to > bind and auth against that. But I also want a seperate ldap admin > account that can only edit this section, and not the rest of the > FreeIPA data. > Thanks. It is possible to do using LDAP tools and then setting an ACI on the container to give the user you want full control on that container. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From doherty at hkl.hms.harvard.edu Tue Feb 15 23:30:51 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Tue, 15 Feb 2011 18:30:51 -0500 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <20110215144535.4054d1c4@willson.li.ssimo.org> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> <20110215144535.4054d1c4@willson.li.ssimo.org> Message-ID: On Feb 15, 2011, at 14:45 , Simo Sorce wrote: > On Tue, 15 Feb 2011 14:09:07 -0500 > Peter Doherty wrote: > >> On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: >> >>> Peter Doherty wrote: >>>> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 >>>> >>>> >>>> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) >>>> and then create an account that can edit that cn as much as they >>>> want, >>>> >>>> >>> >>> What would you put into this container? >>> >>> >>> >>> rob >> >> The first thing I'm looking to do with it is have a web server that >> has account information stored in LDAP, and to allow users to to >> ldap authentication. The users logging into the web server would be >> > > It is possible to do using LDAP tools and then setting an ACI on the > container to give the user you want full control on that container. > > Simo. Simo, This gave me a good starting point, and after reading some more, I'm starting to wrap my brain around what I want to do and how to do it. LDAP has a steep learning curve, IMHO. Can you recommend any GUI tools for creating/modifying the ACI for the container? I started to try and create an ACI using the ones within FreeIPA as a reference, but if there's a GUI that would be useful too. I checked out Apache Directory Studio which looks nice, but doesn't seem to support the schema that FreeIPA is using. --Peter From Steven.Jones at vuw.ac.nz Wed Feb 16 00:58:07 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 16 Feb 2011 13:58:07 +1300 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA v2 Server Release Candidate 1 Release In-Reply-To: <4D59FC4A.5050603@redhat.com> References: <4D59FC4A.5050603@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> Has anyone tried this? I get a "Damaged repo file" regards From sbose at redhat.com Wed Feb 16 09:10:22 2011 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Feb 2011 10:10:22 +0100 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> <20110215144535.4054d1c4@willson.li.ssimo.org> Message-ID: <20110216091022.GA27076@localhost.localdomain> On Tue, Feb 15, 2011 at 06:30:51PM -0500, Peter Doherty wrote: > > On Feb 15, 2011, at 14:45 , Simo Sorce wrote: > > > On Tue, 15 Feb 2011 14:09:07 -0500 > > Peter Doherty wrote: > > > >> On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: > >> > >>> Peter Doherty wrote: > >>>> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 > >>>> > >>>> > >>>> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) > >>>> and then create an account that can edit that cn as much as they > >>>> want, > >>>> > >>>> > >>> > >>> What would you put into this container? > >>> > >>> > >>> > >>> rob > >> > >> The first thing I'm looking to do with it is have a web server that > >> has account information stored in LDAP, and to allow users to to > >> ldap authentication. The users logging into the web server would be > >> > > > > It is possible to do using LDAP tools and then setting an ACI on the > > container to give the user you want full control on that container. > > > > Simo. > > Simo, > > This gave me a good starting point, and after reading some more, I'm starting to wrap my brain around what I want to do and how to do it. > LDAP has a steep learning curve, IMHO. > Can you recommend any GUI tools for creating/modifying the ACI for the container? I started to try and create an ACI using the ones within FreeIPA as a reference, but if there's a GUI that would be useful too. I checked out Apache Directory Studio which looks nice, but doesn't seem to support the schema that FreeIPA is using. I use Apache Directory Studio to edit FreeIPA LDAP objects and I can also see and edit ACIs. The schema shouldn't be a problem, because the editor can read the schema data from the LDAP server. Which kind of problems are you seeing ? bye, Sumit > > --Peter > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From doherty at hkl.hms.harvard.edu Wed Feb 16 14:28:10 2011 From: doherty at hkl.hms.harvard.edu (Peter Doherty) Date: Wed, 16 Feb 2011 09:28:10 -0500 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <20110216091022.GA27076@localhost.localdomain> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> <20110215144535.4054d1c4@willson.li.ssimo.org> <20110216091022.GA27076@localhost.localdomain> Message-ID: <416EEB3F-EBA3-4D19-8033-4EF043A53387@hkl.hms.harvard.edu> On Feb 16, 2011, at 04:10 , Sumit Bose wrote: > On Tue, Feb 15, 2011 at 06:30:51PM -0500, Peter Doherty wrote: >> >> On Feb 15, 2011, at 14:45 , Simo Sorce wrote: >> >>> On Tue, 15 Feb 2011 14:09:07 -0500 >>> Peter Doherty wrote: >>> >>>> On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: >>>> >>>>> Peter Doherty wrote: >>>>>> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 >>>>>> >>>>>> >>>>>> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) >>>>>> and then create an account that can edit that cn as much as they >>>>>> want, >>>>>> >>>>>> >>>>> >>>>> What would you put into this container? >>>>> >>>>> >>>>> >>>>> rob >>>> >>>> The first thing I'm looking to do with it is have a web server that >>>> has account information stored in LDAP, and to allow users to to >>>> ldap authentication. The users logging into the web server would >>>> be >>>> >>> >>> It is possible to do using LDAP tools and then setting an ACI on the >>> container to give the user you want full control on that container. >>> >>> Simo. >> >> Simo, >> >> This gave me a good starting point, and after reading some more, >> I'm starting to wrap my brain around what I want to do and how to >> do it. >> LDAP has a steep learning curve, IMHO. >> Can you recommend any GUI tools for creating/modifying the ACI for >> the container? I started to try and create an ACI using the ones >> within FreeIPA as a reference, but if there's a GUI that would be >> useful too. I checked out Apache Directory Studio which looks >> nice, but doesn't seem to support the schema that FreeIPA is using. > > I use Apache Directory Studio to edit FreeIPA LDAP objects and I can > also see and edit ACIs. The schema shouldn't be a problem, because the > editor can read the schema data from the LDAP server. Which kind of > problems are you seeing ? Well, Apache Directory Studio has ACI editor (looks like this: http://directory.apache.org/studio/screenshots.data/aci_visual_1.png ) so you don't edit the text directly, but rather use a GUI, which builds the policy in text and inserts it when you're done editing. But it seems to use a different schema than FreeIPA is using... Peter From rcritten at redhat.com Wed Feb 16 14:55:06 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Feb 2011 09:55:06 -0500 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <416EEB3F-EBA3-4D19-8033-4EF043A53387@hkl.hms.harvard.edu> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> <20110215144535.4054d1c4@willson.li.ssimo.org> <20110216091022.GA27076@localhost.localdomain> <416EEB3F-EBA3-4D19-8033-4EF043A53387@hkl.hms.harvard.edu> Message-ID: <4D5BE54A.1060800@redhat.com> Peter Doherty wrote: > > On Feb 16, 2011, at 04:10 , Sumit Bose wrote: > >> On Tue, Feb 15, 2011 at 06:30:51PM -0500, Peter Doherty wrote: >>> >>> On Feb 15, 2011, at 14:45 , Simo Sorce wrote: >>> >>>> On Tue, 15 Feb 2011 14:09:07 -0500 >>>> Peter Doherty wrote: >>>> >>>>> On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: >>>>> >>>>>> Peter Doherty wrote: >>>>>>> Hello, I'm running Fedora 14 and freeipa 1.2.2-6 >>>>>>> >>>>>>> >>>>>>> Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) >>>>>>> and then create an account that can edit that cn as much as they >>>>>>> want, >>>>>>> >>>>>>> >>>>>> >>>>>> What would you put into this container? >>>>>> >>>>>> >>>>>> >>>>>> rob >>>>> >>>>> The first thing I'm looking to do with it is have a web server that >>>>> has account information stored in LDAP, and to allow users to to >>>>> ldap authentication. The users logging into the web server would be >>>>> >>>> >>>> It is possible to do using LDAP tools and then setting an ACI on the >>>> container to give the user you want full control on that container. >>>> >>>> Simo. >>> >>> Simo, >>> >>> This gave me a good starting point, and after reading some more, I'm >>> starting to wrap my brain around what I want to do and how to do it. >>> LDAP has a steep learning curve, IMHO. >>> Can you recommend any GUI tools for creating/modifying the ACI for >>> the container? I started to try and create an ACI using the ones >>> within FreeIPA as a reference, but if there's a GUI that would be >>> useful too. I checked out Apache Directory Studio which looks nice, >>> but doesn't seem to support the schema that FreeIPA is using. >> >> I use Apache Directory Studio to edit FreeIPA LDAP objects and I can >> also see and edit ACIs. The schema shouldn't be a problem, because the >> editor can read the schema data from the LDAP server. Which kind of >> problems are you seeing ? > > Well, Apache Directory Studio has ACI editor (looks like this: > http://directory.apache.org/studio/screenshots.data/aci_visual_1.png ) > so you don't edit the text directly, but rather use a GUI, which builds > the policy in text and inserts it when you're done editing. > But it seems to use a different schema than FreeIPA is using... > > Peter You can read about 389-ds acis at: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Access_Control It has 3 basic parts: target, permissions, bind rule In this case the bind rule is the user you want to allow editing. The rest depends on whether you want to restrict your user at all. If you want it to be able to do anything you can probably get away with putting something like this into cn=yourcontainer,dc=example,dc=com (I haven't tested this): aci: (targetattr="*")(version 3.0; acl "Apache access Account"; allow (all) userdn= "ldap:///uid=apache,cn=yourcontainer,dc=example,dc=com";) rob From sbose at redhat.com Wed Feb 16 17:02:31 2011 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Feb 2011 18:02:31 +0100 Subject: [Freeipa-users] limit access to a specific CN In-Reply-To: <416EEB3F-EBA3-4D19-8033-4EF043A53387@hkl.hms.harvard.edu> References: <1DD50A25-59B0-4B94-AD50-3CD3C43CDD0D@hkl.hms.harvard.edu> <4D5ACDBC.8030600@redhat.com> <20110215144535.4054d1c4@willson.li.ssimo.org> <20110216091022.GA27076@localhost.localdomain> <416EEB3F-EBA3-4D19-8033-4EF043A53387@hkl.hms.harvard.edu> Message-ID: <20110216170231.GE27076@localhost.localdomain> On Wed, Feb 16, 2011 at 09:28:10AM -0500, Peter Doherty wrote: > > On Feb 16, 2011, at 04:10 , Sumit Bose wrote: > > >On Tue, Feb 15, 2011 at 06:30:51PM -0500, Peter Doherty wrote: > >> > >>On Feb 15, 2011, at 14:45 , Simo Sorce wrote: > >> > >>>On Tue, 15 Feb 2011 14:09:07 -0500 > >>>Peter Doherty wrote: > >>> > >>>>On Feb 15, 2011, at 14:02 , Rob Crittenden wrote: > >>>> > >>>>>Peter Doherty wrote: > >>>>>>Hello, I'm running Fedora 14 and freeipa 1.2.2-6 > >>>>>> > >>>>>> > >>>>>>Can I create a new cn/nsContainer (cn=subgroup,dc=example,dc=com) > >>>>>>and then create an account that can edit that cn as much as they > >>>>>>want, > >>>>>> > >>>>>> > >>>>> > >>>>>What would you put into this container? > >>>>> > >>>>> > >>>>> > >>>>>rob > >>>> > >>>>The first thing I'm looking to do with it is have a web server that > >>>>has account information stored in LDAP, and to allow users to to > >>>>ldap authentication. The users logging into the web server > >>>>would be > >>>> > >>> > >>>It is possible to do using LDAP tools and then setting an ACI on the > >>>container to give the user you want full control on that container. > >>> > >>>Simo. > >> > >>Simo, > >> > >>This gave me a good starting point, and after reading some more, > >>I'm starting to wrap my brain around what I want to do and how > >>to do it. > >>LDAP has a steep learning curve, IMHO. > >>Can you recommend any GUI tools for creating/modifying the ACI > >>for the container? I started to try and create an ACI using the > >>ones within FreeIPA as a reference, but if there's a GUI that > >>would be useful too. I checked out Apache Directory Studio > >>which looks nice, but doesn't seem to support the schema that > >>FreeIPA is using. > > > >I use Apache Directory Studio to edit FreeIPA LDAP objects and I can > >also see and edit ACIs. The schema shouldn't be a problem, because the > >editor can read the schema data from the LDAP server. Which kind of > >problems are you seeing ? > > Well, Apache Directory Studio has ACI editor (looks like this: > http://directory.apache.org/studio/screenshots.data/aci_visual_1.png > ) > so you don't edit the text directly, but rather use a GUI, which > builds the policy in text and inserts it when you're done editing. > But it seems to use a different schema than FreeIPA is using... This plugin is for Apache Directory Server only. AFAIK there is nothing like a standard for ACIs in directory servers and so every directory server has his own concept of access control. bye, Sumit > > Peter From Steven.Jones at vuw.ac.nz Wed Feb 16 19:57:51 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 17 Feb 2011 08:57:51 +1300 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA v2 Server Release Candidate 1 Release In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> Is there a series of RPMS I can download? ie can someone tell which ones I need for the server and which ones I need for the client and in what order I install? I can get the rpms off the store, just not via yum as the repo is dead for me....either its a remote issue, or our firewall is preventing a connection by some means. regards From rcritten at redhat.com Wed Feb 16 20:07:04 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Feb 2011 15:07:04 -0500 Subject: [Freeipa-users] [Freeipa-devel] Announcing FreeIPA v2 Server Release Candidate 1 Release In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D5C2E68.7000206@redhat.com> Steven Jones wrote: > Is there a series of RPMS I can download? > > ie can someone tell which ones I need for the server and which ones I > need for the client and in what order I install? I can get the rpms off > the store, just not via yum as the repo is dead for me....either its a > remote issue, or our firewall is preventing a connection by some means. > > > regards You can find the rpms in http://freeipa.com/downloads/devel/rpms/ rob From Steven.Jones at vuw.ac.nz Fri Feb 18 00:04:44 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 18 Feb 2011 13:04:44 +1300 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Release Candidate 1 Release In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> Trying to install but there appears to be a dependency failure........ ipa server requires 389-ds-base > 1.2.8 but 389-ds-base = 1.2.6 regards From jhrozek at redhat.com Fri Feb 18 09:02:09 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 18 Feb 2011 10:02:09 +0100 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Release Candidate 1 Release In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D5E3591.1030707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/18/2011 01:04 AM, Steven Jones wrote: > Trying to install but there appears to be a dependency failure........ > > ipa server requires 389-ds-base > 1.2.8 but 389-ds-base = 1.2.6 > > regards > > 389-ds-base 1.2.8 is in the updates-testing repository. yum --enablerepo=updates-testing upgrade 389-ds-base should do the trick. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1eNZEACgkQHsardTLnvCWJXgCcDbrw2lSKyouO9/PCdpno7bus TqgAoJ39eFR7mE2GJcbcQCCfnPYKFwmg =Q0MV -----END PGP SIGNATURE----- From tomasz.napierala at allegro.pl Sun Feb 20 14:11:08 2011 From: tomasz.napierala at allegro.pl (tomasz.napierala at allegro.pl) Date: Sun, 20 Feb 2011 15:11:08 +0100 Subject: [Freeipa-users] Changing IP address of master server Message-ID: Hi, Im sure I read about it somwhere, but I can't find any references now. Is it possible to change IP addres of master server? If so, is ot matter of changing system IP and updating DNS, or should I be aware of any other steps? Regards, -- Tomasz Z. Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4565 bytes Desc: not available URL: From tomasz.napierala at allegro.pl Mon Feb 21 01:07:36 2011 From: tomasz.napierala at allegro.pl (tomasz.napierala at allegro.pl) Date: Mon, 21 Feb 2011 02:07:36 +0100 Subject: [Freeipa-users] 389 DS server closing connection after upgrade from Fedora 12 to 13 Message-ID: Hi, Although I was very happy with FreeIPA on F12, due to compliance issues I had to upgrade our master server from F12 to F13. I tried several methods, and only yum upgrade was semi succesful. After upgrade 389 seems to be running fine, with one exception: it stops responding queries after few minutes. All daemons are running fine: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 1057/python tcp 0 0 10.7.30.20:464 0.0.0.0:* LISTEN 1044/ipa_kpasswd tcp 0 0 127.0.0.1:464 0.0.0.0:* LISTEN 1044/ipa_kpasswd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1063/sshd tcp 0 0 0.0.0.0:8089 0.0.0.0:* LISTEN 1121/splunkd tcp 0 0 :::80 :::* LISTEN 1074/httpd tcp 0 0 fe80::d04c:71ff:fe37:3b:464 :::* LISTEN 1044/ipa_kpasswd tcp 0 0 ::1:464 :::* LISTEN 1044/ipa_kpasswd tcp 0 0 :::22 :::* LISTEN 1063/sshd tcp 0 0 :::443 :::* LISTEN 1074/httpd tcp 0 0 :::636 :::* LISTEN 1307/ns-slapd tcp 0 0 :::389 :::* LISTEN 1307/ns-slapd But every connection lokks like this: [root at ipa ~]# telnet localhost 389 Trying ::1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. [root at ipa ~]# telnet localhost 636 Trying ::1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. Connection is closed immediately. [root at ipa-pci ~]# tail /var/log/dirsrv/slapd-QXLPCI/errors [21/Feb/2011:00:17:25 +0100] - All database threads now stopped [21/Feb/2011:00:17:25 +0100] - slapd stopped. 389-Directory/1.2.7.5 B2010.350.1724 ipa-pci.dc3:636 (/etc/dirsrv/slapd-QXLPCI) I see nothing in the logs: [21/Feb/2011:00:17:27 +0100] - 389-Directory/1.2.7.5 B2010.350.1724 starting up [21/Feb/2011:00:17:27 +0100] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=qxlpci: 20 [21/Feb/2011:00:17:27 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests [21/Feb/2011:00:17:27 +0100] - Listening on All Interfaces port 636 for LDAPS requests [21/Feb/2011:00:18:34 +0100] - conn=51 received a non-LDAP message (tag 0xd, expected 0x30) Dirserver restart helps for few munites. Looks quite serious and I really have no more ideas how to debug it. My setup: 389-ds-base-1.2.7.5-1.fc13.x86_64 ipa-python-1.2.2-4.fc13.x86_64 ipa-client-1.2.2-4.fc13.x86_64 ipa-admintools-1.2.2-4.fc13.x86_64 ipa-server-selinux-1.2.2-4.fc13.x86_64 ipa-server-1.2.2-4.fc13.x86_64 [root at ipa ~]# grep 389 /var/log/yum.log Feb 20 15:35:35 Updated: 389-ds-base-1.2.6.1-2.fc12.x86_64 Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64 Any one have an idea what could be the reason? 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. From rcritten at redhat.com Mon Feb 21 14:09:24 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Feb 2011 09:09:24 -0500 Subject: [Freeipa-users] 389 DS server closing connection after upgrade from Fedora 12 to 13 In-Reply-To: References: Message-ID: <4D627214.1080903@redhat.com> tomasz.napierala at allegro.pl wrote: > Hi, > > Although I was very happy with FreeIPA on F12, due to compliance issues I had to upgrade our master server from F12 to F13. I tried several methods, and only yum upgrade was semi succesful. > After upgrade 389 seems to be running fine, with one exception: it stops responding queries after few minutes. All daemons are running fine: > > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name > tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 1057/python > tcp 0 0 10.7.30.20:464 0.0.0.0:* LISTEN 1044/ipa_kpasswd > tcp 0 0 127.0.0.1:464 0.0.0.0:* LISTEN 1044/ipa_kpasswd > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1063/sshd > tcp 0 0 0.0.0.0:8089 0.0.0.0:* LISTEN 1121/splunkd > tcp 0 0 :::80 :::* LISTEN 1074/httpd > tcp 0 0 fe80::d04c:71ff:fe37:3b:464 :::* LISTEN 1044/ipa_kpasswd > tcp 0 0 ::1:464 :::* LISTEN 1044/ipa_kpasswd > tcp 0 0 :::22 :::* LISTEN 1063/sshd > tcp 0 0 :::443 :::* LISTEN 1074/httpd > tcp 0 0 :::636 :::* LISTEN 1307/ns-slapd > tcp 0 0 :::389 :::* LISTEN 1307/ns-slapd > > But every connection lokks like this: > > [root at ipa ~]# telnet localhost 389 > Trying ::1... > Connected to localhost. > Escape character is '^]'. > Connection closed by foreign host. > [root at ipa ~]# telnet localhost 636 > Trying ::1... > Connected to localhost. > Escape character is '^]'. > Connection closed by foreign host. > > Connection is closed immediately. > [root at ipa-pci ~]# tail /var/log/dirsrv/slapd-QXLPCI/errors > [21/Feb/2011:00:17:25 +0100] - All database threads now stopped > [21/Feb/2011:00:17:25 +0100] - slapd stopped. > 389-Directory/1.2.7.5 B2010.350.1724 > ipa-pci.dc3:636 (/etc/dirsrv/slapd-QXLPCI) > > I see nothing in the logs: > > [21/Feb/2011:00:17:27 +0100] - 389-Directory/1.2.7.5 B2010.350.1724 starting up > [21/Feb/2011:00:17:27 +0100] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=qxlpci: 20 > [21/Feb/2011:00:17:27 +0100] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [21/Feb/2011:00:17:27 +0100] - Listening on All Interfaces port 636 for LDAPS requests > [21/Feb/2011:00:18:34 +0100] - conn=51 received a non-LDAP message (tag 0xd, expected 0x30) > > Dirserver restart helps for few munites. > Looks quite serious and I really have no more ideas how to debug it. > My setup: > 389-ds-base-1.2.7.5-1.fc13.x86_64 > ipa-python-1.2.2-4.fc13.x86_64 > ipa-client-1.2.2-4.fc13.x86_64 > ipa-admintools-1.2.2-4.fc13.x86_64 > ipa-server-selinux-1.2.2-4.fc13.x86_64 > ipa-server-1.2.2-4.fc13.x86_64 > > [root at ipa ~]# grep 389 /var/log/yum.log > Feb 20 15:35:35 Updated: 389-ds-base-1.2.6.1-2.fc12.x86_64 > Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64 > > Any one have an idea what could be the reason? > > Regards, Boy, it could be a lot of things. I'd start by checking the SELinux log in /var/log/audit.log. Are you running in permissive or enforcing mode? telnet is not very effective on SSL ports, you might want to try a real search. This assumes your IPA CA cert is in /etc/ipa/ca.crt: $ TLS_CACERT=/etc/ipa/ca.crt ldapsearch -H ldaps://`hostname` -x -b 'dc=example,dc=com' uid=admin Is the ns-slapd process going away or just refusing to accept connections? Is anything in the access log after you try one? rob From rcritten at redhat.com Mon Feb 21 14:36:15 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Feb 2011 09:36:15 -0500 Subject: [Freeipa-users] Changing IP address of master server In-Reply-To: References: Message-ID: <4D62785F.7070400@redhat.com> tomasz.napierala at allegro.pl wrote: > Hi, > > Im sure I read about it somwhere, but I can't find any references now. > Is it possible to change IP addres of master server? If so, is ot matter of changing system IP and updating DNS, or should I be aware of any other steps? > > Regards, Yes, if you're only changing the IP then updating /etc/hosts, the system config and DNS should be enough. rob From ssorce at redhat.com Mon Feb 21 15:10:06 2011 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 21 Feb 2011 10:10:06 -0500 Subject: [Freeipa-users] 389 DS server closing connection after upgrade from Fedora 12 to 13 In-Reply-To: References: Message-ID: <20110221101006.0217ac18@willson.li.ssimo.org> On Mon, 21 Feb 2011 02:07:36 +0100 "tomasz.napierala at allegro.pl" wrote: > Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64 > > Any one have an idea what could be the reason? If I remember correctly, some people reported similar issues with 1.2.7 It doesn't affect everyone but afaik the lock-up bug has been fixed in the 1.2.8 alphas. You may want to try to upgrade 389ds with the version in updates-testing and see if that fixes this problem. Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Mon Feb 21 16:30:36 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 21 Feb 2011 08:30:36 -0800 Subject: [Freeipa-users] 389 DS server closing connection after upgrade from Fedora 12 to 13 In-Reply-To: <20110221101006.0217ac18@willson.li.ssimo.org> References: <20110221101006.0217ac18@willson.li.ssimo.org> Message-ID: <4D62932C.3090401@redhat.com> On 02/21/2011 07:10 AM, Simo Sorce wrote: > On Mon, 21 Feb 2011 02:07:36 +0100 > "tomasz.napierala at allegro.pl" wrote: > >> Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64 >> >> Any one have an idea what could be the reason? > If I remember correctly, some people reported similar issues with 1.2.7 > It doesn't affect everyone but afaik the lock-up bug has been fixed in > the 1.2.8 alphas. Yes, I believe that this may be https://bugzilla.redhat.com/show_bug.cgi?id=668619. It will be fixed in 389-ds-base-1.2.8, which has alpha builds with the fix available now. > You may want to try to upgrade 389ds with the version in > updates-testing and see if that fixes this problem. > > Simo. > From tomasz.napierala at allegro.pl Mon Feb 21 22:55:09 2011 From: tomasz.napierala at allegro.pl (tomasz.napierala at allegro.pl) Date: Mon, 21 Feb 2011 23:55:09 +0100 Subject: [Freeipa-users] 389 DS server closing connection after upgrade from Fedora 12 to 13 In-Reply-To: <4D627214.1080903@redhat.com> References: <4D627214.1080903@redhat.com> Message-ID: <93899E09-91CB-4C57-A087-06F806C15DBF@allegro.pl> On 2011-02-21, at 15:09, Rob Crittenden wrote: > Boy, it could be a lot of things. I'd start by checking the SELinux log > in /var/log/audit.log. Are you running in permissive or enforcing mode? SELinux was disabled during the test > telnet is not very effective on SSL ports, you might want to try a real > search. This assumes your IPA CA cert is in /etc/ipa/ca.crt: > > $ TLS_CACERT=/etc/ipa/ca.crt ldapsearch -H ldaps://`hostname` -x -b > 'dc=example,dc=com' uid=admin It does not work. Connection is closing immediately. It does not work for ldap either. I attached telnet part just to show that connection is closing, as you can see it there clearly. > Is the ns-slapd process going away or just refusing to accept > connections? Is anything in the access log after you try one? > tcp 0 0 :::636 :::* LISTEN 1307/ns-slapd > tcp 0 0 :::389 :::* LISTEN 1307/ns-slapd As you can see in my original message, ns-slapd is running, listening, accepting connections, but closing them immediately. I will check alpha version mentioned by Simo. Regards, -- Tomasz Z. Napiera?a Systems Architecture Engineer, IT Infrastructure Department Allegro Team http://www.allegro.pl/ From tomasz.napierala at allegro.pl Mon Feb 21 23:07:12 2011 From: tomasz.napierala at allegro.pl (tomasz.napierala at allegro.pl) Date: Tue, 22 Feb 2011 00:07:12 +0100 Subject: [Freeipa-users] Changing IP address of master server In-Reply-To: <4D62785F.7070400@redhat.com> References: <4D62785F.7070400@redhat.com> Message-ID: On 2011-02-21, at 15:36, Rob Crittenden wrote: > tomasz.napierala at allegro.pl wrote: >> Hi, >> >> Im sure I read about it somwhere, but I can't find any references now. >> Is it possible to change IP addres of master server? If so, is ot matter of changing system IP and updating DNS, or should I be aware of any other steps? >> >> Regards, > > Yes, if you're only changing the IP then updating /etc/hosts, the system > config and DNS should be enough. Worked like a charm. Thanks 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. From rcritten at redhat.com Mon Feb 21 23:08:25 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Feb 2011 18:08:25 -0500 Subject: [Freeipa-users] Changing IP address of master server In-Reply-To: References: <4D62785F.7070400@redhat.com> Message-ID: <4D62F069.20206@redhat.com> tomasz.napierala at allegro.pl wrote: > > On 2011-02-21, at 15:36, Rob Crittenden wrote: > >> tomasz.napierala at allegro.pl wrote: >>> Hi, >>> >>> Im sure I read about it somwhere, but I can't find any references now. >>> Is it possible to change IP addres of master server? If so, is ot matter of changing system IP and updating DNS, or should I be aware of any other steps? >>> >>> Regards, >> >> Yes, if you're only changing the IP then updating /etc/hosts, the system >> config and DNS should be enough. > > > Worked like a charm. Thanks > > Regards, Great, thanks for the follow-up. rob From Steven.Jones at vuw.ac.nz Mon Feb 28 00:55:13 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 28 Feb 2011 13:55:13 +1300 Subject: [Freeipa-users] While attempting to make a replica....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> [root at fed14-64-ipam001 jonesst1]# ipa-replica-prepare fed14-64-ipam002.ipa.ac.nz Directory Manager (existing master) password: Preparing replica for fed14-64-ipam002.ipa.ac.nz from fed14-64-ipam001.ipa.ac.nz Creating SSL certificate for the Directory Server ipa: INFO: sslget 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient' Creating SSL certificate for the Web Server ipa: INFO: sslget 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient' preparation of replica failed: cannot connect to 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -12285] (SSL_ERROR_NO_CERTIFICATE) Unable to find the certificate or key necessary for authentication. cannot connect to 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -12285] (SSL_ERROR_NO_CERTIFICATE) Unable to find the certificate or key necessary for authentication. File "/usr/sbin/ipa-replica-prepare", line 431, in main() File "/usr/sbin/ipa-replica-prepare", line 363, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "httpcert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 136, in export_certdb raise e If I go to the URL I get, ================ The Certificate System has encountered an unrecoverable error. Error Message: java.lang.NullPointerException Please contact your local administrator for assistance. ================ ??? regards From Steven.Jones at vuw.ac.nz Mon Feb 28 03:22:06 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 28 Feb 2011 16:22:06 +1300 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> I have just built these 2 fed14 to act as a server and client and run yum update....so they should be as closely sync'd as possible... =============client=========== [root at fed14-64-ipacl01 ~]# ipa-client-install Discovery was successful! Realm: IPA.AC.NZ DNS Domain: ipa.ac.nz IPA Server: fed14-64-ipam001.ipa.ac.nz BaseDN: dc=ipa,dc=ac,dc=nz Continue to configure the system with these values? [no]: yes Enrollment principal: admin Password for admin at IPA.AC.NZ: Joining realm failed because of failing XML-RPC request. This error may be caused by incompatible server/client major versions. [root at fed14-64-ipacl01 ~]# date Mon Feb 28 03:12:57 NZDT 2011 [root at fed14-64-ipacl01 ~]# =============server=========== 8><-------- is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates-testing/prestodelta | 30 kB 00:00 Processing delta metadata Package(s) data still to download: 304 k (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm | 175 kB 00:00 (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm | 129 kB 00:00 ------------------------------------------------------------------------------------------------------------------------ Total 789 kB/s | 304 kB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 1/4 Updating : nss-softokn-3.12.9-5.fc14.x86_64 2/4 Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 3/4 Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 4/4 Updated: nss-softokn.x86_64 0:3.12.9-5.fc14 nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 Complete! [root at fed14-64-ipam001 tmp]# date Mon Feb 28 03:13:02 NZDT 2011 [root at fed14-64-ipam001 tmp]# ============ So nothing major on the server needs updating and the client is bang up to date, time stamp is close.... regards From Steven.Jones at vuw.ac.nz Mon Feb 28 03:34:01 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 28 Feb 2011 16:34:01 +1300 Subject: [Freeipa-users] Freeipa fails to start after a reboot In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB718@STAWINCOEXMAIL1.staff.vuw.ac.nz> What scrips need to be runa and in what order to start the primary ipa server? regards From davido at redhat.com Mon Feb 28 06:39:10 2011 From: davido at redhat.com (David O'Brien) Date: Mon, 28 Feb 2011 16:39:10 +1000 Subject: [Freeipa-users] Freeipa fails to start after a reboot In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB718@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB718@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6B430E.5060602@redhat.com> Steven Jones wrote: > What scrips need to be runa and in what order to start the primary ipa > server? > > regards > if you run "service ipactl start" it should start all the required ipa services in the correct order. -- David O'Brien Red Hat Asia Pacific Pty Ltd +61 7 3514 8189 "He who asks is a fool for five minutes, but he who does not ask remains a fool forever." ~ Chinese proverb From dpal at redhat.com Mon Feb 28 15:42:03 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 28 Feb 2011 10:42:03 -0500 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6BC24B.9060803@redhat.com> On 02/27/2011 10:22 PM, Steven Jones wrote: > I have just built these 2 fed14 to act as a server and client and run > yum update....so they should be as closely sync'd as possible... > > =============client=========== > > [root at fed14-64-ipacl01 ~]# ipa-client-install > Discovery was successful! > Realm: IPA.AC.NZ > DNS Domain: ipa.ac.nz > IPA Server: fed14-64-ipam001.ipa.ac.nz > BaseDN: dc=ipa,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > Password for admin at IPA.AC.NZ: > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > [root at fed14-64-ipacl01 ~]# date > Mon Feb 28 03:12:57 NZDT 2011 > [root at fed14-64-ipacl01 ~]# > > > =============server=========== > > 8><-------- > is this ok [y/N]: y > Downloading Packages: > Setting up and reading Presto delta metadata > updates-testing/prestodelta > | 30 kB 00:00 > Processing delta metadata > Package(s) data still to download: 304 k > (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm > | 175 kB 00:00 > (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm > | 129 kB 00:00 > ------------------------------------------------------------------------------------------------------------------------ > Total > 789 kB/s | 304 kB 00:00 > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 > 1/4 > Updating : nss-softokn-3.12.9-5.fc14.x86_64 > 2/4 > Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 > 3/4 > Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 > 4/4 > > Updated: > nss-softokn.x86_64 0:3.12.9-5.fc14 > nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 > > Complete! > [root at fed14-64-ipam001 tmp]# date > Mon Feb 28 03:13:02 NZDT 2011 > [root at fed14-64-ipam001 tmp]# > ============ > > So nothing major on the server needs updating and the client is bang up > to date, time stamp is close.... > > regards > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > Recent changes and fixes in the server and client communication require the updates to both. Which versions do you have? -- 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 Mon Feb 28 15:43:22 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Feb 2011 10:43:22 -0500 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6BC29A.5020206@redhat.com> Steven Jones wrote: > I have just built these 2 fed14 to act as a server and client and run > yum update....so they should be as closely sync'd as possible... > > =============client=========== > > [root at fed14-64-ipacl01 ~]# ipa-client-install > Discovery was successful! > Realm: IPA.AC.NZ > DNS Domain: ipa.ac.nz > IPA Server: fed14-64-ipam001.ipa.ac.nz > BaseDN: dc=ipa,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > Password for admin at IPA.AC.NZ: > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > [root at fed14-64-ipacl01 ~]# date > Mon Feb 28 03:12:57 NZDT 2011 > [root at fed14-64-ipacl01 ~]# > > > =============server=========== > > 8><-------- > is this ok [y/N]: y > Downloading Packages: > Setting up and reading Presto delta metadata > updates-testing/prestodelta > | 30 kB 00:00 > Processing delta metadata > Package(s) data still to download: 304 k > (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm > | 175 kB 00:00 > (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm > | 129 kB 00:00 > ------------------------------------------------------------------------------------------------------------------------ > Total > 789 kB/s | 304 kB 00:00 > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 > 1/4 > Updating : nss-softokn-3.12.9-5.fc14.x86_64 > 2/4 > Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 > 3/4 > Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 > 4/4 > > Updated: > nss-softokn.x86_64 0:3.12.9-5.fc14 > nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 > > Complete! > [root at fed14-64-ipam001 tmp]# date > Mon Feb 28 03:13:02 NZDT 2011 > [root at fed14-64-ipam001 tmp]# > ============ > > So nothing major on the server needs updating and the client is bang up > to date, time stamp is close.... > > regards The client and server packages need to be the same version. We realized that we had re-used an OID and had to change the OID used to register the enrollment OID. So the client package needs to be the same version as the server, for now anyway. rob From rcritten at redhat.com Mon Feb 28 15:44:18 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Feb 2011 10:44:18 -0500 Subject: [Freeipa-users] Freeipa fails to start after a reboot In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB718@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB718@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6BC2D2.1030203@redhat.com> Steven Jones wrote: > What scrips need to be runa and in what order to start the primary ipa > server? > > regards The ipa script in /etc/init.d should handle startup during a reboot. Alternatively /usr/sbin/ipactl can do the same thing. Can you tell which service(s) didn't start at boot? rob From rcritten at redhat.com Mon Feb 28 15:50:48 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Feb 2011 10:50:48 -0500 Subject: [Freeipa-users] While attempting to make a replica....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6BC458.8080509@redhat.com> Steven Jones wrote: > > [root at fed14-64-ipam001 jonesst1]# ipa-replica-prepare > fed14-64-ipam002.ipa.ac.nz > Directory Manager (existing master) password: > > Preparing replica for fed14-64-ipam002.ipa.ac.nz from > fed14-64-ipam001.ipa.ac.nz > Creating SSL certificate for the Directory Server > ipa: INFO: sslget > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient' > Creating SSL certificate for the Web Server > ipa: INFO: sslget > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient' > preparation of replica failed: cannot connect to > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -12285] (SSL_ERROR_NO_CERTIFICATE) Unable to find the certificate or key necessary for authentication. > cannot connect to > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -12285] (SSL_ERROR_NO_CERTIFICATE) Unable to find the certificate or key necessary for authentication. > File "/usr/sbin/ipa-replica-prepare", line 431, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 363, in main > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "httpcert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-prepare", line 136, in export_certdb > raise e > > > If I go to the URL I get, > > ================ > > The Certificate System has encountered an unrecoverable error. > > Error Message: > java.lang.NullPointerException > > Please contact your local administrator for assistance. > ================ > > ??? > > regards Can you provide the output of: # certutil -L -d /etc/httpd/alias During installation dogtag provides us with an RA agent certificate that we use to communicate with the CA. This certificate should be stored in /etc/httpd/alias. rob From Steven.Jones at vuw.ac.nz Mon Feb 28 19:24:44 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 1 Mar 2011 08:24:44 +1300 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <4D6BC29A.5020206@redhat.com> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC29A.5020206@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71A@STAWINCOEXMAIL1.staff.vuw.ac.nz> Hi, The point is both the client and the server are up to date in terms of patches from teh repo. So your repo is not consistent and needs fixing...... regards On Mon, 2011-02-28 at 10:43 -0500, Rob Crittenden wrote: > Steven Jones wrote: > > I have just built these 2 fed14 to act as a server and client and run > > yum update....so they should be as closely sync'd as possible... > > > > =============client=========== > > > > [root at fed14-64-ipacl01 ~]# ipa-client-install > > Discovery was successful! > > Realm: IPA.AC.NZ > > DNS Domain: ipa.ac.nz > > IPA Server: fed14-64-ipam001.ipa.ac.nz > > BaseDN: dc=ipa,dc=ac,dc=nz > > > > > > Continue to configure the system with these values? [no]: yes > > Enrollment principal: admin > > Password for admin at IPA.AC.NZ: > > > > Joining realm failed because of failing XML-RPC request. > > This error may be caused by incompatible server/client major versions. > > [root at fed14-64-ipacl01 ~]# date > > Mon Feb 28 03:12:57 NZDT 2011 > > [root at fed14-64-ipacl01 ~]# > > > > > > =============server=========== > > > > 8><-------- > > is this ok [y/N]: y > > Downloading Packages: > > Setting up and reading Presto delta metadata > > updates-testing/prestodelta > > | 30 kB 00:00 > > Processing delta metadata > > Package(s) data still to download: 304 k > > (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm > > | 175 kB 00:00 > > (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm > > | 129 kB 00:00 > > ------------------------------------------------------------------------------------------------------------------------ > > Total > > 789 kB/s | 304 kB 00:00 > > Running rpm_check_debug > > Running Transaction Test > > Transaction Test Succeeded > > Running Transaction > > Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 > > 1/4 > > Updating : nss-softokn-3.12.9-5.fc14.x86_64 > > 2/4 > > Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 > > 3/4 > > Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 > > 4/4 > > > > Updated: > > nss-softokn.x86_64 0:3.12.9-5.fc14 > > nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 > > > > Complete! > > [root at fed14-64-ipam001 tmp]# date > > Mon Feb 28 03:13:02 NZDT 2011 > > [root at fed14-64-ipam001 tmp]# > > ============ > > > > So nothing major on the server needs updating and the client is bang up > > to date, time stamp is close.... > > > > regards > > The client and server packages need to be the same version. We realized > that we had re-used an OID and had to change the OID used to register > the enrollment OID. So the client package needs to be the same version > as the server, for now anyway. > > rob From Steven.Jones at vuw.ac.nz Mon Feb 28 19:26:38 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 1 Mar 2011 08:26:38 +1300 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <4D6BC24B.9060803@redhat.com> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC24B.9060803@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71B@STAWINCOEXMAIL1.staff.vuw.ac.nz> Hi, How do I tell? ie what are the package names? but apart from that both are yum updated from the same repo, so this means your repo is probably the problem.... regards On Mon, 2011-02-28 at 10:42 -0500, Dmitri Pal wrote: > On 02/27/2011 10:22 PM, Steven Jones wrote: > > I have just built these 2 fed14 to act as a server and client and run > > yum update....so they should be as closely sync'd as possible... > > > > =============client=========== > > > > [root at fed14-64-ipacl01 ~]# ipa-client-install > > Discovery was successful! > > Realm: IPA.AC.NZ > > DNS Domain: ipa.ac.nz > > IPA Server: fed14-64-ipam001.ipa.ac.nz > > BaseDN: dc=ipa,dc=ac,dc=nz > > > > > > Continue to configure the system with these values? [no]: yes > > Enrollment principal: admin > > Password for admin at IPA.AC.NZ: > > > > Joining realm failed because of failing XML-RPC request. > > This error may be caused by incompatible server/client major versions. > > [root at fed14-64-ipacl01 ~]# date > > Mon Feb 28 03:12:57 NZDT 2011 > > [root at fed14-64-ipacl01 ~]# > > > > > > =============server=========== > > > > 8><-------- > > is this ok [y/N]: y > > Downloading Packages: > > Setting up and reading Presto delta metadata > > updates-testing/prestodelta > > | 30 kB 00:00 > > Processing delta metadata > > Package(s) data still to download: 304 k > > (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm > > | 175 kB 00:00 > > (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm > > | 129 kB 00:00 > > ------------------------------------------------------------------------------------------------------------------------ > > Total > > 789 kB/s | 304 kB 00:00 > > Running rpm_check_debug > > Running Transaction Test > > Transaction Test Succeeded > > Running Transaction > > Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 > > 1/4 > > Updating : nss-softokn-3.12.9-5.fc14.x86_64 > > 2/4 > > Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 > > 3/4 > > Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 > > 4/4 > > > > Updated: > > nss-softokn.x86_64 0:3.12.9-5.fc14 > > nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 > > > > Complete! > > [root at fed14-64-ipam001 tmp]# date > > Mon Feb 28 03:13:02 NZDT 2011 > > [root at fed14-64-ipam001 tmp]# > > ============ > > > > So nothing major on the server needs updating and the client is bang up > > to date, time stamp is close.... > > > > regards > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > Recent changes and fixes in the server and client communication require > the updates to both. > Which versions do you have? > > -- > 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 rcritten at redhat.com Mon Feb 28 19:30:02 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Feb 2011 14:30:02 -0500 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71A@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC29A.5020206@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71A@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6BF7BA.7090902@redhat.com> Steven Jones wrote: > Hi, > > The point is both the client and the server are up to date in terms of > patches from teh repo. > > So your repo is not consistent and needs fixing...... Yes, but what version are you using and what repo, the ipa-devel repo? rob > > regards > > > On Mon, 2011-02-28 at 10:43 -0500, Rob Crittenden wrote: >> Steven Jones wrote: >>> I have just built these 2 fed14 to act as a server and client and run >>> yum update....so they should be as closely sync'd as possible... >>> >>> =============client=========== >>> >>> [root at fed14-64-ipacl01 ~]# ipa-client-install >>> Discovery was successful! >>> Realm: IPA.AC.NZ >>> DNS Domain: ipa.ac.nz >>> IPA Server: fed14-64-ipam001.ipa.ac.nz >>> BaseDN: dc=ipa,dc=ac,dc=nz >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> Enrollment principal: admin >>> Password for admin at IPA.AC.NZ: >>> >>> Joining realm failed because of failing XML-RPC request. >>> This error may be caused by incompatible server/client major versions. >>> [root at fed14-64-ipacl01 ~]# date >>> Mon Feb 28 03:12:57 NZDT 2011 >>> [root at fed14-64-ipacl01 ~]# >>> >>> >>> =============server=========== >>> >>> 8><-------- >>> is this ok [y/N]: y >>> Downloading Packages: >>> Setting up and reading Presto delta metadata >>> updates-testing/prestodelta >>> | 30 kB 00:00 >>> Processing delta metadata >>> Package(s) data still to download: 304 k >>> (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm >>> | 175 kB 00:00 >>> (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm >>> | 129 kB 00:00 >>> ------------------------------------------------------------------------------------------------------------------------ >>> Total >>> 789 kB/s | 304 kB 00:00 >>> Running rpm_check_debug >>> Running Transaction Test >>> Transaction Test Succeeded >>> Running Transaction >>> Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 >>> 1/4 >>> Updating : nss-softokn-3.12.9-5.fc14.x86_64 >>> 2/4 >>> Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 >>> 3/4 >>> Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 >>> 4/4 >>> >>> Updated: >>> nss-softokn.x86_64 0:3.12.9-5.fc14 >>> nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 >>> >>> Complete! >>> [root at fed14-64-ipam001 tmp]# date >>> Mon Feb 28 03:13:02 NZDT 2011 >>> [root at fed14-64-ipam001 tmp]# >>> ============ >>> >>> So nothing major on the server needs updating and the client is bang up >>> to date, time stamp is close.... >>> >>> regards >> >> The client and server packages need to be the same version. We realized >> that we had re-used an OID and had to change the OID used to register >> the enrollment OID. So the client package needs to be the same version >> as the server, for now anyway. >> >> rob > From rcritten at redhat.com Mon Feb 28 19:31:30 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Feb 2011 14:31:30 -0500 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71B@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC24B.9060803@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71B@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4D6BF812.2080401@redhat.com> Steven Jones wrote: > Hi, > > How do I tell? > > ie what are the package names? > > but apart from that both are yum updated from the same repo, so this > means your repo is probably the problem.... On the client: rpm -q freeipa-client On the server: rpm -q freeipa-server > > regards > > On Mon, 2011-02-28 at 10:42 -0500, Dmitri Pal wrote: >> On 02/27/2011 10:22 PM, Steven Jones wrote: >>> I have just built these 2 fed14 to act as a server and client and run >>> yum update....so they should be as closely sync'd as possible... >>> >>> =============client=========== >>> >>> [root at fed14-64-ipacl01 ~]# ipa-client-install >>> Discovery was successful! >>> Realm: IPA.AC.NZ >>> DNS Domain: ipa.ac.nz >>> IPA Server: fed14-64-ipam001.ipa.ac.nz >>> BaseDN: dc=ipa,dc=ac,dc=nz >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> Enrollment principal: admin >>> Password for admin at IPA.AC.NZ: >>> >>> Joining realm failed because of failing XML-RPC request. >>> This error may be caused by incompatible server/client major versions. >>> [root at fed14-64-ipacl01 ~]# date >>> Mon Feb 28 03:12:57 NZDT 2011 >>> [root at fed14-64-ipacl01 ~]# >>> >>> >>> =============server=========== >>> >>> 8><-------- >>> is this ok [y/N]: y >>> Downloading Packages: >>> Setting up and reading Presto delta metadata >>> updates-testing/prestodelta >>> | 30 kB 00:00 >>> Processing delta metadata >>> Package(s) data still to download: 304 k >>> (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm >>> | 175 kB 00:00 >>> (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm >>> | 129 kB 00:00 >>> ------------------------------------------------------------------------------------------------------------------------ >>> Total >>> 789 kB/s | 304 kB 00:00 >>> Running rpm_check_debug >>> Running Transaction Test >>> Transaction Test Succeeded >>> Running Transaction >>> Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 >>> 1/4 >>> Updating : nss-softokn-3.12.9-5.fc14.x86_64 >>> 2/4 >>> Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 >>> 3/4 >>> Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 >>> 4/4 >>> >>> Updated: >>> nss-softokn.x86_64 0:3.12.9-5.fc14 >>> nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 >>> >>> Complete! >>> [root at fed14-64-ipam001 tmp]# date >>> Mon Feb 28 03:13:02 NZDT 2011 >>> [root at fed14-64-ipam001 tmp]# >>> ============ >>> >>> So nothing major on the server needs updating and the client is bang up >>> to date, time stamp is close.... >>> >>> regards >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> Recent changes and fixes in the server and client communication require >> the updates to both. >> Which versions do you have? >> >> -- >> 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 Steven.Jones at vuw.ac.nz Mon Feb 28 19:40:02 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 1 Mar 2011 08:40:02 +1300 Subject: [Freeipa-users] Freeipa fails to start after a reboot In-Reply-To: <4D6B430E.5060602@redhat.com> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB718@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6B430E.5060602@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71C@STAWINCOEXMAIL1.staff.vuw.ac.nz> So Im having fun......... Looks like the rpm didnt install properly? or the install script failed? strange because it seemed to be running before I rebooted....so something has gone wrong after teh install? [root at fed14-64-ipam001 init.d]# ipa start ipa: ERROR: unknown command 'start' [root at fed14-64-ipam001 init.d]# ./ipa start Starting Directory Service Starting dirsrv: IPA-AC-NZ... [ OK ] PKI-IPA... [ OK ] Error retrieving list of services {'matched': 'cn=masters,cn=ipa,cn=etc,dc=ipa,dc=ac,dc=nz', 'desc': 'No such object'} Is IPA installed? Failed to read data from Directory Service Shutting down Shutting down dirsrv: IPA-AC-NZ... [ OK ] PKI-IPA... [ OK ] [root at fed14-64-ipam001 init.d]# service ipactl start ipactl: unrecognized service ]# ============ So find gets me the script.......... [root at fed14-64-ipam001 init.d]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: IPA-AC-NZ... [ OK ] PKI-IPA... [ OK ] Error retrieving list of services {'matched': 'cn=masters,cn=ipa,cn=etc,dc=ipa,dc=ac,dc=nz', 'desc': 'No such object'} Is IPA installed? Failed to read data from Directory Service Shutting down Shutting down dirsrv: IPA-AC-NZ... [ OK ] PKI-IPA... [ OK ] [root at fed14-64-ipam001 init.d]# On Mon, 2011-02-28 at 16:39 +1000, David O'Brien wrote: > Steven Jones wrote: > > What scrips need to be runa and in what order to start the primary ipa > > server? > > > > regards > > > > if you run "service ipactl start" it should start all the required ipa > services in the correct order. > > -- > > David O'Brien > Red Hat Asia Pacific Pty Ltd > +61 7 3514 8189 > > > "He who asks is a fool for five minutes, but he who does not ask remains > a fool forever." > ~ Chinese proverb From Steven.Jones at vuw.ac.nz Mon Feb 28 19:41:02 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 1 Mar 2011 08:41:02 +1300 Subject: [Freeipa-users] While attempting to make a replica....I get this failure.... In-Reply-To: <4D6BC458.8080509@redhat.com> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC458.8080509@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71D@STAWINCOEXMAIL1.staff.vuw.ac.nz> =========== [root at fed14-64-ipam001 init.d]# certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Signing-Cert u,u,u IPA.AC.NZ IPA CA CT,C,C ipaCert u,u,u Server-Cert u,u,u [root at fed14-64-ipam001 init.d]# =========== regards On Mon, 2011-02-28 at 10:50 -0500, Rob Crittenden wrote: > Steven Jones wrote: > > > > [root at fed14-64-ipam001 jonesst1]# ipa-replica-prepare > > fed14-64-ipam002.ipa.ac.nz > > Directory Manager (existing master) password: > > > > Preparing replica for fed14-64-ipam002.ipa.ac.nz from > > fed14-64-ipam001.ipa.ac.nz > > Creating SSL certificate for the Directory Server > > ipa: INFO: sslget > > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient' > > Creating SSL certificate for the Web Server > > ipa: INFO: sslget > > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient' > > preparation of replica failed: cannot connect to > > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -12285] (SSL_ERROR_NO_CERTIFICATE) Unable to find the certificate or key necessary for authentication. > > cannot connect to > > 'https://fed14-64-ipam001.ipa.ac.nz:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -12285] (SSL_ERROR_NO_CERTIFICATE) Unable to find the certificate or key necessary for authentication. > > File "/usr/sbin/ipa-replica-prepare", line 431, in > > main() > > > > File "/usr/sbin/ipa-replica-prepare", line 363, in main > > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "httpcert", > > replica_fqdn, subject_base) > > > > File "/usr/sbin/ipa-replica-prepare", line 136, in export_certdb > > raise e > > > > > > If I go to the URL I get, > > > > ================ > > > > The Certificate System has encountered an unrecoverable error. > > > > Error Message: > > java.lang.NullPointerException > > > > Please contact your local administrator for assistance. > > ================ > > > > ??? > > > > regards > > Can you provide the output of: > > # certutil -L -d /etc/httpd/alias > > During installation dogtag provides us with an RA agent certificate that > we use to communicate with the CA. This certificate should be stored in > /etc/httpd/alias. > > rob From Steven.Jones at vuw.ac.nz Mon Feb 28 20:12:00 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 1 Mar 2011 09:12:00 +1300 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <4D6BF7BA.7090902@redhat.com> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC29A.5020206@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71A@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BF7BA.7090902@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71F@STAWINCOEXMAIL1.staff.vuw.ac.nz> Hi, As per your website and I SCP'd the freeipa-devel.repo over to the client and the replica from the master.... regards On Mon, 2011-02-28 at 14:30 -0500, Rob Crittenden wrote: > Steven Jones wrote: > > Hi, > > > > The point is both the client and the server are up to date in terms of > > patches from teh repo. > > > > So your repo is not consistent and needs fixing...... > > Yes, but what version are you using and what repo, the ipa-devel repo? > > rob > > > > > regards > > > > > > On Mon, 2011-02-28 at 10:43 -0500, Rob Crittenden wrote: > >> Steven Jones wrote: > >>> I have just built these 2 fed14 to act as a server and client and run > >>> yum update....so they should be as closely sync'd as possible... > >>> > >>> =============client=========== > >>> > >>> [root at fed14-64-ipacl01 ~]# ipa-client-install > >>> Discovery was successful! > >>> Realm: IPA.AC.NZ > >>> DNS Domain: ipa.ac.nz > >>> IPA Server: fed14-64-ipam001.ipa.ac.nz > >>> BaseDN: dc=ipa,dc=ac,dc=nz > >>> > >>> > >>> Continue to configure the system with these values? [no]: yes > >>> Enrollment principal: admin > >>> Password for admin at IPA.AC.NZ: > >>> > >>> Joining realm failed because of failing XML-RPC request. > >>> This error may be caused by incompatible server/client major versions. > >>> [root at fed14-64-ipacl01 ~]# date > >>> Mon Feb 28 03:12:57 NZDT 2011 > >>> [root at fed14-64-ipacl01 ~]# > >>> > >>> > >>> =============server=========== > >>> > >>> 8><-------- > >>> is this ok [y/N]: y > >>> Downloading Packages: > >>> Setting up and reading Presto delta metadata > >>> updates-testing/prestodelta > >>> | 30 kB 00:00 > >>> Processing delta metadata > >>> Package(s) data still to download: 304 k > >>> (1/2): nss-softokn-3.12.9-5.fc14.x86_64.rpm > >>> | 175 kB 00:00 > >>> (2/2): nss-softokn-freebl-3.12.9-5.fc14.x86_64.rpm > >>> | 129 kB 00:00 > >>> ------------------------------------------------------------------------------------------------------------------------ > >>> Total > >>> 789 kB/s | 304 kB 00:00 > >>> Running rpm_check_debug > >>> Running Transaction Test > >>> Transaction Test Succeeded > >>> Running Transaction > >>> Updating : nss-softokn-freebl-3.12.9-5.fc14.x86_64 > >>> 1/4 > >>> Updating : nss-softokn-3.12.9-5.fc14.x86_64 > >>> 2/4 > >>> Cleanup : nss-softokn-3.12.9-4.fc14.x86_64 > >>> 3/4 > >>> Cleanup : nss-softokn-freebl-3.12.9-4.fc14.x86_64 > >>> 4/4 > >>> > >>> Updated: > >>> nss-softokn.x86_64 0:3.12.9-5.fc14 > >>> nss-softokn-freebl.x86_64 0:3.12.9-5.fc14 > >>> > >>> Complete! > >>> [root at fed14-64-ipam001 tmp]# date > >>> Mon Feb 28 03:13:02 NZDT 2011 > >>> [root at fed14-64-ipam001 tmp]# > >>> ============ > >>> > >>> So nothing major on the server needs updating and the client is bang up > >>> to date, time stamp is close.... > >>> > >>> regards > >> > >> The client and server packages need to be the same version. We realized > >> that we had re-used an OID and had to change the OID used to register > >> the enrollment OID. So the client package needs to be the same version > >> as the server, for now anyway. > >> > >> rob > > > From Steven.Jones at vuw.ac.nz Mon Feb 28 20:15:07 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 1 Mar 2011 09:15:07 +1300 Subject: [Freeipa-users] While attempting to join a client ....I get this failure.... In-Reply-To: <4D6BF812.2080401@redhat.com> References: <4D59FC4A.5050603@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6DF@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6E6@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB6ED@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB713@STAWINCOEXMAIL1.staff.vuw.ac.nz> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB717@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BC24B.9060803@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE5C81BEB71B@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4D6BF812.2080401@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE5C81BEB720@STAWINCOEXMAIL1.staff.vuw.ac.nz> 8><-------- > On the client: rpm -q freeipa-client freeipa-client-2.0.0.rc1-0.fc14.x86_64 > On the server: rpm -q freeipa-server freeipa-server-2.0.0.rc1-0.fc14.x86_64 regards From rcritten at redhat.com Mon Feb 28 21:07:49 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Feb 2011 16:07:49 -0500 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Release Candidate 2 Release Message-ID: <4D6C0EA5.3040708@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Release Candidate 2 release of freeIPA 2.0 server [1]. * Binaries are available for F-14 and F-15 [2]. * Please do not hesitate to share feedback, criticism or bugs with us on our mailing list: freeipa-users at redhat.com Main Highlights of the Release Candidate. This release consists primarily of bug fixes and polish across all areas of the project. Modifications include but are not limited to * Make Indirect membership clearer. * Input validation fixes. * WebUI improvements. * Created default Roles. * IPv6 support * Documentation updates Focus of the Release Candidate Testing * There was a Fedora test day for FreeIPA on Feb 15th [3]. These tests are still relevant and feedback would be appreciated. * The following section outlines the areas that we are mostly interested to test [4]. Significant Changes Since RC 1 To see all the tickets addressed since the beta 2 release see [6]. Repositories and Installation * Use the following link to install the RC 2 packages [5]. * FreeIPA relies on the latest versions of the packages currently available from the updates-testing repository. Please make sure to enable this repository before you proceed with installation. Known Issues: * There are known issues that currently prevent FreeIPA from successfully installing with dogtag on F-15 [2]. We will send a separate message when this issue is resolved. The FreeIPA server is installable with the --selfsign option on F-15, or with dogtag on F-14. * Server-generated error messages are not translated yet. * The 'ipa help' command does not support localization. We plan to address all the outstanding tickets before the final 2.0 release. For the complete list see [7]. Thank you, The FreeIPA development team [1] http://www.freeipa.org/page/Downloads [2] dogtag is having issues with systemd: https://bugzilla.redhat.com/show_bug.cgi?id=676330 [3] https://fedoraproject.org/wiki/QA/Fedora_15_test_days [4] https://fedoraproject.org/wiki/Features/FreeIPAv2#How_To_Test [5] http://freeipa.org/downloads/freeipa-devel.repo [6] https://fedorahosted.org/freeipa/query?status=closed&milestone=2.0.2+Bug+fixing+(RC2) [7] https://fedorahosted.org/freeipa/milestone/2.0.3.%20Bug%20Fixing%20%28GA%29