El SysAdmin del 3er Mundo

todo lo que expliqué mientras nadie prestaba atención

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 (spot) 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.04 BTC: 1Kg4gu3e7u8HUw8bj5NbBciRg6Y56kuFCU

bind personal

| Comments

Una cosa que me jode, es que linux el tema de los múltiples DNS no los maneje bien. Por ejemplo, estamos en una LAN con red 192.168.1.0/24 y además, tenemos una conexión a internet.

Entonces seteas dos DNS en el resolv.conf y no pincha!

Además, si la situación es itinerante (vas a múltiples LAN) mantener la configuración DNS se vuelve un rollo. Aunque el networkmanager te permita configurarlo, volvemos a la situación anterior.

Solución, tenemos un bin con sus debidos forwarders para cada red. En mi caso, el /etc/named.conf me quedó así:

“/etc/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
// vim:set ts=4 sw=4 et:
options {
        directory "/etc/bind/";
        pid-file "/run/named/named.pid";
        allow-recursion { 127.0.0.1; };
        allow-transfer { 127.0.0.1; };
        allow-update { 127.0.0.1; };
        version none;
        hostname none;
        server-id none;
        recursion yes;
        auth-nxdomain no;
        listen-on { 127.0.0.1; };
};


// la lan por su DNS local
zone "dominio.cu" {
  type forward;
  forwarders { 192.168.1.3; };
};


// lo demás por google
zone "." {
  type forward;
  forwarders { 8.8.8.8; 8.8.4.4; };
};

De esta manera, el dominio de la LAN (dominio.cu), será resuelto a través del servidor DNS 192.168.1.3; que es el de la LAN. Para eso usamos la zona “dominio.cu” del tipo forward y especificamos a 192.168.1.3 como su forward.

El resto, o sea, la zona “.”, será también del tipo forward y para este ejemplo, usamos los dns de google como forward.

Ahora solo te queda actualizar el /etc/resolv.conf y setear a 127.0.0.1 como tu servidor dns

“/etc/resolv.conf”
1
2
# Generated by resolvconf
nameserver 127.0.0.1

Recuerda que cada configuración automatizada, actualiza este fichero. Te recomiendo que no te fajes con el fichero, si no que en cada conexión que desees usar tu servidor, se lo especifiques. Por ejemplo, con networkmanager, le dices a N conexión, que el servidor dns es manual y será 127.0.0.1. Si usas Gnome (NetworkManager), te recomiendo usar la utilidad nm-connection-editor. Te permitirá especificar el dominio de búsqueda, cosa que no he visto como hacer con el administrador de conexiones de gnome.

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

a las puertas del 3g

| Comments

Oficialmente, han anunciado en la mesa redonda que se proveerá internet por 3G.

La noticia me impactó bastante y supongo que todo el que se haga llamar “administrador de red” (en Cuba) se halla sentido conmovido.

A partir de ese día no llevaremos más sobre nuestros hombros la ardua tarea de proveerle internet a una sociedad desconectada. La penosa tarea de explicarle a los usuarios porque fulano sí y tú no. Con ello, nuestra importancia actual en marcos laborales; se verá considerablemente reducida. Ya no seremos las fantásticas criaturas con acceso a internet, si no, un simple operario más (como somos en el mundo entero). Imagino (y espero) que los proxy pasen a ser una segunda prioridad. El uso de internet en las empresas, por fin, será para aquello que realmente fue concebido y no para proveerle facebook a cuatro vacas sagradas.

La introducción de la 3G en cuba, será un cambio. Todos debemos estar preparados para afrontar este cambio; no solo desde el punto de vista tecnológico, si no también social y psicológico. Si dios quiere y todo sale a pedir de boca, caeremos de sopetón y recién llegados; a un mundo donde el internet, ya es algo cotidiano. Todos NO están preparados para esto, en especial, aquellos que tienen canas y teléfonos modernos.

Si bien, las tarifas siguen siendo un misterio por resolver, este es un momento en que no hay lugar para el pesimismo. Nuestro país está haciendo un esfuerzo sin precedentes (al menos en ese aspecto) y nosotros, esperamos lo mejor. Hay mucho optimismo y la gente habla del tema con brillo en lo ojos. Esperamos que esto se materialize y no se convierta en un vaporware. Por otra parte, muchas personas tienen la expectativa muy alta; en especial aquellas que han viajado y conocen el 4g. Esto podría dar lugar a disgustos y desilusiones en aquellas personas que como ya dije “tienen las expectativas muy altas”. Yo solo espero, poder tener internet en mi bolsillo con el salario que me gano.

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

dns con vistas

| Comments

Que lindo corre bind9 en alpine linux. Ahora que mis servidores están todo en el pool de xenserver (los reyes magos me trajeron un servidor pro) tengo un nuevo problema. Dentro de la red interna de xen, los servidores tienen una ip distinta. Por ejemplo, para todo el mundo, el alpine linux que hace de router, es 192.168.0.1, pero para los servidores, es 169.254.0.10

Además, el forward para infomed, es un privilegio que solo los servidores tienen. Por tanto, lo más seguro, será usar una zona para la LAN y otra para la red interna del pool.

Esto me recuerda las DMZ, pero no es lo mismo, porque no estoy creando cuellos de botella. La red interna del pool es una vif, que funciona sin emitir tráfico real por alguna pif.

“/etc/bind/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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
// vim:set ts=4 sw=4 et:

options {

   directory "/etc/bind/";
   pid-file "/run/named/named.pid";
   listen-on-v6 { none; };
   listen-on { 169.254.0.0/16; localhost; 192.168.1.0/24; };
   allow-transfer { none; };
   allow-update { none; };
   version none;
   hostname none;
   server-id none;

   // los servidores hacen recursion
   allow-recursion { 169.254.0.0/16; localhost;};
   recursion yes;

};

view lan  { // la red LAN

   match-clients {192.168.1.0/24;};

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

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

   zone "." {
      type master;
      file "fakeroot.zone";
   };

}; // view lan



view xen { // la red interna de XenServer

   match-clients {169.254.0.0/16; localhost;};

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

   zone "xen" IN {
      type master;
      file "xen.zone";
      notify no;
   };

   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 xen

Como ven, cree el dominio “.xen” que solo será visible a la red interna del pool. La zona “hcg.sld.cu” también será visible para los servidores ya que estos tienen una pata en la LAN; a esto suele llamarse “shared zone” (zona compartida). Finalmente, la zona “sld.cu” (debajo de hcg) es una zona forward en la vista de la interfaz interna.

El host proxy.hcg.sld.cu resolverá una ip de la lan; de esta misma manera, el host proxy.xen, resolverá la ip de dicho host, pero dentro de la red interna del pool.

¿y por qué?

Por que esta menera, solo los servidores (a través de la red del pool), harán forward. Por ejemplo, el servidor de correo, podrá enviar y recibir su correo multipop, ya que el alpine que está haciendo como router, permite forward desde la red del pool hacia la WAN; o sea, todos los servidores, ven a la WAN. Es obligaría al servidor de correo, a usar el dns de infomed para resolver direcciones de infomed y el servidor local para resolver las direcciones de la LAN, lo cual funciona de asco. Sin embargo, la vista del pool tiene una zona forward. Cabe destacar, que una zona forward y un fakeroot, no se por qué; hace que ninguna pinche.

Sensillo y seguro.

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

ipfw simple y conciso

| Comments

Las instrucciones para hacer un cortafuegos realmente SIMPLE y la vez funcional (statefull firewall) con ipfw; sensillamente “no existen”, al menos No de manera oficial. El cortafuegos ejemplificado en el handbook es bastante ortodoxo y no muestra la flexibilidad de ipfw.

Para empezar, el módulo debe ser cargado en el kernel, así que inicializaremos ipfw como si fuera un demonio más del sistema. Esto quiere decir que lo añadiremos al /etc/rc.conf

“/etc/rc.conf”
1
2
 firewall_enable="YES"
 firewall_type="/usr/local/etc/ipfw.rules"

Te recomiendo reiniciar ahora; para que todo se cargue correctamente.

La documentación oficial aclara que los firewall pueden ser (además) del tipo: open, client, simple, closed o UNKNOWN. Sin embargo, en mi opinión estas configuraciones prefabricadas, no son suficiente para un servidor (por ejemplo proxy).

Para mantener la armonía chea y anticuada de freebsd; colocamos el cortafuegos en el etc/ que está bajo /usr/local/. Ten en cuenta que casi todas las aplicaciones que instales, tendrán su /etc ahí.

Reiniciar ipfw no es tan jamón como un usuario de iptables haría. Hacer un flush de las reglas, significa quedarse trancado y perder la conexión por ssh. Para reiniciar el cortafuegos, deberás tener un script que haga flush y además, reiniciar el servicio. Este scriptsito me lo hice para la faena de toquetear el cortafuegos

“/usr/local/bin/reiniciar_ipfw.sh”
1
2
3
4
5
 #!/bin/csh
 service ipfw stop
 ipfw -q flush
 service ipfw start
 ipfw show

La documentación oficial (y otras muchas) indican que cada regla se cree enumerada y que bebes mantener esta numeración manualmente. Sin embargo, esto no es estrictamente necesario. Cada regla incrementará el número de manera implícita.

La mecánica de ipfw es más sencilla que cualquier firewall de linux en mi opinión.

ipfw add accion argumento

Si ya conoces ufw, te darás cuenta de que es una copia bastante mala de ipfw, sobre todo; teniendo cuenta que ipfw es un firewall en sí, mientras que ufw, es un stack que genera instrucciones de iptables.

Algo de lo que linux se ha alejado mucho es el teorema de KISS, pero en BSD, que es unix ortodoxo, mantiene la simpleza como pilar. De esta manera, una acción allow, en su forma más simple, es casi lenguaje natural.

ipfw add allow all from 10.99 to me

O sea, permite todo lo que venga de 10.0.0.1 para mi. Pero podemos hacer algo más discriminatorio.

ipfw add allow tcp from 10.0.0.99 to 10.0.0.1 dst-port 22 in via xn0

Permite el tráfico tcp de 10.99 para 10.1 que valla para el puerto 22 en sentido entrante (in) por la interfaz (via) xn0

¿Te la llevaste? Jamón de pollo! ¿Verdad?

Veamos pues un ipfw.rules bien básico. La interfaz lo0 (lo con un cero) es el localhost. La interfaz xn0 es la WAN y xn1 es la LAN.

“ipfw.rules”
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
 # permite todo por el localhost
 ipfw -q add allow all from any to any via lo0

 # las conexiones que ya estén iniciadas, pásalas
 # compara eso con el de iptables
 ipfw -q add allow tcp from any to any established

 # permite que te hagan ping desde la LAN 
 # pero no mucho icmp para que no hagan flood
 ipfw pipe 1 config bw 30KBytes
 ipfw -q add pipe 1 icmp from 192.168.1.0/24 to me in via xn1
 ipfw -q add allow  icmp from 192.168.1.0/24 to me in via xn1

 # permite que accedan al proxy desde la LAN
 ipfw -q add allow tcp from 192.168.1.0/24 to me 3128 via xn1

 # permite el servidor web pero solo deade la WAN
 # en este caso "me" será la ip de la WAN
 ipfw -q add allow tcp from any to me dst-port 80 via xn0

 # descarta el resto de los paquetes ENTRANTES
 # esta regla casi nunca es necesaria, ya que
 # suele ser implícita, o sea, drop por defecto
 ipfw -q add drop all from any to any

 # finalmente, PA AFUERA, permitimos todo
 ipfw -q add allow all from any to any out

Veamos algunas características de este cortafuegos…

Como ven, no arranca haciendo flush como los de iptables. De hecho, hacer flush como primera linea puede causarte problemas muy serios. Por otro parte, reiniciar el cortafuegos sin hacer flush, provoca que se dupliquen las reglas.

La salida, por definición, está bloqueada. La última regla; autoriza la salida del tráfico. ¿Por qué la última? ¿Por qué no al principio? Pues por si hacemos un pipe de salida. Aveces regular el ancho de banda de salida, es más útil que regular el de entrada. Por ejemplo, si queremos moderar la cantidad de tráfico que un servidor web exporta. Más adelante veremos dummynet y los pipe.

En iptables, hacemos DROP cuando queremos desechar paquetes. En ipfw usamos deny, aunque también puedes usar drop que es sinónimo de deny. El cortafuego lo sustituirá por deny. Lo puedes ver al usar: ipfw show

Note que “from me” para ipfw, significa un paquete que provenga de cualquiera de las ip que tiene configurada el servidor. En este caso, la interfaz xn0 debe tener alguna de la red 192.168.1.0/24 así que me será dicha ip.

Una característica de ipfw bien peligrosa es que tiene muchas cosas implícitas. Como lo de la numeración. Cuando digo implícita me refrito a que si no las pones, ipfw las asume. Fíjate bien como se maneja el tema de los puertos en la siguientes reglas.

“ipfw dst-port”
1
2
3
4
5
6
 # permite que accedan al proxy desde la LAN
 ipfw -q add allow tcp from 192.168.1.0/24 to me 3128 via xn1

 # permite el servidor web pero solo deade la WAN
 # en este caso "me" será la ip de la WAN
 ipfw -q add allow tcp from any to me dst-port 80 via xn0

En la primera regla, declaramos “me 3128”, esto significa “para mi ip por el puerto 3128”. Realmente ipfw lo reescribe (puedes verlo con “show”) y pondrá la cláusula dst-port al igual que la siguiente linea, detrás de me viene la cláusula dst-port seguida por el puerto. Pero si no la pones, se asume como implícita. En poca palabras:

“to me 3128” y “to me dst-port 3128” es exactamente lo mismo.

Otro tema que le retraquetea el mango; es la gestión del ancho de vianda. Porque tc de iproute (en linux) es un asco. Pero si conocemos ipfw, sabremos que maneja el ancho de vianda de una menera muy peculiar; usando un módulo llamado dummynet. No esperes ver la palabra “dummynet” escrita en el cortafuegos. En fin; analiza este ejemplo:

“ipfw y dummynet”
1
2
 ipfw add pipe 1 ip from me to 192.168.1.0/24 out via xn0
 ipfw pipe 1 config bw 128KBytes

Se crea el pipe número 1, con un ancho de banda de 128 KyloBytes. En la regla de arriba, se dijo que todo el tráfico de la interfaz xn0, proveniente de el servidor hacia la red 192.168.1.0/24 y en sentido saliente; será a 128K. O sea, modificamos el ancho de banda que sale del servidor, lo cual es bastante útil para un servidor web o ftp.

En el caso de un servidor proxy, no vale la pena modificar el ancho de banda de salida, ya que las páginas son enviadas al cliente una vez bajadas y si ya nos hicimos el arakiri de bajarla: ¿Pa que demorarlas más? Para un servidor proxy usamos una regla bidireccional. O sea, creamos el pipe 1 y el pipe 2 con igual o diferente ancho de banda y aplicamos una regla pa afuera y otra pa adentro.

Tenga en cuenta que el las conexiones HDSL tiene más ancho de vianda pa abajo que pa arriba. Osea, que salida a la WAN (el router) debe ser más estrecha que salida a la LAN.

En un servidor de correo sí sería útil regular la entrada, ya que hay gente que manda elefantes por el puerto 25. Sobre todo en redes conmutadas o muy lentas. También sería útil moderar la entrada en un servidor que involucre subida de ficheros, por ejemplo, una nube, un servidor de carpetas compartidas.

Ah! por cierto:

Si crearas un pipe y le dijeras que 3 ip, lo usan, el ancho de vianda sería compartido para esas 3 ip. O sea

“ipfw y dummynet”
1
2
3
4
 ipfw add pipe 1 ip from me to 192.168.1.10/24 out via xn0
 ipfw add pipe 1 ip from me to 192.168.1.11/24 out via xn0
 ipfw add pipe 1 ip from me to 192.168.1.12/24 out via xn0
 ipfw pipe 1 config bw 128KBytes

En este caso, 10, 11 y 12, tienen un total de 128KB/s, si 10 acapara todo el ancho de banda (los 128) entonces 11 y 12 tendrán unos bellos timeout como respuesta. Piensa en todo lo que puedes hacer con eso.

OJO CON EL ÓRDEN!!!

Esa regla machea la salida. Si la colocaras debajo de la regla que permite todo hacia afuera, simplemente, no pinchará porque no machea. Coge por la regla de salida y nunca va al pipe. Como diría los yumas “rule of thumbs”

Las reglas que envían el tráfico al pipe, debes ponerlas arriba de la regla “destino final” del paquete.

De esta manera el paquete va al pipe y luego regresa al cortafuegos. O sea, intenta poner siempre los pipe arriba y el cortafuegos abajo

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

mis crónicas con freebsd

| Comments

Si vas a leer este artículo, te aviso, que no tiene nada que ver con el blog. Me dispongo a expresar mi criterio sobre FreeBSD y un tanto de como ha formado parte de mi vida profesional.

FreeBSD, tecnología arcana para algunos y arcaica para otros.

Se cuentan leyendas sobre FreeBSD, como que es el sistema operativo de los nodos y cosas así. Mucha gente lo tiene como un arcano o algo que probarán un día de estos. Yo pienso que no tiene nada del otro mundo. De hecho, en mi opinión, gentoo es más complicado que freebsd.

Lo que si me queda claro que es un excelente sistema operativo para servidores proxy. Además, ipfw, su cortafuegos, es sólido como una piedra. En FreeBSD eso de caer de rodillas ante un ataque DoS, es simplemente utópico.

En ambientes libres de proxy, el binomio dummynet-ipfw permite un manejo del ancho de banda con una simpleza que ya quisiera tc. Un solo pipe puede tener valores diferentes para su ancho de banda, encolamiento y delay.

Por otra parte, el sistema de jails es un batazo. Sobre todo en ambientes donde te ves obligado a meter la pata y no dispones de virtualización. Lo único equivalente a esto en linux, sería LXC, pero no es ni la chancleta. Los jails combinado con ZFS, permiten hacer cosas alucinantes.

Cada versión nueva que sale la pruebo; y aunque había hecho mis cositas con él, siempre acababa dejándolo de lado por el tema del ancho de banda. Cualquier operación que hagas con la paquetería requiere conexión y poco ancho de banda provoca que la operación falle. La versión 9 en mi opinión fue un desastre. Especialmente por el sistema de ports que daba unos palos horribles.

El gestor de paquetes ha mejorado muchísimo. La resolución de dependencias y velocidad es espectacular. Además, han logrado una completa integración de gestión de paquetes en una sola herramienta. Ya no es el reguero ese de pkg_info por un lado y pkg_add por otro. Ahora además, soporta operaciones de limpieza como autoremove y clean. La herramienta portaudit al parecer fue portada a pkg también y ahora es oficial. Otras novedades relevantes son que permite crear respositorios y hacer operaciones en jails. Ah! y para que contarte el soporte de proxy. Más detalles (y una rosetta) lo puedes ver aquí.

FreeBSD 10 no lo toqué, estuve más girado para OpenIndiana.

Pero la versión 7 de OI parecía no terminar nunca. Finalmente el avión no despegó. El fiasco de nexenta store y la insertidumbre de oracle, golpearon fuertemente a la comunidad de OpenIndiana. El mundo se dio cuenta que OI tenía el futuro de un submarino descapotable y gran parte de la comunidad de illumos se mudó pa BSD. La comunidad de OpenIndiana se desmoronaba con las botas puestas. El agitado canal de freenode #openindiana se convirtió en un canal muerto. En lo personal, tras fracasar en mi afán por portar Ruby a OI, en parte debido a que no tengo ancho de banda para hacer operaciones en el Userland; alcé bandera blanca también.

Pero como soy Linuxero! Volví a poner mis servidores en debian y comencé a mirar a fedora. De nuevo el ancho de vianda me golpeó; además de otros avatares de la vida. Terminé usando un chroot de arch, sobre la viejísima instalación de debian en mi laptop Pentium 3 que ya estaba más que obsoleta. Todas mis aplicaciones, mi /home, etc… Eran un chroot de arch dentro de un debian desnudo. Corría i3 y levantaba con startx luego de entrar al chroot.

Free BSD andaba por finales de la 9 y la 10 en el horno; si mal no recuerdo… Yo, me dedicaba a leer noticias y continuaba suscrito a la lista de freebsd en español; donde hacer top-posting se paga con la pena capital.

Mientras tanto, perdía yo mi trabajo y paradógicamente recién adquiría una nueva laptop. Apostar por el recién abierto “modelo de trabajo por cuenta propia”; me costó perder mi empleo y quedarme sentado un buen rato. Instalé ArchLinux en la laptop nueva para conservar las configuraciones de la anterior. Para este entonces me consideraba usuario de archlinux “por casualidad”. Me soñaba como un feliz usuario de Fedora. Consideraba ya a Debian; única y expresamente una herramienta para servidores. Seguía teniendo a FreeBSD en al mira, pero para cuando consiguiera un trabajo con un internet “decente” y tuviera algo de tiempo.

El período más jodido de mi vida estaba aconteciendo en ese momento. No voy a escribir aquí mis problemas personales; pero a modo de resumen diré que la última enfermera que tuve como pareja me calló a tarros y la casa donde nací, la vendieron sin decirme nada. Al estilo país capitalista “me quede en la calle”. Con el ánimo y la autoestima en el piso; el único producto que podía ofrecer eran servidores con debian. A mediados del 2014, empecé en el calixto, de vuelta al trabajo estatal. El ancho de vianda seguía siendo un problema; también el tema de la cuota. FreeBSD seguía “pospuesto pero no olvidado”.

A finales del 2016, me trajeron el servidor de gama media para remplazar el totem de servidores. Además, habían ampliado el susodicho ancho de vianda. Fue entonces cuando decidí, que el nuevo proxy, no podía quedarse mariado como le pasa al squid en linux; muchísimo menos con el micro tan poco potente del servidor (gama media).

Para mi sopresa, FreeBSD andaba por la 11 (yo lo hacía por la 10 todavía) por lo lento que se desarrolla; el pobre. Ahora estoy muy contento con mi squid sobre FreeBSD 11. Que si bien también se marea, lo hace bastante poco y se recupera rápido.

Por lo que veo ya no son tan retrógrados como antes; han mejorado mucho en ese aspecto, aunque siguen siendo una mirada al futuro desde el pasado. Mantienen la onda chea reflejada en su configuración; pero todo bien afinado, fresco y modernizado. Además, la simpleza en un pilar de base en freebsd.

Dejaron de ser retrógrados para convertirse en modernos pero anticuados.

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