martes, 24 de julio de 2012

Pensamientos sobre Steam en GNU/Linux

Con el anuncio de Steam para GNU/Linux han corrido ríos de bits en Internet. Se puede apreciar algo de dicho torrente si leemos el propio post en el blog de Valve, donde hay cientos de comentarios.

Desde el anuncio, le he ido dando vueltas al asunto. Concretamente en cómo será desplegado en los sistemas de los usuarios.

Actualmente en sistemas GNU+Linux existen varias formas de instalar software, a saber:
  • Desde el código fuente
  • Mediante paquetes precompilados
  • Mediante archivos autoinstalables
En el primer caso estaríamos hablando de que Valve nos daría la opción de descargar el código fuente de Steam para luego nosotros compilarlo e instalarlo donde queramos en nuestro sistema. Esto nos daría como resultado, además de la personalización extra posible, unos requisitos más laxos en cuanto a bibliotecas y las versiones de las mismas que debe haber en el sistema. Sin embargo el usuario ha de encargarse de todo: cumplir los requisitos no ya de instalación, sino también de los de compilación. Además la desinstalación implica borrar manualmente todos los archivos, salvo que se conserve el script Make y que éste tenga el objetivo Uninstall o como se le haya llamado, debidamente programado. Resulta evidente que Valve no va a publicar el código fuente del cliente Steam, así que nos podemos ir olvidando de esta opción.

El tercer caso significaría descargarse un binario, normalmente de extensión .sh por lo que precediendo al binario hay como cabecera un shell script (guión de concha según el traductor de Google, antaño, ahora lo traduce como script de shell) que indica en qué carpeta extraer el ejecutable del programa de instalación. Esto será muy conocido por usuarios que provienen de sistemas Windows. En este caso a veces el programa de instalación se hace cargo de gestionar las dependencias (limitándose a avisar de cuáles hacen falta y el usuario teniéndolas que descargar por su cuenta), o si el programa está compilado de forma estática, entonces lo que se tendrá será un ejecutable bastante grande, aunque eso sí, autocontenido y prácticamente independiente del software instalado en el sistema. El problema es que para las actualizaciones o bien te descargas cada vez que haga falta un binario, o bien en el caso de Steam se continua empleando el mismo método que en Windows (actualizaciones silenciosas), con la salvedad de que si Steam no se instala en el directorio de usuario, para cada actualización se requerirá de permisos de super usuario.

Con éste método id Software ha distribuido siempre sus juegos para GNU/Linux. Siempre he optado por instalarlos en mi carpeta de usuario para ahorrarme tener que ejecutar la instalación en modo administrador. Sin embargo instalar el programa en otros directorios como /opt no sería nada del otro mundo, y al fin y al cabo lo que más se va a usar es la lectura de los archivos ejecutables mientras que el guardado de las partidas se hará en el /home del usuario.

La segunda opción es muy usada por distribuciones GNU/Linux. El paquete precompilado no es más que el código fuente compilado, junto con unas directivas (scripts) que indican qué hacer con los archivos (copiarlos, ejecutarlos, destinos de copia, acciones a tomar con archivos ya existentes, configuraciones a cambiar o añadir en distintas partes del sistema, etc.). Estos paquetes se suelen descargar de unos repositorios de los mantenedores del paquete, que no tienen porqué ser los desarrolladores del software empaquetado. Estos repositorios (servidores) y los paquetes que hay en ellos, son descargados según las decisiones tomadas por lo que se llama el Gestor de paquetes de la distribución en GNU/Linux. Este gestor de paquetes determina los requisitos a cumplir para instalar un paquete determinado. La información de los requisitos va incluida en el propio paquete a instalar. Esta información incluye bibliotecas y sus versiones, y también otros programas necesarios para que el software empaquetado funcione. Esos requisitos evidentemente también están empaquetados y se descargan de los repositorios de paquetes.
Este sistema de repositorios de paquetes tiene la ventaja de que los paquetes están perfectamente integrados con el sistema y por tanto todo el software se gestiona mediante una misma aplicación, el Gestor de paquetes. Si hay actualizaciones, el Gestor de paquetes notifica al usuario y se bajan las nuevas actualizaciones. Ningún software descargado mediante repositorios se actualiza por terceras vías. Si así fuera sería un cacao.
En este caso dependemos del mantenedor de paquetes, cosa que si el desarrollador del software empaquetado no es el mismo que el mantenedor, puede suponer un problema. Hacen falta permisos de "root" para el usuario, algo que no supone un problema para entornos domésticos en los que el propio usuario del sistema es el administrador del mismo por lo que se puede conceder a sí mismo los permisos de root cuando haga falta.

Desde mi punto de vista, sería preferible que Valve estableciera un repositorio donde albergar los paquetes de Steam, y así integrar el mantenimiento de dicho software con el resto del software del sistema. Cuando hubieran nuevas actualizaciones, el Gestor de paquetes avisaría de las mismas. No hace falta que las actualizaciones sean silenciosas como ocurre en Windows. De hecho es preferible que no lo sean. Además, se podría tener unos parámetros de configuración intocables en /etc y las preferencias concretas del usuario junto con errores/logs en /home/$USER/.steam, encargándose la desinstalación del paquete de limpiar todo debidamente. Los binarios como siempre en /usr/local/bin o en /opt/steam si hay algo más que el ejecutable, directorios montables en otra partición o disco.

La parte peliaguda nos la encontramos con los juegos, que deben ser controlados por Steam. Estos podrían ser copiados como archivos del tercer tipo (binarios autoinstalables) y podrían ir en el directorio /opt/steam o en /home/$USER/.steam, claro que en el segundo caso estaríamos comprometiendo espacio de directorio de usuario que puede estar definido en una partición más pequeña. Sin embargo actualizar juegos no requeriría permisos de root, mientras que en /opt/steam sí, y quizá ya se estén empezando a añadir demasiadas solicitudes de permisos. Supongo que sería preferible tener los juegos en $HOME/.steam siendo el propietario el usuario, ya que luego permitirían también una mejor modificación y personalización de las instalaciones de los mismos, mientras que a Steam lo podemos dejar con permisos de root para su modificación en la carpeta antes mencionada ("/usr/local/bin", o también en /opt/steam si hay más archivos que el ejecutable, seguramente sí). Sería conveniente crear una variable de entorno que se inicializara con el directorio donde steam esté instalado. Hemos de recordar que los juegos distribuidos mediante Steam tienen algunas modificaciones que enlazan con el entorno de Steam.

Por último también cabría mencionar la necesidad de tener un grupo especial para manejar tanto los archivos de los juegos como el propio Steam (/usr/local/bin, /opt/steam). Crear un grupo llamado "steam" e incluir a los usuarios que quieran acceder a Steam y los juegos instalados en dicho grupo.

Con el tema de los permisos solventado, no estaría de más crear un perfil para AppArmor acerca de las acciones permitidas a Steam o cualquier juego que se instale. Esto requeriría permisos de root también, lo cual no supone ya ningún problema dado que se conceden durante la instalación del juego (que no actualización) por lo que AppArmor quedaría configurado también para cada binario de juego instalado. Todos los juegos necesitarán los mismos permisos de acceso al sistema.

Otra posibilidad sería gestionar también los juegos mediante el gestor de paquetes, y hacer una especie de front end del gestor. Los juegos dependerían del paquete Steam y otro paquete descargado de forma independiente como si fuera un juego (que a su vez también dependería de Steam) conteniendo la lista de juegos de la biblioteca del usuario. Dicha lista iría firmada digitalmente por Valve y el propio programa Steam la comprobaría antes de iniciar cualquier tipo de descarga o de permitir la ejecución de cualquier juego/binario que quiera ejecutarse en el marco de Steam.
Esto último pienso que es complicarse las cosas y diría que es mejor tener Steam gestionado mediante el Gestor de paquetes del sistema y luego que cada juego sea un binario autoinstalable en $HOME/.steam con su perfil AppArmor y que Steam compruebe contra los servidores los juegos que se puede descargar el usuario y que además Steam controle en conjunto con los servidores, como ya ocurre en Windows, los binarios que el usuario se puede descargar de forma que el usuario no se baje binarios por bajar que luego no podrá ejecutar, gastando tráfico inútilmente. Eso sí, nunca estaría de más acompañar la descarga de los juegos con una solicitud de instalación de nuevos paquetes para cumplir los requisitos de bibliotecas de los mismos si es necesario. Eso o obligar a compilar de forma estática los juegos, binarios muy grandes.

Todo esto que he expuesto aquí probablemente sea diferente a lo que se haga en Mac, sistema que no dispone de gestor de paquetes ni tampoco de barreras de seguridad como AppArmor o SELinux.
También es altamente probable que no se parezca a nada de lo que tiene Valve pensado, que con casi toda seguridad se limitará a utilizar el mismo método que utilicen en Mac.

No hay comentarios:

Publicar un comentario en la entrada