LDAP server unavailable: SERVER_DOWN

[Marcel Bischoff]

Thanks. I will try to transplant the Debian Stretch package to the
Ubuntu machine tonight when there is no traffic on the server and report
on my success/failure.

Regarding blame, you are probably correct that Kolab is not directly to
blame. I would however expect a caveat notice or similar to be added to
the installation instruction overview pointing out issue like this, as
this one on particular is a breaking issue (not being able to log in
that is).

In case the transplantation is not successful, do you think a removal of
the respective packages followed by an installation from source be
possible without breaking things?

Best,
Marcel

On 18/01/09, Skale, Franz wrote:
>After investigating  you can clearly see, that ubuntu stopped patching
>of ds389-base with version 1.3.4.9 while debian stretch uses correct
>patched version 1.3.5.15.
>The ubuntu version is missing some CVE patches as well as non nss ldap
>builds.
>This could be your problem.
>You can try packaging the debian stretch version on ubuntu 16.04.
>I often port packages to unbuntu because of the inferior package
>maintenance they provide.
>Jessie uses a much older but stable version 1.3.3.5 though.
>Cannot blame kolab for that.
>
>Rgds.
>Franz
>Am 2018-01-08 16:03, schrieb Marcel Bischoff:
>>>On 8. Jan 2018, at 15:58, Jochen Hein <jochen at jochen.org> wrote:
>>>
>>>Marcel Bischoff <marcel at herrbischoff.com> writes:
>>>
>>>>I have recently set up a Kolab 16 installation, following this
>>>>guide:
>>>>https://docs.kolab.org/installation-guide/ubuntu-16.04.html
>>>>
>>>>Initially everything worked alright until users started connecting
>>>>continually. Now, from time to time, without immediate apparent
>>>>reason, the LDAP service becomes unreachable (according to the log
>>>>messages). This can only be solved by manually restarting the service
>>>>with "systemctl restart dirsrv at mx.service". Even restarting the
>>>>server
>>>>does nothing to recitify this, although the service is started
>>>>at that
>>>>time.
>>>
>>>Can you have a look at the dirsrv logs (access&error)?
>>
>>Good idea, I just did. Here is the tail of the "errors" file. The
>>"access" file has way too many entries to be usefulin this context:
>>
>>[07/Jan/2018:19:39:15 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f146c7e7bd0 to pblock addr 7f14480088d0
>>[07/Jan/2018:20:42:50 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f14747f7bd0 to pblock addr 7f13f400cf50
>>[07/Jan/2018:21:46:16 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f1476ffcbd0 to pblock addr 7f14000097f0
>>[08/Jan/2018:09:35:30 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f14727f3bd0 to pblock addr 7f1428008100
>>[08/Jan/2018:09:35:31 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f14757f9bd0 to pblock addr 7f1420000d50
>>[08/Jan/2018:10:21:28 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f14727f3bd0 to pblock addr 7f1428006770
>>[08/Jan/2018:11:16:07 +0100] - 389-Directory/1.3.4.9 B2016.109.158
>>starting up
>>[08/Jan/2018:11:16:07 +0100] - Detected Disorderly Shutdown last time
>>Directory Server was running, recovering database.
>>[08/Jan/2018:11:16:08 +0100] - slapd started.  Listening on All
>>Interfaces port 389 for LDAP requests
>>[08/Jan/2018:11:24:53 +0100] - 389-Directory/1.3.4.9 B2016.109.158
>>starting up
>>[08/Jan/2018:11:24:53 +0100] - Detected Disorderly Shutdown last time
>>Directory Server was running, recovering database.
>>[08/Jan/2018:11:24:53 +0100] - slapd started.  Listening on All
>>Interfaces port 389 for LDAP requests
>>[08/Jan/2018:11:26:41 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f471dff2bd0 to pblock addr 7f46c4004900
>>[08/Jan/2018:14:39:09 +0100] - 389-Directory/1.3.4.9 B2016.109.158
>>starting up
>>[08/Jan/2018:14:39:09 +0100] - Detected Disorderly Shutdown last time
>>Directory Server was running, recovering database.
>>[08/Jan/2018:14:39:09 +0100] - slapd started.  Listening on All
>>Interfaces port 389 for LDAP requests
>>[08/Jan/2018:14:39:20 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f0fdbffebd0 to pblock addr 7f0f5c00bc80
>>[08/Jan/2018:15:24:48 +0100] NSACLPlugin - acl_access_allowed:
>>Resetting aclpb_pblock 7f0fdb7fdbd0 to pblock addr 7f0fac008480
>>
>>Well... "Disorderly Shutdown" does not sound good at all.
>>_______________________________________________
>>users mailing list
>>users at lists.kolab.org
>>https://lists.kolab.org/mailman/listinfo/users