Can't get throught setup-kolab

[Paul Boddie]

On Thursday 5. June 2014 06.12.48 dsp3 wrote:
> I initially wrestled with Kolab 3.2 on CentoS 6.5. I used the following
> posts to get a working installation:
> http://kolab.org/blog/zharvek/2014/03/19/installing-kolab-3.2-centos
> http://immersia.de/2014/03/weg-von-goolge-mit-dem-eigenen-vpsroot-server-ce
> ntos-6-5-kolab-3-2-owncloud-6-plex/
> 
> I summarised my own experiences here:
> http://www.dsp3.org/kolab-opensource-unified-communication-and-
collaboration-system/

Those are some useful notes. On the subject of getting setup-kolab to behave 
better, I made my branch of the pykolab code available here:

http://git.kolab.org/pykolab/log/?h=dev/boddie

It's quite possible that some of your fixes were already incorporated into 
some of my refactoring and general fixing. Unfortunately, some of my 
refactoring was a bit too invasive, making for awkward large merges that 
perhaps don't encourage the code getting merged with the main branch, but you 
never know.

Meanwhile...

> On 2014-06-05 02:45, Thomas Marshall wrote:
> > [04/Jun/2014:15:49:49 -0400] - Failed to create semaphore for stats
> > file
> > (/var/run/dirsrv/slapd-my.stats). Error 13.(Permission denied)
> > Possible timeout starting server: timeout=1401911989 now=1401911990
> > [14/06/04:15:59:50] - [Setup] Info Could not start the directory server
> > using command '/usr/lib64/dirsrv/slapd-my/start-slapd'.  The last line
> > from
> > the error log was '[04/Jun/2014:15:49:49 -0400] - Failed to create
> > semaphore
> > for stats file (/var/run/dirsrv/slapd-my.stats). Error 13.(Permission
> > denied)
> > '.  Error: Unknown error 256
> > [14/06/04:15:59:50] - [Setup] Fatal Error: Could not create directory
> > server
> > instance 'my'.
> > [14/06/04:15:59:50] - [Setup] Fatal Exiting . . .
> > Log file is '/tmp/setupVSnRbs.log'

I would say that the LDAP configuration is one area I looked at and tried to 
improve in setup-kolab. But on CentOS and Red Hat distributions, I'd also be 
wary of any SELinux settings, too. I've experienced problems with /var/run, 
albeit with other software, and although I'd expect the packages to set the 
appropriate metadata in advance upon installation, it's always worth checking 
the output of "ls -Z" to explain any otherwise inexplicable permissions-
related errors.

Paul