> It only lists the fields that are used, but not how to trap the inbound 
> messages in order to redirect them
Marty, What do you want to accomplish?
The configuration options for what to trap are in Admin, SysConfig, 
SystemMonitoring, Core::PostMaster

There are two blocks: the default runs before PostMasterFilter, the second runs 
after PostMasterfilter (there needs only one)

Most of the fields are self-explanatory or referenced in the PDF.

I am working my way through them to try to figure out the right settings.  It 
does not seem to be working properly at the moment, but I need to trace email 
communications to make sure they are routing through the right internal relays. 
 I think the problem is currently all external to OTRS.  I did find 
Core::PostMaster and am working through those settings.

> Another issue I am having is that we currently have two Nagios based 
> monitoring systems as we move things from an old version of Nagios to the 
> much newer Opsview Nagios-based solution.  I am hoping that I can build for 
> both, but the document only covers one.

What would, in your specific case, be the practical difference between SystemA 
and SystemB  as it relates to OTRS?
Do you need to recognize them separately?
Will they have different From addresses?
Will the regular expressions to parse notifications SystemB be parsed 
differently from SystemA?
Is there a wording change between the two systems that needs to be addressed?
Are you needing to address Nagios Acknowledgements?
(I don't know enough questions to ask that will account for your concern)

I gathered the forces and we have decided that we only need to monitor Opsview 
as this is new functionality and we are moving from Nagios to Opsview over 
time.  As Nagios gets absorbed, it will be a more complete solution, so there 
will no longer be the need to trap from two sources.

The email addresses from the two monitoring systems are different as are the 
credentials to log in to each.  Rather than doing an in place upgrade, we are 
working through a new install and manual recreation/addition of new monitors 
within Opsview.  It helps us iron out the shortcomings in how the 10 year old 
Nagios system was implemented.

For reference, the bodies from both systems are identical.  We are now using 
the proper host names of the machines rather than the plain English 
translations of what the servers do.  This helps us to better pinpoint issues 
and repair them, but that is more a discussion for a Nagios board.

I should have the information I need at this point to get it working now that I 
know where in OTRS the settings are.  I just need to figure out my relay issues 
and will report back when I am complete.  I might put together training 
material on how to configure with base systems once I get it all functioning.

I'd like to help you, but I don't know what you're struggling with.


On Fri, Feb 14, 2014 at 11:42 AM, Marty Hillman 
<mhill...@equuscs.com<mailto:mhill...@equuscs.com>> wrote:
It addresses the basic question about whether it can be done, but not how to 
set it up in OTRS.  I am muddling my way through it now.  It only lists the 
fields that are used, but not how to trap the inbound messages in order to 
redirect them.  Has anyone implemented this that can tell me which System Admin 
components in which to make the adjustments?  I don't see those procedures in 
the document.

Another issue I am having is that we currently have two Nagios based monitoring 
systems as we move things from an old version of Nagios to the much newer 
Opsview Nagios-based solution.  I am hoping that I can build for both, but the 
document only covers one.

From: Gerald Young [mailto:cryth...@gmail.com<mailto:cryth...@gmail.com>]
Sent: Friday, February 14, 2014 4:12 AM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] Email Filtering Question

The PDF attached to the System Monitoring Package (within OTRS Package Manager) 
explains how an incident creates a ticket, matches a host and service 
combination, and closes based upon regular expression processing. It's a quick 
read, but should address your basic questions.

A Notification (Event) might be useful in alerting the user.

On Thu, Feb 6, 2014 at 8:23 PM, Paul Stewart 
<p...@paulstewart.org<mailto:p...@paulstewart.org>> wrote:
Hi there...

We are testing OTRS for an upcoming project.  We are an ISP and utilize 
Solarwinds as our network monitoring platform.

I have read that there are good integration options between OTRS and Nagios for 
example.  Has anyone worked with API level integration between the two 
platforms before?  Just curious on experiences in that area.

Also, instead of using API calls, I'm interested in knowing more about mangling 
email tickets as they arrive.  For example, if we had Solarwinds sent us email 
alerts for every time there was an up or down condition I would want to create 
a ticket under the actual email address of the customer effected (using a 
Managed customer as an example) therefore sending them an automated email 
acknowledgement that we know of a problem with their service.  Further to that 
is the whole discussion around tracking up and down events in the same ticket 
and possibly closing the ticket automatically when there is an up event (after 
a down event).

Any input much appreciated...

Paul



---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs


---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Reply via email to