LDAP server unavailable: SERVER_DOWN

Tue Jan 9 20:44:58 CET 2018

Thank you very much for the testing and the pointers. I was successfully
able to port the package to the Ubuntu 16.04 machine. dpkg-buildpackage
complained about quite a lot of missing dependencies that were easily
install though, with a notable exception of a missing libsvrcore-dev (>=
1:4.1.2+dfsg1-3) dependency, so I had to build and install that as well,
similar to what you had to do on Jessie.

Restarting dirsrv was very quick compared to before and for now
everything appears to be running smooth. So I'm going to go ahead and
send a very big THANK YOU your way. If this works out, you will truly
have saved me from The Wrath of the Users(tm)... ;)

Have a good evening!

Best,
Marcel

On 18/01/09, Skale, Franz wrote:
>Hi,
>i successfully backported this particular package to jessie:
>https://packages.debian.org/stretch/389-ds-base
>For jessie to work, i also had to build:
>https://packages.debian.org/stretch/libsvrcore0
>This will not be necessary for 16.04
>Before building , check the debian/control file for dependencies.
>The build with: dpkgbuildpackage -us -uc (after dpkg-source -x (dsc).
>Since there are a lot of bugfixes, i gave it a try and it works
>properly.
>I did a backup of /var/lib/dirsrv and /etc/dirsrv before, because the
>ldifs werde, of course, migrated too.
>Nevertheless i would give it a try.
>
>Rgds.
>Franz
>
>Am 2018-01-09 17:40, schrieb 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