OpenSolaris 2009.06, disponible

Desde ayer ya nos podemos traer las imágenes de OpenSolaris 2009.06, en versiones para x86 y SPARC. Lamentablemente, esta última no está a la par con la versión para x86, y además requiere una versión del OBP 4.17.1 o superior, por lo que stela (mi Blade 1000) seguirá con Solaris 10 (en todo caso, si me convence la estabilidad de SXCE, podría darle una oportunidad más adelante).

Min intención es probarla en lilit (Acer Aspire One), pero para eso necesito preparar la imagen de arranque USB para meterla en una memoria. Este problema de gallina y huevo (las herramientas están disponibles para OpenSolaris) lo solucionaré desde ignis (Athlon a 1GHz con 768M de memoria y disco IDE de 80G), donde ya he instalado experimentalmente OpenSolaris 2009.06.

Es pronto para dar una opinión fundamentada, pero sí puedo decir que en ignis el arranque y detección de dispositivos es impecable; y que la instalación lleva alrededor de una hora. Sí he notado que el sistema es un poco lento comparado con stela, pero la semana que viene haré las pruebas con Fedora 11. Espero que esto me dé una visión más precisa de si la lentitud se debe a la máquina, al sistema operativo o simplemente al hecho de que estando recién instalado hay tareas iniciales que se realizan de forma transparente al usuario y que llevan su tiempo.

Ahora, lo nuevo de OpenSolaris: ZFS se instala con facilidad y nos da la posibilidad de usar la barra de desplazamiento del tiempo, pudiendo recuperar versiones anteriores de nuestros ficheros. Esto, naturalmente, requiere que activemos la copia periódica. Con la capacidad de los discos y la velocidad de los ordenadoresas actuales, es un pequeño precio a pagar en espacio y tiempo por la funcionalidad recibida. Otras cualidades menos evidentes son el sistema de paquetes IPS, estrenado en la versión anterior, y que ahora podrán ser multisistema; es decir, contener los binarios para x86 y SPARC, al estilo de lo que ocurre (u ocurría al menos) en el mundo Apple.

Para el usuario, la instalación automática de codecs multimedia y tipos de letras será una cualidad bien recibida. Para los Administradores de Sistemas, la virtualización de redes (crossbow) será algo igualmente beneficioso.

Permaneced a la escucha para más novedades :)

system

Comments (0)

Permalink

Migraciones, migraciones…

En *nix pro hacemos las migraciones de cuatro en cuatro. Porque sí. Porque podemos. Porque, cuando nos decidimos, somos imparables. Un ejército de un sólo hombre, marchando impávido hacia la victoria.

¿El motivo? Simplificación de mi infraestructura Informática: dejar a stela (Sun Blade 1000) como ordenador principal y a lilit (Acer Aspire One) como secundario. Al resto (cifer, coral, ignis y orbil), gracias por los servicios recibidos. Ya se pensará en algo para darles utilidad, pero sin prisas.

  1. Ordenador: de un PC portátil (Acer Aspire 1400) a una estación Sun de sobremesa (Blade 1000).
  2. Sistema Operativo: de Linux (Fedora 10) a Solaris 10.
  3. Correo electrónico: de Evolution a Thunderbird.
  4. Proceso de textos: de OpenOffice a LaTeX.

Vayamos por partes.

Migrar de un ordenador a otro “se reduce” a migrar los datos y los periféricos. El primer caso dependerá de si existe compatibilidad entre los Sistemas Operativos o alguna manera de convertirlos. La música, fotos y textos no requieren cambio para funcionar en todas partes, así que no hay problema. Los periféricos, hablando de un portátil y un equipo de sobremesa, se reducen a discos externos USB, que tampoco dan sorpresas siempre que se use un formato común a ambos sistemas.

Migrar a otro Sistema Operativo es algo considerablemente más delicado, pero posible si se trata de parientes, como es el caso con Linux y Solaris. En mi caso, la mayor parte de programas que uso o vienen ya con el sistema, o son de código abierto y fácilmente disponibles, o puedo prescindir de ellos (de Stellarium no, como ya dije en su momento). La operativa en modo gráfico es similar, y en modo texto requiere adaptación para ese 20% de cosas que varía. Las cosas más avanzadas siempre iban a necesitar un poco de aplicación, que por mi formación ya conozco en teoría, así que el panorama pinta bien.

Cambiar de programa de correo electrónico siempre tiene detalles (y ninguno va a ser mejor que mew, así que resignación). En este caso, ha sido una decisión voluntaria, más por homogeneizar mi operativa en casa y el trabajo (donde también he migrado por una cuestión de compatibilidad corporativa. Lo bueno de Thunderbird es que está en todas partes; aunque yo sé bien dónde quiero estar :)

Finalmente, cambiar de sistema de proceso de textos es algo más personal y traumático. He pasado tantas veces por ese trance, que siempre he buscado la manera de hacer “la última migración, la definitiva” y creí encontrarla con LaTeX. Posteriormente, decidí pasarme a OpenOffice “por compatibilidad con el mundo exterior”. He (re)descubierto que realmente no existe “el mundo exterior” :P y que si alguien quiere algo de mí en formato OpenOffice, no tiene más que pedirlo y ya me encargaré de convertirlo yo. Si es que merece la pena, claro: para leer, PDF es lo único parecido a un formato universal. Pasar de OpenOffice a LaTeX viniendo de LaTeX parece trivial, pero no lo es: mi objetivo esta vez era tener que configurar las cosas lo menos posible. Y así ha sido: usando los directorios .texmf-config (usando su estructura “oficial”, heredando los contenidos de mi anterior configuración) y .texmf-var (no he tenido que tocarlo, sólo lo usa LaTeX), las utilidades texhash y updmap (que actualizan, respectivamente, los anteriores directorios), y disponiendo el fichero .dvipsrc (este se quedó tal como lo tenía), no sólo ha quedado perfecto para la creación de documentos PDF con los tipos de letras incorporados, sino que he eliminado todas las definiciones de variables de entorno que antes necesitaba. Perfecto.

Lo dicho: en *nix pro hacemos las migraciones de cuatro en cuatro. Y nos salen bien ;)

etc

Comments (1)

Permalink

Solaris 10 05/09, disponible

La última actualización de Solaris 10 (05/09, también conocida como U7) está disponible ya desde la página de Sun. Creo que pronto mi Blade 1000 va a tener un bonito regalo :) aunque me lleve tres horas :(

ACTUALIZACIÓN: ya hay documentación en inglés.

ACTUALIZACIÓN 2: si se instala desde cero con ZFS en mi Blade 1000, sólo lleva una hora :)

system

Comments (0)

Permalink

Sun compra Oracle por -5,7 Gigaeuros

Podemos leer en El País (entre otros stios) que Sun compra Oracle^W^W^WOracle compra Sun por 5,7 Gigaeuros (aprox.). Parece que las campanas de boda con IBM acabaron en amarga ruptura, y no se sabe quién lloró más: si Sun por no saber cuál iba a ser su futuro, o IBM por no poder “librarse” de un competidor.

Ahora la cosa está más clara: Oracle, el gigante de las bases de datos, va a poder dar una solución “llave en mano” con todos los niveles cubiertos: servidor+S.O., base de datos y pila de servicios de aplicaciones (Glassfish, etc). Hay quien opina que Oracle estará tentado de deshacerse del “lastre”, pero lo cierto es que tiene en su mano una oportunidad dorada de situarse en una posición inmejorable no sólo en su sector de mercado, sino en otros donde su presencia es testimonial o inexistente, por un coste bajísimo en I+D.

Sun tiene unas tecnologías muy interesantes y un fuerte compromiso con el Código Abierto. Oracle tiene un gran producto y una visión y gestión impecables. Lo mejor de ambos mundos podría beneficiar no sólo a la empresa resultante, sino al mercado en su conjunto. ¿Vivimos en tiempos interesantes (en el sentido del proverbio chino)?

system

Comments (0)

Permalink

Sun e IBM (de nuevo): ¿campanas de boda?

Ya me he ocupado anteriormente de las relaciones entre Sun e IBM. Pero lo que ayer saltó a los medios es la posibilidad de la adquisición de Sun por parte de IBM. ¿Alguien se extraña? Veamos.

Sun ha estado últimamente acicalándose y tomando decisiones interesantes (apertura del código de Java, de {Open,}Solaris y de ZFS…) y otras algo más controvertidas (compra de MySQL, cambio del símbolo bursátil de la empresa de SUNW a JAVA, abandono de las estaciones de trabajo basadas en UltraSPARC…). Aparentemente, no hay una estrategia clara definida. En realidad, es la consecuencia lógica (o no tanto) de haber retrasado ciertas tomas de decisiones hasta momentos que han parecido más propicios. Una empresa basada en la tecnología que trata de alejarse del mundo de los servidores (donde ocupa el cuarto puesto mundial, que no es poco) y de abrazar el paradigma “SaaS” (Software as a Service) basándose en soluciones de código abierto. Un enfoque que puede ser válido, pero que se ha tomado tarde y en circunstancias económicas revueltas.

No queda totalmente claro qué sacará IBM del trato, de producirse. ¿Aumentar su cuota de mercado en servidores? Sí. ¿Obtener patentes? Sí. ¿Otro Unix? Con su AIX y Linux, no es un valor a destacar. ¿Procesadores UltraSPARC? Con los de Intel/AMD y los Power propios de IBM, no parece necesitarlos. ¿Una cartera de clientes? Tal vez, pero no creo que sea ese el objetivo. ¿Acabar con la competencia? Aparte de la bronca de los antimonopolistas, Sun e IBM juegan con valores diferentes que no tienen por qué atraer a los mismos clientes.

Sun e IBM. Dos culturas empresariales distintas. Dos enfoques para un mismo problema. De su “fusión” puede salir algo interesante. Pero también podría ocurrir que, de producirse la compra, fuera seguida por una venta selectiva de las partes que menos le interesase. En cualquier caso, yo personalmente estoy agradecido a Sun por algo que no se paga con dinero.

En un momento crítico de mi carrera, involucrarme en el mundo de Solaris y OpenSolaris, adquiriendo parte de la experiencia con máquinas de Sun que compré por internet, me hizo recuperar la fe en mi oficio. Por eso, pase lo que pase: gracias, Sun; y buena suerte.

ACTUALIZACIÓN 20090406: puede que al final, Sun haya de seguir esperando quien la saque a bailar.

system

Comments (0)

Permalink

SXCE b108 en UltraSPARC y x86: éxito parcial

Solaris Express Community Edition (SXCE) es lo último de lo último del repositorio Nevada, edición quincenal. De ahí se obtienen las distribuciones basadas en lo que se ha querido (muy ambiguamente) denominar OpenSolaris, y a las cuales pertenece la distribución insignia de Sun, Indiana.

La conclusión principal de lo anterior es que NO es lo mismo instalar SXCE b108 (build 108) que OpenSolaris 0906 b108, pues esto último es lo que se convertirá en OpenSolaris 2009.06; mientras que SXCE tiene más código (alguno, cerrado; o no abierto aún) del que aparecerá en los repositorios públicos.

La elección depende de varios factores: si necesitamos alguna de la funcionalidad de SXCE (por ejemplo, tenemos una estación Sun Blade 1000 con una tarjeta gráfica XVR-600), esta será nuestra mejor opción; si, por el contrario, nos basta con lo que ofrece(rá) OpenSolaris 2009.06 (que, además, supuestamente estará más pulido), la elegiremos preferentemente.

Bien, armado de paciencia y de sendas imágenes de DVD, me dispuse a “modernizar” (el término que usa Sun en lugar del, para mí, más habitual “actualizar”) stela, una estación Sun Blade 1000 con procesador UltraSPARC III+ (y SXCE b103); y a instalar desde cero en coral, un portátil Compaq Evo N410c con procesador Pentium III, detalle que luego se revelará importante.

Con stela, el único problema fue el tiempo de instalación (realizada en modo gráfico): desde que se contesta a la última pregunta y comienza la instalación hasta que se concluye felizmente el proceso y podemos usar de nuevo nuestro ordenador pasaron TRES HORAS. Desde luego, actualizar siempre es más lento que instalar, pero como no sea por la velocidad del lector de DVD, no me explico la parsimonia. Eso sí: en el poco tiempo que le he dedicado, he visto solucionados algunos problemas menores que afectaban a SXCE b103. Suspender (o “hibernar”, en este caso) sigue siendo una cuestión de suerte, frente a la seguridad que ofrecía Solaris 10. Pero es un precio pequeño a pagar por el aumento de funcionalidad.

Animado por el éxito obtenido, me dispuse a hacer lo propio con coral. El primer intento fue en modo gráfico, y al arrancar el sistema X, se acabó todo. Lo dejé estar, pero no había avance. Lo intenté una vez más, con el mismo resultado. La tercera vez, convencido de que realmente había un problema, lo intenté en consola de modo texto, y ahí sí que la cosa progresó.

La instalación fue considerablemente más rápida, alrededor de una hora desde el comienzo absoluto hasta el final… ¿feliz? No, pues por motivos que se me escapaban en aquel momento, se dejaron de copiar no sé qué ficheros, circunstancia de la cual me advirtió el programa de instalación. Vuelta al comienzo.

La segunda vez que lo intenté en modo texto, llegó hasta el final (otra hora), pero cuando ya iba a arrancar del disco duro, me salieron unos errores bastante feos. Buscando por internet, y sobre todo, recordando que estábamos instalando en un ordenador con procesador Pentium III, encontré lo que podía ser la causa: un error que también afecta a Solaris 10U5 y que hace que la instalación o el arranque fallen. La solución: arrancar con el depurador, poner a 1 la variable cmi_no_init y proceder con la instalación. En efecto, esta vez llegó al final sin problemas (otra hora). Arranqué desde el disco duro y ¡albricias! todo estaba allí, y en modo gráfico. Más o menos.

coral es antiguo, pero está bastante bien soportado en Fedora 10. Con OpenSolaris me esperaba una funcionalidad comparable (prometo intentar hacerlo entre Fedora 11 y OpenSolaris 2009.06 cuando ambas lleguen; y coral será mi banco de pruebas), pero no fue así. Es decir, no he llegado a saberlo, porque a pesar de cambiar la variable de manera permanente en el fichero /etc/system, me encuentro con problemas que, paradójicamente, no hay en la versión para SPARC. La tarjeta de red inalámbrica parece darme errores extraños al tratar de configurarla a mano (un SysAdmin paranoico como yo no activa el DHCP si puede evitarlo), cosa que probablemente esté resuelta en OpenSolaris b108. Sin embargo, la razón por la que gnome-settings-daemon no quiere ejecutarse de manera estable y pierde los colores y algunos iconos debe de ser muy lógica y poderosa; pero, de nuevo, se me escapa.

Decidido a intentar probar OpenSolaris b108, me traje las imágenes de DVD (ocupa unos 800Mb, por lo que no entra en un CD normal) y la destinada a una memoria USB desde genunix. Allí también hay una imagen para SPARC, pero es el automated installer, que no sólo requiere un servidor, sino que necesita el OpenBoot versión 4.17.1 o superior. Y mi Blade 1000 se quedó en el 4.16.4 de 2005. Al margen de que, probablemente, la XVR-600 no esté soportada, o lo esté sin aceleración 3D. Y yo, sin stellarium, puedo vivir. Pero prefiero no prescindir de él.

Bien, independientemente de que coral pueda o no arrancar de USB (no parece haber una opción en el BIOS, pero hay quien afirma que es posible), traté de preparar la memoria USB para, aunque sea, probar el arranque en lilit (mi Aspire One, que uso para las guardias). Imposible.

Un script llamado usbcopy nos ayuda lo que puede, pero coral no me lo iba a poner fácil. Resulta que hay que preparar la memoria USB desde {Open,}Solaris, pues le da formato e instala la versión adecuada de grub. Bien, tengo a coral funcionando, pues le copio la imagen desde la propia memoria y luego lo instalo desde allí. Pues no. Por algún problema desconocido y que me hace sospechar de los puertos USB del ordenador, fue imposible copiar los más de 800Mb al disco. Eso sí, preparé el formato y después me dispuse a copiar la imagen desde stela. usbcopy falló, pero dd es una herramienta temible :) y no me defraudó. Finalmente, la parte de instalación de grub la fuí a hacer en coral, y de nuevo me hizo desistir. Probablemente, un poco más de insistencia lo consiga, pero por hoy ya estaba un poco cansado: usbcopy no daba con el dispositivo correcto, y es una mera cuestión de nombres.

Otro día, os lo aseguro, lo probaré con más calma. Pero de momento, para mí la conclusión es clara: para UltraSPARC, SXCE; para x86, OpenSolaris. Y a disfrutarlo ;)

system

Comments (0)

Permalink

Moblin, ¿el brillante futuro de los ultraportátiles?

En estos tiempos de crisis, la gente mira más el céntimo que antes. Tal vez por eso, y tal vez porque algún día tenía que ser, se busca en la tecnología la respuesta no a “hacer más con los mismos recursos”, sino  a “hacer lo mismo con menos recursos”.

Asus abrió de forma práctica el mercado de los ultraportátiles, a medio camino entre el (al parecer) casi extinto de los PDA (absorbido por los limitados “teléfonos inteligentes”) y el boyante de los portátiles. Intel ha metido mano en estos últimos, desarrollando un completo juego de circuitos (o “chipset”, como dicen los que no saben español :). El mercado ha tratado de aprovechar esta tecnología haciendo uso de los mismos recursos lógicos empleados en sus hermanos mayores: Linux y *indows (sin olvidar a los manitas que han instalado OpenSolaris o MacOS).

Sin embargo, instalar *indows requiere más memoria y disco de lo que sería deseable para abaratar costes, al tiempo que las versiones de Linux a veces están adaptadas mediante la seria mutilación de sus cualidades. Los más aventurados han tratado de reducir los recursos que usan sus distribuciones favoritas para lograr una funcionalidad más idónea sin despilfarrar memoria o disco.

Pero Intel tiene otras ideas en mente: mediante el proyecto moblin, quiere crear el complemento lógico de su sistema físico. Tras comprar OpenedHand y adaptar su proyecto Clutter para el entorno gráfico, desarrollar ConnMan para sustituir a NetworkManager, y diversas cuestiones de arquitectura, se han planteado como objetivo principal que su particular distribución de Linux (basada en Fedora y construida actualmente con XFCE) arranque en cinco segundos. ¿Lo conseguirá?

No lo sé, pero la versión alfa 2 actualmente disponible (se espera que la definitiva aparezca en 2010) no requiere mucho más para arrancar desde una memoria USB en mi Aspire One… Creo que merecerá mucho la pena seguir la evolución de este proyecto.

system

Comments (0)

Permalink

Aspire One, el compañero del Administrador de Sistemas

Me costó elegir un ultraportátil, pero una vez realizada la elección, comenzó realmente la aventura de dejarlo a mi gusto. Y es que la vida está llena de compromisos, y el delicado equilibrio entre funcionalidad y gasto (de recursos en general) a veces no es fácil de solventar. Mi decisión final fue por el Acer Aspire One, concretamente la versión A110L (512MiB de memoria, 8GB de “disco” flash de estado sólido (SSD), Linpus Linux (práctico para un usuario de a pie)).

Hay muchas páginas dedicadas a hacer que otro Linux funcione bien en este ordenador. Yo me limitaré a citarlas para que podáis seguir mis pasos si os apetece, y para concentrarme en los cambios específicos que recomiendo si os decidís por esta pequeña joya. Le instalé Fedora 10 con Gnome, pues con él funciona prácticamente todo lo necesario a la primera (OpenVPN y módem HSDPA incluidos). Si bien es cierto que XFCE consume menos memoria, desactivando algunos servicios innecesarios se obtiene un rendimiento aceptable.

De obligada visita, tenemos los siguientes enlaces:

  • dgoodwin (entre otras cosas, la instalación desde una memoria USB gracias a unetbootin es sencillamente genial; atención a los comentarios)
  • Wiki de Fedora (muchas configuraciones)
  • Jorge Ulver
  • tnkgrl (modificaciones a mansalva)

De los pasos que describen estos enlaces, los que yo di fueron:

  • montar /var/lib, /var/tmp y /tmp como sistemas tmpfs (limitando la memoria máxima a usar en cada caso) para economizar desgaste del SSD;
  • configuraciones de los lectores de tarjetas;
  • sistema instalado en ext2 (un sistema ext3 haría demasiadas escrituras al disco);
  • /home montado en una tarjeta SDHC de 16GB (en el lector izquierdo) con sistema xfs (por desgracia, he encontrado dificultades para suspender, por lo que de momento prescindiré de esta cualidad);
  • poner el tamaño de la letra a 8 puntos;
  • usar el controlador de la tarjeta wifi que viene con el núcleo (los controladores madwifi permiten controlar el led, pero este tiene mejor comportamiento al suspender).

Después de seguir los pasos descritos más arriba, yo dí algunos más:

  • desactivar la partición de swap (aunque así perdemos la funcionalidad de hibernación);
  • actualizar todos los paquetes de Fedora 10 hasta el momento en que hice la instalación y luego sólo mientras añadían funcionalidad necesaria o corrección de fallos (por estabilidad);
  • realizar una copia imagen comprimida del SSD y guardarla en una memoria USB (en mi caso, alrededor de 3GiB);
  • hacer una instalación de Fedora 10 i686 Live en la memoria USB (si no era la misma desde la que instalamos el sistema) ;
  • copiar la aplicación flashit.exe y la imagen del BIOS ZG5IA32.FD al directorio raíz de esta memoria (espero no tener que comprobar si el procedimiento de rescate funciona).

Con esto tendremos una memoria USB de arranque desde la cual podremos recuperar en cualquier momento la configuración, datos y programas que teníamos instalados en el instante en que nos quedamos contentos con ellos. En otras palabras, nunca hemos tenido mejor “seguro de vida” informático.

Eso sí, el procedimiento de recuperación puede llevar alrededor de media hora, así que mejor que no nos haga falta: el SSD es realmente lento, y hasta las actualizaciones duran horas. Pero merece la pena: tampoco necesitamos hacerlo a diario.

platform

Comments (1)

Permalink

Fedora 10, impresiones después de un mes de uso

Migrar desde Fedora 8 a Fedora 10 es una tarea posible y casi indolora (lo he comprobado). Sin embargo, para mi portátil decidí ir directamente a la instalación desde cero, preservando mis datos, por supuesto. Quería acostumbrarme a algunas de las aplicaciones que vienen en el DVD (algo de esto contaré en mi otro diario, no tecnológico), y de paso hacer un poco de limpieza (creo que he ido actualizando desde Fedora 5 o 6, así que ya tocaba).

Fiel a su filosofía de poner lo último, Fedora 10 suspende, hiberna y acelera la tarjeta gráfica de mi portátil del trabajo (Dell Inspiron 6400)… pero con mi fiel Acer Aspire 1400, falla en las tres tareas según se instala. Anteayer realicé una actualización (las he ido probando todas) que ha dejado las dos primeras en perfectas condiciones operativas, mientras que la aceleración 3D sigue siendo deficiente, pero al menos está ahí (ATI Radeon Mobility M6). Por cierto, que el paquete “bueno” es el xorg-x11-drv-ati-6.9.0-63.fc10.i386, los anteriores 61 y 62 hacen que X se pegue el tortazo nada más arrancar GDM.

A día de hoy, todas las cosas complicadas están aparentemente funcionando. Además de las alabanzas a la red, como dije en mi anterior artículo, he de decir que desde un comienzo ha estado funcionando la tarjeta de red inalámbrica (Intel Pro Wireless 2915), además de una basada en ZyDAS 1211. Esta última no es que sea una maravilla, pero su sensibilidad a la orientación nos puede permitir una bonita “caza del zorro”. Quien no sepa lo que es, que no pregunte :P En cualquier caso, la gracia del asunto es que NetworkManager reconoció ambas simultáneamente y mostraba las redes que se captaban con cada una de ellas de manera independiente.

El resto de características, incluyendo el arranque gráfico con Plymouth (no olvidéis poner “vga=0×315″ al final de la línea de arranque si vuestra tarjeta no está soportada pero tiene modos VESA) están más que documentadas por ahí. No hablaré de la versión de Gnome o Firefox que trae de serie, pero sí de lo muy recomendable que es añadirle el repositorio yum de  rpmfusion para complementar los paquetes instalados (multimedia incluido). Gracias a ellos estoy pasando (por última vez, espero :) mi colección de CD de música a mp3, además de a flac y ogg Vorbis.

Así pues, tras un mes de uso puedo recomendar Fedora 10 para casa, para el trabajo y para el ocio… sólo me falta tener el tiempo y el espacio en disco para ponerme en serio con OpenSolaris 2008.11 y así poderlas comparar seriamente.

system

Comments (0)

Permalink

Fedora diez, un diez en la rez (pardiez)

Hace ayer justo un par de semanas tuve uno de esos días de trabajo en los que las tareas llegan espaciadas y con cuentagotas. Y, además, más tarde de la hora a la que debería salir (¿tenemos realmente horario los administradores de sistemas?). Así que, para pasar el rato, decidí actualizar mi portátil del trabajo de CentOS 5.0 (qué gran sistema; todos sabemos de quién lo hereda) a Fedora 10. El motivo principal para mí eran las mejoras en la gestión automática de redes con NetworkManager. Sólo por eso, estaba dispuesto a darle una oportunidad a Gnome y su entorno integrado de red, al que nunca me he acostumbrado.

Algunas noches (como la de ayer) nos toca hacer pasos a producción, y la verdad es que la perspectiva teórica de quedarnos sin red me producía escalofríos. Nunca nos había ocurrido, eso es cierto; pero no sólo dependemos de nuestra conexión ADSL para salir al exterior: el CVS principal también está en nuestras instalaciones, por lo que si nos quedásemos sin conexión, tendríamos que aplazar toda la operación a otro día, con las molestias que ello acarrea.

Así que, animado por la posibilidad de compartir red y servir a otros a través de una conexión HSDPA, GPRS o similar, hice copia de mis datos, instalé Fedora 10 y restablecí mis datos. Todo ello, en las pausas entre tareas de subidas a preproducción. Después de cambiar unos ajustes, o dejé todo más o menos a mi gusto. Al día siguiente me embarqué en la tarea de migrar mi correo a Evolution, para darle una oportunidad más (en el pasado lo encontré demasiado lento). Pero esa es otra cuestión.

Cada vez que alguien me preguntaba por qué me había pasado a Fedora 10 en el trabajo, le contestaba lo mismo: “por la posibilidad de compartir la conexión de red”. No imaginaba entonces que ese mismo viernes nos iba a salvar la vida (más o menos).

Teníamos una subida a preproducción, y nuestro proveedor de ADSL tuvo una avería de las grandes (que llegó a durar más de 18 horas). Había que  tener acceso al CVS desde el exterior, así como enviar las aplicaciones, además de que varios miembros del equipo necesitaban comprobar el correcto funcionamiento. ¿Qué hacer?

¡Fedora 10 al rescate! Conecté al portátil el módem USB HSDPA de Vodafone para salir a internet, conecté la red de cable para acceder a la red local y preparé una red inalámbrica compartida para que mis compañeros pudieran conectarse (afortunadamente, todos teníamos portátiles con conexión Wi-Fi). Sólo tuve que añadir a mano la ruta implícita para salir a internet, el resto funcionó gracias a la magia de NetworkManager.

El CVS seguía sin verse desde afuera, pero me pude traer los proyectos a mi ordenador y enviarlos en bonitos paquetes .tar a los servidores correspondientes. Una vez allí, compilamos los proyectos, los desplegamos (bonito palabro) y los echamos a andar como normalmente. Mientras tanto, mis compañeros probaban las aplicaciones, actualizaban las bases de datos o editaban las configuraciones para ajustar los parámetros que habían cambiado con toda normalidad, salvo que la velocidad de acceso era algo menor.

Gracias a este mecanismo, pudimos ahorrarnos tener que conectarnos el sábado para hacer la misma tarea, pero cada uno cómodamente en su casa en vez de pasar frío en la oficina un viernes desde las 16:30 hasta eso de las 20:00. Espera, al final tal vez no fue tan buena idea después de todo :P

system

Comments (1)

Permalink