Ubuntu: upgrades interrumpidos y recuperación ante desastres

Si algo sabemos a estas alturas es que la interrupción de un proceso de upgrade (cambio de versión del sistema operativo sustituyendo la existente por otra más reciente) es una fatalidad y de las chungas.

Cuando acontece tamaño desastre hay que pensar sólo en una cosa: calma…mucha calma ante todo. Y es que todo puede tener solución, al menos una de compromiso que nos asegure lo más importante: la recuperación de nuestros datos.

Un live CD de cualquier distro de Linux os puede permitir acceder al Filesystem de vuestro disco petado.  A unas malas, montar el disco como slave en otra máquina es una alternativa a contemplar si tenéis el recurso disponible. Un disco externo o el disco maestro de la otra máquina pueden ser el destino de la salvaguarda.

Como leeréis a continuación, el escenario es sobre una máquina activa. La elección de un /home y una máquina funcionando no es incongruente: bien puede ser sobre la que habéis montado el disco como esclavo, o mejor, este planteamiento de inicio os sirve para prevenir o para adelantar trabajo, y además de esta manera controláis dónde y cómo se almacenan. Si no lo veis claro, sustituid /home por la ruta de backup que hayáis decidido.

Como ya sabéis, los sistemas Linux proporcionan un punto único de acceso a la información almacenada en el sistema desde los directorios personales que cuelgan de /home, Otra cosa son los datos almacenados:

las bases de datos mysql se alojan en /var/lib/mysql, los ficheros de configuración implicados son /etc/mysql/my.cnf y /etc/apparmor.d/usr.sbin.mysqld. La idea es ubicarlas dentro de /home y para ello hay que:

  1. Parar el daemon mysqld:
    sudo /etc/init.d/mysql stop
  2. Mover el contenido de /var/lib/mysql a /home/mysql (no estará de más hacer una copia de seguridad):
    sudo cp -rpf /var/lib/mysql /home
     sudo mv /var/lib/mysql /var/lib/mysql.bak
  3. Crear un enlace suave llamado mysql en /var/lib apuntando al nuevo directorio:
    sudo ln -s /home/mysql  /var/lib/mysql 
  4. Cambiar el propietario de /home/mysql con caracter recursivo:
    sudo chown -R mysql:mysql /home/mysql
  5. Editar my.cnf y cambiar el valor de datadir:
    datadir  = /home/mysql
  6. Editar /etc/apparmor.d/usr.sbin.mysqld y añadir  los pertinentes permisos para la nueva ruta:
    /home/mysql/ r,
     /home/mysql/** rwk,
  7. Restablecer apparmor:
    sudo /etc/init.d/apparmor restart
  8. Restablecer el servicio mysql:
    sudo /etc/init.d/mysql start

Ahora tenemos todos los datos colgando de un directorio que controlamos: puede ser nuestro directorio personal o si nos movemos en entornos corporativos, unidades de red NAS o cualquier tipo de sistema de archivos remoto con el que podamos comunicar a nuestro servidor. El procedimiento sería el mismo.

Ahora tenéis casi todo lo que importa dentro de una ruta que controláis y que podéis copiar para luego sustituir una vez machacado el viejo filesystem por la nueva re-instalación, en caso de que la cosa no tenga remedio.  Si tenéis webservers sobre apache con instalación estándar,  hablamos otro día de cómo proceder 😉

Poco más. Espero que podáis utilizarlo con éxito en caso de desastre. Saludos calamares

Advertisements

Pero… ¿Por qué se empeñan en comprar un Mac?

LLevo unos años intentando encontrar una explicación -tecnológica- a este fenómeno, creciente al avanzar en la flecha del tiempo…y no he conseguido encontrar nada que me convenza, nada que no sea producto de la evangelización de estos usuarios…

Y es curioso, porque parece que va la marcha de lo superfluo, de la cáscara, del envoltorio… lo cool es el papel del caramelo y eso es ridículo, pero no importa, ya se encargarán los del marketing en convencer a los suyos de que han adquirido a un precio astronómico algo que es exclusivo y poderoso.

Y sigo preguntándome ¿Qué cXXX hace un Mac que no haga un Linux gratis? Que alguien me lo cuente porque reconozco que estoy perdido: no puede ser que cada vez más usuarios de PCs opten por la solución más aislada y aislante y, por supuesto, la más cara.

¿Será por esto? ¿Porque, pardillos, seguimos creyendo que lo caro es sinónimo de lo mejor? Casi seguro que ésta es la razón principal. Apple ha optado por una estrategia que aisla su software porque además de su propio sistema operativo (un Unix tuneado…), desarrolla una estrategia de hardware privativo, only for our eyes, que blinda el ecosistema. Pues bien, aún así los creyentes se van de cabeza a una plataforma restrictiva porque, bien desconocen, o bien conocen y están dispuestos a obtener de forma ilícita  el software que necesiten.

Los del marketing hacen de las suyas y promueven leyendas urbanas como la inmunidad a los virus, o la interoperabilidad a base de hipervisores -propietarios- (manda guevos), y siempre comparando con la competencia que, mira por donde, hasta me empieza a caer bien: windows es privativo y producto de masas durante ya décadas con la rémora pegada de la compatibilidad hacia atrás, pero al menos NO es hardware privativo.

Lo de Linux no aparece, porque ahí es donde el usuario no evangelizado podría comparar y ahí es donde los de Cupertino se ponen nerviosillos porque lo mismos les pillan vendiendo humo: vuelvo a repetir ¿Me dice alguien qué hace un Mac que no haga gratis un Linux?

Más leyenda urbana: las design power stations son Apple por bemoles y así el baranda de turno ya tiene justificado el pantallón de 30″ y un hardware para el procesamiento gráfico pagado a precio de oro…de oro sí, porque ese mismo hardware te lo pillas y te montas una estación gráfica de narices me juego el meñique que por la mitad al menos.

Eso sí, donde los creyentes se desesperan, y ni os cuento los del Servicio de Informática que los sufran, es al compartir red y periféricos comunes: el tema de los drivers de imprsoras y escáneres de red es algo que no tiene nombre, y que nadie les explica a estos creyentes antes de comprar la monería: como te coloquen una impresora de ese año o un escáner medio modernete, de utilizarlo nada: los usuarios windows tienen su driver de fábrica, los linuxeros se lo hacen ellos mismos, pero los maqueros…crudo lo llevan hasta que Apple decida entregar las especificaciones al fabricante y éste a crearlo.

El ecosistema se completa con virguerías como IPad o IPhone (seguiré pensando en él como un ladrillo por más que lo mire: es enorme, no cabe en el bolsillo, hace fotos, hace fotos, tiene internet a precio de oro, hace fotos, reproduce música, hace fotos), preciosidades que son como el guerrero del antifaz: “Santiago y cierra España”, y cerrado queda el chiringuito. Si quieres chicha, te pasas por la AppleStrudel 🙂 y te retratas pero no importa, que para eso eres del taco y  tu lo vales.

Un servidor, linuxero por más señas, asiste estupefacto al espectáculo y sonríe cuando necesita un software y en 5′ lo tiene de manera lícita y gratuita en su PC, cuando actualiza la versión de su sistema operativo sin coste alguno, cuando virtualiza máquinas para probar entornos que puede exportar a otras plataformas (salvo la de Apple), cuando monta servidores colaborativos sobre software libre y da servicio a todos los usuarios, maqueros incluidos…es otra historia, otra filosofía y sobre todo, más robusta y barata, (aunque el S.O. no haya sido diseñado ex-profeso para un hardware concreto) pues La Comunidad anda por ahí para dar soporte al que lo necesita.

Saludos calamares.

PS: Tenéis dudas? Echadle un ojo a la página de Microsoft:

Una mínima arquitectura de sistemas para grupos apoyada en la virtualización de escritorios (y II)

Una mínima arquitectura…(Parte I)

El caso real es éste: un director de un grupo de trabajo solicita asesoramiento para la adquisición de un servidor de archivos con espacios de trabajo para el grupo y espacios privados o restringidos, ademas de la conexión con equipos de escritorio ya existentes -los existentes en el grupo-  y otros por adquirir. El uso no será intensivo, pero los sistemas operativos del grupo son esencialmente heterogéneos: desde la familia Windows a las variantes MAC OS. Los equipos trabajan dentro y fuera de la sede, en cuyo caso el acceso es obligatoriamente la VPN corporativa. En todos los casos los clientes poseen una asignación dinámica de la dirección de red. Por último, señalar que se dispone de una infraestructura de almacenamiento corporativa que puede ceder cierta cantidad de espacio altamente securizado (sistemas RAID de doble paridad).

Requisitos funcionales: (RF)

  • EL cliente necesita un servicio de almacenamiento de ficheros interoperable (Windows, Mac, …linux??) que permita a los miembros del equipo acceder a la documentación almacenada, así como poder guardar documentos de uso común o de interés general para el trabajo de equipo.
  • También solicita un terminal de usuario (o varios) capaz de poder acceder a esos recursos compartidos, y simultáneamente poder almacenar la documentación privada, de manera que sea posible la securización posterior mediante copia remota o algún mecanismo de salvaguarda equivalente.
  • La arquitectura deberá contemplar la posiblidad de salvaguarda y archivado de la documentación de los espacios de almacenamiento comunes y del espacio privado.

Requisitos no funcionales: (RNF)

  • La arquitectura propuesta debe ser plenamente accesible desde la red corporativa, pero con niveles de privacidad suficientes.
  • La arquitectura debe ser confiable, tanto en lo referente al hw como al sw de base (el MTBF -Medium Time Between Failures- debe tender al mínimo)
  • Es de desear que la latencia de puesta en marcha ante averías (MTTR -Medium Time To Repair) también sea mínima
  • La solución debe ser escalable
  • La arquitectura debe posibilitar un backup simple, al igual que el posterior proceso de archivado

Solución propuesta:

  • Adquisición de un servidor dual core -mínimo- con 4GB de memoria RAM y con implementación RAID (preferentemente RAID 5, asumible RAID 0 y posterior resinronizado y/o archivado) sobre el que se instalaría un Sistema operativo de servidor (Ubuntu server 64 + X) -el anfitrión o Host- y un sw de hipervisor (virtualización completa) que servirá de base para la gestión y monitorización de dos máquinas virtuales, una con Windows XP y otra con Ubuntu Desktop (Lucide Lynx) -los invitados o guests-.
  • Configuración de un segmento de red virtual que unira a host y guests con el resto de la red corporativa.
  • Los espacios de almacenamiento se proponen sobre el propio anfitrión: se creará un volumen común sobre el que se almacenará separadamente los archivos privados de las VMs guests, y los archivos de uso compartido entre éstos y el resto de host físicos de los miembros del equipo.
  • Los protocolos de acceso serán CIFS-SMB para los archivos del equipo de trabajo, y los accesos compartidos que Oracle VirtualBox -la solución de virtualización elegida- implementa entre el host y los diferentes guest -carpetas de uso compartido- para los archivos de uso privado.

Los servicios a implementar en el host:

  • Samba (sudo apt-get install samba samba-common smbclient system-config-samba winbind nautilus-share resolvconf)
  • Acceso por terminal remoto: VNC y RDP (Terminal server) (sudo apt-get install vncserver)
  • ssh
  • VirtualBox
  • Interfaces virtuales de red + bridge

La configuración del sistema de archivos: Un espacio compartido (/home/compartidos) sobre el que se crean dos subespacios, pub y private. Se habilita la compartición CIFS -rw- para pub y sólo para los miembros del grupo -vgrupo-, que deberán estar convenientemente registrados como usuarios en el smb.conf -comando smbpasswd -a-. Private debe ser de libre acceso para virtualbox. Destacar que el host SOLO se dedicará al soporte de la infraestructura de virtualización. COn esto se consigue una mayor limpieza en la arquitectura y se facilita la sencillez y comodidad en las tareas de respaldo. Existen por tanto 3 puntos de respaldo, o uno (o dos) sólo si se quiere -si los discos virtuales se crean físicamente dentro de /home/compartidos, lo que va en beneficio de la cohesión pero en detrimento de un respaldo sobre el sistema de almacenamento corporativo, que de momento no puede asumir el backup de los vdis-. Los tres puntos serían:

  • Punto de montaje del disco duro de la VM on Windows XP
  • Punto de montaje del disco duro de la VM con Ubuntu Desktop
  • /home/compartidos

Respaldo (y archivado): Se deja en el aire, con 2 propuestas: Rsync + archivado externo si el espacio se dimensiona por encima de los 25GB. Si no, cabe la posibilidad de almacenamiento sobre RAID-dp creando un export NFS en nuestra cabina de almacenamiento NetApp y montándolo en el anfitrión como /home/compartidos Ventajas e inconvenientes: Ventajas:

  • TCO (Coste Total de la propiedad) muy bajo: un sólo equipo físico proveera los servicios de un servidor de archivos y dos equipos de escritorio.
  • Portabilidad asegurada: las máquinas virtuales no necesitan un sistema operativo en concreto ya que se instalan sobre el hipervisor, que puede correr tanto en Linux como en Windows y Mac (MAC OS 10.4 mínimo).
  • Simplificación de los puntos de respaldo: 3 o sólo 1, con la seguridad de abarcar todo el ámbito de la salvaguarda de los datos.
  • MTBF -Medium Time Between Failures- y MTTR -Medium Time To Repair- que tienden a reducirse: el primero al elegir un sw de base Linux, que minimiza la entrada de malware así como es mucho más inmune al mismo, orientado a sistemas Windows, mucho más comunes. La reanudación de los servicios asociados a las máquinas virtuales tras un deterioro grave de los mismos se reduciría a restaurar un archivo -el disco duro de la máquina virtual-; si lo que ocurre es el deterioro del propio anfitrión, se puede reanudar sobre otro hipervisor instalado sobre cualquer otra máquina física -o virtual-
  • Escalabilidad: ante nuevas necesidades, tales como el acceso de nuevos usuarios o la creación de nuevas máquinas virtuales, la arquitectura es perfectamente escalable, si bien el límite de VMs simultáneas viene dado por el nº de núcleos del procesador (2).

Inconvenientes:

  • Mayor complejidad de la arquitectura: asumible por el Servicio de Informática
  • Mayor complejidad en la configuración del servidor: asumible por el Servicio de Informática

Trastear con pdfs en Linux

Circunstancias indirectas aunque no demasiado ajenas me han obligado a bichear dos procedimientos en los que intervenían documentos pdf. Cosas de la e-administración…

El caso es que me encontraba ante la disyuntiva de tener que instalar sw para la edición de documentos escaneados en la máquina virtual de WXP o buscarme la manera desde Linux. Es obvio que ya sabes por qué me terminé decantando.

Googleando -todavía no les he dicho nada a estas criaturas, ni a los bonstruos de yahoo tampoco, sobre lo que pienso de su política en paises como China…me reservo un post más adelante pero ya desde aquí les cubro con toda la mala baba que puedo- conseguí conocer 2 herramientas la mar de útiles: imagemagick y pdftk, ambas para su ejecución en modo consola.

imagemagick es una aplicación que sirve para crear, editar y componer imágenes. Puede  además leer, convertir y guardar imágenes en una gran variedad de formatos, y esto último es lo que me interesaba. Pero es mucho más que eso, pues es capaz de crear, editar, componer y transformar archivos de mapas de bits. Además, proporciona APIs para la mayoría de los lenguajes de programación más usuales. Se puede ver más info aquí

Dado que se encuentra en el repositorio de Ubuntu, para los usuarios de ese sabor de Linux es aún más sencillo: tan solo hay que descargarlo además de GhostScript:

sudo apt-get install imagemagick gs

Para poder convertir un jpg en pdf, an sólo hay que ejecutar:

convert miImagen.jpg miPdf.pdf /* No es mu complicao, verdad?*/

Repito: imagemagick es muucho más que esto, y hay que bichearlo con detenimiento, pero quédate en la cabeza la asociación de modificación de una o varias imágenes con este set de herramientas. Puedes ver ejemplos aquí.

La otra herramienta, pdftk -también disponible en el Canonical de Ubuntu- es muy sencilla de utilizar:

pdftk pdf1.pdf pdf2.pdf pdf3.pdf…pdfN.pdf output pdfSalida.pdf

Crea un nuevo pdf a partir de la secuencia de parámetros de entrada, pero cosa curiosa: si somos cuidadosos y nombramos a nuestros pds de origen de manera secuencial, se puede emplear una variante que el comando reconoce y produce una salida ordenada. Suponiendo los nombres de los pdfs de entrada de antes:

senegalensis:~$ cd carpetaConLosPdfs

senegalensis:~/carpetaConLosPdfs$  pdftk *.pdf output pdfSalida.pdf

La salida es un pdf construido según el sufijo ordinal de los pdfs de la carpeta en cuestión.

Saludos calamares.

Cliente vnc para sistemas Linux y servidores Windows inversos

Este post viene a solventar un tema que me ha traido un tanto liadillo, y se encuadra dentro de un sistema de soporte a usuarios con asistencia remota, soporte que no hubiese conocido sin ayuda de mis culturetas colegas Salva, JaviR y JaviG, a los que aprovecho para saludar como se merecen: cuadrándome  😀

(Saludos a toda la peña cultureta XDDD…)

Los sistemas VNC inversos, excelentemente descritos en el link, permiten la conexión a voluntad entre usuarios de los diferentes sistemas de información de la Organización y el servicio de soporte, solventando 2 de los principales problemas de una infraestructura de red corporativa estándar: la asignación dinámica de IP a los usuarios, que impide que el técnico conozca la dirección concreta donde levantar un servidor vnc, y de paso, la cuestión de privacidad que siempre genera susceptibilidades, debido a que éste es un sistema que al contrario del vnc estándar o directo, delega en el usuario el establecimiento y fin de la conexión.

La conexión entre servidores (usuarios) y clientes (soporte) cuando los sistemas son windows es trivial, puesto que no se trata más que de crear el .exe del servidor “one click” enviando a una dirección url un pequeño archivo de configuración modificado por  nosotros (Ver aqui) y listo. Pero cuando el cliente vnc hay que utilizarlo desde una máquina Linux, la cosa cambia.

Después de mucha guerra y googleo, parece que los clientes VNC más usuales no soportan levantar la interfaz gráfica cuando se conectan en modo pasivo (Reverse Mode) con el servidor VNC  “De un sólo click” o servidor inverso,  como los que tenemos para ubicar en las máquinas de nuestros usuarios.

Así, xvncviewer, vncviewer y demás consiguen la conexión (netstat -an |grep tcp) pero no levantar la interfaz gráfica…una putada.

Menos mal que existe un cliente que sí que lo hace: se llama tightvncviewer y es accesible desde la URL:

http://downloads.sourceforge.net/ssvnc/ssvnc_unix_only-1.0.22.tar.gz

y su instalación no es complicada. No ay más que descomprimir la carpeta, moverla a una ruta del path (/usr/local/bin por ejemplo), crear ahí mismo enlaces simbólicos a los archivos de ssvcn/bin que comienzan por t ó s :

ln -s ssvnc/bin/{s,t}* .

y lanzar en modo listen el cliente:

tightvncviewer -listen

Entonces sí, XDDD, sí que podemos acceder a las máquinas de los intrépidos usuarios.

Saludos calamares.