Recién terminé el servidor de LTSP; pero aún estoy como niño con juguete nuevo, viendo que otra gangarrea le puedo poner. En la lista de GUTL un colega me comentó que sería bueno darle explotación a ambas tarjetas de red. Enseguida dijo lo primero en que piensan mis coterráneos, un proxy. Yo le comenté que le había hecho un bonding, operación a la cual yo denomíno “albóndiga” y consiste en levantar una interfaz de red especial que usa dos tarjetas de red como si fueran una.

Esto; para un servidor de tanto tráfico como es el caso de ltsp, es un verdadero batazo. Otros colegas parecieron sorprendidos al ver tal cosa y me pidieron que escribiera un tutorial de como hacerlo; sobre todo para que llegase a aquellos que no tienen internet.

Instala un paquete llamado ifenslave

1

aptitude install ifenslave

Luego declaras en “/etc/network/interfaces” una interfaz llamada bond0 en la cual declaras que interface quieres unir.

A mi me quedó así:

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

root@ganker:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback


auto bond0
iface bond0 inet static
    address 10.1.1.3
    netmask 255.255.255.0
    network 10.1.1.0
    gateway 10.1.1.1
    dns-nameservers 10.1.1.1
    dns-search hcg.sld.cu
    slaves eth0 eth1
    bond_mode 2

Donde eth0 y eth1 son las interfaces que se unirán. Eso es todo…

OJO! Si tienes un cortafuegos que involucre reglas de interfaces, ya tienestarea pa la casa.

Problema

21 de Mayo: La situación de los clientes ligeros en el Calixto no da más. El servidor DHCP del ardence dejó pinchar sin previo aviso. El encargado de los clientes ligeros, reinstaló todo y siguió sin pinchar. Luego determinó que era culpa de un virus. El incha-cojones de Windows vuelve a hacer de la suya. Mientras tanto, el caos se ríe de todos y se frota las manos.

A la novena llamada preguntando “cuando se arreglan los clientes ligeros” determiné que la situación llevaba medidas drásticas, siendo hora de pasar el servidor al lado oscuro de la fuerza.

Plan de migración: El miembro sobre la mesa.

Tiempo estimado: Menos del que te imaginas.

Por un lado, 6 clientes ligeros con un windows XP que se arrastra en los 128 megas de RAM y un servidor dongan de manufactura vietnamita. Por el otro, más de 6 usuarios quejándose porque su sistema funciona lento, cuando le da la gana y además deben reiniciar más de 10 veces al día. Eso sin contar que deben tener la información en memorias flash, porque no se guardan los cambios en las imágenes.

Solución

Linux Terminal Server Project, más conocido como “LTSP”.

Instalar ltsp es un proceso relativamente fácil, sobre todo cuando tienes un tubo de internet a full.

Pero detrás del proxy satánico de infomed; la cosa se vuelve un tanto compleja.

Por suerte, el repo de debian en infomed está bien afinadito y ahora con el tubo de 2 megas, la cosa mejora considerablemente.

Hay dos maneras de hacer esto, la fácil y novel; o la difícil y tediosa. En caso de la fácil, bastará con instalar el paquete “ltsp-server-standalone”; el cual instalará y configurará todo la orquesta de software requerido para pinchar lo que se conoce como ltsp. Entre ellos, el servidor dhcp de ics, el servidor tftp-hpa, la maritrónica que sirve la SWAP por nfs y todo el rebortillo de cosas que requiere NFS.

Corre esto y ponte cómodo, que va pa largo…

1
2
3
4

 ltsp-build-client --http-proxy http://127.0.0.1:3128 \
 --mirror http://ftp.sld.cu/debian \
 --security-mirror http://ftp.sld.cu/debian-security \
 --copy-sourceslist --copy-package-cache --accept-unsigned-packages

El comando que corriste, generó un fichero de configuración para el servidor dhcp de isc. Te sugiero que lo uses como DHCP.

1
2

cp /etc/ltsp/dhcpd.conf /etc/dhcp/dhcpd.conf
systemctl restart isc-dhcp-server

Muy importante NFS. En el fichero /etc/exports ponemos esto:

1

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

y reiniciamos el servicio de NFS

1

systemctl restart nfs-kernel-server

Cuando butees una máquina, el login no te pinchará. Deberás correr esto:

1
2

ltsp-update-sshkeys
ltsp-update-image --config-nbd

La imagen que se instaló en /opt no es más que la matriz para crear un squashfs que se le sirve a los clientes. Con ese comando, reflejamos los cambios volviendo a crear la imagen “squashada”.

Con eso te digo que si haces un cambio en la imagen, deberás correr ese comando.

Ahora bien. Para que no queden lagunas mentales:

Todo lo que tendrán los usuarios, ESTÁ EN EL SERVIDOR

Por tanto, hay que instalar una interfaz visual EN EL SERVIDOR. Será lo que los clientes pinchen. Por supuesto, no necesariamente el servidor tiene que correr dicha interfaz. En mi caso yo instalé solo sistema base y luego corrí esto:

1

aptitude install task-lxde-desktop

Ahora el servidor está equipado con una interfaz visual, pero no la pincha, ya que no le instalamos ningún “display manager”; por tanto, las X no arrancan. El display manager lo tiene la imagen que levantan los clientes; nada menos que LDM.

Los clientes levantan un LDM e inician sesión remota en el servidor.

¿se entendió?

Toas las instrucciones que cargará esta interfaz gráfica minimalista (el LDM de los clientes ligeros), se declaran en el fichero /opt/ltsp/i386/etc/lts.conf a mi me quedó así la primera versión de este fichero.

1
2
3
4
5
6

[default]
    LTSP_CONFIG=True
    SOUND=True
    LOCALDEV=True
    CONFIGURE_X=True
    LDM_SESSION=/usr/bin/startlxde

Dice que está configurado, que tiene sonido, que use dispositivos locales, que configure las X dinámicamente y que arranque lxde como sesión por defecto.

Y ahí empezaron mis problemas. En mi caso, las canchanfletas que usé como clientes ligeros, tenían una tarjeta de video unichrome más extraña que un calsoncillo con tirantes. La pantalla se veía con una capa verde delante. Nunca había visto cosa igual.

Solución. Levanta un cliente ligero, entra en la consola (con Ctrl+Alt+F1) y ejecuta:

1

X -configure

Eso te creará el fichero xorg.conf.new EN EL CLIENTE. A ese punto, se habrá generado una configuración de X decente. Pero ese fichero hay que ponerlo EN EL SERVIDOR:

1

scp xorg.conf root@servidor:/opt/ltsp/i386/etc/X11/xorg.conf

Ahora además, al servidor hay que especificarle que las X NO se auto-configuren y que en cambio, usen el fichero dado. Todo eso lo haremos en /opt/ltsp/i386/etc/lts.conf

1
2
3
4
5
6
7
8
9
10

[default]
    LTSP_CONFIG=True
    SOUND=True
    LOCALDEV=True
    LDM_SESSION=/usr/bin/startlxde
    CONFIGURE_X=False
    X_CONF=/etc/X11/xorg.conf
    X_MODE_0=1024x768
    MODULE_01 = "usb-storage"
    MODULE_02 = "sd_mod"

Dice ahora que: Está configurado, tiene sonido, dispositivos locales (pa que pinchen las memorias flash), que levante lxde, que NO configure las X, que use el fichero dado, que la resolución de su pantalla 0 (la única) es de 1024x768 y además que meta ese par de módulos, pa que pinchen los puertos USB.

Por supuesto, en el chroot que levanta el cliente, la ruta absoluta /etc/X11/xorg.conf es completamente válida.

¡¡Ah, y no olvides volver a crear la imagen!!

pero de vuelta al servidor

Entre los palos más comunes, vemos uno que al iniciar la sesión dice que el usuario “fulano” no pertenece a netdev y que por tanto, el puñetero data-bus no arranca.

1
2

adduser fulano netdev
systemctl restart dbus

En el fichero /etc/adduser.conf puedes especificar los parámetros de los nuevos usuarios creados, ahí puedes declarar que se creen con sus pertinentes grupos.

1
2
3
4
5

# Set this if you want the --add_extra_groups option to adduser to add
# new users to other groups.
# This is the list of groups that new non-system users will be added to
# Default:
EXTRA_GROUPS="dialout cdrom audio video plugdev users netdev netdev messagebus pulse lpadmin"

El directorio /etc/skel/ contiene la plantilla para crear el nuevo usuario. Crea un usuario, has la configuración que desees y cópialo pa /etc/skel.

Otro palo común es que las memorias NTFS se montan como solo lectura. Solución, instala ntfs-3g EN EL CHROOT que está en /opt y vuelve a crear la imagen.

Nota para los mentequieta:

Los usuarios se crean EN EL SERVIDOR no en la imagen.

Sugerencias

Cada cosa que los clientes ejecuten, lo harán en el servidor, y puedes ponerte a mirar con htop que proceso se está metiendo la RAM o el CPU, detener dicho proceso y requerir al usuario. Porque verás los procesos y el usuario que lo ejecuta. Déjame recordarte que Linux, es un sistema multitarea y multiusuarios de verdad.

En mi caso, el servidor (los “dongan” vietnamitas) tiene dos discos duros. Monté uno para el sistema y la swap, el otro lo dejé para el /home.

Mi servidor tiene 512 de RAM y aún con 4 clientes ligeros no ha llenado la mitad de la memoria. ¿Dime tu con 1 Giga de RAM?

Por defecto, los homes de los usuarios se crean con permisos que los hace visibles entre si. Ejecuta: “chmod 770 /home/fulano” cada vez que crees un usuario. Si no, el home de este usuario será visible por los demás usuarios.

¿Has pensando que ahora es más fácil hacerle salvas a las cosas? Todo está en el /home.

No olvides decirle al usuario que ahora pueden hacer y guardar cambios en su “perfil” (como ellos le llaman) pues algunos están acostumbrados a que el cliente ligero No guarda cambios.

Puedes decirle a tus usuarios que su perfil puede ser abierto desde cualquier cliente ligero de la flota. Lo cual les da cierta “movilidad”.

Puedes decirle que si su cliente ligero se rompe no se preocupe, que su información está a salvo. Incluso, le recuerdas además que puede abrir su perfil desde otro cliente ligero que esté en la misma flota.

Puedes hacer configuraciones individuales de cada máquina en el fichero /opt/ltsp/i386/etc/lts.conf

En donde dice [default] puedes poner la MAC del cliente.

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

# configuración genérica
[default]
    LTSP_CONFIG=True
    SOUND=True
    LOCALDEV=True
    LDM_SESSION=/usr/bin/startlxde
    CONFIGURE_X=False
    X_CONF=/etc/X11/xorg.conf
    X_MODE_0=1024x768
    MODULE_01 = "usb-storage"
    MODULE_02 = "sd_mod"

# configuración de un cliente individual el
# jefe no quiere que oiga música ni use
# memorias flash
[00:90:4b:a2:55:05]
    LTSP_CONFIG=True
    SOUND=False
    LOCALDEV=False
    LDM_SESSION=/usr/bin/startlxde
    CONFIGURE_X=True
    X_MODE_0=1024x768

# EOF

Una buena idea, es usar un dhcp con las MAC e ip fijas para cada usuario, sería una mejor manera de cortar el bacalao. Así el servidor solo le respondería a sus clientes. Además, en caso de tener múltiples servidores de clientes ligeros, no tendrás otra opción, pues si no, cada cliente ligero buteará por donde mejor la parezca y seguro no querrás eso.

En el servidor DHCP central, rechaza las MAC de los clientes si se dirigen al puerto 67, para que no reciban dicho servicio, así lo obligas a bootear por el servidor de clientes ligeros.

1
2

iptables -A INPUT -p tcp --dport 67 -m mac --mac-source 00:90:4b:a2:55:05 -j DROP
iptables -A INPUT -p udp --dport 67 -m mac --mac-source 00:90:4b:a2:55:05 -j DROP

Lo ideal sería que el DHCP central tuviera las direcciones MAC de los clientes y le diera los parámetros de buteo a cada cual, pero eso aún no lo he logrado. Hay algo que tiene que ver con el parámetro “next server”. He logrado que estos den con el tftp adecuado, pero luego tratan de contactar al propio servidor DHCP como servidor NFS.

También podrías tener un firewall en el servidor de clientes ligeros. Que permite el DHCP solo a las MAC de los clientes. Así no le das DHCP a cualquiera. Además, podrías decirle también a ese servidor, que solo permite el tráfico de las MAC de los clientes ligeros. No me parece que un servidor como ese tenga que ser alcanzado por otra máquina.

Mientras tanto, muy lejos de infomed y del calixto; con mi triste licencia de “programador de computo”; sigo en peleando en la ciberguerra. Esta trinchera es nada menos que un servidor de correo de cara a internet, en una entidad cubana que no mencionaré.

De siempre, me ha molestado que los hacker de hipatia.net, hagan ataquitos para autenticarse por fuerza bruta en el SMTP.

Mis paisanos suelen resolver ese problema poniendo una pasarela de correo “relay-only” delante de su servidor principal o simplemente con fail2ban.

fail2ban tiene sus ventajas, pues bloqueas a un atacante que podría hacer eso y otras muchas cosas que no imaginamos. Por tanto, no dejo de recomendar que se use SIEMPRE fail2ban.

Por suerte, postfix tiene su método para deshacerse del problema…

Como no tengo nada en mynetworks, a mi me quedó así:

1
2

# sasl solo para nuestra red local
smtpd_sasl_exceptions_networks = !192.168.99.0/24

Osea: “a lo que NO este en esa red, no se le ofrece autenticación”

Se acabó la autenticación pa afuera

Te das cuenta que NO todo se resuelve con violencia,
cuando se te posa un mosquito en los testículos.

Los delay pool de squid, son una herramienta que permite determinar cuanto ancho de vianda le corresponde a ciertas conexiones. A mi en lo personal su uso me disgusta bastante; por el mero hecho de que pone a squid leeeeento. Cuando los delay pools están pinchando, las peticiones se demoran más al ser respondidas y el proto cache manager empieza a hacer cosas raras.

En fin, cierra el chat, apriétate el cinto y abre las entendederas que esto es complicado…

Supón que tienes 128Kbit y queremos repartir el ancho de vianda de manera “equitativa”

El ancho de vianda se vende en KBit pero squid entiende de K Bytes.

1
2

irb(main):611:0> 128/8
=> 16

O sea, que tú canal llega a los 16 Kylo Bytes por segundos…

Nuestro discriminante sistema de castas, tendrá 2 clases

“lo dioses” y “los mortales”

Los dioses cuentan con el 60% del ancho de vianda disponible, mientras que los mortales solo cuentan con el 20%.

OJO: No des a nadie el 100%, ya que podría acaparar todo el canal y dejar a todo el mundo sin navegación.

Los delay pool de clase 2, son los que reparten “ancho de banda por cabeza” Osease, “esto es lo que le toca a esa persona”. Los parámetros de los delay pool de la clase dos son sucesivamente: ancho de banda y ráfaga

El ancho de banda, no puede ser una cosa rígida, porque los datos no se transmiten de manera rígida. Aveces se requiere mucho ancho de banda durante 2 milisegundos para establecer una conexión SSL.

Ahí es donde viene a jugar la ráfaga. Osea: “cuanto ancho de banda máximo tendrá durante los picos”

Digamos que el delay pool será un 20% del canal

1
2

irb(main):612:0> 16*20/100*1024
=> 3072

A la ráfaga le das un Kylo más

1
2

irb(main):613:0> 3072+1024
=> 4096

El delay_pool te viene quedando así:

1

delay_parameters 1 3072/3072 4096/4096

Ahora creamos un delay_pool que tiene el 80% del ancho de banda

1
2

irb(main):614:0> 16*80/100*1024
=> 12288

Sea entonces el delay_pool 2 así:

1

delay_parameters 2 12288/12288 13312/13312

Al final el squid.con

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

# tendremos 2 delai puls
delay_pools 2

# ambos de la clase 2
delay_class 1 2
delay_class 2 2

# los mortales van al 20%
delay_parameters 1 3072/3072 4096/4096

# y los dioses van al 80%
delay_parameters 2 12288/12288 13312/13312

# los dioses, aquellos cuyo nombre de usuario machee esta lista
acl dioses proxy_auth tuusuario eljefe eldirector lajevita lasecretaria

# en el 1 metemos a los dioses
delay_access 1 allow dioses
delay_access 1 deny all 

# el resto, pal 2
delay_access 2 allow all

Ah otra cosa! MUY IMPORTANTE

NADIE debe quedar fuera de delay pool una vez que creas el primero.

Si quieres TÚ (el informático que es tremendo decarao) quires navegar más rápido que nadie, create un delay pool con el 100% del ancho de banda, pero no te quedes fuera de ningún delaypool.

Desde ese momento empezarás a acaparar todo el canal al punto de que NO se podrá navegar. A ese punto te buscarás un lío, no reserves para ti solo más del 80% del canal y navega con cordura.

Zentyal te mantendrá encerrado en tu cuarto, con tu TV y te dará la comida cada 6 horas. No habrá dificultades, nada te faltará.

Nunca verás el hermoso mundo del software libre que hay por explorar.

Los vagos y los mentequietas, prefieren poner una cosa “que pinche y ya” para luego pasarse horas chateando en facebook; antes de ofrecer un producto escalable y competitivo.

Zentyal es el sistema de los infladores, que se las dan de informáticos… y que antes las necesidades responden al más puro estilo windows

“no, eso no se puede hacer”

Si no existe, lo programo, COÑO!!!

Y si el que hay no me gusta, hago uno mejor. En cambio el usuario de Zentyal, si no tiene un botón que lo haga:

SE JODE!!

A esos nunca les ha pasado por la cabeza hacer su propio negocio…

Yo seguiré llevando la luz a las tinieblas y combatiendo la ignorancia con intelecto. Con el software libre como espada, cuyo filo es la dificultad.

Porque la mente que se abre para asimilar una idea, jamás vuelve a cerrarse.

Con ese lenguaje abrupto, cuyas palabras caen como piedras pero que todo el mundo comprende y asimila. Porque el software libre es como el RAP

Hagan Jails de FreeBSD y prueben su sistema de ports

Hagan un servidor de almacenamiento con OpenIndiana y prueben su ZFS

Prueben, gentoo, arch, slackware…

Verás que no te toma 4 horas probar una distro en una máquina virtual

CIERRA FACEBOOK! Y verás cuanto tiempo hay

Luego aprende Python, Perl, Go, C (el que más te guste o el que más lindo nombre tenga) y siente como el sistema dice:

“órdene mi amo”

Hay tantas cosas bellas por aprender, tanto por experimentar y desarollar…

Con zentyal, aprenderás zentyal, con debian, aprendrás Linux

Todo el que halla configurado un navegador con proxy; o sea, todo cubano que halla configurado un navegador, quizás halla visto que una de las tantas opciones dice “configuración automática”. Seguro se preguntarán que carajo es eso.

Pues es un javascript que le dice al navegador como debe ser la configuración del proxy; obviamente.

Resulta que hay dos maneras de hacerlo, vía DHCP o vía DNS. Algunos navegadores lo cogen por DHCP mientras que otros lo hacen por DNS.

Para evitar problemas, configuramos las dos…

Primero y principioso. Creamos el fichero wpad.dat, el nombre debe respetarse. Dicho fichero los servimos, así que por definición los podremos en /var/www. Este fichero contendrá las instrucciones que un navegador necesita para pinchar.

1
2
3
4
5
6
7
8
9
10
11
12

function FindProxyForURL(url, host) {

        // los host locales NO pasan a través del proxy
        if(shExpMatch(url,"*.hcg.sld.cu:*")) { return "DIRECT"; }
        if(shExpMatch(url,"*.hcg.sld.cu:*/*")) { return "DIRECT"; }

        // la red local, tampoco
        if(isInNet(host, "10.1.1.0", "255.255.255.0")) { return "DIRECT"; }

        // lo demás sale por el proxy
        return "PROXY 10.1.1.1:3128";
};

Como ve, es javascript puro, osea que las opciones se podrían hacer más creativas. Por ejemplo, si la ip de la máquina es tal, configuralo así o asao.

Los criticones de código diran que se pudo usar un swith en vez de 4 “if”. Pero eso correrá en un momento y entorno casi imposible de debugar. Lo intenté con swith y no me pinchó.

Ahora el problema es que hay que declarar un nuevo contenido mime para este dato. En mi caso uso nginx y en el fichero de configuración de mime, le aclaramos el nuevo; a mi me quedó así:

1
2
3
4
5
6
7

types {

    application/x-ns-proxy-autoconfig     dat;
    text/html                             html htm shtml;
    text/css                              css;
    (muchas lineas más aqui)
}

Bueno ahora, vamos pal DHCP. Por supuesto, nada menos que el mismísimo dnsmasq:

Primero el método DHCP, declaramos una option cuyo código sea 252

1

option=252,http://10.1.1.1/wpad.dat

También declaramos un puntero DNS, que apunte a wpad.hcg.sld.cu y que sea el servidor donde está el wpad. Le recuerdo que “hcg.sld.cu” es el nombre del dominio.

Al reiniciar nginx y dnsmasq, todo debe estar listo…

En caso de que no uses dnsmasq, asumiré que usas bind e ICS dhcpd…

Para ICS dhcpd, la cosa es un tin más compleja, ya que hay que declarar globalmente el tipo de opción, pero darle el valor en cada subnet o en le única que uses. A mi me pinchó así:

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

# vim:filetype=config
authoritative;

# declaramos lo del proxy automático
option local-proxy-config code 252 = text;

# la red
subnet 10.1.1.0 netmask 255.255.255.0 {

    # los parámetros del rango
    range 10.1.1.100 10.1.1.254;
    option domain-name "hcg.sld.cu";
    option domain-name-servers 10.1.1.1;
    option broadcast-address 10.1.1.255;
    option subnet-mask 255.255.255.0;
    option routers 10.1.1.1;

    # envía el proxy automático
    option local-proxy-config "http://10.1.1.1/wpad.dat";

} # subnet

En el caso de bind9, declaras un CNAME con el nombre wpad que apunte al servidor donde descansa el wpad.dat

1
2
3
4
5
6
7
8
9
10

servidor1    IN A     10.1.1.1
servidor2    IN A     10.1.1.2
mail         IN CNAME servidor2.dominio.cu.
pop          IN CNAME servidor2.dominio.cu.
pop3         IN CNAME servidor2.dominio.cu.
smtp         IN CNAME servidor2.dominio.cu.
proxy        IN CNAME servidor1.dominio.cu.
gateway      IN CNAME servidor1.dominio.cu.
; envía el proxy automático
wpad         IN CNAME servidor1.dominio.cu.

Firefox pincha al palo, los demás no se…