389 Directory Server error

Stephen Switzer steve at switzerbusinesssolutions.com
Mon Sep 12 17:07:40 CEST 2016 

This helps immensely! Thank you!

I kept thinking that maybe the next update would fix it... Perhaps there 
should be a little blurb in the UI under ActiveSync telling us the 
status of the folder support? That would be a nice step forward... maybe 
even a toggle there that overrides the $ext_devices logic for that device.


Best regards,

*Stephen H. Switzer*
*voice:* 585.298.9420 [ x7001 ]
*cell:* 585.202.8312
*fax:* 585.625.0020
*email:* steve at SBSroc.com <mailto:steve at SBSroc.com>
/Technical Consultant & System Engineer/
- VMware VSP
- Microsoft MCP, Desktop/Server


*Switzer Business Solutions, LLC*

*web:* www.SwitzerBusinessSolutions.com 
<http://www.switzerbusinesssolutions.com/>
*fb:* www.facebook.com/sbsolutions <http://www.facebook.com/sbsolutions>
- VMware VIP Partner
- HP Authorized Business Development Partner
- Xorcom Certified Dealer


On 09/12/2016 10:07 AM, Troy Carpenter wrote:
>
> I use Nine on all my devices with full multiple folder support.
>
> I’ve seen the other problems you are working in other follow-up 
> threads, but , don’t forget that you will need to change 
> /usr/share/kolab-syncroton/lib/kolab_sync_data.php so that it allows 
> multiple folders with nine.
>
> You need to change the array $ext_devices, around line 106:
>
>    protected $ext_devices = array(
>
> 'iphone',
>
> 'ipad',
>
> 'thundertine',
>
> 'windowsphone',
>
> 'wp',
>
> 'wp8',
>
> 'playbook',
>
> }
>
> Add ‘android’ to the list:
>
> protected $ext_devices = array(
>
> 'iphone',
>
> 'ipad',
>
> 'thundertine',
>
> 'windowsphone',
>
> 'wp',
>
> 'wp8',
>
> 'playbook',
>
> 'android',
>
> }
>
> Nine sends ‘android’ as the device type.  You can also add other 
> device types there.  Samsung devices support multiple folders now in 
> the built-in app, but they don’t send ‘android’, they send their model 
> number which makes for a long list.  For instance, I also have 
> samsungsghi747, samsungsmp600 among others for users of those devices 
> that are not using Nine.  If you need to find out the device type 
> being sent, you can look at the ActiveSync Option in Roundcube.  It 
> will show the device configuration which lists the Device Type.  Use 
> the string listed there, but I’ve found it has to be all lower case in 
> the code listed above.
>
> *From:*users-bounces at lists.kolab.org 
> [mailto:users-bounces at lists.kolab.org] *On Behalf Of *Stephen Switzer
> *Sent:* Monday, September 12, 2016 12:13 AM
> *To:* users at lists.kolab.org
> *Subject:* 389 Directory Server error
>
> I recently was looking at 9folders (android client) and why I can't 
> see any folders on it other than inbox & sent. I decided to see what 
> updates were available on Kolab16 under Centos. After the update, I'm 
> now running 7.2.1511.
>
> Once the update was done, I rebooted, and quickly noticed that I could 
> not send email.I sa errors like this in the maillog:
>
> Sep 11 23:01:14 kolab16 postfix/trivial-rewrite[11366]: warning: 
> ldap:/etc/postfix/ldap/mydestination.cf: table lookup problem
> Sep 11 23:01:16 kolab16 imaps[3445]: badlogin: localhost [127.0.0.1] 
> login [SASL(-13): authentication failure: checkpass failed]
> Sep 11 23:01:24 kolab16 postfix/trivial-rewrite[11366]: warning: 
> dict_ldap_connect: Unable to bind to server ldap://localhost:389 with 
> dn uid=kolab-service,ou=Special Users,dc=sbsroc,dc=com: -5 (Timed out)
>
> Somehow I didn't notice the ldap error at first glance and looked at 
> other things, noticing the following in /var/log/kolab/pykolab.log:
>
> 2016-09-11 23:04:02,420 pykolab.wallace ERROR Module 
> resources.heartbeat() failed with error: Traceback (most recent call 
> last):
>   File "/usr/lib/python2.7/site-packages/wallace/__init__.py", line 
> 89, in modules_heartbeat
>     modules.heartbeat(module, lastrun)
>   File "/usr/lib/python2.7/site-packages/wallace/modules.py", line 
> 128, in heartbeat
>     return modules[name]['heartbeat'](*args, **kw)
>   File "/usr/lib/python2.7/site-packages/wallace/module_resources.py", 
> line 417, in heartbeat
>     resource_dns = auth.find_resource('*')
>   File "/usr/lib/python2.7/site-packages/pykolab/auth/__init__.py", 
> line 220, in find_resource
>     result = self._auth.find_resource(address)
>   File 
> "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 
> 765, in find_resource
>     self._bind()
>   File 
> "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 
> 1435, in _bind
>     self.ldap.simple_bind_s(bind_dn, bind_pw)
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 837, in simple_bind_s
>     res = 
> self._apply_method_s(SimpleLDAPObject.simple_bind_s,*args,**kwargs)
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 818, in _apply_method_s
>     return func(self,*args,**kwargs)
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 208, in simple_bind_s
>     resp_type, resp_data, resp_msgid, resp_ctrls = 
> self.result3(msgid,all=1,timeout=self.timeout)
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 469, in result3
>     resp_ctrl_classes=resp_ctrl_classes
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 476, in result4
>     ldap_result = 
> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 99, in _ldap_call
>     result = func(*args,**kwargs)
> TIMEOUT
>
> When I finally honed in on the ldap server, I tried to start it:
>
> [root at kolab16 ~]# systemctl restart dirsrv at service.service 
> <mailto:dirsrv at service.service>
> Job for dirsrv at service.service <mailto:dirsrv at service.service> failed 
> because a configured resource limit was exceeded. See "systemctl 
> status dirsrv at service.service <mailto:dirsrv at service.service>" and 
> "journalctl -xe" for details.
>
> So I ran the suggestion:
>
> [root at kolab16 ~]# journalctl -xe
> Sep 11 23:17:44 kolab16.sbsllc.local imaps[12089]: starttls: TLSv1.2 
> with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits reused) no 
> authentication
> Sep 11 23:17:46 kolab16.sbsllc.local imaps[11890]: badlogin: localhost 
> [127.0.0.1] plaintext odoo at mydomain.com <mailto:odoo at mydomain.com> 
> SASL(-13): authentication failure: checkpass fai
> Sep 11 23:18:14 kolab16.sbsllc.local imaps[12089]: timeout_select: 
> reading from ptloader: Connection timed out
> Sep 11 23:18:14 kolab16.sbsllc.local imaps[12089]: ptload failed: but 
> canonified support at mydomain.com <mailto:support at mydomain.com> -> 
> support at mydomain.com <mailto:support at mydomain.com>
> Sep 11 23:18:16 kolab16.sbsllc.local polkitd[926]: Registered 
> Authentication Agent for unix-process:12166:120602 (system bus name 
> :1.36 [/usr/bin/pkttyagent
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: Failed to load 
> environment files: No such file or directory
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: 
> dirsrv at service.service <mailto:dirsrv at service.service> failed to run 
> 'start' task: No such file or directory
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: Failed to start 389 
> Directory Server service..
> -- Subject: Unit dirsrv at service.service 
> <mailto:dirsrv at service.service> has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> -- 
> -- Unit dirsrv at service.service <mailto:dirsrv at service.service> has failed.
> -- 
> -- The result is failed.
>
> The 389 server is not running... I couldn't log in to roundcube, could 
> send email with thunderbird, etc. the web admin panel also didn't let 
> me log in. Since the auth backend is down, that's expected.
>
> I rolled back to a snapshot of this virtual machine, and booted it 
> up... same issue!! Since the old versio behaved the same way, I went 
> back to the newly updated snapshot. I figure if it's failing, I might 
> as well work on the latest version.
>
> After letting it sit for a while during my google research, I received 
> a "new mail" desktop notification from my browser. Uhmmmmm. It started 
> working on its own!
>
> I checked the service status, and it still says it failed:
>
> [root at kolab16 ~]# systemctl status dirsrv at service.service 
> <mailto:dirsrv at service.service>
> ● dirsrv at service.service <mailto:dirsrv at service.service> - 389 
> Directory Server service.
>    Loaded: loaded (/usr/lib/systemd/system/dirsrv at .service 
> <mailto:/usr/lib/systemd/system/dirsrv at .service>; enabled; vendor 
> preset: disabled)
>    Active: failed (Result: resources)
>
> Sep 11 23:10:56 kolab16.sbsllc.local systemd[1]: Failed to load 
> environment files: No such file or directory
> Sep 11 23:10:56 kolab16.sbsllc.local systemd[1]: 
> dirsrv at service.service <mailto:dirsrv at service.service> failed to run 
> 'start' task: No such file or directory
> Sep 11 23:10:56 kolab16.sbsllc.local systemd[1]: Failed to start 389 
> Directory Server service..
> Sep 11 23:10:56 kolab16.sbsllc.local systemd[1]: 
> dirsrv at service.service <mailto:dirsrv at service.service> failed.
> Sep 11 23:10:56 kolab16.sbsllc.local systemd[1]: Starting 389 
> Directory Server service....
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: Failed to load 
> environment files: No such file or directory
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: 
> dirsrv at service.service <mailto:dirsrv at service.service> failed to run 
> 'start' task: No such file or directory
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: Failed to start 389 
> Directory Server service..
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: 
> dirsrv at service.service <mailto:dirsrv at service.service> failed.
> Sep 11 23:18:16 kolab16.sbsllc.local systemd[1]: Starting 389 
> Directory Server service....
>
> But... the LDAP port is open and listening:
>
> [root at kolab16 ~]# netstat -nap | grep 389 | grep "LISTEN "
> tcp6       0      0 :::389 :::*                    LISTEN      
> 705/ns-slapd
> [root at kolab16 ~]#
>
> ...and I'm still seeing errors all over the kolab logs.
>
> 2016-09-11 23:46:54,908 pykolab.auth ERROR Traceback (most recent call 
> last):
>   File 
> "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 
> 3059, in _search
>     secondary_domains
>   File "<string>", line 10, in <module>
>   File 
> "/usr/lib/python2.7/site-packages/pykolab/auth/ldap/__init__.py", line 
> 2738, in _persistent_search
>     resp_ctrl_classes={ecnc.controlType:ecnc}
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 476, in result4
>     ldap_result = 
> self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
>   File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 
> 99, in _ldap_call
>     result = func(*args,**kwargs)
> TIMEOUT
>
> There must be something wrong underlying, but the system is working... 
> (I just sent this email!) I'd like to make sure it's working the the 
> right reason and that it'll stay up. Thank you to anyone that can lend 
> me some input.
>
> -- 
>
> Best regards,
>
> *Stephen H. Switzer*
> /Technical Consultant & System Engineer/
> - VMware VSP
> - Microsoft MCP, Desktop/Server
>
>
> *Switzer Business Solutions, LLC*
> - VMware VIP Partner
> - HP Authorized Business Development Partner
> - Xorcom Certified Dealer
>
>
>
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20160912/e034d750/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graphics1
Type: image/png
Size: 4525 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20160912/e034d750/attachment-0001.png>

More information about the users mailing list