[Kolab-devel] 3.0 on Debian Wheezy: setup-kolab failing because of not running 389
Johannes Graumann
johannes_graumann at web.de
Wed Sep 26 16:15:42 CEST 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120926/a516f14f/attachment.sig>
More information about the devel
mailing list