10 - sistema de ventanas x

Sistema de Ventanas X

1

Capítulo 1 Sistema de Ventanas X

Conceptos clave

• El entorno gráfico de Red Hat Enterprise Linux está sujeto a un proceso de espacio de usuario llamado servidor X.

• El servidor X proporciona acceso de bajo nivel a dispositivos de entrada tales como, el teclado o el ratón y dispositivos de salida tales como, una tarjeta de vídeo y un monitor.

• Los clientes X hacen solicitudes a servidores X mediante el protocolo X11, refiriéndose a la variable de entorno DISPLAY para la identidad del servidor X.

• Los gestores de ventana, una clase especial de cliente X que contiene otros clientes X, permiten mover, dimensionar y utilizar iconos. El gestor de ventana por defecto en Red Hat Enterprise Linux es metacity.

• Un entorno de escritorio es un conjunto de aplicaciones que recurren a bibliotecas comunes para proporcionar un "aspecto y sentido" unificados y comunicación entre aplicaciones. El entorno de escritorio predeterminado en Red Hat Enterprise Linux es GNOME.

El entorno gráfico de Linux

Este cuaderno presentará, en primer lugar, los diversos elementos que componen el entorno gráfico y la manera como se interrelacionan las capas conceptuales. Luego, se centrará en el paso que suele ser más delicado: la configuración de bajo nivel del servidor X. Más tarde, se introducirán dos técnicas para iniciar un servidor X y personalizar estas dos rutas de arranque. Por último, se hablará de la relación del servidor X con la red y de la forma como esta relación se puede utilizar de forma segura para tener acceso a las aplicaciones gráficas en máquinas remotas.

Es importante apreciar que en muchos casos, el entorno gráfico se considera solamente una característica, si no una complicación indeseada. Unix comenzó como un servidor de terminal, con terminales sencillas conectadas a través de cables seriales. El siguiente salto de Unix ocurrió en la red, donde muchos de los protocolos de núcleo que hoy en día sujetan la Internet se nutren, tales como TCP/IP, DNS, SMTP y otros. Desde su diseño inicial y aún hoy en día, el sistema operativo UNIX y Linux se considera completo y robusto como un servidor de archivos en el armario, o como servidor Web en un estante, sin haber nunca utilizado una tarjeta de vídeo en otra cosa que en modo de texto.

No obstante, Unix desarrolló un entorno gráfico avanzado centrado en el servidor X. Los sistemas modernos de Linux se concentran en el sistema de escritorio y en el rápido desarrollo hacia la meta de una terminal gráfica potente pero manejable.

El servidor X


2

El servidor X proporciona el núcleo gráfico del sistema de Red Hat Enterprise Linux. El servidor X representa dos opciones de diseño no evidentes sobre cómo implementar gráficos en sistemas Unix que ellos mismos han demostrado con el tiempo.

El proceso X

En primer lugar, el soporte para gráficos se presenta en el espacio de usuario, no en el kernel. Por diseño, el kernel de Linux suele acceder únicamente a tarjetas de vídeo en modo de texto, dejando el soporte para modo gráfico al servidor X, el cual se ejecuta como un proceso de espacio de usuario (por lo general llamado "X"). Los entornos gráficos son complicados y pueden presentar errores. Sin embargo, si el sistema gráfico se "encierra" en una caja de Linux, el administrador aún puede abrir la shell (a menudo desde una máquina remota a través de la red), rastrear el proceso del servidor X, matarlo ejecutando kill con un SIGKILL letal (número de señal 9). [1] Si el entorno gráfico fuera implementado directamente por el kernel, como en otro sistema operativo moderno conocido, el único recurso del administrador sería reiniciar la máquina. [2]

Cliente X/Diseño de servidor

En segundo lugar, como el nombre de servidor X lo implica, los gráficos se han dividido en dos hardware independientes "controlador de dispositivo" (el servidor X) y las aplicaciones independientes de hardware (clientes X). El servidor X proporciona acceso a los dispositivos de entrada tradicionales, tales como el teclado y el ratón y a los dispositivos de salida tradicionales, tales como la tarjeta de vídeo y el monitor. No obstante, el servidor X no hace nada interesante con estos dos dispositivos.

En su lugar, otras aplicaciones (conocidas como clientes X) hacen solicitudes al servidor X, tales como "pinte un óvalo blanco aquí", o "escriba aquí el texto [root@station root] # en este tipo de letra". Los clientes X también solicitan al servidor X transmitir información sobre presión de teclas en un teclado o movimientos del ratón (dicha información se conoce generalmente como eventos).

Los clientes X se comunican con servidores X mediante el protocolo X11. Como ambos están diseñados para el protocolo, los clientes X pueden hacer solicitudes a los servidores X que se estén ejecutando en una máquina, en máquinas remotas o incluso en otros sistemas operativos.

Números de pantalla y la variable de entorno DISPLAY

Los clientes X pueden hacer solicitudes a cualquiera de los múltiples servidores X ejecutándose en una sola máquina o incluso, ejecutándose en máquinas remotas. Un cliente X particular determina qué servidor X debe contactar al examinar su variable de entorno DISPLAY.


3

La variable de entorno DISPLAY utiliza convencionalmente la siguiente sintaxis, con explicaciones para los componentes hallados en el cuadro a continuación.

DISPLAY=hostname:display_number.screen_number

Table 1. Componentes de la variable de entorno DISPLAY

hostname El host en el cual el servidor X está ejecutándose (localhost por defecto).

display_number

Un número entero que sirve de identidad de una instancia determinada de un servidor X. Si se están ejecutando múltiples servidores X en una sola máquina, cada uno debe tener un número de pantalla. Por defecto, el primer servidor X iniciado tiene un número de pantalla de 0. Todos los otros servidores X tienen un número de pantalla asignado en el arranque.

screen_number

El número entero de pantalla es importante únicamente en los sistemas duales. En un sistema con dos tarjetas de vídeo y dos monitores, cada monitor podría ser un visualizador separado con números de pantalla diferentes o los dos monitores podrían ser dos pantallas del mismo visualizador (mitad izquierda y mitad derecha). Obviamente, el número de pantalla es importante y se predetermina a 0 (la primera pantalla).

El único elemento requerido es el número de pantalla. Por ejemplo, el caso más común es para un cliente que hace solicitudes al único servidor X ejecutándose en la máquina local, en cuyo caso DISPLAY podría apuntar simplemente a :0 (o equivalente a :0.0 como es el caso para gnome-terminal que está ejecutando la siguiente shell).

[root@station root]# echo $DISPLAY :0.0

Aunque la variable de entorno DISPLAY se establece generalmente como parte del proceso de arranque del servidor X se hereda de cliente a cliente sin que se note, en ocasiones es necesario administrarla de modo explícito.

El servidor X xorg

Existen diferentes versiones de servidores X, algunas con marca registrada y otras de código abierto. La versión del servidor X distribuida con Red Hat Linux Enterprise es el servidor "xorg". El proyecto xorg se inició bajo la licencia MIT con objetivos similares a los de la Fundación para el Software Libre (Free Software Foundation): el desarrollo de software de alta calidad con licencia para que el código fuente esté disponible para todos los que lo utilicen. No obstante, el centro del proyecto xorg ha sido el servidor X, como su nombre lo indica.


4

El proyecto xorg mantiene su propia página Web en http://www.xorg.org, un buen recurso de documentación técnica relacionada con el servidor X.

Gestores de Ventanas

Los clientes X son cualquier aplicación que hace solicitudes al servidor X. Por lo general, son responsables de un rectángulo determinado en la pantalla del servidor X, en el que escribirá texto (si es gnome-terminal), o dibujará la cara de un reloj con dos manecillas (si es xclock).

Los gestores de ventana son una clase especial de cliente X que contiene otros clientes X. Tienen todas las propiedades que hacen que el cliente parezca una ventana, por ejemplo, una barra de título, una barra de desplazamiento e iconos que despejan ventanas del escritorio. Observe en las siguientes gráficas que tanto gnome-terminal como xclock tienen delimitadores similares que les permiten cambiar el tamaño, representar con iconos o cerrar.

Figure 1. El cliente X xclock

Figure 2. El cliente X gnome-terminal


5

Todo lo que está "dentro" de la ventana es controlado por un cliente X determinado. No obstante, todo lo que la hace una "ventana" y no solamente una caja, es controlado por el gestor de ventanas.

Tradicionalmente, Linux ha respaldado una amplia variedad de gestores de ventanas, desde el gráficamente avanzado hasta el rápido y sencillo. Red Hat Enterprise Linux se ha estabilizado en metacity, el gestor de ventanas por defecto para el entorno de escritorio de GNOME.

Entornos de escritorio

Un desarrollo bastante reciente dentro de UNIX y LINUX, ha sido el movimiento hacia un "aspecto y sentido" comunes compartido por múltiples aplicaciones. Las aplicaciones extraen la infraestructura de las bibliotecas comunes que componen un entorno de escritorio. Las aplicaciones que utilizan el mismo entorno de escritorio por lo general comparten muchas características comprensibles para el usuario, tales como la presentación, los iconos, y los diálogos). Las similitudes son evidentes en las siguientes dos aplicaciones del mismo entorno de escritorio.

Figure 1. La aplicación GNOME gedit


6

Figure 2. La aplicación GNOME gnome-sound-recorder

Los entornos de escritorio también proporcionan una infraestructura común que no es tan evidente para los usuarios, tales como la aplicación "Arrastrar y soltar", el manejo común de opciones de usuario y las funciones como la entrada "Abrir reciente"en el menú de Aplicaciones compartido por muchos programas.

Linux ha sido testigo de dos desarrollos paralelos de entornos de escritorio: KDE, basado en las bibliotecas Qt y GNOME, basado en las bibliotecas GTK. Red Hat Enterprise Linux tiende a mostrar preferencia por el entorno de escritorio GNOME, aunque ambos entornos son totalmente respaldados. En Red Hat Enterprise Linux, los dos entornos de escritorio se han configurado con un aspecto y sentido comunes, que hacen difícil distinguir el entorno de escritorio subyacente que se está utilizando.

Ejercicios en línea

Lab Exercise Objetivo: Administrar múltiples servidores X

Tiempo estimado: 10 minutos.


7

Specification

Al proseguir con este laboratorio, su consola puede arrancarse de consola a consola ya que los servidores X inician y mueren, lo que puede ser desorientador. Recuerde que en la configuración estándar de Red Hat Enterprise Linux, sus primeras seis consolas contienen consolas virtuales y la séptima, el servidor X "normal". Si se desorienta, la secuencia CONTROL-ALT-F7 lo llevará de vuelta al entorno habitual.

1. Desde el interior de la terminal en su sesión X, inicie un segundo servidor X "vacío" utilizando el primer argumento para asignar al servidor X el número de pantalla: 1 y lleve la tarea a segundo plano. El nuevo servidor X "vacío" debe iniciar en la octava consola.

2. [rhauser@station rhauser]$ X :1 &

Usted verá un servidor X con un cursor sencillo como única retroalimentación.

3. Cambie a una consola virtual e inicie sesión con su primera cuenta alterna. Utilice el comando startx para iniciar un tercer servidor X en su máquina, especificando el número de pantalla: 2. Observe que el argumento debe estar separado del comando startx con doble guión. El tercer servidor X debe iniciar en la novena consola.

4. [rhauser_a@station rhauser_a]$ startx -- :2 &

Observe que el servidor X iniciado con el comando startx comienza con una sesión de GNOME totalmente inicializada, mientras que el servidor X iniciado directamente no tiene clientes.

5. Reuna los ID del proceso de sus tres servidores que se están ejecutando (mediante la combinación de los comandos ps o pidof) y regístrelos en el archivo ~/xpids del directorio de inicio de su cuenta primaria, un ID de proceso por línea.

Resultados

Question 1

1. Tres servidores X ejecutándose con números de pantalla: 0, :1, y :2. 2. El archivo ~/xpids que contiene los ID de proceso de los tres servidores X.

Limpieza

Cuando su laboratorio haya sido calificado, puede matar los segundos dos servidores X (ya sea con un CONTROL-ALT-RETROCESO, o matando los procesos con el comando kill o un CONTROL-C.

Capítulo 2 Configuración del servidor X


8

Conceptos clave

• El servidor X recibe su configuración del archivo /etc/X11/xorg.conf. • El archivo de configuración raras veces se edita a mano, en cambio, se genera

mediante las aplicaciones system-config-keyboard, system-config-mouse y system-config-display.

• El servidor X depende del servidor X de tipo de fuente autónomo para proveer información de tipo de escritura. El demonio xfs es manejado por el script de servicio estándar de Red Hat Enterprise Linux xfs.

Introducción

El primer paso para establecer el entorno gráfico de Red Hat Enterprise Linux es configurar el servidor X. La configuración del servidor X ha sido uno de los aspectos más espinosos de la configuración Linux.

Cualquier componente del sistema operativo que esté muy relacionado con el hardware subyacente es susceptible de problemas generados por variaciones menores de diferentes modelos de hardware. El servidor X no está muy ligado a una parte del hardware, sino a cuatro: el teclado, el ratón, la tarjeta de vídeo y el monitor.

Afortunadamente, la configuración del servidor X es más fácil en los últimos años. Por lo general, Anaconda, el instalador de Red Hat Enterprise Linux, configurará automáticamente un servidor X de trabajo, con el administrador tentado a realizar sólo algunos cambios, si nada. Lo que el instalador no puede realizar, la utilidad system-config-display suele hacerlo.

El objetivo: /etc/X11/xorg.conf

La configuración de un servidor X está casi toda dentro de un sólo archivo de configuración, el cual se almacena en Red Hat Enterprise Linux como /etc/X11/xorg.conf. El objetivo de configurar un servidor X es configurar correctamente este archivo.

A continuación se presenta un archivo de muestra xorg.conf. Algunos de los comentarios largos se han remplazado simplemente por # ..., seguido de una lista de llamadas bastante intimidantes.

[root@station root]# cat /etc/X11/xorg.conf # XFree86 4 configuration created by pyxorgconf Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "DevInputMice" "AlwaysCore" EndSection


9

Section "Files" # ... RgbPath "/usr/X11R6/lib/X11/rgb" FontPath "unix/:7100" EndSection Section "Module" Load "dbe" Load "extmod" Load "fbdevhw" Load "glx" Load "record" Load "freetype" Load "type1" Load "dri" EndSection Section "InputDevice" # ... Identifier "Keyboard0" Driver "keyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/psaux" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "yes" EndSection Section "InputDevice" # If the normal CorePointer mouse is not a USB mouse then # this input device can be used in AlwaysCore mode to let you # also use USB mice at the same time. Identifier "DevInputMice" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "no" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "LCD Panel 1280x1024" HorizSync 31.5 - 67.0 VertRefresh 50.0 - 75.0 Option "dpms" EndSection Section "Device" Identifier "Videocard0"


10

Driver "radeon" VendorName "Videocard vendor" BoardName "ATI Radeon Mobility 7500" EndSection Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 16 Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection Section "DRI" Group 0 Mode 0666 EndSection

La sección de "Diseño de servidor" contiene todas las otras líneas de configuración dentro de un diseño particular. Aunque en la mayoría de las máquinas no se necesita, las máquinas con "dos cabezas" pueden asignar un diseño de servidor distinto a cada monitor. Cuando haya estudiado el resto del archivo, retorne y reexamine esta sección.

La ruta a donde las bases de datos de definición de color se almacenan. Muy pocas veces o quizás nunca deberá preocuparse por esto.

Muchos servidores X manejan sus propias fuentes tipográficas con rutas para base de datos de fuentes que se hallan aquí. En Red Hat Enterprise Linux, las fuentes son manejadas por un proceso de servidor de tipo autónomo llamado xfs del cual hablaremos más adelante.

El servidor X está diseñado por módulos con diferentes características soportadas por diferentes tarjetas de vídeo, monitores, subsistemas de fuentes, etc. Si avanza hasta el servidor X, se hallará especificando o suprimiendo módulos particulares.

La definición de teclado. Los parámetros importantes son "XkbModel", el cual especifica las teclas que hay en el teclado, y "XkbLayout", el cual especifica los símbolos sobre esas teclas.

La configuración del ratón. El "Protocolo" especifica el tipo de ratón. "Z Axis Mapping" asigna a una rueda de ratón un "cuarto " y "quinto" botón. La opción "Emulate3Buttons" permite hacer clic izquierdo y derecho simultáneamente en un ratón de dos botones y se interpreta como pulsar en el centro de un ratón de tres botones

El servidor X siempre tiene una configuración activa para un ratón de USB, incluso si no hay ratón USB en el momento. Así, el servidor X puede responder inmediatamente en el caso de que un ratón de USB tenga que agregarse más tarde al sistema.

Los parámetros importantes para el Monitor son la tasa de sincronización horizontal y la tasa de actualización vertical. La documentación distribuida con cualquier monitor debe publicar estos valores. Para monitores más antiguos, (de los


11

que no se tiene documentación) usted no debe suponer estas tasas, puesto que puede aumentar la frecuencia de reloj y quemar el monitor. Los monitores modernos, especialmente los de múltiple sincronización, tienen circuitos de protección y no están propensos a este problema.

El "Dispositivo" representa la tarjeta de vídeo. Por lo general, sólo se necesita hacer referencia al nombre del vendedor y al nombre de placa, los cuales se hallan en las bases de datos provistas. Algunas tarjetas permiten que las características sean activadas o desactivadas agregando valores personalizados.

La "Pantalla" es la combinación de un "Dispositivo" (tarjeta de vídeo) y un "Monitor" determinados, como también de la profundidad de color y las especificaciones de resolución ("Modos").

No se preocupe. Rara vez o nunca tendrá que editar manualmente este archivo. Sin embargo, vale la pena examinarlo, porque demuestra correctamente los distintos componentes de los que es responsable un servidor X (teclado, ratón, tarjeta de vídeo, monitor y fuentes) y su forma de relacionarse (dispositivos de entrada, pantallas con profundidades de color asociados, resoluciones y diseños de todo el servidor). Para mayor información puede consultar la página de manual xorg.conf(5).

Ahora que el fin está cerca, presentamos herramientas que le ayudarán a lograrlo.

Configuración de teclado: system-config-keyboard

La utilidad de system-config-keyboard permite a los administradores personalizar fácilmente la asignación de teclado asociada con un teclado adjunto. La utilidad se puede ejecutar desde una consola o desde el interior de una sesión X. La versión gráfica del programa se ilustra a continuación.

Figure 1. La aplicación system-config-keyboard


12

La utilidad de system-config-keyboard configura dos sistemas diferentes a la vez. En primer lugar, la utilidad sirve de primer plano para el comando LoadKeys, el cual establece las interpretaciones de mapa de teclado utilizadas por el kernel de Linux para consolas virtuales. La configuración pertinente para ajustar el nivel de kernel se almacena en el archivo /etc/ sysconfig/keyboard.

En segundo lugar, system-config-keyboard sirve de primer plano para la configuración del servidor X y modifica correctamente la sección del teclado del archivo de configuración /etc/X11/xorg.conf.

Como el sistema de archivos de configuración extendida indica, los cambios hechos con esta utilidad se aplican a todo el sistema. Los usuarios individuales pueden personalizar los parámetros de teclado (como el retraso de repetición y la velocidad de repetición para teclas que se presionan continuamente) mediante la utilidad de configuración de teclado del menú de "Preferencias". Además, la pequeña aplicación Selector de diseño de teclado de GNOME puede estar incorporada en el panel de GNOME para permitir a los usuarios cambiar de improviso su asignación de teclado individual.

Configuración de ratón: system-config-mouse

La aplicación system-config-mouse permite a los administradores cambiar fácilmente la configuración del ratón. Esta utilidad se puede ejecutar desde una consola o desde una sesión X, al igual que la aplicación system-config-keyboard.


13

Figure 1. La aplicación system-config-mouse

Al igual que la aplicación del system-config-keyboard, la aplicación system-config-mouse realiza una doble labor. En primer lugar, la configuración elegida se utiliza para configurar gpm, el demonio del ratón asociado con consolas virtuales. (Este demonio se administra con el script de servicio gpm). La información de configuración se almacena en el archivo /etc/sysconfig/mouse. En segundo lugar, la aplicación system-config-mouse aplica las opciones al servidor X y modifica la sección apropiada del archivo /etc/x 11/xorg.conf.

Recuerde que dentro del servidor X, el ratón de USB siempre está definido y activo, para que los usuarios puedan de inmediato utilizar el ratón agregado físicamente al sistema.

Configuración de visualización: system-config-display

Mientras que las dos aplicaciones mencionadas anteriormente se utilizan para configurar dispositivos de entrada del servidor X, el system-config-display configura el dispositivo de salida del servidor X, más conocido como la pantalla.

Figure 1. La aplicación system-config-display


14

Por defecto, la aplicación system-config-display intentará iniciar un servidor X mediante el archivo de configuración existente /etc/X11/xorg.conf, suponiendo que el servidor X ya está configurado, y que el administrador desea hacer cambios sencillos tales como cambiar la resolución del servidor X o la profundidad de color. Si la aplicación no puede iniciar el servidor X utilizando el archivo de configuración o si el archivo de configuración no se encuentra, la aplicación ejecutará la utilidad de configuración desde el interior de un servidor de configuración X de un "mecanismo de seguridad" mínimo.

La aplicación permite a los administradores especificar dos parámetros de nivel inferior: la tarjeta de vídeo y el monitor, y dos valores de nivel superior: la resolución y la profundidad de color. Por lo general, la tarjeta de vídeo se puede reconocer automáticamente y la selección correcta ya se habrá hecho (suponiendo que la tarjeta de vídeo es compatible).

La mayoría de los monitores modernos se pueden examinar y los monitores compatibles serán autoseleccionados por la aplicación. Con la esperanza de que éste sea el caso, system-config-display difiere las especificaciones más fundamentales de tarjeta de vídeo y monitor a la segunda página, confiando que el administrador nunca tenga que ir allí.

Figure 2. Configuración de hardware en system-config-display

Para monitores más antiguos que no se autoexaminan, la segunda página provee una lista de más de 2.000 monitores para elegir. Si un determinado monitor no está listado explícitamente, el administrador podrá escoger de la lista de definiciones de la "Pantalla CRT genérica". Las configuraciones para computadores portátiles y proyectores son más limitadas, por lo tanto, las selección desde la "Pantalla CRT genérica" suele ser más adecuada que las definiciones específicas de vendedor y modelo.

Figure 3. Selección de monitor dentro de system-config-display

Una vez elegida la tarjeta de vídeo y el monitor (ya sea de forma automática o explícita), se pueden seleccionar la resolución y profundidad de color adecuadas. La elección no compatible se inhabilitará, pero la aplicación tiende a ser optimista con lo que deja habilitado. La elección de una resolución no garantiza que usted la obtenga. Si la resolución seleccionada no es compatible, el servidor X suele iniciar en una resolución inferior sin comentario evidente.

Volver a comenzar: system-config-display --reconfig


15

A veces, un archivo de configuración engañoso /etc/X11/xorg será dejado en su lugar por el instalador (Anaconda, por ejemplo). El archivo de configuración es engañoso, porque es "lo suficientemente bueno" para iniciar un servidor X de baja resolución, pero no contiene los ajustes adecuados para el hardware detectado.

En estos casos, system-config-display se puede iniciar con la opción de línea de comando --reconfig. La utilidad de configuración ignorará el archivo de configuración existente y "volverá a comenzar". La configuración resultante suele ser mejor que la que se obtiene con el instalador de Anaconda.

¡Grabe ese archivo!

Como hemos visto, un gran número de máquinas pueden ser instaladas con el servidor de instalación de Red Hat Enterprise Linux y las capacidades de secuencias de comandos del kickstart de Anaconda. No obstante, uno de los puntos más débiles del instalador, es la configuración X. Como mencionamos anteriormente, el instalador casi siempre generará una configuración de trabajo, pero no siempre será la mejor.

El administrador puede pasar el tiempo configurando un archivo /etc/X11/xorg.conf, ya sea con las aplicaciones que acabamos de mencionar o manualmente. Una vez el archivo está correctamente configurado, debe aplicar a todas las máquinas que comparten el mismo hardware. El archivo de configuración se puede almacenar en el servidor de instalación de Red Hat Enterprise Linux e "insertar" en la sección %post de un archivo de configuración de kickstart como el siguiente:

%post curl http://rha-server/pub/ks/xorg.conf > /etc/X11/xorg.conf

Tras el reinicio, la máquina recién instalada recibirá los beneficios de la configuración manual de X.

El servidor X de fuente tipográfica: xfs

Una de las preocupaciones del servidor X es el manejo de fuente. En Red Hat Enterprise Linux, la administración de fuente X se maneja con un demonio autónomo exclusivamente responsable del manejo de fuente, llamado fuente X o xfs. El servidor de fuente X es administrado por el script de servicio xfs y se puede manejar con los comandos estándar service y chkconfig.

Si está utilizando un servidor X, debe primero iniciar el servicio xfs. Si no está ejecutando un servidor X, el servicio xfs se puede inhabilitar. No obstante, si no se ejecuta el servicioxfs cuando se necesita, hará que el servidor X no pueda iniciar mientras se queja sobre la falta de fuentes.



16

Lab Exercise Objetivo: Configurar el servidor X local.


Como este laboratorio requiere reiniciar el servidor X varias veces, se recomienda anotar los pasos en un papel para que no tenga que estar reconectándose con Red Hat Academy.

Specification

1. Antes de comenzar, haga una copia de seguridad de su archivo de configuración xorg.conf del servidor X.

2. [root@station root]# cp /etc/X11/xorg.conf /etc/X11/xorg.conf.orig

3. Ejecute la utilidad system-config-display, cambie la resolución de pantalla a 640x480, y la profundidad de color a 8 bits (256 colores). Cierre sesión y regrese para que sus cambios surtan efecto.

4. Después de salir y regresar, copie el archivo de configuración actual de su servidor X al archivo ~/xorg.conf.painful (en el directorio de inicio de su cuenta primaria de la academia).

5. Vuelva a ejecutar la utilidad system-config-display, esta vez especificando la opción de línea de comando --reconfig. Escoja la configuración adecuada para un servidor X. Su instructor lo podrá guiar. Cierre sesión y regrese para que sus cambios surtan efecto.

Resultados

Question 1

1. El archivo ~/xorg.conf.painful contiene una configuración de un servidor X

para una resolución de 640x480 con 8 bits de profundidad de color (256 colores).

Limpieza

Si es necesario, puede restaurar la configuación original del servidor X, recobrando el archivo /etc/X11/xorg.conf desde su copia de seguridad (/etc/X11/xorg.conf.orig).


17

Capítulo 3 Configuración de arranque X

Conceptos clave

• Los servidores X son iniciados automáticamente por el gestor de visualización (en nivel de ejecución 5), o manualmente con el comando startx (en nivel de ejecución 3).

• El gestor de visualización para Red Hat Enterprise Linux es gdm, el cual recibe su configuración del archivo /etc/X11/gdm/gdm.conf.

• Los administradores pueden adaptar la inicialización X personalizando el archivo de inicialización X /etc/X11/xinit/Xclients o colocando scripts cortos en el directorio /etc/X11/xinit/xinitrc.d.

• Los usuarios pueden anular la inicialización X predeterminada creando scripts de arranque personalizados llamados ~/.Xclients.

• Los scripts de inicio X deben ser ejecutables. Tenga cuidado de no iniciar clientes X en el segundo plano a excepción del último cliente. El último cliente suele ser un gestor de ventanas o delimitador para el entorno de escritorio.

Arranque X

Puede iniciar un servidor X simplemente ejecutando el comando X. Luego, será recibido por un lienzo negro o gris con una X como cursor. Puede presionar teclas, hacer clic en su contenido central y no sucederá nada.

Los servidores X no suelen iniciarse directamente, sino a través de una serie de scripts de arranque que realizan una configuración rutinaria de bajo nivel y una más interesante de alto nivel (tal como, qué clientes X o entorno de escritorio iniciar automáticamente). Esta lección presentará algunos de esos scripts, haciendo énfasis en sitios apropiados para personalización. Pero primero, hablaremos de dos técnicas para iniciar servidores X.

Inicio de servidores X de modo automático: nivel de ejecución 5 y gestores de visualización

Cuando una máquina Linux está en el nivel de ejecución 5, el proceso init iniciará y monitorizará un servidor X. Si el servidor X alguna vez muere, init iniciará otro para que ocupe su lugar. Debido a la prontitud de init, la máquina siempre tendrá un servidor X ejecutándose.

Como el servidor X siempre está ejecutándose, algo necesita administrarlo cuando la sesión X no se esté utilizando. Esta es la función tradicional del Gestor de visualización. En esencia, el gestor de visualización posee el servidor X cuando nadie más lo posee. La prueba de un gestor de visualización suele ser el panel gráfico de inicio de sesión, aunque los gestores de visualización modernos también ofrecen formas de apagado o reinicio de la máquina y cambio de entorno para el siguiente inicio de sesión de usuario.

El gestor de visualización de GNOME: gdm


18

Cuando se utilice el entorno de escritorio de GNOME, el gestor de visualización predeterminado será gdm.

Figure 1. El gestor de visualización de GNOME gdm

El gestor de visualización también juega un papel más sutil, el cual se verá en una lección más adelante: el gestor de visualización puede administrar sesiones X completas para estaciones remotas.

Configuración de gdm: gdmconfig y /etc/X11/gdm/gdm.conf

El gestor de visualización gdm es altamente configurable desde la parte cosmética (las imágenes de segundo plano, "navegadores de cara y similares) hasta la parte funcional (las operaciones realizadas desde la página de inicio de sesión). El archivo de configuración principal es /etc/X11/gdm/gdm.conf, aunque la aplicación gráfica gdmconfig sirve para las configuraciones más comunes.

Inicio manual de un servidor X: nivel de ejecución 3 y startx

Si no se desea un servidor X constante, la máquina de Red Hat Enterprise Linux se puede dejar para arrancar a nivel de ejecución por defecto. El nivel de ejecución 3 está diseñado para duplicar el nivel de ejecución 5, con la única excepción de la falta de un servidor X constante.


19

Cuando se está en nivel de ejecución 3, los usuarios inician sesión en la máquina mediante una consola virtual. Sin embargo, tras iniciar sesión, la sesión X puede iniciarse manualmente con el comando startx. La sesión X debe ser idéntica a la que se entró desde el gestor de visualización, con una excepción: cuando el usuario cierra sesión, vuelve a la consola virtual y ningún otro servidor X es iniciado para ocupar su lugar.

Molestias en nivel de ejecución 5

Por lo general, un servidor X constante es conveniente. Algunas veces, especialmente al configurar el servidor X, un servidor X constante es absolutamente molesto.

Considere arrancar una máquina a un nivel de ejecución 5 con un servidor X desconfigurado. El proceso init inicia el servidor X, el servidor X muere, init observa un servidor X saliente, por lo tanto inicia otro para que ocupe su lugar, este muere, y así sucesivamente. El usuario queda mirando a la máquina que sigue "titilando". (Versiones más recientes de gdm detectarán el bucle y suspendenderán temporalmente el reinicio automático del servidor X, pero es aún molesto.)

En estas situaciones, la máquina puede cambiarse de modo manual al nivel de ejecución 3 desde una consola mediante el comando init.

[root@station root]# init 3

Cuando el cambio al nivel de ejecución 3 termina, el servidor X se puede depurar o configurar sin que se inicie automáticamente otro servidor X. Una vez la configuración está completa, el sistema se puede restaurar al nivel de ejecución 5.

[root@station root]# init 5

Inicializacion X del nivel de ejecución 3: startx

El arranque X es confuso con muchas capas de compatibilidad anteriores que tratan de mantenerse, sin embargo, todo el mundo debería verlo por lo menos una vez. No tiene que memorizarlo. En un momento nos centraremos en los puntos clave.

Figure 1. Inicialización X para startx


20

El script startx es un delimitador para el script xinit, el cual es el delimitador para el servidor X. Estos scripts "delimitadores" proporcionan varias capas de personalización.

Los usuarios pueden anular la secuencia de arranque predeterminada mediante la creación de su propio script de arranque ~/.xinitrc. En este caso, inicializan por sí solos mapas de teclado apropiados y recursos X, entre otras cosas. Esa personalización suele ser para expertos, la mayoría de los usuarios aceptan la personalización de bajo nivel provista por el script predeterminado /etc/X11/xinit/xinitrc, la cual a su vez lee rápidamente el xinitrc-common vecino.

El siguiente trozo se encuentra en el script de inicio predeterminado del sistema xinitrc-common.

# run all system xinitrc shell scripts. for file in /etc/X11/xinit/xinitrc.d/* ; do if echo $file | grep -q "\.sh$" ; then . $file else echo "warning: $file does not end in .sh extension, ignoring" fi done

Tras el arranque, todos los scripts que terminen en .sh enviados al directorio /etc/X11/xinit/xinitrc.d/ y hechos ejecutables, también serán copiados en la secuencia de arranque predeterminada. El requisito de la terminación del archivo en .sh es nuevo en Red Hat Enterprise Linux 4, por lo tanto, se expedirá una advertencia para ayudar en la migración.

Después de realizar una configuración de bajo nivel, el script predeterminado xinitrc se ve otra vez de esta manera en el directorio de inicio del usuario, y si el archivo ~/.Xclients existe, lo ejecuta para finalizar la secuencia de arranque. Suponiendo que este script no existe, la secuencia de arranque utilizará el script predeterminado /etc/X11/xinit/Xclients para continuar el proceso.


21

El script Xclients decide qué clientes X o entorno de escritorio debe iniciarse. Si GNOME está instalado, se iniciará por defecto, de lo contrario, se iniciará KDE o como último recurso una sesión X vanilla. (Este orden puede ser anulado por la variable DESKTOP en el archivo /etc/sysconfig/desktop. Para mayor información consulte /usr/share/doc/initscripts-versión/sysconfig.txt).

Inicialización X de Nivel de ejecución 5: xsession

Iniciar una sesión desde el nivel de ejecución 5 en lugar del nivel de ejecución 3, añade otra complicación. Al iniciar desde el nivel de ejecución 3, cada proceso pertenece al usuario que ejecuta startx. En el nivel de ejecución 5, gdm está ejecutándose como root, pero la sesión X que inicia debe ser propiedad del usuario que inició sesión.

Infortunadamente, esta complicación conduce a una secuencia de inicio alterna. Por fortuna, esta secuencia de inicio rápidamente converge con la que acabamos de presentar.

Figure 1. Inicialización X para xsession

El proceso comienza con scripts que se hallan en el directorio /etc/X11/xdm. (El nombre de directorio se refiere al gestor de visualización xdm, un gestor de visualización que ha existido desde el inicio de X y desde el cual gdm adquiere gran parte de sus directivas de inicio.) Primero Xsetup_0 se ejecuta (para el número de pantalla 0, a cualquier tasa) a fin de configurar el escritorio, luego se inicia gdm. Cuando el usuario inicia sesión, gdm transfiere propiedad mediante GiveConsole, y luego inicia el script de arranque Xsession.

El script /etc/X11/xdm/Xsession realiza muchas configuraciones de bajo nivel como /etc/X11/xinit/xinitrc, incluyendo la ejecución de los scripts que se hallan en el directorio /etc/X11/xinit/xinitrc.d/.


22

Después de que se haya realizado la configuración de bajo nivel, el script predeterminado Xsession buscará archivos dentro del directorio de inicio del usuario ~/.xsession y ~/.Xclients, en ese orden. Si existe alguno, el proceso de inicio termina con su ejecución. Suponiendo que ningún script existe, la secuencia de arranque convergirá en el script predeterminado /etc/X11/xinit/Xclients para continuar el proceso.

Resumen de arranque X

A continuación resumiremos algunos de los puntos más importantes sobre la secuencia de arranque X.

• Los usuarios pueden anular la secuencia predeterminada mediante la creación de un script X de arranque llamado ~/.xinitrc (para startx), ~/.xsession (para un gestor de visualización), o ~/.Xclients (para ambos), y hacerlo ejecutable.

• El preferido de esos tres es ~/.Xclients, porque es compartido por ambos métodos de arranque y porque el usuario no necesita preocuparse por la configuración convencional X de bajo nivel.

• Los administradores de sistemas pueden modificar la secuencia de inicio predeterminada, ya sea enviando un script corto al directorio /etc/X11/xinit/xinit.d/ o modificando el script predeterminido de arranque compartido /etc/X11/xinit/Xclients.

Luego daremos algunas recomendaciones para la escritura de scripts de arranque X.

Scripts de arranque X

Los scripts de arranque X son reminiscentes de los scripts de arranque bash, ya que se utilizan automáticamente cada vez que se inicia una sesión. No obstante, hay diferencias muy importantes.

• Los scripts de arranque X son ejecutados. Esta diferencia implica que los scripts de arranque X deben tener permisos de ejecución. El proceso de arranque X se considera como la ejecución de un sólo comando de arranque, lo cual nos lleva al segundo punto.

• Todos los clientes X deben estar en segundo plano. Si un script de arranque quisiera que el cliente X xclock se iniciara por defecto, el script debe poner en segundo plano el proceso al iniciarlo. Analice los siguiente datos de un script de arranque X que inicia xclock y xeyes.

• /usr/bin/X11R6/xclock & # correct • /usr/bin/X11R6/xeyes # incorrect

Como si los dos se hubiesen iniciado desde la línea de comandos, xclock se iniciará y el procesamiento del script continuará. No obstante, cuando xeyes inicia en el primer plano la secuencia se detendrá hasta que el usuario cierre xeyes, tras de lo cual continuará donde haya quedado.


23

• El servidor X muere cuando el script de arranque termina de ejecutarse. ¿Cómo sabe el servidor X cuándo es tiempo de morir? Por lo general, los scripts de arranque están construidos de tal manera que el último comando no sigue la regla anterior, sino que se ejecuta en el primer plano (o se ejecuta directamente con exec). Por lo general, este último comando es una gestor de ventanas (tal como twm) o un delimitador para entorno de escritorio (tal como gnome-session o startkde). Cuando un usuario elige "cerrar sesión" desde el entorno de escritorio, el script del delimitador de entorno de escritorio sale, el script de arranque X sale y el servidor X muere.

El siguiente trozo de información, implementada como último recurso desde el archivo de arranque X, /etc/X11/xinit/Xclients, ilustra el diseño clásico de un script de arranque X.

# Argh! Nothing good is installed. Fall back to fvwm2 (win95-style) or twm /usr/X11R6/bin/RunWM --Fvwm95 || { # gosh, neither fvwm95 nor fvwm2 is available; # fall back to failsafe settings xclock -geometry 100x100-5+5 & xterm -geometry 80x50-50+150 & if [ -f /usr/bin/mozilla -a -f /usr/share/doc/HTML/index.html ]; then mozilla /usr/share/doc/HTML/index.html & fi if [ -f /usr/X11R6/bin/fvwm ]; then exec fvwm else exec twm fi }

Como el último esfuerzo, el script de arranque inicia los clientes X xclock, xterm, y mozilla (todos en segundo plano) y por último, el gestor de ventanas twm de exec. Cuando el usuario sale del administrador de ventanas (probablemente eligiendo "cerrar sesión" del menú de acciones), el "script de arranque" muere, llevándose al servidor X con él.


Lab Exercise Objetivo: Personalizar el arranque X con un script de arranque individualizado


Specification

Como este laboratorio requiere reiniciar el servidor X varias veces, se recomienda anotar los pasos en un papel para que no tenga que estar reconectándose con Red Hat Academy.


24

1. Cree un script corto de shell que inicie el cliente X xclock, pero deje el comando en el primer plano. Almacene el script como el archivo /etc/X11/xinit/xinitrc.d/xclock.sh y recuerde hacerlo ejecutable.

2. Cierre sesión y regrese. Observe que su proceso de arranque se interrumpirá cuando xclock inicie en el primer plano. Puesto que el gestor de ventana aún no ha iniciado, no es conveniente deshacerse de él. Mate el servidor X con la secuencia de teclas CONTROL-ALT-RETROCESO.

3. Prepare el script iniciando xclock en el segundo plano. Cuando reinicie el servidor X, el cliente X xclock debe iniciar automáticamente con la secuencia de arranque X.

4. Crédito adicional para perfeccionistas: Puede haber notado que el cliente xclock inicia demasiado temprano en la secuencia de arranque (incluso antes de que aparezca la pantalla de GNOME). Modifique su script, mediante el comando sleep para demorar por 10 segundos el inicio de xclock, pero no demore el proceso de arranque del servidor X.

10 - sistema de ventanas x

Documents