Re: [Freeipa-users] Small bug in ipa-backup file naming
On Monday, July 04, 2016 09:01:29 Petr Spacek wrote: > On 2.7.2016 22:00, Joshua J. Kugler wrote: > > Was just playing around with the ipa-backup scripts for a client. Ran ipa- > > backup, and the backup was successfully placed in /var/lib/ipa/backup/ipa- > > full-2016-07-02-11-54-58. Went to view ipa-full.tar, and discovered it's > > actually a tar.gz file. This is FreeIPA 4.2.0 on CentOS 7. > > > > Is this known? Or should I open a bug? > > Please open a ticket: > https://fedorahosted.org/freeipa/newticket > > Thank you! Done, thanks! https://fedorahosted.org/freeipa/ticket/6031 j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Small bug in ipa-backup file naming
Was just playing around with the ipa-backup scripts for a client. Ran ipa- backup, and the backup was successfully placed in /var/lib/ipa/backup/ipa- full-2016-07-02-11-54-58. Went to view ipa-full.tar, and discovered it's actually a tar.gz file. This is FreeIPA 4.2.0 on CentOS 7. Is this known? Or should I open a bug? j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Password sync settings not working
Thanks. In a case of extreme PEBKAC, I had copied the example and failed to
update the DN. It works now.
j
On Monday, June 13, 2016 09:35:53 Martin Kosek wrote:
> On 06/10/2016 01:59 AM, Joshua J. Kugler wrote:
> > Howdy!
> >
> > We are trying to set up password sync. I have read this:
> >
> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h
> > tml-single/Windows_Integration_Guide/index.html#password-sync
> >
> > I have added that attribute:
> > echo -e 'dn: cn=ipa_pwd_extop,cn=plugins,cn=config\nchangetype:
> > modify\nadd: passSyncManagersDNs\npassSyncManagersDNs:
> > uid=admin,cn=users,cn=accounts,dc=example,dc=com' | ldapmodify -x -D
> > 'cn=Directory Manager' -w {{ ipaserver_dir_admin_password }} -h localhost
> > -p 389
> >
> > However, when I reset a password as the 'admin' user, the user's password
> > is still set to expired. This is CentOS 7 with the latest FreeIPA there.
> >
> > What might I be missing?
>
> I would try to double check that the passSyncManagersDNs is indeed filled
> properly in the plugin configuration. Base ldapsearch will help.
>
> Then I would also recommend checking your global password policy "ipa
> pwpolicy-show" to make sure that you for example do not have the password
> max life set to 0, which would cause this behavior in current FreeIPA
> version.
>
> Martin
--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] Password sync settings not working
Howdy!
We are trying to set up password sync. I have read this:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#password-sync
I have added that attribute:
echo -e 'dn: cn=ipa_pwd_extop,cn=plugins,cn=config\nchangetype: modify\nadd:
passSyncManagersDNs\npassSyncManagersDNs:
uid=admin,cn=users,cn=accounts,dc=example,dc=com' | ldapmodify -x -D
'cn=Directory Manager' -w {{ ipaserver_dir_admin_password }} -h localhost -p
389
However, when I reset a password as the 'admin' user, the user's password is
still set to expired. This is CentOS 7 with the latest FreeIPA there.
What might I be missing?
Thanks!
j
--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Looking for documentation for Python API
On Friday, May 06, 2016 09:04:59 Martin Basti wrote: > since IPA4.2 web UI contains API browser (IPA Server/API Browser) > > So for example for caacl-add: > api.Command.caacl_add(u'argument-ca-acl-name', description=u"optional > description") > > you can try commands in "ipa console" it contains initialized API, just > call api.Command.() > > API.txt provides the same information as API browser, but browser looks > better :) > > Feel free to ask anything, if you identified gaps in docs which are hard > to understand for non-IPA developer feel free report it, or feel free to > create howTo in freeipa.org page. Thanks for the pointers. I'm looking at automating some user and group additions, group editing, etc. Am I right in assuming that anything that uses the api.Command. will require a kinit before it is run, even if it is via the Python API? If I want to use a user/pass from the script itself (and not have a shell script which does kinit, then fires off my Python script) would I be better off hitting the web API with sessions and JSON-RPC as detailed here: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ Put another way, since I want to hit the API from a system that might not have sssd installed, nor has joined the realm, I assume it would be *impossible* to use api.Command. as it relies on a Kerberos ticket? To put it yet another way: is there a way to hand a user/pass to the Python API and authenticate that way. Those are the questions I did not see addressed in the docs that I found. There were lots of examples of invoking commands, but I never saw anything about authenticating to the server before running the commands. Thanks again for the pointers, and if there is documentation I missed, feel free to point me in that direction. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Looking for documentation for Python API
I've been googling and looking through the documentation, but I have yet to find official docs for the Python API for FreeIPA. The first result for 'python' when doing a search on www.freeipa.org is http://www.freeipa.org/page/Python_Coding_Style On that page, there is a link to "freeIPA Python API documentation" which goes to https://www.freeipa.org/page/Documentation#Developer_Documentation That page, however, doesn't have one mention of Python, and only one mention of "API" and that is "How to migrate your code to the new LDAP API" which doesn't seem to be related. I did manage to find https://github.com/encukou/freeipa/tree/master/doc/examples which has a couple (very convoluted) examples, but seems far from complete. There is a freeipa-python RPM, but *WHERE* is the documentation for the Python API. Or should I just shell-out to the 'ipa' command from all my python scripts? :) I found https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ and https://git.fedorahosted.org/cgit/freeipa.git/tree/API.txt so I'm sure I could work up something with python and requests, but I'd prefer to use the official API if I could. :) Any assistance would be great! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Looking for documentation for Python API
[This didn't show up in the archives or list after 12 house, so resending. Sorry if it's a dupe.] I've been googling and looking through the documentation, but I have yet to find official docs for the Python API for FreeIPA. The first result for 'python' when doing a search on www.freeipa.org is http://www.freeipa.org/page/Python_Coding_Style On that page, there is a link to "freeIPA Python API documentation" which goes to https://www.freeipa.org/page/Documentation#Developer_Documentation That page, however, doesn't have one mention of Python, and only one mention of "API" and that is "How to migrate your code to the new LDAP API" which doesn't seem to be related. I did manage to find https://github.com/encukou/freeipa/tree/master/doc/examples which has a couple (very convoluted) examples, but seems far from complete. There is a freeipa-python RPM, but *WHERE* is the documentation for the Python API. Or should I just shell-out to the 'ipa' command from all my python scripts? :) I found https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ and https://git.fedorahosted.org/cgit/freeipa.git/tree/API.txt so I'm sure I could work up something with python and requests, but I'd prefer to use the official API if I could. :) Any assistance would be great! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Unexpiring user passwords
On Sunday, May 01, 2016 12:31:14 Rob Crittenden wrote: > > Is there a way around this? Is there a password synchronization protocol > > that can be used to link up systems that need to have common logins? > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#password-sync Rob - Thank you! For some reason, I had seen that page, and scanned through it, but missed that part. Very grateful! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unexpiring user passwords
I have read this page http://www.freeipa.org/page/New_Passwords_Expired Aside from the fact that the decision should have been left to the company and their policies, and violates the tenant that software should have sane defaults while leaving flexibility to the user, I'm wondering if you can help me. We have a situation where the passwords in FreeIPA need to be synchronized with another system in the company (a database of users, which is the authoritative source for users and passwords). But, from what I read, the documentation is telling me we can't do that, because if we followed this work flow: 1. Users goes to "master DB" and changes their password 2. master DB runs a script which sets password on FreeIPA system 3. User's login is now broken because the password is expired. It is really unfortunate that this design decision was made, because 1. It prevents FreeIPA from being integrated with existing systems (telling people, effectively, you have to use FreeIPA for EVERYTHING or you can't use us at all) 2. It doesn't really improve security as claimed, because if the user's new password is intercepted, the interceptor can use that password to login and change the expired password, still giving access. Is there a way around this? Is there a password synchronization protocol that can be used to link up systems that need to have common logins? Thanks for any help you can offer! j -- Joshua J. Kugler -- Fairbanks, AK Blogs: http://jjncj.com/blog/ (Family) -- http://joshuakugler.com (Geek) Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
A replica must connect to the master for initial setup; after that, the master pushes to the replica. j On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: > What's wrong with your scenario B: master(s) in internal network, they > can contact consumers in DMZ and remote rack and replicate to them. > What do you mean by "to contact for setup" ? > > Ludwig > > On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: > > So, we have a need for replication, but the existing push-only methodology > > doesn't work for us. I suppose our problems could be attributed to over- > > zealous network rules, but it is what it is. :) I'd love to change our > > network policy, but we aren't in charge of network policy, and there is > > no way I'm swaying the person that is. > > > > Topology: > > 1) DMZ environments 1,...,n > > 2) An Internal network > > 3) A remote rack in a data center. > > > > Rules (by "talk" I mean initiate connections to): > > 1) DMZs can talk to each other, somewhat. > > 2) The Internal network can talk to the DMZs > > 3) The DMZ *cannot* connect to the Internal network > > 4) The remote rack of course cannot contact the Internal network, but can > > contact the DMZs. > > > > Scenario A, Master in a DMZ: > > - Slave in the Internal network could contact the DMZ master for replica > > > > setup, but the Master could not contact the slave to push updates > > > > - Slave in the remote rack could contact master in DMZ, but incoming to > > > > remote rack is very restrictive, so it is possible that master couldn't > > push. > > > > Scenario B: Master in the Internal network. > > > > - Slaves in DMZ and remote rack couldn't contact master for setup, > > although > > > > the master could contact the slaves to push updates. > > > > Scenario C: Master in remote rack > > > > - Not acceptable as remote rack is a testing rack, and may go down at > > any > > > > time. > > > > So, the best solution, from my current understanding is being able to > > somehow> > > do pull-updates for replicas, because then we could have this: > > - Master in DMZs > > - Slaves in Internal network can contact Master in DMZ for replica setup > > and> > > updates > > > > - Slaves in remote rack can contact Master in DMZ for replica setup and > > > > updates > > > > Any feedback is appreciated, especially if I'm missing something...obvious > > or minor. > > > > j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Need for some pull-style replication, or an alternate solution
So, we have a need for replication, but the existing push-only methodology doesn't work for us. I suppose our problems could be attributed to over- zealous network rules, but it is what it is. :) I'd love to change our network policy, but we aren't in charge of network policy, and there is no way I'm swaying the person that is. Topology: 1) DMZ environments 1,...,n 2) An Internal network 3) A remote rack in a data center. Rules (by "talk" I mean initiate connections to): 1) DMZs can talk to each other, somewhat. 2) The Internal network can talk to the DMZs 3) The DMZ *cannot* connect to the Internal network 4) The remote rack of course cannot contact the Internal network, but can contact the DMZs. Scenario A, Master in a DMZ: - Slave in the Internal network could contact the DMZ master for replica setup, but the Master could not contact the slave to push updates - Slave in the remote rack could contact master in DMZ, but incoming to remote rack is very restrictive, so it is possible that master couldn't push. Scenario B: Master in the Internal network. - Slaves in DMZ and remote rack couldn't contact master for setup, although the master could contact the slaves to push updates. Scenario C: Master in remote rack - Not acceptable as remote rack is a testing rack, and may go down at any time. So, the best solution, from my current understanding is being able to somehow do pull-updates for replicas, because then we could have this: - Master in DMZs - Slaves in Internal network can contact Master in DMZ for replica setup and updates - Slaves in remote rack can contact Master in DMZ for replica setup and updates Any feedback is appreciated, especially if I'm missing something...obvious or minor. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Service...not found in Kerberos database
On Monday, July 01, 2013 14:16:18 Rob Crittenden wrote: > You can also use ipa migrate-ds command to move users and groups from > one IPA server to another. That might be an option, but I take it, due to the Kerberos stuff, that it will not migrate passwords? Getting full replication working would be required for that, no? j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Service...not found in Kerberos database
We are trying to query an IPA server from a new IPA server (not replication, just trying to query to recreate accounts). But, when I run the query, I get this: [root@ipan ~]# ipa -vvv -e xmlrpc_uri=https://ipa0.lab.whamcloud.com/ipa/xml user-show jkugler ipa: INFO: trying https://ipa0.lab.whamcloud.com/ipa/xml ipa: INFO: Forwarding 'user_show' to server u'https://ipa0.lab.whamcloud.com/ipa/xml' ipa: ERROR: Service 'h...@ipa0.lab.whamcloud.com' not found in Kerberos database I've done some googling, and what the answers I found had to do with DNS issues, but I don't believe that is the cause in our case, due to DNS lookups seeming to work. [root@ipan ~]# host ipan.lab.whamcloud.com ipan.lab.whamcloud.com has address 10.10.0.50 [root@ipan ~]# host ipa0.lab.whamcloud.com ipa0.lab.whamcloud.com has address 10.10.0.4 [root@ipan ~]# host 10.10.0.50 50.0.10.10.in-addr.arpa domain name pointer ipan.lab.whamcloud.com. [root@ipan ~]# host 10.10.0.4 4.0.10.10.in-addr.arpa domain name pointer ipa0.lab.whamcloud.com. What config do I need to tweak on the new server to allow it to query the old server? Thanks! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
Finally circling back around to this. On Monday, June 24, 2013 09:44:19 Rob Crittenden wrote: > It's really confusing how you ended up with a CA DS instance configured > without SSL. You're telling me. :) > In any case, by default we configure port 7390 for SSL. StartTLS > shouldn't be needed. > > You may also need to set nsSSL3Ciphers. Sorry, LDAP newbie here. What would I add, and to which files? I assume the dse.ldif for the PKI-CA. What entries would I add for the SSL config? > And you need to create an entry: > > cn=RSA,cn=encryption,cn=config > objectclass=top > objectclass=nsEncryptionModule > cn=RSA > nsSSLPersonalitySSL=Server-Cert > nsSSLToken=internal (software) > nsSSLActivation=on When you say "create entry," is that just adding that to the dse.ldif, or am I adding it to the LDAP DB? (Again, LDAP newbie here). Feel free to point me to docs on this subject. I do want to learn, just not sure where to start. Thank you (again!) for all your help! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
On Friday, June 21, 2013 13:25:24 Joshua J. Kugler wrote: > [root@ipa0 slapd-PKI-IPA]# grep nsslapd-secur /etc/dirsrv/slapd-PKI- > IPA/dse.ldif > [root@ipa0 slapd-PKI-IPA]# > > So, it apparently is not in there at all. There are a couple dse.ldif > backup configs in that dir, but nothing in them either. > > In the dse.ldif for slapd-LAB-WHAMCLOUD-COM I do see: > > nsslapd-security: on > > of course. Further investigation. In the dse.ldif for slapd-PKI-CA, there is: nsslapd-certdir: /etc/dirsrv/slapd-PKI-IPA There is a cert8.db and key3.db file in there. However: root@ipa0 slapd-PKI-IPA]# certutil -d ./ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI [root@ipa0 slapd-PKI-IPA]# Apparently no certs. The cert for slapd-LAB-WHAMCLOUD-COM has this info: issuer: CN=Certificate Authority,O=LAB.WHAMCLOUD.COM subject: CN=ipa0.lab.whamcloud.com,O=LAB.WHAMCLOUD.COM Since it's the same hostname, could I just copy the db files from there into /etc/dirsrv/slapd-PKI-CA? j -- Joshua J. Kugler -- Fairbanks, AK Blogs: http://jjncj.com/blog/ (Family) -- http://joshuakugler.com (Geek) Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
On Friday, June 21, 2013 13:25:24 Joshua J. Kugler wrote:
> [root@ipa0 slapd-PKI-IPA]# grep nsslapd-secur /etc/dirsrv/slapd-PKI-
> IPA/dse.ldif
> [root@ipa0 slapd-PKI-IPA]#
>
> So, it apparently is not in there at all. There are a couple dse.ldif
> backup configs in that dir, but nothing in them either.
>
> In the dse.ldif for slapd-LAB-WHAMCLOUD-COM I do see:
>
> nsslapd-security: on
So, I copied the cert8.db, key3.db, secmod.db and pin.txt and pwdfile.txt from
/etc/dirsrv/slapd-LAB-WHAMCLOUD-COM to /etc/dirsrv/slapd-PKI-CA.
I edited PKI-CA's dse.ldif to include
nsslapd-security: on
but when I try to start it, I get:
# /etc/init.d/dirsrv start PKI-IPA
Starting dirsrv:
PKI-IPA...[21/Jun/2013:15:50:17 -0700] createprlistensockets - PR_Bind()
on All Interfaces port 636 failed: Netscape Portable Runtime error -5982
(Local Network address is in use.)
[FAILED]
*** Warning: 1 instance(s) failed to start
I see that the PKI-CA is listening on 7389, and has these lines in its config:
nsslapd-port: 7389
nsslapd-referral: ldap://ipa1.lab.whamcloud.com:7389/o%3Dipaca
nsDS5ReplicaPort: 7389
nsds50ruv: {replica 97 ldap://ipa1.lab.whamcloud.com:7389} 4d48c6ad0061000
nsds50ruv: {replica 96 ldap://ipa0.lab.whamcloud.com:7389} 4d48c6cb006
nsruvReplicaLastModified: {replica 97 ldap://ipa1.lab.whamcloud.com:7389}
nsruvReplicaLastModified: {replica 96 ldap://ipa0.lab.whamcloud.com:7389}
nsDS5ReplicaPort: 7389
Is there a way to
1) set it to listen on 7636 for ldaps
or
2) Enable TLS without having it try to listen on 636?
I see that the LAB-WHAMCLOUD-COM dse.ldif also contains this:
nsusestarttls: off
So I don't know if TLS connections will work there either.
Still trying to figure this out...
j
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
> That doesn't make any sense. Did you disable SSL? > > You can see the settings with: > > # grep nsslapd-secur /etc/dirsrv/slapd-PKI-IPA/dse.ldif > > It's possible that this cert is expired too, can you check that? [root@ipa0 slapd-PKI-IPA]# grep nsslapd-secur /etc/dirsrv/slapd-PKI- IPA/dse.ldif [root@ipa0 slapd-PKI-IPA]# So, it apparently is not in there at all. There are a couple dse.ldif backup configs in that dir, but nothing in them either. In the dse.ldif for slapd-LAB-WHAMCLOUD-COM I do see: nsslapd-security: on of course. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
On Friday, June 21, 2013 14:46:50 Rich Megginson wrote:
> On 06/21/2013 02:39 PM, Joshua J. Kugler wrote:
> > On Friday, June 21, 2013 09:26:36 Rob Crittenden wrote:
> >> We'd need to see /var/log/ipareplica-install.log to see what the LDAP
> >> error is. If you look on the remote master DS access log it may have
> >> additional information on what was requested.
> >
> > Logs attached.
> >
> > 10.10.0.50 is the new replica.
> >
> > No metion the new replica in the error logs. At least not that I can see.
>
> 2013-06-21T20:12:12Z INFO The ipa-replica-install command failed,
> exception: PROTOCOL_ERROR: {'info': 'unsupported extended operation',
> 'desc': 'Protocol error'}
>
> This is from here:
>
> slapd-PKI-CA.access.log
> [21/Jun/2013:13:26:54 -0700] conn=53 fd=64 slot=64 connection from
> 10.10.0.50 to 10.10.0.4
> [21/Jun/2013:13:26:54 -0700] conn=53 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
> [21/Jun/2013:13:26:54 -0700] conn=53 op=0 RESULT err=2 tag=120
> nentries=0 etime=0
> [21/Jun/2013:13:26:54 -0700] conn=53 op=1 UNBIND
>
> The server cannot respond to the startTLS request - which means the
> server has not been configured for TLS/SSL.
Thanks for the quick reply!
OK...the system was set up (I assume, I wasn't here) with the standard ipa-
server-install script(s). So, it would seem that it didn't configure the PKI-
CA slapd to use SSL? Are there docs on doing that after the fact? Including
creating the SSL certs, and configuring the slapd server to use them. Being
the same host, could i use the same certs as are in use by the slapd-LAB-
WHAMCLOUD-LAB server? Do you know, off hand, the config file I would need to
tweak to put those settings in place?
j
--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
On Friday, June 21, 2013 09:26:36 Rob Crittenden wrote:
> We'd need to see /var/log/ipareplica-install.log to see what the LDAP
> error is. If you look on the remote master DS access log it may have
> additional information on what was requested.
Logs attached.
10.10.0.50 is the new replica.
No metion the new replica in the error logs. At least not that I can see.
--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: pedah...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A2013-06-21T20:11:58Z DEBUG /usr/sbin/ipa-replica-install was invoked with
argument "replica-info-ipan.lab.whamcloud.com.gpg" and options:
{'no_forwarders': False, 'conf_ssh': True, 'setup_ca': True, 'ui_redirect':
True, 'reverse_zone': None, 'trust_sshfp': False, 'unattended': False,
'setup_pkinit': True, 'no_host_dns': False, 'mkhomedir': False, 'ip_address':
None, 'no_reverse': False, 'setup_dns': False, 'create_sshfp': True,
'conf_sshd': True, 'forwarders': None, 'debug': False, 'conf_ntp': False,
'skip_conncheck': True, 'skip_schema_check': False}
2013-06-21T20:11:58Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2013-06-21T20:11:58Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2013-06-21T20:11:58Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2013-06-21T20:12:10Z DEBUG Starting external process
2013-06-21T20:12:10Z DEBUG args=/usr/bin/gpg --batch --homedir
/tmp/tmpi9cPa4ipa/ipa-hRix5l/.gnupg --passphrase-fd 0 --yes --no-tty -o
/tmp/tmpi9cPa4ipa/files.tar -d replica-info-ipan.lab.whamcloud.com.gpg
2013-06-21T20:12:10Z DEBUG Process finished, return code=0
2013-06-21T20:12:10Z DEBUG stdout=
2013-06-21T20:12:10Z DEBUG stderr=gpg: WARNING: unsafe permissions on homedir
`/tmp/tmpi9cPa4ipa/ipa-hRix5l/.gnupg'
gpg: keyring `/tmp/tmpi9cPa4ipa/ipa-hRix5l/.gnupg/secring.gpg' created
gpg: keyring `/tmp/tmpi9cPa4ipa/ipa-hRix5l/.gnupg/pubring.gpg' created
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
2013-06-21T20:12:10Z DEBUG Starting external process
2013-06-21T20:12:10Z DEBUG args=tar xf /tmp/tmpi9cPa4ipa/files.tar -C
/tmp/tmpi9cPa4ipa
2013-06-21T20:12:10Z DEBUG Process finished, return code=0
2013-06-21T20:12:10Z DEBUG stdout=
2013-06-21T20:12:10Z DEBUG stderr=
2013-06-21T20:12:10Z DEBUG Installing replica file with version 0 (0 means no
version in prepared file).
2013-06-21T20:12:10Z DEBUG Check if ipan.lab.whamcloud.com is a primary
hostname for localhost
2013-06-21T20:12:10Z DEBUG Primary hostname for localhost:
ipan.lab.whamcloud.com
2013-06-21T20:12:10Z DEBUG Search DNS for ipan.lab.whamcloud.com
2013-06-21T20:12:10Z DEBUG Check if ipan.lab.whamcloud.com is not a CNAME
2013-06-21T20:12:10Z DEBUG Check reverse address of 10.10.0.50
2013-06-21T20:12:10Z DEBUG Found reverse name: ipan.lab.whamcloud.com
2013-06-21T20:12:10Z DEBUG Check if ipa0.lab.whamcloud.com is a primary
hostname for localhost
2013-06-21T20:12:10Z DEBUG Primary hostname for localhost:
ipa0.lab.whamcloud.com
2013-06-21T20:12:10Z DEBUG Search DNS for ipa0.lab.whamcloud.com
2013-06-21T20:12:10Z DEBUG Check if ipa0.lab.whamcloud.com is not a CNAME
2013-06-21T20:12:10Z DEBUG Check reverse address of 10.10.0.4
2013-06-21T20:12:10Z DEBUG Found reverse name: ipa0.lab.whamcloud.com
2013-06-21T20:12:10Z DEBUG Starting external process
2013-06-21T20:12:10Z DEBUG args=/sbin/ip -family inet -oneline address show
2013-06-21T20:12:10Z DEBUG Process finished, return code=0
2013-06-21T20:12:10Z DEBUG stdout=1: loinet 127.0.0.1/8 scope host lo\
valid_lft forever preferred_lft forever
2: eth0inet 10.10.0.50/16 brd 10.10.255.255 scope global eth0\
valid_lft forever preferred_lft forever
2013-06-21T20:12:10Z DEBUG stderr=
2013-06-21T20:12:10Z DEBUG importing all plugin modules in
'/usr/lib/python2.7/site-packages/ipalib/plugins'...
2013-06-21T20:12:10Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py'
2013-06-21T20:12:10Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py'
2013-06-21T20:12:10Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py'
2013-06-21T20:12:10Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py'
2013-06-21T20:12:10Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py'
2013-06-21T20:12:10Z DEBUG importing plugin module
'/usr/lib/python2.7/site-packages/ipalib/plugins/cer
Re: [Freeipa-users] Upgrade/Migration steps
On Friday, June 21, 2013 09:26:36 Rob Crittenden wrote: > > export LDAPTLS_CACERT=/etc/ipa/ca.crt; ipa-replica-install --setup-ca -N > > replica-info-ipan.lab.whamcloud.com.gpg --skip-conncheck > > > > Same error message. > > > > I'm lost. Help? > > This is unrelated to passing in the CA certificate. > > We'd need to see /var/log/ipareplica-install.log to see what the LDAP > error is. If you look on the remote master DS access log it may have > additional information on what was requested. OK, I'll get that to you. > In 2.2 IPA and the CA each have separate 389-ds instances to store the > LDAP data. They are combined in 3.1 which may be what the schema error > means. > > What exact version is your current master and what are you trying to > create a replica to? I'm trying to do migration via replication (you probably knew that). The Old master is 2.0.0. The new slave is 3.1.5 (Fedora 18). j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trying to renew the CA cert, but NEWLY_ADDED_NEED_KEYINFO_READ_PIN
On Friday, June 21, 2013 09:30:12 Rob Crittenden wrote: > Joshua J. Kugler wrote: > > So, ongoing saga of a FreeIPA 2.x system with an expired cert for the CA > > server: > > > > ca-error: Server failed request, will retry: 907 (RPC failed at server. > > cannot connect to > > 'https://ipa0.lab.whamcloud.com:9443/ca/agent/ca/displayBySerial': [Errno > > -8181] (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.). > I thought you said in a different thread that it wasn't the CA that was > expired, but the tomcat cert. According to our conversation in IRC (a while back) this indicates the Tomcat cert is expired. :) The cert in /etc/ipa/ca.crt (which I assume is the actual CA cert) is good until 2019. That was why I was trying to server the tomcat Server-Cert. > > Any ideas how to get the CA cert renewed? > > > > I know how to generate a CSR and a cert, but I'm not sure 1) how I would > > add it into the cert DB, and 2) how I can add it without invalidating all > > my other certs. Sorry, I wasn't clear. Any idea how to renew the cert in /var/lib/pki- ca/alias. (Server-Cert) > certmonger in F-17 doesn't know how to renew the CA-related > certificates. We fixed this in the IPA 3.1 timeframe. I'm not sure if > the certmonger requires dogtag 10 for this feature or not, but it may. > You'll want to upgrade to 3.1+ if you can. > > So if it is just the tomcat cert that is expired, then for simplicity > I'd set the time back on both systems (you'll need to kill ntp) to when > the cert is valid and try that. I have the feeling you've already done > this, but it is unclear what exactly you've tried. Yes, I've tried setting the clock back, and that works to renew the service certs. But the cert for the Tomcat server was never added to certmonger for some reason, so it was never renewed, which means the service certs don't renew properly, which leads to our current need to get off this instance (along with the LDAP server dying after too many requests, but that's a separate issue). j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Trying to renew the CA cert, but NEWLY_ADDED_NEED_KEYINFO_READ_PIN
So, ongoing saga of a FreeIPA 2.x system with an expired cert for the CA server: ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa0.lab.whamcloud.com:9443/ca/agent/ca/displayBySerial': [Errno -8181] (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.). Figured out that it uses the certs in /var/lib/pki-ca/alias. Per https://docs.fedoraproject.org/en%2dUS/Fedora/15/html/FreeIPA_Guide/certmonger%2dtracking%2dcerts.html I tried adding it to cert monger: # ipa-getcert start-tracking -I CAServerCert -d /var/lib/pki-ca/alias/ -n Server-Cert -r New tracking request "CAServerCert" added. But ipa-getcert list now tells me: Request ID 'CAServerCert': status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki- ca/alias',nickname='Server-Cert' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server- Cert' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes Okie dokie...where might I be able to find the PIN for the cert? I see that the certs for httpd and slapd have a path to a pinfile, but I can't find anything like that for the CA cert. I'm quite stuck. This expired cert, I'm pretty sure, is what is preventing me from using this machine to migrate to a new 3.0 machine (via replication). Any ideas how to get the CA cert renewed? I know how to generate a CSR and a cert, but I'm not sure 1) how I would add it into the cert DB, and 2) how I can add it without invalidating all my other certs. Any help would be fantastic! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
On Wednesday, June 19, 2013 16:34:31 Joshua J. Kugler wrote: > Check SSH connection to remote master > Execute check on remote master > > Remote master check failed with following error message(s): > bash: /usr/sbin/ipa-replica-conncheck: No such file or directory > > Connection check failed! > Please fix your network settings according to error messages above. > If the check results are not valid it can be skipped with --skip-conncheck > parameter. OK, so it didn't click that it was trying to run ipa-replica-conncheck on the other machine, and that the error message was on the other machine. But, skipping the connection check, I'm still getting this: # ipa-replica-install --setup-ca -N replica-info-ipan.lab.whamcloud.com.gpg -- skip-conncheck Directory Manager (existing master) password: ipa : CRITICAL CA DS schema check failed. Make sure the PKI service on the remote master is operational. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: PROTOCOL_ERROR unsupported extended operation I even brought over /etc/ipa/ca.crt file and did this: export LDAPTLS_CACERT=/etc/ipa/ca.crt; ipa-replica-install --setup-ca -N replica-info-ipan.lab.whamcloud.com.gpg --skip-conncheck Same error message. I'm lost. Help? j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
OK, getting further. Turns out the admin password wasn't really reset when I thought it was reset. So, this command: ipa-replica-install --setup-ca -N replica-info-ipan.lab.whamcloud.com.gpg produces a bunch of encouraging output until it hits this: Check SSH connection to remote master Execute check on remote master Remote master check failed with following error message(s): bash: /usr/sbin/ipa-replica-conncheck: No such file or directory Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. HUH? # ls -l /usr/sbin/ipa-replica-conncheck -rwxr-xr-x 1 root root 17129 Jun 3 03:40 /usr/sbin/ipa-replica-conncheck It can't find a file that ls can find? :) This is Fedora 18, and the IPA packages therein. Any ideas? j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
Hit more glitches. As to the expired CA cert, I set the clock back, then ran ipa-replica-prepare. That got me the bundle. Took that to the new one. Tried running ipa-replica-install --setup-ca -N replica-info-ipan.lab.whamcloud.com.gpg But that gave me: > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > ad...@lab.whamcloud.com password: > > Cannot acquire Kerberos ticket: kinit: Cannot read password while getting > initial credentials > > Connection check failed! > Please fix your network settings according to error messages above. > If the check results are not valid it can be skipped with --skip-conncheck > parameter. I know the admin password is correct, as I just reset it. Is the connection check really failing, or is the ipa-install-replica script not passing the password to the kerberos client? Next, I tried: ipa-replica-install --setup-ca -N replica-info-ipan.lab.whamcloud.com.gpg -- skip-conncheck But I just got: ipa : CRITICAL CA DS schema check failed. Make sure the PKI service on the remote master is operational. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: PROTOCOL_ERROR unsupported extended operation Sgh...I'm about to give up and just bring up a new system and tell everyone their passwords got reset. :( Ideas? j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
So, first roadblock encountered. One of the reasons we're migrating off of this machine (besides the fact that it is OLD) is that root CA cert has expired (the one used by Tomcat), and so far I haven't found any documentation on renewing it. Well that presents a problem (see attached). It can't create a cert for the replica, because the root CA cert is expired. :) Can someone point me to docs that outline the step for renewing the root CA cert? I would be most grateful. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A# ipa-replica-prepare ipan.lab.whamcloud.com Directory Manager (existing master) password: Preparing replica for ipan.lab.whamcloud.com from ipa0.lab.whamcloud.com Creating SSL certificate for the Directory Server ipa: INFO: sslget 'https://ipa0.lab.whamcloud.com:9444/ca/ee/ca/profileSubmitSSLClient' ipa: ERROR: cert validation failed for "CN=ipa0.lab.whamcloud.com,O=LAB.WHAMCLOUD.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) preparation of replica failed: cannot connect to 'https://ipa0.lab.whamcloud.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -8181] (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. cannot connect to 'https://ipa0.lab.whamcloud.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -8181] (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. File "/usr/sbin/ipa-replica-prepare", line 438, in main() File "/usr/sbin/ipa-replica-prepare", line 336, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 135, in export_certdb raise e___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade/Migration steps
Thank you so much! A few questions below. On Wednesday, June 19, 2013 08:46:06 Martin Kosek wrote: > This is the migration plan that should work: > > 0) We have IPA server(s) of aging version (2.0 in your case) > > 1) On one of your servers, create a replica (ipa-replica-prepare) and copy > the replica file to the new server/VM which will host the updated IPA > version > > 2) You install the up-to-date FreeIPA server (ipa-replica-install). It > should have all the services as the original server had, i.e. > - if original server had CA installed (it probably did), you will also add > "--setup-ca" option > - if original server had DNS installed , you will also add "--setup-dns" > option - Am I correct in understanding that the replica file won't inform the replica which services to create? - We do have DNS running on our IPA nodes, but it is not controlled by IPA. I assume I don't setup DNS in that case. > The new server should now have all the capability of the aging servers + it > will have features introduced in the new version. > > 4) (Optional but recommended) If the installation went well and you are > satisfied with the new server and plan to migrate, you may also spin off > some replicas from it just to keep the redundancy in case this server break > in any way. > > 5) If the new server was properly installed, you stop all the old IPA > servers: # ipactl stop > - this step is important, this will prevent loosing data in case the new > server misses something and let you test the new server > > 6) On your client(s), you verify that they continue to function as before. > If you use DNS with IPA, this should be easy as they should fallback to the > new IPA servers automatically simply by reading new server address from DNS > SRV records. If you do not use automatic DNS discovery and you use a fixed > list of servers, you would have to update these lists in > /etc/sssd/sssd.conf and /etc/krb5.conf and other configuration files you > used. IPA doesn't control DNS, but I think we may use DNS auto discovery. We have this in our DNS records: ; DNS-discovery service entries _kerberos IN TXT LAB.WHAMCLOUD.COM ; name prioweight porttarget _kerberos._udp IN SRV 10 0 88 ipa0 _kerberos-master._udp IN SRV 0 0 88 ipa0 _kerberos-adm._tcp IN SRV 0 0 749 ipa0 _kpasswd._udp IN SRV 0 0 464 ipa0 _ldap._tcp IN SRV 10 0 389 ipa0 If I add another set of records, but using ipa_new (for example), will the sssd clients be able to see both servers? > 7) When you verify that clients keep functioning properly, you remove the > old IPA servers, i.e: > - log in to the new ipa server and delete the old servers > $ ipa-replica-manage list > $ ipa-replica-manage del old.ipa.server.fqdn > > 8) You can now uninstall old IPA servers (ipa-server-install --uninstall) or > discard their VMs/machines > > 9) You successfully migrated! What are some good tests to run against the replica? The basic ones like ipa user-find, listing groups, listing automounts, etc? How do I make sure my test queries are going against the new IPA server instead of the old one? For the ipa commands is there a way (similar to dig's @) to direct a query against a specific IPA server? > Please note that this procedure works only if your FreeIPA basic settings > (like REALM) stays intact. Nope, everything is staying the same. > Any comments? Does this procedure make sense to you? It does make sense. Thank you so much for walking me through this. I'll let you know if I hit any glitches. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Upgrade/Migration steps
We are migrating from an ancient FreeIPA 2.0 server to a 3.1.5 server. Is there a documented procedure to export all the data from the 2.0 server and import it into the 3.1.5 server? If I copy files over (PKI DB, main IPA DB, Kerberos stuff), will they be upgraded on next restart, or is it much, much, more complicated than that. So far, I have the rough steps (see attached). But I don't know for sure if that will work. Any ideas or insights? Thanks! j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A# Get the Info # get the PKI db /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif.pl -D "cn=Directory Manager" -w - -n ipaca # get the main IPA db /var/lib/dirsrv/scripts-LAB-WHAMCLOUD-COM/db2ldif.pl -D 'cn=Directory Manager' -w - -n userRoot #!/bin/sh KERBEROS="/etc/krb5* /etc/sysconfig/kadmin /etc/sysconfig/krb5kdc /var/kerberos" DIRSRV="/etc/dirsrv /var/lib/dirsrv /etc/sysconfig/dirsrv /var/run/dirsrv /var/lock/dirsrv" CERTMONGER="/etc/certmonger /var/lib/certmonger" IPA="/var/lib/ipa /etc/ipa /root/ca* /etc/httpd/conf/ipa.keytab" PATH_LIST="$DIRSRV $CERTMONGER $IPA $KERBEROS" BACKUP_TGZ=/var/tmp/ipa-backup-$(date +%Y%m%d-%H%M%S).tar.gz # Transfer to new system and import cd / tar -cvzf $BACKUP_TGZ $PATH_LIST /usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db.pl -D "cn=Directory Manager" -w - -n ipaca \ -v -i /tmp/restore/var/lib/dirsrv/slapd-PKI-IPA/ldif/PKI-IPA-ipaca-2012_1_30_13_41_51.ldif /var/lib/dirsrv/scripts-LAB-WHAMCLOUD-COM/ldif2db.pl -D "cn=Directory Manager" -w - \ -n userRoot -v \ -i /tmp/restore/var/lib/dirsrv/slapd-LAB-WHAMCLOUD-COM/ldif/LAB-WHAMCLOUD-COM-userRoot-2012_1_30_11_54_25.ldif2db rsync -aP /tmp/restore/var/kerberos/ /var/kerberos/ cp -a /tmp/restore/etc/krb5.keytab /etc cp -a /tmp/restore/etc/dirsrv/ds.keytab /etc/dirsrv cp -a /tmp/restore/etc/httpd/conf/ipa.keytab /etc/httpd/conf cp -a /tmp/restore/root/ca*.p12 /root ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
