Algo de Linux: 2018

viernes, 20 de julio de 2018

Paquete pkgsync 1.58: Añadidos parámetros al comando pkgsync

En la versión 1.58  he añadido dos nuevos parámetros a /usr/local/sbin/pkgsync:
  • -n, --no-sincpuppet : Permite evitar que se ejecute pkgsync al utilizar el párametro (Recordad que el comportamiento por defecto es que siempre se realice un sinc_puppet antes de realizar la instalación/desinstalación de paquetes).
  • -g, --get-keys: Ejecuta launchpad-keys para obtener claves públicas de repositorios.

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


Si queréis descargar el paquete que instala esta versión, podéis hacerlo desde el siguiente link:

https://drive.google.com/open?id=1ReSd8I8_DdZfmhUi4aX5idk0OFvP5inL
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 19 de julio de 2018

Proxmox: Cambiar el hostname de la máquina del contenedor

Es importante saber que cuando usamos un contenedor y queremos cambiar el hostname de la máquina, no sirve con cambiar el fichero /etc/hostname y el /etc/hosts. Lo que tenemos que hacer es utilizar el comando pct de Proxmox para realizar el renombrado. Veamos cómo con un ejemplo:

Vamos a comprobar qué máquinas virtuales tengo en mi servidor, cuál es su estado y su hostname:
# pct list
VMID       Status     Lock         Name                
105        stopped                 fogserver
Como podéis observar, tengo una sola máquina (fogserver) a la que quiero cambiar el hostname por fogauxiliar. Para cambiarlo, no tengo nada más que hacer lo siguiente:
# pct set 105 --hostname fogauxiliar
Como podéis observar estoy diciendo a Proxmox que cambie el hostname de la máquina alojada en el contenedor con identificador 105 por fogauxiliar.
# pct list
VMID       Status     Lock         Name                
105        stopped                 fogauxiliar
Si os conectáis a la máquina mediante ssh, comprobaréis que en el fichero /etc/hostname y el fichero /etc/hosts se encuentra el nuevo nombre de la máquina.
Publicado por primera vez en http://enavas.blogspot.com.es

Proxmox: Iniciar, parar y comprobar el estado de un contenedor KVM desde la línea de comandos

En un post de 2016 vimos como iniciar, parar y comprobar el estado de una máquina virtual KVM desde la línea de comandos en Proxmox. En este post vamos va ver cómo utilizar la herramienta pct de Proxmox para gestionar contenedores de Qemu/KVM.

Tanto para iniciar una máquina virtual como para pararla o consultar su estado, necesito conocer el vmid (identificador de la máquina virtual). ¿Y qué es lo que puedo hacer para obtenerlo? Bueno, pues simplemente obtener un listado de los contenedores que tengo en Proxmox. Por ejemplo:
# pct list
VMID       Status     Lock         Name                
105        stopped                 fogserver      
Como podéis comprobar, tan sólo tengo un contenedor en el servidor del ejemplo anterior, con identificador 105 y se encuentra parado.

Si quisiera iniciar el contenedor fogserver con identificador vmid 105, tan sólo tendría que ejecutar el siguiente comando:
# pct start 105
Para comprobar que se encuentra arrancada, haría lo siguiente:
# pct status 105
status: running
Con lo que comprobaría que está corriendo.

Y si por alguna razón, quisiera apagar el contenedor, no tendría más que hacer un:
# pct shutdown 105
Publicado por primera vez en http://enavas.blogspot.com.es

FOG Project: Importar/Exportar configuración

La opción de exportación de configuración de FOG nos va a permitir realizar backups de la configuración de nuestro servidor FOG para poder recuperarlo fácilmente en caso de fallo. 

En cuanto a la opción de importación, nos va a permitir restaurar copias de seguridad de la configuración que tengamos almacenadas.

Si yo guardo copias de seguridad de la configuración, junto con las imágenes de clonación almacenadas en el directorio /images del servidor, podré recuperarlo fácilmente en caso de desastre. Pero no sólo eso. Sino que también voy a poder migrar la configuración de un servidor a otro, o incluso, clonarlo y cambiar sus datos para disponer de más servidores de clonación.

Por ejemplo: En mi caso, cuento con dos servidores Proxmox y, en uno de ellos, tengo alojado en un contenedor, un servidor FOG. 

Por otro lado, la máquina con la que trabajo, tiene también instalado un servidor Proxmox en el que he restaurado el backup de la máquina virtual del servidor FOG y he modificado sus datos para disponer de un segundo servidor. También cuento con un par de switches de 24 puertos no gestionables conectados entre sí y mi máquina se encuentra conectada a uno de ellos. La idea es poder conectar clientes en los switches y clonarlos en el mismo segmento LAN del servidor FOG instalado en mi máquina. 

En la siguiente imagen, podéis ver en qué opción del menú de configuración debéis entrar para acceder a las opciones de importación/exportación de la configuración:



El menú concreto es "Configuration save" . Al hacer clic sobre él dispondremos de las dos opciones: 
  • Export Database.
  • Import Database.


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

FOG Project: Cambiar la dirección IP estática del servidor FOG

Si, por alguna razón, queréis cambiar la IP de vuestro servidor FOG, tendréis que realizar el cambio en unos cuantos lugares:
  • Debéis cambiar la IP en los ficheros del sistema operativo.
  • Por otro lado, tendréis que cambiar el campo ipaddress= en el fichero /opt/fog/.fogsettings. Una vez cambiado, deberéis ejecutar el instalador de fog. Por ejemplo: 
    • /root/fogproject-1.5.4/bin/installfog.sh
  • También tendréis que entrar en el apartado Storage del interfaz web del servidor fog y cambiar la IP del nodo de almacenamiento
  • Si tenéis varios nodos de almacenamiento, deberéis cambiar la dirección IP que haga referencia al nodo de almacenamiento en el que estamos cambiando la IP.
  • También habrá que actualizar la dirección IP en el menú FOG Configuration -> Fog Settings -> Web Server del interfaz web. 
  • Y en el menú FOG Configuration -> Fog Settings -> TFTP Server del interfaz web. 

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

Error "dnsmasq: junk found in command line" al iniciar dnsmasq tras una actualización de paquetes

Después de realizar una actualización de paquetes en el servidor FOG con Debian Jessie, me he encontrado con que al tratar de arrancar el servicio dnsmasq, me daba siempre el mismo error:
# /etc/init.d/dnsmasq start
dnsmasq: junk found in command line
La solución ha sido eliminar el paquete dns-root-data:
# apt-get remove dns-root-data
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 17 de julio de 2018

FOG Project: Actualizar el servidor FOG de Debian Jessie a Debian Stretch

Mi servidor FOG principal (fogserver) se encuentra alojado en un contenedor Proxmox. Actualmente tenía instalado Debian Jessie. Así que tocaba actualizarlo a Debian Stretch.

Primero realicé una actualización de paquetes en Debian Jessie:
# apt-get update && apt-get -y upgrade
A continuación, realicé una actualización mediante dist-upgrade, que elimina paquetes si hay problemas de dependencias:
# apt-get dist-upgrade
Una vez actualizados, cambié el archivo /etc/apt/sources.list para que apuntara a los repositorios de Debian Stretch:
# sed -i 's/jessie/stretch/g' /etc/apt/sources.list
Decir que este servidor tan sólo tiene configurados los repositorios oficiales de Debian, por lo que no he tenido que realizar más modificaciones.

Una vez cambiados los repositorios, actualicé los paquetes a Debian Stretch:
# apt-get update && apt-get -y upgrade
Por último, realicé un apt-get dist-upgrade, por si quedaran aún paquetes por actualizar:
# apt-get dist-upgrade
Publicado por primera vez en http://enavas.blogspot.com.es

FOG Project: Añadir Gparted al menú de iPXE

En un post anterior, vimo cómo añadir Super Grub2 Disk al menú de arranque IPXE de FOG. En este post, vamos a ver cómo añadir Gparted, una herramienta que no nos puede faltar en el menú para gestionar particiones.

Lo primero que tenemos que hacer es conectarnos al servidor FOG, vía ssh, por ejemplo.

Una vez conectados, instalamos 7-zip, si no lo teníamos instalado en FOG:
# apt-get update && apt-get -y install p7zip-full
A continuación, creamos un directorio iso en /var/www/, donde almacenaremos nuestras isos:
# mkdir /var/www/iso
Y creamos un enlace al directorio /var/www/iso dentro de /var/www/html:
# ln -s /var/www/iso /var/www/html/iso
Dentro del directorio /var/www/iso crearemos un nuevo subdirectorio para gparted:
# mkdir /var/www/iso/gparted
Entramos dentro del directorio creado:
# cd /var/www/iso/gparted
Y descargamos la ISO desde su web (yo he descargado la última versión disponible a día de hoy para sistemas de 64 bits):
# wget https://downloads.sourceforge.net/gparted/gparted-live-0.31.0-1-amd64.iso
A continuación la descomprimimos:
# 7z x gparted-live-0.31.0-1-amd64.iso
Si queréis, una vez descomprimido, ya podéis eliminar el archivo iso:
# rm gparted-live-0.31.0-1-amd64.iso
A continuación, en el servidor FOG cambiamos el propietario y el grupo del directorio iso y todo su contenido:
# chown -R www-data:www-data /var/www/iso
Por último, accedemos al interfaz de administración de fog desde el navegador:
http://fogserver/fog/

Hacemos clic sobre  el icono del menú de configuración de FOG, y, a continuación, hacemos clic sobre la opción iPXE New Menu Entry:


Se nos mostrará un formulario en el que añadiremos las siguientes opciones:


Aparte de añadir el nombre que se mostrará en la entrada del menú y la descripción, lo más importante es rellenar la entrada "Parameters"
kernel http://${fog-ip}/iso/gparted/live/vmlinuz boot=live config components union=overlay username=user noswap noeject ip= vga=788 fetch=${fog-ip}/iso/gparted/live/filesystem.squashfs
initrd http://${fog-ip}/iso/gparted/live/initrd.img
boot
Publicado por primera vez en http://enavas.blogspot.com.es

Extraer el contenido de una iso desde el shell con 7zip

En ocasiones, necesitamos extraer el contenido de una iso desde el shell. Esta operación es muy sencilla si utilizamos 7zip.

Como nosotros trabajamos con Debian y Ubuntu, y ésta herramienta se encuentra en los repositorios, instalarla es muy sencillo:
# apt-get update && apt-get -y install p7zip-full
Una vez instalada, ya podemos extraer el contenido de nuestras isos:
# 7z x archivo.iso
Por ejemplo:
# 7z x gparted-live-0.31.0-1-amd64.iso
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs Intel(R) Xeon(R) CPU E3-1241 v3 @ 3.50GHz (306C3),ASM,AES-NI)

Scanning the drive for archives:
1 file, 333447168 bytes (318 MiB)

Extracting archive: gparted-live-0.31.0-1-amd64.iso
--
Path = gparted-live-0.31.0-1-amd64.iso
Type = Iso
Physical Size = 333447168
Created = 2018-03-20 03:26:23
Modified = 2018-03-20 03:26:23

Everything is Ok

Folders: 12
Files: 45
Size:       334519165
Compressed: 333447168
Publicado por primera vez en http://enavas.blogspot.com.es

domingo, 15 de julio de 2018

Oferta flash para comprar un Smartwatch Alfawise S2

En un post de febrero de 2018, os hablé de un smartwatch baratito con las mismas funcionalidades que la Xiaomi SmartBand. Pues bien, Gearbest ha lanzado una oferta flash con la que podéis conseguirlo por unos 19 euros.

Comprar en GearBest

Por el precio que tiene, en lugar de comprar un reloj baratito de los que venden en las tiendas de deportes, os recomiendo comprar éste.  

Me gusta mi Xiaomi Mi Band 2, pero tiene un problema muy grande: Apenas se ve en exteriores a la luz del día. Así que probablemente la cambie por un Alfawise S2. Total. No llega ni a los 20 euros...
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 14 de julio de 2018

Actualizar OpenMediaVault 3.0 a OpenMediaVault 4.0

Siguiendo con el proceso de actualización de servidores, le ha tocado el turno a OpenMediaVault, la distribución que utilizo en mi NAS.

Tenía instalada la versión 3.0 (Erasmus) basada en Debian Jessie y tocaba actualizar a la 4.0 (Arrakis), basada en Debian Stretch.

Para actualizar, lo primero que hice fue realizar una actualización de paquetes:
# apt-get update && apt-get -y upgrade
A continuación, realicé una actualización mediante dist-upgrade, que elimina paquetes si hay problemas de dependencias:
# apt-get dist-upgrade
Una vez actualizados, ejecuté omv-update para actualizar los índices de los repositorios:
omv-update
Y, a continuación, omv-release-upgrade, un script creado para actualizar OpenMediaVault a la siguiente versión:
omv-release-upgrade
Por último, realicé un apt-get dist-upgrade, por si quedaran aún paquetes por actualizar:
# apt-get dist-upgrade
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 13 de julio de 2018

Actualizar Proxmox VE no subscription 4.x a 5.x

El soporte para Proxmox VE 4.4 terminó el 30 de junio de 2018. Lo que significa que, si no habéis actualizado a versiones 5.x, deberíais hacerlo lo antes posible. 

Uno de los cambios importantes es que Proxmox 4.x está basado en Debian 8.x (Jessie) y Proxmox 5.x está basado en Debian 9.x (Stretch). Yo, hasta ahora, he preferido no realizar la actualización para evitar problemas puesto que mi servidor es cliente de un servidor puppet de Mérida y, con las nuevas versiones de paquetes, alguna tarea o paquete para jessie, podrían crearme problemas. Para próximas actualizaciones, tengo claro que virtualizaré el servidor que se nos proporcione, y mi servidor físico tan sólo tendrá Proxmox. Mientras tanto, voy a explicar cómo actualizar un Proxmox desde la versión 4.4 a la versión 5.2. Ahora bien, si instalasteis proxmox, como yo en el servidor jessie del centro, no os recomiendo actualizar porque se os romperán algunos servicios.

Lo primero que haremos será descargar la ISO de Proxmox (En estos momentos, la 5.2). Una vez descargada, la copiamos al servidor. ¿Para qué? Bueno, pues básicamente para que los paquetes de Proxmox se instalen localmente desde el propio servidor. Para ello, una vez descargada la iso, la montamos. Por ejemplo:
# mkdir /mnt/iso
# mount proxmox-ve_5.2-1.iso /mnt/iso/
Una vez montada, creamos un fichero sources.list para que nuestro servidor utilice como fuente de paquetes el directorio de paquetes de la imagen:
# echo "deb file:///mnt/iso/proxmox/packages/  ./" > /etc/apt/sources.list.d/iso.list
A continuación, editamos el fichero /etc/apt/sources.list y cambiamos todas las apariciones de jessie por stretch, de manera que nos quedará tal que así:
# Utilizamos los repositorios oficiales

deb http://ftp.es.debian.org/debian/ stretch main contrib non-free
#deb-src http://ftp.es.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main contrib non-free
#deb-src http://security.debian.org/ stretch/updates main

deb http://ftp.es.debian.org/debian/ stretch-updates main contrib non-free
#deb-src http://ftp.es.debian.org/debian/ stretch-updates main
Por último, editamos el fichero /etc/apt/sources.list.d/pve-opensource.list y cambiamos jessie por stretch para que quede de la siguiente manera:
deb http://download.proxmox.com/debian stretch pve-no-subscription
Y nos aseguramos de que el repositorio enterprise /etc/apt/sources.list.d/pve-enterprise.list se encuentra comentado:
# deb https://enterprise.proxmox.com/debian stretch pve-enterprise
Si tuviérais algún repositorio extra más, que no tenga nada que ver con los repositorios de la distribución, modificadlo para que no se utilice.

Una vez listos los repositorios, hacemos una actualización de índices:
# apt-get update
A continuación, actualizamos paquetes:
# apt-get upgrade
Al actualizar el paquete proxmox-ve, se suele producir un error por dependencias entre los paquetes proxmox-ve y pve-manager. La solución es hacer lo siguiente:
# apt-get update && touch /proxmox_install_mode && apt-get -y install proxmox-ve && rm /proxmox_install_mode
En mi caso, lo tengo convertido en un script para hacerlo de un plumazo cada vez que haya que actualizar proxmox-ve. Por último, habrá bastantes paquetes retenidos. Los instalaremos simplemente haciendo un:
# apt-get dist-upgrade
Y listo.
Para terminar, comentamos el repositorio de la ISO:
# echo "# deb file:///mnt/iso/proxmox/packages/  ./" > /etc/apt/sources.list.d/iso.list
No lo borramos. Lo dejamos ahí por si tuviéramos que volver a utilizarlo.
Desmontamos la ISO:
# umount proxmox-ve_5.2-1.iso /mnt/iso/
Y reiniciamos el servidor para comprobar que todo ha ido bien.
# reboot
Publicado por primera vez en http://enavas.blogspot.com.es

FOG Project: Añadir herramientas al menú de IPXE

Aunque en ocasiones utilizo clonezilla desde un pendrive/disco duro para clonar equipos aislados, llevo ya un tiempo usando FOG para clonar de forma remota los equipos de mi centro y cuanto más lo uso, más me gusta.

FOG proporciona a los clientes un arranque vía IPXE. Pues bien, podemos modificar el menú para añadir herramientas que habitualmente utilizamos para cargarlas a través de la red y evitar tener que cargar con pendrives, discos duros, CD's o DVD's.

En nuestros centros, hay muchos administradores que utilizan Boot Repair Disk para reparar el arranque dual, por ejemplo, cuando Windows se lo carga. En mi caso, prefiero utilizar Super Grub 2 Disk. Me parece mucho más práctico porque es más rápido y puedo arrancar directamente el sistema operativo instalado en la máquina para hacer cualquier cosa que necesite, además de reparar el arranque.

En este post, vamos a ver cómo añadir Super Grub2 Disk al menú de arranque IPXE de FOG. 

Lo primero que tenemos que hacer es descargar la ISO desde su web:

Una vez descargada, la copiamos al directorio /var/www/html/fog/service/ipxe/ de nuestro servidor FOG. Por ejemplo:
# scp /home/gestor/Descargas/super_grub2_disk_hybrid_2.02s9.iso root@fogserver:/var/www/html/fog/service/ipxe/
A continuación, en el servidor FOG cambiamos el propietario y el grupo:
# chown fog:www-data /var/www/html/fog/service/ipxe/super_grub2_disk_hybrid_2.02s9.iso
Por último, accedemos al interfaz de administración de fog desde el navegador:
http://fogserver/fog/

Hacemos clic sobre  el icono del menú de configuración de FOG, y, a continuación, hacemos clic sobre la opción iPXE New Menu Entry:


Se nos mostrará un formulario en el que añadiremos las siguientes opciones:


Aparte de añadir el nombre que se mostrará en la entrada del menú y la descripción, lo más importante es rellenar la entrada "Parameters"
initrd http://${fog-ip}/fog/service/ipxe/super_grub2_disk_hybrid_2.02s9.iso
chain memdisk iso raw

Si os dáis cuenta, en el initrd estamos indicando que se cargue la iso que hemos subido al directorio /var/www/html/fog/service/ipxe/  y que ésta debe cargarse con memdisk.

Por último, decir que he seleccionado que esta entrada se muestre a todos los clientes "All Hosts" porque es un herramienta que me interesa poder utilizar en todos ellos.

Así es como quedaría la entrada una vez creada:



Siguiendo estas pequeñas instrucciones, podéis añadir más herramientas al menú iPXE.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 12 de julio de 2018

Paquete pkgsync 1.57: Eliminada opción -r, --remove-orphan-libs

En la versión 1.57 he eliminado la -r, --remove-orphan-libs. Hoy en día ya no tenía mucha utilidad y en Bionic provocaba efectos adversos.

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


Si queréis descargar el paquete que instala esta versión, podéis hacerlo desde el siguiente link:

https://drive.google.com/open?id=1SqlIwGYSZ9hbROWfhsT_B4wc8IH60BdL
Publicado por primera vez en http://enavas.blogspot.com.es

Paquete linex-ubuntu-puppet 2.27: Quitado el permiso de ejecución en el servicio sincpuppet.service

Tan sólo he realizado una pequeña modificación en el paquete linex-ubuntu-puppet, para quitar el permiso de ejecución al servicio sincpuppet.service
linex-ubuntu-puppet_2.27

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

Actualizar FOG Server desde la versión 1.5.0 a la versión 1.5.4

Hasta ahora tenía instalado FOG Server 1.5.0 que está basado en Debian Jessie. Como estamos en época de migración de clientes, creo que es más que conveniente migrar también los servidores.

Para empezar, le ha tocado el turno a mi servidor de clonación: fogserver.

La actualización del servidor consiste en bajar la última versión (en estos momentos, la 1.5.4):
# wget https://github.com/FOGProject/fogproject/archive/1.5.4.tar.gz
Descomprimirla:
# tar xfvz 1.5.4.tar.gz
Entrar dentro del directorio donde se encuentra el instalador:
# cd fogproject-1.5.4/bin
E iniciarlo:

Como podéis comprobar en la siguiente imagen, el mismo instalador nos informa de que es a la vez instalador y actualizador:


Como lo tenía instalado ya, detecta que existe una instalación previa, basándose en el archivo de configuración /opt/fog/.fogsettings:


Es importante destacar que, en mi instalación, no uso el servidor DHCP de FOG. En lugar de ello, tengo instalado dnsmasq para que actúe como proxyDHCP y sea el servidor del centro quien atienda las peticiones de DHCP de los clientes a clonar. De este modo, tengo perfectamente integrado el servidor de clonación en la red del centro. 

Como también podéis observar en la imagen anterior, además de los ajustes de configuración, me muestra un mensaje informativo donde me dice los cambios que debemos realizar en nuestro servidor DHCP para utilizar el servicio PXE de FOG. En nuestro caso, que tenemos servidores linux, habrá que añadir dos ajustes a DHCP:
  • nextserver
  • filename
Nos pregunta si estamos seguros de querer continuar el proceso. Le decimos que sí y realizará la instalación, configuración y puesta en marcha de servicios.

Cuando termine, veremos una pantalla como la siguiente donde los indica cómo podemos acceder al portal de gestión del servidor FOG:

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

miércoles, 11 de julio de 2018

Testear un servicio de systemd

Podemos testear un servicio de systemd simplemente haciendo uso de systemd-analyze:
# systemd-analyze verify conectarwifi.service
Publicado por primera vez en http://enavas.blogspot.com.es

Distribuir los ficheros de pkgsync mediante un módulo puppet

Para distribuir los ficheros de pkgsync a clientes, utilizo un pequeño módulo al que llamé pkgsync. Es muy sencillo y, entre otras cosas, distribuye al cliente:
  • El fichero /etc/default/pkgsync
  • El directorio /etc/pkgsync con todos los ficheros de configuración en función del tipo de cliente (workstation, infolab, siatic, notebook, notebookHP) y la arquitectura:
file { "/etc/default/pkgsync":
          source=>"puppet:///modules/pkgsync/$tipo/pkgsync.default",
          owner => root, group => root, mode => 644,
}

file { "/etc/pkgsync":
          source=>"puppet:///modules/pkgsync/$tipo/pkgsync_$architecture",
          recurse => remote,
          owner => root, group => root, mode => 755,
}
Publicado por primera vez en http://enavas.blogspot.com.es

Script remove-cached-credentials: Invalidar credenciales de usuario cacheadas en SSSD

En un post anterior, vimos cómo cachear credenciales con sss_seed e invalidarlas con sss_cache. Para facilitar la tarea de invalidar credenciales de usuarios y grupos, lo más práctico es hacerlo mediante un script que distribuyamos a todas nuestras máquinas mediante puppet:
#!/bin/bash
#
# remove-cached-credentials: Invalidar credenciales de usuario cacheadas en SSSD
# Esteban M. Navas Martin
# algodelinux@gmail.com
# Fecha creacion: 10/11/2016
# Última modificación: 10/07/2018

# Borramos las credenciales de usuario cacheadas
[ -x /usr/sbin/sss_cache ] && /usr/sbin/sss_cache -U -G
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 10 de julio de 2018

grep: Comprobar si existen dos palabras en una línea

Para comprobar si existen dos palabras en una misma línea, podemos utilizar expresiones regulares con grep.

Por ejemplo, supongamos que estamos usando nmcli para comprobar si un equipo se encuentra conectado vía wifi.

Para obtener la lista de conexiones de los diferentes dispositivos no tenemos más que ejecutar el siguiente comando:
# LC_ALL=C nmcli dev
DEVICE  TYPE      STATE      CONNECTION                          
enp2s0  ethernet  connected  Conexi?n cableada 1                 
wlp3s0  wifi      connected  netplan-wlp3s0-IESVALLEDELJERTE3_00 
lo      loopback  unmanaged  --  
Si ahora queremos quedarnos tan sólo con las conexiones wifi conectadas, podemos aplicar un grep de la siguiente manera:
root@modelo:~# LC_ALL=C nmcli dev | grep -E 'wifi.*connected'
wlp3s0  wifi      connected  netplan-wlp3s0-IESVALLEDELJERTE3_00 
El usar LC_ALL=C antes del comando me permite obtener la salida en inglés, con el fin de que la combinación de comandos funcione con cualquier idioma.
Publicado por primera vez en http://enavas.blogspot.com.es

sssd-tools: "Jugando" a cachear credenciales en un sistema con SSSD

Las credenciales de un usuario son su nombre de usuario (username) y su contraseña (password).

El cacheo de credenciales es muy útil, sobre todo, para ordenadores portátiles en los que se realiza la autenticación de usuarios mediante un servidor LDAP. Si cacheamos las credenciales de un usuario, éste podrá acceder al portátil  cuando el servicio de ldap no se encuentre disponible, por ejemplo, cuando el portátil no se encuentre conectado a la red.

Antiguamente, utilizábamos libpam-ccreds para cachear credenciales de usuario en Debian. Ahora, con el cambio a Ubuntu Bionic Beaver, hemos pasado a usar SSSD (System Security Services Daemon) como sistema de autenticación, principalmente porque nos proporciona acceso a diferentes proveedores de identificación y autenticación. De este modo, podemos cambiar de proveedor de autenticación cuando nos interese.

Para cachear credenciales SSSD, lo primero que tenemos que hacer es instalar el paquete sssd-tools, que nos proporciona un amplio conjunto de herramientas, entre las que encontraremos sss_seed y sss_cache:
# apt-get update && apt-get -y install sssd-tools
sss_seed nos servirá para cachear credenciales de usuario.

Por ejemplo, si ejecutamos el siguiente comando:
# sss_seed  -n enavas -D LDAP -p /root/sss_passwd
Estaríamos cacheando las credenciales del usuario enavas, cuya password se encuentra almacenada en el archivo /root/sss_passwd en el dominio con nombre LDAP.

Para más información, ver el man:
# man sss_seed
Bien, pues ahora que ya sabemos cachear credenciales de usuario, vamos a ver cómo invalidarlas. Para ello, haremos uso del comando sss_cache.

El comando sss_cache invalida registros en la caché SSSD. Los registros invalidados son forzados a ser recargados desde el servidor tan pronto como el backend SSSD utilizado se encuentre disponible. Existen una opción para invalidar directamente toda la caché (-E,--everything):
# sss_cache -E
Y, además, existen opciones para invalidar objetos concretos: usuarios, grupos, netgroups, servicios, etc...

Por ejemplo, Supongamos que queremos invalidar el usuario cacheado enavas:
# sss_cache -u enavas
Ahora bien, supongamos que queremos invalidar todos los usuarios cacheados. Haríamos lo siguiente:
# sss_cache -U
De igual modo, podríamos invalidar grupos individuales (-g login) o todos los grupos (-G).

Combinando ambas opciones, es muy fácil invalidar usuarios y grupos cacheados localmente:
# sss_cache -U -G
Para más información, ver el man:
# man sss_cache
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 9 de julio de 2018

Error al iniciarse autofs antes de estar listos los listeners de sssd

Parece que en Ubuntu Bionic sigue habiendo un bug porque el servicio autofs se inicia antes de estar listos los listeners de sssd. Podéis comprobarlo fácilmente si hacéis un systemctl status autofs.service -l y véis el siguiente error:
 setautomntent: lookup(sss): setautomntent: Connection refused
# systemctl status autofs.service -l
● autofs.service - Automounts filesystems on demand
   Loaded: loaded (/lib/systemd/system/autofs.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-07-09 12:07:17 CEST; 1h 59min left
  Process: 1086 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /var/run/autofs.pid (code=exited, status=0/SUCCESS)
 Main PID: 1087 (automount)
    Tasks: 3 (limit: 4915)
   CGroup: /system.slice/autofs.service
           └─1087 /usr/sbin/automount --pid-file /var/run/autofs.pid

jul 09 12:07:17 a19-pro systemd[1]: Starting Automounts filesystems on demand...
jul 09 12:07:17 a19-pro automount[1087]: setautomntent: lookup(sss): setautomntent: Connection refused
jul 09 12:07:17 a19-pro systemd[1]: Started Automounts filesystems on demand.
Por lo que he podido observar, al menos en la imagen de equipos SIATIC, quien la haya preparado, ha tratado de solventar el problema haciendo que se ejecute un script (/usr/share/linex-config-ldapclient/autofs-restart) que reinicia autofs al levantar la red. No es lo más correcto, y, por lo que he visto, esta solución, al menos en mis máquinas, no funcionaba.

Si os sucede ésto, podéis resolver el problema de una forma más adecuada:
Primero cread un directorio autofs.service.d en /etc/systemd/system:
# mkdir /etc/systemd/system/autofs.service.d
A continuación, cread un fichero override.conf en el directorio /etc/systemd/system/autofs.service.d/:
/etc/systemd/system/autofs.service.d/override.conf
Y añadidle el siguiente contenido:
[Unit]
Wants=network-online.target
Requires=network.target rpc-statd.service rpcbind.service
After=network.target sssd.service network-online.target remote-fs.target
No voy a entrar en detalles, pero con ésto, estamos haciendo que el servicio autofs se inicie en el momento adecuado.

El fichero override.conf es un snippet que aplicará cambios en la definición de la unit file original (autofs.service), de manera que las modificaciones del snippet tendrán preferencia.

Una vez creado, tan sólo tendremos que reiniciar el servicio:
# systemctl restart autofs
Y comprobaremos que el problema está resuelto:
# systemctl status autofs.service -l
● autofs.service - Automounts filesystems on demand
   Loaded: loaded (/lib/systemd/system/autofs.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/autofs.service.d
           └─override.conf
   Active: active (running) since Mon 2018-07-09 10:09:22 CEST; 7min ago
 Main PID: 8164 (automount)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/autofs.service
           └─8164 /usr/sbin/automount --pid-file /var/run/autofs.pid

jul 09 10:09:21 a19-pro systemd[1]: Starting Automounts filesystems on demand...
jul 09 10:09:22 a19-pro systemd[1]: Started Automounts filesystems on demand.
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 6 de julio de 2018

cnvt-ocs-dev: Cambiar identificador de disco duro en imagen de Clonezilla

cnvt-ocs-dev es un script que clonezilla usa para cambiar los identificadores de disco duro (sda, sdb, etc...). 

Este script puede resultarnos útil en muchas ocasiones, pero sobre todo cuando tratamos de restaurar una imagen de múltiples discos y alguno de los equipos tiene cambiados dichos identificadores. Por ejemplo, me he encontrado algunos equipos de Infolab en los que los discos duros se encontraban identificados como sda sdc, cuando en la mayoría la identificación era sda y sdb. Pues bien, este problema es fácil de resolver mediante cnvt-ocs-dev.

Veamos cómo utilizarlo con un ejemplo:
# cnvt-ocs-dev -d /home/partimag infolab-dual-amd64 sdc sdb
En el ejemplo anterior, lo que haríamos sería cambiar en la imagen la identificación del disco sdc por sdb.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 5 de julio de 2018

Crear un pendrive de instalación de Ubuntu Bionic Beaver usando ddrescue

Hay una forma muy sencilla de crear un pendrive de instalación de Ubuntu Bionic Beaver y es utilizando ddrescue.

Para instalar ddrescue en Ubuntu o en Debian, lo haremos desde los repositorios de la distribución:
# apt-get update && apt-get install gddrescue
Una vez instalado, no tenemos más que introducir el pendrive e identificar el nombre del dispositivo (sda, sdb, sdc, ...).
Cuando hayamos identificado el dispositivo, ejecutamos ddrescue de la siguiente manera (sustituyendo sdX por el identificador de nuestro dispositivo):
# ddrescue bionic-desktop-amd64.iso /dev/sdX --force -D
root@equipo:/home/enam0000# ddrescue /media/enam0000/TOOLS/isos/ubuntu-18.04-desktop-amd64.iso  /dev/sdc --force -D
GNU ddrescue 1.22
     ipos:    1921 MB, non-trimmed:        0 B,  current rate:    393 kB/s
     opos:    1921 MB, non-scraped:        0 B,  average rate:   9284 kB/s
non-tried:        0 B,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    1921 MB,   bad areas:        0,        run time:      3m 26s
pct rescued:  100.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Finished     
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 4 de julio de 2018

Acceder al menú de configuración de Plank

El menú de configuración de plank se encuentra oculto.


Podemos acceder a él de dos formas:
  • Pulsamos la tecla Ctrl en el teclado, y, sin soltarla, hacemos clic con el botón derecho del ratón sobre el dock.
  • Abrimos un terminal, y ejecutamos el siguiente comando:
# plank --preferences

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

Agregar un equipo a un dominio desde PowerShell

Agregar un equipo a un dominio mediante PowerShell, es tan sencillo como ejecutar el comando AddComputer, pasándole como parámetros el nombre del dominio al que queremos añadir el equipo y el nombre de un usuario del dominio con permisos para gestionar el dominio. Por ejemplo:
Add-Computer -DomainName instituto.extremadura.es -Credential instituto\gestor
Nos solicitará que intoduzcamos la contraseña del usuario. La introducimos y el equipo será agregado al dominio:


Como los cambios no se harán efectivos hasta reiniciar el equipo, lo reiniciamos:
Restart-Computer
Publicado por primera vez en http://enavas.blogspot.com.es

Obtener la Windows OEM Key

Desde hace ya algún tiempo, los equipos OEM (Original Equipment Manufacturer) almacenan la clave de Windows en BIOS/UEFI.
Para obtener la clave de Windows en uno de estos equipos,  tan sólo tenemos que abrir un cmd o un powershell y ejecutar el siguiente comando:
wmic path softwarelicensingservice get OA3xOriginalProductKey
Publicado por primera vez en http://enavas.blogspot.com.es

sábado, 30 de junio de 2018

Netplan: Interfaces de red opcionales

Cuando una máquina tiene instaladas diferentes interfaces de red y no necesitamos utilizarlas todas,  podemos optar por dos soluciones:
  • Configurar en netplan tan sólo las interfaces de red que vamos a usar.
  • Configurar todas las interfaces de red y definir como opcionales aquellas que no son necesarias para el arranque.
Ésto es muy importante porque networkd esperará un tiempo a que los dispositivos sean configurados antes de continuar con el arranque. 

Si optamos por configurar todas las interfaces de red en un fichero de configuración de netplan, podemos marcar como opcionales aquellas interfaces de red que no sean necesarias para el arranque, haciendo uso del valor optional

Por ejemplo:
# cat /etc/netplan/01-network-manager-all.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: yes
    enp2s0:
      dhcp4: no
      optional: true
    enp3s0:
      dhcp4: no
      optional: true
    enp4s0:
      dhcp4: no
      optional: true

Es importante destacar que este parámetro sólo está soportado por networkd. y su valor por defecto es no.
Publicado por primera vez en http://enavas.blogspot.com.es

Netplan: Configurar una IP estática utilizando networkd

En un post anterior,  hemos visto cómo configurar la red en un cliente mediante netplan, obteniendo una dirección IP vía DHCP.  En este post, vamos a ver cómo configurar una dirección IP estática en un cliente.

Como ya hemos comentado en otros posts, netplan utiliza archivos de configuración en formato yaml almacenados en el directorio /etc/netplan. Y si no hay ningún archivo de configuración en /etc/netplan, podemos generarlo automáticamente con tan sólo ejecutar: 
# netplan generate
Una vez generado, podemos editarlo para ajustar la configuración.

En máquinas conectadas vía ethernet, en las que no necesitamos que el usuario pueda gestionar la configuración de red, podemos usar el renderer networkd en lugar de NetworkManager.

Para entender mejor cómo configurar una IP estática,  vamos a ver un ejemplo:
# cat /etc/netplan/01-network-manager-all.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: no
      dhcp6: no
      adresses: [172.19.144.16/23]
      gateway4: 172.19.144.1
      nameservers:
         addresses: [172.19.144.2,172.19.144.3,208.67.222.222] 
Como podéis observar, en este ejemplo, estamos configurando:
  • Una tarjeta de red cuyo nombre es enp0s1 y estamos especificando que no debe obtener una dirección IP mediante dhcp (dhcp4: no, dhcp6:no).
  • Una dirección ip estática junto con la máscara de red (172.19.144.16/23).
  • Un gateway para IPv4 (172.19.144.1)
  • Diferentes servidores DNS (addresses: [172.19.144.2,172.19.144.3,208.67.222.222])
No olvidéis que es necesario respetar los sangrados en el fichero de configuración .yaml.

Una vez realizados los cambios en el fichero de configuración, comprobamos que no hay errores en la configuración:
# netplan try
Y si no hay errrores, aplicamos la configuración:
# netplan apply
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 29 de junio de 2018

Paquete linex-ubuntu-puppet 2.26: Modificación para iniciar sinc-puppet mediante systemd en sistemas basados en systemd

He modificado creado una nueva versión del paquete linex-ubuntu-puppet, concretamente la 2.26 para  iniciar sinc-puppet mediante systemd en sistemas basados en systemd, en lugar de iniciarlo al levantar las interfaces de red.
linex-ubuntu-puppet_2.26

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

Error al iniciarse el backend de sssd antes de estar levantada la red

Cuando he clonado los equipos SIATIC, no me funcionaba la autenticación. Revisando los logs, he comprobado que el servicio sssd se iniciaba antes de estar levantada la red:
# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: ena
   Active: active (running) since Fri 2018-06-29 08:15:30 CEST; 40min ago
 Main PID: 837 (sssd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/sssd.service
           ├─837 /usr/sbin/sssd -i --logger=files
           ├─933 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain LDAP --uid 0 --
           ├─945 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logge
           ├─946 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logge
           └─947 /usr/lib/x86_64-linux-gnu/sssd/sssd_autofs --uid 0 --gid 0 --lo

jun 29 08:15:30 a17-pro systemd[1]: Starting System Security Services Daemon...
jun 29 08:15:30 a17-pro sssd[837]: Starting up
jun 29 08:15:30 a17-pro sssd[be[933]: Starting up
jun 29 08:15:30 a17-pro sssd[945]: Starting up
jun 29 08:15:30 a17-pro sssd[946]: Starting up
jun 29 08:15:30 a17-pro sssd[947]: Starting up
jun 29 08:15:30 a17-pro systemd[1]: Started System Security Services Daemon.
jun 29 08:15:30 a17-pro sssd[be[933]: Backend is offline
Si os sucede ésto, podéis resolver el problema de la siguiente manera:
Primero cread un directorio sssd.service.d en /etc/systemd/system:
# mkdir /etc/systemd/system/sssd.service.d
A continuación, cread un fichero override.conf en el directorio /etc/systemd/system/sssd.service.d/:
/etc/systemd/system/sssd.service.d/override.conf
Y añadidle el siguiente contenido:
[Unit]
Requires=network-online.target
After=network-online.target
Con ésto, le estamos diciendo a systemd que el servicio sssd requiere que la red esté online antes de iniciarse.

El fichero override.conf es un snippet que aplicará cambios en la definición de la unit file original (sssd.service), de manera que las modificaciones del snippet tendrán preferencia.

Una vez creado, tan sólo tendremos que reiniciar el servicio:
# systemctl restart sssd
Y comprobaremos que el problema está resuelto:
# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: ena
  Drop-In: /etc/systemd/system/sssd.service.d
           └─override.conf
   Active: active (running) since Fri 2018-06-29 09:24:18 CEST; 28s ago
 Main PID: 2999 (sssd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/sssd.service
           ├─2999 /usr/sbin/sssd -i --logger=files
           ├─3000 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain LDAP --uid 0 -
           ├─3001 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logg
           ├─3002 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logg
           └─3003 /usr/lib/x86_64-linux-gnu/sssd/sssd_autofs --uid 0 --gid 0 --l

jun 29 09:24:18 a20-pro systemd[1]: Starting System Security Services Daemon...
jun 29 09:24:18 a20-pro sssd[2999]: Starting up
jun 29 09:24:18 a20-pro sssd[be[3000]: Starting up
jun 29 09:24:18 a20-pro sssd[3001]: Starting up
jun 29 09:24:18 a20-pro sssd[3003]: Starting up
jun 29 09:24:18 a20-pro sssd[3002]: Starting up
jun 29 09:24:18 a20-pro systemd[1]: Started System Security Services Daemon.
Publicado por primera vez en http://enavas.blogspot.com.es

jueves, 28 de junio de 2018

Netplan: Configurar interfaz de red utilizando networkd

Como ya hemos comentado en otro post, la configuración de red en Ubuntu 18.04 ha cambiado y ya no se utiliza /etc/network/interfaces para configurar las interfaces de red. En lugar de ésto, se usa Netplan.

Netplan utiliza archivos de configuración en formato yaml almacenados en el directorio /etc/netplan.

Si no hay ningún archivo de configuración en /etc/netplan, podemos generarlo automáticamente con tan sólo ejecutar: 
# netplan generate
Una vez generado, podemos editarlo para ajustar la configuración.

En máquinas conectadas vía ethernet, en las que no necesitamos que el usuario pueda gestionar la configuración de red, podemos usar el renderer networkd en lugar de NetworkManager.
# cat /etc/netplan/01-network-manager-all.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: yes
      dhcp6: no
Como podéis deducir, en este ejemplo, estamos configurando una tarjeta de red cuyo nombre es eno1 para que obtenga una dirección IP mediante dhcp versión 4.

No olvidéis que es necesario respetar los sangrados en el fichero de configuración .yaml.

Una vez realizados los cambios en el fichero de configuración, nos aseguramos de que no haya errores de sintaxis:
# netplan try
Si no hay errores, generamos la configuración para el backend systemd-networkd:
# netplan generate
Y aplicaremos la configuración mediante el siguiente comando:
# netplan apply
Y, por último, comprobamos que los cambios se han aplicado correctamente:
# netplan ip leases eno1
# This is private data. Do not parse.
ADDRESS=172.19.144.49
NETMASK=255.255.254.0
ROUTER=172.19.144.2
SERVER_ADDRESS=172.19.144.3
NEXT_SERVER=172.19.144.68
T1=10800
T2=18900
LIFETIME=21600
DNS=172.19.144.2 172.19.144.3
NTP=172.19.144.2
DOMAINNAME=valledeljerte3
CLIENTID=ffb6220feb00020000ab11122baf93b503a8de
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 27 de junio de 2018

Netplan: Gestionar configuración de red mediante Network Manager

Como ya habréis podido observar, la configuración de red en Ubuntu 18.04 ha cambiado y ya no se utiliza /etc/network/interfaces para configurar las interfaces de red. En lugar de ésto, se usa Netplan.

Netplan utiliza archivos de configuración en formato yaml almacenados en el directorio /etc/netplan.

Si no hay ningún archivo de configuración en /etc/netplan, podemos generarlo automáticamente con tan sólo ejecutar: 
# netplan generate
Una vez generado, podemos editarlo para ajustar la configuración.

En máquinas como los portátiles, lo más probable es que nos interese que el usuario pueda gestionar la configuración mediante Network Manager. En ese caso, modificaremos el archivo de configuración para indicar a netplan que el renderer NetworkManager:
# cat /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
Es importante destacar que es necesario respetar los sangrados en el fichero de configuración .yaml.

Una vez realizados los cambios en el fichero de configuración, los aplicaremos mediante el siguiente comando:
# netplan apply
Publicado por primera vez en http://enavas.blogspot.com.es

Nueva forma de nombrar las interfaces de red en systemd

Con la llegada de systemd v197 se empezó a utilizar una nueva forma de nombrar las interfaces de red. Esta nueva forma permite asignar nombres de interfaces de red previsibles y persistentes para evitar los problemas de detección y configuración que muchas veces hemos sufrido (Todos los que habéis administrado el sistema de un IES, recordaréis los problemas al nombrarse las interfaces de red tras una clonación).

A partir de systemd v197:
  1. Si los nombres que incorporan el Firmware/BIOS proporcionan los números de índices para los dispositivos conectados, se aplica esta política. Por ejemplo: eno1
  2. Si los nombres que incorporan el Firmware/BIOS proporcionan los números de las ranuras PCI Express, se aplica esta directiva.  Por ejemplo: ens1
  3. Si el hardware incorpora información de ubicación física del conector, se aplica esta directiva.  Por ejemplo: enp5s2
  4. También es posible utilizar nombres que incorporan la dirección MAC de las interfaces. Por ejemplo: enx66e7d1ec46da.
  5. Por último, si no se puede aplicar ninguna de las políticas anteriores, se utiliza la nomenclatura tradicional del kernel (ejemplo, eth0, eth1, etc).
Si abrís un terminal, podréis comprobar qué interfaces de red tiene vuestra máquina y cómo se encuentran nombradas:
root@a20-pro:~# ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 50:65:f3:28:e2:41 brd ff:ff:ff:ff:ff:ff
    inet 172.19.144.49/23 brd 172.19.145.255 scope global dynamic eno1
       valid_lft 21335sec preferred_lft 21335sec
    inet6 fe80::5265:f3ff:fe28:e241/64 scope link 
       valid_lft forever preferred_lft forever
3: enp3s0:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a0:36:9f:5a:39:a1 brd ff:ff:ff:ff:ff:ff
En este caso (un SIATIC), observamos que hay tres interfaces de red:
  • La interfaz localhost: lo.
  • Una interfaz ethernet: eno1.
  • Una segunda interfaz ethernet: enp3s0.
Hoy he clonado un siatic y he visto que la imagen de clonación, por alguna razón, al contrario que la imagen de portátiles y workstation, traía la configuración tradicional. Así que he decidido cambiarlo. Si este nuevo sistema de nombrado hace que los nombres de las interfaces de red sean previsibles y persistentes, lo más conveniente es utilizarlo, aunque al principio cueste acostumbrarse.
Publicado por primera vez en http://enavas.blogspot.com.es

Utilizar nombres tradicionales en las tarjetas de red

Ubuntu Bionic usa netplan para gestionar la configuración de red. Ésto implica que se utilice una nomenclatura diferente para nombrar las tarjetas de red. 

Para que se asignen a las tarjetas de red los nombres tradicionales (eth0,…,wlan0), podemos editar el fichero /etc/default/grub y cambiar:

GRUB_CMDLINE_LINUX=""

por:

GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

Una vez hecho ésto, ejecutamos el comando update-grub2 para aplicar la configuración y listo.
Publicado por primera vez en http://enavas.blogspot.com.es

launchpad-getkeys: Obtener automáticamente claves públicas de repositorios utilizando un proxy

Como ya sabéis, pkgsync, lleva incorporada la herramienta launchpad-getkeys que nos permite obtener automáticamente claves públicas de repositorios. 

Si por alguna razón (de filtros, por ejemplo), no pudiérais descargar dichas claves, launchpad-getkeys tiene un parámetro -p que nos permite indicar un proxy y puerto. Por ejemplo: Si hacéis ésto en el centro, se estará utilizando el proxy de squid para realizar la descarga:
# launchpad-getkeys -p http://servidor:3128
Publicado por primera vez en http://enavas.blogspot.com.es

martes, 26 de junio de 2018

Ejecutar un script de inicio en sytemd desde /etc/rc.local

Systemd tiene un servicio rc-local.service para mantener compatibilidad con /etc/rc.local. De manera que podemos seguir añadiendo comandos al fichero /etc/rc.local que se ejecuten al final del proceso de inicio del sistema.
$ cat /lib/systemd/system/rc-local.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
Documentation=man:systemd-rc-local-generator(8)
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

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

Paquetes para la reproducción de contenidos multimedia y DVDs

Una vez instalado nuestro Xubuntu 18.04, hay un conjunto de paquetes que deberemos instalar:
# apt install libdvdnav4 libdvdread4 gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly libdvd-pkg
# apt install ubuntu-restricted-extras
Con ésto conseguiremos:
  • Reproducir DVD's y vídeos con control de copyright.
  • Códecs de audio para reproducir mp3 y otros formatos.
  • Software para instalar Microsoft Web fonts.
  • Plugin de Adobe Flash.
  • El software lame, para crear archivos de audio comprimidos.

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

lunes, 25 de junio de 2018

Instalar Scratch 2.0 Offline Editor en Ubuntu Bionic Beaver

Mientras esperamos la llegada de Scratch 3.0, vamos a instalar Scratch 2.0 en un cliente antes de clonar para disponer del editor offline.

Una vez instalado Adobe Air en Ubuntu Bionic Beaver, podemos proceder a instalar Scratch 2.0. Para ello, abrimos un terminal y ejecutamos:
# /opt/Adobe\ AIR/Versions/1.0/Adobe\ AIR\ Application\ Installer Scratch-461.air 
Se nos abrirá un asistente con el que podremos realizar fácilmente la instalación.
Publicado por primera vez en http://enavas.blogspot.com.es

Instalar Adobe Air en Ubuntu Bionic Beaver

Es sencillo instalar Adobe Air desde drive.noobslab.com.

Para empezar, descargamos el paquete (en nuestro caso de 64 bits porque nuestras máquinas son todas de 64 bits):
# wget -O adobe-air_amd64.deb http://drive.noobslab.com/data/apps/AdobeAir/adobeair_2.6.0.2_amd64.deb
Una vez descargado, lo más sencillo es subirlo a nuestro repositorio local e instalarlo desde allí porque se resolverán las dependencias. Pero, si no tenéis un repositorio local, siempre podéis instalarlo mediante un pequeño módulo puppet o, simplemente, de forma local con dpkg:
# dpkg -i adobe-air_amd64.deb
Si lo instaláis mediante dpkg, tendréis que hacer un:
# apt-get -f install
Para que se instalen las dependencias. Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 22 de junio de 2018

Paquete pkgsync 1.54: Modificado pkgsync para mostrar información acerca del fichero y paquete cuando se usa la opción -t, --test-files

He modificado el paquete pkgsync (versión 1.54) para que muestre más información al utilizar la opción -t, --test-files.

Ahora, mostrará el nombre del paquete que se está chequeando y en qué fichero se encuentra dicho nombre.

Recordad que esta opción permite chequear qué paquetes incluidos en los ficheros con listas de paquetes alojados en /etc/pkgsync no se encuentran en los repositorios y que, además, existe un argumento (r) para eliminarlos.

Si queremos testear los ficheros tan sólo tenemos que hacer un:
# pkgsync -t

Y si, además de testearlos, queremos eliminar los nombres de aquellos paquetes que nno se encuentran en los repositorios, haremos un:
# pkgsync -tr


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


Si queréis descargar el paquete que instala esta versión, podéis hacerlo desde el siguiente link:
https://drive.google.com/file/d/1bqK-lK9aVCmHLSAhmrMt4TDADaWy77sE/view?usp=sharing
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 20 de junio de 2018

Crear un usuario de sistema sin directorio HOME

Crear un usuario de sistema sin directorio HOME es tan sencillo como ejecutar el siguiente comando:
# adduser --system --no-create-home USERNAME
Publicado por primera vez en http://enavas.blogspot.com.es

Error en apt-mirror (0.5.1-1): No mirroriza bionic/main DEP-11 64x64@2 iconos ni bionic-updates/main DEP-11 64x64@2 iconos

Esta versión de apt-mirror (0.5.1-1) no mirroriza bionic/main DEP-11 64x64@2 ni bionic-updates/main DEP-11 64x64@2

Parece ser que tal y como está escrito el código, se está ignorando el símbolo arroba.

Para evitar el problema, matando dos pájaros de un tiro, he aprovechado para actualizar la máquina virtual que implementa el mirror de Debian Jessie a Debian Stretch, ya que tiene una versión más reciente  del paquete apt-mirror sin ese problema.

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

martes, 19 de junio de 2018

cambiamarca: Script para cambiar la marca de un equipo en el fichero /etc/escuela2.0

Reutilizando el código del script cambiahostname, he escrito otro script cambiamarca que permite cambiar la marca del equipo en el fichero /etc/escuela2.0:
#!/bin/bash
#
# Esteban M. Navas 
# Fecha creación:      19/07/2018
# Última modificación: 19/07/2018

# Si no hay parámetros, el script se está usando de forma interactiva
if [ -z "$1" ]; then

   DIALOG="dialog"
   tempfile=`tempfile 2>/dev/null` || tempfile=/tmp/test$$
   trap "rm -f $tempfile" 0 1 2 5 15

   $DIALOG --title "Marca del equipo" --clear \
           --inputbox "Introduzca la marca que quiere asignar a este equipo [ ACER, APD, HP, Xtrem, ... ]:" 15 51 2> $tempfile

   retval=$?

   case $retval in
     0)
       MARCA=`cat $tempfile`
     ;;
     1) ;;
   esac
else
   MARCA=$1
fi


if [ "$MARCA" ] ; then

   grep -q '^marca=' /etc/escuela2.0 && sed -i "s/^marca=.*/marca=$MARCA/" /etc/escuela2.0 || echo "marca=$MARCA" >> /etc/escuela2.0

   /usr/sbin/sinc_puppet -f now
#  /usr/local/sbin/pkgsync -pcr

fi
En este caso:
  • Si existe, reemplazamos la definición del tipo de host en el fichero /etc/excuela2.0.
  • Si no existe, simplemente la insertamos.
Al igual que en el script cambiahostname, se puede indicar el nombre del host como parámetro del script. Y, si no se especifica, mostrará un cuadro de diálogo para que lo escribamos.

Tras cambiar el host, se ejecutará sinc_puppet (He dejado la línea que ejecutaría pkgsync comentada).

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

lunes, 18 de junio de 2018

Modificado el script musthave-build para Ubuntu Bionic Beaver

He modificado el script musthave-build para generar la lista de paquetes instalados en el sistema en Ubuntu Bionc Beaver. 

Aquí podéis ver el código:
Publicado por primera vez en http://enavas.blogspot.com.es

miércoles, 13 de junio de 2018

Script auto-config-network: Configurar automáticamente las interfaces de red del equipo

El script auto-config-network es un script ideal para ejecutar en una máquina que acabamos de clonar. Su función es configurar automáticamente las interfaces de red de la máquina donde lo ejecute.

Lo primero que hace es eliminar el fichero /etc/udev/rules.d/70-persistent-rules para que no tenga datos de la máquina modelo en caso de que se hubiera clonado el equipo. Una vez eliminado, lo vuelve a regenerar detectando las interfaces de red de la máquina.


Por otro lado, hace una copia el fichero /etc/network/interfaces en /etc/network/interfaces.old y lo regenera automáticamente, haciendo lo siguiente:
  • Configura la interfaz localhost.
  • Configura con una IP estática (192.168.0.254), las interfaces configuradas para servir DHCP en el fichero /etc/default/isc-dhcp-server que tienen link.
  • Configura con una IP dinámica las interfaces que tienen link pero no se encuentran configuradas para servir DHCP.
Éste es el script que utilizaré para configurar las interfaces de red de una máquina una vez clonada.

Instalarlo es muy sencillo:
# wget --no-check-certificate -O /usr/local/sbin/auto-config-network https://raw.githubusercontent.com/algodelinux/auto-config-network/master/auto-config-network
# chmod 755 /usr/local/sbin/auto-config-network
Aquí podéis ver el código completo de auto-config-network:

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

Script cambiahostname: Cambiar el nombre de una máquina y realizar un pkgsync

Escribí el script cambiahostname tan sólo para facilitar la tarea de establecer el nombre del equipo en un curso de puppet. Pero, más adelante, me di cuenta que podía resultarme muy útil en el centro si lo modificaba para que ejecutara pkgsync tras cambiar el nombre. Estos últimos días, he vuelto a modificarlo de manera que:

  • Permite introducir el nombre de la máquina como parámetro.
  • Si no se introduce el nombre como parámetro, tratará de obtenerlo consultando al DNS definido en DNSSERVER.
  • Si no se puede obtener el nombre consultando al servidor DNS, se solicita su introdución mediante teclado. 

Éste es el script que utilizo para configurar una máquina una vez clonada.

Instalarlo es muy sencillo:
# wget --no-check-certificate -O /usr/local/sbin/cambiahostname https://raw.githubusercontent.com/algodelinux/cambiahostname/master/cambiahostname
# chmod 755 /usr/local/sbin/cambiahostname
Aquí podéis ver el código completo de cambiahostname:

Por último, tan sólo comentar que el script hace uso del comando nslookup que pertenece al paquete dnsutils. Por tanto, para que el script funcione, deberéis tener instalado dicho paquete. Como se encuentra en los repositorios, resulta fácil de instalar:
# apt-get install dnsutils
Publicado por primera vez en http://enavas.blogspot.com.es

Script get-my-hostname: Obtener el nombre del equipo consultando al servidor DNS definido en DNSSERVER

El script get-my-hostname permite obtener el nombre del equipo en que se ejecuta. Para ello, realiza una consulta al servidor DNS definido en una variable llamada DSNSERVER.

Este script puede sernos muy útil cuando vamos a configurar un equipo registrado en el servidor DNS, tras una clonación, por ejemplo.

Instalarlo es muy sencillo:
# wget --no-check-certificate -O /usr/local/sbin/get-my-hostname https://raw.githubusercontent.com/algodelinux/get-my-hostname/master/get-my-hostname
# chmod 755 /usr/local/sbin/get-my-hostname
Aquí podéis ver el código completo de get-my-hostname:

Por último, tan sólo comentar que el script hace uso del comando nslookup que pertenece al paquete dnsutils. Por tanto, para que el script funcione, deberéis tener instalado dicho paquete. Como se encuentra en los repositorios, resulta fácil de instalar:
# apt-get install dnsutils
Publicado por primera vez en http://enavas.blogspot.com.es

lunes, 11 de junio de 2018

LVM: Aumentar el tamaño de un volumen lógico

Ahora que he añadido un segundo volumen físico al NAS, observo que el espacio de almacenamiento del volumen lógico que aloja backups y máquinas virtuales comienza a tener poco espacio libre:
# df -h | grep backup
/dev/mapper/openmediavault--vg-backup           1,7T   1,4T  231G  86% /export/backup
Por tanto, voy a aumentar en 500 GB el tamaño de este volumen lógico:
# lvextend -L+500G /dev/openmediavault-vg/backup 
  Size of logical volume openmediavault-vg/backup changed from 1,65 TiB (433822 extents) to 2,14 TiB (561822 extents).
  Logical volume backup successfully resized
Una vez aumentado el tamaño del volumen logico, redimensionamos el sistema de archivos alojado en dicho volumen lógico:
# resize2fs /dev/openmediavault-vg/backup 
resize2fs 1.42.12 (29-Aug-2014)
El sistema de ficheros de /dev/openmediavault-vg/backup está montado en /media/e3da494b-3f93-43f3-ad44-55c23672533f; hace falta cambiar el tamaño en línea
old_desc_blocks = 106, new_desc_blocks = 138
The filesystem on /dev/openmediavault-vg/backup is now 575305728 (4k) blocks long.
Por último, comprobamos que el tamaño del sistema de archivos se ha aumentado:
# df -h | grep backup
/dev/mapper/openmediavault--vg-backup           2,2T   1,4T  703G  66% /export/backup
Un detalle que es importante destacar es que podemos aumentar el tamaño del sistema de ficheros online, es decir, sin desmontarlo, porque el kernel 2.6 y sucesivos, soportan el redimensionado on-line para sistemas de ficheros ext3 y ext4. Sin embargo, si en lugar de aumentar el tamaño del sistema de archivos, quisiera reducirlo, tendría que hacerlo forzosamente off-line. Es decir, arrancando desde un live-cd, por ejemplo.
Publicado por primera vez en http://enavas.blogspot.com.es

pvcreate: Inicializar un disco o partición para usar con LVM

pvcreate nos permite inicializar un volumen físico (ya sea un disco o una partición) para utilizarlo con LVM.

Si lo que queremos inicializar es una partición hay dos posibilidades:
  • Si la partición es DOS, tendremos que definir el tipo de partición con el identificador 0x8e utilizando por ejemplo fdisk o cfdisk.
  • Si la partición es GPT, el identificador que tendremos que asignar a dicha partición es E6D6D379-F507-44C2-A23C-238F2A3DF928 utilizando gdisk.
Ahora bien, si lo que queremos es inicializar un disco entero, debemos eliminar la tabla de particiones. Por ejemplo, suponiendo que queremos inicializar el disco /dev/sdb:
# dd if=/dev/zero of=/dev/sdb bs=512 count=1
1+0 registros leídos
1+0 registros escritos
512 bytes (512 B) copiados, 0,526633 s, 1,0 kB/s
Una vez eliminada la tabla de particiones, podemos inicializar el disco:
# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created
Y una vez creado el volúmen físico, no tenemos nada más que añadirlo al grupo de volúmenes:
# vgextend openmediavault-vg /dev/sdb
  Volume group "openmediavault-vg" successfully extended
root@nas:~# vgdisplay
  --- Volume group ---
  VG Name               openmediavault-vg
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  27
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                9
  Open LV               8
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               6,37 TiB
  PE Size               4,00 MiB
  Total PE              1669196
  Alloc PE / Size       709674 / 2,71 TiB
  Free  PE / Size       959522 / 3,66 TiB
  VG UUID               S8vhnq-5qyu-ma9Q-GzQ6-UfXo-u98J-NoQUDD
Publicado por primera vez en http://enavas.blogspot.com.es

viernes, 8 de junio de 2018

Simular operaciones de instalación/desinstalación/actualización de paquetes con aptitude y apt-get

Tanto aptitude como apt-get disponen de un parámetro (-s, --simulate) que nos permite simular la instalación/desinstalación/actualización de paquetes antes de realizarla. Es conveniente, sobre todo en servidores, utilizar esta opción de simulación para ver si hay algún problema antes de realizar una operación de este tipo.

Por ejemplo:
admin@bdc:~$ sudo apt-get -s upgrade
[sudo] password for admin: 
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
Calculando la actualización... Hecho
Los siguientes paquetes se han retenido:
  libdrm-amdgpu1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-egl1-mesa linux-generic linux-headers-generic linux-image-generic
Se actualizarán los siguientes paquetes:
  libldap-2.4-2
1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 9 no actualizados.
Inst libldap-2.4-2 [2.4.42+dfsg-2ubuntu3.2] (2.4.42+dfsg-2ubuntu3.3 Ubuntu:16.04/xenial-updates [amd64])
Conf libldap-2.4-2 (2.4.42+dfsg-2ubuntu3.3 Ubuntu:16.04/xenial-updates [amd64])
Al ejecutar el comando en modo simulación en este servidor, estoy viendo que se va a instalar un paquete y que no se produce ninguna desinstalación no deseada de otros paquetes. Así que, puedo hacer tranquilamente una actualización de paquetes:
$ sudo apt-get -y upgrade
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
Calculando la actualización... Hecho
Los siguientes paquetes se han retenido:
  libdrm-amdgpu1 libdrm2 libegl1-mesa libgbm1 libgl1-mesa-dri libwayland-egl1-mesa linux-generic linux-headers-generic linux-image-generic
Se actualizarán los siguientes paquetes:
  libldap-2.4-2
1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 9 no actualizados.
Se necesita descargar 161 kB de archivos.
Se utilizarán 0 B de espacio de disco adicional después de esta operación.
Des:1 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64 libldap-2.4-2 amd64 2.4.42+dfsg-2ubuntu3.3 [161 kB]
Descargados 161 kB en 0s (492 kB/s)   
(Leyendo la base de datos ... 127182 ficheros o directorios instalados actualmente.)
Preparando para desempaquetar .../libldap-2.4-2_2.4.42+dfsg-2ubuntu3.3_amd64.deb ...
Desempaquetando libldap-2.4-2:amd64 (2.4.42+dfsg-2ubuntu3.3) sobre (2.4.42+dfsg-2ubuntu3.2) ...
Procesando disparadores para man-db (2.7.5-1) ...
Configurando libldap-2.4-2:amd64 (2.4.42+dfsg-2ubuntu3.3) ...
Procesando disparadores para libc-bin (2.23-0ubuntu10) ...
Publicado por primera vez en http://enavas.blogspot.com.es

Estructura del mirror de Ubuntu Bionic Beaver

En un post del miércoles pasado, os mostré como crear el mirror de Ubuntu Bionic Beaver con los repositorios fundamentales. A raiz de este post, algunos compañeros me han preguntado cuáles eran los repositorios que estaba mirrorizando actualmente. Pues bien, aquí podéis verlo:
/var/spool/apt-mirror/
├── mirror
│   ├── archive.canonical.com
│   │   └── ubuntu
│   │       ├── dists
│   │       │   └── bionic
│   │       └── pool
│   │           └── partner
│   ├── desarrollo.educarex.es
│   │   └── solointranet
│   │       └── ubuntu
│   │           └── bionic
│   ├── dl.google.com
│   │   └── linux
│   │       ├── chrome
│   │       │   └── deb
│   │       └── earth
│   │           └── deb
│   ├── es.archive.ubuntu.com
│   │   └── ubuntu
│   │       ├── dists
│   │       │   ├── bionic
│   │       │   ├── bionic-backports
│   │       │   ├── bionic-proposed
│   │       │   └── bionic-updates
│   │       └── pool
│   │           ├── main
│   │           ├── multiverse
│   │           ├── restricted
│   │           └── universe
│   ├── hp.archive.canonical.com
│   │   └── updates
│   │       └── dists
│   │           └── bionic-oem
│   ├── oem.archive.canonical.com
│   │   └── updates
│   │       └── dists
│   │           └── bionic-oem
│   └── security.ubuntu.com
│       └── ubuntu
│           ├── dists
│           │   └── bionic-security
│           └── pool
│               ├── main
│               ├── multiverse
│               └── universe
├── skel
│   ├── archive.canonical.com
│   │   └── ubuntu
│   │       └── dists
│   │           └── bionic
│   ├── desarrollo.educarex.es
│   │   └── solointranet
│   │       ├── pizarras
│   │       │   └── testing
│   │       └── ubuntu
│   │           └── bionic
│   ├── dl.google.commás
│   │   └── linux
│   │       ├── chrome
│   │       │   └── deb
│   │       └── earth
│   │           └── deb
│   ├── es.archive.ubuntu.com
│   │   └── ubuntu
│   │       └── dists
│   │           ├── bionic
│   │           ├── bionic-backports
│   │           ├── bionic-proposed
│   │           └── bionic-updates
│   ├── hp.archive.canonical.com
│   │   └── updates
│   │       └── dists
│   │           └── bionic-oem
│   ├── oem.archive.canonical.com
│   │   └── updates
│   │       └── dists
│   │           └── bionic-oem
│   └── security.ubuntu.com
│       └── ubuntu
│           └── dists
│               └── bionic-security
└── var
Si echáis un vistazo al post del miércoles, veréis que es sencillo añadir más repositorios para mirrorizarlos.

No hace mucho tiempo, virtualicé el mirror de trusty en un contenedor Proxmox. Ahora, en lugar de mirrorizar bionic en el mismo contenedor, he creado el mirror de bionic en otro contenedor. De este modo, cuando deje de tener clientes trusty, tan sólo tengo que parar la máquina virtual  que contiene el mirror de trusty y eliminarla, manteniendo la copia de seguridad durante un tiempo, por si volviera a necesitarla.

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