Re: 3.0 on Debian Wheezy: setup-kolab failing because of not running 389

On Wednesday, September 26, 2012 17:11:33 Johannes Graumann wrote:
> On Wednesday, September 26, 2012 16:57:18 Jeroen van Meeuwen wrote:
> > On Tuesday, September 25, 2012 09:37:09 PM Johannes Graumann wrote:
> > > Jeroen van Meeuwen wrote:
> > > > On Tuesday, September 25, 2012 04:07:19 PM Johannes Graumann wrote:
> > > >> So I keep digging into this and have been exploring what the
> > > >> responsible
> > > >> 
> > > >> > /usr/lib/python2.7/dist-packages/pykolab/setup/setup_ldap.py
> > > >> 
> > > >> is actually doing.
> > > >> 
> > > >> First off I find that "/usr/sbin/setup-ds-admin.pl" seems to be
> > > >> called "/usr/sbin/setup-ds-admin" here, so
> > > >> 
> > > >> > 225c225
> > > >> > <     setup_ds_admin = "/usr/sbin/setup-ds-admin.pl"
> > > >> > ---
> > > >> > 
> > > >> > >     setup_ds_admin = "/usr/sbin/setup-ds-admin"
> > > >> 
> > > >> might be in order.
> > > > 
> > > > It's actually the '-admin' part of 'setup-ds-admin' that causes the
> > > > process to require the semaphore to be created.
> > > > 
> > > > Using just 'setup-ds' does succeed for me.
> > > 
> > > The semaphore issue is solved (see other part of this thread) by making
> > > sure /dev/shm is actually mounted as tmpfs ... the error described
> > > above is independent of the semaphore isse.
> > 
> > Right - that may resolve the issue for your deployment but it will still
> > fail on a standard Debian installation (permission errors), which we
> > can't sensibly change through packaging or application fixes.
> > 
> > So, I was shipping a patch in the Debian packages for pykolab, that would
> > cause setup-kolab to use 'setup-ds' rather than 'setup-ds-admin', but
> > Paul decided to drop it (#1040[1], [2])
> > 
> > [1] https://bugzilla.kolabsys.com/show_bug.cgi?id=1040
> > [2]
> > http://git.kolabsys.com/apt/pykolab/commit/?id=ed1370beb1024261fdcb2d6e97
> > c9 7e186daac863
> > 
> > > The central parts are:
> > > > Could not import LDIF file '/tmp/ldifUN9JLt.ldif'.  Error: 65280.
> 
> Output:
> > > importing data ...
> > > 
> > > > [25/Sep/2012:11:50:56 +0000] - mkdir_p /var/lib/dirsrv/slapd-kolab:
> > > > error
> > > 
> > > -5966 (Access Denied.)
> > > 
> > > > [25/Sep/2012:11:50:56 +0000] - Can't start because the database
> > > > directory
> > > 
> > > "/var/lib/dirsrv/slapd-kolab/db" either doesn't exist, or is not
> > > accessible
> > > 
> > > > [25/Sep/2012:11:50:56 +0000] - ERROR: Failed to init database (error 
-1:
> > > Unknown error: -1)
> > > 
> > > > Error: Could not create directory server instance 'kolab'.
> > > > Exiting . . .
> > > > Log file is '/tmp/setupIdMLnz.log'
> > > 
> > > '/tmp/ldifUN9JLt.ldif' does not exist and 'ls -la /var/lib/dirsrv/'
> > > gives
> > > 
> > > >drwxrwx---  5 nobody nobody 4096 Sep 25 11:50 slapd-kolab
> > 
> > I reckon the default user/group account for the directory server was
> > patched (in the debian packaging) to be 'dirsrv', not 'nobody'.
> 
> Correct. Solved for now by 'chown -R nobody:nobody /var/lib/dirsrv/', but
> maybe it is more sustainable to use user/group "dirsrv" during setup-kolab?
> 
> Would that interfere anywhere else?

Just tested this and group/user = dirsrv fails with

> 2012-09-26 14:12:34,642 pykolab.auth DEBUG [1812]: Connecting to LDAP...
> 2012-09-26 14:12:34,642 pykolab.auth DEBUG [1812]: Attempting to use LDAP
> URI ldap://localhost:389 *** <ldap.ldapobject.SimpleLDAPObject instance at
> 0x2074368> ldap://localhost:389 - SimpleLDAPObject.set_option ((17, 3),
> {})
> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x2074368>
> ldap://localhost:389 - SimpleLDAPObject.set_option ((17, 3), {})
> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x2074368>
> ldap://localhost:389 - SimpleLDAPObject.simple_bind (('cn=Directory
> Manager', 'qxot4Y05qOTRJ-I', None, None), {})
> *** <ldap.ldapobject.SimpleLDAPObject instance at 0x2074368>
> 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', '3iwOVv4FeIxDIMB'),
>    ('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
>   371, 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(server
>     ctrls),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 my chowning solution seems better for now. Why?

Sincerely, Joh

_______________________________________________
Kolab-devel mailing list
[email protected]
https://www.intevation.de/mailman/listinfo/kolab-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAABCgAGBQJQYw4OAAoJEPEE8yDpbiX78iwQAJI/wi9/rXJ7z/ZEHz6yUpXG
xpIwAUR2IU0j2ABDBgQvhGA+3uvSBmdRt9+k8WX4onSYFQDflK2M4CQjAbInhik7
7jUWYnuOMYnuQ184SScySP8Y6Xo32JYHV6/IJ/aM/gT/t2SINOf9sdIV0DERr1by
cYPXTID4YG8Q5RU1vVnY1p2aUNGgIXhyKR7nkDSWTp6tBJOQkc15jsp5oQY7gQkm
XR1VhofYcUC+eBvL1heItfAmwsUulagO4QF5uEUCCqRkAywaWFuUa4w28Y/Q8r9l
+2n4UhLoY4XPn7mk+KpXdurwhiLvaVQD7/kvYSuP5aKfz0Wu02w3IbWsc5qkpki5
GY839q7816NJ7gy5oN3vYlAX5zHLhZjHETCGy3Z++PVjiXDsYhwLoSWMRKrVO8O0
0To+1DzIQTizlemrOHks3gXv6e4PS2pxB7hwgXaV8fT6qRaS33U8ecfoOcwkGcQ2
iS9UA8AE7j9nXBkYJz4FtwrdMaf1oBl4mreX/p8y01opUUpwCMskkAnvNfFcO/MV
biFDTTqZ0aIiM7XcnVsfc0Yk3eWBq5np3ttdAmkqpWAqA9luZg2Yqw4KrPZhlrbL
nIkyEeHserrerKsieEWT5LUZkVAxEOkpuBhKSw6Y6qjkwz4cAVeKlYFQ4jOOUA3x
xwoTG4HlgsxZPQ8ZZBbO
=gvgV
-----END PGP SIGNATURE-----