This document describes the procedure to be used to install an X-Itools server from an archive release file available on X-Itools sourceforge project page (*.tar.gz format).

The installation is certified for RedHat 7.2 and 7.3 servers.
The installation is certified for RedHat 8.0 and 9.0 servers, which includes gcc 3.x and apache 2.x, from version 0.5.65 of the X-Itools only.
The installation is certified for Fedora Core 2 servers.

The installation consist in several parts:

• before to start
• download the archive file you want
• modify httpd.conf file of apache server 1.3.X
• configuration, compilation and installation of the product
• configuration of PostgreSQL
• initialization of the X-Itools database
• installation of the localisation files (languages)
• installation of the crontab
• update an existing X-Itools database to a new database template
• restart apache
• the X-Itools configuration file
• Install the X-Itools startup script
• Install the X-Itools Firewall Logger startup script
• X-Itools log files
• Devices manager and SSHTerm configuration
• test of the X-Itools server

This documentation does not describe how to install softs needed for X-Itools server to run properly: apache, postgresql, sendmail, SSL, OpenSSH, LDAP, CheckPoint SDK, and/or others. But usually, you will not have the possibility to compile the product if one of them is not installed. You will have error messages instead. Furthemore, recent Linux distributions allow a very easy installation with their integrated packages managment system, RPM.

BEFORE TO START:

Versions < 0.6.10:

On the computer which will be the X-Itools server, create a user called xitools:

#> useradd xitools

His home directory should be something like /home/xitools or whatever.

We will use this unprivileged user to receive the X-Itools tar.gz archive which will be downloaded below.

Versions >= 0.6.10:

Just log on with your user account. We will download the X-Itools archive directly under your home directory.

DOWNLOAD THE ARCHIVE RELEASE FILE:

Versions < 0.6.10:

Now that the xitools user has been added, login as him.

#> su - xitools $>

and download the latest release file of the X-Itools project on sourceforge.

Versions >= 0.6.10:

Now that you are in your home directory, download the latest release file of the X-Itools project on sourceforge.

All versions:

The package name is x-itools. Click on download on the right and select the archive you want. As of today, several packages are available, but of course we strongly recommend you to download the latest:

x-itools-0.5.tar.gz x-itools-0.5.20.tar.gz ... ... x-itools-0.6.10.tar.gz

now, uncompress the archive:

$> tar -xzf x-itools-0.6.10.tar.gz

If all goes well, you should now have a directory named x-itools in your homedirectory. This directory contains all what is needed to install a X-Itools server from sources.

Here below is the tree you should have in the x-itools directory:

x-itools-0.6.10     +    lib               // sources of the shared library     +    pixmaps           // picture files     +    po                // language files     +    src               // sources of each module     +    DB                // Database patches and template     +    m4                // m4 preprocessing macros

MODIFY HTTPD.CONF FILE OF APACHE 1.3.X SERVER:

You will need root rights to modify the apache configuration file for X-Itools. Normally, this file sould be located in /etc/httpd/conf directory, but it could depends of your linux distribution or installation.

So, do the following:

$> su root

enter your root password and edit the httpd.conf file with your favorite editor (I'm sure it is vi):

#> vi /etc/httpd/conf/httpd.conf

This configuration file is very well documented. Go at section 3 of the file: this is where we will create and configure virtual hosts.
For this, look for the word NameVirtualHost in the file: it should exist. We have to enable this directive if it is not the case. For that, remove the # if there is one. The NameVirtualHost must contain your ip address: in fact the IP address of your apache server, where will be installed the X-Itools binary files. For example:

NameVirtualHost 10.10.10.1

Now, we have to create a VirtualHost on usual http port 80 specific to the X-Itools server. If you wish, you can modify the default virtualhost for port 443, and in this case the X-Itools server will be accessible through SSL. If your are a company, I am sure you think that security is something important.

So, if you want to enable SSL for X-Itools, modify the <VirtualHost _default_:443> block as follow in the httpd.conf file:

<VirtualHost _default_:443> # General setup for the virtual host DocumentRoot "/var/www/x-itools" #ServerName new.host.name ServerAdmin xitools ErrorLog logs/x-itools.ssl.error_log TransferLog logs/x-itools.sll.access_log # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. #SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A test # certificate can be generated with `make certificate' under # built time. Keep in mind that if you've both a RSA and a DSA # certificate you can configure both in parallel (to also allow # the use of DSA ciphers, etc.) SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt #SSLCertificateFile /etc/httpd/conf/ssl.crt/server-dsa.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key #SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server-dsa.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/httpd/conf/ssl.crt/ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/httpd/conf/ssl.crt #SSLCACertificateFile /etc/httpd/conf/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/httpd/conf/ssl.crl #SSLCARevocationFile /etc/httpd/conf/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details. #<Location /> #SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ #</Location> # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o CompatEnvVars: # This exports obsolete environment variables for backward compatibility # to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this # to provide compatibility to existing CGI scripts. # o StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire <Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars </Files> #<Directory "/var/www/cgi-bin"> # SSLOptions +StdEnvVars #</Directory> <Directory /var/www/x-itools> AddHandler cgi-script .cgi Options +ExecCGI SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" </VirtualHost>

As you can see, we have decided that the DocumentRoot for the files of the X-Itools server is /var/www/x-itools, and the ServerAdmin is the user xitools we have created previously. You can change this if you want.

It means that all the files we will compile must be installed in the directory /var/www/x-itools.

Furthemore, don't forget to enable some options for the directory /var/www/x-itools, regarding the execution of the scripts. This is in the sub-section <Directory /var/www/x-itools> of the virtual host.

So, all is done for X-Itools over ssl.
Now, we will create another virtualhost for X-Itools server on usual http port 80.

At the end of the httpd.conf file, just add this VirtualHost section:

<VirtualHost 62.50.65.20>     ServerName x-itools.mydomain.com     ServerAdmin xitools     ErrorLog logs/x-itools.error_log     TransferLog logs/x-itools.access_log     DocumentRoot /var/www/x-itools     <Directory /var/www/x-itools>         AddHandler cgi-script .cgi         Options +ExecCGI     </Directory> </VirtualHost>

In this case, the X-Itools virtual host can be reached in a browser with the following URL only:

http://x-itools.mydomain.com

As usual, you can change the DocumentRoot directory and the ServerAdmin name. But if you have enabled X-Itools over SSL, the DocumentRoot directory must be exactly the same in the SSL VirtualHost and in the normal VirtualHost.

A last thing we have to configure is to tell to Apache that it must take care of the index.cgi file, because in standard, it is only configured with a lot of index files, but not with a CGI based index file. For this, look for the keywork DirectoryIndex and add at the end of this parameter, the file index.cgi. You should obtain something like this after that:

DirectoryIndex index.html index.htm index.shtml index.php index.php4 index.php3 index.phtml index.cgi

once you did all of this, you can save the changes in the httpd.conf file and exit vi.

We will not restart the web server now, because before, all the X-Itools binaries must be installed in the correct directory.

CONFIGURATION, COMPILATION AND INSTALLATION OF THE PRODUCT:

To compile the X-Itools you need gcc 2.96.x minimum on RedHat 7.x based systems, or gc 3.x on RedHat 8.0 or 9.0 based systems. However, only X-Itools from version 0.5.65 are designed to be compiled on both gcc 2.96.x and 3.x.

As root, perform the following operations in the directory of the X-Itools project:

#> ./configure #> make #> make install

That's it !!!

As usual, the configure script will check if all needed dependencies are installed on your system in order to compile the X-Itools source codes. You shouldn't have any error messages here. If so, try to install the missing packages or try to resolve any other issues.

The make command compile all the sources.

The make install command install the binaries and other related files in /usr/local by default, which is not the correct recommended path. For example, the directory of the X-Itools virtual web server will be created as /usr/local/var/www/x-itools, the database files will be installed in /usr/local/var/lib/pgsql, and so on.

In order to install all files in the correct path, that is to say the base path must be / and not /usr/local, type the following configure command before to do the makes:

#> ./configure --prefix=/

After this, correct files will be installed in correct paths, that is to say /var/www/x-itools for executable files, /var/lib/pgsql for the database files, and so on. /var/www is the base path that should correspond to Apache standard path (which is /var/www on a RedHat 7.3). The configuration file will be installed in /etc, and the database template will be installed under /var/lib/pgsql, which is the standard location for PostgreSQL 7.2.x. Furthemore, the crontab of the X-Itools will be installed in the cron entries of your system, and the localisation files will be installed in the correct path.

Note that instead of setting a prefix for the configure command, you could leave it as it is, and you can after the makes, copy the correct files in the correct paths yourself.

Of course, it is necessary to initialize the database, and to modify the httpd.conf file in order to create the virtual server needed for X-Itools files (see step above).

Versions >= 0.6.10:

The compilation of a X-Itools version greater or equal to 0.6.10 is different. From this version, a new X-Itools daemon is included, using the CheckPoint SDK. This daemon is the X-Itools Firewall logger daemon.

CheckPoint SDK must be downloaded from the CheckPoint web site and used the way it is described below to successfully compile the X-Itools. The problem is that ChekPoint has created his SDK on a RedHat 7.3 basis, with gcc 2.96.x.

So here you have two choices: either you don't need the X-Itools CPLog Daemon and you can proceed with compilation and installation as described just above, or you want to use it and you will have to compile all X-Itools modules with a gcc 2.96.x, using the instructions below.

At first, you need to download the CheckPoint SDK directly from CheckPoint web site. After having it uncompressed in your home directory, you just have to add the --with-opsec-dir=/CheckPoint/SDK/Directory to the ./configure command, as below:

#> ./configure --with-opsec-dir=/home/directory/OPSEC --prefix=/

After, continue as described above.

CONFIGURATION OF POSTGRESQL:

In order for the X-Itools server to be able to connect to the X-Itools database, postgresql must be configured to allow TCP/IP connections accross the network. Even if the database server and the X-Itools server are installed on the same machine.

So, we have 2 PostgreSQL configuration files to modify. At first, modify /var/lib/pgsql/data/postgresql.conf and enable those lines to enable PostgreSQL network listener:

# # Connection Parameters # tcpip_socket = true                  # we have enabled and modified this line #ssl = false #max_connections = 32 port = 5432                            # we have enabled and modified this line #hostname_lookup = false #show_source_port = false

host all 0.0.0.0 0.0.0.0 trust

The line above means that all connection to all the database from any hosts are allowed. We can be more restrictive than this. At first, limit connections only on xitools database, and from your different networks only (if the X-Itools server is to be used internally only, for an intranet for example). In this case, we can have something like this:

host xitools 10.0.0.0 255.0.0.0 trust host xitools 192.168.16.0 255.255.255.0 trust

Note that if you have only one X-Itools server on the same machine than the X-Itools database server, you can configure PostgreSQL like this:

host xitools 127.0.0.1 255.255.255.255 trust

If you have several X-Itools server connected on the X-Itools database server, just register all the IPs of them like showed below. Such configuration can be used to introduce redundancy or fault tolerance:

host xitools 193.212.7.9 255.255.255.255 trust host xitools 193.212.7.10 255.255.255.255 trust host xitools 89.12.69.254 255.255.255.255 trust

Now that PostgreSQL configuration files have been modified, PostgreSQL daemon must be restarted like this, under root user:

#> /etc/rc.d/init.d/postgresql restart

Be very carefull and check that PostgreSQL will start each time the machine will boot. For this, and like Apache, startup scripts in /etc/rc.d/init.d must exist. To check it for PostgreSQL, type the following command:

#> chkconfig --list postgresql

If you don't have a list of runlevels where you see 'on' or 'off', but instead a message is displayed telling you that despite the fact that PostgreSQL can use chkconfig, it is not registered for now, type the following command to enable PostgreSQL at startup:

#> chkconfig --add postgresql

In another case, if you have a list or runlevels where you see 'on' or 'off' but if you see that it is off for runlevels 3, 4 and 5, type this command:

#> chkconfig postgresql on

We have finished for the configuration of PostgreSQL.

INSTALL AND INITIALISE THE DATABASE:

The only one useable database for now is PostgreSQL 7.x.

You should have postgresql installed and running on the X-Itools server or on another remote server. PostgreSQL must be configured to allow connexions on a database named xitools comming from your X-Itools web server, even if the SQL server is the same as the DB server.

You will have to change or update the pg_hba.conf file to authorize such connexions. And postgresql must be launched with the option which makes it accept the connexions accross the network. For this, just read previous section.

If the database template is not in postgresql home directory (which is usually /var/lib/pgsql), copy it like this:

#> cp /home/xitools/20010715_01/xitools_template.out /var/lib/pgsql

and set the good rights on the file:

#> chown postgres:postgres /var/lib/pgsql/xitools_template.out

Login as your database user:

#> su - postgres $>

create the xitools database (postgresql must be running):

$> createdb xitools

run pgsql interface to create postgresql xitools users:

$> psql xitools xitools=#

now, create the xitools user:

xitools=# create user xitools with password 'xitools';

and create the user nobody:

xitools=# create user nobody with password 'xitools';

and exit pgsql interface:

xitools=# \q

now, initialize the xitools database:

$> psql -e xitools < xitools_template.out

The xitools database is now ready.

Don't forget to edit the file XItool_Biblio.H of the source tree to update some #define parameters according of the ip address of your database server. For now, such parameters are hard-coded directly in the sources. In the future, such parameters will be moved in the configuration file which will be read by the X-Itools binaries.

INSTALLATION OF THE LOCALISATION FILES (LANGUAGES):

If you want to use the X-Itools in french or another language, you will have to install the localisation files. The command below, which install french localisation file, must be used after installing the X-itools server for the first time, and each time you do an update, in order to install the updated localisation file.

To install french localisation file, type de command below (you must be in the X-Itools base directory, ie 20010715_01, as root):

#> msgfmt -o /usr/share/locale/fr/LC_MESSAGES/X-Itools.mo po/fr.po

Normally, you are now completely ready to test the X-Itools server.

INSTALLATION OF THE CRONTAB:

If the crontab hasn't been installed, we have to do it. Here, we have three cases: either you have a version of the X-Itools server which is under 0.5.65, or you have a version which is between 0.5.65 and 0.5.96, or you have a version which is 0.5.97+.

Versions < 0.5.65:

The crontab is a very important piece of the X-Itools server: thanks to it, the database is optimized automatically each night, and the Check script is launched each minute. This script is responsible for a lot of operations like send shared agenda notifications, do the necessary checks of machines across your network (for the ping module) to see if there are alive, perform operations on users holiday accounts, and so on...

To check if the crontab is installed or not, type as root user the following command:

#> crontab -l

If nothing appears, it just means the crontab must be installed. The crontab file of the X-Itools project is located at the base of the X-Itools directory. The file is named crontab.root. Install it like this:

#> crontab crontab.root

And check again. You should have the following result:

#> crontab -l * * * * * /var/www/x-itools/XItool_Check.cgi 0 0 * * 0 psql -c "vacuum analyze;" -q -U postgres -d xitools 0 0 * * 1-6 psql -c "vacuum;" -q -U postgres -d xitools

Versions 0.5.65 <= V <= 0.5.96:

Here, the crontab is only responsible for the operations related to the database, in order to optimize it and to give you the guarantee that it is running as faster as possible.

To check if the crontab is installed or not, type as root user the following command:

#> crontab -l

If nothing appears, it just means the crontab must be installed. The crontab file of the X-Itools project is located at the base of the X-Itools directory. The file is named crontab.root. Install it like this:

#> crontab crontab.root

And check again. You should have the following result:

#> crontab -l 0 0 * * 0 psql -c "vacuum analyze;" -q -U postgres -d xitools 0 0 * * 1-6 psql -c "vacuum;" -q -U postgres -d xitools

The check script is not executed by the crontab any more: this script must be launched by hand after your X-itools server has booted, and it will stay in the process table and it will perform its tasks each minute. This solution is temporary, during the time needed to code a daemonized version of this very specific X-Itools module.

Versions >= 0.5.97:

In this last case, the crontab is only responsible for the operations related to the database, in order to optimize it and to give you the guarantee that it is running as faster as possible.

To check if the crontab is installed or not, type as root user the following command:

#> crontab -l

If nothing appears, it just means the crontab must be installed. The crontab file of the X-Itools project is located at the base of the X-Itools directory. The file is named crontab.root. Install it like this:

#> crontab crontab.root

And check again. You should have the following result:

#> crontab -l 0 0 * * 0 psql -c "vacuum analyze;" -q -U postgres -d xitools 0 0 * * 1-6 psql -c "vacuum;" -q -U postgres -d xitools

It is not needed to run the script once the system has booted. The Check script is now a daemon, which is launched and stopped like any other daemon, by a startup script in the /etc/rc.d/init.d path.

WARNING !!! Be very carefull to not erase a previous existing crontab: you could cause damages to your system.

UPDATE AN EXISTING X-ITOOLS DATABASE TO A NEW DATABASE TEMPLATE:

The content of this section must be read and executed if a X-Itools server is already installed and you want to migrate to a new version. It concerns X-Itools versions from 0.5.40 and higher only. Don't do what is written here if you have an X-Itools server with a version number below 0.5.40.

To migrate your existing X-Itools database to the new schema, you can see that you have files named 0.5.40_to_0.5.41, 0.5.42_to_0.5.43 and so on.

Those files are database scripts which must be executed by postgresql to migrate the X-Itools database from one version to another.

For example, if you had previously the version 0.5.40 of the X-Itools and you just compiled version 0.5.41, you will have to type those commands under postgresql user to update your database without losing it or without installing a blank new template:

$> psql -e xitools < 0.5.40_to_0.5.41

and do it only once !!!

The case is a little bit different if you want to migrate from version 0.5.40 to version 0.5.43 for example. You will have to execute each script until you reach your new version number. It is very important to not forget one script among all, and to apply them in their version order. If a script doesn't exist for a specific X-Itools version, it just means there is no need to migrate the database, because the schema doesn't have to change.

For example, to go from version 0.5.40 to version 0.5.43, execute those commands under postgresql user:

$> psql -e xitools < 0.5.40_to_0.5.41 $> psql -e xitools < 0.5.42_to_0.5.43

Note that there isn't any script to go from 0.5.41 to 0.5.42.

Normally, you are now completely ready to run your new version of the X-Itools server.

RESTART APACHE:

Before to use the X-Itools server for the first time, apache must be restarted. As root on a RedHat:

#> /etc/rc.d/init.d/httpd restart

You can check that all virtual hosts are correcly configured and recognised by Apache by typing:

#> httpd -S

it should give you the list of all configured VirtualHosts. X-Itools VirtualHosts should be in this list.

Don't forget to update your DNS or your hosts file with the X-Itools FQDN (x-itools.mydomain.com here).

THE X-ITOOLS CONFIGURATION FILE:

WARNING : the versions of the X-Itools product from 0.5.97 included only will take care of the /etc/x-itools.conf configuration file. Before this, the different parameters configured in this configuration file must be configured directly in the source code, in the XItool_Biblio.H file.

It remains one last thing to do before to test the X-Itools product: we must configure the X-Itools configuration file, as below:

Versions 0.5.97 <= V <= 0.6.00:

# SQLTYPE: in the futur, maybe X-Itools will use other databases than # postgres, but for now this field must only contain postgres. # # possible values: postgres SQLTYPE=postgres # SQLSERVER: address of the SQL server. It can be either an IP address or # the fully qualified domain name. SQLSERVER=127.0.0.1 # SQLPORT: port on which the SQL server listen. SQLPORT=5432 # DBUSER is the name of the user used to connect to the database DBUSER=nobody # DBNAME is the name of the X-Itools database DBNAME=xitools # UNIXACCOUNTS must be set to one if xitools user authentication must be # done according the UNIX user accounts database (/etc/passwd) AND the # xitools user database. # # by default it is set to 0 UNIXACCOUNTS=0 # DEBUG must be set to 1 if you want that extensive information be # written in the /var/log/XItools.log file # # by default it is set to 0 DEBUG=0

Versions >= 0.6.05:

# SQLTYPE: in the futur, maybe X-Itools will use other databases than # postgres, but for now this field must only contain postgres. # # possible values: postgres SQLTYPE=postgres # SQLSERVER: address of the SQL server. It can be either an IP address or # the fully qualified domain name. SQLSERVER=127.0.0.1 # SQLPORT: port on which the SQL server listen. SQLPORT=5432 # DBUSER is the name of the user used to connect to the database DBUSER=nobody # DBNAME is the name of the X-Itools database DBNAME=xitools # UNIXACCOUNTS must be set to one if xitools user authentication must be # done according the UNIX user accounts database (/etc/passwd) AND the # xitools user database. # # by default it is set to 0 UNIXACCOUNTS=0 # DEBUG must be set to 1 if you want that extensive information be # written in the /var/log/XItools.log file # # by default it is set to 0 DEBUG=0 # PASSWORD_HTTPS must usually be set to 1. In this case, the X-Itools # password module can only be used accross an SSL session (HTTPS), # which seems to be logic for a password manager. So, if you try to # use this module accross a normal HTTP session, the module will only # display an error message, and no action will be possible. Set it to # 0 to cancel this security. PASSWORD_HTTPS=0

This is very simple. The file must be created in the /etc directory of your X-Itools server. Its name must be x-itools.conf. You can copy the one which is provided with the archive.

Basically, you will just have to set the SQLSERVER variable correctly. If the database of the X-Itools server is running on a remote server (not the same than the Apache server), replace the IP by the IP of this SQL server. If the X-Itools product and the SQL server are the same, put 127.0.0.1 as IP.

Now, you can open your browser and go on the X-Itools URL you have defined in the httpd.conf file, which should be something like: http://x-itools.mydomain.com

INSTALL THE X-ITOOLS STARTUP SCRIPT:

WARNING: This part is only intended for X-Itools version 0.5.97 or above. Because this is from this version only that the X-itools Check module is now a daemon, which must be started at boot time by a startup script. Here below is explained how to install this startup script.

At first, you have to know that the X-Itools Check module is responsible for various and very important operations.

This module is responsible for a lot of operations like send shared agenda notifications, do the necessary checks of machines across your network (for the ping module) to see if there are alive, perform operations on user holiday accounts, and so on...

You should see in the X-itools archive you have uncompressed, a file named XItools. This file is the startup script: it must be copied (or moved) in the /etc/rc.d/init.d directory. After this, we must put the x permission on it, which means that this script can be executed. Finally, we will use chkconfig to configure the system correctly, in order for this scripts to be started and stopped automatically in various run levels.

You just have to enter the commands below, to accomplish all this steps:

#> cp XItools /etc/rc.d/init.d #> chmod a+x /etc/rc.d/init.d/XItools #> chkconfig XItools on

And the next time you will reboot your system, the XItools Check module will be started automatically.

To control that this module is running without problems, we encourage you to set the DEBUG variable of the X-Itools configuration file to 1. By doing this, you will have the possibility to view the X-itools log file, which should be in /var/log. But don't forget to disable it after some time, otherwise your disk might be full (a lot of logs are generated, each minute).

It must be clear that the Check module must be running as long as your server is running.

You can use the following commands to start, stop, or restart the Check module (something you have to do if you modify the DEBUG variable of the configuration file):

#> /etc/rc.d/init.d/XItools stop #> /etc/rc.d/init.d/XItools start #> /etc/rc.d/init.d/XItools restart

And you can obtain information by this way:

#> /etc/rc.d/init.d/XItools status

Versions >= 0.6.10:

As of version 0.6.10 of the X-Itools server, this startup script automatically creates the xitools user account f it doesn't exist, as well as the ssh private and public keys which are needed by the X-Itools devices and password manager module, if they don't exist. So, before to use the X-Itools for the first time, this startup script must be started.

INSTALL THE X-ITOOLS FIREWALL LOGGER STARTUP SCRIPT:

WARNING: This part is only intended for X-Itools version 0.6.10 or above. Because this is from this version only that the X-itools Firewall Logger daemon exists, which must be started at boot time by a startup script. Here below is explained how to install this startup script.

At first, you have to know that the X-Itools Firewall Logger daemon is responsible for the management of Checkpoint connections. This daemon is necessary if you wish to use the corresponding X-Itools Firewall logger module. Otherwise, you don't need to install it.

This daemon need CheckPoint SDK libraries to run properly. It establish connections requested by the firewall logger module and receive and compute the logs from the CheckPoint management station in the X-itools database. After this, it is the responsibility of the X-Itools firewall module (different from, the daemon) to do various operations on the logs, and to display them.

You should see in the X-itools archive you have uncompressed, a file named XItools_CPLog. This file is the startup script: it must be copied (or moved) in the /etc/rc.d/init.d directory. After this, we must put the x permission on it, which means that this script can be executed. Finally, we will use chkconfig to configure the system correctly, in order for this scripts to be started and stopped automatically in various run levels.

You just have to enter the commands below, to accomplish all this steps:

#> cp XItools_CPLog /etc/rc.d/init.d #> chmod a+x /etc/rc.d/init.d/XItools_CPLog #> chkconfig XItools_CPLog on

And the next time you will reboot your system, the XItools Firewall Logger daemon will be started automatically.

To control that this module is running without problems, we encourage you to set the DEBUG variable of the X-Itools configuration file to 1. By doing this, you will have the possibility to view the X-itools log file, which should be in /var/log. But don't forget to disable it after some time, otherwise your disk might be full (a lot of logs are generated, each minute).

You can use the following commands to start, stop, or restart this daemon (something you have to do if you modify the DEBUG variable of the configuration file):

#> /etc/rc.d/init.d/XItools_CPLog stop #> /etc/rc.d/init.d/XItools_CPLog start #> /etc/rc.d/init.d/XItools_CPLog restart

And you can obtain information by this way:

#> /etc/rc.d/init.d/XItools_CPLog status

X-ITOOLS LOG FILES:

You can have those log files for X-Itools server > 0.5.99.

For debugging purposes, you can take a look at the X-Itools log files. For this, you have to enable the logs in the X-Itools configuration file, and the log files must exist in the /var/log directory.

To create them, just do the following:

#> touch /var/log/XItools.log #> touch /var/log/XItools_DB.log #> chmod a+w /var/log/XItools*

The log concerning the database can be enabled only on a script basis, and by changing a line of code in the source of each script, for now. So if you want them, it will be needed to recompile all.

Be very carefull because the database log file size can be more than 10 Mb in less than 1 minute !!!

DEVICES MANAGER AND SSHTerm CONFIGURATION:

This part can be applied to X-Itools version >=0.6.00 only.

The X-Itools devices manager module (previously named Password manager) can help you to connect on the various devices you store in its database with SSH protocol in its version 2 only, by using the SSHTerm applet. If you want to benefit of this new feature, there is some additionnal configuration to do, as explained below.

Note that the SSHTem applet is part of another sourceforge project named SSHTools, mainly programmed by Lee David Painter and Richard Pernavas, under GPL.

In order to use this applet, you will have to download it by clicking on the links above, to install it according the explanations given below, and you must have installed JRE 1.4.0 minimum to run it. It will not work with a previous version of the JRE or the JDK.

Note that according to our tests, this applet (version 0.1.4 at the time of the writting of this documentation) work really fine under IE or Netscape on Windows, but we experimented a lot of troubles with several versions of RedHat (8.0 and 9.0) with their corresponding version of mozilla, either with the last JRE from IBM or from SUN. Of course, it is not under our responsibility to develop this applet, so, please contact the corresponding team developement group for any questions relative to it.

To install the SSHTerm applet, download the *.tar.gz archive of it and uncompress it in a temporary directory. After this, move all *.jar files in the path where the X-Itools files are installed (where the X-Itools *.cgi files are installed). Finally, execute the following commands as root, in the X-Itools directory path:

#> chown nobody:nobody *.jar #> mkdir SSHTerm #> chown apache:apache SSHTerm

The SSHTerm directory is used by the X-Itools server to store the temporary configuration files needed each time you run the SSHTerm applet, each time you want to connect to a device.

Note that in version 0.6.00 of the X-Itools server, the files stored in this directory are not erased. So if you connect to some devices very often, you will have to clean this directory from time to time (use crontab for this). This very little drawback will be solved in the next X-itools release.

The first time you will run the SSHTerm applet, it will request you to be registered, because only registered applets can connect to external machines, except your local host (the host on which you run the SSHTerm applet). For this registration to be done correctly, accept for always, and you will not be disturb by this kind of registration for the next times.

TEST THE X-ITOOLS SERVER:

if all goes well, the X-Itools login page is loaded into your browser. But because it is the first time you use it, no users exist in the X-Itools database, except one: the xitools system user.

So, login with user xitools, and password xitools.

If your login is successfull (should be), you have now the X-Itools menu bar on your screen, in a separate window. You can go in the Administrator module to add and manage X-Itools domains and users and X-Itools server.

When you logon for the first time in the X-Itools server, a default domain exist, as well as another user, which is named 'me (rename me)'. At first, we strongly recommand you to modify the name of the default domain, and to modify the name of the default 'me' user. The me user is another administrator.

They are three levels of users in the XItools server: the Super Admin user (xitools user), the administrator users, and the unprivileged users. It can exist only one Super Admin user. You should never use the xitools super admin account, except for specific operations like domain creation and to assign an administrator user to the domains.

Versions >= 0.6.00:

The 'me' user is an administrator user for the first existing domain of the X-itools server. You should rename it with your name or the name of the real X-Itools domain administrator. At least one administrator is needed for each domain, in order to manage it. And the X-Itools server needs one administrator to run properly, because the first time you run X-itools, any account request which might be made by your users will be not interpreted correctly without at least one administrator. Furthemore, the administrator is set as default for the holidays manager of the domain.

After you 've configured correctly the 'me' administrator account, you can now let your users go to the X-Itools server login web page, and request an xitools account. All what you have to do is to accept (or refuse) those requests, and assign your users a X-Itools user profile.

Versions <= 0.5.99:

In X-Itools versions prior to 0.6.00, a default domain existed, but no default 'me' administrator account. It is a little bit tricky to create it properly, and the X-Itools server will not run properly until an administrator is not created for each domain. (to be completed...)

After you 've created correctly at least one administrator account, you can now let your users go to the X-Itools server login web page, and request an xitools account. All what you have to do is to accept (or refuse) those requests, and assign your users a X-Itools user profile.

Refer to the user documentation for further details (when it will exist ;-)
Enjoy ;-)