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.

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

Cambio en la distro preferida

Ubuntu ha sido la distribución de entrada para una gran número de usuarios de GNU/Linux para sus escritorios. Mi caso es otro porque comencé a utilizar Linux antes de que apareciera. Ha hecho mucho por facilitar el acceso y sus grandes valores han sido la combinación de estabilidad de Debian con una adopción temprana de actualizaciones.

He oido recientemente en tres canales distintos (solo puedo citar dos; The Linux Experiment y el famoso podcast The Linux Unplugged cap. 454) la misma argumentación a favor de Fedora. Ha sido la primera en ofrecer Gnome 41, y será la primera en Fedora 36 en ofrecer Gnome 42, que es una revisión importante de escritorio con novedades relevantes. La confiabilidad de las actualizaciones de software y de versión de distribución también son valoradas. Añado a eso que, en mi opinión, Fedora como Ubuntu cuenta con el respaldo de una empresa que apoya su desarrollo.

El apoyo de Red Hat a Fedora se ve enmarcado en el movimiento de considerar CentOS como una versión rolling release (que ellos llaman Stream) de lo que acabará siendo RHEL. Acentúa que Fedora quede como la versión orientad al software más reciente. Recordemos que aunque menos popular también dispone de una versión Fedora Server.

Ubuntu en Cloud es una versión ampliamente elegida, esto no ocurre con Fedora obviamente, ni con RHEL porque quien requiere RHEL en servicios cloud o suele elegir un clon (antes CentOS, ahora RockyLinux o Alma), o despliega (y orquesta) con OpenShift su infraestructura en una nube híbrida.

Cambios en CentOS

Los cambios de Red Hat en CentOS han causado una oleada de opiniones, mayoritariamente en contra. El argumento más frecuente es que Red Hat ha matado CentOS.Ha matado Red Hat a CentOS

¿Ha matado Red Hat a CentOS?

Sí, tal y como la conocíamos, y no pasa nada, ahora veremos por qué. Eso, curiosamente, no contradice el mensaje que se publicó hace años cuando entró en el proyecto.

Red Hat declaró que entraba para que la comunidad participase más en el desarrollo de RHEL. Lo que no dijo y era público, aunque no publicitado, era que el proyecto había tenido algún problema por dependencia de una sola persona. Se evidenció cuando se ausentó una semana y nadie atendía servidores, dominios, cuentas de ingreso de dinero, etc y algunos desarrolladores hicieron público el asunto.

¿Por qué no pasa nada?

Si para tí CentOS era fundamentalmente un clon gratuito de RHEL recordemos que CentOS no era la única (por ejemplo, Scientific Linux, Oracle Unbreakable Linux, ClearOS) y a consecuencia del cambio de rumbo de RH en CentOS aparecen nuevas. Por ejemplo:

En qué se convierte CentOS

El cambio en CentOS cumple lo que dijo RH al hacerse cargo de la distribución: abrir el desarrollo de RHEL y que la comunidad participe.

El núcleo del cambio: CentOS deja de ser un clon de RHEL para convertirse en la antesala de la versión estable de RHEL; CentOS Stream.

¿Y qué puede ocurrir ahora?

Hay un escenario prioritario a considerar; la base instalada de CentOS para tener un clon de RHEL sin pagar subcripción y renunciando a soporte.

Estos servidores disponen de varias alternativas;

  • migrar Ubuntu: me parece menos probable por que es un cambio de infraestructura considerable
  • migrar a otro clon de RHEL: me parece el escenario más probable porque plantea menos riesgo en la transición y no hay curva de aprendizaje en los administradores, ni adaptaciones, ni testing para verificar que todo funciona.
  • utilizar CentOS Stream: aún sin soporte y sabiendo que es una versión en desarrollo. Me parece un escenario improbable para máquinas en producción, para el resto podría ser.
  • utilizar versiones de RHEL sin soporte: RH tiene un plan aún no publicado para facilitar el acceso a RHEL sin soporte y por coste (casi) cero. Esas versiones serán realmente a coste cero si las descargas en calidad de desarrollador. Si se descargan para que administrador pruebe o toque, es probable que previamente debas ser cliente, todo esto está muy pendiente de que RH cierre en qué consistirá ese plan para facilitarl el acceso a RHEL.

¿Qué distribución saldrá beneficiada?

En el momento de escribir esto diria que la iniciativa de CloudLinux, el proyecto Lenix por que ofrecen una transición transparente de CentOS a Lenix, porque continua garantizando compatibilidad binaria con RHEL, porque -aparentemente- CloudLinux tienen recursos y experiencia para el proyecto.

Oracle puede aprovechar esta oportunidad para ofertar Unbreakable Linux en clientes empresariales y sustituir máquinas CentOS por su distribución a coste menor que RH, sobre todo si se emplean para BDs y/o cluster.

Otras candidatas son RockyLinux, de momento una promesa y con antecedentes de desaparición del líder del proyecto cuando estaba al frente de CentOS y las que existían como Scientific Linux entre otras.

¿Cómo obtener información básica de red con nmcli?

¿Cómo obtener información básica de red con nmcli en GNU/Linux?

El post pretende ser un recordatorio para mi mismo y un acicate para profundizar en nmcli, un desconocido para mi, que me ha parecido más amigable que el nuevo ip.

A modo de ejemplo, listo las conexiones activas con el comando en negrita:


user@machine:~$ nmcli connection show
NAME UUID TYPE DEVICE
MIWIFI_2G_nnGQ 43ce5cc0-6ecc-4fca-997b-ccdcb12ca2ff wifi
wlx74da38e4733c

virbr0 a756e70d-7f44-4bc6-8ce7-a3d1265cee1f bridge virbr0
Conexión cableada 1 3df083b6-e2d3-35b6-a55d-d1c540443eca ethernet

¿Cómo sé a qué velocidad se conecta la WiFi? nmcli ofrece un parámetro para saber los campos (-f para fields en inglés) de las conexiones a las que el sistema puede acceder.

user@machine:~$ nmcli -f WIFI-PROPERTIES dev show wlx74da38e4733c
WIFI-PROPERTIES.WEP: sí
WIFI-PROPERTIES.WPA: sí
WIFI-PROPERTIES.WPA2: sí
WIFI-PROPERTIES.TKIP: sí
WIFI-PROPERTIES.CCMP: sí
WIFI-PROPERTIES.AP: sí
WIFI-PROPERTIES.ADHOC: sí
WIFI-PROPERTIES.2GHZ: sí
WIFI-PROPERTIES.5GHZ: no
WIFI-PROPERTIES.MESH: sí
WIFI-PROPERTIES.IBSS-RSN: sí

Para quedarnos con ganas de explorar más las opciones de nmcli podemos listar la conexión concreta que nuestro equipo utilizaba y filtrar información sobre IPv4. Nos permite ver la ip de la conexión, la del router, los DNS que utiliza, etc.

user@machine:~$ nmcli connection show "MIWIFI_2G_nnGQ" | grep ^IP4
IP4.ADDRESS[1]: 192.168.1.142/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 600
IP4.ROUTE[2]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.ROUTE[3]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 600
IP4.DNS[1]: 212.230.135.2
IP4.DNS[2]: 212.230.135.1
IP4.DOMAIN[1]: home