Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Configuraciones gráficas

Distribuciones
Por SegFault
departamento intentando llegar a todo el mundo , Sección Software Libre
Puesto a las Sat Aug 14th, 2004 at 01:22:41 PM CET
Leyendo una nota sobre el modo kiosk de KDE, que es una parte muy importante para que SuSE/KDE pueda llegar a un entorno corporativo (donde Novell quiere llegar), he recordado que otra herramienta que me pareció muy interesante fue la anteriormente conocida como Ximian Setup Tools y ahora rebautizado GNOME System Tools. Se trata de un proyecto que pretende ofrecer herramientas de configuración para un sistema. La arquitectura divide el proyecto en 2 partes claramente diferenciadas: un frontend gráfico desde el que se gestionan las configuraciones que son almacenadas en ficheros XML, y por otro lado un conjunto de backends que aplican esas configuraciones al sistema apropiado y que son independientes del frontend (no tendrían nada que ver con GNOME).

 


La idea en principio parece buena, pero hasta ahora da la sensación que las GST no han tenido demasiado actividad (tampoco en el CVS se ve mucho movimiento) y no está recibiendo el apoyo de ninguna distribución ya que las principales utilizan sus propias herramientas de configuración. ¿Qué es lo que está saliendo mal en este proyecto? Quizás le falte visibilidad, y en ese caso el hecho de que aparezca en Gnome 2.8 sólo podrá ser algo bueno. Quizás incluso sería beneficioso que desapareciera la parte "GNOME" del nombre, que el proyecto se alojase en otro sitio (los backends claro) aunque no creo que eso ayudara mucho, pero algo de tacto tampoco sería perjudicial. De esa forma podrían existir más herramientas como KNetworkConf que utilizan GST, y quizás esas utilidades podrían llegar a más gente.

El principal escollo que le puedo ver a este tipo de herramientas es cómo de bien se comportan cuando cambias las configuraciones de varias formas. Hace algunos años estuve usando SuSE como sistema de escritorio durante unos meses, pero el estropicio que se formaba entre los cambios de YaST y mis configuraciones manuales fue razón suficiente como para que cambiase de sistema. ¿Sería posible que las GST conviviesen con herramientas tan populares como Webmin o con los sistemas que cada distribución incluye? Creo que eso sería una parte muy importante para conseguir un buen sistema de configuración.

Por cierto, si queréis leer más sobre ello he descubierto que en una de las listas de Gnome han estado debatiendo sobre este asunto.

< Debian y sus problemas con la MPL (10 comments) | Monta un servidor para un proyecto libre (8 comments) >
Enlaces Relacionados
· el modo kiosk de KDE
· GNOME System Tools
· arquitectura
· frontend gráfico
· conjunto de backends
· GST no han tenido demasiado actividad
· el CVS
· el hecho de que aparezca en Gnome 2.8
· KNetworkConf que utilizan GST
· Webmin
· han estado debatiendo sobre este asunto
· More on Distribuciones
· Also by SegFault

Encuesta
¿Utilizas alguna herramienta de configuración?
· Solo las que trae mi distribución 26%
· Para algunas cosas uso unos asistentes gráficos que me ayudan 12%
· No podría vivir sin Webmin 2%
· Claro que sí, lo configuro todo con vim 52%
· Tengo un amigo que me hace eso 8%

Votos: 50
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Configuraciones gráficas | 27 comentarios (27 temáticos, editoriales, 0 ocultos)
Hay más inconvenientes... (none / 0) (#1)
por FidoX a las Tue Aug 17th, 2004 at 05:08:25 PM CET
(Información Usuario) http://www.corebedigital.com

No solo está el inconveniente de que es muy dificil hacer convivir a varias aplicaciones de configuración a la vez, además de las configuraciones que quiera modificar uno mismo a mano.

Otro problema que veo yo, es que si instalas una aplicación, a ésta le resulta bastante dificil adivinar parámetros de configuración de otros programas para adaptarse a ellos. El caso típico el del driver de nvidia. El programa de instalación debería ser capaz de leer el fichero de configuración de las X, ver las opciones que le interesan y modificarlo. Pero con ésto, de momento, parece que no se atreven y parece bastante lógico por las diferencias que se pueden dar en cada distribución, al final es más fácil dar las instrucciones al usuario para que haga los cambios pertinentes en el fichero.

Realmente ésto no parece tan problematico para nosotros, pero supongo que para llegar un poco más lejos en el escritorio, debería ser posible que al pinchar un dispositivo usb, se modifiquen las configuraciones de los programas para acceder a él, sin que se pierdan nuestras preferencias.

Supongo que aunque éste sería el panorama ideal, puede que como están estructurados los archivos de configuración de la mayoría de los programas resulta bastante complicado.

Yo estoy participando en un proyecto que pretende unificar todos los archivos de configuración de las aplicaciones más importantes en linux. Quizá no llegemos a ninguna parte, porque no se trata de hacer otro sistema de configuración. Básicamente se trata de olvidarse de la compatibilidad hacia atrás, arremangarse y reescribir el código necesario para que las aplicaciones lean los ficheros de configuración como a nosotros nos interesan.

Yo actualmente estoy metido con algunos ficheros de la glibc para intentar hacer una distribución mínima con las aplicaciones que vayamos portando.

Los problemas principales de éste proyecto, no son técnicos, por eso nos asaltan muchas dudas sobre si lograremos algo. Está claro que podemos programarlo, pero es un poco más dificil convencer a alguien para que incluya nuestros parches en su código.

Idealmente, una vez la distribución esté portada al nuevo sistema de configuración, se podría configurar cualquier opción con el vi, cambiando las opciones en los ficheros correspondientes, con un programa en línea de comandos la mar de cómodo ;) o con aplicaciones gráficas, además un script de instalación podría usar, por ejemplo el programa en línea de comandos, para modificar la configuración que le parezca, siempre que disponga de los permisos necesarios, claro está.

Además, en la última versión se está integrando un sistema de notificación de forma que cuando cambie el valor de una clave (por cualquiera de los métodos mencionados ántes) el programa en cuestión sea notificado y pueda actuar en consecencia.

Es un sistema parecido al gconf, solo que eliminando los problemas que a nosotros nos parecía que evitaban que esa herramienta prosperaba:
* Demasiadas dependencias: nuestra librería no depende de nada (salvo de la glib, claro), de hecho hemos creado un módulo para incluir en la glibc sin dependencias de ningún tipo. Puede funcionar en estadíos tempranos de arranque ya que no necesita tener ningún demonio ejecutando.
* Demasiado complejo y lento: gconf prácticamente te obliga a usar las herramientas visuales para modificar la configuración. En nuestro caso ésto no es necesario, ya que son ficheros de texto plano, se pueden modificar a mano o a máquina ;) como más te guste.
* No es portable: en nuestro caso el sistema es tan simple que es bastante sencillo portarlo a otras plataformas.

Pensando en ello detenidamente ofrece un montón de ventajas, el principal problema es el rechazo de la gente a dar grandes pasos. El promotor del proyecto se va a pasar por la devconf de KDE el día 22 a ver qué pasa ;)

El que quiera saber algo más del proyecto:
* http://registry.sourceforge.net/
* http://registry.sf.net/registry.sxi

aunque sería mejor aún que se apuntaran a participar... todavía hay un montón de cosas que hacer. ;)
Israel E. Bethencourt
FidoX/CORE


la mecánica de GST (none / 0) (#2)
por raster a las Wed Aug 18th, 2004 at 01:18:10 PM CET
(Información Usuario)

Yo estuve viendo como trabaja GST y me pareció una mecánica bastante buena: el backend, escrito en Perl, es llamado primero para leer la configuración actual, para lo cual primero comprueba qué distribución estamos usando. Una vez leída, se la pasa en formato XML al frontend. Allí modificas lo que quieras, y luego se pasa la nueva configuración en XML al backend, que modifica los ficheros.

Lo estuve probando y la verdad es que trabaja muy bien, además de que detecta muchas distribuciones, en concreto: Debian 2.2 (potato), 3.0 (Woody) y 3.1 (Sarge); Fedora core 1 y 2, FreeBSD 5, Gentoo, Mandrake 10.0, 10.1, 7.2, 9.0, 9.1 y 9.2, OpenNA, PLD 1.0, 1.1 y 1.99; RedHat 5.2, 6.0, 6.1, 6.2, 7.0, 7.1, 7.2, 7.3, 8.0 y 9.0; Slackware 8.0.0, 8.1, 9.0.0 y 9.1.0; Suse 7.0 y 9.0; y Turbo Linux 7.0 (arf). En caso de que no detecte la tuya (cosa que me ocurre con SID, aunque ya envié el error), te muestra una lista y puedes escoger la que mejor se adapte (en mi caso le dije Sarge).

Respecto a vuestro proyecto ¿qué formato de texto usais? ¿XML? Creo que sería la mejor opción (además de que teneis la libXML2, bastante pequeña y potente).

[ Padre ]


un fichero por clave? (none / 0) (#3)
por raster a las Wed Aug 18th, 2004 at 01:49:37 PM CET
(Información Usuario)

Tenía que haberme leido antes la página de vuestro proyecto O:)

Reconozco que la idea es buena en principio, pero le veo algunos problemas:

*¿no rompe la compatibilidad POSIX? Creo que POSIX también especifica la situación de algunos ficheros, como passwd y groups ¿o no? :?

*desperdicio de disco duro: si se usa un único fichero para cada clave (según he entendido, esto es lo que haceis), tendremos miles de ficheros de un tamaño diminuto, ocupando miles y miles de inodos en el disco duro. ¿No sería mejor agrupar las claves de una categoría en un mismo fichero? Esto es, por ejemplo, las claves:

system/user/nobody/uid=99
system/user/nobody/gid=99
system/user/nobody/gecos=nobody
system/user/nobody/home=/
system/user/nobody/shell=/bin/bash

irian todas en el fichero

system/user/nobody/keys

y las claves

system/user/nobody/programs/mozilla/user=nobody
system/user/nobody/programs/mozilla/mouse_scroll=fast

irian todas en el fichero

system/user/nobody/programs/mozilla/keys

Se ahorraría mucho en inodos ¿no? Además, no sería muy problemático un fallo de dicho fichero frente al fallo de un único fichero de configuración actual (poca diferencia hay entre que te falle una entrada de la configuración de las X-Windows a que te falle todo el fichero de configuración de las X-Windows, que, a fin de cuentas, es lo que ocurriría hoy en día).

[ Padre ]


Lo de los ficheros (none / 0) (#4)
por SegFault (segfault tiene un Mailbox en frenopatico punto net) a las Wed Aug 18th, 2004 at 01:52:25 PM CET
(Información Usuario) http://www.frenopatico.net/segfault

Los Maildir utilizan un fichero por mail, y puedes tener unas pocas decenas de ficheros en cuanto te descuidas ;-) Pero el uso de varios ficheros también ofrece varias ventajas que hay que tener en cuenta.

[ Padre ]


cientos vs miles (none / 0) (#5)
por raster a las Wed Aug 18th, 2004 at 02:20:44 PM CET
(Información Usuario)

Hay dos factores a tener en cuenta: por un lado la fragmentación... ¿interna? (creo que es eso, sí), que es mucho mayor al tener muchos ficheros pequeños que unos pocos grandes. Recuerda que un fichero ocupa siempre un número entero de sectores, por lo que con muchos ficheros pequeños desperdicias muchísimo más espacio que con unos pocos grandes.

Por otro lado, fíjate que un fichero /etc/passwd en un sistema usado sólo por un usuario tiene ya varias líneas (en mi equipo son 25 usuarios entre root, daemon y más, y cada uno tiene 9 parámetros, por lo que serían, solo para este passwd 241 ficheros). Pásalo a un sistema con cincuenta usuarios: tenemos ya 50+25 usuarios=675 claves almacenadas cada una en un ficherito diminuto. Sumale un fichero más por cada posible entrada de cada fichero de configuración (Sendmail y sus "diminutos" ficheros de configuración, por ejemplo :) y tenemos varios miles de ellos.

Ten en cuenta, además, que, salvo que el programador sea un poco cuidadoso, estarán disponibles también las entradas para opciones que no se usen, apuntando a cadenas en blanco.

En fin, que, personalmente, sigo diciendo que un fichero por clave no me parece adecuado, aunque la idea en sí del registro me parece magnífica.

[ Padre ]


 
Sid (none / 0) (#7)
por algarcia a las Thu Aug 19th, 2004 at 04:02:44 AM CET
(Información Usuario)

En caso de que no detecte la tuya (cosa que me ocurre con SID, aunque ya envié el error), te muestra una lista y puedes escoger la que mejor se adapte (en mi caso le dije Sarge).

Hombre, es que Sid no me parece que sea una distribución con una identidad propia estrictamente hablando. Me refiero a que si Sarge es Debian 3.1, la actual Sid es Debian 3.1 antes de que llegue a ser (por decirlo de alguna manera) Debian 3.1. Y cuando la testing sea otra y sea la Debian 3.2 (o la numeración que siga, vamos), la Sid no será otra cosa que la Debian 3.2 antes de ser 3.2.

Pero vamos, a efectos prácticos de este caso de las GST creo que se puede considerar que la actual Sid conicide con la Sarge o Debian 3.1. Que es lo que le corresponde, vamos.

--
No me pregunto lo que yo puedo hacer por el S.L., si no lo que todos vosotros podéis hacer por mí. :-P
[ Padre ]


 
Pues sí, interesante el tema. (none / 0) (#23)
por melenas a las Tue Aug 24th, 2004 at 03:32:05 PM CET
(Información Usuario)

Pensando en ello detenidamente ofrece un montón de ventajas, el principal problema es el rechazo de la gente a dar grandes pasos. El promotor del proyecto se va a pasar por la devconf de KDE el día 22 a ver qué pasa ;)

Precisamente estuvimos tomando unas cervezas con Avi, el gestor de todo esto y pudimos charlar de esto, joder, que bueno es esto de tener a los "maestros" al lado y poder resolver tus dudas casi al momento :-)


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
[ Padre ]


 
registry (none / 0) (#6)
por FidoX a las Wed Aug 18th, 2004 at 08:19:08 PM CET
(Información Usuario) http://www.corebedigital.com

El usar XML para los ficheros de claves está totalmente descartado de momento. No tiene ninguna razón de ser, ya que en cada fichero solo se graban algunos datos, los cuales deben ser fácilmente editables con el vi. Además, tampoco me imagino teniendo que meter todo el código de parseo de XML en la glib, por ejemplo o tenerlo que portar a todas las plataformas en las que ejecute apache.

Sobre el tema de un fichero por clave... pues bueno, han corrido ríos de tinta (o de bytes) sobre ese tema. La conclusión a la que hemos llegado es que no es un problema del que debamos preocuparnos. Primero, porque se puede cambiar sin mayor problema en cualquier momento y todas las aplicaciones seguirían funcionando exáctamente igual.

En segundo lugar porque hay sistemas de archivos que están muy optimizados para ficheros pequeños. Si no quieres usar ese sistema de archivos, puedes crearte una partición virtual con el loop. (en linux, al menos)

Así, tienes la ventaja de poder fijar permisos, por ejemplo para que un usuario pueda modificar la configuración de un servidor virtual de apache, pero no la configuración genérica y cosas así.

De todas formas, ya digo que éste no es el momento de preocuparnos por esas cosas, porque incluso podrían subsistir claves en grupo y claves por ficheros en el mismo sistema.

Además algo que me gusta a mi particularmente, es la posibilidad de indicarle a alguien un cambio en la configuración ejecutando un simple comando:

bash$ rg set /system/hw/net/address "192.168.1.1"

mediante ese comando se podría cambiar la IP de la máquina. Además con el sistema de notificaciones se podría resetear la interfaz para que el cambio sea inmediato.

Otra posibilidad es la de tener pequeños scripts que te permitan a base de preguntas configurar los parámetros básicos de varios ordenadores a la vez.

Si todos los valores van a ser los mismos, supongo que ahora se podriá hacer sobreescribiendo los ficheros a lo béstia. Pero de ésta forma, cualquiera podría hacerse un script en bash a base de read y rg que con preguntas sencillitas configure la red, las X, los puntos de montaje, /etc/hosts, /etc/resolv.conf, etc...

Ya ven que las ventajas no están solo en las interfaces gráficas, que a mi personalmente por llevar mucho tiempo usando una shell bash, tampoco me agradan mucho. Yo he podido encontrar ventajas que me venefician a mi personalmente que no tengo ningún problema en editar cualquier fichero con vi. El hecho es que éste sistema es más o menos parecido, pero con un poco de ayuda para hacerlo más... moderno ;)

Creo que las ventajas son muchas y al fin y al cabo solo estamos modificando los ficheros de configuración que no va a suponer ningún cambio drástico en la manera de funcionar de los programas. Seguirán funcionando igual de estables (o inestables ;)) a la misma velocidad y exactamente de la misma forma, solo que, creo yo, acabarán teniendo conocimiento de sus programas vecinos y serán más cómodos de configurar.
Israel E. Bethencourt
FidoX/CORE


Sí y no... (none / 0) (#8)
por raster a las Sat Aug 21st, 2004 at 02:45:44 AM CET
(Información Usuario)

Hombre, el problema de los inodos creo que se puede considerar bastante serio. Fijate que dices que se puede crear un sistema de archivos en un fichero y montarlo por loop. ¿Y si casca el archivo que contiene dicho sistema de ficheros? Sería tener el registro en un único fichero, como en windows, con todos sus problemas.

Sí es cierto que el API permite abstraerse por completo de si se guardan las claves en ficheros independientes o no, salvo en un único detalle: se pueden especificar privilegios a cada entrada de manera independiente. Eso ya obliga a que las entradas estén cada una en un fichero (no sirve de nada incluir los permisos junto a cada clave porque se tiene que poder acceder al fichero global, con lo que, aunque las herramientas no lo permitan, sólo tendría que ir con vi y tira millas). Si hicieseis que los permisos se aplicasen a todas las entradas de un nivel, permitiríais ambos casos y sin pérdida de generalidad (se meten en un nivel las que sólo puede cambiar una persona, en otro las que puedan cambiar todo el mundo, etc, y se asignan los permisos en concordancia por grupos).

Puedo parecer pesado, pero creo que es un tema muy importante: de él puede depender que sea aceptado o no. Yo, desde luego, pondría muchos reparos a un registro con un fichero por entrada (aunque repito que la idea del registro en sí me parece magnífica). Si sólo cambiaseis ese detalle en el API, sería perfecto (afecta a las llamadas KeyGetUID, KeySetUID, KeyGetGID, KeySetGID, KeyGetAccess y KeySetAccess), aunque no lo implementeis de momento. Al menos no cerraríais la puerta a la posibilidad de "varias claves=un fichero".

[ Padre ]


Permisos (none / 0) (#9)
por man ls a las Mon Aug 23rd, 2004 at 12:18:08 AM CET
(Información Usuario)

No creo que los permisos sean un obstáculo; si se meten varias claves en un fichero, se pueden añadir los permisos en él o incluso en otro fichero del mismo directorio.

Sí creo que lo importante es que se adopte un sistema global de configuración, y los detalles de implementación se irán puliendo luego -- es imposible hacerlo todo correcto a la primera. Cuando sea posible configurar un sistema con scripts, en red, de forma gráfica y desde línea de comandos (sin artefactos extraños como el sistema de ficheros /proc) la vida de los BOFHs mejorará bastante; si además es seguro, fiable, grepable y sin problemas de sincronización, tendremos un sistema operativo sin rival.

[ Padre ]


registro = /etc (none / 0) (#10)
por musg0 a las Mon Aug 23rd, 2004 at 09:34:59 AM CET
(Información Usuario) http://helvete.escomposlinux.org

Cuando sea posible configurar un sistema con scripts, en red, de forma gráfica y desde línea de comandos (sin artefactos extraños como el sistema de ficheros /proc) la vida de los BOFHs mejorará bastante; si además es seguro, fiable, grepable y sin problemas de sincronización, tendremos un sistema operativo sin rival.

Yo creo que el registro ya lo tenemos y se llama /etc.

Lo que sí debería hacerse ya es organizarlo porque /etc se está desmadrando un poco.

Estaría bien tener todas las configuraciones de los programas colgando de /etc/programs/nombre-version-subversion/

Así cada programa podría hacer lo que le viniera en gana pero no tendrías que pensar nada para saber donde está su configuración.

En Debian por política todas las configuraciones de los programas tienen que ir a /etc. Estaría bien que se llegara un paso más allá y se se organizara por versiones. Así, al instalar los paquetes te podría preguntar si quieres borrar la última configuración, moverla, copiarla, instalar la que viene en el paquete, etc...

Estaría todo ordenado en una jerarquía como en /usr/share/doc y dentro de cada directorio de programa ya sería labor del programa el cómo leer sus configuraciones ya que no creo que se necesite una forma común de trabajar con ellas.

[ Padre ]


Tiene sus limitaciones (none / 0) (#11)
por man ls a las Mon Aug 23rd, 2004 at 10:14:15 AM CET
(Información Usuario)

Guardar todas las configuraciones de /etc no es la panacea. Varios ejemplos de cosas que no están resueltas:
  • Configuraciones de usuario. Ahora mismo, los programas derraman sus configuraciones por todo mi $HOME, cuando yo preferiría que todas estuvieran en $HOME/.etc o algo parecido.
  • Configuraciones para X. Si arranco una sesión X remota, ¿qué valores debería usar, los míos locales o los del servidor?
  • Siguiendo con lo mismo, algunos programas usan Xresources y otros ficheros locales.
  • No es fácil centralizar todas las configuraciones para varias máquinas en un servidor.
  • No se guardan las versiones antiguas de los ficheros de configuración, para poder deshacer los cambios.
  • Hay que reiniciar los programas o decirles que vuelvan a leer la configuración después de cada cambio.
Una forma común de leer configuraciones podría resolver estas cuestiones de un plumazo.

[ Padre ]


Yo no las veo (none / 0) (#12)
por musg0 a las Mon Aug 23rd, 2004 at 12:03:51 PM CET
(Información Usuario) http://helvete.escomposlinux.org

# Configuraciones de usuario. Ahora mismo, los programas derraman sus configuraciones por todo mi $HOME, cuando yo preferiría que todas estuvieran en $HOME/.etc o algo parecido.

Al igual que en mi ejemplo hay un /etc/programas/nombre-version podría haber lo mismo en cada directorio de usuario. En Debian se modifican muchas fuentes para que usen /etc. Podrían también cambiar esos programas para que usen ~/.etc/programs/nombre-version/ para guardar las configuraciones locales. Esto no necesita nueva infraestructura si no una recompilación con los cambios pertinentes a las rutas.

# Configuraciones para X. Si arranco una sesión X remota, ¿qué valores debería usar, los míos locales o los del servidor?

Yo creo que la configuración del ordenador que está ejecutando ese programa. El programa puede estar instalado en un servidor remoto pero se está ejecutando en la máquina local. Por ahora no creo que haya nada que haga streaming de configuraciones por red.

# Siguiendo con lo mismo, algunos programas usan Xresources y otros ficheros locales.

Estos serían configuraciones del DISPLAY, ¿no?. Me parece lógico ya que el DISPLAY es local a la máquina en la que estás y no se está "ejecutando" en otra máquina. No veo problemas en esto. Repito que lo raro me parecería tener que hacer una especie de streaming de las configuraciones por red. Me parece que no me queda claro lo que quiero comunicar...

# No es fácil centralizar todas las configuraciones para varias máquinas en un servidor.

Con los HOME exportados por NFS nunca ha habido problemas de eso. Tienes un sólo directorio de usuario para todas las máquinas. El problema vendría si las máquinas son heterogéneas y no se usa la misma versión del software en todas, pero para eso exportar /usr por NFS también es la solución.

# No se guardan las versiones antiguas de los ficheros de configuración, para poder deshacer los cambios.

Con lo que digo del /etc/programs se arreglaría ya que las configuraciones serían por paquete. En mi opinión parte de la solución la tienen los desarrolladores de la distribución que deberían hacer herramientas para controlar las versiones de las configuraciones y al crear el paquete tener en cuenta eso. En Debian creo que no habría mucho problema en ampliar la política de forma que todas las configuraciones estén más jerarquizadas.

# Hay que reiniciar los programas o decirles que vuelvan a leer la configuración después de cada cambio.

De toda la vida un kill -HUP ha servido para que relean las configuraciones. Parece que se ha perdido esa sana costumbre y no veo porqué es necesaria una infraestructura nueva. Con lo poco que tiene Unix se pueden hacer bien las cosas sin inventar nada nuevo.

[ Padre ]


Todo es posible (none / 0) (#13)
por man ls a las Mon Aug 23rd, 2004 at 12:35:36 PM CET
(Información Usuario)

No, si todo se puede hacer. El problema es que no se hace. Ni se recompilan los programas para que dejen las configuraciones de usuario en un sitio decente, ni se organiza /etc, ni se hacen herramientas para gestionarlo, ni se usan los Xresources (esto que lo explique otro que tenga más experiencia, yo conozco el problema de oídas). Y a lo mejor no se hace porque es demasiado trabajo -- mientras que una infraestructura nueva lo haría más sencillo.

Hay un punto que no he explicado bien:
# No es fácil centralizar todas las configuraciones para varias máquinas en un servidor.
Me refería no a las configuraciones de usuario, sino a las del sistema. Vamos, como si exportáramos /etc por NFS. Hay soluciones parciales como DHCP, que permite asignar direcciones IP dinámicas, pero nada que funcione de forma global.

¿Para qué serviría semejante engendro? Por ejemplo para tener un cluster de servidores web. Me dirás que en este caso se puede exportar /etc por NFS, pero como decía Manzano en La Estanquera de Vallecas, "ej que no é lo mimmo". Tienes que embarcarte en una tarea laboriosa de poner configuraciones por defecto en local, montar el directorio, luego leer las configuraciones remotas y que coincidan; cualquier cambio en la configuración por defecto y tienes que cambiar todas las máquinas.

[ Padre ]


¿Para qué quieres configuraciones locales? (none / 0) (#16)
por jorginius ("jorginius" en Google Mail) a las Mon Aug 23rd, 2004 at 08:25:09 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Por ejemplo para tener un cluster de servidores web. Me dirás que en este caso se puede exportar /etc por NFS, pero [...] Tienes que embarcarte en una tarea laboriosa de poner configuraciones por defecto en local, montar el directorio, luego leer las configuraciones remotas y que coincidan;

¿Por?, ¿para qué necesitas las configuraciones locales en ese caso? y ya puestos, ¿para que necesitas que los nodos tengan discos?.

Otras opciones son rsync de la configuración del nodo maestro, usar LDAP o NIS para centralizar cuentas y grupos, etc. Pero la más evidente es exportar /etc. Lo que planteas me parece que tiene vieja solución.

[ Padre ]


Para montar las unidades (none / 0) (#19)
por man ls a las Mon Aug 23rd, 2004 at 11:32:45 PM CET
(Información Usuario)

¿Por?, ¿para qué necesitas las configuraciones locales en ese caso? y ya puestos, ¿para que necesitas que los nodos tengan discos?.
El objeto es, por supuesto, tener las mismas configuraciones de apache.

Me baso en mi grandísima ignorancia: tendrás que tener la configuración para que el equipo medio-arranque, y luego un fstab para montar las unidades remotas, ¿no? Parece mucho mejor desde luego no tener ni discos, pero eso ya es demasiado sofisticado para mí.

[ Padre ]


No, en realidad no (none / 0) (#21)
por jorginius ("jorginius" en Google Mail) a las Tue Aug 24th, 2004 at 11:39:51 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

tendrás que tener la configuración para que el equipo medio-arranque, y luego un fstab para montar las unidades remotas, ¿no?

El raíz se monta antes que se lean los guiones de arranque (y las configuraciones) y éste lo puedes montar por NFS. En el raíz puedes colocar el /etc/ junto a los puntos de montaje (que se montaran en remoto o en local: al gusto) o puedes colocar todo el sistema de archivos y no usar sistemas de archivos locales para nada.

En realidad lo único que no pueden compartir los nodos es el /tmp, el /var, el /dev y la swap, pero lo del /dev lo puedes manejar con devfs o, imagino, udev, el /tmp y el /var meterlos en un mini-disco ram incluido en el kernel y la swap desactivarla. También haría falta un syslog-ng para centralizar todos los logs de los nodos en un mismo punto.

Para arrancar, te puedes hacer un floppy de arranque con un kernel en plan tú mismo o usar Etherboot. O ya puestos a prescindir de partes móviles, puedes grabar Etherboot en la prom de la tarjeta de red.

En el Diskless-root-NFS HOWTO tienes descrito cómo se haría. Admite mejoras pero básicamente es eso.

[ Padre ]


 
¿Y no se hace así ya? (none / 0) (#17)
por jorginius ("jorginius" en Google Mail) a las Mon Aug 23rd, 2004 at 08:36:41 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Al igual que en mi ejemplo hay un /etc/programas/nombre-version podría haber lo mismo en cada directorio de usuario.

La mayoría de los programas tienen una configuración global en /etc, que luego el usuario puede reescribir en su home mediante el pertinente ".archivo" (KDE y Gnome incluidos). El resto de los programas que no se adscriben a eso es porque no tiene sentido que cada usuario tenga una configuración de los mismos (cada usuario con una configuración diferente de Sendmail, por ejemplo).

[ Padre ]


Eso es así (none / 0) (#25)
por musg0 a las Fri Aug 27th, 2004 at 12:49:41 PM CET
(Información Usuario) http://helvete.escomposlinux.org

Pero lo que yo digo es que haya un estándar para que todas las configuraciones de los programas de /etc estén ordenados.

Lo mismo dentro de cada directorio de usuario.

Debian tiene por política meter todas las configuraciones dentro de /etc. Podrían ir más lejos y exigir que cada programa ponga sus configuraciones dentro de su directorio, al igual que se hace con /usr/share/doc.

Al final, si /etc está ordenado es un registro de esos milagrosos que parece todo el mundo está intentando reinventar.

[ Padre ]


Ok, pero no veo grandes ventajas (none / 0) (#27)
por jorginius ("jorginius" en Google Mail) a las Fri Aug 27th, 2004 at 02:01:08 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Pero lo que yo digo es que haya un estándar para que todas las configuraciones de los programas de /etc estén ordenados. Lo mismo dentro de cada directorio de usuario.

Sí, es verdad que dijiste eso. Lo lei por encima y respondí a lo que quise. Perdón :-D

Debian tiene por política meter todas las configuraciones dentro de /etc. Podrían ir más lejos y exigir que cada programa ponga sus configuraciones dentro de su directorio

Bueno, de todas formas, de $HOME puedes asumir que existe y que puedes escribir en él. Para otro directorio que pendiese de $HOME habría que comprobar por aplicación si existe o no y cuáles son los permisos antes de escribir la configuración. Tampoco es que sea mucho más pesado (eso mismo se hace en KDE con ~/.kde/) pero sí es una pequeña molestia. Por otro lado muchas aplicaciones, la mayoría, te permiten indicar dónde buscar el archivo de preferencias, ya sea por línea de órdenes o por una variable de entorno, así que puedes ordenarlo tú mismo desde ya.

Personalmente no veo diferencia entre tener un/os subdirectorio/s dentro de $HOME para la configuración y tenerla en el raíz de él. Yo no tengo en el $HOME más que algunos subdirectorios propios (lo típico: "proyectos", "cajón", "música", "correo", etc.) y los archivos y subdirectorios con la con las configuraciones (".*"), y tanto me da hacer "vi ~/.bashrc" que "vi ~/etc/bashrc" o "vi ~/etc/bash/rc".

Si lo que no le gusta a la gente es tener mezclados en el raíz de $HOME los archivos propios con los archivos ocultos de configuración, que procure mantener los suyos separados en un directorio "trabajos" o similar... Y si lo que molesta es tener que andar haciendo cd tras el login, el usuario siempre puede, por ejemplo, escribir un archivo tal que:
# .chgcd $Id$
cd ~/trabajos
Añadir al final del ~/.bashrc:
source ~/.chgcd
Y ya no pisar el raíz de $HOME para nada.

Imagino que no descubro nada nuevo pero plantar un "cd ~/trabajos" tal cual al final del .bashrc no funcionaría por razones obvias. Esto no es DOS :-D.

[ Padre ]


 
Eso es así (none / 0) (#26)
por musg0 a las Fri Aug 27th, 2004 at 12:55:45 PM CET
(Información Usuario) http://helvete.escomposlinux.org

Pero lo que yo digo es que haya un estándar para que todas las configuraciones de los programas de /etc estén ordenados. Lo mismo dentro de cada directorio de usuario.

Debian tiene por política meter todas las configuraciones dentro de /etc. Podrían ir más lejos y exigir que cada programa ponga sus configuraciones dentro de su directorio, al igual que se hace con /usr/share/doc.

Muchos programas en Debian se modifican para que su configuración caiga en /etc. Como digo ya puestos podrían organizar un poco /etc y que cada programa tenga sus configuraciones ordenadas por nombre y versión.

Al final, si /etc está ordenado es un registro de esos milagrosos que parece todo el mundo está intentando reinventar.

[ Padre ]


 
Los Xresources y RCS, ese gran desconocido (none / 0) (#18)
por jorginius ("jorginius" en Google Mail) a las Mon Aug 23rd, 2004 at 08:52:38 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Configuraciones para X. Si arranco una sesión X remota, ¿qué valores debería usar, los míos locales o los del servidor?

Evidentemente si el servidor X va a correr en tu máquina, sobre tu hardware, la configuración del servidor debe ser la local. De las aplicaciones que escriban en tu display dependerá de desde dónde corran.

Siguiendo con lo mismo, algunos programas usan Xresources y otros ficheros locales.

Eso cada vez es menos problema porque ya hay pocas aplicaciones que usen sólo Xresources: o te dan la opción de configurarlas de las dos formas o usan sus propios archivos de configuración. Ahora mismo sólo se me ocurre xedit y familia como ejemplos de aplicaciónes "sólo Xresources".

No se guardan las versiones antiguas de los ficheros de configuración, para poder deshacer los cambios.

No las guardarás tú :-D. Yo uso RCS para mantener el control de versiones de lo que hay en mi /etc. Tengo en todo momento el histórico de los cambios que he ido haciendo, puedo generar los parches, deshacer, rehacer, etc.

Sobre lo de compartir la configuración (exportar /etc) e indicarle a los programas que lean de nuevo los cambios (kill -HUP) ya te ha dicho musg0 un poco más abajo todo lo que yo podría decir :-).

[ Padre ]


Qué virguero (none / 0) (#20)
por man ls a las Mon Aug 23rd, 2004 at 11:33:15 PM CET
(Información Usuario)

Yo uso RCS para mantener el control de versiones de lo que hay en mi /etc.
Qué buena idea, me gustaría saber cómo hacerlo -- ¿hay algún HOWTO por ahí?

De todas formas, el problema sigue siendo el mismo: tienes que currártelo tú y hacer todo el montaje. Con un sistema uniforme de configuración se podría hacer automáticamente, de forma que sea fácil hasta para novatos como yo.

[ Padre ]


Pregunta a Google (none / 0) (#22)
por jorginius ("jorginius" en Google Mail) a las Tue Aug 24th, 2004 at 01:24:26 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

La verdad es que ya no me acuerdo de a quién se lo vi hacer primero pero no es que sea una idea novedosa ni rara. He consultado en Google y en Slashdot se preguntan "Linux Distros with CVS/RCS for Config Files?". Ahí se vé como la gente usa también CVS o Subversion para controlar la configuración. También hay un tip publicado en la Linux Gazette de Noviembre de 1995: RCS: Managing System Config Files.

No es que mi método sea muy complicado. Sólo uso RCS, un editor que lo soporte (por comodidad, por no andar actualizando los cambios a mano cada vez que toco algo) y un poco de Bash scripting y cron para hacer revisiones de seguridad si algo cambió y no fuimos mi editor y yo los que lo cambiamos.

Editores con soporte de RCS hay muchos pero si el tuyo no tiene puedes adaptarle algo como esto, sacado del mismo hilo de Slashdot, RCS and vim. Dice "Vim" pero parece que Vim sí tiene soporte RCS, aunque el script de /. tiene algunos pluses interesantes (más transparente, lista de que no hay que mantener bajo control, etc).

De todas formas, el problema sigue siendo el mismo: tienes que currártelo tú y hacer todo el montaje.

Bueno, en Gentoo tienen algo similar de serie, llamado dispatch-conf y tampoco es que me parezca un problema el que tenga que currármelo yo para mi problema concreto:

Esto es Unix y la filosofía de Unix es "cómo es imposible adaptarse a todo, damos las herramientas y que cada cual se construya su solución a la medida". Hay quien adora esto y otros que no. En Windows o en Mac la idea es que hay una solución adecuada para el 90% de la gente y el resto o se joden o lo tienen más crudo para montarse la suya propia. Es cuestión de ver en que porcentaje caes.

Vamos, que a mí me parece chachi que se haga un sistema de configuración como los que proponéis, siempre que no me obliguen a usarlo y lo pueda dejar todo como estaba sin traumas :-D.

[ Padre ]


Otra aproximación interesante (none / 0) (#24)
por jorginius ("jorginius" en Google Mail) a las Tue Aug 24th, 2004 at 05:34:58 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

... Es integrar el control de versiones en un sistema de archivos, y usarlo para el /etc.

El ClearCase FS (ClearCase de Rational/IBM) contabiliza de forma transparente las modificaciones que hagamos en los archivos que contiene. Si queremos consultar una versión previa, lo único que tenemos que hacer es leer "archivo@@/versión" como si leyésemos un archivo más (esos "*@@/versión" no aparecen en el listado regular de archivos y directorios). Se cambien como se cambien los archivos en ese sistema, la coherencia en los históricos no se pierde... Y para el que no quiere enredar es ideal puesto que más cómodo y simple imposible: el sistema de archivos lleva el control de versiones por ti.

Algo así es interesante precisamente para la partición con las configuraciones o para la partición donde guardemos nuestro trabajo :). Clonar el ClearCase FS (que hay para varias plataformas, includa Linux) puede ser un buen proyecto.

[ Padre ]


 
registry (none / 0) (#14)
por FidoX a las Mon Aug 23rd, 2004 at 01:21:06 PM CET
(Información Usuario) http://www.corebedigital.com

Yo creo que el registro ya lo tenemos y se llama /etc.

Hombre, pues sí. Nuestra idea es no alejarnos demasiado de /etc. Pero también queremos aportar algo, no nos basta con reorganizar el directorio.

Yo he tenido que trastear un poco con los ficheros de configuración de la glibc y aunque desde fuera no se vea, se hacen cosas un poco feas con los ficheros de configuración. No hay un API medianamente estandarizada dentro del a propia glib. Y bueno, a mi me gustaría que hubiese un api que los programadores pudiesen usar para implementar sus sistemas de configuración porque no tengas que dedicarle mucho tiempo, al fin y al cabo, solo es la configuración. No tengas que reescribir las mismas instrucciones una y otra vez, de leer y escribir en fichero, controlando los errores de sintaxis, falta de claves, etc. Algo que usen porque les resuelve la vida en ese sentido y además después queda integrado con todo el sistema.

Hay varios proyectos en ese sentido, pero nosotros pretendemos ir un poco más allá intentando buscar una organización un poco más óptima.

A mi /etc me parece bien, pero si buscaramos algo que poder hacer para mejorarlo un poco, creo que sería ésto.

Estaría bien tener todas las configuraciones de los programas colgando de /etc/programs/nombre-version-subversion/

Es más o menos nuestra idea, pero ya que vas a intentar hacer algo así, pues creas un api más o menos consistente para que los programadores la puedan usar, y optimizas un poco los ficheros para que sea más fácil de tratar.

Sobre el tema de los detalles técnicos, pues de momento estamos en una fase muy temprana y aún hay cosas que tenemos que descubrir. Pero no hemos cerrado ninguna puerta.


Israel E. Bethencourt
FidoX/CORE
[ Padre ]


 
registry (none / 0) (#15)
por FidoX a las Mon Aug 23rd, 2004 at 01:35:59 PM CET
(Información Usuario) http://www.corebedigital.com

¿Y si casca el archivo que contiene dicho sistema de ficheros? Sería tener el registro en un único fichero, como en windows, con todos sus problemas.

Bueno... Si casca el disco duro vas a tener problemas independientemente de cómo tengas organizada la información. Y un fichero de loop es bastante fácil de recuperar.

Sobre los problemas que comentas sobre el registro de windows. Realmente el problema no está en que sea un solo fichero, sino en que solo hay un método de acceso. Si metieramos el registro en un fichero binario donde solo nuestra api pudiera acceder, tendríamos un problema parecido al de windows (aunque nunca de tal magnitud, claro está). Que es, básicamente el obscurecimiento de su funcionamiento. En nuestro caso nunca llegaremos a ese punto, porque nuestra meta principal es que esté todo bien a la vista.

Un buen ejemplo, podría ser la recuperación de una clave de administrador.

La semana pasada tuve que recuperar la clave de administrador de un WinXP. Eso en linux es bastante fácil. Arrancas con un disco de rescate y modificas el fichero /etc/passwd. Si el registro estuviese implementado, el proceso sería exactamente el mismo, puedes recuperar la clave con las herramientas mínimas.

En el caso de WinXP recuperar la clave es un poco más complicado. ¿Porqué? Realmente no porque esté toda la configuración en un solo fichero. El problema es que para acceder a ese fichero son necesarios una serie de recursos de los que no se pueden disponer fácilmente. Hay que hacer un poco de ingeniería inversa para modificar el registro con cuidado de no romper nada, para una tarea tan simple como modificar la clave.

Eso en un sistema como el nuestro, en el que intentamos dejar las cosas bien claras, aparte de que es GPL, no podría pasar.

Sobre si decidimos agrupar claves por ficheros, pues evidentemente se perdería la granularidad de la seguridad. Pero, es que todo no puede ser ;)
Israel E. Bethencourt
FidoX/CORE
[ Padre ]


 
Configuraciones gráficas | 27 comentarios (27 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda