LUA - how to make function call in action.command and send output to a file?

[Anon Anon]

Hi,

This is a continuous thread from my first post about LUA.

<1> My lib

library/gait-arguments

function myplink ()
   local plink = "D:\\WIT\\Commands\\Restart\\plink.exe"
   return plink
end

------------------------------------

<2> My script

require ("library/gait-arguments")

buf = action.command ("myplink () -v -i D:\\WIT\\jobs\\wit\\.ssh2\\nanimbus5-rsa-key-1024-20080513-x86.ppk -batch aiadm@ds6 ls -l /tmp")

for i=1,#buf do
   printf ("%02d -> %s",i,buf >> "D:\\WIT\\Commands\\Restart\\logs\\test.log")
end

------------------------------------

<3> My objective:
In (2), I want to make a function call myplink() in the action.command then capture the output in a file.  I'm fairly new to LUA and have been checking out some of the examples from Help and the Wiki online for user-lua site, but I haven't got (2) to work.

Your suggestion is appreciated.

-Hoang

[Anon Anon]

I forgot to add one other objective: Scan the script log for a certain keyword e.g. "successful" or "failed" and send out an email indicating if the script ran OK or NOT.

Thanks,
Hoang

[Anon Anon]

Hoang,

Could you just redirect the output to a file directly in the command?  I am picturing something like this:

buf = action.command ("myplink () -v -i
D:\\WIT\\jobs\\wit\\.ssh2\\nanimbus5-rsa-key-1024-20080513-x86.ppk
-batch aiadm@ds6 ls -l /tmp >> D:\\WIT\\Commands\\Restart\\logs\\test.log")

When it comes to scanning the log, maybe this would not be an ideal solution.  Reading the output of the command into the script (instead of direct to a file) probably makes it easier to check it for success or failure.

If you want to get the command output into the script, I would think this would work well with the file.create() function, which is part of teh NAS Lua extensions.  It seems that it could work this way:

for i=1,#buf do
   contents = contents..i.." -> "..buf
end
file.create("D:\\WIT\\Commands\\Restart\\logs\\test.log", contents)

The one problem is that this would not format the line numbers to have two digits on each line, but there is probably a way to make that work as well.

And just to confirm, have you verified that you successfully get the output you are expecting into the buf variable?  That is probably not an issue, but I thought I would make sure that the problem could not be coming in at that point.

Regards,
Keith

[Anon Anon]

Hi,

buf = action.command ("myplink () -v -i
D:\\WIT\\jobs\\wit\\.ssh2\\nanimbus5-rsa-key-1024-20080513-x86.ppk
-batch aiadm@ds6 ls -l /tmp >> D:\\WIT\\Commands\\Restart\\logs\\test.log")

I am having two issues with LUA

1) passing the function myplink ()  does not work
2) redirecting the output >> also does not work

One (1) and (2) work, I can advance a little further.  But for now, I'm kinda stuck at this step.

Thanks,
Hoang

[Anon Anon]

Hoang,

The myplink() function is never going to be executed in the action.command statement.  This is due to leaving the LUA interpretor.  What I think you want to do is to concatenate the string returned from myplink, with a variable part of the command.

function myplink()
   local plink = "D:\\WIT\\Commands\\Restart\\plink.exe"
   return plink
end

buf = action.command ( myplink() .. " -v -i D:\\WIT\\jobs\\wit\\.ssh2\\nanimbus5-rsa-key-1024-20080513-x86.ppk -batch aiadm@ds6 ls -l /tmp")

Then you can build up your command string with variable parts.

Remember from the earler post that you will need to redirect standard error to standard out by issuing

2>&1

I don't quite understand that reasons for you to wanting to redirect output to a file, since you have it (the output) as part of the returned data from action.command.  It would be simple to iterate through the output and test for "successful" or "failed" by using some of the powerful string functions.

Here's an example that wraps your plink command into a function:

function myplink(server,command)
   return action.command("D:\\WIT\\Commands\\Restart\\plink.exe -ssh -i D:\\WIT\\jobs\\wit\\.ssh2\\nanimbus5-rsa-key-1024-20080513-x86.ppk -batch "..server.." "..command.." 2>&1")
end

and call it with:

buf = myplink ("aiadm@ds6","ls -l /tmp")

Hope this helps,
Carstein

Carstein

[Anon Anon]

Hi Carlstein,

>>I don't quite understand that reasons for you to wanting to redirect output to a file, since you have it (the output) as part of the returned data from action.command.  It would be simple to iterate through the output and test for "successful" or "failed" by using some of the powerful string functions.

The output file captures the output of the script and can be useful for troubleshooting purpose.  I'm using the cmd_daemon probe to run commands on the remote hosts.  The pu that calls the cmd_daemon actually print out the status.  When cmd_daemon did not run successully (at 4am when I'm still asleep), I could look at the log and determine the next course of action.

I am able to use your example and make it work with plink.  However, I need to apply the same logic for the pu

MyFunction:
function mypu (runprobe,command)
   return action.command("d:\\progra~1\\NimBUS\\bin\\pu.exe -u usr1 -p ****** "..runprobe.." "..command.." 2>&1")
end

MyScript
require ("library/gait-arguments")
buf = mypu("/Sybase/Dublin-5/ollie/cmd_daemon run_system","/usr/bin/su - aiadm -c touch /tmp/helloworld.txt")

for i=1,#buf do
   printf ("%02d -> %s",i,buf)
end

Result:

----------- Executing script at 10/30/2008 4:56:49 PM ----------

  01 -> ======================================================
  02 -> Address: /Sybase/Dublin-5/ollie/cmd_daemon Request: run_system
  03 -> ======================================================
  04 -> exit_value      PDS_I             2 0
  05 -> signal_num      PDS_I             2 0
  06 -> dumped_core     PDS_I             2 0

Problems:
(1) /tmp/helloworld.txt did not get created.

(2) If the script failed to run or did not execute, I want to send out an email

(3) I would like to redirect/capture the above result/output in to a file e.g. D:\WIT\Commands\Restart\logs\MyOutput.log, but still not sure how to do this either.

If I can solve (1) (2) nd (3) then I think I'm ready to convert all of my existing batch files into LUA scripts.

Thanks,
Hoang

[Anon Anon]

Hoang,

I would use the nimbus.request method to achieve this instead of going external using the action.command method.

Then you can test directly on the exit_value etc. returned by the request.  I don't know the cmd_daemon probe, but I would assume it takes a command-line as a parameter.  Could you please bring up the PU (ctrl-p) from the NimBUS Manager and provide the parameter names.

Assuming the parameter name to 'run_system' is 'command', then the request would look like this:

args = pds.create()
pds.putString(args,"command","/usr/bin/su - aiadm -c touch /tmp/helloworld.txt")
ret = nimbus.request ("/Sybase/Dublin-5/ollie/cmd_daemon","run_system",args)

if ret.exit_value ~= 0 then
   printf("ERROR: %d",ref.exit_value)
else
   printf("OK")
end


Regards,
Carstein

[Anon Anon]

Hi Carlstein,

>>Could you please bring up the PU (ctrl-p) from the NimBUS Manager and provide the parameter names.

cmd_daemon probe command set

(1) run_command
Parameters:
arg1
arg2_str
arg3_num

(2) run_system
Parameters:
command
destname

command (example):
touch /tmp/hello123.txt

** I could run the touch command and it would create the file with the 0 status (success)

** I tried running the example script you provided but got

----------- Executing script at 10/31/2008 5:01:35 PM ----------

Error in line 8: attempt to index global 'ref' (a nil value)

** I'll attach a screenshot of the PU for cmd_daemon

Thanks,
-Hoang

[Anon Anon]

Hoang,

As far as that error from Carstein's sample code is concerned, it looks like there was a typo in hist post.  Here is the line that he posted:

printf("ERROR: %d",ref.exit_value)

But I believe he meant ret rather than ref, like this:

printf("ERROR: %d",ret.exit_value)

Give that a try to see if it has the desired result.

Regards,
Keith

[Anon Anon]

Keith,

You are correct.  It was a typo and I made the change.  I tried running   the Script without the /usr/bin/su - aiadm -c and I was able to create the helloworld.txt file as 'root'.  But when including /usr/bin/su - aiadm -c (see below example), I got ERROR: 2. 

In my hub, I could successfully run this window command line (also the same line I used in my batch file)
"d:\Program Files\NimBUS\bin\pu.exe" -u usr1 -p ****** /Sybase/Dublin-5/ollie/cmd_daemon run_system "/usr/bin/su - aiadm -c touch /tmp/test/helloword.txt"

Fyi, I need to be able to su as a certain user to run remote command because that user has specific settings to bring up the server successfully.  Running as root is not good and will cause problem; hence; I am passing in this argument "/usr/bin/su - aiadm -c MyCommand"

Any comment is appreciated.  TIA.

Script

require ("library/gait-arguments")

args = pds.create()
pds.putString(args,"command","/usr/bin/su - aiadm -c touch /tmp/test/helloworld.txt")
ret = nimbus.request ("/Sybase/Dublin-5/ollie/cmd_daemon", "run_system",args)

if ret.exit_value ~= 0 then
   printf("ERROR: %d",ret.exit_value)
else
   printf("OK")
end


-Hoang

[Anon Anon]

Hoang,

Sorry about that typo,

Error 2 - means that the NAS was unable to set up communication with the requested probe.
Could be connection problems, or timeout issues.

I noticed that you are running the pu command as nimbus user 'usr1', while the NAS will issue the command as a probe with administrational privileges.  Does the probe take this into consideration ?
Is there a logfile from the cmd_daemon that could shed some light ?

But I would expect the su command to have its -c command argument enclosed in single/double quotes:
/usr/bin/su - aiadm -c 'touch /tmp/test/helloworld.txt' like below:

pds.putString(args,"command","/usr/bin/su - aiadm -c 'touch /tmp/test/helloworld.txt'")

Carstein

[Anon Anon]

Hi Carstein,

Your suggestion of the single quote works like a charm.  I ran the below and got an OK and checked the remote robot and saw the helloworld.txt file.

pds.putString(args,"command","/usr/bin/su - aiadm -c 'touch /tmp/test/helloworld.txt'")

I guess there are two obstacles left.  I want to send an email on the "Error 2" condition and would like to capture the detail status of this "Error 2" in an output file. 

The real reason of capturing the details is that I have a number of applications that run on several remote web and application servers.  All of these applications depend on one critical database server.  Whenever this database server is bounced due to maintenance, I also need to bounce all of the dependencies e.g. app/web servers; and I'm planning to use one LUA script to bounce all of the app/web servers.  As a result, it's important for me to have an output file to scan through it and to make sure all of those web/app servers come up normally e.g. I'm looking for lines like these

  01 -> ======================================================
  02 -> Address: /Sybase/Dublin-5/ollie/cmd_daemon Request: run_system
  03 -> ======================================================
  04 -> exit_value      PDS_I             2 0
  05 -> signal_num      PDS_I             2 0
  06 -> dumped_core     PDS_I             2 0


Let me know if you have suggestions to implement these two features (email and redirect to output file) that I need in LUA.

Thank you for your pointers,
Hoang

[Anon Anon]

Hoang,

I believe at this point that your request is being sent like this:

ret = nimbus.request ("/Sybase/Dublin-5/ollie/cmd_daemon", "run_system",args)

The values returned from the callback in a PDS are now stored in the ret variable (which is a table).  Therefore, you should able to access the three variables listed in your post as follows:

ret.exit_value
ret.signal_num
ret.dumped_core

I suspect those values can tell you if your command worked but only if the script actually reached the cmd_daemon probe.  If it did not reach the probe, I believe (and Carstein should be able to confirm) that ret will end up with a value of nil.

So after doing the request, you would probably check for nil and then check the values returned by the cmd_daemon probe.  Then you could log success or failure to a log file (probably with the file.write() function, which is mentioned in the NAS Technical Brief).  In the log, you can have the script include any information you want, so this should be far more flexible than the PU command.

Personally, I think I would generate a new alarm if the script fails to bounce one of the app/web servers, rather than write it to a log file.  You could also do both, but it seems likely that an alarm message would be a lot more obvious.  You can do that with the nimbus.alarm() function.

So assuming you expect all of the returned values from the request to be zero, here is one way to do it:

if ret == nil then
   nimbus.alarm(5, "Failed to reach cmd_daemon on /Sybase/Dublin-5/ollie for restart")
elseif ret.exit_value ~= 0 or ret.signal_num ~= 0 or ret.dumped_core ~= 0 then
   nimbus.alarm(5, "Restart on /Sybase/Dublin-5/ollie returned error: exit_value = "
   ..ret.exit_value..", signal_num = "..ret.signal_num..", dumped_core = "
   ..ret.dumped_core)
end

(If you try that, watch out for typos!  I do not trust myself.)  Many possibilities exist.  Let us know how it goes...

Regards,
Keith

[Anon Anon]

Keith,

Nice work.  Using your code, I got everything to work now including using the nas to send out the email.  I will do a couple more tests to test the 'failed' conditions.  Will update.

Thanks again,
Hoang

Quote: ([e-mail])
Hoang,

I believe at this point that your request is being sent like this:

ret = nimbus.request ("/Sybase/Dublin-5/ollie/cmd_daemon", "run_system",args)

The values returned from the callback in a PDS are now stored in the ret variable (which is a table).  Therefore, you should able to access the three variables listed in your post as follows:

ret.exit_value
ret.signal_num
ret.dumped_core

I suspect those values can tell you if your command worked but only if the script actually reached the cmd_daemon probe.  If it did not reach the probe, I believe (and Carstein should be able to confirm) that ret will end up with a value of nil.

So after doing the request, you would probably check for nil and then check the values returned by the cmd_daemon probe.  Then you could log success or failure to a log file (probably with the file.write() function, which is mentioned in the NAS Technical Brief).  In the log, you can have the script include any information you want, so this should be far more flexible than the PU command.

Personally, I think I would generate a new alarm if the script fails to bounce one of the app/web servers, rather than write it to a log file.  You could also do both, but it seems likely that an alarm message would be a lot more obvious.  You can do that with the nimbus.alarm() function.

So assuming you expect all of the returned values from the request to be zero, here is one way to do it:

if ret == nil then
   nimbus.alarm(5, "Failed to reach cmd_daemon on /Sybase/Dublin-5/ollie for restart")
elseif ret.exit_value ~= 0 or ret.signal_num ~= 0 or ret.dumped_core ~= 0 then
   nimbus.alarm(5, "Restart on /Sybase/Dublin-5/ollie returned error: exit_value = "
   ..ret.exit_value..", signal_num = "..ret.signal_num..", dumped_core = "
   ..ret.dumped_core)
end

(If you try that, watch out for typos!  I do not trust myself.)  Many possibilities exist.  Let us know how it goes...

Regards,
Keith

[Anon Anon]

Hi,

For this line

nimbus.alarm(5, "Failed to reach cmd_daemon on /Sybase/Dublin-5/ollie for restart")

Is there a way to pass in the NimBUS variables to retrieve the /domain/hub/hostname?  It's more effective with variables than hardcoding every /domain/hub/hostname in the scripts.

Thanks,
Hoang

[Anon Anon]

Hoang,

Unfortunately, I do not think you can pass variables into Lua scripts at this time.  I have run into the same issue before, and that is what I was told.

The way I got around this was I created a "library" script that defined a function that did all of the work.  Then I created multiple scripts that each required the library file called the function with a different argument.  In your library file, you would have something like this:

function do_restart (robot_addr)
   args = pds.create()
   pds.putString(args, "command", "/usr/bin/su - aiadm -c touch /tmp/test/helloworld.txt")
   ret = nimbus.request (robot_addr.."cmd_daemon", "run_system", args)
   if ret == nil then
      nimbus.alarm(5, "Failed to reach cmd_daemon on "..robot_addr.." for restart")
   elseif ret.exit_value ~= 0 or ret.signal_num ~= 0 or ret.dumped_core ~= 0 then
      nimbus.alarm(5, "Restart on "..robot_addr.." returned error: exit_value = "
      ..ret.exit_value..", signal_num = "..ret.signal_num..", dumped_core = "
      ..ret.dumped_core)
   end
end

If you put that function in a file named do_restart, then one of the main scripts can be as simple as this:

require("do_restart")
do_restart("/Sybase/Dublin-5/ollie")

Of course, you could also have the function accept arguments for the command to run on the server or anything else you can imagine...

Regards,
Keith

[Anon Anon]

Keith,

Your suggestion works well.  I am starting my migration now. It will take a few hours/days to port them all 8)

I'll try to fiddle with the ntservices probe that I am also using to restart the nt services.

Question: is there a limitation to the size of a LUA script within the nas?  The size of my function script is getting larger and larger (as of now it's 47,567 (bytes?)), and it's taking about 1-2 minutes to open it.

Thanks,
Hoang

[Anon Anon]

Hoang,

There is no physical limitation.  The problem you'll face
is that the syntax high-lighting algorithms is not efficient when the
script becomes large.  One way to avoid this is by creating
libraries/modules that is referenced through the require statement.  As
a consequence, it also becomes more readable :-)

Carstein

[Anon Anon]

Carstein's suggestion for breaking out functionality into multiple files to treat them as libraries is a very good one.  If you need to keep a bunch of code together and find that the editor within the NAS GUI is not performing well, you could always edit the scripts directly with a text editor.

I am partial to Vim (including GVim on Windows), which happens to support syntax highlighting for Lua.  (It might not figure out the file contains Lua code, but you can tell it that if necessary to get the syntax highlighting to work.)  The Windows installer offers the option of adding an Edit with Vim option to context menus in Windows Explorer, which I find quite handy for editing any text file.

Keith

[Anon Anon]

I like vi(m) as well, but I must admit that the Crimson Editor with its possibilities of running the script and capturing the output in an integrated window is better.  Works perfectly with Perl and Lua (NSA).

Try it out, I have modifed the lua syntax highlighting rules to include some of the specific NAS ( and the soon to come NSA - NimBUS Script Agent) statements.  Place these files into the spec directory of crimson.

The crimson editor:  http://www.crimsoneditor.com/

[Anon Anon]

Hi,

I want to use the same logic to call the ntservices probe to stop and start the following ntservices: MSFTPSVC, W3SVC, HTTPFilter and IISADMIN. I have been trying out a few tricks but could not pull the rabbit out of the hat.  Perhaps you have a better trick?

This is my none-working function

function SYBERJOBS_maui_IIS (robot_addr)
local svr_name = "SYBERJOBS-maui-IIS"
args = pds.create()
pds.putString(args,"command","stop_service MSFTPSVC")
pds.putString(args,"command","stop_service W3SVC")
pds.putString(args,"command","stop_service HTTPFilter")
pds.putString(args,"command","stop_service IISADMIN")
pds.putString(args,"command","start_service MSFTPSVC")
pds.putString(args,"command","start_service W3SVC")
pds.putString(args,"command","start_service HTTPFilter")
pds.putString(args,"command","start_service IISADMIN")
ret = nimbus.request (robot_addr.."/ntservices", "stop_service", args)
ret = nimbus.request (robot_addr.."/ntservices", "start_service", args)
if ret == nil then
   nimbus.alarm(4,"AutoRestart: ntservices probe is NOT running on "..robot_addr)
   printf("Failed to reach the ntservices probe.  Make sure ntservices is running on "..robot_addr)
elseif ret.exit_value ~= 0 or ret.signal_num ~= 0 or ret.dumped_core ~= 0 then
   nimbus.alarm(4, "AutoRestart "..svr_name.." FAILED with exit_value = "..ret.exit_value..", signal_num = "..ret.signal_num..", dumped_core = "..ret.dumped_core)
   printf("Failed to Restart "..svr_name.." with exit_value = %d, signal_num = %d, and dumped_core = %d",ret.exit_value,ret.signal_num,ret.dumped_core)
   printf("Take a look into this Restart ASAP")
else
   nimbus.alarm (1,"AutoRestart "..svr_name.." OK with exit_value = "..ret.exit_value..", signal_num = "..ret.signal_num..", dumped_core = "..ret.dumped_core)
   printf("Successful Restart of "..svr_name.." with exit_value = %d, signal_num = %d, and dumped_core = %d",ret.exit_value,ret.signal_num,ret.dumped_core)
   printf("0 is normal")
end
end


Thanks,
Hoang

[Anon Anon]

The ntservices command-interface 'stop_service' with the service as the parameter needs to be called per service you want to stop ( or start for that matter).  So the simplest (and nicest) way is to implement a function that allows you to pass the start_service and stop_service command to the probe.

Carstein

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

function nt_services (address, mode ,service)
   local args = pds.create ()
   local out,rc

   pds.putString(args,"name",service)
   out,rc = nimbus.request (address.."/ntservices",mode,args)
   pds.delete(args)
   return rc
end

--rc = nt_services ("xpcase","stop_service","Spooler")
rc = nt_services ("xpcase","start_service","Spooler")

printf ("status: %d",rc)

[Anon Anon]

Hi Carstein,

Your elegant solution works great.  I had migrated all of my windows scripting into LUA. 

I gotta tell ya, the Nimsoft's forum is the best place that I can seek LUA solutions.

Thanks,
Hoang

Quote: ([e-mail])
The ntservices command-interface 'stop_service' with the service as the parameter needs to be called per service you want to stop ( or start for that matter).  So the simplest (and nicest) way is to implement a function that allows you to pass the start_service and stop_service command to the probe.

Carstein

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

function nt_services (address, mode ,service)
   local args = pds.create ()
   local out,rc

   pds.putString(args,"name",service)
   out,rc = nimbus.request (address.."/ntservices",mode,args)
   pds.delete(args)
   return rc
end

--rc = nt_services ("xpcase","stop_service","Spooler")
rc = nt_services ("xpcase","start_service","Spooler")

printf ("status: %d",rc)

[Anon Anon]

Quote: ([e-mail])
I like vi(m) as well, but I must admit that the Crimson Editor with its possibilities of running the script and capturing the output in an integrated window is better.  Works perfectly with Perl and Lua (NSA).

Try it out, I have modifed the lua syntax highlighting rules to include some of the specific NAS ( and the soon to come NSA - NimBUS Script Agent) statements.  Place these files into the spec directory of crimson.

The crimson editor:  http://www.crimsoneditor.com/

Hi Carstein,
I tried downloading the lua.key file and I get a page not found error. Would you mind attaching it again? I'm going to play around a bit with the NSA.

Thanks,
Chris

[Anon Anon]

It is now included in the NSA - try it out:

http://support.nimsoft.com/default.aspx?center=forum/forumPoster&fort_id=365&for_id=13

Carstein