Iloo

https://iloo.wordpress.com

Archivos por Etiqueta: CentOS

openssl: remover passphrase

Se tienen las keys generadas usando un passphrase:

  • ssl.key
  • ssl.cert
  • ca.cert

Al parecer hay un problema usando curl (lo dejare para otra ocasión) en Centos7, parece estar relacionado a NSS, la petición con curl seria:

--
curl -v -k --cert ./ssl.cert --key ./ssl.key --cacert ./ca.cert  --pass 'passphrase' --header "Content-Type: application/json" --data '{"key":"value"}' https://host.com
--

Esta petición no funciona correctamente incluso de forma insegura, agregando la opción -k, por lo que se intenta usar el comando wget para enviar la petición, el problema es que por medio de wget no existe la opción de envío del passphrase, por tanto el paso seria remover este passphrase, lo cual se hace de la siguiente manera:

--
openssl rsa -in ssl.key -out new_ssl.key
--

Ruby on Rails: puma en producción con SSL

Los detalles:

Servidor de producción: Centos 7

Servidor web: Apache 2.4.6

Ruby: 2.4.2

Esta guía es un compendio de varias guías que se pueden encontrar en internet.

Assets

Este archivo es importante para poder cargar los assets.

#/etc/httpd/conf.d/puma.conf

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RequestHeader unset X-Forwarded-Proto
<locationmatch "^/assets/.*$">
	Header unset ETag
	FileETag None
	ExpiresActive On
	ExpiresDefault "access plus 1 year"
</locationmatch>

<locationmatch "^/assets/.*\.(css|js)$">
	RewriteEngine on
	RewriteCond %{HTTP:Accept-Encoding} \b(x-)?gzip\b
	RewriteCond %{REQUEST_FILENAME}.gz -s
	RewriteRule ^(.+)$ $1.gz
</locationmatch>

<locationmatch "^/assets/.*\.css\.gz$">
	ForceType text/css
	Header set Content-Encoding gzip
	Header add Vary Accept-Encoding
</locationmatch>

<locationmatch "^/assets/.*\.js\.gz$">
	ForceType application/javascript
	Header set Content-Encoding gzip
	Header add Vary Accept-Encoding
</locationmatch>

AddOutputFilterByType DEFLATE text/html

Apache

Configuramos el archivo /etc/httpd/conf/httpd.conf:

<VirtualHost 111.222.333.444:80>
ServerName puma.web.com
DocumentRoot /home/puma/public_html/puma/public

include /etc/httpd/conf.d/puma.conf
Redirect permanent / https://puma.web.com/

<Directory /home/puma/public_html/puma/public>
AllowOverride All Options=FollowSymLinks,MultiViews
Order deny,allow
Allow from all
</Directory>
</VirtualHost>


<VirtualHost 111.222.333.444:443>
ServerName puma.web.com
DocumentRoot /home/puma/public_html/puma/public

include /etc/httpd/conf.d/puma.conf
RewriteRule ^/(.*)$ https://0.0.0.0:9294%{REQUEST_URI} [P]

<Directory /home/puma/public_html/puma/public>
AllowOverride All Options=FollowSymLinks,MultiViews
Order deny,allow
Allow from all
</Directory>

SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

SSLEngine on
SSLCertificateFile /home/puma/public_html/puma/FILE.cert
SSLCertificateKeyFile /home/puma/public_html/puma/FILE.key
SSLProtocol +TLSv1.2
SSLCACertificateFile /home/puma/public_html/puma/FILE.crt
</VirtualHost>

Puma

Se tiene que iniciar usando dos puertos uno para http y el otro para https, de la siguiente manera:

puma -d -b "ssl://127.0.0.1:9294?key=FILE.key&cert=FILE.cert&verify_mode=none&ca=FILE.crt" -b "tcp://127.0.0.1:9293" -e production

Cambiando los nombres de los archivo FILE.* por los de su certificado

Los puertos pueden ser cualquiera que no estén siendo usandos, podrían ser el 3000 y 3001 no hay problema.

 

 

 

 

Android: fallan las conexiones

Vamos indicando el entorno, se tiene una app en Android y que hace llamadas de tipo POST a un servidor para obtener datos, el servidor cuenta con SO Centos 6, apache, php 5.6, mysql, un servidor normal.

Lo que sucede, se tiene varios dispositivos de la misma red (6 dispositivos) trabajando con la app al mismo tiempo, cuando ingresa uno nuevo suceden dos cosas.

  • El ultimo simplemente deja de recibir la informacion del servidor por medio de la app.
  • Todas se bloquean excepto el primer dispositivo que uso la app.

Los mensajes de error en adroid son los siguientes:

org.apache.http.conn.HttpHostConnectException: Connection to https://xxx.com/ refused
java.net.SocketTimeoutException: failed to connect to xxx.com/111.222.333.444 (port 443) after 3000ms

La solucion en este caso fue desactivar el TCP timestamps de centos.

echo "0" > /proc/sys/net/ipv4/tcp_timestamps

Apache: KeepAlive On

apache_logo

Un caso de estudio

El servidor

  • Centos 6.
  • Apache.
  • PHP 5.6

Los clientes

  • MAC OS.
  • Windows.

El problema:

Se tiene una aplicacion en PHP sin frameworks mas que uno que otro generador, tablas, formularios, etc.

Cuando dos clientes (en la misma red) con SO MAC OS intentan ingresar a la aplicacion, esta responde correctamente al primer cliente pero con el segundo, se bloquea, y se pone tremendamente lenta, no se corta solo que la carga se pone demasiada lenta. Para los clientes Windows funciona correctamente

Despues de hacer varias pruebas en los clientes, desactivando caches, definiendo DNSs, probando con el TTFB, etc. Se intuye que el problema esta en el servidor.

Revisando la configuracion de Apache, se observa que el parametro KeepAlive  (la misma aplicacion corre en varios servidores y todos los servidores tienen la misma configuracion), se encuentra desactivado, se procede a encender la opcion y… funciona, todo solucionado.

KeepAlive Off

Captura de pantalla 2018-02-19 a las 22.31.45.png

KeepAlive On

Captura de pantalla 2018-02-19 a las 22.33.41.png

 

PHP: error al subir archivos por FTP

php-logo

 

En este caso las características son las siguientes:

  • Servidor CenOS 6 (origen).
  • PHP 5.5.
  • iptables activado.

El script (resumido) que se esta usando para subir el archivo es:

$connection = ftp_connect($hostname, 21);
ftp_login($connection, $user, $password);
ftp_put($connection, $ftp_path, $local_file, FTP_ASCII);

El problema es que el script se detiene en la tercera linea, no se corta ni muestra un mensaje de error y por tanto no se sube el archivo ni termina de procesarse todo el código.

El primer paso seria desactivar iptables y verificar el código:

service iptables stop

Y ahora si, el script funciona perfectamente.

En este caso el problema esta en iptables, probamos que activando el modo pasivo para ftp de la siguiente manera:

modprobe ip_conntrack_ft

Y volver a verificar el script, si funciona entonces agregar el modulo cada vez que se inicie iptables, editar el siguiente archivo:

nano /etc/sysconfig/iptables-config

Y agregar el modulo propiamente dicho:

IPTABLES_MODULES="ip_conntrack_ftp"

Y reiniciar el servicio:

service iptables start