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.

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.

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

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

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.

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

 # lo permitimos todo pa afuera
 ipfw -q add allow all from any to any out keep-state

 # 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

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.

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:

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

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

Por si se me olvida, porque lo he olvidado varias veces. En ocasiones, queremos hacer una simple animación de consola, para representar trabajo de un script sin mostrar lo que está procesando. Este script de ejemplo, itera por cada caracter de la fecha y muestra la barra cambiando de posición, el clásico palito girando.

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

#!/usr/bin/env ruby

# esta es la animación, puedes sustituirla
# por lo que más te guste, solo pon la secuencia
animacion=['|','/','-', '\ '.strip]

for d,i  in Time.now.to_s.chars.each_with_index

   # múeve a la siguiente frama de la animación
   palito=(animacion.push animacion.shift)[0]

   # muestra el palito y has un retorno de carro
   print("#{palito} #{i}\r")

   # has una media
   sleep 0.3

   d=d # nada que hacer con los datos

end

En el array, el último caracter tiene un String#strip porque al escribir \‘ el compilador suele interpretarlo como que estás escapando la comilla simple.

Siempre hay un cliente exquisito que le molesta la aplicación completa en español, a excepción del puñetero paginador que está en inglés.

Como ya no uso kaminari ni will_paginate la cosa se complica. Decidí llamar a todas las tables id=“latabla” y en el application.js, según la documentación de la API de DataTables, le ponemos la clave language con sus pertinentes componentes.

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

$(document).ready(function() {

    $('#latabla').DataTable( {

      "language": {
        "decimal":        ".",
        "emptyTable":     "No hay datos para mostrar",
        "info":           "del _START_ al _END_ (_TOTAL_ total)",
        "infoEmpty":      "del 0 al 0 (0 total)",
        "infoFiltered":   "(filtrado de todas las _MAX_ entradas)",
        "infoPostFix":    "",
        "thousands":      "'",
        "lengthMenu":     "Mostrar _MENU_ entradas",
        "loadingRecords": "Cargando...",
        "processing":     "Procesando...",
        "search":         "Buscar:",
        "zeroRecords":    "No hay resultados",
        "paginate": {
          "first":      "Primero",
          "last":       "Último",
          "next":       "Siguiente",
          "previous":   "Anterior"
        },
        "aria": {
          "sortAscending":  ": ordenar de manera Ascendente",
          "sortDescending": ": ordenar de manera Descendente ",
        }
      }

    } );

} ); // document ready

Claro, realmente no lo hice así, ya que en vez de “Anterior” puse t(:dt_prev) y cree su pertinente fichero de idioma con la traducción, pero escribí esta entrada pensando en gente que puede o no usar RoR. No obstante, el buen desarrollador de rails, sabe que lo correcto sería usar la in API de i18n.

Por suerte, la era de Zentyal está a punto de terminar.

Ahora tenemos tocadores de pfSense, que se creen usuarios de FreeBSD.

Siempre me ha maravillado el criterio de selección tecnológica de la mayoría (NO todos) los cubanos

puro efecto bandwagon

Funciona como especie de moda, donde el software más popular triunfa, simplemente por su popularidad, no por su adecuación, o idoneidad.

Por ejemplo, nginx se puso de moda, porque el jovenclub lo usa. El jovenclub es famoso por sus disparates tecnológicos, pero no importa. ¡Usemos nginx! Antes yo usaba nginx, como proxy inverso, balanceo de carga y servidor web de contenido estático. Entonces yo era “un extravagante”. Ahora todo el mundo usa nginx para TODO. Tipos que AYER tocaron la puntica de nginx, te dicen: “¿aún usas apache?” y te miran como si tú fueras un bicho raro. Curiosamente, la misma mirada que ponían cuando les decías que usabas nginx (además de apache).

Muchos dicen que “systemd es una mierda”, pero al preguntar “por qué”, son pocos los que dan argumentos técnicos que vallan más allá de simple resistencia al cambio. Parece no haber un término medio. Todo es blanco y negro. Nadie dice por ejemplo que systemd es bueno para máquinas de escritorios pero no tan bueno para servidores. NOOoo…

Otro que bien baila es Proxmox. La herramienta de virtualización que ha caído en manos de los mas perezosos como dedo en el anillo. Al parecer soy el único cubano que usa Xen. Actualmente me dicen: “ah! ¿no usas proxmox?”. Pero cuando pregunto: ¿qué tiene proxmox superior a xen? Estoo, es queeee, veráaas, bueeenooo…. Nada, que está moda. La ecuación es simple:

Virtualización = Proxmox

click-click-click-click-click ¡ZAS! Todo está listo!!

Dejaron de usar windows Server (click, click listo!)

Para usar:

Proxmox+Zimbra+pfSense (click, click ¡LISTO! ¡¡¡y además FUNCIONA!!)

¿Cambio de paradigma? ¿Filosofía UNIX? ¿Estilo de trabajo? ¿Teorema de KISS? ¿Software Libre? -pfff, que chiste. Ese tipo está loco, anda con la pila de consolas que parecen salida de la matrix. Nerd!

No saben que demonios es un cortafuegos, no son capaces de elaborar una solución a la medida de su problema y ni siquiera entienden el software que usan pero eso son nimiedades.

Cuando las necesidades tan pecularies de cubita la bella dicen “aquí estoy”, entonces no saben como van a modificar el comportamiento del software para adecuarse a nuestras extravagantes necesidades. Por que hay cientos de menus con cientos de click y checkmarks, pero ninguna hace lo que le exigen al sysadmin cubano.

El servidor de correos, es su mayor dolor de cabeza, pero hay Zimbra. A veces necesitan un servidor SIMPLE o un servidor COMPLEJO, nada que ver con Zimbra y bueno, prueba a ver si iRedMail te lo resuelve.

Ven herramientas como nagios o smokeping, se quedan con la boca abierta, pero ¡joder! es muy complicado, me paso. Al menos, hasta que alguien me de una configuración que funcione y yo cambiarle los valores para que se adecue a mi entorno.

Reza porque todo funcione. Ya que es tanta la ignorancia, que si hay un problema, ni siquiera saben como van a pedir ayuda, porque ni siquiera entienden con que están tratando.

Siempre puedes decirle al jefe “no se puede”. Después de todo, eres un tolerable asalariado y no te pasará nada por incumplir. Le puedes echar la culpa al país que es una mierda por el atraso tecnológico y bla bla bla; todas esas excusas que usan los mediocres de gama alta.

pero tienen más horas de facebook que de consola

Los más triste del caso, es que luego quieren venir a discutir de tecnología y uno no sabe como va a llevar la conversación para no humillarlos.

punto y aparte

Además, están los tipos que Sí SABEN, pero que usan todo eso porque “no tienen tiempo”. Trabajan sentados, el día entero apretando teclas en aire acondicionado y “no tienen tiempo”.

Pierden su tiempo en jugar con toda esta parafernalia modista, para luego darse cuenta que esos sistemas, están incompletos. Les falta algo que ellos ya han hecho mejor y es cuando se dan cuenta, que están andando con juguetes.

para los extremistas

No digo que Zimbra/pfSense/Proxmox sean malos, digo que el método perezoso, es malo.

No puedes comparar la picoloro con la llave inglesa.

Tampoco puedes pensar que solo necesitas una de las dos para hacerlo todo. Ambas son útiles, en su adecuado ambiente y para la tarea que fueron diseñadas.

Antes de emitir un criterio tecnológico, pruebo el software, lo instalo, lo manoceo, trato de romperlo, de ver como funciona, que tiene por detrás; finalmente, que haría yo si quisiera/pudiera mejorarlo. Entonces me hago un criterio.

La gente que me conoces, sabe que aveces digo: “eso es una mierda”. Otros, que me conocen mejor y que hace lo mismo que yo; suelen oírme cuando digo: -eso es una mierda y te contaré como llegué a esa conclusión, ya que seguro que a ti te ha pasado parecido.