myNMS

Installation

WARNING: this is not a configure / make / make install distribution! You will need Perl, sysadmin and possibly mySQL skills and to do a bit of work to get myNMS set up and working for you on your system.

Prerequisites

In addition to myNMS you will require:

  • Perl

    myNMS was developed using Perl 5.005_03 built for sun4-solaris. YMMV on other versions and OSes.

  • Perl Modules

    In addition to modules included in the core Perl distribution the following are required:

  • NET-SNMP

    and the SNMP.pm module included with this package. You will also need to put a copy of the BRDIDGE MIB in net-snmp's mibs directory (on the prototype system this is /opt/local/share/snmp/mibs/).

  • mySQL

    myNMS was developed using version 3.22.32, but 3.23.32 is the current stable (and supported) version. You will also need the Perl DBI and Msql-Mysql-modules (see above)

  • A web server

    myNMS was developed using Apache 1.2.3, but a newer versin of Apache with mod_perl support, with configuration set up to keep the Query script loaded in memory for faster execution would be far preferable.

  • ssh/scp

    Several of the collection scripts use ssh and/or scp to gather data from other hosts. This will be very site-specific and you may use other methods e.g. rsh/rcp, ftp or other mechanisms (e.g. simple client & server socket Perl scripts) to transfer data between your machines, depending on the configuration of your network and your security and operational requirements.

    It is not advisable to rely on NFS- or SMB-mounting filesystems from other machines: if one of these is down it can cause the NMS machine to hang awaiting response, and one of the important requirements of an NMS is usually high availability, thus it should not be dependant on other systems. (For this reason our NMS does not run NIS, unlike most other systems on our campus network.)

    Installation & configuration

    All this assumes a unix system: myNMS was developed on Solaris, but there should be no particular problems with any mainstream *n*x, e.g. Lignux. In principle myNMS should run on NT, although the Cygwin tools may help (although the KeepAlive script is heavily Unix-centric and will not run at all on NT until (when/if) the Proc-ProcessTable module is adapted to run on this system). Also note that mySQL is not free (in monetary rather than intellectual terms) for use on M$ platforms.

    For the prototype myNMS everything - collection and query scripts, SQL engine, Apache server - runs under one user account. Some sysadmins may prefer to run the SQL engine and web server as separate user IDs.

    The myNMS user has all privileges for the myNMS database, and it may help in table maintenance for the user also to have File privilege (for importing and exporting data from the database). The myNMS user is set up to not require a password for access to mySQL since in our case the NMS is running with effectively only one user accessing the machine, and with mySQL set up not to accept connections from other systems. If myNMS is run on a shared machine the DB_utils.pl script should be modified to supply the myNMS user's mySQL username and password when establishing a connection.

    Directories

    The myNMS scripts are assumed by default to be installed in the base directory and the myNMS tar file will unpack into these subdirectories relative to a directory myNMS. Thus to unpack into the default location unpack the tar file in /usr/local.

    (On a typical system it will require root privilege to create a directory in /usr/local: either run the install as root or, more safely, have root create the myNMS directory and chown it to the appropriate user and install as the user.)

    The Perl scripts assume that perl is in /usr/bin/perl.

    Perl, the base directory and any of the other directories can be located elsewhere, and either symlinked to the defaults assumed above, or myNMS files modified to point to the new locations. Each perl script starts typically: 

    #!/usr/bin/perl -w
..
use lib '/usr/local/myNMS/bin' ;
use My_module ;
    Changing these path specifiers, and the specifications of the directories (DIR section) in the etc/My_Config.cf file allows myNMS to be run with a different directory structure, provided either that the My_Config .pm (module) and .cf (config) files are in directories something/bin and something/etc, or that they are in the same directory, otherwise My_Config.pm will not find its config file.

    Running the command: 
    perl -pi.orig -e's|/usr/bin/perl|/my/path/to/perl|;s|/usr/local/myNMS|/base/dir/of/myNMS|;'
    on all the perl scripts and the config file would set the location of Perl to /my/path/to/perl and the myNMS base directory to /base/dir/of/myNMS, renaming the original files with the suffix .orig.

    This could be knocked up into a proper configure or install script.

    Configuration file: etc/My_Config.cf

    Most of the site-specific configuration parameters are set in this config file. This file is grouped into sections: section names must be at the left of the line. Within each section values are generally of the form key = value (although the = is optional). Key-value lines must start with a hard tab.

    Values may refer to values specified earlier, in the form $CONFIG{GROUP}{KEY}

    Unix-style comments starting with # are permitted.

    WWW access control file: etc/htaccess.cf

    This defines the groups of hosts and users and the members of these groups, for controlling access to web pages generated by myNMS as well as other static content pages which are required to be similarly controlled.

    In the HOSTS section host names or addresses are specified exactly as they may appear in Apache-type .htacess files.

    In the USERS section usernames alone may be specified, in which case passwords are taken from the local Unix passwd map, or username:passwd pairs can be specified.

    In either section any group may include another already-defined group using the @OTHERGROUP contriuct.

    WWW index page template: etc/index.cf

    This file controls what is displayed to users belonging to the different groups defined in the access control file.

    WWW sub-directory structure

    Within the www directory, create subdirectories with names corresponding to the 'dir' names in the 'ACCESS_GROUPS' section of the My_Config.cf file. In each directory create a symlink to the .htaccess file configured as $CONFIG{ACCESS}{ACL} suffixed with the directory name e.g. 
        ln -s /usr/local/myNMS/var/www/.htaccess.noc .htaccess
    Make symlinks in other directories to the appropriate one of these group master files, to give the same control over access to other directories/pages unrelated to myNMS. In the index page configuration file (index.cf) make links to the directories/pages for the user groups as appropriate. Example: if you have a directory 'routerconf' of router config files and info which should only be accessible to group 'noc' make a link from inside the 'routerconf' directory to the '.noc' htaccess file, and in index.cf have a line like 
        {noc}<a href="routerconf">Router Configs etc</a>

    Run the command: 

        /usr/local/myNMS/bin/DB_maint --mkhtaccess
    and check that the htaccess and passwd files are generated and that the access control mechanism works.

    Run the command: 

        /usr/local/myNMS/bin/Query index=1
    and check that index pages are created in the configured user-group directories, and that the links work properly.

    In the etc directory run make all and check that the above commands get run if the htaccess.cf and/or index.cf files have been changed (or touched).

    discovery gateway address

    The KeepAlive configuration file contains an IP address of a gateway (--gateway IP-address) which SNMP_info will use to starts its discovery of the network: this must be set to a suitable address.

    Run by hand the commands: 

        /usr/local/myNMS/bin/SNMP_info -v --gateway gateway-IP-address --snmp
    /usr/local/myNMS/bin/SNMP_info -v --arp
    /usr/local/myNMS/bin/SNMP_info -v --dot1d
    The latter two will not do anything until the first has found (from its configured gateway address) any routers and switches.

    Run by hand the command: 

        /usr/local/myNMS/bin/MAP_info

    When MAP_info has finished running, stop the SNMP_info commands if they are still running and run: 

        /usr/local/myNMS/bin/KeepAlive
    and check that the SNMP_info commands above, and MAP_info, get started up.

    Vendor/MAC codes

    The table of Vendor codes must be populated from an external source, such as this SQL restore file. This would be loaded by the command: 
    	mysql NMS < Vendor_MAC.sql
    NB The 'create table' command in the restore file will harmlessly report errors as the table already exists

    Run scripts

    Test the various other commands to be run by cron and, when satisfied that they work, enter them into the crontab, e.g: 
    # myNMS KeepAlive: this cron entry keeps alive the script which keeps processes running
*  * * * * /usr/local/myNMS/bin/KeepAlive
#
# every 5 minutes: update web index and access control pages
0,5,10,15,20,25,30,35,40,45,50,55 * * * * cd /usr/local/myNMS/etc/; make all
#
# once an hour at all times
0 * * * * /usr/local/myNMS/bin/Query_Users >> /usr/local/myNMS/log/Query_Users.log 2>&1
0 * * * * /usr/local/myNMS/bin/Query_Hosts >> /usr/local/myNMS/log/Query_Hosts.log 2>&1
# more often during mon-fri, 9am - 6pm
15,30,45 9-18 * * 1-5 /usr/local/myNMS/bin/Query_Users >> /usr/local/myNMS/log/Query_Users.log 2>&1
30 9-18 * * 1-5 /usr/local/myNMS/bin/Query_Hosts >> /usr/local/myNMS/log/Query_Hosts.log 2>&1
#
# Get web logs and process:
0 4 * * * /usr/local/myNMS/bin/LOG_info --squid > /usr/local/myNMS/log/LOG_info_squid.log 2>&1
#