Setting up prerequisite software on Linux flavors
The OCS Inventory NG management server consists of the following four server roles:
- Database server: It requires MySQL 4.1 or a higher version that uses the InnoDB engine
- Communication server: It requires Apache web server 1.3 or higher and some Perl modules (which we are going to present in a minute)
- Deployment server: It requires any web server (Apache works here too)
- Administration console: It needs Apache Web Server, PHP 4.3 or higher, and some additional ZIP and GD support
Apart from those main server components, the following modules are necessary:
- Apache server needs to be 1.3.X, 2.0.X+ with the following modules:
- Mod_perl version 1.29+
- Mod_php version 4.3.2+
- PHP 4.3.2+ with extensions:
- ZIP library of ZIP file functions and support
- GD library of image functions
- PERL 5.6+ with the following modules:
- XML::Simple version 2.12+
- Compress::Zlib version 1.33+
- DBI version 1.40+
- DBD::MySQL version 2.9004+
- Apache::DBI version 0.93
- Net::IP version 1.21+
- SOAP::Lite version 0.66+
- MySQL 4.1+ with following engine:
- InnoDB
- Any sort of make utility to control the generation of executables and similar important files from an application's source code files
- For example: GNU make.
The list might look overwhelming at first. However, in the real world, setting up these components isn't any hassle at all. Almost every Linux distribution comes with these (and many more) server roles that can be enabled easily during setup or after. The addition of these modules and certain extensions can be done in less than five minutes.
The process of installing new applications inside a Linux environment is usually assisted by package management software. These are distribution-specific utilities that download software packages from maintained repositories and automate the installation process. If all goes well, "dependency hell" is avoided seamlessly. From the user's point of view, these package managers handle everything. As a result, they are confused with installers.
Demystifying package management
The overall list of tasks that a package manager is responsible for performing is quite long. Firstly, these tools track and organize libraries and other applications present on the operating system. They know each and every program that is installed, their version, where they are installed, the packages they are dependent upon, and more.
Ever since the evolution of Linux operating system, newcomers to this world were terrified of the "dependency hell." As we all know, Linux brings lots of options when it comes to the kind of software we can choose from. There are hundreds of applications for every simple task. Usually these applications rely on already created libraries, but a problem arises when there are numerous versions of a certain library. It is hard to keep track of them manually.
Years ago, users were required to resolve this "dependency hell" themselves. This meant figuring out the list of dependencies in case of a software. Somehow, one had to find those necessary packages and libraries (that is, download them from the Web), and set them up. Once these were done, one had to try to install the application again. New dependency problems might have appeared again. Rinse and repeat. It was a long-winded process.
Package management software was designed to automate all of the preceding installations. Each distribution has an official repository of certified software, which is pretty much guaranteed to work on the said operating system. The dependencies is resolved really fast. The required libraries are downloaded from the repository as well.
This solution works fantastically in the case of popular applications as these are all officially supported. From a pragmatic point of view, this method is not a magic pill. It is not possible to officially support and certify all of the software that exists. In rare cases, the user still needs to struggle and fight with dependencies like our forefathers did.
Nevertheless, the management server of OCS-NG requires tried and proven open source server components. LAMP is the acronym for Linux, Apache, MySQL, and PHP/Perl. This software stack is one of the most widely recognized bundles with regards to setting up a general-purpose web server. This means that no matter what distribution you've chosen, these server components are going to be available via their official repos.
Before we actually begin to set up Apache, MySQL, and PHP/Perl on our Linux distro, we are going to look into some of the most common package managers. Once we know how to work with each, installing those server daemons and packages is child's play.
Getting familiar with your distribution's package manager
Nowadays, most Linux distributions come with at least one full-fledged package manager. By default, these connect and grab those binary packages from officially supported software repositories. Most package management software achieves the same functionality under a different layout, shape, form, or by using a different approach.
As a memory refresher, we cannot forget that installing packages and/or updating our Linux distributions requires root access. Despite the controversy it created, some distros allow the installation of signed packages from their official repository even without a root password, but in most cases we need root access to do administrative tasks on an operating system. Therefore, working under our favorite package manager also requires root access.
One of the most widely implemented package managers these days is yum. Yum comes from Yellowdog Updater. It is RPM-compatible and, thus, it is equipped in most distributions that support RPM packages. By its nature, yum is console based, but there are many graphical user interface (GUI) frontends available.
The advantage of using package management software such as yum comes mainly from making the update procedure really trivial. Every time a new package is installed via yum, it is stored in your software/package database. When a new version is released and added to the repository, you can find out whether you're lagging behind and update it if required. Nevertheless, not every repository is always up-to-date. This is to be kept in mind.
Opting for software that is distributed via package management comes with a certain guarantee. In case of really popular software packages, like the server components we are going to install soon (Apache Web Server, MySQL, and PHP/PERL), this is critical. Their installation becomes seamless, and they are guaranteed to work on your specific distributions. If you're running an old Linux distro, then you'll get an old version of those too.
The following Linux distributions are equipped with yum right from scratch:
- Red Hat Enterprise Linux
- Fedora/Fedora Core
- Mandrake/Mandriva
- CentOS
- SuSE Linux/openSUSE
- Yellow Dog Linux
- And others
Working with yum is quite easy. For example, installing a package is done by typing yum install package-name. To check whether an update is available for a package, we type yum update package-name. Without specifying a package-name, type yum update, it checks and updates each of them if updates are ready. In order to find out if a package is installed or not, we can simply type yum list installed package-name.
Then there are situations when we aren't sure of a package's full name. In such cases, we type yum list perl* and this way it enumerates every package that begins with perl. We can use wildcards. Removing packages can be done with yum remove package-name.
For more information and other useful tips on how to fully use yum, type man yum.
Advanced Packaging Tool (APT), was designed as a package manager user interface for Debian-based Linux distributions. Initially, it was just a frontend for dpkg, which is the core package manager on Debian derivates; it works with .deb packages.
For a moment, let's think of a pyramid. On the lowest layer, there is dpkg. It is the core of Debian package management. It is the tool that provides the functionality to install, remove, and extract information out of .deb packages. On top of dpkg sits APT. It is a friendlier interface. It is well designed, and it provides robust means to find out the best possible order for packages necessary to be installed or removed for great performance.
Some enthusiasts swear by APT, and they claim it's one of the main reasons why they stick with Debian variants. Over the years, APT was extended, and it now supports RPMs too.
Drifting back to our pyramid, on the top layer we can find Aptitude or Synaptic. These are graphical user interfaces to the previously mentioned APT. They provide a comfortable frontend and powerful searching features. Aptitude also has a command-line interface (CLI). Should you want to find more information about these applications, type man followed by command name. Right now, let's learn about the most frequently used APT commands.
The most basic APT command deals with installing packages, we can do this with apt-get install packagename. We can remove the said package with apt-get remove packagename. Upgrading packages can be achieved with apt-get -u upgrade, where the -u argument tells the system to print out the packages that are going to be updated.
As mentioned earlier, APT was ported to RPM and the tool that deals with RPM packages is called APT-RPM. The rest of the commands and arguments are similar. The configuration of APT can be quite complex, depending on your needs. Be sure to check the manual.
The following list contains a few Linux distributions that support APT:
- Debian GNU/Linux
- Ubuntu
- Conectiva ( APT-RPM, they did the port to RPM)
- Mandrake
- SuSE
- Sun Solaris
- Red Hat
- PLD
- Vine Linux
- ALT Linux
- Yellow Dog Linux
- And others
Gentoo Linux takes a different approach when considering a package management system. Originally developed on the idea of FreeBSD ports, Gentoo's powerful package manager is called Portage. Portage works with ebuilds, which are bash scripts that deal with the installation of applications. In essence, the process encapsulates the tasks of downloading the sources, configuring, making, compiling, and finally installing them appropriately.
Emerge is the utility that works with Portage. Using emerge is a double-edged sword. While it comes with lots of advantages, it can become quite complex at the same time. What we need to know is how to use emerge to install some of the necessary prerequisite packages in order to have our platform ready for OCS-NG management server. Should you really want to get your feet wet with Portage, there's plenty of documentation.
There are more than 25,000 ebuilds available through Gentoo official mirror servers. We can synchronize our local repository with these mirror servers by executing the emerge --sync command. This updates the repository with the latest version packages. We can grab a package by typing emerge packagename. This downloads the respective ebuild(s) and starts the installation process. Usually, the compiling steps are (or can be) lengthy.
Despite the original approach of not supporting binary packages, Portage does contain Pre Compiled Binary Packages (PCBP) for really popular applications that are time consuming to compile. No user fancies waiting for hours just to get a complex application suite like OpenOffice.org up and running. We can add the --bin argument to search for an available binary package. If there's one, then emerge utility will get that instead of the ebuild.