Libertonia || Comments || Configuraciones gráficas


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Configuraciones gráficas | 27 comentarios (27 temáticos, editoriales, 0 ocultos)

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 ]

Configuraciones gráficas | 27 comentarios (27 temáticos, editoriales, 0 ocultos)

Menu

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

Login


Nueva cuenta
Usuario:
Contraseña:

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