Etiquetar particiones

Si bien el otro día hablamos de cómo manejar y cambiar el UUID de una partición, hoy vamos a ver cómo emplear las etiquetas (labels) para poder administrar nuestros puntos de montaje y que así tengan más significado. La idea es pasar de un /dev/sda1 a un /dev/disk/by-label/raiz. Algo más legible y entendible por cualquier persona.
Para hacerlo, lo primero que debemos es comprobar si nuestro disco tiene alguna etiqueta. Para ello,
shell> lsblk -f
NAME      FSTYPE      LABEL      MOUNTPOINT
sda                                         
├─sda1    ext4                   /boot
├─sda2    ext4                   /
└─sda3    ext4                                  
Como vemos, no hay ninguna etiqueta de nombre para las particiones. La solución está en el empleo del comando e2label, que sirve precisamente para asignarle etiquetas a las particiones. Procederemos por lo tanto como sigue,
shell> e2label /dev/sda1 boot
shell> e2label /dev/sda2 raiz
shell> e2label /dev/sda3 data
Puedes aplicar etiquetas únicamente a aquellas particiones que te interese, a mi me interesa etiquetarlas las 3 que voy a usar. Si ahora ejecutamos nuevamente el primer comando (lsblk),
shell> lsblk -f
NAME      FSTYPE      LABEL      MOUNTPOINT
sda                 
├─sda1    ext4        boot       /boot
├─sda2    ext4        raiz       /
└─sda3    ext4        data
A partir de este momento, bajo la carpeta /dev/disk/by-label existe los links a los disco y que se pueden usar, por ejemplo, para montar una partición.
shell> mount /dev/disk/by-label/data /mnt
Quizás acordarse de la nueva ruta para realizar los montajes de disco sea más complejo, pero desde luego, para saber qué es lo que se está haciendo, mucho más simple.

Referencias

Leer más

Listado de ramas remotas con git

En el uso cotidiano de git, el manejo y cambio de ramas en local no suele ser un problema. branch y checkout son comando habituales con los que trabajar. Sin embargo, el problema viene cuando quieres contribuir o hacer algún tipo de desarrollo colaborativo contra un repositorio que no conoces. En este caso, tras hacer el clone correspondiente, únicamente tienes, por ejemplo la rama master. Si empleas github o algún interfaz de gestión de repositorios, entonces averiguar el nombre de todas las ramas que tiene el proyecto es más sencillo. Sin embargo, hacerlo desde consola ya no tanto.

Listado de ramas

Si lo que nos interesa es averiguar aquellas ramas que están disponibles para un proyecto, con el comando git también lo podemos lograr. La forma más sencilla,
shell> git branch -r
  origin/test
  origin/prueba
  origin/HEAD
  origin/master
Y si nos interesa tener un listado completo de las ramas remotas y locales,
shell> git branch -a
* master
  origin/test
  origin/prueba
  origin/HEAD
  origin/master
Rápido, limpio y sencillo. Sabiendo aquellas ramas disponibles, si queremos cambiar a alguna, únicamente habrá que realizar el checkout correspondiente, tanto sea local como remota.

Referencias

Leer más

Cambiar UUID del disco

Hace ya un tiempo hablamos en este blog acerca del uso de los UUIDs y los discos. El que no sepa de qué estoy hablando, puede leer la entrada Obtener el UUID del disco. En él se indica de forma clara cómo obtener el identificador universal del disco para posteriormente trabajar con él, por ejemplo en fstab.

Cambiando UUID

Hoy vamos a dar un paso más allá y ver cómo cambiar dicho UUID. A priori, el algoritmo que se emplea para la creación de los UUID no permite que este identificador esté repetido en un mismo equipo, aunque como todo, siempre puede haber excepciones. En caso de que esto os haya pasado, sabréis que trabajar con UUIDs en un sistema con dos repetidos es imposible. En cada montaje del sistema, aparece un disco y otro y hay muchos fallos. Pues bien, la solución en esos casos no es otra que la de cambiar dicho UUID.
Con el comando blkid se puede obtener el listado de los IDs de las particiones del disco,
shell> blkid
/dev/sda1: UUID="e12c98df-7c8e-4f50-be39-e208597f71a7"
/dev/sda2: UUID="2bf49a55-f967-4fec-9127-9d049a5e7091"
/dev/sda3: UUID="a6a1fc9a-48e5-4cff-82b9-04f0afa925e3"
y también está el comando uuidgen, que permite precisamente crear "el churro" alfanumérico que se emplea como identificado.
shell> uuidgen
502eb30f-9c0c-4308-80d7-e1061ba39e4f
Para cambiar el ID de una partición debemos de emplear el comando tune2fs y pasarle el nuevo UUID que nos interese, es decir, uno aleatorio. Por lo tanto,
shell> tune2fs -U `uuidgen` /dev/sda3
tune2fs 1.42.9 (4-Feb-2014)
Y vemos ahora que los cambios han surtido el efecto deseado.
shell> blkid
/dev/sda1: UUID="e12c98df-7c8e-4f50-be39-e208597f71a7"
/dev/sda2: UUID="2bf49a55-f967-4fec-9127-9d049a5e7091"
/dev/sda3: UUID="c6dfe0b1-ceec-477b-a764-9db98439c5f9"

Referencias


Nota: La partición afectada que vayamos a cambiar debe de estar desmontada.
Leer más

Bacula TLS, cifrando la comunicación

Esta semana tocó configurar Bacula. La configuración básica del servicio es bastante sencilla y ponerlo a funcionar suele no llevar mucho. Sin embargo, si estás pensando en realizar backup remoto o entre diferentes redes, la opción de que los datos viajen cifrados, no es discutible. Incluso dentro de la propia red local no debería de serlo.
Por suerte, Bacula ya trae soporte para cifrar los datos mediante certificados TLS. Y es importante que tanto la parte cliente como la parte servidor traigan dicho soporte. Para comprobarlo, podemos emplear el comando ldd contra el binario de Bacula.
shell> ldd /usr/sbin/bacula-dir
   libcrypt.so.1 => /lib/libcrypt.so.1
   libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
   libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
   ...
shell> ldd /usr/sbin/bacula-fd
   libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
   libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
   ...
Si vuestros servicios tienen soporte SSL, entonces podemos seguir leyendo la entrada. Si por el contrario el paquete del que dispones no viene con soporte SSL, intenta actualizarlo o compilarlo para que sí lo soporte.

Crear los certificados

Lo primero que debemos hacer es crear los certificados para los equipos. La parte más importante aquí es aclarar que cada equipo tendrá unos certificados diferentes y por lo tanto, los siguientes 4 pasos habrá que repetirlos en cada uno de los equipos en los que vaya algún componente de Bacula.
  1. Clave privada del equipo
    Esta va a ser la llave maestra para el equipo.
    shell> openssl genrsa -des3 -out a.local.net.key 4096
  2. Solicitud de certificado
    Con la clave anteriormente creada generamos una solicitud de certificado. Es importante que estos datos se rellenen correctamente y en especial la parte del Common Name, que debe ser el FQDN del equipo.
    shell> openssl req -new \
           -key a.local.net.key \
           -out a.local.net.csr
    Enter pass phrase for a.local.net.key:
    ...
    Organizational Unit Name (eg, section) []:Elmundoenbits
    Common Name (e.g. server FQDN) []:a.local.net
    ...
  3. Firmamos la solicitud con una CA conocida
    En este caso, recomiendo recurrir a cacert.org como CA. La creación de la cuenta es gratuita y puedes firmar todas las solicitudes que desees, siempre que tengas permiso para el dominio.
    En caso de que tu sistema no tenga el certificado raíz del CACert, lo puedes descargar desde aquí y le vamos a llamar cacert.pem.
  4. Generamos la clave sin contraseña
    Finalmente y puesto que Bacula no permite trabajar con certificados con contraseña, necesitamos exportar la clave privada (paso 1) a la versión sin contraseña.
    shell> openssl rsa \
           -in a.local.net.key \
           -out a.local.net-nopass.key
    shell> mv a.local.net-nopass.key a.local.net.key
    
Como dije, estos pasos los repetiremos para cada uno de los equipos. Para el ejemplo que aquí manejamos, tendremos dos equipos. El equipo servidor de Bacula (bacula.local.net), para el que tenemos los siguientes ficheros disponibles:
  • cacert.pem
  • bacula.local.net.cert
  • bacula.local.net.key
Y el equipo cliente, a.local.net, con sus tres ficheros correspondientes,
  • cacert.pem
  • a.local.net.cert
  • a.local.net.key

director - bconsole

Lo primero que debemos hacer ahora es indicarle al software de consola (bconsole) que para conectarse al bacula-director debe de emplear certificados TLS. Para ello editamos el fichero bconsole.conf y añadimos las opciones de TLS.
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Y a continuación, debemos de indicarle a la parte contrarios (director) exactamente lo mismo (fichero bacula-dir.conf).
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Con ello, ya es posible conectarse con bconsole a Bacula para realizar comprobaciones.

director - bacula-sd

A continuación, hay que establecer la comunicación cifrada entre el director y el storage. Para ello nos toca editar el fichero bacula-sd.conf y en el apartado Director, añadirle las opciones TLS. Como siempre,
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Y a continuación, en el fichero bacula-dir.conf, editar el apartado Storage y también añadir las opciones TLS.
Storage {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}


bacula-fd - bacula-sd

La que citamos a continuación es quizás la parte más importante en la que aplicar el cifrado, ya que es la que se encarga de enviar y recibir los datos. Por lo tanto, nos interesa mucho que estos sí estén cifrados. Para hacerlo editamos nuevamente el fichero bacula-sd.conf y en el apartado Storage añadimos los TLS,
Storage {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
y en cada uno de los clientes (fichero bacula-fd.conf) hacemos lo correspondiente,
FileDaemon {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/a.local.net.cert
   TLS Key = /etc/bacula/tls/a.local.net.key
}


bacula-fd - director

Para finalizar toda la configuración lo que nos queda es realizar la comunicación entre el director y el cliente también cifrada. Para ello, fichero bacula-dir.conf, apartado del cliente,
Client {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem   
   TLS Certificate = /etc/bacula/tls/bacula.local.net.cert
   TLS Key = /etc/bacula/tls/bacula.local.net.key
}
Y en el fichero del cliente (bacula-fd.conf),
Director {
   ...
   TLS Enable = yes
   TLS Require = yes
   TLS Verify Peer = yes
   TLS CA Certificate File = /etc/bacula/tls/cacert.pem
   TLS Certificate = /etc/bacula/tls/a.local.net.cert
   TLS Key = /etc/bacula/tls/a.local.net.key
}
Para terminar, reiniciamos los servidor bacula-sd, bacula-dir y los bacula-fd que correspondan. Si no hay ningún problema, la comunicación debería de estar cifrada en el servicio funcionando perfectamente.

Referencias

Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios