Instalación del servidor OCS Inventory NG 2.7 en CentOS 8

abril 19, 2020 De GabrielKfr

Instalación del servidor OCS Inventory NG 2.7 en CentOS 8

OCS Inventory NG es una herramienta que permite inventariar nuestro parque de equipos informáticos.

Permite recopilar mediante agentes que se instalan en los equipos clientes información referente al sistema operativo, software instalado, componentes de hardware, etc.

El servidor OCS Inventory NG está compuesta de los siguientes 4 componentes básicos:

Database server: Motor de base de datos que almacena la información del inventario.
Communication server: Servidor que gestiona la comunicación entre el motor de base de datos y agentes remotos mediante el protocolo HTTP.
Administration console: La consola de administración es la herramienta Web que nos permitirá administrar y consultar los datos recopilados por la herramienta.
Deployment server: Servidor para configurar la implementación de paquetes, que requiere el protocolo HTTPS para funcionar.

En este tutorial nos centraremos en los tres primeros componentes del servidor. La instalación y configuración de los agente remotos que recopilan y reportan la información al servidor serán tratados en un post independiente.

Configuración inicial del sistema operativo

Instalar el sistema operativo Linux CentOS 8 con una configuración de tipo servidor con entorno gráfico y comprobar que el servidor cuente con acceso a Internet, al menos temporalmente para instalar los paquetes requeridos más adelante para la instalación de la herramienta.
Ahora nos toca agregar como fuente de datos al contenido del DVD de instalación del sistema operativo como nuevo origen al gestor de paquetes YUM. Para ello nos dirigimos al directorio de configuración /etc/yum.repos.d, hacemos una copia del seguridad del archivo CentOS-Media.repo y lo editamos con los siguientes comandos:
```
[root@testsrv ~]# cd /etc/yum.repos.d/
[root@testsrv yum.repos.d]# cp CentOS-Media.repo CentOS-Media.repo.bkp
[root@testsrv yum.repos.d]# vim CentOS-Media.repo
```
Editamos el contenido dejándolo como sigue a continuación:
```
[c8-media-BaseOS]
name=CentOS-BaseOS-$releasever - Media
baseurl=file:///media/BaseOS
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
```
Ahora el gestor de paquetes YUM ya tiene configurado la nueva fuente de datos que apunta al directorio local /media. Para que le herramienta pueda instalar paquetes a partir de dicho medio es necesario que montemos el DVD en el mencionado directorio y eso lo logramos con el siguiente comando:
```
[root@testsrv yum.repos.d]# mount /dev/cdrom /media
```
Podemos verificar los paquetes disponibles ejecutando lo siguiente:
```
[root@testsrv yum.repos.d]# cd
[root@testsrv ~]# yum list available
```
Paramos y desactivamos el servicio packagekit para evitar que proceda a descargar actualizaciones en segundo plano sin nuestra autorización:
```
[root@testsrv ~]# systemctl stop packagekit
[root@testsrv ~]# systemctl disable packagekit
```

Para este tutorial voy a deshabilitar el módulo de seguridad SELinux y si esto pone en riesgo o no la seguridad del servidor queda bajo la responsabilidad de cada administrador. Para avanzar con esto procedemos a editar el archivo /etc/selinux/config,

[root@testsrv ~]# vim /etc/selinux/config

y le configuramos la directiva SELINUX con el valor disabled:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Una de las formas para que los cambios anteriores toman efecto es reiniciar el sistema operativo, sin embargo también podemos parar el SELinux en el entorno de ejecución actual con el siguiente comando:

[root@testsrv ~]# setenforce 0

Si queremos configurar un servidor ntp específico a partir de donde deseamos sincronizar la fecha y hora del servidor, podemos editar el archivo chrony.conf del directorio /etc:
```
[root@testsrv ~]# vim /etc/chrony.conf
```
Donde configuramos la sección server con nuestro servidor ntp preferido:
```
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 2.centos.pool.ntp.org iburst
server mi_servidor_ntp_local.gknet.local prefer
```
Finalmente tenemos que reiniciar el servicio chrony para que los cambios tomen efecto:
```
[root@testsrv ~]# systemctl restart chronyd
```
Para forzar la sincronización de la hora del equipo con el servidor ntp de forma inmediata podemos ejecutar el siguiente comando:
```
[root@testsrv ~]# ntpdate -u mi_servidor_ntp_local.gknet.local
```
Para ver en tiempo real la hora en el servidor, incluyendo los segundos, podemos ejecutar el comando watch. Para salir hay que presionar las teclas CTRL+C.
```
[root@testsrv ~]# watch -n 1 date

Every 1,0s: date            Mon Jul  1 11:35:04 2019

lun jul  1 11:35:04 -04 2019
```

Instalación de servidor Apache:

Tenemos que instalar el servidor Apache.

[root@testsrv ~]# yum install httpd
[root@testsrv ~]# yum install mod_ssl openssl

Para activar el servicio SSL en Apache primero creamos el directorio /etc/httpd/ssl para albergar certificados:
```
[root@testsrv ~]# mkdir /etc/httpd/ssl
```

Luego pasamos a ejecutar el comando openssl para generar una nueva llave para nuestro servidor Apache. Al ejecutar el comando nos solicitará que vayamos cargando información para el certificado:

[root@testsrv ~]# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/httpd/ssl/apache.key -out /etc/httpd/ssl/apache.crt
Generating a 2048 bit RSA private key
...............+++
...................+++
writing new private key to '/etc/httpd/ssl/apache.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:PY
State or Province Name (full name) []:It
Locality Name (eg, city) [Default City]:HO
Organization Name (eg, company) [Default Company Ltd]:Gabriel-Corp.
Organizational Unit Name (eg, section) []:Informatica
Common Name (eg, your name or your server's hostname) []:testsrv.gknet.local
Email Address []:contacto(ARROBA)tormentadebits.com
[root@testsrv ~]#

Como estamos usando OpenSSL, se recomienda crear una fuerte clave Diffie-Hellman:
```
[root@testsrv ~]# openssl dhparam -out /etc/httpd/ssl/dhparam.pem 2048
```
El hash code generado por el comando anterior lo tenemos que agregar al certificado apache.crt generado más arriba:
```
[root@testsrv ~]# cat /etc/httpd/ssl/dhparam.pem | tee -a /etc/httpd/ssl/apache.crt
```

Luego editamos el archivo de configuración /etc/httpd/conf.d/ssl.conf:

[root@testsrv ~]# vim /etc/httpd/conf.d/ssl.conf

Y nos ubicamos donde se encuentran las directivas #DocumentRoot y #ServerName:

# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443

Descomentamos ambas y a la directiva ServerName le asignamos el nombre de servidor que corresponde, en este ejemplo testsrv:

# General setup for the virtual host, inherited from global configuration
DocumentRoot "/var/www/html"
ServerName testsrv:443

Luego pasamos a configurar la directiva SSLCertificateFile a la que le asignamos la ruta al nuevo certificado generado más arriba:

#   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 new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/httpd/ssl/apache.crt

Y finalmente también configuramos la directiva SSLCertificateKeyFile a la que le asignamos la ruta a la nueva llave generada más arriba:

#   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/ssl/apache.key

Guardamos los cambios y salimos del archivo de configuración.

Comprobamos que la configuración de Apache esté correcta con el siguiente comando:
```
[root@testsrv ~]# apachectl configtest
Syntax OK
[root@testsrv ~]#
```

Terminada la configuración de nuestro servidor Apache, tenemos que habilitar en el Firewall los puertos http y https para que el servidor Apache sea accesible desde equipos remotos.

[root@testsrv ~]# firewall-cmd --get-active-zones
libvirt
  interfaces: virbr0
public
  interfaces: enp0s3
[root@testsrv ~]# firewall-cmd --zone=public --list-services
cockpit dhcpv6-client ssh
[root@testsrv ~]# firewall-cmd --zone=public --permanent --add-service=http
success
[root@testsrv ~]# firewall-cmd --zone=public --permanent --add-service=https
success
[root@testsrv ~]# systemctl restart firewalld
[root@testsrv ~]# firewall-cmd --zone=public --list-services
cockpit dhcpv6-client http https ssh
[root@testsrv ~]#

Habilitamos y arrancamos el servidor de Apache:

[root@testsrv ~]# systemctl enable httpd
[root@testsrv ~]# systemctl start httpd

Y finalmente probamos si podemos acceder al servicio Apache del servidor introduciendo la URL que corresponde en el navegador de otro equipo de nuestra red local:
```
http://ip_del_servidor
```

Configuración de MariaDB

Tenemos que instalar el motor de base de datos MariaDB.
```
[root@testsrv ~]# yum install mariadb mariadb-server
```
Abrimos el archivo de configuración del motor de base de datos my.cnf:
```
[root@testsrv ~]# vim /etc/my.cnf.d/mariadb-server.cnf
```
Y agregamos a la sección de configuración [mysqld] la siguiente directiva:
```
# Habilita paquetes de hasta 20 MB.
max_allowed_packet=20M
```

Habilitamos y arrancamos el servidor de MariaDB:

[root@testsrv ~]# systemctl enable mariadb
[root@testsrv ~]# systemctl start mariadb

Nos conectamos al motor de base de datos con el usuario root y le asignamos una contraseña inicial:

[root@testsrv ~]# mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.60-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('yourpassword');
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]>

Sin desconectarnos pasamos a crear la base de datos que será utilizada desde el mismo servidor:
```
MariaDB [(none)]> CREATE DATABASE ocsweb;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]>
```

Creamos un nuevo usuario denominado ocs y le asignamos los privilegios necesarios para acceder a la base de datos ocsweb creada en el punto anterior.

MariaDB [(none)]> CREATE USER 'ocs'@'localhost' IDENTIFIED BY 'ocspass';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> GRANT ALL PRIVILEGES ON ocsweb.* TO 'ocs'@'localhost' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]>

Finalmente ejecutamos la siguiente directiva para aplicar los parámetros y salimos del intérprete de comandos de MariaDB ejecutando el comando exit:
```
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit
Bye
[root@testsrv ~]#
```

Por último también es importante ejecutar la directiva mysql_secure_installation y seguir las instrucciones para realizar configuraciones de seguridad adicionales al motor de base de datos. A continuación dejo resaltado en rojo las interacciones realizadas con la herramienta para definir ciertas configuraciones de seguridad:

[root@testsrv ~]# mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): 
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

You already have a root password set, so you can safely answer 'n'.

Change the root password? [Y/n] N
 ... skipping.

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!
[root@testsrv ~]#

Instalación del servidor OCS Inventory desde RPM

Instalamos y activamos el repositorio EPEL (Extra Packages for Enterprise Linux) requerido para suplir algunas dependencias.
```
[root@testsrv yum.repos.d]# yum --enablerepo=extras install epel-release
```

Luego procedemos a descargar e instalar los repositorios ocsinventory-release-latest y remi-release-8 que contienen paquetes requeridos para instalar la nueva herramienta en pasos posteriores:

[root@testsrv ~]# wget https://rpm.ocsinventory-ng.org/ocsinventory-release-latest.el8.ocs.noarch.rpm
[root@testsrv ~]# wget https://rpms.remirepo.net/enterprise/remi-release-8.rpm
[root@testsrv ~]# yum install ocsinventory-release-latest.el8.ocs.noarch.rpm remi-release-8.rpm

Para la instalación del servidor OCS Inventory debemos ejecutar la siguiente secuencia de comandos:

[root@testsrv ~]# dnf install yum-utils
[root@testsrv ~]# yum-config-manager --enable remi
[root@testsrv ~]# dnf module reset php
[root@testsrv ~]# dnf module install php:remi-7.3
[root@testsrv ~]# dnf install --enablerepo=PowerTools ocsinventory

Luego editamos el archivo ocsinventory-server.conf del directorio /etc/httpd/conf.d:
```
[root@testsrv ~]# vim /etc/httpd/conf.d/ocsinventory-server.conf
```
Y una vez abierto el archivo buscamos la siguiente directiva:
```
# Password for user
  PerlSetVar OCS_DB_PWD ocs
```
Y le asignamos la misma contraseña que le asignamos al usuario osc del motor de base de datos MariaDB:
```
# Password for user
  PerlSetVar OCS_DB_PWD ocspass
```
La misma configuración también tenemos que realizar en el archivo ocsinventory-restapi.conf:
```
[root@testsrv ~]# vim /etc/httpd/conf.d/ocsinventory-restapi.conf
```

Si queremos evitar que aparezca el sitio web de bienvenida de Apache al acceder al documento root (http://ip_o_nombre_dominio_servidor), podemos hacer que automáticamente se redirija al sub-directorio ocsreports (http://ip_o_nombre_dominio_servidor/ocsreports) editando el archivo welcome.conf del directorio /etc/httpd/conf.d:

[root@testsrv conf.d]# vim /etc/httpd/conf.d/welcome.conf

Y luego agregarle antes de todo la directiva RedirectMatch de la siguiente manera:

#
# This configuration file enables the default "Welcome" page if there
# is no default index page present for the root URL.  To disable the
# Welcome page, comment out all the lines below.
#
# NOTE: if this file is removed, it will be restored on upgrades.
#
RedirectMatch ^/$ /ocsreports/

<LocationMatch "^/+$">
    Options -Indexes
    ErrorDocument 403 /.noindex.html
</LocationMatch>

<Directory /usr/share/httpd/noindex>
    AllowOverride None
    Require all granted
</Directory>

Alias /.noindex.html /usr/share/httpd/noindex/index.html
Alias /noindex/css/bootstrap.min.css /usr/share/httpd/noindex/css/bootstrap.min.css
Alias /noindex/css/open-sans.css /usr/share/httpd/noindex/css/open-sans.css
Alias /images/apache_pb.gif /usr/share/httpd/noindex/images/apache_pb.gif
Alias /images/poweredby.png /usr/share/httpd/noindex/images/poweredby.png

A continuación necesitamos editar el archivo php.ini ubicado en el directorio /etc para realizar una serie de configuraciones:

[root@testsrv ~]# vim /etc/php.ini

Y una vez abierto buscamos y modificamos el valor de la directiva post_max_size como sigue:

; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
;post_max_size = 8M
post_max_size = 201M

y también de la directiva upload_max_filesize:

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
;upload_max_filesize = 2M
upload_max_filesize = 200M

Procedemos a activar e iniciar el servicio requerido php-fpm:

[root@testsrv ~]# systemctl enable php-fpm
[root@testsrv ~]# systemctl start php-fpm

El siguiente paso consiste en reiniciar el servidor Apache:
```
[root@testsrv ~]# systemctl restart httpd
```
Si todo ha funcionado como corresponde desde nuestro navegador Web favorito colocamos una URL similar a la que sigue (reemplazar el nombre del servidor testsrv por el suyo o bien la dirección IP que hayan usado para el mismo):
```
https://testsrv/ocsreports/
```
Que debería lanzar la siguiente interfaz de usuario para avanzar con la configuración del servidor OCS Inventory. Como se puede observar, se tiene que introducir los datos de conexión del motor de base de datos:

Una vez cargado los datos que corresponden en cada campo procedemos a presionar el botón Send.
A continuación el asistente web de configuración nos indicará que la instalación ha concluido y que hagamos clic en el enlace asociado al texto "Click here to enter OCS-NG GUI".
A continuación el asistente web nos informa que se puede actualizar el contenido de la base de datos de una versión anterior a la versión más reciente. Para avanzar presionamos el botón Perform the update:
Luego del paso anterior el asistente nos confirmará que la actualización fue realizada exitosamente y que hagamos clic nuevamente en el link "Click here to enter OCS-NG GUI" para acceder a la consola de administración de la herramienta.
En el siguiente paso ya estamos en la interfaz de conexión de la consola de administración de OCS Inventory. Debemos especificar el usuario admin que es el administrador de la herramienta y cuya contraseña por defecto también es la palabra admin:
Autorizada la conexión, la herramienta nos llevará al dashboard donde se muestra una alerta de seguridad que nos informa que el archivo install.php sigue existiendo en el directorio ocsreports:

La alerta anterior se debe a que alguien podría volver a ejecutar el archivo install.php especificando la URL completa. Para evitar eso nos dirigimos al directorio /usr/share/ocsinventory-reports/ocsreports desde donde movemos el archivo al directorio /etc/ocsinventory y de paso lo renombramos:
```
[root@testsrv ~]# cd /usr/share/ocsinventory-reports/ocsreports
[root@testsrv ocsreports]# mv install.php /etc/ocsinventory/install.php.bkp
```
Si volvemos a refrescar nuestro navegador podremos observar que el mensaje de advertencia desaparece, dejándonos la consola de administración lista para ser utilizada.

Como no dispongo de mucho tiempo no daré ninguna introducción sobre las opciones de configuración y utilización que ofrece la consola de administración de la herramienta OCS Inventory NG. Además, aún no tengo instalado un agente remoto que suministre información al servidor que se pueda mostrar de ejemplo.

Adecuación del servidor para distribución de Agentes

Es necesario realizar algunas configuraciones para adecuar nuestro servidor OCS Inventory para que pueda servir de plataforma de descarga de los agentes OCS a través de distintos protocolos y así facilitar su instalación en los equipos que deseamos inventariar.

Lo primero que tenemos que hacer es crear un directorio en donde podamos ubicar los agentes para su descarga remota, para ello creamos el siguiente directorio:
```
[root@testsrv ~]# mkdir -p /srv/ocsinventory/agents
```
Dentro del directorio /srv/ocsinventory/agents recomendamos crear varios directorios para los agentes cuyo configuración y versión dependen para el sistema operativo para el cual fueron preparados. En este ejemplo estaremos abarcando la instalación de agentes para los sistemas operativos Windows y openSUSE:
```
[root@testsrv ~]# mkdir /srv/ocsinventory/agents/Windows
[root@testsrv ~]# mkdir /srv/ocsinventory/agents/openSUSE
```
Finalmente asignamos los permisos correspondientes a la estructura del directorio /srv/ocsinventory:
```
[root@testsrv ~]# chown -Rf apache:root /srv/ocsinventory
```

El siguiente paso consistirá en configurar el servicio Apache para permitir que los agentes puedan ser descargados remotamente a través del protocolo http. Para ello editamos el archivo de configuración ocsinventory-reports.conf del directorio /etc/httpd/conf.d:

[root@testsrv ~]# vim /etc/httpd/conf.d/ocsinventory-reports.conf

Y al final del archivo le agregamos la siguiente configuración:

# Path para descargas de instaladores de agentes.
Alias /ocsagents /srv/ocsinventory/agents
<Directory /srv/ocsinventory/agents>
   Options Indexes FollowSymLinks
   AllowOverride All
   Order allow,deny
   Allow from all
   Require all granted
</Directory>

Como medida de seguridad adicional, también procederemos a configurar un archivo de autenticación htpasswd en el servidor OCS Inventory para que exija a los agentes remotos autenticarse con un usuario y contraseña antes de que puedan enviar información alguna. Para ello comenzamos por editar el archivo ocsinventory-server.conf del directorio /etc/httpd/conf.d:

[root@testsrv ~]# vim /etc/httpd/conf.d/ocsinventory-server.conf

Y en la sección que sigue a continuación descomentamos las líneas correspondientes a las directivas AuthType, AuthName, AuthUserFile y Require (resaltadas en amarillo), y nos aseguramos de comentar la línea relacionada a la directiva Require all granted (resaltada en rojo) para evitar que el servidor Apache tome ésta directiva como la principal en vez de la directiva Require valid-user:

  # Engine apache settings
  # "Virtual" directory for handling OCS Inventory NG agents communications
  # Be careful, do not create such directory into your web server root document !
  <Location /ocsinventory>
    <IfModule mod_authz_core.c>
      # Apache 2.4
      #Require all granted
        </IfModule>
        <IfModule !mod_authz_core.c>
      # Apache 2.2
          order deny,allow
          allow from all
        </IfModule>
        # If you protect this area you have to deal with http_auth_* agent's parameters
        AuthType Basic
        AuthName "OCS Inventory agent area"
        AuthUserFile "/etc/ocsinventory/ocsinventory-server/htpasswd"
        Require valid-user
        SetHandler perl-script
        PerlHandler Apache::Ocsinventory
  </Location>

Con el siguiente comando actualizamos el archivo htpasswd del directorio /etc/ocsinventory/ocsinventory-server (o bien lo crearemos si no existe) con el nombre del usuario genérico "ocsagentes" y su correspondiente contraseña de ejemplo "passwagentes" que deberán usar todos los agentes para conectarse al servidor:

[root@testsrv ~]# htpasswd -c /etc/ocsinventory/ocsinventory-server/htpasswd ocsagentes
New password: 
Re-type new password: 
Adding password for user ocsagentes
[root@testsrv ~]#b

Finalmente verificamos la configuración del servicio Apache y lo reiniciamos para que los cambios tomen efecto:

[root@testsrv ~]# apachectl configtest
[root@testsrv ~]# systemctl restart httpd

Otro medio para facilitar la descarga remota de los agentes, especialmente en equipos que tienen instalado el sistema operativo Windows, es compartir el directorio /srv/ocsinventory/agents a través de Samba. Comenzamos por instalar las dependencias requeridas para hacer funcionar el servicio Samba:

[root@testsrv ~]# yum install samba samba-client samba-common

A continuación habilitamos en el Firewall los puertos que utiliza el servicio Samba:

[root@testsrv ~]# firewall-cmd --permanent --zone=public --add-service=samba
[root@testsrv ~]# firewall-cmd --reload

A continuación editamos el archivo de configuración de Samba smb.conf ubicado en el directorio /etc/samba:

[root@testsrv ~]# vim /etc/samba/smb.conf

En el cual configuramos las directivas workgroup y netbios name, comentamos con puntos y comas las secciones homes, printers y print$, y al final del archivo agregamos la sección ocsagents:

# See smb.conf.example for a more detailed config file or
# read the smb.conf manpage.
# Run 'testparm' to verify the config is correct after
# you modified it.

[global]
        workgroup = gknet.local
        server string = Samba Server %v
        netbios name = testsrv
        security = user
        map to guest = bad user
        passdb backend = tdbsam

        printing = cups
        printcap name = cups
        load printers = yes
        cups options = raw

;[homes]
;       comment = Home Directories
;       valid users = %S, %D%w%S
;       browseable = No
;       read only = No
;       inherit acls = Yes

;[printers]
;       comment = All Printers
;       path = /var/tmp
;       printable = Yes
;       create mask = 0600
;       browseable = No

;[print$]
;       comment = Printer Drivers
;       path = /var/lib/samba/drivers
;       write list = @printadmin root
;       force group = @printadmin
;       create mask = 0664
;       directory mask = 0775

[ocsagents]
       comment = OCS Inventory Agents Repository
       path = /srv/ocsinventory/agents
       browseable = yes
       writable = no
       guest ok = yes

Luego ya podemos habilitar e iniciar los servicios Samba smb y nmb con los siguientes comandos:

[root@testsrv ~]# systemctl enable smb.service
[root@testsrv ~]# systemctl enable nmb.service
[root@testsrv ~]# systemctl start smb.service
[root@testsrv ~]# systemctl start nmb.service

Con el paso anterior hemos finalizado la adecuación de nuestro servidor OCS Inventory para que funcione como plataforma de distribución de los instaladores de los agentes OCS y mejorar la seguridad de las conexiones de los agentes.

Realización de copias de seguridad

En principio necesitamos definir un directorio en donde ubicar las copias de seguridad realizadas, en mi caso voy a crear una estructura de directorios backups/ocsinventory en el directorio raíz.
```
[root@testsrv ~]# mkdir -p /backups/ocsinventory
```

A continuación creamos el archivo bkpocsinventory.sh en el directorio /backups/ocsinventory que contendrá el script que realizará la copia de seguridad, además se le asignará los permisos correspondientes y luego lo editamos:

[root@testsrv ~]# touch /backups/ocsinventory/bkpocsinventory.sh
[root@testsrv ~]# chmod 750 /backups/ocsinventory/bkpocsinventory.sh
[root@testsrv ~]# vim /backups/ocsinventory/bkpocsinventory.sh

y le agregamos el siguiente script bash:

#!/bin/bash
# Realiza una copia de seguridad completa de la herramienta OCS Inventory.
DIA=`date +"%Y%m%d"`
HORA=`date +"%H%M"`
BACKUP_PATH=/backups/ocsinventory
 
# -- OCS
OCS_REPORTS_WEB=/usr/share/ocsinventory-reports
OCS_REPORTS_TOOLS=/var/lib/ocsinventory-reports
OCS_AGENTS_INSTALLERS=/srv/ocsinventory/agents
OCS_DB_NAME=ocsweb
OCS_DB_USER=ocs
OCS_DB_PASS=ocspass
OCS_DB_BACKUP=$OCS_REPORTS_WEB/ocsinventory-db-bkp.sql
OCS_APACHE_CONF_PATH=/etc/httpd/conf.d
OCS_BACKUP_NAME="ocsinventory-bkp-"$DIA"_"$HORA".tgz"
OCS_BACKUP_LIVE_TIME=30

# -- PATRON LIMPIEZA
PATRON_BKP_DIARIO=ocsinventory-bkp-*.tgz
 
# Se procede a exportar la base de datos de OCS Inventory.
echo
echo "-->BACKUP DE LA BASE DE DATOS DE OCS INVENTORY"
echo "===================================================================="
echo "Exportando la base de datos de OCS Inventory a partir de MySQL. Aguarde un momento..."
mysqldump -v -u $OCS_DB_USER -p$OCS_DB_PASS --database $OCS_DB_NAME > $OCS_DB_BACKUP
echo "Fin del proceso de exportacion."
echo
 
# Se generan los archivos con todas las copias de seguridad para ser enviadas a una unidad de cinta.
echo
echo "-->CREANDO FULL BACKUP DE OCS INVENTORY"
echo "===================================================================="
tar -czf $BACKUP_PATH/$OCS_BACKUP_NAME $OCS_REPORTS_WEB $OCS_REPORTS_TOOLS $OCS_AGENTS_INSTALLERS $OCS_APACHE_CONF_PATH/ocsinventory-*
 
# Para no llenar el disco duro con backups, se eliminan todos los backups diarios pasados la cantidad
# de dias especificados en la variable OCS_BACKUP_LIVE_TIME.
echo
echo "-->LIMPIEZA DE BACKUPS ANTIGUOS"
echo "===================================================================="
find $BACKUP_PATH/$PATRON_BKP_DIARIO -mtime +$OCS_BACKUP_LIVE_TIME -exec rm {} \;

# Mensaje de finalizacion:
echo
echo "-->FIN DE BACKUP"
echo

En este punto ya podemos probar la ejecución del script de la siguiente manera:

[root@testsrv ~]# /backups/ocsinventory/bkpocsinventory.sh
 
-->BACKUP DE LA BASE DE DATOS DE OCS INVENTORY 
==================================================================== 
Exportando la base de datos de OCS Inventory a partir de MySQL. Aguarde un momento... 
Info: Using unique option prefix 'database' is error-prone and can break in the future. Please use the full name 
'databases' instead. 
-- Connecting to localhost... 
-- Retrieving table structure for table accesslog... 
-- Sending SELECT query... 
-- Retrieving rows... 
....
....
-- Retrieving rows... 
-- Disconnecting from localhost... 
Fin del proceso de exportacion. 

-->CREANDO FULL BACKUP DE OCS INVENTORY 
==================================================================== 
tar: Eliminando la `/' inicial de los nombres 
tar: Eliminando la `/' inicial de los objetivos de los enlaces 

-->LIMPIEZA DE BACKUPS ANTIGUOS 
==================================================================== 

-->FIN DE BACKUP 

[root@testsrv ~]#

Y al finalizar ya podríamos ver la copia de seguridad generada en el directorio /backups/ocsinventory:

[root@testsrv ~]# ls -l /backups/ocsinventory
total 2732
-rwxr-x---. 1 root root    1749 abr 19 01:42 bkpocsinventory.sh
-rw-r--r--. 1 root root 2793315 abr 19 01:43 ocsinventory-bkp-20200419_0143.tgz
[root@testsrv ~]#

Para programar la ejecución periódica del script debemos agregar una tarea programada. Para ello creamos el archivo ocsinventory en el directorio /etc/cron.d:
```
[root@testsrv ~]# touch /etc/cron.d/ocsinventory
[root@testsrv ~]# vim /etc/cron.d/ocsinventory
```
Para luego agregarle el siguiente contenido:
```
# Backup OCS Inventory
30 22 * * * root /backups/ocsinventory/bkpocsinventory.sh > /backups/ocsinventory/bkpocsinventory.log 2>&1
```
Finalmente reiniciamos el servicio cron para que la tarea programada sea funcional.
```
[root@testsrv ~]# systemctl restart crond
```
Y hasta aquí va el artículo de hoy, veremos cuando sale el artículo sobre la instalación de los agentes.

Referencias y enlaces útiles:

ACTUALIZACIÓN 28/06/2020: Se ha agregado la nueva sección "Adecuación del servidor para distribución de Agentes" y se ha modificado de forma menor el script de backup para incorporar la ruta al repositorio de agentes /srv/ocsinventory/agents.

Comentarios

Anónimo22 de mayo de 2020, 7:29
Muy interesante, justo ayer implemente un servidor como tu indicas. Lo que hice diferente fue crear un nuevo user superadministrador, borrar el que hay por defecto (admin), crear un nuevo usuario en la base de datos mariadb con permisos totales a la bd ocsweb y cambiar los archivos que conectan con la bd.
Ahora me encuentro con el problema que al instalar desde los rpm del repositorio no consigo que se instalen los plug-in y parece que el rpm crea la carpeta extensions en otro sitio diferente a la que el sistema espera. asi que o encuentro donde estan definidas esta rutas o esperar a un nuevo parche.

Genial tu articulo.
ResponderEliminar
Respuestas
Unknown21 de julio de 2020, 13:10
Muy buen tutorial, gracias! Rescate algunas cosas que habia omitido
ResponderEliminar
Respuestas
Cesar30 de septiembre de 2021, 14:42
Buen dia queria consultar al cargarme la página OCS-NG Inventory Installation
Me pide que llene los campos de la BBDD y los campos SSL
Me parece que no me deja continuar por que falta ingresar los campos:
SSL Key path
SSL Certificat path
Me podrian decir como llenar esos campos?
ResponderEliminar
Respuestas

Añadir comentario

Buscar este blog

Tormenta de Bits

Instalación del servidor OCS Inventory NG 2.7 en CentOS 8

Configuración inicial del sistema operativo

Instalación de servidor Apache:

Configuración de MariaDB

Instalación del servidor OCS Inventory desde RPM

Adecuación del servidor para distribución de Agentes

Realización de copias de seguridad

Referencias y enlaces útiles:

Comentarios

Publicar un comentario