[Kolab-devel] kolabctl instead of kolabsrv
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Wed Oct 13 00:28:14 CEST 2010
Richard Bos wrote:
> Jeroen,
>
> no need to Cc me, I'm subscribed to the ML (you should know by know).
>
Please configure, in your mailman subscription preferences, that mailman
should not deliver you a copy of what will apparently already be delivered to
you. This should have been a default setting but regrettably I do not
administer the list server this runs on.
> Op dinsdag 12 oktober 2010 19:48:30 schreef Jeroen van Meeuwen (Kolab
>
> Systems):
> > > 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.
>
> In case you replace it with another tool, remember that openSUSE uses
> /etc/init.d and not /etc/rc.d. Your current script, being a work in
> progress, does that not take that into account yet.
>
> > > > - 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.
>
> OK. What do you mean with AS and AV?
>
Anti-Spam/Anti-Virus.
> > > > - 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.
>
> Correct. But this hardly happens.
>
> > > > - 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.
>
> Pfffff. It solves the name of the script, and that is what you complained
> about in the lines above.
>
If that's what you have taken away from all of it, I'm sorry.
> > > > - 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_con
> > > > f/
> > > >
> > > >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
>
> Indeed. Some things are missing in your script at the moment. Perhaps you
> wanted to add that, but did not have the time yet to do that. The thing
> missing: /etc/init.d for openSUSE and it does not take into account whether
> freshclam or clamav must be started or not, depending on the setting in the
> web GUI. More could be missing the list argument, e.g.
>
The parsing of any type of configuration is currently subject to the
configuration utility in use, whereas this script just takes "if installed,
then put forth action". I'm thinking, rather then nailing it down right now,
for the future we may want to first think about how we apply any configuration
changes to any given system possibly including the removal of packages from
said system.
That said, this new kolabctl is not something that is going to replace
anything in 2.2 for sure - it might in 2.3 but only if it's good and ready,
while I'd say 3.0 right now seems a more reasonable target milestone.
> > 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?
>
> I've been working for over 5 years in this community, and we've to become
> to respect each other.
>
This community itself has certainly impacted how I choose to interact with it.
You may have seen some of it going through these lists. The former not
withstanding, I may have needed to indeed show some more restraint in some
aspects. If I offended you or anyone else for that matter, in any way, I
sincerely apologize and please rest assured such has not ever been my
intention.
> On the other hand, you showed up somewhere in spring and start to tell that
> a lot of things are not good, that you know everything very well as a
> senior engineer, this and that, etc. In other words at this moment you
> behave like an elephant in the porcelain cupboard ( you know the
> expression). You might be right that things are not the way they should
> be, and perhaps this community went the wrong direction. But perhaps
> adapt to the community and become one with it.
Well, normally, or at least from what I'm used to, communities are delighted
to obtain or have obtained new perspective from outsiders or any other type of
resource willing to sink their teeth into whatever. Such most evidently shows,
for example, with the Cyrus community. The difference between what happened
here and what happens elsewhere is these other communities ask "how?" and not
"if" or "why?" types of questions.
That said, I'm the type of guy that moves forward fast; It's part of the
reason I'm here to begin with, but then to be held back works frustrating, as
you can undoubtedly understand. On the other side of this medal is, however,
that if I were to move forward too fast too soon for the rest of you, that may
work frustrating for you. Note however, I haven't been able to make anything
significant happen quite yet -and it's not for a lack of trying to make things
happen.
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