openSUSE y su misterioso problema del VNC

Cada distribución es un mundo aparte, cada una viene con sus luces y sombras, y en este caso openSUSE tampoco es la excepción.

Como ya adelanté en el título, este artículo tratará acerca de un misterioso problema en el servicio VNC, y el tedioso proceso que se tuvo que seguir para primeramente poder identificar la causa del inconveniente y finalmente realizar los ajustes necesarios para solucionar el problema de la mejor forma posible, como siempre.

La forma más sencilla y rápida de configurar un servicio VNC en openSUSE es mediante su asistente Yast, que no hace otra cosa que configurar el servicio xinetd para servir sesiones VNC mediante la aplicación Xvnc. En resumen, configurar VNC es tan sencillo como abrir Yast, dirigirnos a la sección Servicios de Red, hacer clic en la opción Administración remota (VNC) y dejar configurada la ventana desplegada como se muestra en la siguiente captura:


Si bien la configuración anterior en muchos casos funciona de buenas a primera, a veces ocurren cosas misteriosas. El extraño problema del que les hablo es que al intentar abrir la sesión VNC configurada desde otro equipo con una aplicación cliente cualquiera, la sesión automáticamente se cerraba sin dejar mayor información al respecto.

No es la primera vez que me sucedía algo así, yo recordaba haber tenido casos similares con versiones anteriores de openSUSE, pero que por las circunstancias de aquellos momentos no las pude dar el seguimiento y la documentación correspondiente, algo que esta vez no iba a dejar pasar.

Con la esperanza de encontrar ciertos indicios del problema, mi primera acción fue consultar el archivo log del servicio xinetd, donde salió lo siguiente:
testsrv:~ # tail -f /var/log/xinetd.log
13/4/20@09:46:35: START: vnc1 from=192.168.100.18
13/4/20@09:46:36: EXIT: vnc1 status=0 duration=1(sec)
Como se puede observar, la información proveída por dicho archivo no ayudaba en absoluto para aclarar el panorama, ya que solo indicaba que al poco tiempo de haber sido establecida la conexión, ésta automáticamente se desconectaba sin propiciar información del porqué.

Luego de trastear lo suficiente pude dar con una solución al problema un tanto curiosa, que consistía en modificar el nombre del host en el archivos /etc/hosts, ¿extraño verdad? si, lo es. El tema es que en mi caso de prueba el nombre del equipo asociado a la direcciones IP era un Fully Qualified Domain Name (o por su acrónimo FQDN, que será utilizado de aquí en adelante) seguido de su alias, o sea, al revisar el archivo /etc/hosts del equipo en el cual se encontraba corriendo el servicio VNC se podía observar lo siguiente:
127.0.0.1       localhost
# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback
fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
127.0.0.1       testsrv.testnet.local testsrv
192.168.xxx.xxx testsrv.testnet.local testsrv
Si han tenido el problema y probablemente hayan buscado una solución en Internet, en varios lugares quizás habrán visto que recomiendan comentar la línea ::1 localhost ipv6-localhost ipv6-loopback, esto yo ya lo había intentado, porque como les había comentado más arriba en un pasado tuve un problema similar con el VNC en versiones más antiguas de openSUSE, y según creo en algunos casos lo había solucionado de esa forma, que sin embargo en esta ocasión no funcionaba.

La forma bizarra en la que pude hacer funcionar el VNC fue intercambiando el orden entre el hostname FQDN con el alias, o lo que es lo mismo, dejar todo como sigue:
127.0.0.1       localhost
# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback
fe00::0         ipv6-localnet
ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts
127.0.0.1       testsrv testsrv.testnet.local
192.168.xxx.xxx testsrv testsrv.testnet.local
Pero intercambiar el orden del hostname y el alias de forma automática no es algo sencillo, ya que el orden está pre-establecido en el asistente de instalación y configuración Yast que registra dicha información (esto lo pueden verificar en el código del módulo /usr/share/YaST2/modules/Host.ycp). Obviamente el problema del VNC no era por culpa de Yast y el orden que aplica al instalar el sistema operativo, así que solucionar el problema modificando en código del asistente es una solución cuanto menos estúpida.

Siguiendo con la búsqueda pude observar otra pista que me sirvió para acercarme un poco más al objetivo. Revisando el archivo log messages del directorio /var/log pude constatar de que el causante del cierre de la conexión VNC era el KDM (KDE Display Manager):
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of section [General] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of section [Xdmcp] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of section [X-*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of section [X-*-Greeter] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of key 'UseTheme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of key 'Theme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of section [X-:*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Apr 20 10:36:59 test kdm_config[30568]: Multiple occurrences of section [X-:0-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Apr 20 10:36:59 test kdm_greet[30573]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: No existe el fichero o el directorio
Apr 20 10:37:02 test kdm: localhost:1[30572]: Abnormal termination of greeter for display localhost:1, code 1, signal 0
Finalmente, después de mucha investigación, recopilación de información, lamentos, decepciones y demás pude dar con la "gratificante" solución al problema gracias al siguiente reporte de bug que merece un premio.

En el reporte, el autor pudo solucionar el inconveniente editando el archivo de configuración del servicio vnc de xinetd:
testsrv:~ # vi /etc/xinetd.d/vnc
Dentro de la sección de configuración de la sesión vnc en cuestión modificar el valor de la directiva user de nobody a root:
user = root
Y por último reiniciar el servicio xinetd para que los cambios puedan tomar efecto inmediato.
testsrv:~ # systemctl restart xinetd.service
Sobre esta configuración quiero dejar algo en claro, solamente KDM será desplegado con los permisos de este usuario, cuando el cliente remoto seleccione un usuario de KDE se accederá al escritorio de ese usuario con sus propios permisos.

Como nota anexa quiero agregar que a partir de la versión openSUSE 12.3 también es necesario agregar el argumento -SecurityTypes None a la directiva server_args para que despliegue la opción de logueo mediante KDM (soy usuario de KDE).
OBSERVACIÓN: El autor no se hace responsable por cualquier eventualidad que pueda presentarse a causa del contenido de este artículo.
La configuración final de la sesión (en este caso vnc1) ha quedado similar a lo siguiente, donde las líneas resaltadas son las que han sufrido los ajustes.
service vnc1
{
        type            = UNLISTED
        port            = 5901
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/bin/Xvnc
        server_args     = -noreset -inetd -once -query localhost -geometry 1024x768 -depth 32 -SecurityTypes None
}
Al final y para alegría mía, todo ha funcionado correctamente luego de aplicar los cambios sugeridos. Sin embargo, es probable que usar el usuario root para lanzar el servicio VNC pueda representar una debilidad en la seguridad de nuestros entornos, así que debemos tener mucho cuidado donde implementarlo y en qué casos.


Conclusión y nota final

Deduzco que el problema original se encuentra en que el usuario nobody no tiene los permisos adecuados para resolver algunos procedimientos requeridos por la aplicación KDM, entre ellos probablemente la correcta interpretación del nombre FQDN presente en el archivo /etc/hosts, lo que en definitiva obligaba al servicio a cerrar la sesión debido a dichas carencias. Aun así, esto lo menciono según mi parecer y sin tener la certeza plena, así que espero el comentario de cualquiera que tenga un conocimiento más profundo del tema.

Solo para finalizar quisiera expresar el motivo del porqué redacté este artículo, la falta de información en Internet ha ocasionado que haya invertido demasiado tiempo para encontrar una solución más o menos válida que me convenciera, demasiado tiempo que no debería ser derrochado por nadie más ya que estas situaciones nos desconcentran y nos desvían de nuestras actividades normales y prioritarias.


Entorno de pruebas

  • openSUSE 12.3
  • KDE 4.10


Fuentes y enlaces relacionados

Comentarios

  1. Me aparece una pantalla negra. A que se debe este problema?

    ResponderEliminar
  2. Hice todas la configuraciones sugeridas pero al momento de reiniciar y entrar me despliega una "black screen" y no se visualiza nada excepto el cursor en forma de X

    ResponderEliminar
    Respuestas
    1. Hola Herber, que versión de openSUSE estás utilizando? ya has probado comentar las lineas relacionadas a IPv6 en el archivo /etc/hosts? quizás con eso podría llegar a funcionar..

      Saludos.

      Eliminar
  3. Hola que tal, Es la 12.3. Desde Yast inabilité el IPv6 settings. Ya se puede accesar por web desde el puerto 5801. Por VNC desde windows no quizás porque hay que reiniciar el servidor. Debido a que hay una gran cantidad de usuarios (176) que estan trabajando de 8:00AM hasta 6:00PM no puedo hacerlo sino hasta despues de fin de turno. Te comento del resultado mañana. Sin embargo ya me has ayudado mucho porque por web ya puedo entrar y con eso es mas que suficiente.
    Saludos y gracias por el aporte

    ResponderEliminar
    Respuestas
    1. Genial, espero que termine por funcionar el acceso mediante el puerto 5901.. Saludos!

      Eliminar
  4. Si quedó Gabriel. Una vez mas gracias...

    ResponderEliminar
  5. Buenas Gabriel. Lo primero darte las gracias por tu artículo porque me ha sacado de la desesperación de buscar entre un mar de "supuestas" soluciones a este problema.

    He solucionado el problema que tenías tú y que tenía yo, comentando las líneas de IPV6 y cambiando al usuario root como indicas.

    Lo que me parece increíble es que después de dos años de escribir tu artículo y en un opensuse 13.2 recién instalado y actualizado, este problema no esté resuelto.
    Estas cosas son las que facilitan mucho la vida a Microsoft :-(

    ResponderEliminar
    Respuestas
    1. Hola DMYS, gracias por tu comentario, la verdad es sorprendente pero sinceramente yo tampoco reporté este problema como un bug en openSUSE cuando lo debería haber hecho, así quizás hoy estaría solucionado.

      Te voy a ser sincero, a mi siempre me gustó la filosofía del software opensource, el kernel Linux y obviamente mi distro favorita openSUSE, que la comencé a utilizar constantemente desde la versión 10.0 hasta la 12.3 en mis equipos. Sin embargo, el tiempo pasó y las ganas de ver algún día una distro Linux que compita con Windows a nivel de estaciones de trabajo ha desaparecido.

      Y es que para mí las distros tradicionales no han cambiado su enfoque, hay demasiadas opciones y cada una sigue sus propios caprichos, demasiada fragmentación y experiencias de usuario muy dispares entre distribuciones, inclusive entre distintas versiones de la misma distribución. Además los sistemas operativos de escritorio, y principalmente las distribuciones Linux en general han perdido su popularidad en los medios y ya no se habla más tanto de ellos como hace unos años atrás, actualmente ese espacio lo ocupan los sistemas operativos móviles.

      Hoy en día soy pragmático, uso el sistema operativo que se ajuste a lo que necesito y se acabó.

      Saludos!

      Eliminar
  6. Gracias Gabriel por tu comentario sobre VNC. Me fue muy util.

    ResponderEliminar
  7. tengo un problema con escritorio compartido ya que a configurar el escritorio con el puerto 5904 y despues ingreso para ver que esta haciendo el usuario se cierra solo. es con opensuse 10. gracias

    ResponderEliminar
    Respuestas
    1. Hola anónimo, puerto 5904? para ver que está haciendo el usuario que usa el equipo deberías utilizar alguna herramienta tipo x11vnc, porque el vnc de este artículo o el que se configura por yast2 te muestra una sesión totalmente nueva e independiente. Saludos.

      Eliminar

Publicar un comentario

Entradas populares