[Kolab-devel] [PARTIALLY SOLVED] Re: 3.0 on Debian Wheezy: setup-kolab failing because of not running 389

[Johannes Graumann]

Johannes Graumann wrote:

> Johannes Graumann wrote:
> 
>> Hello,
>> 
>> My wheezy/3.0 odyssey now has led me to the error reported as the end of
>> the 'setup-kolab -d 9' output below:
>>> ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}
>> 
>> Indeed, the installation log from aptitude also contains this:
>>> Setting up 389-ds-base (1.2.11.7+nmu1-5) ...
>>> adduser: Warning: The home directory `/var/lib/dirsrv' does not belong
>>> to the user you are currently creating.
>>> [info] no dirsrv instances configured so not starting 389 DS.
>> 
>> and 'service dirsvr start' reproduces the "no instance configured" bit
>> ...
>> 
>> It looks like setup-kolab needs to have 389 running, which won't start
>> ... any pointers on how to overcome this obstacle?
>> 
> 
> Running '/usr/sbin/setup-ds' is bringing me full circle to my earlier
> attempts on CentOS, where the lxc-container based installation (wheezy
> also runs in lxc) would also produce the last statement seen in
> /var/log/dirsrv/slapd-kolab/errors
>>         389-Directory/1.2.11.7 B2012.250.1648
>>         kolab.<MYDOMAIN>.org:389 (/etc/dirsrv/slapd-kolab)
>> 
>> [24/Sep/2012:12:32:06 +0000] - WARNING: Import is running with
>> [nsslapd-db-
> private-import-mem on; No other process is allowed to access the database
>> [24/Sep/2012:12:32:06 +0000] - check_and_set_import_cache: pagesize:
>> [4096,
> pages: 1007173, procpages: 48653
>> [24/Sep/2012:12:32:06 +0000] - Import allocates 1611476KB import cache.
>> [24/Sep/2012:12:32:06 +0000] - import userRoot: Beginning import job...
>> [24/Sep/2012:12:32:06 +0000] - import userRoot: Index buffering enabled
> with bucket size 100
>> [24/Sep/2012:12:32:07 +0000] - import userRoot: Processing file
> "/tmp/ldifbCMGzg.ldif"
>> [24/Sep/2012:12:32:07 +0000] - import userRoot: Finished scanning file
> "/tmp/ldifbCMGzg.ldif" (9 entries)
>> [24/Sep/2012:12:32:07 +0000] - import userRoot: Workers finished;
>> [cleaning
> up...
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Workers cleaned up.
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Cleaning up producer
> thread...
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Indexing complete.  Post-
> processing...
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Generating
>> [numSubordinates
> complete.
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Flushing caches...
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Closing files...
>> [24/Sep/2012:12:32:08 +0000] - All database threads now stopped
>> [24/Sep/2012:12:32:08 +0000] - import userRoot: Import complete.
> Processed 9 entries in 2 seconds. (4.50 entries/sec)
>> [24/Sep/2012:12:32:09 +0000] - 389-Directory/1.2.11.7 B2012.250.1648
> starting up
>> [24/Sep/2012:12:32:09 +0000] - Failed to create semaphore for stats file
> (/var/run/dirsrv/slapd-kolab.stats). Error 38.(Function not implemented)
>> 
> 
> If I now only remembered how that was fixed ...
OK, for the record: apparently /dev/shm functionality relies on it being 
mounted using tmpfs. As the debian template for lxc generates a symbolic 
link /dev/shm --> /run/shm the following had to be added to the container's 
config file to make all the semaphore issues go away:

lxc.mount.entry = tmpfs /var/lib/lxc/kolab.<MYDOMAIN>.org/rootfs/run/shm 
tmpfs  defaults 0 0

Sincerely, Joh