[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