Cambios en GNUPG en Debian testing

gpg

Aprovechando que acaba de entrar en testing la versión “moderna” de GnuPG os traigo esta entrada sobre los cambios que introduce la nueva versión. De acuerdo al mantenedor del paquete en Debian, Daniel K. Gillmore, los principales cambios son:

  • gpg-agent (paquete gnupg-agent) será el responsable de manejar toda la información relativa a las claves secretas, lo que significa que las operaciones de cifrado/descifrado más delicadas quedan en manos de un software más contenido y menos proclive a sufrir vulnerabilidades.

  • Los demonios se irán lanzando según se necesiten, optimizando el uso de memoria.

  • scdaemon manejará todos los accesos a smartcards.

  • dirmngr manejará todos los accesos a red.

  • Se retira el soporte a claves PGPv3.

  • Las claves secretas dejan de almacenarse en secring.pgp y pasan a private-keys-v1.d

  • Los anillos de claves públicas ahora se almacenan en formato keybox (~/.gnupg/pubring.kbx) para nuevos usuarios.

  • Si actualizas desde una versión anterior de GNUPG mantendrás el archivo pubring.gpg hasta que decidas migrar a la nueva versión

Migrar el directorio de GNUPG a la versión moderna

Las claves secretas se migran de forma automática de la estructura clásica a la moderna tras las primera ejecución del programa. Si guardas tus claves secretas en una smartcard, tras la primera ejecución de la versión moderna de GNUPG, conecta el lector de tarjetas y teclea:

gpg --card-status

El anillo de claves públicas no se migra de manera automática. Si quieres pasar tus claves públicas a formato .kbx puedes usar el script incluido en /usr/bin/migrate-pubring-from-classic-gpg.

Más información

Podéis encontrar más información sobre la nueva versión de gpg en la web oficial del proyecto y en sus listas de correo.

Cifrad vuestras comunicaciones on-line

Recordad que utilicéis el proveedor que utilicéis, cifrar vuestras comunicaciones es la única forma de mantener vuestra privacidad en línea.

Happy cyphering!

 

Instalación de un repositorio debian con reprepro

Lenny Updated

Cuando se pega mucho (pero mucho, mucho) con debian, lleva un momento en que empieza a hacer o modificar paquetes y es entonces cuando el uso de un repositorio personal es una buena idea. Hace unos años, crear y sobre todo mantener un repositorio de paquetes de debian era doloroso por los scripts que había que ejecutar, puesto que funcionaban una de cada dos veces y estaban llenos de parches. Afortunidamente han surgido unos cuantos programas que facilitan mucho la tarea de instalación y sobre todo de mantenimiento de los repositorios y, dentro de todos ellos, mi favorito es reprepro.

No es excesivamente pesado, se maneja completamente desde la línea de comandos y el cifrado de los ficheros que contienen las sumas MD5 (los ficheros Release) es transparente. También, la configuración de cada repositorio es sencilla y mediante ficheros de texto y toda la información de los paquetes se almacen en una base de datos Berkeley, por lo que no es necesarios ningún SGBD.

Tener los repositorios disponibles para un sólo equipo no es muy inteligente así que se suelen instalar bajo servidores web o ftp. Los repositorios de mi red están en ranas, mi servidor raspberry NAS, así que por motivos de rendimiento y recursos preferí instalar un servidor pure-ftpd antes que un apache2. Como ambos pillan fuera del ámbito de esta guía, os dejo los enlaces de configuración de ambos:

Instalación

Instalamos conjuntamente reprepro y pure-ftpd.

pure-ftpd

Configuramos pure-ftp según se explica en los enlaces superiores y configuramos unas cuantas cosas más.

  • crear usuario ftp con directorio /media/nas/ftp/.

  • asignar permisos a mi usuario en el directorio de los repositorios.

reprepro

Toda la configuración y gestión del repositorio con reprepro se realiza como un usuario sin privilegios, salvo el de escribir en el directorio de los repositorios.

Dada la versatilidad de reprepro puedo crear tantos repositorios como quiera. Si, por ejemplo, quiero tener los repositorios de cada proyecto organizados, puedo crear dentro de /media/nas/ftp un directorio, proy01, que contenga los repos proy01, partners y apps. Para el segundo proyecto crearía proy02 con los repos proy02 y extras y así… Cada proyecto con sus paquetes y, probablemente, un repo general con debian, con jessie, wheezy y sid dentro.

  • debemos crear una llave gpg de 2048 bits con que firmar los paquetes.

  • exportamos la parte pública de la llave a un fichero asc.

  • creamos el fichero de configuración del repo nimhix.

Las líneas más jugosas son Architectures, donde indicamos que arquitecturas están soportadas, Components, donde se enumeran las ramas del repo y SignWith, donde especificamos la clave pública que se usará para firmar los paquetes. Codename es el nombre en clave del repositorio y si, en este caso viene de la serie Justified.

  • creamos el repositorio y los enlaces. Si estamos en el directorio principal del repositorio (donde se ve el directorio conf), no es necesario pasar el argumento -b.

Gestionando paquetes

Todos los ejemplos se ejecutan desde el directorio principal (al mismo nivel que conf). De no ser así, el argumento -b es tu amigo. 🙂

Listar paquetes del repositorio

Añadir nuevos paquetes (o versiones actualizadas)

Borrar paquetes

Y con esto ya tenemos cuantos repositorios necesitemos. Actualmente es ranas quien sirve los paquetes en mi red local, así que el gasto de recursos está bastante contenido (con pure-ftpd). Si, además, configuras samba para “tirar” los paquetes en el directorio del ftp, lo tienes todo más a mano.

 

Securizando un VPS

Hace ya tiempo que busqué y alquilé el VPS (Virtual Private Server) más barato que pude encontrar, animado por dabo, que mantenía (y con razón) que por unos euros al mes tienes un juguete con el mantenerte bastante en forma en esto del sysadmining. Tras darle muchos usos, alguno incluso para el que no estaba preparado y no podía con ellos, se quedó con un apache2 y un par de blogs en wordpress durante el último año. Pero he decidio hacer de él un servidor de provecho y eso pasa por una reinstalación (aka limpieza) y configuración.

Ésta es una guía no exhaustiva de los pasos que sigo para dejar el servidor un poco más seguro tras la instalación.

1. Reinstalar el VPS

Desde el panel de control del VPS (al menos en mi caso), elijo una Debian GNU/Linux 8 de 64 bits y le digo que si, que estoy seguro de que se puede cargar el servidor y reinstalar. Al cabo de unos minutos asigno una nueva contraseña de root y me conecto por ssh.

2. Cerrar puertos abiertos (de más)

Ejecuto netstat -pta y detengo todos aquellos servicios que no sean ssh. En este caso, apache2 y postfix. En alguna ocasión me he encontrado con un montón de servicios instalados y funcionando, algunos de ellos inseguros por definición, así que antes de seguir, cerrojo.

3. Borrado de paquetes

Igual que con los servicios funcionando (o precisamente por eso), hay bastantes paquetes que a mi juicio sobran y que desinstalo por real decreto. Y si, algunos de los paquetes que elimino los instalaré más tarde pero será bajo demanda, porque decido instalar el servicio y configurarlo y no porque tenga que venir preinstalado. Llamadme exagerao pero, en un VPS donde no puedes instalar un escritorio, ¿para qué hacen falta fuentes truetype?

En esta ocasión, partí de una lista total de 380 paquetes y los reduje hasta los 290. La lista la genero mediante el comando:

Normalmente, en otra pestaña del terminal abro otra sesión ssh y creo un alias para que sólo sea copiar y pegar nombres de paquetes.

La lista de paquetes eliminados es:

Y para eliminar varios paquetes que empiezan por el mismo nombre, como las fuentes, unas cuantas tuberías y listo.

4. Creación y configuración de un usuario

Lo de conectarse como rootnunca ha sido una opción así que una de las primeras acciones es crear un usuario con el que conectarse.

No voy a explicar porqué debe usarse sudo porque, como decía un profe en la universidad “es de sentido común”.

5. SSH

Si ejecutamos nmap sobre sobre el propio servidor descubriremos que ssh es un chivato de cuidado.

Así que para vamos a pedirle que de menos información y a evitar que root pueda iniciar sesión a través de este protocolo.

Ahora estará un poco más callado :).

6. NTP

El VPN que estoy configurando está situado en la costa oeste americana a siete horas de diferencia y eso puede (y lo hace, vaya si lo hace) complicar bastante las cosas. Así que se impone el ajuste de la zona horaria y la instalación de un servidor de hora.

7. Securización extra

1. portsentry

No está de más tener un perro guardian que vigile todos los recovecos de la casa y eso precisamente hace portsentry. Audita los puertos inactivos del sistema en busca de actividad e informa si la encuentra donde no debe.

Si ejecutamos un netstat -pta veremos que hay servicios que antes no estaban y que ni tan siquiera están instalados, como finger.

2. logwatch

Un estupendo servicio que lee los logs del sistema y nos avisa en caso de que algo no le cuadre. Es un poco pesado en la configuración pero merece mucho la pena. Unas excelentes guías para la configuración de logcheck son las de Un pingüino en mi ascensor: Vigilando los logs con logcheck (I) y Vigilando los logs con logcheck (II).

3. maldet

maldet es un software muy interesante que escanea en busca de malware, se actualiza automáticamente y emite unos informes con todos los cambios que encuentra y que pueden ser de interés. No tiene paquete debian por lo que se descarga e instala.

En este punto tenemos un directorio, /usr/local/maldetect con el software instalado, por eso se borra el directorio de instalación en la última línea.

Lo configuramos y ejecutamos.

4. iptables (o ufw)

A estas alturas un firewall resulta imprescindible, ya estés configurando un servidor en el otro lado del mundo o una raspberry pi para tu red local. De hecho, es más importante en el caso de la raspi porque el servidor está protegido por la empresa que te lo alquila. Haz la prueba, instala ufw en tu raspi y échale un ojo a los logs, te garantizo que querrás llorar. Si iptables te asusta (a mí me pasó durante un tiempo), instala ufw que es su cara amable y de lenguaje llano. Si no te asusta, usálo a discrección porque es uno de esos programas sin los que linux estaría cojo.

Aquí dejo el script con las reglas para ufw que uso en una de mis raspberries.

Y hasta aquí, la configuración básica. Obviamente se complica cuando instalamos algún servicio porque hay que habilitarlo en el firewall, configurarlo adecuadamente y ajustar algunas cosas más. Pero esa es la magia de este juego al que es difícil cansarse de jugar.

 

Boosting tola

Turbo_Boost01

Hace unas semanas que el ordenador portátil que utilizaba para trabajar, tola, ha pasado a ser de mi propiedad y, a pesar de que sólo tiene tres años, decidí que podía intentar mejorar su rendimiento. El aparato en cuestión es un ACER Aspire E-571, con un procesador i3 de Intel, 4GB de memoria RAM y 500 GB de disco duro y no lo hace mal, sobre todo teniendo en cuenta que he llegado a ejecutar dos máquinas virtuales con Windows 2012 a una velocidad aceptable. Pero ya que es mío… ¡qué carajo, voy a doparlo! 🙂

Mis intenciones eran dos: ampliar la memoria RAM, doblando los 4GB, porque nunca se tiene suficiente RAM y meter un disco SSD como disco principal, instalando el disco mecánico en el hueco del DVD. Por el camino tuve que sustituir la batería que perdió un 75% de capacidad en apenas dos semanas y sin estar conectada a la toma de corriente.

La batería

En la eterna lucha entre duración de batería y ligereza, esta vez ganó la duración y le endosé medio kilo largo que dan 6600 mA de capacidad, lo que se traduce en unas cinco horas y media de uso normal (y cuatro de uso salvaje, lo que está muy bien :D). Además viene con un alza, lo que le da mejor ventilación en los largos veranos extremeños. En conjunto se nota que ha ganado peso pero, insisto, lo compensa la duración de la batería con creces.

La memoria RAM

Personalmente prefiero tener 4GB de RAM riéndose de mí por haberme gastado el dinero para que luego se usen cada veintinueve de febrero, a no tenerla y preguntarme si realmente habría mejorado el rendimiento con ellos. Así que me llevé el portátil a una tienda, que no tengo edad ni paciencia para perseguir frecuencias, chips y formatos de pastillas de memoria y salí de allí con 4GB más de RAM.

IMG_20160211_172949

Una nota negativa para ACER: no encontré por ningún lugar documentación relativa a la BIOS ni a las posibilidades de cambiar piezas para aumentar la potencia ni en la web, cosa que me extraña, ni tan siquiera buscando por el número de versión de la BIOS. Este modelo de ordenador, además, tiene docena y media de submodelos de los que no hay información y cuyo nombre varía en una letra añadida al final: E-571G, E-571B… Al final, en la caja vi que ponía 8GB/4GB, dando a entender que soporta ambas configuraciones, me arriesgué y salió bien (por esta vez).

El disco duro SSD

Había oído que los discos duros de estado sólido, SSD, revivían ordenadores dándoles una velocidad desconocida y no fue hasta que reinicié un MacBook Air en un centro comercial y vi que tardaba unos pocos segundos en arrancar, que me lo creí. Desde aquel día sólo era cuestión de tiempo que le metiese uno a uno de mis ordenadores. Y le tocó a tola y, de paso, al macbook de 2007 que heredó mi señora.

Me decanté por un SanDisk SATA III de 120GB tras leer varias comparativas que ponían a Kingston a caer de un burro y hacer un ejercicio de análisis profundo para saber si realmente iba a necesitar un disco del doble de capacidad para el directorio raíz, la swap y un home medio decente. La respuesta fue que no, que si podía instalar debian en 120MB no necesito tanto disco para el raíz. Además, para almacén de datos se iban a quedar los 500GB del disco mecánico.

Lo que más me mosqueó al recibirlo fue el poco peso del dispositivo. Son sólo unos gramos y mi impresión es que me habían colado una carcasa vacía y que no albergaría ni un mísero bit. Pero no, el disco funciona a pesar de que se lo llevaría el viento y creo que he podido ver esas 23 veces más rápido que comentan en amazon. Porque sí que se nota la velocidad, empezando por el arranque del sistema operativo, que dura entre dos y cinco segundos hasta que aparece lightdm, cuando antes le llevaba unos 30-40. Y las aplicaciones que más recursos consumen, vuelan. Iceweasel y Icedove se abren en un parpadeo y hasta con VirtualBox se nota cláramente. Y esto fue antes de instalar la memoria RAM, que conste.

IMG_20160211_172924

Para cambiar la memoria RAM como el disco duro, hay que quitar únicamente un par de tornillos de la parte inferior del portátil y hacer palanca ligeramente. Si, suena a roto pero no es para prevenir accesos de usuario mediante el uso del miedo :). El disco sale al tirar de la solapa de plástico, deslizándolo lateralmente hacia la izquierda y la memoria RAM basta con añadir el módulo de 4GB en el zócalo vacío.

El DVD

Seamos serios: ¿quién utiliza un DVD hoy en día, habiendo discos duros USB por cuatro duros? Yo no, así que me dije que ese hueco estaría mejor aprovechado con los 500GB del disco duro mecánico y también dejaría de tropezar con el bótón de apertura cada vez que muevo el ordenador (si, pasa mucho). Si es que son todo ventajas.

En eBay adquirí una carcasa que entra en el hueco, tiene conexión SATA y alberga un disco de 2,5 pulgadas por menos de diez euros, fácil y rápida de instalar.

IMG_20160303_124738

Parece fácil, ¿verdad? Bien, pues ahora los trucos.

Primero, no es necesario quitar todos los tornillos del ordenador buscando la forma de extraer del DVD. En este tutorial tan sencillo de ifixit.com explican que basta con hacer un poco de palanca tras quitar un único tornillo. Y ya está.

El segundo se basó en que no leí completamente la descripción de la carcasa una vez que la recibí y sí me fijé en la serigrafía que trae, concretamente en la forma en que se sujeta el disco para que no se mueva. No se aprecia pero utiliza una pieza para calzar el disco, pieza que no trae y que, obviamente, sustituí con imaginación, cinta americana y unos calzos de cinta de carrocero. Casi nadie lo aprecia así pero era una obra de arte improvisado. Hasta que, al intentar meter el la caja en el hueco del DVD noté que algo metálico chocaba. Eran un par de tornillos que fijan el disco duro sin necesidad de cinta americana… ¡y hasta te adjuntan el destornillador con que apretarlos!

IMG_20160307_022539

Luego, leyendo la descripción del artículo me topé con esta línea: The build-in lock screws make it easy to mount your second hard drive in the caddy. Más claro, agua.

El tercer y último truco es la tapita de plástico de forma triangular con el perfil del portátil. En teoría se quita esa tapa para colocarla sobre la cuna del disco duro para que no se pierda el diseño del ordenador. En la práctica, los tres anclajes que trae no son de plástico, son de adamantium y se resisten a abandonar su acomodo sin dar batalla. Me llevó casi quince minutos de autocontrol y mantras quitar la tapita sin arrancarla del DVD. Todo por el diseño del portátil, que luego queda feo, repetía. Personalmente valoré más sacar entera la tapa que la integridad de la pieza que sujetaba el último enganche y… la corté.

El resultado después de media hora de pelea fue este:

discos

Bola extra: cifrar el disco duro

A dabo le debo muchas cosas, incluída la paranoia de «¿dónde vas con un portátil sin cifrar?» y claro, sus sabias palabras retumbaban en mi cabeza mientras instalaba Debian GNU/Linux en el disco SSD, así que cifré las particiones de swap y home. Si, no es la mejor solución pero quería tener el portátil instalado y me pudo la vagancia. Me consuelo pensando que todo lo que se puede encontrar son un montón de paquetes estándar y una configuración básica porque los logs los elimino periódicamente. Y claro, un par de semanas después instalé el disco duro mecánico y me pareció oportuno que también fuese cifrado.

Lo primero es crear la partición sobre la que irán los datos cifrados. Aunque el destino de esta es que cryptsetup la sobreescriba, hay que crearla.

Y ahora se inicializa la partición cifrada con cryptsetup, que se encargará de sobreescribirla con datos aleatorios y pedirá la contraseña de acceso.

Se puede comprobar que se ha creado correctamente mediante un volcado de la información de la partición:

Y, finalmente, abrimos la partición para poder asignarle un sistema de ficheros:

Como no devuelve ninguna información, se ejecuta sudo fdisk -l para ver que el dispositivo al que accede es /dev/mapper/sdb1:

Y, finalmente, se crea el sistema de ficheros sobre /dev/mapper/sdb1:

Para hacer que se monte durante el arranque del sistema operativo (preguntando la contraseña), primero hay que averiguar el UUID asignado a la partición con el comando blkid:

Luego se edita el fichero /etc/fstab para añadir una línea similar a esta:

Vinculamos el dispositivo sdb1_crypt con el UUID del dispositivo en el fichero /etc/crypttab:

Y terminamos actualizando el fichero initram:

Durante el próximo inicio del sistema pedirá las contraseñas de todos los sistemas de ficheros cifrados.

Conclusiones

Si descontamos la batería (era obligado si no quería un ordenador de sobremesa), el total invertido en el proceso no superó los 85€ y el resultado es realmente impresionante. Todo aquello que está en el disco SSD se ejecuta a una velocidad endiablada y el acceso a disco ha dejado de ser un cuello de botella. Personalmente me parece poco dinero para el resultado obtenido y creo que voy a empezar a convertir otros ordenadores al SSD-ismo.

 

Aplicaciones para escapar al yugo de la gran G

No suelo empezar así, y menos después de tanto tiempo sin dar señales de vida pero, si aún no has leído el libro El pequeño libro rojo del activista en la red de Marta Peirano, ya estás tardando. Además de didáctico e instructivo (y detallado y acertado y paranoico y muchas cosas más), nos recuerda que el anonimato es una ilusión y que, básicamente, somos productos que pueblan internet. Algo así como los habitantes de aquellos capullos rosaceos de las granjas de electricidad de Matrix, no nos damos cuenta que somos quienen alimentan a la bestia (o bestias) y, además, estamos encantandos con nuestras vidas en esa ilusión de colores en que nos mantienen.

Analogías aparte, leer el libro de Marta Peirano en los últimos días me ha reforzado una idea que tenía dando vueltas por la cabeza y que ya había empezado a aplicar: desvincularme de google. Llevo algunos años sustituyendo servicios de la gran G por otros basados en software libre y mantenidos en servidores propios desde un año antes de que cerrasen reader (si, en 2016 y todavía con esto…), con un resultado esperanzador. Si, hacen muy bien las aplicaciones para que tú no tengas complicaciones e integran perfectamente con el teléfono pero, en mi opinión, el peaje es demasiado grande. Personalmente estoy cansado de meterme en las configuración de google de mi teléfono para decirle, entre otras, que no recuerde por donde me muevo, que no me de información que no le he pedido, que no lea mi agenda y que desactive la señal GPS. Por eso cada dos o tres meses me paso, a ver qué han vuelto a activar.

Como siempre que me complico la vida con estos proyectos, parto de un escenario y unas condiciones. En esta ocasión el escenario es múltiple y las condiciones leoninas:

  1. Escenario
    • linux: instalar, configurar y mantener el programa en linux, GNU/Debian preferentemente.
    • linux: utilizar el programa en linux, sobre diferentes escritorios (MATE, gnome, xfce) y programas (thunderbird, evolution).
    • android: utilizar el programa en el móvil de manera fluida.
    • LAMP: fácil de mantener y gestionar.
  2. Condiciones
    • software libre: What else?
    • múltiples plataformas: poder utilizarlo desde un navegador y/o un programa cliente.
    • gestión completa de los datos: ya está bien de enviar mi información fuera.
    • versatilidad y facilidad de uso: no voy a sustituir servicios que funcionan muy bien por otros a medio hacer.

La lista de servicios a sustituir ha ido aumentando con el tiempo y, de comenzar buscando un buen sustituto a reader he terminado buscando sustituto a casi cualquier aplicación que venga instalada por defecto en el móvil. Lo sorprendente es que las hay y muy buenas.

Y, los nominados son…

google reader (lector de feeds)

Fue el primer servicio que sustituí, en parte porque me di cuenta que las alternativas a reader no me terminaban de convencer, en parte porque nada garantizaba que no terminase en otro servicio que cerrase también. El elegido fue Tiny Tiny RSS y, a día de hoy, no puedo estar más contento. Es muy configurable, soporta los comandos de reader (si, es una extravagancia mía) y es fácil de mantener, incluso para varios usuarios. La aplicación android, ttrss reader, es sencilla y rápida.

delicious (favoritos)

Cuando tienes varios ordenadores, varias plataformas y varios navegadores, querer guardar un enlace es ligeramente complicado. Por eso cuando del.icio.us se fue al garete, le busqué un sustituto que resultó ser SemanticScuttle. Al igual que con Tiny Tiny RSS, su mayor virtud fue ser un del.icio.us con añadidos, muchos añadidos. Además de las condiciones (irrenunciables), SemanticScuttle funciona con múltiples usuarios, es fácil de utilizar, tiene extensiones para firefox (no sé para el resto de navegadores), tiene zona pública y privada donde guardar los enlaces y permite compartir enlaces entre los usuarios del sitio, entre otras cosas. Tiene aplicación para android.

google keep (notas)

Soy un usuario de notas en el móvil desde mi último nokia pero tampoco soy un fanático ni un usuario pro. Intenté utilizar evernote y keep y me sentí más cómodo con la última, porque era más sencilla y no tenía tantas opciones que no usaba. Ademas, la aplicación de evernote para linux es la web y no me entedía bien con nixnote (antes nevernote), el clon para linux. Así que cuando me topé con tomboy, rainy y tomdroid, dejé de buscar. Es sencillo de usar, soporta añadidos y, salvo el pequeño detalle de que las notas (aún) no soportan markdown, es perfecto para mí y mi uso moderado. También quiero dejar constancia que he tenido a rainy alojado en la raspberry pi modelo 1 durante seis meses sin ningún problema, ni de rendimiento ni de estabilidad, que no todo van a ser servidores dedicados con gigas y gigas de RAM.

Por cierto, si alguien va a pegarse con rainy para tener un servidor de notas multiusuario que funcione con el móvil y en cualquier navegador, le recomiendo que no lo haga, que lea el siguiente punto y se quede con este nombre: grauphel. De nada ;).

google drive (la nube)

Al principio sólo estaba dropbox y sus 2 GB de almacenamiento. Luego llegó drive, de google y subieron un poco más el espacio pero compartíendolo con el correo y las fotos. Y luego apareció owncloud y todos esos servicios dejaron de tener sentido para mí. Pasé de tener 2 GB a 16 GB de espacio simplemente instalándolo en una raspberry pi con un USB de esa capacidad (si, la misma raspberry que ya tenía funcionando rainy, el servidor torrent y un par de cositas más). Al final he subido la apuesta instalándolo en un servidor dedicado con 400 GB de espacio sólo para la nube.

¿Ventajas? Casi todas: cumple las condiciones a rajatabla, funciona estupendamente, tengo tantos usuarios y grupos como necesito con permisos de acceso variados, es fácil de mantener aunque algunas veces las actualizaciones las lleve a cabo el enemigo y, sobre todo, soporta aplicaciones. Así, puedo configurar la aplicación de android (importante: las diferencias entre la versión del play store y de f-droid es que una está completa y la otra no; ¿adivinas cúal es la completa?) para que vuelque las fotos y los videos en un directorio concreto como para que la aplicación Gallery las muestre en cualquier navegador o permita enviarlas como enlace protegido, tanto dentro como fuera de owncloud. Otra aplicación, Documents, convierte el navegador en un editor de textos con todos los ficheros que suba y las hay para cifrar todo el contenido de owncloud, leer ficheros pdf, reproducir música y videos, instalar un servidor de correo y noticias, etcétera.

Hay aplicaciones para casi cualquier tarea o servicio de uso cotidiano y, de verdad, merece mucho la pena echarle un vistazo a la lista completa de aplicaciones que soporta owncloud. En los siguientes puntos hablaré de tres de estas aplicaciones Calendar Plus, Contacts Plus y Grauphel.

google calendar (calendarios)

Los calendarios fueron el primer caballo de batalla del móvil con que me metí, principalmente porque la instalación de Calendar Plus en owncloud es extremadamente sencillo e importar los calendarios, también. Lo más complicado fue encontrar una aplicación que funcionase bien en el móvil porque no quería instalar 50 MB para terminar usando los calendarios de alguna plataforma concreta. Tras una larga búsqueda encontré CalDAV Sync Adapter que hace exactamente lo que quería. Crea un tipo de cuenta en la configuración de android para dar de alta calendarios de owncloud de manera sencilla y transparente. Por 778 kB no se puede pedir más. Tras crear la cuenta y autenticar contra owncloud, se pueden utilizar los calendarios sin problemas y de forma transparente, desde la propia aplicación de calendarios.

Al cambiar de móvil y meterme también con los contactos, CalDAV Sync Adapter se quedó corto. Una vez más la respuesta estaba en f-droid y se llamaba DAVdroid. Esta aplicación hace, en esencia, lo mismo que CalDAV Sync Adapter pero también soporta el protocolo CarDAV y, con el, los contactos. Se utiliza de la misma manera, creando un tipo específico de cuenta, que permite conectarse a los calendarios y los contactos de nuestro servidor. Una vez más, en f-droid está la versión completa y en el play store, no.

google contacts (contactos)

Para los contactos, instalé la aplicación Contacts Plus en owncloud, migré los casi cuatrocientos contactos que tenía en google y los ordené en grupos. En definitiva, los puse guapos y presentables. Luego, desde el móvil y con DAVdroid, los puedo gestionar a mi gusto. Los cambios y nuevos usuarios aparecen instantáneamente en el servidor y de ahí, al resto de clientes.

bola extra: google keep (contactos)

Rainy funciona bastante bien pero está basado en mono y sólo su instalación le añade 100 MB al servidor. Por eso cuando vi que owncloud tiene una aplicación, grauphel que se define como Tomboy sync server, me puse a probarla. Y el resultado es impresionante. El servicio es rápido, estable y al estar integrado en owncloud te despreocupas de usuarios. Nada más instalarlo, probé desde tomboy y tomdroid y la velocidad fácilmente duplica a la de rainy. Yo, que no soy un fanático de las notas, he vuelto al vicio de hacer una para cada chorrada que se me ocurre. Y eso es mucha carga para el servidor :).

futuro

Las siguientes aplicaciones o servicios en caer serán (sin ningún orden en particular):

  • gmail: servicio de correo electrónico.
  • XMPP: mensajería instantánea y OTR.
  • mozilla sync: sincronización de los perfiles de firefox.

A ver si, al terminar este año 2016 puedo declarar el móvil libre de aplicaciones google (si, lo sé, quedan muchas por debajo…).

Nota: la entrada de debish que menciono es Escapa a la vigilancia masiva y debería ser de obligada lectura junto con el libro de Marta Peirano.

 

owncloud, actualizaciones y certificados

He actualizado owncloud, mi nube particular, de la versión 8.0.4 a la 8.1.11 y tengo la impresión de haber actualizado a Windows 10. Quizá es que, con miles de actualizaciones de debian a mis espaldas que me han malacostumbrado a que sean silenciosas e indoloras, quizá es que ninguna actualización es sencilla o quizá es que tienen varios puntos que mejorar.

En cualquier caso, tras terminar la actualización tenía tres errores en la consola de administración, varias apps que no funcionaban y un problema, que el cliente de escritorio de linux (los tres, en realidad) no conectaba. Éste último fue fácil de solucionar, actualizando el cliente a la versión 2.0, que además soporta múltiples cuentas sin hacer cosas raras.

error no internet connection

De los errores, el más extraño era uno que decía que owncloud no tenía conexión a internet y que era necesaria para un funcionamiento adecuado. Lo extraño es que ese servidor está en algún lugar de Bélgica y yo, obviamente, no cojo el coche cada vez que quiero conectarme. Además, este error en concreto parecía deberse a un fichero de configuración viejo, según el solucionador de problemas de actualización, que no existía.

Leyendo a más gente con el mismo problema (y conexión a sus servidores remotos), me encontré con una persona que atinaba con la solución, diciendo que en un hilo de github alguien decía algo de un certificado. Y así es. El error se debe a que owncloud no reconoce a https://owncloud.org como entidad certificadora hasta que no tiene ese fichero y lo asocia con una desconexión de la red. La pregunta es porqué no se asegura el proceso de actualización que ese fichero existe antes de validar nada más. Así que, para solucionar el error más absurdo de owncloud, sólo tuve que descargar el código y copiar el fichero /config/ca-bundle.crt en mi instalación de owncloud. Nada más. Y, a partir de ese momento, las apps que no funcionaban y el propio entorno de gestión de apps, comenzaron a funcionar correctamente.

A lo tonto he estado pegándome con la actualización de marras unas cuantas horas para tenerlo todo bien configurado. Y luego damos (doy) por sentado que las actualizaciones tienen que ser sencillas, rápidas e indoloras. A ver si aprendo.

 

Configurando una raspberry pi 2 como servidor NAS

Creo que ya he comentado que tengo un par de raspberry pi, de los modelos 1 y 2. El proyecto en sí me fascinó desde que supe de el y luego, al comprar la primera, caí rendido a sus pies por todo lo que ofrece con ese precio y esos consumos mínimos. De hecho, el día que raspas (la raspi 1) tiene tos, toda la red de mi casa se convulsiona porque, entre otras cosas, sólo es el guardian de la wifi y, por extensión, de la entrada y salida a la red.

Así que cuando por fin tuve en mis manos la versión 2 de la raspi, ranas (raspberry nas server), ya tenía más proyectos que llevar a cabo que tiempo para implementarlos. Tuve que elegir y los finalistas fueron tres:

  • NAS y servidor de backup para todos los ordenadores de la red (linux, windows, mac) y alguno externo.
  • centro multimedia con kodi.
  • consola MAME.

Para poder llevar a cabo el primero quería que no tuviese que estar anclado a un disco duro externo que necesitase de un enchufe y que pudiese ser portátil (de una manera un poco tosca), así que tenía que utilizar un disco duro externo de 2,5′ comprado para la ocasión. El pero vino porque los dispositivos USB 3.0 necesitan más corriente que la que suministra un único puerto USB de la raspi y la solución, como casi siempre, estaba en ebay. Por cuatro euros adquirí un sofisticado mecanismo capaz de suministrarle toda la energía que necesita el disco duro externo: ¡un cable en forma de Y para USB 3.0!

Los dos últimos proyectos sólo tenían dos necesidades: estar físicamente cerca de la televisión (a un cable HDMI de distancia) y tener conexión inalámbrica puesto que no llega ningún RJ45 al salón. Así que lo primero era la conexión wifi.

Conexión wifi

El dongle USB wifi que compré en una de esas cadenas que te tratan como a un gilipollas lo reconoció sin problemas, una vez instalado el paquete con el firmware adecuado a la marca, así que para conectarla a la red, modifiqué el fichero /etc/network/interfaces:

Como el filtrado de MACs para obtener una IP de la wifi lo gestiona raspas, sólo hay que decirle que use DHCP y la contraseña de acceso. En total, poco más de diez minutos para poder quitarle el cable RJ45.

Reviviendo el disco duro

Mi cara fue un poema cuando recibí el cable porque, al conectarlo todo, no funciona. De hecho, el disco no terminaba la maniobra de arranque y emitía unos quejidos que daban mucha lástima y algo de miedo. Leyendo un poco sobre el voltaje en los puertos USB en las raspberry pi me enteré de que el cable sí que funciona pero que, por defecto, las raspi limitan la potencia de salida de los USB, por lo que incluso empleando dos puertos, el disco duro no tenía suficiente para operar con normalidad.

La solución es sencilla y rápida. Hay que pasarle un parámetro al fichero config.txt que es el equivalente a la BIOS que las rasp no tienen, diciéndole que utilice toda la potencia en los puertos USB.

Tras reiniciarla, la raspi comenzó a usar el disco sin ningún problema.

Nota: en versiones anteriores de raspberry pi (1 y 1+) el parámetro es este, safe_mode_gpio=4. De nada.

NAS, ra NAS

Para hacer que ranas sea el NAS de la red, hay que hacer que comparta un espacio en disco donde el resto de ordenadores podrán escribir siempre que cuenten con un usuario válido. Así que lo primero es instalar samba y lo segundo, crear un usuario en el sistema que usaremos para gestionar dicho espacio.

En mi caso el usuario se llama nas y no podrá iniciar sesión en el sistema:

A continuación, creamos el espacio en samba, comentando el resto de volúmenes compartidos y añadiendo este:

Preparamos el disco duro y reiniciamos samba:

Y, finalmente, añadimos al usuario nas a la base de datos de usuarios de samba:

Después de esto, podremos conectarnos mediante el protocolo CIFS (antes SMB) a la raspberry y podemos apuntar aquí los programas de backup y comenzar a volcar datos, copias de seguridad o capítulos de series para luego ver con kodi, por ejemplo.

ranas-cifs

Disclaimer

La raspberry pi tiene los puertos USB conectados a la tarjeta de red por lo que no me hago ilusiones con lo que respecta a la velocidad, incluso cuando no utilizo dicha tarjeta de red. Pero no me importa demasiado porque se trata de una prueba y tampoco tengo excesiva prisa.

Para finalizar una imagen que prueba lo que se puede hacer con un poco de tiempo, una brida de fontanería, un disco duro y una raspberry pi 2. 🙂

pi-nas01

pi-nas02

 

Debian Jessie, más allá del lanzamiento de una nueva release

Debian 8 JessieHoy ha sido un día de fiesta, fiesta del Software Libre, de GNU/Linux y sobre todo, el día de Debian. Más allá de una cuestión de fechas por lo que ha supuesto este sábado 24 (por si alguien no lo sabe hoy ha visto la luz Debian 8 estable), para muchos es la reafirmación de algo que vemos a diario en nuestros entornos de escritorio o servidores.

Algo tan tuyo que sólo puedes entenderlo cuando has tomado el pulso a esta release cuando aún estaba en pañales viendo algunos paquetes en versiones de Sid o Testing. Lo que hoy ha sucedido es el resultado de las sinergias de miles de personas de todos los rincones del mundo realizando un ejercicio colectivo de solidaridad y continuidad para con la comunidad, impensable en otros ámbitos de la vida y del Software.

Felicidades por la parte que os toca, ya queda menos para Debian 9 y esto no para. Sí amigos, podemos sentirnos afortunados ya que en Debian, por encima de las compañías están las personas. Muchas gracias a todos esos desarrolladores anónimos que hacen posible que pueda usar el mejor y más estable Sistema Operativo jamás creado.

P.D: Yo he celebrado este sábado (no sin una marcada amargura por el terremoto del Nepal, donde hay más de 1500 fallecidos y colegas montañeros entre ellos y muchos desaparecidos) instalando como he dicho en Twitter con mucho mimo mi futuro servidor principal una flamante Debian 8. Ya os comentaré qué tal los cambios que voy viendo.

 

dnsmasq y la persistencia de las IPs

A veces pasa. Te obsesionas con un problema determinado, algo nimio pero capaz de perturbar tu sueño por el mero hecho de estar ahí, de existir. Pasa el tiempo y no das con la solución y, finalmente, cansado de la situación, desistes. Pues bien, lo que suele pasar es que en un plazo de tiempo no superior a las dos semanas, la solución te busca y, claro está, te encuentra. ¡Maldito Murphy!

La última solución que me buscó y me encontró, tiene que ver con dnsmasq, el servidor de DNS y DHCP que tengo funcionando en raspas, el ordenador más importante de mi casa, ese que entra en una cajetilla de tabaco. Con la limitada capacidad de raspas no hay nada mejor que un servicio ligero y muy ágil que apenas entorpece. Mi problema, decía, tenía que ver con la asignación de direcciones IP y, básicamente consistía en que tenía todo el rango separado según el tipo de solicitante (móviles, tabletas, ordenadores personales, ordenadores de trabajo, lavadoras, tostadoras, etcétera…) y en unos pocos casos, ignoraba mis instrucciones y asignaba una IP diferente, aunque reconociese al dispositivo.

Concretamente me tenía frito que mi movil, nexus no tuviese la dirección IP 20 asignada con mimo y cariño sino la 131. Tras realizar todo tipo de ajustes en la configuración del servicio, cambios en el direccionamiento IP y un largo etcétera de pruebas, todas infructuosas, claudiqué y admití mi derrota a manos de un ordenador que se llama igual que el esqueleto de las sardinas. De eso hace un par de semanas.

Hoy sólo quería saber dónde podía encontrar una lista de los dispositivos que tienen asignada una dirección IP en dnsmasq.

Una búsqueda rápida y el primer resultado, una respuesta de una lista de email, sólo dice que la tiene en el fichero que contiene los préstamos de IPs, en /var/lib/misc/dnsmasq.leases. Y es cierto, contiene esa lista, un poco más grande de lo que esperaba. De hecho, estaba a punto de cerrar el fichero cuando un dato llamó mi atención: algunos de los equipos listados sólo habían estado conectados unas horas, mucho tiempo atrás. Mirando con más detenimiento, observé que, además, esos equipos tenían direcciones IP que deberían estar asignadas a otros, como el nexus. Y todos ellos tenían un bonito cero al principio de la línea. En este punto, sólo quería llorar.

Lo que acababa de ver era una demostración del concepto de persistencia. Al principio, cuando estaba aprendiendo a usar dnsmasq le asigné a los equipos con una IP determinada un tiempo de arrendamiento muy alto, infinito concretamente. Luego decidí cambiar el direccionamiento y, aunque cambié en la mayor parte de los casos la etiqueta infinite por 12h, no limpié la base de datos y esas IPs seguían reservadas hasta el infinito y más allá. Por eso, por mucho que intentase asignarle la 20 al nexus el servidor seguía dándole una muy superior y alejada de mis sueños de orden y categorización, puesto que ya primera ya estaba asignada por siempre jamás.

Bastó una prueba para que quisiese darle cabezazos a la pared. Detuve el servicio, borré las entradas viejas del fichero /var/lib/misc/dnsmasq.leases y volví a levantar el servicio. A continuación solicité una nueva IP desde el móvil y… dnsmasq le asignó la número 20.

Por supuesto, ya le había cambiado el tiempo de asignación en la configuración para que nunca más tuviese otra IP.

¿La moraleja de esta historia? Que nunca barres toda la mierda de debajo de las alfombras. Siempre queda algo que, además, apesta.