|
How do I start the GUI?
For windows, just double click on the desktop icon. For Unix/Linux, change directory into the “script-run” directory you created in the End-User Setup Instructions. Then, from the Unix shell prompt, type in the command “automater“
Example:
cd $HOME/net-scripts
automater
How do I run the scripts from the command line?
The scripts can be run from the GUI or from the command line. To run the scripts from the command line, change directory into the “script-run” directory you created in the End-User Setup Instructions. Next, from the Unix shell prompt, type in the script name along with the relevant options:
Example
cd $HOME/net-scripts
cisco_send_cmds -cf my_show_cmds.txt -rf rtrs_asia_pac.txt -safe
All of the scripts can run with the -help option to view the command line options. Below are the executable script names. Complete details for each script can be found in the Users Manual.
catos_send_cmds
check_bgp_routes
cisco_passwd_change
cisco_send_cmds
conf_bkup_show_run
cisco_config_cmds_devices
cisco_config_cmds_rcf
copy_to_tftp
encrypt_logins
flash_report
generic_send_cmds
ios_report
pinger
tracer
What should I check after a script completes?
After a script completes first check the summary_log file located in $HOME/net-scripts (You can also click on Summary Log from the GUI). This will tell you whether the script reported any errors. If there are errors you can check the detailed trace log for more information. The detailed trace log will is written to the file script_name.log.or the filename specified if you used the -log <filename> option.
Do I need to use the -log option?
No, this is optional. Use this if you want the detailed trace file to be saved to a name other than the default name which is script_name.log. This is useful if you run the same script multiple times called from a shell script. This way you don’t overwrite your detailed trace for each script run after the shell script completes all of the script runs. Remember, the file script_name.log is overwritten each time a particular script is run.
Suppressing Output to screen when running scripts.
When a script runs, all of the output that you would normally see, if you were typing the commands manually, is written to the screen (or the log Window for the GUI). There’s a configurable paramter that will block all of this output and only display error messages and status messages. From the GUI, go to Options-Settings and deselect the “Verbose Log Display” button. If your not using the GUI, you can edit the variable “log_user” located in the file $HOME/net-scripts/setup.var. By default this parameter is set to 1, which shows all output. Change this variable to a zero to hide the output and only display error messages. Note, the detailed log file will still be created. If running the GUI from a remote X windows session, the output written to the log window may lag. In this case, deselecting the “Verbose Log Display” button will help performance. Note, when running a script for the first time or making critical changes, it may not be desirable to block the output display. This way you can view exactly what is happening. If you think you have made a mistake or you don’t like what is happening, you can just hit the GUI “Abort” button, or type Control C if running the scripts from the command line.
Building command line options using the GUI.
The GUI contains a History button which keeps track of the options for any previous script runs. This is convenient when running scripts multiple times (once a day or once a month); just select a previous script run and all of the options are automatically populated in the GUI. In addition, you can select the a previous script run and then just copy the entire command line. This is useful if you want to create a batch job in a shell script. Just copy the command line from the History window and paste it into a “wrapper” script (shell program).
Tracing Errors from Summary Log and Detailed Log.
When a script encounters an error, an error message is written to both the summary log file and detailed trace file. The error message starts with the word ERROR (all capitals) followed by a number. Thus, you can see the error message and number in the summary log file and easily search for and go to the location in the detailed trace log where the error occurred.
Using “Safe” (-sf) and “SuperSafe” (-ssf) modes
Some of the scripts have the option to run in safe or supersafe mode. The option is available primarily on the scripts that have the ability to make configuration changes to devices. In safe mode, if a script encounters an error while issuing a command to a device, the remaining commands that should be sent to that device are aborted and the script moves on to the next router/device in the list. An example of where this would be useful is when sending commands that are sub-commands of a previous command. For example, suppose you wanted to send the following commands to a router:
interface fastethernet 0/0
ip accounting
interface fastethernet 0/1
no ip accounting
If fastethernet 0/1 does not exist on the router and you did NOT run the script in safe mode, interface fastethernet 0/0 would have ip accounting turned OFF. That’s because “interface fastethernet 0/1″ would return an error and the script would just go on and issue the next command (no ip accounting).
In supersafe mode, the script will abort entirely if an error is encountered (not move on to the next router in the list)
The -ual Option and Enable Mode on Routers
When issuing commands on IOS based devices, some commands require “enable” access (or 2nd level access) while others don’t. For scripts that must have have 2nd level access to work (e.g, cisco_passwd_change), the script automatically attempts to go into enable mode. For other scripts, enable mode access is really dependant on the type of commands you are sending to the router/device. For scripts that do not automatically go into enable mode, use the -ual 2 option if you require 2nd level access. (Note, ual stands for User Access Level)
|
