[Freeipa-users] CA CRL not tracking any certificates. Normal?

2017-05-18 Thread Christophe TREFOIS
Hi,

I just saw that my CA CRL master is not tracking any certs.

However, my other CA master replica is tracking 8 certificates.

Is this normal and expected?

Thanks,
Christophe

-- 
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] Replica cannot be reinitialized after upgrade

2017-05-18 Thread Goran Marik
Thanks Ludwig for the suggestion and thanks to Maciej for the confirmation from 
his end. This issue is happening for us for several weeks, so I don’t think 
this is a transient problem. 

What is the best way to sanitize the logs without removing useful info before 
sending them your way? Will the files mentioned on 
"https://www.freeipa.org/page/Files_to_be_attached_to_bug_report -> Directory 
server failed" be sufficient? 

I’ve also run the ipa_consistency_check script, and the output shows that 
something is indeed wrong with the sync:
“””
FreeIPA servers:inf01inf01inf02inf02STATE
=
Active Users15   15   15   15   OK
Stage Users 0000OK
Preserved Users 3333OK
User Groups 9999OK
Hosts   45   45   45   46   FAIL
Host Groups 7777OK
HBAC Rules  6666OK
SUDO Rules  7777OK
DNS Zones   33   33   33   33   OK
LDAP Conflicts  NO   NO   NO   NO   OK
Ghost Replicas  2222FAIL
Anonymous BIND  YES  YES  YES  YES  OK
Replication Status  inf01.prod 0inf01.dev 0inf01.dev 0inf01.dev 0
inf02.dev 0inf02.dev 0inf01.prod 0inf01.prod 0
inf02.prod 0inf02.prod 0inf02.prod 0inf02.dev 0
=
“””

Thanks,
Goran

> On May 15, 2017, at 6:35 AM, Ludwig Krispenz  wrote:
> 
> The messages you see could be transient messages, and if replication is 
> working than this seems to be the case. If not we would need more data to 
> investigate: deployment info, relicaIDs of all servers, ruvs, logs,.
> 
> Here is some background info: there are some scenarios where a csn could not 
> be found in the changelog, eg if updates were aplied on the supplier during a 
> total init, they could be part of the data and database ruv, but not in the 
> changelog of the initialized replica.
> ds did try to use an alternative csn in cases where it could not be found, 
> but this had the risk of missing updates, so we decided to change it and make 
> this misssing csn a non fatal error, backoff and retry, if another supplier 
> would have updated the replica in between, the starting csn could have 
> changed and be found. so if the reported missing csns change and replication 
> continues everything is ok, although I think the messages should stop at some 
> point.
> 
> There is a configuration parameter for a replciation agreement to trigger the 
> previous behaviour of picking an alternative csn: 
> nsds5ReplicaIgnoreMissingChange
> with potential values "once", "always".
> 
> where "once" just tries to kickstart replication by using another csn and 
> "always" changes the default behaviour
> 
> 
> On 05/11/2017 06:53 PM, Goran Marik wrote:
>> Hi,
>> 
>> After an upgrade to Centos 7.3.1611 with “yum update", we started seeing the 
>> following messages in the logs:
>> “””
>> May  9 21:58:28 inf01 ns-slapd[4323]: [09/May/2017:21:58:28.519724479 +] 
>> NSMMReplicationPlugin - changelog program - 
>> agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389): CSN 
>> 576b34e8000a050f not found, we aren't as up to date, or we purged
>> May  9 21:58:28 inf01 ns-slapd[4323]: [09/May/2017:21:58:28.550459233 +] 
>> NSMMReplicationPlugin - 
>> agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389): Data 
>> required to update replica has been purged from the changelog. The replica 
>> must be reinitialized.
>> May  9 21:58:32 inf01 ns-slapd[4323]: [09/May/2017:21:58:32.588245476 +] 
>> agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389) - 
>> Can't locate CSN 576b34e8000a050f in the changelog (DB rc=-30988). If 
>> replication stops, the consumer may need to be reinitialized.
>> May  9 21:58:32 inf01 ns-slapd[4323]: [09/May/2017:21:58:32.611400689 +] 
>> NSMMReplicationPlugin - changelog program - 
>> agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389): CSN 
>> 576b34e8000a050f not found, we aren't as up to date, or we purged
>> May  9 21:58:32 inf01 ns-slapd[4323]: [09/May/2017:21:58:32.642226385 +] 
>> NSMMReplicationPlugin - 
>> agmt="cn=cloneAgreement1-inf02.dev.ecobee.com-pki-tomcat" (inf02:389): Data 
>> required to update replica has been purged from the changelog. The replica 
>> must be reinitialized.
>> “””
>> 
>> The log messages are pretty frequently, every few seconds, and report few 
>> different CSN numbers that cannot be located. 
>> 
>> This happens only on one replica out of 4. We’ve tried "ipa-replica-manage 
>> re-initialize —from” and “ipa-csreplica-manage re-initialize 

Re: [Freeipa-users] Freeipa and limiting access by group (memberOf)

2017-05-18 Thread Jakub Hrozek
On Thu, May 18, 2017 at 10:37:57AM -0600, Janet Houser wrote:
> 
> 
> On 5/17/17 9:22 AM, Jakub Hrozek wrote:
> > On Tue, May 16, 2017 at 07:56:38AM -0600, Janet Houser wrote:
> > > Hi Folks,
> > > 
> > > Last week I deployed freeipa on a CentOS7 VM.   The installation went very
> > > smoothly using:
> > > 
> > >  yum install ipa-server
> > > 
> > > and
> > > 
> > >  ipa-server-install
> > > 
> > > 
> > > My issue is with connecting a CentOS 7 client.  On my client, I yum
> > > installed  ipa-client and ipa-admintools.
> > > I than ran  "ipa-client-install"  and answered the setup questions (very
> > > easy and smooth).
> > > 
> > > The "getent passwd" command didn't return any users, but the "getent 
> > > passwd
> > > jdoe" does give the information
> > > for the user.   I found in the archives that I can set "enumerate=True" 
> > > so I
> > > get a complete user listing.   That
> > > seems to be working, and I was able to login with the account "jdoe"
> > > (brilliant!).
> > I would discourage enumeration especially if you're planning on a large
> > domain. The performance right now is not great. Moreover, the way the
> > trusted accounts are retrieved doesn't support enumeration at all
> > either.
> 
> Copy that.  Enumeration is set to true just for testing.  It will be
> disabled later.
> > 
> > > Problem 1:
> > > 
> > > 
> > > I created a user group on the ipa server  with the following attributes:
> > > 
> > > name = xyx,  gid = 1000
> > > 
> > > I changed the user "jdoe" to have gid = 1000, but when I ssh into the ipa
> > > client, I get the following message after
> > > logging in:
> > > 
> > > /usr/bin/id: cannot find name for group ID 1000
> > > 
> > > A "getent group" command does list the group: xyz:*:1000:
> > > 
> > > A "groups" command issued by the user shows:   xyz
> > > 
> > > files created by the user show the correct ownership and group.
> > I would first try to remove the sssd caches because uid/gid renumbering
> > doesn't work great. If that doesn't help, please check the sssd logs.
> 
> Didn't work, and the logs aren't really being helpful, but I'll dig further.

Feel free to paste some sanitized snippet here..

> 
> > 
> > By the way, 1000 is quite low and would most probably clash with local
> > accounts. I would strongly suggest to stick to ID numbers within the
> > configured ID range (ipa idrange-find)
> > 
> > > Problem 2:
> > > ===
> > > 
> > > I've been looking through the freeipa groups and literature and I can't
> > > figure out how to limit user login access to
> > > an ipa client by a memberOf group.
> > > 
> > > When I was using CentOS 6 and 7 I could use the nslcd.conf file to put in 
> > > a
> > > group filter like:
> > > 
> > > passwd 
> > > (&(objectClass=posixAccount)(memberOf=CN=test,OU=Groups,DC=abc,DC=xyx,DC=edu))
> > > 
> > > 
> > > I tried changing the access_provider to simple and using the
> > > "simply_allow_groups = test", but that didn't work.
> > > However, using "access_provider = ipa" and "filter_users" did allow me to
> > > filter out a user from the "getent passwd" command.
> > > 
> > > I tried changing the access_provider to ldap and using the filter
> > > "ldap_access_filter = memberOf=cn=test=OU=Groups,DC=abc,DC=xyx,DC=edu
> > > but that failed too.
> > Please check out "ipa help hbac"
> > 
> I just realized hbac is host based access control.   I can't really use this
> since I need to restrict certain users
> to resources.   Since freeipa is based on directory server 389, I'm assuming
> it can do group / memberOf filtering.

What are the resources we're talking about here?

> 
> Any suggestions would be appreciated.

-- 
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] Cant locate CSN after yum update

2017-05-18 Thread Christophe TREFOIS
Dear Ludwig,

Thanks for your help in IRC to guide me in running the right commands.

Here is the output, toto1 and toto2 are CA master, and toto3 and toto4 are non 
CA master. The problematic replica was toto3, and after re-init, we haven’t 
seen any errors in the log anymore.

https://paste.fedoraproject.org/paste/j8c30CZPyh8rPymjbKSvZF5M1UNdIGYhyRLivL9gydE=

I also ran ipa-replica-manage on all replicas to all replicas, so total of 16 
command, and found all of them reported “incremental update succeeded”.

As discussed, I’m not sure what I’m looking at with the RUV stuff above, and 
any explanation for a newcomer to ldap / ds / freeipa would be greatly 
appreciated.

Thanks a lot for your help!

Kind regards,
Christophe aka Trefex

On 18 May 2017, at 17:04, Christophe TREFOIS 
> wrote:

Hi Ludwig,

Since we were scared, we did a full re-init of that specific replica from the 
CA master, and it looks like the issue is not appearing anymore.

Is this sufficient, or should we still investigate ?

Thanks for your help!
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 




This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




On 18 May 2017, at 16:11, Ludwig Krispenz 
> wrote:

hi,

there was a change that in the case of a missing csn ds would not silently use 
a "close" one and continue, but log an error, backoff and retry - after updates 
on other masters the staring csn coudl change and replication continue.

Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that this csn 
is no longer found in the changelog.

To continue analysis, could you provide the replicaids of all your current 
replicas, and which is the replicaid of the sever logging the change and the 
ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv

Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:
Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.


Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=

Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??

Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
replication.

Remaining replicas were upgraded today as well, and don’t seem to complain. 
Only 1 of them complains.

389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype]



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.








--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-18 Thread Michael Plemmons
SOLVED!

Thank you Flo!  That did the trick.  Once I made the change to the
certificate and restarted the IPA services everything came back up like it
was supposed to.

High five!


*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 18, 2017 at 10:28 AM, Florence Blanc-Renaud 
wrote:

> On 05/18/2017 03:49 PM, Michael Plemmons wrote:
>
>>
>>
>>
>>
>> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> *
>> 614.427.2411
>> mike.plemm...@crosschx.com 
>> www.crosschx.com 
>>
>> On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud > > wrote:
>>
>> On 05/15/2017 08:33 PM, Michael Plemmons wrote:
>>
>> I have done more searching in my logs and I see the following
>> errors.
>>
>> This is in the localhost log file /var/lib/pki/pki-tomcat/logs
>>
>> May 15, 2017 3:08:08 PM
>> org.apache.catalina.core.ApplicationContext log
>> SEVERE: StandardWrapper.Throwable
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
>> loadOnStartup
>> SEVERE: Servlet [castart] in web application [/ca] threw load()
>> exception
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:09 PM
>> org.apache.catalina.core.StandardHostValve invoke
>> SEVERE: Exception Processing /ca/admin/ca/getStatus
>> javax.ws.rs 
>> .ServiceUnavailableException: Subsystem
>> unavailable
>>
>>
>> Looking at the debug log it says Authentication failed for port
>> 636.
>>
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
>> init()
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
>> init begins
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
>> init ends
>> [15/May/2017:17:39:25][localhost-startStop-1]: init: before
>> makeConnection errorIfDown is true
>> [15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
>> errorIfDown true
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: Setting desired cert nickname
>> to:
>> subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket:
>> set
>> client auth cert nickname subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificatSelectionCB: Entering!
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: returning: null
>> [15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake
>> happened
>> Could not connect to LDAP server host ipa12.mgmt.crosschx.com
>> 
>> > > port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConne
>> ction(LdapBoundConnFactory.java:205)
>>
>>
>> I looked at the validity of the cert it mentions and it is fine.
>>
>> (root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n
>> 'subsystemCert
>> cert-pki-ca'
>> State MONITORING, stuck: no.
>>
>>
>> I then looked at the ldap errors around the time of this failure
>> and I
>> am seeing this log entry.
>>
>>
>> [15/May/2017:17:38:42.063080758 +] set_krb5_creds - Could
>> not get
>> initial credentials for principal
>> [ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
>> 
>> > >] in keytab
>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any
>> KDC for
>> requested realm)
>>
>> When I perform a klist against that keytab nothing appears out
>> of the
>> ordinary compared to working IPA servers.
>>
>> I am not sure what to look at next.
>>
>>
>> Hi,
>>
>> you can try the following to manually replay the connection
>> established by Dogtag to LDAP server:
>>
>> root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
>> root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'
>>
>> The above commands specify the NSSDB containing the user certificate
>> and its name for SASL-EXTERNAL authentication.
>>
>> Then note the value obtained below as it will be used for the next
>> step as the password to access the private key in the NSSDB:
>> root$ grep 

Re: [Freeipa-users] Cant locate CSN after yum update

2017-05-18 Thread Christophe TREFOIS
Hi Ludwig,

Since we were scared, we did a full re-init of that specific replica from the 
CA master, and it looks like the issue is not appearing anymore.

Is this sufficient, or should we still investigate ?

Thanks for your help!
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




On 18 May 2017, at 16:11, Ludwig Krispenz 
> wrote:

hi,

there was a change that in the case of a missing csn ds would not silently use 
a "close" one and continue, but log an error, backoff and retry - after updates 
on other masters the staring csn coudl change and replication continue.

Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that this csn 
is no longer found in the changelog.

To continue analysis, could you provide the replicaids of all your current 
replicas, and which is the replicaid of the sever logging the change and the 
ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv

Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:
Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.


Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=

Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??

Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
replication.

Remaining replicas were upgraded today as well, and don’t seem to complain. 
Only 1 of them complains.

389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype]



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.








--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

-- 
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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-18 Thread Florence Blanc-Renaud

On 05/18/2017 03:49 PM, Michael Plemmons wrote:





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX
*
614.427.2411
mike.plemm...@crosschx.com 
www.crosschx.com 

On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud > wrote:

On 05/15/2017 08:33 PM, Michael Plemmons wrote:

I have done more searching in my logs and I see the following
errors.

This is in the localhost log file /var/lib/pki/pki-tomcat/logs

May 15, 2017 3:08:08 PM
org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NullPointerException

May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
loadOnStartup
SEVERE: Servlet [castart] in web application [/ca] threw load()
exception
java.lang.NullPointerException

May 15, 2017 3:08:09 PM
org.apache.catalina.core.StandardHostValve invoke
SEVERE: Exception Processing /ca/admin/ca/getStatus
javax.ws.rs 
.ServiceUnavailableException: Subsystem
unavailable


Looking at the debug log it says Authentication failed for port 636.

[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init()
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
init begins
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo:
init ends
[15/May/2017:17:39:25][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
errorIfDown true
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: Setting desired cert nickname to:
subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: set
client auth cert nickname subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: null
[15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake
happened
Could not connect to LDAP server host ipa12.mgmt.crosschx.com

> port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
at

com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)


I looked at the validity of the cert it mentions and it is fine.

(root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n
'subsystemCert
cert-pki-ca'
State MONITORING, stuck: no.


I then looked at the ldap errors around the time of this failure
and I
am seeing this log entry.


[15/May/2017:17:38:42.063080758 +] set_krb5_creds - Could
not get
initial credentials for principal
[ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com

>] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any
KDC for
requested realm)

When I perform a klist against that keytab nothing appears out
of the
ordinary compared to working IPA servers.

I am not sure what to look at next.


Hi,

you can try the following to manually replay the connection
established by Dogtag to LDAP server:

root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'

The above commands specify the NSSDB containing the user certificate
and its name for SASL-EXTERNAL authentication.

Then note the value obtained below as it will be used for the next
step as the password to access the private key in the NSSDB:
root$ grep internal /etc/pki/pki-tomcat/password.conf
internal=

root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
-Q -LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token
'ldap(0)': here supply the value found above
dn:
namingcontexts: cn=changelog
namingcontexts: dc=ipadomain,dc=com
namingcontexts: o=ipaca



So I guess I found my problem.

(root)>ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
-LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token 'ldap(0)':
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
  additional info: TLS error 

Re: [Freeipa-users] Cant locate CSN after yum update

2017-05-18 Thread Ludwig Krispenz

hi,

there was a change that in the case of a missing csn ds would not 
silently use a "close" one and continue, but log an error, backoff and 
retry - after updates on other masters the staring csn coudl change and 
replication continue.


Now, in your case the csn reported missing: 59095fe1000b0012
has a time stamp from May,3rd, so it could very well be correct that 
this csn is no longer found in the changelog.


To continue analysis, could you provide the replicaids of all your 
current replicas, and which is the replicaid of the sever logging the 
change and the ruvs of the replicas from all servers.
ldapsearch   -D "cn=directory manager"  -b cn=config 
"objectclass=nsds5replica" nsds50ruv


Regards,
Ludwig

On 05/18/2017 03:09 PM, Christophe TREFOIS wrote:

Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.



Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=


Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??


Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in 
diamond replication.


Remaining replicas were upgraded today as well, and don't seem to 
complain. Only 1 of them complains.


389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T:+352 46 66 44 6124
F:+352 46 66 44 6949
http://www.uni.lu/lcsb

Facebook Twitter 
Google Plus 
Linkedin 
skype



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the 
original message and any copies.








--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-18 Thread Michael Plemmons
*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud 
wrote:

> On 05/15/2017 08:33 PM, Michael Plemmons wrote:
>
>> I have done more searching in my logs and I see the following errors.
>>
>> This is in the localhost log file /var/lib/pki/pki-tomcat/logs
>>
>> May 15, 2017 3:08:08 PM org.apache.catalina.core.ApplicationContext log
>> SEVERE: StandardWrapper.Throwable
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
>> loadOnStartup
>> SEVERE: Servlet [castart] in web application [/ca] threw load() exception
>> java.lang.NullPointerException
>>
>> May 15, 2017 3:08:09 PM org.apache.catalina.core.StandardHostValve invoke
>> SEVERE: Exception Processing /ca/admin/ca/getStatus
>> javax.ws.rs .ServiceUnavailableException: Subsystem
>> unavailable
>>
>>
>> Looking at the debug log it says Authentication failed for port 636.
>>
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init()
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init begins
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init ends
>> [15/May/2017:17:39:25][localhost-startStop-1]: init: before
>> makeConnection errorIfDown is true
>> [15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
>> errorIfDown true
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: Setting desired cert nickname to:
>> subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: set
>> client auth cert nickname subsystemCert cert-pki-ca
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificatSelectionCB: Entering!
>> [15/May/2017:17:39:25][localhost-startStop-1]:
>> SSLClientCertificateSelectionCB: returning: null
>> [15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake happened
>> Could not connect to LDAP server host ipa12.mgmt.crosschx.com
>>  port 636 Error
>> netscape.ldap.LDAPException: Authentication failed (48)
>> at
>> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConne
>> ction(LdapBoundConnFactory.java:205)
>>
>>
>> I looked at the validity of the cert it mentions and it is fine.
>>
>> (root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
>> cert-pki-ca'
>> State MONITORING, stuck: no.
>>
>>
>> I then looked at the ldap errors around the time of this failure and I
>> am seeing this log entry.
>>
>>
>> [15/May/2017:17:38:42.063080758 +] set_krb5_creds - Could not get
>> initial credentials for principal
>> [ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
>> ] in keytab
>> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
>> requested realm)
>>
>> When I perform a klist against that keytab nothing appears out of the
>> ordinary compared to working IPA servers.
>>
>> I am not sure what to look at next.
>>
>>
> Hi,
>
> you can try the following to manually replay the connection established by
> Dogtag to LDAP server:
>
> root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
> root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'
>
> The above commands specify the NSSDB containing the user certificate and
> its name for SASL-EXTERNAL authentication.
>
> Then note the value obtained below as it will be used for the next step as
> the password to access the private key in the NSSDB:
> root$ grep internal /etc/pki/pki-tomcat/password.conf
> internal=
>
> root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
> -LLL dn namingcontexts
> Please enter pin, password, or pass phrase for security token 'ldap(0)':
>    here supply the value found above
> dn:
> namingcontexts: cn=changelog
> namingcontexts: dc=ipadomain,dc=com
> namingcontexts: o=ipaca
>
>

So I guess I found my problem.

(root)>ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q
-LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token 'ldap(0)':
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
  additional info: TLS error -12195:Peer does not recognize and trust the
CA that issued your certificate.


I looked at our certs in /etc/dirsrv/slapd-IPADOMAIN-COM and found the
following.

IPA12 - problem server
(root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Server-Cert  u,u,u
IPADOMAIN-COM IPA CA C,,



IPA11/IPA13 - 11 was the master and 13 is the new master
(root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Server-Cert

[Freeipa-users] Cant locate CSN after yum update

2017-05-18 Thread Christophe TREFOIS
Hi all,

Did a yum update on one of my replicas, non CA master, and upgrade was 
successful (ipupgrade.log) said so.


Hwoever, now every few seconds I get the following message. 
https://paste.fedoraproject.org/paste/wS4x9KvD3EB0gv2HAsj6X15M1UNdIGYhyRLivL9gydE=

Does anybody know how to proceed and if this is important?
ipa-replica-manage says, backing off, retrying later, so not sure if 
replication happens successfully or not and what to do ??

Setup: CentOS 7.3 all up-to-date, 2 CA master, 2 non CA master in diamond 
replication.

Remaining replicas were upgraded today as well, and don’t seem to complain. 
Only 1 of them complains.

389-ds-base-libs-1.3.5.10-20.el7_3.x86_64
389-ds-base-1.3.5.10-20.el7_3.x86_64


[root@lums3 ~]# rpm -qa | grep ipa
libipa_hbac-1.14.0-43.el7_3.14.x86_64
python-iniparse-0.4-9.el7.noarch
ipa-admintools-4.4.0-14.el7.centos.7.noarch
python2-ipaserver-4.4.0-14.el7.centos.7.noarch
python2-ipalib-4.4.0-14.el7.centos.7.noarch
sssd-ipa-1.14.0-43.el7_3.14.x86_64
python-ipaddress-1.0.16-2.el7.noarch
python2-ipaclient-4.4.0-14.el7.centos.7.noarch
ipa-server-common-4.4.0-14.el7.centos.7.noarch
ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-common-4.4.0-14.el7.centos.7.noarch
python-libipa_hbac-1.14.0-43.el7_3.14.x86_64
ipa-server-4.4.0-14.el7.centos.7.x86_64

Thanks a lot for any pointers,
Christophe

--

Dr Christophe Trefois, Dipl.-Ing.
Technical Specialist / Post-Doc

UNIVERSITÉ DU LUXEMBOURG

LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE
Campus Belval | House of Biomedicine
6, avenue du Swing
L-4367 Belvaux
T: +352 46 66 44 6124
F: +352 46 66 44 6949
http://www.uni.lu/lcsb

[Facebook]  [Twitter] 
   [Google Plus] 
   [Linkedin] 
   [skype] 



This message is confidential and may contain privileged information.
It is intended for the named recipient only.
If you receive it in error please notify me and permanently delete the original 
message and any copies.




-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
OK Martin, thanks for the explanation - i suspected it might not work quite
correctly. On that basis I have decided to hold off an wait for a more
optimistic situation.

I really appreciate the advice, looks like my time will be better spent
configuring the clients to use the replica!

On Thu, May 18, 2017 at 1:49 PM Martin Bašti  wrote:

> It will create clone of the original CA, it will work as backup not a
> separate CA.
>
> I'm afraid it will result into the same behavior because it uses almost
> the same code, but as I said before this issue is on dogtag side and not
> always reproducible.
>
> On 18.05.2017 14:44, Callum Guy wrote:
>
> Thanks for that Martin.
>
> The man page for ipa-ca-install suggests i could pass in my replica file
> to create a "CA-less" configuration. Is this what i want or is a CA-full
> appropriate? All I want to achieve is the additional resilience provided by
> a replica which can both authorise and sign certificates in the event of a
> loss of the master server. I certainly don't want an entirely separate CA
> to be installed - my anticipation is that my replica will be able to become
> an intermediate authority - is that the intended arrangement for a replica?
>
> Finally, do you hold out much hope that ipa-ca-install will work any
> better than --setup-ca flag I was attempting to get working for the replica
> install? If its the same code I would probably just end up with a half
> configured CA and have to rebuild my replica - something I would like to
> avoid repeating after the last couple of days!
>
> On Thu, May 18, 2017 at 1:28 PM Martin Bašti  wrote:
>
>> ipa-ca-install will install on top of FreeIPA CA-less replica, nothing
>> else, you really don't want to do it manually.
>>
>> On 18.05.2017 14:12, Callum Guy wrote:
>>
>> Thanks Martin, really appreciate the additional information.
>>
>> Are you aware of a separate guide for installing DogTag/PKI on top of
>> FreeIPA - basically I am happy to install separately if it doesn't
>> compromise the FreeIPA server configuration, i'm not clear on whether this
>> is possible without a major time investment.
>>
>> On Thu, May 18, 2017 at 12:46 PM Martin Bašti  wrote:
>>
>>>
>>> Please note that commits in #6766 will not fix this issue, the issue is
>>> on dogtag side, please see https://pagure.io/dogtagpki/issue/2646
>>> Sorry for troubles
>>>
>>>
>>> On 18.05.2017 12:19, Callum Guy wrote:
>>>
>>> Haha, looks like i'm going CA-less for a while on the replica. I don't
>>> see any immediate requirement for one so time to get on with my life!
>>>
>>> I'll post back if anything changes but I'm probably stuck waiting for
>>> the upgrade too..
>>>
>>> On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman 
>>> wrote:
>>>
 Sorry cobber. We only found 6766 today - we've been tackling it on and
 off for a couple of weeks :)

 --
 "Mission Statement: To provide hope and inspiration for collective
 action, to build collective power, to achieve collective transformation,
 rooted in grief and rage but pointed towards vision and dreams."

  - Patrice Cullors, *Black Lives Matter founder*

 On 18 May 2017 at 19:53, Callum Guy  wrote:

> Ah, thanks for that Lachlan - its always reassuring to hear that its
> not just me!
>
> As mentioned above I have it running without the CA so that's a good
> start. I am sure we will upgrade as well once 4.5 becomes stable and GA 
> for
> CentOS. I'm not expecting that to happen quickly so will have to work with
> what we have for now.
>
> Do you happen to know if there is any way to build the CA component
> separately?
>
> On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman 
> wrote:
>
>> https://pagure.io/freeipa/issue/6766
>>
>> 4.5.1 - I stand corrected. Can add more tomorrow.
>>
>> --
>> "Mission Statement: To provide hope and inspiration for collective
>> action, to build collective power, to achieve collective transformation,
>> rooted in grief and rage but pointed towards vision and dreams."
>>
>>  - Patrice Cullors, *Black Lives Matter founder*
>>
>> On 18 May 2017 at 19:34, Lachlan Musicman  wrote:
>>
>>> We are seeing this. I'm not at work, but I think it's bug report
>>> 6766.
>>>
>>> Patch has already been committed (bot by us), we're waiting for IPA
>>> 4.5.
>>>
>>> cheers
>>> L.
>>>
>>> --
>>> "Mission Statement: To provide hope and inspiration for collective
>>> action, to build collective power, to achieve collective transformation,
>>> rooted in grief and rage but pointed towards vision and dreams."
>>>
>>>  - Patrice Cullors, *Black Lives Matter founder*
>>>
>>> On 18 May 2017 at 18:57, Callum Guy  

Re: [Freeipa-users] I think I lost my CA...

2017-05-18 Thread Bret Wortman

Oops, the slapd messages are arriving every 60s, not 5m.


On 05/18/2017 08:56 AM, Bret Wortman wrote:


httpd_error seems to give the most information. When i try to use ipa 
cert-show:


ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: ping(): SUCCESS
(111)Connection refused: AH00957: AJP: attempt to connect to 
127.0.0.1:8009 (localhost) failed

AH00959: ap_proxy_connect_backend disabling worker for (locahost) for 60s
[client 192.168.208.54:52714] AH00896: failed to make connection to 
backend: localhost

ipa: ERROR: ra.get_certificate(): Unable to communicate with CMS (503)
ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: 
cert_show/1(u'895', version=u'2.213'): CertificateOperationError


/var/log/pki/pki-tomcat/ca/debug just loops through the same set of 
messages every 5 minutes or so but doesn't seem to error.


/var/log/pki/localhost_access_log.2017-05-18.txt is basically empty 
except for a single entry (for a POST to /ca/admin/ca/getStatus)


Nothing shows up in dirsrv/slapd-DAMASCUSGRP-COM/errors or access when 
I issue the request, but periodic messages do appear about every 5 
minutes or so.



On 05/18/2017 08:43 AM, Bret Wortman wrote:

On 04/26/2017 06:02 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So I can see my certs using cert-find, but can't get details using
cert-show or add new ones using cert-request.

 # ipa cert-find
 :
 --
 Number of entries returned 385
 --
 # ipa cert-show 895
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 # ipa cert-show 1 (which does not exist)
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 # ipa cert-status 895
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 #

Is this an IPV6 thing? Because ipactl shows everything green and
certmonger is running.

Doubtful.

cert-find and cert-show use different APIs in dogtag. cert-find uses 
the

newer RESTful API and cert-show uses the older XML-based API (and is
authenticated). I'm guessing that is where the issue lies.

What I'd recommend doing is noting the time, restarting the CA, and 
then
plow through the debug log looking for failures. It could be that 
the CA

is only partially up (and I'd check your CA subsystem certs as well).
Which debug log, specifically, do you think will help? I'm also not 
sure what you mean by, "check your CA subsystem certs." We still have 
pending CSRs that we can't grant until I get this working again.

rob


Bret


On 04/26/2017 09:03 AM, Bret Wortman wrote:

Digging still deeper:

 # ipa cert-request f.f 
--principal=HTTP/`hostname`@DAMASCUSGRP.COM

 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)

Looks like this is an HTTP error; so is it possible that my IPA 
thinks

it has a CA but there's no CMS available?


On 04/26/2017 08:41 AM, Bret Wortman wrote:

Using the firefox debugger, I get these errors when trying to pop up
the New Certificate dialog:

 Empty string passed to getElementById(). (5)
 jquery.js:4:1060
 TypeError: u is undefined
 app.js:1:362059
 Empty string passed to getElementById(). (5)
 jquery.js:4:1060
 TypeError: t is undefined
 app.js:1:217432

I'm definitely not a web kind of guy so I'm not sure if this is
helpful or not. This is on 4.4.0, API Version 2.213.


Bret


On 04/26/2017 08:35 AM, Bret Wortman wrote:

Good news. One of my servers _does_ have CA installed. So why does
"Action -> New Certificate" not do anything on this or any other 
server?



Bret


On 04/25/2017 02:52 PM, Bret Wortman wrote:

I recently had to upgrade all my Fedora IPA servers to C7. It went
well, and we've been up and running nicely on 4.4.0 on C7 for the
past month or so.

Today, someone came and asked me to generate a new certificate for
their web server. All was good until I went to the IPA UI and 
tried

to perform Actions->New Certificate, which did nothing. I tried
each of our 3 servers in turn. All came back with no popup window
and no error, either.

I suspect the problem might be that we no longer have a CA server
due to the method I used to upgrade the servers. I likely missed a
"--setup-ca" in there somewhere, so my rolling update rolled over
the CA.

What's my best hope of recovery? I never ran this before, so I'm
not sure if this shows that I'm missing a CA or not:

 # ipa ca-find
 
 1 CA matched
 
   Name: ipa
   Description IPA CA
   Authority ID: 3ce3346[...]
   Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
   Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM
 
 Number of entries returned 1
 
 # ipa ca-add dg --desc "Damascus Group" --subject 

Re: [Freeipa-users] I think I lost my CA...

2017-05-18 Thread Bret Wortman
httpd_error seems to give the most information. When i try to use ipa 
cert-show:


ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: ping(): SUCCESS
(111)Connection refused: AH00957: AJP: attempt to connect to 
127.0.0.1:8009 (localhost) failed

AH00959: ap_proxy_connect_backend disabling worker for (locahost) for 60s
[client 192.168.208.54:52714] AH00896: failed to make connection to 
backend: localhost

ipa: ERROR: ra.get_certificate(): Unable to communicate with CMS (503)
ipa: INFO: [jsonserver_kerb] ad...@damascusgrp.com: cert_show/1(u'895', 
version=u'2.213'): CertificateOperationError


/var/log/pki/pki-tomcat/ca/debug just loops through the same set of 
messages every 5 minutes or so but doesn't seem to error.


/var/log/pki/localhost_access_log.2017-05-18.txt is basically empty 
except for a single entry (for a POST to /ca/admin/ca/getStatus)


Nothing shows up in dirsrv/slapd-DAMASCUSGRP-COM/errors or access when I 
issue the request, but periodic messages do appear about every 5 minutes 
or so.



On 05/18/2017 08:43 AM, Bret Wortman wrote:

On 04/26/2017 06:02 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So I can see my certs using cert-find, but can't get details using
cert-show or add new ones using cert-request.

 # ipa cert-find
 :
 --
 Number of entries returned 385
 --
 # ipa cert-show 895
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 # ipa cert-show 1 (which does not exist)
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 # ipa cert-status 895
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 #

Is this an IPV6 thing? Because ipactl shows everything green and
certmonger is running.

Doubtful.

cert-find and cert-show use different APIs in dogtag. cert-find uses the
newer RESTful API and cert-show uses the older XML-based API (and is
authenticated). I'm guessing that is where the issue lies.

What I'd recommend doing is noting the time, restarting the CA, and then
plow through the debug log looking for failures. It could be that the CA
is only partially up (and I'd check your CA subsystem certs as well).
Which debug log, specifically, do you think will help? I'm also not 
sure what you mean by, "check your CA subsystem certs." We still have 
pending CSRs that we can't grant until I get this working again.

rob


Bret


On 04/26/2017 09:03 AM, Bret Wortman wrote:

Digging still deeper:

 # ipa cert-request f.f 
--principal=HTTP/`hostname`@DAMASCUSGRP.COM

 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)

Looks like this is an HTTP error; so is it possible that my IPA thinks
it has a CA but there's no CMS available?


On 04/26/2017 08:41 AM, Bret Wortman wrote:

Using the firefox debugger, I get these errors when trying to pop up
the New Certificate dialog:

 Empty string passed to getElementById(). (5)
 jquery.js:4:1060
 TypeError: u is undefined
 app.js:1:362059
 Empty string passed to getElementById(). (5)
 jquery.js:4:1060
 TypeError: t is undefined
 app.js:1:217432

I'm definitely not a web kind of guy so I'm not sure if this is
helpful or not. This is on 4.4.0, API Version 2.213.


Bret


On 04/26/2017 08:35 AM, Bret Wortman wrote:

Good news. One of my servers _does_ have CA installed. So why does
"Action -> New Certificate" not do anything on this or any other 
server?



Bret


On 04/25/2017 02:52 PM, Bret Wortman wrote:

I recently had to upgrade all my Fedora IPA servers to C7. It went
well, and we've been up and running nicely on 4.4.0 on C7 for the
past month or so.

Today, someone came and asked me to generate a new certificate for
their web server. All was good until I went to the IPA UI and tried
to perform Actions->New Certificate, which did nothing. I tried
each of our 3 servers in turn. All came back with no popup window
and no error, either.

I suspect the problem might be that we no longer have a CA server
due to the method I used to upgrade the servers. I likely missed a
"--setup-ca" in there somewhere, so my rolling update rolled over
the CA.

What's my best hope of recovery? I never ran this before, so I'm
not sure if this shows that I'm missing a CA or not:

 # ipa ca-find
 
 1 CA matched
 
   Name: ipa
   Description IPA CA
   Authority ID: 3ce3346[...]
   Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
   Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM
 
 Number of entries returned 1
 
 # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA,
 O=DAMASCUSGRP.COM"
 ipa: ERROR: Failed to authenticate to CA REST API
 # klist
 Ticket cache: 

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Martin Bašti
It will create clone of the original CA, it will work as backup not a 
separate CA.


I'm afraid it will result into the same behavior because it uses almost 
the same code, but as I said before this issue is on dogtag side and not 
always reproducible.



On 18.05.2017 14:44, Callum Guy wrote:

Thanks for that Martin.

The man page for ipa-ca-install suggests i could pass in my replica 
file to create a "CA-less" configuration. Is this what i want or is a 
CA-full appropriate? All I want to achieve is the additional 
resilience provided by a replica which can both authorise and sign 
certificates in the event of a loss of the master server. I certainly 
don't want an entirely separate CA to be installed - my anticipation 
is that my replica will be able to become an intermediate authority - 
is that the intended arrangement for a replica?


Finally, do you hold out much hope that ipa-ca-install will work any 
better than --setup-ca flag I was attempting to get working for the 
replica install? If its the same code I would probably just end up 
with a half configured CA and have to rebuild my replica - something I 
would like to avoid repeating after the last couple of days!


On Thu, May 18, 2017 at 1:28 PM Martin Bašti > wrote:


ipa-ca-install will install on top of FreeIPA CA-less replica,
nothing else, you really don't want to do it manually.


On 18.05.2017 14:12, Callum Guy wrote:

Thanks Martin, really appreciate the additional information.

Are you aware of a separate guide for installing DogTag/PKI on
top of FreeIPA - basically I am happy to install separately if it
doesn't compromise the FreeIPA server configuration, i'm not
clear on whether this is possible without a major time investment.

On Thu, May 18, 2017 at 12:46 PM Martin Bašti > wrote:


Please note that commits in #6766 will not fix this issue,
the issue is on dogtag side, please see
https://pagure.io/dogtagpki/issue/2646

Sorry for troubles


On 18.05.2017 12:19, Callum Guy wrote:

Haha, looks like i'm going CA-less for a while on the
replica. I don't see any immediate requirement for one so
time to get on with my life!

I'll post back if anything changes but I'm probably stuck
waiting for the upgrade too..

On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman
> wrote:

Sorry cobber. We only found 6766 today - we've been
tackling it on and off for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for
collective action, to build collective power, to achieve
collective transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:53, Callum Guy
>
wrote:

Ah, thanks for that Lachlan - its always reassuring
to hear that its not just me!

As mentioned above I have it running without the CA
so that's a good start. I am sure we will upgrade as
well once 4.5 becomes stable and GA for CentOS. I'm
not expecting that to happen quickly so will have to
work with what we have for now.

Do you happen to know if there is any way to build
the CA component separately?

On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman
> wrote:

https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and
inspiration for collective action, to build
collective power, to achieve collective
transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:34, Lachlan Musicman
>
wrote:

We are seeing this. I'm not at work, but I
think it's bug report 6766.

Patch has already been committed (bot by
us), we're waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and
inspiration for collective action, to build
   

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
Thanks for that Martin.

The man page for ipa-ca-install suggests i could pass in my replica file to
create a "CA-less" configuration. Is this what i want or is a CA-full
appropriate? All I want to achieve is the additional resilience provided by
a replica which can both authorise and sign certificates in the event of a
loss of the master server. I certainly don't want an entirely separate CA
to be installed - my anticipation is that my replica will be able to become
an intermediate authority - is that the intended arrangement for a replica?

Finally, do you hold out much hope that ipa-ca-install will work any better
than --setup-ca flag I was attempting to get working for the replica
install? If its the same code I would probably just end up with a half
configured CA and have to rebuild my replica - something I would like to
avoid repeating after the last couple of days!

On Thu, May 18, 2017 at 1:28 PM Martin Bašti  wrote:

> ipa-ca-install will install on top of FreeIPA CA-less replica, nothing
> else, you really don't want to do it manually.
>
> On 18.05.2017 14:12, Callum Guy wrote:
>
> Thanks Martin, really appreciate the additional information.
>
> Are you aware of a separate guide for installing DogTag/PKI on top of
> FreeIPA - basically I am happy to install separately if it doesn't
> compromise the FreeIPA server configuration, i'm not clear on whether this
> is possible without a major time investment.
>
> On Thu, May 18, 2017 at 12:46 PM Martin Bašti  wrote:
>
>>
>> Please note that commits in #6766 will not fix this issue, the issue is
>> on dogtag side, please see https://pagure.io/dogtagpki/issue/2646
>> Sorry for troubles
>>
>>
>> On 18.05.2017 12:19, Callum Guy wrote:
>>
>> Haha, looks like i'm going CA-less for a while on the replica. I don't
>> see any immediate requirement for one so time to get on with my life!
>>
>> I'll post back if anything changes but I'm probably stuck waiting for the
>> upgrade too..
>>
>> On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman 
>> wrote:
>>
>>> Sorry cobber. We only found 6766 today - we've been tackling it on and
>>> off for a couple of weeks :)
>>>
>>> --
>>> "Mission Statement: To provide hope and inspiration for collective
>>> action, to build collective power, to achieve collective transformation,
>>> rooted in grief and rage but pointed towards vision and dreams."
>>>
>>>  - Patrice Cullors, *Black Lives Matter founder*
>>>
>>> On 18 May 2017 at 19:53, Callum Guy  wrote:
>>>
 Ah, thanks for that Lachlan - its always reassuring to hear that its
 not just me!

 As mentioned above I have it running without the CA so that's a good
 start. I am sure we will upgrade as well once 4.5 becomes stable and GA for
 CentOS. I'm not expecting that to happen quickly so will have to work with
 what we have for now.

 Do you happen to know if there is any way to build the CA component
 separately?

 On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman 
 wrote:

> https://pagure.io/freeipa/issue/6766
>
> 4.5.1 - I stand corrected. Can add more tomorrow.
>
> --
> "Mission Statement: To provide hope and inspiration for collective
> action, to build collective power, to achieve collective transformation,
> rooted in grief and rage but pointed towards vision and dreams."
>
>  - Patrice Cullors, *Black Lives Matter founder*
>
> On 18 May 2017 at 19:34, Lachlan Musicman  wrote:
>
>> We are seeing this. I'm not at work, but I think it's bug report
>> 6766.
>>
>> Patch has already been committed (bot by us), we're waiting for IPA
>> 4.5.
>>
>> cheers
>> L.
>>
>> --
>> "Mission Statement: To provide hope and inspiration for collective
>> action, to build collective power, to achieve collective transformation,
>> rooted in grief and rage but pointed towards vision and dreams."
>>
>>  - Patrice Cullors, *Black Lives Matter founder*
>>
>> On 18 May 2017 at 18:57, Callum Guy  wrote:
>>
>>> Hi All,
>>>
>>> I am currently stuck trying to setup the first replica of our master
>>> IPA server. I have tried a number of different approaches including
>>> escalating from a client and nothing is working for me. I perform a 
>>> full OS
>>> reset each time I get stuck.
>>>
>>> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
>>> version however having performed ipa-server-upgrade - does this mean 
>>> i'm on
>>> 4.4.4?).
>>>
>>> The command is shown below - note that i am skipping the conn check
>>> as my platforms security settings do not allow the SSH session to be
>>> established back on the master, all ports should be available to the
>>> application however.
>>>

Re: [Freeipa-users] I think I lost my CA...

2017-05-18 Thread Bret Wortman

On 04/26/2017 06:02 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So I can see my certs using cert-find, but can't get details using
cert-show or add new ones using cert-request.

 # ipa cert-find
 :
 --
 Number of entries returned 385
 --
 # ipa cert-show 895
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 # ipa cert-show 1 (which does not exist)
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 # ipa cert-status 895
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)
 #

Is this an IPV6 thing? Because ipactl shows everything green and
certmonger is running.

Doubtful.

cert-find and cert-show use different APIs in dogtag. cert-find uses the
newer RESTful API and cert-show uses the older XML-based API (and is
authenticated). I'm guessing that is where the issue lies.

What I'd recommend doing is noting the time, restarting the CA, and then
plow through the debug log looking for failures. It could be that the CA
is only partially up (and I'd check your CA subsystem certs as well).
Which debug log, specifically, do you think will help? I'm also not sure 
what you mean by, "check your CA subsystem certs." We still have pending 
CSRs that we can't grant until I get this working again.

rob


Bret


On 04/26/2017 09:03 AM, Bret Wortman wrote:

Digging still deeper:

 # ipa cert-request f.f --principal=HTTP/`hostname`@DAMASCUSGRP.COM
 ipa: ERROR: Certificate operation cannot be completed: Unable to
 communicate with CMS (503)

Looks like this is an HTTP error; so is it possible that my IPA thinks
it has a CA but there's no CMS available?


On 04/26/2017 08:41 AM, Bret Wortman wrote:

Using the firefox debugger, I get these errors when trying to pop up
the New Certificate dialog:

 Empty string passed to getElementById(). (5)
 jquery.js:4:1060
 TypeError: u is undefined
 app.js:1:362059
 Empty string passed to getElementById(). (5)
 jquery.js:4:1060
 TypeError: t is undefined
 app.js:1:217432

I'm definitely not a web kind of guy so I'm not sure if this is
helpful or not. This is on 4.4.0, API Version 2.213.


Bret


On 04/26/2017 08:35 AM, Bret Wortman wrote:

Good news. One of my servers _does_ have CA installed. So why does
"Action -> New Certificate" not do anything on this or any other server?


Bret


On 04/25/2017 02:52 PM, Bret Wortman wrote:

I recently had to upgrade all my Fedora IPA servers to C7. It went
well, and we've been up and running nicely on 4.4.0 on C7 for the
past month or so.

Today, someone came and asked me to generate a new certificate for
their web server. All was good until I went to the IPA UI and tried
to perform Actions->New Certificate, which did nothing. I tried
each of our 3 servers in turn. All came back with no popup window
and no error, either.

I suspect the problem might be that we no longer have a CA server
due to the method I used to upgrade the servers. I likely missed a
"--setup-ca" in there somewhere, so my rolling update rolled over
the CA.

What's my best hope of recovery? I never ran this before, so I'm
not sure if this shows that I'm missing a CA or not:

 # ipa ca-find
 
 1 CA matched
 
   Name: ipa
   Description IPA CA
   Authority ID: 3ce3346[...]
   Subject DN: CN=Certificate Authority, O=DAMASCUSGRP.COM
   Issuer DN: CN=Certificate Authority,O=DAMASCUSGRP.COM
 
 Number of entries returned 1
 
 # ipa ca-add dg --desc "Damascus Group" --subject "CN=DG CA,
 O=DAMASCUSGRP.COM"
 ipa: ERROR: Failed to authenticate to CA REST API
 # klist
 Ticket cache: KEYRING:persistent:0:0
 Default principal: ad...@damascusgrp.com

 Valid starting  Expires  Service principal
 04/25/2017 18:48:26 04/26/2017 18:48:21
 krbtgt/damascusgrp@damascusgrp.com
 #


What's my best path of recovery?

--
*Bret Wortman*
The Damascus Group















--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Martin Bašti
ipa-ca-install will install on top of FreeIPA CA-less replica, nothing 
else, you really don't want to do it manually.



On 18.05.2017 14:12, Callum Guy wrote:

Thanks Martin, really appreciate the additional information.

Are you aware of a separate guide for installing DogTag/PKI on top of 
FreeIPA - basically I am happy to install separately if it doesn't 
compromise the FreeIPA server configuration, i'm not clear on whether 
this is possible without a major time investment.


On Thu, May 18, 2017 at 12:46 PM Martin Bašti > wrote:



Please note that commits in #6766 will not fix this issue, the
issue is on dogtag side, please see
https://pagure.io/dogtagpki/issue/2646

Sorry for troubles


On 18.05.2017 12:19, Callum Guy wrote:

Haha, looks like i'm going CA-less for a while on the replica. I
don't see any immediate requirement for one so time to get on
with my life!

I'll post back if anything changes but I'm probably stuck waiting
for the upgrade too..

On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman
> wrote:

Sorry cobber. We only found 6766 today - we've been tackling
it on and off for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for
collective action, to build collective power, to achieve
collective transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:53, Callum Guy > wrote:

Ah, thanks for that Lachlan - its always reassuring to
hear that its not just me!

As mentioned above I have it running without the CA so
that's a good start. I am sure we will upgrade as well
once 4.5 becomes stable and GA for CentOS. I'm not
expecting that to happen quickly so will have to work
with what we have for now.

Do you happen to know if there is any way to build the CA
component separately?

On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman
> wrote:

https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and inspiration
for collective action, to build collective power, to
achieve collective transformation, rooted in grief
and rage but pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:34, Lachlan Musicman
> wrote:

We are seeing this. I'm not at work, but I think
it's bug report 6766.

Patch has already been committed (bot by us),
we're waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and
inspiration for collective action, to build
collective power, to achieve collective
transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 18:57, Callum Guy
> wrote:

Hi All,

I am currently stuck trying to setup the
first replica of our master IPA server. I
have tried a number of different approaches
including escalating from a client and
nothing is working for me. I perform a full
OS reset each time I get stuck.

I'm running CentOS 7.2 with the FreeIPA 4.4.0
(rpm -q reports this version however having
performed ipa-server-upgrade - does this mean
i'm on 4.4.4?).

The command is shown below - note that i am
skipping the conn check as my platforms
security settings do not allow the SSH
session to be established back on the master,
all ports should be available to the
application however.

[root@ipa2 ~]# ipa-replica-install
--ip-address=172.24.0.101 --setup-ca

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
Thanks Martin, really appreciate the additional information.

Are you aware of a separate guide for installing DogTag/PKI on top of
FreeIPA - basically I am happy to install separately if it doesn't
compromise the FreeIPA server configuration, i'm not clear on whether this
is possible without a major time investment.

On Thu, May 18, 2017 at 12:46 PM Martin Bašti  wrote:

>
> Please note that commits in #6766 will not fix this issue, the issue is on
> dogtag side, please see https://pagure.io/dogtagpki/issue/2646
> Sorry for troubles
>
>
> On 18.05.2017 12:19, Callum Guy wrote:
>
> Haha, looks like i'm going CA-less for a while on the replica. I don't see
> any immediate requirement for one so time to get on with my life!
>
> I'll post back if anything changes but I'm probably stuck waiting for the
> upgrade too..
>
> On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman 
> wrote:
>
>> Sorry cobber. We only found 6766 today - we've been tackling it on and
>> off for a couple of weeks :)
>>
>> --
>> "Mission Statement: To provide hope and inspiration for collective
>> action, to build collective power, to achieve collective transformation,
>> rooted in grief and rage but pointed towards vision and dreams."
>>
>>  - Patrice Cullors, *Black Lives Matter founder*
>>
>> On 18 May 2017 at 19:53, Callum Guy  wrote:
>>
>>> Ah, thanks for that Lachlan - its always reassuring to hear that its not
>>> just me!
>>>
>>> As mentioned above I have it running without the CA so that's a good
>>> start. I am sure we will upgrade as well once 4.5 becomes stable and GA for
>>> CentOS. I'm not expecting that to happen quickly so will have to work with
>>> what we have for now.
>>>
>>> Do you happen to know if there is any way to build the CA component
>>> separately?
>>>
>>> On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman 
>>> wrote:
>>>
 https://pagure.io/freeipa/issue/6766

 4.5.1 - I stand corrected. Can add more tomorrow.

 --
 "Mission Statement: To provide hope and inspiration for collective
 action, to build collective power, to achieve collective transformation,
 rooted in grief and rage but pointed towards vision and dreams."

  - Patrice Cullors, *Black Lives Matter founder*

 On 18 May 2017 at 19:34, Lachlan Musicman  wrote:

> We are seeing this. I'm not at work, but I think it's bug report 6766.
>
> Patch has already been committed (bot by us), we're waiting for IPA
> 4.5.
>
> cheers
> L.
>
> --
> "Mission Statement: To provide hope and inspiration for collective
> action, to build collective power, to achieve collective transformation,
> rooted in grief and rage but pointed towards vision and dreams."
>
>  - Patrice Cullors, *Black Lives Matter founder*
>
> On 18 May 2017 at 18:57, Callum Guy  wrote:
>
>> Hi All,
>>
>> I am currently stuck trying to setup the first replica of our master
>> IPA server. I have tried a number of different approaches including
>> escalating from a client and nothing is working for me. I perform a full 
>> OS
>> reset each time I get stuck.
>>
>> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
>> version however having performed ipa-server-upgrade - does this mean i'm 
>> on
>> 4.4.4?).
>>
>> The command is shown below - note that i am skipping the conn check
>> as my platforms security settings do not allow the SSH session to be
>> established back on the master, all ports should be available to the
>> application however.
>>
>> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101
>> --setup-ca --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>>
>> Directory Manager (existing master) password:
>>
>> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
>> check queries IPA DNS directly and ignores /etc/hosts.)
>> Continue? [no]: yes
>> Configuring NTP daemon (ntpd)
>>   [1/4]: stopping ntpd
>>   [2/4]: writing configuration
>>   [3/4]: configuring ntpd to start on boot
>>   [4/4]: starting ntpd
>> Done configuring NTP daemon (ntpd).
>> Configuring directory server (dirsrv). Estimated time: 1 minute
>>   [1/42]: creating directory server user
>>   [2/42]: creating directory server instance
>>   [3/42]: updating configuration in dse.ldif
>>   [4/42]: restarting directory server
>>   [5/42]: adding default schema
>>   [6/42]: enabling memberof plugin
>>   [7/42]: enabling winsync plugin
>>   [8/42]: configuring replication version plugin
>>   [9/42]: enabling IPA enrollment plugin
>>   [10/42]: enabling ldapi
>>   [11/42]: configuring uniqueness plugin
>>   [12/42]: configuring uuid plugin
>>   [13/42]: 

Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

2017-05-18 Thread Florence Blanc-Renaud

On 05/15/2017 08:33 PM, Michael Plemmons wrote:

I have done more searching in my logs and I see the following errors.

This is in the localhost log file /var/lib/pki/pki-tomcat/logs

May 15, 2017 3:08:08 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NullPointerException

May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext
loadOnStartup
SEVERE: Servlet [castart] in web application [/ca] threw load() exception
java.lang.NullPointerException

May 15, 2017 3:08:09 PM org.apache.catalina.core.StandardHostValve invoke
SEVERE: Exception Processing /ca/admin/ca/getStatus
javax.ws.rs .ServiceUnavailableException: Subsystem
unavailable


Looking at the debug log it says Authentication failed for port 636.

[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init()
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init begins
[15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: init ends
[15/May/2017:17:39:25][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[15/May/2017:17:39:25][localhost-startStop-1]: makeConnection:
errorIfDown true
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: Setting desired cert nickname to:
subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: set
client auth cert nickname subsystemCert cert-pki-ca
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[15/May/2017:17:39:25][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: null
[15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake happened
Could not connect to LDAP server host ipa12.mgmt.crosschx.com
 port 636 Error
netscape.ldap.LDAPException: Authentication failed (48)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)


I looked at the validity of the cert it mentions and it is fine.

(root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
cert-pki-ca'
State MONITORING, stuck: no.


I then looked at the ldap errors around the time of this failure and I
am seeing this log entry.


[15/May/2017:17:38:42.063080758 +] set_krb5_creds - Could not get
initial credentials for principal
[ldap/ipa12.mgmt.crosschx@mgmt.crosschx.com
] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)

When I perform a klist against that keytab nothing appears out of the
ordinary compared to working IPA servers.

I am not sure what to look at next.



Hi,

you can try the following to manually replay the connection established 
by Dogtag to LDAP server:


root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca'

The above commands specify the NSSDB containing the user certificate and 
its name for SASL-EXTERNAL authentication.


Then note the value obtained below as it will be used for the next step 
as the password to access the private key in the NSSDB:

root$ grep internal /etc/pki/pki-tomcat/password.conf
internal=

root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q 
-LLL dn namingcontexts
Please enter pin, password, or pass phrase for security token 'ldap(0)': 
    here supply the value found above

dn:
namingcontexts: cn=changelog
namingcontexts: dc=ipadomain,dc=com
namingcontexts: o=ipaca


In the LDAP server access log (in 
/etc/dirsrv/slapd-IPADOMAIN.COM/access), you should see the 
corresponding connection:


[18/May/2017:13:35:14.822090417 +0200] conn=297 fd=150 slot=150 SSL 
connection from xxx to yyy
[18/May/2017:13:35:15.789414017 +0200] conn=297 TLS1.2 128-bit AES-GCM; 
client CN=CA Subsystem,O=IPADOMAIN.COM; issuer CN=Certificate 
Authority,O=IPADOMAIN.COM
[18/May/2017:13:35:15.793108509 +0200] conn=297 TLS1.2 client bound as 
uid=pkidbuser,ou=people,o=ipaca
[18/May/2017:13:35:15.798101505 +0200] conn=297 op=0 BIND dn="" 
method=sasl version=3 mech=EXTERNAL
[18/May/2017:13:35:15.800322076 +0200] conn=297 op=0 RESULT err=0 tag=97 
nentries=0 etime=0 dn="uid=pkidbuser,ou=people,o=ipaca"


HTH,
Flo.





*Mike Plemmons | Senior DevOps Engineer | CROSSCHX
*
614.427.2411
mike.plemm...@crosschx.com 
www.crosschx.com 

On Wed, May 10, 2017 at 3:35 PM, Michael Plemmons
>
wrote:

The PKI service came up successfully but only when it uses BasicAuth
rather than SSL auth.  I am not sure about what I need to do in
order to get the auth working over SSL again.

None of the certs are expired when I run getcert list and
ipa-getcert list.

Since the failure is with attempts to login to LDAP over 636.  I
have been attempting to auth to LDAP via port 

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Martin Bašti


Please note that commits in #6766 will not fix this issue, the issue is 
on dogtag side, please see https://pagure.io/dogtagpki/issue/2646


Sorry for troubles

On 18.05.2017 12:19, Callum Guy wrote:
Haha, looks like i'm going CA-less for a while on the replica. I don't 
see any immediate requirement for one so time to get on with my life!


I'll post back if anything changes but I'm probably stuck waiting for 
the upgrade too..


On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman > wrote:


Sorry cobber. We only found 6766 today - we've been tackling it on
and off for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for collective
action, to build collective power, to achieve collective
transformation, rooted in grief and rage but pointed towards
vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:53, Callum Guy > wrote:

Ah, thanks for that Lachlan - its always reassuring to hear
that its not just me!

As mentioned above I have it running without the CA so that's
a good start. I am sure we will upgrade as well once 4.5
becomes stable and GA for CentOS. I'm not expecting that to
happen quickly so will have to work with what we have for now.

Do you happen to know if there is any way to build the CA
component separately?

On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman
> wrote:

https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and inspiration for
collective action, to build collective power, to achieve
collective transformation, rooted in grief and rage but
pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 19:34, Lachlan Musicman
> wrote:

We are seeing this. I'm not at work, but I think it's
bug report 6766.

Patch has already been committed (bot by us), we're
waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and inspiration
for collective action, to build collective power, to
achieve collective transformation, rooted in grief and
rage but pointed towards vision and dreams."

 - Patrice Cullors, /Black Lives Matter founder/

On 18 May 2017 at 18:57, Callum Guy
>
wrote:

Hi All,

I am currently stuck trying to setup the first
replica of our master IPA server. I have tried a
number of different approaches including
escalating from a client and nothing is working
for me. I perform a full OS reset each time I get
stuck.

I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm
-q reports this version however having performed
ipa-server-upgrade - does this mean i'm on 4.4.4?).

The command is shown below - note that i am
skipping the conn check as my platforms security
settings do not allow the SSH session to be
established back on the master, all ports should
be available to the application however.

[root@ipa2 ~]# ipa-replica-install
--ip-address=172.24.0.101 --setup-ca --setup-dns
--skip-conncheck --no-forwarders SITE.net.gpg

Directory Manager (existing master) password:

ipa : ERROR  Could not resolve hostname
ipa2.SITE.net  usis check
queries IPA DNS directly and ignores /etc/hosts.)
Continue? [no]: yes
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated
time: 1 minute
  [1/42]: creating directory server user
  [2/42]: creating directory server instance
  [3/42]: updating configuration in 

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
Haha, looks like i'm going CA-less for a while on the replica. I don't see
any immediate requirement for one so time to get on with my life!

I'll post back if anything changes but I'm probably stuck waiting for the
upgrade too..

On Thu, May 18, 2017 at 11:01 AM Lachlan Musicman  wrote:

> Sorry cobber. We only found 6766 today - we've been tackling it on and off
> for a couple of weeks :)
>
> --
> "Mission Statement: To provide hope and inspiration for collective action,
> to build collective power, to achieve collective transformation, rooted in
> grief and rage but pointed towards vision and dreams."
>
>  - Patrice Cullors, *Black Lives Matter founder*
>
> On 18 May 2017 at 19:53, Callum Guy  wrote:
>
>> Ah, thanks for that Lachlan - its always reassuring to hear that its not
>> just me!
>>
>> As mentioned above I have it running without the CA so that's a good
>> start. I am sure we will upgrade as well once 4.5 becomes stable and GA for
>> CentOS. I'm not expecting that to happen quickly so will have to work with
>> what we have for now.
>>
>> Do you happen to know if there is any way to build the CA component
>> separately?
>>
>> On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman 
>> wrote:
>>
>>> https://pagure.io/freeipa/issue/6766
>>>
>>> 4.5.1 - I stand corrected. Can add more tomorrow.
>>>
>>> --
>>> "Mission Statement: To provide hope and inspiration for collective
>>> action, to build collective power, to achieve collective transformation,
>>> rooted in grief and rage but pointed towards vision and dreams."
>>>
>>>  - Patrice Cullors, *Black Lives Matter founder*
>>>
>>> On 18 May 2017 at 19:34, Lachlan Musicman  wrote:
>>>
 We are seeing this. I'm not at work, but I think it's bug report 6766.

 Patch has already been committed (bot by us), we're waiting for IPA 4.5.

 cheers
 L.

 --
 "Mission Statement: To provide hope and inspiration for collective
 action, to build collective power, to achieve collective transformation,
 rooted in grief and rage but pointed towards vision and dreams."

  - Patrice Cullors, *Black Lives Matter founder*

 On 18 May 2017 at 18:57, Callum Guy  wrote:

> Hi All,
>
> I am currently stuck trying to setup the first replica of our master
> IPA server. I have tried a number of different approaches including
> escalating from a client and nothing is working for me. I perform a full 
> OS
> reset each time I get stuck.
>
> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
> version however having performed ipa-server-upgrade - does this mean i'm 
> on
> 4.4.4?).
>
> The command is shown below - note that i am skipping the conn check as
> my platforms security settings do not allow the SSH session to be
> established back on the master, all ports should be available to the
> application however.
>
> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101
> --setup-ca --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>
> Directory Manager (existing master) password:
>
> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
> check queries IPA DNS directly and ignores /etc/hosts.)
> Continue? [no]: yes
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
>   [1/42]: creating directory server user
>   [2/42]: creating directory server instance
>   [3/42]: updating configuration in dse.ldif
>   [4/42]: restarting directory server
>   [5/42]: adding default schema
>   [6/42]: enabling memberof plugin
>   [7/42]: enabling winsync plugin
>   [8/42]: configuring replication version plugin
>   [9/42]: enabling IPA enrollment plugin
>   [10/42]: enabling ldapi
>   [11/42]: configuring uniqueness plugin
>   [12/42]: configuring uuid plugin
>   [13/42]: configuring modrdn plugin
>   [14/42]: configuring DNS plugin
>   [15/42]: enabling entryUSN plugin
>   [16/42]: configuring lockout plugin
>   [17/42]: configuring topology plugin
>   [18/42]: creating indices
>   [19/42]: enabling referential integrity plugin
>   [20/42]: configuring ssl for ds instance
>   [21/42]: configuring certmap.conf
>   [22/42]: configure autobind for root
>   [23/42]: configure new location for managed entries
>   [24/42]: configure dirsrv ccache
>   [25/42]: enabling SASL mapping fallback
>   [26/42]: restarting directory server
>   [27/42]: setting up initial replication
> Starting replication, please wait until this has completed.

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Lachlan Musicman
Sorry cobber. We only found 6766 today - we've been tackling it on and off
for a couple of weeks :)

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 18 May 2017 at 19:53, Callum Guy  wrote:

> Ah, thanks for that Lachlan - its always reassuring to hear that its not
> just me!
>
> As mentioned above I have it running without the CA so that's a good
> start. I am sure we will upgrade as well once 4.5 becomes stable and GA for
> CentOS. I'm not expecting that to happen quickly so will have to work with
> what we have for now.
>
> Do you happen to know if there is any way to build the CA component
> separately?
>
> On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman 
> wrote:
>
>> https://pagure.io/freeipa/issue/6766
>>
>> 4.5.1 - I stand corrected. Can add more tomorrow.
>>
>> --
>> "Mission Statement: To provide hope and inspiration for collective
>> action, to build collective power, to achieve collective transformation,
>> rooted in grief and rage but pointed towards vision and dreams."
>>
>>  - Patrice Cullors, *Black Lives Matter founder*
>>
>> On 18 May 2017 at 19:34, Lachlan Musicman  wrote:
>>
>>> We are seeing this. I'm not at work, but I think it's bug report 6766.
>>>
>>> Patch has already been committed (bot by us), we're waiting for IPA 4.5.
>>>
>>> cheers
>>> L.
>>>
>>> --
>>> "Mission Statement: To provide hope and inspiration for collective
>>> action, to build collective power, to achieve collective transformation,
>>> rooted in grief and rage but pointed towards vision and dreams."
>>>
>>>  - Patrice Cullors, *Black Lives Matter founder*
>>>
>>> On 18 May 2017 at 18:57, Callum Guy  wrote:
>>>
 Hi All,

 I am currently stuck trying to setup the first replica of our master
 IPA server. I have tried a number of different approaches including
 escalating from a client and nothing is working for me. I perform a full OS
 reset each time I get stuck.

 I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
 version however having performed ipa-server-upgrade - does this mean i'm on
 4.4.4?).

 The command is shown below - note that i am skipping the conn check as
 my platforms security settings do not allow the SSH session to be
 established back on the master, all ports should be available to the
 application however.

 [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101
 --setup-ca --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg

 Directory Manager (existing master) password:

 ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
 check queries IPA DNS directly and ignores /etc/hosts.)
 Continue? [no]: yes
 Configuring NTP daemon (ntpd)
   [1/4]: stopping ntpd
   [2/4]: writing configuration
   [3/4]: configuring ntpd to start on boot
   [4/4]: starting ntpd
 Done configuring NTP daemon (ntpd).
 Configuring directory server (dirsrv). Estimated time: 1 minute
   [1/42]: creating directory server user
   [2/42]: creating directory server instance
   [3/42]: updating configuration in dse.ldif
   [4/42]: restarting directory server
   [5/42]: adding default schema
   [6/42]: enabling memberof plugin
   [7/42]: enabling winsync plugin
   [8/42]: configuring replication version plugin
   [9/42]: enabling IPA enrollment plugin
   [10/42]: enabling ldapi
   [11/42]: configuring uniqueness plugin
   [12/42]: configuring uuid plugin
   [13/42]: configuring modrdn plugin
   [14/42]: configuring DNS plugin
   [15/42]: enabling entryUSN plugin
   [16/42]: configuring lockout plugin
   [17/42]: configuring topology plugin
   [18/42]: creating indices
   [19/42]: enabling referential integrity plugin
   [20/42]: configuring ssl for ds instance
   [21/42]: configuring certmap.conf
   [22/42]: configure autobind for root
   [23/42]: configure new location for managed entries
   [24/42]: configure dirsrv ccache
   [25/42]: enabling SASL mapping fallback
   [26/42]: restarting directory server
   [27/42]: setting up initial replication
 Starting replication, please wait until this has completed.
 Update in progress, 4 seconds elapsed
 Update succeeded

   [28/42]: adding sasl mappings to the directory
   [29/42]: updating schema
   [30/42]: setting Auto Member configuration
   [31/42]: enabling S4U2Proxy delegation
   [32/42]: importing CA certificates from LDAP
   [33/42]: initializing group membership
   [34/42]: adding master entry
   [35/42]: initializing domain level
   [36/42]: 

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
Ah, thanks for that Lachlan - its always reassuring to hear that its not
just me!

As mentioned above I have it running without the CA so that's a good start.
I am sure we will upgrade as well once 4.5 becomes stable and GA for
CentOS. I'm not expecting that to happen quickly so will have to work with
what we have for now.

Do you happen to know if there is any way to build the CA component
separately?

On Thu, May 18, 2017 at 10:38 AM Lachlan Musicman  wrote:

> https://pagure.io/freeipa/issue/6766
>
> 4.5.1 - I stand corrected. Can add more tomorrow.
>
> --
> "Mission Statement: To provide hope and inspiration for collective action,
> to build collective power, to achieve collective transformation, rooted in
> grief and rage but pointed towards vision and dreams."
>
>  - Patrice Cullors, *Black Lives Matter founder*
>
> On 18 May 2017 at 19:34, Lachlan Musicman  wrote:
>
>> We are seeing this. I'm not at work, but I think it's bug report 6766.
>>
>> Patch has already been committed (bot by us), we're waiting for IPA 4.5.
>>
>> cheers
>> L.
>>
>> --
>> "Mission Statement: To provide hope and inspiration for collective
>> action, to build collective power, to achieve collective transformation,
>> rooted in grief and rage but pointed towards vision and dreams."
>>
>>  - Patrice Cullors, *Black Lives Matter founder*
>>
>> On 18 May 2017 at 18:57, Callum Guy  wrote:
>>
>>> Hi All,
>>>
>>> I am currently stuck trying to setup the first replica of our master IPA
>>> server. I have tried a number of different approaches including escalating
>>> from a client and nothing is working for me. I perform a full OS reset each
>>> time I get stuck.
>>>
>>> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
>>> version however having performed ipa-server-upgrade - does this mean i'm on
>>> 4.4.4?).
>>>
>>> The command is shown below - note that i am skipping the conn check as
>>> my platforms security settings do not allow the SSH session to be
>>> established back on the master, all ports should be available to the
>>> application however.
>>>
>>> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
>>> --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>>>
>>> Directory Manager (existing master) password:
>>>
>>> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
>>> check queries IPA DNS directly and ignores /etc/hosts.)
>>> Continue? [no]: yes
>>> Configuring NTP daemon (ntpd)
>>>   [1/4]: stopping ntpd
>>>   [2/4]: writing configuration
>>>   [3/4]: configuring ntpd to start on boot
>>>   [4/4]: starting ntpd
>>> Done configuring NTP daemon (ntpd).
>>> Configuring directory server (dirsrv). Estimated time: 1 minute
>>>   [1/42]: creating directory server user
>>>   [2/42]: creating directory server instance
>>>   [3/42]: updating configuration in dse.ldif
>>>   [4/42]: restarting directory server
>>>   [5/42]: adding default schema
>>>   [6/42]: enabling memberof plugin
>>>   [7/42]: enabling winsync plugin
>>>   [8/42]: configuring replication version plugin
>>>   [9/42]: enabling IPA enrollment plugin
>>>   [10/42]: enabling ldapi
>>>   [11/42]: configuring uniqueness plugin
>>>   [12/42]: configuring uuid plugin
>>>   [13/42]: configuring modrdn plugin
>>>   [14/42]: configuring DNS plugin
>>>   [15/42]: enabling entryUSN plugin
>>>   [16/42]: configuring lockout plugin
>>>   [17/42]: configuring topology plugin
>>>   [18/42]: creating indices
>>>   [19/42]: enabling referential integrity plugin
>>>   [20/42]: configuring ssl for ds instance
>>>   [21/42]: configuring certmap.conf
>>>   [22/42]: configure autobind for root
>>>   [23/42]: configure new location for managed entries
>>>   [24/42]: configure dirsrv ccache
>>>   [25/42]: enabling SASL mapping fallback
>>>   [26/42]: restarting directory server
>>>   [27/42]: setting up initial replication
>>> Starting replication, please wait until this has completed.
>>> Update in progress, 4 seconds elapsed
>>> Update succeeded
>>>
>>>   [28/42]: adding sasl mappings to the directory
>>>   [29/42]: updating schema
>>>   [30/42]: setting Auto Member configuration
>>>   [31/42]: enabling S4U2Proxy delegation
>>>   [32/42]: importing CA certificates from LDAP
>>>   [33/42]: initializing group membership
>>>   [34/42]: adding master entry
>>>   [35/42]: initializing domain level
>>>   [36/42]: configuring Posix uid/gid generation
>>>   [37/42]: adding replication acis
>>>   [38/42]: enabling compatibility plugin
>>>   [39/42]: activating sidgen plugin
>>>   [40/42]: activating extdom plugin
>>>   [41/42]: tuning directory server
>>>   [42/42]: configuring directory to start on boot
>>> Done configuring directory server (dirsrv).
>>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>>> 30 seconds
>>>   [1/27]: creating certificate server user
>>>   [2/27]: configuring certificate server instance
>>>   [3/27]: stopping 

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Lachlan Musicman
https://pagure.io/freeipa/issue/6766

4.5.1 - I stand corrected. Can add more tomorrow.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 18 May 2017 at 19:34, Lachlan Musicman  wrote:

> We are seeing this. I'm not at work, but I think it's bug report 6766.
>
> Patch has already been committed (bot by us), we're waiting for IPA 4.5.
>
> cheers
> L.
>
> --
> "Mission Statement: To provide hope and inspiration for collective action,
> to build collective power, to achieve collective transformation, rooted in
> grief and rage but pointed towards vision and dreams."
>
>  - Patrice Cullors, *Black Lives Matter founder*
>
> On 18 May 2017 at 18:57, Callum Guy  wrote:
>
>> Hi All,
>>
>> I am currently stuck trying to setup the first replica of our master IPA
>> server. I have tried a number of different approaches including escalating
>> from a client and nothing is working for me. I perform a full OS reset each
>> time I get stuck.
>>
>> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this
>> version however having performed ipa-server-upgrade - does this mean i'm on
>> 4.4.4?).
>>
>> The command is shown below - note that i am skipping the conn check as my
>> platforms security settings do not allow the SSH session to be established
>> back on the master, all ports should be available to the application
>> however.
>>
>> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
>> --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>>
>> Directory Manager (existing master) password:
>>
>> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
>> check queries IPA DNS directly and ignores /etc/hosts.)
>> Continue? [no]: yes
>> Configuring NTP daemon (ntpd)
>>   [1/4]: stopping ntpd
>>   [2/4]: writing configuration
>>   [3/4]: configuring ntpd to start on boot
>>   [4/4]: starting ntpd
>> Done configuring NTP daemon (ntpd).
>> Configuring directory server (dirsrv). Estimated time: 1 minute
>>   [1/42]: creating directory server user
>>   [2/42]: creating directory server instance
>>   [3/42]: updating configuration in dse.ldif
>>   [4/42]: restarting directory server
>>   [5/42]: adding default schema
>>   [6/42]: enabling memberof plugin
>>   [7/42]: enabling winsync plugin
>>   [8/42]: configuring replication version plugin
>>   [9/42]: enabling IPA enrollment plugin
>>   [10/42]: enabling ldapi
>>   [11/42]: configuring uniqueness plugin
>>   [12/42]: configuring uuid plugin
>>   [13/42]: configuring modrdn plugin
>>   [14/42]: configuring DNS plugin
>>   [15/42]: enabling entryUSN plugin
>>   [16/42]: configuring lockout plugin
>>   [17/42]: configuring topology plugin
>>   [18/42]: creating indices
>>   [19/42]: enabling referential integrity plugin
>>   [20/42]: configuring ssl for ds instance
>>   [21/42]: configuring certmap.conf
>>   [22/42]: configure autobind for root
>>   [23/42]: configure new location for managed entries
>>   [24/42]: configure dirsrv ccache
>>   [25/42]: enabling SASL mapping fallback
>>   [26/42]: restarting directory server
>>   [27/42]: setting up initial replication
>> Starting replication, please wait until this has completed.
>> Update in progress, 4 seconds elapsed
>> Update succeeded
>>
>>   [28/42]: adding sasl mappings to the directory
>>   [29/42]: updating schema
>>   [30/42]: setting Auto Member configuration
>>   [31/42]: enabling S4U2Proxy delegation
>>   [32/42]: importing CA certificates from LDAP
>>   [33/42]: initializing group membership
>>   [34/42]: adding master entry
>>   [35/42]: initializing domain level
>>   [36/42]: configuring Posix uid/gid generation
>>   [37/42]: adding replication acis
>>   [38/42]: enabling compatibility plugin
>>   [39/42]: activating sidgen plugin
>>   [40/42]: activating extdom plugin
>>   [41/42]: tuning directory server
>>   [42/42]: configuring directory to start on boot
>> Done configuring directory server (dirsrv).
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>> 30 seconds
>>   [1/27]: creating certificate server user
>>   [2/27]: configuring certificate server instance
>>   [3/27]: stopping certificate server instance to update CS.cfg
>>   [4/27]: backing up CS.cfg
>>   [5/27]: disabling nonces
>>   [6/27]: set up CRL publishing
>>   [7/27]: enable PKIX certificate path discovery and validation
>>   [8/27]: starting certificate server instance
>>
>> And here is stays and refuses to move on. The ipareplica-install.log log
>> reports:
>> 2017-05-18T08:40:07Z DEBUG wait_for_open_ports: localhost [8080, 8443]
>> timeout 300
>> 2017-05-18T08:40:09Z DEBUG Waiting until the CA is running
>> 2017-05-18T08:40:09Z DEBUG request POST http://ipa2.SITE.net:8080/ca/a
>> dmin/ca/getStatus
>> 

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Lachlan Musicman
We are seeing this. I'm not at work, but I think it's bug report 6766.

Patch has already been committed (bot by us), we're waiting for IPA 4.5.

cheers
L.

--
"Mission Statement: To provide hope and inspiration for collective action,
to build collective power, to achieve collective transformation, rooted in
grief and rage but pointed towards vision and dreams."

 - Patrice Cullors, *Black Lives Matter founder*

On 18 May 2017 at 18:57, Callum Guy  wrote:

> Hi All,
>
> I am currently stuck trying to setup the first replica of our master IPA
> server. I have tried a number of different approaches including escalating
> from a client and nothing is working for me. I perform a full OS reset each
> time I get stuck.
>
> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this version
> however having performed ipa-server-upgrade - does this mean i'm on 4.4.4?).
>
> The command is shown below - note that i am skipping the conn check as my
> platforms security settings do not allow the SSH session to be established
> back on the master, all ports should be available to the application
> however.
>
> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
> --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>
> Directory Manager (existing master) password:
>
> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
> check queries IPA DNS directly and ignores /etc/hosts.)
> Continue? [no]: yes
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
>   [1/42]: creating directory server user
>   [2/42]: creating directory server instance
>   [3/42]: updating configuration in dse.ldif
>   [4/42]: restarting directory server
>   [5/42]: adding default schema
>   [6/42]: enabling memberof plugin
>   [7/42]: enabling winsync plugin
>   [8/42]: configuring replication version plugin
>   [9/42]: enabling IPA enrollment plugin
>   [10/42]: enabling ldapi
>   [11/42]: configuring uniqueness plugin
>   [12/42]: configuring uuid plugin
>   [13/42]: configuring modrdn plugin
>   [14/42]: configuring DNS plugin
>   [15/42]: enabling entryUSN plugin
>   [16/42]: configuring lockout plugin
>   [17/42]: configuring topology plugin
>   [18/42]: creating indices
>   [19/42]: enabling referential integrity plugin
>   [20/42]: configuring ssl for ds instance
>   [21/42]: configuring certmap.conf
>   [22/42]: configure autobind for root
>   [23/42]: configure new location for managed entries
>   [24/42]: configure dirsrv ccache
>   [25/42]: enabling SASL mapping fallback
>   [26/42]: restarting directory server
>   [27/42]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 4 seconds elapsed
> Update succeeded
>
>   [28/42]: adding sasl mappings to the directory
>   [29/42]: updating schema
>   [30/42]: setting Auto Member configuration
>   [31/42]: enabling S4U2Proxy delegation
>   [32/42]: importing CA certificates from LDAP
>   [33/42]: initializing group membership
>   [34/42]: adding master entry
>   [35/42]: initializing domain level
>   [36/42]: configuring Posix uid/gid generation
>   [37/42]: adding replication acis
>   [38/42]: enabling compatibility plugin
>   [39/42]: activating sidgen plugin
>   [40/42]: activating extdom plugin
>   [41/42]: tuning directory server
>   [42/42]: configuring directory to start on boot
> Done configuring directory server (dirsrv).
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
> seconds
>   [1/27]: creating certificate server user
>   [2/27]: configuring certificate server instance
>   [3/27]: stopping certificate server instance to update CS.cfg
>   [4/27]: backing up CS.cfg
>   [5/27]: disabling nonces
>   [6/27]: set up CRL publishing
>   [7/27]: enable PKIX certificate path discovery and validation
>   [8/27]: starting certificate server instance
>
> And here is stays and refuses to move on. The ipareplica-install.log log
> reports:
> 2017-05-18T08:40:07Z DEBUG wait_for_open_ports: localhost [8080, 8443]
> timeout 300
> 2017-05-18T08:40:09Z DEBUG Waiting until the CA is running
> 2017-05-18T08:40:09Z DEBUG request POST http://ipa2.SITE.net:8080/ca/
> admin/ca/getStatus
> 2017-05-18T08:40:09Z DEBUG request body ''
>
> I have tried and that port is indeed inaccessible but I can't establish a
> way to progress this issue from any of the the other log files. Also I have
> seen in the 4.4.4 release notes that IPv6 being disabled on the master can
> cause issues, re-enabling (at least in /etc/hosts) did not seem to help.
>
> If anyone is able to offer ideas that would be very much appreciated. I am
> tempted to remove the --setup-ca option to see if this helps.
>
> Thanks,
>
> Callum
>
>
>
> *0333 332   |  

Re: [Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
Hi All,

Just following on from this, I have performed an installation without
--setup-ca and it has completed successfully.

I now need to understand what impact this might have, is it the case that I
can still install/configure the CA component? Is there any documentation on
this action?

Also in the event of a failure of my master server (I only have these two)
will all my certificates be invalidated and lost or will the replica still
be able to handle these certificates until a time where a new master has
been created?

Thanks,

Callum


On Thu, May 18, 2017 at 9:57 AM Callum Guy  wrote:

> Hi All,
>
> I am currently stuck trying to setup the first replica of our master IPA
> server. I have tried a number of different approaches including escalating
> from a client and nothing is working for me. I perform a full OS reset each
> time I get stuck.
>
> I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this version
> however having performed ipa-server-upgrade - does this mean i'm on 4.4.4?).
>
> The command is shown below - note that i am skipping the conn check as my
> platforms security settings do not allow the SSH session to be established
> back on the master, all ports should be available to the application
> however.
>
> [root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
> --setup-dns --skip-conncheck --no-forwarders SITE.net.gpg
>
> Directory Manager (existing master) password:
>
> ipa : ERRORCould not resolve hostname ipa2.SITE.net usis
> check queries IPA DNS directly and ignores /etc/hosts.)
> Continue? [no]: yes
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
>   [1/42]: creating directory server user
>   [2/42]: creating directory server instance
>   [3/42]: updating configuration in dse.ldif
>   [4/42]: restarting directory server
>   [5/42]: adding default schema
>   [6/42]: enabling memberof plugin
>   [7/42]: enabling winsync plugin
>   [8/42]: configuring replication version plugin
>   [9/42]: enabling IPA enrollment plugin
>   [10/42]: enabling ldapi
>   [11/42]: configuring uniqueness plugin
>   [12/42]: configuring uuid plugin
>   [13/42]: configuring modrdn plugin
>   [14/42]: configuring DNS plugin
>   [15/42]: enabling entryUSN plugin
>   [16/42]: configuring lockout plugin
>   [17/42]: configuring topology plugin
>   [18/42]: creating indices
>   [19/42]: enabling referential integrity plugin
>   [20/42]: configuring ssl for ds instance
>   [21/42]: configuring certmap.conf
>   [22/42]: configure autobind for root
>   [23/42]: configure new location for managed entries
>   [24/42]: configure dirsrv ccache
>   [25/42]: enabling SASL mapping fallback
>   [26/42]: restarting directory server
>   [27/42]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 4 seconds elapsed
> Update succeeded
>
>   [28/42]: adding sasl mappings to the directory
>   [29/42]: updating schema
>   [30/42]: setting Auto Member configuration
>   [31/42]: enabling S4U2Proxy delegation
>   [32/42]: importing CA certificates from LDAP
>   [33/42]: initializing group membership
>   [34/42]: adding master entry
>   [35/42]: initializing domain level
>   [36/42]: configuring Posix uid/gid generation
>   [37/42]: adding replication acis
>   [38/42]: enabling compatibility plugin
>   [39/42]: activating sidgen plugin
>   [40/42]: activating extdom plugin
>   [41/42]: tuning directory server
>   [42/42]: configuring directory to start on boot
> Done configuring directory server (dirsrv).
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
> seconds
>   [1/27]: creating certificate server user
>   [2/27]: configuring certificate server instance
>   [3/27]: stopping certificate server instance to update CS.cfg
>   [4/27]: backing up CS.cfg
>   [5/27]: disabling nonces
>   [6/27]: set up CRL publishing
>   [7/27]: enable PKIX certificate path discovery and validation
>   [8/27]: starting certificate server instance
>
> And here is stays and refuses to move on. The ipareplica-install.log log
> reports:
> 2017-05-18T08:40:07Z DEBUG wait_for_open_ports: localhost [8080, 8443]
> timeout 300
> 2017-05-18T08:40:09Z DEBUG Waiting until the CA is running
> 2017-05-18T08:40:09Z DEBUG request POST
> http://ipa2.SITE.net:8080/ca/admin/ca/getStatus
> 2017-05-18T08:40:09Z DEBUG request body ''
>
> I have tried and that port is indeed inaccessible but I can't establish a
> way to progress this issue from any of the the other log files. Also I have
> seen in the 4.4.4 release notes that IPv6 being disabled on the master can
> cause issues, re-enabling (at least in /etc/hosts) did not seem to help.
>
> If anyone is able to offer ideas that would be very much 

[Freeipa-users] ipa-replica-install hangs: starting certificate server instance

2017-05-18 Thread Callum Guy
Hi All,

I am currently stuck trying to setup the first replica of our master IPA
server. I have tried a number of different approaches including escalating
from a client and nothing is working for me. I perform a full OS reset each
time I get stuck.

I'm running CentOS 7.2 with the FreeIPA 4.4.0 (rpm -q reports this version
however having performed ipa-server-upgrade - does this mean i'm on 4.4.4?).

The command is shown below - note that i am skipping the conn check as my
platforms security settings do not allow the SSH session to be established
back on the master, all ports should be available to the application
however.

[root@ipa2 ~]# ipa-replica-install --ip-address=172.24.0.101 --setup-ca
--setup-dns --skip-conncheck --no-forwarders SITE.net.gpg

Directory Manager (existing master) password:

ipa : ERRORCould not resolve hostname ipa2.SITE.net usis check
queries IPA DNS directly and ignores /etc/hosts.)
Continue? [no]: yes
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated time: 1 minute
  [1/42]: creating directory server user
  [2/42]: creating directory server instance
  [3/42]: updating configuration in dse.ldif
  [4/42]: restarting directory server
  [5/42]: adding default schema
  [6/42]: enabling memberof plugin
  [7/42]: enabling winsync plugin
  [8/42]: configuring replication version plugin
  [9/42]: enabling IPA enrollment plugin
  [10/42]: enabling ldapi
  [11/42]: configuring uniqueness plugin
  [12/42]: configuring uuid plugin
  [13/42]: configuring modrdn plugin
  [14/42]: configuring DNS plugin
  [15/42]: enabling entryUSN plugin
  [16/42]: configuring lockout plugin
  [17/42]: configuring topology plugin
  [18/42]: creating indices
  [19/42]: enabling referential integrity plugin
  [20/42]: configuring ssl for ds instance
  [21/42]: configuring certmap.conf
  [22/42]: configure autobind for root
  [23/42]: configure new location for managed entries
  [24/42]: configure dirsrv ccache
  [25/42]: enabling SASL mapping fallback
  [26/42]: restarting directory server
  [27/42]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 4 seconds elapsed
Update succeeded

  [28/42]: adding sasl mappings to the directory
  [29/42]: updating schema
  [30/42]: setting Auto Member configuration
  [31/42]: enabling S4U2Proxy delegation
  [32/42]: importing CA certificates from LDAP
  [33/42]: initializing group membership
  [34/42]: adding master entry
  [35/42]: initializing domain level
  [36/42]: configuring Posix uid/gid generation
  [37/42]: adding replication acis
  [38/42]: enabling compatibility plugin
  [39/42]: activating sidgen plugin
  [40/42]: activating extdom plugin
  [41/42]: tuning directory server
  [42/42]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
seconds
  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
  [3/27]: stopping certificate server instance to update CS.cfg
  [4/27]: backing up CS.cfg
  [5/27]: disabling nonces
  [6/27]: set up CRL publishing
  [7/27]: enable PKIX certificate path discovery and validation
  [8/27]: starting certificate server instance

And here is stays and refuses to move on. The ipareplica-install.log log
reports:
2017-05-18T08:40:07Z DEBUG wait_for_open_ports: localhost [8080, 8443]
timeout 300
2017-05-18T08:40:09Z DEBUG Waiting until the CA is running
2017-05-18T08:40:09Z DEBUG request POST
http://ipa2.SITE.net:8080/ca/admin/ca/getStatus
2017-05-18T08:40:09Z DEBUG request body ''

I have tried and that port is indeed inaccessible but I can't establish a
way to progress this issue from any of the the other log files. Also I have
seen in the 4.4.4 release notes that IPv6 being disabled on the master can
cause issues, re-enabling (at least in /etc/hosts) did not seem to help.

If anyone is able to offer ideas that would be very much appreciated. I am
tempted to remove the --setup-ca option to see if this helps.

Thanks,

Callum

-- 



*0333 332   |  www.x-on.co.uk   |   ** 
    
   * 
X-on is a trading name of Storacall Technology Ltd a limited company 
registered in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel 
Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the 
addressee(s) only. If you are not the intended recipient, please notify 
X-on immediately on +44(0)333 332  and delete the
message from your computer. If you are not a named addressee you must not 
use, disclose, disseminate, distribute, copy, 

[Freeipa-users] IMPORTANT: Migration of FreeIPA-users list to lists.fedorahosted.org

2017-05-18 Thread Martin Bašti

Dear FreeIPA-users subscribers,

due to various issues with the current mailing lists, the FreeIPA-users 
list is being migrated to a new provider, lists.fedorahosted.org.



Information about the new list:

E-mail address: freeipa-us...@lists.fedorahosted.org
Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/ 


List-Id: FreeIPA users list 


All subscribers will be automatically subscribed to the new mailing 
list, please update your email filters in advance.

The mass subscription will be done in 24 hours.

This mailing list will be set to read-only mode after migration.

Sorry for inconvenience,
Your FreeIPA developers

--
Martin Bašti
Software Engineer
Red Hat Czech

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