Algo de Linux: mayo 2016

martes, 31 de mayo de 2016

Iso de Clonezilla + DRBL + Boot Repair Disk para montar en pendrive/disco duro USB

En un post de octubre de 2014 compartí con vosotros una imagen iso de Clonezilla y DRBL para montar en un disco duro USB o un pendrive. Como ya he comentado en otro post, esta imagen ya tenía casi dos añitos y he decidido actualizarla.

En el siguiente enlace dejo colgada la nueva versión, muy interesante, sobre todo para los administradores de centros, en la que he montado Clonezilla, DRBL y Boot Repair Disk:
https://mega.nz/#!opFyDYrL!i4Su5GJSP721rmt2ij1d0fSyLwdJhD34PGXR5fcAo08


Al igual que ya comenté en su día, monto clonezilla y drbl en el mismo dispositivo por una razón muy sencilla: Habitualmente uso clonezilla para crear y restaurar imágenes con entradas de menú directas o inicio sesión en un terminal de clonezilla para hacer algún diagnóstico, o cualquier modificación, pero, además, cuando tengo que clonar de forma masiva, utilizo DRBL para restaurar imágenes en modo multicast.

Por otra parte, he añadido Boot Repair Disk porque parece que se va a convertir en una herramienta de cabecera...
 
Los ajustes que llevan tanto clonezilla como DRBL son los mismos que en la versión anterior:
  • El filesystem.squashfs de DRBL se aloja en el directorio live y el filesystem.squashfs de Clonezilla se encuentra ubicado en el directorio live-clonezilla. De este modo, es posible tener ambas herramientas en el mismo dispositivo.
  • Se establece por defecto el idioma español tanto para la interfaz como para el teclado. Con ésto evitamos tener que seleccionar el idioma en el asistente de clonación cada vez que lo usemos.
  • Se fija como directorio de imágenes el /home/partimag del dispositivo para ambas herramientas y se monta en modo lectura/escritura con el fin de que se use tanto para salvar/restaurar imágenes desde ambas herramientas.
En cuanto al menú de opciones, he seguido dejando syslinux para equipos sin UEFI y modificado el grub.cfg para equipos UEFI. 

Una vez que lo montéis en vuestro disco duro/pendrive USB, podéis editar las entradas y adaptarlas a vuestras necesidades. He dejado oculta alguna opción de restauración de syslinux para que sirva de ejemplo a la hora de personalizar el menú.

Para montar la ISO en el pendrive podéis usar tuxboot, o hacer el dispositivo arrancable de forma manual y copiar el contenido.

IMPORTANTE: La imagen de Clonezilla + DRBL + Boot Repair Disk ya no está disponible. Me pareció mejor opción reemplazarla por Clonezilla + DRBL + Rescatux.

Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 30 de mayo de 2016

Utilizar GRUB2 en nuestro dispositivo USB de herramientas

Hasta ahora utilizaba syslinux para los menús de mis pendrives o discos duros USB de herramientas. El problema es que con la introducción de sistemas UEFI en los nuevos equipos, me obliga a mantener dos menús diferentes:
  • Uno para sistemas no UEFI, con syslinux.
  • Otro para sistemas UEFI, con grub.
Para evitar este problema, manteniendo un sólo menú (el de grub), he decidido instalar grub en mis dispositivos y dejar de usar syslinux.

Para instalar grub en nuestros usb, antes debemos tener instalado el paquete grub-pc en nuestro equipo:
# apt-get install grub-pc
Una vez instalado, montamos la partición de nuestro dispositivo USB. Suponiendo que mi pendrive ha sido identificado como sdb y tiene una partición sdb1:
# mount /dev/sdb1 /mnt
Una vez montado, ejecutamos grub-install para instalar grub en él:
# grub-install --no-floppy --boot-directory /mnt/boot/ /dev/sdb
Observad, que a grub-install debemos indicarle el dispositivo donde vamos a realizar la instalación (no la partición).
Publicado por primera vez en http://enavas.blogspot.com.es

genisoimage: Crear iso booteable

En octubre de 2014 escribí un post para compartir una iso de Clonezilla + DRBL. Como la iso ya iba camino de los dos añitos, decidí ponerme a actualizarla, aprovechando que tanto clonezilla como drbl tienen soporte efi, algo que estaba necesitando para las últimas máquinas que hemos recibido. Y ya de he paso, para tener el kit completo, he añadido Boot Repair Disk a la compilación.

He añadido las herramientas a un directorio de mi máquina y he generado la iso utilizando la herramienta genisoimage:
Iso de Clonezilla + DRBL para montar en pendrive/disco duro USB - See more at: http://enavas.blogspot.com.es/2014/10/iso-de-clonezilla-drbl-para-montar-en.html#sthash.5auR94hk.dpufis
Iso de Clonezilla + DRBL para montar en pendrive/disco duro USB - See more at: http://enavas.blogspot.com.es/2014/10/iso-de-clonezilla-drbl-para-montar-en.html#sthash.5auR94hk.dpuf
# genisoimage -r -V "clone-drbl-boot" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o clonezilla-drbl-live-2.4.5-i686-algodelinux-pae.iso /media/gestor/ISO/
El directorio isolinux debe existir en la compilación. En mi caso tan sólo tenía el syslinux, que contenía el fichero isolinux.bin. Así que he hecho una copia del directorio syslinux como isolinux y listo.
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 28 de mayo de 2016

pkgsync 1.29: Modificado pkgsync para esperar mientras se esté realizando una actualización de índices o una actualización de paquetes

Para evitar que pkgsync no se ejecute mientras algún otro proceso está actualizando índices de repositorios o instalando paquetes al iniciarse pkgsync, introduje una espera mientras los siguientes ficheros lock estén bloqueados por algún proceso:
  • /var/lib/apt/lists/lock
  • /var/lib/dpkg/lock 
Lo que he hecho en esta última modificación ha sido comprobar ambas situaciones (actualización de índices o instalación de paquetes), tanto cuando pkgsync va a realizar una actualización  de índices como cuando va a realizar instalaciones de paquetes.
Aquí podéis ver el código completo de pkgsync:

Y si queréis descargar el paquete que instala esta versión de pkgsync, aquí lo tenéis:
https://copy.com/d2n3dZ2izAlvj6fH
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 24 de mayo de 2016

pkgsync 1.28: Modificado pkgsync para esperar mientras se esté ejecutando un gestor de paquetes

A veces sucede que se está ejecutando el gestor de paquetes porque, por ejemplo, puppet está actualizando índices de repositorios o instalando paquetes al iniciarse pkgsync.

Para evitar este problema, he modificado pkgsync de forma que espere mientras los siguientes ficheros lock estén bloqueados por algún proceso:
  • /var/lib/apt/lists/lock
  • /var/lib/dpkg/lock
Aquí podéis ver el código completo de pkgsync:
Y si queréis descargar el paquete que instala esta versión de pkgsync, aquí lo tenéis:
https://copy.com/d2n3dZ2izAlvj6fH
Publicado por primera vez en http://enavas.blogspot.com.es

domingo, 22 de mayo de 2016

Script de sincronización sinc_puppet

Escribo este post para explicar un poco la problemática del script sinc_puppet en equipos trusty (o sinc_puppet_inst en wheezy) y las mejoras que le he realizado, con el fin de que alguno de los compañeros que me siguen se anime a probarlo antes de solicitar propagarlo a todos los centros. 

En principio, lo tengo funcionando en mi centro desde hace tiempo  y tan sólo he ido realizando mejoras en él, pero, sería conveniente que se probara en algún centro más.

Os cuento primero los problemas que tiene el script actual:
  • Tiene un bucle de espera activa que hace que el script se esté ejecutando eternamente al esperar una respuesta de ping al puppetinstituto,  si el equipo se encuentra fuera del centro.
  • Es demasiado agresivo. Se ejecuta una sola vez en el arranque y borra el directorio de certificados del cliente completo /var/lib/puppet/ssl/, si el cliente ha estado sin sincronizar con puppet más de 12 horas, lo que sucederá cada día. Como consecuencia, cada día, el cliente solicitará nuevos certificados al servidor.
  • Al borrar el directorio /var/lib/puppet/ssl completo en el cliente, los certificados que tiene el servidor almacenados, ya no serán válidos. Ese es el motivo de que se colocara una tarea cron que borre los certificados firmados cada 10 minutos entre las 8:00 y las 20:00. Y si cada 10 minutos se borran todos los certificados de clientes en el servidor, lo que se está consiguiendo al final es que cada cliente solicite un nuevo certificado cada vez que se ejecute puppet. Por eso digo que el funcionamiento es demasiado agresivo.
Y ahora os cuento las mejoras que le he aplicado:
  • He eliminado la espera activa limitando el número de intentos de hacer ping a puppetinstituto.
  • He trasladado la ejecución de puppet a /etc/network/if-up.d para que se ejecute al levantar el interfaz de red. Así no es necesario comprobar si se ha levantado el interfaz de red.
  • Como no se quiere ejecutar puppet si no ha transcurrido un tiempo determinado, he adelantado esta comprobación al principio para que no se realicen más acciones en ese caso.
  • Compruebo si existe el certificado en el cliente, y, si no existe, ejecuto puppet agent con un waitforcert de 60 para que se ejecute puppet y se solicite un nuevo certificado con una espera máxima de 60 segundos.
  • Si existe el certificado y ha estado más del tiempo determinado sin sincronizar con puppet, se ejecuta puppet agent con los parámetros splay y splaylimit para lograr que se realize en un tiempo pseudoaleatorio como máximo de splaylimit tiempo.
  • He hecho que sinc_puppet sea configurable por el administrador, creando un fichero de configuración /etc/default/sincpuppet que permitirá personalizarlo según necesidades.
  • También me ha parecido interesante añadir un parámetro ENABLE (como hicimos con pkgsync) al fichero de configuración para que podamos desactivarlo fácilmente si fuera necesario.
Aquí tenéis el código, por si queréis echarle un vistazo:
/usr/share/linex-ubuntu-puppet/sinc_puppet
Y el fichero de configuración:
/etc/default/sincpuppet
Todo es mejorable. Así que si alguien tiene alguna propuesta, que la envíe y lo hablamos.

sinc_puppet se distribuye en el paquete linex-ubuntu-puppet para los equipos con Ubuntu. Así que he creado una nueva versión de dicho paquete:
https://mega.nz/#!Fl8mDBDJ!-ELC2x2koIWe9HaYAvuNML8fe64Qe2pt4DpK7fg8c2Q
Como no podemos evitar que en el servidor puppet se borren los certificados firmados del directorio /var/lib/puppet/ssl porque la tarea cron que lo hace está puesta mediante el puppetmaster de Mérida, lo que tenéis que hacer es comentar la línea que dice ssldir=/var/lib/puppet/ssl en la sección [master] del fichero /etc/puppet/puppet.conf del servidor puppet:
[master]
ssldir=/var/lib/puppet/ssl

certname=puppetinstituto
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
#templatedir=/var/lib/puppet/templates
autosign=true
Para que quede tal que así:
[master]
# ssldir original
# ssldir=/var/lib/puppet/ssl
# ssldir cambiado para que no me borren los certificados
ssldir=/var/lib/puppet/ssl.ies

certname=puppetinstituto
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
#templatedir=/var/lib/puppet/templates
autosign=true
De este modo, estamos cambiando la ubicación de certificados del servidor a /var/lib/puppet/ssl.ies

Un detalle importante que se me había pasado comentar y que me ha apuntado nuestro compañero Francisco Paniagua (Gracias, Francis!!!!): 

Como estamos utilizando puppet con apache2 mediante passenger, al cambiar la ruta /var/lib/puppet/ssl por  /var/lib/puppet/ssl.ies, tendremos que cambiar la ubicación de los certificados en el fichero /etc/apache2/sites-available/puppetmaster.conf para que apunten también al directorio /var/lib/puppet/ssl.ies

/etc/apache2/sites-available/puppetmaster.conf antes del cambio:
# This Apache 2 virtual host config shows how to use Puppet as a Rack
# application via Passenger. See
# http://docs.puppetlabs.com/guides/passenger.html for more information.

# You can also use the included config.ru file to run Puppet with other Rack
# servers instead of Passenger.

# you probably want to tune these settings
PassengerHighPerformance on
PassengerMaxPoolSize 12
PassengerPoolIdleTime 1500
# PassengerMaxRequests 1000
PassengerStatThrottleRate 120

Listen 8140

<VirtualHost *:8140>
        SSLEngine on
        SSLProtocol             ALL -SSLv2 -SSLv3
        SSLCipherSuite          EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
        SSLHonorCipherOrder     on

        SSLCertificateFile      /var/lib/puppet/ssl/certs/puppetinstituto.pem
        SSLCertificateKeyFile   /var/lib/puppet/ssl/private_keys/puppetinstituto.pem
        SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
        SSLCACertificateFile    /var/lib/puppet/ssl/certs/ca.pem
        # If Apache complains about invalid signatures on the CRL, you can try disabling
        # CRL checking by commenting the next line, but this is not recommended.
        SSLCARevocationFile     /var/lib/puppet/ssl/ca/ca_crl.pem
        # Apache 2.4 introduces the SSLCARevocationCheck directive and sets it to none
        # which effectively disables CRL checking; if you are using Apache 2.4+ you must
        # specify 'SSLCARevocationCheck chain' to actually use the CRL.
        # SSLCARevocationCheck chain
        SSLVerifyClient optional
        SSLVerifyDepth  1
        # The `ExportCertData` option is needed for agent certificate expiration warnings
        SSLOptions +StdEnvVars +ExportCertData

        # This header needs to be set if using a loadbalancer or proxy
        RequestHeader unset X-Forwarded-For

        RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
        RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
        RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

        DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
        RackBaseURI /
        <Directory /usr/share/puppet/rack/puppetmasterd/>
                Options None
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>
/etc/apache2/sites-available/puppetmaster.conf después del cambio:
# This Apache 2 virtual host config shows how to use Puppet as a Rack
# application via Passenger. See
# http://docs.puppetlabs.com/guides/passenger.html for more information.

# You can also use the included config.ru file to run Puppet with other Rack
# servers instead of Passenger.

# you probably want to tune these settings
PassengerHighPerformance on
PassengerMaxPoolSize 12
PassengerPoolIdleTime 1500
# PassengerMaxRequests 1000
PassengerStatThrottleRate 120

Listen 8140

<VirtualHost *:8140>
        SSLEngine on
        SSLProtocol             ALL -SSLv2 -SSLv3
        SSLCipherSuite          EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
        SSLHonorCipherOrder     on

        SSLCertificateFile      /var/lib/puppet/ssl.ies/certs/puppetinstituto.pem
        SSLCertificateKeyFile   /var/lib/puppet/ssl.ies/private_keys/puppetinstituto.pem
        SSLCertificateChainFile /var/lib/puppet/ssl.ies/certs/ca.pem
        SSLCACertificateFile    /var/lib/puppet/ssl.ies/certs/ca.pem
        # If Apache complains about invalid signatures on the CRL, you can try disabling
        # CRL checking by commenting the next line, but this is not recommended.
        SSLCARevocationFile     /var/lib/puppet/ssl.ies/ca/ca_crl.pem
        # Apache 2.4 introduces the SSLCARevocationCheck directive and sets it to none
        # which effectively disables CRL checking; if you are using Apache 2.4+ you must
        # specify 'SSLCARevocationCheck chain' to actually use the CRL.
        # SSLCARevocationCheck chain
        SSLVerifyClient optional
        SSLVerifyDepth  1
        # The `ExportCertData` option is needed for agent certificate expiration warnings
        SSLOptions +StdEnvVars +ExportCertData

        # This header needs to be set if using a loadbalancer or proxy
        RequestHeader unset X-Forwarded-For

        RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
        RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
        RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

        DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
        RackBaseURI /
        <Directory /usr/share/puppet/rack/puppetmasterd/>
                Options None
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>
Está pensado para Ubuntu. Así que probadlo en Ubuntu aquellos que queráis, más que nada para testear su funcionamiento en otros centros y, si a todo el que lo haya probado le va bien, solicitamos su propagación mediante puppet. O, si le encontramos fallos, los corregimos.
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 20 de mayo de 2016

Clase frequency: Esablecer frecuencia de ejecución automática de pkgsync

Antes de nada, dar las gracias a Ismael por aceptar las sugerencias de mejora que vamos proponiendo y que es bueno aplicar en todos los centros.

Este post es para aclarar las dudas que algunos compañeros me han planteado sobre esta clase. Lo dejo escrito y así sirve para cuando a alguien más le surjan dudas:
  • La clase pkgsync-ies::frequency sirve para establecer una frecuencia de ejecución automática particular para cada tipo de máquina.
  • Se llama así (pkgsync-ies::frequency) porque en mi centro tengo un módulo para distribuir los ficheros de pkgsync .ies a los diferentes tipos de clientes del que forma parte. Este módulo contiene otro módulo más: pkgsync-ies:config. No lo he compartido porque lo retoqué para mostrar ejemplos representativos de diferentes formas de distribuir ficheros a los clientes. Si queréis podría estandarizarlo y compartirlo.
  • Contempla todos los posibles tipos de máquinas a las que el servidor presta servicio mediante expresiones regulares. Ésto significa que podréis establecer una frecuencia diferente para:
    • máquinas cuya variable facter use contenga las palabras portatil, workstation y ltsp.
    • máquinas cuya variable facter tipo contenga las palabras notebook, siatic e infolab.
  • Podéis modificar la frecuencia de ejecución para cada tipo de máquina con tan sólo cambiar el valor de la variable $FREQUENCY en cada caso del bloque que he marcado en color amarillo.
  • Si necesitáis añadir más casos de uso, podéis hacerlo. Se ha cambiado la forma de distribuir los módulos para que podamos adaptar los módulos recibidos en /etc/puppet/modules y nos sigan pasando módulos que no es conveniente modificar en otra ubicación.
class pkgsync-ies::frequency {

    if ($use =~ /portatil/) { $FREQUENCY="weekly" }      
   elsif ($use =~ /workstation/) { $FREQUENCY="daily" }  
   elsif ($use =~ /ltsp/) { $FREQUENCY="daily" }         

   if ($tipo =~ /notebook/) { $FREQUENCY="weekly" }      
   elsif ($tipo =~ /siatic/) { $FREQUENCY="daily" }      
   elsif ($tipo =~ /infolab/) { $FREQUENCY="daily" }     

   case $FREQUENCY {
      "weekly": {
         file { "/etc/cron.weekly/nightly-pkgsync":
            source => "puppet:///modules/pkgsync-ies/nightly-pkgsync",
            owner => root, group => root, mode => 755
         }
         file { "/etc/cron.daily/nightly-pkgsync":
            ensure => absent
         }
         file { "/etc/cron.monthly/nightly-pkgsync":
            ensure => absent
         }
      }
      "monthly": {
         file { "/etc/cron.monthly/nightly-pkgsync":
            source => "puppet:///modules/pkgsync-ies/nightly-pkgsync",
            owner => root, group => root, mode => 755
         }
         file { "/etc/cron.daily/nightly-pkgsync":
            ensure => absent
         }
         file { "/etc/cron.weekly/nightly-pkgsync":
            ensure => absent
         }
      }
      default: {
         file { "/etc/cron.daily/nightly-pkgsync":
            source => "puppet:///modules/pkgsync-ies/nightly-pkgsync",
            owner => root, group => root, mode => 755
         }
         file { "/etc/cron.monthly/nightly-pkgsync":
            ensure => absent
         }
         file { "/etc/cron.weekly/nightly-pkgsync":
            ensure => absent
         }
      } # default="daily"
   } # end case
} # end class
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 19 de mayo de 2016

pkgsync 1.27: Añadida nueva funcionalidad

Como ya hemos hablado en alguna ocasión, hay máquinas en las que no nos interesa ejecutar pkgsync automáticamente, como por ejemplo en portátiles porque puede crearnos problemas. 

Para poder desactivar la ejecución automática de pkgsync añadimos una mejora a la versión 1.26 que consistía en añadir un parámetro ENABLE al fichero de configuración /etc/default/pkgsync, de manera que nos permita activar o desactivar pkgsync en el cliente: 
  • ENABLE="yes": activa pkgsync (opción por defecto) 
  • ENABLE="no" : desactiva pkgsync 
  • Si no existe la variable ENABLE en el fichero /etc/default/pkgsync o no tiene valor, es equivalente al valor ’yes’. 
El problema es que si desactivamos completamente pkgsync, no lo vamos a poder ejecutar ni de forma manual, ni de forma automática. 

Para permitir la ejecución de pkgsync de forma manual, he introducido un nuevo parámetro en la versión 1.27: -f o --force  con el que podemos ejecutar pkgsync de forma manual estando desactivada la ejecución automática.
# pkgsync -f

Aquí podéis ver el código completo de pkgsync:

Y si queréis descargar el paquete que instala esta versión de pkgsync, aquí lo tenéis:
https://copy.com/d2n3dZ2izAlvj6fH
Publicado por primera vez en http://enavas.blogspot.com.es

Propuesta de gestión de módulos Puppet de forma compartida entre administradores y la sección de administración de sistemas

Para gestionar módulos puppet de forma compartida entre administradores y la sección de administración de sistemas, propongo:
  • Que los administradores coloquemos nuestros módulos puppet en /etc/puppet/modules
  • Que los módulos puppet suministrados por la Sección de Administración de Sistemas se coloquen en /usr/share/puppet/modules
Puppet tiene configurado como valor por defecto buscar los módulos en ambas ubicaciones:
# puppet config print modulepath
/etc/puppet/modules:/usr/share/puppet/modules
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 18 de mayo de 2016

Sincronizar los módulos de un servidor puppet en otro

Es muy sencillo y verdaderamente útil sincronizar el contenido de un directorio entre el servidor puppet y clientes. 

El caso más claro es aquél en que tenemos un servidor puppet que debe distribuir módulos a otros servidores puppet, como puede ocurrir en los CPR's, donde es interesante que el servidor del CPR suministre módulos puppet a los servidores de colegios; o, el caso de la sección de administración de sistemas, donde hay un servidor que distribuye módulos puppet a los servidores de todos los centros.

Distribuir los módulos es tan sencillo como crear un módulo que contenga la siguiente clase:
class modulesync {
   file { '/etc/puppet/modules':
      ensure  => directory,
      source  => 'puppet:///modules/modulesync/modules',
      owner   => puppet,
      group   => puppet,
      mode    =>  0755,
      recurse => true,   # entrar en subdirectorios
      replace => true,   # reemplazar ficheros que ya existan
      purge   => false,  # no eliminar ficheros que no tengamos
      links   => follow, # seguir enlaces y modificar el objetivo del link
      force   => false
   }
}
Si os fijáis en los dos atributos que he resaltado en color amarillo, le estamos diciendo a puppet que reemplace el contenido del directorio modules y todo su contenido (recurse => true) y que reemplace los ficheros que ya existan (replace => true). Ésta última opción es la opción por defecto, es decir, que no habría que especificarla expresamente. 

Podríamos utilizar este módulo en servidores puppet de CPR's para distribuir módulos a servidores de colegios. Ahora bien,  si la sección de administración de sistemas distribuye módulos a todos los centros, tanto de primaria como de secundaria, no podremos gestionar el recurso /etc/puppet/modules porque ya lo gestionan ellos. En ese caso, es preferible que nos distribuyan los módulos utilizando la opción replace => false para que los administradores podamos modificar los módulos que nos distribuyen.
class modulesync {
   file { '/etc/puppet/modules':
      ensure  => directory,
      source  => 'puppet:///modules/modulesync/modules',
      owner   => puppet,
      group   => puppet,
      mode    =>  0755,
      recurse => true,   # entrar en subdirectorios
      replace => false,  # no reemplazar ficheros que ya existan
      purge   => false,  # no eliminar ficheros que no tengamos
      links   => follow, # seguir enlaces y modificar el objetivo del link
      force   => false
   }
}
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 17 de mayo de 2016

Utilizar expresiones regulares en clases puppet

Me preguntaba un compañero cómo podía hacer referencia a un conjunto de nodos concretos con los siguientes nombres de host: siatic-informatica-01,
 siatic-intormatica-02,..., siatic-informatica-30.

Como podemos hacer uso de expresiones regulares en una clase puppet, es muy sencillo identificar los hosts en función del nombre del host obtenido de la variable facter hostname. Por ejemplo:
if $hostname =~ /^siatic-informatica-(\d+)/ {
   lista de includes
}
Si os dáis cuenta:
  • Estamos usando el operador =~ para comparar el contenido de la variable facter hostname con la expresión regular. En la comparación de expresiones regulares también podríamos utilizar el operador de no coincidencia !~
  • La espresión regular es aquella que va entre los símbolos /    /
  • En este caso estamos definiendo una expresión regular que se refiere a un nombre que comienza por la cadena siatic-informatica- y a continuación tiene un número cualquiera de dígitos.
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 14 de mayo de 2016

Extremadura: Des-coordinación TIC en Educación

Viendo el vídeo de esta comisión de Educación, Empleo y Deportes, tan sólo saco una conclusión: O no les han informado bien, o lo único que interesa es excusarse y no importa si las cosas se están haciendo bien o mal para buscar una solución.

Desde luego, estamos ya en el tercer trimestre, dicen que la fase de puesta en marcha óptima del sistema finalizó y lo cierto es que todo sigue teniendo los mismos problemas que cuando el material se suministró. Os lo dice un administrador informático que está cada día al pie del cañón.

Dicen que han organizado un "comité de expertos". Muy bien. ¿Pero para qué? Desde luego, para solucionar los problemas técnicos, tengo claro que no, porque para ello tendrían que haber contado con el colectivo de administradores informáticos y para eso no hemos recibido ninguna comunicación. 

Como bien se dice en esta comisión, se ha creado un foro de administradores
que para nosotros no tiene ninguna utilidad, básicamente por dos razones:
  • Nos da la impresión de se ha convertido tan sólo en un diario personal donde contamos los problemas del sistema, ofrecemos nuestra opinión de cómo se podría actuar, de las cosas que se deberían hacer, etc.. pero no sirve para nada porque los responsables de dar respuesta no contestan.
  • Ya teníamos una lista para comunicarnos, el foro no aporta nada nuevo y las informaciones no se organizarían bien.

Los administradores informáticos tan sólo queremos prestar un buen servicio a los centros y nos resulta muy difícil sin información y planificación.

Necesitamos:
  • Más información sobre el nuevo sistema que debemos gestionar en cuestiones técnicas que nos planteamos para actuar en consecuencia.
  • Que exista una mejor comunicación con nosotros y con la Sección de Administración de Sistemas.
  • Es imprescindible que se cuente con los técnicos a la hora de diseñar cualquier solución para que cualquier cambio en el sistema sea óptimo y se eviten los problemas que estamos sufriendo actualmente.
  • La formación específica es fundamental. Nuestro principal interés es recibir formación concreta para nuestro trabajo.
  • Laboratorios que usemos tanto para la formación como para la realización de pruebas fuera del entorno de producción, ubicados en CPR's distribuidos en diferentes zonas. Las pruebas deben realizarse en entornos de pruebas y no entornos de producción. De lo contrario, pueden acarrearse muchos problemas.
  • Pero sobre todo, necesitamos organización y planificación. Estamos en el tercer trimestre y seguimos trabajando de forma aislada para solucionar cada uno los problemas de su centro, cuando se podría trabajar en equipo para tener un sistema funcional y verdaderamente bueno con una cierta uniformidad. Con la forma de trabajo actual, como cada uno aplica soluciones particulares en su centro, lo que se está consiguiendo es que el sistema se convierta en algo demasiado heterogéneo que será cada vez más difícil de gestionar. Se podrían establecer grupos de trabajo y administradores de referencia en torno a los diferentes servicios que debe proporcionar el sistema, pero todo ésto requiere una organización y coordinación.
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 11 de mayo de 2016

pkgsync 1.26-2: Añadida nueva funcionalidad

Cuando envié el paquete pkgsync para distribuir a todos los servidores puppet de los centros, recibí una propuesta de mejora de nuestro compañero Antonio Abasolo, que pareció muy interesante incluir en la versión 1.26

Esta mejora consiste en añadir un parámetro ENABLE al fichero de configuración /etc/default/pkgsync, de manera que nos permita activar o desactivar pkgsync en el cliente: 
  • ENABLE="yes": activa pkgsync (opción por defecto) 
  • ENABLE="no" : desactiva pkgsync 
  • Si no existe la variable ENABLE en el fichero /etc/default/pkgsync o no tiene valor, es equivalente al valor ’yes’. 
Es una mejora que nos viene muy bien para desactivar pkgsync, por ejemplo, en portátiles, donde su uso puede ser más problemático. 
Posteriormente, a propuesta de Antonio también, he creado una versión 1.26-2 en la que corregía dos pequeñas cosas: 
  • La forma de mostrar el mensaje que informa de que pkgsync ha sido desactivado. 
  • Los comentarios explicativos del uso del parámetro ENABLE en el fichero de configuración /etc/default/pkgsync. 
Aquí podéis ver el código completo de pkgsync:
Y si queréis descargar el paquete que instala esta versión de pkgsync, aquí lo tenéis:
https://copy.com/d2n3dZ2izAlvj6fH
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 7 de mayo de 2016

Subir un archivo a Mega utilizando megatools

megatools nos ofrece un conjunto de herramientas para gestionar nuestro espacio de almacenamiento en Mega desde la línea de comandos: 
  • megareg: Nos permite registrar y verificar una nueva cuenta de mega.
  • megadf: Muestra la información del espacio de almacenamiento en términos de uso.
  • megals: Lista los ficheros almacenados en la cuenta.
  • megamkdir: Crea un directorio en nuestra cuenta de mega.
  • megarm: Elimina un fichero o directorio de nuestro espacio de almacenamiento.
  • megaput: Permite subir archivos individuales.
  • megaget: Permite descargar archivos individuales.
  • megadl: Descarga un fichero desde un enlace público de mega.
  • megacopy: Sube o descarga un árbol de directorios.
  • megafs: Nos permite montar el sistema de ficheros remoto localmente.
Veamos un ejemplo de subida del paquete megatools a nuestra cuenta de Mega:
# megaput -u miusuario@gmail.com megatools_1.9.97-1_i386.deb 
Enter password for (miusuario@gmail.com): 
Good, signing in...
Uploaded megatools_1.9.97-1_i386.deb
Publicado por primera vez en http://enavas.blogspot.com.es

Paquete megatools_1.9.97-1_i386.deb compilado para Debian Wheezy

Como ya comentamos en un post anterior, megatools es un cliente de línea de comandos para mega.nz, algo que nos va a permitir utilizar Mega en servidores para realizar copias de seguridad en la nube o descargar archivos directamente en el servidor. 

He creado un paquete de megatools mediante checkinstall para poder instalarlo en Debian Wheezy de 32 bits.
https://mega.nz/#!5wUwjY7K!U5-1TzcgD3qKKxgF61iih_NzOa6IZUEvThJ7r_DwEgg

Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 6 de mayo de 2016

Crear un mirror local con apt-mirror para los nuevos Ubuntu-Linex enviados a los centros

En los centros ya tenemos un mirror de Debian creado con una herramienta llamada debmirror. Como ya comenté en un post del año 2012, apt-mirror es otra excelente herramienta para crear mirrors de repositorios.

Aprovechando que no me convencía tener el nuevo servidor con un sistema de 32 bits, que disponer de un mirror facilita enormemente el trabajo de actualizar paquetes en los clientes y reduce el consumo de ancho de banda, ya puestos en faena, decidí crear un mirror de Ubuntu para los nuevos Ubuntu-Linex enviados a los centros partiendo de que ya tenía escrito el post del año 2012, en el que hablaba de apt-mirror.

apt-mirror maneja los siguientes ficheros de configuración y directorios:
  • /etc/apt/mirror.list: Es el principal fichero de configuración.
  • /etc/cron.d/apt-mirror: Es una plantilla de configuración de cron para lanzar apt-mirror de forma programada
  • /var/spool/apt-mirror/mirror: Es el directorio donde se guardará el mirror.
  • /var/spool/apt-mirror/skel: Es un directorio para almacenar temporalmente los índices descargados.
  • /var/spool/apt-mirror/var: Es un directorio donde se guardan los logs, urls y hashes md5.
Primero instalamos apache2 (si no lo tenemos instalado ya) para servir los paquetes del mirror:
# apt-get install apache2
A continuación instalamos el paquete apt-mirror:
# apt-get install apt-mirror
Una vez instalados los paquetes, hacemos una copia del fichero de configuración principal, para recurrir a él, si fuera necesario:
# cp /etc/apt/mirror.list /etc/apt/mirror.list.orig
Y editamos el fichero:
# nano /etc/apt/mirror.list
############# config ##################
#
# set base_path    /var/spool/apt-mirror
#
# set mirror_path  $base_path/mirror
# set skel_path    $base_path/skel
# set var_path     $base_path/var
# set cleanscript $var_path/clean.sh
# set defaultarch  
# set postmirror_script $var_path/postmirror.sh
# set run_postmirror
set nthreads     20
set _tilde 0
set limit_rate 1000k
#
############# end config ##############

#deb http://ftp.us.debian.org/debian unstable main contrib non-free
##deb-src http://ftp.us.debian.org/debian unstable main contrib non-free

# mirror additional architectures
#deb-alpha http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-amd64 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-armel http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-hppa http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-i386 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-ia64 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-m68k http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-mips http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-mipsel http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-powerpc http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-s390 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-sparc http://ftp.us.debian.org/debian unstable main contrib non-free

#clean http://ftp.us.debian.org/debian

#deb cdrom:[Ubuntu 14.04.3 LTS _Trusty Tahr_ - Beta i386 (20150805)]/ trusty main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty main restricted
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty universe
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty universe
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty multiverse
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty multiverse
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb-i386 http://es.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-amd64 http://es.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse

deb-i386 http://security.ubuntu.com/ubuntu trusty-security main restricted
deb-amd64 http://security.ubuntu.com/ubuntu trusty-security main restricted
deb-i386 http://security.ubuntu.com/ubuntu trusty-security universe
deb-amd64 http://security.ubuntu.com/ubuntu trusty-security universe
deb-i386 http://security.ubuntu.com/ubuntu trusty-security multiverse
deb-amd64 http://security.ubuntu.com/ubuntu trusty-security multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu trusty partner

## This software is not part of Ubuntu, but is offered by third-party
## developers who want to ship their latest software.
deb-i386 http://extras.ubuntu.com/ubuntu trusty main
deb-amd64 http://extras.ubuntu.com/ubuntu trusty main

clean http://es.archive.ubuntu.com/ubuntu/
clean http://security.ubuntu.com/ubuntu/
clean http://extras.ubuntu.com/ubuntu/

Como podéis ver, en la sección de configuración, todos los parámetros de ubicación de ficheros están comentados. No los he "descomentado" porque quiero que se almacenen en la ubicación por defecto.

Tampoco he tocado la opción set defaultarch que nos permite indicar la arquitectura de paquetes por defecto. Por ejemplo:

# set defaultarch amd64

También he dejado por defecto set nthreads 20 para indicar que se usen 20 hilos.

set nthreads 20

Y he añadido set limit_rate 1000k para establecer un límite de consumo de ancho de banda de descarga de 1000k por hilo. Apt-mirror usa wget para descargar los paquetes y mediante este parámetro limitamos la tasa de descarga.

set limit_rate 1000k

Como se puede apreciar en el fichero de configuración, estoy creando específicamente el repositorio con:
  • paquetes de 64 bits: deb-amd64  
  • y paquetes de 32 bits: deb-i386
Por último, en el fichero de configuración veréis las siguientes línea:

clean http://es.archive.ubuntu.com/ubuntu/
clean http://security.ubuntu.com/ubuntu/
clean http://extras.ubuntu.com/ubuntu/

Estas líneas le dicen a apt-mirror en qué directorios del disco duro local debería chequear para ver si se puede liberar espacio.

Con ésto, como se puede ver en el archivo de configuración, voy a crear los siguientes mirrors:

/var/spool/apt-mirror/mirror/
├── es.archive.ubuntu.com
│   └── ubuntu
│       ├── dists
│       │   ├── trusty
│       │   ├── trusty-backports
│       │   └── trusty-updates
│       └── pool
│           ├── main
│           ├── multiverse
│           ├── restricted
│           └── universe
├── extras.ubuntu.com
│   └── ubuntu
│       └── dists
│           └── trusty
└── security.ubuntu.com
    └── ubuntu
        ├── dists
        │   └── trusty-security
        └── pool
            ├── main
            ├── multiverse
            ├── restricted
            └── universe

Bien, pues una vez que ya tenemos los repositorios en /var/spool/apt-mirror/mirror, vamos a crear enlaces en /var/www para que los paquetes del repositorio sean servidos por apache:
# cd /var/www
# ln -s /var/spool/apt-mirror/mirror/es.archive.ubuntu.com/ubuntu/ es.archive.ubuntu.com
# ln -s /var/spool/apt-mirror/mirror/extras.ubuntu.com/ubuntu/ extras.ubuntu.com
# ln -s /var/spool/apt-mirror/mirror/security.ubuntu.com/ubuntu/ security.ubuntu.com
Una vez que tengamos el enlace creado, el siguiente paso será editar el fichero /etc/cron.d/apt-mirror y modificar la hora de puesta en marcha de la creación del mirror:
# /etc/cron.d/apt-mirror
# Regular cron jobs for the apt-mirror package
#
00 22    * * *    apt-mirror    /usr/bin/apt-mirror > /var/spool/apt-mirror/var/cron.log
Por otra parte, crearemos un fichero cron para matar la tarea anterior a cierta hora:
# Kill the apt-mirror
#
45 7    * * *    apt-mirror    killall -9 apt-mirror
46 7    * * *    root          /var/spool/apt-mirror/var/clean.sh
Y eso es todo. Cuando lleguen las 22:00 comenzará la creación del mirror y terminará a las 7:45 de la mañana del día siguiente.

Por último, tan sólo me queda mencionar cómo usar los repositorios en el fichero /etc/apt/sources.list de los clientes.

Al haber creado el mirror y los enlaces como he explicado, es muy sencillo modificar cada una de las entradas del sources.list.
Veamos un ejemplo:
Si utilizamos el mirror de Ubuntu:
deb http://es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
No tenemos más que cambiarlo por:
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
Y así con todos los repositorios.

De este modo es como quedaría el /etc/apt/sources.list de un cliente:
#deb cdrom:[Ubuntu 14.04.3 LTS _Trusty Tahr_ - Beta i386 (20150805)]/ trusty main restricted

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
#deb http://es.archive.ubuntu.com/ubuntu/ trusty main restricted
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty main restricted
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty main restricted

## Major bug fix updates produced after the final release of the
## distribution.
#deb http://es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
#deb http://es.archive.ubuntu.com/ubuntu/ trusty universe
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty universe
#deb http://es.archive.ubuntu.com/ubuntu/ trusty-updates universe
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty-updates universe
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty universe
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
#deb http://es.archive.ubuntu.com/ubuntu/ trusty multiverse
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty multiverse
#deb http://es.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty-updates multiverse
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty multiverse
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
#deb http://es.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
#deb-src http://es.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb http://servidor/es.archive.ubuntu.com/ubuntu/ trusty-backports main restricted universe multiverse

#deb http://security.ubuntu.com/ubuntu trusty-security main restricted
#deb-src http://security.ubuntu.com/ubuntu trusty-security main restricted
#deb http://security.ubuntu.com/ubuntu trusty-security universe
#deb-src http://security.ubuntu.com/ubuntu trusty-security universe
#deb http://security.ubuntu.com/ubuntu trusty-security multiverse
#deb-src http://security.ubuntu.com/ubuntu trusty-security multiverse
deb http://servidor/security.ubuntu.com/ubuntu trusty-security main restricted
deb http://servidor/security.ubuntu.com/ubuntu trusty-security universe
deb http://servidor/security.ubuntu.com/ubuntu trusty-security multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu trusty partner
# deb-src http://archive.canonical.com/ubuntu trusty partner

## This software is not part of Ubuntu, but is offered by third-party
## developers who want to ship their latest software.
#deb http://extras.ubuntu.com/ubuntu trusty main
#deb-src http://extras.ubuntu.com/ubuntu trusty main
deb http://servidor/extras.ubuntu.com/ubuntu trusty main
En mi opinión, es interesante crear una entrada DNS en el servidor ldap a la que llamemos mirror que apunte al servidor  en que tenemos almacenado el mirror. De este modo, si en algún momento necesitamos cambiar el mirror que vamos a usar, no tendremos más que cambiar esa entrada en el servidor ldap para que apunte a otro mirror.
Publicado por primera vez en http://enavas.blogspot.com.es

Exportar mi clave pública y mi clave privada

Exportar nuestra clave pública y nuestra clave privada puede ser útil cuando queremos tener una copia de seguridad o utilizarlas en otra máquina diferente, por ejemplo.

Para exportar la clave pública, lo primero que necesito saber es el identificador de clave. Y eso puedo averiguarlo simplemente utilizando el comando gpg --list-keys:
$ gpg --list-keys
/home/enam0000/.gnupg/pubring.gpg
---------------------------------
pub   1024D/153F5386 2009-12-01
uid                  Esteban M. Navas Martín (Administrador Informatico) <adminies.valledeljerte@juntaextremadura.net>
sub   2048g/83061C03 2009-12-01
Una vez que conozco el identificador, exportar la clave pública es muy sencillo: 
$ gpg --export --armor 153F5386
Y exportar la clave privada también:
$ gpg --export-secret-key --armor 153F5386
Publicado por primera vez en http://enavas.blogspot.com.es

Proteger entradas de Grub2 con password

Hasta ahora trabajábamos con Debian en los centros educativos, y, por las razones que sea, alguien decidió cambiar a Ubuntu en máquinas cliente. El problema es que se nos han entregado máquinas nuevas con Xubuntu y las máquinas que ya teníamos, siguen teniendo Debian.

Como no es práctico, tanto para los usuarios como los administradores, gestionar dos sistemas diferentes, estamos preparando imágenes para migrar las máquinas cliente con Debian a Ubuntu y que todo el entorno sea uniforme para el usuario.

Con la ayuda de mi alumno de prácticas, Sergio, estoy preparando una imagen de 64 bits Xubuntu y otra de 32 bits que vamos a  usar como modelo para  lograr esa uniformidad. Ésto es algo que lleva trabajo y tiempo porque ya teníamos implantadas muchas mejoras que hay que testear en Ubuntu.

La cuestión es que en nuestros sistemas Debian teníamos una partición de autorestauración con clonezilla que nos permitía restaurar o hacer un backup del sistema fácilmente desde entradas de grub protegidas con contraseña, y, al tratar de implantar el sistema en Xubuntu, nos hemos dado cuenta de que hay algunas variaciones a la hora de proteger entradas de grub2 con password. Y esas variaciones vienen motivadas porque Debian Wheezy utilizaba la versión 1.99 de grub2 y tanto Ubuntu 14.04 com Debian Jessie usan la versión 2.xx de grub2.

Así que vamos a ver cómo hemos realizado los cambios para proteger las entradas de grub2 en los nuevos equipos con Xubuntu.

Lo primero que hay que decir es que, en principio, nos interesa que el usuario pueda seleccionar tan sólo la opción de iniciar ubuntu sin tener que introducir una password de grub2. El resto de entradas: opciones avanzadas, crear un backup del sistema, restaurar un backup del sistema, ... deben requerir que el usuario introduzca una password.

Primero.- Debemos crear contraseñas encriptadas para aquellos usuarios que deban tener acceso. Para ello, utilizaremos grub-mkpasswd-pbkdf2. Por ejemplo:
# grub-mkpasswd-pbkdf2

Introduzca la contraseña: 
Reintroduzca la contraseña: 
El hash PBKDF2 de su contraseña es grub.pbkdf2.sha512.10000.F3BBCA221181E11CFFB0F88917D1D39CB3BE23C88559B15AF31C7DC1C7197D7276B79D2985538AE046A510AFC58EDFB554C23FF72102F74B79BB020B73EB6AD7.104336C8A35ED8D53BBCBE2A27784281D2D13843CD408B1CF6405308F6DCB3DD4271F9CB9909178AE25F82D834EDA59DFB2BBC60CB37ED1EB245C3DF9D28ECEB
Como podéis ver, la herramienta nos pide que introduzcamos dos veces la contraseña para asegurar que es correcta y crea el hash.

Segundo.- En principio, podríamos poner directamente la información de usuarios en el fichero /etc/grub.d/00_header. No obstante, por cuestiones de organización y claridad, vamos a crear un fichero /etc/grub.d/01_password en el que definiremos expresamente la información relativa a usuarios de grub. Veamos un ejemplo:
# cat /etc/grub.d/01_password

#!/bin/sh
cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.9D8920FDD6AEBB0CBDA90902E4C5B33117713DF9F56B34E4C8138B7B69723121E8BE423A43244238C40C8D32EE1B05E1C05FCE1B0CAC9D7F8EB63B8052DF6C5E.72A8ED09C9C6CCD396090A10305F1A395D6BFAC227C1196F54B59067295AA29B017C33954138F246426C2C099E2C3974B26A79846DE480CC3108C3CB2E97A540
EOF
En este fichero de ejemplo, estamos definiendo tan sólo un usuario "root", pero podríamos definir también un usuario "clonezilla" que utilizáramos única y exclusivamente en las entradas de clonezilla.
Pero, además, estamos diciendo que el superusuario se llama "root".
# cat /etc/grub.d/01_password

#!/bin/sh
cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.9D8920FDD6AEBB0CBDA90902E4C5B33117713DF9F56B34E4C8138B7B69723121E8BE423A43244238C40C8D32EE1B05E1C05FCE1B0CAC9D7F8EB63B8052DF6C5E.72A8ED09C9C6CCD396090A10305F1A395D6BFAC227C1196F54B59067295AA29B017C33954138F246426C2C099E2C3974B26A79846DE480CC3108C3CB2E97A540
password_pbkdf2 clonezilla grub.pbkdf2.sha512.10000.521C3D1C22CF1592862FD809FEFC0124FD4331303EE8B735679AE53440B7E0C0FF2879DE6E8C176CAB57C1B55345D65AC6D280A32A0280BDEF1EE85D59A15B2C.CFE0974C2BFF35E8E31229AA286ED76B6F0E0E950AA1B9F83AD7597AB68E786817F9C080A29D9402449682AED43719BD7A262D862F6710CED5839E2E2F181E85
EOF
Es importante tener en cuenta que los usuarios definidos como superusuarios podrán:
  • Iniciar cualquier entrada de grub2.
  • Editar items en el menú  de grub2 durante el boot.
  • Usar la línea de comandos de grub2.
Además, podríamos definir todos los usuarios que quisiéramos con el fin de permitir realizar determinadas acciones a dichos usuarios.
Tercero.- Damos permisos de ejecución al fichero /etc/grub.d/01_password:
# chmod +x /etc/grub.d/01_password
Cuarto.- Editamos el archivo /etc/grub.d/10_linux y buscamos las siguientes líneas:
echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {" | sed "s/^/$submenu_indentation/"

echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
Y las modificamos para que queden de la siguiente manera:
echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} --unrestricted \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {" | sed "s/^/$submenu_indentation/"

echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} --unrestricted \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
Si os dáis cuenta, el cambio que hemos realizado ha sido añadir la opción "--unrestricted" para que la entrada que arranca Ubuntu pueda ser utilizada por cualquier usuario sin tener que introducir username y password.

Cuarto.- Ejecutamos el comando update-grub2 para que se regenere el fichero de configuración /boot/grub/grub.cfg:
# update-grub2
De este modo, todas las entradas estarían restringidas, salvo la primera que permite arrancar el sistema operativo. Esto es interesante cuando tenemos entradas de grub que permiten arrancar clonezilla, realizar un backup del sistema, restaurarlo o iniciar una herramienta como udpcast, operaciones reservadas para el administrador.

Las entradas que inician clonezilla y udpcast, las hemos colocado en el archivo /etc/grub.d/40_custom.
menuentry "Arrancar Clonezilla" {
   set root=(hd0,3)
   linux /live-hd/vmlinuz boot=live live-config noswap nolocales edd=on nomodeset ocs_live_run=\"ocs-live-general\" ocs_live_extra_param=\"\" keyboard-layouts=\"\" ocs_live_batch=\"no\" locales=\"\" vga=788 ip=frommedia nosplash live-media-path=/live-hd bootfrom=/dev/sda3 toram=filesystem.squashfs
   initrd /live-hd/initrd.img
}

menuentry "Restaurar sistema con Clonezilla (/dev/sda1, /dev/sda2) sin modificar la partición home (/dev/sda6)" {
   set root=(hd0,3)
   linux /live-hd/vmlinuz boot=live live-config noswap nolocales edd=on nomodeset noprompt ocs_live_run=\"ocs-live-restore\" ocs_live_extra_param=\" -e1 auto -e2 -c -r -j2 -k -p reboot restoreparts backup-miniportatil-sin-home sda1 sda2\" keyboard-layouts=\"NONE\" ocs_live_batch=\"yes\" locales=\"es_ES.UTF-8\" vga=788 ip=frommedia nosplash live-media-path=/live-hd bootfrom=/dev/sda3 
   initrd /live-hd/initrd.img
}

menuentry "Realizar backup del sistema con Clonezilla (/dev/sda1, /dev/sda2) excluyendo la partición home (/dev/sda6)" {
   set root=(hd0,3)
   linux /live-hd/vmlinuz boot=live live-config noswap nolocales edd=on nomodeset noprompt ocs_live_run=\"ocs-live-restore\" ocs_live_extra_param=\" -q2 -c -j2 -z1 -i 10000000 -p reboot saveparts backup-miniportatil-sin-home sda1 sda2\" keyboard-layouts=\"NONE\" ocs_live_batch=\"yes\" locales=\"es_ES.UTF-8\" vga=788 ip=frommedia nosplash live-media-path=/live-hd bootfrom=/dev/sda3 
   initrd /live-hd/initrd.img
}

menuentry "Udpcast" {
    set root=(hd0,1)
    linux /udpcast/linux
    initrd /udpcast/initrd
} 
Si ahora quisiéramos que las entradas de clonezilla pudieran ser utilizadas tanto por el usuario root como por el usuario clonezilla, les añadiríamos la siguiente opción: "--users clonezilla":
menuentry "Arrancar Clonezilla" --users "clonezilla" {
   set root=(hd0,3)
   linux /live-hd/vmlinuz boot=live live-config noswap nolocales edd=on nomodeset ocs_live_run=\"ocs-live-general\" ocs_live_extra_param=\"\" keyboard-layouts=\"\" ocs_live_batch=\"no\" locales=\"\" vga=788 ip=frommedia nosplash live-media-path=/live-hd bootfrom=/dev/sda3 toram=filesystem.squashfs
   initrd /live-hd/initrd.img
}

menuentry "Restaurar sistema con Clonezilla (/dev/sda1, /dev/sda2) sin modificar la partición home (/dev/sda6)" --users "clonezilla" {
   set root=(hd0,3)
   linux /live-hd/vmlinuz boot=live live-config noswap nolocales edd=on nomodeset noprompt ocs_live_run=\"ocs-live-restore\" ocs_live_extra_param=\" -e1 auto -e2 -c -r -j2 -k -p reboot restoreparts backup-miniportatil-sin-home sda1 sda2\" keyboard-layouts=\"NONE\" ocs_live_batch=\"yes\" locales=\"es_ES.UTF-8\" vga=788 ip=frommedia nosplash live-media-path=/live-hd bootfrom=/dev/sda3 
   initrd /live-hd/initrd.img
}

menuentry "Realizar backup del sistema con Clonezilla (/dev/sda1, /dev/sda2) excluyendo la partición home (/dev/sda6)" --users "clonezilla" {
   set root=(hd0,3)
   linux /live-hd/vmlinuz boot=live live-config noswap nolocales edd=on nomodeset noprompt ocs_live_run=\"ocs-live-restore\" ocs_live_extra_param=\" -q2 -c -j2 -z1 -i 10000000 -p reboot saveparts backup-miniportatil-sin-home sda1 sda2\" keyboard-layouts=\"NONE\" ocs_live_batch=\"yes\" locales=\"es_ES.UTF-8\" vga=788 ip=frommedia nosplash live-media-path=/live-hd bootfrom=/dev/sda3 
   initrd /live-hd/initrd.img
}

menuentry "Udpcast" {
    set root=(hd0,1)
    linux /udpcast/linux
    initrd /udpcast/initrd
} 
Publicado por primera vez en http://enavas.blogspot.com.es