Troubleshooting Network Shell issues
The following topics apply to troubleshooting issues with Network Shells:
Network Shell not functioning after uninstalling an agent
If a 32-bit version of Network Shell and 64-bit agent are installed on a 64-bit server, uninstalling the agent causes Network Shell to not function.
Extracted package includes host name in file structure
The tar command removes a leading slash when it creates and extracts tar files. As a result, if you attempt to package files located on a remote host, the file structure includes the host name when the tar file is extracted.
Workaround: Create the tar file with four leading slashes as shown in the following example:
Host1# tar -cvf file.tar ////host2/tmp/hosts
*tar* command issues message - End of archive volume
Occasionally the tar command produces a tar: End of archive volume 1 reached message at the end of extraction. This message is not an indication of failure and does not affect the extraction in any way.
vi command takes too long to load
The vi command may take 5-10 seconds to load in Windows environments if the TMPDIR environment variable is not set to a local directory. To ensure that vi uses a local temporary directory even when invoked on a remote host, use the following syntax to set your TMPDIR environment variable:
vi command fails due to permission issues
When launching the vi command on Windows, permission errors are issued in the BMC Server Automation Console.
Choose from the following actions:
Ensure that you are logged on to the BMC Server Automation Console as an administrator (for example, as BLAdmin or RBACAdmin) when you launch Network Shell.
- Ensure that the following directories are granted read and write permissions for all users:
- Temporary file directory, <installation path>/BMC Software/BladeLogic/NSH/tmp
- Recovery file directory, <installation path>/BMC Software/BladeLogic/NSH/var/tmp
Network Shell upgrade encounters problems
Upgrading from previous versions of the Network Shell is not supported using the AIX Package Installer.
Interactive commands blocked by script command
Inclusion of interactive commands in your NSH script can cause issues if you run the NSH script on a remote terminal or shell where the operating system (Linux, AIX, Solaris, or HPUX) uses the script command (a typescript command). The script command blocks or terminates the interactive command and leads to unexpected results.
For the NSH script to successfully execute interactive commands, temporarily comment out the script command in all OS files.
External process does not return the full amount of data
External processes that are included in an NSH script and are planned to return large amounts of data (for example, a
nexec command that runs a remote batch file and then uses the
echo command to output a message 1000 times) do not return the full amount of output if the NSH process ends to soon after the external process completed. This is due to java limitations.
Include a sleep command in the NSH script to suspend the process for several seconds after the execution of the external process.
RDP tunneling on Windows requires additional configuration
You can use the
tcptunnel command to create a TCP tunnel to an RSCD agent for RDP tunneling on Windows. However, after creating the TCP tunnel, a remote desktop (RDP) connection is not established successfully without additional configuration.
To ensure successful RDP tunneling, additional configuration is required. Depending on how you launch the RDP connection, perform the relevant configuration task:
|Mode of launching RDP||Configuration task|
In your RDP (.rdp) file, set the authentication level to a value of 0:
In the default RDP file (Default.rdp) in the My Documents or Documents folder, set the authentication level to a value of 0:
or through any other shortcut to mstsc.exe