Por que fallan las aplicaciones de KDE4 al usar solo su

Los usuarios a veces se sorprenden por el nuevo comportamiento de las aplicaciones de KDE4.

Como no se trabaja normalmente en modo administrador, a
menudo hay que abrir la consola y con el comando “su” cambiar a usuario root.

En primer lugar, hay que señalar que “su” suple a un usuario , pero no al administrador.

"su" permite el paso a cualquier usuario y no sólo al usuario root.

Si no se especifica el usuario, entonces se entiende que se refiere al usuario root.
Esto es lógico, porque en los sistemas Unix/Linux,
sólo hay un usuario que siempre existe y con el mismo nombre: root.

Aclarado este punto, hay dos formas de cambiar a otro usuario:
la ligera y la pesada.
Vamos a explicar las diferencias entre una y otra:

- La ligera sólo requiere utilizar "su". Esto cambiará de usuario,
pero no se actualizarán todas las variables de entorno asociadas al nuevo usuario y, en particular,
los valores de muchas de las variables de entorno se heredarán del anterior usuario.

Otro aspecto interesante es que no se sale del directorio en el que uno se encuentra.
Aquí pongo un ejemplo, pasando de usuario administrador a usuario invitado:

[admin@info1 ~]$ whoami
admin

[admin@info1 ~]$ pwd
/home/techmodis/admin

[admin@info1 ~]$ env | grep -E 'BUS|USER'
KONSOLE_DBUS_SERVICE=:1.48
USER=admin
KONSOLE_DBUS_SESSION=/Sessions/4
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-FWmPVm44Lx,guid=7e2ee933b5ed99e499368d4d4a28f64b

[admin@info1 ~]$ su invite
Password:

[invite@info1 admin]$ pwd
/home/techmodis/admin

[invite@info1 admin]$ env | grep -E 'BUS|USER'
KONSOLE_DBUS_SERVICE=:1.48
USER=invite
KONSOLE_DBUS_SESSION=/Sessions/4
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-FWmPVm44Lx,guid=7e2ee933b5ed99e499368d4d4a28f64b

[invite@info1 admin]$ whoami
invite

Como habrá notado, todavía estoy en el directorio
/home/techmodis/admin, incluso después de haber cambiado al usuario "invite".
Prestemos atención a la variable de entorno
$DBUS_SESSION_BUS_ADDRESS.

Si esta variable no está definida, entonces se iniciará una nueva.

Pero si ya estuviera definida, entonces se intentará conectar con el servidor
DBUS y fallará si no se puede.

Como normalmente un usuario no puede conectarse a la sesión DBUS de otro usuario,
es fácil ver que si una aplicación lanzada desde el usuario "invite" intenta
conectarse a la sesión DBUS del usuario administrador, fallará
(véase la página man de dbus-launch para más detalles).

Si por ejemplo el usuario "invite" intenta lanzar dolphin,
fallará porque no podrá conectarse al DBUS, puesto que no tiene
permisos para conectarse al servidor DBUS del usuario administrador.

[invite@info1 admin]$ dolphin
(1985)/: KUniqueApplication: Cannot find the D-Bus session server:  "Did not receive
 a reply. Possible causes include: the remote application did not send a reply, the message bus security policy
 blocked the reply, the reply timeout expired, or the network connection was broken."

(1984)/: KUniqueApplication: Pipe closed unexpectedly.

- La forma pesada: para usar el método pesado, simplemente agregue un guión a su.
De este modo, hará que su cargue todas las variables de entorno del nuevo usuario.
Por ejemplo:

[admin@info1 ~]$ whoami
admin

[admin@info1 ~]$ pwd
/home/techmodis/admin

[admin@info1 ~]$ su - invite
Password:

[invite@info1 ~]$ pwd
/home/techmodis/invite

[invite@info1 ~]$ env | grep -E 'BUS|USER'
USER=invite

[invite@info1 ~]$ whoami
invite

Como se puede ver, cuando se cambia a otro usuario, el nuevo
directorio de trabajo será el directorio home del nuevo usuario.
Observemos que la variable $DBUS_SESSION_BUS_ADDRESS no está definida.

Esto implica que cuando una aplicación intente conectarse al DBUS,
se iniciará una nueva sesión DBUS. En esta ocasión, Dolphin si se lanzará con éxito:

[invite@info1 ~]$ dolphin
dolphin(2499)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: Available methods:  ("Stat", "FAM", 
INotify")
dolphin(2499)/kio (KDirWatch) KDirWatchPrivate::addEntry: Added File "/home/techmodis/invite/.local/share
//user-places.xbel" for "" ["KDirWatch-1"]
dolphin(2499)/kio (bookmarks) KBookmarkManager::KBookmarkManager: starting KDirWatch for  "/home
/techmodis/invite/.local/share//user-places.xbel"
dolphin(2499)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from  "/var/tmp
/kdecache-invite/ksycoca4"
dolphin(2499)/kio (KDirListerCache) KDirListerCache::listDir: Listing directory: KUrl("trash:/")
"/usr/bin/dolphin(2499)" Error in thread 3048703696 : "org.freedesktop.DBus.Error.ServiceUnknown - The 
name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
"/usr/bin/dolphin(2499)" Error in thread 3048703696 : "QLocalSocket::connectToServer: Invalid name"
dolphin(2499) ::GlobalModelContainer::init: Failed to connect to Nepomuk server via local socket 
"/home/techmodis/invite/.kde4/share/apps/nepomuk/socket"
dolphin(2499)/kio (KDirListerCache) KDirListerCache::listDir: Reloading directory: KUrl("file:///home/techmodis/invite")
....

Esto explica por qué no se puede ejecutar una aplicación de KDE utilizando solo "su".
Del manual de dbus-launch, aparentemente la unica forma de resolver esto es añadiendo
al final de la variable la palabra autolaunch: Incluso se puede incluir autolaunch en
la dirección explicita de una sesión bus en caso de fallo,
por ejemplo DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:"
- en este caso si la primera dirección no funciona, se ejecutara el proceso automáticamente.
(La dirección de la variable bus contiene una lista separada por comas, de direcciones a intentar.).

Así que si conoce la aplicación o script que fija el valor de $DBUS_SESSION_BUS_ADDRESS,
puede modificarlo(a) para anexarle autolaunch al final.

Espero que esto les permita entender por qué necesitan hacer algunos pasos extra
para ejecutar las aplicaciones de KDE4. El comportamiento de su es normal
y existe desde hace años en los diferentes sistemas Unix. Para mayor información,
por favor consulte el manual.

Traducido de este articulo de Linux Wizard por miembros de MdkTrans