blog.ngen.com.ar

Las pelirrojas… Si es pelirroja tetona y con pecas = Nirvana :D

En el ámbito de administración de servidores GNU/Linux, cuando se necesita especificar más de una IP en una interface se recurre generalmente los alias de interface, los conocidos ethx:x.
Aunque funciona perfectamente bien y la administración de las reglas iptables asociadas es relativamente fácil estamos dejando de lado una suma de funciones poderosas a utilizar en un servidor GNU/Linux.
Nunca me gustó utilizar alias, pocas veces lo he necesitado; Ahora justamente tengo en mi empresa un server con Debian “Squeeze” cumpliendo las funciones de gateway, tenemos un enlace dedicado con un pool de 14 IPs públicas y necesito dejar todo listo para un próximo enlace dedicado a la par del actual, utilizar alias realmente me limita en comparación con los beneficios a futuro si utilizo iproute [0].

Tengo hasta el momento 4 interfaces físicas en mi server (eth0=ISP1, eth1=ISP2, eth2=lan, eth3=dmz)

Como por el momento tengo solamente 1 ISP, y estoy utilizando al menos 3 IPs públicas del pool disponible y en el futuro inmediato necesito:

• balanceo de carga
• Wan failover
• traffic shapping
• múltilples rutas entre la (dmz, openvpn, lan, internet, etc)

La solución es integrar iproute con la estructura de networking en Debian.

Debian utiliza el archivo /etc/network/interfaces para definir el estado de las interfaces y sus IPs, en este caso en particular definimos las IPs utilizando iproute, debemos cambiar entonces el comportamiento modificando algunos valores.

He aqui un ejemplo típico (las IPs son ficticias)

1
2
3
4
5
6
7

auto eth0
iface eth0 inet static
        address 190.139.257.1
        netmask 255.255.255.240
        network 190.139.257.0
        broadcast 190.139.257.15
        gateway 190.139.257.14

auto eth0
iface eth0 inet static
        address 190.139.257.1
        netmask 255.255.255.240
        network 190.139.257.0
        broadcast 190.139.257.15
        gateway 190.139.257.14

Utilizando iproute cambiamos el valor inet a “manual” quedando como el ejemplo que sigue.

1
2
3
4
5
6

auto eth0
iface eth0 inet manual
        pre-up ip link set eth0 up
        post-up ip addr add 190.139.257.1/28 dev eth0
        post-up ip addr add 190.139.257.2/28 dev eth0
        post-up ip route add default via 190.139.257.14 dev eth0

auto eth0
iface eth0 inet manual
        pre-up ip link set eth0 up
        post-up ip addr add 190.139.257.1/28 dev eth0
        post-up ip addr add 190.139.257.2/28 dev eth0
        post-up ip route add default via 190.139.257.14 dev eth0

Para confirmar que las IPs esta correctamente configuradas, iproute nos provee con el comando “ip” para verificarlo

12
3
4
5
6
7

root@cerberus:~# ip addr show eth02: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:7d:ea:f6:00 brd ff:ff:ff:ff:ff:ff
    inet 190.139.257.1/28 scope global eth0
    inet 190.139.257.2/28 scope global secondary eth0
    inet6 fe80::2e0:7dff:feea:f600/64 scope link
       valid_lft forever preferred_lft forever

root@cerberus:~# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:7d:ea:f6:00 brd ff:ff:ff:ff:ff:ff
    inet 190.139.257.1/28 scope global eth0
    inet 190.139.257.2/28 scope global secondary eth0
    inet6 fe80::2e0:7dff:feea:f600/64 scope link
       valid_lft forever preferred_lft forever

Eso es todo, posteriormente se puede agregar a las lineas de /etc/network/interfaces todo lo que necesitemos aplicar con iproute (rutas extras, traffic shapping, etc)

[0] http://lartc.org

Despues de haber estado 3 semanas sin el servidor (por baja del servicio donde estaba alojado) me armé un nuevo server en el cual instalé el flamante y recién estrenado Debian GNU/Linux “Squeeze”.
Me falta poner en linea de mi qmail y listo! (estimo hacerlo este fin de semana)

Es importante poder acceder al administrador de wordpress mediante https, nos garantiza que cuando hacemos login nuestro user & pass no van en texto plano hasta el servidor.

En mi blog, que utilizo wordpress + nginx y debo asegurarme que todo funcione perfectemente; Desde la versión 3.x de Wordpres ha cambiado el método a utilizar, a pesar de que aún la documentación oficial [0] es vieja y no tiene aplicación hoy en dia, les daré algunos tips para poder publicar el /wp-admin sobre ssl y con nginx como webserver.

wp-includes/default-constants.php
El archivo implicado, en mi caso el path es: /var/www/ngen.com.ar/blog/wp-includes/default-constants.php donde deben buscar el valor define(‘FORCE_SSL_ADMIN’, false); y cambiarlo a true.

1
2
3

        if ( !defined('FORCE_SSL_ADMIN') )
                define('FORCE_SSL_ADMIN', true);
        force_ssl_admin(FORCE_SSL_ADMIN);

        if ( !defined('FORCE_SSL_ADMIN') )
                define('FORCE_SSL_ADMIN', true);
        force_ssl_admin(FORCE_SSL_ADMIN);

Importante!
Cada vez que actualizen WordPress desde el dashboard este archivo se sobreescribe con la configuración por defecto que es “false”, asi que deben volver a editarlo y cambiar el valor para aplicar nuevamente los cambios.

Configuración nginx
No voy a explicar aqui cómo es la configuración global de nginx y dado que publico mi blog como /blog en nginx la configuración es asi:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

        location /blog {
                root   /var/www/ngen.com.ar;
                index   index.php;
                }
 
        access_log  /var/log/nginx/blog.access.log;
        error_log      /var/log/nginx/blog.error.log;
 
        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/ngen.com.ar/blog$fastcgi_script_name;
                include        fastcgi_params;
                }
 
        # rewrite wp-admin to https
        location ~ wp-login.php$ {
                rewrite ^/wp-login.php(.*)$ https://$host/$1 last;
                }

        location /blog {
                root   /var/www/ngen.com.ar;
                index   index.php;
                }

        access_log  /var/log/nginx/blog.access.log;
        error_log      /var/log/nginx/blog.error.log;

        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/ngen.com.ar/blog$fastcgi_script_name;
                include        fastcgi_params;
                }

        # rewrite wp-admin to https
        location ~ wp-login.php$ {
                rewrite ^/wp-login.php(.*)$ https://$host/$1 last;
                }

No tiene nada fuera de lo común, salvo las lineas donde especifico con rewrite que todo lo que sea ^/wp-login.php lo envié al mismo host pero bajo https.

Tambien debemos configurar el mismo virtualhost en nignx pero con el puerto 443 que en este caso los datos incorporan mas información.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

        ssl  on;
        ssl_certificate         /etc/nginx/ssl/server.crt;
        ssl_certificate_key     /etc/nginx/ssl/server.key;
 
        access_log      /var/log/nginx/wp-admin.access.log;
        error_log      /var/log/nginx/wp.admin.error.log;
 
        location /blog {
                alias   /var/www/ngen.com.ar/blog;
                index  index.php;
                }
 
        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/ngen.com.ar/blog$fastcgi_script_name;
                include        fastcgi_params;
                }

        ssl  on;
        ssl_certificate         /etc/nginx/ssl/server.crt;
        ssl_certificate_key     /etc/nginx/ssl/server.key;

        access_log      /var/log/nginx/wp-admin.access.log;
        error_log      /var/log/nginx/wp.admin.error.log;

        location /blog {
                alias   /var/www/ngen.com.ar/blog;
                index  index.php;
                }

        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  /var/www/ngen.com.ar/blog$fastcgi_script_name;
                include        fastcgi_params;
                }

Eso es todo, desde ahora cada vez que quiero acceder al admin del wordpress desde http://ngen.com.ar/blog/wp-admin me redirecciona automáticamente hacia https://ngen.com.ar/blog/wp-admin/

[0] http://codex.wordpress.org/Administration_Over_SSL

Desde unos dias atrás que tengo en mi poder un nuevo integrante tecnológico en casa, compré a un amigo un Cisco 1721.
Lo obtuve con el objetivo de certificar CCNA de una vez por todas en Febrero/Marzo (cortesía de mi empresa) eso determina que me pasaré el verano estudiando y repasando toda la currícula de Cisco para preparar el examen.

Tengo que conseguir un módulo de expansión extra para poder tener algunos ethernet más, el que me interesa es este:
http://www.compucanjes.com/products/view/11625.html dependiendo entonces de qué tan maltrecha tenga mi economía despues de fin de año le pediré a los reyes que me traigan una :D

O sea, no tendré vacaciones hasta Abril/Mayo como mínimo, mucho mejor asi me voy en invierno a Mendoza :D