Introducing the Nimsoft Script Agent (NSA)

[Anon Anon]

The NSA is a multi-platform (currently Windows, Linux and Solaris) script engine based on the Lua language and built-in services like NimBUS, SNMP, ADO (windows), sqlite and simple networking (TCP/ICMP).  It requires no runtime environment.  It also supports threading (very useful when writing maintenance or other time consuming functions), as well as the Lua based co-routines.  The NSA also gives you the option of creating scrambled (and host-locked) passwords that may be used in login, community strings and connection strings.

The package includes a PDF for documentation, as well as examples on how to utilize the various function classes.  You can create a full-blown NimBUS probe in less than 10 lines of code.  I'm also enclosing the latest version of the CodeWizard (1.60) that will generate code for the NSA.

The installation is done through drag-n-drop over the NimBUS manager.  All files will be installed on the target robot under the SDK/nsa directory.

The memory and disk footprint is about 2MB.

The tip of the day is to use the Crimson Editor for script development.  You may, after installing the NSA and codewizard packages (standard probe installation) and Crimson, configure a user-tool that (see png) that allows for script-editing in the top and executing with output in the bottom pane.  The package also contains syntax high-lighting files for Crimson.

UPDATE:
The NSA 1.04 and the CodeWizard 1.60 is now (Aug. 14) available as official downloads in the archive.  Please open up a new thread in this forum when having questions/problems regarding the NSA, mainly because of the poor forum tools ability to handle large threads.

Anyway, I hope you find this useful.

Happy scripting,
Carstein

[Anon Anon]

The zip files are NimBUS probe packages, and should not be opened by an unzip. 
They are installed by dropping the zip-files into your local archive, then dragged onto a target robot ( typically the one on your desktop ).

[Anon Anon]

Carstein,

It looks like all of the paths used by require() are at or below the current path, so it is probably not very useful with probes that live in their own directories but need access to shared modules.  I would like to build a "library" of Lua functions that I can load into probes as needed.  According to the page at the URL you provided, the path checked by require() can be changed by setting the LUA_PATH global variable.  I tried setting that variable before calling require(), but it did not seem to work.  Any idea why?

For building my "library" of Lua functions, should I just avoid require() and stick with dofile()?  Or is there somewhere I can put the files such that they would be accessible using require()?

Thanks,
Keith

[Anon Anon]

You guys are keeping me busy... :-)

The NSA 1.04 now supports the NIM_ROOT variable by building a lookup path like the dump below.
In addition to this it also supports the LUA_PATH and LUA_CPATH variables by injecting them as the first items in the new and exported environment variables.  This would allow you to use build libraries as part of your solution.

require ("not_found") causes (if the NIM_ROOT is set):

Aug 14 13:17:04:894 nsa: Script error, test.lua:3: module 'not_found' not found:
        no field package.preload
        no file 'C:\Program Files\Nimbus/not_found'
        no file 'C:\Program Files\Nimbus/not_found.lua'
        no file 'C:\Program Files\Nimbus/sdk/nsa/modules/not_found'
        no file 'C:\Program Files\Nimbus/sdk/nsa/modules/not_found.lua'
        no file 'C:\Program Files\Nimbus/sdk/nsa/modules/not_found/not_found'
        no file 'C:\Program Files\Nimbus/sdk/nsa/modules/not_found/not_found.lua'
        no file 'C:\Program Files\Nimbus/sdk/nsa/scripts/not_found'
        no file 'C:\Program Files\Nimbus/sdk/nsa/scripts/not_found.lua'
        no file 'C:\Program Files\Nimbus/sdk/nsa/scripts/not_found/not_found'
        no file 'C:\Program Files\Nimbus/sdk/nsa/scripts/not_found/not_found.lua'
        no file 'not_found'
        no file 'scripts/not_found'
        no file 'scripts/not_found.lua'
        no file 'modules/not_found'
        no file 'modules/not_found/not_found'
        no file 'modules/not_found/not_found.lua'
        no file 'C:\Program Files\Nimbus/sdk/nsa/not_found'
        no file 'C:\Program Files\Nimbus/sdk/nsa/not_found.dll'
        no file 'C:\Program Files\Nimbus/sdk/nsa/modules/not_found.dll'
        no file 'C:\Program Files\Nimbus/sdk/nsa/modules/not_found/not_found.dll'
        no file 'not_found'
        no file 'not_found.dll'
        no file 'modules/not_found.dll'
        no file 'modules/not_found/not_found.dll'

A tip: require("my.library.db_functions") would honor your structure and cause the NSA to look in
     my/library/db_functions

Carstein

[Anon Anon]

Hi Carstein,

Thanks for this. I'll give it a go.

Regards
Dean

[Anon Anon]

Thanks, Carstein!  That will be a great feature.  I just finished up a rough first version of my first NSA probe, but it depends on a function I added to the probe table.  (I plan to post that function to the forum.)  I need to distribute that dependency before I can use the probe, so I was trying to decide where to put everything.  This will definitely make things simpler.  You are making me look forward to NSA 1.04!

It kind of looks like it would make the most sense to put my library of functions in one of these directories:

• sdk/nsa/modules
• sdk/nsa/scripts

Do you recommend either one over the other?  I am not sure if there is some philosophical difference between "modules" and "scripts" in the Lua world.

Thanks,
Keith

[Anon Anon]

Ideally the modules directory is meant for binary distributions containing a .dll (or .so) files.
The luacom package installs itself in module, and so does the ndg (Nimsoft Dashboard Generator) package.

I'd go for installing the library in the substructure of sdk/nsa.

NSA 1.04, CodeWizard 1.60, luacom (in unsupported) and ndg should all hit the archive shortly....

Enjoy,
Carstein

[Anon Anon]

I have completed the Lua code for a probe to save some basic data to QoS.  I have tested it in the Crimson environment.  It uses the NSA.exe for testing.  My question is do we need to compile the lua code into an exe for use in a new package?  This thread might be a good spot to show a sample probe made using nsa for us n00bs.  Thanks for the good info so far!

[Anon Anon]

You can do this in two ways, either make the package containing your script dependent on the NSA package (this makes the script platform independant), or bundle the appropriate NSA binary into your script package.  Your choice.  Either way, the script relies only on the NSA.

You can post your script to the "customer upload archive" forum.

Btw. NSA 1.10 is out in the beta archive.  It contains some new platforms, and quite a few important fixes.

Carstein