Vi as a default editor in Fedora 42

Since the very first moment I upgrade from Fedora 41 to Fedora 42 I notice a good and a bad thing.

The good one was an improvement in performance on the same hardware, maybe it’s just an illusion but that was the impression.

The bad one is Fedora 42 changes the default system editor to Nano. I look for a solution and I found quite a large number of fast and dirty solutions, such as include this line in your profile;
$ echo "export EDITOR=/usr/bin/vim" >> ~/.bashrc

I didn’t like those solutions because they all attack the “effect” but not the “cause” and they didn’t seems to me a canonical solution. I was pretty sure that if Fedora decides to change the default editor there must be a way to revert it… and it was.

The default editor was config via the file: /etc/profile.d/nano-default-editor.sh . So I check what package owns that file via: rpm -qf /etc/profile.d/nano-default-editor.sh and that file belongs to nano-default-editor.noarch.

Since the very first moment I upgrade from Fedora 41 to Fedora 42 I notice a good and a bad thing.

The good one was an improvement in performance on the same hardware, maybe it’s just an illusion but that was the impression.

The bad one is Fedora 42 changes the default system editor to Nano. I look for a solution and I found quite a large number of fast and dirty solutions, such as include this line in your profile;
$ echo “export EDITOR=/usr/bin/vim” >> ~/.bashrc

I didn’t like those solutions because they all attack the “effect” but not the “cause” and they seems to me a canonical solution. I was pretty sure that if Fedora decides to change the default editor there must be a way to revert it… and it was.

The default editor was config via the file: /etc/profile.d/nano-default-editor.sh . So I check what package owns that file via: rpm -qf /etc/profile.d/nano-default-editor.sh and that file belongs to nano-default-editor.noarch.

It was obvious to me that there would be available a package named vim-default-editor.noarch. I tried an simple installation and dnf asks you if you agree to remove the nano-default package, you just consented and since them Vi rules again on the system.

Cómo reducir el tamaño de un fichero de log en caliente

Algunos ficheros no deben modificarse mientras están en uso porque comprometen la “estabilidad” del sistema. Son poco y uno de ellos es /var/log/lastlog donde se registra información en formato binario sobre los accesos al sistema.

Un ejemplo sería encontrar un fichero con este tamaño:

root@hostname:[~]$ ls -shl /var/log/lastlog 
48K -rw-rw-r--. 1 root utmp 523G jul 11 08:04 /var/log/lastlog

Para reducir el tamaño mientras está en uso sin comprometer las esstabilidad del sistema operativo se utiliza el comando truncate.

Por ejemplo, específicando el tamaño (size) en bytes al que queremos reducir el fichero. Conservará las entradas más recientes.

$ truncate -s 104857600 /var/log/lastlog

El resultado es la esperada reducción de tamaño (en el ejemplo sobre un fichero de 523G) sin que haya afectado a la escritura en él

root@hostname:[~]$ ls -shl /var/log/lastlog 
44K -rw-rw-r--. 1 root utmp 100M jul 11 14:20 /var/log/lastlog

Alma Linux vs Rocky Linux

Red Hat decidió cambiar el propósito de CentOS orientándola a ser una distribución con versiones más actualizadas (ahora encontramos cuatro variedades de CentOS; una CentOS sin más nomenclatura, una CentoOS Linux, una CentOS Stream y CentOS SIG ) y un anticipo de lo que se incorporaría a la siguiente versión de RHEL. CentOS dejaba de ser el clon gratuito de RHEL.

El movimiento causó que aparecieran dos nuevas distribuciones (añadidas a las que ya existían) que se presentaban como clones de RHEL gratuitos, gratuitos, (RHEL aunque sea software libre no es gratis). Las dos alternativas son Alma Linux y Rocky Linux. Ha pasado un tiempo suficiente y se pueden considerar asentadas.

¿Cuáles son sus principales diferencias si ambas con clones de RHEL? Lo que sigue es la suma de hechos recogidos y opinión personal

Ventajas

Alma Linux

  • Iniciada por la empresa CloudLinux que desde más de 10 años desarrollan “forks” de RHEL (CloudLinux OS) especialmente orientado a kernel fortificados, previenen ataques al virtualizar el sistema de ficheros de usuario (CageFS), ataques a enlaces simbólicos del kernel, técnicas que previenen el colapso del sistema por sobrecarga de consumo (LVE Manager),… trabajan con ISP más que con usuarios finales o instalaciones “on site”.
  • Respaldada por una organización sin ánimo de lucro, AlmaLinux OS Foundation. CloudLinux la fundó para que fuera una comunidad ajena a la empresa la que gobernase el futuro de la distribución.
  • Ofrece script de migración desde CentOS transparente para el usuario.
  • Primer clon estable alternativo a CentOS liberado
  • Soporte comercial vía https://tuxcare.com

Rocky Linux

  • El creador de CentOS es el creador de Rocky Linux, Gregory Krutzer.
  • Respaldada por Google Cloud.
  • Soporte comercial vía https://ciq.co.

Inconvenientes

Alma Linux

  • No elegida por Google Cloud.

Rocky Linux

  • Respaldada por una fundación también, aunque debido a diferencias “legales” la propiedad es de una sola persona; Gregory Kurtzer [1, 2, 3], creador de la distribución y de CiQ..
  • Primera versión estable liberada después de AlmaLinux.

Conclusión (personal)

Se puede elegir cualquiera de las dos como sustitución de CentOS. Si se trata de instalaciones en Cloud no será necesario elegir, lo hará AWS o Google por nosotros.

La diferencia en este momento, a falta de ver cómo evolucionan, está más en que AlmaLinux mantiene una proximidad a software libre mayor que RockyLinux que está más vinculada a las decisiones de una empresa gobernada por una persona.

Añado que la empresa que está detrás del proyecto de Alma Linux está compuesta por ingenieros que se dedicaban a trabajar en clones de RHEL para ISP que permitían, por ejemplo actualizar el kernel sin reiniciar el sistema. Su conocimiento y experiencia debe ser un valor a considerar.

Listar contenido de un paquete no instalado

Existen distintas manera de listar el contenido de un paquete rpm instalado. Una que funciona siempre es ejecutar:

rpm -ql NombreDelPaquete

El comando anterior funciona solamente si el paquete está instalado. ¿Y si queremos conocer qué contiene un paquete sin haberlo instalado o antes de instalarlo? He encontrado una manera de hacerlo sin instalar el paquete y que consulta a la información de la base de datos rpm / dnf:

dnf repoquery -l NombreDelPaquete

Un ejemplo para el paquete cmatrix (un pequeño paquete que presenta un protector de pantalla en el terminal). Primero se desintala, con lo que el comando rpm -ql cmatrix no encontrará nada en la base de datos del sistema. Segundo se ejecuta el dnf repoquery -l cmatrix que consultará la información presente en el repositorio.

[root@host ~]# rpm -ql cmatrix
el paquet cmatrix no està instal·lat
[root@host ~]# dnf repoquery -l cmatrix
Fedora 37 - x86_64 - Updates 15 kB/s | 7.9 kB 00:00
Fedora Modular 37 - x86_64 - Updates 33 kB/s | 17 kB 00:00
Fedora 37 - x86_64 - VirtualBox 2.9 kB/s | 6.9 kB 00:02
/usr/bin/cmatrix
/usr/bin/cmatrix-tty
/usr/lib/.build-id
/usr/lib/.build-id/11
/usr/lib/.build-id/11/92b5cf8ad61f36e6322a0f1270a4a88eaf5d5a
/usr/lib/kbd/consolefonts/matrix.fnt
/usr/lib/kbd/consolefonts/matrix.psf.gz
/usr/share/doc/cmatrix
/usr/share/doc/cmatrix/AUTHORS
/usr/share/doc/cmatrix/CODE_OF_CONDUCT.md
/usr/share/doc/cmatrix/CONTRIBUTING.md
/usr/share/doc/cmatrix/ChangeLog
/usr/share/doc/cmatrix/ISSUE_TEMPLATE.md
/usr/share/doc/cmatrix/NEWS
/usr/share/doc/cmatrix/README
/usr/share/doc/cmatrix/README.md
/usr/share/licenses/cmatrix
/usr/share/licenses/cmatrix/COPYING
/usr/share/man/man1/cmatrix.1.gz

Infraestructura de MercadoLibre

La entrevista de Pelado Neerd a dos administradores de sistemas de MercadoLibre (familiarmente y en adelante ML) aporta el estímulo de conocer qué se hace en otros entornos, sus diferencias con los nuestros, por tamaño o por decisiones para retos de infraestructura. Destaco unos pocos asuntos que me han llamado la atención y porqué:

  • Servidores: 10.000, aparentemente todo máquinas virtuales y no se menciona que haya infraestructura en centro de datos propio.
  • Equipo: 300 personas en mantenimiento de la infraestructura y 7.000 desarrolladores. Dividido en equipos de comunicaciones, creación y mejora de la propia infraestructura, operación de la infraestructura.
  • Nubes empleadas: emplean AWS y GCE para evitar dependencias, realizan movimiento de infraestructura de una a otra aunque determinados servicios está atados a una de ellas.
  • Machine Learning para optimización de la infraestructura: han empleado machine learning para diagnosticos de la infraestructura, si proyectan crecimientos, dónde optimizar, etc. Coinciden con Pelado Nerd que un acercamiento menos ambicioso es más efectivo. Hay herramientas de machine learning en el mercado que ofrecen ahorros como resultados de sus diagnósticos y el coste de la herramienta es superior al ahorro que propone.
  • Infraestructura para pruebas: las pruebas de desarrollo se realizan automatizadamente (CI / CD vía Git, sin necesidad del equipo de infraestructura) en una infraestructura que se despliega a propósito para cada prueba sin afectar al resto de los entornos, cuando finaliza la prueba se destruye.
  • Modelos de despliegue: “blue-green” es empleado mayoritariamente, en ocasiones “rolling