Re: [Freeipa-users] FreeIPA-Samba4 integration?

[Endi Sukma Dewata]

Hi Attila,

Attila Bogár wrote:
> I would like to deploy an integrated Samba4 / FreeIPA environment.
> I would like to enquire, what's the current status of FreeIPA 1.9.0.pre4 and 
> Samba4 integration.

The integration plan that I was involved with was between IPA v3 and Samba 4. 
But this plan has
been deferred in favor of an alternative design using Samba 3.

> I've tried http://freeipa.org/page/Samba_4_Configuration a month ago, though 
> the ldap provision
> didn't seem to work. I've even raised a bug at Samba 
> https://bugzilla.samba.org/show_bug.cgi?id=7530
> - which is still open.

Yes, this is taking too long to resolve. Unfortunately the last time I tested 
this there
was a problem in Samba 4 that was affecting other LDAP backends as well, not 
just specific
to 389 DS. Samba 4 code is changing a lot so it's rather difficult for me to 
keep up with
the changes especially if it happens in the core code. I plan to continue the 
investigation
as soon as I get the chance.

I'll let the others respond to the following questions:

> If the Fedora-DS backed Samba4 isn't ready for production at this time,
> I would be interested in the pro/contra views of
> - deploying a separate Samba4 instance with filesystem backend
> - writing a password syncing plugin for Samba4 vs. 389-ds
>based on the docs at http://directory.fedoraproject.org/wiki/Plugins
> - other paths achieving integration?

Thanks.

--
Endi S. Dewata

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting

[Endi Sukma Dewata]

On 3/23/2015 12:10 PM, Michael Pawlak wrote:

Rob,

Thanks. Any additional eyes would be greatly apprecated.

*Michael Pawlak*
Web Systems Administrator | Colovore LLC
E: m...@colovore.com 
C: 408.316.2154


On Mon, Mar 23, 2015 at 6:24 AM, Rob Crittenden mailto:rcrit...@redhat.com>> wrote:

Martin Kosek wrote:
 > This may mean that Dogtag is not up. Can you please check with
"ipactl status"
 > that it (pki-ca) is up and running and that there are no related
SELinux AVCs?
 >

The problem seems to be java-related:

The self test plugin named selftests.container.logger.class contains a
value com.netscape.cms.logging.RollingLogFile which is invalid.

I've seen cases where selftest failures don't cause the CA to not start
up but does prevent it from actually operating.

The bottom line of the errors you are seeing is that the CA is not
completely running. I've cc'd a couple of dogtag developers to see if
they can help with the Java exception.

rob

 > On 03/23/2015 04:52 AM, Michael Pawlak wrote:
 >>> - /var/log/pki-ca/debug -
 >>>
 >>> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile
 >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile
 >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests
 >>> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests
 >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init():
ENTERING . . .
 >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init():
loading self
 >>> test logger parameters
 >>> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException
 >>> The self test plugin named selftests.container.logger.class
contains a
 >>> value com.netscape.cms.logging.RollingLogFile which is invalid.
 >>> at
 >>>

com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422)
 >>> at
 >>>


Hi,

Unfortunately the code doesn't log the exact cause of the problem. I 
need some additional info:


1. Which platform are you using?
2. What are the versions of the pki-* packages before and after upgrade?
3. Please provide the /etc/pki-ca/CS.cfg and /var/log/pki-ca/transactions.

Thanks.

--
Endi S. Dewata

--
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] Unable to Install IPA

[Endi Sukma Dewata]

On 3/3/2015 8:19 AM, Endi Sukma Dewata wrote:

On 2/28/2015 1:01 PM, Hadoop Solutions wrote:

Hi Rob,

please find the attached log of /var/log/ipaserver-install.log

kindly let me know the solution for this..

Thanks,
Shaik


Hi,

I see this near the bottom of the ipaserver-install.log.

#
Attempting to connect to: sv2lxdpdsedi02.corp.equinix.com:9445
Connected.
Posting Query =
https://sv2lxdpdsedi02.corp.equinix.com:9445//ca/admin/console/config/wizard?p=9&op=next&xml=true&host=sv2lxdpdsedi02.corp.equinix.com&port=7389&binddn=cn%3DDirectory+Manager&__bindpwd=&basedn=o%3Dipaca&database=ipaca&display=%24displayStr

RESPONSE STATUS:  HTTP/1.1 404 Not Found
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: text/html;charset=UTF-8
RESPONSE HEADER:  Date: Sat, 28 Feb 2015 05:57:35 GMT
RESPONSE HEADER:  Connection: close
ERROR: unable to parse xml
ERROR XML =
ERROR: Tag='updateStatus' has no values
Error in LdapConnectionPanel(): updateStatus value is null
ERROR: ConfigureCA: LdapConnectionPanel() failure
ERROR: unable to create CA

###

2015-02-28T05:57:35Z 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(xerces-j2-2.7.1.jar.so)
at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(xerces-j2-2.7.1.jar.so)
at javax.xml.parsers.DocumentBuilder.parse(libgcj.so.10)
at ParseXML.parse(ParseXML.java:258)
at ConfigureCA.getStatus(ConfigureCA.java:205)
at ConfigureCA.checkStatus(ConfigureCA.java:221)
at ConfigureCA.checkStatus(ConfigureCA.java:216)
at ConfigureCA.LdapConnectionPanel(ConfigureCA.java:510)
at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1225)
at ConfigureCA.main(ConfigureCA.java:1672)

Could you post the /var/log/pki-ca/debug? Thanks.



Hi, if this is still a problem please let me know. Thanks.

--
Endi S. Dewata

--
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] Having Issues with Dogtag After Updating IPA and Rebooting

[Endi Sukma Dewata]

Thanks for the info. The transaction log doesn't indicate the cause of the 
problem either. I might need to provide a custom build that generates more 
useful information. Would you be able to test that? Thanks.

--
Endi S. Dewata

- Original Message -
> Endi,
> 
> 1. I am currently using CentOS 6.5.
> 
> 2. Below are the package versions.
> 
> Former:
> Don't have that information available
> 
> Current:
> pki-java-tools-9.0.3-38.el6_6.noarch
> pki-silent-9.0.3-38.el6_6.noarch
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> pki-ca-9.0.3-38.el6_6.noarch
> pki-setup-9.0.3-38.el6_6.noarch
> pki-native-tools-9.0.3-38.el6_6.x86_64
> pki-util-9.0.3-38.el6_6.noarch
> pki-selinux-9.0.3-38.el6_6.noarch
> pki-common-9.0.3-38.el6_6.noarch
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> pki-symkey-9.0.3-38.el6_6.x86_64
> 
> 3. Attached
> 
> *Michael Pawlak*
> Web Systems Administrator | Colovore LLC
> E: m...@colovore.com
> C: 408.316.2154
>   <http://www.colovore.com>
> 
> On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata 
> wrote:
> >
> > Hi,
> >
> > Unfortunately the code doesn't log the exact cause of the problem. I need
> > some additional info:
> >
> > 1. Which platform are you using?
> > 2. What are the versions of the pki-* packages before and after upgrade?
> > 3. Please provide the /etc/pki-ca/CS.cfg and /var/log/pki-ca/transactions.
> >
> > Thanks.
> >
> > --
> > Endi S. Dewata

-- 
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] Having Issues with Dogtag After Updating IPA and Rebooting

[Endi Sukma Dewata]

Hi Michael,

It took longer than expected, but I finally managed to create the build:

https://edewata.fedorapeople.org/files/pki-common-9.0.3-39.el6_6.noarch.rpm

Please install it and retry the operation. I have not tried this myself, 
but it should generate more useful information.


Please let me know the exception that you see in /var/log/pki-ca/debug. 
Thanks.


--
Endi S. Dewata

On 3/24/2015 7:21 PM, Michael Pawlak wrote:

Endi,

Any word on the build?

*Michael Pawlak*
Web Systems Administrator | Colovore LLC
E: m...@colovore.com <mailto:m...@colovore.com>
C: 408.316.2154
<http://www.colovore.com>

On Mon, Mar 23, 2015 at 2:55 PM, Michael Pawlak mailto:m...@colovore.com>> wrote:

Endi,

I could test that.

*Michael Pawlak*
Web Systems Administrator | Colovore LLC
E: m...@colovore.com <mailto:m...@colovore.com>
C: 408.316.2154 
<http://www.colovore.com>

On Mon, Mar 23, 2015 at 1:36 PM, Endi Sukma Dewata
mailto:edew...@redhat.com>> wrote:

Thanks for the info. The transaction log doesn't indicate the
cause of the problem either. I might need to provide a custom
build that generates more useful information. Would you be able
to test that? Thanks.

--
Endi S. Dewata

- Original Message -
 > Endi,
 >
 > 1. I am currently using CentOS 6.5.
 >
 > 2. Below are the package versions.
 >
 > Former:
 > Don't have that information available
 >
 > Current:
 > pki-java-tools-9.0.3-38.el6_6.noarch
 > pki-silent-9.0.3-38.el6_6.noarch
 > ipa-pki-common-theme-9.0.3-7.el6.noarch
 > pki-ca-9.0.3-38.el6_6.noarch
 > pki-setup-9.0.3-38.el6_6.noarch
 > pki-native-tools-9.0.3-38.el6_6.x86_64
 > pki-util-9.0.3-38.el6_6.noarch
 > pki-selinux-9.0.3-38.el6_6.noarch
 > pki-common-9.0.3-38.el6_6.noarch
 > ipa-pki-ca-theme-9.0.3-7.el6.noarch
 > pki-symkey-9.0.3-38.el6_6.x86_64
 >
 > 3. Attached
 >
 > *Michael Pawlak*
 > Web Systems Administrator | Colovore LLC
 > E: m...@colovore.com <mailto:m...@colovore.com>
     > C: 408.316.2154 
 >   <http://www.colovore.com>
 >
 > On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata
mailto:edew...@redhat.com>>
 > wrote:
 > >
 > > Hi,
 > >
 > > Unfortunately the code doesn't log the exact cause of the
problem. I need
 > > some additional info:
 > >
 > > 1. Which platform are you using?
 > > 2. What are the versions of the pki-* packages before and
after upgrade?
 > > 3. Please provide the /etc/pki-ca/CS.cfg and
/var/log/pki-ca/transactions.
 > >
 > > Thanks.
 > >
 > > --
 > > Endi S. Dewata






--
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] Setup of freeipa 4.1.3 failed

[Endi Sukma Dewata]

On 4/1/2015 2:29 AM, Martin Kosek wrote:

On 03/31/2015 07:58 PM, Dmitri Pal wrote:

On 03/31/2015 01:54 PM, Markus Roth wrote:

Hi all,

I want setup freeipa 4.1.3 on a fresh installed fedora 21.
The ipa-server-install shows the following output:


...


Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30
seconds
[1/27]: creating certificate server user
[2/27]: configuring certificate server instance
[3/27]: stopping certificate server instance to update CS.cfg
[4/27]: backing up CS.cfg
[5/27]: disabling nonces
[6/27]: set up CRL publishing
[7/27]: enable PKIX certificate path discovery and validation
[8/27]: starting certificate server instance
[error] RuntimeError: CA did not start in 300.0s
CA did not start in 300.0s

The ipa server install log shows this:

2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
2015-03-31T17:39:35Z DEBUG Waiting for CA to start...


...


I uninstalled the ipa server completely several times and installed it again.
But it always stops at the same step with the setup.

Can anybody help?

Markus.


Please provide install logs, and look at directory server and PKI server logs
created during the installation.
It seems that Dogtag did not start. It usually does not start when the DS under
it does not start. The logs would show that.
DS does not start does because of different issues. Can bind to the port for
example. So please review the logs and see what they reveal.

This might help you with details http://www.freeipa.org/page/Troubleshooting


+1. CCing Dogtag guys for reference.


Based on the IPA install log alone it looks like the DS is already 
started, and the Dogtag is already started too in step [3/27]. It's the 
restart on step [8/27] that is failing.


We will need to see the Dogtag debug log in order to know if Dogtag is 
indeed failing to restart or the installer for some reason cannot 
connect to Dogtag.


--
Endi S. Dewata

--
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] Setup of freeipa 4.1.3 failed

[Endi Sukma Dewata]

On 4/1/2015 11:56 AM, Endi Sukma Dewata wrote:

On 03/31/2015 01:54 PM, Markus Roth wrote:

Hi all,

I want setup freeipa 4.1.3 on a fresh installed fedora 21.
The ipa-server-install shows the following output:


...


Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3
minutes 30
seconds
[1/27]: creating certificate server user
[2/27]: configuring certificate server instance
[3/27]: stopping certificate server instance to update CS.cfg
[4/27]: backing up CS.cfg
[5/27]: disabling nonces
[6/27]: set up CRL publishing
[7/27]: enable PKIX certificate path discovery and validation
[8/27]: starting certificate server instance
[error] RuntimeError: CA did not start in 300.0s
CA did not start in 300.0s

The ipa server install log shows this:

2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
2015-03-31T17:39:35Z DEBUG Waiting for CA to start...


...


I uninstalled the ipa server completely several times and installed
it again.
But it always stops at the same step with the setup.

Can anybody help?



Based on the IPA install log alone it looks like the DS is already
started, and the Dogtag is already started too in step [3/27]. It's the
restart on step [8/27] that is failing.

We will need to see the Dogtag debug log in order to know if Dogtag is
indeed failing to restart or the installer for some reason cannot
connect to Dogtag.


Hi Markus,

Based on the logs that you sent me, the Dogtag took a really long time 
to start:


  INFORMATION: Server startup in 739700 ms

More than half of that time was spent starting the CA subsystem alone:

  INFORMATION: Deployment of configuration descriptor /etc/pki
  /pki-tomcat/Catalina/localhost/ca.xml has finished in 393,390 ms

The whole (failed) IPA installation took about 38 minutes. Is this correct?

It's possible the system was running out of entropy. You might want to 
install haveged or rngd. See:

http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/
https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

However, the system seems to be running very slowly in general. How 
powerful is this machine?


--
Endi S. Dewata

--
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] Setup of freeipa 4.1.3 failed

[Endi Sukma Dewata]

On 4/1/2015 4:29 PM, Markus Roth wrote:

Am Mittwoch, 1. April 2015, 16:04:54 schrieben Sie:

On 4/1/2015 11:56 AM, Endi Sukma Dewata wrote:

On 03/31/2015 01:54 PM, Markus Roth wrote:

Hi all,

I want setup freeipa 4.1.3 on a fresh installed fedora 21.



The ipa-server-install shows the following output:

...


Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3
minutes 30
seconds

 [1/27]: creating certificate server user
 [2/27]: configuring certificate server instance
 [3/27]: stopping certificate server instance to update CS.cfg
 [4/27]: backing up CS.cfg
 [5/27]: disabling nonces
 [6/27]: set up CRL publishing
 [7/27]: enable PKIX certificate path discovery and validation
 [8/27]: starting certificate server instance
 [error] RuntimeError: CA did not start in 300.0s

CA did not start in 300.0s

The ipa server install log shows this:

2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted
2015-03-31T17:39:35Z DEBUG Waiting for CA to start...


...


I uninstalled the ipa server completely several times and installed
it again.
But it always stops at the same step with the setup.

Can anybody help?


Based on the IPA install log alone it looks like the DS is already
started, and the Dogtag is already started too in step [3/27]. It's the
restart on step [8/27] that is failing.

We will need to see the Dogtag debug log in order to know if Dogtag is
indeed failing to restart or the installer for some reason cannot
connect to Dogtag.


Hi Markus,

Based on the logs that you sent me, the Dogtag took a really long time
to start:

INFORMATION: Server startup in 739700 ms

More than half of that time was spent starting the CA subsystem alone:

INFORMATION: Deployment of configuration descriptor /etc/pki
/pki-tomcat/Catalina/localhost/ca.xml has finished in 393,390 ms

The whole (failed) IPA installation took about 38 minutes. Is this correct?

It's possible the system was running out of entropy. You might want to
install haveged or rngd. See:
http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/
https://www.digitalocean.com/community/tutorials/how-to-setup-additional-ent
ropy-for-cloud-servers-using-haveged

However, the system seems to be running very slowly in general. How
powerful is this machine?


Hi Endi

the system is a banana pi system. Seems that this ARM CPU based system isn't
suitable for FreeIPA


The installation might still succeed if IPA doesn't have the 300s time 
limit. If you want to try, you probably can specify a larger 
startup_timeout in ~/.ipa/default.conf, or change the code in 
ipaplatform/redhat/services.py to wait indefinitely, and see what 
happens. I don't know if it will be usable though.


--
Endi S. Dewata

--
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] ipa-server setup with external CA fails

[Endi Sukma Dewata]

On 3/11/2015 8:55 PM, Endi Sukma Dewata wrote:

On 3/11/2015 10:13 PM, Gould, Joshua wrote:

The selftests.log contradicts itself and I¹m not really sure where to
look
next. Any ideas?


There's an existing ticket about the confusing selftest messages:
https://fedorahosted.org/pki/ticket/1249

Could you post the full CA debug log (i.e.
/var/log/pki/pki-tomcat/ca/debug)? The error might have happened much
earlier. Thanks.



Hi, if this is still a problem please let us know.

--
Endi S. Dewata

--
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] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

[Endi Sukma Dewata]

On 5/12/2015 11:39 AM, Thibaut Pouzet wrote:

There is no more this weird "friendlyName :unable to print
attribute" thing, but the NoSuchTokenException is still in the debug log
of pki-ca


Hi,

Could you post or email me the CS.cfg and the log files of the CA? Thanks.

--
Endi S. Dewata

--
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] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

[Endi Sukma Dewata]

On 5/12/2015 1:11 PM, Nalin Dahyabhai wrote:

On Tue, May 12, 2015 at 06:39:13PM +0200, Thibaut Pouzet wrote:

There is no more this weird "friendlyName :unable to print
attribute" thing, but the NoSuchTokenException is still in the debug log
of pki-ca

Thank you for you answer though, we've still made some progress in
identifying that I messed the CA used for this certificate !


Hmm, so what you've got there looks pretty normal for a renewal request.
Just to rule out a problem with the request's signature or the encoding
of the subject name in the request (the latter is a bug in versions of
certmonger before 0.72), can you check the version of the certmonger
package and show us the base64-encoded form of the signing request?

I'm just about grasping at straws here, but the NoSuchTokenException
exception appears to be coming from the jss library, and is thrown when
it can't find the software module that is used for accessing the
server's keys.  Can you verify that your /etc/pki-ca/CS.cfg file
contains these lines?

   jss.configDir=/var/lib/pki-ca/alias/
   jss.enable=true
   jss.secmodName=secmod.db

Is there a ca.requestVerify.token value set in /etc/pki-ca/CS.cfg?  I
don't have one.  The Dogtag logic looks like it would try to use one set
there rather than the default, but letting it use the default looks like
the intended way of doing things.

Which version of the jss and tomcatjss packages are installed?  I'm
using jss-4.2.6-24.el6 and tomcatjss-2.1.0-3.el6 here.

If none of this turns up anything, then I'm going to have to defer to
the Dogtag team, too.

Nalin


I think you're on to something. The "Invalid Request" message is 
misleading. The actual error is NoSuchTokenException and it happens 
before the PKCS10 request is parsed. So yes, we need to check the 
ca.requestVerify.token parameter.


--
Endi S. Dewata

--
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] Certificate renewal issues for dogtag GUI (9443/9444/9445 ports)

[Endi Sukma Dewata]

On 5/19/2015 3:54 AM, Thibaut Pouzet wrote:

Hi,

It appeared that the NSS DB had fips enabled due to the troubleshooting
of an old problem :

# modutil -dbdir /var/lib/pki-ca/alias/ -list

Listing of PKCS #11 Modules
---
   1. NSS Internal FIPS PKCS #11 Module
  slots: 1 slot attached
 status: loaded

  slot: NSS FIPS 140-2 User Private Key Services
 token: NSS FIPS 140-2 Certificate DB
---

I disabled it : modutil -dbdir /var/lib/pki-ca/alias -fips false

And no longer have the stack trace in the debug logs while re-sumbitting
the certificate with certmonger.

This is a first step in this certificate renewal, as I still cannot
renew it, I have a new error :
 status: CA_UNREACHABLE
 ca-error: Error 60 connecting to
https://ipa_server:9443/ca/agent/ca/profileReview: Peer certificate
cannot be authenticated with known CA certificates.

This looks like a chicken and egg problem, the certificate served on
ipa_server:9443 is the one that needs to be renewed. I tried to step
back in time when the certificate was still valid with no luck.

So if anyone has an idea here...

Cheers,


Hi,

Is this still a problem? Per discussion with Rob it doesn't seem to be 
an issue with Dogtag itself.


I suppose you are following this instruction:
http://www.freeipa.org/page/Howto/CA_Certificate_Renewal

Could you post the full getcert list output? Also after you reset the 
clock back and try the renewal again could you post the error messages 
that you get?


Hopefully the IPA team will be able to troubleshoot further. Thanks.

--
Endi S. Dewata

--
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] Impossible to restart IPA because of the presence of a file called CS.cfg.bak.saved

[Endi Sukma Dewata]

On 7/12/2016 12:17 PM, bahan w wrote:

Hello everyone.

I'm using ipa 3.0.0-47 on a RHEL6.6 OS (multi-masters).

Today I tried to restart the IPA service with the commande
###
service ipa restart
###

And I got the following warning concerning the pkica service :
###
Since the file '/var/lib/pki-ca/conf/CS.cfg.bak.saved' exists, a
previous backup attempt has failed!  Backups will be discontinued until
this issue has been resolved!
###

And then the service get KO.

I wanted to know, may you tell me when this file CS.cfg.bak.saved is
created ?
Also, do you know why the presence of this file prevent the ipa service
to start ?

Thank you in advance for your help.

BR.

Bahan



Hi Bahan,

To my understanding during CS.cfg backup process the old CS.cfg.bak is 
temporarily saved into the CS.cfg.bak.saved. When the backup is complete 
the CS.cfg.bak.saved should be removed automatically.


In your case there might be something wrong in the CS.cfg that causes 
the backup to fail. Try comparing the CS.cfg with CS.cfg.bak.saved to 
see what has changed recently. If you find something wrong, shutdown the 
server, fix the CS.cfg, move CS.cfg.bak.saved somewhere else, then 
restart the server again.


Please also check if the disk is full.

If it's still not working please send the CA debug log 
(/var/log/pki-ca/debug) to pki-users mailing list or to RHEL support 
channel. Thanks.


--
Endi S. Dewata

--
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: Cannot add Centos7.2 replica to Centos6.8 ipa server

[Endi Sukma Dewata]

On 9/9/2016 8:09 AM, Petr Vobornik wrote:

On 09/09/2016 02:33 PM, Giorgos Kafataridis wrote:



Yes, I have followed
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

to the letter.
The only reason I had to recreate the cacert.p12 file is because it
is not
renewed automatically in v3, so the cacert.p12 was outdated and the
CA was
throwing an "p12 invalid digest" error.

   * I opened all necessary ports
   * I checked all certs and they are valid for another year


/Run connection check to master//
//Check connection from replica to remote master 'ipa-server.nelios'://
//   Directory Service: Unsecure port (389): OK//
//   Directory Service: Secure port (636): OK//
//   Kerberos KDC: TCP (88): OK//
//   Kerberos Kpasswd: TCP (464): OK//
//   HTTP Server: Unsecure port (80): OK//
//   HTTP Server: Secure port (443): OK//
//   PKI-CA: Directory Service port (7389): OK//
//
//The following list of ports use UDP protocol and would need to be//
//checked manually://
//   Kerberos KDC: UDP (88): SKIPPED//
//   Kerberos Kpasswd: UDP (464): SKIPPED//
//
//Connection from replica to master is OK.//
//Start listening on required ports for remote master check//
//Get credentials to log in to remote master//
//Check SSH connection to remote master//
//Execute check on remote master//
//Check connection from master to remote replica
'ipa2-server2.nelios'://
//   Directory Service: Unsecure port (389): OK//
//   Directory Service: Secure port (636): OK//
//   Kerberos KDC: TCP (88): OK//
//   Kerberos KDC: UDP (88): OK//
//   Kerberos Kpasswd: TCP (464): OK//
//   Kerberos Kpasswd: UDP (464): OK//
//   HTTP Server: Unsecure port (80): OK//
//   HTTP Server: Secure port (443): OK//
//
//Connection from master to replica is OK.//
//
//Connection check OK/

*Even with a fresh install of centos 7 with different hostname and ip
and I
still get the  the error below*

Configuring certificate server (pki-tomcatd). Estimated time: 3
minutes 30 seconds
[1/24]: creating certificate server user
[2/24]: configuring certificate server instance
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
configure CA
instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpbMwmp_''
returned non-zero exit status 1
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the
installation logs
and the following files/directories for more information:
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki-ca-install.log
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL
/var/log/pki/pki-tomcat
[error] RuntimeError: CA configuration failed.
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERRORCA
configuration failed.

*
**With debug enabled I get: *

pa : DEBUGStarting external process
ipa : DEBUGargs='/usr/sbin/pkispawn' '-s' 'CA' '-f'
'/tmp/tmpwY8XjR'
ipa : DEBUGProcess finished, return code=1
ipa : DEBUGstdout=Log file:
/var/log/pki/pki-ca-spawn.20160909044214.log
Loading deployment configuration from /tmp/tmpwY8XjR.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.

Installation failed.


ipa : DEBUG
stderr=/usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769:
InsecureRequestWarning: Unverified HTTPS request is being made. Adding
certificate verification is strongly advised. See:
https://urllib3.readthedocs.org/en/latest/security.html
InsecureRequestWarning)
pkispawn: WARNING  ... unable to validate security domain
user/password
through REST interface. Interface not available
pkispawn: ERROR... Exception from Java Configuration
Servlet: 500
Server Error: Internal Server Error
pkispawn: ERROR... ParseError: not well-formed (invalid
token): line
1, column 0:
{"Attributes":{"Attribute":[]},"ClassName":"com.netscape.certsrv.base.PKIException","Code":500,"Message":"Failed

to obtain installation token from security domain"}


Is there a way to validate the repilca .gpg file from a v3
installation against
a v4.2 freeipa installation to check for any errors before going
through the
ipa-replica-install?
The ipa-replica-install completes if I don't include the --setup-ca
flag but I
don't want that


There is no automatic method to verify the replica file.

Could you share the stack trace from /var/log/pki/pki-tomcat/ca/debug  +
couple lines before and after?




Contents  of /var/log/pki/pki-tomcat/ca/debug:

[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
SystemConfigResource.configure()
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
content-type: application/json
[09/Sep/2016:08:22:51][http-bio-8443-exec-3]: MessageFormatInterceptor:
accept: [application/json]
[09/Sep/2016

Re: [Freeipa-users] CA: Cannot add Centos7.2 replica to Centos6.8 ipa server

[Endi Sukma Dewata]

On 9/9/2016 2:46 PM, Georgios Kafataridis wrote:

I've tried that but still the same result.

[root@ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 389 -h
localhost -b "uid=admin,ou=people,o=ipaca"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object


Hi,

The master's logs indicate there's an authentication issue.

Could you search the whole directory to find the admin user?
$ ldapsearch ... -b "o=ipaca" "(uid=admin)"

Try also other suffixes that you have in the DS.

If you find it, try to authenticate against DS directly as the admin 
user. If the authentication fails, try resetting the password.


--
Endi S. Dewata

--
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: Cannot add Centos7.2 replica to Centos6.8 ipa server

[Endi Sukma Dewata]

On 9/12/2016 9:35 PM, Endi Sukma Dewata wrote:

On 9/9/2016 2:46 PM, Georgios Kafataridis wrote:

I've tried that but still the same result.

[root@ipa-server /]# ldapsearch -D "cn=directory manager" -W -p 389 -h
localhost -b "uid=admin,ou=people,o=ipaca"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object


Hi,

The master's logs indicate there's an authentication issue.

Could you search the whole directory to find the admin user?
$ ldapsearch ... -b "o=ipaca" "(uid=admin)"

Try also other suffixes that you have in the DS.

If you find it, try to authenticate against DS directly as the admin
user. If the authentication fails, try resetting the password.


I believe there is actually another DS instance on CentOS 6.8 running on 
port 7389, so make sure you check that too. If the admin user is indeed 
missing, it will need to be recreated, assigned a password and 
certificate, and added to the appropriate groups.


See also: http://pki.fedoraproject.org/wiki/IPA_PKI_Users

--
Endi S. Dewata

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

[Endi Sukma Dewata]

On 9/23/2014 6:35 PM, swartz wrote:

On 9/22/2014 7:59 PM, Ade Lee wrote:

If you scroll to the end of the CS.cfg, does it look like it has been
truncated?



I'd have to say no. It doesn't look truncated to me. At least there are
no obvious signs. But then again I don't know everything that is suppose
to be there. I know that the line starting  with
"pkicreate.unsecure_port=" isn't there, that's for sure. Hence why init
script fails to start PKI-CA.


Hi,

Ade and I looked at the file that you sent, and I sent you an updated 
CS.cfg based on my system (and you indicated that it's working now). I 
noticed that your original file contains the following line:


  cloning.ocsp_signing.dn=CN=OCSP Subsys

where it probably should have been something like this:

  cloning.ocsp_signing.dn=CN=OCSP Subsysstem,O=CS.MYDOMAIN.CA

Also, it's missing the next ~400 lines which seem to have been replaced 
with these lines:


  proxy.securePort=443
  proxy.unsecurePort=80

So we're suspecting that something was adding these proxy parameters 
directly to CS.cfg while the CA is saving configuration changes to 
CS.cfg too. Luckily your original CS.cfg still contains enough 
information to fully restore the file. I guess we need someone who's 
more familiar with the IPA & CA upgrade process to take a look at this 
more closely.


The CS.cfg is actually owned by the CA server, but sometimes people are 
advised to change the file directly, and maybe some codes are written 
that way too. There are some ways to avoid this kind of problems in the 
future:


1. Require CA to be shutdown before changing CS.cfg directly.
2. Prohibit direct access to the file and require the use of tools that 
send the changes to the CA server (e.g. via CLI/REST).
3. Break CS.cfg into user-owned and server-owned parameters, and move 
mostly-static parameters into a separate default file.

4. Replace CS.cfg with LDAP-based configuration.

In the short term we might be limited to #1, but in the long term we 
might be able to implement the other options.


--
Endi S. Dewata

--
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] Problems and questions installing Identity Manager on RHEL V7

[Endi Sukma Dewata]

On 10/1/2014 12:46 PM, Alexander Bokovoy wrote:

On Wed, 01 Oct 2014, Licause, Al (CSC AMS BCS - UNIX/Linux Network
Support) wrote:



I have tried to deinstall and reinstall the ipa server but the
installation is now failing.


The ipa-server-install is failing with the following:

 [37/38]: tuning directory server
 [38/38]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
 [1/22]: creating certificate server user
 [2/22]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpLb1CmI' returned non-zero exit
status 1
Configuration of CA failed

This happens each time I try to uninstall and reinstall the ipa server
on RHEL V7.


Looking at the latest log in /var/log/pki, I see this at the end of
the log:

2014-10-01 11:53:10 pkispawn: INFO BEGIN spawning subsystem
'CA' of instance 'pki-tomcat' . . .
2014-10-01 11:53:10 pkispawn: INFO ... initializing
'pki.deployment.initialization'
2014-10-01 11:53:10 pkispawn: ERROR... PKI subsystem 'CA'
for instance 'pki-tomcat' already exists!
2014-10-01 11:53:10 pkispawn: DEBUG... Error Type: SystemExit
2014-10-01 11:53:10 pkispawn: DEBUG... Error Message: 1
2014-10-01 11:53:10 pkispawn: DEBUG...   File
"/usr/sbin/pkispawn", line 374, in main
   rv = instance.spawn()
 File
"/usr/lib/python2.7/site-packages/pki/deployment/initialization.py",
line 56, in spawn
   util.instance.verify_subsystem_does_not_exist()
 File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py",
line 990, in verify_subsystem_does_not_exist
   sys.exit(1)

I am no python expert by any means and I'm not sure what this is
telling us so any help
would be greatly appreciated.



This issue is known -- when CA install fails, we rollback but since CA
isn't installed, we miss rolling it back. There is a ticket for
eventually fixing this issue.


Which ticket is this? The rollback was actually disabled to allow 
troubleshooting the failed installation:

https://fedorahosted.org/freeipa/ticket/3990


Following sequence should clean up all the bits:

pkidestroy -s CA -i pki-tomcat
rm -rf /var/log/pki/pki-tomcat
rm -rf /etc/sysconfig/pki-tomcat
rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
rm -rf /var/lib/pki/pki-tomcat
rm -rf /etc/pki/pki-tomcat


It's not official, but we call this step pki-nuke.


It also helps to reboot between multiple reinstalls on a single machine.


Rather than rolling back the installation automatically (and delete all 
files needed to troubleshoot the problem), it would be better to provide 
an option to the uninstall command to forcibly remove all installed 
files regardless whether the installation was successful or not, just 
like the pki-nuke above.


--
Endi S. Dewata

--
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] Problems and questions installing Identity Manager on RHEL V7

[Endi Sukma Dewata]

On 10/3/2014 2:30 AM, Alexander Bokovoy wrote:

This issue is known -- when CA install fails, we rollback but since CA
isn't installed, we miss rolling it back. There is a ticket for
eventually fixing this issue.


Which ticket is this? The rollback was actually disabled to allow
troubleshooting the failed installation:
https://fedorahosted.org/freeipa/ticket/3990



I think this ticket is unrelated -- its solution only affects
ipa-client-install --on-master, not what ipa-server-install does when it
rolls back configuration for dirsrv and other servers.


I think the idea can be expanded to the entire server installation.


I can't find the exact ticket though.


Following sequence should clean up all the bits:

pkidestroy -s CA -i pki-tomcat
rm -rf /var/log/pki/pki-tomcat
rm -rf /etc/sysconfig/pki-tomcat
rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
rm -rf /var/lib/pki/pki-tomcat
rm -rf /etc/pki/pki-tomcat


It's not official, but we call this step pki-nuke.


It also helps to reboot between multiple reinstalls on a single machine.


Rather than rolling back the installation automatically (and delete
all files needed to troubleshoot the problem), it would be better to
provide an option to the uninstall command to forcibly remove all
installed files regardless whether the installation was successful or
not, just like the pki-nuke above.



We simply have no information about the fact what pkicreate did before
it failed.


It shouldn't matter. The forced removal should clean up anything that 
might have been created during the installation. That way the next 
installation should be able to run without any possibility of conflicts 
with residual files.


I created this Dogtag ticket:
https://fedorahosted.org/pki/ticket/1172

When that's implemented, the IPA uninstall script can do this:

  try:
  # forcibly remove Dogtag instance
  pkidestroy -i pki-tomcat
  except Exception:
  # ignore error
  pass

  try:
  # forcibly remove DS instance
  remove-ds.pl -f -i slapd-pki-tomcat
  except Exception:
  # ignore error
  pass

  ... and so on ...

If we use an automatic rollback, in addition to the lost debugging info, 
sometimes the rollback itself can be buggy so the machine is left in an 
inconsistent/unusable state. With a separate forced removal like above, 
we can debug the failed installation, and also debug the failed removal 
if necessary.


--
Endi S. Dewata

--
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] Trouble installing F21 4.1.2 replica from F20 3.3.5 master

[Endi Sukma Dewata]

On 1/5/2015 8:53 PM, Martin Kosek wrote:

On 01/05/2015 02:05 PM, Anthony Messina wrote:

I was hoping to "migrate" from F20 to F21 using:
http://www.freeipa.org/page/Howto/Migration
http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master


The migration procedure is only needed if you run FreeIPA server with PKI based
on Dogtag (pki-ca package) 9. Do you? Is your Fedora 20 FreeIPA&PKI instance
functional? FreeIPA+Dogtag 9 is not supported since Fedora 18, so I was
surprised such setup worked in Fedora 20.


I don't use Dogtag 9.  I installed FreeIPA freshly on a F19 VM, then yum
upgraded to F20.  With the significant changes for Fedora.next, systemd-216,
and FreeIPA 4, I wanted to create a new "master" (amd retire the old) by
replicating the current F20 3.3.5 master to what would become an F21 4.1.2 
master.


Ah, makes more sense then. The PKI error below gets more serious then - Fraser
and Endi, please help Anthony.


I'm discussing this with Ade (CC'd). Based on the stack trace it looks 
like the replica thinks the master returns an incomplete information 
about the security domain, probably due to the different Dogtag versions 
used in master and replica.


We need some additional info:

1. What is the pki-ca version on the master (F20)?
2. What is the pki-ca version on the replica (F21)?
3. What is the output of this URL on the master?
   https://:8443/ca/rest/securityDomain/domainInfo

Thanks.

--
Endi S. Dewata

--
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] Trouble installing F21 4.1.2 replica from F20 3.3.5 master

[Endi Sukma Dewata]

On 1/6/2015 4:55 AM, Anthony Messina wrote:

I'm discussing this with Ade (CC'd). Based on the stack trace it looks
like the replica thinks the master returns an incomplete information
about the security domain, probably due to the different Dogtag versions
used in master and replica.

We need some additional info:

1. What is the pki-ca version on the master (F20)?


pki-ca-10.1.2-7.fc20.noarch


2. What is the pki-ca version on the replica (F21)?


pki-ca-10.2.0-5.fc21.noarch


3. What is the output of this URL on the master?
 https://:8443/ca/rest/securityDomain/domainInfo




   
 
   FALSE
   TRUE
   ipa1.example.com
   80
   443
   443
   443
   443
   CA ipa1.example.com 8443
 
 
   TRUE
   TRUE
   ipa2.example.com
   80
   443
   443
   443
   443
   CA ipa2.example.com 8443
 
   



Thanks for the info. This is indeed a bug. I filed the following ticket 
for Dogtag:

https://fedorahosted.org/pki/ticket/1235

--
Endi S. Dewata

--
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] Redhat/Centos iDM 3.0 to 3.1 upgrade fail

[Endi Sukma Dewata]

Hi,

I need some information from you. Which versions of the PKI packages 
that you are using on the CentOS 6.6 and 7.0 machines? Could you email 
me the PKI CA debug logs (/var/log/pki-ca/debug or 
/var/log/pki/pki-tomcat/ca/debug) from both machines?


There's a possibility it may be related to this ticket:
https://fedorahosted.org/pki/ticket/1235

Thanks.

--
Endi S. Dewata

On 1/13/2015 7:59 PM, Jim Richard wrote:

Carefully following the instructions here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html

I have split one of my Centis 6.6 based replicas from the main cluster
of 4 IDM servers, fully disconnected it from current IDM infrastructure,
converted it to a master CA, double checked that I have no
dangling/tombstone entries pointing back to other cluster members,
ipa-replica-manage list and ipa-replica-manage list-ruv both show no
other masters, in short, made absolutely sure that this replica is now a
standalone.

I then applied the schema updates via the python script per the above
referenced instructions, did “ipa-replica-prepare”, deployed a new
Centos 7 vm, yum install ipa-server there, scp’d over the replica file.

Next up, "ipa-replica-install --setup-ca”.

And that’s where the story ends…..

Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
   [1/19]: creating certificate server user
   [2/19]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpM9BzPz' returned non-zero exit status 1

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

Configuration of CA failed


I tried the workaround mentioned here:

https://fedorahosted.org/pki/ticket/816

updated /usr/share/pki/ca/conf/CS.cfg before running ipa-replica-install

But not luck.

Anybody have a clue where I should look?

From pki-ca-spawn.20150114014019.log:
2015-01-14 01:40:32 pkispawn: ERROR... Exception from Java
Configuration Servlet: Failed to obtain installation token from security
domain

and in /var/log/pki/pki-tomcat/ca/server I have:

2754.localhost-startStop-1 - [14/Jan/2015:01:40:29 UTC] [3] [3] Cannot
build CA chain. Error java.security.cert.CertificateException:
Certificate is not a PKCS #11 certificate
2754.localhost-startStop-1 - [14/Jan/2015:01:40:29 UTC] [13] [3] authz
instance DirAclAuthz initialization failed and skipped, error=Property
internaldb.ldapconn.port missing value


more info that might help…….


[root@sso-centos7 pki]# certutil -L -d /var/lib/pki/pki-tomcat/alias

Certificate Nickname Trust
Attributes

  SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca  CTu,Cu,Cu
Certificate Authority - PLACEIQ.NET 
  CT,c,

My CS.cfg is attached.



Maybe the fact that my new server is looking at the same DNS and can see
the SRV records for the current Centos 6.6/IDM 3.0 cluster is causing a
problem ??

Of course I have uninstalled and done this a zillion times:

pkidestroy -s CA -i pki-tomcat
rm -rf /var/log/pki/pki-tomcat
rm -rf /etc/sysconfig/pki-tomcat
rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat
rm -rf /var/lib/pki/pki-tomcat
rm -rf /etc/pki/pki-tomcat


I’m at a loss, no idea even where to look at this point.


Thanks in advance for any clues you can provide.








Jim Richard  | PlaceIQ

  |
  Systems Administrator  |  jrich...@placeiq.com
  | +1 (646) 338-8905








--
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] bug in pki during install of CA replica and workaround/solution

[Endi Sukma Dewata]

On 2/6/2015 8:39 AM, Martin Kosek wrote:

Reinstalling the pki-selinux rpm (found references in some other forum posts) 
via yum reinstall pki-selinux is not enough to help.

The solution is as follows:

yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools 
pki-symkey pki-util pki-native-tools
which takes components back to 9.0.3-32
then
yum -y update  pki-selinux pki-ca pki-common pki-setup pki-silent 
pki-java-tools pki-symkey pki-util pki-native-tools
then (after cleaning up half installed pki components)
ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg

Then, the CA replication completes successfully.

Regards,

Les


I saw this one around, e.g. in:

http://www.redhat.com/archives/freeipa-devel/2014-May/msg00507.html

Did you try reinstalling pki-selinux before ipa-server-install?

Endi/Matthew, do we have a bug/fix for this?

Thanks,
Martin



Yes, we have a ticket for this:
https://fedorahosted.org/pki/ticket/1243
The default selinux-policy is version 3.7.19-231. It needs to be updated 
to at least version 3.7.19-260.


--
Endi S. Dewata

--
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] ipa-getcert list fails to report correctly - RESOLVED

[Endi Sukma Dewata]

On 2/25/2015 6:35 PM, Martin Kosek wrote:

yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools 
pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client 
ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 
389-ds-base-libs
userdel pkisrv
userdel pkiuser


This should not be needed at all, AFAIK.


This may not be related to this problem, but sometimes reinstalling the 
packages is necessary to resolve installation problem. For example:

https://fedorahosted.org/freeipa/ticket/4591
In this ticket reinstalling 389-ds-base will recreate the missing folder.

--
Endi S. Dewata

--
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] ipa-getcert list fails to report correctly - RESOLVED

[Endi Sukma Dewata]

On 2/26/2015 8:02 AM, Les Stott wrote:

rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger
/etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid
/usr/share/pki /etc/ipa /var/log/ipa* reboot

Now you have a clean slate.


Do you know which step of the steps above actually helped you resolve the
reinstall issue?



The reboot I think was key to the whole process, but pki remnants seemed left 
behind too which caused grief. Previously I had never rebooted the system in 
between uninstall/reinstall.

/etc/ipa/ca.crt was also left behind. It caused an issue during one reinstall 
as it never got updated and the install bombed out because it found a 
mismatched cert. This led me to deleting all possible ipa/pki directories and 
then removing/reinstalling rpms to restore to default state.

I noticed that in some cases (I went through this same process on 6 servers to reinstall 
and setup CA replicas) I could still see a left over process running as the pkiuser 
(tomcat/java) which stopped the "userdel pkiuser" command from completing. I 
had to kill that process and then userdel pkiuser worked.


Some of the above files/folders should have been removed automatically 
when the Dogtag instance/package is removed. There's already a ticket to 
improve this on Dogtag 10:

https://fedorahosted.org/pki/ticket/1172

I created a new ticket for Dogtag 9:
https://fedorahosted.org/pki/ticket/1280

Thanks!

--
Endi S. Dewata

--
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] Unable to Install IPA

[Endi Sukma Dewata]

On 2/28/2015 1:01 PM, Hadoop Solutions wrote:

Hi Rob,

please find the attached log of /var/log/ipaserver-install.log

kindly let me know the solution for this..

Thanks,
Shaik


Hi,

I see this near the bottom of the ipaserver-install.log.

#
Attempting to connect to: sv2lxdpdsedi02.corp.equinix.com:9445
Connected.
Posting Query = 
https://sv2lxdpdsedi02.corp.equinix.com:9445//ca/admin/console/config/wizard?p=9&op=next&xml=true&host=sv2lxdpdsedi02.corp.equinix.com&port=7389&binddn=cn%3DDirectory+Manager&__bindpwd=&basedn=o%3Dipaca&database=ipaca&display=%24displayStr

RESPONSE STATUS:  HTTP/1.1 404 Not Found
RESPONSE HEADER:  Server: Apache-Coyote/1.1
RESPONSE HEADER:  Content-Type: text/html;charset=UTF-8
RESPONSE HEADER:  Date: Sat, 28 Feb 2015 05:57:35 GMT
RESPONSE HEADER:  Connection: close
ERROR: unable to parse xml
ERROR XML =
ERROR: Tag='updateStatus' has no values
Error in LdapConnectionPanel(): updateStatus value is null
ERROR: ConfigureCA: LdapConnectionPanel() failure
ERROR: unable to create CA

###

2015-02-28T05:57:35Z 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(xerces-j2-2.7.1.jar.so)
   at 
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(xerces-j2-2.7.1.jar.so)

   at javax.xml.parsers.DocumentBuilder.parse(libgcj.so.10)
   at ParseXML.parse(ParseXML.java:258)
   at ConfigureCA.getStatus(ConfigureCA.java:205)
   at ConfigureCA.checkStatus(ConfigureCA.java:221)
   at ConfigureCA.checkStatus(ConfigureCA.java:216)
   at ConfigureCA.LdapConnectionPanel(ConfigureCA.java:510)
   at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1225)
   at ConfigureCA.main(ConfigureCA.java:1672)

Could you post the /var/log/pki-ca/debug? Thanks.

--
Endi S. Dewata

--
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] ipa-server setup with external CA fails

[Endi Sukma Dewata]

On 3/11/2015 10:13 PM, Gould, Joshua wrote:

The selftests.log contradicts itself and I¹m not really sure where to look
next. Any ideas?


There's an existing ticket about the confusing selftest messages:
https://fedorahosted.org/pki/ticket/1249

Could you post the full CA debug log (i.e. 
/var/log/pki/pki-tomcat/ca/debug)? The error might have happened much 
earlier. Thanks.


--
Endi S. Dewata

--
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] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Endi Sukma Dewata]

Hi,

If you're cloning from an IPA running on RHEL/CentOS 6 with CA signed by 
another CA you are likely hitting this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1291747

The bug has been fixed in this package: pki-ca-9.0.3-45. You'll need to install 
it on the master, then restart the server, then try cloning again.

The latest PKI available on RHEL/CentOS 7 is version 10.2.5, but it's patched 
with relevant bug fixes from newer versions.

If you're still having a problem, try enabling the debug log on the master and 
clone by setting the following property in CS.cfg:
debug.level=1

See also: http://pki.fedoraproject.org/wiki/PKI_Server_Logs

--
Endi S. Dewata

- Original Message -
> Hi Martin
> 
> I am happy to provide the necessary information. What packages should i check
> for? As for IPA we are IPA CA being signed with other CA
> 
> Thank You
> 
> On Wed, Jan 27, 2016 at 2:24 AM, Martin Kosek < mko...@redhat.com > wrote:
> 
> 
> On 01/26/2016 09:45 PM, Ash Alam wrote:
> > I didnt want to dig up an old thread but i am running into this issue. The
> > old thread points to Pki 10.2.6 as the solution but i am not seeing that
> > package on centos 7.2.
> > 
> > STDERR: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to
> > configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f'
> > '/tmp/tmpHfdvFD'' returned non-zero exit status 1
> 
> CCing David and Endi, they might have an idea what is wrong. There were
> several
> recent fixes, to again fix RHEL-6 to RHEL-7 migration, we would need to check
> if you have them installed. As for your RHEL-6 IPA setup, is it running with
> External CA, i.e. IPA CA with being signed with other CA?
> 
> > 
> > On Tue, Jan 26, 2016 at 12:14 PM, Ash Alam < aa...@paperlesspost.com >
> > wrote:
> > 
> >> thank you! Out of curiosity has anyone been able to automate this using
> >> chef/puppet etc?
> >> 
> >> On Tue, Jan 26, 2016 at 10:56 AM, Martin Kosek < mko...@redhat.com >
> >> wrote:
> >> 
> >>> Did you follow the instructions in the error message? There is also a
> >>> longer
> >>> description here:
> >>> 
> >>> 
> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html#migrating-ipa-proc
> >>> 
> >>> Martin
> >>> 
> >>> On 01/26/2016 04:38 PM, Ash Alam wrote:
>  I wanted to follow up on this as i finally gotten around to doing the
>  upgrade. I an running into this error. I also found a bugzilla ticket.
> >>> Do
>  you have to do some type of schema upgrade like you do with active
>  directory?
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1235766
>  
>  STDERR: ipa : CRITICAL The master CA directory server does
> >>> not
>  have necessary schema. Please copy the following script to all CA
> >>> masters
>  and run it on them: /usr/share/ipa/copy-schema-to-ca.py
>  
>  If you are certain that this is a false positive, use
>  --skip-schema-check.
>  
>  ipa.ipapython.install.cli.install_tool(Replica): ERROR IPA schema
>  missing on master CA directory server
>  
>  
>  
>  Thank You
>  
>  
>  
>  
>  On Fri, Nov 20, 2015 at 11:13 AM, Martin Kosek < mko...@redhat.com >
> >>> wrote:
>  
> > On 11/20/2015 04:08 PM, Ash Alam wrote:
> > 
> >> Most of the clients in my env are centos 6.6 with ipa 3.0.0 client
> >> installed. I
> >> if bring up a replica on centos 7.2 with ipa 4.2.3 server and then
> >>> start
> >> phasing out the older 3.0.0 servers. Will the client that are still
> >> running the
> >> older client software still work?
> >> 
> > 
> > It should, yes. It is expected that there are RHEL/CentOS-6 clients
> >>> with
> > RHEL-7 FreeIPA servers. The older clients just won't be able to use the
> > newest features.
> > 
> > 
> >> On Fri, Nov 20, 2015 at 4:31 AM, Martin Kosek < mko...@redhat.com
> >> > wrote:
> >> 
> >> On 11/19/2015 11:03 PM, Ash Alam wrote:
> >> 
> >> Hello All
> >> 
> >> I am looking for some advice on upgrading. Currently our
> >>> FreeIPA
> >> servers are
> >> 3.0.0 on centos 6.6. We are looking to go to 4.2.3 Centos7.
> >>> This
> >> upgrade path
> >> is not possible per IPA documentation. Minimum version
> >>> required
> >> is 3.3.x. I
> >> have also found that cenos6 does not provide anything past
> >>> 3.0.0.
> >> 
> >> 
> >> And it won't. There are no plans in updating FreeIPA version in
> >> RHEL/CentOS-6.x, we encourage people who want the new features to
> >> migrate
> >> to RHEL-7.x:
> >> 
> >> 
> >> 
> >>> http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS
> >> 
> >> 
> >> 
> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Poli

Re: [Freeipa-users] Upgrading from 3.0.0 CentOS6 to 4.2.3 CentOS7

[Endi Sukma Dewata]

On 1/28/2016 2:45 PM, Endi Sukma Dewata wrote:

Hi,

If you're cloning from an IPA running on RHEL/CentOS 6 with CA signed by 
another CA you are likely hitting this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1291747

The bug has been fixed in this package: pki-ca-9.0.3-45. You'll need to install 
it on the master, then restart the server, then try cloning again.

The latest PKI available on RHEL/CentOS 7 is version 10.2.5, but it's patched 
with relevant bug fixes from newer versions.

If you're still having a problem, try enabling the debug log on the master and 
clone by setting the following property in CS.cfg:
debug.level=1

See also: http://pki.fedoraproject.org/wiki/PKI_Server_Logs

--
Endi S. Dewata


Just a note, I believe the fix is already available on CentOS 6:
http://mirror.centos.org/centos/6.7/updates/x86_64/Packages/

--
Endi S. Dewata

--
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] IPA 4.2: pki-tomcatd in terrible shape

[Endi Sukma Dewata]

On 3/28/2016 10:00 AM, Rob Crittenden wrote:

Timothy Geier wrote:

Thanks for the procedure..the good news is this worked quite well in
making sure that 389 didn’t crash immediately after startup.  The bad
news is that the certificates still didn’t renew due to

Server at "http://master_server:8080/ca/ee/ca/profileSubmit
"

replied: Profile caServerCert Not Found

which was the same error in getcert list I saw that one time 389
didn’t crash right away.  At least now this can be further
troubleshooted without worrying about 389.




To follow up on this issue, we haven’t been able to get any further
since last month due to the missing caServerCert profile..the
configuration files /usr/share/pki/ca/profiles/ca/caServerCert.cfg
and /var/lib/pki/pki-tomcat/ca/profiles/ca/caServerCert.cfg are present
and are identical.   The pki-ca package
passes rpm -V as well.   Are there any other troubleshooting steps we
can take?


Maybe Endi or Ade have some ideas why the CA isn't recognizing the profile.

rob



Fraser, is it possible the profile is missing from LDAP?

Timothy, could you provide us with the CA debug logs 
(/var/log/pki/pki-tomcat/ca/debug) and CA configuration file 
(/var/lib/pki/pki-tomcat/ca/conf/CS.cfg)?


Thanks!

--
Endi S. Dewata

--
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] Optionistic approach for new DNS API

[Endi Sukma Dewata]

On 12/14/2011 3:41 PM, Martin Kosek wrote:

ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0
ipa dnsrecord-del ZONE NAME --type=mx --preference=0 
--exchanger=server1.example.com.


I think the mod & del commands should use the same way to specify the 
existing data.


If we use the raw data, it should be specified as an option instead of 
an argument:


  ipa dnsrecord-mod ZONE NAME --type=mx \
--rec-data="10 server1.example.com." --new-preference=20

  ipa dnsrecord-del ZONE NAME --type=mx \
--rec-data="10 server1.example.com."

Alternatively we can use separate option for each parameter:

  ipa dnsrecord-mod ZONE NAME --type=mx \
--preference=10 --exchanger=server1.example.com. \
--new-preference=0

  ipa dnsrecord-del ZONE NAME --type=mx \
--preference=10 --exchanger=server1.example.com.

Or we can support both.


- SHOW and FIND commands do not need this new --type parameter


We can also add --types to specify the record types we want to get back 
in the result. This could be useful in case we want to refresh a certain 
table only in the record details page. Low priority.


BTW, I'd rather use --rec-type instead of just --type because 'type' 
seems to be more generic. In case a certain DNS record type also has a 
'type' parameter, it might conflict with that. Another possibility is to 
use a prefix for all type-specific options, e.g. --mx-preference.



- ADD command:
   - when no option is passed to dnsrecord-add command, it may ask for
--type and then for the options specific for the particular type
- MOD command:
   - when no option is passed to dnsrecord-mod command, it may provide a
list of current DNS record values and ask for specific DNS record parts
to be changed for chosen value
- DEL command:
   - when no option is passed to dnsrecord-del command, it may provide a
list of current DNS record values remove the chosen value


For consistency the mod & del commands can also ask for the type, then 
show the list of records in that type. This way the list can be shown in 
a nicely formatted table rather than just raw data.


--
Endi S. Dewata

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Optionistic approach for new DNS API

[Endi Sukma Dewata]

On 12/15/2011 4:03 PM, Martin Kosek wrote:

If we use the raw data, it should be specified as an option instead of
an argument:

ipa dnsrecord-mod ZONE NAME --type=mx \
  --rec-data="10 server1.example.com." --new-preference=20


I was also thinking about using current param "--mx-rec":

 ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \
   --mx-preference=20

But this would be a misuse and unexpected behavior. A new option would
be better for that.


I'm OK with either options. The help doc describes the --mx-rec option 
as a "comma-separated list of MX records". It doesn't say how the 
parameter should be used. We could say the mod command can be used in 2 
different modes.


In the first mode (the original) the command modifies the entire record 
object and the ---rec is used to specify the new records.


In the second mode the command modifies a record specified in the 
---rec. It also syntactically means we could perform the same 
modification against several records at once, although I'm not sure if 
it makes sense:


  ipa dnsrecord-mod ZONE NAME \
--mx-rec="10 server1.example.com.,10 server2.example.com."
--mx-preference=20


Current command can do that:
 ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com."
We have this behavior for free.


This is probably another reason to use the same --mx-rec option in mod.


Alternatively we can use separate option for each parameter:

ipa dnsrecord-mod ZONE NAME --type=mx \
  --preference=10 --exchanger=server1.example.com. \
  --new-preference=0

ipa dnsrecord-del ZONE NAME --type=mx \
  --preference=10 --exchanger=server1.example.com.

Or we can support both.


I think I would implement the first option first. We can extend if we
see it is useful. My point is that I don't think use would bother
constructing structured DNS record from its options in dnsrecord-del/mod
(fill --preference and --exchanger) but rather copy&paste raw DNS value
or use the interactive mode.


It might be useful for someone writing an application using the CLI. 
This way we don't need to know the order of the parameters.


It's a low priority, but we should plan what parameter names we're going 
to use in the future. If now we use --mx-preference to specify the new 
value, later when we implement the new mechanism we will need to use 
something like --mx-old-preference to specify the old value. I'd rather 
use --mx-new-preference for the new value.



- SHOW and FIND commands do not need this new --type parameter


We can also add --types to specify the record types we want to get back
in the result. This could be useful in case we want to refresh a certain
table only in the record details page. Low priority.


Ok, noted as an idea for enhancement. I would rather like to create a
functional minimalistic API first and add all the bells and whistles
later when we see it is useful.


OK.


BTW, I'd rather use --rec-type instead of just --type because 'type'
seems to be more generic. In case a certain DNS record type also has a
'type' parameter, it might conflict with that. Another possibility is to
use a prefix for all type-specific options, e.g. --mx-preference.


Actually, I was discussing this with Honza today. The problem is that we
can't add conflicting options to one command (e.g. --preference for MX
record and --preference for KX record). We would have to use
--mx-preference and --kx-preference anyway.


It probably depends on how it's actually implemented. I suppose it's 
possible to keep a separate list of options for each type-specific 
command, then merge the lists for the main dnsrecord-add/mod/del command 
while removing duplicates. But using prefix is OK too.



This would also remove the necessity to use --rec-type at all. I think
we could detect the type from the options that were passed. I.e. when
the following command is passed:

ipa dnsrecord-add ZONE NAME --mx-preference=0 
--mx-exchanger=server1.example.com.

We know that MX record is being created.


Without the --rec-type, it's syntactically possible to add/mod/del 
multiple RR types at once. I'm not sure if we want to support that:


  ipa dnsrecord-mod ZONE NAME \
--mx-preference=0 --mx-exchanger=server1.example.com \
--mx-new-preference=1
--kx-preference=0 --kx-exchanger=server1.example.com \
--kx-exchanger=server2.example.com


- ADD command:
- when no option is passed to dnsrecord-add command, it may ask for
--type and then for the options specific for the particular type
- MOD command:
- when no option is passed to dnsrecord-mod command, it may provide a
list of current DNS record values and ask for specific DNS record parts
to be changed for chosen value
- DEL command:
- when no option is passed to dnsrecord-del command, it may provide a
list of current DNS record values remove the chosen value


For consistency the mod&  del commands can also ask for the type, then
show the list of records in that type