[Freeipa-users] FreeIPA unresponsive - Causes DOS situations

Tue Nov 11 12:13:39 UTC 2014

I've just cleaned out a ton of slapd_poll timed out messages from the
output and changed the names to protect the innocent, :-)
Here is the output as requested:

*[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds
maximum allowed limit (length=805634565, limit=2097152).  Change the
nsslapd-maxsasliosize attribute in cn=config to increase limit.*

*[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
*[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL security
on connection in CLOSING state*
*[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers from
connection*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling operation
threads*
*[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30
threads to terminate*
*[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down internal
subsystems and plugins*
*[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
*[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
*[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
*[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 <http://1.2.11.15>
B2014.219.179 starting up*
*[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no entries
set up under cn=computers, cn=compat,dc=sample,dc=example*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which
should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which
should be added before the CoS Definition.*
*[11/Nov/2014:13:26:36 +0200] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 for
LDAPS requests*
*[11/Nov/2014:13:26:36 +0200] - Listening on
/var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*
*[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*

On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti <mbasti at redhat.com> wrote:

>  IMHO It's DS bug, can you share DS error log?
> pspacek CCed to examine named logs.
>
> Martin^2
>
>
> On 11/11/14 12:13, Walter van Lille wrote:
>
> Hi Martin, thanks for the reply.
> My version: bind-dyndb-ldap-2.3-5.el6.x86_64
> The server doesn't have journalctl installed but I have the outputs from
> the messages and named.run files that I included here:
>
>  Messages:
>
>  *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable)
> resolving 'example.example.com.10.123.123.123/A/IN': 2001:500:2f::f#53*
> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
> *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
> *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try to adjust
> "timeout" parameter*
>
>  Named.run:
>
>  *client 10.123.123.123#42639: transfer of 'example.example/IN':
> AXFR-style IXFR started*
> *client 10.123.123.123#42639: transfer of ''example.example/IN':
> AXFR-style IXFR ended*
> *client 10.123.123.123#46912: transfer of
> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
> *client 10.123.123.123#46912: transfer of
> '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
> *LDAP query timed out. Try to adjust "timeout" parameter*
> *LDAP query timed out. Try to adjust "timeout" parameter*
> *LDAP query timed out. Try to adjust "timeout" parameter*
>
>  I just replaced the IPs and the actual names with something more generic.
>
>  Regards,
>
>  Walter
>
> On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti <mbasti at redhat.com> wrote:
>
>>   On 06/11/14 14:58, Walter van Lille wrote:
>>
>> Hi,
>>
>>  I need some assistance please.
>> I've taken over an IPA server to manage a few months ago, and it was
>> working fine until recently when it started acting up seemingly off its own
>> accord.
>> When I do an ipactl status it basically gives an output as shown below:
>>
>>
>>
>> *Directory Service: RUNNING *
>>
>>  *Loooooooooooooooooooooooooooooooooooooooooooooooooong pause... (To the
>> tune of 7 minutes sometimes)*
>>
>>  *KDC Service: RUNNING*
>> *KPASSWD Service: RUNNING*
>> *DNS Service: RUNNING*
>> *MEMCACHE Service: RUNNING*
>> *HTTP Service: RUNNING*
>> *CA Service: RUNNING*
>> *ADTRUST Service: RUNNING*
>> *EXTID Service: RUNNING*
>>
>>  Running top showed that ns-slapd was munching almost all my resources,
>> but I got that fixed by upping the cache. Unfortunately this did not
>> correct the issue and it still reacts in the same fashion, although the
>> resources have been freed up now.
>> I've noticed that when I run dig on either the local server or a remote
>> machine that the query basically just times out as shown here:
>>
>>   *dig freeipa.myexample.sample*
>>
>>  *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>>
>> freeipa.myexample.sample*
>> *;; global options: +cmd*
>> *;; connection timed out; no servers could be reached*
>>
>>  When the KDC service fails to start, then name lookups seem OK, but
>> authentication fails. otherwise it's dead in the water.
>>
>>  This also happens:
>>
>>  *sudo ipactl status*
>> *Directory Service: RUNNING*
>> *Unknown error when retrieving list of services from LDAP:*
>>
>>  My software setup is as follows:
>>
>>
>> *CentOS release 6.5 (Final) *
>>
>> *389-ds-base.x86_64   1.2.11.15-34.el6_5 *
>>
>> *bind.x86_64          32:9.8.2-0.23.rc1.el6_5.1 *
>>  *bind-dyndb-ldap.x86_64*
>> *bind-libs.x86_64     32:9.8.2-0.23.rc1.el6_5.1*
>> *bind-utils.x86_64    32:9.8.2-0.23.rc1.el6_5.1*
>> *rpcbind.x86_64       0.2.0-11.el6
>> @anaconda-CentOS-201311291202.x86_64/6.5*
>> *samba4-winbind.x86_64*
>>
>> *krb5-server.x86_64   1.10.3-15.el6_5.1 *
>>
>>
>> *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05 UTC 2014
>> x86_64 x86_64 x86_64 GNU/Linux *
>>
>>  It's not a permanent situation as it sometimes runs 100% for a while,
>> but 80% of the time it is unusable. If anybody can assist me, please be so
>> kind.
>>
>>  Regards,
>>
>>  Walter
>>
>>    Hello please which version of bind-dyndb-ldap do you use?
>> I had similar issue with bind-dyndb-ldap, but it was development version,
>> I'm not sure if this is your case.
>> When named was failing, dirserv was really slow.
>>
>> Can you send journalctl -b -u named log when dig doesn't work??
>>
>> --
>> Martin Basti
>>
>>
>
>
> --
> Martin Basti
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141111/12eb17a1/attachment.htm>