Version 2.1.0
http://sourceforge.net/projects/onecmdb/forums/forum/916038/topic/3684851
Several days ago a tested OneCMDB installation in an existing Tomcat setup.
On first sight everything works well.
But while using NMAP and importing excel-sheets things go wrong.
I found out why.
In all OneCMDB UNIX-scripts this string ". ../../setenv.sh" is used for sourcing the "/path/to/onecmdb/bin/setenv.sh" file to get the variables
echo ============ENVIRONMENT=====================
echo ONECMDB_HOME=$ONECMDB_HOME
echo JAVA_HOME=$JAVA_HOME
echo NMAP_HOME=$NMAP_HOME
echo ONECMDB_URL=$ONECMDB_URL
echo ONECMDB_DESKTOP_URL=$ONECMDB_DESKTOP_URL
echo ============================================
The usage of . ../../setenv.sh is very error-prone.
In several cases the variables will not be set because of the path being wrong.
Also, in the second part of some of the scripts (where transform.sh is called) the variables will never reach the subshell. This is caused by the lack of exporting the variables.
Therefore my proposal is to use
--------------------------------------------------------
export ONECMDB=`pwd | sed 's/onecmdb.*/onecmdb/'`
. $ONECMDB/bin/setenv.sh
--------------------------------------------------------
instead of the ". ../../setenv.sh" string
This works OK. Whatever the current directory is, $ONECMDB/bin/setenv.sh will now be sourced as it is intended.
This should be done for the files
repository/MDR/NMAP_Discovery/bin/nmap-discovery.sh
repository/MDR/NMAP2BasicModel/bin/nmap2cmdb.sh
repository/MDR/Nagios2BasicModel/bin/cmdb2nagios.sh
repository/MDR/Nagios/bin/import-nagios.sh
repository/MDR/Nagios/bin/export-nagios.sh
repository/MDR/Import2BasicModel/bin/transform-import-cmdb.sh
repository/MDR_Template/Default/bin/transform-import-cmdb.sh << template
The file repository/MDR/setenv.sh is not necessary anymore and can disappear!
This change should also be done for the files in $ONECMDB/bin
discover.sh, export.sh, generate-transform.sh, import.sh, modrepl.sh, schedule.sh, setenv.sh, sync.sh and transform.sh
Note: This problem also exists for Windows/MS-DOS scripting
Regards, Jan E. van Bijnen / NetSourcing, Netherlands
