DX Unified Infrastructure Management

  • Private Community
Back to discussions
Expand all | Collapse all

Impersonating an alarm from the sending probe using raw-alarms

  • 1.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Feb 13, 2009 09:53 PM
    Now and then the question comes up if it is possible to associate an existing alarm generated by a probe or the infrastructure components.  This post shows how this is done by the use of generating a "raw" alarm message onto the bus.   The NAS will use elements like the domain, robotname, source and
    suppression key to tie messages.  The nimbus.alarm sent from the NAS has a different "footprint" than the ones generated by the probes.  The following code contains one function to generate a unique key (the nimid) and the actual 'rawalarm' function. 

    Please use this knowledge with care :-)
    Carstein

    ----8<------8<------8<------8<------8<------8<------8<------8<------8<--

    -- Generates a nimid
    function unique_id()
      
       key = ""
       base="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
       math.random();math.random()
      
      
    key = mid(base,math.random(1,26),1) .. mid(base,math.random(1,26),1) ..
    sprintf("%07d", math.random(1,100000000)) .. "-" ..
    sprintf("%05d",math.random(1,100000))
       return key
    end

    -----------------------------------------------------------------------------------------
    -- rawalarm (source,severity,subsystem,message ]]]])
    -- returns 0 - ok, rest error
    ---
    function rawalarm (source,severity,subsystem,message,suppkey,domain,origin,robot,probe)
       -- expect following parameters
       if type(severity) ~= "number" then return 1 end
       if type(message) ~= "string" then return 1 end
       if type(subsystem) ~= "string" then return 1 end
       if type(source) ~= "string" then return 1 end

       -- set default values for optional parameters.
       if type(domain) ~= "string" then domain="lua-domain" end
       if type(origin) ~= "string" then origin="lua-origin" end
       if type(robot) ~= "string" then robot="lua-robot" end
       if type(probe) ~= "string" then probe="lua-probe" end
       if type(suppkey) ~= "string" then suppkey="lua-suppkey" end
     
       msg = pds.create ()
       nimid = unique_id()
      
       -- Create message header
       pds.putString (msg,"nimid",nimid)
       pds.putInt    (msg,"nimts",timestamp.now() )
       pds.putString (msg,"subject","alarm")
       pds.putInt    (msg,"pri",1)
       pds.putString (msg,"source",source)
       pds.putString (msg,"origin",origin)
       pds.putString (msg,"domain",domain)
       pds.putString (msg,"robot",robot)
       pds.putString (msg,"prid",probe)
       pds.putString (msg,"suppression","y+000000000#" .. suppkey)
       pds.putString (msg,"supp_key",suppkey)
      
       -- Add raw alarm data
       udata = pds.create()
       pds.putInt    (udata,"level",severity)
       pds.putString (udata,"subsys",subsystem)
       pds.putString (udata,"message",message)
      
       pds.putPDS (msg,"udata",udata)
      
       -- Post the message to the hub-spooler
       t,rc = nimbus.request ("spooler","hubpost",msg)

       pds.delete (udata)
       pds.delete (msg)
       return rc,nimid
    end

    -- initialize the random generator
    math.randomseed(os.time())

    rc,id = rawalarm ("193.71.55.210",3,"1.2.3","This is a simple test...")
    printf ("rawalarm: %s, %d",id,rc)

    rc,id = rawalarm ("193.71.55.207",NIML_CRITICAL,"1.2.3","This is an advanced test...","mykey","mydomain","myorigin","myrobot","myprobe")
    printf ("rawalarm: %s, %d",id,rc)




  • 2.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Sep 12, 2009 12:24 AM
    I encountered an issue with the unique_id() function in that it will generates the same unique_id()'s upon execution. The following code demonstrates the behavior:

    -- Generates a nimid
    function unique_id()
     
       key = ""
       base="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
       math.random();math.random()
     
     
    key = mid(base,math.random(1,26),1) .. mid(base,math.random(1,26),1) ..
    sprintf("%07d", math.random(1,100000000)) .. "-" ..
    sprintf("%05d",math.random(1,100000))
       return key
    end

    print(unique_id())
    print(unique_id())
    print(unique_id())

    If you run the script as above, you will get same three unique_id() strings. I found that the following 3 strings were output on multiple NASs:

      FV58500931-47988
      VT17410810-85895
      HA9140294-36446

    If you seed the pseudo-random number generator with timestamp.now(), or some other unique value, you decrease the likelihood of receiving duplicate unique_id()s:

    math.randomseed(timestamp.now())
    -- Generates a nimid
    function unique_id()
     
       key = ""
       base="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
       math.random();math.random()
     
     
    key = mid(base,math.random(1,26),1) .. mid(base,math.random(1,26),1) ..
    sprintf("%07d", math.random(1,100000000)) .. "-" ..
    sprintf("%05d",math.random(1,100000))
       return key
    end

    print(unique_id())
    print(unique_id())
    print(unique_id())

    ~jesse




  • 3.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Sep 12, 2009 10:41 AM
    Jesse,

    It looks like your sample code is missing the following line from the original script:
    math.randomseed(os.time())
    Wouldn't that take care of the issue, similarly to your solution?

    -Keith


  • 4.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 10, 2009 05:16 AM
    Hello,

    I am running a probe on one system that compares configurations to itself and generates alarms when there are differences. I can set source, hostname, etc. when generating the alarms. The only thing that I can't set is the robotname. I am trying to use this script to have the robotname for the alarms be the "errored" system, not the "checking" system. If I just use the code from the script to send a raw alarm, I never see the alarms (or the messages on the bus). If I "post" the PDS, I see the message on the bus, but still no alarms are generated. Am I misinterpreting how this works? Should I be able to use this to generate an alarm?

    Thanks,
    Craig


  • 5.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 10, 2009 07:00 AM
    Craig,

    Have you tried running the original code from Carstein as is without modifications?  What do you see if you try that?

    Could you share your code?  At least the part that sends the raw alarms...  It would be easier for us to see what is going on or even test it.

    -Keith


  • 6.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 10, 2009 11:57 PM
    Hi Keith,

    Yes, I have tried the original code from Carstein. Same result. I am using the raw_alarm function pretty much verbatum. I should have added this earlier. In all cases. I am getting a return code of "11". So, something isn't happy, but I can't find where to map error codes to error messages.

    Thanks,
    Craig


  • 7.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 12, 2009 07:05 PM
    Craig,

    I suspect that you are running the script on a non-hub host; I get the same return code (11) when I do that.  It looks like the spooler only understands the hubpost callback when running on a host along with the hub probe.  I am not sure if you can get this to work with the spooler on a non-hub host; Carstein would have to tell us that.  I suspect the spooler might not like the raw alarm, so you may need to send it to a hub.

    I was able to make this work on a non-hub by changing this line:
    t,rc = nimbus.request ("spooler","hubpost",msg)
    I replaced the address of "spooler" with the address to a spooler running on a hub ("/Domain/hubname/hubrobotname/spooler").

    If you do not want to hard-code the hub spooler address in the script, you can have the probe issue a gethub callback to the robot to find out the domain, hub name, and hub robot name.

    -Keith


  • 8.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 12, 2009 11:04 PM
    Hi Keith,

    Thank you very much. That was exactly the issue. I was already looping through hubs to get robotnames, so it was very straightforward to add the hub name to the "hubpost" request. I am now getting 0 as a return code and alarms are coming through. Nicely done. I appreciate your help.

    Craig


  • 9.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 13, 2009 02:20 PM
    Quote: (kruepke@berbee.com)
    I suspect that you are running the script on a non-hub host; I get the same return code (11) when I do that.  It looks like the spooler only understands the hubpost callback when running on a host along with the hub probe.  I am not sure if you can get this to work with the spooler on a non-hub host; Carstein would have to tell us that.  I suspect the spooler might not like the raw alarm, so you may need to send it to a hub.

    Yes Keith, your are correct in your assumptions.  This will only work through the hubpost command.  This command is used for hub-hub communication and does not wrap any header information like the spooler "post" command does.  So your solution is right on the dot, you'll always need to impersonate through the hub.

    Carstein


  • 10.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 20, 2009 07:11 PM
    Hi,

    Everything is working great. I would like to add User Tags to the raw alarm. I can get the user tags from the robot. I'm having trouble adding it to the PDS, because I don't know what the tags should be. I tried a couple of tags such as "os_user1", User Tag 1", etc. in the pds.putString (msg,"os_user1",os_user1) call, but no luck.

    Would anybody happen to know the correct tags to use here?

    Thanks,
    Craig


  • 11.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 20, 2009 07:33 PM
    Hi Craig,

    That's in the header as user_tag_1 and user_tag_2. A tip for the future is starting Dr.Nimbus and sniffing messages called "alarm" with the Show header checkbox ticked, that will show you not only the contents of the userdata but the message header too.

    Cheers,
    Stian


  • 12.  Impersonating an alarm from the sending probe using raw-alarms

    Posted Nov 23, 2009 10:47 PM
    Thank you. That worked perfectly and the tip to use Dr. Nimbus is exactly what I needed.

    Thanks,
    Craig


  • 13.  Re: Impersonating an alarm from the sending probe using raw-alarms

    Posted Jul 01, 2010 12:45 PM

    *snip*

    key = mid(base,math.random(1,26),1) .. mid(base,math.random(1,26),1) ..

    sprintf("%07d", math.random(1,100000000)) .. "-" ..

    sprintf("%05d",math.random(1,100000))

    return key

    end

    *snip*

     

     

    Any specific reason only a 7 character width is enforced with sprintf for an up to 8 digit number?



  • 14.  Re: Impersonating an alarm from the sending probe using raw-alarms

    Posted Jul 02, 2010 02:04 PM

    The unique message id (nimid, generated by the spooler), is on the format XX99999999-99999.  The function merely copycats this format.  The math.random (info)  function generates a number between 1 and 10000000, so you should not end up with a 8 digit number.



  • 15.  Re: Impersonating an alarm from the sending probe using raw-alarms

    Posted Jul 02, 2010 02:35 PM

    The original posting creates a random number between 1 and 100,000,000.

    Not 1 and 10,000,000 as in your reply.

     

     

    And if the expected nimid format is indeed ([A-Z]{2})([0-9]{8})-([0-9]{5}), why would I not want to end up with an 8 digit number? Considering that \2 is expected to be 8 digits long?



  • 16.  Re: Impersonating an alarm from the sending probe using raw-alarms

    Posted Jul 02, 2010 02:58 PM

    You're right, the function does not mimic the id generated by the spooler, it misses by 1 character.  However, this does not really matter since the only real importance is to avoid duplicate id's (but it increases the spread which is good).  The size should however not exceed 16 characters, since this might yield unwanted behaviour in code where nimid's are mapped to fixed buffers.

     

    The correct code should be as you pointed out:

     

              sprintf("%08d",