This chapter describes what you need to know to get NetworkAuthority Inventory installed and running to manage your network device inventory.
NetworkAuthority Inventory can be downloaded as a VMWare Virtual Appliance. If you choose to go this route you only need to get a VMWare player from http://www.vmware.com/download/player/. All of the prerequisites are met insite of the virtual image. Simply download the NetworkAuthority Inventory VM image, play it in your VM Player and open a web page to https://your-vm-ip:8080.
Follow these steps if you are not using the VMWare Virtual Appliance.
Before installing the NetworkAuthority Inventory server certain prerequisites must be met.
To connect to the NetworkAuthority Inventory server the client just needs any modern browser with the Adobe Flash Player 9 installed.
The following operating systems are officially supported for the NetworkAuthority Inventory server:
AlterPoint also provides a unix tarball of the NetworkAuthority Inventory binaries that can be used to run NAI on other Linux variants as well as Mac OS X. Running NAI on any platform not listed above is considered experimental. All support must come from the community via the IRC, email lists or the forums.
The following prerequisites are needed for running the NetworkAuthority Inventory server:
Sun Java Development Kit (
JDK) version 1.5 (aka version 5) or higher
-
-
On Mac
OS X, the version of Sun Java included should be the correct version if updates with Apple are up to date. Please run Apple's Software Update to ensure this is so.
Perl version 5.8.8 or higher
-
On Linux and Mac
OS X, the
Perl included with the operating system should suffice.
Besides having version 5.8.8 of higher installed of Perl, there are a number of Perl modules that must be properly installed in order for the NetworkAuthority Inventory server to function properly.
= perlcheck.pl Perl Script =
There is a Perl script named perlcheck.pl located in the base directory of the NetworkAuthority Inventory server install that can be executed to check if all of the Perl dependencies have been met. While the perlcheck.pl script will check for missing modules on all operating systems, it does behave slightly differently depending on if Windows is being used or not:
On Windows, if it has been determined that any number of
Perl modules have been missing, then PPM will automatically be used to download all of the missing modules. The
NetworkAuthority Inventory server installer for Windows automatically executes the
perlcheck.pl Perl script at the end of installation to automate the install of missing modules.
On Linux and Mac
OS X, the
perlcheck.pl Perl script will simply print out all of the
Perl CPAN commands necessary to retrieve the missing
Perl modules. This method was chosen since many distributions of Linux can have their package managers install
Perl modules instead of using the CPAN method of install
Perl modules. It is up to the user to decide how they want to install the missing
Perl modules.
Once the perlcheck.pl Perl script has been executed and all of the Perl module dependencies have been successfully met, you should see a message stating:
All the Perl modules required by ZipTie are already installed! Yatta!
The following sections outline steps for properly installing the NetworkAuthority Inventory server component on various operating systems. Certain operating systems may have various ways of having the NetworkAuthority Inventory server installed, so please find the section that corresponds the chosen installation method. Before attempting installation of the NetworkAuthority Inventory server, please ensure that all the prerequisites are met; this is outlined in the Prerequisites section of the User Guide.
To install the NetworkAuthority Inventory server on Windows, double-click the downloaded file and follow the installation wizard. The installation wizard will perform the following actions:
Checks if an existing ZipTie server is already installed on the system. If it is, the installer will not continue onwards until the previous ZipTie server installation is removed. If you do remove the previous installation of ZipTie, make sure to preserve your data when prompted; the NetworkAuthority Inventory installation will migrate any exisiting ZipTie data if found.
Ensure that a valid version of both
Perl and and the Sun
JDK are installed before continuing. This should not be an issue if all of the prerequisites have been properly met.
Prompts the user for the desired installation location. The default location is: C:\Program Files\NetworkAuthority Inventory
Prompts the user as to whether or not they would like to install the
NetworkAuthority Inventory server as a service and/or start the server once the installation has finished. For more information regarding running the
NetworkAuthority Inventory server, particularly as a service, please refer to
The Server section.
Installs all of the NetworkAuthority Inventory server files into the specified location.
Once the installation has finished, the
perlcheck.pl script will be ran to resolve any possible missing
Perl modules. For more information regarding the
perlcheck.pl script, please refer to the
Perl Module Dependencies section.
To install the NetworkAuthority Inventory server on Ubuntu, the preferred method is to use the Ubuntu-specific .deb package. Please note that this .deb package is designed specifically for Ubuntu. This means that it will not work for Debian or any Debian-based Linux distributions. This is because the list of dependencies that the .deb package try to resolve are specific only to Ubuntu. In order to install the NetworkAuthority Inventory server on a different Linux distribution, please refer to the Other Linux Distributions and Mac OS X (.tgz Method) section.
The Ubuntu-specific .deb package will perform the following actions:
Installs all of the NetworkAuthority Inventory server files into the /usr/share/networkauthority-inventory directory.
Creates an
alterpoint user. This is the user that will be used to run the
NetworkAuthority Inventory server if being executed through as an init.d service. Please refer to the various ways to run the
NetworkAuthority Inventory server in the
The Server section.
Changes the ownership of all of the files and directories in the /usr/share/networkauthority-inventory directory to belong to the alterpoint user. This is to ensure that the server can only be run by the authorized alterpoint user and to make sure that it can't be executed with an super-user privileges.
Executes the
perlcheck.pl Perl script to determine if there are any missing
Perl modules that are required by the
NetworkAuthority Inventory server. The check is performed because when using the Ubuntu-specific
.deb package, nearly all dependencies will be installed; It is possible, however, that not all of
Perl module dependencies could automatically be installed. The reasons for this is that some of the required
Perl modules can not be installed using Ubuntu's package manager or they do not have package maintainer for Ubuntu. Please use the commands output by the
perlcheck.pl Perl script to install these missing modules. For more information regarding the
perlcheck.pl script, please refer to the
Perl Module Dependencies section.
Installs the
NetworkAuthority Inventory server to run as an init.d service and be properly handled at system startup and shutdown. Once the service is installed, the
NetworkAuthority Inventory server will be started. For detailed regarding setting up and running the NetworkAuthority Inventoryserver using a service, please refer to the
The Server section.
To install the NetworkAuthority Inventory server on any other distribution of Linux or Mac OS X, simply download the NetworkAuthority Inventory Server tarball (.tgz) archive and extract the contents into a desired location. This process will only install the NetworkAuthority Inventory server files onto the system and does not perform any other task. In order to to run the server, refer to the The Server section.
The default installation of the NetworkAuthority Inventory server includes an embedded version of the Apache Derby database. However, NetworkAuthority Inventory can be configured to use MySQL 5.1+ (officially supported) or PostgreSQL 8.2.5+ (experimental only).
Included with the NetworkAuthority Inventory server is a utility that can be used to initialize (or re-initialize) the NetworkAuthority Inventory database. This utility is a Perl script that resides in the root of the server installation directory and is called dbutil.pl.
Here is an example of running the utility to initialize a MySQL database instance:
./dbutil.pl --db=mysql reset
And here is an example of running the utility to initialize a PostgreSQL database instance:
./dbutil.pl --db=pgsql reset
Both of these example assume defaults for the given database. For MySQL the user 'root' with no password is assumed, and for PostgreSQL the user 'postgres' is assumed. By default, a 'localhost' installation of either database is assumed. These defaults can be overridden by command line parameters supplied to the dbutil.pl utility. Running dbutil.pl with no parameters provides usage information for the utility, like so:
Usage: dbutil [options] <action>
Options:
--db database (one of: derby, mysql, pgsql)
--user the user to connect to the database as (optional)
--pass the password to connect to the database with (optional)
--host the hostname of the database server (optional)
--port the port number of the database server (optional)
--dir the NetworkAuthority Inventory installation directory (optional)
Actions:
reset reset NetworkAuthority Inventory to it's original state
If you are running your database server on a different machine, there are further edits to NetworkAuthority Inventory configuration files that must be made in order for the NetworkAuthority Inventory server to be able to connect to the database during startup.
For MySQL the file osgi-config/bitronix-jta/btm-config.mysql.properties must be edited and the following lines changed to suit your environment:
resource.ds.driverProperties.url=jdbc:mysql://localhost/ziptie
resource.ds.driverProperties.user=root
resource.ds.driverProperties.password=
Additionally, the file osgi-config/quartz/quartz.mysql.properties must be edited and the following lines changed to suit your environment:
org.quartz.dataSource.ziptie.URL=jdbc:mysql://localhost/ziptie
org.quartz.dataSource.ziptie.user=root
org.quartz.dataSource.ziptie.password=
In the files above, for a remote installation of a server, 'localhost' should be replaced by the hostname or IP address of the server along with the port if it is not the default port (eg. jdbc:mysql:/ /dbhost:8029/ziptie). Once these edits are made, the server can be started. You should check the ziptieServer.log file to ensure there were no errors during startup. If you received no errors, your installation is correctly configured.
For Postgres the file osgi-config/bitronix-jta/btm-config.pgsql.properties must be edited and the following lines changed to suit your environment:
resource.ds.driverProperties.user=postgres
resource.ds.driverProperties.password=
Additionally, the file osgi-config/quartz/quartz.mysql.properties must be edited and the following lines changed to suit your environment:
org.quartz.dataSource.ziptie.URL=jdbc:postgresql://localhost/ziptie
org.quartz.dataSource.ziptie.user=postgres
org.quartz.dataSource.ziptie.password=
In the files above, for a remote installation of a server, 'localhost' should be replaced by the hostname or IP address of the server along with the port if it is not the default port (eg. jdbc:postgresql:/ /dbhost:8029/ziptie). Once these edits are made, the server can be started. You should check the ziptieServer.log file to ensure there were no errors during startup. If you received no errors, your installation is correctly configured.
The following sections outline steps for running the NetworkAuthority Inventory server component on various operating systems. Certain operating systems may have various ways of running the NetworkAuthority Inventory server installed, so please find the section that corresponds to the desired method of execution.
If you are running NetworkAuthority Inventory from the VMWare virtual appliance then the server process will be started as a daemon process when the image loads.
On Windows, there are two methods for running the NetworkAuthority Inventory server: using the system service that was setup when the NetworkAuthority Inventory server was installed, or directly starting up using the server.bat batch script.
The NetworkAuthority Inventory server is capable of being installed as a Windows Service, which will allow it to begin at system startup and will terminate at system shutdown. The installation of this service is usually achieved by choosing to install it during the NetworkAuthority Inventory server installation. Assuming that the NetworkAuthority Inventory server install ran successfully with the option to install as a service, then there should be a NetworkAuthority Inventory Server service available on your system.
If the NetworkAuthority Inventory server was not installed as a Windows Service during the installation process, it can be done manually after the fact following these steps:
In a terminal, navigate to the NetworkAuthority Inventory server installation directory, such as C:\Program Files\NetworkAuthority Inventory
From the base NetworkAuthority Inventory server directory, navigate to the ztwrapper\windows directory
Execute the following command:
''ztwrapper.exe --install ztwrapper.conf''
Once the NetworkAuthority Inventory server is installed as a Windows service, the following message will be displayed:
STATUS | wrapper | 2008/01/15 12:54:21 | NetworkAuthority Inventory Server installed.
In order to manually control the NetworkAuthority Inventory Server service from the command line, refer to the following commands:
To start the service:
net start "NetworkAuthority Inventory Server"
To stop the service:
net stop "NetworkAuthority Inventory Server"
To see what other functionality can be performed against the service:
net help
Although the NetworkAuthority Inventory Server service may have been properly installed, there may be a time when a user wishes to manually run the NetworkAuthority Inventory server. This can be achieved by executing the server.bat batch script that is located within the installation directory of the NetworkAuthority Inventory server. Please note that the server can only be invoked this way if the NetworkAuthority Inventory Server service is not currently running; otherwise, there will be conflicts.
In order to provide support for automatically starting and stopping the NetworkAuthority Inventory server on Ubuntu, an init.d service script by the name of ztserver is included. The ztserver script allows the NetworkAuthority Inventory server life cycle to be controlled within the init.d service framework. Here are the actions that the ztserver init.d script supports:
start
stop
Tears down any port redirection that was set up using the iptables command.
Uses the su command to switch to the alterpoint user.
Invokes the ztwrapper binary as the alterpoint user to stop the server.
restart
Calls the stop action
Calls the start action
status
As mentioned in the Server Installation section, this init.d service functionality will be installed automatically when using the Ubuntu .deb package.
In order to manually control the NetworkAuthority Inventory server init.d service on Ubuntu, reference the following commands:
To start the server:
sudo invoke-rc.d networkauthority-inventory start
To stop the server:
sudo invoke-rc.d networkauthority-inventory stop
To restart the server:
sudo invoke-rc.d networkauthority-inventory restart
To check the status of the server:
sudo invoke-rc.d networkauthority-inventory status
For more information on how to manually set up the init.d service for the NetworkAuthority Inventory server, read the following section.
On systems that don't support init.d style services, or if you wish to manually run the server, there is a Bash shell script provided to invoke the NetworkAuthority Inventory server called server.sh. The server.sh is a Bash script that invokes the NetworkAuthority Inventory server for startup. The server.sh script can be found with in the base NetworkAuthority Inventory server directory location.
In contrast to the functionality of the ztserver init.d script, the server.sh script only brings up the NetworkAuthority Inventory server. This means that any port redirection that may be necessary for certain low ports for TFTP, FTP, HTTPS and SNMP to higher ports for use by NetworkAuthority Inventory Server will need to be manually done by the user. This has to be done because the TFTP and FTP servers provided by the NetworkAuthority Inventory server can not bind to 69/21 due to restricted access. The NetworkAuthority Inventory TFTP and FTP servers by default bind to port 11069 and 11021 respectively.
On most Linux distributions, the iptables command is available to perform this functionality. Please refer to the zt_iptables function within the ztserver script to see one way of redirecting ports using the iptables command.
On Linux systems that support the init.d services framework, a user can leverage the ztserver script to control the NetworkAuthority Inventory server life cycle. Here are the actions that the ztserver init.d script supports:
start
stop
Tears down any port redirection that was set up using the iptables command.
Uses the su command to switch to the alterpoint user.
Invokes the ztwrapper binary as the alterpoint user to stop the server.
restart
Calls the stop action
Calls the start action
status
In order to properly use the ztserver script to control the NetworkAuthority Inventory server, two pre-requisites must be fulfilled:
Create a alterpoint user with non-administrative privileges. This is required in order to ensure that the NetworkAuthority Inventory server is not run as a user with administrative privileges. Within the ztserver script, it is expected that alterpoint is a valid user and will be used via the su command when starting/stopping/restarting the server. If you wish to use a different name than alterpoint, be sure to update the RUN_AS_USER variable located within the ztserver script; the RUN_AS_USER variable is what is referenced when changing users using the su command.
Change the ownership for the NetworkAuthority Inventory server installation directory and its entire contents to belong to the newly created alterpoint user. This is to ensure that the NetworkAuthority Inventory server can only be executed by the alterpoint user or a super-user.
Once the alterpoint user has been successfully created and the ownership of the NetworkAuthority Inventory server has been successfully changed, the following steps can be enacted to allow the ztserver script to be used to control the NetworkAuthority Inventory server as an init.d service:
Create a symbolic link to the
ztserver script within your distribution's init.d directory:
ln -s <NetworkAuthority Inventory>/ztserver /etc/init.d/networkauthority-inventory
A symbolic link must be used rather than copying the ztserver script because there are relative paths contained within the script that assume the script is based out of the NetworkAuthority Inventory server directory.
Create a symbolic link to the
ztserver script within your distribution's desired init.d run-level directories. For most distributions based on System V architecture, the following commands should work:
ln -s /etc/init.d/networkauthority-inventory /etc/rc3.d/S99ztserver
ln -s /etc/init.d/networkauthority-inventory /etc/rc3.d/K01ztserver
ln -s /etc/init.d/networkauthority-inventory /etc/rc5.d/S99ztserver
ln -s /etc/init.d/networkauthority-inventory /etc/rc5.d/K01ztserver
These commands will ensure that the NetworkAuthority Inventory server is invoked at system startup and terminated at system shutdown.
In order to manually control the NetworkAuthority Inventory server init.d service, reference the following commands:
To start the server:
sudo /etc/init.d/networkauthority-inventory start
To stop the server:
sudo /etc/init.d/networkauthority-inventory stop
To restart the server:
sudo /etc/init.d/networkauthority-inventory restart
To check the status of the server:
sudo /etc/init.d/networkauthority-inventory status
NetworkAuthority Inventory has the ability to mail things like scheduled reports. To do this, NetworkAuthority Inventory must know of a good SMTP server to send mail through. By default it tries to send mail to the hostname mail. If that hostname doesn't resolve on your NetworkAuthority Inventory server then you must configure it further.
To do so, edit the file ~/NetworkAuthority Inventory/osgi-config/mail/mail.properties. Set the mail.host property to the hostname of your SMTP server. There are additional commented out fields in the file to allow you to authenticate to your SMTP server if necessary. Below is an example of this file's contents.
mail.host=mail
mail.from=nai@nai.alterpoint.com
mail.from.name=NetworkAuthority Inventory
mail.smtp.starttls.enable=true
# mail.auth.user=someuser
# mail.auth.password=somepassword
mail.smtp.auth=false
After editing the file you must restart your NetworkAuthority Inventory server for the changes to take effect.
Once the server has been installed you can connect to it from a web browser at https://yourserver:8080/
Enter the Administrator username (default 'admin') and password (default 'password') and click Login.
Once you have your inventory populated, you will want to back up the configurations of all your devices. A device that has never been backed up will be decorated with a question mark on it.
To back up a device, select the device in the Devices view and select 
Backup.
A progress dialog is displayed. If the backup fails, the device is decorated with a red exclamation mark. If the backup is successful, the device is decorated with a green check.
NetworkAuthority Inventory provides a way for you to organize your devices by “tagging” them. You can tag devices by selecting one or more of them in the inventory and selecting 
Tag. You can create as many tags as you like. You can tag and untag devices and, you can file devices with the same tag by performing a tag search.
The Devices view displays all the devices in your inventory. This is the starting point for many tasks in the system.
The left section is the search area. Here you may specify a type of search (eg: IP Address, Hostname, OS Version, etc) and the query input. Under the query is a status message explaining the results of the last search requested.
The right section is the results area. The devices matching your search on the left will be displayed in this table.
This search allows you to search for devices that have an interface matching a query of either an exact IP Address or an IP CIDR mask.
For example: '10.100.22.6' will return just the device with the IP '10.100.22.6' and '10.100.22.0/24' will return all devices that are in the 10.100.22.* subnet.
This search works the same way as the Interface IP Search except that it only returns the devices who's administrative interface's IP matches the query. The administrative IP is the IP Address that is used by NetworkAuthority Inventory to uniquely identify the device.
This search allows you to search for devices based on the Operating System Version devices are running.
To search for a device you must specify an OS Type an operator and the target value.
For example: If you are looking for Cisco devices running IOS 12.2(17) or higher your search input would be 'Cisco IOS', '>=' (Greater or equal to), and '12.2(17)'.
In this case, a devices running 12.2(15) or 11.2 won't match but a devices running 12.2(17a) or 12.3 will.
As different device types use different versioning schemes it is not possible to search for similar version across device types.
This search allows you to find devices based on their model number. For this search you must specify the Vendor and a query for the Model.
The Vendor drop down is populated based on all the available vendors in the system.
The Model query allows for '*' wildcards anywhere in the input.
For example: If you want to see a list of you Cisco 2600 series routers select 'Cisco' as the Vendor and specify the Model query as '26*'. The results will include Cisco devices with model numbers that start with 26.
This search allows you to find devices based on user set tags. You will be presented with a selectable list of tags. If the list is empty, this is because you have not yet configured any tags. You can ctrl+select more than one tag. Selected tags will be used in the search.
The hostname search allows you to find devices based on the hostname.
You may use wildcards in you query input but only at the beginning or end of the input.
The right side of the view contains a table display of the devices. This table gives a brief overview of each device it displays. For more information on any device you may double click on it to open it's details.
The configuration search view allows you to search for text in all devices' latest configurations.
ZipTie uses Apache Lucene to search configurations, details on the syntax can be found on the Lucene website: http://lucene.apache.org/java/docs/queryparsersyntax.html
The following Lucene fields are made available to search upon:
text - The contents of the configuration.
address - The device IP address.
name - The configuration path (eg: /running-config)
timestamp - The time when the configuration was backed up.
mimetype - The mime-type of the configuration.
network - The device's managed network.
To find any configuration containing the text “Joe Bob”
"Joe Bob"
To find any configuration containing the text Joe and Bob but not necessarily next to each other
Joe Bob
To find all running-configs containing the text “Loopback2”
text:"Loopback2" AND name:"/running-config"
The Jobs View shows all the server jobs. From this view you can open, rename, move, and delete jobs.
This view will display the history of job executions including jobs currently in progress. Double clicking on an execution will open the results for the execution if applicable.
The Switch Port Search provides a way to find the closest switch to a given host. You can specify the host either by Fully Qualified Domain Name (FQDN), IP Address, or MAC Address. For this feature to work you must have neighbor data collected for your network devices.
A
DNS lookup is performed to resolve the FQDN to an IP Address.
NetworkAuthority Inventory determines the MAC Address for the IP by finding a device that has an ARP or NDP entry for the IP Address. If the IP address exists on more than one ARP table, the ARP entry with a unique MAC address is used.
The MAC Address is then used to search for a switch and switch port nearest to the host. If the MAC address is found on more than on forwarding table, the port with the lowest number of MAC addresses forwarded to it is used.
The IP Search allows you to search for addresses allocated on your network based on device ARP entries.
Given an IP Address or CIDR it will find all the devices managed by NetworkAuthority Inventory that have an ARP entry for the address.
In this chapter you will be introduced to the standard tools supplied with NetworkAuthority Inventory. See the Content Developer's guide for information on writing your own tools.
In a fresh install of NetworkAuthority Inventory there are three categories of tools: Change, Read, and View. To access those you can use a button on the control panel with the nut wrench icon. You have to have at least one device selected. Below you can see 2 screenshots with unselected and selected device from the list and disabled/enabled control panel.
Unselected device / disabled control panel
Selected device / enabled control panel
After you selected a device and clicked on the tools button you can see context menu like in the screenshot below:
Change tools act directly on devices to make changes to their configurations. This includes things like adding user accounts, changing passwords, and pushing new
OS images.
View tools do not interact with devices directly but instead use the data already collected by the NetworkAuthority Inventory server to show information about the devices. This includes things like showing the hardware information, the interfaces, and viewing the firewall model (access lists).
The DNS Lookup tool performs a reverse-DNS lookup using the IP of the selected devices to resolve the names. Note that the name resolution is performed on the NetworkAuthority Inventory server, and therefore the DNS servers configured for that machine will be used.
The Interface Brief tool obtains the list of interfaces configured on the selected device and displays Current UP/DOWN status and Administrative UP/DOWN status of each interface.
The IP Routing tool retrieves the routing table, if available, from the selected device.
The Ping tool performs a simple (ICMP) ping operation against the selected devices and displays the results in a tabular format.
The Portmap tool performs a port-scan of the selected devices and displays the results in a table consisting of common protocol ports and an “Other” column used to display non-standard ports that are discovered open.
The SNMP System Information tool uses SNMP to retrieve system information from a standard SNMP Object Identifier against a set of selected devices. The resulting system information is displayed in a table.
The Traceroute tool performs a standard traceroute operation to discover the connection path between the NetworkAuthority Inventory server and the selected device. The resulting route is displayed in a table, with one “hop” displayed per row.
These tools act directly on devices to make changes to their configurations. This includes things like adding user accounts, changing passwords, and pushing new OS images. Please be aware that some change tools use configurations stored in your local computer to facilitate input and it won't be updated until the next successfull backup job.
This tool allows you to change interface status. Just choose the status from Up/Down drop down and interface(s) from the list and click ok. Again be aware that these inerfaces are taken from the configuration stored in your server (the workstation you running NetworkAuthority Inventory server on) and is not reflecting the real status of the interfaces from the device. You can run the backup right after you ran some change tool or you can configure SEC to do that automatically. Below the screenshot of the “Enable or Disable Interfaces” tool.
This tool allows you to upload the new software image to the box. Software image is like an OS kernel. Is NOT a running-config or startup-config. The inputs of this tool are: IOS image file to push - the local path to software image, Destination flash location - the remote path of the software image (located in the flash device) and additional fields explained below.
Destination flash directory - to specify the destination flash directory (it has to exist on the flash)
Destination flash partition - to specify the destination flash partition (it has to exist on the flash)
Remove the existing image from flash - to replace files
Boot from the new image - makes box to boot from the new image
Reload after image push - reload after the change is completed
This tool changes login banner of the device. Just input login banner content and click OK.
This tool adds/removes name servers to/from the device (those are used when device needs to convert example.com to 208.77.188.166). It also allows you to change domain suffix name (like yourdomain.com).
This tool adds/removes ntp servers to/from the device. Just type the the server to remove or server to add and click OK.
This tool allows you to assign one or several ports/interfaces to a VLAN. You can choose several ports/interfaces and only 1 VLAN at a time. Ports/interfaces and VLANs are taken from your NetworkAuthority Inventory server config entries. Just like in “interfaces statuses” tool port/interface you choose to assign might already belong to that specific VLAN. So it would be a good custom to backup the device after running this tool. Below the screenshot of the “Port VLAN Assignment” tool.
This tool allows you to upload configuration file to device. You can upload configuration to the running-config or to the startup-config. Just choose the destination file, local path for the config and click OK.
This tool adds/removes community string to snmp database of the device. You can choose between 2 access types of the new community: RO (read-only) & RW (read-write).
This tool adds/removes trap hosts to snmp database of the device. The inputs of the tool are: trap host name/address (can be IP or hostname), community string and the action to perform - add or delete.
This tool adds/removes syslog hosts of the device. You can input one or more hosts, to add or delete, separated by the comma semicolon or space.
This tool has 2 suboptions: 1 - Add Static Route, 2 - Delete Static Route. As those names indicate first suboption allows you to add static route and the second one to delete one or more static routes. The inputs to add static routes are: destination address (ip address), destination mask (using common ip notation) and the gateway (ip address). If the device needs an extra input for the interface (for example PIX require interface to set static route) then tool will automatically find out all the interfaces installed on that box and loop through those to add the static route to each specific ethernet card. The inputs to delete static route is just a list with “existing” static routes from the device. Just like in other tools when the NetworkAuthority Inventory client uses lists with data to facilitate input these static route already may not exist on that device because they are taken from the NetworkAuthority Inventory server configs. So make sure to backup the device after you ran this tool.
This tool has 5 suboptions: 1 - Add User Account, 2 - Delete User Account, 3 - Change User Password, 4 - Change Enable Password, 5 - Change VTY Password (the order of the options may be different). Before starting to use this tool please be aware that if you have any AAA service running in your box (like TACACS or RADIUS) some of those suboptions may not have effect.
Add User Account: helps you to add new user account. The inputs used by this tool are: username, password and privilege (RO - read only, SU - super user/admin/root).
Delete User Account: helps you to remove existing user account. The input used by this tool is username.
Change User Password: helps you to change password of the existing user. The inputs used by this tool are: password and confirm password.
Change Enable Password: helps you to change password of the enable/root/super user. The inputs used by this tool are: password and confirm password.
Change VTY Password: helps you to change VTY password. The inputs used by this tool are: password and confirm password. If VTY config has other settings stored in the config those will be reprinted by the tool.
To connect to individual device in the network NetworkAuthority Inventory must - like all other device users - gain access to the devices. To gain access to a specific device, the device must first ensure that NetworkAuthority Inventory is a valid user on that device. Many network environments have different authentication credentials for different types or different functions of their devices. For example, you may have one set of credentials for all of your Cisco devices and another set for all of your Nortel devices. You may have different sets of credentials based on whether the devices are routers or firewalls or because one set of devices is managed by one part of the organization and another set by another part of the organization. In this chapter you will learn how to configure these device credentials for NetworkAuthority Inventory to use.
Before NetworkAuthority Inventory performs its management operations on individual devices in the network, it must - like all other device users - initiate communication with the devices to perform backups and make changes. For NetworkAuthority Inventory to communicate with a specific device, NetworkAuthority Inventory must understand the protocol the device uses for communication. Many network environments have different communication protocol for different types or different functions of their devices. For example, you may have one protocol for all of your Cisco devices and another set for all of your Nortel devices. You may have different protocols based on whether the devices are routers or firewalls or because one set of devices is managed by one part of the organization and another set by another part of the organization.
Since there may be multiple different credentials for the devices in your network, NetworkAuthority Inventory employs the concept of network groups. A network group is a container into which you add credential sets and address sets. Credential sets are “named sets” of credential types and credential values for a set of devices that require those specific authentication credentials. Address sets are IP addresses that define the network group. You can use wildcards as a way of grouping devices based on your network addressing scheme.
Network groups can have multiple credential sets and multiple address sets. To help manage access to network devices, NetworkAuthority Inventory provides a way to prioritize how network groups (and their associated credentials and address sets) are evaluated. By listing network groups in priority order, you are telling NetworkAuthority Inventory which address sets to attempt to connect to first, second, and third before failing. When the credentials in a network group are successful at accessing a device, NetworkAuthority Inventory remembers the credentials that were successful on that device and uses them each time thereafter when connecting to the device. If, for some reason, the credentials on that device change, then the next time NetworkAuthority Inventory attempts to connect to that device, it will fail authentication. On the next connection attempt, NetworkAuthority Inventory will reconcile the credentials again, so it will succeed. And then it remembers the new credentials.
You specify the IP addresses of a set of device and then create enough credential sets to authenticate NetworkAuthority Inventory on all devices under management.
NetworkAuthority Inventory employs the same strategy for protocols as it does for credentials. Protocol sets are sets of protocol types for a set of devices that require those specific communication protocols. Address sets are IP addresses that define the network group.
There are a few schedulable jobs in ZipTie including Device Backup, Tools and Reports. Scheduling works the same for all of them.
Most jobs can be created either from the Jobs View or from the New Job
menu in the Devices View.
You can open existing jobs from the Jobs or from the History View.
All jobs' editors have a page called the Schedule
page. This is the page where the Triggers for the job are managed.
Here is an example of the Schedule page for a Backup job. This page is the same for all job types. It is from this page that you will manage the schedule for the job.
A Trigger defines when a job should run. A job's Schedule normally refers to the set of all Triggers for the job.
To create a trigger all you need is a trigger Name, a Start time, and a Recurrence.
The Name needs to be unique for the specific job but does not need to be anything specify.
The Start time is the time when the trigger will be activated. This is not necessarily the time the job will be run.
The Recurrence is the definition of when the job will run. The available types of recurrence are Once, Daily, Weekly, Monthly, or Cron.
If once is specified as the recurrence frequency the job will run at the time specified by the Start time and then the trigger will be discarded.
A daily trigger will be executed at the time of day as specified by the Start Time every X number of days.
A weekly trigger will be executed at the time of day as specified by the Start Time every checked day of the week.
A monthly trigger will be executed every X months on a certain day of the month at the time of day as specified by the Start Time.
If an End Date is specified the trigger will be discarded on that day.
A Filter defines a period of time when triggers will not fire. Each trigger can have one filter associated with it.
Filters are defined in the Scheduler Filters
dialog which can be found on the left side bar.
NetworkAuthority Inventory uses Quartz internally for job schedule management. For more information about quartz please visit their website at http://www.opensymphony.com/quartz/.
NetworkAuthority Inventory provides a role-based security system. In a role-based security system, Roles are comprised of a set of Permissions. Users in the system can be assigned a Role. This section will document how to manage user's and roles with the NetworkAuthority Inventory administration utility.
The NetworkAuthority Inventory Administration Shell is a command line utility that can be used to administer users and roles. The utility is named admin.pl and can be found in the NetworkAuthority Inventory Server installation directory. In Linux and Mac OS X, the utility is invoked as follows:
./admin.pl
And in Windows, the utlity is invoked as follows:
admin.pl
If you don't have Perl associations installed, you can invoke the utility as follows on all platforms:
perl admin.pl
Once the utility has been invoked, you will receive a login prompt for the Administrative ('admin') password. Once the password has been entered, and the server has been successfully connected to, you will receive an Administration utility prompt like so:
NetworkAuthority Inventory Administrative Shell - 2008.10.0
Administrator password: ********
[localhost:8080]$
–more to come–
NetworkAuthority Inventory can be configured to send SNMP v2c traps to an external listener. Currently the following events in NetworkAuthority Inventory can generate a trap.
A new device is added to the inventory
A device configuration has changed
A device is deleted from the inventory
An operation, such as a backup, fails
To setup the ZipTie server to send these traps, edit the file ~/osgi-conifg/network/nil.properties found on your NetworkAuthority Inventory server. In this file, add your trap receiver to the nil.snmp.trap.receivers property. The NetworkAuthority Inventory server must be restarted to pick up your new trap receivers.
Trap receiver definitions are in the form:
<community>@<host>/<port>
For example:
public@10.100.32.53/162
You can configure multiple trap receivers by comma separating their definitions.
public@192.168.1.20/162,public@10.23.30.2/162
NetworkAuthority Inventory ships with a ZIPTIE-MIB.txt MIB which you can compile on your external trap listener to make the integration even easier. The MIB can be found in your ~/osgi-config/network/ folder on your server or you can download the MIB from http://fisheye.ziptie.org/browse/ZipTie/conf/network/ZIPTIE-MIB.txt.
