The Complete Magazine on Open Source

A First Look at Open Computer and Software Inventory –Next Generation (OCS-NG)

SHARE
/ 717 0

OCS Inventory

OCS inventory NG is cross-platform software, which supports most OSs. It is based on the popular LAMP or WAMP solutions stack. Using a standardised Web interface of HTTP protocols, the network agents communicate with the management server via XML protocols. By deploying it, the systems admin’s job can be made much easier.

OCS-NG is designed to ease the systems admin’s job of managing the inventory and updating information about hardware. Licensed under GPL, it is available in 11 languages. It is also available for various flavours of Linux, Windows, Solaris, HP-UNIX, AIX and Mac OS. And it even has an option called ‘Remote deployment of software’. The unique feature of OCS-NG is auto rebuild. If your asset database gets corrupted and you have no backups, OCS-NG will rebuild it by re-collecting the data from agents through locally stored data.
OCS-NG consists of four major components that are listed below.

Figure 1

Figure 1: OCS-NG architecture

Figure 2

Figure 2: The complete OCS inventory

Administrative console: This can be accessed via an Internet browser, to manage the OCS-NG inventory. Usually, it will query the data from the database server.
Communication server: This manages the communication between agents and the database server via http.
Database server: Actual data is stored here. The default database is MySQL.
Deployment server: This is used to store deployment configurations and it works using https for high security.
All the components can be installed on a single server or on multiple servers. The best combination will be a DB server + a communication server and admin server + a console server. Figure 1 gives the communication methodology and architecture of OCS-NG. For high availability (HA) purposes we can use the admin server as the backup database server. If you have a small number of computers, e.g., 200+ nodes, you can deploy all components on a single server which has 4GB RAM running on Linux. If you choose multiple servers, Linux is preferred.
Let’s look at the pre-requisites for each component. I tried testing OCS by installing all the modules in one CentOS 5.6 server. The following are installation/configuration examples, with a single server installation of OCSNG 2.1.2.

figure 5

Figure 3: Inventory Output

Preparing the servers/components

a. Database server: For MySQL 4.1 or greater with InnoDB engine active, run the following commands:

# yum install mysql-server
# service mysqld start
# chkconfig mysqld on

To check whether the InnoDB engine is active or not, enter the following command:

# mysql> SHOW ENGINE INNODB STATUS

The default port for MySQL is 3306. Make sure your firewall or Iptables do not block Port 3306.
If you want to secure your MySQL server, run the following code:

#mysql_secure_installation

By default, the root password for MySQL will be null. Please set the root password immediately after MySQL is installed.
b. Administration console: What are required are Apache 2.x, Perl and PHP 4.1 or greater, along with GD and ZIP support enabled.
c. Deployment server: Apache with SSL enabled.
d. Communication server: Apache 2.x and Perl along with additional modules.
We have to install the rpms listed below. Most of the rpms are available on installation DVDs and the rest can be downloaded from the Web. I downloaded the missing rpms and created a separate repository as most of the following rpms are needed on the client side too. You can use Yum to install all the rpms. This will resolve all the dependencies automatically.

· perl-Apache2-SOAP-0.73-1.el5.noarch.rpm
· perl-Apache-DBI-1.08-1.el5.rf.noarch.rpm
· perl-Class-Inspector-1.24-1.el5.rf.noarch.rpm
· perl-DBD-MySQL-4.014-1.el5.rfx.x86_64.rpm
· perl-Digest-SHA1-2.13-1.el5.rfx.x86_64.rpm
· perl-FCGI-0.68-1.el5.rf.x86_64.rpm
· perl-IO-Socket-SSL-1.01-2.el5.noarch.rpm
· perl-Net-IP-1.25-3.el5.noarch.rpm
· perl-SOAP-Lite-0.712-3.el5.rf.noarch.rpm
· perl-Task-Weaken-1.03-1.el5.rf.noarch.rpm
· perl-version-0.91-1.el5.rf.x86_64.rpm
· perl-XML-Entities-1.0000-1.el5.rf.noarch.rpm
· perl-XML-Simple-2.14-8.0.el5.noarch.rpm
· php-mbstring-5.1.6-44.el5_10.x86_64.rpm
· php-pecl-zip-1.8.10-3.el5.x86_64.rpm
· php.x86_64 0:5.1.6-45.el5_11
· php-cli.x86_64 0:5.1.6-45.el5_11
· php-common.x86_64 0:5.1.6-45.el5_11
· php-ldap.x86_64 0:5.1.6-45.el5_11

OCS-NG is now ready to install. Download the OCS-NG server gzip file from http://www.ocsinventory-ng.org/ ; copy it to the test folder and install.
Create a folder OCSNG_UNIX_SERVER-2.1.2 and extract files under it, as follows:

#tar zxvf OCSNG_UNIX_SERVER-2.1.2.tar.gz
# cd OCSNG_UNIX_SERVER-2.1.2
#./setup.sh-> make sure you running this script as a root user

Answer the following questions during installation, as indicated below.

  • Which host is running database server? It’s localhost/Ipaddress
  • On which port is the database server running? The default port 3306
  • Where is the Apache daemon binary [/usr/sbin/httpd]? For default, press enter.
  • Where is the Apache main configuration file? The default configuration file is /etc/httpd/conf/httpd.conf, which you choose depending on your requirement.
  • Which user account is running the Apache Web server? Choose Apache.
  • Which user group is running the Apache Web server? Choose Apache.
  • Where is Apache Include configuration directory? The default is /etc/httpd/conf.d
  •  Where is the PERL Interpreter binary? The default is /usr/bin/perl
  • Do you wish to set up a communication server on this computer ([y]/n)? If you want to do so on the same one, press ‘y’ or ‘n’. ‘y’ is the default here
  • Where should one put the communication server log directory? The default location is /var/log/ocsinventory-server.
  • Where should one put the communication server plugins configuration files? The default location is /etc/ocsinventory-server/plugin.
  • Where should the communication server plugins Perl modules files be placed? The default location is /etc/ocsinventory-server/perl

After this, it will check all Perl modules and may throw an error for a missing SOAP::LITE module, even though you’ve installed it. Just continue to the next questions.

  • Do you want to allow the set-up renaming the communication server’s Apache configuration file to ‘z-ocsinventory-server.conf’ ([y]/n)? Press ‘y’ and then Enter.
  • Do you wish to set up the administration server (Web Administration Console) on this computer ([y]/n)? Press ‘y’ and then Enter.
  • Do you wish to continue ([y]/n)? -> You can select ‘y’ as this is our first installation and not an upgrade.
  • Where should one copy the administration server static files for the PHP Web console? The default is /usr/share/ocsinventory-reports
  • Where should one create writable/cache directories for deployment packages, administration console logs, IPDiscover and SNMP? The default is /var/lib/ocsinventory-reports

The installation logs are created under /test/OCSNG_UNIX_SERVER-2.1.2/ocs_server_setup.log. So you can store these logs for future reference.
Finally, restart Apache to reread the updated configurations.

#service httpd restart
figure 4

Figure 4: Inventory Output

Configuration
Connect to the admin console by typing http://localhost/ocsreports/ in a browser. Replace localhost with your server IP if you are working remotely.
If you get an error, then use the URL http://localhost/ocsreports/install-php to initiate the configuration again.
Use the MySQL login name root, let the password field remain blank and the rest of the values be left as they are. By default, MySQL will come with a blank root password. Modify the root password immediately after configuration.
You may get the following error: ‘Not able to connect to database.’ The ocsweb database may not be created by default, so create it manually by using the following commands:

#mysql
#show databases; -> To list DB’s
#mysql> create database ocsweb;-> To create DB ocsweb

You can now log in to OCS to configure your inventory systems. Type http://localhost/ocsreports/ in a browser and you should get a login screen. The default username/password is admin/admin. Now we will jump to OCS agent installation on client servers.

Agent installation/configuration
To install the OCS agent, we have to ensure that the following rpms are installed as a pre-requisite.

Compress::Zlib version 1.33
Digest::MD5 version 2.33
LWP::UserAgent version 5.800
Net::IP version 1.21
Net::SSLeay version 1.25
XML::Simple version 2.12

Download the Ocsinventory-Unix-Agent-2.1.1.tar.gz package, extract it and compile it by using the following code:

# tar zxvf Ocsinventory-Unix-Agent-2.1.1.tar.gz
# cd Ocsinventory-Unix-Agent-2.1.1
# perl Makefile.pl
# make
# make install

Once it is successfully compiled, it will start executing the postinstallation.pl script, which will ask the questions listed below. Be ready with the IP address of the master server running the OCS-NG service.

  • Do you want to configure the agent? If so, enter ‘y’
  • Where do you want to write the configuration file? Choose the following options:
    0 -> /etc/ocsinventory
    1 -> /usr/local/etc/ocsinventory
    2 -> /etc/ocsinventory-agent
  • What is the address of your OCS server? IP ADDRESS of your OCS master.
  • Do you need the credentials for the server? Enter ‘n’.
  • Do you want to install the cron task in /etc/cron.d? If you want to run this as a cron job, press ‘y’; otherwise ‘n’.
  • Where do you want the agent to store its files? The default location is /var/lib/ocsinventory-agent
  • Should I remove the old Linux_agent? Enter ‘y’.
  • Do you want to disable the SSL CA verification configuration option? Choose ‘n’ if you need a secured one.
  • Do you want to use the OCS-Inventory software deployment feature? Enter ‘y’.
  • Do you want to use the OCS-Inventory SNMP scans feature? Enter ‘y’.
  • Do you want to send an inventory of this machine? Enter ‘y’.

Finally, you will get the following output, which will show successful completion:

Creating /var/lib/ocsinventory-agent/http:__192.168.162.133_ocsinventory/snmp directory...
Copying SNMP MIBs XML files...
Activating modules if needed...
Launching OCS Inventory NG Unix Unified agent...
-> Success!
figure 3

Figure 5: Inventory Output

figure 6

Figure 6: OCS initial screen

We have completed the agent side configuration too. Let’s jump to the OCS admin console http://localhost/ocsreports/. Run the inventory agent from the client side, and it will automatically register in the OCS database. If it is not visible in the OCS admin console, please check the agent installation logs.
Let us view the icons shown in the OCS intial screen given in Figure 6. A brief description of each icon is given below:
1. Views all computers – once you click on it, you will get a screen like the one shown in Figure 3.
2. Views computers group-wise. You can create your own group like Prod/QA/Dev.
3. Views the computers based on your tag. For example, you can add or customise a tag (keyword) to all computers. If I add the city of the data centre as a tag, then I can search the servers in Chennai city.
4. Lists all the software installed on the server.
5. This is to search computers using a name, like, IP Addr, MAC addr, cpu, architecture and many more. And you can use multiple operators to compare groups.
6. This deploys and activates packages/apps. First, you have to build the package and deploy it on client servers. The important attributes for building a package bundle are:
a) Priority: Level 0 to 9. 9 is the least and 0 is the highest priority. This will be used to decide which package has to be installed first when deploying multiple packages.
b) File: Zip for window and tar.gz for Linux.
c) Action – Store: Just download the bundle at the client server.
d) Execute: This will deploy and execute the installer file from the bundle. Either .exe for Windows or an rpm in the case of Linux. It will just execute the command from the command box and won’t return anything like ‘success’ or ‘failure’.
e) Launch: This is to deploy a bundle with the command and it will return the value. Here you can use your own script to deploy patches.
f) You can configure the user notification if you want to notify users.
Once done, you can activate the bundle to make it ready for deployment.
7. Config: You can configure the default attributes related to the server, IPDiscovery. We will discuss a few important attributes below:
a) Frequency: This refers to the frequency (in days) to collect inventory.
b) Inventory_Diff: This is for whether to enable differential inventory or not (like differential backup).
c) Inventory Transaction: If this is enabled, it will not store inventory information in case of any partial error.
d) IPDiscover: This is to find the number of agents running IPDiscovery per subnet.
e) Deploy: This is for whether to enable automatic deployment or not.
f) Download_timeout: This is the maximum time a package can take to download to the client. If it exceeds the limit, cancel the download and log error message.
g) Local_port: This is the TCP port of the OCS communication server.
h) Local_server: This is the communication server’s name.
i) Loglevel: This is the level of log creation. /var/log/ocsinventory-NG for Linux and <appfolder>\xampp\apache\logs for Windows.
j) LDAP configuration: This is to configure LDAP credentials.
8. IP Discover: This is to auto discover the devices in a network or subnet. This feature will auto discover servers in a network.
9. Registry: This modifies Windows’ registry values.
10. Administrative data: This stores custom data for each server. For example, you may store the data centre’s name, rack number, etc, by creating custom values here.
11. Duplicates: This checks duplicates of IP, hostname and mac address, or a combination of all these parameters.
12. Dictionary: This categorises the detected packages manually.
a. New: Uncategorised softwares/packages
b. Ignored: Cannot import GLPI under these packages
c. Unchanged: The packages under this category will be imported, as is
13. Plugins: This lists installed plugins and the management of these plugins.
14. Logs: This views the logs and imports them as .csv files too.
15. Statistics: This gets the statistics about valid connections and failed connections, as well as successful and errored deployments.
16. Users: This creates users with different roles like Super admin/Admin/requester.
a. Super admin: Can change the entire configuration
b. Admin: Can add/modify users and has fewer controls
c. Requester: Has no modification access
17. Local import: Another good feature in OCS is that you can maintain inventory for non- networked servers also. You can run the inventory agent and export the file as a .ocs file from source, and import the same in the admin console using this option. So you can include servers in DMZ without actually connecting to it.
18. Help: Shows the wiki page for more help.
The list of options is very long. We can see what information we get from the inventory through the screenshots given in Figures 4, 5, and 6.
The inventory will list all the details of the installed hardware and software as shown in these figures. There are many customisations which can be done in OCS. Remember that these are only Linux agents.