RunNow - My first script.

[llamnuds]

Attached is my first useful (well to me at least) script.

If you administrate many machines at work you might find it useful too.

What does it do?

I use it at work to launch programs on many machines simultaneously, either at a predetermined time or "now".

It can also be used to determine if a specific service is running or not running on a group of machines.

Examples?

Well say you have an application that has a database back end, and some important table gets corrupt and requires administrative intervention by yourselves, to rebuild indexes or something. You need to get everyone out of the application as quick as possible, rebuild the indexes, then let everyone know they can start using the application again.

Oftentimes the hardest part of this scenario is getting everyone out, this is why I wrote RUNNOW. It can be used to put up on every-ones screen a message, with an HTML web page, a flash application, an AU3 script or whatever, some message explaining how dire the situation is and what the user has to do to help. Or if appropriate it could be used to fire up a script to close down the application automatically.

Another feature I recently used was the process interrogator. I needed to find out exactly who out of our 250 odd users was running OUTLOOK.

In a similar vein, I needed to find out which of our machines were not running our anti-virus software, so I used RUNNOW for that too.

Installation

1) Create a directory on a shared drive accessible to all users - e.g. "Z:\RunNow\" and copy RUNNOW.AU3 executable to this directory.

2) Edit the following lines in RUNNOW.AU3 as appropriate.

• Global $admins="yourname" ; This is your windows username in your environment, so you get any error messages.
• Global $scriptDirectory="Z:\RunNow" ; This is the directory you created in step 1.

3) Compile to RUNNOW.EXE and remove RUNNOW.AU3 to a safe place.

4) Run newly compiled executable, this will automatically create any required directories.

These directories must be writable by your users, or things won't work correctly.

You may need NetWare/Windows Server administrative rights to change these permissions.

5)Add a line to your Novell/Windows login script so that your users will run this executable on logging in.

Everything revolves around a file called RUNLIST.TXT which contains instructions, or actions, which are to be carried out.

This file should only be writable by yourself and other (RunNow) administrators.

A sample RUNLIST.TXT is created automatically so you can see how to format entries in this file.

You could use it locally, on one machine, but it's really designed for network/server administrators controlling many machines/users.

For instance, I use it to control around 250 machines/users.

So once it's running on a machine, it checks the RUNLIST.TXT file every so many seconds (configurable).

Each time it checks the file, it has a look through to see if there are any entries that need to be executed.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

- - - - - - - - - - - - - - C A U T I O N : U S E A T Y O U R O W N R I S K - - - - - - - - - - - - - - - - - - - - - - -

You must Test, Test, Test before using on your machines as this script can screw up many machines in one fell swoop!

I take no responsibility if you mess up all your machines - use with care!

- - - - - - - - - - - - - - - - - - - - Y O U H A V E B E E N W A R N E D ! - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ** * * * * * * * * * *

Notes:

• You must be a listed admin to see any error messages, otherwise it runs silently.
• If it looks like something has gone orribly wrong, un-rem (remove the ; ) on the QUIT action. Then any machines running the script will quit immediately.
• RUNLIST.TXT must be readable by everyone but only writable by admins.
• The RunNow directory must be writable by everyone.
• Each action line in the RUNLIST.TXT file is executed once only for each machine/user.
• To make an action run again, change the index identifier for that line, i.e. the first parameter.
• Actions can be run at a specified date and time or immediately.
• Actions can be targeted at individual machines, individual users or all machines/users.
• Example actions : starting up a web page, a DOS program or a Windows program.
• Other actions include reporting whether a process is running, or not running.

I'm very happy to accept suggestions for improvements.

Please let me know what you think !

I value your feedback.

Cheers

Llamnuds.

Previous Versions Downloaded 126 times.

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

New Version below is V1.3.2.

RunNow.au3

Edited January 26, 2007 by llamnuds

[Eliah]

[*]RUNLIST.TXT must be readable by everyone but only writable by admins.

[*]The RunNow directory must be writable by everyone.

I understand why the list needs to be readable, as it is the point of the script, but why on earth should the executable's directory be writable?? Wouldnt that undermine the whole operation?

Is there some reason for that?

[llamnuds]

I understand why the list needs to be readable, as it is the point of the script, but why on earth should the executable's directory be writable?? Wouldnt that undermine the whole operation?

Is there some reason for that?

Hi Eliah,

Yes, there is a reason for that.

Say the script is reading the RUNLIST and comes across an action that should be performed, it first checks to make sure it hasn't already been performed.

But how does it know what it's already done?

It keeps track of what actions each machine and user has performed by writing entries in subdirectories inside the RUNNOW directory. They are simple text files, one file for each user and another for each machine, inside which is a comma seperated list of the indexes of all the commands that have been executed by that machine/user.

If the directory isn't writable then the script won't be able to record the fact that an action has been performed, therefore the action will be performed over and over, each time the script checks the RUNLIST.

So changing one or more characters in the index field of an action in RUNLIST will ensure the action is executed again. This is because the new index will not be found in each user/machine action tracking file.

Clear as mud, eh!

It's a lot simpler than I've made it sound, honest!

Cheers,

llamnuds

[Eliah]

If the directory isn't writable then the script won't be able to record the fact that an action has been performed, therefore the action will be performed over and over, each time the script checks the RUNLIST.

If this "accomplished" data is only for the client machine to know, why not save it on the client machine? I guess saving it to the shared folder is good for the admin to see what has been accomplished already; I'm just getting a bad feeling about write access to the place orders are taken from!

[llamnuds]

If this "accomplished" data is only for the client machine to know, why not save it on the client machine? I guess saving it to the shared folder is good for the admin to see what has been accomplished already; I'm just getting a bad feeling about write access to the place orders are taken from!

Saving the "accomplished" data on the client machine is a good idea but for the fact that client machines might occasionally be re-imaged, and thus the data lost in the process. When the "refreshed" machine comes back up it would re-run any commands listed as being applicable for all machines. Keeping this data centrally prevents this from happening.

I think the way it is at the moment is a good way of doing it, though to be honest until you just mentioned it I hadn't thought of storing that data locally. Hmmmm.

There is no worry about users writing to the RUNLIST file if it is has it's rights correctly set to Read Only for regular users.

Cheers,

llamnuds

[daslick]

Why not use a different shared folder for the log data? That way a malicious user could not damage the operation of the program, only the logs?

[llamnuds]

Why not use a different shared folder for the log data? That way a malicious user could not damage the operation of the program, only the logs?

The way it's currently setup there are a number of shared directories within the main application folder.

These should be set up with R/W access for everyone/public.

The RUNLIST.TXT and RUNNOW.EXE file should have R/W access for people listed as RunNow admins and R/O access for everyone/public.

As long as these permission are set correctly, despite the fact that RUNLIST.TXT and RUNNOW.EXE are visible to the users, and readable, and in a directory they can write to - they won't be able to write to RUNLIST.TXT or change/delete the program.

So from the users perspective...

RUNNOW - - r/o directory

|

|___RunNow.exe - - r/o file

|___RunList.txt - - - r/o file

|___ACTIONEDBYMACHINE - r/w directory

|___ACTIONEDBYUSER - - - r/w directory

|___AUDITBYMACHINES - - - r/w directory

|___AUDITBYUSERS - - - - - - r/w directory

Cheers,

Llamnuds

Edited January 5, 2007 by llamnuds

[llamnuds]

I'm curious, has anyone got this to work?

Cheers,

Llamnuds

[jaenster]

Great , but al that comment makes it 5 kb bigger

[SmOke_N]

Great , but al that comment makes it 5 kb bigger

That was just a stupid thing to say.

[llamnuds]

I've uploaded a new version, with the following changes...

1.0.0 Released into the wild.

1.0.1 Changed processAuditRecording to seperate Users and Machines into different directories.

1.1.0 Added File Existence auditing capabilities with the "FILEEXISTS" and "FILENOTEXISTS" actions.

1.1.1 Amended File existence routine to allow for wildcard checking by removing * and ? where appropriate in the audit filenames

1.1.2 Added some missing comments in the inital RUNLIST text file creation function, and some blank lines.

Also removed a few redundant lines of code from the deleteOldCopies function.

1.1.3 Added $logThis global variable - to which OSVersion and OSBuild were added.

1.1.4 Added password auditing facility, and move RELOAD action up, to be an early action.

1.2.0 Refactored action routines - tidied up and combined/renamed ISRUNNING and ISNOTRUNNING into PROCESS, and FILEEXISTS and FILENOTEXISTS into FILE.

1.3.0 Changed the order of the fields in RUNLIST.TXT

Combined USER and MACHINE fields to be one and the same. Made two fields a minimum requirement - index and action.

1.3.1 Corrected missing CheckPassword action

1.3.2 Some general tidying up and refactoring.

Cheers,

Llamnuds