m.gabriel at das-netzwerkteam.de
Mon Mar 31 21:40:36 CEST 2008
Quoting Bernhard Reiter <bernhard at intevation.de>:
> On Wednesday 26 March 2008 08:26, Gunnar Wrobel wrote:
>> > Example munin output: http://munin.ping.uio.no/
>> > Just to let you know, that this application exists and seems usefull to
>> > kolab admins.
>> munin is definitely a very useful tool and I think using it with the
>> Kolab server makes a lot of sense.
> I've only briefly checked the webpage and munin looks overwhelming.
>> Adding it to the set of features provided by the core Kolab server is
>> a different thing though. We'll get the same problem as with grey
>> listing: The Kolab server already has a rather large set of features
>> that is hard to support in its entirety. Each extra application would
>> add a good deal of additional features that would also need testing
>> and support. Given the current man power behind the project we should
>> definitely be careful about that.
> I agree with this notion.
> Also my strategy would be to keep the tools orthogonal to what Kolab Server
> comes with or find a very good one. I do not know enough knowledge
> to compare munin to all the other solutions to similiar problems I have seen.
>> That being said I believe we need a good extension/plugin possibility
>> that allows to provide such additional features/applications.
> I would maintain that Kolab Server is already pretty "pluggable" due to its
> Unix philosophy. Of course I am still looking forward to your proposal. :)
i have been using munin at an institute i worked for for quite a
while. to monitor a mailsystem it has quite an overhead of
the question is: what information do kolab administrators really
need??? i personally would rather prefer a slightly thinner solution
than munin (or do postmasters really need their system's entropy to
make a brighter day???).
a less scribbly tool (compared to munin) is "spong". on its initial
page it basically shows you green, yellow or red lights that tell you
if your servers' services are running or not, if there is enough disk
space available, etc. unfortunately, spong has not been maintained
very actively, recently... spong is written in perl and it's easy to
add features... (if one knows how to speak perl).
to watch over postfix, there is also a fine solution called
"mailgraph" (it's a debian package). mailgraph adds perfectly missing
information to spong (received mails, bounces, spam, etc.)
to watch over IMAP/POP3, there is another fine add-on solution.
unfortunately, it is only available only for "courier" users, its name
is "couriergraph". maybe this tool is easily adaptable to cyrus (both
simply analyze the log files in /var/log/mail.*, i think).
however, providing tools like these hardcoded into kolab would imply
providing a webserver with kolab, as well (horde also does imply
the more packages you stuff into kolab's openpkg the more conflicts
arise with already installed services on an already running systems.
if you want to run other stuff on a kolab server that comes with the
system's distribution, a package's dependencies might request the
installation of a webserver (from the dist) and this will conflict
with a multiply used port 80/443. loads of other conflice scenarios
are imaginable here...
(becoming more and more off-thread here...) why not rather and this
spend more effort on regularly providing packages that neatly
integrate into the various package systems available in the unix
world. it also would be helpful to store package information for
various package systems within your CVS repository (e.g. the "debian"
dir that contains all information to build the corresponding kolab
packages from source). thus, checking out kolab source would allow an
immediate package build from kolab source...
mike gabriel, hamburger chaussee 240, 24113 kiel
fon: +49 431 64 74 196
voip/voicemail: +49 431 643 643 6
fax: +49 431 64 74 276
mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
More information about the devel