LDAP server unavailable: SERVER_DOWN

Wed Jan 10 07:17:17 CET 2018

Hi Marcel,
cool, that it worked out for you.
I didn't have any problems with the new version 1.3.5.17 overnight.
Will keep it.
Ubuntu seems to neglect certain packages !

Best regards
Franz

Am 2018-01-09 20:44, schrieb Marcel Bischoff:
> 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