Custom actions for inserting multiple mixed v4/v6 IP addresses into a custom field

On Sep 5, 2012, at 11:00 AM, Kevin Falcone:> On Fri, Aug 31, 2012 at 05:49:36PM +0000, Lundberg, Emory wrote:

I cannot seem to get a scrip that will accept multiple comma-seperated addresses from an email (or any correspondevent for that matter), only one address will be accepted.
The scrip I am using is a custom action that looks like this:

I’d suggest looking at what RTIR’s IP address parsing routines are
doing.

You’ll want lib/RT/Action/RTIR_FindIP.pm in the RTIR tarball.

Also, keep in mind that if you create an Multiple Value IP Address
custom field, you still need to add your multiple values one at a time
(like if you were adding multiple values to a normal multi-value CF).

It’s my understanding that RTIR’s module will snarf up all IP addresses and that isn’t exactly what I was wanting to do. I may be going about this in a weird way and I’m absolutely doing something with less resistance.

Users are filling out a form that is emailed into RT for staging new systems, and it would be advantageous for us to collect all the IP addresses on all interfaces at that time instead of one, which historically is the management IP address collected via scrip as X-IP. We have a scrip that gathers up that and several other values in one go, and then inserts that into custom fields. The reason that I’d like to avoid the RTIR approach is that those requests can have IP addresses in them for host ip filters or firewall policies.

I don’t know how “normal multi-value” CFs behave, our other CFs are just one-value. The RT cli is perfectly capable of handling multiple values for my new IP-addresses CF, and I cannot seem to have more than one X-IP-addresses match per reply/comment. It picks up the first and then ignores the rest.

i.e.

X-IP-addresses: 127.0.0.1
X-IP-addresses: 127.0.0.2
X-IP-addresses: 127.0.0.3

would result in only X-IP-addresses: 127.0.0.1 getting picked up.

I’m not at all opposed to being told I’m doing this in a dumb way. If adopting the logic in RTIR’s module into a scrip for RT so that it only picks up addresses I tag with X-$CFNAME is the best way, I would appreciate any tips or suggestions to prime the pump, I am not confidant I’m approaching this right or understanding the recommendation.

thank you!

I’d suggest looking at what RTIR’s IP address parsing routines are
doing.

To revisit this, I was able to get a scrip that would pick up the first
occurrence of an address using a loop, but it would not pick up other
instances of a match.

In light of that, I suspect having RTIR_FindIP.pm pick up those IP
addresses in transactions like RTIR would be less rickety and suck-prone
for someone that isn’t me one day having the unfortunate task of
following in my shoes, but I’m not sure how to include that
RTIR_FindIP.pm’s logic in RT.
Is it better to:

  1. implement RTIR_FindIP.pm’s voodoo as a scrip
  2. hook RTIR_FindIP.pm and its dependancies into my RT as a local plugin
  3. some other non-wrong option that I don’t know?

I’d suggest looking at what RTIR’s IP address parsing routines are doing.

To revisit this, I was able to get a scrip that would pick up the first
occurrence of an address using a loop, but it would not pick up other
instances of a match.

In light of that, I suspect having RTIRFindIP.pm pick up those IP addresses
in transactions like RTIR would be less rickety and suck-prone for someone
that isn’t me one day having the unfortunate task of following in my shoes,
but I’m not sure how to include that RTIRFindIP.pm’s logic in RT.
Is it better to:

implement RTIR_FindIP.pm’s voodoo as a scrip
hook RTIR_FindIP.pm and its dependancies into my RT as a local plugin
some other non-wrong option that I don’t know?

Well, RTIR’s FindIP scrip is very self contained. I don’t mind it
transfering into
RT::Extension::ExtractIPs with more configuration options. It makes sense
considering that code to support IP custom fields migrated from RTIR to RT.
If this extension would be generic and configurable enough. RTIR can just
switch over the extension one day.


We’re hiring! Careers — Best Practical Solutions

Best regards, Ruslan.