- IT Inventory and Resource Management with OCS Inventory NG 1.02
- Barzan
- 3295字
- 2025-02-18 05:23:08
Setting up the OCS-NG management server on Linux operating systems
Before we begin, let's initiate a terminal session at the Linux server. This is going to be the server on which we will install the OCS-NG server. It is recommended to start an encrypted shell such as SSH. You may even work locally on the server, if possible.
We are going to look into two individual ways of installing the OCS-NG management server. You may pick either. The first installation modality will be via RPMs. Ever since OCS-NG has become popular and recognized in the open source community, several Linux distributions have started to include it into their package repository. The advantage of this is that they are officially supported, fully maintained, and kind of guaranteed to work.
While installing software, when there's an RPM, it takes barely one line of command, and the process is fully automated. The second modality that we will cover is slightly longer, as the user is required to download and extract the latest OCS-NG server archive. The user can then follow the instructions throughout the verbosely logged and interactive setup.
We agree that whenever possible, using RPMs to install and remove packages is generally recommended. In this way, you are keeping things consistent, and the software database is updated and reflects the overall state of all your applications. One thing is clear, we won't get into the source code versus RPM debate here. It's pretty long winded.
What really matters is that we know the real installation modality, if and when you fail to find an RPM package based on the version of OCS-NG you want to install.
Although these software repositories seem to be quite up-to-date, keep in mind that they are always lagging behind their official releases. Moreover, as you find yourself getting familiar with the entire OCS-NG architecture, you will want to try and play around with beta and release candidate versions.
Then again, we might also use a Linux distribution that is not RPM based. Summing these issues up, it is important to know both installation modalities. If you're using one of the popular distributions that support RPMs such as Red Hat, Fedora, SUSE, Mandriva, and others, opting for this keeps things integral. But perhaps in the official repo, there's an older version of OCS-NG. We consider it's worth taking those few minutes to install OCS-NG without precompiled packages. This is entirely your choice. We can make an inventory on either.
Another key point needs to be mentioned: OCS-NG is based on web technologies. It does not need to be compiled. A lot of people are terrified of having to compile source code in order to install an application. The OCS-NG installation package needs to be extracted and copied where you want. Once this step is done, you just launch the shell script.
Now that we know what to expect, let's get down to the real deal.
Installing OCS-NG server via an RPM package
Every time we look forward to installing an application via precompiled packages, we have to first ask our package management software repository what to do with the package (search, install, check the version, and so on). In case of OCS-NG, when it comes to these packages, most repositories are called ocsinventory.
Therefore, provided that we're dealing with Yum, we run the following query:
#yum search ocsinventory Loaded plugins: refresh-packagekit ======================Matched: ocsinventory===================== ocsinventory.noarch : Open Computer and Software Inventory Next Generation ocsinventory-agent.noarch : Open Computer and Software Inventory NG client ocsinventory-ipdiscover.i386 : Open Computer and Software Inventory NG client ocsinventory-reports.noarch : OCS Inventory NG - Communication server ocsinventory-server.noarch : OCS Inventory NG - Communication server
Based on the previous output, we have found out that there is some kind of ocsinventory package inside the yum repository of our distribution. In order to find out more details regarding the version, release, size, and so on, we are going to run the yum info ocsinventory command. The output can be seen in the following screenshot. Version 1.02.1 is available.
Now, we're quite lucky because the version found inside the repository matches the latest stable version released. This means that we can get the OCS-NG management server up and running just like installing any other application by running the following query:
yum install ocsinventory.
As always, this command resolves the dependencies and proceeds to install the software. We're going to be asked to confirm the transaction summary (six packages are needed for this).
There is another modality when we want to get an RPM package that matches the version number of our Linux distribution. We can give a try to RPM packet search engines. RPM PBone is just an example. You can find Pbone at http://rpm.pbone.net/. There are others like Rpmfind, which you can find at http://www.rpmfind.net/.
Luckily, for those who love to deal with RPMs, there's an enthusiast and developer called Remi who maintains an RPM repository dedicated to OCS Inventory-NG and GLPI. We will cover the latter in a future chapter when we get to extensions and how to integrate OCS-NG with other tools. Remi has a blog at http://blog.famillecollet.com/pages/OCS-GLPI-en where he has also posted instructions.
On this link, we can find instructions on how to install OCS-NG via RPMs provided by Remi as well. We can either configure our package management system to look into his repository, or we can just download the RPM packages ourselves and get them installed.
Check out his entire RPM collection. Keep in mind, these are not officially maintained. The community is thankful to Remi for his work and dedication.
http://rpms.famillecollet.com/
Here's a quick example on how to download and install Remi's release for Fedora 11:
#wget http://rpms.famillecollet.com/remi-release-11.rpm #rpm -Uvh remi-release-11.rpm
Should we choose to install one of Remi's releases without a package management system like yum or APT, there's a preliminary step. The RPM validity check requires the GNU Privacy Guard (GnuPG or GPG) of Remi to be imported. For instructions on how to do this, you can refer to the following link:
http://blog.famillecollet.com/pages/Config-en
The command is rpm --import RPM-GPG-KEY-remi after we downloaded the key.
These modalities should suffice, if you really opt for getting OCS-NG up and running via precompiled RPM packages. However, if we end up struggling to find the right version from repositories, then we don't need to worry. The script-based installation is the way to go.
Installing OCS-NG server via installation script
The installation script automates the setup procedure. The user is required to be present as the setup is interactive. Depending on the configuration we are trying to work with, we can install all of the server roles of OCS-NG on the same server.
In most cases, you don't really need a distributed setup where two or more servers are dedicated just for inventorying needs. A few million computers can be inventoried with today's modern servers. Any modest computer (not even a real dedicated server) can deal with thousands of inventories by itself.
These rather shy performance requirements also mean that the OCS-NG management server can be made virtual. Nowadays, most companies have server needs that are virtual and centralized. Should this be one of your concerns, it does work well with OCS-NG too.
Note
As with every other software, it is strongly recommended to use the latest final and stable release for production use. In case of test environments, beta versions and release candidates are alright. In scenarios where unknown behavior cannot be allowed: for example, production use, always choose fully tested stable versions.
The real benefit of opting for the script-based installation comes mainly from the fact that we are getting the latest versions right from the OCS-NG developers. We have the liberty to choose whichever version to install on whatever Linux distribution (or Windows), and as the installation of OCS-NG does not require compiling of sources, it goes smoothly.
The first step of the installation process is grabbing the latest version of the OCS-NG. Point your favorite browser to the Downloads section of the official OCS-NG website:
http://www.ocsinventory-ng.org/index.php?page=downloads
On the left side of the web page, you can see the versions enumerated from newest to the oldest. At the time of writing this book, the latest version is 1.02.1. Don't be led into doubt, as this does not mean that the product is in its early development stages. This is one of the project's traits, slowly increasing in version numbers. As of November 6, 2009, a new beta 2.1.3 version was released and is going through initial testing. For now, we'll work with 1.02.1.
Download the OCS Inventory NG server in a .tar.gz archived format. You should find the file in the following format:
OCSNG_UNIX_SERVER-1.02.1.tar.gz
# wget http://downloads.sourceforge.net/project/ocsinventory/OCS%20Inventory%20NG/1.02/OCSNG_UNIX_SERVER-1.02.1.tar.gz
# ls -l -rw-r--r-- 1 root root 1488981 2009-05-30 11:21 OCSNG_UNIX_SERVER-1.02.1.tar.gz
The next step is extraction. The archive contains a folder so we don't need to create it.
# tar -xvzf OCSNG_UNIX_SERVER-1.02.1.tar.gz
As you can see, we have used the tar command with -xvzf options to extract the archive. Tar is one of the most basic GNU archiving tool in Linux. The specified parameters stand for the following: -x for to extract, -v for verbose logging, -z for gzip to process the archiving through gzip and ungzip, and finally -f is followed by the target filename.
The following directory is created: OCSNG_UNIX_SERVER-1.02.1 (version dependent)
#ls -l drwxr-xr-x 5 root root 4096 2009-05-30 10:53 OCSNG_UNIX_SERVER-1.02.1
Alright, the chances are we have not encountered any problems. It is time take a peek into the extracted folder.
#cd OCSNG_UNIX_SERVER-1.02.1 #ls -l total 132 drwxr-xr-x 5 root root 4096 2009-05-30 10:53 Apache -rw-r--r-- 1 root root 36923 2009-05-30 10:52 ChangeLog drwxr-xr-x 3 root root 4096 2009-05-30 10:53 dtd -rw-r--r-- 1 root root 17987 2009-05-30 10:52 LICENSE.txt drwxr-xr-x 9 root root 4096 2009-05-30 10:53 ocsreports -rw-r--r-- 1 root root 3946 2009-05-30 10:52 README -rwxr-xr-x 1 root root 54851 2009-05-30 10:52 setup.sh
The LICENSE.txt is the GNU Public License (GPL) v2 of End User License Agreement (EULA). As always, we should not proceed further without reading the license thoroughly. Fortunately for many of us, we're quite familiar with the GNU Public License (GPL) v2 already.
The README file is a short description of the OCS Inventory NG setup procedure. A More detailed documentation is available on the online wiki from the OCS Inventory NG's website:
http://wiki.ocsinventory-ng.org/
It is available in the following languages: English, French, Spanish, Deutsch, and Italian.
The setup.sh is a console-based installation shell script that requires user interaction.
We are going to execute this script with either ./setup.sh or sh setup.sh.
When we hit Enter to the launching command, we are greeted by the OCS Inventory NG welcome screen in the terminal window.
A caution related to upgrading is pointed out, as shown in the following figure:
Any earlier Apache configuration needs to be wiped out when upgrading the communication server from 1.0 RC2. Assuming this is our first installation, we ignore it.
The installation script checks the existence of MySQL on the server and then queries its version number. You should pass this step as we did with the prerequisites earlier.
Your MySQL client seems to be part of MySQL version 5.1. Your computer seems to be running MySQL 4.1 or higher, good ;-)
Now, we are asked to specify our MySQL database network information. Where it is located? If it's on the same server, then we hit Enter for localhost.
Which host is running database server [localhost] ? OK, database server is running on host localhost ;-)
On which port does it run? If it's set to the default port 3306, then we hit Enter here too.
On which port is running database server [3306] ? OK, database server is running on port 3306 ;-)
Once the database configuration is gathered, it asks for the Apache web daemon. Assuming the daemon is binary on the default path: /usr/sbin/httpd, we hit Enter.
Where is Apache daemon binary [/usr/sbin/httpd] ? OK, using Apache daemon /usr/sbin/httpd ;-)
Now comes the main configuration file of Apache. Unless modified, it's on the default path.
Where is Apache main configuration file [/etc/httpd/conf/httpd.conf] ? OK, using Apache main configuration file /etc/httpd/conf/httpd.conf ;-)
The right permissions also need to be set. In order to do this, the script asks for the Apache user account and user group. By default, these are both apache.
Which user account is running Apache web server [apache] ? OK, Apache is running under user account apache ;-) Which user group is running Apache web server [apache] ? OK, Apache is running under users group apache ;-)
Moving on, the script automatically detects the Apache Include configuration directory. This is the place where the OCS Inventory NG configuration file is also placed. The user is asked for confirmation of the Apache Include configuration folder. If there are multiple installations of Apache and the installer gets confused, then just hit Enter on default.
Setup found Apache Include configuration directory in /etc/httpd/conf.d/. Setup will put OCS Inventory NG Apache configuration in this directory. Where is Apache Include configuration directory [/etc/httpd/conf.d/] ? OK, Apache Include configuration directory /etc/httpd/conf.d/ found ;-)
After these two main components of the LAMP solution stack are configured, we're finally getting to the last letter of the acronym. The script asks for the path of the PERL interpreter. It should be automatically detected. Just hit Enter, unless you know it's at another place.
Found PERL Intrepreter at </usr/bin/perl> ;-) Where is PERL Intrepreter binary [/usr/bin/perl] ? OK, using PERL Intrepreter /usr/bin/perl ;-)
We know that there are different ways to set up the roles of OCS-NG management server such as distributed setups where the communication server is on another server. This is when you're asked whether you want to install the communication server on the same machine as well. If so, then hit y for yes.
Do you wish to setup Communication server on this computer ([y]/n)?y
Right away, the setup automatically detects the make utility. Now it won't ask for confirmation.
OK, Make utility found at </usr/bin/make> ;-)
Mod_perl is an amazing Perl interpreter for your Apache web server. This mod is required for OCS Inventory NG's communication server to function properly. The installation script will try to detect the presence of mod_perl along with its version.
Checking for Apache mod_perl version 1.99_22 or higher Checking for Apache mod_perl version 1.99_21 or previous
If all goes well, the setup recognizes its version. Chances are it's going to be 1.99_22+.
Checking for Apache mod_perl version 1.99_22 or higher Found that mod_perl version 1.99_22 or higher is available. OK, Apache is using mod_perl version 1.99_22 or higher ;-)
However, don't worry if it cannot auto-detect the correct version. The following output may be presented on your terminal screen:
Setup is unable to determine your Apache mod_perl version. Apache must have module mod_perl enabled. As configuration differs from mod_perl 1.99_21 or previous AND mod_perl 1.99_22 or higher, Setup must know which release Apache is using. You can find which release you are using by running the following command - On RPM enabled OS, rpm -q mod_perl - On DPKG enabled OS, dpkg -l libapache*-mod-perl* Enter 1 for mod_perl 1.99_21 or previous. Enter 2 for mod_perl 1.99_22 and higher. Which version of Apache mod_perl the computer is running ([1]/2) ?2
You can find out your correct version of mod_perl by following the instruction which is as follows:
[root@fedorabox tony]# rpm -q mod_perl mod_perl-2.0.4-7.i386
We have chosen the second option as our version is higher than 1.99.2. If you don't have mod_perl installed, then it's not too late to fix this problem. Fire up another terminal/console shell on your Linux server, and using your package management software, grab it.
There are a few more steps in the installation. Now, we are asked where the server should place the communication server's logs. It defaults to a rather self-explanatory path.
Where to put Communication server log directory [/var/log/ocsinventory-server] ? OK, Communication server will put logs into directory /var/log/ocsinventory-server ;-)
The installation is going to check those prerequisite Perl modules we talked about earlier.
Checking for DBI PERL module... Found that PERL module DBI is available. Checking for Apache::DBI PERL module... Found that PERL module Apache::DBI is available. Checking for DBD::mysql PERL module... Found that PERL module DBD::mysql is available. Checking for Compress::Zlib PERL module... Found that PERL module Compress::Zlib is available. Checking for XML::Simple PERL module... Found that PERL module XML::Simple is available. Checking for Net::IP PERL module... Found that PERL module Net::IP is available.
It also checks for optional ones. These are not necessary unless the Simple Object Access Protocol (SOAP) web service functionality is required. In a nutshell, SOAP is an XML-based protocol that simplifies information exchange over HTTP. SOAP opens up numerous doors for further extensions and easy data access through third-party applications. We will learn more about this in Chapter 7, Integrating OCS-NG with GLPI when we discuss extensions and plugins.
Checking for SOAP::Lite PERL module... Found that PERL module SOAP::Lite is available. Checking for XML::Entities PERL module... Found that PERL module XML::Entities is available.
Once this step is over, the installation script begins the real work, which is as follows:
- Configures Communication server Perl modules
- Checks if the kit is complete
- Writes the Makefile for Apache::Ocsinventory
- Prepares Communication server Perl modules
- Installs Communication server Perl modules
- Creates Communication server log directory
- Fixes file permissions on the log directory, configures log rotation
- Configures Apache web server
The setup can ensure that mod_perl is loaded up before the OCS-NG Communication server is launched. This requires some renaming, and the user is asked for confirmation. Hit y for yes.
To ensure Apache loads mod_perl before OCS Inventory NG Communication Server, Setup can name Communication Server Apache configuration file 'z-ocsinventory-server.conf' instead of 'ocsinventory-server.conf'. Do you allow Setup renaming Communication Server Apache configuration file to 'z-ocsinventory-server.conf' ([y]/n) ?y
Finally, the script arrives to the last component of the OCS-NG management server suite. It asks you whether you desire to set up the Administration Server (Web Administration Console) on the same machine. Unless you're looking for a distributed setup, say y forYes.
Do you wish to setup Administration Server (Web Administration Console) on this computer ([y]/n)?y
Another caution is thrown on the terminal screen. Ignore it if you are installing it for the first time as we're doing now. Either way, the script verbosely explains the situation and asks you what to do. If you are upgrading, you will know the tasks to carry out.
After we get past that caution, we are asked where to copy the Administration Server static files.
Where to copy Administration Server static files for PHP Web Console [/usr/share/ocsinventory-reports] ? OK, using directory /usr/share/ocsinventory-reports to install static files ;-) Where to create writable/cache directories for deployement packages and IPDiscover [/var/lib/ocsinventory-reports] ? OK, writable/cache directory is /var/lib/ocsinventory-reports ;-)
The script checks those necessary Perl modules again. We're skipping that part now.
Once they are alright, as a final step, it copies and fixes the permissions for the new files.
Creating PHP directory /usr/share/ocsinventory-reports/ocsreports. Copying PHP files to /usr/share/ocsinventory-reports/ocsreports. Fixing permissions on directory /usr/share/ocsinventory-reports/ocsreports. Creating database configuration file /usr/share/ocsinventory-reports/ocsreports/dbconfig.inc.php. Creating IPDiscover directory /var/lib/ocsinventory-reports/ipd. Fixing permissions on directory /var/lib/ocsinventory-reports/ipd. Creating packages directory /var/lib/ocsinventory-reports/download. Fixing permissions on directory /var/lib/ocsinventory-reports/download. Configuring IPDISCOVER-UTIL Perl script. Installing IPDISCOVER-UTIL Perl script. Fixing permissions on IPDISCOVER-UTIL Perl script. Writing Administration server configuration to file /etc/httpd/conf.d//ocsinventory-reports.conf
The installation script quits specifying where the log file was saved and stresses on the fact that one should not forget to restart the Apache web server daemon. Before doing that, you are advised to revise the config file as follows:
/etc/httpd/conf.d/ocsinventory-reports.conf