Sockets io con SSL, Apache, Ubuntu

Primero desplegamos nuestro servidor de Sockets.io Node con Node.

Escenario:

La app de node sale por el puerto 8101.
Partimos de que tenemos el SSL correctamente configurado con Let’s Encrypt.
PHP 5.6
Apache/2.4.29 (Ubuntu)

Lo que vamos a hacer es redirigir mediante Apache proxy el tráfico del puerto 443 (SSL) al puerto 8101 (Por donde sale nuestro server de Node).

Para ellos, desplegamos nuestra app de Node en nuestro servidor y la corremos (Enlace para correr nuestro servidor de Node en segundo plano en nuestro Linux).

Clonamos nuestra app node desde nuestro repositorio:

Nos dirigimos a nuestro directorio:

Instalamos dependencias:

Arrancamos nuestra app con Forever (Tutorial en el link del párrafo anterior):

Creamos el sitio en apache:

Y escribimos en este (cambiando el puerto 8101 por el que nosotros saquemos nuestro servidor de Node/Sockets):

Comprobamos que la sintaxis de nuestro sitio es correcta con:

Nos debería de responder: Syntax OK

Habilitamos el sitio:

Nos cercionamos que tenemos los siguientes módulos de Apache habilitados:

ssl
headers
proxy
proxy_http
proxy_wstunnel

Podemos listarlos con:

O podemos habilitarlos:

En caso de que ya estuvieran habilitados, no pasaría nada. Apache nos avisaría que ya está «enabled» y a marchar.

Reiniciamos nuestro apache:

Y a funcionar!

En caso de fallo, podemos pegarle un vistazo a Log, seguramente nos arroje algo de luz:


NOTA:

El cliente Socket se conectaría de la siguiente manera:

No apuntaríamos al puerto por el que sale nuestra app de node (8101 en mi caso), ya que estamos redirigiendo el tráfico del 443 (ssl) al 8101 para nuestro subdominio de sockets.

También sería válido:

Saludossss 💃🏻


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Correr una aplicación de node en background, Linux

De manera «nativa» podemos ejecutar nuestra app de node en linux con nohup.

Pero tenemos una magnifica tool de para node llamada Forever (https://github.com/foreversd/forever). Lo instalaremos mediante:

Y os dejo algunos comandos básicos.

Para iniciar la app:

Pararla:

Reiniciar:

Etc etc…

Para ver las apps en ejecución:

Para ver más:


Para parar procesos de Node podemos…

Buscar procesos de node:

Matar el proceso por su número de PID:


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Que cada subdomino de Odoo 12 apunte a una base de datos

Esta es para mi la guía definitiva de cómo tener varios Odoo’s o bases de datos de Odoo bajo nombre de dominio diferente.

Partimos del escenario en el que las bases de datos que tenemos son:

ejemplo_erp
erp_demo

Vamos a trabajar con el dominio erp_demo, haríamos lo mismo para erp_ejemplo

En el en el archivo de odoo.conf tenemos que modificar los siguiente parámetros: db_name, dbfilter y proxy_mode:

Si no sabemos donde se encuentra el archivo podemos buscarlo con

Y editamos el archivo:

Los parámetros de mi instalación de Odoo (y funcionando) eran:

db_name = False
dbfilter =
proxy_mode = false

Los modificamos a:

db_name = False
dbfilter = %d
proxy_mode = True

En algunos casos recomiendan utilizar para dbfilter la expresión regular:

dbfilter = ^%d$

A mi, solo con %d me funciona.

dbfilter = %d

En el archivo rc.local no tengo ninguna redirección, sería conveniente que le peguéis un ojo por si alguna redirección está actuando por ahí.

Para leer el archivo:

Creamos el certificado SSL para nuestro nuevo subdominio:

Mas info en al web de certbot: https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx

Bien, vayamos para NGINX!

Creamos o editamos el sitio web:

Y escribimos:

No olvidemos editar el server_name de los dos «server» Y la ubicación de los certificados de letsencrypt en los parámetros ssl_certificate, ssl_certificate_key y ssl_trusted_certificate

Si creásemos otro sitio, no olvidéis cambiar los «upstream«. De todos modos si al arrancar NGINX o al reiniciarlo no los hemos cambiado, no arrancará correctamente y nos lazará un error, para verlo nos sugiere que escribamos el comando: «sudo systemctl status nginx.service»

Habilitamos sitio:

Reiniciamos NGINX:

Reiniciamos Odoo:

Y a funcionar, accedemos a «erp_demo.ekiketa.com» y debería de funcionar 👀


👀
Ojo, con el cambio del dbfilter hay algo que es importante. Puede que al intentar imprimir un «Report» (Facturas, pedidos de compra, etc) Odoo 12 pierda la sesión y la factura se imprima sin estilos. Recordemos qué hacer si Odoo imprime mal las facturas, tocábamos un parámetro del sistema de Odoo llamado «report.url«. (Click en el enlace anterior para ver el tutorial).
Pues con el dbfilter activado, tenemos que hacer una pequeña modificación en este parámetro y en el archivo «/etc/hosts» de la máquina donde está Odoo 12 instalado.

Para ello, vamos a editar el archivo hosts de el servidor donde tenemos nuestro Odoo.

(Puede que se redundante que mencione tanto nuestro máquina donde está Odoo, nuestro servidor de Odoo, etc… Pero es importante no perder el contexto en estos puntos)

Y añadimos un nombre «local» para nuestros dominios, por ejemplo:

Ahora, desde nuestro navegador «local» (Donde se encuentra nuestro Odoo) deberemos acceder a éste mediante: http://erp_demo.ekiketa.local:8069 y… deberemos cambiar en Odoo el parámetro «report.url» de los Parámetros del sistema.

Y ya, ahora sí que estará todo al sitio.

¡Saludos!


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

413 (Request Entity Too Large) Nginx

El problema nos llega en el momento que intentamos enviar una petición que ocupa más de 1MB, que es el máximo por defecto de NGINX.

Para arreglar este pequeño imprevisto, editaremos la configuración de NGINX:

(Siempre que no sabemos exactamente qué estamos haciendo, antes de modificar un archivo de configuraciones es conveniente hacer una copia de seguridad.)

y modificaremos el parámetro:

El número «12m» indicará 12 Megas, si queremos deshabilitarlo podemos introducir un «0«.

Podemos verlo en la documentación: http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size


Si vamos a recibir peticiones un poco más pesadas podríamos considerar el subir el parámetro client_body_buffer_size a 16K por ejemplo.

Todo ello nos quedaría algo parecido a:

(Los 3 puntos sería el resto del archivo y de nuestras configuraciones)


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Odoo 12 imprime las facturas sin estilos

Si tanto al imprimir como al crear el PDFen Odoo 12 nos lo imprime sin estilo, seguramente tenga fácil solución.

Primero nos dirigiremos a: Ajustes ( Con modo desarrollador activo ) > Técnico > Parámetros > Parámetros del sistema

Y allí veremos una serie de parámetros Clave/Valor.

Buscaremos la clave «report.url» y si no existe la añadimos.

Como valor le añadimos

o

Teniendo en cuenta que nuestro Odoo funciona sobre el puerto 8069, que es el puerto por defecto

Y ya en un principio podríamos imprimir sin problemas. (No debería ser necesario reiniciar Odoo)


Y ya de paso, podemos repasar los siguientes parámetros;

Y

¡Saludos!


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule

Puede que estemos intentando configurar un proxy en Apache y nos devuelve este error:

If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule

Es porque no tenemos habilitado el módulo mod_proxy_http. En mi caso, he tenido que habilitar el siguiente módulo

Luego de habilitar, no olvidemos reiniciar:


Otros relacionado para este tipo de casos.


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Invalid command ‘ProxyRequests’, perhaps misspelled or defined by a module not included in the server configuration

Si por parte de Apache recibimos este error:

Invalid command ‘ProxyRequests’, perhaps misspelled or defined by a module not included in the server configuration

Simplemente lo que tenemos que hacer es activar el módulo con:

Ahora, reiniciamos Apache y arreglado:


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Invalid command ‘RequestHeader’, perhaps misspelled or defined by a module not included in the server configuration

Si por parte de Apache recibimos este error:

Invalid command ‘RequestHeader’, perhaps misspelled or defined by a module not included in the server configuration

Simplemente lo que tenemos que hacer es activar el módulo con:

Ahora, reiniciamos Apache y arreglado:


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Instalar git-flow en Mac

Pues… si queremos crear git-flow en un repositorio que tenemos en nuestro MacOS, a priori no estará instalado y al ejecutar:

nos responderá:

bash: git-flow: command not found

Para instalar git-flow hay que ejecutar el siguiente comando con brew (cómo instalar brew en macOS).

Y a funcionar.

Para iniciar git-flow escribimos en el directorio raíz de nuestro proyecto:

Y en los mensajes que nos va preguntando podemos ir pulsando Enter para dejar los nombres por defecto:

Which branch should be used for bringing forth production releases?
– master
Branch name for production releases: [master]
Branch name for «next release» development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Saludos 🙂


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?

Instalar brew en nuestro Mac

Para instalar el gestor de paquetes de en nuestro macOS simplemente abrimos la terminal y ejecutamos:

Easy, podéis verlo en la web oficial: https://brew.sh/index_es

Saludosss


Tu opinión es importante para mi, ¿Te ha resultado útil este artículo?