[Kolab-devel] Autofoo Proposal

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> > The configuration is difficult enough without an extra paragraph in the
> > configuration manual on changing a default setting ;-) Additionally,  
> > one could
> > argue it's way more efficient to spend the time upstream once, at the
> > distributor once, then to have thousands of people run in circles checking
> > their default configuration files for error-by-default.
> 
> No, of course that is not desired. Right now the default configuration  
> works out of the box and this should indeed stay that way.
> 

Actually, from where I'm sitting (Fedora realm), the default configuration 
does not work out-of-the-box. Even though that's also dependent on a different 
problem, one of the problems is the extent to which the dist_conf mechanism 
let's me adapt the product to the contents of a buildroot, and how such ends 
up on a system.

> > By saying "auto-detecting the server configuration", what I meant to say 
is
> > detecting where, for example, php is located (it's used in, for example, 
the
> > master.cf.template, but also the httpd.conf.template), or  
> > cyrus.conf, and many
> > others.
> 
> To that I agree. It would simply mean that maintaining the dist_conf  
> file becomes much easier as the maintainer does not need to search for  
> these settings manually. Using autoconf during build time for that  
> seems perfectly valid.
> 
> > For example, I would like to have an option that allows me to disable
> > kolab assuming the LDAP server is local (and thus pulling in the 
requirement
> > by means of packaging). Red Hat Enterprise Linux customers and CentOS 
users
> > don't think that's funny. Yet though, on a standalone Kolab server, 
requiring
> > some ldap server makes perfect sense (think ClarkConnect). I would thus 
like
> > to be able to toggle those options during build time.
> >
> 
> That however is something different and here I don't see how autoconf  
> would help. The packages will probably be build on some build server  
> and whether LDAP is installed there or not does not seem to matter to  
> me. Isn't the installation of the package the relevant step here?
> 

It's all about generating the default configuration file shipped with the 
package.

kolabsrv and kolabconf need to know things part of which is in 
/etc/kolab/kolab.globals. Either way, whether generated statically or 
configured dynamically, the defaults need to make sense.

Hence, for LDAP, I would like to have:

./configure --with-ldaprc=/etc/init.d/dirsrv (389-ds)
./configure --with-ldaprc=/etc/init.d/redhat-ds (redhat-ds)
./configure --with-ldaprc=/etc/init.d/slapd (openldap)

or, for SUSE:

./configure --with-ldaprc=/etc/rc.d/init.d/ldap

A default ./configure (no --with-ldaprc option) would just go through a list 
and see what's in the buildroot (controlled by BuildRequires while preserving 
the possibility to override). *Additionally*, --without-ldaprc becomes 
available for those situations where the LDAP server is not local, and thus 
kolabsrv/kolabconf do not 1) need to generate the template settings, 2) 
check/restart any of the LDAP services, 3) may not be able to generate hashed 
passwords, 4) ..., 5) ...

There's a number of settings and variables that need sane defaults, and then 
there's some more (scripted) routines that are completely subject to the 
specific platform (look at kolabsrv.in, but also kolab_sslcert.sh.in).

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08