Re: ns-slapd hangs for 2-3 minutes, then resumes.
by Guillermo Fuentes
Hi list,
Just closing the loop on this one.
This issue finally got resolved for us after installing the latest FreeIPA
update available for CentOS 7:
OS version: CentOS Linux release 7.4.1708 (Core)
ipa-server-trust-ad-4.5.0-22.el7.centos.x86_64
ipa-common-4.5.0-22.el7.centos.noarch
sssd-ipa-1.15.2-50.el7_4.8.x86_64
ipa-client-4.5.0-22.el7.centos.x86_64
ipa-server-4.5.0-22.el7.centos.x86_64
ipa-client-common-4.5.0-22.el7.centos.noarch
ipa-server-dns-4.5.0-22.el7.centos.noarch
ipa-python-compat-4.5.0-22.el7.centos.noarch
ipa-server-common-4.5.0-22.el7.centos.noarch
389-ds-base-libs-1.3.6.1-24.el7_4.x86_64
389-ds-base-snmp-1.3.6.1-24.el7_4.x86_64
389-ds-base-1.3.6.1-24.el7_4.x86_64
pki-ca-10.4.1-17.el7_4.noarch
pki-tools-10.4.1-17.el7_4.x86_64
pki-server-10.4.1-17.el7_4.noarch
pki-kra-10.4.1-17.el7_4.noarch
pki-base-10.4.1-17.el7_4.noarch
pki-base-java-10.4.1-17.el7_4.noarch
pki-symkey-10.4.1-17.el7_4.x86_64
Many thanks for such a great product!
Guillermo
On Mon, Jul 18, 2016 at 2:37 PM, Guillermo Fuentes <guillermo.fuentes@
modernizingmedicine.com> wrote:
> Hi all,
>
> Did any ipa/sssd developer had a chance to take a look at this issue?
>
> Updating to the latest version available for CentOS 7 didn't fix it:
> ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64
> ipa-python-4.2.0-15.0.1.el7.centos.17.x86_64
> ipa-server-dns-4.2.0-15.0.1.el7.centos.17.x86_64
> sssd-ipa-1.13.0-40.el7_2.9.x86_64
> python-libipa_hbac-1.13.0-40.el7_2.9.x86_64
> ipa-admintools-4.2.0-15.0.1.el7.centos.17.x86_64
> ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64
> libipa_hbac-1.13.0-40.el7_2.9.x86_64
> ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.17.x86_64
> ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64
>
> 389-ds-base-libs-1.3.4.0-32.el7_2.x86_64
> 389-ds-base-1.3.4.0-32.el7_2.x86_64
> 389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64
>
>
> Please let me know if you need more information or how I can help to get
> it fixed.
>
> Thanks so much,
> Guillermo
>
>
> On Mon, Jun 13, 2016 at 6:30 PM, Rich Megginson <rmeggins(a)redhat.com>
> wrote:
>
>> On 06/13/2016 01:13 PM, Guillermo Fuentes wrote:
>>
>>> Hi Rich,
>>>
>>> After I started running the stack traces, the problem hasn't happen as
>>> frequently as it use to but today I was able to get the stack traces.
>>> As they aren't similar I'll send them over to you in a separate email.
>>>
>>> This is what I did to start the stack traces (CentOS 7):
>>> # yum install -y --enablerepo=base-debuginfo 389-ds-base-debuginfo
>>> ipa-debuginfo slapi-nis-debuginfo nspr-debuginfo
>>> # yum install -y gdb
>>> # systemctl stop ipa.service ; sleep 10; systemctl start ipa.service
>>> # mkdir -p /var/log/stacktraces
>>>
>>> Setup crontab to run the following every minute:
>>> gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply
>>> all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` >
>>> /var/log/stacktraces/stacktrace.`date +%s`.txt 2>&1
>>>
>>
>> It looks similar to https://fedorahosted.org/389/ticket/48341 but you
>> already have that fix.
>>
>> One of the problems is that ids_sasl_check_bind acquires the connection
>> lock and holds it for a very long time, which causes the main loop to block
>> on that connection, which is similar to the above problem, and also similar
>> to https://fedorahosted.org/389/ticket/48882. Basically, anything which
>> holds the connection c_mutex lock too long can hang the server. In your
>> case, this stack trace:
>>
>> poll sss_cli_make_request_nochecks sss_cli_check_socket
>> sss_pac_make_request sssdpac_verify krb5int_authdata_verify
>> rd_req_decoded_opt krb5_rd_req_decoded kg_accept_krb5
>> krb5_gss_accept_sec_context_ext krb5_gss_accept_sec_context
>> gss_accept_sec_context gssapi_server_mech_step sasl_server_step
>> sasl_server_start ids_sasl_check_bind do_bind connection_dispatch_operation
>> _pt_root start_thread clone
>>
>> I'm not sure if this particular situation is known/fixed. Perhaps there
>> is a way to make the poll() called by sss_cli_make_request_nochecks()
>> have a smaller timeout?
>>
>> Does this look familiar to any ipa/sssd developer?
>>
>>
>>
>>> Thank you so much for your help,
>>>
>>> Guillermo
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 1, 2016 at 6:52 PM, Guillermo Fuentes
>>> <guillermo.fuentes(a)modernizingmedicine.com> wrote:
>>>
>>>> I'm now taking stack traces every minute and waiting for it to hang
>>>> again to check it. It happens usually under load but it's
>>>> unpredictable. Must likely tomorrow.
>>>> GUILLERMO FUENTES
>>>> SR. SYSTEMS ADMINISTRATOR
>>>>
>>>> 561-880-2998 x1337
>>>>
>>>> guillermo.fuentes(a)modmed.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jun 1, 2016 at 2:03 PM, Rich Megginson <rmeggins(a)redhat.com>
>>>> wrote:
>>>>
>>>>> On 06/01/2016 10:37 AM, Guillermo Fuentes wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> We are experiencing a similar issue like the one discussed in the
>>>>>> following thread but we are running FreeIPA 4.2 on CentOS 7.2:
>>>>>> https://www.redhat.com/archives/freeipa-users/2015-February/
>>>>>> msg00205.html
>>>>>>
>>>>>
>>>>> Are your stack traces similar?
>>>>>
>>>>>
>>>>> LDAP service stops responding to queries (hangs). LDAP connections on
>>>>>> the server climb sometimes up to 10 times the normal amount and load
>>>>>> goes to 0. Then, the connections start to drop until they get to a
>>>>>> normal level and the LDAP service starts to respond to queries again.
>>>>>> This happens in between 3-5 minutes:
>>>>>>
>>>>>> Time,LDAP conn, Opened files(ns-slapd), File
>>>>>> Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15
>>>>>> 8:54:03,101,353,216,142,0.43,0.20,0.16
>>>>>> 8:55:02,108,359,221,142,0.19,0.18,0.15
>>>>>> 8:56:03,110,361,224,142,0.07,0.15,0.14
>>>>>> 8:57:14,117,383,246,142,0.15,0.16,0.15
>>>>>> 8:58:04,276,371,234,142,0.05,0.13,0.14
>>>>>> 8:59:05,469,371,234,142,0.02,0.11,0.13
>>>>>> 9:00:08,719,371,234,142,0.01,0.09,0.12
>>>>>> 9:01:18,1060,371,234,142,0.00,0.07,0.12
>>>>>> 9:02:10,742,371,233,142,0.10,0.09,0.12
>>>>>> 9:03:06,365,372,235,142,0.13,0.10,0.13
>>>>>> 9:04:04,262,379,242,142,0.87,0.29,0.19
>>>>>> 9:05:02,129,371,233,142,0.51,0.31,0.20
>>>>>> 9:06:03,126,377,240,142,0.42,0.33,0.22
>>>>>> 9:07:03,125,377,238,142,0.17,0.27,0.21
>>>>>>
>>>>>> Nothing is logged in the errors log file of the server having the
>>>>>> problem (ipa1 as an example).
>>>>>> In the replicas this is logged:
>>>>>> 8:59:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com"
>>>>>> (ipa1:389): Unable to receive the response for a startReplication
>>>>>> extended operation to consumer (Timed out). Will retry later.
>>>>>> 9:01:05 -0400] NSMMReplicationPlugin - agmt="cn=meToipa1.example.com"
>>>>>> (ipa1:389): Unable to receive the response for a startReplication
>>>>>> extended operation to consumer (Timed out). Will retry later.
>>>>>>
>>>>>> Nothing is logged in the access log file until after ns-slapd starts
>>>>>> responding again:
>>>>>> ...
>>>>>> 8:57:00 -0400] conn=12384 fd=234 slot=234 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 8:57:00 -0400] conn=12385 fd=235 slot=235 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 8:57:00 -0400] conn=12386 fd=236 slot=236 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 8:57:00 -0400] conn=12387 fd=237 slot=237 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 8:57:00 -0400] conn=10384 op=1227 EXT oid="2.16.840.1.113730.3.5.12"
>>>>>> name="replication-multimaster-extop"
>>>>>> 8:57:00 -0400] conn=12324 op=8 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 8:57:00 -0400] conn=8838 op=2545 EXT oid="2.16.840.1.113730.3.5.12"
>>>>>> name="replication-multimaster-extop"
>>>>>> 8:57:00 -0400] conn=8838 op=2545 RESULT err=0 tag=120 nentries=0
>>>>>> etime=0
>>>>>> 8:57:00 -0400] conn=10384 op=1227 RESULT err=0 tag=120 nentries=0
>>>>>> etime=0
>>>>>> 8:57:00 -0400] conn=12382 op=-1 fd=170 closed - B1
>>>>>> 8:57:00 -0400] conn=12383 op=0 SRCH base="" scope=0
>>>>>> filter="(objectClass=*)" attrs="supportedSASLMechanisms
>>>>>> defaultnamingcontext namingContexts schemanamingcontext saslrealm"
>>>>>> 8:57:00 -0400] conn=12384 op=-1 fd=234 closed - B1
>>>>>> 8:57:00 -0400] conn=12385 op=0 SRCH base="" scope=0
>>>>>> filter="(objectClass=*)" attrs="supportedSASLMechanisms
>>>>>> defaultnamingcontext namingContexts schemanamingcontext saslrealm"
>>>>>> 8:57:00 -0400] conn=12383 op=0 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 8:57:00 -0400] conn=12386 op=-1 fd=236 closed - B1
>>>>>> 8:57:00 -0400] conn=12385 op=0 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 8:57:00 -0400] conn=12387 op=0 SRCH base="" scope=0
>>>>>> filter="(objectClass=*)" attrs="supportedSASLMechanisms
>>>>>> defaultnamingcontext namingContexts schemanamingcontext saslrealm"
>>>>>> 8:57:00 -0400] conn=12387 op=0 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 8:57:00 -0400] conn=12385 op=1 BIND dn="" method=sasl version=3
>>>>>> mech=GSSAPI
>>>>>> 8:57:00 -0400] conn=12387 op=1 BIND dn="" method=sasl version=3
>>>>>> mech=GSSAPI
>>>>>> 8:57:00 -0400] conn=12385 op=1 RESULT err=14 tag=97 nentries=0
>>>>>> etime=0, SASL bind in progress
>>>>>> 8:57:00 -0400] conn=12383 op=1 BIND dn="" method=sasl version=3
>>>>>> mech=GSSAPI
>>>>>> 8:57:00 -0400] conn=10384 op=1228 EXT oid="2.16.840.1.113730.3.5.5"
>>>>>> name="Netscape Replication End Session"
>>>>>> 8:57:00 -0400] conn=10384 op=1228 RESULT err=0 tag=120 nentries=0
>>>>>> etime=0
>>>>>> 8:57:00 -0400] conn=12383 op=1 RESULT err=14 tag=97 nentries=0
>>>>>> etime=0, SASL bind in progress
>>>>>> 9:02:00 -0400] conn=12388 fd=170 slot=170 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12389 fd=234 slot=234 SSL connection from
>>>>>> 172.20.0.24 to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12390 fd=236 slot=236 connection from local to
>>>>>> /var/run/slapd-EXAMPLE-COM.socket
>>>>>> 9:02:00 -0400] conn=12391 fd=238 slot=238 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12392 fd=239 slot=239 SSL connection from
>>>>>> 172.20.0.24 to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12393 fd=240 slot=240 connection from local to
>>>>>> /var/run/slapd-EXAMPLE-COM.socket
>>>>>> 9:02:00 -0400] conn=12394 fd=241 slot=241 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12395 fd=242 slot=242 SSL connection from
>>>>>> 172.20.0.24 to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12396 fd=243 slot=243 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12397 fd=244 slot=244 SSL connection from
>>>>>> 172.20.0.24 to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12398 fd=245 slot=245 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12400 fd=247 slot=247 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> 9:02:00 -0400] conn=12401 fd=248 slot=248 connection from 172.20.0.1
>>>>>> to 172.20.2.45
>>>>>> ...
>>>>>> 9:02:00 -0400] conn=12390 op=0 BIND dn="" method=sasl version=3
>>>>>> mech=GSSAPI
>>>>>> 9:02:00 -0400] conn=12388 op=-1 fd=170 closed - B1
>>>>>> 9:02:00 -0400] conn=12393 op=0 BIND dn="" method=sasl version=3
>>>>>> mech=GSSAPI
>>>>>> 9:02:00 -0400] conn=12391 op=0 SRCH base="" scope=0
>>>>>> filter="(objectClass=*)" attrs="supportedSASLMechanisms
>>>>>> defaultnamingcontext namingContexts schemanamingcontext saslrealm"
>>>>>> 9:02:00 -0400] conn=12394 op=-1 fd=241 closed - B1
>>>>>> 9:02:00 -0400] conn=12391 op=0 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 9:02:00 -0400] conn=12396 op=0 SRCH base="" scope=0
>>>>>> filter="(objectClass=*)" attrs="supportedSASLMechanisms
>>>>>> defaultnamingcontext namingContexts schemanamingcontext saslrealm"
>>>>>> 9:02:00 -0400] conn=12396 op=0 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 9:02:00 -0400] conn=12398 op=-1 fd=245 closed - B1
>>>>>> 9:02:00 -0400] conn=12400 op=0 SRCH base="" scope=0
>>>>>> filter="(objectClass=*)" attrs="supportedSASLMechanisms
>>>>>> defaultnamingcontext namingContexts schemanamingcontext saslrealm"
>>>>>> 9:02:00 -0400] conn=12400 op=0 RESULT err=0 tag=101 nentries=1 etime=0
>>>>>> 9:02:00 -0400] conn=12401 op=-1 fd=248 closed - B1
>>>>>> 9:02:00 -0400] conn=12391 op=1 ABANDON targetop=NOTFOUND msgid=1
>>>>>> 9:02:00 -0400] conn=12396 op=1 ABANDON targetop=NOTFOUND msgid=1
>>>>>> 9:02:00 -0400] conn=12400 op=1 ABANDON targetop=NOTFOUND msgid=1
>>>>>> 9:02:00 -0400] conn=12391 op=2 UNBIND
>>>>>> 9:02:00 -0400] conn=12396 op=2 UNBIND
>>>>>> 9:02:00 -0400] conn=12391 op=2 fd=238 closed - U1
>>>>>> 9:02:00 -0400] conn=12396 op=2 fd=243 closed - U1
>>>>>> 9:02:00 -0400] conn=12400 op=2 UNBIND
>>>>>> 9:02:00 -0400] conn=12400 op=2 fd=247 closed - U1
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> Environment:
>>>>>> # cat /etc/redhat-release
>>>>>> CentOS Linux release 7.2.1511 (Core)
>>>>>>
>>>>>> # rpm -qa ipa*
>>>>>> ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>>>> ipa-python-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>>>> ipa-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>>>> ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>>>> ipa-client-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>>>> ipa-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64
>>>>>>
>>>>>> # rpm -qa 389*
>>>>>> 389-ds-base-libs-1.3.4.0-30.el7_2.x86_64
>>>>>> 389-ds-base-1.3.4.0-30.el7_2.x86_64
>>>>>>
>>>>>> We have 4 FreeIPA servers with replication working fine between them.
>>>>>> ipa1 is handling LDAP authentication for +400 clients and has been
>>>>>> tunned as recommended per
>>>>>>
>>>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Direct
>>>>>> ory_Server/8.2/html/Performance_Tuning_Guide/system-tuning.html
>>>>>>
>>>>>> Is this a known issue?
>>>>>> Any idea what can be causing ns-slapd to hang?
>>>>>>
>>>>>> Thanks in advance!
>>>>>>
>>>>>> Guillermo
>>>>>>
>>>>>> --
>>>>> Manage your subscription for the Freeipa-users mailing list:
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>> Go to http://freeipa.org for more info on the project
>>>>>
>>>>
>>
>>
>
6 years, 3 months
ipa: ERROR: Major (851968): Unspecified GSS failure. - before kinit
by lejeczek
hi
would you know if normal is below from ipa * commands,
before kinit is done?:
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor
code may provide more information, Minor (2529638943):
Decrypt integrity check failed
I remember before, tools would silently execute if a ticket
was not there, but do not recall errors like above.
many thanks, L.
6 years, 3 months
"certmonger.py", line 317, in request_and_wait_for_cert
by lejeczek
hi
not an python nor ipa expert here, looking at certmonger.py
what does such an error indicate? :
ipa : DEBUG certmonger request is in state
dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
ipa : DEBUG certmonger request is in state
dbus.String(u'CA_UNREACHABLE', variant_level=1)
ipa : DEBUG Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 504, in start_creation
run_step(full_msg, method)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 494, in run_step
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 824, in __enable_ssl
post_command=cmd)
File
"/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
line 317, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed
({})".format(state))
RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
ipa : DEBUG [error] RuntimeError: Certificate
issuance failed (CA_UNREACHABLE)
[error] RuntimeError: Certificate issuance failed
(CA_UNREACHABLE)
-- end
Is this about local replica candidate or remote ipa server?
thanks, L.
6 years, 3 months
replica install fails: CA_UNREACHABLE
by lejeczek
hi
I'm trying to install replica, process fails:
..
[3/5]: creating anonymous principal
[4/5]: starting the KDC
[5/5]: configuring KDC to start on boot
Done configuring Kerberos KDC (krb5kdc).
Configuring kadmin
[1/2]: starting kadmin
[2/2]: configuring kadmin to start on boot
Done configuring kadmin.
Configuring directory server (dirsrv)
[1/3]: configuring TLS for DS instance
[error] RuntimeError: Certificate issuance failed
(CA_UNREACHABLE)
Your system may be partly configured.
..
-- end
and in intall log file:
..
2018-01-06T13:50:29Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-PRIVATE-xx.xx.PRIVATE-CAM-AC-UK/ -A -n
PRIVATE.xx.xx.PRIVATE.xx.xx.x IPA CA -t CT,C,C -a -f
/etc/dirsrv/slapd-PRIVATE-xx.xx.PRIVATE-CAM-AC-UK/pwdfile.txt
2018-01-06T13:50:29Z DEBUG Process finished, return code=0
2018-01-06T13:50:29Z DEBUG stdout=
2018-01-06T13:50:29Z DEBUG stderr=
2018-01-06T13:50:30Z DEBUG certmonger request is in state
dbus.String(u'NEWLY_ADDED_READING_CERT', variant_level=1)
2018-01-06T13:50:35Z DEBUG certmonger request is in state
dbus.String(u'CA_UNREACHABLE', variant_level=1)
2018-01-06T13:50:35Z DEBUG Traxx.ck (most recent call last):
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 504, in start_creation
run_step(full_msg, method)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
line 494, in run_step
method()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line 824, in __enable_ssl
post_command=cmd)
File
"/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
line 317, in request_and_wait_for_cert
raise RuntimeError("Certificate issuance failed
({})".format(state))
RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
2018-01-06T13:50:35Z DEBUG [error] RuntimeError:
Certificate issuance failed (CA_UNREACHABLE)
2018-01-06T13:50:35Z DEBUG File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py",
line 172, in execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipapython/install/cli.py",
line 333, in run
cfgr.run()
File "/usr/lib/python2.7/site-
...
-- end
Would this be that new candidate's problem or some
communication issues with existing server? Client installed
(kind of)okey though.
6 years, 3 months
Re: Unable to configure an IPA replica with dns
by Alexander Bokovoy
Please don't drop the mailing list.
On pe, 12 tammi 2018, Nacho del Rey wrote:
>I think it is connecting locally (to the replica server itself)
>
>ldap_uri = ldapi://%2fvar%2frun%2fslapd-XXXXXX-COM.socket
>
>How can I check and to enable this feature? I guess that if the LDAP is
>replicated between master & replica, it has to done once, right?
The feature is enabled by default and nothing in IPA is removing it.
Can you explain in more details what is your actual environment? OS is
CentOS 7.3 but where is it running? Bare metal, VM, Docker, LXC, etc?
What are the package versions that you have for ipa-server, 389-ds-base,
etc.
CentOS 7.3 is "old" now (CentOS only supports the very latest release), so
question about what packages are installed can reveal what's wrong.
--
/ Alexander Bokovoy
6 years, 3 months
Unable to configure an IPA replica with dns
by Nacho del Rey
Hi list
I have spent several days trying to configure a mater<->replica scenario but I'm having a problem with the dns which doesn't allow to me to go ahead
I could deploy an IPA server successfully in a Centos 7.3 using the following command
ipa-server-install --realm XXXX.COM --ds-password XXXX --admin-password XXXX --hostname=name.domain.com --setup-dns --no-forwarders --unattended
but when I try to configure an IPA replica with dns activated I'm getting the following error once and again
ipa-replica-install --skip-conncheck --setup-dns --principal=admin -w XXXX --force-join --ssh-trust-dns --no-dnssec-validation --unattended --realm= XXXX.COM --domain=domain.com --auto-forwarders
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: ipa : INFO Commencing sync process
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: Traceback (most recent call last):
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 114, in <module>
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search):
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 348, in syncrepl_poll
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: add_intermediates=1, add_ctrls=1, all = 0
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476, in result4
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: result = func(*args,**kwargs)
Jan 12 10:27:41 replica01 ipa-dnskeysyncd[5159]: ldap.UNAVAILABLE_CRITICAL_EXTENSION: {'desc': 'Critical extension is unavailable'}
Jan 12 10:27:41 replica01 systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE
Jan 12 10:27:41 replica01 systemd[1]: Unit ipa-dnskeysyncd.service entered failed state.
Jan 12 10:27:41 replica01 systemd[1]: ipa-dnskeysyncd.service failed.
Jan 12 10:28:30 replica01 named-pkcs11[5110]: GSSAPI client step 1
Jan 12 10:28:30 replica01 named-pkcs11[5110]: GSSAPI client step 1
Jan 12 10:28:30 replica01 ns-slapd[3651]: GSSAPI server step 1
Jan 12 10:28:30 replica01 named-pkcs11[5110]: GSSAPI client step 1
Jan 12 10:28:30 replica01 ns-slapd[3651]: GSSAPI server step 2
Jan 12 10:28:30 replica01 named-pkcs11[5110]: GSSAPI client step 2
Jan 12 10:28:30 replica01 ns-slapd[3651]: GSSAPI server step 3
Jan 12 10:28:30 replica01 named-pkcs11[5110]: successfully reconnected to LDAP server
Jan 12 10:28:30 replica01 named-pkcs11[5110]: LDAP error: Critical extension is unavailable: unable to start SyncRepl session: is RFC 4533 supported by LDAP server?
Jan 12 10:28:30 replica01 named-pkcs11[5110]: LDAP configuration synchronization failed: socket is not connected
Jan 12 10:28:30 replica01 named-pkcs11[5110]: ldap_syncrepl will reconnect in 60 seconds
These are the parameters generated by this failing service
[root@replica01 etc]# cat ./sysconfig/ipa-dnskeysyncd
SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf
[root@replica01 etc]# cat /etc/ipa/dnssec/softhsm2.conf
# SoftHSM v2 configuration file
# File generated by IPA instalation
directories.tokendir = /var/lib/ipa/dnssec/tokens
objectstore.backend = file
[root@replica01 etc]# ls -lart /var/lib/ipa/dnssec/tokens/b591e51f-56c3-dc08-158f-a01b7f177bc3/
total 16
drwxrws---. 3 ods named 50 Jan 12 10:06 ..
-rwxrwx---. 1 ods named 320 Jan 12 10:06 token.object
-rwxrwx---. 1 ods named 0 Jan 12 10:06 token.lock
-rwxrwx---. 1 ods named 0 Jan 12 10:06 0c1e587e-443b-cc05-dd3d-2ddaccde958f.lock
-rwxrwx---. 1 ods named 931 Jan 12 10:06 0c1e587e-443b-cc05-dd3d-2ddaccde958f.object
drwxrws---. 2 ods named 262 Jan 12 10:06 .
-rwxrwx---. 1 ods named 0 Jan 12 10:06 194085eb-3127-4e35-3874-4f935a069025.lock
-rwxrwx---. 1 ods named 2208 Jan 12 10:06 194085eb-3127-4e35-3874-4f935a069025.object
-rwxrwx---. 1 ods named 8 Jan 12 10:25 generation
any help would be too much appreciated
Kind regards
Nacho.
6 years, 3 months
Promote new CA master after failure?
by Jonathan Kelley
I've got ipa-server 4.5.0. This is topology with 2 servers and and lost my
primary. I found this guide "Promote CA to Renewal and CRL Master Procedure
in FreeIPA 4.0 or later
<https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master>".
Server 1 failed in my case.
On server 2, I set enableCRLCache, enableCRLUpdates to false in
/etc/pki/pki-tomcat/ca/CS.cfg
I restarted pki-tomcatd@pki-tomcat
I fixed the revokation rule in apache (enabled the rule)
I restarted httpd
Now the FreeIPA website says "Internal Server Error" and running kinit
admin "kinit: Client's credentials have been revoked while getting initial
credentials"
Before CA promotion the website and kinit seemed to be working fine on
server 2. Is kerberos or LDAP or Kerberos broken now? What steps were
missed to failover?
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager.
Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the company.
Finally, the recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused
by any virus transmitted by this email.
6 years, 3 months
Replacing externally signed CA long before expiry
by Steve Dainard
Hello,
Using freeipa 4.5.
I've replaced an external root CA that had a very short key, and have gone
through the process of resigning the ipa intermediate-CA.
I've used ipa-cacert-manage to generate a new csr and have signed it with
my new external CA. The cert was successfully imported.
I also ran ipa-certupdate on 2 of 2 ipa servers and I can see the new CA
listed on both ipa servers with 'certutil -L -d /etc/pki/pki-tomcat/alias'
When I run 'ipa-getcert resubmit -n Server-Cert -d /etc/httpd/alias' on an
ipa server the certificate is resubmitted, but its still being signed by
the old ipa intermediate-CA.
I also see in the web ui under Authentication -> Certificates ->
Certificate Authorities that only one ca named 'ipa' exists, and I can see
the Issuer DN is still the old root CA.
How can I invalidate the old intermediate-CA so the new intermediate-CA is
used to sign certs going forwards?
Thanks,
Steve
6 years, 3 months
Two Different Environments, Crashed First Master
by Michael S. Moody
Within the last week, in two completely separate environments, I've had a
first master go where the Directory Server won't stay running, and as a
result, pki-tomcatd, and other services will never start. This has happened
in two completely separate distinct environments. I've had to basically fix
it by uninstalling the first master, and putting it back.
Does anyone have any idea why? Is there a bug that started very recently?
Both on CentOS 7, both slightly different releases of FreeIPA.
I'm at a loss to explain it.
Thanks,
Michael
6 years, 3 months
Advice about topology for personal use
by Alex Corcoles
Hi,
After some comments on:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...
I decided to file a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1533228
, but the comments there made me doubt my plan to set up FreeIPA, which is
a project to update my dedicated server running CentOS 7 which has ZFS and
runs several personal and public services on KVM VMs (Owncloud, Wordpress,
Redmine, Jenkins...), adding:
* A directory server that allows me to manage users in a centralized way;
both UNIX users and services users
* Seamless private communication between my two homes and my hosted VMs,
also access on foreign networks
* Forget about IP address management and be able to refer to all hosts from
all sites by their hostname
I've set up dnsmasq on each site with internal domains and done proper
delegation which seems to be working correctly, but I'm not sure how to
handle FreeIPA reliability and integrate it with my existing DNS setup. I
would run a FreeIPA server on my dedicated server, but I think I want to
run another server in another place- as I do worry about the FreeIPA server
going down and disabling everything. I don't want to run it at home, so
I've located a cheap VPS provider to host a second instance.
Now, I'm not sure about how to go forward, esp. with regards to DNS. Should
I run FreeIPA's DNS server for easier handling of the SRV records required
for Kerberos et al. or should I add those to my existing servers?
I thought the former was less administrative overhead, until I hit the
problem I commented on the thread mentioned above, which led me to filing
https://bugzilla.redhat.com/show_bug.cgi?id=1533228 but now I doubt that
FreeIPA's DNS server is going to work nicely in my situation- basically due
to me wanting to keep my other DNS setup, DHCP and having a mixture of
public and private IPs.
Anyone thought about this? I'm guessing most FreeIPA installations are run
by people not as cheap as me, and they run multiple servers on public IPs
and be done with it, but I'd like to avoid that cost.
Thanks,
Álex
--
___
{~._.~}
( Y )
()~*~() mail: alex at corcoles dot net
(_)-(_) http://alex.corcoles.net/
6 years, 3 months
