El directorio /usr/local/forseti donde quedó instalado forseti, contiene los siguientes subdirectorios: act, bin, emp, log, pac y req.
act: Este subdirectorio contendrá las actualizaciones descargadas del servicio.
bin: De suma importancia, contiene archivos ocultos de las propiedades del servidor. Estos son
-
.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.
-
.forseti_doc; Contiene toda la estructura de la documentación del servidor en caso de que este servidor maneje documentación propia, de lo contrario, la documentación la toma del sitio http://www.forseti.org.mx.
-
.forseti_es; Contiene toda la información de los mensajes en español que genera el servidor a través de cada proceso.
-
.forseti_init; Es el código fuente de inicialización del servidor Forseti. Básicamente, contiene la estructura de la base de datos principal "FORSETI_ADMIN".
-
.forseti_inibd; Es el código fuente de inicialización para cada empresa que se dé de alta en el sistema.
-
.forseti_pac; Maneja la configuración de los datos de este servidor, para poder recibir los servicios de timbrado de comprobantes fiscales digitales, envío automático de correo electrónico y alojamiento de archivos en la nube de Amazon S3.
-
.forseti_smtp; Cuando este servidor forseti 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 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.
-
forseti_srv; Este archivo no se utiliza aún, pero servirá para futuras versiones cuando el módulo de CRM esté terminado.
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. 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, etc.
pac: Cuando este servidor forseti 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, y también el archivo .forseti_pac que contiene la configuración para la conexión al servicio web del proveedor autorizado de certificación del SAT.
req: Contiene archivos de recursos que utiliza forseti para realizar algunas tareas.
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/SAF
Ingresamos la IP 127.0.0.1, el puerto de comunicación (por lo general será 5432 a menos que se agregue un cluster específico para forseti) y la contraseña del usuario "forseti" que acabamos de crear. Presionamos Ok.
Esperamos unos minutos y listo... Ya esta configurada la base de datos principal FORSETI_ADMIN, ahora reiniciamos tomcat con:
$ sudo service tomcat7 restart
Y ya podemos iniciar sesión en el SAF como:
Usuario "fsi" y
Contraseña "fsi".
NOTA: Si se instaló el servidor forseti 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. 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/SAF
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 y también vamos a configurar la ruta de la instalación de Tomcat para establecerla como
/var/lib/tomcat7 (para distribuciones diferentes a la familia Ubuntu, la ruta de instalación puede cambiar). Si todo va bien damos Aceptar.
El servicio tomcat utiliza por default el puerto 8080 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 perspectiva
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.
Primero configuramos tomcat para aceptar la instalación desde el SAF ( Esto solo se debe hacer en caso de que forseti sea la única aplicación que contendrá tomcat, de lo contrario, se tendrá que cambiar el archivo de manera manual. ):
$ sudo chgrp tomcat7
/var/lib/tomcat7/conf/server.xml
$ sudo chmod 660 /var/lib/tomcat7/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 deberías saber). 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 tomcat7 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/SAF
Ahora el tráfico viaja cifrado y nadie podrá leerlo en caso de interceptarlo.
NOTA 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.
En perspectivas de implantación
En la Nube, sería muy conveniente 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 desde esta perspectiva, 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.
Usando la terminal habilitamos AUTHBIND. Abrimos el archivo "/etc/default/tomcat7" con el editor de texto y agregamos la linea "AUTHBIND=yes":
$ sudo nano /etc/default/tomcat7
# Run Tomcat as this user ID. Not setting this or leaving it blank will use the
# default of tomcat7.
.........................
.........................
.........................
# If you run Tomcat on port numbers that are all higher than 1023, then you
# do not need authbind. It is used for binding Tomcat to lower port numbers.
# NOTE: authbind works only with IPv4. Do not enable it when using IPv6.
# (yes/no, default: no)
# AUTHBIND=no
AUTHBIND=yes
Salvamos el archivo y salimos. Ahora creamos los archivos de permisos para 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 tomcat7:tomcat7 /etc/authbind/byport/80
$ sudo chown tomcat7:tomcat7 /etc/authbind/byport/443
Reiniciamos Tomcat
$ sudo service tomcat7 restart
Una vez reiniciado tomcat, vamos de nuevo a iniciar sesión en el SAF de la misma manera:
https://localhost:8443/SAF
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. Ahora, reiniciamos otra vez el servicio desde una terminal tecleando:
$ sudo service tomcat7 restart
Checamos si tomcat está corriendo.
$ sudo netstat -tulpn
Conexiones activas de Internet (solo servidores)
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/SAF
Para finalizar, y sobre todo si se piensa ser proveedor de
Out-Soursing, sería muy buena idea comprar un certificado firmado por una autoridad certificadora (CA) como VerySign. Esto requiere de una preparación que se explica en el apartado
JSSE de esta documentación.