[Kolab-devel] kolabctl instead of kolabsrv

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Mon Oct 11 12:14:24 CEST 2010


Hi there,

In native packaging, as well as with the eye on the future, I decided kolabsrv 
is not suitable for the job it's supposed to do, for the following reasons;

- kolabsrv assumes all applications related to kolab are installed on the 
local host, which of course is not necessarily true. It's not acceptable to 
have to change the code of the script to make the script work in certain 
deployment scenarios;

- kolabsrv will fail in case any of such applications are not installed on the 
local host, which of course requires change to the code of the script to make 
it work in certain deployment scenarios;

- kolabsrv maintains lists of applications and service names per distribution, 
resulting in the following downsides;

  - it's not providing the necessary option value to use a different ldap 
technology,

  - it's not providing the necessary option value to not have ldap, or AS/AV, 
or MTA, or (...), installed on the backend server,

  - with changes being made across distributions, we'd have to make changes to 
the script that go across distributions as well,

  - when changes are being made in between one released version of a 
distribution, and the following released version of a distribution, the script 
would require additional intelligence to take into account not only the 
distribution, but the distribution version as well;

- kolabsrv is a wrapper utility, and should therefor be called 'control' or 
'ctl'. The 'srv' part merely applies to the kolab daemon itself;

- kolabsrv.in results in a generated script which then also draws it's own 
conclusions; this is inappropriate because part of the script's execution is 
now subject to compile-time, and part of it's execution is subject to it's 
runtime; it's easy enough to make that be runtime only to avoid support issues 
with the script resulting in having to rebuild anything;

- kolabsrv / kolabctl is a utility, because it is a wrapper script, and as 
such is not part of the kolab server per-se, nor of the perl-Kolab library. It 
should, therefor, live in a kolab-utils type of location; which we do not have 
right now.

Similarly, in relation to the latter point, many of the bin/ and sbin/ 
utilities now still a part of the perl-Kolab library location in the SCM, are 
actually utilities as well. To say the least, the perl-Kolab perl library 
should be cleaned out and only contain the parts of the code that actually 
relate to the perl library. However, that's besides the $subject in this OP 
for now;

I've made available a general, conceptual idea of what a kolabctl script could 
look like in HG;

  http://hg.kolab.org/server/file/fdb4dec37808/kolabd/kolabd/dist_conf/kolabctl

Noted that 1) the simple lists are not complete in this version, but I'm not 
allowed to continue to work on it because apparently it confuses some people, 
2) some intelligence might be added provided a more intelligent configuration 
management framework / utility -which is an entirely different realm of 
changes and outside $subject of this OP as well.

Kind regards,

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




More information about the devel mailing list