[Kolab-devel] Autofoo Proposal
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Wed May 12 08:59:50 CEST 2010
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
> > detecting where, for example, php is located (it's used in, for example,
> > 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
> > by means of packaging). Red Hat Enterprise Linux customers and CentOS
> > don't think that's funny. Yet though, on a standalone Kolab server,
> > some ldap server makes perfect sense (think ClarkConnect). I would thus
> > 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
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:
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
pgp: 9342 BF08
More information about the Kolab-devel