subject:"\[Freeipa\-users\] Failed to start pki\-tomcatd Service"

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-09-17 Thread Alexandre Ellert

My FreeIPA  PKI is totally broken since upgrade from 3.0 (RHEL 6.6) to 4.1
(RHEL 7.1)
This thread started on July and still no resolution... Can someone please
advice ?
-- 
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] Failed to start pki-tomcatd Service

2015-09-15 Thread Alexandre Ellert

So, here is the recap :
I migrate a single IPA server Centos 6.6 to dual IP server Centos 7.1. The
PKI was only installed on server two.
Everything was working fine, replication OK, new enrollements OK,
authentication with Kerberos and LDAP OK.
After some time, I discover that pki tomcatd service didn't restart
automatically after reboot on server two.

Now I want to repair things, but I can't deploy a new PKI and I can't
delete the existing broken PKI...

Maybe I should use ipa-backup and then rebuilt an IPA infrastructure and
then ipa-restore ?

Please advice.


2015-09-07 13:36 GMT+02:00 Alexandre Ellert :

>
> > Le 4 sept. 2015 à 16:37, Martin Babinsky  a écrit :
> >
> > On 08/28/2015 05:46 PM, Alexandre Ellert wrote:
> >>
> >>> Le 28 août 2015 à 17:41, Alexander Bokovoy  a
> écrit :
> >>>
> >>> On Fri, 28 Aug 2015, Alexandre Ellert wrote:
> 
> > Le 28 août 2015 à 17:09, Alexander Bokovoy  a
> écrit :
> >
> > On Wed, 26 Aug 2015, Alexandre Ellert wrote:
> >>
> >>> Le 28 juil. 2015 à 05:59, Alexander Bokovoy 
> a écrit :
>  If the problem is too hard to solve, maybe I should try to deploy
> another
>  replica ?
> >>> You may try that. Sorry for not responding, I have some other
> tasks that
> >>> occupy my time right now.
> >>>
> >>
> >>
> >> Can you please tell me the procedure to decommission and re-create
> a new replica ?
> >> Are "ipa-server-install —uninstall" then "ipa-server-install" the
> only things to do ?
> > No, you need also to remove the server from the replication topology.
> >
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html
> >
> > --
> > / Alexander Bokovoy
> 
>  I can’t remove the node on which I have problem with pki-tomcatd :
> 
>  # ipa-replica-manage del .example.com
>  Deleting a master is irreversible.
>  To reconnect to the remote master you will need to prepare a new
> replica file
>  and re-install.
>  Continue to delete? [no]: yes
>  Deleting this server is not allowed as it would leave your
> installation without a CA
> 
>  I seem that it’s the only node where CA is installed. What should I
> do now ?
> >>> Add a replica with CA using ipa-ca-install on existing replica.
> >>>
> >>> Read the guide, it has detailed coverage of these situations.
> >>> --
> >>> / Alexander Bokovoy
> >>
> >> On the first node (which is working and without pki-tomcatd service)
> >> # ipa-ca-install
> >> Directory Manager (existing master) password:
> >>
> >> CA is already installed.
> >>
> >> How is it possible ?
> >>
> >>
> > You must provide a replica file as an argument to ipa-ca-install if you
> want to setup CA on another replica.
> >
> > --
> > Martin^3 Babinsky
>
> I’m still stuck with the correct command line :
> [root@inf-ipa ~]# ipa-ca-install
> /var/lib/ipa/replica-info-inf-ipa.numeezy.fr.gpg
> Directory Manager (existing master) password:
>
> Run connection check to master
> Check connection from replica to remote master 'inf-ipa-2.numeezy.fr':
>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
>
> 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
> ad...@numeezy.fr password:
>
> Check SSH connection to remote master
> Execute check on remote master
> Check connection from master to remote replica 'inf-ipa.numeezy.fr':
>Directory Service: Unsecure port (389): OK
>Directory Service: Secure port (636): OK
>Kerberos KDC: TCP (88): OK
>Kerberos KDC: UDP (88): WARNING
>Kerberos Kpasswd: TCP (464): OK
>Kerberos Kpasswd: UDP (464): WARNING
>HTTP Server: Unsecure port (80): OK
>HTTP Server: Secure port (443): OK
> The following UDP ports could not be verified as open: 88, 464
> This can happen if they are already bound to an application
> and ipa-replica-conncheck cannot attach own UDP responder.
>
> Connection from master to replica is OK.
>
> Connection check OK
> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30
> seconds
>   [1/21]: creating certificate server user
>   [2/21]: configuring certificate server instance
> ipa : CRITICAL failed to configure ca instance Command
> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp_KIouo'' returned non-zero
> exit status 1
>   [error] RuntimeError: Configuration of CA failed
>
> Your

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-09-15 Thread Steven Jones

Hi,

I am in a similar boat, well RHEL6.7 to RHEL7.1.  I joined a RHEL7.1 / IPA4.1 
to the 6.7 / IPA3.0 --self-cert domain, got rid of all the 6.7's so I was 
ca-less.  Did a full backup on the RHEL7.1 / IPA 4.1.  Blew away the ipa 
server, installed fresh, pki-tomcat runs, did a restore and pki-tomcat doesnt 
run.

btw what does --data do?  I tried that before a full restore and no passwords 
worked ie i could not login and no users worked at all, so it seems pointless? 
or maybe rather what is it for? and when to use it?

regards

Steven

From: freeipa-users-boun...@redhat.com <freeipa-users-boun...@redhat.com> on 
behalf of Alexandre Ellert <ellertalexan...@gmail.com>
Sent: Wednesday, 16 September 2015 12:09 a.m.
To: Martin Babinsky
Cc: freeipa-users@redhat.com; Alexander Bokovoy
Subject: Re: [Freeipa-users] Failed to start pki-tomcatd Service

So, here is the recap :
I migrate a single IPA server Centos 6.6 to dual IP server Centos 7.1. The PKI 
was only installed on server two.
Everything was working fine, replication OK, new enrollements OK, 
authentication with Kerberos and LDAP OK.
After some time, I discover that pki tomcatd service didn't restart 
automatically after reboot on server two.

Now I want to repair things, but I can't deploy a new PKI and I can't delete 
the existing broken PKI...

Maybe I should use ipa-backup and then rebuilt an IPA infrastructure and then 
ipa-restore ?

Please advice.

2015-09-07 13:36 GMT+02:00 Alexandre Ellert 
<ellertalexan...@gmail.com<mailto:ellertalexan...@gmail.com>>:

> Le 4 sept. 2015 à 16:37, Martin Babinsky 
> <mbabi...@redhat.com<mailto:mbabi...@redhat.com>> a écrit :
>
> On 08/28/2015 05:46 PM, Alexandre Ellert wrote:
>>
>>> Le 28 août 2015 à 17:41, Alexander Bokovoy 
>>> <aboko...@redhat.com<mailto:aboko...@redhat.com>> a écrit :
>>>
>>> On Fri, 28 Aug 2015, Alexandre Ellert wrote:
>>>>
>>>>> Le 28 août 2015 à 17:09, Alexander Bokovoy 
>>>>> <aboko...@redhat.com<mailto:aboko...@redhat.com>> a écrit :
>>>>>
>>>>> On Wed, 26 Aug 2015, Alexandre Ellert wrote:
>>>>>>
>>>>>>> Le 28 juil. 2015 à 05:59, Alexander Bokovoy 
>>>>>>> <aboko...@redhat.com<mailto:aboko...@redhat.com>> a écrit :
>>>>>>>> If the problem is too hard to solve, maybe I should try to deploy 
>>>>>>>> another
>>>>>>>> replica ?
>>>>>>> You may try that. Sorry for not responding, I have some other tasks that
>>>>>>> occupy my time right now.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Can you please tell me the procedure to decommission and re-create a new 
>>>>>> replica ?
>>>>>> Are "ipa-server-install —uninstall" then "ipa-server-install" the only 
>>>>>> things to do ?
>>>>> No, you need also to remove the server from the replication topology.
>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html
>>>>>
>>>>> --
>>>>> / Alexander Bokovoy
>>>>
>>>> I can’t remove the node on which I have problem with pki-tomcatd :
>>>>
>>>> # ipa-replica-manage del .example.com<http://.example.com>
>>>> Deleting a master is irreversible.
>>>> To reconnect to the remote master you will need to prepare a new replica 
>>>> file
>>>> and re-install.
>>>> Continue to delete? [no]: yes
>>>> Deleting this server is not allowed as it would leave your installation 
>>>> without a CA
>>>>
>>>> I seem that it’s the only node where CA is installed. What should I do now 
>>>> ?
>>> Add a replica with CA using ipa-ca-install on existing replica.
>>>
>>> Read the guide, it has detailed coverage of these situations.
>>> --
>>> / Alexander Bokovoy
>>
>> On the first node (which is working and without pki-tomcatd service)
>> # ipa-ca-install
>> Directory Manager (existing master) password:
>>
>> CA is already installed.
>>
>> How is it possible ?
>>
>>
> You must provide a replica file as an argument to ipa-ca-install if you want 
> to setup CA on another replica.
>
> --
> Martin^3 Babinsky

I’m still stuck with the correct command line :
[root@inf-ipa ~]# ipa-ca-install 
/var/lib/ipa/replica-info-inf-ipa

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-09-07 Thread Alexandre Ellert


> Le 4 sept. 2015 à 16:37, Martin Babinsky  a écrit :
> 
> On 08/28/2015 05:46 PM, Alexandre Ellert wrote:
>> 
>>> Le 28 août 2015 à 17:41, Alexander Bokovoy  a écrit :
>>> 
>>> On Fri, 28 Aug 2015, Alexandre Ellert wrote:
 
> Le 28 août 2015 à 17:09, Alexander Bokovoy  a écrit :
> 
> On Wed, 26 Aug 2015, Alexandre Ellert wrote:
>> 
>>> Le 28 juil. 2015 à 05:59, Alexander Bokovoy  a 
>>> écrit :
 If the problem is too hard to solve, maybe I should try to deploy 
 another
 replica ?
>>> You may try that. Sorry for not responding, I have some other tasks that
>>> occupy my time right now.
>>> 
>> 
>> 
>> Can you please tell me the procedure to decommission and re-create a new 
>> replica ?
>> Are "ipa-server-install —uninstall" then "ipa-server-install" the only 
>> things to do ?
> No, you need also to remove the server from the replication topology.
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html
> 
> --
> / Alexander Bokovoy
 
 I can’t remove the node on which I have problem with pki-tomcatd :
 
 # ipa-replica-manage del .example.com
 Deleting a master is irreversible.
 To reconnect to the remote master you will need to prepare a new replica 
 file
 and re-install.
 Continue to delete? [no]: yes
 Deleting this server is not allowed as it would leave your installation 
 without a CA
 
 I seem that it’s the only node where CA is installed. What should I do now 
 ?
>>> Add a replica with CA using ipa-ca-install on existing replica.
>>> 
>>> Read the guide, it has detailed coverage of these situations.
>>> --
>>> / Alexander Bokovoy
>> 
>> On the first node (which is working and without pki-tomcatd service)
>> # ipa-ca-install
>> Directory Manager (existing master) password:
>> 
>> CA is already installed.
>> 
>> How is it possible ?
>> 
>> 
> You must provide a replica file as an argument to ipa-ca-install if you want 
> to setup CA on another replica.
> 
> -- 
> Martin^3 Babinsky

I’m still stuck with the correct command line :
[root@inf-ipa ~]# ipa-ca-install 
/var/lib/ipa/replica-info-inf-ipa.numeezy.fr.gpg 
Directory Manager (existing master) password: 

Run connection check to master
Check connection from replica to remote master 'inf-ipa-2.numeezy.fr':
   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

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
ad...@numeezy.fr password: 

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'inf-ipa.numeezy.fr':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): WARNING
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): WARNING
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK
The following UDP ports could not be verified as open: 88, 464
This can happen if they are already bound to an application
and ipa-replica-conncheck cannot attach own UDP responder.

Connection from master to replica is OK.

Connection check OK
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 
seconds
  [1/21]: creating certificate server user
  [2/21]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command 
''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmp_KIouo'' returned non-zero exit 
status 1
  [error] RuntimeError: Configuration of CA failed

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

Configuration of CA failed


-- 
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] Failed to start pki-tomcatd Service

2015-09-04 Thread Martin Babinsky

On 08/28/2015 05:46 PM, Alexandre Ellert wrote:

Le 28 août 2015 à 17:41, Alexander Bokovoy a écrit :

On Fri, 28 Aug 2015, Alexandre Ellert wrote:

Le 28 août 2015 à 17:09, Alexander Bokovoy a écrit :

On Wed, 26 Aug 2015, Alexandre Ellert wrote:

Le 28 juil. 2015 à 05:59, Alexander Bokovoy a écrit :

If the problem is too hard to solve, maybe I should try to deploy another
replica ?

You may try that. Sorry for not responding, I have some other tasks that
occupy my time right now.

Can you please tell me the procedure to decommission and re-create a new
replica ?
Are "ipa-server-install —uninstall" then "ipa-server-install" the only things
to do ?

No, you need also to remove the server from the replication topology.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html

--
/ Alexander Bokovoy

I can’t remove the node on which I have problem with pki-tomcatd :

# ipa-replica-manage del .example.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica file
and re-install.
Continue to delete? [no]: yes
Deleting this server is not allowed as it would leave your installation without
a CA

I seem that it’s the only node where CA is installed. What should I do now ?

Add a replica with CA using ipa-ca-install on existing replica.

Read the guide, it has detailed coverage of these situations.
--
/ Alexander Bokovoy

On the first node (which is working and without pki-tomcatd service)
# ipa-ca-install
Directory Manager (existing master) password:

CA is already installed.

How is it possible ?

You must provide a replica file as an argument to ipa-ca-install if you
want to setup CA on another replica.

--
Martin^3 Babinsky

--
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] Failed to start pki-tomcatd Service

2015-08-28 Thread Alexandre Ellert

Le 28 août 2015 à 17:41, Alexander Bokovoy aboko...@redhat.com a écrit :

On Fri, 28 Aug 2015, Alexandre Ellert wrote:

Le 28 août 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit :

On Wed, 26 Aug 2015, Alexandre Ellert wrote:

Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit
:
If the problem is too hard to solve, maybe I should try to deploy another
replica ?
You may try that. Sorry for not responding, I have some other tasks that
occupy my time right now.

Can you please tell me the procedure to decommission and re-create a new
replica ?
Are ipa-server-install —uninstall then ipa-server-install the only
things to do ?
No, you need also to remove the server from the replication topology.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html

--
/ Alexander Bokovoy

I can’t remove the node on which I have problem with pki-tomcatd :

I seem that it’s the only node where CA is installed. What should I do now ?
Add a replica with CA using ipa-ca-install on existing replica.

Read the guide, it has detailed coverage of these situations.
--
/ Alexander Bokovoy

On the first node (which is working and without pki-tomcatd service)
# ipa-ca-install
Directory Manager (existing master) password:

CA is already installed.

How is it possible ?

--
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] Failed to start pki-tomcatd Service

2015-08-28 Thread Alexander Bokovoy


On Wed, 26 Aug 2015, Alexandre Ellert wrote:



Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit :

If the problem is too hard to solve, maybe I should try to deploy another
replica ?

You may try that. Sorry for not responding, I have some other tasks that
occupy my time right now.




Can you please tell me the procedure to decommission and re-create a new 
replica ?
Are ipa-server-install —uninstall then ipa-server-install the only things 
to do ?

No, you need also to remove the server from the replication topology.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html

--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-08-28 Thread Alexandre Ellert


 Le 28 août 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Wed, 26 Aug 2015, Alexandre Ellert wrote:
 
 Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit :
 If the problem is too hard to solve, maybe I should try to deploy another
 replica ?
 You may try that. Sorry for not responding, I have some other tasks that
 occupy my time right now.
 
 
 
 Can you please tell me the procedure to decommission and re-create a new 
 replica ?
 Are ipa-server-install —uninstall then ipa-server-install the only 
 things to do ?
 No, you need also to remove the server from the replication topology.
 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/removing-replica.html
 
 -- 
 / Alexander Bokovoy

I can’t remove the node on which I have problem with pki-tomcatd :

# ipa-replica-manage del .example.com
Deleting a master is irreversible.
To reconnect to the remote master you will need to prepare a new replica file
and re-install.
Continue to delete? [no]: yes
Deleting this server is not allowed as it would leave your installation without 
a CA

I seem that it’s the only node where CA is installed. What should I do now ?

Thank you again for your support.

-- 
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] Failed to start pki-tomcatd Service

2015-08-28 Thread Alexander Bokovoy

On Fri, 28 Aug 2015, Alexandre Ellert wrote:

Le 28 août 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit :

On Wed, 26 Aug 2015, Alexandre Ellert wrote:

Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit :

If the problem is too hard to solve, maybe I should try to deploy another
replica ?

You may try that. Sorry for not responding, I have some other tasks that
occupy my time right now.

Can you please tell me the procedure to decommission and re-create a new
replica ?
Are ipa-server-install —uninstall then ipa-server-install the only things
to do ?

--
/ Alexander Bokovoy

I can’t remove the node on which I have problem with pki-tomcatd :

I seem that it’s the only node where CA is installed. What should I do now ?

Add a replica with CA using ipa-ca-install on existing replica.

Read the guide, it has detailed coverage of these situations.
--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-08-26 Thread Alexandre Ellert


 Le 28 juil. 2015 à 05:59, Alexander Bokovoy aboko...@redhat.com a écrit :
 If the problem is too hard to solve, maybe I should try to deploy another
 replica ?
 You may try that. Sorry for not responding, I have some other tasks that
 occupy my time right now.
 


Can you please tell me the procedure to decommission and re-create a new 
replica ?
Are ipa-server-install —uninstall then ipa-server-install the only things 
to do ?

Thank you

Alexandre-- 
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] Failed to start pki-tomcatd Service

2015-07-27 Thread Alexander Bokovoy


On Sun, 26 Jul 2015, Alexandre Ellert wrote:

2015-07-23 8:41 GMT+02:00 Alexander Bokovoy aboko...@redhat.com:


On Thu, 23 Jul 2015, Ludwig Krispenz wrote:


- Directory server starts just fine but serves only port 389

- krb5kdc starts just fine and works fine with LDAP server
- Dogtag tries to use LDAP server via port 636 and fails

We need to see why port 636 is disabled.


why do you think so ? There is:

[22/Jul/2015:18:14:54 +0200] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[22/Jul/2015:18:14:54 +0200] - Listening on All Interfaces port 636 for
LDAPS requests
[22/Jul/2015:18:14:54 +0200] - Listening on
/var/run/slapd-NUMEEZY-FR.socket for LDAPI requests


Missed that part. However, dogtag was failing in accessing LDAP over
port 636.

 but what is failing is:

agmt=cn=cloneAgreement1-inf-ipa-2.numeezy.fr-pki-tomcat (inf-ipa:7389):
Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP
server) ()

Is dogtag on a different instance ? why do we use port 7389 ?


Because it was migration from RHEL6 to RHEL7. In RHEL6 dogtag was living
in a separate instance.


If the problem is too hard to solve, maybe I should try to deploy another
replica ?

You may try that. Sorry for not responding, I have some other tasks that
occupy my time right now.

If you have Red Hat subscription, it would be good to open a support
case and put the details of the migration and logs there.
--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-26 Thread Alexandre Ellert

2015-07-23 8:41 GMT+02:00 Alexander Bokovoy aboko...@redhat.com:

 On Thu, 23 Jul 2015, Ludwig Krispenz wrote:

 - Directory server starts just fine but serves only port 389
 - krb5kdc starts just fine and works fine with LDAP server
 - Dogtag tries to use LDAP server via port 636 and fails

 We need to see why port 636 is disabled.

 why do you think so ? There is:

 [22/Jul/2015:18:14:54 +0200] - slapd started.  Listening on All
 Interfaces port 389 for LDAP requests
 [22/Jul/2015:18:14:54 +0200] - Listening on All Interfaces port 636 for
 LDAPS requests
 [22/Jul/2015:18:14:54 +0200] - Listening on
 /var/run/slapd-NUMEEZY-FR.socket for LDAPI requests

 Missed that part. However, dogtag was failing in accessing LDAP over
 port 636.

  but what is failing is:
 agmt=cn=cloneAgreement1-inf-ipa-2.numeezy.fr-pki-tomcat (inf-ipa:7389):
 Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP
 server) ()

 Is dogtag on a different instance ? why do we use port 7389 ?

 Because it was migration from RHEL6 to RHEL7. In RHEL6 dogtag was living
 in a separate instance.

 --
 / Alexander Bokovoy


If the problem is too hard to solve, maybe I should try to deploy another
replica ?
-- 
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] Failed to start pki-tomcatd Service

2015-07-23 Thread Ludwig Krispenz



On 07/22/2015 06:40 PM, Alexander Bokovoy wrote:

On Wed, 22 Jul 2015, Alexandre Ellert wrote:


Le 22 juil. 2015 à 18:08, Alexander Bokovoy aboko...@redhat.com a 
écrit :


On Wed, 22 Jul 2015, Alexandre Ellert wrote:

# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
from both servers?


Server 1:
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )


Server 2 :
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )




With correct setup IPA 4.x should show:
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-EXAMPLE-COM/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )


I.e. there are two lines -- in the default schema and in the IPA
instance schema. —


Seems to be good ?

Yes. Can you get a new set of logs on 'ipactl start'?

--
/ Alexander Bokovoy


Sorry, the log is very long…I can format differently if you need.

Thanks, no need for more logs right now.

What I see from these logs:
- Directory server starts just fine but serves only port 389
- krb5kdc starts just fine and works fine with LDAP server
- Dogtag tries to use LDAP server via port 636 and fails

We need to see why port 636 is disabled.

why do you think so ? There is:

[22/Jul/2015:18:14:54 +0200] - slapd started.  Listening on All Interfaces port 
389 for LDAP requests
[22/Jul/2015:18:14:54 +0200] - Listening on All Interfaces port 636 for LDAPS 
requests
[22/Jul/2015:18:14:54 +0200] - Listening on /var/run/slapd-NUMEEZY-FR.socket 
for LDAPI requests

but what is failing is:
agmt=cn=cloneAgreement1-inf-ipa-2.numeezy.fr-pki-tomcat (inf-ipa:7389): 
Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ()

Is dogtag on a different instance ? why do we use port 7389 ?



Can you grep /etc/dirsrv/slapd-NUMEEZY-FR/dse.ldif for following
attributes:
nsslapd-security
nsslapd-port

They should be 'on' and '389' correspondingly.



--
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] Failed to start pki-tomcatd Service

2015-07-23 Thread Alexander Bokovoy


On Thu, 23 Jul 2015, Ludwig Krispenz wrote:

- Directory server starts just fine but serves only port 389
- krb5kdc starts just fine and works fine with LDAP server
- Dogtag tries to use LDAP server via port 636 and fails

We need to see why port 636 is disabled.

why do you think so ? There is:

[22/Jul/2015:18:14:54 +0200] - slapd started.  Listening on All Interfaces port 
389 for LDAP requests
[22/Jul/2015:18:14:54 +0200] - Listening on All Interfaces port 636 for LDAPS 
requests
[22/Jul/2015:18:14:54 +0200] - Listening on /var/run/slapd-NUMEEZY-FR.socket 
for LDAPI requests

Missed that part. However, dogtag was failing in accessing LDAP over
port 636.


but what is failing is:
agmt=cn=cloneAgreement1-inf-ipa-2.numeezy.fr-pki-tomcat (inf-ipa:7389): 
Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ()

Is dogtag on a different instance ? why do we use port 7389 ?

Because it was migration from RHEL6 to RHEL7. In RHEL6 dogtag was living
in a separate instance.

--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexandre Ellert


 Le 22 juil. 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Wed, 22 Jul 2015, Alexandre Ellert wrote:
 
 Le 20 juil. 2015 à 17:17, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Mon, 20 Jul 2015, Alexandre Ellert wrote:
 
 Can you please show output from
 fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema
 
 # fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema
 
 This is original 'dc' definition:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 This is the offending one:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
 
 In 00core.ldif, I have :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' 
 )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent' )
 If you look into 99user.ldif, you'll see the wrong definition there.
 
 99user.ldif accumulates definitions coming from replication or updates.
 You can check other IPA masters, do they have 'dc' attribute defined in
 a wrong way?
 
 I have a second IPA master and here is the occurence of ‘ domaincomponent' 
 in /etc/dirsrv/slapd-NUMEEZY-FR/schema :
 In 00core.ldif :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent’ )
 In 99user.ldif :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) 
 D
 ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn
 oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORI
 GIN ( 'RFC 2247' 'user defined' ) )
 
 This two definition are exactly the same on both IPA masters.
 
 I don’t understand what is wrong in 99user.ldif ? How can I correct with the 
 good definition ?
 The correct definition is in the 00core.ldif. The one in 99user.ldif is
 wrong.
 
 I think you can remove it from 99user.ldif on both servers but you need
 to shut down dirsrv instances on both to do that.
 -- 
 / Alexander Bokovoy

I shut down IPA on both servers (ipactl stop) and removed this section in 
99user.ldif :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
  ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn
  oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORI
  GIN ( 'RFC 2247' 'user defined' ) )

But still have the same behavior (pki-tomcatd don’t start, same errors in 
logs). Do you have another idea ?

Thanks for your support

-- 
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexander Bokovoy


On Wed, 22 Jul 2015, Alexandre Ellert wrote:

# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
from both servers?


Server 1:
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

Server 2 :
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )



With correct setup IPA 4.x should show:
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-EXAMPLE-COM/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

I.e. there are two lines -- in the default schema and in the IPA
instance schema. —


Seems to be good ?

Yes. Can you get a new set of logs on 'ipactl start'?

--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexander Bokovoy


On Wed, 22 Jul 2015, Alexandre Ellert wrote:



Le 20 juil. 2015 à 17:17, Alexander Bokovoy aboko...@redhat.com a écrit :

On Mon, 20 Jul 2015, Alexandre Ellert wrote:



Can you please show output from
fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema


# fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema


This is original 'dc' definition:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )


This is the offending one:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D



In 00core.ldif, I have :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE
X-ORIGIN 'RFC 4519'
X-DEPRECATED 'domaincomponent' )

If you look into 99user.ldif, you'll see the wrong definition there.

99user.ldif accumulates definitions coming from replication or updates.
You can check other IPA masters, do they have 'dc' attribute defined in
a wrong way?


I have a second IPA master and here is the occurence of ‘ domaincomponent' in 
/etc/dirsrv/slapd-NUMEEZY-FR/schema :
In 00core.ldif :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent’ )
In 99user.ldif :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn
oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORI
GIN ( 'RFC 2247' 'user defined' ) )

This two definition are exactly the same on both IPA masters.

I don’t understand what is wrong in 99user.ldif ? How can I correct with the 
good definition ?

The correct definition is in the 00core.ldif. The one in 99user.ldif is
wrong.

I think you can remove it from 99user.ldif on both servers but you need
to shut down dirsrv instances on both to do that.
--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexandre Ellert


 Le 22 juil. 2015 à 17:43, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Wed, 22 Jul 2015, Alexandre Ellert wrote:
 
 Le 22 juil. 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Wed, 22 Jul 2015, Alexandre Ellert wrote:
 
 Le 20 juil. 2015 à 17:17, Alexander Bokovoy aboko...@redhat.com a écrit 
 :
 
 On Mon, 20 Jul 2015, Alexandre Ellert wrote:
 
 Can you please show output from
 fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema
 
 # fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema
 
 This is original 'dc' definition:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 This is the offending one:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
 
 In 00core.ldif, I have :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 
 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent' )
 If you look into 99user.ldif, you'll see the wrong definition there.
 
 99user.ldif accumulates definitions coming from replication or updates.
 You can check other IPA masters, do they have 'dc' attribute defined in
 a wrong way?
 
 I have a second IPA master and here is the occurence of ‘ domaincomponent' 
 in /etc/dirsrv/slapd-NUMEEZY-FR/schema :
 In 00core.ldif :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' 
 )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent’ )
 In 99user.ldif :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' 
 ) D
 ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR 
 caseIgn
 oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE 
 X-ORI
 GIN ( 'RFC 2247' 'user defined' ) )
 
 This two definition are exactly the same on both IPA masters.
 
 I don’t understand what is wrong in 99user.ldif ? How can I correct with 
 the good definition ?
 The correct definition is in the 00core.ldif. The one in 99user.ldif is
 wrong.
 
 I think you can remove it from 99user.ldif on both servers but you need
 to shut down dirsrv instances on both to do that.
 --
 / Alexander Bokovoy
 
 I shut down IPA on both servers (ipactl stop) and removed this section in 
 99user.ldif :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' 
 ) D
 ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR 
 caseIgn
 oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE 
 X-ORI
 GIN ( 'RFC 2247' 'user defined' ) )
 
 But still have the same behavior (pki-tomcatd don’t start, same errors
 in logs). Do you have another idea ?
 We need to find out where the definition comes from.
 
 Can you give me output of
 # fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
 from both servers?

Server 1:
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

Server 2 :
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

 
 With correct setup IPA 4.x should show:
 /etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
 NAME ( 'dc' 'domaincomponent' )
 /etc/dirsrv/slapd-EXAMPLE-COM/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 I.e. there are two lines -- in the default schema and in the IPA
 instance schema. — 

Seems to be good ?


-- 
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexander Bokovoy


On Wed, 22 Jul 2015, Alexandre Ellert wrote:



Le 22 juil. 2015 à 17:09, Alexander Bokovoy aboko...@redhat.com a écrit :

On Wed, 22 Jul 2015, Alexandre Ellert wrote:



Le 20 juil. 2015 à 17:17, Alexander Bokovoy aboko...@redhat.com a écrit :

On Mon, 20 Jul 2015, Alexandre Ellert wrote:



Can you please show output from
fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema


# fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema


This is original 'dc' definition:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )


This is the offending one:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D



In 00core.ldif, I have :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE
X-ORIGIN 'RFC 4519'
X-DEPRECATED 'domaincomponent' )

If you look into 99user.ldif, you'll see the wrong definition there.

99user.ldif accumulates definitions coming from replication or updates.
You can check other IPA masters, do they have 'dc' attribute defined in
a wrong way?


I have a second IPA master and here is the occurence of ‘ domaincomponent' in 
/etc/dirsrv/slapd-NUMEEZY-FR/schema :
In 00core.ldif :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE
X-ORIGIN 'RFC 4519'
X-DEPRECATED 'domaincomponent’ )
In 99user.ldif :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn
oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORI
GIN ( 'RFC 2247' 'user defined' ) )

This two definition are exactly the same on both IPA masters.

I don’t understand what is wrong in 99user.ldif ? How can I correct with the 
good definition ?

The correct definition is in the 00core.ldif. The one in 99user.ldif is
wrong.

I think you can remove it from 99user.ldif on both servers but you need
to shut down dirsrv instances on both to do that.
--
/ Alexander Bokovoy


I shut down IPA on both servers (ipactl stop) and removed this section in 
99user.ldif :

attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
 ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn
 oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORI
 GIN ( 'RFC 2247' 'user defined' ) )


But still have the same behavior (pki-tomcatd don’t start, same errors
in logs). Do you have another idea ?

We need to find out where the definition comes from.

Can you give me output of
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
from both servers?

With correct setup IPA 4.x should show:
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-EXAMPLE-COM/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

I.e. there are two lines -- in the default schema and in the IPA
instance schema. 
--

/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexander Bokovoy


On Wed, 22 Jul 2015, Alexandre Ellert wrote:



Le 22 juil. 2015 à 18:08, Alexander Bokovoy aboko...@redhat.com a écrit :

On Wed, 22 Jul 2015, Alexandre Ellert wrote:

# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
from both servers?


Server 1:
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

Server 2 :
# fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )



With correct setup IPA 4.x should show:
/etc/dirsrv/schema/00core.ldif:attributeTypes: ( 0.9.2342.19200300.100.1.25 
NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-EXAMPLE-COM/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )

I.e. there are two lines -- in the default schema and in the IPA
instance schema. —


Seems to be good ?

Yes. Can you get a new set of logs on 'ipactl start'?

--
/ Alexander Bokovoy


Sorry, the log is very long…I can format differently if you need.

Thanks, no need for more logs right now.

What I see from these logs:
- Directory server starts just fine but serves only port 389
- krb5kdc starts just fine and works fine with LDAP server
- Dogtag tries to use LDAP server via port 636 and fails

We need to see why port 636 is disabled.

Can you grep /etc/dirsrv/slapd-NUMEEZY-FR/dse.ldif for following
attributes:
nsslapd-security
nsslapd-port

They should be 'on' and '389' correspondingly.

--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexandre Ellert


 Le 22 juil. 2015 à 18:40, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Wed, 22 Jul 2015, Alexandre Ellert wrote:
 
 Le 22 juil. 2015 à 18:08, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Wed, 22 Jul 2015, Alexandre Ellert wrote:
 # fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
 from both servers?
 
 Server 1:
 # fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
 /etc/dirsrv/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 Server 2 :
 # fgrep -r 0.9.2342.19200300.100.1.25 /etc/dirsrv
 /etc/dirsrv/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 
 With correct setup IPA 4.x should show:
 /etc/dirsrv/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 /etc/dirsrv/slapd-EXAMPLE-COM/schema/00core.ldif:attributeTypes: ( 
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 I.e. there are two lines -- in the default schema and in the IPA
 instance schema. —
 
 Seems to be good ?
 Yes. Can you get a new set of logs on 'ipactl start'?
 
 --
 / Alexander Bokovoy
 
 Sorry, the log is very long…I can format differently if you need.
 Thanks, no need for more logs right now.
 
 What I see from these logs:
 - Directory server starts just fine but serves only port 389
 - krb5kdc starts just fine and works fine with LDAP server
 - Dogtag tries to use LDAP server via port 636 and fails
 
 We need to see why port 636 is disabled.
 
 Can you grep /etc/dirsrv/slapd-NUMEEZY-FR/dse.ldif for following
 attributes:
 nsslapd-security
 nsslapd-port
 
 They should be 'on' and '389' correspondingly.
 
 -- 
 / Alexander Bokovoy

Here is the result (on both servers)
# grep nsslapd-security /etc/dirsrv/slapd-NUMEEZY-FR/dse.ldif 
nsslapd-security: on
# grep nsslapd-port /etc/dirsrv/slapd-NUMEEZY-FR/dse.ldif 
nsslapd-port: 389

Notice that ns-slapd is listening on port 636 :
# netstat -antp|grep '636\|389'|grep LISTEN
tcp6   0  0 :::389  :::*LISTEN  
12271/ns-slapd  
tcp6   0  0 :::636  :::*LISTEN  
12271/ns-slapd


-- 
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] Failed to start pki-tomcatd Service

2015-07-22 Thread Alexandre Ellert


 Le 20 juil. 2015 à 17:17, Alexander Bokovoy aboko...@redhat.com a écrit :
 
 On Mon, 20 Jul 2015, Alexandre Ellert wrote:
 
 Can you please show output from
 fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema
 
 # fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema
 
 This is original 'dc' definition:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 This is the offending one:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
 
 In 00core.ldif, I have :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent' )
 If you look into 99user.ldif, you'll see the wrong definition there.
 
 99user.ldif accumulates definitions coming from replication or updates.
 You can check other IPA masters, do they have 'dc' attribute defined in
 a wrong way?

I have a second IPA master and here is the occurence of ‘ domaincomponent' in 
/etc/dirsrv/slapd-NUMEEZY-FR/schema :
In 00core.ldif :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  SINGLE-VALUE
  X-ORIGIN 'RFC 4519'
  X-DEPRECATED 'domaincomponent’ )
In 99user.ldif :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
 ESC 'Standard LDAP attribute type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgn
 oreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORI
 GIN ( 'RFC 2247' 'user defined' ) )

This two definition are exactly the same on both IPA masters.

I don’t understand what is wrong in 99user.ldif ? How can I correct with the 
good definition ?

 
 As far as I remember, the only modification I made was to disable
 read-only access without authentication.  I don’t need any other
 special customization.
 Something brought the wrong definition into your IPA masters.
 May be someone tried to add support for some old application?

Nobody else never have access read/write to the IPA servers. I’m the only admin.


-- 
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] Failed to start pki-tomcatd Service

2015-07-20 Thread Alexandre Ellert


 Can you please show output from
 fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema

# fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:objectClasses: ( 
1.3.6.1.4.1.1466.344 NAME 'dcObject'
/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:  MUST dc
/etc/dirsrv/slapd-NUMEEZY-FR/schema/05rfc4524.ldif:  MUST dc
/etc/dirsrv/slapd-NUMEEZY-FR/schema/50ns-mail.ldif:attributeTypes: ( 
2.16.840.1.113730.3.1.22 NAME ( 'mgrpAllowedBroadcaster' ) DESC 'Netscape 
Messaging Server 4.x defined attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26  
X-ORIGIN 'Netscape Messaging Server 4.x' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/50ns-mail.ldif:attributeTypes: ( 
2.16.840.1.113730.3.1.788 NAME ( 'mgrpBroadcasterPolicy' ) DESC 'Netscape 
Messaging Server 4.x defined attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15  
X-ORIGIN 'Netscape Messaging Server 4.x' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/50ns-mail.ldif:objectclasses: ( 
2.16.840.1.113730.3.2.4 NAME 'mailGroup' DESC 'Netscape Messaging Server 4.x 
defined objectclass' SUP top AUXILIARY MUST ( objectClass ) MAY ( cn $ mail $ 
mailAlternateAddress $ mailHost $ mailRoutingAddress $ mgrpAddHeader $ 
mgrpAllowedBroadcaster $ mgrpAllowedDomain $ mgrpApprovePassword $ 
mgrpBroadcasterPolicy $ mgrpDeliverTo $ mgrpErrorsTo $ mgrpModerator $ 
mgrpMsgMaxSize $ mgrpMsgRejectAction $ mgrpMsgRejectText $ 
mgrpNoDuplicateChecks $ mgrpRemoveHeader $ mgrpRFC822MailMember $ owner ) 
X-ORIGIN 'Netscape Messaging Server 4.x' )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60trust.ldif:# 
dc=com?sub?objectclass=posixAccount)(|(trustmodel=fullaccess)(accessto=server)
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:objectClasses: ( 
1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST d
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif: UST dc MAY ( userPassword $ 
searchGuide $ seeAlso $ businessCategory $ x121Ad
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif: dBroadcaster $ 
mgrpAllowedDomain $ mgrpApprovePassword $ mgrpBroadcasterPolic
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif: bTicketPolicyReference $ 
krbKdcServers $ krbPwdServers $ krbAdmServers $ krbP
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:objectClasses: ( 
2.16.840.1.113719.1.301.6.4.1 NAME 'krbKdcService' SUP krbSer
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: ( 
2.16.840.1.113719.1.301.4.17.1 NAME 'krbKdcServers'  EQUALIT
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: ( 
2.16.840.1.113730.3.1.788 NAME 'mgrpBroadcasterPolicy' DESC 
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: ( 
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: ( 
2.16.840.1.113730.3.1.22 NAME 'mgrpAllowedBroadcaster' DESC 
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60kerberos.ldif:# (FDNs of the 
krbKdcService objects).
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60kerberos.ldif:# Example:   cn=kdc - 
server 1, ou=uvw, o=xyz
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60kerberos.ldif:attributetypes: ( 
2.16.840.1.113719.1.301.4.17.1 NAME 'krbKdcServers' EQUALITY 
distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12)
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60kerberos.ldif:objectClasses: ( 
2.16.840.1.113719.1.301.6.2.1 NAME 'krbRealmContainer' SUP top MUST ( cn ) MAY 
( krbMKey $ krbUPEnabled $ krbSubTrees $ krbSearchScope $ krbLdapServers $ 
krbSupportedEncSaltTypes $ krbDefaultEncSaltTypes $ krbTicketPolicyReference $ 
krbKdcServers $ krbPwdServers $ krbAdmServers $ krbPrincNamingAttr 
$krbPwdPolicyReference $ krbPrincContainerRef ) )
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60kerberos.ldif:# krbKdcService, 
krbAdmService and krbPwdService derive from this class.
/etc/dirsrv/slapd-NUMEEZY-FR/schema/60kerberos.ldif:objectClasses: ( 
2.16.840.1.113719.1.301.6.4.1 NAME 'krbKdcService' SUP ( krbService ) )

 
 and definitions of 'dc' attribute from there.
 
 'dc' attribute is defined in 00core.ldif as
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent’ )

In 00core.ldif, I have :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  SINGLE-VALUE
  X-ORIGIN 'RFC 4519'
  X-DEPRECATED 'domaincomponent' )

 
 Note that syntax is 1.3.6.1.4.1.1466.115.121.1.26 (IA5String) while yours is
 1.3.6.1.4.1.1466.115.121.1.15 (DirectoryString), they are not the same.
 
 What modifications did you do to the schema?

As far as I remember, the only modification I made was to disable read-only 
access without authentication.
I don’t need any other special customization.

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-07-20 Thread Alexander Bokovoy


On Mon, 20 Jul 2015, Alexandre Ellert wrote:



Can you please show output from
fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema


# fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema


This is original 'dc' definition:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )


This is the offending one:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D



In 00core.ldif, I have :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent' )

If you look into 99user.ldif, you'll see the wrong definition there.

99user.ldif accumulates definitions coming from replication or updates.
You can check other IPA masters, do they have 'dc' attribute defined in
a wrong way?


As far as I remember, the only modification I made was to disable
read-only access without authentication.  I don’t need any other
special customization.

Something brought the wrong definition into your IPA masters.
May be someone tried to add support for some old application?

--
/ Alexander Bokovoy

--
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] Failed to start pki-tomcatd Service

2015-07-20 Thread Alexandre Ellert


 Le 20 juil. 2015 à 17:58, Petr Vobornik pvobo...@redhat.com a écrit :
 
 On 07/20/2015 05:17 PM, Alexander Bokovoy wrote:
 On Mon, 20 Jul 2015, Alexandre Ellert wrote:
 
 Can you please show output from
 fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema
 
 # fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema
 
 This is original 'dc' definition:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )
 
 This is the offending one:
 /etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D
 
 In 00core.ldif, I have :
 attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc'
 'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent' )
 If you look into 99user.ldif, you'll see the wrong definition there.
 
 99user.ldif accumulates definitions coming from replication or updates.
 You can check other IPA masters, do they have 'dc' attribute defined in
 a wrong way?
 
 As far as I remember, the only modification I made was to disable
 read-only access without authentication.  I don’t need any other
 special customization.
 Something brought the wrong definition into your IPA masters.
 May be someone tried to add support for some old application?
 
 
 Probably caused by migration from 6.6 to 7.x. See 
 https://bugzilla.redhat.com/show_bug.cgi?id=1220788 Usually it doesn't cause 
 any issue but looks scary.

I confirm this was a migration from CentOS 6.6 to 7.1. Every thing else worked 
just fine following the RedHat migration procedure 
(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html
 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html)

 
 I'd try to isolate entries from DS, CA, maybe also krb5kdc logs around the 
 time the following CA error happened (could be new start).
 
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
 Internal Database Error encountered: Could not connect to LDAP server host 
 ipa.mydomain.org http://ipa.mydomain.org/

I restarted IPA :

/var/log/pki/pki-tomcat/ca/debug  :
[20/Jul/2015:18:12:17][localhost-startStop-1]: CMS:Caught EBaseException

/var/log/krb5kdc.log :
otp: Loaded
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](Error): preauth pkinit 
failed to initialize: No realms configured correctly for pkinit support
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): setting up network...
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): listening on fd 8: 
udp 0.0.0.0.88 (pktinfo)
krb5kdc: setsockopt(9,IPV6_V6ONLY,1) worked
krb5kdc: Invalid argument - Cannot request packet info for udp socket address 
:: port 88
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): skipping 
unrecognized local address family 17
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): skipping 
unrecognized local address family 17
krb5kdc: setsockopt(9,IPV6_V6ONLY,1) worked
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): listening on fd 9: 
udp fe80::250:56ff:fe93:357e%ens160.88
krb5kdc: setsockopt(10,IPV6_V6ONLY,1) worked
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): listening on fd 11: 
tcp 0.0.0.0.88
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): listening on fd 10: 
tcp ::.88
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16635](info): set up 4 sockets
Jul 20 18:11:47 inf-ipa-2.numeezy.fr krb5kdc[16636](info): commencing operation
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): AS_REQ (6 etypes {18 
17 16 23 25 26}) 37.59.203.176: NEEDED_PREAUTH: 
host/inf-ipa-2.numeezy...@numeezy.fr for krbtgt/numeezy...@numeezy.fr, 
Additional pre-authentication required
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): closing down fd 12
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): AS_REQ (6 etypes {18 
17 16 23 25 26}) 37.59.203.176: ISSUE: authtime 1437408708, etypes {rep=18 
tkt=18 ses=18}, host/inf-ipa-2.numeezy...@numeezy.fr for 
krbtgt/numeezy...@numeezy.fr
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): closing down fd 12
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): TGS_REQ (6 etypes 
{18 17 16 23 25 26}) 37.59.203.176: ISSUE: authtime 1437408708, etypes {rep=18 
tkt=18 ses=18}, host/inf-ipa-2.numeezy...@numeezy.fr for 
ldap/inf-ipa-2.numeezy...@numeezy.fr
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): closing down fd 12
Jul 20 18:11:48 inf-ipa-2.numeezy.fr krb5kdc[16636](info): AS_REQ (6 etypes {18 
17 16 23 25 26}) 37.59.203.176: NEEDED_PREAUTH: 
DNS/inf-ipa-2.numeezy...@numeezy.fr for krbtgt/numeezy...@numeezy.fr, 
Additional pre-authentication required
Jul 20 18:11:48

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-07-20 Thread Petr Vobornik


On 07/20/2015 05:17 PM, Alexander Bokovoy wrote:

On Mon, 20 Jul 2015, Alexandre Ellert wrote:



Can you please show output from
fgrep -r 'dc' /etc/dirsrv/slapd-INSTANCE/schema


# fgrep -r 'dc' /etc/dirsrv/slapd-NUMEEZY-FR/schema


This is original 'dc' definition:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/00core.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' )


This is the offending one:

/etc/dirsrv/slapd-NUMEEZY-FR/schema/99user.ldif:attributeTypes: (
0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domaincomponent' ) D



In 00core.ldif, I have :
attributeTypes: ( 0.9.2342.19200300.100.1.25 NAME ( 'dc'
'domaincomponent' )
 EQUALITY caseIgnoreIA5Match
 SUBSTR caseIgnoreIA5SubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
 SINGLE-VALUE
 X-ORIGIN 'RFC 4519'
 X-DEPRECATED 'domaincomponent' )

If you look into 99user.ldif, you'll see the wrong definition there.

99user.ldif accumulates definitions coming from replication or updates.
You can check other IPA masters, do they have 'dc' attribute defined in
a wrong way?


As far as I remember, the only modification I made was to disable
read-only access without authentication.  I don’t need any other
special customization.

Something brought the wrong definition into your IPA masters.
May be someone tried to add support for some old application?



Probably caused by migration from 6.6 to 7.x. See 
https://bugzilla.redhat.com/show_bug.cgi?id=1220788 Usually it doesn't 
cause any issue but looks scary.


I'd try to isolate entries from DS, CA, maybe also krb5kdc logs around 
the time the following CA error happened (could be new start).


[30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server 
host ipa.mydomain.org


--
Petr Vobornik

--
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] Failed to start pki-tomcatd Service

2015-07-16 Thread Alexandre Ellert


 Le 16 juil. 2015 à 09:29, Lukas Slebodnik lsleb...@redhat.com a écrit :
 
 I had a similar issue on fedora 21 or fedora 22.
 The workarounds from freeipa ticket #4666 did not help for me either.
 I found out that there was some problem with upgrading dogtag configuration.
 
 You can try up ru upgrade manually. It might help you.
 [root@vm-114 ~]# rpm -q --scripts pki-server
 postinstall scriptlet (using /bin/sh):
 ## NOTE:  At this time, NO attempt has been made to update ANY PKI subsystem
 ##from EITHER 'sysVinit' OR previous 'systemd' processes to the new
 ##PKI deployment process
 
echo Upgrading server at `/bin/date`. 
/var/log/pki/pki-server-upgrade-10.2.4.log 21
/sbin/pki-server-upgrade --silent 
/var/log/pki/pki-server-upgrade-10.2.4.log 21
echo  /var/log/pki/pki-server-upgrade-10.2.4.log 21
 
systemctl daemon-reload
 
 
 In my case, it didn't help. So I updated freeipa to the latest version.
 then I install similar new freeipa on another machine. So I had functional
 dogtag. Then I tried to fix broken dogtag configuration using functional
 configuration from 2nd freeipa. I would definitely recommend to backup data
 from old freeipa before any manual updates.
 
 Maybe Fraser would have a better advice.
 
 LS

I tried the suggested solution with pki-server-upgrade script but it didn’t 
fix, the output was :
# cat /var/log/pki/pki-server-upgrade-10.1.2.log
Upgrading from version 10.1.2 to 10.1.2:
1. Add TLS Range Support

Upgrade complete.

I will try the second solution and install a fresh new IPA server to compare 
dogtag configuration.
Do you know what files/directory I should check ?

Thanks for your help-- 
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] Failed to start pki-tomcatd Service

2015-07-16 Thread Lukas Slebodnik

On (16/07/15 09:56), Alexandre Ellert wrote:

 Le 16 juil. 2015 à 09:29, Lukas Slebodnik lsleb...@redhat.com a écrit :

 I had a similar issue on fedora 21 or fedora 22.
 The workarounds from freeipa ticket #4666 did not help for me either.
 I found out that there was some problem with upgrading dogtag configuration.

 You can try up ru upgrade manually. It might help you.
 [root@vm-114 ~]# rpm -q --scripts pki-server
 postinstall scriptlet (using /bin/sh):
 ## NOTE:  At this time, NO attempt has been made to update ANY PKI subsystem
 ##from EITHER 'sysVinit' OR previous 'systemd' processes to the new
 ##PKI deployment process

echo Upgrading server at `/bin/date`. 
/var/log/pki/pki-server-upgrade-10.2.4.log 21
/sbin/pki-server-upgrade --silent 
/var/log/pki/pki-server-upgrade-10.2.4.log 21
echo  /var/log/pki/pki-server-upgrade-10.2.4.log 21

systemctl daemon-reload


 In my case, it didn't help. So I updated freeipa to the latest version.
 then I install similar new freeipa on another machine. So I had functional
 dogtag. Then I tried to fix broken dogtag configuration using functional
 configuration from 2nd freeipa. I would definitely recommend to backup data
 from old freeipa before any manual updates.

 Maybe Fraser would have a better advice.

 LS

I tried the suggested solution with pki-server-upgrade script but it didn’t 
fix, the output was :
# cat /var/log/pki/pki-server-upgrade-10.1.2.log
Upgrading from version 10.1.2 to 10.1.2:
1. Add TLS Range Support

Upgrade complete.

I will try the second solution and install a fresh new IPA server to compare 
dogtag configuration.
Do you know what files/directory I should check ?

I filtered my bash history and here is an output. I hope the history contains
all files. Please do not forget to backup all data.

[root@vm-114 ~]# history | grep vimdiff
  272  vimdiff pki/pki-tomcat/pki.policy /etc/pki/pki-tomcat/pki.policy
  275  vimdiff pki/pki-tomcat/context.xml /etc/pki/pki-tomcat/context.xml
  277  vimdiff pki/pki-tomcat/tomcat-users.xml pki/pki-tomcat/tomcat-users.xml
  278  vimdiff pki/pki-tomcat/tomcat-users.xml 
/etc/pki/pki-tomcat/tomcat-users.xml
  280  vimdiff pki/pki-tomcat/log4j.properties 
/etc/pki/pki-tomcat/log4j.properties
  288  vimdiff pki/pki-tomcat/password.conf /etc/pki/pki-tomcat/password.conf
  290  vimdiff pki/pki-tomcat/password.conf /etc/pki/pki-tomcat/password.conf
  293  vimdiff pki/pki-tomcat/tomcat.conf /etc/pki/pki-tomcat/tomcat.conf
  299  vimdiff pki/pki-tomcat/server.xml /etc/pki/pki-tomcat/server.xml
  302  vimdiff pki/pki-tomcat/Catalina/localhost/ca.xml 
/etc/pki/pki-tomcat/Catalina/localhost/ca.xml
  304  vimdiff pki/pki-tomcat/ca/vlvtasks.ldif 
/etc/pki/pki-tomcat/ca/vlvtasks.ldif
  306  vimdiff pki/pki-tomcat/ca/caOCSPCert.profile 
/etc/pki/pki-tomcat/ca/caOCSPCert.profile
  307  vimdiff pki/pki-tomcat/ca/acl.ldif /etc/pki/pki-tomcat/ca/acl.ldif
  309  vimdiff pki/pki-tomcat/ca/adminCert.profile 
/etc/pki/pki-tomcat/ca/adminCert.profile
  312  vimdiff pki/pki-tomcat/ca/database.ldif 
/etc/pki/pki-tomcat/ca/database.ldif
  314  vimdiff pki/pki-tomcat/ca/db.ldif /etc/pki/pki-tomcat/ca/db.ldif
  316  vimdiff pki/pki-tomcat/ca/index.ldif /etc/pki/pki-tomcat/ca/index.ldif
  318  vimdiff pki/pki-tomcat/ca/manager.ldif 
/etc/pki/pki-tomcat/ca/manager.ldif
  320  vimdiff pki/pki-tomcat/ca/proxy.conf /etc/pki/pki-tomcat/ca/proxy.conf
  322  vimdiff pki/pki-tomcat/ca/registry.cfg 
/etc/pki/pki-tomcat/ca/registry.cfg
  325  vimdiff pki/pki-tomcat/ca/schema.ldif /etc/pki/pki-tomcat/ca/schema.ldif
  613  vimdiff pki/java/cacerts /etc/pki/java/cacerts
  623  vimdiff pki/default.cfg /etc/pki/default.cfg
  626  vimdiff pki/pki.version /etc/pki/pki.version
  632  vimdiff pki/pki-tomcat/logging.properties 
/etc/pki/pki-tomcat/logging.properties
  635  vimdiff pki/pki-tomcat/catalina.policy 
/etc/pki/pki-tomcat/catalina.policy
  638  vimdiff pki/pki-tomcat/web.xml /etc/pki/pki-tomcat/web.xml
  654  vimdiff pki/pki-tomcat/ca/CS.cfg /etc/pki/pki-tomcat/ca/CS.cfg
  666   vimdiff pki/ca-trust/ca-legacy.conf /etc/pki/ca-trust/ca-legacy.conf
  677  vimdiff pki/nssdb/pkcs11.txt /etc/pki/nssdb/pkcs11.txt
  684  vimdiff pki/default.cfg /etc/pki/default.cfg
  707  vimdiff pki/tls/openssl.cnf etc/pki/tls/openssl.cnf
  708  vimdiff pki/tls/openssl.cnf /etc/pki/tls/openssl.cnf
  871  vimdiff slapd-IDM-EXAMPLE-COM/dse.ldif 
/etc/dirsrv/slapd-IDM-EXAMPLE-COM/dse.ldif
 1005  vimdiff pki/pki-tomcat/ca/schema.ldif /etc/pki/pki-tomcat/ca/schema.ldif


It is also possible that some certificates might be expired because dogtag
was not functional for soem time. So please take a look into wiki:
https://www.freeipa.org/page/Howto/CA_Certificate_Renewal

LS

-- 
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] Failed to start pki-tomcatd Service

2015-07-16 Thread Lukas Slebodnik

On (10/07/15 17:28), Alexandre Ellert wrote:

 Le 30 juin 2015 à 10:16, Alexandre Ellert aell...@numeezy.com a écrit :
 
 
 Could you please provide the content of logfile:
 `/var/log/pki/pki-tomcat/ca/debug', around the time the error
 occurs?
 
 Thanks,
 Fraser
 
 When the pki-tomcatd service is trying to start, I see this message in 
 /var/log/pki/pki-tomcat/ca/debug
 
 [30/Jun/2015:10:02:13][localhost-startStop-1]: 
 
 [30/Jun/2015:10:02:13][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
 INITIALIZED   ===
 [30/Jun/2015:10:02:13][localhost-startStop-1]: 
 
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: done init id=debug
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initialized debug
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initSubsystem 
 id=log
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: ready to init 
 id=log
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=log
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized log
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem 
 id=jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init 
 id=jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem 
 id=dbs
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init 
 id=dbs
 [30/Jun/2015:10:02:14][localhost-startStop-1]: DBSubsystem: init()  
 mEnableSerialMgmt=true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory: init 
 [30/Jun/2015:10:02:14][localhost-startStop-1]: 
 LdapBoundConnFactory:doCloning true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init()
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init begins
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init ends
 [30/Jun/2015:10:02:14][localhost-startStop-1]: init: before makeConnection 
 errorIfDown is true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: makeConnection: errorIfDown 
 true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapJssSSLSocket set client 
 auth cert nicknamesubsystemCert cert-pki-ca
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
 Internal Database Error encountered: Could not connect to LDAP server host 
 ipa.mydomain.org http://ipa.mydomain.org/ port 636 Error 
 netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
  at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
  at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
  at 
 com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
  at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
  at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
  at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
  at 
 com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:606)
  at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
  at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
  at java.security.AccessController.doPrivileged(Native Method)
  at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
  at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
  at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
  at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
  at 
 org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
  at 
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
  at 
 org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
  at 
 org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
  at 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
  at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
  at 
 org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at 
 org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
  at 
 org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-07-16 Thread Petr Vobornik


On 07/10/2015 05:28 PM, Alexandre Ellert wrote:



Le 30 juin 2015 à 10:16, Alexandre Ellert aell...@numeezy.com a écrit :



Could you please provide the content of logfile:
`/var/log/pki/pki-tomcat/ca/debug', around the time the error
occurs?

Thanks,
Fraser


When the pki-tomcatd service is trying to start, I see this message in 
/var/log/pki/pki-tomcat/ca/debug

[30/Jun/2015:10:02:13][localhost-startStop-1]: 

[30/Jun/2015:10:02:13][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[30/Jun/2015:10:02:13][localhost-startStop-1]: 

[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: done init id=debug
[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initialized debug
[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initSubsystem id=log
[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: ready to init id=log
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=log
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized log
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem id=jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init id=jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[30/Jun/2015:10:02:14][localhost-startStop-1]: DBSubsystem: init()  
mEnableSerialMgmt=true
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory: init
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory:doCloning 
true
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init()
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init begins
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init ends
[30/Jun/2015:10:02:14][localhost-startStop-1]: init: before makeConnection 
errorIfDown is true
[30/Jun/2015:10:02:14][localhost-startStop-1]: makeConnection: errorIfDown true
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapJssSSLSocket set client auth 
cert nicknamesubsystemCert cert-pki-ca
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server host 
ipa.mydomain.org http://ipa.mydomain.org/ port 636 Error 
netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
at 
com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
at 
com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
at 
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at 
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
at 
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
at 
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
at java.security.AccessController.doPrivileged(Native

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-07-10 Thread Alexandre Ellert


 Le 30 juin 2015 à 10:16, Alexandre Ellert aell...@numeezy.com a écrit :
 
 
 Could you please provide the content of logfile:
 `/var/log/pki/pki-tomcat/ca/debug', around the time the error
 occurs?
 
 Thanks,
 Fraser
 
 When the pki-tomcatd service is trying to start, I see this message in 
 /var/log/pki/pki-tomcat/ca/debug
 
 [30/Jun/2015:10:02:13][localhost-startStop-1]: 
 
 [30/Jun/2015:10:02:13][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
 INITIALIZED   ===
 [30/Jun/2015:10:02:13][localhost-startStop-1]: 
 
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: done init id=debug
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initialized debug
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initSubsystem id=log
 [30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: ready to init id=log
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=log
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized log
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem id=jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init id=jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized jss
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init id=dbs
 [30/Jun/2015:10:02:14][localhost-startStop-1]: DBSubsystem: init()  
 mEnableSerialMgmt=true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory: init 
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory:doCloning 
 true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init()
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init begins
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init ends
 [30/Jun/2015:10:02:14][localhost-startStop-1]: init: before makeConnection 
 errorIfDown is true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: makeConnection: errorIfDown 
 true
 [30/Jun/2015:10:02:14][localhost-startStop-1]: LdapJssSSLSocket set client 
 auth cert nicknamesubsystemCert cert-pki-ca
 [30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
 Internal Database Error encountered: Could not connect to LDAP server host 
 ipa.mydomain.org http://ipa.mydomain.org/ port 636 Error 
 netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
   at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
   at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
   at 
 com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
   at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
   at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
   at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
   at 
 com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
   at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
   at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
   at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
   at 
 org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
   at 
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
   at 
 org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
   at 
 org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
   at 
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
   at 
 org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
   at 
 org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
   at 
 org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
   at java.security.AccessController.doPrivileged(Native Method)
   at

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-07-09 Thread Alexandre Ellert

2015-06-29 19:37 GMT+02:00 Alexandre Ellert aell...@numeezy.com:
 Hello,

 I have a problem on a replica server running Centos 7.1 and ipa 
 4.1.0-18.el7.centos.3.x86_64 (last version)
 Ipa server doesn’t restart correctly (using systemctl restart ipa or reboot 
 the whole server) :
 # ipactl status
 Directory Service: STOPPED
 Directory Service must be running in order to obtain status of other services
 ipa: INFO: The ipactl command was successful

 and I have to force the start process :
 # ipactl start -f
 Existing service file detected!
 Assuming stale, cleaning and proceeding
 Starting Directory Service
 Starting krb5kdc Service
 Starting kadmin Service
 Starting named Service
 Starting ipa_memcached Service
 Starting httpd Service
 Starting pki-tomcatd Service


 Failed to start pki-tomcatd Service
 Forced start, ignoring pki-tomcatd Service, continuing normal operation
 Starting ipa-otpd Service
 ipa: INFO: The ipactl command was successful

 But, as you see the pki-tomcatd is unable to start.
 I started looking at /var/log/pki/pki-tomcat/localhost.2015-06-29.log and 
 found this error :
 Jun 29, 2015 7:33:12 PM org.apache.catalina.core.StandardWrapperValve invoke
 SEVERE: Servlet.service() for servlet [caProfileSubmit] in context with path 
 [/ca] threw exception
 java.io.IOException: CS server is not ready to serve.
 at 
 com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
 at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
 at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
 at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
 at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
 at 
 org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
 at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
 at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
 at 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
 at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
 at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
 at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
 at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
 at 
 org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
 at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
 at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
 at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-06-30 Thread Fraser Tweedale

On Mon, Jun 29, 2015 at 07:37:31PM +0200, Alexandre Ellert wrote:
 Hello,
 
 I have a problem on a replica server running Centos 7.1 and ipa 
 4.1.0-18.el7.centos.3.x86_64 (last version)
 Ipa server doesn’t restart correctly (using systemctl restart ipa or reboot 
 the whole server) :
 # ipactl status
 Directory Service: STOPPED
 Directory Service must be running in order to obtain status of other services
 ipa: INFO: The ipactl command was successful
 
 and I have to force the start process :
 # ipactl start -f
 Existing service file detected!
 Assuming stale, cleaning and proceeding
 Starting Directory Service
 Starting krb5kdc Service
 Starting kadmin Service
 Starting named Service
 Starting ipa_memcached Service
 Starting httpd Service
 Starting pki-tomcatd Service
 
 
 Failed to start pki-tomcatd Service
 Forced start, ignoring pki-tomcatd Service, continuing normal operation
 Starting ipa-otpd Service
 ipa: INFO: The ipactl command was successful
 
 But, as you see the pki-tomcatd is unable to start.
 I started looking at /var/log/pki/pki-tomcat/localhost.2015-06-29.log and 
 found this error :
 Jun 29, 2015 7:33:12 PM org.apache.catalina.core.StandardWrapperValve invoke
 SEVERE: Servlet.service() for servlet [caProfileSubmit] in context with path 
 [/ca] threw exception
 java.io.IOException: CS server is not ready to serve.
   at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
   at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
   at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
   at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
   at 
 org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
   at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
   at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
   at 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
   at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
   at 
 org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
   at 
 org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
   at 
 org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
   at 
 org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
   at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
   at 
 org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
   at java.security.AccessController.doPrivileged(Native Method)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
   at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
   at

Re: [Freeipa-users] Failed to start pki-tomcatd Service

2015-06-30 Thread Alexandre Ellert


 Could you please provide the content of logfile:
 `/var/log/pki/pki-tomcat/ca/debug', around the time the error
 occurs?
 
 Thanks,
 Fraser

When the pki-tomcatd service is trying to start, I see this message in 
/var/log/pki/pki-tomcat/ca/debug

[30/Jun/2015:10:02:13][localhost-startStop-1]: 

[30/Jun/2015:10:02:13][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[30/Jun/2015:10:02:13][localhost-startStop-1]: 

[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: done init id=debug
[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initialized debug
[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: initSubsystem id=log
[30/Jun/2015:10:02:13][localhost-startStop-1]: CMSEngine: ready to init id=log
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=log
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized log
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem id=jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init id=jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: done init id=jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initialized jss
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: initSubsystem id=dbs
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMSEngine: ready to init id=dbs
[30/Jun/2015:10:02:14][localhost-startStop-1]: DBSubsystem: init()  
mEnableSerialMgmt=true
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory: init 
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapBoundConnFactory:doCloning 
true
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init()
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init begins
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapAuthInfo: init ends
[30/Jun/2015:10:02:14][localhost-startStop-1]: init: before makeConnection 
errorIfDown is true
[30/Jun/2015:10:02:14][localhost-startStop-1]: makeConnection: errorIfDown true
[30/Jun/2015:10:02:14][localhost-startStop-1]: LdapJssSSLSocket set client auth 
cert nicknamesubsystemCert cert-pki-ca
[30/Jun/2015:10:02:14][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server host 
ipa.mydomain.org port 636 Error netscape.ldap.LDAPException: IO Error creating 
JSS SSL Socket (-1)
at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
at 
com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
at 
com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123)
at 
org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at 
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
at 
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
at 
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
at

[Freeipa-users] Failed to start pki-tomcatd Service

2015-06-29 Thread Alexandre Ellert

Hello,

I have a problem on a replica server running Centos 7.1 and ipa 
4.1.0-18.el7.centos.3.x86_64 (last version)
Ipa server doesn’t restart correctly (using systemctl restart ipa or reboot the 
whole server) :
# ipactl status
Directory Service: STOPPED
Directory Service must be running in order to obtain status of other services
ipa: INFO: The ipactl command was successful

and I have to force the start process :
# ipactl start -f
Existing service file detected!
Assuming stale, cleaning and proceeding
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting ipa_memcached Service
Starting httpd Service
Starting pki-tomcatd Service


Failed to start pki-tomcatd Service
Forced start, ignoring pki-tomcatd Service, continuing normal operation
Starting ipa-otpd Service
ipa: INFO: The ipactl command was successful

But, as you see the pki-tomcatd is unable to start.
I started looking at /var/log/pki/pki-tomcat/localhost.2015-06-29.log and found 
this error :
Jun 29, 2015 7:33:12 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [caProfileSubmit] in context with path 
[/ca] threw exception
java.io.IOException: CS server is not ready to serve.
at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:443)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

Re: [Freeipa-users] Failed to start pki-tomcatd Service

[Freeipa-users] Failed to start pki-tomcatd Service

35 matches

Site Navigation

Mail list logo

Footer information