Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On Tue, Apr 08, 2014 at 05:22:46PM -0700, Shree wrote: Not sure if anyone read my last reply I was still not having any luck. Anyways I found the file which was causing it to contact the old IP address just a few minutes ago. Though I would share with you in case someone else may need it. I started going through the directory listed in the krb5.conf file [ includedir /var/lib/sss/pubconf/krb5.include.d/ ] Just one level up there was a file called kdcinfo.MYDOMAIN.COM which had the old IP address. I changed it to the new one and kinit started working fine. I was able to install ipa-client without any issues. I still cannot figure out why only one of my several servers behaved this way. Thanks This file is generated by SSSD and tells the IP address of a KDC that the SSSD discovered to libkrb5. The reason is that you want applications that rely on Kerberos configuration only (for example kinit) to be able to use the KDCs SSSD uses without having to duplicate information in both sssd.conf and krb5.conf and also make sure that both sssd and libkrb5 really talk to the same server. The file is normally generated when SSSD goes online after startup and should be removed either when SSSD goes offline for one reason or another or when SSSD is shut down. If the file was around even if SSSD was not running, then I'd say it was a bug. But I admit I haven't read this whole thread, so I'm not 100% what was going on before. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Not sure if anyone read my last reply I was still not having any luck. Anyways
I found the file which was causing it to contact the old IP address just a few
minutes ago. Though I would share with you in case someone else may need it. I
started going through the directory listed in the krb5.conf file
[ includedir /var/lib/sss/pubconf/krb5.include.d/ ]
Just one level up there was a file called kdcinfo.MYDOMAIN.COM which had the
old IP address. I changed it to the new one and kinit started working fine. I
was able to install ipa-client without any issues. I still cannot figure out
why only one of my several servers behaved this way.
Thanks
Shreeraj
Change is the only Constant !
On Monday, March 31, 2014 8:22 AM, Shree shreerajkarul...@yahoo.com wrote:
Excellent Rob
I see that it is trying the IP address on the main master (ldap.mydomain) and
not the ldap2.mydomain. So how do I fix it or where do I find that?
Shreeraj
Change is the only Constant !
On Monday, March 31, 2014 8:09 AM, Rob Crittenden rcrit...@redhat.com wrote:
Shree wrote:
Rob
This is what I get.
Realm is case-sensitive, try skarul...@mydomain.com
rob
[root@www ~]# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
[14858] 1396278013.584391: Getting initial credentials for
skarul...@mydomain.com
[14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com
[14858] 1396278013.585470: Retrying AS request with master KDC
[14858] 1396278013.585492: Getting initial credentials for
skarul...@mydomain.com
[14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com
(master)
kinit: Cannot find KDC for requested realm while getting
initial credentials
[root@www ~]#
Shreeraj
Change is the only Constant !
On Monday, March 31, 2014 7:02 AM, Rob Crittenden rcrit...@redhat.com
wrote:
Shree wrote:
Martin
First of all thank you so much for your detailed analysis. I got a
chance to finally take a look at it today. I tried your suggested
changes to the /etc/krb5.conf and I now get the following
response.
[root@www mailto:root@www ~]# kinit
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
initial credentials
[root@www mailto:root@www ~]# kinit skarulkar
kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
initial credentials
[root@www mailto:root@www ~]# vi /etc/krb5.conf
[root@www mailto:root@www ~]# kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
kinit: Cannot find KDC for requested realm while getting initial
credentials
Now I have seen this issue earlier in the project but I don't remember
what I did to fix this.
ldap.mydomain.com is our
primary which connects to ldap2.mydomain.com
that exists in a separate VLAN through specific ACLs in the firewall.
They sync with each other fine. My clients are only able to talk to
ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
ldap2 I only seem to have issue with this last one?
I have even tried dropping a test VM in the same VLAN and it had no
issues joining the IPA. So that rules out any ACL misconfigurations to
this VLAN.
Did you try the tracing that Martin suggested?
rob
Shreeraj
Change is the only Constant !
On Tuesday, March 25, 2014 12:55 AM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would
check that the generated /etc/krb5.conf is
correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install
does not
generate 2 domain_realm mappings unless client domain is different that
server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote:
Martin
First of all thank you so much for your detailed analysis. I got a
chance to finally take a look at it today. I tried your suggested
changes to the /etc/krb5.conf and I now get the following response.
[root@www ~]# kinit
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
initial credentials
[root@www ~]# kinit skarulkar
kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
initial credentials
[root@www ~]# vi /etc/krb5.conf
[root@www ~]# kinit skarul...@mydomain.com
kinit: Cannot find KDC for requested realm while getting initial credentials
Now I have seen this issue earlier in the project but I don't remember
what I did to fix this.
ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
that exists in a separate VLAN through specific ACLs in the firewall.
They sync with each other fine. My clients are only able to talk to
ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
ldap2 I only seem to have issue with this last one?
I have even tried dropping a test VM in the same VLAN and it had no
issues joining the IPA. So that rules out any ACL misconfigurations to
this VLAN.
Did you try the tracing that Martin suggested?
rob
Shreeraj
Change is the only Constant !
On Tuesday, March 25, 2014 12:55 AM, Martin Kosek mko...@redhat.com wrote:
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would check that the generated /etc/krb5.conf is
correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install
does not
generate 2 domain_realm mappings unless client domain is different that
server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during
ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:
# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
You will be then able to see if it really connects to right IP address which
would enable you to debug further.
Martin
On 03/24/2014 07:20 PM, Shree wrote:
If you look at the attached logs, you can see it is going to the
correct dns server. dig information is also correct. There is something
else going on I can figure out what?
Shreeraj
Change is the only Constant !
On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 03/21/2014 07:44 PM, Shree wrote:
Hi
Attaching the install log. It complains about unable to reach
certain ports, however my tests by using telnet were successful.
Also to refresh your memory the client should be reaching for
the replica lda2.mydomain.com and not ldap.mydomain.com which it
does for the most part but I found a couple of instances of
ldap.mydomain.com in the log. Let me know what you find. I can't
believe I migrated over 40 servers and only this one refuses to
install ipa-client.
If it is getting to the wrong server then it is either looking at
the wrong DNS server (see resolve.conf) which is telling it to use
the wrong IPA server (may be from some old try/POC) or it has some
explicit entries entered in /etc/hosts.
Shreeraj
Change is the only Constant !
On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
On 03/19/2014 10:37 PM, Shree wrote:
Hello
I was able to successfully move all my clients to
the replica except on the process I had to upgrade the
client to ipa-client-3.0.0-37.el6.x86_64 and some
times run a --uninstall
. Bit it works for the most part. Have been
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Rob
This is what I get.
[root@www ~]# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
[14858] 1396278013.584391: Getting initial credentials for
skarul...@mydomain.com
[14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com
[14858] 1396278013.585470: Retrying AS request with master KDC
[14858] 1396278013.585492: Getting initial credentials for
skarul...@mydomain.com
[14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com (master)
kinit: Cannot find KDC for requested realm while getting initial credentials
[root@www ~]#
Shreeraj
Change is the only Constant !
On Monday, March 31, 2014 7:02 AM, Rob Crittenden rcrit...@redhat.com wrote:
Shree wrote:
Martin
First of all thank you so much for your detailed analysis. I got a
chance to finally take a look at it today. I tried your suggested
changes to the /etc/krb5.conf and I now get the following response.
[root@www ~]# kinit
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
initial credentials
[root@www ~]# kinit skarulkar
kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
initial credentials
[root@www ~]# vi /etc/krb5.conf
[root@www ~]# kinit skarul...@mydomain.com
kinit: Cannot find KDC for requested realm while getting initial credentials
Now I have seen this issue earlier in the project but I don't remember
what I did to fix this.
ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
that exists in a separate VLAN through specific ACLs in the firewall.
They sync with each other fine. My clients are only able to talk to
ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
ldap2 I only seem to have issue with this last one?
I have even tried dropping a test VM in the same VLAN and it had no
issues joining the IPA. So that rules out any ACL misconfigurations to
this VLAN.
Did you try the tracing that Martin suggested?
rob
Shreeraj
Change is the only Constant !
On Tuesday, March 25, 2014 12:55 AM, Martin Kosek mko...@redhat.com wrote:
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would check that the generated /etc/krb5.conf is
correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install
does not
generate 2 domain_realm mappings unless client domain is different that
server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during
ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:
# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
You will be then able to see if it really connects to right IP address which
would enable you to debug further.
Martin
On 03/24/2014 07:20 PM, Shree wrote:
If you look at the attached logs, you can see it is going to the
correct dns server. dig information is also correct. There is something
else going on I can figure out what?
Shreeraj
Change is the only Constant !
On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 03/21/2014 07:44 PM, Shree wrote:
Hi
Attaching the install log. It complains about unable to reach
certain ports, however my tests by using telnet were successful.
Also to refresh your memory the client should be reaching for
the replica lda2.mydomain.com and not ldap.mydomain.com which it
does for the most part but I found a couple of instances of
ldap.mydomain.com in the log. Let me know what you find. I can't
believe I migrated over 40 servers and only this one refuses to
install
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote:
Rob
This is what I get.
Realm is case-sensitive, try skarul...@mydomain.com
rob
[root@www ~]# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
[14858] 1396278013.584391: Getting initial credentials for
skarul...@mydomain.com
[14858] 1396278013.584975: Sending request (188 bytes) to mydomain.com
[14858] 1396278013.585470: Retrying AS request with master KDC
[14858] 1396278013.585492: Getting initial credentials for
skarul...@mydomain.com
[14858] 1396278013.585848: Sending request (188 bytes) to mydomain.com
(master)
kinit: Cannot find KDC for requested realm while getting initial credentials
[root@www ~]#
Shreeraj
Change is the only Constant !
On Monday, March 31, 2014 7:02 AM, Rob Crittenden rcrit...@redhat.com
wrote:
Shree wrote:
Martin
First of all thank you so much for your detailed analysis. I got a
chance to finally take a look at it today. I tried your suggested
changes to the /etc/krb5.conf and I now get the following response.
[root@www mailto:root@www ~]# kinit
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting
initial credentials
[root@www mailto:root@www ~]# kinit skarulkar
kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting
initial credentials
[root@www mailto:root@www ~]# vi /etc/krb5.conf
[root@www mailto:root@www ~]# kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
kinit: Cannot find KDC for requested realm while getting initial
credentials
Now I have seen this issue earlier in the project but I don't remember
what I did to fix this.
ldap.mydomain.com is our primary which connects to ldap2.mydomain.com
that exists in a separate VLAN through specific ACLs in the firewall.
They sync with each other fine. My clients are only able to talk to
ldap2.mydomain.com. And out of 40 + clients that I moved from ldap to
ldap2 I only seem to have issue with this last one?
I have even tried dropping a test VM in the same VLAN and it had no
issues joining the IPA. So that rules out any ACL misconfigurations to
this VLAN.
Did you try the tracing that Martin suggested?
rob
Shreeraj
Change is the only Constant !
On Tuesday, March 25, 2014 12:55 AM, Martin Kosek mko...@redhat.com
mailto:mko...@redhat.com wrote:
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would check that the generated /etc/krb5.conf is
correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install
does not
generate 2 domain_realm mappings unless client domain is different that
server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during
ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
mailto:skarul...@mydomain.com mailto:skarul...@mydomain.com
Then it will be easier to troubleshoot. To get more information what
kinit
actually does, try enabling a trace:
# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
mailto:skarul...@mydomain.com
mailto:skarul...@mydomain.com mailto:skarul...@mydomain.com
You will be then able to see if it really connects to right IP
address which
would enable you to debug further.
Martin
On 03/24/2014 07:20 PM, Shree wrote:
If you look at the attached logs, you can see it is going to the
correct dns server. dig information is also correct. There is something
else going on I can figure out what?
Shreeraj
Change is the only Constant !
On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com
mailto:d...@redhat.com mailto:d...@redhat.com wrote:
On 03/21/2014 07:44 PM, Shree wrote:
Hi
Attaching the install log. It complains about unable
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Martin
First of all thank you so much for your detailed analysis. I got a chance to
finally take a look at it today. I tried your suggested changes to the
/etc/krb5.conf and I now get the following response.
[root@www ~]# kinit
kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial
credentials
[root@www ~]# kinit skarulkar
kinit: Cannot contact any KDC for realm ''MYDOMAIN.COM' while getting initial
credentials
[root@www ~]# vi /etc/krb5.conf
[root@www ~]# kinit skarul...@mydomain.com
kinit: Cannot find KDC for requested realm while getting initial credentials
Now I have seen this issue earlier in the project but I don't remember what I
did to fix this.
ldap.mydomain.com is our primary which connects to ldap2.mydomain.com that
exists in a separate VLAN through specific ACLs in the firewall. They sync
with each other fine. My clients are only able to talk to ldap2.mydomain.com.
And out of 40 + clients that I moved from ldap to ldap2 I only seem to have
issue with this last one?
I have even tried dropping a test VM in the same VLAN and it had no issues
joining the IPA. So that rules out any ACL misconfigurations to this VLAN.
Shreeraj
Change is the only Constant !
On Tuesday, March 25, 2014 12:55 AM, Martin Kosek mko...@redhat.com wrote:
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would check that the generated /etc/krb5.conf is correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install does not
generate 2 domain_realm mappings unless client domain is different that server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarul...@mydomain.com
Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:
# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
You will be then able to see if it really connects to right IP address which
would enable you to debug further.
Martin
On 03/24/2014 07:20 PM, Shree wrote:
If you look at the attached logs, you can see it is going to the correct dns
server. dig information is also correct. There is something else going on I
can figure out what?
Shreeraj
Change is the only Constant !
On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com wrote:
On 03/21/2014 07:44 PM, Shree wrote:
Hi
Attaching the install log. It complains about unable to reach
certain ports, however my tests by using telnet were successful.
Also to refresh your memory the client should be reaching for
the replica lda2.mydomain.com and not ldap.mydomain.com which it
does for the most part but I found a couple of instances of
ldap.mydomain.com in the log. Let me know what you find. I can't
believe I migrated over 40 servers and only this one refuses to
install ipa-client.
If it is getting to the wrong server then it is either looking at
the wrong DNS server (see resolve.conf) which is telling it to use
the wrong IPA server (may be from some old try/POC) or it has some
explicit entries entered in /etc/hosts.
Shreeraj
Change is the only Constant !
On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com wrote:
On 03/19/2014 10:37 PM, Shree wrote:
Hello
I was able to successfully move all my clients to
the replica except on the process I had to upgrade the
client to ipa-client-3.0.0-37.el6.x86_64 and some
times run a --uninstall
. Bit it works for the most part. Have been
struggling with one last host with errors like below.
I have tested the port connectivity using telnet and
netcat commands but the
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would check that the generated /etc/krb5.conf is correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install does not
generate 2 domain_realm mappings unless client domain is different that server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarul...@mydomain.com
Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:
# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
You will be then able to see if it really connects to right IP address which
would enable you to debug further.
Martin
On 03/24/2014 07:20 PM, Shree wrote:
If you look at the attached logs, you can see it is going to the correct dns
server. dig information is also correct. There is something else going on I
can figure out what?
Shreeraj
Change is the only Constant !
On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com wrote:
On 03/21/2014 07:44 PM, Shree wrote:
Hi
Attaching the install log. It complains about unable to reach
certain ports, however my tests by using telnet were successful.
Also to refresh your memory the client should be reaching for
the replica lda2.mydomain.com and not ldap.mydomain.com which it
does for the most part but I found a couple of instances of
ldap.mydomain.com in the log. Let me know what you find. I can't
believe I migrated over 40 servers and only this one refuses to
install ipa-client.
If it is getting to the wrong server then it is either looking at
the wrong DNS server (see resolve.conf) which is telling it to use
the wrong IPA server (may be from some old try/POC) or it has some
explicit entries entered in /etc/hosts.
Shreeraj
Change is the only Constant !
On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com wrote:
On 03/19/2014 10:37 PM, Shree wrote:
Hello
I was able to successfully move all my clients to
the replica except on the process I had to upgrade the
client to ipa-client-3.0.0-37.el6.x86_64 and some
times run a --uninstall
. Bit it works for the most part. Have been
struggling with one last host with errors like below.
I have tested the port connectivity using telnet and
netcat commands but the install thinks these ports are
blocked?
kerberos authentication failed
kinit: Cannot contact any KDC for realm
'MYDOMAIN.COM' while getting initial credentials
Please make sure the following ports are opened
in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88
has to be open)
Also note that following ports are necessary for
ipa-client working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file
/etc/sssd/sssd.conf was moved to
/etc/sssd/sssd.conf.deleted
Restoring client configuration files
Client uninstall complete.
[root@www /]#
In the /var/log/ipaclient-install.log I also see
things like below. I get Autodiscovery failures but I
am manually entering things and they have been
working.
2014-03-19T21:13:47Z DEBUG Found:
cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
2014-03-19T21:13:47Z DEBUG Discovery result:
Success; server=ldap2.mydomain.com,
domain=mydomain.com, kdc=ldap.mydomain.com,
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
If you look at the attached logs, you can see it is going to the correct dns server. dig information is also correct. There is something else going on I can figure out what? Shreeraj Change is the only Constant ! On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com wrote: On 03/21/2014 07:44 PM, Shree wrote: Hi Attaching the install log. It complains about unable to reach certain ports, however my tests by using telnet were successful. Also to refresh your memory the client should be reaching for the replica lda2.mydomain.com and not ldap.mydomain.com which it does for the most part but I found a couple of instances of ldap.mydomain.com in the log. Let me know what you find. I can't believe I migrated over 40 servers and only this one refuses to install ipa-client. If it is getting to the wrong server then it is either looking at the wrong DNS server (see resolve.conf) which is telling it to use the wrong IPA server (may be from some old try/POC) or it has some explicit entries entered in /etc/hosts. Shreeraj Change is the only Constant ! On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com wrote: On 03/19/2014 10:37 PM, Shree wrote: Hello I was able to successfully move all my clients to the replica except on the process I had to upgrade the client to ipa-client-3.0.0-37.el6.x86_64 and some times run a --uninstall . Bit it works for the most part. Have been struggling with one last host with errors like below. I have tested the port connectivity using telnet and netcat commands but the install thinks these ports are blocked? kerberos authentication failed kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Installation failed. Rolling back changes. Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted Restoring client configuration files Client uninstall complete. [root@www /]# In the /var/log/ipaclient-install.log I also see things like below. I get Autodiscovery failures but I am manually entering things and they have been working. 2014-03-19T21:13:47Z DEBUG Found: cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com 2014-03-19T21:13:47Z DEBUG Discovery result: Success; server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, basedn=dc=mydomain,dc=com 2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com 2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured. 2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover cannot work with this configuration. 2014-03-19T21:13:47Z INFO If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Ok. I would guess you have some DNS issue. But it is hard to tell without the entire ipaclient-install.log of the failed installation. Martin -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On 03/21/2014 07:44 PM, Shree wrote: Hi Attaching the install log. It complains about unable to reach certain ports, however my tests by using telnet were successful. Also to refresh your memory the client should be reaching for the replica lda2.mydomain.com and not ldap.mydomain.com which it does for the most part but I found a couple of instances of ldap.mydomain.com in the log. Let me know what you find. I can't believe I migrated over 40 servers and only this one refuses to install ipa-client. If it is getting to the wrong server then it is either looking at the wrong DNS server (see resolve.conf) which is telling it to use the wrong IPA server (may be from some old try/POC) or it has some explicit entries entered in /etc/hosts. Shreeraj Change is the only Constant ! On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com wrote: On 03/19/2014 10:37 PM, Shree wrote: Hello I was able to successfully move all my clients to the replica except on the process I had to upgrade the client to ipa-client-3.0.0-37.el6.x86_64 and some times run a --uninstall . Bit it works for the most part. Have been struggling with one last host with errors like below. I have tested the port connectivity using telnet and netcat commands but the install thinks these ports are blocked? kerberos authentication failed kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Installation failed. Rolling back changes. Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted Restoring client configuration files Client uninstall complete. [root@www mailto:root@www /]# In the /var/log/ipaclient-install.log I also see things like below. I get Autodiscovery failures but I am manually entering things and they have been working. 2014-03-19T21:13:47Z DEBUG Found: cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com 2014-03-19T21:13:47Z DEBUG Discovery result: Success; server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, basedn=dc=mydomain,dc=com 2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com 2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured. 2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover cannot work with this configuration. 2014-03-19T21:13:47Z INFO If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Ok. I would guess you have some DNS issue. But it is hard to tell without the entire ipaclient-install.log of the failed installation. Martin -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Hi Attaching the install log. It complains about unable to reach certain ports, however my tests by using telnet were successful. Also to refresh your memory the client should be reaching for the replica lda2.mydomain.com and not ldap.mydomain.com which it does for the most part but I found a couple of instances of ldap.mydomain.com in the log. Let me know what you find. I can't believe I migrated over 40 servers and only this one refuses to install ipa-client. Shreeraj Change is the only Constant ! On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com wrote: On 03/19/2014 10:37 PM, Shree wrote: Hello I was able to successfully move all my clients to the replica except on the process I had to upgrade the client to ipa-client-3.0.0-37.el6.x86_64 and some times run a --uninstall . Bit it works for the most part. Have been struggling with one last host with errors like below. I have tested the port connectivity using telnet and netcat commands but the install thinks these ports are blocked? kerberos authentication failed kinit: Cannot contact any KDC for realm 'MYDOMAIN.COM' while getting initial credentials Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Installation failed. Rolling back changes. Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted Restoring client configuration files Client uninstall complete. [root@www /]# In the /var/log/ipaclient-install.log I also see things like below. I get Autodiscovery failures but I am manually entering things and they have been working. 2014-03-19T21:13:47Z DEBUG Found: cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com 2014-03-19T21:13:47Z DEBUG Discovery result: Success; server=ldap2.mydomain.com, domain=mydomain.com, kdc=ldap.mydomain.com, basedn=dc=mydomain,dc=com 2014-03-19T21:13:47Z DEBUG Validated servers: ldap2.mydomain.com 2014-03-19T21:13:47Z WARNING The failure to use DNS to find your IPA server indicates that your resolv.conf file is not properly configured. 2014-03-19T21:13:47Z INFO Autodiscovery of servers for failover cannot work with this configuration. 2014-03-19T21:13:47Z INFO If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Ok. I would guess you have some DNS issue. But it is hard to tell without the entire ipaclient-install.log of the failed installation. Martin ipaclient-install.log Description: Binary data ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Can you help me figure out, below is some info on the existing working
configuration one one of the clients
1)Sudo version 1.7.4p5
2)[root@test500 ~]# sssd --version
1.9.2
3)These are the uncommented lines in /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = mydomain.com
[domain/mydomain.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = mydomain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = dns.mydomain.com
chpass_provider = ipa
ipa_server = ldap.mydomain.com
ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com
ldap_tls_cacert = /etc/ipa/ca.crt
===
4)And these are the options in /etc/nsswitch.conf
sudoers: files ldap
passwd: files sss
shadow: files sss
group: files sss
Shreeraj
Change is the only Constant !
On Thursday, February 20, 2014 7:20 AM, Dmitri Pal d...@redhat.com wrote:
On 02/19/2014 06:52 PM, Shree wrote:
Rob
You were right. After upgrading the client to the
ipa-client-3.0.0-37.el6.x86_64 version I started seeing a
warning during the client install that went something like
=
Autodiscovery of servers for failover cannot work with this
configuration.
If you proceed with the installation, services will be
configured to always access the discovered server for all
operations and will not fail over to other servers in case of
failure.
Proceed with fixed values and no DNS discovery? [no]: yes
=
I continued by saying yes because in my case the master and the replica are in
different VLANs and failover is not possible for me. I have tried in two hosts
successfully and am hoping that does the trick.
However I see one issue immediately that my sudo access does not seem to work
now on the newly added clients! Do you know what might be happening?
Are you using SSSD and SUDO integration?
What version of sudo and sssd?
See if this would help:
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Shree wrote:
root@test500 ~]# rpm -q ipa-client
ipa-client-2.2.0-16.el6.x86_64
[root@test500 ~]#
You'll definitely want to update to 2.2.0-17, that fixes
CVE-2012-5484
Unfortunately our logging around discovery was rather
horrible in 2.2.x
so it is difficult to know exactly what is going on.
I believe the problem is that it is still doing DNS
discovery even
though you've passed in a server name so it is setting
up Kerberos to
look up the KDC which it finds but can't talk to.
This should be fixed in the 3.0 packages so updating to
those is the
preferred solution.
For 2.x you can try the --force option which should make
it skip some
discovery.
rob
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 1:17 PM, Rob
Crittenden
rcrit...@redhat.com wrote:
Shree wrote:
Here are a couple of things
[skarulkar@ldap2 mailto:skarulkar@ldap2 ~]$ rpm -q ipa-client
ipa-client-3.0.0-26.el6_4.4.x86_64
What is the version on the client that is failing
to enroll?
rob
and my /etc/krb5.conf looks like ..
===
includedir
/var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
===
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 12:59 PM, Rob
Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
Shree wrote:
1) I have got a step furthur. My
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On 02/20/2014 02:58 PM, Shree wrote:
Can you help me figure out, below is some info on the existing working
configuration one one of the clients
1)Sudo version 1.7.4p5
2)[root@test500 ~]# sssd --version
1.9.2
3)These are the uncommented lines in /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = mydomain.com
[domain/mydomain.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = mydomain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = dns.mydomain.com
chpass_provider = ipa
ipa_server = ldap.mydomain.com
ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com
ldap_tls_cacert = /etc/ipa/ca.crt
===
4)And these are the options in /etc/nsswitch.conf
sudoers:files ldap
passwd: files sss
shadow: files sss
group: files sss
Shreeraj
Change is the only Constant !
On Thursday, February 20, 2014 7:20 AM, Dmitri Pal d...@redhat.com
wrote:
On 02/19/2014 06:52 PM, Shree wrote:
Rob
You were right. After upgrading the client to the
ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning
during the client install that went something like
=
Autodiscovery of servers for failover cannot work with this
configuration.
If you proceed with the installation, services will be configured to
always access the discovered server for all operations and will not
fail over to other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
=
I continued by saying yes because in my case the master and the
replica are in different VLANs and failover is not possible for me. I
have tried in two hosts successfully and am hoping that does the trick.
However I see one issue immediately that my sudo access does not seem
to work now on the newly added clients! Do you know what might be
happening?
Are you using SSSD and SUDO integration?
What version of sudo and sssd?
See if this would help:
http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
Shree wrote:
root@test500 mailto:root@test500 ~]# rpm -q ipa-client
ipa-client-2.2.0-16.el6.x86_64
[root@test500 mailto:root@test500 ~]#
You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484
Unfortunately our logging around discovery was rather horrible in 2.2.x
so it is difficult to know exactly what is going on.
I believe the problem is that it is still doing DNS discovery even
though you've passed in a server name so it is setting up Kerberos to
look up the KDC which it finds but can't talk to.
This should be fixed in the 3.0 packages so updating to those is the
preferred solution.
For 2.x you can try the --force option which should make it skip some
discovery.
rob
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
Shree wrote:
Here are a couple of things
[skarulkar@ldap2 mailto:skarulkar@ldap2 mailto:skarulkar@ldap2
mailto:skarulkar@ldap2 ~]$ rpm -q ipa-client
ipa-client-3.0.0-26.el6_4.4.x86_64
What is the version on the client that is failing to enroll?
rob
and my /etc/krb5.conf looks like ..
===
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
===
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com
mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
Shree wrote:
1) I have got a step furthur. My replica is not running CA
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Dmitri, Rob, Lucas et al. Thank you for all your help and patience and pointing me to the right direction. I was able to fix most of my issues. My setup is a little complex where I am trying to have a master and the replica in different networks and are in sync + each of them is serving a different set of hosts. Shreeraj Change is the only Constant ! On Thursday, February 20, 2014 2:20 PM, Dmitri Pal d...@redhat.com wrote: On 02/20/2014 02:58 PM, Shree wrote: Can you help me figure out, below is some info on the existing working configuration one one of the clients 1)Sudo version 1.7.4p5 2)[root@test500 ~]# sssd --version 1.9.2 3)These are the uncommented lines in /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = mydomain.com [domain/mydomain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = mydomain.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = dns.mydomain.com chpass_provider = ipa ipa_server = ldap.mydomain.com ldap_netgroup_search_base = cn=ng,cn=compat,dc=mydomain,dc=com ldap_tls_cacert = /etc/ipa/ca.crt === 4)And these are the options in /etc/nsswitch.conf sudoers: files ldap passwd: files sss shadow: files sss group: files sss Shreeraj Change is the only Constant ! On Thursday, February 20, 2014 7:20 AM, Dmitri Pal d...@redhat.com wrote: On 02/19/2014 06:52 PM, Shree wrote: Rob You were right. After upgrading the client to the ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning during the client install that went something like = Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: yes = I continued by saying yes because in my case the master and the replica are in different VLANs and failover is not possible for me. I have tried in two hosts successfully and am hoping that does the trick. However I see one issue immediately that my sudo access does not seem to work now on the newly added clients! Do you know what might be happening? Are you using SSSD and SUDO integration? What version of sudo and sssd? See if this would help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf Shreeraj Change is the only Constant ! On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: root@test500 ~]# rpm -q ipa-client ipa-client-2.2.0-16.el6.x86_64 [root@test500 ~]# You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484 Unfortunately our logging around discovery was rather horrible in 2.2.x so it is difficult to know exactly what is going on. I believe the problem is that it is still doing DNS discovery even though you've passed in a server name so it is setting up Kerberos to look up the KDC which it finds but can't talk to. This should be fixed in the 3.0 packages so updating to those is the preferred solution. For 2.x you can try the --force option which should make it skip some discovery. rob Shreeraj Change is the only Constant ! On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: Here are a couple of things
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Guys Any word on this? New logs are attached to the email. I am still not able to add clients using the replica. Let me know if you need any other information and thanks for you help. Shreeraj Change is the only Constant ! On Tuesday, February 18, 2014 1:18 PM, Shree shreerajkarul...@yahoo.com wrote: 1) I have got a step furthur. My replica is not running CA Service. To achieve this I had to remove the existing cert with this command pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force Now the replica looks like this skarulkar@ldap2 tmp]$ sudo ipactl status [sudo] password for skarulkar: Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [skarulkar@ldap2 tmp]$ 2) I am still not able to add client using ipa-client-install using the replica. Logs for replica install and client install are attached. Shreeraj Change is the only Constant ! On Tuesday, February 18, 2014 11:31 AM, Shree shreerajkarul...@yahoo.com wrote: Rob The logs are attached in the email chain. If you need fresh ones, I can try to replicate it again. Shreeraj Change is the only Constant ! On Tuesday, February 18, 2014 11:19 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: Rob I am giving it a fresh start and I notice similar issues. 1) I wasn't able to use the --setup-ca while running the ipa-replica-install on the replica. It stopped the install after the ntpd step see below. Done configuring NTP daemon (ntpd). A CA is already configured on this system. This is left over from a previous failed installation. If the CA install fails early enough we don't log the fact that it was installed so the uninstall doesn't clean it up. 2) So I tried my install command again without the --setup-ca option. It went furthur although it completed it show one error see below. MY COMMAND: -- ipa-replica-install /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck the skip-conncheck was needed to complete the install. Connections checks were manually done. 14/31]: configuring lockout plugin [15/31]: creating indices [16/31]: enabling referential integrity plugin [17/31]: configuring ssl for ds instance ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-MYDOMAIN.COM -n Server-Cert -p /etc/dirsrv/slapd-MYDOMAIN.COM/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv MYDOMAIN.COM' returned non-zero exit status 1 [18/31]: configuring certmap.conf [19/31]: configure autobind for root . Without logs there is no way to diagnose. This could leave you in a situation where the certificate fails to renew in 2 years and IPA suddenly stops working. 3) The replica installed fine I can access the same database from the replica's website. 4) I cannot add new clients. MY COMMAND: -- ipa-client-install --domain=mydomain.com --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d ldap.mydomain.com = master ldap2.mydomain.com = replica No idea without seeing the logs. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote: 1) I have got a step furthur. My replica is not running CA Service. To achieve this I had to remove the existing cert with this command pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force Now the replica looks like this skarulkar@ldap2 tmp]$ sudo ipactl status [sudo] password for skarulkar: Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [skarulkar@ldap2 tmp]$ The tracking failed with: 2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library: Improper format of Kerberos configuration file. It looks like it failed on this for most if not all the tracking. What does /etc/krb5.conf look like? 2) I am still not able to add client using ipa-client-install using the replica. The temporary krb5.conf that is used during enrollment has dns_lookup_kdc=True so it is probably trying to contact the other KDC and failing. What is the output of: $ rpm -q ipa-client rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Here are a couple of things
[skarulkar@ldap2 ~]$ rpm -q ipa-client
ipa-client-3.0.0-26.el6_4.4.x86_64
and my /etc/krb5.conf looks like ..
===
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
===
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Shree wrote:
1) I have got a step furthur. My replica is not running CA Service. To
achieve this I had to remove the existing cert with this command
pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force
Now the replica looks like this
skarulkar@ldap2 tmp]$ sudo ipactl status
[sudo] password for skarulkar:
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING
[skarulkar@ldap2 tmp]$
The tracking failed with:
2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library:
Improper format of Kerberos configuration file.
It looks like it failed on this for most if not all the tracking. What
does /etc/krb5.conf look like?
2) I am still not able to add client using ipa-client-install using the
replica.
The temporary krb5.conf that is used during enrollment has
dns_lookup_kdc=True so it is probably trying to contact the other KDC
and failing.
What is the output of:
$ rpm -q ipa-client
rob___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
root@test500 ~]# rpm -q ipa-client
ipa-client-2.2.0-16.el6.x86_64
[root@test500 ~]#
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Shree wrote:
Here are a couple of things
[skarulkar@ldap2 ~]$ rpm -q ipa-client
ipa-client-3.0.0-26.el6_4.4.x86_64
What is the version on the client that is failing to enroll?
rob
and my /etc/krb5.conf looks like ..
===
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
===
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden
rcrit...@redhat.com wrote:
Shree wrote:
1) I have got a step furthur. My replica is not running CA Service. To
achieve this I had to remove the existing cert with this command
pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force
Now the replica looks like this
skarulkar@ldap2 mailto:skarulkar@ldap2 tmp]$ sudo ipactl status
[sudo] password for skarulkar:
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING
[skarulkar@ldap2 mailto:skarulkar@ldap2 tmp]$
The tracking failed with:
2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library:
Improper format of Kerberos configuration file.
It looks like it failed on this for most if not all the tracking. What
does /etc/krb5.conf look like?
2) I am still not able to add client using ipa-client-install using the
replica.
The temporary krb5.conf that is used during enrollment has
dns_lookup_kdc=True so it is probably trying to contact the other KDC
and failing.
What is the output of:
$ rpm -q ipa-client
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote:
root@test500 ~]# rpm -q ipa-client
ipa-client-2.2.0-16.el6.x86_64
[root@test500 ~]#
You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484
Unfortunately our logging around discovery was rather horrible in 2.2.x
so it is difficult to know exactly what is going on.
I believe the problem is that it is still doing DNS discovery even
though you've passed in a server name so it is setting up Kerberos to
look up the KDC which it finds but can't talk to.
This should be fixed in the 3.0 packages so updating to those is the
preferred solution.
For 2.x you can try the --force option which should make it skip some
discovery.
rob
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden
rcrit...@redhat.com wrote:
Shree wrote:
Here are a couple of things
[skarulkar@ldap2 mailto:skarulkar@ldap2 ~]$ rpm -q ipa-client
ipa-client-3.0.0-26.el6_4.4.x86_64
What is the version on the client that is failing to enroll?
rob
and my /etc/krb5.conf looks like ..
===
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
===
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
Shree wrote:
1) I have got a step furthur. My replica is not running CA Service. To
achieve this I had to remove the existing cert with this command
pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force
Now the replica looks like this
skarulkar@ldap2 mailto:skarulkar@ldap2 mailto:skarulkar@ldap2
mailto:skarulkar@ldap2 tmp]$ sudo ipactl status
[sudo] password for skarulkar:
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING
[skarulkar@ldap2 mailto:skarulkar@ldap2 mailto:skarulkar@ldap2
mailto:skarulkar@ldap2 tmp]$
The tracking failed with:
2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library:
Improper format of Kerberos configuration file.
It looks like it failed on this for most if not all the tracking. What
does /etc/krb5.conf look like?
2) I am still not able to add client using ipa-client-install
using the
replica.
The temporary krb5.conf that is used during enrollment has
dns_lookup_kdc=True so it is probably trying to contact the other KDC
and failing.
What is the output of:
$ rpm -q ipa-client
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Rob
You were right. After upgrading the client to the
ipa-client-3.0.0-37.el6.x86_64 version I started seeing a warning during the
client install that went something like
=
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always
access the discovered server for all operations and will not fail over to other
servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]: yes
=
I continued by saying yes because in my case the master and the replica are in
different VLANs and failover is not possible for me. I have tried in two hosts
successfully and am hoping that does the trick.
However I see one issue immediately that my sudo access does not seem to work
now on the newly added clients! Do you know what might be happening?
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 2:21 PM, Rob Crittenden rcrit...@redhat.com
wrote:
Shree wrote:
root@test500 ~]# rpm -q ipa-client
ipa-client-2.2.0-16.el6.x86_64
[root@test500 ~]#
You'll definitely want to update to 2.2.0-17, that fixes CVE-2012-5484
Unfortunately our logging around discovery was rather horrible in 2.2.x
so it is difficult to know exactly what is going on.
I believe the problem is that it is still doing DNS discovery even
though you've passed in a server name so it is setting up Kerberos to
look up the KDC which it finds but can't talk to.
This should be fixed in the 3.0 packages so updating to those is the
preferred solution.
For 2.x you can try the --force option which should make it skip some
discovery.
rob
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 1:17 PM, Rob Crittenden
rcrit...@redhat.com wrote:
Shree wrote:
Here are a couple of things
[skarulkar@ldap2 mailto:skarulkar@ldap2 ~]$ rpm -q ipa-client
ipa-client-3.0.0-26.el6_4.4.x86_64
What is the version on the client that is failing to enroll?
rob
and my /etc/krb5.conf looks like ..
===
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
[dbmodules]
MYDOMAIN.COM = {
db_library = ipadb.so
}
===
Shreeraj
Change is the only Constant !
On Wednesday, February 19, 2014 12:59 PM, Rob Crittenden
rcrit...@redhat.com mailto:rcrit...@redhat.com wrote:
Shree wrote:
1) I have got a step furthur. My replica is not running CA Service. To
achieve this I had to remove the existing cert with this command
pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force
Now the replica looks like this
skarulkar@ldap2 mailto:skarulkar@ldap2 mailto:skarulkar@ldap2
mailto:skarulkar@ldap2 tmp]$ sudo ipactl status
[sudo] password for skarulkar:
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING
[skarulkar@ldap2 mailto:skarulkar@ldap2 mailto:skarulkar@ldap2
mailto:skarulkar@ldap2 tmp]$
The tracking failed with:
2014-02-18T20:20:43Z DEBUG stdout=Error initializing Kerberos library:
Improper format of Kerberos configuration file.
It looks like it failed on this for most if not all the tracking. What
does /etc/krb5.conf look like?
2) I am still not able to add client using ipa-client-install
using the
replica.
The temporary krb5.conf that is used during enrollment has
dns_lookup_kdc=True so it is probably trying to contact the other KDC
and failing.
What is the output of:
$ rpm -q ipa-client
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Rob I am giving it a fresh start and I notice similar issues. 1) I wasn't able to use the --setup-ca while running the ipa-replica-install on the replica. It stopped the install after the ntpd step see below. Done configuring NTP daemon (ntpd). A CA is already configured on this system. 2) So I tried my install command again without the --setup-ca option. It went furthur although it completed it show one error see below. MY COMMAND: -- ipa-replica-install /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck the skip-conncheck was needed to complete the install. Connections checks were manually done. 14/31]: configuring lockout plugin [15/31]: creating indices [16/31]: enabling referential integrity plugin [17/31]: configuring ssl for ds instance ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-MYDOMAIN.COM -n Server-Cert -p /etc/dirsrv/slapd-MYDOMAIN.COM/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv MYDOMAIN.COM' returned non-zero exit status 1 [18/31]: configuring certmap.conf [19/31]: configure autobind for root . 3) The replica installed fine I can access the same database from the replica's website. 4) I cannot add new clients. MY COMMAND: -- ipa-client-install --domain=mydomain.com --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d ldap.mydomain.com = master ldap2.mydomain.com = replica Shreeraj Change is the only Constant ! On Friday, February 14, 2014 11:40 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: 1) 7839 TCP is open between the master and replica, do I need 7389 udp also? What about clients and replica? I have the following ports opened and tested between master and replica. -- 389 (TCP), 636 (TCP), 88 (TCP), 464 (TCP), 80 (TCP), 443 (TCP), 7389 (TCP) and 88 (UDP) 464 (UDP) Do I need any more ports opened, I have to work with another team to get this done, so it will help having all the information. No, this list is enough. Still, it can't connect to it. Seeing the failure output from the connection check might be useful, or at least confirm the same. 2)I see you skip the connection check, what was failing? :-- Yes my replica install fails unless I user --skip connection check. I have tested the connection with the ports mentioned during the install. I don't know what to say, the logs pretty clearly indicate that it can't connect on port 7389. 3) In the ipareplica-install log this is reported: Failed to setup the replication for cloning. :--- Yes but what is the solution? Fix the firewall. 4) And in the debug log: :- Also what is the solution for the Java.io error? Same thing. One failure cascades to another. rob___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote:
The logs are attached here. I had a day off yesterday.
Is port 7389 open? I see you skip the connection check, what was failing?
In the ipareplica-install log this is reported:
Failed to setup the replication for cloning.
And in the debug log:
[12/Feb/2014:15:15:38][http-9445-2]: DatabasePanel setupReplication:
java.io.IOException: consumer initialization failed. -1 - LDAP error:
Can't contact LDAP server
rob
Shreeraj
Change is the only Constant !
On Thursday, February 13, 2014 6:41 AM, Rob Crittenden
rcrit...@redhat.com wrote:
Shree wrote:
Ok, failed at the same stage, would you like the entire
/var/log/ipareplica-install.log. If yes, should I attach to the email?
pa: INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py,
line 614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 467, in main
(CA, cs) = cainstance.install_replica_ca(config)
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
1604, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
617, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.6/site-packages/ipaserver/install/service.py,
line 358, in start_creation
method()
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
879, in __configure_instance
raise RuntimeError('Configuration of CA failed')
ipa: INFOThe ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed
[root@ldap2 mailto:root@ldap2 ~]#
We need to see the full /var/log/ipareplica-install.log and the debug
log from /var/log/pki-ca.
rob
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 02/12/2014 04:57 PM, Shree wrote:
If there aren't any other tests to perform, can I go ahead and
uninstall the ipa client and configure this Vm as a replica?
Thanks for trying. At least we know that certmonger can run by itself.
When you install replica please collect all the install logs.
Is SELinux on/off?
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 1:40 PM, Shree
shreerajkarul...@yahoo.com mailto:shreerajkarul...@yahoo.com
mailto:shreerajkarul...@yahoo.com mailto:shreerajkarul...@yahoo.com
wrote:
getcert list returned a bunch of info, see below
root@ldap2 mailto:root@ldap2 ~]# getcert list
Number of certificates and requests being tracked: 2.
Request ID '20140206184920':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,..
.
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal
d...@redhat.com mailto:d...@redhat.com
mailto:d...@redhat.com mailto:d...@redhat.com wrote:
On 02/12/2014 03:41 PM, Shree wrote:
So I uninstalled the ipa server and installed the client
(ipa-client-install) on the same VM pointing at the master and
everything seems to work OK. All the sudo rules etc. Are there any
tests I can do check connectivity that could be helpful before I
configure this as a replica again.
Ask certmonger to get a certificate
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal
d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com
mailto:d...@redhat.com wrote:
On 02/12/2014 02:09 PM, Shree wrote:
Rob
I really appreciate your help, please bear with me. At this point I
need to take you back to my ipa-replica-install and what happened
there.
[1] My command: ipa-replica-install --setup-ca
/var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck
This ended with a
Done configuring NTP daemon (ntpd).
A CA is already configured on this system.
[2] So did a pkiremove with the
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote: 1) 7839 TCP is open between the master and replica, do I need 7389 udp also? What about clients and replica? I have the following ports opened and tested between master and replica. -- 389 (TCP), 636 (TCP), 88 (TCP), 464 (TCP), 80 (TCP), 443 (TCP), 7389 (TCP) and 88 (UDP) 464 (UDP) Do I need any more ports opened, I have to work with another team to get this done, so it will help having all the information. No, this list is enough. Still, it can't connect to it. Seeing the failure output from the connection check might be useful, or at least confirm the same. 2)I see you skip the connection check, what was failing? :-- Yes my replica install fails unless I user --skip connection check. I have tested the connection with the ports mentioned during the install. I don't know what to say, the logs pretty clearly indicate that it can't connect on port 7389. 3) In the ipareplica-install log this is reported: Failed to setup the replication for cloning. :--- Yes but what is the solution? Fix the firewall. 4) And in the debug log: :- Also what is the solution for the Java.io error? Same thing. One failure cascades to another. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote:
Ok, failed at the same stage, would you like the entire
/var/log/ipareplica-install.log. If yes, should I attach to the email?
pa : INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py,
line 614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 467, in main
(CA, cs) = cainstance.install_replica_ca(config)
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
1604, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
617, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.6/site-packages/ipaserver/install/service.py,
line 358, in start_creation
method()
File
/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py, line
879, in __configure_instance
raise RuntimeError('Configuration of CA failed')
ipa : INFO The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
Configuration of CA failed
[root@ldap2 ~]#
We need to see the full /var/log/ipareplica-install.log and the debug
log from /var/log/pki-ca.
rob
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 2:55 PM, Dmitri Pal d...@redhat.com wrote:
On 02/12/2014 04:57 PM, Shree wrote:
If there aren't any other tests to perform, can I go ahead and
uninstall the ipa client and configure this Vm as a replica?
Thanks for trying. At least we know that certmonger can run by itself.
When you install replica please collect all the install logs.
Is SELinux on/off?
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 1:40 PM, Shree
shreerajkarul...@yahoo.com mailto:shreerajkarul...@yahoo.com wrote:
getcert list returned a bunch of info, see below
root@ldap2 ~]# getcert list
Number of certificates and requests being tracked: 2.
Request ID '20140206184920':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,..
.
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 12:43 PM, Dmitri Pal d...@redhat.com
mailto:d...@redhat.com wrote:
On 02/12/2014 03:41 PM, Shree wrote:
So I uninstalled the ipa server and installed the client
(ipa-client-install) on the same VM pointing at the master and
everything seems to work OK. All the sudo rules etc. Are there any
tests I can do check connectivity that could be helpful before I
configure this as a replica again.
Ask certmonger to get a certificate
Shreeraj
Change is the only Constant !
On Wednesday, February 12, 2014 11:46 AM, Dmitri Pal
d...@redhat.com mailto:d...@redhat.com wrote:
On 02/12/2014 02:09 PM, Shree wrote:
Rob
I really appreciate your help, please bear with me. At this point I
need to take you back to my ipa-replica-install and what happened
there.
[1] My command: ipa-replica-install --setup-ca
/var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck
This ended with a
Done configuring NTP daemon (ntpd).
A CA is already configured on this system.
[2] So did a pkiremove with the following command
# pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force
[3] Re ran the ipa-replica-install command in step 1
The install went a little further but ended below.
Configuring directory server for the CA (pkids): Estimated time 30
seconds
[1/3]: creating directory server user
[2/3]: creating directory server instance
[3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
ipa : ERROR certmonger failed starting to track certificate:
Command '/usr/bin/ipa-getcert start-tracking -d
/etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p
/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C
/usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero
exit status 1
Configuring certificate server (pki-cad): Estimated time 3 minutes
30 seconds
[1/17]: creating certificate server user
[2/17]: creating pki-ca instance
[3/17]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
.
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Peter Actually I mentioned earlier that my clients are in a separate VLAN and cannot access the master. We have made provisions for the master and the replica to sync by opening the needed ports in the firewall. We have also opened up ports between the clients and the replica. I have tested the connectivity for these ports. Perhaps you can tell me if what I am trying to achieve is even possible? i.e I seem to get stuck with making the replica with the --setup-ca option. Wthout that option I am able to create a replica and have it in sync with the master. However my ipa-client-install fails from clients as they try looking for the master for CA part of the install. Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 12:45 AM, Petr Spacek pspa...@redhat.com wrote: On 11.2.2014 23:53, Shree wrote: Following ports are opened between the 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional). When the replica was up it worked fine as far as syncing was concerned. 80 tcp 443 tcp 389 tcp 636 tcp 88 tcp 464 tcp 88 udp 464 udp 123 udp Shreeraj Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal d...@redhat.com wrote: On 02/11/2014 05:05 PM, Shree wrote: Dimitri Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) Please republish it on the list. Do not reply to me directly. Did you set your first server with the CA? Does all ports that need to be open in the firewall between primary or server are actually open? What I have done so far is uninstalled the replica and tried to install it again using the --setup-ca option. Previously I had failures and when I removed the --setup-ca option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. 1)The workaround helped me go forward a bit but I got stuck at this point see below === [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd -preop_pin OlGXcjPVXoQcuuQkGgoG - === 2) No we do not use IPA for a DNS server. 3)The reason for this could be that I had installed the replica without the --setup-ca. Shreeraj Change is the only Constant ! On Monday, February 10, 2014 12:43 PM, Dmitri Pal d...@redhat.com wrote: On 02/09/2014 07:44 AM, Rob Crittenden wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote: Peter Actually I mentioned earlier that my clients are in a separate VLAN and cannot access the master. We have made provisions for the master and the replica to sync by opening the needed ports in the firewall. We have also opened up ports between the clients and the replica. I have tested the connectivity for these ports. Perhaps you can tell me if what I am trying to achieve is even possible? i.e I seem to get stuck with making the replica with the --setup-ca option. Wthout that option I am able to create a replica and have it in sync with the master. However my ipa-client-install fails from clients as they try looking for the master for CA part of the install. Clients don't talk to the CA, they talk to an IPA server which talks to the CA. I think we need to see /var/log/ipaclient-install.log to see what is going on. rob Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 12:45 AM, Petr Spacek pspa...@redhat.com wrote: On 11.2.2014 23:53, Shree wrote: Following ports are opened between the 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional). When the replica was up it worked fine as far as syncing was concerned. 80 tcp 443 tcp 389 tcp 636 tcp 88 tcp 464 tcp 88 udp 464 udp 123 udp Shreeraj Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/11/2014 05:05 PM, Shree wrote: Dimitri Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) Please republish it on the list. Do not reply to me directly. Did you set your first server with the CA? Does all ports that need to be open in the firewall between primary or server are actually open? What I have done so far is uninstalled the replica and tried to install it again using the --setup-ca option. Previously I had failures and when I removed the --setup-ca option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. 1)The workaround helped me go forward a bit but I got stuck at this point see below === [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa: ERRORcertmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa: CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd -preop_pin OlGXcjPVXoQcuuQkGgoG - === 2) No we do not use IPA for a DNS server. 3)The reason for this could be that I had installed the replica without the --setup-ca. Shreeraj Change is the only Constant ! On Monday, February 10, 2014 12:43 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/09/2014 07:44 AM, Rob Crittenden wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
OK I thought CA is a part of IPA ? Below is from my master IPA server [root@ldap ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root@ldap ~]# I can certainly send you a log if needed. Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: Peter Actually I mentioned earlier that my clients are in a separate VLAN and cannot access the master. We have made provisions for the master and the replica to sync by opening the needed ports in the firewall. We have also opened up ports between the clients and the replica. I have tested the connectivity for these ports. Perhaps you can tell me if what I am trying to achieve is even possible? i.e I seem to get stuck with making the replica with the --setup-ca option. Wthout that option I am able to create a replica and have it in sync with the master. However my ipa-client-install fails from clients as they try looking for the master for CA part of the install. Clients don't talk to the CA, they talk to an IPA server which talks to the CA. I think we need to see /var/log/ipaclient-install.log to see what is going on. rob Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 12:45 AM, Petr Spacek pspa...@redhat.com wrote: On 11.2.2014 23:53, Shree wrote: Following ports are opened between the 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional). When the replica was up it worked fine as far as syncing was concerned. 80 tcp 443 tcp 389 tcp 636 tcp 88 tcp 464 tcp 88 udp 464 udp 123 udp Shreeraj Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/11/2014 05:05 PM, Shree wrote: Dimitri Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) Please republish it on the list. Do not reply to me directly. Did you set your first server with the CA? Does all ports that need to be open in the firewall between primary or server are actually open? What I have done so far is uninstalled the replica and tried to install it again using the --setup-ca option. Previously I had failures and when I removed the --setup-ca option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. 1)The workaround helped me go forward a bit but I got stuck at this point see below === [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd -preop_pin OlGXcjPVXoQcuuQkGgoG - === 2) No we do not use IPA for a DNS server. 3)The reason for this could be that I had installed the replica without the --setup-ca. Shreeraj Change is the only Constant ! On Monday, February 10, 2014 12:43 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 02/09/2014 07:44 AM, Rob Crittenden wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Rob I really appreciate your help, please bear with me. At this point I need to take you back to my ipa-replica-install and what happened there. [1] My command: ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck This ended with a Done configuring NTP daemon (ntpd). A CA is already configured on this system. [2] So did a pkiremove with the following command # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force [3] Re ran the ipa-replica-install command in step 1 The install went a little further but ended below. Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname . ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed If I skip the --setup-ca option then the replica gets created without any CA services. The master and replica are in sync but I am unable to run a ipa-client-install using the replica. Now I need to fix this to get a replica in place correctly. Shreeraj On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: OK I thought CA is a part of IPA ? Below is from my master IPA server [root@ldap ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root@ldap ~]# I can certainly send you a log if needed. It is part of IPA but the IPA server talks to it, not the clients directly. I can only speculate what the client is doing without seeing the log files, but I suspect both masters are in DNS and IPA is trying to enroll to the initial master which isn't available. rob Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: Peter Actually I mentioned earlier that my clients are in a separate VLAN and cannot access the master. We have made provisions for the master and the replica to sync by opening the needed ports in the firewall. We have also opened up ports between the clients and the replica. I have tested the connectivity for these ports. Perhaps you can tell me if what I am trying to achieve is even possible? i.e I seem to get stuck with making the replica with the --setup-ca option. Wthout that option I am able to create a replica and have it in sync with the master. However my ipa-client-install fails from clients as they try looking for the master for CA part of the install. Clients don't talk to the CA, they talk to an IPA server which talks to the CA. I think we need to see /var/log/ipaclient-install.log to see what is going on. rob Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 12:45 AM, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 11.2.2014 23:53, Shree wrote: Following ports are opened between the 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional). When the replica was up it worked fine as far as syncing was concerned. 80 tcp 443 tcp 389 tcp 636 tcp 88 tcp 464 tcp 88 udp 464 udp 123 udp Shreeraj Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com wrote: On 02/11/2014 05:05 PM, Shree wrote: Dimitri Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) Please republish it on the list. Do not
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On 02/12/2014 02:09 PM, Shree wrote: Rob I really appreciate your help, please bear with me. At this point I need to take you back to my ipa-replica-install and what happened there. [1] My command: ipa-replica-install --setup-ca /var/tmp/replica-info-ldap2.mydomain.com.gpg --skip-conncheck This ended with a Done configuring NTP daemon (ntpd). A CA is already configured on this system. [2] So did a pkiremove with the following command # pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca -force [3] Re ran the ipa-replica-install command in step 1 The install went a little further but ended below. Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa : ERRORcertmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname . ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed If I skip the --setup-ca option then the replica gets created without any CA services. The master and replica are in sync but I am unable to run a ipa-client-install using the replica. Now I need to fix this to get a replica in place correctly. Shreeraj On Wednesday, February 12, 2014 10:42 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: OK I thought CA is a part of IPA ? Below is from my master IPA server [root@ldap mailto:root@ldap ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root@ldap mailto:root@ldap ~]# I can certainly send you a log if needed. It is part of IPA but the IPA server talks to it, not the clients directly. I can only speculate what the client is doing without seeing the log files, but I suspect both masters are in DNS and IPA is trying to enroll to the initial master which isn't available. rob Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 10:32 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Shree wrote: Peter Actually I mentioned earlier that my clients are in a separate VLAN and cannot access the master. We have made provisions for the master and the replica to sync by opening the needed ports in the firewall. We have also opened up ports between the clients and the replica. I have tested the connectivity for these ports. Perhaps you can tell me if what I am trying to achieve is even possible? i.e I seem to get stuck with making the replica with the --setup-ca option. Wthout that option I am able to create a replica and have it in sync with the master. However my ipa-client-install fails from clients as they try looking for the master for CA part of the install. Clients don't talk to the CA, they talk to an IPA server which talks to the CA. I think we need to see /var/log/ipaclient-install.log to see what is going on. rob Shreeraj Change is the only Constant ! On Wednesday, February 12, 2014 12:45 AM, Petr Spacek pspa...@redhat.com mailto:pspa...@redhat.com mailto:pspa...@redhat.com mailto:pspa...@redhat.com wrote: On 11.2.2014 23:53, Shree wrote: Following ports are opened between the 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional). When the replica was up it worked fine as far as syncing was concerned. 80 tcp 443 tcp 389 tcp 636 tcp 88 tcp 464 tcp 88 udp 464 udp 123 udp Shreeraj Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com wrote: On 02/11/2014
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Lukas I read the information on those two links, my problem is different. My replica is working fine, the database has all the records. My problem is I am not able to use the replica for ipa-client -install. In one of my replies I sent information that kinit was trying to access my master instead of the replica. Let me know what you think. Thanks Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Following ports are opened between the 1) Between the master and the replica (bi directional) 2) client machine and the ipa replica (unidirectional). When the replica was up it worked fine as far as syncing was concerned. 80 tcp 443 tcp 389 tcp 636 tcp 88 tcp 464 tcp 88 udp 464 udp 123 udp Shreeraj Change is the only Constant ! On Tuesday, February 11, 2014 2:22 PM, Dmitri Pal d...@redhat.com wrote: On 02/11/2014 05:05 PM, Shree wrote: Dimitri Sorry some the mail landed in my SPAM folder. Let answer your questions (thanks for your help man) Please republish it on the list. Do not reply to me directly. Did you set your first server with the CA? Does all ports that need to be open in the firewall between primary or server are actually open? What I have done so far is uninstalled the replica and tried to install it again using the --setup-ca option. Previously I had failures and when I removed the --setup-ca option the installation succeeded (in a way). I understand now that I really need to fix the CA installation errors first. 1)The workaround helped me go forward a bit but I got stuck at this point see below === [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). ipa : ERROR certmonger failed starting to track certificate: Command '/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA' returned non-zero exit status 1 Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ldap2.macosforge.org -cs_port 9445 -client_certdb_dir /tmp/tmp-ipJSsT -client_certdb_pwd -preop_pin OlGXcjPVXoQcuuQkGgoG - === 2) No we do not use IPA for a DNS server. 3)The reason for this could be that I had installed the replica without the --setup-ca. Shreeraj Change is the only Constant ! On Monday, February 10, 2014 12:43 PM, Dmitri Pal d...@redhat.com wrote: On 02/09/2014 07:44 AM, Rob Crittenden wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On 02/09/2014 07:44 AM, Rob Crittenden wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUGstderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users What server provides DNS capabilities to the clients? Do you use IPA DNS or some other DNS? Clients seem to not be able to see replica KDC and try to access hidden master but they can know about this master only via DNS. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Lucas (sorry my previous email may have got sent improperly edited. My typical command looks like this (domain name changed due to disclosure reasons) # ipa-client-install --domain=mydomain.com --server=ldap2.mydomain.com --hostname=test500.mydomain.com -d master = ldap.mydomain.com replica = ldap2.mydomain.com I ran lsof while running a ipa-client-install and found the following kinit instances trying to access my master = ipa-clien 10443 root mem REG 253,0 334040 1704353 /lib64/libldap_r-2.4.so.2.5.6 ipa-clien 10443 root mem REG 253,0 61896 1444372 /usr/lib64/python2.6/site-packages/_ldap.so kinit 10545 root 3u IPv4 143621 0t0 UDP test500.mydomain.com:57166-ldap.mydomain.com:kerberos kinit 10545 root 4u IPv4 143636 0t0 TCP test500.mydomain.com:35574-ldap.mydomain.com:kerberos (SYN_SENT) = the client install also finds issue with syncing time during client install, but only gives warning. The time difference between master and client is within seconds. the client install also finds issue with Shreeraj Change is the only Constant ! On Sunday, February 9, 2014 4:44 AM, Rob Crittenden rcrit...@redhat.com wrote: Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Shree wrote: Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need No, the clients don't directly talk to the CA. You'd need to look in /var/log/ipaclient-install.log to see what KDC was found and we were trying to use. If you have SRV records for both but we try to contact the hidden master this will happen. You can try specifying the server on the command-line with --server but this will be hardcoding things and make it less flexible later. rob Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUGstderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
Lukas Perhaps I should explain the design a bit and see if FreeIPA even supports this.Our replica is in a separate network and all the appropriate ports are opened between the master and the replica. The replica got created successfully and is in sync with the master (except the CA services which I mentioned earlier) Now,when I try to run ipa-client-install on hosts in the new network using the replica, it complains that about Cannot contact any KDC for realm. I am wondering it my hosts in the new network are trying to access the master for certificates since the replica does not have any CA services running? I couldn't find any obvious proof of this even running the install in a debug mode. Do I need to open ports between the new hosts and the master for CA services? At this point I cannot disable or move the master, it needs to function in its location but I need Shreeraj Change is the only Constant ! On Saturday, February 8, 2014 1:29 AM, Lukas Slebodnik lsleb...@redhat.com wrote: On (06/02/14 18:33), Shree wrote: First of all, the ipa-replica-install did not allow me to use the --setup-ca option complaining that a cert already exists, replicate creation was successful after I skipped the option. Seems like the replica is one except 1) There is no CA Service running on the replica (which I guess is expected) and 2) I am unable to run ipa-client-install successfully on any clients using the replica. (I don't have the option of using the primary master as it is configured in a segregated environment. Only the master and replica are allowed to sync. Debug shows it fails at ipa : DEBUG stderr=kinit: Cannot contact any KDC for realm 'mydomainname.com' while getting initial credentials I was not able to install replica witch CA on fedora 20, Bug is already reported https://fedorahosted.org/pki/ticket/816 Guys from dogtag found a workaround https://fedorahosted.org/pki/ticket/816#comment:12 Does it work for you? LS___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
