Configuración

Forseti ERP
< Regresar
Imprimir
Publicado
Actualizado
Porforseti.network

Configurando PostgreSQL

Lo primero que necesitamos hacer es cambiar la contraseña del usuario postgres. Este fue generado por la instalación de PostgreSQL y lo cambiaremos ejecutando el comando psql:

sudo -u postgres psql postgres

Establecemos la contraseña para el rol de base de datos postgres usando el comando:

postgres=# \password

Proporcionamos la contraseña y su confirmación. El texto de estas, permanecerá oculto en la terminal por razones de seguridad. Una vez establecida, salimos:

postgres=# \q

Ahora creamos el rol forseti que es indispensable para nuestro servidor Forseti ERP. Nos pedirá una contraseña y su confirmación.

sudo -u postgres createuser -s -d -r -E -P forseti
IMPORTANTE: Es indispensable llamar a rol "forseti" con minúsculas para que nuestro servidor pueda trabajar bien, de lo contrario, la configuración fallará y no se podrá iniciar.

El archivo de configuración pg_hba.conf contiene los parámetros de conexión al servidor y se verá probablemente de la siguiente manera:

# PostgreSQL Client Authentication Configuration File
# ===================================================
#
# Refer to the "Client Authentication" section in the PostgreSQL
....
....
....
....
local   all             all                             peer
host    all             all             127.0.0.1/32    scram-sha-256
host    all             all             ::1/128         scram-sha-256

Aquí lo que nos interesa es la linea host all all 127.0.0.1/32 scram-sha-256 que nos indica que podremos conectarnos a todas las bases de datos que se vayan creando con Forseti ERP desde la aplicación instalada en este mismo ordenador, a través del protocolo de Internet con una seguridad scram-sha-256. Para poder accesar al archivo pg_hba.conf usamos nano de la siguiente manera:

sudo nano /etc/postgresql/14/main/pg_hba.conf

Debemos sustituir 14 por la versión de nuestro PostgreSQL. Si no estamos seguros de la versión podemos usar:

dpkg -s postgresql

Si deseas entender mejor como funciona el archivo de configuración, puedes verificar la documentación de PostgreSQL en su portal https://www.postgresql.org. Hasta aquí, la configuración de PostgreSQL ha finalizado y se puede proceder a la configuración del servidor web Forseti ERP en la siguiente sección.

Configurando Forseti ERP

El directorio /usr/local/forseti donde quedó instalado Forseti ERP contiene los siguientes subdirectorios: act, bin, ftl, emp, log, pac y req.

  • act: Este subdirectorio contendrá las actualizaciones descargadas del servicio.
  • bin: De suma importancia, contiene archivos de las propiedades del servidor. Estos son:
    • FORSETI_INIT.dump; Es el código fuente de inicialización del servidor Forseti ERP. Básicamente, contiene la estructura de la base de datos principal “FORSETI_ADMIN”.
    • FORSETI_INIBD.dump; Es el código fuente de inicialización para cada empresa que se de de alta en el sistema.
    • .forseti_inipryct; Es el código fuente de inicialización para cada sistema de desarrollo, como lo son el desarrollo de reportes específicos que se lleguen a dar de alta para cada empresa instalada en el sistema.
    • .forseti_auto; Este contiene las propiedades para la automatización de procesos del servidor como respaldos, actualizaciones y actualizaciones de saldos del CEF.
    • .forseti_conf; Maneja la configuración para la conexión al servidor de bases de datos PostgreSQL y otras configuraciones como la manera en que se manejan los mensajes del sistema y el desarrollo sobre Forseti ERP.
    • .forseti_pac; Cuando este servidor Forseti ERP brinde el servicio de timbrado por medio de su servicio web JPacConn, utilizará este archivo para manejar la configuración de conexión al servidor al servicio de timbrado de comprobantes fiscales digitales.
    • .forseti_smtp; Cuando este servidor Forseti ERP brinde el servicio de envío automático de correo electrónico por medio de su servicio web JSmtpConn, utilizará este archivo para manejar la configuración de conexión al servidor SMTP.
    • .forseti_awss3; Cuando este servidor Forseti ERP brinde el servicio de alojamiento de archivos en la nube por medio de su servicio web JAwsS3Conn, utilizará este archivo para manejar la configuración de conexión al buket de Amazon S3.
  • emp: Dentro de emp se creará un directorio específico para los archivos importantes de cada empresa dada de alta en el servidor. Estos pueden ser plantillas para correo electrónico automático, archivos no aptos para guardarse dentro de PostgreSQL, etc.
  • log: Este directorio está destinado al registro de sucesos administrativos del servidor Forseti ERP. Aquí se guardará el registro de la creación y eliminación de empresas, creación y restauración de respaldos, actualización de saldos del CEF, actualización del servidor Forseti ERP, etc.
  • pac: Cuando este servidor Forseti ERP brinde el servicio de timbrado de comprobantes fiscales digitales por medio de su servicio web JPacConn, utilizará este directorio para controlar los archivos CFD y CFDI.
  • req: Contiene archivos de recursos que utiliza Forseti ERP para realizar algunas tareas.
  • respaldos: Es un directorio vacío que se utilizará como directorio por defecto para los respaldos del servidor. El directorio de respaldos se puede cambiar y no es estrictamente necesario utilizar este.

Ahora que ya conocemos ligeramente la estructura del servidor procedemos a iniciarlo. En la barra de dirección del navegador tecleamos lo siguiente:

http://localhost:8080/forseti/saf/Registro

Ingresamos la IP 127.0.0.1 en el espacio de Dirección IP del servidor PostgreSQL, En Puerto del servidor PostgreSQL, el puerto de comunicación por lo general será 5432 a menos que se agregue un cluster específico para Forseti ERP y para el espacio Contraseña del usuario forseti, ingresamos la contraseña que acabamos de crear. Presionamos Iniciar Servidor, esperamos unos minutos y listo. Esta acción configura la base de datos principal FORSETI_ADMIN. Ahora reiniciamos tomcat con:

sudo service tomcat9 restart
IMPORTANTE: Es indispensable reiniciar tomcat para que podamos tener nuestro servidor funcionando, de lo contrario, al volver a cargar el registro con http://localhost:8080/forseti/saf/Registro nos volverá a presentar el formulario de inicio anterior en lugar del formulario de registro para el SAF, además, nos arrojará un error de que ya existe la base de datos FORSETI_ADMIN en caso de volver a intentar iniciar el servidor.

Ahora ya podemos iniciar sesión en el SAF como usuario fsi y contraseña fsi.

NOTA: Si se instaló el servidor Forseti ERP en un sistema operativo Ubuntu Server o cualquier otro sistema sin interfaz gráfica, podemos ingresar desde un navegador instalado en cualquier otra máquina sustituyendo la parte de la dirección localhost por la IP del servidor Forseti ERP.

Suponiendo que ésta fuera la 192.168.2.4, la dirección completa tendría que quedar como sigue:

http://192.168.2.4:8080/forseti/saf/Registro

El siguiente paso, es iniciar sesión en el SAF como fsi con contraseña fsi y una vez dentro ingresar al módulo de “Servidor y Empresas” del menú Administración. En este módulo, entramos a “propiedades del servidor” y vamos a cambiar la contraseña de fsi además de que vamos a configurar la ruta de la instalación de Tomcat para establecerla como /var/lib/tomcat9. Si todo va bien damos Aceptar.

IMPORTANTE: Para distribuciones diferentes a la familia Ubuntu, la ruta de instalación de tomcat puede cambiar.

El servicio tomcat utiliza por default el puerto 8080 para escuchar peticiones http. Ya que estas peticiones no viajan cifradas por la red, solo son aceptables para implementaciones en una sola máquina donde no existe una red de área local (LAN) y se usan para trabajar desde la misma máquina. Si estás implementando un servidor para dar servicio centralizado desde una implantación En Sitio, lo más conveniente es hacer que la información viaje cifrada para que otros no puedan verla en caso de que la intercepten por la red y así evitar un ataque de man-in-the-middle. Para esto, debemos generar un certificado auto-firmado y configurar tomcat para que escuche en el puerto 8443 por peticiones seguras https.

Para lograr esto, primero configuramos tomcat para aceptar la instalación desde el SAF, esto solo se debe de hacer en caso de que Forseti ERP sea la única aplicación que contendrá tomcat, de lo contrario, se tendrá que cambiar el archivo de manera manual:

sudo chgrp tomcat /var/lib/tomcat9/conf/server.xml
sudo chmod 660 /var/lib/tomcat9/conf/server.xml

Estando dentro del SAF, nos vamos al módulo de “Control SSL” del menú de Administración y ahí ejecutamos el proceso “Certificado Auto-Firmado”, llenamos el certificado con nuestros datos y damos aceptar. El siguiente apartado llamado JSSE explica a detalle los datos del certificado e información sobre SSL que debes saber. Por ahora, ya con el certificado creado, lo seleccionamos de la lista y ejecutamos el proceso “Instalar Certificado”. Este nos pedirá la contraseña y el puerto. Le pasamos la contraseña que acabamos de darle, seleccionamos el puerto 8443 y damos Aceptar. Ahora, reiniciamos el servicio desde una terminal tecleando:

sudo service tomcat9 restart

Una vez reiniciado tomcat, vamos de nuevo a iniciar sesión en el SAF de la siguiente manera:

https://192.168.2.4:8443/forseti/saf/Registro

Ahora el tráfico viaja cifrado y nadie podrá leerlo en caso de interceptarlo.

MUY IMPORTANTE: Los sitios con certificados auto-firmados muestran un mensaje de error diciendo que el sitio web al que intentas ingresar no es válido, que éste, esta usando un certificado firmado por él mismo lo cual pudiera tratarse de un sitio corrupto, etc… Dependiendo del navegador es el mensaje. Esto sucede porque ahora ya estámos utilizando un certificado generado de manera local con JSSE, y no, un certificado comprado generado por una autoridad certificadora como VeriSign. No te asustes, los certificados generados con JSSE son totalmente seguros. Solo necesitas agregar la excepción al navegador diciéndole que confías permanentemente en el sitio web para que este mensaje ya no te aparezca. El mismo mensaje de error te debe llevar paso a paso, para resolver el problema.

Sobre implantaciones En la Nube, es indispensable configurar tomcat para escuchar en el puerto 443. El hecho de accesar a través del puerto 443 y no del 8443, brinda beneficios enormes en implantaciones En la Nube porque la mayoría de los cortafuegos o proxys de red de las empresas de servicios de internet de datos como por ejemplo telcel, rechazarán las conexiones al puerto 8443 del servidor porque no lo reconocen como un servicio web. Hay que recordar que los puertos 80 y 443 son manejados como el estándar para los protocolos http y https respectivamente.

Para hacer esto, creamos los archivos de permisos para AUTHBIND: 

sudo apt-get install authbind
sudo touch /etc/authbind/byport/80
sudo touch /etc/authbind/byport/443
sudo chmod 0755 /etc/authbind/byport/80
sudo chmod 0755 /etc/authbind/byport/443
sudo chown tomcat:tomcat /etc/authbind/byport/80
sudo chown tomcat:tomcat /etc/authbind/byport/443

Ahora abrimos /etc/systemd/system/multi-user.target.wants/tomcat9.service y abrimos con nano:

sudo nano /etc/systemd/system/multi-user.target.wants/tomcat9.service

Esta abrirá el archivo tomcat9.service al cual debemos remplazar la linea ExecStart=/bin/sh /usr/libexec/tomcat9/tomcat-start.sh con ExecStart=authbind --deep /bin/sh /usr/libexec/tomcat9/tomcat-start.sh de la sección de # Lifecycle:

............
............

# Lifecycle
Type=simple
ExecStartPre=+/usr/libexec/tomcat9/tomcat-update-policy.sh
# ExecStart=/bin/sh /usr/libexec/tomcat9/tomcat-start.sh
ExecStart=authbind --deep /bin/sh /usr/libexec/tomcat9/tomcat-start.sh
SuccessExitStatus=143
Restart=on-abort

............
............

Guardamos el archivo y recargamos el servicio tomcat con:

sudo systemctl daemon-reload
sudo service tomcat9 restart

Una vez reiniciado tomcat, vamos de nuevo a iniciar sesión en el SAF de la misma manera:

https://localhost:8443/forseti/saf/Registro

Ahora, vamos al menú de Administración, al módulo “Control SSL”, seleccionamos el certificado de la lista y ejecutamos de nuevo el proceso “Instalar Certificado”. Introducimos la contraseña, pero ahora el puerto lo seleccionamos como 443 y damos Aceptar. Reiniciamos otra vez el servicio desde una terminal tecleando:

sudo service tomcat9 restart

Instalamos el paquete net-tools:

sudo apt-get install net-tools

Checamos si tomcat está corriendo con:

sudo netstat -tulpn

La salida nos debe devolver algo en la terminal como esto:

Proto Recib Enviad Dirección local Dirección remota Estado PID/Program name
tcp 0 0 127.0.1.1:53 0.0.0.0:* ESCUCHAR 1045/dnsmasq
tcp 0 0 127.0.0.1:631 0.0.0.0:* ESCUCHAR 1498/cupsd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* ESCUCHAR 936/postgres
tcp6 0 0 ::1:631 :::* ESCUCHAR 1498/cupsd
tcp6 0 0 ::1:5432 :::* ESCUCHAR 936/postgres
tcp6 0 0 :::443 :::* ESCUCHAR 3285/java
tcp6 0 0 127.0.0.1:8005 :::* ESCUCHAR 3285/java
udp 0 0 0.0.0.0:39121 0.0.0.0:* 1019/dhclient
udp 0 0 0.0.0.0:5353 0.0.0.0:* 474/avahi-daemon: r
udp 0 0 0.0.0.0:60396 0.0.0.0:* 474/avahi-daemon: r
udp 0 0 127.0.1.1:53 0.0.0.0:* 1045/dnsmasq

Tomcat está corriendo en el puerto 443 como un proceso java. Esto ya permite accesar al servidor a través de una conexión natural https de la siguiente manera:

https://192.168.2.4/forseti/saf/Registro

Si deseas brindar la máxima seguridad es una muy buena idea comprar un certificado firmado por una autoridad certificadora (CA) como VerySign. Esto requiere de una preparación que se explica a continuación.

JSSE

NOTA: No es indispensable generar certificados auto-firmados e instalarlos a partir de las instrucciones en este tema, porque el SAF permite hacerlo dentro del módulo "Control SSL". Este tema se incluye en esta documentación con el propósito de ayudar a entender un poco mas a fondo los elementos criptográficos utilizados por el sistema. También es importante para aquellos que deseen comprar certificados a una autoridad certificadora (CA) en lugar de usar certificados auto-firmados o para aquellos que deseen crearse sus propias CAs.

Generando certificados auto-firmados con JSSE (Java Secure Socket Layer)

Primero que nada, hay que preparar el almacén de claves. Un almacén es esencialmente un repositorio de archivos de objetos criptográficos tales como llaves y certificados. Tomcat opera en formato de claves de JKS (Java KeyStore) y es el formato creado por la herramienta de claves de línea de comandos. Esta herramienta está incluida en el OpenJDK instalado. Para crear un nuevo almacén que contenga un certificado auto-firmado, ejecuta la siguiente línea de comandos en la terminal:

keytool -genkey -alias tomcat -validity 365 -keyalg RSA -keystore /home/forseti/fsi-keystore

Este comando creará un nuevo archivo en el directorio /home/forseti de nombre “fsi-keystore”.

Después de ejecutar el comando keytool, se te harán algunas preguntas para identificar el certificado, primero se te pedirá la contraseña del almacén de claves.

Introduzca la contraseña del almacén de claves: forseti 
¿Cuál es su nombre y apellido?   
[Unknown]: www.forseti.org.mx 
¿Cuál es el nombre de su unidad de organización?   
[Unknown]: Seguridad 
¿Cuál es el nombre de su organización?   
[Unknown]: Forseti Network 
¿Cuál es el nombre de su ciudad o localidad?   
[Unknown]: GAM 
¿Cuál es el nombre de su estado o provincia?   
[Unknown]: DF 
¿Cuál es el código de dos letras de la unidad?   
[Unknown]: MX 
¿Es correcto CN=www.forseti.org.mx, OU=Seguridad, O=Forseti Network, L=GAM, ST=DF, C=MX?   
[no]: y 
NOTA: Los datos se deben cambiar para que este certificado informe sobre la identidad específica de tu organización.

Entendiendo mas sobre SSL, y configurando JSSE con certificados emitidos por una Autoridad Certificadora (CA).

SSL o Secure Socket Layer permite que, una vez esté habilitado, todas las comunicaciones entre el servidor y el cliente viajen cifradas, de forma que terceros no puedan entender los datos que viajan del cliente al servidor o viceversa.
Los certificados tienen dos funciones principales en este proceso: Asegurar la identidad del servidor para que no haya posibilidad de suplantación por un tercero y proporcionar las claves de cifrado.

Nosotros, como dueños del servidor donde queremos activar el SSL, tendremos que generar una petición de certificado (“CSR” – Certificate Signing Request). El CSR se lo mandaremos a una entidad certificadora “CA”. Estas entidades están reconocidas a nivel mundial, y su papel es como el de un notario. Es decir, la labor de estas entidades será firmar nuestra petición asegurando ante cualquiera de nuestros clientes, que nosotros somos realmente quienes decimos ser (no suplantación). Ejemplos de estas CAs son VeriSign o VISA, aunque hay muchas más. Una vez tengamos la respuesta de la CA, la pondremos en el lugar correspondiente en nuestro servidor. Con esto estamos capacitando al servidor para establecer comunicaciones usando SSL.

Generar el CSR

Primero generamos un par de claves (pública / privada) para nuestra organización. Este par de claves se guardan en un certificado auto-firmado. Esto es lo que hicimos al principio, con el comando keytool. Con esta operación también se creó nuestro almacén.
Como se trata de un certificado auto-firmado, el propietario y el emisor son la misma entidad.

Ahora generamos el CSR. El fichero resultante de esta operación será lo que mandaremos a la CA.

keytool -certreq -alias tomcat -file mi-empresa.csr -keystore /home/forseti/fsi-keystore

En este punto tendríamos que mandar nuestro archivo “mi-empresa.csr” a una CA reconocida como VeriSign. Esta, previo pago, nos devolverá nuestro certificado firmado por ella, el cual, ya podremos instalar en nuestro sistema.

Crear nuestra propia CA

OpenSSL nos proporciona un script que nos facilita la tarea de crear una CA propia. Basta con hacer:

/usr/lib/ssl/misc/CA.sh -newca

Pulsando “enter” nos creará nuestra CA y nos pedirá la clave para acceder a la clave privada del nuevo certificado que está creando (el certificado de la CA). Nos pide el código de país, la provincia, la ciudad, la organización, la unidad organizativa, el nombre y la dirección de correo. El comando habrá creado el directorio “demoCA”. Dentro de este directorio podemos encontrar el certificado de la CA: cacert.pem.

Firmar el CSR

Ya tenemos la CA, ahora firmamos el CSR mi-empresa.csr. Para esto también usaremos el script CA.sh. Este script trabaja con nombres fijos de ficheros, con lo que espera encontrar el CSR con el nombre “newreq.pem”. Lo que vamos a hacer es renombrar mi-empresa.csr a newreq.pem. NOTA: nuestro CSR debe quedar a la misma altura que el directorio”demoCA”, y no dentro de él. Ahora, estando en el directorio donde tenemos newreq.pem hacemos:

/usr/lib/ssl/misc/CA.sh -signreq

Nos pide la clave para acceder al certificado de la CA. Es la clave que pusimos a la CA en el punto anterior. Nos mostrará la información del CSR que vamos a firmar y nos pide confirmación para firmar el certificado. Por último nos pide confirmar para aceptar los cambios. Al final nos mostrará el fichero “newcert.pem” con nuestro certificado firmado por la CA. Dentro del fichero”newcert.pem” lo que nos interesa es lo que hay al final entre “BEGIN CERTIFICATE” y “END CERTIFICATE”. Esto es realmente el certificado, así que vamos a poner esto en un fichero a parte (hacemos copy-paste con cualquier editor). El nuevo fichero lo llamaremos “tomcatsign.pem” y su contenido será algo como:

-----BEGINCERTIFICATE-----
MIIFPDCCBKWgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBuzELMAkGA1UEBhMCRVMx
DzANBgNVBAgTBk1hZHJpZDEUMBIGA1UEBxMLVHJlcyBDYW50b3MxKTAnBgNVBAoT
IEF1dGVudGlhIFJlYWwgQnVzaW5lc3MgU29sdXRpb25zMSIwIAYDVQQLExlJbXBs
YW50YWNpb24geSBEZXNhcnJvbGxvMRQwEgYDVQQDEwtBdXRlbnRpYSBDQTEgMB4G
CsqGSIb3DQEJARYRaW5mb0BhdXRlbnRpYS5jb20wHhcNMDUwODAyMDkxMzEyWhcN
MDYwODAyMDkxMzEyWjCBnjELMAkGA1UEBhMCZXMxDzANBgNVBAgTBk1hZHJpZDEU
MBIGA1UEBxMLVHJlcyBDYW50b3MxKTAnBgNVBAoTIEF1dGVudGlhIFJlYWwgQnVz
aW5lc3MgU29sdXRpb25zMSMwIQYDVQQLExpJbXBsYW50YWNpb24geSBSZW5kaW1p
ZW50bzEYMBYGA1UEAxMPQWxlamFuZHJvIFBlcmV6MIIBuDCCASwGByqGSM44BAEw
ggEfAoGBAP1/U4EddRIpUt9KnC7s5Of2EbdSPO9EAMMeP4C2USZpRV1AIlH7WT2N
Wpq/xfW6MPbLm1Vs14E7gB00b/JmYLdrmVClpJ+f6AR7ECLCT7up1/63xhv4O1fn
xqimFQ8E+4P208UewwI1VBNaFpEy9nXzrith1yrv8iIDGZ3RSAHHAhUAl2BQjxUj
C8yykrmCouuEC/BYHPUCgYEA9+GghdabPd7LvKtcNrhXuXmUr7v6OuqC+VdMCz0H
gmdRWVeOutRZT+ZxBxCBgLRJFnEj6EwoFhO3zwkyjMim4TwWeotUfI0o4KOuHiuz
EwJFUzEPMA0GA1UECBMGTWFkcmlkMRQwEgYDVQQHEwtUcmVzIENhbnRvczEpMCc
-----END CERTIFICATE-----

Instalar la respuesta de la CA

Si nos hemos generado nuestra propia CA con la que hemos firmado nuestra petición, tendremos que instalar el fichero “tomcatsign.pem” que hemos preparado. Este punto sólo tenemos que hacerlo si la CA que ha firmado nuestra petición no está reconocida por nuestro fsi-keystore, ni por nuestro cacerts keystore. NOTA: “cacerts keystore” es el que viene por defecto cuando se instala el OpenJDK. Lo podemos encontrar en $JAVA_HOME/jre/lib/security/cacerts. En ubuntu en /etc/lib/ssl/. Por defecto contiene algunos certificados de CAs reconocidas (VeriSign, EquiFax, Entruts, …). Como en nuestro caso la CA la hemos generado nosotros mismos, tendremos que instalar el certificado de la CA. Para ello hacemos:

keytool -import -alias demoCaCert -file demoCA/cacert.pem -keystore /home/forseti/fsi-keystore

Como se puede ver en el ejemplo, el fichero que contiene el certificado de nuestra CA es “demoCA/cacert.pem”. Es fundamental que mandemos este fichero a los clientes que más tarde se quieran conectar con nuestro servidor, para que puedan importarlo igual que hemos hecho nosotros. De lo contrario cuando se intenten conectar con el servidor les aparecerá una ventana indicando que nuestro certificado viene firmado por una CA no reconocida. Si quisiéramos instalar el certificado de la CA en el cacerts keystore podríamos hacer:

keytool -import -alias demoCaCert -file demoCA/cacert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts

En Ubuntu:

keytool -import -alias demoCaCert -file demoCA/cacert.pem -keystore /etc/lib/ssl/cacerts

Instalar nuestro certificado firmado por la CA

El último paso es instalar nuestro nuevo certificado firmado por la CA. Para esto haremos:

keytool -import -alias tomcat -file tomcatsign.pem -keystore /home/forseti/fsi-keystore

Fíjate que el alias es el mismo que usamos en el paso 4.1, es decir, estamos sustituyendo el certificado auto-firmado por el certificado firmado por la CA. Si el certificado de la CA lo habíamos guardado en el cacerts keystore tendremos que añadir la opción “-trustcacerts”:

keytool -import -alias tomcat -file tomcatsign.pem -trustcacerts -keystore /home/forseti/fsi-keystore

Ya está todo listo. Ahora podemos ver el contenido de nuestro almacén de claves para ver como quedo:

keytool -list -v -keystore /home/forseti/fsi-keystore

Podemos fijarnos en que ahora el emisor de “tomcat” es “La demo CA”. Podemos contrastar esto con lo que veíamos en el primer punto donde se puede ver que, como el certificado es auto-firmado, el propietario y el emisor son la misma entidad.

Conclusiones

El correcto uso de los certificados es fundamental para la seguridad de nuestros servidores. Aquí hemos visto como manejar los certificados con la herramienta keytool y con OpenSSL y se ha repasado el ciclo desde que se hace la petición del certificado hasta que finalmente se instala. Forseti cuenta con un módulo de gestión de seguridad el cual es accesible desde el SAF – Administracion – Control SSL, el cual permite consultar, crear certificados auto-firmados e instalarlos ya que gestiona keytool, y el archivo de tomcat “server.xml”. Por el momento no permite la creación de nuestra propia CA, por lo que si deseas creártela, tienes que hacerlo manualmente desde la terminal. Hay que recordar tres cosas de suma importancia:

  • Los certificados tienen caducidad, por lo que es importante que haya un responsable encargado de renovarlos cuando sea necesario. No te sorprendas si ves como un servidor deja de funcionar de repente y sin motivo aparente, y al final resulta que alguno de los certificados ha caducado.
  • Si nos hemos creado nuestra propia CA, debemos enviar el certificado de nuestra CA a los clientes, para que estos se puedan conectar sin problema con nuestro servidor (que tiene un certificado firmado por esta CA).
  • Si nuestro servidor es un servidor de Out-Sourcing, es muy aconsejable que nuestros certificados estén firmados por una CA auténtica y reconocida a nivel mundial como VerySign, auque esto nos genere gastos. Generar confianza absoluta a las empresas registradas en nuestro sistema justificará el gasto.

Primeros pasos

Ahora que ya hemos instalado y configurado nuestro servidor Forseti ERP, deberíamos actualizarlo. Actualizar, es una de las principales tareas administrativas para nuestro nuevo servidor ya que con ellas mantenemos la estabilidad y las mejoras al sistema tanto de seguridad como de funcionalidad. Para actualizar simplemente vamos a entrar al SAF y en el menú de Administración entramos al módulo “Servidor y Empresas”, allí ejecutamos el proceso “Actualizar Servidor” y esperamos a que termine. Podemos ver el registro de la actualización, para ello vamos al menú Registros y entramos al módulo “Registros Administrativos”, luego en el panel izquierdo seleccionamos la ficha “Tipo / Actualizaciones” y “Rango / Hoy”. Esto nos mostrará los archivos de registro de las actualizaciones del día. Seleccionamos el archivo y ejecutamos el proceso “Abrir”. Esto nos mostrará el registro del proceso de actualización del servidor, algo como esto:

----------------------------------------------------------------------------
              ACTUALIZACION DEL SERVIDOR: 12:30:30 
---------------------------------------------------------------------------- 
Obteniendo indice de actualizacion desde: 
https://s3-us-west-2.amazonaws.com/forseti.org.mx/descargas/actualizaciones 
--2014-08-18 12:30:30--  
https://s3-us-west-2.amazonaws.com/forseti.org.mx/descargas/actualizaciones/indice.si 
Resolving s3-us-west-2.amazonaws.com (s3-us-west-2.amazonaws.com)... 54.231.162.192 
Connecting to s3-us-west-2.amazonaws.com (s3-us-west-2.amazonaws.com)|54.231.162.192|:443... connected. 
HTTP request sent, awaiting response... 200 OK 
Length: 48 [application/octet-stream] 
Saving to: `/usr/local/forseti/act/indice.si'

      0K                                                       100% 1,46M=0s 

2014-08-18 12:30:30 (1,46 MB/s) - `/usr/local/forseti/act/indice.si' saved [48/48] 
FINALIZANDO DESCARGA DEL INDICE: 12:30:30 
------------------------------------------------------------------------------ 
Se han descargado y actualizado el servidor 
Probablemente se necesitará reiniciar este servidor si tomcat no esta configurado con autodeploy.... 
--------------------- FIN DE LA ACTUALIZACION --------------------------

En este caso nada fue actualizado, pero en caso de que hayan actualizaciones disponibles, estas se instalarán y el servidor quedará actualizado a su última versión.

Las tareas frecuentes como Actualizaciones al servidor, Respaldos y Actualización de saldos del CEF (saldos contables, existencias, saldos de cuentas bancarias, clientes, proveedores, etc.), se pueden configurar para que se conviertan en una tarea automática. Para ello, vamos a irnos al menú Administración, al módulo “Servidor y Empresas” y ejecutamos el proceso “Propiedades”. Ingresamos la hora para el inicio del proceso de automatización en formato hh:mm de 24 hrs, por ejemplo, 23:59 será a las 11:59 de la noche, y seleccionamos las tareas que queremos automatizar. Para los respaldos, necesitamos también la ruta absoluta, por ejemplo “/usr/local/forseti/respaldos” que es la ruta predeterminada. Esta ruta, debe ser un directorio y existir en nuestro sistema de archivos y debe ser posible que el proceso tomcat tenga acceso y pueda escribir en ella.

¡Listo!. Ahora las tareas seleccionadas se ejecutarán diario a la hora indicada. Es recomendable que se realicen durante un horario en el que el servidor no reciba mucha carga de trabajo porque este proceso puede volverlo lento.

Creando nuestra primera base de datos.

Una empresa en nuestro servidor es físicamente una base de datos en PostgreSQL, además de ciertos archivos de configuración en el directorio emp del sistema base. Cada base de datos funciona independiente y no comparten ninguna información. Crear nuestra primera empresa es un proceso tan sencillo en el SAF como ir a Administración – Servidor y Empresas – Agregar Empresa, llenar los datos que se piden y dar Aceptar. Esto empieza el proceso de creación de la base de datos en el servidor PostgreSQL y la creación de archivos de configuración del sistema base, además, crea el registro en la base de datos principal “FORSETI_ADMIN” para poder administrar los recursos anteriormente descritos entre otros recursos de empresa.

Una vez creada la empresa, podemos accesar desde el navegador web como https://localhost/forseti/cef/Registro o https://localhost:8443/forseti/cef/Registro o incluso como http://localhost:8080/forseti/cef/Registro, dependiendo de como hayamos configurado nuestro servidor.

Estando dentro, iniciamos sesión y podemos empezar a trabajar en ella. Para iniciar sesión por primera ocasión, proporcionamos el nombre en mayúsculas en “Nombre de la Base de Datos”, el usuario administrador de esta base de datos se llamará exactamente igual al nombre de la base de datos, pero en minúsculas, y la contraseña será la que se introdujo al crear la empresa.

NOTA: Es muy recomendable crear usuarios dentro de la empresa asignándole sus permisos y no accesar a ella como usuario administrador que es el usuario que se llama igual a la base de datos.

Para empezar a manejar tu empresa te sugerimos revisar la documentación del CEF. El CEF te brinda una interfaz web bastante poderosa y robusta para su control. Puedes dirigirte directamente a la documentación del centro de control ya que es la parte del CEF que permite la configuración de la empresa y te puede dar una idea general del poder de Forseti ERP. También te sugerimos que inicialmente crees empresas de prueba para irte familiarizando con el sistema antes de ponerlo en producción. Debido a la alta cantidad de procesos de un sistema como lo es Forseti ERP donde trabajas en todos los módulos y departamentos, y además estos se integran, crear empresas de prueba para estudiar el comportamiento siguiendo ejemplos en la documentación será la mejor herramienta de aprendizaje.

Contenido