[SOLVED] Re: Debian Wheezy Installation Attempt: subprocess.call issues in setup-kolab?

Johannes Graumann <[email protected]>
Newsgroups gmane.comp.kde.devel.kolab
Message-ID <20121001195913.3471219C20A1__4428.63346911526$1349121574$gmane$org@h1906259.stratoserver.net>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.