Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-09-09 Thread Nicklas Björk
On 2014-08-28 10:58, Nicklas Björk wrote:
 2014-08-27T14:45:19Z DEBUG stderr=pkispawn: WARNING  ... unable
 to validate security domain user/password through REST interface.
 Interface not available

Digging a bit further I found the following in
/var/lib/pki-ca/logs/debug on the FreeIPA master. All lines share the
common prefix [09/Sep/2014:14:30:27][TP-Processor6].

CMSServlet:service() uri = /ca/agent/ca/updateDomainXML
CMSServlet::service() param name='name' value='/var/lib/pki/pki-tomcat'
CMSServlet::service() param name='ncsport' value='8443'
CMSServlet::service() param name='sport' value='None'
CMSServlet::service() param name='operation' value='remove'
CMSServlet::service() param name='adminsport' value='8443'
CMSServlet::service() param name='list' value='caList'
CMSServlet::service() param name='type' value='CA'
CMSServlet::service() param name='agentsport' value='8443'
CMSServlet::service() param name='host' value='replica.example.net'
CMSServlet: caUpdateDomainXML start to service.
UpdateDomainXML: processing...
UpdateDomainXML process: authentication starts
IP: 192.168.1.20
AuthMgrName: certUserDBAuthMgr
CMSServlet: retrieving SSL certificate
CMSServlet: certUID=CN=CA Subsystem,O=EXAMPLE.NET
CertUserDBAuth: started
CertUserDBAuth: Retrieving client certificate
CertUserDBAuth: Got client certificate
Authentication: client certificate found
In LdapBoundConnFactory::getConn()
masterConn is connected: true
getConn: conn is connected true
getConn: mNumConns now 2
returnConn: mNumConns now 3
SignedAuditEventFactory: create()
message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=CA
Subsystem,O=EXAMPLE.NET] authentication failure

CMSServlet: curDate=Tue Sep 09 14:30:27 CEST 2014 id=caUpdateDomainXML
time=5


What kind of authentication is it complaining about, and is it possible
to repair it?



Nicklas



signature.asc
Description: OpenPGP digital signature
-- 
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] RHEL 7 Upgrade experience so far

2014-08-28 Thread Nicklas Björk
I have been following this thread with great interest, as I have
encountered similar problems with our migration from 3.0.0-37 on CentOS
6.5 to 3.3.3-28 on CentOS 7. I have been able to solve a few of them
with manual patching, but there is still something going on that will
make the CA replication to fail.

The following changes have been made to the environments:

- On the replica,
/usr/lib/python2.7/site-packages/ipaserver/install/replication.py has
been patched to handle multiple values of nsDS5ReplicaId on the master.

- /usr/share/ipa/html/ca.crt used to contain our local root certificate
as well as the IPA CA-certificate, which caused the replica installation
to fail. The root certificate was removed from this file, the replica
gpg-bundle recreated, and the installation would happily continue.

- /etc/httpd/conf.d/ipa-pki-proxy.conf has been patched to contain the
profileSubmit-patch to the ee port-line
LocationMatch
^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit

and have also tried with and without the additions to the admin port and
installer-line

LocationMatch
^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken|^/ca/admin/ca/updateNumberRange|^/ca/rest/securityDomain/domainInfo|^/ca/rest/account/login|^/ca/admin/ca/tokenAuthenticate|^/ca/admin/ca/updateNumberRange|^/ca/admin/ca/updateDomainXML|^/ca/rest/account/logout|^/ca/rest/securityDomain/installToken



Checking the log files on the 3.3.3 replica, there are a few error
messages, which I am not sure how to resolve.


/var/log/ipareplica-install.log ends with the following lines:

2014-08-27T14:44:15Z DEBUG Starting external process
2014-08-27T14:44:15Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpxkixl8
2014-08-27T14:45:19Z DEBUG Process finished, return code=1
2014-08-27T14:45:19Z DEBUG stdout=Loading deployment configuration from
/tmp/tmpxkixl8.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.


2014-08-27T14:45:19Z DEBUG stderr=pkispawn: WARNING  ... unable
to validate security domain user/password through REST interface.
Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Error while updating security domain: java.io.IOException: 2

2014-08-27T14:45:19Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpxkixl8' returned non-zero exit status 1
2014-08-27T14:45:19Z DEBUG   File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()

  File /usr/sbin/ipa-replica-install, line 667, in main
CA = cainstance.install_replica_ca(config)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
1678, in install_replica_ca
subject_base=config.subject_base)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
478, in configure_instance
self.start_creation(runtime=210)

  File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation
method()

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')

2014-08-27T14:45:19Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed


/var/log/pki/pki-ca-spawn.20140827164415.log reveals these error messages:

2014-08-27 16:44:16 pkispawn: INFO ... executing 'systemctl
start pki-tomcatd@pki-tomcat.service'
2014-08-27 16:44:18 pkispawn: DEBUG... No connection -
server may still be down
2014-08-27 16:44:18 pkispawn: DEBUG... No connection -
exception thrown: [Errno 111] Connection refused
2014-08-27 16:44:26 pkispawn: DEBUG... ?xml
version=1.0 encoding=UTF-8
standalone=no?XMLResponseState0/StateTypeCA/TypeStatusrunning/StatusVersion10.0.5-3.el7/Version/XMLResponse
2014-08-27 16:44:27 pkispawn: INFO ... constructing PKI
configuration data.
2014-08-27 16:44:27 pkispawn: INFO ... configuring PKI
configuration data.
2014-08-27 16:45:19 pkispawn: ERROR... Exception from Java
Configuration Servlet: Error while updating security domain:
java.io.IOException: 2
2014-08-27 16:45:19 pkispawn: DEBUG... Error Type: HTTPError
2014-08-27 16:45:19 pkispawn: DEBUG... Error Message: 500
Server Error: Internal Server Error
2014-08-27 16:45:19 pkispawn: DEBUG...   File
/usr/sbin/pkispawn, line 374, in main
rv = instance.spawn()
  File
/usr/lib/python2.7/site-packages/pki/deployment/configuration.py, line
128, in 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-06 Thread Ade Lee
Thanks for sticking in there with the debugging.
Let us know if you run into any issues with the re-install.

I will open a Dogtag ticket to look into the multiple certs issue for
Dogtag.

Ade

On Tue, 2014-08-05 at 21:30 -0700, Erinn Looney-Triggs wrote:
 Ok I am throwing up the white flag on this one and starting anew.
 Clearly there are several things broken down there in the murky
 depths, and well I just don't trust my install all that much at this
 point.
 
 Thanks for all the help I really appreciate it.
 
 Please remember to take a look at the multiple certs issue for
 creating a clone in dogtag, as that is a bug for sure.
 
 -Erinn
 


-- 
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] RHEL 7 Upgrade experience so far

2014-08-05 Thread Martin Kosek
On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote:
 On 08/04/2014 01:51 PM, Ade Lee wrote:
 OK - I suspect you may be running into an issue with serial number 
 generation.  Each time we install a clone, we end up allocating a new 
 range of serial numbers for the clone.
 
 The idea is to keep separate ranges for each CA replica so that no two 
 replicas can issue certs with the same serial number.
 
 The problem is that you've probably retried the install a whole bunch
 of times and now perhaps the serial number range is too high.
 
 This is just a guess - but you can see what ranges have been assigned
 by looking in :
 
 1,  ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for 
 the master  (look for the attributes dbs.* 3. The value of the
 attribute nextRange on : ou=certificateRepository, o=ipaca and
 ou=Requests, o=ipaca
 
 Please send me that info, and I'll explain how to clean that up.
 
 Ade
 
 On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote:
 On 08/04/2014 11:48 AM, Ade Lee wrote:
 OK - so its not really even getting started on the install. My
 guess is there is some cruft from previous installs/uninstalls that
 was not cleaned up.  Is there anything in the directory server logs
 on the RHEL7 machine? What operation is being attempted that the
 server is refusing to perform?
 
 Ade
 
 
 Ok I moved on past this issue. Problem was minssf was set to 56 on
 the RHEL 7 dirsrv instance, setting it to 0 resolved this issue.
 Thanks for having me check the dir on the RHEL 7 instance I was
 assuming it was hitting against the RHEL 6.5 instance and was finding
 basically nothing there.
 
 
 This run looks like it pulled a lot more information in but it still 
 errored out.
 
 ipa : DEBUGstderr=pkispawn: WARNING  ... unable
 to validate security domain user/password through REST interface. 
 Interface not available pkispawn: ERROR... Exception from 
 Java Configuration Servlet: Error in confguring system 
 certificatesjava.security.cert.CertificateException: Unable to 
 initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, 
 too big.
 
 ipa : CRITICAL failed to configure ca instance Command 
 '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit 
 status 1
 
 From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance:
 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with 
 mininum 3 and maximum 15 connections to host ipa2.abaqis.com port
 389, secure connection, false, authentication type 1 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum 
 connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new 
 total available connections 3 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of 
 connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In 
 LdapBoundConnFactory::getConn() 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is
 connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn:
 conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]:
 getConn: mNumConns now 2
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS:
 param=preop.internaldb.post_ldif 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif
 file = /usr/share/pki/ca/conf/vlv.ldif 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif
 file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP 
 Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
 exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm 
 database, cn=plugins, cn=config:netscape.ldap.LDAPException: error 
 result (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
 exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, 
 cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: 
 error result (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
 exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, 
 cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: 
 error result (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
 exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, 
 cn=ipaca, cn=ldbm database, cn=plugins, 
 cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = 
 o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
 exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, 
 cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: 
 error result (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
 exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, 
 cn=ldbm database, 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-05 Thread Martin Kosek
On 08/04/2014 10:41 PM, Erinn Looney-Triggs wrote:
 On 08/04/2014 08:46 AM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 08/04/2014 04:01 AM, Martin Kosek wrote:
 On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:




 Whether related or not I am getting the following in my
 RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug
 log:

 [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error:
 could not send startTLS re quest: error -1 (Can't contact
 LDAP server) errno 107 (Transport endpoint is not
 connected) [26/Jul/2014:20:23:23 +]
 NSMMReplicationPlugin - agmt=cn=masterAgreement1-i
 pa2.example.com-pki-ca (ipa2:7389): Replication bind with
 SIMPLE auth failed: LD AP error -1 (Can't contact LDAP
 server) ((null)) [26/Jul/2014:20:23:37 +]
 slapi_ldap_bind - Error: could not send startTLS re quest:
 error -1 (Can't contact LDAP server) errno 107 (Transport
 endpoint is not connected) [26/Jul/2014:20:23:48 +]
 slapi_ldap_bind - Error: could not send startTLS re quest:
 error -1 (Can't contact LDAP server) errno 107 (Transport
 endpoint is not connected)

 And these errors just continue to be logged.

 When attempting to run ipa-ca-install -d on the RHEL 7
 replica (all other services are on there running fine) I
 receive the following:

 ipa : CRITICAL failed to configure ca instance
 Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF'
 returned non-zero exit status 1 ipa : DEBUG
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,






 line 638, in run_script
 return_value = main_function()

 File /usr/sbin/ipa-ca-install, line 179, in main CA = 
 cainstance.install_replica_ca(config, postinstall=True)

 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,






 line 1678, in install_replica_ca
 subject_base=config.subject_base)

 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,






 line 478, in configure_instance
 self.start_creation(runtime=210)

 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,




 line 364, in start_creation method()

 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,






 line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')

 ipa : DEBUGThe ipa-ca-install command failed, 
 exception: RuntimeError: Configuration of CA failed

 Your system may be partly configured. Run 
 /usr/sbin/ipa-server-install --uninstall to clean up.

 Configuration of CA failed


 So this behavior changed after restarting the IPA service
 on the RHEL 6.5 system.

 So at this point I have a RHEL 6.5 system and a RHEL 7
 replica of everything except the CA. The RHEL 6.5 system,
 when the IPA service is restarted throws an error, perhaps
 from schema change?

 Any ideas?

 -Erinn



 I went in and debugged this a bit further by changing the 
 verbosity for nsslapd-errorlog-level. It appears that the
 rhel 6.5 system is attempting to connect to the RHEL 7 system
 on port 7389 and since the RHEL 7 system does not have the CA
 installed this would obviously fail. This leads me to believe
 that there is cruft in the directory that is pointing to the
 wrong place. I don't think this will fix my second group of
 errors, but how does one view the replication agreements
 specifically for the ca?

 As well I omitted to lines from the ipa-ca-install error
 which are probably pertinent:

 ERROR:  Unable to access directory server: Server is
 unwilling to perform

 ipa : DEBUGstderr=

 -Erinn

 This is strange. ipa-ca-install/ipa-replica-install --setup-ca 
 should create the replication agreement pointing at port 389
 on RHEL-7.0, given that the 2 originally separated DS databases
 were merged.

 It looks like this is some replication agreement left over
 from previous tests.

 Anyway, to list all hosts with PKI, try:

 # ipa-csreplica-manage list Directory Manager password:

 vm-089.idm.lab.bos.redhat.com: master 
 vm-086.idm.lab.bos.redhat.com: master

 master means that this server has PKI service installed. It
 will show different value if there is no PKI service.

 To check PKI replication agreements for specific hostname,
 run:

 # ipa-csreplica-manage list `hostname` Directory Manager
 password:

 vm-089.idm.lab.bos.redhat.com

 Check man ipa-csreplica-manage for advise how to delete or
 create the PKI agreements.

 HTH, Martin


 Yeah here is what I get: ipa-csreplica-manage list Directory
 Manager password:

 ipa2.example.com: CA not configured ipa.example.com: master

 ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.

 ipa-csreplica-manage list ipa2.example.com Directory Manager
 password:

 Can't contact LDAP server

 Which I guess makes sense, however: ipa-csreplica-manage list -v
 ipa.example.com Directory Manager password:

 ipa2.example.com last init status: None last init ended: None 
 last update status: -1  - LDAP error: Can't contact LDAP server 
 last update ended: None ipa2.example.com 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-05 Thread Ade Lee
On Tue, 2014-08-05 at 09:08 +0200, Martin Kosek wrote:
 On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote:
  On 08/04/2014 01:51 PM, Ade Lee wrote:
  OK - I suspect you may be running into an issue with serial number 
  generation.  Each time we install a clone, we end up allocating a new 
  range of serial numbers for the clone.
  
  The idea is to keep separate ranges for each CA replica so that no two 
  replicas can issue certs with the same serial number.
  
  The problem is that you've probably retried the install a whole bunch
  of times and now perhaps the serial number range is too high.
  
  This is just a guess - but you can see what ranges have been assigned
  by looking in :
  
  1,  ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for 
  the master  (look for the attributes dbs.* 3. The value of the
  attribute nextRange on : ou=certificateRepository, o=ipaca and
  ou=Requests, o=ipaca
  
  Please send me that info, and I'll explain how to clean that up.
  
  Ade
  
  On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote:
  On 08/04/2014 11:48 AM, Ade Lee wrote:
  OK - so its not really even getting started on the install. My
  guess is there is some cruft from previous installs/uninstalls that
  was not cleaned up.  Is there anything in the directory server logs
  on the RHEL7 machine? What operation is being attempted that the
  server is refusing to perform?
  
  Ade
  
  
  Ok I moved on past this issue. Problem was minssf was set to 56 on
  the RHEL 7 dirsrv instance, setting it to 0 resolved this issue.
  Thanks for having me check the dir on the RHEL 7 instance I was
  assuming it was hitting against the RHEL 6.5 instance and was finding
  basically nothing there.
  
  
  This run looks like it pulled a lot more information in but it still 
  errored out.
  
  ipa : DEBUGstderr=pkispawn: WARNING  ... unable
  to validate security domain user/password through REST interface. 
  Interface not available pkispawn: ERROR... Exception from 
  Java Configuration Servlet: Error in confguring system 
  certificatesjava.security.cert.CertificateException: Unable to 
  initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, 
  too big.
  
  ipa : CRITICAL failed to configure ca instance Command 
  '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit 
  status 1
  
  From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance:
  
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with 
  mininum 3 and maximum 15 connections to host ipa2.abaqis.com port
  389, secure connection, false, authentication type 1 
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum 
  connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new 
  total available connections 3 
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of 
  connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In 
  LdapBoundConnFactory::getConn() 
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is
  connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn:
  conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]:
  getConn: mNumConns now 2
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS:
  param=preop.internaldb.post_ldif 
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif
  file = /usr/share/pki/ca/conf/vlv.ldif 
  [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif
  file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif 
  [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP 
  Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif 
  [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
  exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm 
  database, cn=plugins, cn=config:netscape.ldap.LDAPException: error 
  result (32); matchedDN = o=ipaca
  
  [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
  exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, 
  cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: 
  error result (32); matchedDN = o=ipaca
  
  [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
  exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, 
  cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: 
  error result (32); matchedDN = o=ipaca
  
  [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
  exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, 
  cn=ipaca, cn=ldbm database, cn=plugins, 
  cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = 
  o=ipaca
  
  [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: 
  exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, 
  cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: 
  error result (32); matchedDN = o=ipaca
  
  

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-05 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


 
 
 Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1
  dbs.beginSerialNumber=1 dbs.enableSerialManagement=true 
 dbs.endReplicaNumber=50 dbs.endRequestNumber=990 
 dbs.endSerialNumber=ff6 dbs.ldap=internaldb 
 dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 
 dbs.replicaDN=ou=replica dbs.replicaIncrement=100 
 dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica,
 ou=ranges dbs.requestCloneTransferNumber=1
 dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=1000
 dbs.requestLowWaterMark=200 dbs.requestRangeDN=ou=requests,
 ou=ranges dbs.serialCloneTransferNumber=1 
 dbs.serialDN=ou=certificateRepository, ou=ca
 dbs.serialIncrement=1000 dbs.serialLowWaterMark=200
 dbs.serialRangeDN=ou=certificateRepository, ou=ranges
 
 
 Erinn, I still need to see the ldap entries I mentioned above. 
 Those are actually the ones that will need to be changed.
 
 Unfortunately, things seem to have gone further south on the
 RHEL 6.5 CA instance now. This just seems to be my luck on this
 replica install. From the debug of the ipa-ca-install: ipa
 : DEBUGStarting external process ipa : DEBUG
 args=/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw ipa :
 DEBUGProcess finished, return code=1 ipa : DEBUG
 stdout=Loading deployment configuration from /tmp/tmp1G6jOw. 
 ERROR:  Unable to access security domain: 404 Client Error: Not
 Found
 
 ipa : DEBUGstderr= ipa : CRITICAL failed to
 configure ca instance Command '/usr/sbin/pkispawn -s CA -f
 /tmp/tmp1G6jOw' returned non-zero exit status 1
 
 I can see in the apache logs on the RHEL 6.5 instance it errors
 out: [Mon Aug 04 21:06:02 2014] [error] [client 
 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: 
 /var/www/html/ca
 
 This is supposed to be mapped via ajp to localhost:9447 which
 does appear to be listening. Anyway, I am in the throws of that
 currently, but let me know if those ranges are out of control
 big.
 
 -Erinn
 
 Erinn, I'm a little confused.
 
 Perhaps at this point, it would make sense for you to test out your
 6.5 instance and confirm that its working/ can issue certs etc. 
 Maybe a restart of IPA on that server could help right things.
 
 Could this be caused by
 https://bugzilla.redhat.com/show_bug.cgi?id=1083878? You could
 check access log to see what calls are being made by 7.0
 replica.
 
 This will be fixed in 6.6, I am afraid that for 6.5 you will have
 to do the update (adding |^/ca/ee/ca/profileSubmit) yourself.
 
 Martin
 
 

You and me both my friend, confusion seems to be par for the course on
this particular migration, but hey I am learning a lot and y'all are
great help.

Actually I think I have figured out why everything went a bit further
south, well at least I have a theory I would like to run by you folks.
I did a run on the RHEL 7 system of ipa-ca-install that failed
probably because of Ade's theory. However, I think at that point the
replication agreement was in place and functioning possibly because of
the old entries on the RHEL 6.5 system.

I then ran a pkidestroy on the RHEL 7 instance to clean things up. I
reckon this might have replicated on over because at this point it
appears I have no ipaca entries, nor anything functioning in that area
on the RHEL 6.5 system.

Either that or I have some serious corruption or HW problems.

So I am working on a restore from a backup of the directory server
info for the CA on the RHEL 6.5 system.

All in all, pretty damn funny if that is how it worked out. One way or
another the cert info is gone on the RHEL 6.5 system though the
cn=config info remains intact.

- -Erinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT4PtuAAoJEFg7BmJL2iPOsr8IAIgS7qnfbXYqJ5bnc2/zXafH
w4Y5/zs9JtD19MeA+vFou9D0RlJA4KZ0CDk9gyMnbaM0Yb4H+9rLSF8HIK/B7IzO
Cv67gbhDC7ut1L2rBRGMDUzwOlgm3mfukZLRsuWU1age49WayxzLrGLCcBM/8xqf
/67etQoNYX4wHYQRPsdnm/8D3RkYPZ3LtxZqkvbxl3LERXhzjsJV5F4Jl7LKK6OE
gag0qHIyfzlw7Si/kOzkNusdETRE/ZF4H7/xI/0IbrSIuG8gVovkdVxeBPOCrZ90
w1xlQyArEbIAADhQ5meez4e+MhMGHK+HlKtUHod2iXyWF2GAIR+6v1CMOljSBxs=
=13KE
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-08-05 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/04/2014 01:51 PM, Ade Lee wrote:
 OK - I suspect you may be running into an issue with serial number 
 generation.  Each time we install a clone, we end up allocating a
 new range of serial numbers for the clone.
 
 The idea is to keep separate ranges for each CA replica so that no
 two replicas can issue certs with the same serial number.
 
 The problem is that you've probably retried the install a whole
 bunch of times and now perhaps the serial number range is too
 high.
 
 This is just a guess - but you can see what ranges have been
 assigned by looking in :
 
 1,  ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg
 for the master  (look for the attributes dbs.* 3. The value of the
 attribute nextRange on : ou=certificateRepository, o=ipaca and
 ou=Requests, o=ipaca
 
 Please send me that info, and I'll explain how to clean that up.
 
 Ade
 

Ok, after that brief little side trip down deleting my CA lane, here
is what I have for the ranges info:


1. Hmm ok, I'll do the best I can here, LDAP is not yet my forte:
dn: ou=ranges,o=ipaca
objectClass: organizationalUnit
objectClass: top
ou: ranges

dn: ou=replica,ou=ranges,o=ipaca
objectClass: organizationalUnit
objectClass: top
ou: replica

dn: ou=requests,ou=ranges,o=ipaca
objectClass: organizationalUnit
objectClass: top
ou: requests

dn: ou=certificateRepository,ou=ranges,o=ipaca
objectClass: organizationalUnit
objectClass: top
ou: certificateRepository

dn: cn=1001,ou=requests,ou=ranges,o=ipaca
objectClass: pkiRange
objectClass: top
beginRange: 1001
cn: 1001
endRange: 2000
host: ipa2.example.com
SecurePort: 443

dn: cn=1001,ou=certificateRepository,ou=ranges,o=ipaca
objectClass: pkiRange
objectClass: top
beginRange: 1001
cn: 1001
endRange: 2000
host: ipa2.example.com
SecurePort: 443

2.
dbs.beginReplicaNumber=1
dbs.beginRequestNumber=1
dbs.beginSerialNumber=1
dbs.enableSerialManagement=true
dbs.endReplicaNumber=50
dbs.endRequestNumber=990
dbs.endSerialNumber=ff6
dbs.ldap=internaldb
dbs.newSchemaEntryAdded=true
dbs.replicaCloneTransferNumber=5
dbs.replicaDN=ou=replica
dbs.replicaIncrement=100
dbs.replicaLowWaterMark=20
dbs.replicaRangeDN=ou=replica, ou=ranges
dbs.requestCloneTransferNumber=1
dbs.requestDN=ou=ca, ou=requests
dbs.requestIncrement=1000
dbs.requestLowWaterMark=200
dbs.requestRangeDN=ou=requests, ou=ranges
dbs.serialCloneTransferNumber=1
dbs.serialDN=ou=certificateRepository, ou=ca
dbs.serialIncrement=1000
dbs.serialLowWaterMark=200
dbs.serialRangeDN=ou=certificateRepository, ou=ranges

3.
In ou=ca,ou=ranges,o=ipaca nextRange:  2001
Ditto for ou=certificateRepository,ou=ca,o=ipaca

Thanks,
- -Erinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT4SKhAAoJEFg7BmJL2iPOBmUIAKoiE7IOW3ld9ja03L9oOvdc
geI56IWSXV2i5p5vln+BWQMvBko724smohWFxCJ88LY4NIXKYIV877+oDUBYX0BO
pygaDZp43qTll4mo+0akYk8Ooy/4qpP2a9uslxUH6/KfhmGmo/aF1WPbfmw5t5p3
nfktyOfHp0iaD5nGjfjTlF8jhJ0UQRZxkX49u2zXKMNVZ3Oay7sItziBUtnvXcaD
eIeOKjgY3dUuGulqXGqkhSev7ZV5w7WUA8snyDyG/Ls0LZdgYc3+RvdA9DuNxXFL
PE36+1tfVIDnVwvwSPz/dKTMs/ThHPBbNQh/7UYVUEe5dVnUIvhVJEHJupFj9xk=
=u2/z
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-08-05 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ok I am throwing up the white flag on this one and starting anew.
Clearly there are several things broken down there in the murky
depths, and well I just don't trust my install all that much at this
point.

Thanks for all the help I really appreciate it.

Please remember to take a look at the multiple certs issue for
creating a clone in dogtag, as that is a bug for sure.

- -Erinn

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT4a91AAoJEFg7BmJL2iPOxk8IAIvLoQdw4mkL6CGpzlU8H2go
C1OXaS52pd9cX7LLZkNgVYUcaAizyND2cNp7vjwhESRwDcPSBzDWl1jXGhrv/Dp9
TOpP7YvR8WueifgQkqcEVCUf6TEH07v4MXNwkrX6h6eX092583jfXLuzmp3hjO+J
cLbWAwuQR5E0xntkfrnWjdjDddWVzUKVUGNO2Da5nIjancGZLaRAgMYIpY3tz0FD
F6OVEUQA4eP/xoZlN8bFBLbtLH4n+/pFOF66A0e+9NtXUEtW3Sd+OupTerpDcid9
7YMmJ2kXsyhT3X9Rykm8irMRx6zGNZhf/TUfVg5tLFRzoZ+LvqxY+52SnSL5jwo=
=mt1j
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-08-04 Thread Martin Kosek
On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
 
 
 
 
 Whether related or not I am getting the following in my RHEL 6.5
 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
 
 [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error: could not
 send startTLS re quest: error -1 (Can't contact LDAP server) errno
 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23
 +] NSMMReplicationPlugin - agmt=cn=masterAgreement1-i 
 pa2.example.com-pki-ca (ipa2:7389): Replication bind with SIMPLE
 auth failed: LD AP error -1 (Can't contact LDAP server) ((null)) 
 [26/Jul/2014:20:23:37 +] slapi_ldap_bind - Error: could not
 send startTLS re quest: error -1 (Can't contact LDAP server) errno
 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48
 +] slapi_ldap_bind - Error: could not send startTLS re quest:
 error -1 (Can't contact LDAP server) errno 107 (Transport endpoint
 is not connected)
 
 And these errors just continue to be logged.
 
 When attempting to run ipa-ca-install -d on the RHEL 7 replica
 (all other services are on there running fine) I receive the
 following:
 
 ipa : CRITICAL failed to configure ca instance Command 
 '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero 
 exit status 1 ipa : DEBUG  File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
 
 
 line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-ca-install, line 179, in main CA =
 cainstance.install_replica_ca(config, postinstall=True)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 
 
 line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 
 
 line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 
 
 line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 ipa : DEBUGThe ipa-ca-install command failed,
 exception: RuntimeError: Configuration of CA failed
 
 Your system may be partly configured. Run
 /usr/sbin/ipa-server-install --uninstall to clean up.
 
 Configuration of CA failed
 
 
 So this behavior changed after restarting the IPA service on the
 RHEL 6.5 system.
 
 So at this point I have a RHEL 6.5 system and a RHEL 7 replica of 
 everything except the CA. The RHEL 6.5 system, when the IPA service
 is restarted throws an error, perhaps from schema change?
 
 Any ideas?
 
 -Erinn
 
 
 
 I went in and debugged this a bit further by changing the verbosity
 for nsslapd-errorlog-level. It appears that the rhel 6.5 system is
 attempting to connect to the RHEL 7 system on port 7389 and since the
 RHEL 7 system does not have the CA installed this would obviously
 fail. This leads me to believe that there is cruft in the directory
 that is pointing to the wrong place. I don't think this will fix my
 second group of errors, but how does one view the replication
 agreements specifically for the ca?
 
 As well I omitted to lines from the ipa-ca-install error which are
 probably pertinent:
 
 ERROR:  Unable to access directory server: Server is unwilling to perform
 
 ipa : DEBUGstderr=
 
 -Erinn

This is strange. ipa-ca-install/ipa-replica-install --setup-ca should create
the replication agreement pointing at port 389 on RHEL-7.0, given that the 2
originally separated DS databases were merged.

It looks like this is some replication agreement left over from previous tests.

Anyway, to list all hosts with PKI, try:

# ipa-csreplica-manage list
Directory Manager password:

vm-089.idm.lab.bos.redhat.com: master
vm-086.idm.lab.bos.redhat.com: master

master means that this server has PKI service installed. It will show
different value if there is no PKI service.

To check PKI replication agreements for specific hostname, run:

# ipa-csreplica-manage list `hostname`
Directory Manager password:

vm-089.idm.lab.bos.redhat.com

Check man ipa-csreplica-manage for advise how to delete or create the PKI
agreements.

HTH,
Martin

-- 
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] RHEL 7 Upgrade experience so far

2014-08-04 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/04/2014 08:46 AM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 08/04/2014 04:01 AM, Martin Kosek wrote:
 On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote:
 
 
 
 
 Whether related or not I am getting the following in my
 RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug
 log:
 
 [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error:
 could not send startTLS re quest: error -1 (Can't contact
 LDAP server) errno 107 (Transport endpoint is not
 connected) [26/Jul/2014:20:23:23 +]
 NSMMReplicationPlugin - agmt=cn=masterAgreement1-i
 pa2.example.com-pki-ca (ipa2:7389): Replication bind with
 SIMPLE auth failed: LD AP error -1 (Can't contact LDAP
 server) ((null)) [26/Jul/2014:20:23:37 +]
 slapi_ldap_bind - Error: could not send startTLS re quest:
 error -1 (Can't contact LDAP server) errno 107 (Transport
 endpoint is not connected) [26/Jul/2014:20:23:48 +]
 slapi_ldap_bind - Error: could not send startTLS re quest:
 error -1 (Can't contact LDAP server) errno 107 (Transport
 endpoint is not connected)
 
 And these errors just continue to be logged.
 
 When attempting to run ipa-ca-install -d on the RHEL 7
 replica (all other services are on there running fine) I
 receive the following:
 
 ipa : CRITICAL failed to configure ca instance
 Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF'
 returned non-zero exit status 1 ipa : DEBUG
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,





 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-ca-install, line 179, in main CA = 
 cainstance.install_replica_ca(config, postinstall=True)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,





 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,





 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,



 
line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,





 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 ipa : DEBUGThe ipa-ca-install command failed, 
 exception: RuntimeError: Configuration of CA failed
 
 Your system may be partly configured. Run 
 /usr/sbin/ipa-server-install --uninstall to clean up.
 
 Configuration of CA failed
 
 
 So this behavior changed after restarting the IPA service
 on the RHEL 6.5 system.
 
 So at this point I have a RHEL 6.5 system and a RHEL 7
 replica of everything except the CA. The RHEL 6.5 system,
 when the IPA service is restarted throws an error, perhaps
 from schema change?
 
 Any ideas?
 
 -Erinn
 
 
 
 I went in and debugged this a bit further by changing the 
 verbosity for nsslapd-errorlog-level. It appears that the
 rhel 6.5 system is attempting to connect to the RHEL 7 system
 on port 7389 and since the RHEL 7 system does not have the CA
 installed this would obviously fail. This leads me to believe
 that there is cruft in the directory that is pointing to the
 wrong place. I don't think this will fix my second group of
 errors, but how does one view the replication agreements
 specifically for the ca?
 
 As well I omitted to lines from the ipa-ca-install error
 which are probably pertinent:
 
 ERROR:  Unable to access directory server: Server is
 unwilling to perform
 
 ipa : DEBUGstderr=
 
 -Erinn
 
 This is strange. ipa-ca-install/ipa-replica-install --setup-ca 
 should create the replication agreement pointing at port 389
 on RHEL-7.0, given that the 2 originally separated DS databases
 were merged.
 
 It looks like this is some replication agreement left over
 from previous tests.
 
 Anyway, to list all hosts with PKI, try:
 
 # ipa-csreplica-manage list Directory Manager password:
 
 vm-089.idm.lab.bos.redhat.com: master 
 vm-086.idm.lab.bos.redhat.com: master
 
 master means that this server has PKI service installed. It
 will show different value if there is no PKI service.
 
 To check PKI replication agreements for specific hostname,
 run:
 
 # ipa-csreplica-manage list `hostname` Directory Manager
 password:
 
 vm-089.idm.lab.bos.redhat.com
 
 Check man ipa-csreplica-manage for advise how to delete or
 create the PKI agreements.
 
 HTH, Martin
 
 
 Yeah here is what I get: ipa-csreplica-manage list Directory
 Manager password:
 
 ipa2.example.com: CA not configured ipa.example.com: master
 
 ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance.
 
 ipa-csreplica-manage list ipa2.example.com Directory Manager
 password:
 
 Can't contact LDAP server
 
 Which I guess makes sense, however: ipa-csreplica-manage list -v
 ipa.example.com Directory Manager password:
 
 ipa2.example.com last init status: None last init ended: None 
 last update status: -1  - LDAP error: Can't contact LDAP 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-04 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/04/2014 01:51 PM, Ade Lee wrote:
 OK - I suspect you may be running into an issue with serial number 
 generation.  Each time we install a clone, we end up allocating a
 new range of serial numbers for the clone.
 
 The idea is to keep separate ranges for each CA replica so that no
 two replicas can issue certs with the same serial number.
 
 The problem is that you've probably retried the install a whole
 bunch of times and now perhaps the serial number range is too
 high.
 
 This is just a guess - but you can see what ranges have been
 assigned by looking in :
 
 1,  ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg
 for the master  (look for the attributes dbs.* 3. The value of the
 attribute nextRange on : ou=certificateRepository, o=ipaca and
 ou=Requests, o=ipaca
 
 Please send me that info, and I'll explain how to clean that up.
 
 Ade
 
 On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote:
 On 08/04/2014 11:48 AM, Ade Lee wrote:
 OK - so its not really even getting started on the install.
 My guess is there is some cruft from previous
 installs/uninstalls that was not cleaned up.  Is there anything
 in the directory server logs on the RHEL7 machine? What
 operation is being attempted that the server is refusing to
 perform?
 
 Ade
 
 
 Ok I moved on past this issue. Problem was minssf was set to 56
 on the RHEL 7 dirsrv instance, setting it to 0 resolved this
 issue. Thanks for having me check the dir on the RHEL 7 instance
 I was assuming it was hitting against the RHEL 6.5 instance and
 was finding basically nothing there.
 
 
 This run looks like it pulled a lot more information in but it
 still errored out.
 
 ipa : DEBUGstderr=pkispawn: WARNING  ...
 unable to validate security domain user/password through REST
 interface. Interface not available pkispawn: ERROR...
 Exception from Java Configuration Servlet: Error in confguring
 system certificatesjava.security.cert.CertificateException:
 Unable to initialize, java.io.IOException: DerInput.getLength():
 lengthTag=127, too big.
 
 ipa : CRITICAL failed to configure ca instance Command 
 '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero
 exit status 1
 
 From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7
 instance:
 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with 
 mininum 3 and maximum 15 connections to host ipa2.abaqis.com port
 389, secure connection, false, authentication type 1 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum 
 connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]:
 new total available connections 3 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of
 connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In 
 LdapBoundConnFactory::getConn() 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is
 connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]:
 getConn: conn is connected true 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns
 now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: 
 param=preop.internaldb.post_ldif 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif
 file = /usr/share/pki/ca/conf/vlv.ldif 
 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif
 file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS():
 LDAP Errors in importing
 /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]:
 LDAPUtil:importLDIF: exception in adding entry
 cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins,
 cn=config:netscape.ldap.LDAPException: error result (32);
 matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]:
 LDAPUtil:importLDIF: exception in adding entry
 cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database,
 cn=plugins, cn=config:netscape.ldap.LDAPException: error result
 (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]:
 LDAPUtil:importLDIF: exception in adding entry
 cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database,
 cn=plugins, cn=config:netscape.ldap.LDAPException: error result
 (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]:
 LDAPUtil:importLDIF: exception in adding entry
 cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm
 database, cn=plugins, cn=config:netscape.ldap.LDAPException:
 error result (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]:
 LDAPUtil:importLDIF: exception in adding entry
 cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database,
 cn=plugins, cn=config:netscape.ldap.LDAPException: error result
 (32); matchedDN = o=ipaca
 
 [04/Aug/2014:19:02:37][http-bio-8443-exec-3]:
 LDAPUtil:importLDIF: exception in adding entry
 cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database,
 cn=plugins, 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-03 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/30/2014 02:31 PM, Ade Lee wrote:
 On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote:
 
 
 Ok, well I tried deleting it using certutil it deletes both,
 I tried using keytool to see if it would work any better, no
 dice there. I'll try the rename, but at this point I am not
 holding my breath on that, it seems all operation are a bit
 too coarse. It seems the assumption was being made that there
 would only be one of each nickname. Which frankly makes me
 wonder how any of this kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using
 python.
 
 It is a little strange that there are multiple 'caSigningCert 
 cert-pki-ca' as this is the CA itself. It should be good for
 20 years and isn't something that the current renewal code
 handles yet.
 
 You probably won't have much luck with python-nss. It can
 handle reading PKCS#12 files but I don't believe it can write
 them (access to key material).
 
 I'm not sure why certutil didn't do the trick. This should
 work, if you want to give it another try. I'm assuming that
 /root/cacert.p12 has the latest exported certs, adjust as
 necessary:
 
 # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d 
 /tmp/test # certutil -D -d /tmp/test -n 'nickname'
 
 certutil should delete the oldest cert first, it always has
 for me.
 
 rob
 
 
 Ok folks I managed to clean up the certificate DB so there is
 only one valid certificate for each service. Installation
 continued pass that step and then failed shortly thereafter on
 configuring the ca. So here is my new error:
 
 
 pkispawn: ERROR... Exception from Java Configuration 
 Servlet: Error while updating security domain:
 java.io.IOException: 2 pkispawn: DEBUG... Error Type:
 HTTPError pkispawn: DEBUG... Error Message: 500
 Server Error: Internal Server Error pkispawn: DEBUG
 ...   File /usr/sbin/pkispawn, line 374, in main rv =
 instance.spawn() File 
 /usr/lib/python2.7/site-packages/pki/deployment/configuration.py,

 
line 128, in spawn
 json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File
 /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py, 
 line 2998, in configure_pki_data response =
 client.configure(data) File
 /usr/lib/python2.7/site-packages/pki/system.py, line 80, in 
 configure r = self.connection.post('/rest/installer/configure',
 data, headers) File
 /usr/lib/python2.7/site-packages/pki/client.py, line 64, in
 post r.raise_for_status() File
 /usr/lib/python2.7/site-packages/requests/models.py, line 638,
 in raise_for_status raise http_error
 
 
 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance
 Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned
 non-zero exit status 1 2014-07-30T00:27:48Z DEBUG   File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,

 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in main CA =
 cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command
 failed, exception: RuntimeError: Configuration of CA failed
 
 And from the pki-tomcat/ca debug log: isSDHostDomainMaster():
 Getting domain.xml from CA... 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
 status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
 getDomainXML: domainInfo=?xml version=1.0 encoding=UTF-8 
 standalone=no?DomainInfoNameIPA/NameCAListCAHostipa.example.com/HostSecurePort443/SecurePortSecureAgentPort443/SecureAgentPortSecureAdminPort443/SecureAdminPortSecureEEClientAuthPort443/SecureEEClientAuthPortUnSecurePort80/UnSecurePortCloneFALSE/CloneSubsystemNamepki-cad/SubsystemNameDomainManagerTRUE/DomainManager/CASubsystemCount1/SubsystemCount/CAListOCSPListSubsystemCount0/SubsystemCount/OCSPListKRAListSubsystemCount0/SubsystemCount/KRAListRAListSubsystemCount0/SubsystemCount/RAListTKSListSubsystemCount0/SubsystemCount/TKSListTPSListSubsystemCount0/SubsystemCount/TPSList/DomainInfo

 
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase 
 updateDomainXML start hostname=ipa.example.com port=443 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
 updateSecurityDomain: failed to update security domain using
 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-08-03 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


 
 
 
 Whether related or not I am getting the following in my RHEL 6.5
 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log:
 
 [26/Jul/2014:20:23:23 +] slapi_ldap_bind - Error: could not
 send startTLS re quest: error -1 (Can't contact LDAP server) errno
 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23
 +] NSMMReplicationPlugin - agmt=cn=masterAgreement1-i 
 pa2.example.com-pki-ca (ipa2:7389): Replication bind with SIMPLE
 auth failed: LD AP error -1 (Can't contact LDAP server) ((null)) 
 [26/Jul/2014:20:23:37 +] slapi_ldap_bind - Error: could not
 send startTLS re quest: error -1 (Can't contact LDAP server) errno
 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48
 +] slapi_ldap_bind - Error: could not send startTLS re quest:
 error -1 (Can't contact LDAP server) errno 107 (Transport endpoint
 is not connected)
 
 And these errors just continue to be logged.
 
 When attempting to run ipa-ca-install -d on the RHEL 7 replica
 (all other services are on there running fine) I receive the
 following:
 
 ipa : CRITICAL failed to configure ca instance Command 
 '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero 
 exit status 1 ipa : DEBUG  File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,

 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-ca-install, line 179, in main CA =
 cainstance.install_replica_ca(config, postinstall=True)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 ipa : DEBUGThe ipa-ca-install command failed,
 exception: RuntimeError: Configuration of CA failed
 
 Your system may be partly configured. Run
 /usr/sbin/ipa-server-install --uninstall to clean up.
 
 Configuration of CA failed
 
 
 So this behavior changed after restarting the IPA service on the
 RHEL 6.5 system.
 
 So at this point I have a RHEL 6.5 system and a RHEL 7 replica of 
 everything except the CA. The RHEL 6.5 system, when the IPA service
 is restarted throws an error, perhaps from schema change?
 
 Any ideas?
 
 -Erinn
 
 

I went in and debugged this a bit further by changing the verbosity
for nsslapd-errorlog-level. It appears that the rhel 6.5 system is
attempting to connect to the RHEL 7 system on port 7389 and since the
RHEL 7 system does not have the CA installed this would obviously
fail. This leads me to believe that there is cruft in the directory
that is pointing to the wrong place. I don't think this will fix my
second group of errors, but how does one view the replication
agreements specifically for the ca?

As well I omitted to lines from the ipa-ca-install error which are
probably pertinent:

ERROR:  Unable to access directory server: Server is unwilling to perform

ipa : DEBUGstderr=

- -Erinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT3vPJAAoJEFg7BmJL2iPOv+MH/iRgdN+7R5q3BtQE9RcoZHss
eMoUIEwAji/I1ddHklZc03p9fU5HTHlKKqRcfRGLA5nka5q3g4ZKlqh+N4BVoZrq
2wGxhD4Qh1Ye3TzwuB2Ex2oXQmRqrd96irdUnu/nf5LoFz0eBMPOcdAGRX6uMyoa
lRF91cLX4HlA3neL0cSGsAp376WGMnU/EWdnriGmORkkoIqmYkR/38GYPCC3qoYG
hYJK/YjInQxv1B5bXCJ/IQC3xgKkeXlzDiChp4rLNSJXWByxX3hcxTZ51YqTE49d
t+yNIGkQk73yojW7WBluw2IidYXFEqqO/ORTMsd2mWUHDaGID+G3q9VCLdRHp/s=
=Qv14
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-07-31 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/30/2014 02:31 PM, Ade Lee wrote:
 On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote:
 
 
 Ok, well I tried deleting it using certutil it deletes both,
 I tried using keytool to see if it would work any better, no
 dice there. I'll try the rename, but at this point I am not
 holding my breath on that, it seems all operation are a bit
 too coarse. It seems the assumption was being made that there
 would only be one of each nickname. Which frankly makes me
 wonder how any of this kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using
 python.
 
 It is a little strange that there are multiple 'caSigningCert 
 cert-pki-ca' as this is the CA itself. It should be good for
 20 years and isn't something that the current renewal code
 handles yet.
 
 You probably won't have much luck with python-nss. It can
 handle reading PKCS#12 files but I don't believe it can write
 them (access to key material).
 
 I'm not sure why certutil didn't do the trick. This should
 work, if you want to give it another try. I'm assuming that
 /root/cacert.p12 has the latest exported certs, adjust as
 necessary:
 
 # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d 
 /tmp/test # certutil -D -d /tmp/test -n 'nickname'
 
 certutil should delete the oldest cert first, it always has
 for me.
 
 rob
 
 
 Ok folks I managed to clean up the certificate DB so there is
 only one valid certificate for each service. Installation
 continued pass that step and then failed shortly thereafter on
 configuring the ca. So here is my new error:
 
 
 pkispawn: ERROR... Exception from Java Configuration 
 Servlet: Error while updating security domain:
 java.io.IOException: 2 pkispawn: DEBUG... Error Type:
 HTTPError pkispawn: DEBUG... Error Message: 500
 Server Error: Internal Server Error pkispawn: DEBUG
 ...   File /usr/sbin/pkispawn, line 374, in main rv =
 instance.spawn() File 
 /usr/lib/python2.7/site-packages/pki/deployment/configuration.py,

 
line 128, in spawn
 json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File
 /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py, 
 line 2998, in configure_pki_data response =
 client.configure(data) File
 /usr/lib/python2.7/site-packages/pki/system.py, line 80, in 
 configure r = self.connection.post('/rest/installer/configure',
 data, headers) File
 /usr/lib/python2.7/site-packages/pki/client.py, line 64, in
 post r.raise_for_status() File
 /usr/lib/python2.7/site-packages/requests/models.py, line 638,
 in raise_for_status raise http_error
 
 
 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance
 Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned
 non-zero exit status 1 2014-07-30T00:27:48Z DEBUG   File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,

 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in main CA =
 cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command
 failed, exception: RuntimeError: Configuration of CA failed
 
 And from the pki-tomcat/ca debug log: isSDHostDomainMaster():
 Getting domain.xml from CA... 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
 status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
 getDomainXML: domainInfo=?xml version=1.0 encoding=UTF-8 
 standalone=no?DomainInfoNameIPA/NameCAListCAHostipa.example.com/HostSecurePort443/SecurePortSecureAgentPort443/SecureAgentPortSecureAdminPort443/SecureAdminPortSecureEEClientAuthPort443/SecureEEClientAuthPortUnSecurePort80/UnSecurePortCloneFALSE/CloneSubsystemNamepki-cad/SubsystemNameDomainManagerTRUE/DomainManager/CASubsystemCount1/SubsystemCount/CAListOCSPListSubsystemCount0/SubsystemCount/OCSPListKRAListSubsystemCount0/SubsystemCount/KRAListRAListSubsystemCount0/SubsystemCount/RAListTKSListSubsystemCount0/SubsystemCount/TKSListTPSListSubsystemCount0/SubsystemCount/TPSList/DomainInfo

 
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase 
 updateDomainXML start hostname=ipa.example.com port=443 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
 updateSecurityDomain: failed to update security domain using
 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-31 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/30/2014 02:31 PM, Ade Lee wrote:
 On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote:
 
 
 Ok, well I tried deleting it using certutil it deletes both,
 I tried using keytool to see if it would work any better, no
 dice there. I'll try the rename, but at this point I am not
 holding my breath on that, it seems all operation are a bit
 too coarse. It seems the assumption was being made that there
 would only be one of each nickname. Which frankly makes me
 wonder how any of this kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using
 python.
 
 It is a little strange that there are multiple 'caSigningCert 
 cert-pki-ca' as this is the CA itself. It should be good for
 20 years and isn't something that the current renewal code
 handles yet.
 
 You probably won't have much luck with python-nss. It can
 handle reading PKCS#12 files but I don't believe it can write
 them (access to key material).
 
 I'm not sure why certutil didn't do the trick. This should
 work, if you want to give it another try. I'm assuming that
 /root/cacert.p12 has the latest exported certs, adjust as
 necessary:
 
 # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d 
 /tmp/test # certutil -D -d /tmp/test -n 'nickname'
 
 certutil should delete the oldest cert first, it always has
 for me.
 
 rob
 
 
 Ok folks I managed to clean up the certificate DB so there is
 only one valid certificate for each service. Installation
 continued pass that step and then failed shortly thereafter on
 configuring the ca. So here is my new error:
 
 
 pkispawn: ERROR... Exception from Java Configuration 
 Servlet: Error while updating security domain:
 java.io.IOException: 2 pkispawn: DEBUG... Error Type:
 HTTPError pkispawn: DEBUG... Error Message: 500
 Server Error: Internal Server Error pkispawn: DEBUG
 ...   File /usr/sbin/pkispawn, line 374, in main rv =
 instance.spawn() File 
 /usr/lib/python2.7/site-packages/pki/deployment/configuration.py,

 
line 128, in spawn
 json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File
 /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py, 
 line 2998, in configure_pki_data response =
 client.configure(data) File
 /usr/lib/python2.7/site-packages/pki/system.py, line 80, in 
 configure r = self.connection.post('/rest/installer/configure',
 data, headers) File
 /usr/lib/python2.7/site-packages/pki/client.py, line 64, in
 post r.raise_for_status() File
 /usr/lib/python2.7/site-packages/requests/models.py, line 638,
 in raise_for_status raise http_error
 
 
 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance
 Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned
 non-zero exit status 1 2014-07-30T00:27:48Z DEBUG   File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,

 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in main CA =
 cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command
 failed, exception: RuntimeError: Configuration of CA failed
 
 And from the pki-tomcat/ca debug log: isSDHostDomainMaster():
 Getting domain.xml from CA... 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
 status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
 getDomainXML: domainInfo=?xml version=1.0 encoding=UTF-8 
 standalone=no?DomainInfoNameIPA/NameCAListCAHostipa.example.com/HostSecurePort443/SecurePortSecureAgentPort443/SecureAgentPortSecureAdminPort443/SecureAdminPortSecureEEClientAuthPort443/SecureEEClientAuthPortUnSecurePort80/UnSecurePortCloneFALSE/CloneSubsystemNamepki-cad/SubsystemNameDomainManagerTRUE/DomainManager/CASubsystemCount1/SubsystemCount/CAListOCSPListSubsystemCount0/SubsystemCount/OCSPListKRAListSubsystemCount0/SubsystemCount/KRAListRAListSubsystemCount0/SubsystemCount/RAListTKSListSubsystemCount0/SubsystemCount/TKSListTPSListSubsystemCount0/SubsystemCount/TPSList/DomainInfo

 
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase 
 updateDomainXML start hostname=ipa.example.com port=443 
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
 updateSecurityDomain: failed to update security domain using
 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-30 Thread Ade Lee
On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote:
  
 
  Ok, well I tried deleting it using certutil it deletes both, I
  tried using keytool to see if it would work any better, no dice
  there. I'll try the rename, but at this point I am not holding my
  breath on that, it seems all operation are a bit too coarse. It
  seems the assumption was being made that there would only be one
  of each nickname. Which frankly makes me wonder how any of this
  kept running after the renewal.
  
  For now I'll see what I can do on a copy of the db using python.
  
  It is a little strange that there are multiple 'caSigningCert 
  cert-pki-ca' as this is the CA itself. It should be good for 20
  years and isn't something that the current renewal code handles
  yet.
  
  You probably won't have much luck with python-nss. It can handle
  reading PKCS#12 files but I don't believe it can write them (access
  to key material).
  
  I'm not sure why certutil didn't do the trick. This should work, if
  you want to give it another try. I'm assuming that /root/cacert.p12
  has the latest exported certs, adjust as necessary:
  
  # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d
  /tmp/test # certutil -D -d /tmp/test -n 'nickname'
  
  certutil should delete the oldest cert first, it always has for
  me.
  
  rob
  
 
 Ok folks I managed to clean up the certificate DB so there is only one
 valid certificate for each service. Installation continued pass that
 step and then failed shortly thereafter on configuring the ca. So here
 is my new error:
 
 
 pkispawn: ERROR... Exception from Java Configuration
 Servlet: Error while updating security domain: java.io.IOException: 2
 pkispawn: DEBUG... Error Type: HTTPError
 pkispawn: DEBUG... Error Message: 500 Server Error:
 Internal Server Error
 pkispawn: DEBUG...   File /usr/sbin/pkispawn, line 374,
 in main
 rv = instance.spawn()
   File
 /usr/lib/python2.7/site-packages/pki/deployment/configuration.py,
 line 128, in spawn
 json.dumps(data, cls=pki.encoder.CustomTypeEncoder))
   File /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py,
 line 2998, in configure_pki_data
 response = client.configure(data)
   File /usr/lib/python2.7/site-packages/pki/system.py, line 80, in
 configure
 r = self.connection.post('/rest/installer/configure', data, headers)
   File /usr/lib/python2.7/site-packages/pki/client.py, line 64, in post
 r.raise_for_status()
   File /usr/lib/python2.7/site-packages/requests/models.py, line
 638, in raise_for_status
 raise http_error
 
 
 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance Command
 '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned non-zero
 exit status 1
 2014-07-30T00:27:48Z DEBUG   File
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
 line 638, in run_script
 return_value = main_function()
 
   File /usr/sbin/ipa-replica-install, line 667, in main
 CA = cainstance.install_replica_ca(config)
 
   File
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
   File
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 line 478, in configure_instance
 self.start_creation(runtime=210)
 
   File
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
 364, in start_creation
 method()
 
   File
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command failed,
 exception: RuntimeError: Configuration of CA failed
 
 And from the pki-tomcat/ca debug log:
 isSDHostDomainMaster(): Getting domain.xml from CA...
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML: status=0
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
 domainInfo=?xml version=1.0 encoding=UTF-8
 standalone=no?DomainInfoNameIPA/NameCAListCAHostipa.example.com/HostSecurePort443/SecurePortSecureAgentPort443/SecureAgentPortSecureAdminPort443/SecureAdminPortSecureEEClientAuthPort443/SecureEEClientAuthPortUnSecurePort80/UnSecurePortCloneFALSE/CloneSubsystemNamepki-cad/SubsystemNameDomainManagerTRUE/DomainManager/CASubsystemCount1/SubsystemCount/CAListOCSPListSubsystemCount0/SubsystemCount/OCSPListKRAListSubsystemCount0/SubsystemCount/KRAListRAListSubsystemCount0/SubsystemCount/RAListTKSListSubsystemCount0/SubsystemCount/TKSListTPSListSubsystemCount0/SubsystemCount/TPSList/DomainInfo
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase
 updateDomainXML start hostname=ipa.example.com port=443
 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateSecurityDomain:
 failed to update security domain using admin port 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-29 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

 

 Ok, well I tried deleting it using certutil it deletes both, I
 tried using keytool to see if it would work any better, no dice
 there. I'll try the rename, but at this point I am not holding my
 breath on that, it seems all operation are a bit too coarse. It
 seems the assumption was being made that there would only be one
 of each nickname. Which frankly makes me wonder how any of this
 kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using python.
 
 It is a little strange that there are multiple 'caSigningCert 
 cert-pki-ca' as this is the CA itself. It should be good for 20
 years and isn't something that the current renewal code handles
 yet.
 
 You probably won't have much luck with python-nss. It can handle
 reading PKCS#12 files but I don't believe it can write them (access
 to key material).
 
 I'm not sure why certutil didn't do the trick. This should work, if
 you want to give it another try. I'm assuming that /root/cacert.p12
 has the latest exported certs, adjust as necessary:
 
 # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d
 /tmp/test # certutil -D -d /tmp/test -n 'nickname'
 
 certutil should delete the oldest cert first, it always has for
 me.
 
 rob
 

Ok folks I managed to clean up the certificate DB so there is only one
valid certificate for each service. Installation continued pass that
step and then failed shortly thereafter on configuring the ca. So here
is my new error:


pkispawn: ERROR... Exception from Java Configuration
Servlet: Error while updating security domain: java.io.IOException: 2
pkispawn: DEBUG... Error Type: HTTPError
pkispawn: DEBUG... Error Message: 500 Server Error:
Internal Server Error
pkispawn: DEBUG...   File /usr/sbin/pkispawn, line 374,
in main
rv = instance.spawn()
  File
/usr/lib/python2.7/site-packages/pki/deployment/configuration.py,
line 128, in spawn
json.dumps(data, cls=pki.encoder.CustomTypeEncoder))
  File /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py,
line 2998, in configure_pki_data
response = client.configure(data)
  File /usr/lib/python2.7/site-packages/pki/system.py, line 80, in
configure
r = self.connection.post('/rest/installer/configure', data, headers)
  File /usr/lib/python2.7/site-packages/pki/client.py, line 64, in post
r.raise_for_status()
  File /usr/lib/python2.7/site-packages/requests/models.py, line
638, in raise_for_status
raise http_error


2014-07-30T00:27:48Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned non-zero
exit status 1
2014-07-30T00:27:48Z DEBUG   File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()

  File /usr/sbin/ipa-replica-install, line 667, in main
CA = cainstance.install_replica_ca(config)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
364, in start_creation
method()

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')

2014-07-30T00:27:48Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed

And from the pki-tomcat/ca debug log:
isSDHostDomainMaster(): Getting domain.xml from CA...
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML: status=0
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
domainInfo=?xml version=1.0 encoding=UTF-8
standalone=no?DomainInfoNameIPA/NameCAListCAHostipa.example.com/HostSecurePort443/SecurePortSecureAgentPort443/SecureAgentPortSecureAdminPort443/SecureAdminPortSecureEEClientAuthPort443/SecureEEClientAuthPortUnSecurePort80/UnSecurePortCloneFALSE/CloneSubsystemNamepki-cad/SubsystemNameDomainManagerTRUE/DomainManager/CASubsystemCount1/SubsystemCount/CAListOCSPListSubsystemCount0/SubsystemCount/OCSPListKRAListSubsystemCount0/SubsystemCount/KRAListRAListSubsystemCount0/SubsystemCount/RAListTKSListSubsystemCount0/SubsystemCount/TKSListTPSListSubsystemCount0/SubsystemCount/TPSList/DomainInfo
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipa.example.com port=443
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateSecurityDomain:
failed to update security domain using admin port 443:
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White
spaces are required between publicId and systemId.

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 08:04 AM, Ade Lee wrote:
 On Mon, 2014-07-28 at 07:41 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 07:17 AM, Rob Crittenden wrote:
 Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 07/27/2014 12:02 AM, Erinn Looney-Triggs wrote:
 On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
 On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
 Well it hasn't been all the pretty trying to move
 from RHEL 6.5 to RHEL 7.
 
 I have two servers providing my ipa instances ipa
 and ipa2. Given that I don't have a great deal of
 spare capacity the plan was to remove ipa2 from the
 replication agreement, modify DNS so that only IPA
 was available in SRV logs (IPA does not manage DNS at
 this point, was waiting for DNSSEC). As well, I would
 change my sudo-ldap config files to point to ipa and
 remove ipa2.
 
 Well that all worked well, installed RHEL 7 on the
 system and began working through the steps in the
 upgrade guide.
 
 First major problem was running into this bug: 
 https://fedorahosted.org/freeipa/ticket/4375
 ValueError: nsDS5ReplicaId has 2 values, one
 expected.
 
 Went and patched the replication.py file to get
 around that issue, and we moved on.
 
 Next up is my current issue: Exception from Java 
 Configuration Servlet: Clone does not have all the 
 required certificates.
 
 I suspect this is because I am running the CA as a 
 subordinate to an AD CS instance, but I am unsure at
 this point.
 
 It has been a haul to get here, despite the short 
 explanation. It seems that my primary ipa instance
 is working on only a hit or miss basis for kerberos
 tickets which has made all this a bit of a pain. You
 can kinit as admin once it will fail unable to find
 KDC, try again another three times, it will work. I
 have even modified the krb5.conf file to point
 directly at the server, thus bypassing DNS SRV
 lookups, however, that hasn't worked.
 
 Point is, any help would be appreciated on the 
 aforementioned error.
 
 -Erinn
 
 
 To reply to myself here, I believe the problem may be
 that I had to renew the CA certificates and as such
 the certificates in /root/cacert.p12 are no longer
 valid. It is this file that gets bundled up with
 whatever else using ipa-replica-prepare, so I will have
 to create a new one that has the valid certificates in
 it.
 
 One way or another though, if it isn't already
 documented, during a CA renewal this file should
 probably be updated with the correct certificates.
 
 -Erinn
 
 -Erinn
 
 
 
 Well thanks to this: 
 http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password




 
I have gotten a little further down the road an created a new
 cacert.p12 which looks to be complete.
 
 However, installation still fails in the same place:
 
 2014-07-27T06:33:04Z DEBUG Starting external process 
 2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn -s CA
 -f /tmp/tmp5QGhUx 2014-07-27T06:33:25Z DEBUG Process
 finished, return code=1 2014-07-27T06:33:25Z DEBUG
 stdout=Loading deployment configuration from
 /tmp/tmp5QGhUx. Installing CA into
 /var/lib/pki/pki-tomcat. Storing deployment configuration
 into 
 /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. 
 Installation failed.
 
 
 2014-07-27T06:33:25Z DEBUG stderr=pkispawn: WARNING 
 ... unable to validate security domain user/password 
 through REST interface. Interface not available pkispawn
 : ERROR... Exception from Java Configuration
 Servlet: Clone does not have all the required
 certificates
 
 2014-07-27T06:33:25Z CRITICAL failed to configure ca 
 instance Command '/usr/sbin/pkispawn -s CA -f
 /tmp/tmp5QGhUx' returned non-zero exit status 1
 2014-07-27T06:33:25Z DEBUG File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,





 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in main
 CA = cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,





 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,





 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,



 
line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,





 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-27T06:33:25Z DEBUG The ipa-replica-install
 command failed, exception: RuntimeError: Configuration of
 CA failed
 
 
 So some of the required certificates must be missing
 still.
 
 Unhelpfully, the ipa-server-install --uninstall process
 is not cleaning up everything after this failure, it
 leaves the CA intact and the next run through the
 installer believes the CA is working so it does not
 configure it. As such, I guess a re-install is necessary
 or 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-28 Thread Ade Lee
On Mon, 2014-07-28 at 08:26 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 08:04 AM, Ade Lee wrote:
  On Mon, 2014-07-28 at 07:41 -0700, Erinn Looney-Triggs wrote:
  On 07/28/2014 07:17 AM, Rob Crittenden wrote:
  Rob Crittenden wrote:
  Erinn Looney-Triggs wrote:
  On 07/27/2014 12:02 AM, Erinn Looney-Triggs wrote:
  On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
  On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
  Well it hasn't been all the pretty trying to move
  from RHEL 6.5 to RHEL 7.
  
  I have two servers providing my ipa instances ipa
  and ipa2. Given that I don't have a great deal of
  spare capacity the plan was to remove ipa2 from the
  replication agreement, modify DNS so that only IPA
  was available in SRV logs (IPA does not manage DNS at
  this point, was waiting for DNSSEC). As well, I would
  change my sudo-ldap config files to point to ipa and
  remove ipa2.
  
  Well that all worked well, installed RHEL 7 on the
  system and began working through the steps in the
  upgrade guide.
  
  First major problem was running into this bug: 
  https://fedorahosted.org/freeipa/ticket/4375
  ValueError: nsDS5ReplicaId has 2 values, one
  expected.
  
  Went and patched the replication.py file to get
  around that issue, and we moved on.
  
  Next up is my current issue: Exception from Java 
  Configuration Servlet: Clone does not have all the 
  required certificates.
  
  I suspect this is because I am running the CA as a 
  subordinate to an AD CS instance, but I am unsure at
  this point.
  
  It has been a haul to get here, despite the short 
  explanation. It seems that my primary ipa instance
  is working on only a hit or miss basis for kerberos
  tickets which has made all this a bit of a pain. You
  can kinit as admin once it will fail unable to find
  KDC, try again another three times, it will work. I
  have even modified the krb5.conf file to point
  directly at the server, thus bypassing DNS SRV
  lookups, however, that hasn't worked.
  
  Point is, any help would be appreciated on the 
  aforementioned error.
  
  -Erinn
  
  
  To reply to myself here, I believe the problem may be
  that I had to renew the CA certificates and as such
  the certificates in /root/cacert.p12 are no longer
  valid. It is this file that gets bundled up with
  whatever else using ipa-replica-prepare, so I will have
  to create a new one that has the valid certificates in
  it.
  
  One way or another though, if it isn't already
  documented, during a CA renewal this file should
  probably be updated with the correct certificates.
  
  -Erinn
  
  -Erinn
  
  
  
  Well thanks to this: 
  http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
 
 
 
 
  
 I have gotten a little further down the road an created a new
  cacert.p12 which looks to be complete.
  
  However, installation still fails in the same place:
  
  2014-07-27T06:33:04Z DEBUG Starting external process 
  2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn -s CA
  -f /tmp/tmp5QGhUx 2014-07-27T06:33:25Z DEBUG Process
  finished, return code=1 2014-07-27T06:33:25Z DEBUG
  stdout=Loading deployment configuration from
  /tmp/tmp5QGhUx. Installing CA into
  /var/lib/pki/pki-tomcat. Storing deployment configuration
  into 
  /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. 
  Installation failed.
  
  
  2014-07-27T06:33:25Z DEBUG stderr=pkispawn: WARNING 
  ... unable to validate security domain user/password 
  through REST interface. Interface not available pkispawn
  : ERROR... Exception from Java Configuration
  Servlet: Clone does not have all the required
  certificates
  
  2014-07-27T06:33:25Z CRITICAL failed to configure ca 
  instance Command '/usr/sbin/pkispawn -s CA -f
  /tmp/tmp5QGhUx' returned non-zero exit status 1
  2014-07-27T06:33:25Z DEBUG File 
  /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
 
 
 
 
 
  
 line 638, in run_script
  return_value = main_function()
  
  File /usr/sbin/ipa-replica-install, line 667, in main
  CA = cainstance.install_replica_ca(config)
  
  File 
  /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 
 
 
 
 
  
 line 1678, in install_replica_ca
  subject_base=config.subject_base)
  
  File 
  /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 
 
 
 
 
  
 line 478, in configure_instance
  self.start_creation(runtime=210)
  
  File 
  /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 
 
 
  
 line 364, in start_creation method()
  
  File 
  /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
 
 
 
 
 
  
 line 604, in __spawn_instance
  raise RuntimeError('Configuration of CA failed')
  
  2014-07-27T06:33:25Z DEBUG The ipa-replica-install
  command failed, exception: RuntimeError: Configuration of
  CA failed
  
  
  So some of the required certificates must be missing
  still.
  
  Unhelpfully, the ipa-server-install --uninstall process
  is not cleaning up everything 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 11:07 AM, Ade Lee wrote:
 On Mon, 2014-07-28 at 08:26 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 08:04 AM, Ade Lee wrote:
 On Mon, 2014-07-28 at 07:41 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 07:17 AM, Rob Crittenden wrote:
 Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 07/27/2014 12:02 AM, Erinn Looney-Triggs wrote:
 On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
 On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
 Well it hasn't been all the pretty trying to
 move from RHEL 6.5 to RHEL 7.
 
 I have two servers providing my ipa instances
 ipa and ipa2. Given that I don't have a great
 deal of spare capacity the plan was to remove
 ipa2 from the replication agreement, modify DNS
 so that only IPA was available in SRV logs (IPA
 does not manage DNS at this point, was waiting
 for DNSSEC). As well, I would change my sudo-ldap
 config files to point to ipa and remove ipa2.
 
 Well that all worked well, installed RHEL 7 on
 the system and began working through the steps in
 the upgrade guide.
 
 First major problem was running into this bug: 
 https://fedorahosted.org/freeipa/ticket/4375 
 ValueError: nsDS5ReplicaId has 2 values, one 
 expected.
 
 Went and patched the replication.py file to get 
 around that issue, and we moved on.
 
 Next up is my current issue: Exception from Java
  Configuration Servlet: Clone does not have all
 the required certificates.
 
 I suspect this is because I am running the CA as
 a subordinate to an AD CS instance, but I am
 unsure at this point.
 
 It has been a haul to get here, despite the short
  explanation. It seems that my primary ipa
 instance is working on only a hit or miss basis
 for kerberos tickets which has made all this a
 bit of a pain. You can kinit as admin once it
 will fail unable to find KDC, try again another
 three times, it will work. I have even modified
 the krb5.conf file to point directly at the
 server, thus bypassing DNS SRV lookups, however,
 that hasn't worked.
 
 Point is, any help would be appreciated on the 
 aforementioned error.
 
 -Erinn
 
 
 To reply to myself here, I believe the problem may
 be that I had to renew the CA certificates and as
 such the certificates in /root/cacert.p12 are no
 longer valid. It is this file that gets bundled up
 with whatever else using ipa-replica-prepare, so I
 will have to create a new one that has the valid
 certificates in it.
 
 One way or another though, if it isn't already 
 documented, during a CA renewal this file should 
 probably be updated with the correct certificates.
 
 -Erinn
 
 -Erinn
 
 
 
 Well thanks to this: 
 http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password






 
I have gotten a little further down the road an created a new
 cacert.p12 which looks to be complete.
 
 However, installation still fails in the same place:
 
 2014-07-27T06:33:04Z DEBUG Starting external process
  2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn
 -s CA -f /tmp/tmp5QGhUx 2014-07-27T06:33:25Z DEBUG
 Process finished, return code=1 2014-07-27T06:33:25Z
 DEBUG stdout=Loading deployment configuration from 
 /tmp/tmp5QGhUx. Installing CA into 
 /var/lib/pki/pki-tomcat. Storing deployment
 configuration into 
 /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
  Installation failed.
 
 
 2014-07-27T06:33:25Z DEBUG stderr=pkispawn:
 WARNING ... unable to validate security domain
 user/password through REST interface. Interface not
 available pkispawn : ERROR... Exception from
 Java Configuration Servlet: Clone does not have all
 the required certificates
 
 2014-07-27T06:33:25Z CRITICAL failed to configure ca
  instance Command '/usr/sbin/pkispawn -s CA -f 
 /tmp/tmp5QGhUx' returned non-zero exit status 1 
 2014-07-27T06:33:25Z DEBUG File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,







 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in
 main CA = cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,







 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,







 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,





 
line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,







 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-27T06:33:25Z DEBUG The ipa-replica-install 
 command failed, exception: RuntimeError:
 Configuration of CA failed
 
 
 So some of the required certificates must be missing 
 still.
 
 Unhelpfully, the ipa-server-install --uninstall
 process is not cleaning up everything after this
 failure, it leaves the CA intact and the next run
 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 11:07 AM, Ade Lee wrote:
 On Mon, 2014-07-28 at 08:26 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 08:04 AM, Ade Lee wrote:
 On Mon, 2014-07-28 at 07:41 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 07:17 AM, Rob Crittenden wrote:
 Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 07/27/2014 12:02 AM, Erinn Looney-Triggs wrote:
 On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
 On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
 Well it hasn't been all the pretty trying to
 move from RHEL 6.5 to RHEL 7.
 
 I have two servers providing my ipa instances
 ipa and ipa2. Given that I don't have a great
 deal of spare capacity the plan was to remove
 ipa2 from the replication agreement, modify DNS
 so that only IPA was available in SRV logs (IPA
 does not manage DNS at this point, was waiting
 for DNSSEC). As well, I would change my sudo-ldap
 config files to point to ipa and remove ipa2.
 
 Well that all worked well, installed RHEL 7 on
 the system and began working through the steps in
 the upgrade guide.
 
 First major problem was running into this bug: 
 https://fedorahosted.org/freeipa/ticket/4375 
 ValueError: nsDS5ReplicaId has 2 values, one 
 expected.
 
 Went and patched the replication.py file to get 
 around that issue, and we moved on.
 
 Next up is my current issue: Exception from Java
  Configuration Servlet: Clone does not have all
 the required certificates.
 
 I suspect this is because I am running the CA as
 a subordinate to an AD CS instance, but I am
 unsure at this point.
 
 It has been a haul to get here, despite the short
  explanation. It seems that my primary ipa
 instance is working on only a hit or miss basis
 for kerberos tickets which has made all this a
 bit of a pain. You can kinit as admin once it
 will fail unable to find KDC, try again another
 three times, it will work. I have even modified
 the krb5.conf file to point directly at the
 server, thus bypassing DNS SRV lookups, however,
 that hasn't worked.
 
 Point is, any help would be appreciated on the 
 aforementioned error.
 
 -Erinn
 
 
 To reply to myself here, I believe the problem may
 be that I had to renew the CA certificates and as
 such the certificates in /root/cacert.p12 are no
 longer valid. It is this file that gets bundled up
 with whatever else using ipa-replica-prepare, so I
 will have to create a new one that has the valid
 certificates in it.
 
 One way or another though, if it isn't already 
 documented, during a CA renewal this file should 
 probably be updated with the correct certificates.
 
 -Erinn
 
 -Erinn
 
 
 
 Well thanks to this: 
 http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password






 
I have gotten a little further down the road an created a new
 cacert.p12 which looks to be complete.
 
 However, installation still fails in the same place:
 
 2014-07-27T06:33:04Z DEBUG Starting external process
  2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn
 -s CA -f /tmp/tmp5QGhUx 2014-07-27T06:33:25Z DEBUG
 Process finished, return code=1 2014-07-27T06:33:25Z
 DEBUG stdout=Loading deployment configuration from 
 /tmp/tmp5QGhUx. Installing CA into 
 /var/lib/pki/pki-tomcat. Storing deployment
 configuration into 
 /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
  Installation failed.
 
 
 2014-07-27T06:33:25Z DEBUG stderr=pkispawn:
 WARNING ... unable to validate security domain
 user/password through REST interface. Interface not
 available pkispawn : ERROR... Exception from
 Java Configuration Servlet: Clone does not have all
 the required certificates
 
 2014-07-27T06:33:25Z CRITICAL failed to configure ca
  instance Command '/usr/sbin/pkispawn -s CA -f 
 /tmp/tmp5QGhUx' returned non-zero exit status 1 
 2014-07-27T06:33:25Z DEBUG File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,







 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in
 main CA = cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,







 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,







 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,





 
line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,







 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-27T06:33:25Z DEBUG The ipa-replica-install 
 command failed, exception: RuntimeError:
 Configuration of CA failed
 
 
 So some of the required certificates must be missing 
 still.
 
 Unhelpfully, the ipa-server-install --uninstall
 process is not cleaning up everything after this
 failure, it leaves the CA intact and the next run
 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 11:07 AM, Ade Lee wrote:
 
 No exceptions thrown in the journal.
 
 When investigating the cacert.p12 file that is bundled up for
 the replica's I see two caSigningCert's. One is the older one,
 before I renewed and one is the new, valid, post renewal one. Are
 these the certs that are used or are they requested from the
 primary much like the servercert?
 
 I think the problem might be that there are two caSigningCerts,
 with presumably the same nickname.  We need to try and generate a
 p12 file without the old pre-renewal signing cert.
 
 Does the master certdb contain both certs with the same nickname? 
 If so, you could try to remove the old signing cert from the
 master certdb and then regenerate the pkcs12 using PKCS12Export.
 
 Here is one way you could try to do this: 1. Export the caSigning
 cert from the certdb using pk12util.  Check that only the latest
 cert/key has been exported.  Make sure to note down the exact cert
 nickname.  If so, then continue .. 2. Shut down the CA. 3.
 IMPORTANT: Back up the certdb. 4. Delete the caSigning cert from
 the certdb using certutil.  You may have to do this twice to remove
 both certs. 5. Re-import the saved caSigningCert using pk12util. 6.
 Restart the CA.
 
 
 However, when examining the /etc/pki/pki-tomcat/alias db there is
 no casigningcert, hence I suppose the failure. So somewhere in
 there it is getting lost, I'll keep looking but throw me any
 ideas.
 
 By this, you are implying looking at the clone certdb, right?  The
 cert should certainly still exist on the master.  The cert not
 being in the clone certdb is because it fails to be imported from
 the PKCS12 file.
 
 
 -Erinn
 
 
 

Ok to make sure we are on the same page and I am not chasing my own
tail here, I am going to recap this as I understand the issue now.

Essentially, we get a cacert.p12 file on the master IPA server that
was generated using: PKCS12Export -d $ALIAS_PATH -p /root/keydb_pin -w
/root/dm_password -o /root/cacert.p12

This cacert.p12 file contains multiple copies of certificates, both
expired and valid, for, well, multiple aliases in fact not just the
caSigningCert.

Nevertheless, because of these multiple copies of the caSigningCert we
are venturing a guess that this is munging up the ca clone on the
replica (a fair guess I would say). So there is probably a bug in here
somewhere, either on the exporting end, or on the importing end.

So, I/we are trying to use the userspace tools to basically clean up
the NSS db to only have the valid copy of this certificate.

However, it appears to me that most of these tools are not granular
enough in their selection, the export everyhing with an alias of
'caSigningCert cert-pki-ca' or delete all instance of 'caSigningCert
cert-pki-ca'. Kind of a sledgehammer for a penny nail type thing. Does
this sound about right?

If so, it looks like a more granular approach is warranted. I'll be
looking into python-nss as python is what I know best to see if I can
hack up something to whip the DB into proper shape.

Anything I am missing here? Sound like a reasonable approach?

- -Erinn


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT1qEcAAoJEFg7BmJL2iPODSoIALnUtSlHWofmKwvFWPdvOWz4
iSW03DVLHf1bz+OQUWziWOXNStUxfLb/CIhH3PEpCT9Uf4ssxGEfnsCpqgoDGYJd
OB3YxK/BG38EkH9iIYmc+RivaWIKFdHBemHovGUgnbVzro+vnh8rboUIDM1390Ve
PL3O5nKpNMfKFwLoWU8bkqZNQxy15Ydta7nggVDNhuGT715COE7kGfRHYy9D4rlW
gPjQa8crZIPbYtqm7hpWDZHz1ha+MB+ZtkiWsNhYQ6wACTC8uhSNU51zcdwacasO
D3l51DRRwnkDDo1a2V6cgKzdVcvPLXM9jGpV8zP1qKcVKxwh1hm9W0EixULnIrM=
=69GB
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-07-28 Thread Ade Lee
On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 11:07 AM, Ade Lee wrote:
  
  No exceptions thrown in the journal.
  
  When investigating the cacert.p12 file that is bundled up for
  the replica's I see two caSigningCert's. One is the older one,
  before I renewed and one is the new, valid, post renewal one. Are
  these the certs that are used or are they requested from the
  primary much like the servercert?
  
  I think the problem might be that there are two caSigningCerts,
  with presumably the same nickname.  We need to try and generate a
  p12 file without the old pre-renewal signing cert.
  
  Does the master certdb contain both certs with the same nickname? 
  If so, you could try to remove the old signing cert from the
  master certdb and then regenerate the pkcs12 using PKCS12Export.
  
  Here is one way you could try to do this: 1. Export the caSigning
  cert from the certdb using pk12util.  Check that only the latest
  cert/key has been exported.  Make sure to note down the exact cert
  nickname.  If so, then continue .. 2. Shut down the CA. 3.
  IMPORTANT: Back up the certdb. 4. Delete the caSigning cert from
  the certdb using certutil.  You may have to do this twice to remove
  both certs. 5. Re-import the saved caSigningCert using pk12util. 6.
  Restart the CA.
  
  
  However, when examining the /etc/pki/pki-tomcat/alias db there is
  no casigningcert, hence I suppose the failure. So somewhere in
  there it is getting lost, I'll keep looking but throw me any
  ideas.
  
  By this, you are implying looking at the clone certdb, right?  The
  cert should certainly still exist on the master.  The cert not
  being in the clone certdb is because it fails to be imported from
  the PKCS12 file.
  
  
  -Erinn
  
  
  
 
 Ok to make sure we are on the same page and I am not chasing my own
 tail here, I am going to recap this as I understand the issue now.
 
 Essentially, we get a cacert.p12 file on the master IPA server that
 was generated using: PKCS12Export -d $ALIAS_PATH -p /root/keydb_pin -w
 /root/dm_password -o /root/cacert.p12
 
 This cacert.p12 file contains multiple copies of certificates, both
 expired and valid, for, well, multiple aliases in fact not just the
 caSigningCert.
 
 Nevertheless, because of these multiple copies of the caSigningCert we
 are venturing a guess that this is munging up the ca clone on the
 replica (a fair guess I would say). So there is probably a bug in here
 somewhere, either on the exporting end, or on the importing end.
 
 So, I/we are trying to use the userspace tools to basically clean up
 the NSS db to only have the valid copy of this certificate.
 
 However, it appears to me that most of these tools are not granular
 enough in their selection, the export everyhing with an alias of
 'caSigningCert cert-pki-ca' or delete all instance of 'caSigningCert
 cert-pki-ca'. Kind of a sledgehammer for a penny nail type thing. Does
 this sound about right?
 
 If so, it looks like a more granular approach is warranted. I'll be
 looking into python-nss as python is what I know best to see if I can
 hack up something to whip the DB into proper shape.
 
 Anything I am missing here? Sound like a reasonable approach?
 
That sounds exactly right.  

You could try deleting the cert using certutil -D (make sure to back up
the certdb first) and see if it will delete one or both certificates.
Or you could try renaming the cert nick using certutil and see if it
renames just one.

Ade
 -Erinn
 
 


-- 
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] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 12:20 PM, Ade Lee wrote:
 On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 11:07 AM, Ade Lee wrote:
 
 No exceptions thrown in the journal.
 
 When investigating the cacert.p12 file that is bundled up
 for the replica's I see two caSigningCert's. One is the older
 one, before I renewed and one is the new, valid, post renewal
 one. Are these the certs that are used or are they requested
 from the primary much like the servercert?
 
 I think the problem might be that there are two
 caSigningCerts, with presumably the same nickname.  We need to
 try and generate a p12 file without the old pre-renewal signing
 cert.
 
 Does the master certdb contain both certs with the same
 nickname? If so, you could try to remove the old signing cert
 from the master certdb and then regenerate the pkcs12 using
 PKCS12Export.
 
 Here is one way you could try to do this: 1. Export the
 caSigning cert from the certdb using pk12util.  Check that only
 the latest cert/key has been exported.  Make sure to note down
 the exact cert nickname.  If so, then continue .. 2. Shut down
 the CA. 3. IMPORTANT: Back up the certdb. 4. Delete the
 caSigning cert from the certdb using certutil.  You may have to
 do this twice to remove both certs. 5. Re-import the saved
 caSigningCert using pk12util. 6. Restart the CA.
 
 
 However, when examining the /etc/pki/pki-tomcat/alias db
 there is no casigningcert, hence I suppose the failure. So
 somewhere in there it is getting lost, I'll keep looking but
 throw me any ideas.
 
 By this, you are implying looking at the clone certdb, right?
 The cert should certainly still exist on the master.  The cert
 not being in the clone certdb is because it fails to be
 imported from the PKCS12 file.
 
 
 -Erinn
 
 
 
 
 Ok to make sure we are on the same page and I am not chasing my
 own tail here, I am going to recap this as I understand the issue
 now.
 
 Essentially, we get a cacert.p12 file on the master IPA server
 that was generated using: PKCS12Export -d $ALIAS_PATH -p
 /root/keydb_pin -w /root/dm_password -o /root/cacert.p12
 
 This cacert.p12 file contains multiple copies of certificates,
 both expired and valid, for, well, multiple aliases in fact not
 just the caSigningCert.
 
 Nevertheless, because of these multiple copies of the
 caSigningCert we are venturing a guess that this is munging up
 the ca clone on the replica (a fair guess I would say). So there
 is probably a bug in here somewhere, either on the exporting end,
 or on the importing end.
 
 So, I/we are trying to use the userspace tools to basically clean
 up the NSS db to only have the valid copy of this certificate.
 
 However, it appears to me that most of these tools are not
 granular enough in their selection, the export everyhing with an
 alias of 'caSigningCert cert-pki-ca' or delete all instance of
 'caSigningCert cert-pki-ca'. Kind of a sledgehammer for a penny
 nail type thing. Does this sound about right?
 
 If so, it looks like a more granular approach is warranted. I'll
 be looking into python-nss as python is what I know best to see
 if I can hack up something to whip the DB into proper shape.
 
 Anything I am missing here? Sound like a reasonable approach?
 
 That sounds exactly right.
 
 You could try deleting the cert using certutil -D (make sure to
 back up the certdb first) and see if it will delete one or both
 certificates. Or you could try renaming the cert nick using
 certutil and see if it renames just one.
 
 Ade
 -Erinn
 
 
 
 

Ok, well I tried deleting it using certutil it deletes both, I tried
using keytool to see if it would work any better, no dice there. I'll
try the rename, but at this point I am not holding my breath on that,
it seems all operation are a bit too coarse. It seems the assumption
was being made that there would only be one of each nickname. Which
frankly makes me wonder how any of this kept running after the renewal.

For now I'll see what I can do on a copy of the db using python.

- -Erinn

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT1qY0AAoJEFg7BmJL2iPOTpgH/0WSF7Hd1UI1plhfKECnM62P
zXIGVXb6SI+zy8txsjL9XPRndmy+TEFdxw858PuPJSWaGt0JNPk4uVZ8I3fa4ekS
aT5qedSyaSDMI6bNSyo8LSHap2J2CY/eNrGPHIQk31RvXCH9C8vnrbRIiDcKmVYH
UliRpntYUnuyAlIc91unkIaGJHQ4BAgCQ2gSzv40Ub9exhhTgLwguLnD1N9w0qgl
HjQrLTuLvbDDu/FYlcW9uBr16iSriw71yZyPZ4KnyOO50yP+MjHcjoXpw5d5WLc3
qYSMLRHpWHAKkyxwhz6472XfRjP+lg6zCLzB+O2/A3BbHzX9eVgI4pkC02u1Uhg=
=XPfQ
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-07-28 Thread Rob Crittenden
Erinn Looney-Triggs wrote:
 On 07/28/2014 12:20 PM, Ade Lee wrote:
 On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 11:07 AM, Ade Lee wrote:

 No exceptions thrown in the journal.

 When investigating the cacert.p12 file that is bundled up
 for the replica's I see two caSigningCert's. One is the older
 one, before I renewed and one is the new, valid, post renewal
 one. Are these the certs that are used or are they requested
 from the primary much like the servercert?

 I think the problem might be that there are two
 caSigningCerts, with presumably the same nickname.  We need to
 try and generate a p12 file without the old pre-renewal signing
 cert.

 Does the master certdb contain both certs with the same
 nickname? If so, you could try to remove the old signing cert
 from the master certdb and then regenerate the pkcs12 using
 PKCS12Export.

 Here is one way you could try to do this: 1. Export the
 caSigning cert from the certdb using pk12util.  Check that only
 the latest cert/key has been exported.  Make sure to note down
 the exact cert nickname.  If so, then continue .. 2. Shut down
 the CA. 3. IMPORTANT: Back up the certdb. 4. Delete the
 caSigning cert from the certdb using certutil.  You may have to
 do this twice to remove both certs. 5. Re-import the saved
 caSigningCert using pk12util. 6. Restart the CA.


 However, when examining the /etc/pki/pki-tomcat/alias db
 there is no casigningcert, hence I suppose the failure. So
 somewhere in there it is getting lost, I'll keep looking but
 throw me any ideas.

 By this, you are implying looking at the clone certdb, right?
 The cert should certainly still exist on the master.  The cert
 not being in the clone certdb is because it fails to be
 imported from the PKCS12 file.


 -Erinn




 Ok to make sure we are on the same page and I am not chasing my
 own tail here, I am going to recap this as I understand the issue
 now.

 Essentially, we get a cacert.p12 file on the master IPA server
 that was generated using: PKCS12Export -d $ALIAS_PATH -p
 /root/keydb_pin -w /root/dm_password -o /root/cacert.p12

 This cacert.p12 file contains multiple copies of certificates,
 both expired and valid, for, well, multiple aliases in fact not
 just the caSigningCert.

 Nevertheless, because of these multiple copies of the
 caSigningCert we are venturing a guess that this is munging up
 the ca clone on the replica (a fair guess I would say). So there
 is probably a bug in here somewhere, either on the exporting end,
 or on the importing end.

 So, I/we are trying to use the userspace tools to basically clean
 up the NSS db to only have the valid copy of this certificate.

 However, it appears to me that most of these tools are not
 granular enough in their selection, the export everyhing with an
 alias of 'caSigningCert cert-pki-ca' or delete all instance of
 'caSigningCert cert-pki-ca'. Kind of a sledgehammer for a penny
 nail type thing. Does this sound about right?

 If so, it looks like a more granular approach is warranted. I'll
 be looking into python-nss as python is what I know best to see
 if I can hack up something to whip the DB into proper shape.

 Anything I am missing here? Sound like a reasonable approach?

 That sounds exactly right.
 
 You could try deleting the cert using certutil -D (make sure to
 back up the certdb first) and see if it will delete one or both
 certificates. Or you could try renaming the cert nick using
 certutil and see if it renames just one.
 
 Ade
 -Erinn


 
 
 
 Ok, well I tried deleting it using certutil it deletes both, I tried
 using keytool to see if it would work any better, no dice there. I'll
 try the rename, but at this point I am not holding my breath on that,
 it seems all operation are a bit too coarse. It seems the assumption
 was being made that there would only be one of each nickname. Which
 frankly makes me wonder how any of this kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using python.

It is a little strange that there are multiple 'caSigningCert
cert-pki-ca' as this is the CA itself. It should be good for 20 years
and isn't something that the current renewal code handles yet.

You probably won't have much luck with python-nss. It can handle reading
PKCS#12 files but I don't believe it can write them (access to key
material).

I'm not sure why certutil didn't do the trick. This should work, if you
want to give it another try. I'm assuming that /root/cacert.p12 has the
latest exported certs, adjust as necessary:

# certutil -N -d /tmp/test
# pk12util -i /root/cacert.p12 -d /tmp/test
# certutil -D -d /tmp/test -n 'nickname'

certutil should delete the oldest cert first, it always has for me.

rob

-- 
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] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 12:56 PM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 07/28/2014 12:20 PM, Ade Lee wrote:
 On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 11:07 AM, Ade Lee wrote:
 
 No exceptions thrown in the journal.
 
 When investigating the cacert.p12 file that is bundled
 up for the replica's I see two caSigningCert's. One is
 the older one, before I renewed and one is the new,
 valid, post renewal one. Are these the certs that are
 used or are they requested from the primary much like the
 servercert?
 
 I think the problem might be that there are two 
 caSigningCerts, with presumably the same nickname.  We need
 to try and generate a p12 file without the old pre-renewal
 signing cert.
 
 Does the master certdb contain both certs with the same 
 nickname? If so, you could try to remove the old signing
 cert from the master certdb and then regenerate the pkcs12
 using PKCS12Export.
 
 Here is one way you could try to do this: 1. Export the 
 caSigning cert from the certdb using pk12util.  Check that
 only the latest cert/key has been exported.  Make sure to
 note down the exact cert nickname.  If so, then continue ..
 2. Shut down the CA. 3. IMPORTANT: Back up the certdb. 4.
 Delete the caSigning cert from the certdb using certutil.
 You may have to do this twice to remove both certs. 5.
 Re-import the saved caSigningCert using pk12util. 6.
 Restart the CA.
 
 
 However, when examining the /etc/pki/pki-tomcat/alias db 
 there is no casigningcert, hence I suppose the failure.
 So somewhere in there it is getting lost, I'll keep
 looking but throw me any ideas.
 
 By this, you are implying looking at the clone certdb,
 right? The cert should certainly still exist on the master.
 The cert not being in the clone certdb is because it fails
 to be imported from the PKCS12 file.
 
 
 -Erinn
 
 
 
 
 Ok to make sure we are on the same page and I am not chasing
 my own tail here, I am going to recap this as I understand
 the issue now.
 
 Essentially, we get a cacert.p12 file on the master IPA
 server that was generated using: PKCS12Export -d $ALIAS_PATH
 -p /root/keydb_pin -w /root/dm_password -o /root/cacert.p12
 
 This cacert.p12 file contains multiple copies of
 certificates, both expired and valid, for, well, multiple
 aliases in fact not just the caSigningCert.
 
 Nevertheless, because of these multiple copies of the 
 caSigningCert we are venturing a guess that this is munging
 up the ca clone on the replica (a fair guess I would say). So
 there is probably a bug in here somewhere, either on the
 exporting end, or on the importing end.
 
 So, I/we are trying to use the userspace tools to basically
 clean up the NSS db to only have the valid copy of this
 certificate.
 
 However, it appears to me that most of these tools are not 
 granular enough in their selection, the export everyhing with
 an alias of 'caSigningCert cert-pki-ca' or delete all
 instance of 'caSigningCert cert-pki-ca'. Kind of a
 sledgehammer for a penny nail type thing. Does this sound
 about right?
 
 If so, it looks like a more granular approach is warranted.
 I'll be looking into python-nss as python is what I know best
 to see if I can hack up something to whip the DB into proper
 shape.
 
 Anything I am missing here? Sound like a reasonable
 approach?
 
 That sounds exactly right.
 
 You could try deleting the cert using certutil -D (make sure
 to back up the certdb first) and see if it will delete one or
 both certificates. Or you could try renaming the cert nick
 using certutil and see if it renames just one.
 
 Ade
 -Erinn
 
 
 
 
 
 Ok, well I tried deleting it using certutil it deletes both, I
 tried using keytool to see if it would work any better, no dice
 there. I'll try the rename, but at this point I am not holding my
 breath on that, it seems all operation are a bit too coarse. It
 seems the assumption was being made that there would only be one
 of each nickname. Which frankly makes me wonder how any of this
 kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using python.
 
 It is a little strange that there are multiple 'caSigningCert 
 cert-pki-ca' as this is the CA itself. It should be good for 20
 years and isn't something that the current renewal code handles
 yet.
 
 You probably won't have much luck with python-nss. It can handle
 reading PKCS#12 files but I don't believe it can write them (access
 to key material).
 
 I'm not sure why certutil didn't do the trick. This should work, if
 you want to give it another try. I'm assuming that /root/cacert.p12
 has the latest exported certs, adjust as necessary:
 
 # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d
 /tmp/test # certutil -D -d /tmp/test -n 'nickname'
 
 certutil should delete the oldest cert first, it always has for
 me.
 
 rob
 

Well I reckon you don't issue certificates that are longer than the
lifetime of the 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 12:20 PM, Ade Lee wrote:
 On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 11:07 AM, Ade Lee wrote:
 
 No exceptions thrown in the journal.
 
 When investigating the cacert.p12 file that is bundled up
 for the replica's I see two caSigningCert's. One is the older
 one, before I renewed and one is the new, valid, post renewal
 one. Are these the certs that are used or are they requested
 from the primary much like the servercert?
 
 I think the problem might be that there are two
 caSigningCerts, with presumably the same nickname.  We need to
 try and generate a p12 file without the old pre-renewal signing
 cert.
 
 Does the master certdb contain both certs with the same
 nickname? If so, you could try to remove the old signing cert
 from the master certdb and then regenerate the pkcs12 using
 PKCS12Export.
 
 Here is one way you could try to do this: 1. Export the
 caSigning cert from the certdb using pk12util.  Check that only
 the latest cert/key has been exported.  Make sure to note down
 the exact cert nickname.  If so, then continue .. 2. Shut down
 the CA. 3. IMPORTANT: Back up the certdb. 4. Delete the
 caSigning cert from the certdb using certutil.  You may have to
 do this twice to remove both certs. 5. Re-import the saved
 caSigningCert using pk12util. 6. Restart the CA.
 
 
 However, when examining the /etc/pki/pki-tomcat/alias db
 there is no casigningcert, hence I suppose the failure. So
 somewhere in there it is getting lost, I'll keep looking but
 throw me any ideas.
 
 By this, you are implying looking at the clone certdb, right?
 The cert should certainly still exist on the master.  The cert
 not being in the clone certdb is because it fails to be
 imported from the PKCS12 file.
 
 
 -Erinn
 
 
 
 
 Ok to make sure we are on the same page and I am not chasing my
 own tail here, I am going to recap this as I understand the issue
 now.
 
 Essentially, we get a cacert.p12 file on the master IPA server
 that was generated using: PKCS12Export -d $ALIAS_PATH -p
 /root/keydb_pin -w /root/dm_password -o /root/cacert.p12
 
 This cacert.p12 file contains multiple copies of certificates,
 both expired and valid, for, well, multiple aliases in fact not
 just the caSigningCert.
 
 Nevertheless, because of these multiple copies of the
 caSigningCert we are venturing a guess that this is munging up
 the ca clone on the replica (a fair guess I would say). So there
 is probably a bug in here somewhere, either on the exporting end,
 or on the importing end.
 
 So, I/we are trying to use the userspace tools to basically clean
 up the NSS db to only have the valid copy of this certificate.
 
 However, it appears to me that most of these tools are not
 granular enough in their selection, the export everyhing with an
 alias of 'caSigningCert cert-pki-ca' or delete all instance of
 'caSigningCert cert-pki-ca'. Kind of a sledgehammer for a penny
 nail type thing. Does this sound about right?
 
 If so, it looks like a more granular approach is warranted. I'll
 be looking into python-nss as python is what I know best to see
 if I can hack up something to whip the DB into proper shape.
 
 Anything I am missing here? Sound like a reasonable approach?
 
 That sounds exactly right.
 
 You could try deleting the cert using certutil -D (make sure to
 back up the certdb first) and see if it will delete one or both
 certificates. Or you could try renaming the cert nick using
 certutil and see if it renames just one.
 
 Ade
 -Erinn
 
 
 
 

certutil doesn't appear to have a rename option, there looks to be a
RFE open for it that was last updated about 5 years ago:
https://bugzilla.mozilla.org/show_bug.cgi?id=448738

But if it is available in certutil it isn't documented. Though it is a
good thought, I reckoned as long as it renamed one of the certs then I
could get what I wanted to get done.

- -Erinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT1sADAAoJEFg7BmJL2iPODRkH/3FzRbUn1QRMY531sr+trFmo
Aokjqka02i2wd+/QD3qfAFqA4J6ZPywRcx3edt6EqHSRGu1J2acnuzfr0zs3c1x+
Fgha7GLPCHTYa1Ct43HEzpPKiajXV+lMzCB34mZqIik+Npgs77qb6JecPRHsBdGT
lPi/gvRb0uoWsCQwn5oizksLjqN5kB2pdpZ7CKDuuX3RRPkgYjNY9gKkSbIfLOTW
RMCYnyCefR3qdABRacijVX27LhsGmDBkYBEABNf80kHcGtCVrrxIfpUKTzOoC1Bi
3Zq8lfAu0SiKcC+H/nCQHUjbJvw1nJn3ig5Zi+snzccUTiv4PyAtbcmYN35o8aQ=
=L7sm
-END PGP SIGNATURE-

-- 
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] RHEL 7 Upgrade experience so far

2014-07-28 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/28/2014 12:56 PM, Rob Crittenden wrote:
 Erinn Looney-Triggs wrote:
 On 07/28/2014 12:20 PM, Ade Lee wrote:
 On Mon, 2014-07-28 at 12:14 -0700, Erinn Looney-Triggs wrote:
 On 07/28/2014 11:07 AM, Ade Lee wrote:
 
 No exceptions thrown in the journal.
 
 When investigating the cacert.p12 file that is bundled
 up for the replica's I see two caSigningCert's. One is
 the older one, before I renewed and one is the new,
 valid, post renewal one. Are these the certs that are
 used or are they requested from the primary much like the
 servercert?
 
 I think the problem might be that there are two 
 caSigningCerts, with presumably the same nickname.  We need
 to try and generate a p12 file without the old pre-renewal
 signing cert.
 
 Does the master certdb contain both certs with the same 
 nickname? If so, you could try to remove the old signing
 cert from the master certdb and then regenerate the pkcs12
 using PKCS12Export.
 
 Here is one way you could try to do this: 1. Export the 
 caSigning cert from the certdb using pk12util.  Check that
 only the latest cert/key has been exported.  Make sure to
 note down the exact cert nickname.  If so, then continue ..
 2. Shut down the CA. 3. IMPORTANT: Back up the certdb. 4.
 Delete the caSigning cert from the certdb using certutil.
 You may have to do this twice to remove both certs. 5.
 Re-import the saved caSigningCert using pk12util. 6.
 Restart the CA.
 
 
 However, when examining the /etc/pki/pki-tomcat/alias db 
 there is no casigningcert, hence I suppose the failure.
 So somewhere in there it is getting lost, I'll keep
 looking but throw me any ideas.
 
 By this, you are implying looking at the clone certdb,
 right? The cert should certainly still exist on the master.
 The cert not being in the clone certdb is because it fails
 to be imported from the PKCS12 file.
 
 
 -Erinn
 
 
 
 
 Ok to make sure we are on the same page and I am not chasing
 my own tail here, I am going to recap this as I understand
 the issue now.
 
 Essentially, we get a cacert.p12 file on the master IPA
 server that was generated using: PKCS12Export -d $ALIAS_PATH
 -p /root/keydb_pin -w /root/dm_password -o /root/cacert.p12
 
 This cacert.p12 file contains multiple copies of
 certificates, both expired and valid, for, well, multiple
 aliases in fact not just the caSigningCert.
 
 Nevertheless, because of these multiple copies of the 
 caSigningCert we are venturing a guess that this is munging
 up the ca clone on the replica (a fair guess I would say). So
 there is probably a bug in here somewhere, either on the
 exporting end, or on the importing end.
 
 So, I/we are trying to use the userspace tools to basically
 clean up the NSS db to only have the valid copy of this
 certificate.
 
 However, it appears to me that most of these tools are not 
 granular enough in their selection, the export everyhing with
 an alias of 'caSigningCert cert-pki-ca' or delete all
 instance of 'caSigningCert cert-pki-ca'. Kind of a
 sledgehammer for a penny nail type thing. Does this sound
 about right?
 
 If so, it looks like a more granular approach is warranted.
 I'll be looking into python-nss as python is what I know best
 to see if I can hack up something to whip the DB into proper
 shape.
 
 Anything I am missing here? Sound like a reasonable
 approach?
 
 That sounds exactly right.
 
 You could try deleting the cert using certutil -D (make sure
 to back up the certdb first) and see if it will delete one or
 both certificates. Or you could try renaming the cert nick
 using certutil and see if it renames just one.
 
 Ade
 -Erinn
 
 
 
 
 
 Ok, well I tried deleting it using certutil it deletes both, I
 tried using keytool to see if it would work any better, no dice
 there. I'll try the rename, but at this point I am not holding my
 breath on that, it seems all operation are a bit too coarse. It
 seems the assumption was being made that there would only be one
 of each nickname. Which frankly makes me wonder how any of this
 kept running after the renewal.
 
 For now I'll see what I can do on a copy of the db using python.
 
 It is a little strange that there are multiple 'caSigningCert 
 cert-pki-ca' as this is the CA itself. It should be good for 20
 years and isn't something that the current renewal code handles
 yet.
 
 You probably won't have much luck with python-nss. It can handle
 reading PKCS#12 files but I don't believe it can write them (access
 to key material).
 
 I'm not sure why certutil didn't do the trick. This should work, if
 you want to give it another try. I'm assuming that /root/cacert.p12
 has the latest exported certs, adjust as necessary:
 
 # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d
 /tmp/test # certutil -D -d /tmp/test -n 'nickname'
 
 certutil should delete the oldest cert first, it always has for
 me.
 
 rob
 

And finally there is a bug open from 11 years ago (!!) that defines
this problem: 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-27 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
 On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
 Well it hasn't been all the pretty trying to move from RHEL 6.5
 to RHEL 7.
 
 I have two servers providing my ipa instances ipa and ipa2.
 Given that I don't have a great deal of spare capacity the plan
 was to remove ipa2 from the replication agreement, modify DNS so
 that only IPA was available in SRV logs (IPA does not manage DNS
 at this point, was waiting for DNSSEC). As well, I would change
 my sudo-ldap config files to point to ipa and remove ipa2.
 
 Well that all worked well, installed RHEL 7 on the system and 
 began working through the steps in the upgrade guide.
 
 First major problem was running into this bug: 
 https://fedorahosted.org/freeipa/ticket/4375 ValueError: 
 nsDS5ReplicaId has 2 values, one expected.
 
 Went and patched the replication.py file to get around that
 issue, and we moved on.
 
 Next up is my current issue: Exception from Java Configuration 
 Servlet: Clone does not have all the required certificates.
 
 I suspect this is because I am running the CA as a subordinate
 to an AD CS instance, but I am unsure at this point.
 
 It has been a haul to get here, despite the short explanation. It
  seems that my primary ipa instance is working on only a hit or 
 miss basis for kerberos tickets which has made all this a bit of
 a pain. You can kinit as admin once it will fail unable to find
 KDC, try again another three times, it will work. I have even
 modified the krb5.conf file to point directly at the server, thus
 bypassing DNS SRV lookups, however, that hasn't worked.
 
 Point is, any help would be appreciated on the aforementioned 
 error.
 
 -Erinn
 
 
 To reply to myself here, I believe the problem may be that I had
 to renew the CA certificates and as such the certificates in 
 /root/cacert.p12 are no longer valid. It is this file that gets 
 bundled up with whatever else using ipa-replica-prepare, so I will 
 have to create a new one that has the valid certificates in it.
 
 One way or another though, if it isn't already documented, during a
 CA renewal this file should probably be updated with the correct 
 certificates.
 
 -Erinn
 
 -Erinn
 
 

Well thanks to this:
http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

I have gotten a little further down the road an created a new
cacert.p12 which looks to be complete.

However, installation still fails in the same place:

2014-07-27T06:33:04Z DEBUG Starting external process
2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp5QGhUx
2014-07-27T06:33:25Z DEBUG Process finished, return code=1
2014-07-27T06:33:25Z DEBUG stdout=Loading deployment configuration
from /tmp/tmp5QGhUx.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.


2014-07-27T06:33:25Z DEBUG stderr=pkispawn: WARNING  ...
unable to validate security domain user/password through REST
interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: Clone does not have all the required certificates

2014-07-27T06:33:25Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmp5QGhUx' returned non-zero exit
status 1
2014-07-27T06:33:25Z DEBUG   File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()

  File /usr/sbin/ipa-replica-install, line 667, in main
CA = cainstance.install_replica_ca(config)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)

  File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
364, in start_creation
method()

  File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')

2014-07-27T06:33:25Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed


So some of the required certificates must be missing still.

Unhelpfully, the ipa-server-install --uninstall process is not
cleaning up everything after this failure, it leaves the CA intact and
the next run through the installer believes the CA is working so it
does not configure it. As such, I guess a re-install is necessary or
some other steps to truly clean everything that I haven't found yet.

- -Erinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT1KQNAAoJEFg7BmJL2iPOeBIH/AyqKoybrpbt/k3E6HgE9YJB
5zEzSxnKCax52PYqLEg3h5CkBFmHsmIblTeM6pKhqCed6fheGTZeTpUYjwrsQfjC
h7PTyX8ymc0FVMhmCDSNEufOerV9UKXfV8yCta4dfo3ei4lv76mI4R7/rJLM3urL

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-27 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/27/2014 12:02 AM, Erinn Looney-Triggs wrote:
 On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
 On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
 Well it hasn't been all the pretty trying to move from RHEL
 6.5 to RHEL 7.
 
 I have two servers providing my ipa instances ipa and ipa2. 
 Given that I don't have a great deal of spare capacity the
 plan was to remove ipa2 from the replication agreement, modify
 DNS so that only IPA was available in SRV logs (IPA does not
 manage DNS at this point, was waiting for DNSSEC). As well, I
 would change my sudo-ldap config files to point to ipa and
 remove ipa2.
 
 Well that all worked well, installed RHEL 7 on the system and 
 began working through the steps in the upgrade guide.
 
 First major problem was running into this bug: 
 https://fedorahosted.org/freeipa/ticket/4375 ValueError: 
 nsDS5ReplicaId has 2 values, one expected.
 
 Went and patched the replication.py file to get around that 
 issue, and we moved on.
 
 Next up is my current issue: Exception from Java Configuration
  Servlet: Clone does not have all the required certificates.
 
 I suspect this is because I am running the CA as a subordinate 
 to an AD CS instance, but I am unsure at this point.
 
 It has been a haul to get here, despite the short explanation.
 It seems that my primary ipa instance is working on only a hit
 or miss basis for kerberos tickets which has made all this a
 bit of a pain. You can kinit as admin once it will fail unable
 to find KDC, try again another three times, it will work. I
 have even modified the krb5.conf file to point directly at the
 server, thus bypassing DNS SRV lookups, however, that hasn't
 worked.
 
 Point is, any help would be appreciated on the aforementioned 
 error.
 
 -Erinn
 
 
 To reply to myself here, I believe the problem may be that I had 
 to renew the CA certificates and as such the certificates in 
 /root/cacert.p12 are no longer valid. It is this file that gets 
 bundled up with whatever else using ipa-replica-prepare, so I
 will have to create a new one that has the valid certificates in
 it.
 
 One way or another though, if it isn't already documented, during
 a CA renewal this file should probably be updated with the
 correct certificates.
 
 -Erinn
 
 -Erinn
 
 
 
 Well thanks to this: 
 http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

  I have gotten a little further down the road an created a new 
 cacert.p12 which looks to be complete.
 
 However, installation still fails in the same place:
 
 2014-07-27T06:33:04Z DEBUG Starting external process 
 2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn -s CA -f
 /tmp/tmp5QGhUx 2014-07-27T06:33:25Z DEBUG Process finished, return
 code=1 2014-07-27T06:33:25Z DEBUG stdout=Loading deployment
 configuration from /tmp/tmp5QGhUx. Installing CA into
 /var/lib/pki/pki-tomcat. Storing deployment configuration into 
 /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. 
 Installation failed.
 
 
 2014-07-27T06:33:25Z DEBUG stderr=pkispawn: WARNING  ... 
 unable to validate security domain user/password through REST 
 interface. Interface not available pkispawn: ERROR...
 Exception from Java Configuration Servlet: Clone does not have all
 the required certificates
 
 2014-07-27T06:33:25Z CRITICAL failed to configure ca instance
 Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp5QGhUx' returned
 non-zero exit status 1 2014-07-27T06:33:25Z DEBUG   File 
 /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,

 
line 638, in run_script
 return_value = main_function()
 
 File /usr/sbin/ipa-replica-install, line 667, in main CA =
 cainstance.install_replica_ca(config)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 1678, in install_replica_ca
 subject_base=config.subject_base)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 478, in configure_instance
 self.start_creation(runtime=210)
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
 line 364, in start_creation method()
 
 File 
 /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,

 
line 604, in __spawn_instance
 raise RuntimeError('Configuration of CA failed')
 
 2014-07-27T06:33:25Z DEBUG The ipa-replica-install command failed, 
 exception: RuntimeError: Configuration of CA failed
 
 
 So some of the required certificates must be missing still.
 
 Unhelpfully, the ipa-server-install --uninstall process is not 
 cleaning up everything after this failure, it leaves the CA intact
 and the next run through the installer believes the CA is working
 so it does not configure it. As such, I guess a re-install is
 necessary or some other steps to truly clean everything that I
 haven't found yet.
 
 -Erinn

Continuing on, in order to remove the CA I am manually running:
pkidestroy -s CA -i pki-tomcat

And indeed there is a bug: 

Re: [Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-26 Thread Erinn Looney-Triggs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
 Well it hasn't been all the pretty trying to move from RHEL 6.5 to 
 RHEL 7.
 
 I have two servers providing my ipa instances ipa and ipa2. Given
 that I don't have a great deal of spare capacity the plan was to
 remove ipa2 from the replication agreement, modify DNS so that only
 IPA was available in SRV logs (IPA does not manage DNS at this
 point, was waiting for DNSSEC). As well, I would change my
 sudo-ldap config files to point to ipa and remove ipa2.
 
 Well that all worked well, installed RHEL 7 on the system and
 began working through the steps in the upgrade guide.
 
 First major problem was running into this bug: 
 https://fedorahosted.org/freeipa/ticket/4375 ValueError:
 nsDS5ReplicaId has 2 values, one expected.
 
 Went and patched the replication.py file to get around that issue,
 and we moved on.
 
 Next up is my current issue: Exception from Java Configuration 
 Servlet: Clone does not have all the required certificates.
 
 I suspect this is because I am running the CA as a subordinate to
 an AD CS instance, but I am unsure at this point.
 
 It has been a haul to get here, despite the short explanation. It 
 seems that my primary ipa instance is working on only a hit or
 miss basis for kerberos tickets which has made all this a bit of a
 pain. You can kinit as admin once it will fail unable to find KDC,
 try again another three times, it will work. I have even modified
 the krb5.conf file to point directly at the server, thus bypassing
 DNS SRV lookups, however, that hasn't worked.
 
 Point is, any help would be appreciated on the aforementioned
 error.
 
 -Erinn
 

To reply to myself here, I believe the problem may be that I had to
renew the CA certificates and as such the certificates in
/root/cacert.p12 are no longer valid. It is this file that gets
bundled up with whatever else using ipa-replica-prepare, so I will
have to create a new one that has the valid certificates in it.

One way or another though, if it isn't already documented, during a CA
renewal this file should probably be updated with the correct
certificates.

- -Erinn

- -Erinn


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT1GAjAAoJEFg7BmJL2iPO1BsIAIVSC2p7bR1mHSG9VVbJq6Uk
ostO/9Yh1ro8pgAWXbRnGJphDlfHhot+aauITsuFzIVSUk4rw7nTYA2jynROmjQJ
8mUEXap3i7GOnonHmZmUL3wrhiBVmkNWIizUZV3uIQ9/FKgUpTcflpeUqm/lUzxj
FeaQ3QOVeizdib2r+QkFLjF6nMYRZ7FTPIdXZiilVkG1TkEDK2V3LpZfnN5LBgNf
AzsnA0opUxNWvPeorFBD2RV20rVsTTf424S8nqseP1yALUIh4hc9xk6qivB+7DdF
MXI85uSGj30p1Wk3kIEWlUNU/mkmN0wQL2NcMTCJMrLrLbUQ9c+AvGNdmhBv8s4=
=74l8
-END PGP SIGNATURE-

-- 
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