Overcee and Variables

Introduction

Today I’m going to be creating a custom computer reboot tool in Overcee in order to show off how to use variables to lock tools down.

Situation

As has been previously mentioned, allowing free access to modify some tools can be inherently dangerous and can result in unexpected or unwanted behaviour. However, sometimes you want users to be able to set or modify one small part of the input, without modifying the whole thing. So how do you do that? The answer lies in variables.

In the example below, a user is going to create a Tool Sequence for remotely restarting client devices, allowing other users to specify the message that is displayed to users of those computers.

Job Space Variables

Overcee implements a concept known as Job Space Variables (JSV), which provide temporary data storage for the duration of a job. These variables may be set and read internally by tools, or manually through the use of “variable” tools.

Process

Nigel is a power user, and is trusted with using the Remote Execute program directly. He has a copy in his “Nigel’s Base Tools” container, along with the Set Job Space Variable tool.

Nigel doesn’t have write access to this container, but can derive tools from it. So he goes to a container he does have write access to (“Nigel’s Tools”) and goes to New Tool to derive new tools from his base ones.

He selects and configures the Set Job Space Variable tool first.

Nigel wants to use the Set Job Space Variable tool to allow users to set the message that displays when restarting computers. To make this clearer to users, he renames this tool to “Comment” and changes the description accordingly.

He then sets the Variable Name input’s Value property (the name of the Job Space Variable) to “COMMENT” (without the quotes) and locks it down so that when running or deriving from this tool, this value cannot be viewed or modified. Note that here the variable name is plain text without the surrounding square brackets (“[” and “]”) as you would use when calling the variable from elsewhere.

Next, he wants to make sure the input is clear to users, so he changes the “New Value” input’s name to “Comment”, updates its description, and adds a default value (“Your system is about to be restarted for maintenance”.

Finally, he changes the “This Computer Only” input to FALSE, so that this is used throughout the whole job, not just for the computer it is running on at that time (this doesn’t matter in this case as the variable would be set to the same value for each computer, but this is for clarity’s sake).

With that done, Nigel moves on to the Remote Execute Program tool. Like before, he derives and configures a new tool from it.

Here, Nigel has renamed the tool to “Restart Computer” and updated the description accordingly.

He sets the Command Line input to use the shutdown.exe tool available in Windows’ System32 folder. He doesn’t bother to change the name of the input or anything else, because he locks this input down so that it won’t be shown to users.

Next he configures the Parameters input. The shutdown.exe tool requires a few parameters to work. Nigel wants the target computer to restart, so he adds the “/r” command, and he wants a fair warning period before initiating the restart, so he sets it to wait 120 seconds with the “/t 120” command.

Now he wants to add the message the user has entered. The shutdown.exe command to add a message is “/c “, so he enters that with the Job Space Variable he defined in the “Comment” tool he created previously by adding the command “/c “[COMMENT]””.

Now Nigel creates a simple Tool Sequence and add first the “Comment” tool, and then the “Restart Computer” tool to the sequence.

And that’s it. When a user runs the Tool Sequence, they will be prompted for a Comment input.

When the Job is run, the Job Dispatcher will automatically pick up the comment value set by the user and run the shutdown command with it.

Conclusion

This is a simple use of Job Space Variables which can help to lock down tools while still providing flexibility to users. It isn’t perfect, and could be greatly improved through the use of the String Replace tool to filter user input, for example, or by also allowing the user to specify the warning delay time.

Hopefully this gives you some idea of the power that can be achieved through the proper use of variables in Overcee though.