On Thu, 2007-03-22 at 17:45 +0100, Rico Barth wrote: > Hi bb! > > On Thu, 22 Mar 2007, Bodo Bauer wrote: > > > This pretty much sums up what I am working at right now. :) > > > > I didn't distinguish between host and service requests however. If no > > service can be identified, service is set to 'Host' (or whatever you > > configure it to be) and from that point on 'Host' is treated as any > > other service. > > In the past I have had some Nagios implementations where message subject > and message bodies are changed for local needs. so this is why I > distinguish between Host, Service and any others. I would be flexible with > this module to set some specific values, do some specific things and so > on. I put the code on our homepage. may have a look on it. (it's not > beautified :-> ) > > http://www.cape-it.de/download/EMailNagios.tgz
I had quick glance at your module, and while we're trying address the
same issue, we choose very different ways to do so. You're detecting
Nagios mails and create a ticket object in case you fond one. Nothing
wrong with that.
But I think our solution has more flexibility. We implemented a filter
at the beginning of the mail processing pipeline. We also detect Nagios
Mails by the From: header and extract service host, etc using configured
regular expressions from the body just as you do. What we don't have is
handling of encrypted mails...
But going on from there we choose a different route. Instead of creating
a ticket, only a few relevant X-OTRS headers are set and mail is passed
back to the regular mail processing. This allows for all the tinkering
you can do with other incoming mails as well. Queue selection, setting
more headers, etc. And all this without any change in the Nagios Module.
This means that any other features of mail processing are preserved and
future additions will just plug in.
I rather have a set of small, easy to understand and easy to maintain
modules which I can connect with each other than a few specialized ones
which do one thing very well, but can't be reused in for tasks very
easily.
It's the old UNIX tradition I guess... :)
> > I like the idea of what I would call a real-time-ticket-watcher. I see
> > this as an independent functionality however. Why restrict it to special
> > tickets? Wouldn't it be cooler to select a search template and have all
> > ticket matched by that search to be monitored?
>
> What's your opinion about rss? IMHO it's a cool idea to implement an
> real-time-watcher. What about environments where no additional
> software is allowed?
Yeah, having an RSS feed would be very cool. I'm not too concerned about
the add-on software issue. Firefox for example comes with Build-In RSS
support. I'm not sure about legacy Software like IE but I guess they'll
have this as well sooner or later.
More important is that if RSS feeds are important for a particular
installation, this should be a management decision. So if they decide
that they need this service for OTRS, they also should realize that they
need to allow/provide a client app or a Web Service to watch these
notifications.
And what I really like about RSS is that there are plenty of mobile
clients around. Meaning you could get ticket notifications on your cell
just as easy as on you desktop. :)
BB
--
((otrs)) :: OTRS GmbH :: Norsk-Data-Strasse 1 :: D - 61352 Bad Homburg
Fon: +49 (0) 6172 681988 0 :: Fax: +49 (0) 9421 56818 18
http://www.otrs.com/ :: Communication with success!
Geschäftsführer: André Mindermann, Martin Edenhofer
Handelsregister: HRB 9452 Bad Homburg
Steuernummer: 003/240/97521
signature.asc
Description: This is a digitally signed message part
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
