Reparar una actualización fallida de Ubuntu

El otro día estaba realizando una actualización en un computador portátil antiguo de Ubuntu 18.04 a Ubuntu 20.04. Recientemente, el computador ha tenido algunos problemas de sobrecalentamiento, por lo cual tuve que cambiarle la pasta térmica del CPU. Como no había presentado más fallas, me confié, y realicé una una actualización a la siguiente versión. Desgraciadamente, a medio camino de la instalación se sobrecalentó el computador, y por seguridad se apagó. De allí, al iniciar el sistema no volvió a entrar al ambiente gráfico, sino a la consola de emergencia.

En consola de emergencia, lo primero que intenté fue reparar la el estado de instalación de los paquetes utilizando el siguiente comando:

sudo apt install -f

Pero esto falló debido a un aparente conflicto de dependencia mutua de udev con snapd. Entonces comencé a buscar en internet, y conseguí que en algunos casos, basta con:

1. Reparar la instalación anterior.
2. Reconfigurar los paquetes instalados.
3. Actualizar el listado de paquetes instalables desde los repositorios.
4. Actualizar los paquetes instalados en el sistema (que no requieran la desinstalación de paquetes ya presentes en el sistema).

Esto se puede ejecutar utilizando los siguientes comandos:

sudo apt install -f #1
sudo dpkg --configure -a #2
sudo apt update #3
sudo apt upgrade #4

Mi caso no fue solucionable con los comandos anteriores, ya que el conflicto antes mencionado hacía que terminasen con error "sudo apt install -f", "sudo dpkg --configure -a" y "sudo apt upgrade". El único comando que siguió funcionando fue "sudo apt update". 

Entonces seguí investigando y encontré un procedimiento para reparar una instalación fallida iniciando el equipo con un sistema operativo desde un medio externo (LiveUSB o LiveCD), utilizando chroot. En mi caso, utilicé una memoria USB que tenía a la mano con Debian, pero cualquier otra distribución derivada de Debian (Ubuntu, Mint, etc) o incluso otras distribuciones de Linux. Tomé como base los comandos utilizados allí, pero le hice algunas modificaciones. Los pasos ejecutados fueron:

1. Iniciar el computador desde un sistema Linux externo.
   
2. Identificar la partición donde está instalada el sistema a recuperar. En mi caso tuve que probar con varias, porque el computador tiene varias instalaciones de Linux, de diferentes distribuciones, en distintas particiones.
3. Montar la partición a reparar en /mnt
4. Montar "enlazados" (utilizando la opción bind) los directorios proc, sys, y dev del sistema a reparar en el ambiente del medio externo.
5. Copiar el archivo resolv.conf desde el ambiente externo al ambiente a reparar.
6. Cambiar de ambiente raíz, al sistema a reparar.
7. Reparar la instalación anterior.
8. Reconfigurar los paquetes instalados.
9. Actualizar el listado de paquetes instalables desde los repositorios.
10. Actualizar los paquetes instalados en el sistema, que no requieran la desinstalación de paquetes ya presentes en el sistema.
11. Actualizar los paquetes instalados en el sistema, aunque sí requieran la desinstalación de paquetes ya presentes en el sistema.
12. Desinstalar los paquetes innecesarios
13. Salir del ambiente raíz del sistema a reparar.
14. Desmontar los directorios proc, sys, y dev del sistema a reparar previamente montados en el ambiente externo.
15. Desmontar la partición a reparar en /mnt previamente montada en el ambiente externo.
16. Reiniciar el sistema en el ambiente ya reparado.

Estos pasos se pueden ejecutar con los siguientes comandos:

fdisk -l #2
sudo mount /dev/sda1/ /mnt #3 Sustituir sda1 por la partición correcta.
sudo mount --bind /proc/ /mnt/proc/ #4.a
sudo mount --bind /sys/ /mnt/sys/ #4.b
sudo mount --bind /dev/ /mnt/dev/ #4.c
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf #5
sudo chroot /mnt/ #6
sudo apt install -f #7
sudo dpkg --configure -a #8
sudo apt update #9
sudo apt upgrade #10
sudo apt full-upgrade #11
sudo apt autoremove  #12
exit #13
sudo umount /proc/ #14.a
sudo umount /sys/ #14.b
sudo umount /dev/ #14.c
sudo umount /mnt/ #15

Obtener Serial de Producto de Windows 7 a través de la consola

Para poder obtener el número de serial de producto de Windows 7 desde la consola, el primer paso es abrir una consola de comandos como administrador. Una vez abierta la consola, basta con ingresar el siguiente comando:

wmic os get "serialnumber"

Contar rápidamente una gran cantidad de archivos en Linux

Este es un artículo breve, tengo un directorio lleno de archivos para un proyecto, y quería una forma de poder contarlos eficientemente. El siguiente comando resultó muy bien:

/bin/ls -f | wc -l 

Encontrar la dirección IP de un equipo en la red local (nmap)

Lo primero que tuve que hacer cuando comencé a utilizar mi Banana Pi, fue averiguar cuál dirección IP le había asignado el enrutador por DHCP, para poder conectarme por SSH y hacer las respectivas configuraciones.

Aprovechando que tengo Nmap instalado en mi computador de escritorio, hice uso de los siguientes comandos (desde Windows).

Para obtener los datos generales de la red local:

ipconfig

El cual da como respuesta un listado de la información de todas las interfaces de red del equipo. En la interfaz apropiada (inalámbrica o cableada, por ejemplo), nos interesan los siguientes datos:

   IPv4 Address. . . . . . . . . . . : 192.168.0.80
   Subnet Mask . . . . . . . . . . . : 255.255.255.0

Con la dirección IP y la máscara de subred, ejecutamos (con permiso de Administrador)

nmap -sP 192.168.0.80/24

El listado resultante nos indicará cuáles direcciones IP están activas en la red local, así como el nombre del equipo.

Windows: Cómo saber quien está conectado a un servidor remoto

A veces es necesario conectarse a un servidor Windows remoto, pero por limitaciones en el número de licencias, se debe revisar primero quién está conectado.
Una forma de hacerlo, es intentar conectarse y que el Servidor indique si hace falta expulsar a alguien para poder conectarse. Pero esa forma me parece poco elegante y algo intrusiva.
Buscando en internet conseguí el comando query, que permite listar los usuarios conectados a un servidor, ejecutando la siguiente sentencia en CMD:

query user /server:example.com

Cómo ejecutar sentencias PHP desde la consola

Estaba revisando el código de algunas páginas en PHP y quise validar, rápidamente, el valor de algunas expresiones utilizadas. 

Para no tener que montar un depurador, o configurar un ide, o empezar a escribir mini páginas PHP de prueba, decidí averiguar como ejecutar PHP desde la consola.

Resultó ser bastante sencillo

php5 -r 'echo php_uname("n") . "\n";'

Configurar HTTPS en Banananian (Debian)

Ya configurado Apache HTTPD en mi Banana Pi, el siguiente paso paranoico lógico es configurar HTTPS para que el tráfico quede cifrado. De esta forma se protege la confidencialidad de cualquier información importante (como contraseñas) que tengan que viajar por la red.
Encontré un tutorial para Debian, bastante completo, en Digital Ocean.
En resumen, para asegurarnos de que estén instalados y actualizados tanto Apache HTTPD como OpenSSL, activar HTTPS y generar el certificado SSL:

sudo aptitude update
sudo aptitude full-upgrade
sudo aptitude install apache2 openssl
sudo a2enmod ssl
sudo a2ensite default-ssl
sudo service apache2 reload
sudo mkdir /etc/apache2/ssl

sudo openssl req -x509 -nodes -days 365 -newkey \
rsa:2048 -keyout /etc/apache2/ssl/apache.key -out \
/etc/apache2/ssl/apache.crt
sudo chmod 600 /etc/apache2/ssl/*

Luego es necesario editar el archivo de configuración del sitio web SSL con

sudo nano /etc/apache2/sites-enabled/default-ssl.conf

Allí debemos modificarlo para que quede de la siguiente manera:

<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        ServerName www.example.com:443
        DocumentRoot /var/www/html
        . . .
        SSLEngine on
        . . .
        SSLCertificateFile /etc/apache2/ssl/apache.crt
        SSLCertificateKeyFile /etc/apache2/ssl/apache.key

Reiniciamos el servicio Apache HTTPD

sudo service apache2 reload

En este punto el servicio Apache HTTPD está respondiendo peticiones por HTTP y por HTTPS. Para que todo el tráfico HTTP sea redirigido a HTTPS, editamos la configuración del sitio por defecto con

sudo nano /etc/apache2/sites-enabled/000-default.conf

Y modificamos el archivo de forma que quede así

<VirtualHost *:80>
    ServerName www.example.com
    Redirect / https://www.example.com/
</VirtualHost >

Finalmente, reiniciamos el servicio Apache HTTPD

sudo service apache2 reload

Si la consola no autocompleta (2)

Hace un (largo) tiempo, tuve que modificar la configuración de bash en mi laptop (con Ubuntu) porque no podía autocompletar con la tecla de tabulación comandos como aptitude o apt-get. Me encontré con el mismo problema en mi Banana Pi, con Bananian, pero el problema no estaba en el archivo .bashrc, ya que éste ya tenía activa la opción para autocompletar.
Luego de algunas búsquedas en Internet, di con el tema: faltaba instalar el paquete bash-completion

sudo aptitude install bash-completion

Luego de recargar bash, comenzó a funcionar el autocompletado para aptitude y apt-get

bash 

Instalando Apache HTTPD en Bananian (Debian)

Lo primero que tengo que hacer para poder utilizar mi Banana Pi como un servidor de Intranet en mi casa es instalar el servidor web.
Empezamos con la instalación de Apache2 y los paquetes que recomienda.

sudo aptitude install apache2 -r

Luego viene la configuración de los módulos, en particular userdir, que permite que los usuarios del servidor puedan publicar sitios en html en la dirección servidor/~nombredeusuario, con tan solo guardarlos en el directorio public_html de su carpeta personal.

sudo a2enmod userdir.load

Luego unas medidas de seguridad sencillas: Desactivamos que indique su versión y el sistema operatico en las cabeceras HTTP y en el pie de página de algunas páginas por defecto. Es necesario editar el archivo /etc/apache2/conf-enabled/security.conf y fijar los siguientes valores

ServerTokens ProductOnlyServerSignature Off 

Finalmente, reiniciamos el servicio Apache2

sudo service apache2 restart

Ahora tenemos un servidor web en el Banana Pi.

Para deshacernos del siguiente mensaje:

apache2: Could not reliably determine the server's fully qualified domain name, using 192.168.1.162. Set the 'ServerName' directive globally to suppress this message

Creamos el siguiente archivo

sudo nano /etc/apache2/conf-available/ServerName.conf 

Cuyo contenido debe ser

ServerName nombredelservidor

Activamos este archivo de configuración con

sudo a2enconf ServerName.conf

Y reiniciamos el servicio Apache2 nuevamente

sudo service apache2 restart

Primeros pasos con Bananian (Debian)

Luego de instalar Bananian Linux en la tarjeta Micro SD, como indiqué en el artículo anterior, llegó la hora de arrancar el sistema y ejecutar los pasos iniciales.

1. Configuración inicial del sistema. Nombre del equipo, localización e idioma, zona horaria, etc.

bananapi-config

2. Actualizar el sistema. Descargar la información de los repositorios y actualizar las aplicaciones ya instaladas.

aptitude update && aptitude full-upgrade -y

3. Credenciales. Cambiar la contraseña del superusuario, crear mi usuario, y hacerlo administrador

passwd
adduser usuarionuevo
aptitude install sudo
adduser usuarionuevo sudo

Ahora tengo un sistema actualizado, puedo dejar de lado el superusuario y utilizar un usuario a mi medida.

Desinstalar actualizaciones de Windows por consola de comandos

Estaba leyendo sobre varias actualizaciones indeseables de Windows, y decidí validar que no estuviesen instaladas en mi sistema, para lo cual fui a la sección de Actualizaciones de Windows en el Panel de Control.

Sin embargo, me resultó engorroso consultar puntualmente si las actualizaciones de mi interés estaban instaladas o no.

Buscando en Internet, conseguí que el comando para listar todas las actualizaciones instaladas es:

wmic qfe list

Podemos filtrarlo utilizando

wmic qfe list | findstr KB1234567

Podemos redireccionar la salida del comando a un archivo de texto, y ahí consultar más cómodamente con

wmic qfe list > C:\kblist.txt
cat C:\kblist.txt | findstr KB1234567

Para desinstalar una actualización, basta con ejecutar

wusa /uninstall /kb:1234567 /quiet /norestart 

Aplicando unzip masivo a archivos con espacios

Tenía una carpeta llena de archivos ZIP, cuyos nombres contenían espacios, paréntesis, apóstrofes y otros caracteres especiales.

Carpeta
+ Primer Archivo.zip
+ Archivo (Paréntesis).zip
+ Archivo 'Apóstrofe.zip

Y mi intención era descomprimirlos todos de una sola vez, para que otra aplicación importase los archivos internos, manteniendo la jerarquía de carpetas.
Mi primer intento fue

unzip *.zip

Error. Unzip tomaba cada fragmento separado por espacio como un parámetro individual.
Luego vino

find *.zip -type f -exec unzip {} \;

Error. Unzip seguía tomando cada fragmento separado por espacio como un parámetro individual.
Entonces intente con un null como separador, no conseguí el comando de unzip que le permitiese entender el separador null, así que incorporé xargs al comando, incluso intenté con comillas.

find *.zip -type f -print0 | xargs -0 unzip {}
find *.zip -type f -print0 | xargs -0 unzip "{}"

Mismo error.
Descubrí que ls -b da como salida una lista de nombres de archivo con los espacios escapados.

ls -b *.zip | xargs unzip {}

Mismo error. Probé con echo, y sospecho que xargs se come las escapadas de los espacios.
Empiezo el camino de admisión de derrota al redactar un pequeño guión bash

#!/bin/sh

for file $(ls -b *.zip)
do
    unzip $file
done

Mismo error. Resulta que el for toma cada pedazo separado por espacios.
Quedaban dos opciones de admisión total de derrota ante el reto de descomprimir masivamente archivos ZIP con espacios en el nombre:

1. Eliminar los espacios de los nombres de archivo
2. Lanzar muchos comandos de descompresión

Me fui por la segunda opción. No era una aceptable escribir cada comando manualmente, así que construí un comando que elaborase un guión bash especializado.

echo "#!/bin/sh" > descomprimir.sh
ls -b *.zip | sed 's/^/unzip /' >> descomprimir.sh
chmod +x descomprimir.sh
./descomprimir.sh

El archivo resultante, descomprimir.sh queda de la forma:

#!/bin/sh
unzip Primer\ Archivo.zip
unzip Archivo\ (Paréntesis).zip
unzip Archivo\ 'Apóstrofe.zip

Eso hizo 90% del trabajo. Me di cuenta de que los paréntesis y los apóstrofes seguían dando problemas. Como ya había descomprimido parte de los archivos, decidí generar el archivo anterior nuevamente de forma que unzip no reescribiese los archivos ya extraídos, lo cual se logró con unzip -n. Escapar el apóstrofe requirió utilizar el valor en hexadecimal.

echo "#!/bin/sh" > descomprimir.sh
ls -b *.zip | sed 's/^/unzip -n /' |\
sed 's/(/\\(/' | \sed 's/)/\\)/' | sed "s|\x27|\x5c\'|">> descomprimir.sh

chmod +x descomprimir.sh
./descomprimir.sh

Con esto, el archivo quedó de la forma

#!/bin/sh
unzip -n Primer\ Archivo.zip
unzip -n Archivo\ \(Paréntesis\).zip
unzip -n Archivo\ \'Apóstrofe.zip

Éxito. Se descomprimieron todos los archivos.
Como reflexión final, quizás hubiese sido más sencillo renombrar masivamente los archivos para eliminar los espacios, o quizás los paréntesis y los apóstrofes igual me hubiesen llevado por el mismo camino. Otro día investigaré más a fondo las posibilidades de xargs o algún otro comando de escapar todos los caracteres especiales.

Migrar fstab a UUID

Una computadora de escritorio que administro ha pasado desde Dapper Drake (Ubuntu 6.06 LTS) hasta Lucid Lynx (Ubuntu 10.04 LTS), y tiene heredado el archivo /etc/fstab sin los identificadores UUID para las particiones.
Cuando se dañó el disco duro donde estaba Windows y GRUB , hubo que reinstalar GRUB en el disco de Ubuntu. Como el disco pasó de ser sdb a ser sda, no se podían ubicar las particiones con el archivo fstab que las referenciaba como /dev/sdb1, /dev/sdb2, etc.
Desde la consola de superusuario que cargó Ubuntu apenas falló el fstab se cambiaron las particiones críticas (/, /home y swap) de sdb a sda.
Pero para evitar que un disco duro o partición nueva descuadre el arranque, es buena idea utilizar los identificadores UUID.
Para listar los UUID de todas las particiones se ejecuta el comando

sudo blkid

Luegose edita el archivo /etc/fstab sustituyendo

/dev/sda1 {opciones}

Por

UUID="{identificador UUID}" {opciones}

Para evitar incovenientes por configuraciones incorrectas, se puede comentar las lineas de tipo /dev/sda1 con "#" y agregar las líneas con UUID="{identificador}".
Al reiniciar el equipo se podrá comprobar que todas las particiones hayan cargado exitosamente.

Si la consola no autocompleta

Acostumbrado a la alta disponibilidad de aplicaciones y repositorios asociados a Debian y sus derivados, además de la gran cantidad de tutoriales disponibles para Ubuntu, se hizo insostenible mantener SUSE como distribución de uso principal.
Instalé Ubuntu en una nueva partición, indicándole cuál partición usar como /home. Sin embargo, pulsar el tabulador en la consola no funcionaba como es lo usual: no se autocompletaban comandos invocados con sudo, no se autocompletaban las opciones de apt-get y aptitude, además de otras molestias menores.
Luego de mucho indagar me di cuenta que el problema yacía en el archivo de configuración de la consola ~/.bashrc que había sido heredado de SUSE.
Bastó ejecutar

cp /etc/bash.bashrc ~/.bashrc

Y luego descomentar el tramo  de autocompletación en consolas interactivas en ~/.bashrc

# enable bash completion in interactive shells
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi

Ahora sólo hace falta cerrar la consola y abrirla de nuevo. Ya está cargado el nuevo ~/.bashrc