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:crythias@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 mailto:paul@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

I need to do some more reading on this but since I started the thread I just want to clarify that using the postmaster function or using the System Monitoring piece that the following can be done? Email comes into OTRS from Solarwinds – each email is always from the same email address Email goes through the System Monitoring piece and creates a ticket for a specific customer (based on the node name or some other unique variable from the email) Ticket is opened under customer ID and an email is sent to the customer to confirm we are aware of the incident and are working on it SLA starts to tick away at the clock etc etc. Email comes into OTRS from Solarwinds for the same specific node name and the System Monitoring piece updates the existing ticket (not creating a new one) including possibly closing the ticket if the incident clears itself. So far with that I”m reading this should all be possible and it sounds like the System Monitoring piece is the “glue” to put this together more than the postmaster function. Am I reasonably correct in what I’m assuming above? Thanks, Paul From: Gerald Young Reply-To: "User questions and discussions about OTRS." Date: Friday, February 14, 2014 at 12:37 PM To: "User questions and discussions about OTRS." Subject: Re: [otrs] Email Filtering Question

...

...

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.

...

...

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'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 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:crythias@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 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

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 mailto:mhillman@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:crythias@gmail.commailto:crythias@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 mailto:paul@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