Debian/Linux: cambiando arquitectura x86 a x64

Hace poco os conté que no me aparecía el comando shutdown una vez había elevado privilegios con su y cómo lo solucioné. Todo ello porque descubrí que mi instalación de Debian estaba como x86 cuando mi máquina era x64. No recuerdo por qué lo hice en su momento: si fue un despiste o si tenía una razón que en ese momento era lógica. Así que busqué el procedimiento, lo seguí, me dio problemas, acabé actualizando (de casualidad) a la nueva versión de Debian hasta que me encontré con dicho problema y con su solución, ahí contada.

Como dije escribiría un post contando qué procedimientos seguí. No tomé nota, pero sí he estado manteniendo las distintas pestañas que estuve viendo, por lo que lo más seguro es que alguna cosa no termine de coincidir.

También, y antes de ponernos en harina, toca el típico disclaimer: no hagas esto si no estás muy seguro. Podrías terminar necesitando reinstalar muchísimos paquetes y te volverás loco. Vamos: que casi, casi podrías necesitar reinstalar (tal y como recomiendan en algunos sitios: hacer una instalación limpia antes de hacer el cambio).

Todo lo vamos a hacer en consola con privilegios.

Ejecutamos:

# dpkg --print-architecture

Que nos mostrará la arquitecura actual (que es la que nos indica que estamos en x86)

i386

Vamos a añadir la nueva para poder tirar de x64:

dpkg --add-architecture amd64

Si ahora ejecutamos:

dpkg --print-foreign-architectures

Nos mostrará:

amd64

Ahora toca actualizar el repostorio e instalar el kernel para x64. El mayor misterio es indicar en el que queremos que tire de amd64.

apt-get update
apt-get install linux-image-amd64:amd64

Toca reiniciar. Acuérdate de seleccionar el kernel recién instalado.

Al ejecutar dpkg con los dos parámetros anteriores los resultados se intercambiarán, siendo amd64 el principal e i386 el foreing.

Desconozco por qué hacen un clean pero normalmente para estos casos yo lanzo todos: purge, clean, autoclean, etc.

apt-get clean
apt-get autoclean
apt-get purge
...

Ahora toca descargamos tres paquetes para esta arquitectura y forzar su instalación con dpkg:

apt-get --download-only install dpkg:amd64 tar:amd64 apt:amd64
dpkg --install /var/cache/apt/archives/*_amd64.deb

Tampoco estoy muy seguro si le llegué a pasar el parámetro --force-architecture en alguno  de estos dos comandos. Me suena que sí pero no recuerdo en cuál (mínimo en el segundo).

En teoría ahora podrías instalar cosas en la recién configurada arquitectura. Esto tiene su aquel. Porque según las distintas fuentes ponen un orden u otro sobre cómo o cuándo instalar los paquetes. Al final lo que hace falta es actualizar todos los máximos paquetes necesarios. Además, hay más librerías que harán falta (gcc, libgcc1, libc6...) y se te quejará mucho el sistema si no las has actualizado.

Un ejemplo para las actualizaciones y correcciones de los paquetes puede ser el siguiente...

Actualizar el repositorio:

apt-get update

En algunas de esas instalaciones te forzará a escribir algo así como "Sí, ¡haz lo que yo digo!". Además, no metas ningún typo o no lanzará la instalación. Al final hace una comparación literal de lo que busca (entiendo que se incluyen exclamaciones y todo).

Aunque será necesario corregir o reparar muchas instalaciones (ambos son los mismos):

apt-get -f install
apt-get --fix-broken install

También se puede hacer reinstalación de paquetes. Este parámetro no recuerdo si lo llegué a poner: pero revisando la ayuda de apt-get viene y seguro que en algún momento lo lancé. Más adelante mostraré un ejemplo.

Actualizar todos los paquetes del sistema con respecto al repositorio:

apt-get upgrade
apt-get dist-upgrade

Ir buscando los paquetes instalador como i386 para ver si puedes forzar a que se instalen como amd64:

dpkg --get-selections | grep i386

Y a partir de aquí, forzar la reinstalación:

apt-get --fix-broken --reinstall paqueteParaReinstalar:amd64

Y de todas formas, te encontrarás con que hay paquetes que tienen ambas versiones instaladas. Algunas las podrás desinstalar (no te olvides de poner :i386 no vayas a perder la de la nueva arquitectura).

Así, será necesario repetir muchas, muchas, muchas... muchas veces todos estos procesos de apt-get. Por eso, al ser una locura y encontrarme con tantos problemas, se me ocurrió actualizar a la nueva versión de Debian. Que por suerte llevaba apenas dos semanas publicada. Y aún así, terminé corrigiendo problemas montando el entorno con una unidad de arranque y actualizando muchos más paquetes en ese entorno.

Como podéis ver es... Vamos. Que es bastante lío. ¿Compensa reinstalar de cero e ir montando el sistema de nuevo? Pues no lo sé. Para suele ser mejor recuperar un sistema que montarlo de cero. Pero de vez en cuando toca hacerlo. En mi caso, que llevaba relativamente poco tiempo con la instalación original, no me compensaba ponerlo de cero.

Si puedo ayudar en cualquier duda del procedimiento, por favor, avisadme. A ver si hay suerte y puedo ayudar.

***
Algunas de las fuentes que tuve que utilizar:

https://askubuntu.com/questions/5018/is-it-possible-to-upgrade-from-a-32bit-to-a-64bit-installation
https://unix.stackexchange.com/questions/40463/how-to-convert-a-32-bit-x86-debian-based-system-to-64-bit
https://wiki.debian.org/CrossGrading

Debian; shutdown: command not found

Por cierto: este post lo escribiendo desde el móvil. Espero que el corrector no haga de las suyas.

Hace poco hice una actualización de mi Debian "scratch" a... "buster". Pero por intentar pasar la arquitectura de instalación de 32 bits a 64. Como la cosa no me terminó de ir del todo bien al intentar sustituir las aplicaciones me dio por buscar y encontré con que había nueva versión de Debian.

Para resumir: después de muchas sustituciones y malabarismos varios, di por finalizada la tarea. Pero mi usuario root era incapaz de apagar o. reiniciar la máquina con los comandos.

Así, buscando, me he encontrado con la solución.

El problema se da sólo al elevar simplemente con

#su

Porque ahora, tal cual está, no incluye la variable de entorno $PATH de root. Para que la incluya hay que pasar alguno de los siguientes parámetros: [- | -l (L minúscula) | --login]

Así, ejecutando:

#su -l

Ya nos incluirá en el $PATH la carpeta

/sbin

Que ha dejado de ponerla con el su de toda la vida.

Espero que si os sucede os sea de utilidad.

Elegir qué versión de Python ejecutar

En el siguiente enlace:

https://linuxconfig.org/how-to-change-default-python-version-on-debian-9-stretch-linux

nos indican cómo forzar qué versión de python ejecutamos tenemos varias instaladas a la vez.

Aunque también se tiene la opción de seleccionar el número directamente:

$python3.6
$python2.7

si ejecutamos

$python

¿Qué se ejecuta? Eso es lo que decidimos aquí. Así, además, se debería de poder desinstalar la versión antigua.

Sólo para tenerlo como chuleta. Espero que a vosotros también os sea de utilidad en algún momento.

Simulador de expresiones regulares

Uno muy, muy rápido.

Un simulador para hacer expresiones regulares y ver con colorines qué se selecciona realmente es este que enlace aquí abajo:

https://regex101.com/


Al menos para python me ha venido muy bien y quiero tenerlo por aquí (hasta que se me olvide que lo tenía) por si algún día me hace falta encontrarlo de nuevo.

Además de python también lo ejecuta con otros tres o cuatro lenguajes más. Esto ahorrará mucho ensayo y error. Además, da bastantes pistas de qué parte se está detectando y cuál no.

/etc/resolv.conf: se sobreescribe

A ver si me sale corto este post.

Esta es la típica solución que cuesta mucho encontrar, uno cree que se acordará de la solución y tiempo después la necesita y se ha olvidado.

Problema que llevo queriendo solucionar desde hace mucho tiempo: el fichero /etc/resolv.conf de un Debian que tengo instalado se me sobreescribe. Todo el tiempo que he querido solucionarlo he intentado quitar distintos servicios que ya ni me acuerdo. Pero me he encontrado con que una persona ha mostrado distintas soluciones al problema.

Una de ellas me ha permitido solucionarlo encontrándome con que mi resolv.conf era un enlace a un fichero de NetworkManager. En mi caso, su solución la he aplicado modificando directamente /etc/NetworkManager/NetworkManager.conf.

Ojo, que ese mismo enlace tiene más soluciones.

En el segundo enlace dan unas pocas pistas más. Pero habiéndolo solucionado con el primero poco más he leído del segundo (a parte de que he llegado a este a partir del segundo).

Espero que en algún momento os sea de utilidad.

Compartiendo impresoras por internet

Hoy he adquirido una impresora láser multifunción por Wallapop. Un trasto que de sólo transportarlo a pulso del coche (que no he podido aparcar excesivamente cerca de casa) ya me he ahorrado un día de entrenamiento en el gimnasio.

El caso: se me ha ocurrido hacer una búsqueda de su márca (XXX) y modelo (YYY) para ver temas de configuraciones (manual), tóner, ruidos raros que no me pareció oir cuando la han probado... El tema es que el primer resultado era el manual en PDF de la propia página del fabricante. Y para mi sorpresa había varias direcciones IP después. No sé por qué se me ha ocurrido acceder a ellas (cenutrio de mí, todo sea dicho). Y me he encontrado... ¡Con un panel de control del servidor web de la propia impresora!

Ahora que sigo fijándome en la búsqueda: he puesto el nombre completo entrecomillado "XXX YYY" problema para solucionar

Sí, ya sé que esto se podría hacer en Shodan. Pero no me hubiera imaginado nunca que una búsqueda tan básica me hubiera dado un resultado de este tipo en la segunda entrada. Como hubiera dicho Eugenio en un chiste "Cosa curiosa Rusia".

Seguiré configurando el cacharro y si me encuentro más cosas del aparato, aviaré por aquí. Por cierto: tengo pendiente un artículo que tengo a medias del Grandstream. Ya veré cuándo puedo jugar con el teléfono y lo documento.

Rsyslog: Logrotate

Voy a añadir una opción más a la configuración que hice recientemente para rsyslog. Para poder ver los datos que se envían desde el dispositivo que estamos analizando al servidor de logs correctamente, el hecho de que esté lleno de resultados de hace días no ayuda nada. Para ello se usa logrotate.

¿Cómo lo he configurado? Bien. He encontrado que existe un fichero en /etc/logrotate.conf y otros ficheros dentro de la carpeta /etc/logrotate.d/. De los ficheros que aparecían estaban asterisk, dpkg, samba, rsyslog.

Para forzar a que se cambien los ficheros diariamente para los dos aparatos que me interesa analizar, el SPA3102 y el teléfono Grandstream he incluido las siguientes líneas en el fichero de rsyslog:

/var/log/spa3102.log
/var/log/grandstream.log
{
        rotate 31
        daily
        dateext
        missingok
        notifempty
}

Las notas que puedo hacer al respecto:

• rotate: número de ficheros que quiero que se me generen.
• daily: quiero que se hagan diariamente.
• dateext: concatenar la fecha en los ficheros cuando se copian en vez de usar números.
• missingok: Por lo que he entendido, si el fichero de log (¿original?) falta, no se genera ningún error.
• notifempty: no rotar el fichero cuando este esté vacío.

Como no me terminaba de convencer hacer la prueba con todo lo que contiene rsyslog he decidido copiar y pegar la configuración aquí mostrada, sólo para Grandstream, en su propio fichero.

Después de la configuración he ejecutado la siguiente instrucción:

#logrotate -f -v /etc/logrotate.d/grandstream.conf

El resultado, además de rotar ficheros que no se habían tocado en mucho tiempo, es que me ha concatenado al fichero /var/log/grandstream.log la fecha, pero no me ha generado otro nuevo. Si miro su contenido, puedo ver que en dicho fichero se siguen guardando datos. Esto me hace preguntarme: ¿Me concatenará siempre la fecha o será sólo hoy? 

---

Si bien cuando empecé escribiendo este artículo, el sistema no se comportó como esperaba, me esperé unos días más para ver qué sucedía. ¿Qué tengo ahora? 

Ahora sí que tengo los ficheros con su nombre original y sus copias diarias con la extensión de "-aaaammdd" (año, mes, día). El único problema: no se están haciendo en el momento adecuado, por lo que tengo ficheros que dicen que son, por ejemplo, del día 15, que contienen datos del 14 y del 15. :

Así, tengo:

• grandstream.log-20190515: registros de las 6H del 14 a las 6H del día 15.
• grandstream.log: a partir de las 6H del día 15.

Ejecutando:

#cat /var/lib/logrotate/status

Es posible ver cuándo se rotó cada fichero. Y, en efecto, las horas cuadran con respecto al desfase mostrado en los logs que necesito analizar. Repasando el comando de más arriba:

#logrotate -dfv /etc/logrotate.d/grandstream.conf

Gracias a que he revisado con más detenimiento el resultado de su ejecución he podido corregir algunos de los ficheros de configuración aquí explicados (pero yo lo muestro sin me avise de errores). 

Con respecto a las horas a las que se produce la rotación ya he encontrado la razón de esa hora tan rara. La rotación se realiza con un cron diario (/etc/cron.daily/). Dentro de esa carpeta, entre otros ficheros, se encuentra el relacionado con logrotate. A su vez, la ejecución de cada uno de los scripts que tiene que lanzar cron, independientemente de que sean diarios, semanales, mensuales... Se hace a través de la configuración que se encuentra dentro de /etc/crontab. Este fichero muestra la hora y minuto que cuadra con la que se muestra en el contenido de los logs al final del más reciente con su extensión de fecha y al principio del que se ha creado.

Lo voy a dejar aquí. Sólo me queda tomar la decisión de dejarlo tal cual, quitar la extensión de fecha (y que me salga la numeración), cambiar la hora para la ejecución de todos los diarios, forzar a que se roten sólo esos ficheros a las 0H (y por lo tanto, al intentar hacerlo de nuevo a las 6H no tendrá efecto)... Ya veré.

Sólo para tener un listado de los distintos sitios que he visitado (y así poder buscar en un posible futuro si es necesario, aunque creo que he perdido alguno):

• https://www.networkworld.com/article/3218728/how-log-rotation-works-with-logrotate.html
• https://kifarunix.com/how-to-configure-log-rotation-with-logrotate-on-ubuntu-18-04-lts/
• https://www.svennd.be/rotate-rsyslog-logs-using-logrotate/
• https://www.loggly.com/docs/log-rotate/
• https://www.reddit.com/r/sysadmin/comments/309coq/a_little_help_with_logrotate_and_rsyslog/