[Kolab-devel] kolabctl instead of kolabsrv
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Tue Oct 12 19:48:30 CEST 2010
Richard Bos wrote:
> Op maandag 11 oktober 2010 12:14:24 schreef Jeroen van Meeuwen (Kolab
>
> Systems):
> > - 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;
>
> The script contains this:
> # Some distributions run / control the services clamav and freshclam from
> # amavisd. The services can be unset in @sysconfdir@/kolab/profile.sh,
> # when unset, they are not called obviously.
> CLAMAV=clamav
> FRESHCLAM=freshclam
>
> [[ -f /etc/kolab/profile.sh ]] && . /etc/kolab/profile.sh
>
> If other services than clamav or freshclam or to be skipped add the
> necessary variables to it, so it is possible.
>
> What the script accomplish, is that depending on the check spam/virus in
> the web GUI, clamav and freshclam are started or not started. So, if you
> extend this, you could specify in the web GUI what service you want to run
> for ldap, MTA, and whatever.
>
This does not even remotely apply to the two points I've made;
- No kolab/profile.sh nor $CLAMAV/$FRESHCLAM variable can control whether the
script knows the application is not installed, not available, critical or
delegated to another system.
- Shipping different profile.sh versions is exactly the same thing as shipping
different kolabsrv's, etc/defaults or etc/sysconfigs, which is not necessary
at all if and when;
1) the script learns to take into account what more intelligent
configuration management could apply to a system's configuration,
2) the script learns to not error out when any of the LSB compliant rc
scripts fail executing a 'stop',
3) (cumulatively) replace the script with something sane.
> > - 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,
>
> See above.
>
> (to what are you referring with AS/AV)
>
Like I said; Does not apply.
> > - with changes being made across distributions, we'd have to make
> > changes
> >
> > to the script that go across distributions as well,
>
> I don't see what you mean.
>
Suppose Red Hat renames the rc script for openldap from ldap to openldap. This
would mean the script would be updated, and the updated script would need to
be distributed across all distributions, while effectively not including any
changes related to the distributions other then Red Hat.
> > - 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;
>
> Just provide a different @sysconfdir@/kolab/profile.sh with your rpm.
>
Already addressed in the aforementioned.
> > - kolabsrv is a wrapper utility, and should therefor be called 'control'
> >
> > or 'ctl'. The 'srv' part merely applies to the kolab daemon itself;
>
> Rename the script in the spec file to whatever name is appreciated by the
> distribution.
>
Does not solve the non-functioning script.
> > - 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;
>
> Do you mean this part:
> 22 function rcrun() {
> 23 $RCDIR/$SERVICE $PARAM
> 24 retc=$?
> 25 if [ $retc -ne 0 ] && [ $retc -ne 3 ]; then
> 26 ( echo "ERROR: $RCDIR/$SERVICE $PARAM failed"
> 27 echo "Run: $PRGNAME rc all stop"
> 28 echo "to stop all services"
> 29 ) >&2
> 30 exit 1
> 31 fi
> 32 }
>
> That is LSB compliant, that should be a no problem.
>
The kolabsrv/kolabctl script itself should not be LSB compliant -it is not an
rc script itself, but should only make use of any existing, LSB-compliant
service provider scripts. How you want it to error out (return codes) also
does not in any way relate to whether you want it to error out at all in the
first place.
> > - 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/ko
> > la
> >
> > bctl
> >
> > 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.
>
> Whatever, you like. But work with the community please....
I'm giving you a solution on a silver platter. You start arguing against it,
and instead of doing so with some progressive suggestions, you start telling
me what I might do to marginally improve to the existing script, thinking
maybe I didn't think of improving the existing script? I've stated my reasons
that caused me to conclude the script is not up for the task, not a list of
questions about what I might do to adopt it to what I need.
Who did you suggest is not working with whom exactly?
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