LDAP server unavailable: SERVER_DOWN

[Skale, Franz]

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