El SysAdmin del 3er Mundo

todo lo que expliqué mientras nadie prestaba atención

rainloop en debian

| Comments

Aún recuerdo que algunos clientes me preguntaban con mucho asombro: “-y porque no roundcube”; cuando hablábamos de webmail. Pero finalmente rainloop se ha puesto de moda en cuba.

Un método bastante perezoso de instalar una LAMP en Debian, es instalar el paquete phpmyadmin. Esto instala y configura el servidor SQL; además de hacer jugar a apache2 con php y mysql, todo de un solo teclazo. Pero aveces, por ejemplo, al instalar RainLoop, no queremos que phpmyadmin quede instalado. Una buena variante es desinstalarlo después; pero nos quedan algunos paquetes innecesarios instalados.

Para lograr la armonía que buscamos, instalaremos la LAMP por partes. Primero apache SOLO.

1
 aptitude install apache2

Ahora instalamos mysql, a través de los metapaquetes, para que se instale el adecuado de manera automática.

1
 aptitude install mysql-server mysql-client

Llegado a este punto, debian y su magia te ayudarán a configurar el mysql, pidiéndote la contraseña del root. Ahora instalamos la piedra angular. El soporte de php+mysql de apache.

“soporte de mysql”
1
 aptitude install php5 libmysqlclient-dev php5-mysql

Instalamos el resto de la paquetería necesaria para rainloop.

“paquetería de rainloop”
1
 aptitude install curl libcurl3 libcurl3-dev php5-curl php5-json

Ahora reinicia tanto apache como mysql.

1
2
 systemctl restart mysql
 systemctl restart apache2

Crearemos un par de bases de datos necesarias para rainloop. Puedes o no crear un usuario para rainloop, pero si vamos a tener un servidor sql con dos bases de datos para una aplicación; la cual además, será la única cosa sql en el servidor; no vale la pena crear otro usuario. Lo dejo a tu elección.

“creando las bases”
1
2
3
4
create database rainloop;
create database contactos;
commit;
exit;

Si de todas maneras quieres crear el usuario.

“un usuario pa rainloop”
1
2
3
4
create user rainloop@localhost identified by "rainloop";
grant all privileges on rainloop.* to rainloop@localhost;
flush privileges;
exit;

Y vamos a instalar rainloop! La manera clásica de hacerlo es usando el paquete “.zip” del sitio. Si quieres llégate allá y bájatelo. Descomprimes en un directorio y sigue las instrucciones; sin embargo hay otra manera.

“alando rainloop del repositorio”
1
2
3
mkdir -p /var/www/rainloop
cd /var/www/rainloop
curl -s http://repository.rainloop.net/installer.php | php

Si tienes acceso a internet de verdad. Pinchará. Si estás detrás de un proxy, te jodiste, hazlo a la manera ortodoxa.

Rainloop es fulísima con los permisos. Si no los tienes claros, dará unos palos horribles que no tienen nada que ver con permisos aparentemente. Por ejemplo, si el fichero que dice la versión, no pertenece al usuario que corre el servidor web, te dirá que no puede encontrar el directorio “data”. Espectacular! Para evitar eso, solo los directorios tendrán el ejecutable. Además, todo pertenecerá al usuario www-data; que en debian es el usuario que usa el apache para correr.

“estableciendo permisos”
1
2
3
chown -R www-data:www-data .
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

No te pondré como hacer el virtualhost porque eso no tengo que explicártelo (no te hace falta verdad?). Te recomiendo que uses SSL.

No olvides entrar al admin panel (o al fichero de configuración) de rainloop y pasarle la mano. Para abrir el admin panel, usa la url /?admin. Ahí configura las bases de datos. Muy importante habilitar el soporte de contactos y especificarle la base de datos, que creo, no debe ser la misma que rainloop; aunque una gente me dijo que tiene ambas cosas en la misma base de datos; yo no le he probado.

El usuario por defecto es admin y la contraseña es 12345. De más está que te diga: CÁMBIALO!

Si estás de cara a internet, recuerda que rainloop viene con yahoo y gmail configurado como servidores por defecto. No sé si está habilitados pero chequéalo. Juraría que hay versiones en que venía habilitado. De todas formas, te interesará que tus usuarios tengan gmail/yahoo más cerca, especialmente si un usuario tiene múltiples identidades. Recuérdales que deben habilitar el acceso pop en su cuenta de gmail.

Si este artículo te resultó interesante, considere donar 0.05 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

nginx y websocket

| Comments

Resulta que los websocket no pasan tan fácilmente por el proxy inverso. Llevan su burumba.

Aquí por ejemplo, haremos un proxy inverso con SSL para una aplicación que escucha por el puerto 8888.

“nginx”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
server {
   listen 80 default_server;
   return 301 https://$host$request_uri;
}


server {
  listen 443 ssl default_server;
   ssl_certificate /etc/nginx/nginx.crt;
   ssl_certificate_key /etc/nginx/nginx.key;
   location / {
      proxy_set_header        Host $host;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_pass http://127.0.0.1:8888/;
      proxy_http_version 1.1;
      proxy_set_header Connection "upgrade";
      proxy_set_header Upgrade $http_upgrade;
      proxy_redirect default;
      proxy_read_timeout 1800;
      client_max_body_size 128G;
   }
}

Note como los encabezados Upgrade son seteados. Ese es el truco…

Si este artículo te resultó interesante, considere donar 0.06 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

pkg tras un proxy

| Comments

En el 5to infierno de infomed, con la vida detrás del proxy que ya he mencionado incontables veces; todo se vuelve difícil.

Por suerte freebsd ha mejorado en materia de soporte de proxy. Si bien en csh, basta con usar:

“setenv”
1
2
setenv http_proxy http://proxy.sld.cu:3128
setenv https_proxy $http_proxy

Operaciones de rutinas como pkg audit -F suelen fallar al ser ejecutadas por el cron. Setear el proxy de manera global es una opción; pero nunca ha sido de mi agrado. Por suerte, el nuevo gestor de paquetes de freebsd soporta proxy en su configuración.

El fichero de configuración está en una ubicación bien extravagante. Nada menos que en /usr/local/etc/pkg.conf. Los comentarios hablan por si solos, vale la pena mirarlos; no necesitarás leer manual ni buscar en google para darte cuenta que:

“/usr/local/etc/pkg.conf”
1
2
3
PKG_ENV : {
   http_proxy: "http://proxy.sld.cu:3128",
}

¡Establece el proxy!

Con eso pkg audit corrido desde el cron funcionará perfectamente. Además de las demás operaciones que requieran bajar contenido de internet; claro está.

OJO! Nota que al final de la declaración del proxy, lo que hay es una coma, NO un punto y coma. La configuración parece ser un json.

Si este artículo te resultó interesante, considere donar 0.08 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

portknocking en freebsd

| Comments

La técnica port-knocking o knockd para otros, es en mi opinión, pilar de la seguridad en cualquier servidor que use SSH. Aunque es bastante versátil y puede ser usado hasta para reiniciar servicios sin loguearte.

Una de las cosas que empece a extrañar en FreeBSD fue knockd, pero gracias a la flexbilidad de ipfw, podemos usar este poderoso software. En FreeBSD el fichero se encuentra en /usr/local/etc/knockd.conf.sample y el paquete se llama knock.

OJO!! Muy importante especificarle la interfaz por la cual va a escuchar.

“/usr/local/etc/knockd.conf”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 [options]
         logfile = /var/log/knockd.log
         interface = xn0

 [openSSH]
         sequence    = 111,222,333
         seq_timeout = 9
         command     = /sbin/ipfw -q add 00001 allow all from %IP% to me
         tcpflags    = syn

 [closeSSH]
         sequence    = 222,111,333
         seq_timeout = 9
         command     = /sbin/ipfw -q delete 00001
         tcpflags    = syn

Nada, resumiendo, que el truco está en poner la regla con el número 00001. Recuerdas que ipfw te permite (casi te obliga a) especificar un número para cada regla. Pues usaremos ese numerito diminuto para ponerla de primera.

Los tipos ortodoxos criticarán que es una regla al tetón. Pienso que no vale la pena abrir solo el 22; si voy a pasar tanto trabajo, que se me abra la puerta completa.

Por cierto, junto con knock, viene un programita para hacer el knocking. Yo solía hacerlo con netcat pero knock es más cómodo.

“knock”
1
   knock 192.168.3.1 111,222,333

En mi .bashrc, tengo esta función declarada.

“.bashrc”
1
2
3
4
5
 abrete_cesamo() {
    knock  $1 111 222 333
    ssh root@$1
    knock  $1 222 111 333
 }

No tengo que decirte que la combinación de puertos está de acorde al ejemplo de la entrada y que debes cambiarla por la que tu establezcas. Así de esa manera, hacerle SSH a un servidor es ejecutar abrete_cesamo ip.del.servidor Luego al terminar la sesión ssh, se ejecuta la secuencia de cerrado.

Y hablando de implementaciones raras de knockd!

En alpine linux, iptables está en /sbin, no en /usr/sbin. Sin embargo, el fichero de configuración tiene puesto que está en /usr/sbin/, lo cual, repito; no es correcto.

Además, tanto en debian como alpine. No importa que pongas en la configuración porque interfaz escuchará. Siempre lo hará por eth0. Para cambiar esta situación; debes:

En alpine linux, configurar la interfaz en el fichero /etc/conf.d/knockd

En debian, configurar la interfaz (y poner un 1) en /etc/default/knockd

Recuerda que en linux, el comando de iptables, viene con “-A INPUT”. Si tienes un firewall corriendo, obviamente que no pincha; por tanto, ponlo con “-I INPUT”.

Si este artículo te resultó interesante, considere donar 0.04 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

bind en infomed

| Comments

Seguimos con bind…

No hace mucho le comentaba a alguien, a raíz de una duda que tenía el colega Paradyx; la manera correcta de configurar un servidor bind para una red que cuelga de infomed.

Le comentaba que no vale la pena usar un forward por defecto; que hacer del dominio ‘.sld.cu’ una zona forward sería más que suficiente. Digo esto porque infomed no resuelve ningún dominio que valla más allá de “.sld.cu”, por tanto, no vale la pena transferirle las sepetecientas peticiones que hacen cuanta mierda se conecta a nuestra red (especialmente android).

“named.conf”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
options {
   directory "/etc/bind/";
   pid-file "/run/named/named.pid";
   listen-on { 10.1.1.1; localhost; };
   allow-transfer { none; };
   allow-update { none; };
   version none;
   hostname none;
   server-id none;
};


view lan {

   match-clients {10.1.1.0/24;};

   zone "localhost" IN {
      type master;
      file "localhost.zone";
   };

   zone "hcg.sld.cu" IN {
      type master;
      file "hcg.zone";
      notify no;
   };

   zone "sld.cu" {
      forwarders { 201.220.222.131; 201.220.222.132; };
      type forward;
      forward only;
   };

}; // view lan

Como mi dominio es hcg.sld.cu (subdominio de .sld.cu) lo declaramos ARRIBA del dominio sld.cu. El dominio hcg.sld.cu es una zona master, sin embargo, el dominio sld.cu es del tipo forward y entonces ahí declaramos los forwarders (los dns de infomed).

Así solo le reenviaremos a infomed, aquellas peticiones que sean para infomed.

En mi opinión esto no es necesario. Tanto así, que la zona donde infomed hace forward; la tengo para los servidores. En el caso de la zona para LAN, simplemente declaro los servidores de correo en un fakeroot y listo.

Si este artículo te resultó interesante, considere donar 0.06 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

QoS con tc o dummynet

| Comments

Acá en el 5to infierno de infomed, algunos usuarios; están acostumbrados a usar un “MUA” (léase “cliente de correo”) para alar el correo de infomed. Con el boom de la wifi, los médicos querían tener su correo de infomed en el puñetero cliente de correo de android/ios. Tras hacer un forward a los smtp y pop de infomed, el ancho de vianda se fue a la mierda. Por tanto, surgió la necesidad de chapiar el tráfico que va desde/hacia infomed. Por ejemplo, el tráfico smtp, es saliente (subida), sin embargo, el tráfico pop es entrante (bajada).

El servidor que uso como “router”, es un alpine linux. El trinomio bind, dhcp e iptables, sumado al kernel grsec; convierte en mi opinión a alpinelinux en la mejor opción para un router.

Entrando en materia. Tenemos un canal de 2 megabit (256 KB/s). Pero en HDSL, la subida es más triste que la bajada; y además, hay más gente bajando correo que subiendo. Por tanto, usaremos un canal para el smtp, más estrecho que el del pop. En este caso, eth0 será la interfaz donde está el router.

“tc del firewall”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# reiniciamos las colas que hallan en eth0
# para empezar a trabajar en limpio
tc qdisc del root dev eth0
tc qdisc add dev eth0 root handle 1: htb default 30

# un canal de 256 KB/s lo partimos en dos
# una fracción de 10 KB/s y otro de 20KB/s
tc class add dev eth0 parent 1:  classid 1:1  htb rate 256kbps burst 5k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate  20kbps burst 5k
tc class add dev eth0 parent 1:1 classid 1:11 htb rate  10kbps burst 5k

# lo que valla para el pop e imap, lo dejamos en el :10 con 20kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 201.220.211.7 match ip sport 110 0xffff flowid 1:10
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip src 201.220.211.7 match ip sport 143 0xffff flowid 1:10

# lo que valla por el smtp, en el :11 de 10kbps
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dst 201.220.211.39 match ip dport 25 0xffff flowid 1:11

Note como en el caso de lo que venga del “.7”, (src) de los puertos pop e imap (sport) pasarán por la cola 1:10. Mientras que en el “.39”, se usan las cláusulas dst y dport.

pero aquí NO terminan las aventuras de QoS

Resulta que el tráfico proveniente de las WiFi era apabullante para el servidor proxy. Mientras que de una IP de una máquina entran 3 peticiones, de la IP de un router wifi entran 30.

En un principio pensaba usar un delay_pool especial para estas ip, pero sería complicar más el esquema de delay_pool que funciona bien por usuarios. Por tanto, el tema de la bajada ya está cubierto. Ningún usuario puede acaparar todo el ancho de banda con una descarga. Sin embargo, 1’000 peticiones de basura (android con proxy configurado) ahogan al proxy. La medida fue, que el tráfico entrante de la wifi, no exceda los 200KB.

En mi caso, los AP usan la ip 10 al 15, por tanto, haciendo un pipe de dummynet y metiéndolos a todos en ese pipe: -que se fajen por los 200KB!

“ipfw.rules”
1
2
3
4
5
6
7
ipfw pipe 1 config bw 200KBytes
ipfw add pipe 1 ip from 10.1.1.10 to me
ipfw add pipe 1 ip from 10.1.1.11 to me
ipfw add pipe 1 ip from 10.1.1.12 to me
ipfw add pipe 1 ip from 10.1.1.13 to me
ipfw add pipe 1 ip from 10.1.1.14 to me
ipfw add pipe 1 ip from 10.1.1.15 to me

Si este artículo te resultó interesante, considere donar 0.08 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU