Ahora con el bun de la WiFi, comienzan las necesidades básicas, como cifrado de red y protección de acceso. Todavía el cubano no sabe la diferencia entre WEP y WPA pero bueno, para el que lea esto, el tutorial va por el camino duro pero correcto.

¿Qué haremos?

Configurar hostapd con freeradius para proveer una WiFi con WPA2

Si no sabes que cosa es WPA2 míralo aquí

Para la ocasión, usaremos ArchLinux y requeriremos los paquetes siguientes hostapd y freeradius. ¿No tengo que decirte como instalarlos verdad? Entonces, supongamos que tienes la WiFi en wlan0.

Vamos a empezar de atrás pa alante, el AP. Como no tenemos un ap profesional muy de pinga, vamos a usar hostapd. A mi la configuración me quedó así:

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

ssid=APconLinux
interface=wlp2s0b1
driver=nl80211
ieee8021x=1
hw_mode=g
channel=1
wpa=2
wpa_key_mgmt=WPA-EAP
rsn_pairwise=CCMP
auth_algs=1
auth_server_addr=127.0.0.1
auth_server_port=1812
auth_server_shared_secret=mifortalezaimperial

Ahora localizamos el fichero donde se configura el EAP, en el caso de archlinux, este fichero está en /etc/raddb/mods-enabled/eap ahí localizamos una linea que dice default_eap_type y donde dice md5 y le ponemos peap. A mi me quedó así:

1
2
3
4
5

   eap {

   default_eap_type = peap

   # (el resto del fichero)

Esa cláusula está por la línea 27… Bueno ahora vamos a declarar los usaurios en el fichero users el mio está en /etc/raddb/users, ahí le pones al fondo el usuario y el password, a mi me quedó así:

1
2
3
4

  # (la parte de arriba del fichero)

  # el usaurio secretísimo
  usuario Cleartext-Password := "secretisimo"

Ahora declararemos la dirección IP del AP, que en este caso, sería un cliente radius eso está en el fichero clients.conf.

1
2
3
4

client 127.0.0.1 {
   secret = mifortalezaimperial
   shortname = hostapd
}

Le declaramos que el cliente que se conecte desde la 127.0.0.1 usando como secreto la cadena de texto “mifortalezaimperial” será hostapd.

Bueno, vamos a empezar la conga, instrumento por instrumento. Primero el AP

hostapd /etc/hostapd/hostapd.conf

1
2
3
4
5
6

Configuration file: /etc/raddb/hostapd.conf
Using interface wlp2s0b1 with hwaddr 4c:ed:de:df:ad:f1 and ssid "APconLinux"
RADIUS: socket[PF_INET6,SOCK_DGRAM]: Address family not supported by protocol
wlan0: RADIUS Authentication server 127.0.0.1:1812
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED

Ahora el radius:

raduisd -X

1
2
3
4
5

Listening on auth address 127.0.0.1 port 1812 bound to server default
Listening on acct address * port 1813 bound to server default
Listening on auth address 127.0.0.1 port 18120 bound to server inner-tunnel
Listening on proxy address * port 38055
Ready to process requests

Y el toque final, dnsmasq como DHCP

1
2
3
4

ip a a 10.0.0.1/24 dev wlan0

# OJO linea larga
dnsmasq -a 10.0.0.1 -F 10.0.0.2,10.0.0.100 -i wlan0 -K --log-dhcp  -R -d --log-queries --log-dhcp

Te recuerdo, que si android, al conectarse a una WiFi, no recibe ip, considera que hubo error de autenticación…

Al escanear verás algo como esto.

Note como dice que APconLinux, está asegurada con 802.1x y al intentar conectarte, verás algo como esto:

Desliza el menú ese, para que veas lo que está al fondo. Ahí es donde va la burumba. Donde dice identity pones el usuario, donde dice Anonymous Identity, LO DEJAS EN BLANCO y donde dice password pones el precio actual de la libra de papa.

Se quedará un ratico en Authenticating…

Mientras tanto, hostapd mostrará algo como esto

1
2
3
4
5
6
7
8

wlan0: STA 78:9e:d0:f2:9e:ad IEEE 802.11: authenticated
wlan0: STA 78:9e:d0:f2:9e:ad IEEE 802.11: associated (aid 1)
wlan0: CTRL-EVENT-EAP-STARTED 78:9e:d0:f2:9e:ad
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
wlan0: STA 78:9e:d0:f2:9e:ad WPA: pairwise key handshake completed (RSN)
wlan0: AP-STA-CONNECTED 78:9e:d0:f2:9e:ad
wlan0: STA 78:9e:d0:f2:9e:ad RADIUS: starting accounting session EFB68C31-00000000
wlan0: STA 78:9e:d0:f2:9e:ad IEEE 802.1X: authenticated - EAP type: 25 (PEAP)

Y radius dirá algo como esto:

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

(9) eap: Sending EAP Success (code 3) ID 112 length 4
(9) eap: Freeing handler
(9)     [eap] = ok
(9)   } # authenticate = ok
(9) # Executing section post-auth from file /etc/raddb/sites-enabled/default
(9) Sent Access-Accept Id 9 from 127.0.0.1:1812 to 127.0.0.1:58792 length 0
(9)   MS-MPPE-Recv-Key = 0x486910b6930c3d5beae2e5831a3d15545066fcd8964d4a396d9950f1d2142b59
(9)   MS-MPPE-Send-Key = 0xcfbf7ae337d7bd5c9e747c2a6f5864746b308523d7a4fb261bc1b32a5cdafce2
(9)   EAP-Message = 0x03700004
(9)   Message-Authenticator = 0x00000000000000000000000000000000
(9)   User-Name = "username"
(9) Finished request

La salida de dnsmasq quizás estes aburrido de verla, nada nuevo, le dio la ip, etc… dnsmasq es necesario en este caso para completar la autenticación ya que nuestro hostapd no tiene un dhcp incluído. Más adelante, veremos que radius puede asignar una ip a cada usaurio e incluso se tira contra mysql, pero ahora mismo esto es un experimento para familiarizarnos con radius, así que con eso bastará.

Pasamos a comerciales y próximamente veremos como hace con MySQL, no te prometo nada, solo lo haré si logro vender el producto; ya que aquí somos partidarios de que “la wifi sin contraseña es más fácil” sin pensar en riesgos…

Para nadie es un secreto que foxconn, no le descarga a Linux. Hacen mil mierdas para entorpecerlo cuando corre sobre su hardware.

Uno de los misterios, es cuando las tajetas de red permiten conexiones, pues dan ping sin problema. Pero al intentar transferir grandes bloques de red, da timeout.

Problema, el tamaño del MTU por defecto en sus putas tarjetas

1

ip l set dev eth0 mtu 1492

Veremos con que se bajan la próxima vez

De siempre, desplegar Ruby con RVM, ha sido un método catalogado de “burdo” o “sucio” aunque sin dudas, es el más rápido.

Un problema que se enfrenta con RVM, es a la hora de integrarlo a entornos que no carguen el bashrc modificado por el instalador. Por ejemplo, un script de arrancada con el sistema o un script del cron.

He aquí un ejemplo, de un escript.sh que levanta una aplicación de ruby on rails, luego de haber cargado el entorno de RVM.

1
2
3
4

#!/bin/bash
cd /opt/aplicacion
source /usr/local/rvm/environments/default
unicorn -l 0:8080 -D

Como vemos, el fichero en environments carga todas las variables de entorno requerida y de facto; unicorn pasa a ser un ejecutable, ya que $PATH ahora contiene también la ruta bin/ donde se instalaron las gemas…

Problema resolvido…

Note en caso de tener varios rubies instalados, en environments, tendrás junto a default, los demás script necesarios para cargar dichos rubies.

Usualmente, tenemos un botón en un formulario y nos gustaría que al pulsar este, nos preguntara algo para confirmar. He aquí un buen ejemplo:

1
2
3
4
5
6
7
8

  <%= form_tag manager_email_path,class: 'navbar-form navbar-left',role: 'search',method: :post do %>
    <div class="form-group">
      <input name="email" type="text" class="form-control" placeholder="fulanito@infomed.sld.cu">
    </div>
     <%= button_tag(:class => "btn btn-default", data: {:confirm => 'Seguro?'} ) do %>
        Enviar
     <% end %>
  <% end %>

Finalmente, después de tantas plegarias, tenemos hooks en pacman. Lo cual nos permite, por medio de la poderosa API de alpm correr script antes o después de cada instalación.

Desgraciadamente, hay poca documentación sobre el tema. Para colmo, la página de man de alpm-hooks, no dice como deben llamarse los archivos. Tuve que adivinar que la extensión .hook era necesaria.

Primero que todo, vamos a especificar en /etc/pacman.conf que el directorio de hooks está en otro lado.

1

HookDir = /etc/pacman.d/hooks/

¿Por qué aquí? Muy sencillo. Quiero que al hacer una salva de mi configuración de pacman, los hooks también se salven. Un hook sencillo, podría correr un comando simple, como el del ejemplo en la página de man; sin embargo, uno complejo, sería mejor ponerlo en un script.

Lo más importante: El fichero con el hook debe tener la extensión .hook Si no pacman se limpia el culo con él.

Creemos uno de ejemplo, llamado /etc/pacman.d/hooks/migancho.hook y digámosle que ejecutará el script, sito en /etc/pacman.d/hooks/migancho.sh

Sería así:

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

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *

[Action]
Description = sincronizando disco
Depends = coreutils
When = PostTransaction
Exec = /etc/pacman.d/hooks/migancho.sh

Como ve, la cláusula Operation está repetida, con los 3 posibles momentos que se disparará el gancho. Podrías hacerlo en uno de ellos solamente. La cláusula Description se verá cuando pacman termine de instalar. En este caso cuando termine, ya que la cláusula When especifica PreTransaction o PostTransaction (antes o después de la transacción).

Ahora creamos el script migancho.sh y le ponemos todas las aberraciones que queremos llevar a cabo tras una instalación, desinstalación o actualización.

Digamos por ejemplo, en este caso uno trivial, ejecutar sync cuando termine una operación, lo cual evita que si falla la energía en ese momento, queden datos por escribirse en la cache disco (con suerte).

1
2

#!/bin/bash
/usr/bin/sync

Veámoslo en acción

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

[root@artema ~]# pacman -S --noconfirm unrar
warning: unrar-1:5.3.11-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) unrar-1:5.3.11-1

Total Installed Size:  0.32 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                                                   [##############################################] 100%
(1/1) checking package integrity                                                 [##############################################] 100%
(1/1) loading package files                                                      [##############################################] 100%
(1/1) checking for file conflicts                                                [##############################################] 100%
(1/1) checking available disk space                                              [##############################################] 100%
:: Processing package changes...
(1/1) reinstalling unrar                                                         [##############################################] 100%
:: Running post-transaction hooks...
(1/1) sincronizando disco
[root@artema ~]#

Véanlo como dice sincronizando discos en español, corriendo la operación (1/1) ya que hay un solo hook.

Sencillo!!! Como todo en ArchLinux: KISS

Podría volverse más creativo…

Digamos por ejemplo, que yo quiero tener la lista de paquetes que tiene mi sistema antes y después de una instalación, para saber que se instalo y cuando.

1
2

#!/bin/bash
pacman -Qe > /root/$(date +%j%H%M%S)

Eso creará un fichero similar a /root/051153712, el nombre, es el yday (día del año) y con la hora, minuto y segundo. Dentro del fichero, una lista de todos los paquetes instalados. Muy útil si eres tester o desarrollador, o simplemente quieres saber que paquetes había antes o después de instalar.

Por cierto, otra manera de saber que si instalo hoy y ayer, es esta:

1

ls -ltcr --time-style +%j /var/lib/pacman/local/

Devuelve el día del año en el que se instaló un paquete. Así sabes que se instaló hoy. Te recuerdo, que en ArchLinux, todos los días hay algo nuevo que instalar :D

No desde cuando, pero por fin, un sueño echo realidad en ArchLinux. Revertir un paquete de su forma instalada, a su forma de paquete. Esto puede no resultar algo novedoso para el que tenga internet como algo cotidiano, pero para los cubanos de a pie, resulta una verdadera novedad.

Digamos que mi socio necesita instalar nginx en su arch, misma arquitectura que el mío. Simplemente, le genero el paquete a partir de mi instalación y listo.

1
2
3
4
5
6
7
8
9

[root@samsung ~]# cd /var/cache/pacman/pkg/
[root@samsung pkg]# bacman nginx
==> Package: nginx-1.8.1-1
  -> Copying package files...
    -> Generating .PKGINFO metadata...
    -> Generating the package...
  ==> Done.
[root@samsung pkg]# ls nginx*
nginx-1.8.1-1-x86_64.pkg.tar.xz

Pues bacman es la respuesta. Ahora se puede regresar un paquete a su estado; digamos “pristino”.

¡¡OJO!! TUS ficheros de configuración, también se empaquetan.

Usualmente solía mantener en mi caché los paquetes necesarios para llevar a cabo una instalación de archlinux usando mi laptop; pero con este nuevo método, la cosa cambia bastante. Ahora solo debo cargar con el “.iso”

Mi proxima idea es reconstruir el grupo base completo dentro de la cache y luego con repo-add crear un mirror, capaz de llevar a cabo una instalación de sistema.

De momento quiero probar este script:

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

#!/bin/bash

# cambiate al directorio de cache
cd /var/cache/pacman/pkg/

# itera por los paquetes del sistema base
for pkg in $(pacman -Qeg base|awk '{print $2}'); do

   # háblate
   echo $pkg '>' $(pacman -Qi $pkg|grep Description|cut -d : -f 2)

   # reviértelo
   bacman $pkg 2> /dev/null > /dev/null

done

# crea el repo
rm /var/cache/pacman/pkg/custom.db.tar.gz
repo-add /var/cache/pacman/pkg/custom.db.tar.gz /var/cache/pacman/pkg/*.pkg.tar.xz

Tendré que probar a instalar usando mi cache como repo. Poniéndole a la máquina una source como esta:

1
2
3

[mirepo]
SigLevel = Optional TrustAll
Server = http://localhost:8080

Nota para los imbéciles: Cambiar localhost por la ip de la máquina que está compartiendo la caché.

Y para servir tu cache como repo, puedes usar darkhttpd

1

darkhttpd /var/cache/pacman/pkg/ --chroot --port 8080