DX Unified Infrastructure Management

  • Private Community

  • 1.  Performing auto-operator action based on robot operating system type

    Posted Jan 14, 2009 09:45 PM
    Hi,

    Enclosing a little snippet that will help the auto-operator to perform an action based on the operating system of the sending robot.  Note that you should add probe information (like cdm, ntservices, etc) to the profile filters to only act on alarms that come from the robot.  This is needed to avoid generating alarms for remote systems (like from net_connect, etc.).

    Enjoy,
    Carstein


    --
    -- Mapping alarms to the operating system type of a robot.
    --
    a = alarm.get ()
    s = file.stat ("robotcache.db")
    osname=""

    database.open("robotcache.db")
    if s == nil then
       database.query("CREATE TABLE ROBOT_OSTYPE (name text, hub text, os_minor text, os_major text)")
    end

    rs = database.query("SELECT os_major FROM ROBOT_OSTYPE WHERE name='"..a.robot.."' and hub='"..a.hub.."'")
    if #rs == 0 then
       addr = "/"..a.domain.."/"..a.hub.."/"..a.robot.."/controller"
       info = nimbus.request(addr,"get_info")
       if info ~= nil then
          database.query("INSERT INTO ROBOT_OSTYPE VALUES ('"..a.robot.."','"..a.hub.."','"..info.os_minor.."','"..info.os_major.."')");
          osname = info.os_major
       else
          printf("error, no info from controller at: %s",addr)
       end
    else
       osname = rs.os_major
    end

    database.close()

    if osname == "Windows" then
       printf("Sending mail to Windooze groupies...")
    elseif osname == "Linux" then
       printf("Sending mail to UNIX groupies...")
    else
       printf("Unable to resolve osname for robot '%s', osname:%s",a.robot,osname)
    end





  • 2.  Performing auto-operator action based on robot operating system type
    Best Answer

    Posted Jan 24, 2009 04:46 AM
    Carstein,
    Just curious, why create a local sqlite table for this,  it would seem that if a robot name was reused and already existed in this database you would return invalid information,
    Why not use the grp_server table and allow the group_server probe to maintain the information for you?
    additionally in my environment the host name matches  the robot name, i have net connect setup on each hub and profiles for each robot connected to that hub have been defined, so using the origin hub and robot name = to hostname you could easily make this work for net_connet as well.... with modifications of course..  it would not be 100% but it would be close enough i think.

    something like the script below:
    ----------------
    -- Mapping alarms to the operating system type of a robot.
    --
    a = alarm.get ()
    osname=""

    database.open("Provider=sqloledb;Data Source=uscdcnim60;Initial Catalog=NimbusSLM;User Id=testuser;Password=testpassword;")

    rs = database.query("SELECT os_major FROM grp_server WHERE robotname='"..a.robot.."' and hubname='"..a.hub.."'")
    if #rs == 0 then
       printf("error, no info from controller at: %s, %s", a.hub, a.robot)
    else
       osname = rs.os_major
    end

    database.close()

    if osname == "Windows" then
       printf("Sending mail to Windooze groupies...")
    elseif osname == "Linux" then
       printf("Sending mail to UNIX groupies...")
    else
       printf("Unable to resolve osname for robot '%s', osname:%s",a.robot,osname)
    end

    =====================

    am i missing something?

    Mike


    Quote:     (carstein.seeberg@nimsoft.com)
    Hi,

    Enclosing a little snippet that will help the auto-operator to perform an action based on the operating system of the sending robot.  Note that you should add probe information (like cdm, ntservices, etc) to the profile filters to only act on alarms that come from the robot.  This is needed to avoid generating alarms for remote systems (like from net_connect, etc.).

    Enjoy,
    Carstein






  • 3.  Performing auto-operator action based on robot operating system type

    Posted Jan 26, 2009 09:53 PM
    Mike,

    No, you are absolutely right.  For customers running a complete NimBUS server this would be the preferred solution.  I would, however, try not to depend the insert-rate of the NAS on the connectivity to the database, so some kind of a local cache should be preferred.  My approach is based on the idea of NAS being standalone not seldom a few hops away from the NiS.

    Carstein


  • 4.  Performing auto-operator action based on robot operating system type

    Posted Jan 27, 2009 05:43 AM
    Carstein,
    Interesting, did not really think of it that way.
    Maybe a hybrid of the concept,  pull from the SLM database and populate/validate a sqlite table as a local cache...

    I may see if i can get some time to build a prototype script for something like that.

    Is there any way to schedule an operator to execute every so often (say once and hour) consistently.? this would help in updating a local cache without having to check the cache state on every event.

    Thanks
    Mike


  • 5.  Performing auto-operator action based on robot operating system type

    Posted Feb 12, 2009 02:40 AM
    Mike,

    The auto-operator has a scheduler, which has the ability to run NAS Lua scripts.  I think that would do the trick for what you would like to accomplish.

    Regards,
    Keith