Recon Linux/Unix inventory details and general troubleshooting steps

  • 7007707
  • 27-Jan-2011
  • 20-Nov-2012

Environment

Applies to:Recon 3.7 and above.

Situation

The article provides detailed information about Recon's inventory process for Linux/Unix systems and troubelshooting steps for common failures during inventory.

Resolution

1. First confirm that the version of Linux/Unit being Inventoried is supported by checking the following article for Recon 3.7:
 

PlateSpin Recon 3.7 supported platforms for Inventory and Data Collection ( Novell TID: 7920909 )

 
2. Once the version of Linux/Unix is confirmed to be supported, the next important thing to check is that the credentials provided have enough access.  We recommend using root when possible to both Inventory and Monitor a Linux/Unix system. In cases were it is not possible to use root, then a sudo access is needed for the account provided to be able to simulate root for some tasks.
 
3. The following article discusses the use of a non-standard SSH port for the Inventory of a Linux/Unix system in Recon:
 

HOWTO: Inventory a Linux machine using non-standard SSH port (Novell TID: 7005706 )

 
4. The following process is performed for the Inventory of Linux/Unix systems.  If any permissions or mounting options prevent the following then they will need to be corrected for Inventory to work.
 
a)   The product first uses SSH to confirm that the connection can be established.
 
b)   Recon then uses SCP to copy a script called ‘getplatform’ to the $HOME folder of the machine in question.
 
c)   Recon then changes it’s permissions to allow it to execute, and then launches that script which determines the version/build of the Linux/Unix machine.
 
d)   The results are written to the stream from the Recon server and read back.
 
e)   Recon then selects the most appropriate Inventory Plugin and uses SCP to copy the Plugin folders to a temporary folder made in /tmp on the Linux/Unix system.
 
f)   The ‘chmod +x’ command is then used on the ‘Inventory’ script in the ‘/tmp/<temporary Inventory folder>/bin’ folder.
 
g)   The script ‘Inventory’ is then run and the output is put into a XML file.
 
h)   The XML output file is then read back using SCP and the temporary Inventory folder is deleted.
 

Note: The Inventory Plugin is a set of Inventory executable files and some of it’s dependent libraries sorted on the Recon server in folders in the following default location:

C:\Program Files\PlateSpin Recon 3.7 Server\plugins\Inventory

5. If the /tmp folder is mounted with the ‘noexec’ option then the Inventory will fail.  If this is the case then the /tmp folder needs to be modified to allow execution of scripts.

6. During the Inventory process the scripts assume that various dependencies are available depending on which Inventory Plugin is used and the dependencies’ package is assumed to be in a default location.  Is it’s located anywhere else, you will need to create links to the package files in order for our script to use them.

Script Dependancies

If the Inventory script fails then a dependency may be the problem.  The following steps can be used to confirm the dependencies of the used Inventory executable:

1.    Contact PlateSpin Support to get the getPlatform script and FullInventory.xml file to troubleshoot Linux Inventory issues.

2.    Once you have the getplatform script from support, download the script to the /tmp folder on the Linux/Unix system in question.

3.    Run the following command to allow the script to run:

chmod +x /tmp/getplatform

4.    Run the script using the following command to find the output which the getplatform script thinks you have:

./getplatform

5.    Once you have the output of the getplatform script, this tells you what release of Linux/Unix the script thinks the installation is.

6.    Navigate to the following folder on the PlateSpin Recon server:

C:\Program Files\PlateSpin Recon 3.7 Server\plugins\Inventory

7.    Navigate to the sub folder which the getplatform script thinks the Linux/Unix system is.

8.    Create a folder called ‘inventory’ in the /tmp folder of the Linux/Unix system so you end up with the following folder:

/tmp/inventory

9.    Copy both folders found in step 8 above to the folder /tmp/inventory created in step 8 above.

10. Copy the 'FullInventory.xml' to the '/tmp/inventory/bin' folder.

11. Set LD_LIBRARY_PATH to the following folder:

/tmp/inventory/lib

12. On the Linux/Unix server navigate to the following folder:

/tmp/inventory/bin

13. Run the following command to allow the executable to run:

chmod +x Inventory

14. Run the following command:

./Inventory FullInventory.xml out.xml log.xml

Note: If the executable fails then you may be missing a dependency and should use the following steps to determine the dependencies of the executable on your Linux/Unix system:

a.    Run the following command:

                                  ldd /tmp/inventory/bin/Inventory

b.    If any dependencies listed are not available or in a different location then you will need to make soft links to these dependencies for the script to work.

c.    For example of step 15 part b above would be if the zlib package is installed in ‘/usr/local/lib’ instead of the expected location of ‘/usr/lib’, then run the following command:

ln –s /usr/local/lib/libz.so.1 /usr/lib/libz.so

15. The command in step 14 above will generate two XML files.  The out.xml file will contain the information that the Inventory executable was able to gather about the system.  The log.xml file will contain a log file of the script’s attempt and should include any errors that can be used to trace down further problems.

For Solaris: Sometimes on Solaris, during this process, the log.xml will be created but not the out.xml.  In this case you need to make sure that log.xml does not contain any errors.

 
Note: When using SUDO to Inventory a Linux/Unix system, all commands in this article should begin with ‘sudo ’.