Fedora 28. Problemas asociados a sudo (o no?) y otras menudencias

Como ya habíamos mencionado en la entrada anterior, Fedora 28 Workstation Live instala un Linux sin usuario administrador. Eso solo me ha pasado con uno de mis ordenadores, al que cambié el SSD del sistema por necesidades de espacio —esta es otra historia que si tenemos tiempo contaremos algún día— y lo instalé de nuevo desde un Fedora 28 Live. Lo primero que hice tras la sorpresa fue crear un usuario root desde sudo. Sin embargo, esta situación genera un problema; todo lo que realizábamos como root ahora tiene que hacerse desde sudo (configurar cortafuegos, llamar a aplicaciones de sistema...). Pero además me encontré con dos problemas nuevos:
1. Amule tomaba el control de sistema hasta su congelación completa. Este problema se soluciona poniendo emule por wine (véase aquí), pero solo fue necesario una semana, por que era un "bug" de amule que ya ha sido controlado en su última actualización. Pero este era el menor de los problemas...
2. Este segundo problema era doble. Si lanzaba nautilus (ahora denominado "Gnome Files" o Gnome Archivos) tardaba horas en aparecer de forma gráfica, lo que me obligó a instalar Thunar para poder trabajar de forma gráfica. Curiosamente, si lo lanzaba desde root aparecía inmediatamente, pero no debemos trabajar como administrador con nautilus. Pero aún hay más; tanto con nautilus (al día siguiente de haberlo lanzado) o con thunar, al copiar cualquier bloque mayor de 1 GB, cuando llevaba unos segundos copiando, se congelaba el sistema de manera completa, sin respuesta a Alt+F2, Ctrl+Alt+Fx ni a las teclas mágicas REISUB, lo que obligaba a reiniciarlo por las "malas" (y la pérdida de ficheros de los discos duros que se estaban copiando en ese momento). Este segundo problema me ha tenido preocupado hasta esta semana, por que en pleno fin de curso el trabajo aprieta y no podemos arriesgarnos a que una instalación no salga a la primera. Esta situación se ha encontrado en muy pocas ocasiones con diferentes causas:
- Tarjetas Nvidia. No es el caso, por que este ordenador lleva un i7 3770 con HD4000 integrada y nunca he tenido problemas gráficos.
- Errores asociados a Nautilus (véase bug 1208993 o bug 1133477). Parece que nautilus llena la memoria del sistema antes de enviarlo a la copia física al dispositivo destino y el sistema se congela. En algunos de estos casos recomiendan controlar el máximo de memoria que puede ocupar estas "dirty pages" en /etc/sysctl.d/90-override.conf (o el fichero de configuración inicial que use cada uno) mediante
vm.dirty_background_ratio = 5 # Memoria total que se puede llenar hasta copiar en el dispositivo destino
vm.dirty_ratio = 10 # Memoria total que se puede llenar con las "páginas sucias"
En mi caso he intentado superar el problema dando diferentes valores (5-10, 10-20, 20-40... a esta configuración sin resultado (si se quiere mirar algo más sobre esto, mirar aquí).
Ahora que he podido reinstalar el sistema de nuevo, en este caso desde el formato netinst, con root como siempre y sin abrir sudo a nadie, todo funciona correctamente.

Como todo lo demás es igual, ¿quién era el culpable? Así que no nos interesa sudo. Si fuera así instalaríamos Ubuntu, y no es el caso.

Y aquí tenemos a sudo, sin haberlo pedido

Así es; en Fedora 28 Workstation tenemos sudo sí o sí. En Fedora magazine tenemos la noticia. La cosa queda más o menos en "In the end they opted for just always skipping the user and root configuration screens in Anaconda and just configuring a user with sudo rights in Gnome Initial Setup."
Es decir, cuando instalamos de manera limpia la version Fedora 28 Workstation Live no aparece la indicación de palabra de administrador; además, el usuario se configura después. En resumen, vivimos en el mundo de sudo, ni blanco ni negro, gris. Desde mi punto de vista:
1. ¿Para que quiero sudo si puedo ejecutar como administrador lo que necesito?
2. ¿Desde cuando un usuario puede pensar que puede hacerlo todo? De ahí a acabar como Windows diciendo Sí a cualquier tontería falta un paso muy pequeño.
3. ¿Y si sudo trae errores de seguridad en su código? Otro posible agujero de seguridad.
Y lo peor de todo es que si lo instalamos así no existe administrador. Después de años de ejecutar bajo el paraguas del administrador toda modificación del sistema, ahora lo tiene que hacer todo el usuario. Ejemplo, de repente me veo configurando el cortafuegos como usuario; me entró una angustia existencial...
No, no me gusta; lo evitaré todo lo que pueda.

Estoy seguro que con sudo el sandwich es de brocoli.

Mientras tanto, instalación desde formato netinst, con administrador incluido. Además, en mi caso sudo es el principal sospechoso de problemas mucho más importantes. Lo veremos en una próxima entrada.

Wayland: como ejecutar aplicaciones gráficas con permisos de administrador

La actualización a Fedora 27 no ha "solucionado" el problema de la ejecución de aplicaciones gráficas como administrador, como ya hemos visto con gparted. Sin embargo, esta vez ha sido por bleachbit.

Como se afirma en la página de información de los bugs de Fedora, no es un error ("This is not exactly a bug, but an intentional design [...] to make Wayland safer than X"). Esto nos deja tres opciones:

1. Edición de ficheros de configuración: podemos usar nano sin más, pero para los que quieran editores gráficos, por ejemplo gedit, podemos recurrir al protocolo admin:///

gedit admin:///etc/fichero.conf

Este protocolo se puede utilizar en las aplicaciones que utilicen la capa de acceso GTK+ Gvfs.

2. Para aplicaciones que no son nativas de Wayland, podemos sortear el problema ejecutando en un terminal el comando

xhost +si:localuser:root

como usuario (como ya habíamos utilizado para ejecutar gparted); no sirve para las aplicaciones que se lanzan a través de xWayland.

3. Ajo y agua y arrancar en x11.

Debemos esperar para ver como va evolucionando Wayland.

gparted Gtk-WARNING: cannot open display - root y xhost

No es la primera vez que me pasa esto; instalación de sistema, llamar a gparted y se obtiene un mensaje de

Gtk-WARNING **: cannot open display

Esto se debe a que gparted requiere privilegios de administrador para poder usarse

Root privileges are required for running gparted

y que es una máscara GRÁFICA. El administrador solicita la apertura de un nuevo sistema gráfico y ya está en posesión del usuario. En general muchas páginas recomiendan una orden como

xhost +

pero esto genera un problema de seguridad, ya que se abre el sistema gráfico a cualquiera (véase por ejemplo aquí). Es además matar moscas a cañonazos, ya que si lo único que necesitamos es que el administrador local tenga acceso al sistema gráfico, ¿por qué añadimos todos? Así que creo que es más lógico añadir al administrador local

xhost local:root

y listo. gparted en marcha