[Kolab-devel] [Debian BUG REPORT] Re: Debian Wheezy Installation Attempt: subprocess.call issues in setup-kolab?

[Johannes Graumann]

Johannes Graumann wrote:

> Johannes Graumann wrote:
> 
>> Hi, this lates one really has me confused ...
>> 
>> On wheezy I run "setup-kolab' and the error I am finally encountering is
>>> 2012-09-29 20:30:13,418 pykolab.auth DEBUG [13534]: Attempting to use
>>> LDAP
>> URI ldap://localhost:389
>>> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x1bfb638>
>> ldap://localhost:389 - SimpleLDAPObject.set_option
>>> ((17, 3), {})
>>> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x1bfb638>
>> ldap://localhost:389 - SimpleLDAPObject.set_option
>>> ((17, 3), {})
>>> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x1bfb638>
>> ldap://localhost:389 - SimpleLDAPObject.simple_bind
>>> (('cn=Directory Manager', 'WCawmmQ4hpZURnk', None, None), {})
>>> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x1bfb638>
>> ldap://localhost:389 - SimpleLDAPObject.add_ext
>>> (('uid=cyrus-admin,ou=Special Users,dc=graumannschaft,dc=org',
>>>   [('surname', 'Administrator'),
>>>    ('uid', 'cyrus-admin'),
>>>    ('objectclass',
>>>     ['top', 'person', 'inetorgperson', 'organizationalperson']),
>>>    ('userPassword', 'zbBStCZKRhgHeCE'),
>>>    ('givenname', 'Cyrus'),
>>>    ('cn', 'Cyrus Administrator')],
>>>   None,
>>>   None),
>>>  {})
>>> Traceback (most recent call last):
>>>   File "/usr/sbin/setup-kolab", line 42, in <module>
>>>     setup.run()
>>>   File "/usr/lib/python2.7/dist-packages/pykolab/setup/__init__.py",
>>>   line
>> 42, in run
>>>     components.execute('_'.join(to_execute))
>>>   File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py",
>> line 170, in execute
>>>     execute(component)
>>>   File "/usr/lib/python2.7/dist-packages/pykolab/setup/components.py",
>> line 202, in execute
>>>     components[component_name]['function'](conf.cli_args, kw)
>>>   File "/usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py",
>> line 394, in execute
>>>     auth._auth.ldap.add_s(dn, ldif)
>>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 194,
>>>   in
>> add_s
>>>     msgid = self.add(dn,modlist)
>>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 191,
>>>   in
>> add
>>>     return self.add_ext(dn,modlist,None,None)
>>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 176,
>>>   in
>> add_ext
>>>     return
>> 
> 
self._ldap_call(self._l.add_ext,dn,modlist,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
>>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99,
>>>   in
>> _ldap_call
>>>     result = func(*args,**kwargs)
>>> ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}
>> 
>> So far so good - 'service dirsrv status' also says it's not running ...
>> hmmm ...
>> 
>> With the slapd-kolab now configured, I can use
>> 'subprocess.call(['/usr/sbin/service', 'dirsrv', 'restart'])' from within
>> a python shell to make disrv (389) run ... hm.
>> 
>> I now started to pepper the attached version of setup_ldap.py with calls
>> like this:
>>> print 'Status -1'
>>> subprocess.call(['/usr/sbin/service', 'dirsrv', 'status'])
>> and to my dismay, that ALWAYS returns that dirsrv is NOT running (see
>> attachment for the locations of the calls). What is going wrong here?
>> Firing up the dirsrv works from within a python shell using the same
>> commands !?
>> 
>> Puzzled, Joh
> 
> This was a tough one ... turns out that dirsrv in debian has a bug:
> "service dirsrv restart" will not work, as the 389 port has not yet been
> released when the starting process tries to bind to it ... thus changing
>> subprocess.call(['/usr/sbin/service','dirsrv','restart'])
> to
>> subprocess.call(['/usr/sbin/service','dirsrv','stop'])
>> time.sleep(20)
>> subprocess.call(['/usr/sbin/service','dirsrv','start'])
> solves the problem.
> 
> See the attached setup_ldap.py ... patchset forthcomming ...
> 
> Sincerely, Joh

As there was some sceptizism expressed on IRC regarding my finding, I set 
out to reproduce it in a lxc-free context on my local machine - and was able 
to do so. Accordingly I filed a bugreport with debian - it contains detailed 
instruction on how to reproduce: http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=689389

Sincerely, Joh