Ekiketa – Mi biblioteca de código, el sitio donde iré posteando ayudas que sirven en el día a día de un programador.

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:

git clone https://ekiketa@ejemplo.org/app-sockets.git

1	git clone https://ekiketa@ejemplo.org/app-sockets.git

Nos dirigimos a nuestro directorio:

cd nombre-directorio/

1	cd nombre-directorio/

Instalamos dependencias:

npm install

1	npm install

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

forever start app.js

1	forever start app.js

Creamos el sitio en apache:

sudo nano /etc/apache2/sites-available/sockets-ssl.conf

1	sudo nano /etc/apache2/sites-available/sockets-ssl.conf

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

<VirtualHost *:80>

	ServerName sockets.ekiketa.es
	Redirect permanent / https://sockets.ekiketa.es

</VirtualHost>
<VirtualHost *:443>

	ServerName sockets.ekiketa.es

	SSLEngine on
	SSLProtocol all -SSLv2
	SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

	SSLCertificateFile	/etc/letsencrypt/live/ekiketa.es/fullchain.pem
	SSLCertificateKeyFile	/etc/letsencrypt/live/ekiketa.es/privkey.pem

        # ServerAdmin webmaster@localhost

	<Proxy *>
		Require all granted
	</Proxy>

	ProxyRequests off
	ProxyVia on

	RewriteEngine On
	RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
	RewriteCond %{QUERY_STRING} transport=websocket    [NC]
	RewriteRule /(.*)           ws://localhost:8101/$1 [P,L]


	ProxyPass        /socket.io	http://localhost:8101/socket.io
	ProxyPassReverse /socket.io	http://localhost:8101/socket.io

	<Location />
		ProxyPass http://127.0.0.1:8101/
		ProxyPassReverse http://127.0.0.1:8101/
	</Location>


	ErrorLog /var/log/apache2/sockets-ssl-error.log
	CustomLog /var/log/apache2/sockets-ssl-access.log combined

</VirtualHost>

ServerName sockets.ekiketa.es

Redirect permanent / https://sockets.ekiketa.es

</VirtualHost>

ServerName sockets.ekiketa.es

SSLEngine on

SSLProtocol all -SSLv2

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

SSLCertificateFile /etc/letsencrypt/live/ekiketa.es/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/ekiketa.es/privkey.pem

# ServerAdmin webmaster@localhost

Require all granted

</Proxy>

ProxyRequests off

ProxyVia on

RewriteEngine On

RewriteCond %{REQUEST_URI} ^/socket.io [NC]

RewriteCond %{QUERY_STRING} transport=websocket [NC]

RewriteRule /(.*) ws://localhost:8101/$1 [P,L]

ProxyPass /socket.io http://localhost:8101/socket.io

ProxyPassReverse /socket.io http://localhost:8101/socket.io

ProxyPass http://127.0.0.1:8101/

ProxyPassReverse http://127.0.0.1:8101/

</Location>

ErrorLog /var/log/apache2/sockets-ssl-error.log

CustomLog /var/log/apache2/sockets-ssl-access.log combined

</VirtualHost>

Comprobamos que la sintaxis de nuestro sitio es correcta con:

apachectl configtest

1	apachectl configtest

Nos debería de responder: Syntax OK

Habilitamos el sitio:

sudo a2ensite sockets-ssl.conf

1	sudo a2ensite sockets-ssl.conf

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

ssl
headers
proxy
proxy_http
proxy_wstunnel

Podemos listarlos con:

ll /etc/apache2/mods-enabled/

1	ll /etc/apache2/mods-enabled/

O podemos habilitarlos:

sudo a2enmod ssl 
sudo a2enmod headers
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_wstunnel

sudo a2enmod ssl

sudo a2enmod headers

sudo a2enmod proxy

sudo a2enmod proxy_http

sudo a2enmod proxy_wstunnel

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:

sudo systemctl restart apache2.service

1	sudo systemctl restart apache2.service

Y a funcionar!

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

tail -f /var/log/apache2/sockets-ssl-error.log

1	tail -f /var/log/apache2/sockets-ssl-error.log

NOTA:

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

let appSocket = {
    server  : {
        protocol        : 'http://',
        host            : 'sockets.cactusds.com',
        port            : 443
    }
}

const socket = io( appSocket.server.protocol + appSocket.server.host + ':' + appSocket.server.port );

let appSocket = {

server : {

protocol : 'http://',

host : 'sockets.cactusds.com',

port : 443

}

const socket = io( appSocket.server.protocol + appSocket.server.host + ':' + appSocket.server.port );

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:

let appSocket = {
    server  : {
        protocol        : 'https://',
        host            : 'sockets.cactusds.com',
        port            : ''
    }
}

let appSocket = {

server : {

protocol : 'https://',

host : 'sockets.cactusds.com',

port : ''

}

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.

nohup node /nodeapp/index.js &

1	nohup node /nodeapp/index.js &

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

sudo npm install forever -g

1	sudo npm install forever -g

Y os dejo algunos comandos básicos.

Para iniciar la app:

forever start app.js

1	forever start app.js

Pararla:

forever stop app.js

1	forever stop app.js

Reiniciar:

forever restart app.js

1	forever restart app.js

Etc etc…

Para ver las apps en ejecución:

forever list

1	forever list

Para ver más:

forever --help

1	forever --help

Para parar procesos de Node podemos…

Buscar procesos de node:

ps axl | grep node

1	ps axl \| grep node

Matar el proceso por su número de PID:

kill <PID>

1	kill <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

sudo find / -name odoo.conf

1	sudo find / -name odoo.conf

Y editamos el archivo:

sudo nano /etc/odoo/odoo.conf

1	sudo nano /etc/odoo/odoo.conf

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:

cat /etc/rc.local

1	cat /etc/rc.local

Creamos el certificado SSL para nuestro nuevo subdominio:

sudo certbot --nginx -d erp_demo.ekiketa.com

1	sudo certbot --nginx -d erp_demo.ekiketa.com

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:

sudo nano /etc/nginx/sites-available/erp_demo

1	sudo nano /etc/nginx/sites-available/erp_demo

Y escribimos:

upstream odoo_ejemplo {
	server 127.0.0.1:8069;
}
upstream odoochat_ejemplo {
	server 127.0.0.1:8072;
}


server {
	listen 80;
	server_name erp_demo.ekiketa.com;

	include snippets/letsencrypt.conf;
	return 301 https://$host$request_uri;
}

server {
	listen 443 ssl http2;
	server_name erp_demo.ekiketa.com;

	proxy_read_timeout 720s;
	proxy_connect_timeout 720s;
	proxy_send_timeout 720s;

	# Add Headers for odoo proxy mode
	proxy_set_header X-Forwarded-Host $host;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header X-Forwarded-Proto $scheme;
	proxy_set_header X-Real-IP $remote_addr;


	# Redirect requests to odoo backend server
	location / {
		proxy_redirect off;
		proxy_pass http://odoo_ejemplo;
	}

	location /longpolling {
		proxy_pass http://odoochat_ejemplo;
	}

	# common gzip
	gzip_types text/css text/less text/plain text/xml application/xml application/json application/javascript;
	gzip on;

	ssl_certificate /etc/letsencrypt/live/erp_demo.ekiketa.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/erp_demo.ekiketa.com/privkey.pem;
	ssl_trusted_certificate /etc/letsencrypt/live/erp_demo.ekiketa.com/chain.pem;
	include snippets/ssl.conf;
	include snippets/letsencrypt.conf;

}

upstream odoo_ejemplo {

server 127.0.0.1:8069;

}

upstream odoochat_ejemplo {

server 127.0.0.1:8072;

}

server {

listen 80;

server_name erp_demo.ekiketa.com;

include snippets/letsencrypt.conf;

return 301 https://$host$request_uri;

}

server {

listen 443 ssl http2;

server_name erp_demo.ekiketa.com;

proxy_read_timeout 720s;

proxy_connect_timeout 720s;

proxy_send_timeout 720s;

# Add Headers for odoo proxy mode

proxy_set_header X-Forwarded-Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Real-IP $remote_addr;

# Redirect requests to odoo backend server

location / {

proxy_redirect off;

proxy_pass http://odoo_ejemplo;

}

location /longpolling {

proxy_pass http://odoochat_ejemplo;

}

# common gzip

gzip_types text/css text/less text/plain text/xml application/xml application/json application/javascript;

gzip on;

ssl_certificate /etc/letsencrypt/live/erp_demo.ekiketa.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/erp_demo.ekiketa.com/privkey.pem;

ssl_trusted_certificate /etc/letsencrypt/live/erp_demo.ekiketa.com/chain.pem;

include snippets/ssl.conf;

include snippets/letsencrypt.conf;

}

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:

sudo ln -s /etc/nginx/sites-available/erp_demo /etc/nginx/sites-enabled/

1	sudo ln -s /etc/nginx/sites-available/erp_demo /etc/nginx/sites-enabled/

Reiniciamos NGINX:

sudo systemctl restart nginx.service

1	sudo systemctl restart nginx.service

Reiniciamos Odoo:

sudo systemctl restart odoo.service

1	sudo systemctl restart odoo.service

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.

sudo nano /etc/hosts

1	sudo nano /etc/hosts

(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:

127.0.0.1 erp_demo.ekiketa.local
127.0.0.1  ejemplo_erp.ekiketa.local

1 2	127.0.0.1 erp_demo.ekiketa.local 127.0.0.1 ejemplo_erp.ekiketa.local

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:

sudo nano /etc/nginx/nginx.conf

1	sudo nano /etc/nginx/nginx.conf

(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:

client_max_body_size 12m;

1	client_max_body_size 12m;

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

client_max_body_size 0;

1	client_max_body_size 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:

...
http {
    ...

    client_max_body_size 12m;
    client_body_buffer_size 16K;
    ...
}

...

http {

...

client_max_body_size 12m;

client_body_buffer_size 16K;

...

}

(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

http://127.0.0.1:8069

1	http://127.0.0.1:8069

http://localhost:8069

1	http://localhost:8069

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;

Clave: web.base.url
Valor: http://nuestrodominio.paraodoo.ejemplo:8888

1 2	Clave: web.base.url Valor: http://nuestrodominio.paraodoo.ejemplo:8888

Clave: web.base.url.freeze
Valor: True

1 2	Clave: web.base.url.freeze Valor: True

¡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

sudo a2enmod proxy_http

1	sudo a2enmod proxy_http

Luego de habilitar, no olvidemos reiniciar:

sudo systemctl restart apache

1	sudo systemctl restart apache

Otros relacionado para este tipo de casos.

sudo a2enmod ssl
sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http

sudo a2enmod ssl

sudo a2enmod proxy

sudo a2enmod proxy_balancer

sudo a2enmod proxy_http

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:

sudo a2enmod proxy

1	sudo a2enmod proxy

Ahora, reiniciamos Apache y arreglado:

systemctl restart apache2

1	systemctl restart apache2

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:

sudo a2enmod headers

1	sudo a2enmod headers

Ahora, reiniciamos Apache y arreglado:

systemctl restart apache2

1	systemctl restart apache2

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:

git-flow init

1	git-flow init

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).

brew install git-flow

1	brew install git-flow

Y a funcionar.

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

git-flow init

1	git-flow init

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:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

1	/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

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?

¡Hola!