subject:"\[Freeipa\-users\] RHEL 7 Upgrade experience so far"

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


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





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... 0CArunning10.0.5-3.el7
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 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


In /var/log/pki/pki-tomcat/catalina.out one can read:

Aug 27, 2014 4:44:22 PM org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory /var/lib/pki/pki

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


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

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

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,

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); matche

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

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 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, 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=allRevokedCerts-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=allRevokedCertsNotAfter-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=allRevokedExpiredCerts-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=allRevokedOrRevokedExpiredCaCerts-pki-tomcat, cn=ipaca, cn=ldbm
database, cn=plugins, cn=config:netscape.ldap.LDAPException: e

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

2014-08-04 Thread Rob Crittenden

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-

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

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 06:36 AM, Ade Lee wrote:
>> 
>> Well here is probably the pertinent part of the debug log,
>> though there is a lot more when the clone is setting up: 
>> [31/Jul/2014:13:23:53][TP-Processor3]: AuthMgrName:
>> certUserDBAuthMgr [31/Jul/2014:13:23:53][TP-Processor3]:
>> CMSServlet: retrieving SSL certificate 
>> [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: certUID=CN=CA 
>> Subsystem,O=example.COM [31/Jul/2014:13:23:53][TP-Processor3]:
>> CertUserDBAuth: started [31/Jul/2014:13:23:53][TP-Processor3]:
>> CertUserDBAuth: Retrieving client certificate 
>> [31/Jul/2014:13:23:53][TP-Processor3]: CertUserDBAuth: Got
>> client certificate [31/Jul/2014:13:23:53][TP-Processor3]: In
>> LdapBoundConnFactory::getConn() 
>> [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected:
>> true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is
>> connected true [31/Jul/2014:13:23:53][TP-Processor3]: getConn:
>> mNumConns now 2 [31/Jul/2014:13:23:53][TP-Processor3]:
>> returnConn: mNumConns now 3 
>> [31/Jul/2014:13:23:53][TP-Processor3]: Authentication: client 
>> certificate found [31/Jul/2014:13:23:53][TP-Processor3]: In
>> LdapBoundConnFactory::getConn() 
>> [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected:
>> true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is
>> connected true [31/Jul/2014:13:23:53][TP-Processor3]: getConn:
>> mNumConns now 2 [31/Jul/2014:13:23:53][TP-Processor3]:
>> returnConn: mNumConns now 3 
>> [31/Jul/2014:13:23:53][TP-Processor3]: SignedAuditEventFactory: 
>> create() 
>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=CA
>>
>> 
Subsystem,O=example.COM] authentication failure
>> 
>> [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: curDate=Thu
>> Jul 31 13:23:53 GMT 2014 id=caUpdateDomainXML time=11
>> 
> Lets focus on the above error.  This says that the master was
> unable to map the certificate that was presented to a user under
> ou=users, o=ipaca.
> 
> I would look at the database (for the master) and see what users
> are defined.  Check which users have the subsystem certificate
> defined as their certificate, and check the description attribute.
> That attribute should contain a string that includes the
> certificate serial number, subject DN and issuer, delimited by
> semicolons.  Check that string and confirm that the certificate for
> that user matches the description delimiter, and that the subsystem
> certificate is the same as the subsystem certificate in the replica
> certdb.
> 
> It would also be useful to see what the DS access logs say at the
> time this authentication failure occurs.
> 
> Ade
>> 
>> -Erinn
>> 
> 
> 

Well unfortunately, after restarting the IPA services on the RHEL 6.5
system I no longer receive this error at all. Using ipa-ca-install
fails in the steps before this error was received.

ipa : DEBUGStarting external process
ipa : DEBUGargs=/usr/sbin/pkispawn -s CA -f /tmp/tmpvByIvk
ipa : DEBUGProcess finished, return code=1
ipa : DEBUGstdout=Loading deployment configuration from
/tmp/tmpvByIvk.
ERROR:  Unable to access directory server: Server is unwilling to perform

ipa : DEBUGstderr=
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpvByIvk' 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

And the access log from /var/log/dirsrv/slapd-PKI-CA/access on the
RHEL 6.5 master only shows this:

[04/Aug/2014:14:16:25 +] conn=211 fd=74 slot=74 connection from
2001:4870:800e:301:862b:2bff:fe67:704d to
2001:4870:800e:301:f24d:a2ff:fe09:ae0
[04/Aug/2014:14:16:25 +] conn=211 op=0 EXT
oid="1.3.6.1.4.1.1466.20037" name="startTLS"
[04/Aug/2014:14:16:25 +] conn=211 op=0 RESULT err=0 tag=120
nentries=0 etime=0
[04/Aug/2014:14:16:25 +] conn=211

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

2014-08-04 Thread Ade Lee

On Thu, 2014-07-31 at 06:27 -0700, Erinn Looney-Triggs wrote:
> 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 ''
> >>> 
> >>> 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= >> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE10
> >>
> >> 
> [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 po

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-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-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 ''
>>> 
>>> 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=> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE10
>>
>> 
[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. [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
>> updateSecurityDomain: now trying agent port with client auth 
>> [30/Jul/20

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 ''
>>> 
>>> 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=> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE10
>>
>> 
[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. [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
>> updateSecurityDomain: now trying agent port with client auth 
>> [30/Jul/20

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 ''
>>> 
>>> 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=> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE10
>>
>> 
[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. [30/Jul/2014:00:27:48][http-bio-8443-exec-3]:
>> updateSecurityDomain: now trying agent port with client auth 
>> [30/Jul/20

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 ''
> > 
> > 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= standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE10
> [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.
> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateSecurityDomain:
> now trying agent port with client auth
> [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][h

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 ''
> 
> 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=IPAipa.example.com44344344344380FALSEpki-cadTRUE10
[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.
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateSecurityDomain:
now trying agent port with client auth
[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]: updateDomainXML()
nickname=subsystemCert cert-pki-ca
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML: status=1

And from pki-tomcat/catalina.out:
00:26:53,450  INFO
(org.jboss.resteasy.plugins.server.servlet.Servl

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

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

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 -

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

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

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

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

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

2014-07-28 Thread Ade Lee

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

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

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

2014-07-28 Thread Rob Crittenden

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 th

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

2014-07-28 Thread Rob Crittenden

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 d

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

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

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

[Freeipa-users] RHEL 7 Upgrade experience so far

2014-07-26 Thread Erinn Looney-Triggs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJT1EbkAAoJEFg7BmJL2iPOscwH/1ghb+CrY0raAanuTGbITL7R
eTuJKEPbHB3bfSo0Qt3gBKsOQiCo3vsX26LqmKVOPudNUlI4G49kqqPfrUjxoBuN
XrCRWcInTKA0pfzPuIKzueSinYR+d1x48J2tJkMovdYJwn8VaYoxadYaBFinj8/X
UFTBr7QWH0HO+/gIhyvfA5/V/0OHqNa+EbVuu61FlfjxYNSYLKPU2UDhXeV0T9DJ
R9MgeEPh7XUdhhiAIV9ccyqchS1kzWKALEetNJNDdZafuAhQOY/5LNyPYiZ8CVu4
yX3875zp4Rz8EDud9vVTfMTWGONVJ5LsEnr5NtBAyfDW5R8SM5HQUVI46vlsaJw=
=CJP5
-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

42 matches

Mail list logo