[Kolab-devel] Autofoo Proposal

Wed May 12 21:00:53 CEST 2010

Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> 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) ...

I still don't see why you would determine that during build time. How  
would people identify the correct package they would need to download?  
I assume the --with-ldaprc option is nothing you'd find represented in  
the file name of the resulting RPM or am I wrong?

Or are these really different "distributions" for Fedora? Is it  
impossible to go from "dirsrv" to "redhat-ds" or "slapd" in a running  
system? If you cannot and that is really its own distribution then I  
agree it is a build time job. Otherwise it is a configuration job for  
the installed system.

Anyhow as mentioned in my last mail I'm not really against you  
autoconf proposal as I see situations where it can automate and  
simplify package maintenance for different distributions. So if you  
can come up with some reasonable patches I think we should integrate  
them.

In the long term I'm still dreaming of a more decent configuration  
management for the Kolab server in general but I realize that this is  
difficult because of time constraints.

Cheers,

Gunnar

>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100512/8a63a18f/attachment.sig>