Re: [Freeipa-users] CA Replication Installation Failing
Actually, it looks like it fails even earlier than getting the domain info - that is, when the replica contacts the master and tries to get its cert chain. I think that you have modified the logs slightly? There are a couple of things that don't make sense. See annotated log below -- On Wed, 2015-02-04 at 09:19 -0500, Ade Lee wrote: From the snippet of log below, it looks like the replica CA is trying to contact the master CA to obtain the security domain information and is failing to get a valid response. The message about spaces and parsing is basically the replica saying that it cannot understand the response -- or lack of one from the master CA. As this is an old version of IPA and Dogtag, it is trying to contact the master CA on port 9443. Things to look into: 1) Is the CA on the master up? Is port 9443 open on the master (firewalls on master or replica)? You could test this by using a browser/curl on the replica to go to https://master_host:9443/ca/admin/ca/getDomainXML 2) Is selinux preventing the access? You might want to set it in permissive mode on either master or replica. 3) Do you see activity in the master's debug log? This looks to me like a different error from what was described before. Its failing much earlier now. Ade On Fri, 2015-01-30 at 05:48 +, Les Stott wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Wednesday, 10 December 2014 6:22 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: Ade Lee [mailto:a...@redhat.com] Sent: Wednesday, 10 December 2014 5:05 AM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On Tue, 2014-12-09 at 07:48 +, Les Stott wrote: __ From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. I think that this is a safe bet to be the problem. The error in the log snippet you posted says: errorStringThe pkcs12 file is not correct./errorString This indicates that the clone CA was unable to decode the pkcs12 file in the replica. Perhaps the certs changed -- or the DM password changed? Ade I regenerated the replica file and retired the CA replica setup, but it failed at the same point with the same error. I am thinking that the next step is to uninstall the ipa replica to cleanup, remove all traces and re-add as a replica on serverb. I wonder if the cert that its having an issue with is the one on serverB under /etc/ipa/ca.crt which is from Dec 2013. I will try that in a couple of days as I have to schedule this work in as its in production. Regards, Les May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B. Do not forget to clean replication agreements on master. But that would be work around, would not solve this specific problem, it will kill it. I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb. I'll report back what i find after regenerating the replica file and re-trying to setup CA replication. After a bit of a hiatus I have revisited this issue and I still have it. Just
Re: [Freeipa-users] CA Replication Installation Failing
From the snippet of log below, it looks like the replica CA is trying to contact the master CA to obtain the security domain information and is failing to get a valid response. The message about spaces and parsing is basically the replica saying that it cannot understand the response -- or lack of one from the master CA. As this is an old version of IPA and Dogtag, it is trying to contact the master CA on port 9443. Things to look into: 1) Is the CA on the master up? Is port 9443 open on the master (firewalls on master or replica)? You could test this by using a browser/curl on the replica to go to https://master_host:9443/ca/admin/ca/getDomainXML 2) Is selinux preventing the access? You might want to set it in permissive mode on either master or replica. 3) Do you see activity in the master's debug log? This looks to me like a different error from what was described before. Its failing much earlier now. Ade On Fri, 2015-01-30 at 05:48 +, Les Stott wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Wednesday, 10 December 2014 6:22 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: Ade Lee [mailto:a...@redhat.com] Sent: Wednesday, 10 December 2014 5:05 AM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On Tue, 2014-12-09 at 07:48 +, Les Stott wrote: __ From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. I think that this is a safe bet to be the problem. The error in the log snippet you posted says: errorStringThe pkcs12 file is not correct./errorString This indicates that the clone CA was unable to decode the pkcs12 file in the replica. Perhaps the certs changed -- or the DM password changed? Ade I regenerated the replica file and retired the CA replica setup, but it failed at the same point with the same error. I am thinking that the next step is to uninstall the ipa replica to cleanup, remove all traces and re-add as a replica on serverb. I wonder if the cert that its having an issue with is the one on serverB under /etc/ipa/ca.crt which is from Dec 2013. I will try that in a couple of days as I have to schedule this work in as its in production. Regards, Les May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B. Do not forget to clean replication agreements on master. But that would be work around, would not solve this specific problem, it will kill it. I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb. I'll report back what i find after regenerating the replica file and re-trying to setup CA replication. After a bit of a hiatus I have revisited this issue and I still have it. Just to re-iterate the problem... Trying to setup a ca replica on an already installed replica fails in rhel 6.6, ipa-3.0.0.42, pki 9.0.3-38. /usr/sbin/ipa-ca-install -p xx -w xx -U /var/lib/ipa/replica-info-myhost.mydomain.com.gpg It fails showing CRITICAL failed to configure ca instance Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring
Re: [Freeipa-users] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached
On Tue, 2014-12-09 at 23:52 +0100, chymian wrote: Am Dienstag, 9. Dezember 2014, 09:49:04 schrieb Ade Lee: On Tue, 2014-12-09 at 13:54 +0100, chymian wrote: hey people, after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107) but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie) I can reach work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca. $ systemctl status pki-tomcatd@pki-tomcat.service ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled) Active: failed (Result: resources) Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd@pki-tomcat.service failed to run 'start-pre' task: No such file or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd@pki-tomcat.service entered failed state. Is dogtag actually running? ps -ef |grep java it shows: pkiuser 676 1 0 13:25 ? 00:00:26 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -DRESTEASY_LIB=/usr/share/java/ -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/var/lib/pki/pki-tomcat/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp org.apache.catalina.startup.Bootstrap start is it ment to be, that the dogtag-pki package it’s self is not installed, just the dogtag-pki-server-theme is and a couple pki-packages… pki-base, pki-ca, pki-server, pki-tools? Ok, so as far as I can see, the dogtag CA is in fact up and operational. The systemctl error messages are probably a result of the systemd unit scripts not yet being used. We clearly see that the IPA RA and Jar signing certs are issued with no problems. I do notice a few attempts to reach the agent pages which result in failed authentication. My guess is that you are trying to access these pages using the browser and are not providing the agent cert. As you have the dogtag-pki-server-theme package installed, you should be able to reach the UI. But .. -- If you try to access the dogtag UI pages through port 80 and 443, then you are going through the apache instance for IPA. This instance talks to Dogtag on the back-end using AJP, and has a proxy configuration file that only permits certain URL paths to go through. -- If you want to access the Dogtag UI pages, you need to access https://host:8443/... or http://host:8080/... To access the agent pages, you need to import the IPA RA agent certificate into your browser (and trust the CA cert). That cert/key is in the IPA HTTP certdb. You will need to extract it from there as a p12 file and import it into your browser. Ade You could try restarting it - systemctl restart pki-tomcatd@pki-tomcat.service fails with same log-msg. The logs should be found in the journal -- journalctl -u pki-tomcatd@pki-tomcat.service same as above. Other debug logs should be found under /var/log/pki/pki-tomcat/. Please provide a tar of that directory. attached I am curious what the unit file looks like: On Fedora, its at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service lrwxrwxrwx 1 pkiuser pkiuser 40 Dez 8 20:22 pki-tomcatd@pki-tomcat.service - /lib/systemd/system/pki-tomcatd@.service root@ipa /etc/systemd/system/pki-tomcatd.target.wants $ cat pki-tomcatd@pki-tomcat.service [Unit] Description=PKI Tomcat Server %i After=pki-tomcatd.target network.target PartOf=pki-tomcatd.target [Service] Type=simple EnvironmentFile=/etc/tomcat/tomcat.conf Environment=NAME=%i EnvironmentFile=-/etc/default/%i ExecStartPre=/usr/bin/pkidaemon start %i ExecStart=/usr/libexec/tomcat/server start ExecStop=/usr/libexec/tomcat/server stop SuccessExitStatus=143 User=pkiuser Group=pkiuser [Install] WantedBy=multi-user.target which points to an EnvironmentFile /etc/tomcat/tomcat.conf. Does that file exist? there is not even an dir. /etc/tomcat/, or rather a tomcat.conf in it. this is what was installed: ii libtomcat7-java 7.0.56-1 ii libtomcatjss-java 7.1.1-2 ii tomcat7-common 7.0.56-1 ii tomcat7
Re: [Freeipa-users] Unit pki-tomcatd@pki-tomcat.service entered failed state @ vanilla install on jessie – with log attached
On Tue, 2014-12-09 at 13:54 +0100, chymian wrote: hey people, after a successful install of ipa 4.0.5-2 on jessie, the named services started flawless during setup. see attached log, Installation summary (line 3107) but after reboot, it refuses to start. (did this install a couple times, on vanilla jessie) I can reach work with Dogtag https://ipa.eb8.lan:8443/ca, but not the admin-services on https://ipa.eb8.lan/ca/ee/ca and https://ipa.eb8.lan/ca/agent/ca. $ systemctl status pki-tomcatd@pki-tomcat.service ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled) Active: failed (Result: resources) Dez 08 20:40:13 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... Dez 08 20:40:13 ipa systemd[1]: Failed to load environment files: No such file or directory Dez 08 20:40:13 ipa systemd[1]: pki-tomcatd@pki-tomcat.service failed to run 'start-pre' task: No such file or directory Dez 08 20:40:13 ipa systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. Dez 08 20:40:13 ipa systemd[1]: Unit pki-tomcatd@pki-tomcat.service entered failed state. Is dogtag actually running? ps -ef |grep java You could try restarting it - systemctl restart pki-tomcatd@pki-tomcat.service The logs should be found in the journal -- journalctl -u pki-tomcatd@pki-tomcat.service Other debug logs should be found under /var/log/pki/pki-tomcat/. Please provide a tar of that directory. I am curious what the unit file looks like: On Fedora, its at /etc/systemd/system/pki-tomcatd.target.wants/pki-tomcatd@pki-tomcat.service which points to an EnvironmentFile /etc/tomcat/tomcat.conf. Does that file exist? Ade a second service fails to start: $ systemctl status dirsrv-snmp.service ● dirsrv-snmp.service - 389 Directory Server SNMP Subagent. Loaded: loaded (/lib/systemd/system/dirsrv-snmp.service; enabled) Active: failed (Result: exit-code) since Di 2014-12-09 13:25:04 CET; 5min ago Process: 156 ExecStart=/usr/sbin/ldap-agent /etc/dirsrv/config/ldap-agent.conf (code=exited, status=1/FAILURE) Dez 09 13:25:04 ipa systemd[1]: Starting 389 Directory Server SNMP Subagent Dez 09 13:25:04 ipa ldap-agent[156]: ldap-agent: No server instances defined in config file Dez 09 13:25:04 ipa systemd[1]: dirsrv-snmp.service: control process exited, code=exited status=1 Dez 09 13:25:04 ipa systemd[1]: Failed to start 389 Directory Server SNMP Subagent.. Dez 09 13:25:04 ipa systemd[1]: Unit dirsrv-snmp.service entered failed state. except these, I was able to subscribe a jessie-client with autodiscovery right after I did configure the ipa-server, before first reboot. any help appreciated, since I do not have much experience with IPA – yet. guenter -- 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] CA Replication Installation Failing
On Tue, 2014-12-09 at 07:48 +, Les Stott wrote: __ From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. I think that this is a safe bet to be the problem. The error in the log snippet you posted says: errorStringThe pkcs12 file is not correct./errorString This indicates that the clone CA was unable to decode the pkcs12 file in the replica. Perhaps the certs changed -- or the DM password changed? Ade May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B. Do not forget to clean replication agreements on master. But that would be work around, would not solve this specific problem, it will kill it. I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb. I'll report back what i find after regenerating the replica file and re-trying to setup CA replication. Thanks, Les Thanks in advance, Les From:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Tuesday, 2 December 2014 6:17 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] CA Replication Installation Failing Hi All, I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38. Servera is the master Serverb is the replica Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica. I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why. Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue. Here is what I get….(for the sake of brevity, I am excluding the lines for connection check which were all OK) = /usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg Directory Manager (existing master) password: Get credentials to log in to remote master ad...@mydomain.com password: Execute check on remote master Connection check OK Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On Wed, 2014-09-24 at 16:24 -0400, Rob Crittenden wrote: Dmitri Pal wrote: On 09/24/2014 03:29 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 09/24/2014 02:07 PM, swartz wrote: On 9/24/2014 9:05 AM, Ade Lee wrote: Forwarding to a couple of colleagues of mine who will be taking point on this. From what I can see, the CS.cfg is truncated. Fortunately, I believe it is reparable. Ade I've been in contact with Endi and Ade. It was a truncated config file as per msg above. Endi had emailed me a restored config. I can happily say that my IPA instance is back in operation. Thank you all. For anyone else reading this: For me this config truncation happened after a 'yum update'. Perhaps shutting down the IPA stack before doing package updates might be more advisable. Is there any chance to detect which package caused this truncation? It was almost certainly related to IPA, if not ipa-upgradeconfig directly. For any number of reasons it may write directly to CS.cfg without stopping the service first. It may also call the dogtag-provided pki-setup-proxy which also doesn't stop the service before touching CS.cfg. The upgrader will then determine if any changes were made and restart the service. rob So is it a race condition? Something does not sound right. What I don't understand is: if dogtag always writes CS.cfg on exit, why does this work the majority of the time? Dogtag does not write CS.cfg on exit (like 389). Rather, if there are changes to CS.cfg, they will be committed and the file will be changed and the in-memory version of CS.cfg will be written at that time. I think what we're seeing is two different things modifying the CS,cfg at the same time (or at least within the time frame of whatever file buffering is going on). In other cases where I've seen this, I see CS.cfg end up the size of n * file buffer. Shutting down CA before changing CS.cfg is a way of preventing access by more than one source at the same time. But anyway, it sounds like we need to shut down dogtag every time we touch CS.cfg which isn't a big deal but it will change the way we do some things. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On Wed, 2014-09-24 at 16:33 -0400, Ade Lee wrote: On Wed, 2014-09-24 at 16:24 -0400, Rob Crittenden wrote: Dmitri Pal wrote: On 09/24/2014 03:29 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 09/24/2014 02:07 PM, swartz wrote: On 9/24/2014 9:05 AM, Ade Lee wrote: Forwarding to a couple of colleagues of mine who will be taking point on this. From what I can see, the CS.cfg is truncated. Fortunately, I believe it is reparable. Ade I've been in contact with Endi and Ade. It was a truncated config file as per msg above. Endi had emailed me a restored config. I can happily say that my IPA instance is back in operation. Thank you all. For anyone else reading this: For me this config truncation happened after a 'yum update'. Perhaps shutting down the IPA stack before doing package updates might be more advisable. Is there any chance to detect which package caused this truncation? It was almost certainly related to IPA, if not ipa-upgradeconfig directly. For any number of reasons it may write directly to CS.cfg without stopping the service first. It may also call the dogtag-provided pki-setup-proxy which also doesn't stop the service before touching CS.cfg. The upgrader will then determine if any changes were made and restart the service. rob So is it a race condition? Something does not sound right. What I don't understand is: if dogtag always writes CS.cfg on exit, why does this work the majority of the time? Dogtag does not write CS.cfg on exit (like 389). Rather, if there are changes to CS.cfg, they will be committed and the file will be changed and the in-memory version of CS.cfg will be written at that time. I think what we're seeing is two different things modifying the CS,cfg at the same time (or at least within the time frame of whatever file buffering is going on). In other cases where I've seen this, I see CS.cfg end up the size of n * file buffer. Shutting down CA before changing CS.cfg is a way of preventing access by more than one source at the same time. In the long term of course, we need to provide an interface to dogtag to allow these types of changes by the dogtag server. But anyway, it sounds like we need to shut down dogtag every time we touch CS.cfg which isn't a big deal but it will change the way we do some things. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On Mon, 2014-09-22 at 10:50 +0200, Martin Kosek wrote:
On 09/20/2014 01:02 AM, swartz wrote:
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update' and
reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in /usr/share/pki/scripts/functions
(which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search parameter.
Hence invalid call to grep and subsequent error msg I'm seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file} |
cut
-b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use
in grep.
Why there is no such line in config file where one is expected is unknown
to me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do I
resolve it?
There have been no updates recently on rhel 6 to the pki packages.
There has, however, been an update to tomcat - which broke dogtag
startups.
What version of tomcat6 is on your system?
Thank you.
Also please see another PKI crash on EL6 reported on freeipa-users:
https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html
This is not the first time this issue was reported, but we got no response
from
PKI team, even though I CCed several members (maybe that was actually the root
case).
The PKI installation errors are piling up (7.1 too), I would like to resolve
that very soon so that we are not seen as too unstable software.
The issues on 7.1 are tomcat related too. Builds were completed last
week to address these.
Thanks for help,
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] PKI-CA fails to start (broken config after update?)
On Mon, 2014-09-22 at 10:43 -0400, Ade Lee wrote:
On Mon, 2014-09-22 at 10:50 +0200, Martin Kosek wrote:
On 09/20/2014 01:02 AM, swartz wrote:
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update'
and reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in
/usr/share/pki/scripts/functions
(which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search parameter.
Hence invalid call to grep and subsequent error msg I'm seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port=' ${pki_instance_configuration_file}
| cut
-b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for use
in grep.
Why there is no such line in config file where one is expected is unknown
to me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do I
resolve it?
Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ?
There have been no updates recently on rhel 6 to the pki packages.
There has, however, been an update to tomcat - which broke dogtag
startups.
What version of tomcat6 is on your system?
Thank you.
Also please see another PKI crash on EL6 reported on freeipa-users:
https://www.redhat.com/archives/freeipa-users/2014-September/msg00331.html
This is not the first time this issue was reported, but we got no response
from
PKI team, even though I CCed several members (maybe that was actually the
root
case).
The PKI installation errors are piling up (7.1 too), I would like to resolve
that very soon so that we are not seen as too unstable software.
The issues on 7.1 are tomcat related too. Builds were completed last
week to address these.
Thanks for help,
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] PKI-CA fails to start (broken config after update?)
On Mon, 2014-09-22 at 13:39 -0600, swartz wrote: On 9/22/2014 9:14 AM, Ade Lee wrote: Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? ls -l /etc/pki-ca/CS.cfg -rw-r-. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg In very rare cases, I've seen cases where the CS.cfg becomes truncated during an update. Unfortunately, we have not been able to reproduce the event. In later versions of dogtag, we make sure to save the CS.cfg just in case. Your instance sounds like a truncated CS.cfg instance, but the size is a lot larger than cases I've seen before, so I don't want to jump to that conclusion yet. If you scroll to the end of the CS.cfg, does it look like it has been truncated? If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* Also, do you have a replica CA? Ade I know that I did NOT change the configs myself. But something certainly did during 'yum update'. There are no .rpmsave or .rpmnew files that would typically be created if configs are properly marked in RPM spec file. There are two other files that exist though: -rw-r-. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 -rw-rw. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 However, they are not usable either in place of current CS.cfg. The above files are templates only. They are modified during instance configuration. There have been no updates recently on rhel 6 to the pki packages. There has, however, been an update to tomcat - which broke dogtag startups. What version of tomcat6 is on your system? rpm -qa tomcat6 tomcat6-6.0.24-78.el6_5.noarch This tomcat version should still be a working one. The tomcat6 then broke things has not made it out yet, having been discovered in QE testing. -- 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
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
On Tue, 2014-08-05 at 09:08 +0200, Martin Kosek wrote: On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote: On 08/04/2014 01:51 PM, Ade Lee wrote: OK - I suspect you may be running into an issue with serial number generation. Each time we install a clone, we end up allocating a new range of serial numbers for the clone. The idea is to keep separate ranges for each CA replica so that no two replicas can issue certs with the same serial number. The problem is that you've probably retried the install a whole bunch of times and now perhaps the serial number range is too high. This is just a guess - but you can see what ranges have been assigned by looking in : 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for the master (look for the attributes dbs.* 3. The value of the attribute nextRange on : ou=certificateRepository, o=ipaca and ou=Requests, o=ipaca Please send me that info, and I'll explain how to clean that up. Ade On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: On 08/04/2014 11:48 AM, Ade Lee wrote: OK - so its not really even getting started on the install. My guess is there is some cruft from previous installs/uninstalls that was not cleaned up. Is there anything in the directory server logs on the RHEL7 machine? What operation is being attempted that the server is refusing to perform? Ade Ok I moved on past this issue. Problem was minssf was set to 56 on the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. Thanks for having me check the dir on the RHEL 7 instance I was assuming it was hitting against the RHEL 6.5 instance and was finding basically nothing there. This run looks like it pulled a lot more information in but it still errored out. ipa : DEBUGstderr=pkispawn: WARNING ... unable to validate security domain user/password through REST interface. Interface not available pkispawn: ERROR... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit status 1 From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host ipa2.abaqis.com port 389, secure connection, false, authentication type 1 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new total available connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: param=preop.internaldb.post_ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlv.ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote:
Ok, well I tried deleting it using certutil it deletes both, I
tried using keytool to see if it would work any better, no dice
there. I'll try the rename, but at this point I am not holding my
breath on that, it seems all operation are a bit too coarse. It
seems the assumption was being made that there would only be one
of each nickname. Which frankly makes me wonder how any of this
kept running after the renewal.
For now I'll see what I can do on a copy of the db using python.
It is a little strange that there are multiple 'caSigningCert
cert-pki-ca' as this is the CA itself. It should be good for 20
years and isn't something that the current renewal code handles
yet.
You probably won't have much luck with python-nss. It can handle
reading PKCS#12 files but I don't believe it can write them (access
to key material).
I'm not sure why certutil didn't do the trick. This should work, if
you want to give it another try. I'm assuming that /root/cacert.p12
has the latest exported certs, adjust as necessary:
# certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d
/tmp/test # certutil -D -d /tmp/test -n 'nickname'
certutil should delete the oldest cert first, it always has for
me.
rob
Ok folks I managed to clean up the certificate DB so there is only one
valid certificate for each service. Installation continued pass that
step and then failed shortly thereafter on configuring the ca. So here
is my new error:
pkispawn: ERROR... Exception from Java Configuration
Servlet: Error while updating security domain: java.io.IOException: 2
pkispawn: DEBUG... Error Type: HTTPError
pkispawn: DEBUG... Error Message: 500 Server Error:
Internal Server Error
pkispawn: DEBUG... File /usr/sbin/pkispawn, line 374,
in main
rv = instance.spawn()
File
/usr/lib/python2.7/site-packages/pki/deployment/configuration.py,
line 128, in spawn
json.dumps(data, cls=pki.encoder.CustomTypeEncoder))
File /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py,
line 2998, in configure_pki_data
response = client.configure(data)
File /usr/lib/python2.7/site-packages/pki/system.py, line 80, in
configure
r = self.connection.post('/rest/installer/configure', data, headers)
File /usr/lib/python2.7/site-packages/pki/client.py, line 64, in post
r.raise_for_status()
File /usr/lib/python2.7/site-packages/requests/models.py, line
638, in raise_for_status
raise http_error
2014-07-30T00:27:48Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned non-zero
exit status 1
2014-07-30T00:27:48Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 667, in main
CA = cainstance.install_replica_ca(config)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py, line
364, in start_creation
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
2014-07-30T00:27:48Z DEBUG The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
And from the pki-tomcat/ca debug log:
isSDHostDomainMaster(): Getting domain.xml from CA...
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML: status=0
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML:
domainInfo=?xml version=1.0 encoding=UTF-8
standalone=no?DomainInfoNameIPA/NameCAListCAHostipa.example.com/HostSecurePort443/SecurePortSecureAgentPort443/SecureAgentPortSecureAdminPort443/SecureAdminPortSecureEEClientAuthPort443/SecureEEClientAuthPortUnSecurePort80/UnSecurePortCloneFALSE/CloneSubsystemNamepki-cad/SubsystemNameDomainManagerTRUE/DomainManager/CASubsystemCount1/SubsystemCount/CAListOCSPListSubsystemCount0/SubsystemCount/OCSPListKRAListSubsystemCount0/SubsystemCount/KRAListRAListSubsystemCount0/SubsystemCount/RAListTKSListSubsystemCount0/SubsystemCount/TKSListTPSListSubsystemCount0/SubsystemCount/TPSList/DomainInfo
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase
updateDomainXML start hostname=ipa.example.com port=443
[30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateSecurityDomain:
failed to update security domain using admin port
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
On Mon, 2014-07-28 at 08:26 -0700, Erinn Looney-Triggs wrote:
On 07/28/2014 08:04 AM, Ade Lee wrote:
On Mon, 2014-07-28 at 07:41 -0700, Erinn Looney-Triggs wrote:
On 07/28/2014 07:17 AM, Rob Crittenden wrote:
Rob Crittenden wrote:
Erinn Looney-Triggs wrote:
On 07/27/2014 12:02 AM, Erinn Looney-Triggs wrote:
On 07/26/2014 07:12 PM, Erinn Looney-Triggs wrote:
On 07/26/2014 05:25 PM, Erinn Looney-Triggs wrote:
Well it hasn't been all the pretty trying to move
from RHEL 6.5 to RHEL 7.
I have two servers providing my ipa instances ipa
and ipa2. Given that I don't have a great deal of
spare capacity the plan was to remove ipa2 from the
replication agreement, modify DNS so that only IPA
was available in SRV logs (IPA does not manage DNS at
this point, was waiting for DNSSEC). As well, I would
change my sudo-ldap config files to point to ipa and
remove ipa2.
Well that all worked well, installed RHEL 7 on the
system and began working through the steps in the
upgrade guide.
First major problem was running into this bug:
https://fedorahosted.org/freeipa/ticket/4375
ValueError: nsDS5ReplicaId has 2 values, one
expected.
Went and patched the replication.py file to get
around that issue, and we moved on.
Next up is my current issue: Exception from Java
Configuration Servlet: Clone does not have all the
required certificates.
I suspect this is because I am running the CA as a
subordinate to an AD CS instance, but I am unsure at
this point.
It has been a haul to get here, despite the short
explanation. It seems that my primary ipa instance
is working on only a hit or miss basis for kerberos
tickets which has made all this a bit of a pain. You
can kinit as admin once it will fail unable to find
KDC, try again another three times, it will work. I
have even modified the krb5.conf file to point
directly at the server, thus bypassing DNS SRV
lookups, however, that hasn't worked.
Point is, any help would be appreciated on the
aforementioned error.
-Erinn
To reply to myself here, I believe the problem may be
that I had to renew the CA certificates and as such
the certificates in /root/cacert.p12 are no longer
valid. It is this file that gets bundled up with
whatever else using ipa-replica-prepare, so I will have
to create a new one that has the valid certificates in
it.
One way or another though, if it isn't already
documented, during a CA renewal this file should
probably be updated with the correct certificates.
-Erinn
-Erinn
Well thanks to this:
http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password
I have gotten a little further down the road an created a new
cacert.p12 which looks to be complete.
However, installation still fails in the same place:
2014-07-27T06:33:04Z DEBUG Starting external process
2014-07-27T06:33:04Z DEBUG args=/usr/sbin/pkispawn -s CA
-f /tmp/tmp5QGhUx 2014-07-27T06:33:25Z DEBUG Process
finished, return code=1 2014-07-27T06:33:25Z DEBUG
stdout=Loading deployment configuration from
/tmp/tmp5QGhUx. Installing CA into
/var/lib/pki/pki-tomcat. Storing deployment configuration
into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2014-07-27T06:33:25Z DEBUG stderr=pkispawn: WARNING
... unable to validate security domain user/password
through REST interface. Interface not available pkispawn
: ERROR... Exception from Java Configuration
Servlet: Clone does not have all the required
certificates
2014-07-27T06:33:25Z CRITICAL failed to configure ca
instance Command '/usr/sbin/pkispawn -s CA -f
/tmp/tmp5QGhUx' returned non-zero exit status 1
2014-07-27T06:33:25Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 667, in main
CA = cainstance.install_replica_ca(config)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 1678, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 478, in configure_instance
self.start_creation(runtime=210)
File
/usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py,
line 604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
2014-07-27T06:33:25Z DEBUG The ipa-replica-install
command failed, exception: RuntimeError: Configuration of
CA failed
So some of the required certificates must be missing
still.
Unhelpfully, the ipa-server-install --uninstall process
is not cleaning up everything
Re: [Freeipa-users] RHEL 7 Upgrade experience so far
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] Failure configuring certificate server instance
On Wed, 2014-05-28 at 10:37 +0100, Scott Ryan wrote: I am trying to get freeIPA up and running on a minimal CentOS6.5 installation. i have forward and reverse DNS setup on an external DNS server - no SELinux no iptables (for troubleshooting) but keep running into the following problem during installation : [3/21]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa1.int.immi.gov.au -cs_port 9445 -client_certdb_dir /tmp/tmp-RsFkUW -client_certdb_pwd -preop_pin miTD9vj5e6KwfqQNy2ig -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=INT.IMMI.GOV.AU -ldap_host ipa1.int.immi.gov.au -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INT.IMMI.GOV.AU -ca_subsystem_cert_subject_name CN=CA Subsystem,O=INT.IMMI.GOV.AU -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=INT.IMMI.GOV.AU -ca_server_cert_subject_name CN=ipa1.int.immi.gov.au,O=INT.IMMI.GOV.AU -ca_audit_signing_cert_subject_name CN=CA Audit,O=INT.IMMI.GOV.AU -ca_sign_cert_subject_name CN=Certificate Authority,O=INT.IMMI.GOV.AU -external false -clone false' returned non-zero exit status 255 Configuration of CA failed The installation log shows this : 2014-05-28T09:19:47Z DEBUG importing plugin module '/usr/lib/python2.6/site-packages/ipalib/plugins/delegation.py' ...skipping... at java.net.URLClassLoader$1.run(URLClassLoader.java:358) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at java.lang.ClassLoader.loadClass(ClassLoader.java:412) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:215) at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) at sun.security.jca.ProviderList.loadAll(ProviderList.java:281) at sun.security.jca.ProviderList.removeInvalid(ProviderList.java:298) at sun.security.jca.Providers.getFullProviderList(Providers.java:176) at java.security.Security.insertProviderAt(Security.java:362) at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:942) at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:869) at ComCrypto.loginDB(ComCrypto.java:420) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1145) at ConfigureCA.main(ConfigureCA.java:1672) Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:215) at java.util.zip.ZipFile.init(ZipFile.java:145) at java.util.jar.JarFile.init(JarFile.java:153) at java.util.jar.JarFile.init(JarFile.java:90) at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:728) at sun.misc.URLClassPath$JarLoader.access$600(URLClassPath.java:591) at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:673) at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:666) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:665) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:836) ... 23 more Thats a very interesting error. Looks like something is going on at the nss/jss level on the client side when trying to initialize the client side nss database. Can you tell me what versions you have for nss, jss, pki-common, pkisilent, pki-ca ? rpm -q nss jss pki-common pki-silent pki-ca Thanks. 2014-05-28T09:20:15Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa1.int.immi.gov.au -cs_port 9445 -client_certdb_dir /tmp/tmp-RsFkUW -client_certdb_pwd -preop_pin miTD9vj5e6KwfqQNy2ig -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject
Re: [Freeipa-users] CS.cfg empty
Bret, What version is the Dogtag instance on that server? (rpm -q pki-ca) We have seen cases when the CS.cfg has zero length - and have modified code to: 1) not write to CS.cfg on startup 2) backup the CS.cfg on upgrades. Under normal operations, unless you are configuring the Dogtag instance - which would not be happening during normal IPA operations, the CS.cfg should not be written to. Is there perhaps a backup of CS.cfg under /etc/pki/pki-tomcat/ca (assuming this is Dogtag 10) or under /var/log/pki/server/upgrade ? Ade On Mon, 2014-01-27 at 06:17 -0500, Bret Wortman wrote: Martin, The only other systems I have running IPA are on another network. I could take their CS.cfg file and try to modify it to fit what this one should have had, but that's my only option. On the up side, this is a relatively small network, and reinstating the users and hosts won't be an enormous task. Big, but not enormous. And I should have had a backup, especially knowing there was a scheduled power outage coming up. Because those are always problem-free ;-) Bret On 01/27/2014 04:14 AM, Martin Kosek wrote: On 01/27/2014 01:51 AM, Bret Wortman wrote: We had to reboot the IPA server on a standalone network recently, and this IPA server is the only one on that network; there are no replicas. Upon restarting, the IPA software refused to start because, after a couple hours of tracking things down, our /etc/pki-ca/CS.cfg file is zero-length. How can I most easily restore this file given that I doubt we have a backup (our bad)? Is there a way to basically reinstall the server without losing the data in the database? Our users and host definitions, anyway? Thanks! Bret Hello Bret, Sorry to hear that. It looks like something (PKI?) was writing to the CS.cfg while the IPA server restarted. What version of IPA and PKI are we talking about? Do you have any other PKI server with CA you can use as a source of the CS.cfg file or as a replica to reinstall the IPA server with CA from (in the worst case)? I am adding PKI developers to the CC to advise. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Elliptic curves with the CA
As a partial answer to this, work has been ongoing to fully support ECC in Dogtag. Attached is a most likely out-of-date wiki page detailing ECC support in Dogtag. https://pki.fedoraproject.org/wiki/ECC_in_Dogtag If I recall correctly, we are somewhere around phase 3. Ade On Fri, 2013-09-20 at 11:48 -0400, Dmitri Pal wrote: On 09/18/2013 01:53 PM, mees virk wrote: I do not have a valid support contract, or other contracts with RedHat. Doesn't that stop me from opening proper RFE ticket? In any case, my interest was this time solely for evaluation purposes. If I were actively choosing an integrated identity management product, I might not choose Freeipa because it takes the longevity of the product and the development stance (lack of roadmap?) into question. I wonder where the lack of roadmap came from? http://www.freeipa.org/page/Roadmap So the trac system we use gives a good view of the dynamics of the project https://fedorahosted.org/freeipa/roadmap However IMO disconnect in expectations is that support of the ECC is not exactly FreeIPA's problem (yet). It needs to be implemented by the lower levels of the stack first: NSS, Dogtag etc. We have plans for support of the certs for users and we understand that RSA becomes outdated. Your RFE would allow us to track your specific requirements and interest (and make it our problem). Right now the position is that: let the underlying components grow ECC suppoirt and consume this functionality in FreeIPA when it matures. Filing an RFE would change this dynamics and would signal us that there is interest in the community in the actual end point solution, i.e. FreeIPA supporting ECC. Thanks! RSA is slowly getting into slippery slope, because it really isn't about what it's worth today. When you protect something with a cryptographic algorithm you have to take account for how long certain types of data will be stored, and factor that time frame in. Increasing the key sizes will not be solution, because several embedded devices such as VPN products, smartcards and RFID devices will start failing pretty fast after 1024-2048 bit keys. ECC was designed to solve some of these issues; it's important development not mostly because of security today but because it will scale better up (it was designed to be implementable better on hardware), and the key sizes start from nicer point of security vs size. So it's the feature that would future proof the CA. At this moment there is available ECC support on some products on all the areas such as smart cards, so the products not having that option out of the box will start basically losing in the competition. I'm not trying to make a technical point here (if I made some minor error there, sorry) but a managerial, and from product management viewpoint. ECC must be on the feature set, or the CA features will be discarded in the future by potential users. That means the Freeipa as a whole might not be selected for some projects. Plus, it doesn't really hurt having ECC in. :) IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not looked at this area yet. I suspect it would require changes in Dogtag first. Would be best if you can file and RFE ticket, then we would be able to follow up. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] F18 - F19 upgrade
Ian, Sorry for the late response. Just saw this email. I'm surprised that you were able to update your machine to F19. We explicitly put in spec file logic to do a pre-trans check to see if you had dogtag 9 system instances before updating to f19. This was to prevent people from getting into a situation where there installation was broken. The issue is that dogtag 9 instances use tomcat 6, and tomcat 6 is no longer in fedora 19. Dogtag 10 instances, on the other hand, use tomcat 7. The two instance types are therefore incompatible. The suggestion therefore would have been to create a replica of the ipa master prior to doing the upgrade to F19. In fact, you could have just installed a brand new f19 machine and then created a replica (and then shut down the old machine). Seeing as you have somehow upgraded your machine to F19, we need to try and get your system back up. For that, you need to follow the instructions in Workaround ie. installing tomcat6 and downgrading tomcatjss to the version in f18. That will hopefully get your CA up and running. At that point, it is highly recommended that you use ipa utilities to create a replica and use that instead. Ade On Mon, 2013-07-15 at 17:47 +0200, Martin Kosek wrote: On 07/13/2013 05:28 AM, Ian Chapman wrote: Hi, I've just recently upgrade my F18 server to F19 and IPA is failing to start: Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Aborting ipactl Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Starting Directory Service Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Starting krb5kdc Service Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Starting kadmin Service Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Starting ipa_memcached Service Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Starting httpd Service Jul 13 10:52:30 rex.homenet.lan ipactl[98002]: Starting pki-cad Service Jul 13 10:52:30 rex.homenet.lan systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURE Jul 13 10:52:30 rex.homenet.lan systemd[1]: Failed to start Identity, Policy, Audit. Jul 13 10:52:30 rex.homenet.lan systemd[1]: Unit ipa.service entered failed state. It seems that the pki-cad service fails to start. Is that in relation to dogtag upgrade of 9 to 10 or possibly another problem? There is of course this page: http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10 but frankly I don't really understand it. Well I get that the idea is to create a new pki cloned instance which would be dogtag 10 compatible and then delete the old one - I'm really don't know what I'm supposed to put in the configuration file. Has anybody else done this? Is there some more examples? Thanks. The status of pki-cad is: systemctl status pki-cad@pki-ca.service pki-cad@pki-ca.service - PKI Certificate Authority Server pki-ca Loaded: loaded (/usr/lib/systemd/system/pki-cad@.service; enabled) Active: failed (Result: exit-code) since Sat 2013-07-13 10:54:23 WST; 30min ago Process: 98170 ExecStart=/usr/bin/pkicontrol start ca %i (code=exited, status=1/FAILURE) Jul 13 10:54:23 rex.homenet.lan systemd[1]: Starting PKI Certificate Authority Server pki-ca... Jul 13 10:54:23 rex.homenet.lan pkicontrol[98170]: WARNING: Symbolic link '/var/lib/pki-ca/pki-ca' does NOT exist! Jul 13 10:54:23 rex.homenet.lan pkicontrol[98170]: INFO: Attempting to create '/var/lib/pki-ca/pki-ca' - '/usr/sbin/tomcat6-sysd' . . . Jul 13 10:54:23 rex.homenet.lan pkicontrol[98170]: ERROR: Failed making '/var/lib/pki-ca/pki-ca' - '/usr/sbin/tomcat6-sysd' since target '/usr/sb...T exist! Jul 13 10:54:23 rex.homenet.lan systemd[1]: pki-cad@pki-ca.service: control process exited, code=exited status=1 Jul 13 10:54:23 rex.homenet.lan systemd[1]: Failed to start PKI Certificate Authority Server pki-ca. Jul 13 10:54:23 rex.homenet.lan systemd[1]: Unit pki-cad@pki-ca.service entered failed state. Adding PKI/Dogtag developers to CC to advise. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] error setting up replication client
Ok. The log directory being empty is indicative of the server not having started - which is what I suspected based on the output you provided. There might have been some indication in /var/log/messages or in /var/log/audit/audit.log (for selinux) as to why this happened. If this does happen again, I would check there. Ade On Thu, 2013-03-21 at 16:24 -0400, Patrick Hemmer wrote: I'm not sure what happened here. The log dir for pki-ca was completely empty. I restarted pki-ca, the log files were created, and it appeared to operate normally. I rebuilt the box from scratch (just to have a clean start) and everything came up perfectly fine. -Patrick On 2013/20/03 12:54, Ade Lee wrote: Patrick, Can you provide some log files? Looks like pkisilent is trying to get to the first configuration panel on the CA and is getting a 302. I would need to see the logs under /var/log/pki-ca for the replica subsystem. Thanks, Ade Lee On Wed, 2013-03-20 at 12:04 -0400, Patrick Hemmer wrote: I'm trying to set up an ipa replica, and each time I try the install process fails at the same point. When I look in the ipareplica-install.log I see a 302 redirection which seems to be causing the issue. Any ideas why this is happening (or if something else is the issue)? Thanks -Patrick (http://fpaste.org/gbYz/) 2013-03-15T17:19:50Z DEBUG stderr= 2013-03-15T17:19:50Z DEBUG duration: 5 seconds 2013-03-15T17:19:50Z DEBUG [3/17]: configuring certificate server instance 2013-03-15T17:19:51Z DEBUG args=/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname i-d1579ba3.ipa-server.us-east-1.cloud.com -cs_port 9445 -client_certdb_dir /tmp/tmp-2l64F1 -client_certdb_pw d -preop_pin IWk44JzZT6A78Pha3SrM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa - agent_cert_subject CN=ipa-ca-agent,O=CLOUD.COM -ldap_host i-d1579ba3.ipa-server.us-east-1.cloud.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ip aca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD .COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=CLOUD.COM -ca_server_cert_subject_name CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O= CLOUD.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=CLOUD.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=CLOUD.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_pa ssword -sd_hostname i-6775b715.ipa-server.us-east-1.cloud.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://i-6775b715.ipa-ser ver.us-east-1.cloud.com:443 2013-03-15T17:19:51Z DEBUG stdout=libpath=/usr/lib64 ### CRYPTO INIT WITH CERTDB:/tmp/tmp-2l64F1 tokenpwd: # Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 in TestCertApprovalCallback.approve() Peer cert details: subject: CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O=CLOUD.COM issuer: CN=Certificate Authority,O=CLOUD.COM serial: 3 item 1 reason=-8172 depth=1 cert details: subject: CN=Certificate Authority,O=CLOUD.COM issuer: CN=Certificate Authority,O=CLOUD.COM serial: 1 importing certificate. Connected. Posting Query = https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/login?pin=IWk44JzZT6A78Pha3SrMxml=true RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT RESPONSE HEADER: Connection: keep-alive xml returned: # Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 Connected. Posting Query = https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/wizard?p=0op=nextxml=true RESPONSE STATUS: HTTP/1.1 302 Moved Temporarily RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Set-Cookie: JSESSIONID=A8B36AB92F386DB22B193215907C01AC; Path=/ca; Secure RESPONSE HEADER: Location: https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445/ca/admin/console/config/login RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT RESPONSE HEADER: Connection: keep-alive ERROR: unable to parse xml ERROR XML
Re: [Freeipa-users] error setting up replication client
Patrick, Can you provide some log files? Looks like pkisilent is trying to get to the first configuration panel on the CA and is getting a 302. I would need to see the logs under /var/log/pki-ca for the replica subsystem. Thanks, Ade Lee On Wed, 2013-03-20 at 12:04 -0400, Patrick Hemmer wrote: I'm trying to set up an ipa replica, and each time I try the install process fails at the same point. When I look in the ipareplica-install.log I see a 302 redirection which seems to be causing the issue. Any ideas why this is happening (or if something else is the issue)? Thanks -Patrick (http://fpaste.org/gbYz/) 2013-03-15T17:19:50Z DEBUG stderr= 2013-03-15T17:19:50Z DEBUG duration: 5 seconds 2013-03-15T17:19:50Z DEBUG [3/17]: configuring certificate server instance 2013-03-15T17:19:51Z DEBUG args=/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname i-d1579ba3.ipa-server.us-east-1.cloud.com -cs_port 9445 -client_certdb_dir /tmp/tmp-2l64F1 -client_certdb_pw d -preop_pin IWk44JzZT6A78Pha3SrM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa - agent_cert_subject CN=ipa-ca-agent,O=CLOUD.COM -ldap_host i-d1579ba3.ipa-server.us-east-1.cloud.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ip aca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD .COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=CLOUD.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=CLOUD.COM -ca_server_cert_subject_name CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O= CLOUD.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=CLOUD.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=CLOUD.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_pa ssword -sd_hostname i-6775b715.ipa-server.us-east-1.cloud.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://i-6775b715.ipa-ser ver.us-east-1.cloud.com:443 2013-03-15T17:19:51Z DEBUG stdout=libpath=/usr/lib64 ### CRYPTO INIT WITH CERTDB:/tmp/tmp-2l64F1 tokenpwd: # Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 in TestCertApprovalCallback.approve() Peer cert details: subject: CN=i-d1579ba3.ipa-server.us-east-1.cloud.com,O=CLOUD.COM issuer: CN=Certificate Authority,O=CLOUD.COM serial: 3 item 1 reason=-8172 depth=1 cert details: subject: CN=Certificate Authority,O=CLOUD.COM issuer: CN=Certificate Authority,O=CLOUD.COM serial: 1 importing certificate. Connected. Posting Query = https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/login?pin=IWk44JzZT6A78Pha3SrMxml=true RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT RESPONSE HEADER: Connection: keep-alive xml returned: # Attempting to connect to: i-d1579ba3.ipa-server.us-east-1.cloud.com:9445 Connected. Posting Query = https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445//ca/admin/console/config/wizard?p=0op=nextxml=true RESPONSE STATUS: HTTP/1.1 302 Moved Temporarily RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Set-Cookie: JSESSIONID=A8B36AB92F386DB22B193215907C01AC; Path=/ca; Secure RESPONSE HEADER: Location: https://i-d1579ba3.ipa-server.us-east-1.cloud.com:9445/ca/admin/console/config/login RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Content-Length: 0 RESPONSE HEADER: Date: Fri, 15 Mar 2013 17:19:51 GMT RESPONSE HEADER: Connection: keep-alive ERROR: unable to parse xml ERROR XML = ERROR: Tag=statushas no values Error in LoginPanel(): status value is null ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2013-03-15T17:19:51Z DEBUG stderr=[Fatal Error] :-1:-1: Premature end of file. org.xml.sax.SAXParseException; Premature end of file. at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:239) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) at ParseXML.parse(ParseXML.java:43) at ConfigureCA.getStatus(ConfigureCA.java:205) at ConfigureCA.checkStatus(ConfigureCA.java:221) at ConfigureCA.checkStatus
Re: [Freeipa-users] Trouble with ipa-server-install in Fedora 18
Can you confirm that using a password without % or ( in it resolves the
issue?
On Thu, 2013-01-24 at 16:32 -0500, Rob Crittenden wrote:
小龙 陈 wrote:
Hi everyone,
I have been having trouble getting FreeIPA set up on Fedora 18.
ipa-server-install
keeps failing at the [2/20]: configuring certificate server instance
stage. This is
on a fresh Fedora 18 virtual machine. I never had any issues on any of the
Fedora 18
prereleases.
ipa-server-install output: http://paste.kde.org/655916/raw/
rpm -qa | grep freeipa | sort: http://paste.kde.org/655928/raw/
/var/log/ipaserver-install.log:
http://ompldr.org/vaDdsOA/ipaserver-install.log
If I copy the pkispawn configuration from the log to /tmp/tmpZmif5T and run
the
failed command, I get: http://paste.kde.org/655940/raw/
Does anyone know what could be the problem? I can't seem to find anything
about
that error.
Looks like a bug in pki-core:
2013-01-24T20:18:55Z DEBUG stderr=Traceback (most recent call last):
File /usr/sbin/pkispawn, line 220, in module
main(sys.argv)
File /usr/sbin/pkispawn, line 158, in main
rv = parser.read_pki_configuration_file()
File /usr/lib/python2.7/site-packages/pki/deployment/pkiparser.py,
line 229, in read_pki_configuration_file
config.pki_subsystem_dict = dict(self.pki_config.items('CA'))
File /usr/lib64/python2.7/ConfigParser.py, line 655, in items
for option in options]
File /usr/lib64/python2.7/ConfigParser.py, line 691, in _interpolate
self._interpolate_some(option, L, rawval, section, vars, 1)
File /usr/lib64/python2.7/ConfigParser.py, line 732, in
_interpolate_some
'%%' must be followed by '%%' or '(', found: %r % (rest,))
ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or
'(', found: '%'
If you are using % or ( in your DM password you might try a different
password as a workaround.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa host-del
The logs seem to show that the CA cannot find JSS.
What versions of the following are on your system?
pki-ca, pki-common, jss, nss, tomcat6, tomcat, java
Is this a system that was working and now fails to work? Or is this a
new instance?
Ade
On Wed, 2012-09-05 at 06:41 -0700, george he wrote:
there are somethign like these:
type=AVC msg=audit(1346710042.243:56): avc: denied { execute } for
pid=4243 comm=gdm name=arch dev=dm-0 ino=786829
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(1346710042.243:57): avc: denied { execute } for
pid=4243 comm=gdm name=arch dev=dm-0 ino=786829
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
and some others like these:
type=AVC msg=audit(1346838993.154:2567): avc: denied { search } for
pid=17155 comm=java name=gridengine dev=dm-0 ino=391879
scontext=unconfined_u:system_r:pki_ca_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir
type=AVC msg=audit(1346838993.154:2568): avc: denied { search } for
pid=17155 comm=java name=gridengine dev=dm-0 ino=391879
scontext=unconfined_u:system_r:pki_ca_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir
And yes, I did yum update recently.
Where else should I look?
Thanks,
George
__
From: Rob Crittenden rcrit...@redhat.com
To: george he george_...@yahoo.com
Cc: Ade Lee a...@redhat.com; freeipa-users@redhat.com
freeipa-users@redhat.com
Sent: Wednesday, September 5, 2012 8:40 AM
Subject: Re: [Freeipa-users] ipa host-del
george he wrote:
here are the new errors:
# rm /var/log/pki-ca/*
# service dirsrv restart
# service pki-cad restart
# grep -i error /var/log/pki-ca/*
/var/log/pki-ca/catalina.2012-09-05.log:WARNING: Error while
removing
context [/ca]
/var/log/pki-ca/catalina.2012-09-05.log:SEVERE: Error
initializing
socket factory
/var/log/pki-ca/catalina.2012-09-05.log:java.lang.ClassNotFoundException:
Error
loading SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.2012-09-05.log:LifecycleException:
Protocol
handler initialization failed:
java.lang.ClassNotFoundException: Error
loading SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.2012-09-05.log:SEVERE: Error
deploying web
application directory ca
/var/log/pki-ca/catalina.out:SEVERE: Error initializing
socket factory
/var/log/pki-ca/catalina.out:java.lang.ClassNotFoundException: Error
loading SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.out:LifecycleException: Protocol
handler
initialization failed: java.lang.ClassNotFoundException:
Error loading
SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.out:SEVERE: Error deploying web
application
directory ca
/var/log/pki-ca/catalina.out:SEVERE: Error initializing
socket factory
/var/log/pki-ca/catalina.out:java.lang.ClassNotFoundException: Error
loading SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.out:LifecycleException: Protocol
handler
initialization failed: java.lang.ClassNotFoundException:
Error loading
SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
Hmm. Is there any additional information in the debug log? Any
AVCs in
/var/log/audit/audit.log?
Have you updated any packages recently? I'm not sure why
dogtag would be
throwing this exception.
rob
*From:* Rob Crittenden rcrit...@redhat.com
*To:* george he george_...@yahoo.com
*Cc:* John
Re: [Freeipa-users] ipa host-del
weird. Can you try putting selinux in permissive mode, and then
restarting ipa?
On Wed, 2012-09-05 at 08:21 -0700, george he wrote:
This is a newly installed system. It does most of the things, but I
just cannot del the host that I have uninstalled ipa-client, which
prvents me from re-installing ipa-client.
Here are the versions:
pki-ca.noarch9.0.3-24.el6
pki-common.noarch 9.0.3-24.el6
jss.x86_64 4.2.6-22.el6
nss.x86_643.13.5-1.el6_3
tomcat6.noarch 6.0.24-45.el6
java-1.5.0-gcj.x86_64 1.5.0.0-29.1.el6
java-1.6.0-openjdk.x86_64 1:1.6.0.0-1.48.1.11.3.el6_2
java_cup.x86_64 1:0.10k-5.el6
Thanks for your help.
George
__
From: Ade Lee a...@redhat.com
To: george he george_...@yahoo.com
Cc: Rob Crittenden rcrit...@redhat.com;
freeipa-users@redhat.com freeipa-users@redhat.com
Sent: Wednesday, September 5, 2012 10:46 AM
Subject: Re: [Freeipa-users] ipa host-del
The logs seem to show that the CA cannot find JSS.
What versions of the following are on your system?
pki-ca, pki-common, jss, nss, tomcat6, tomcat, java
Is this a system that was working and now fails to work? Or
is this a
new instance?
Ade
On Wed, 2012-09-05 at 06:41 -0700, george he wrote:
there are somethign like these:
type=AVC msg=audit(1346710042.243:56): avc: denied
{ execute } for
pid=4243 comm=gdm name=arch dev=dm-0 ino=786829
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=AVC msg=audit(1346710042.243:57): avc: denied
{ execute } for
pid=4243 comm=gdm name=arch dev=dm-0 ino=786829
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
and some others like these:
type=AVC msg=audit(1346838993.154:2567): avc: denied
{ search } for
pid=17155 comm=java name=gridengine dev=dm-0 ino=391879
scontext=unconfined_u:system_r:pki_ca_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir
type=AVC msg=audit(1346838993.154:2568): avc: denied
{ search } for
pid=17155 comm=java name=gridengine dev=dm-0 ino=391879
scontext=unconfined_u:system_r:pki_ca_t:s0
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir
And yes, I did yum update recently.
Where else should I look?
Thanks,
George
__
From: Rob Crittenden rcrit...@redhat.com
To: george he george_...@yahoo.com
Cc: Ade Lee a...@redhat.com;
freeipa-users@redhat.com
freeipa-users@redhat.com
Sent: Wednesday, September 5, 2012 8:40 AM
Subject: Re: [Freeipa-users] ipa host-del
george he wrote:
here are the new errors:
# rm /var/log/pki-ca/*
# service dirsrv restart
# service pki-cad restart
# grep -i error /var/log/pki-ca/*
/var/log/pki-ca/catalina.2012-09-05.log:WARNING:
Error while
removing
context [/ca]
/var/log/pki-ca/catalina.2012-09-05.log:SEVERE:
Error
initializing
socket factory
/var/log/pki-ca/catalina.2012-09-05.log:java.lang.ClassNotFoundException:
Error
loading SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.2012-09-05.log:LifecycleException:
Protocol
handler initialization failed:
java.lang.ClassNotFoundException: Error
loading SSL Implementation
org.apache.tomcat.util.net.jss.JSSImplementation
:java.lang.ClassNotFoundException:
org.mozilla.jss.ssl.SSLSocket
/var/log/pki-ca/catalina.2012-09-05.log:SEVERE:
Error
deploying web
application directory ca
/var/log/pki-ca/catalina.out:SEVERE: Error
initializing
socket factory
Re: [Freeipa-users] Problem installing replica CA
On Tue, 2012-04-24 at 11:28 -0400, Rob Crittenden wrote: Dan Scott wrote: On Tue, Apr 24, 2012 at 02:58, Ondrej Hamadaoham...@redhat.com wrote: On 04/20/2012 09:35 PM, Dan Scott wrote: On Fri, Apr 20, 2012 at 15:26, Dmitri Pald...@redhat.comwrote: On 04/20/2012 12:15 PM, Dan Scott wrote: Hi, My FreeIPA servers were in a real mess recently and I think I've finally got them into a reasonable state by cleaning up the tombstone entries and fixing some broken replication agreements. I'm trying to setup a new replica and receive the following error: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/12]: creating certificate server user [2/12]: creating pki-ca instance [3/12]: configuring certificate server instance root: CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' 'fileserver4.ecg.mit.edu' '-cs_port' '9445' '-client_certdb_dir' '/tmp/tmp-JwjkjT' '-client_certdb_pwd' '-preop_pin' '5wVoLxO2KJ1aOlOk74mA' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' 'root@localhost' '-admin_password' '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' '-agent_cert_subject' 'CN=ipa-ca-agent,O=ECG.MIT.EDU' '-ldap_host' 'fileserver4.ecg.mit.edu' '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' '-subsystem_name' 'pki-cad' '-token_name' 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=ECG.MIT.EDU' '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=ECG.MIT.EDU' '-ca_server_cert_subject_name' 'CN=fileserver4.ecg.mit.edu,O=ECG.MIT.EDU' '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=ECG.MIT.EDU' '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=ECG.MIT.EDU' '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' '-clone_p12_password' '-sd_hostname' 'fileserver3.ecg.mit.edu' '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' '-clone_start_tls' 'true' '-clone_uri' 'https://fileserver3.ecg.mit.edu:443'' returned non-zero exit status 255 creation of replica failed: Configuration of CA failed The /var/log/pki-ca/debug file contains: [20/Apr/2012:12:07:36][http-9445-1]: CertRequestPanel: Failed to import user certificate.org.mozilla.jss.crypto.TokenException: PK11_ImportDERCertForKey Unable to import certificate to its token: (-8054) You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. [20/Apr/2012:12:07:36][http-9445-1]: Updating local request... certTag=sslserver [20/Apr/2012:12:07:36][http-9445-1]: In LdapBoundConnFactory::getConn() [20/Apr/2012:12:07:36][http-9445-1]: masterConn is connected: true [20/Apr/2012:12:07:36][http-9445-1]: getConn: conn is connected true [20/Apr/2012:12:07:36][http-9445-1]: getConn: mNumConns now 2 [20/Apr/2012:12:07:36][http-9445-1]: returnConn: mNumConns now 3 [20/Apr/2012:12:07:36][http-9445-1]: In LdapBoundConnFactory::getConn() [20/Apr/2012:12:07:36][http-9445-1]: masterConn is connected: true [20/Apr/2012:12:07:36][http-9445-1]: getConn: conn is connected true [20/Apr/2012:12:07:36][http-9445-1]: getConn: mNumConns now 2 [20/Apr/2012:12:07:36][http-9445-1]: returnConn: mNumConns now 3 [20/Apr/2012:12:07:36][http-9445-1]: getNextPanel input p=12 [20/Apr/2012:12:07:36][http-9445-1]: getNextPanel output p=13 [20/Apr/2012:12:07:36][http-9445-1]: panel no=13 [20/Apr/2012:12:07:36][http-9445-1]: panel name=backupkeys [20/Apr/2012:12:07:36][http-9445-1]: total number of panels=19 [20/Apr/2012:12:07:36][http-9445-1]: WizardServlet: found xml [20/Apr/2012:12:07:36][http-9445-1]: Error: unknown type org.apache.catalina.connector.ResponseFacade [20/Apr/2012:12:07:36][http-9445-1]: Error: unknown type java.lang.Boolean [20/Apr/2012:12:07:36][http-9445-1]: Error: unknown type org.apache.catalina.connector.RequestFacade So it looks like there's some certificate confusion going on. Can someone help? Is there anything particularly sensitive in the /var/log/ipareplica-install.log or /var/log/pki-ca/debug files that I shouldn't send them to the list? Are you installing it on a new machine? What version of the OS and tomcat is there? There have been some glitches in the tomcat package in the past. It's quite new - a VM which I installed 10 days ago. I tried to install a replica on it before I cleaned my other IPA servers. Are you sure that the CA was cleaned up on the replica? Run 'ipa-server-install --uninstall' and then check existence of /var/lib/pki-ca. if it's still there -
Re: [Freeipa-users] CA replica installation failure
Ok -- at this point, I need some logs to determine why the server is not starting. How about you zip up all the logs in /var/log/pki-ca as well as /var/pki-ca-install.log ? Ade On Thu, 2012-03-01 at 11:07 -0500, Dan Scott wrote: Hi, I tried with SELinux in permissive mode. It failed in the same way. Dan On Wed, Feb 29, 2012 at 16:28, Ade Lee a...@redhat.com wrote: Its a little strange that its showing up as an error -- it shouldn't if they are already set and they are of the right context. That said, its not really an error - and should not be a problem unless its preventing the installation from completing successfully. Try doing the installation with selinux in permissive mode and see if it makes a difference. Ade On Wed, 2012-02-29 at 16:18 -0500, Dan Scott wrote: On Wed, Feb 29, 2012 at 16:03, Ade Lee a...@redhat.com wrote: Thats a pretty strange error. The ports there are supposed to be reserved for pki_ca_port_t. Can you do the following for each of the ports? semanage port -l |grep 9443 [root@fileserver3 ~]# semanage port -l |grep 9443 pki_ca_port_t tcp 9180, 9701, 9443-9447 944[456] don't match, but they're in the range, so they should be OK, right? Is it really an error? Or is it just indicating that the port has already been set. Thanks, Dan Its probably best to completely remove the replica. You could try use dogtag specific commands to uninstall and install the ca - but then the rest of the ipa install scripts would be confused. Ade On Wed, 2012-02-29 at 13:44 -0500, Dan Scott wrote: Anyone have any suggestions for how I can fix this? Dan On Mon, Feb 27, 2012 at 21:06, Dan Scott danieljamessc...@gmail.com wrote: Hi, I'm having another problem with replica installation - just the CA this time It looks like there's a problem with SELinux and the pki-ca service: After configuration, the server can be operated by the command: /bin/systemctl restart pki-cad@pki-ca.service 2012-02-27 20:33:45,729 DEBUG stderr=[error] Failed setting selinux context pki_ca_port_t for 9180. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9701. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9443. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9444. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9446. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9445. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9447. Port already defined otherwise. [error] FAILED run_command(/bin/systemctl restart pki-cad@pki-ca.service), exit status=1 output=Job failed. See system logs and 'systemctl status' for details. 2012-02-27 20:33:45,729 DEBUG duration: 6 seconds 2012-02-27 20:33:45,730 DEBUG [3/11]: configuring certificate server instance [clip] 2012-02-27 20:33:46,159 DEBUG stdout=libpath=/usr/lib64 ### CRYPTO INIT WITH CERTDB:/tmp/tmp-cDdVph tokenpwd: # Attempting to connect to: fileserver3.example.com:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-02-27 20:33:46,159 DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at java.net.Socket.connect(Socket.java:495) at java.net.Socket.init(Socket.java:392) at java.net.Socket.init(Socket.java:235) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main
Re: [Freeipa-users] CA replica installation failure
Thats a pretty strange error. The ports there are supposed to be reserved for pki_ca_port_t. Can you do the following for each of the ports? semanage port -l |grep 9443 Its probably best to completely remove the replica. You could try use dogtag specific commands to uninstall and install the ca - but then the rest of the ipa install scripts would be confused. Ade On Wed, 2012-02-29 at 13:44 -0500, Dan Scott wrote: Anyone have any suggestions for how I can fix this? Dan On Mon, Feb 27, 2012 at 21:06, Dan Scott danieljamessc...@gmail.com wrote: Hi, I'm having another problem with replica installation - just the CA this time It looks like there's a problem with SELinux and the pki-ca service: After configuration, the server can be operated by the command: /bin/systemctl restart pki-cad@pki-ca.service 2012-02-27 20:33:45,729 DEBUG stderr=[error] Failed setting selinux context pki_ca_port_t for 9180. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9701. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9443. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9444. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9446. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9445. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9447. Port already defined otherwise. [error] FAILED run_command(/bin/systemctl restart pki-cad@pki-ca.service), exit status=1 output=Job failed. See system logs and 'systemctl status' for details. 2012-02-27 20:33:45,729 DEBUG duration: 6 seconds 2012-02-27 20:33:45,730 DEBUG [3/11]: configuring certificate server instance [clip] 2012-02-27 20:33:46,159 DEBUG stdout=libpath=/usr/lib64 ### CRYPTO INIT WITH CERTDB:/tmp/tmp-cDdVph tokenpwd: # Attempting to connect to: fileserver3.example.com:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-02-27 20:33:46,159 DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at java.net.Socket.connect(Socket.java:495) at java.net.Socket.init(Socket.java:392) at java.net.Socket.init(Socket.java:235) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) /var/log/messages contains the following: Feb 27 20:40:45 localhost kpasswd[2198]: Error receiving request (104) Connection reset by peer Feb 27 20:57:26 localhost pkicontrol[2778]: /usr/bin/runcon: invalid context: system_u:system_r:pki_ca_script_t:s0: Invalid argument Feb 27 20:57:26 localhost systemd[1]: pki-cad@pki-ca.service: control process exited, code=exited status=1 Feb 27 20:57:26 localhost systemd[1]: Unit pki-cad@pki-ca.service entered failed state. This is a fresh install of Fedora 16. There are no updates to apply. Any ideas? One more thing. Is there a way to remove and reinstall just the CA? Or do I have to completely remove and re-install the entire IPA replica? i.e. Is there something like ipa-ca-install --uninstall I couldn't see the option anywhere. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] CA replica installation failure
Its a little strange that its showing up as an error -- it shouldn't if they are already set and they are of the right context. That said, its not really an error - and should not be a problem unless its preventing the installation from completing successfully. Try doing the installation with selinux in permissive mode and see if it makes a difference. Ade On Wed, 2012-02-29 at 16:18 -0500, Dan Scott wrote: On Wed, Feb 29, 2012 at 16:03, Ade Lee a...@redhat.com wrote: Thats a pretty strange error. The ports there are supposed to be reserved for pki_ca_port_t. Can you do the following for each of the ports? semanage port -l |grep 9443 [root@fileserver3 ~]# semanage port -l |grep 9443 pki_ca_port_t tcp 9180, 9701, 9443-9447 944[456] don't match, but they're in the range, so they should be OK, right? Is it really an error? Or is it just indicating that the port has already been set. Thanks, Dan Its probably best to completely remove the replica. You could try use dogtag specific commands to uninstall and install the ca - but then the rest of the ipa install scripts would be confused. Ade On Wed, 2012-02-29 at 13:44 -0500, Dan Scott wrote: Anyone have any suggestions for how I can fix this? Dan On Mon, Feb 27, 2012 at 21:06, Dan Scott danieljamessc...@gmail.com wrote: Hi, I'm having another problem with replica installation - just the CA this time It looks like there's a problem with SELinux and the pki-ca service: After configuration, the server can be operated by the command: /bin/systemctl restart pki-cad@pki-ca.service 2012-02-27 20:33:45,729 DEBUG stderr=[error] Failed setting selinux context pki_ca_port_t for 9180. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9701. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9443. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9444. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9446. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9445. Port already defined otherwise. [error] Failed setting selinux context pki_ca_port_t for 9447. Port already defined otherwise. [error] FAILED run_command(/bin/systemctl restart pki-cad@pki-ca.service), exit status=1 output=Job failed. See system logs and 'systemctl status' for details. 2012-02-27 20:33:45,729 DEBUG duration: 6 seconds 2012-02-27 20:33:45,730 DEBUG [3/11]: configuring certificate server instance [clip] 2012-02-27 20:33:46,159 DEBUG stdout=libpath=/usr/lib64 ### CRYPTO INIT WITH CERTDB:/tmp/tmp-cDdVph tokenpwd: # Attempting to connect to: fileserver3.example.com:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2012-02-27 20:33:46,159 DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) at java.net.Socket.connect(Socket.java:546) at java.net.Socket.connect(Socket.java:495) at java.net.Socket.init(Socket.java:392) at java.net.Socket.init(Socket.java:235) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) /var/log/messages contains the following: Feb 27 20:40:45 localhost kpasswd[2198]: Error receiving request (104) Connection reset by peer Feb 27 20:57:26 localhost pkicontrol[2778]: /usr/bin/runcon: invalid context: system_u:system_r:pki_ca_script_t:s0: Invalid argument Feb 27 20:57:26 localhost systemd[1]: pki-cad@pki-ca.service: control process exited, code=exited status=1 Feb 27 20:57:26 localhost systemd[1]: Unit pki-cad@pki-ca.service
[Freeipa-users] [Fwd: [Freeipa-devel] script to proxy-ize a dogtag instance]
Cross-posting to freeipa-users. In addition, Adam determined that the following dirctives need to be enabled in /etc/httpd/conf.d/nss.conf : NSSRenegotiation on NSSRequireSafeNegotiation on Ade ---BeginMessage--- Hi, With recent changes, Dogtag instances in IPA now reside behind an Apache proxy and are accessed using ports 80 and 443. This is the default configuration for any newly created instances. Older instances that have been recently upgraded will need to run a script to upgrade the Dogtag configuration to use the Apache proxy. A script (pki_setup_proxy) is attached. It is essentially complete - only needing things like usage() and some cleanup. It has been through some minimal testing. I am posting it now to help users who are stuck to fix their existing instances. It will be delivered as part of pki-setup in the very near future. The script will modify the following files (making a backup of each as $filename.pre-proxy beforehand). /var/lib/pki-ca/conf/proxy.conf /var/lib/pki-ca/conf/CS.cfg /var/lib/pki-ca/conf/server.xml /var/lib/pki-ca/webapps/ca/WEB_INF/web.xml /var/lib/pki-ca/webappas/ca/ee/ca/ProfileSubmit.template And will log all actions in /var/log/pki-ca-proxy-setup.log * Instructions for IPA: 1. Run the script as follows (as root): chmod +x pki-setup-proxy ./pki-setup-proxy -pki_instance_root=/var/lib -pki_instance_name=pki-ca -subsystem_type=ca 2. Copy the proxy.conf file: cp /var/lib/pki-ca/conf/proxy.conf /etc/httpd/conf.d/ipa-pki-proxy.conf 3. Restart IPA. Please send me feedback if things don't work! Thanks, Ade pki-setup-proxy Description: Perl program ___ Freeipa-devel mailing list freeipa-de...@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel---End Message--- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA 2.1.0 - SELinux
Siggi, The fix for this has already been checked into the dogtag code. We'll have a new build out (for pki-ca) probably sometime next week. Ade On Fri, 2011-08-19 at 12:57 -0400, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I've just updated to FreeIPA 2.1.0. I disabled SELinux on this machine (Fedora 15) when I installed IPA, as there was a bug with IPA's SELinux ruleset, which made the ipa-server-install script fail. That decision seem to be biting my ass now, I get the following error message: /usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel whenever I attempt to start IPA. See below for output. After configuring SELinux to be permissive the error disappears, and IPA starts normally. I have opened a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=732064 Other than that - thank you for an excellent product! I've been waiting for the automount option in the GUI, makes editing automount rules a whole lot easier!! :) Regards, Siggi [root@ipa03 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: IX-TEST-COM... server already stopped [FAILED] PKI-IPA... server already stopped [FAILED] *** Error: 2 instance(s) unsuccessfully stopped [FAILED] Starting dirsrv: IX-TEST-COM... [ OK ] PKI-IPA... [ OK ] Restarting KDC Service Restarting krb5kdc (via systemctl): [ OK ] Restarting KPASSWD Service Restarting ipa_kpasswd (via systemctl): [ OK ] Restarting HTTP Service Restarting httpd (via systemctl): [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] /usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel Failed to restart CA Service Shutting down Stopping krb5kdc (via systemctl): [ OK ] Stopping ipa_kpasswd (via systemctl): [ OK ] Stopping httpd (via systemctl): [ OK ] Stopping pki-ca: [ OK ] Shutting down dirsrv: IX-TEST-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl [root@ipa03 ~]# getenforce Disabled What is/was the bug in the SELinux ruleset that caused you to disable SELinux in the first place? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Configuring IPA replicas
Hi, The replica installation is failing when the replica attempts to contact the CA on the master to log into the security domain. According to your log, this is https://ipa01.ix.test.com:9445 Can the master be resolved and reached from the replica? Can port 9445 be reached (as well as ports 9444 and 9443?) You can also check the master's /var/log/pki-ca/debug log to see if any communication was received from the replica. Ade On Mon, 2011-06-13 at 16:17 +0200, Sigbjorn Lie wrote: On 06/13/2011 04:12 PM, Simo Sorce wrote: On Mon, 2011-06-13 at 15:23 +0200, Sigbjorn Lie wrote: Hi, I have successfully configured one IPA replica, now I'm trying to configure a second replica, but I'm not having much success. I've attached the output of ipa-replica-install -d. I get as far as [4/11]: configuring certificate server instance. The machine is configured in the same way as the 2 first machines. They are all F15, updated with all available packages from the official repos. The installation fails when it's trying to connect to the dogtag server on the ipa replica it's just configured, with a Invalid clone_uri message. (See the attached file for details). I'm not sure where to start looking. The only difference from the 2 first IPA servers, is that this server is located at another subnet, over a site-to-site VPN connection. Any suggestions to what might be wrong? I have never seen this error, have you created a new replica package with ipa-replica-prepare to create the second replica ? Yes, a fresh package was created using ipa-replica-prepare and scp'ed to the new ipa server. I've even tried re-creating the package. Still the same error message. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
