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 :-> )
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