[Kolab-devel] kolabctl instead of kolabsrv

Gunnar Wrobel wrobel at kolabsys.com
Thu Oct 14 09:11:27 CEST 2010


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

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

Hence I suggest doing some stuff in a "fast forward" branch.  
Especially when it comes to new features or larger restructuring it  
makes sense to me to have these in a separate branch first. I think  
this provides a decent middle ground where the one side can move  
forward and the other has more time to adapt.

This is the reason why there is a "Horde4" branch after all. I'm not  
going to enforce a Kolab Server 2.3 based on Horde4 by committing to  
"default" - but of course I'll try to convince you that this should  
happen at some point ;)

Cheers,

Gunnar

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



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the devel mailing list