lunes, 4 de julio de 2016

La belleza de KVM y virt-manager

Luego de varias actualizaciones, me encontré con la belleza de necesitar conectarme a mis máquinas virtuales usando "virt-manager", y me topé con el hermoso mensaje:

libvirtError: authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'

La cuestión es que en medio de estas actualizaciones, hubo una de seguro que no tuvo en cuenta algunas cosas. Mi usuario debiera ser administrador de KVM, pero no lo veo en el grupo "kvm", entonces decidí agregarlo como en la vieja escuela: tocando /etc/group, buscando el grupo kvm, y agregando mi usuario allí.

Pero con eso no alcanza. Se deberá agregar un archivo llamado "/etc/polkit-1/rules.d/49-org.libvirt.unix.manager.rules", con el siguiente contenido:

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("kvm")) {
            return polkit.Result.YES;
        }
});

Listo, luego de haber relanzado algunos procesos, pude conectarme tranquilamente.

LA EXPLICACIÓN

Generalmente esta sección será obviada por todo el mundo, y sólo cuando encuentren más problemas quizá vuelvan para acá. Pero debo explicar un poco de esto, así que allá vamos.

Según su página oficial, polkit es una forma de entregar permisos privilegiados a procesos no privilegiados. Sudo lo podría hacer, todo el mundo pensaría...pero lo cierto es que polkit los asigna a niveles atómicos, permitiendo mayor control todavía que con sudo. 

Como cada día estamos más cerca de volvernos desarrolladores web cuando lo que queremos es gestionar un GNU/Linux, polkit maneja sus reglas de autorización usando un lenguaje muy de la onda Javascript, ubicados en /etc/polkit-1/rules.d. Tal como lo hicimos nosotros. Aviso: cuando el /etc/passwd se deba escribir con tags HTML, me paso a otro sistema operativo. 

Qué es lo que hicimos en nuestro caso? Le dijimos a polkit que si la action.id es org.libvirt.unix.manage, que es la que nos está generando el error, y el que lo invoca está en el grupo "kvm", que es al que nos hemos agregado, entonces el resultado es una hermosa autorización. Sencillo, no? Así de fácil es manejar la seguridad de nuestros equipos ahora. A disfrutarlo...

domingo, 3 de abril de 2016

VLC 2.2.2 en Manjaro

Para los sufrientes amigos de los videos y demás yerbas multimedias que usan el viejo y querido VLC, habrán notado que luego de la última actualización (este post es del 02/04/2016) este programa no levanta.
Si lo ejecutan desde línea de comandos encontrarán el mensaje:

[hecsa@sdf1 ~]$ vlc
VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
[000000000062d148] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
Segmentation fault (core dumped)

Y si lo ejecutan en modo verborrágico:

[hecsa@sdf1 ~]$ vlc -v
VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
[0000000000c7b148] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/visualization/libprojectm_plugin.so' (libprojectM.so.2: cannot open shared object file: No such file or directory)
[0000000000c7b148] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/visualization/libgoom_plugin.so' (libgoom2.so.0: cannot open shared object file: No such file or directory)
[0000000000c7b148] core libvlc warning: cannot load module `/usr/lib/vlc/plugins/codec/libtwolame_plugin.so' (libtwolame.so.0: cannot open shared object file: No such file or directory)
[0000000000c7b148] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
Segmentation fault (core dumped)

La solución? Bien sencilla: hay que instalar algunos paquetes que los genios que armaron el instalable del VLC no pusieron como dependencias: 

[root@sdf1 ~]# pacman -S community/projectm community/projectm-jack community/projectm-libvisual community/projectm-pulseaudio community/projectm-qt community/projectm-test community/libgoom2  community/twolame 

Luego, abrimos de nuevo el querido VLC, y funciona. Los espero en la próxima entrega de "los garfios mágicos".

domingo, 20 de marzo de 2016

Windows 10 muy lejos de la empresa

No suelo embarcarme en discusiones del estilo "GNU/Linux vs. Windows" ya que dejé ese capítulo hace varios años. De hecho, pensé que las bases tecnológicas de este tipo de discusión formaban parte del maletín cultural de las personas cercanas al mundo de IT, y que por ende, no tenía más sentido.
Pero por cuestiones laborales tuve en suerte el tener la primera homologación de Windows 10 para un entorno corporativo, y con esta tarea, comenzaron las sorpresas. Como consecuencia de un proyecto de este estilo, me siento comprometido a compartir algunas de las impresiones que me llevaron a pensar en este nuevo sistema operativo de M$ como algo más orientado a un celular o un tablet, y ni en chiste al mundo corporativo, considerando inclusive elementos importantes, como ser la integración de entornos, o la interfaz común entre ellos.
El proceso de homologación comienza como siempre con los pasos necesarios para realizar la instalación, y la validación sobre la compatibilidad de las máquinas existentes en casa de un cliente para albergar el SO, incluyendo detalles sobre disponibilidad, estabilidad y mantenibilidad de drivers, y los programas circundantes.
Aquí la primer sorpresa. No todas, ni tampoco la mayoría, pero sí varias de las máquinas existentes, que soportaban Windows 7, tienen problemas con sus drivers para Windows 10. Y cuando digo problemas me refiero no a que no existan, sino a que luego de implementados requieren de verificaciones varias por haber problemas que llevan a que la máquina se rebootee.
Literalmente un desastre, porque uno prefiere saber que algo no está soportado, a encontrarse con la sorpresa de que se le cae la máquina por un bug que sólo se descubre cuando una falla aparece. Al comunicarnos con el soporte Gold de M$ encontramos que la respuesta es "es cierto, no funciona con tal o cual pieza de hardware, el driver no está aún estable". En particular, hemos juntado varias preguntas para ser volcadas al soporte en cuestión, siempre hablando del Gold.
Una vez analizados esos inconvenientes, y acotada la cantidad total de máquinas que pueden recibir este nuevo SO, nos encontramos con varios problemas de seguridad bastante fuertes, que no sólo que no están resueltos, sino que ni en el soporte oficial ni en algún foro perdido pudieron ser superados.
Por ejemplo, M$ Edge es considerado inseguro, y por ello si alguien genera un usuario local en una máquina, y decide ingresar con él y abrir dicho programa, recibe un mensaje interesante, mencionando que no se puede con esa cuenta. Sí, el usuario no es guest, ni nada de ese estilo.



Al hablar con el soporte (remarco, Gold), nos mencionaron que ese problema está reportado, y que no se va a solucionar porque M$ Edge es considerado inseguro.
Y lo mismo pasa con otros elementos que sorprenden por ser de los usados normalmente por un usuario local, como ser el cambio de hora en el reloj, o los gadgets que aparecen al abrir el menú que sería de "Inicio".
Todo esto ocurre con el equipo recién instalado, y sin incorporarlo a dominio alguno.
Entonces comenzaron las pruebas insertándolo a un dominio prexistente, tanto AD como Samba-NT, ya que se debe homologar para ambos casos.
Para el caso de AD, uno de los primeros problemas encontrados consistió en que un equipo agregado al AD, luego de ingresar con un usuario de dominio, comienza a pedir la clave de dicho usuario y lockear la pantalla, aún cuando el tiempo de lock no se haya alcanzado. Algunas veces la deslockea, y otras veces no, por lo que si hay alguna política de lock de claves por reintentos fallidos (como las hay en la mayor parte de las empresas), el usuario termina lockeando invountariamente su cuenta, aún cuando haya ingresado bien su contraseña. En este caso es necesario acceder al servidor de dominios y deslockear dicha cuenta para que se pueda seguir trabajando. La respuesta de soporte Gold? "Ya está reportado, y no hay una solución inmediata al tema". No es terrible, pero implica que un usuario genere un ticket, y que el sysadmin lo resuelva reactivando la cuenta. Supongamos una hora de trabajo, y una o dos horas sin poder trabajar por parte del usuario final. Y eso si el usuario no está de viaje por alguna región exótica del mundo, donde una llamada signifique una diferencia de ocho horas, por ejemplo.



Otro issue encontrado es que aún cuando el servidor de dominios sea Windows 2012, pueden aparecer problemas al mapear unidades de red compartidas cuando se intentan montar automáticamente por medio de logon scripts. Para resolverlo hay que tocar algunas claves de registry, y sale funcionando. Nuevamente, un par de horas de máquina sin producir, y alguna hora de sysadmin. Eso por cada máquina.
Si todo lo anterior parece sacado de un libro de fantasías, lo mejor viene cuando se quiere ingresar a un viejo dominio Samba-NT (Samba 4 en modo NT, no AD), momento en el cual hay que cargarle varias claves de registry para que no nos reporte que no hay servidor de dominios, otro tanto para que soporte los nuevos roaming profiles, y otros tantos rebooteos y cambios para que realmente funcione de manera medianamente estable.
Calculé el tiempo de implementación en una hora, para el SO básico, media hora por los patches iniciales, media hora para cambiar claves de registry para su ingreso en el dominio, otra media hora para las siguientes modificaciones de registry, y como me levanté con el corazón dulce, dejo en sólo una hora el marcador para todo lo demás. Y ojo, no estoy considerando implementación de Office, y demás herramientas.Eso implica unas tres horas y media por puesto.
Claramente, mi informe final trató de plasmar todo esto, y llegamos a lo siguiente:


  • Implementar M$ Win 10 significa, en casos de AD, unas dos horas de implementación, y unas dos a tres horas de soporte mensuales al menos hasta que aparezcan patches para todo lo que nos fuera reportado como "ya lo sabemos, y no hay solución".
  • Implementar M$ Win 10 significa, en casos de NT-Domains, unas tres horas y media por puesto.

Entonces, pensándolo para una empresa de unos cien puestos (100 PCs), que no es una gran cantidad, ni nada que se le parezca, caeríamos en un overhead de unas doscientas horas de implementación, y unas trescientas horas de soporte, para que quede algo estable. Para el caso de NT-Domains, tenemos unas trescientos cincuenta horas de implementación.
De lo anterior llegamos a que un proyecto de despliegue de este nuevo SO significaría, entonces, contratar por lo menos tres personas extra en el equipo de IT. Al menos por el tiempo que se esté desplegando el SO.
Luego tenemos otros temas, como ser las configuraciones de actualizaciones automáticas, seguridad, cada paquete de oficina, y demás, de lo que cual no tiene mucho sentido hablar aquí, ya que es lo mismo que venimos haciendo hace años.
Agradezco a M$ los intentos por aumentar la ocupación en nuestro rubro de IT, pero no es ésta la forma...termina en un costo extra para empresarios que no conocen mucho del tema, y deciden adquirir las nuevas licencias casi a la fuerza, y con la promesa de que "si no te gusta, te vestís y te vas"...
Por estos elementos, y por la increible desprolijidad en la entrega de un SO que pareciera haber salido del horno un tiempo antes de estar cocido, creo que está aún bastante lejos del mundo corporativo, y no lo veo evolucionar tampoco demasiado en el mundo móvil. Veremos qué nos depara el destino en este sentido, y recordemos que siempre tendremos a nuestros amigos, los pingüinos, los diablillos, o los soles, que se implementan en pocos minutos, se mantienen estables en el tiempo, no requieren antivirus, y su licencia puede ser GPL. Y en una de esas, hasta logramos que nuestro sysadmin amigo sonría...

[Agregado] Hoy me encontré con la belleza de que ya varios son los sitios que no soportan Windows 10. El que más me preocupó, al menos por ahora, es el de Webex, que al accederlo nos muestra esto:



Por lo tanto, si tu usuario pide Windows 10 y quiere mantener reuniones con Webex, estamos en problemas...


sábado, 9 de enero de 2016

Breve review de las laptops que usé en mi vida

NOTA: Si no sos de los que les gusta leer mucho, acercate a la parte de abajo de este artículo, a su conclusión. Si querés entender el por qué de esto, seguí leyendo de arriba para abajo, como siempre.

Hoy desperté y recordé que tengo una máquina muy vieja y chica sólo funcionando como filtro de correo. Casi como si fuera nueva me acerqué para ver cómo estaba, y si necesitaba actualizaciones, ya que no la toco desde hace siglos.

Allí estaba, funcionando como si nada, con una tonelada de tierra encima, la pantalla con más suciedad de lo que cualquiera podría imaginar en una laptop, que en este caso es una netbook.
Mientras le bajaba los mil patches que necesitaba para estar actualizada, comencé a recordar las máquinas que me acompañaron en mi vida, y decidí que no sería mala idea hacer este review como para tener una idea general de cómo funcionaron.

La primera fue una Texas Instruments viejísima, que creo que no contaría en el review, ya que no tiene ni por las tapas las características de las que hay ahora.

Esa máquina funcionó relativamente bien, aunque tenía su buen peso (en esa época, más de quince años atrás todas eran pesadas), y un mecanismo un tanto extraño para intercambiar la diskettera con la unidad lectora de CDs. Decidí ver si aún la tenía entre mis cosas, y efectivamente, allí estaba. Su batería ahora no dura más de media hora, pero aún vive. No tenía tarjeta de red, pero le agregué una junto a un módem para conectarme a Internet.

La que tuve inmediatamente después fue una IBM Thinkpad 600, la que para mi sorpresa aún está en un rincón de la casa de mis padres. La encendí, y luego de explicarle a su BIOS que ya no es el año 1976, y ver que comenzó a cargar su batería, quedó funcionando.

Levanté el mail, le configuré mi cuenta actual, y funcionó aún con los viejos programas que tenía ese antiquísimo Slackware que estaba instalado. Y funcionó todo. Hasta levanté archivos adjuntos en formato Word, que abrieron el StarOffice que tenía (el antecesor del OpenOffice, que es el antecesor del LibreOffice).

Cuando la desenchufé, la batería aguantó casi cuarenta y cinco minutos. No tiene WiFi, pero la usé con una tarjeta PCMCIA WiFi, y todos felices.

Luego, tuve una IBM A22m. Literalmente, era el Ford Falcon de las máquinas. Como gran innovación, aparte de tener una pantalla de 14', tenía diskettera, lectograbadora de CDs, lectora de DVDs, y UN puerto USB. Esa ya no la tengo, porque luego de haber compilado cantidad de kernels de Solaris Express para el proyecto Indiana, lo que luego sería OpenSolaris, la vendí a alguien que cuando vino a retirarla por mi casa recuerdo que me preguntó si era nueva, porque tenía su teclado perfecto, la pantalla sin un mínimo pixel quemado, su batería duraba una hora y media, y todo, pero todo, andaba bien.

Luego recuerdo que una persona que viajaba bastante me comentó que estaba trayendo unos equipos de una marca rara llamada Lenovo, y que como usaba sólo dos, podía traer tres y venderme una de esas máquinas a mí. Esa fue mi primera Lenovo, de la vieja época, que tenía un interesante teclado con algunos símbolos en japonés, así como su BIOS, y un maletín que creo, fue el mejor que tuve en mi vida entera. Su pantalla tenía una definición infernal: 1280x1024. Tenía lectora de DVDs, y una innovación interesante que no pude usar sino hasta que comenzaron a venderse por acá Access Points: tenía WiFi incorporado.

Cuando la vendí el comprador me preguntó lo mismo, si hacía poco que la tenía, porque estaba, literalmente, con el teclado perfecto, y su batería duraba casi dos horas.

Al vender esa máquina compré una HP Pavilion DV5000. Pantalla grande, Windows Media Center preinstalado, un teclado más que decente, lectograbadora de DVDs, WiFi, etc. Esa máquina aún la tengo, claramente apagada. Su batería, que en un principio duraba dos horas, comenzó a durar cada vez menos, hasta que se quedó en algo así como unos cuarenta y cinco minutos. También fue laboratorio del ya ahora existente OpenSolaris, y luego de experimentos varios con Illumos.

Un detalle: el circuito de refrigeración siempre tenía problemas, y tuve que desarmarla para sacarle pelusas mil veces. Recuerdo por lo menos unas cinco veces, porque cuando subía la temperatura, se apagaba sola. Yo en el medio de una edición de un documento, y la maldita se apagaba.

En el medio, y por cuestiones laborales, tuve una Dell D600. Lindo bicho, con una batería que no duraba más d euna hora y media, un teclado que parecía que se iba a romper, pero no terminaba de hacerlo, un puerto USB, y tornillos que cada tanto se salían solos. Levantaba la máquina y veía cómo se caían. Muy bien armada, ja!

A esa máquina, y por temas laborales también, la sucedió una Dell 630. También lindo equipo, pero con la batería que cada día parecía funcionar peor. Un buen día me llegó un mail de Dell avisando que la batería por un problema de diseño podría explotar, por lo que me mandarían una nueva. Y así lo hicieron. Literalmente, el mejor servicio al cliente que uno pueda imaginar. Incluye hospital de quemados...

Luego de esa máquina, adquirí una HP 2133 mini, ya que quería una máquina con el formato netbook, pero con un teclado que sirva para algo. Y esa máquina, un lujo de puro aluminio, con procesador Via C-7m, soportó hasta la instalación de OpenIndiana. Interesante que en esa época HP, por estar algo peleada con Microsoft, la vendía con Suse Linux. Claro está, el Suse no se podía actualizar a menos que pague un contrato con Suse, lo que me parecía en extremo absurdo considerando que justamente había comprado algo con un sistema operativo de código abierto. Puro software libre, pero pago. Un chiste de HP.

como buena HP, también tenía problemas térmicos constantes. No se llegaba a apagar, pero los sensores marcaban muy seguido los tan temidos 80°. Y se me tostaban los pelos de las piernas, eso lo recuerdo. Esa máquina aún la tengo, ya que me encariñé con el hecho de haber cosido una funda de cuerina sólo para que no se me raye. Su disco cada tanto comenzaba a zapatear, eso sí.

Luego en un viaje adquirí una Lenovo S10e (en realidad me la regalaron los miembros de la comunidad de OpenSolaris en un viaje a San Francisco donde todos nos juntamos para planificar lo que sería el futuro de este sistema operativo, casi sin saber que en breve se venía el destrozo, y no iba a tener futuro, al menos no como OpenSolaris). Esa máquina es la que hoy encontré, y cuya batería viene aguantando más de tres horas, con el WiFi encendido, y sin chistar. Teclado algo chico, pero la máquina anda perfecto.

Claro, con mi fiebre de potencia, adquirí una Toshiba con procesador Core i7, 32 GB de RAM, y un disco de 1 TB. A la semana de usarla, tenía la sensación de que la tenía de toda la vida. El teclado ya se mostraba gastado, la pantalla parece de nylon, el lectograbador de DVDs funciona cuando quiere (desarrolló una personalidad destructiva para con sus insumos) y su batería bajó en un 20% su capacidad. El balance general es bastante malo, y sé que si tuviera un mínimo golpe, se viene el velatorio de la máquina. Es una 850, o algo así. Lo peor, es el UEFI. No sólo por ser UEFI, sino porque está programado de forma tal que para poder ingresar a él, y solicitar funciones tan avanzadas como un cambio del dispositivo de booteo (!) hay que generar un error de teclado, con lo que cual se puede ingresar. Muy práctico e intuitivo, por supuesto. Eso lo obtuve de un foro una semana y media antes que el soporte de Toshiba siquiera me responda el mail que les mandé.

En el camino compré una Banghó para un pariente mío, la cual, sorprendentemente, sigue funcionando, luego de más de cinco años. No se lentificó, y si bien su batería ya pasó a mejor vida, aún se pelea con el mundo de la informática. Eso sí, he visto otras máquinas con el mismo procesador, la misma RAM, y el mismo disco, funcionar notablemente más rápido. Ergo: algo es malo en el motherboard, y eso pone todo más lento. Ni que hablar de las acrobacias que tuve que hacer para instalarle Linux, ya que su chipset debe haberse fabricado en forma artesanal en alguna casa de familia de Japón, la que se quemó y no se pudieron recuperar ni los planos ni las especificaciones.

Todas las demás Banghó que probé, ya sean Celeron, Core i3, i5, i7, y sus variantes, tienen la característica de parecer hechas para que un soplido o estornudo fuerte las rompa. Y calientan. Todas calientan al nivel de esterilizar a un Sysadmin si se las pone sobre las piernas. Los ventiladores siempre están funcionando al máximo, y aún así calientan muchísimo. Máquina ideal para el invierno de zonas árticas, pero creo que allá no se venden.

Luego, por temas laborales tengo una Lenovo T430, cuyo teclado estoy usando para escribir esto, y que aún funciona, luego de tres años de transportarla de acá para allá, perfectamente. El disco no presenta errores, y si no fuera por un sistema de encripción de datos que la lentifica notablemente, no tendría que cambiar nada.

En el medio de todo esto, compré una HP Pavilion dm1. Procesadores AMD E350-II, 2 GB RAM, 500 GB de disco. Esta máquina es decente desde el punto de vista del teclado, y su pantalla, y su carcaza es también de aluminio, pero el disco ya patinó un par de veces, y como todas las HP, levanta temperatura en forma exagerada, aún cuando no hay mucho procesamiento. Otra tostadora que al menos, no se apaga sola.

También por el medio de esto obtuve una Asus tipo netbook, con procesador Celeron. Una cosa bárbara, porque funciona aún el día de hoy. Y funciona bien. Su teclado anda, su disco no falló, así como ninguna otra pieza de su hardware. Lo mismo le pasó a todos los que conozco que compraron esta marca.

CONCLUSIÓN:

- Todas las Lenovo que usé en mi vida tuvieron teclado duradero, batería que no se agotó, disco que no se rompió, y las pude revender a buen valor, por ser Lenovo. Y no me tostaron las piernas.

- Todas las HP que tuve al poco tiempo quise revolearlas por el aire, porque calentaban muchísimo (80°, llegando a apagarse solas), o se tapaban sus ductos por problemas de diseño. En todos los casos sus discos se rompieron, ya sean de notebook, netbook, o cualquier cosa. Al querer venderlas, todos los compradores peleaban el precio "por ser una HP". Nunca más compro una a menos que me aseguren que su fábrica contrato psicólogos para sus diseñadores.

- Salvo una Celeron muy vieja, que varios me dijeron que salió buena de fábrica, las Banghó resultaron descarte. Caras para el pésimo hardware que tienen, y sus carcazas son de juguete. Todas calientan una barbaridad, sufren de problemas de hardware fuertes (pantallas que se queman solas, lectograbadoras que no funcionan luego de un par de grabaciones, teclados malísimos, tarjetas WiFi que se descomponen porque sí, discos más que débiles, y un largo etc.).

- Las Dell se mostraron como un punto intermedio entre la excelencia de las Lenovo, y la basura Banghó. Me da un poco de impresión que alguien me diga que me pueden estallar los genitales por una batería que salió de fábrica con un error de diseño, no lo voy a negar. Que me manden un reemplazo de batería a un hospital donde puedo estar internado en la sala de urología por una reconstrucción no sería algo que consideraría un buen "servicio al cliente". Pero bueno, es mejor que nada.

- Prometo no adquirir nunca más una Toshiba aunque venga con cuatro procesadores Intel Xeon de última generación, 64 TB de memoria RAM, y un array de discos de 250 TB colgando de su costado. Son quizá un punto intermedio entre las Dell y las HP. El precio es por lejos mejor que en cualquiera de estos casos, y casi que son más económicas, si se consigue la promo adecuada, que las Banghó.

- Las Asus aparentemente, y tocando madera, se vienen comportando bastante bien, por lo que podrían colocarse en un escalón entre las Lenovo y las Dell.

- Texas Instruments, lamentablemente, R.I.P. Amé mi primer notebook, donde instalé mis primeros Linux móviles.

- La escala final, en función de calidades, queda así:

1) Lenovo. Todas funcionaron bien, sin importar si eran de gama alta, media o baja.
2) Asus o Dell, según se prefiera.
3) Dell o Asus, según se prefiera.
4) Toshiba.
5) HP (no es gracioso perder información porque siempre sus discos se rompen, tanto en laptops como en PCs o servidores).
1006) Banghó. Todas, salvo una, funcionaron muy por debajo de lo esperado. Y de lo pagado.

En fin, esto no es para influir el deseo de compras de nadie, pero sí para compartir mi propia experiencia, que como podrán ver más arriba, es más que personal, y podrá ser retrucado por cuaqluiera que haya logrado con una máquina de las marcas que yo considero hoy incomprables, increibles resultados.

Abrazos!

[NOTA]: He recibido excelentes referencias de las máquinas Samsung, poniéndolas quizá por debajo de las Lenovo. Luego de las Mac, poniéndolas inclusive por arriba de las Lenovo. No las agregué a la escala, por no ser parte de mi experiencia de vida. Pero si adquiero alguna de ellas, o algún alma (muy) caritativa decide donarlas a la causa, no les quepa duda que estarán por acá en una próxima edición.

PD: Todas las marcas mencionadas en este artículo son propiedad de ellas, o eso piensan sus directivos, y sólo se las menciona por ser éste un blog, y no un centro de difusión de radio, televisión, onda corta transoceánica, microondas espaciales, o similar.

sábado, 9 de mayo de 2015

Primeros pasos recreando una máquina Manjaro

Hoy, luego de un buen tiempo usando el mismo viejo Manjaro que tengo implementado hace años, uno de sus discos decidió dejar el servicio.

Tengo gran cantidad de backups de ese disco, pero por primera vez, me dije que no sería una mala práctica comenzar de nuevo, con un sistema completamente limpio, y ver qué queda al finalizar.

Los servicios que mi máquina tenía antes de la muerte de su disco eran:
  • SSH Server.
  • ownCloud 8.
  • GateOne.
  • Lógicamente, Apache, PHP, MySQL.
  • Una vieja aplicación hecha en PHP3 que aún levanto, y que no tengo ganas de migrar a nuevas versiones de PHP dado que aún funciona de maravillas, y cumple con lo que necesito. Si algo no está roto, no intentes arreglarlo...
  • Cliente no-ip.
Lo primero fue bajar de www.manjaro.org la imagen de sistema operativo para 64 bits (0.8.12 en este momento), y pasarla a un pendrive.

Para ello no tuve que hacer más que colocar el pendrive en mi laptop, y ejecutar:

$ sudo dd if=manjaro-0.8.12-x64.iso of=/dev/sdf bs=1M

Efectivamente, el pendrive se ubica en el dispositivo /dev/sdf.

Booteé con el pendrive, particioné un disco USB externo para tener 500 MB de /boot, 8 GB de swap, 150 GB de /, y el resto para /home. Luego de eso, configuré mi zona horaria, mi teclado, mi usuario, y continué con una instalación común y corriente.

Al finalizar la instalación el sistema me pidió ejecutar alguna actualización. Como nada es fácil, se colgó la implementación del paquete "manjaro-system", que es el que actualiza el sistema operativo en general.

Entonces abrí una terminal, ejecuté "xkill" (viejo truco), y maté la ventana donde se estaba ejecutando la actualización.
En esa misma terminal ejecuté:

$ sudo pacman -Syyuu

...y acepté todo lo que me pidió cambiar. El total del download me pareció algo excesivo para un sistema recién instalado, pero la recompensa vale la pena. Son 800 MB de downloads.

Al finalizar la actualización, como siempre hacemos en estos casos, rebooteamos para que el nuevo kernel comience a tomar sus funciones.

Muy para mi sorpresa, al rebootear aparece un pedido de dos paquetes más que deben ser actualizados. En este caso, no se bajan y se instalan, sino que se compilan en vivo y en directo. Son los paquetes "libxfcegui4" y "arj". No hay problema, acepto todo y dejo que se baje el código fuente, y luego que se compilen e instalen.

Luego de esto, procedí a engordar con un pequeño lujito: yendo a la configuración de Manjaro, y de allí a "Kernel", pude implementar el nuevo kernel 4.0.1. Rebooteé, y noté para mi asombro que todo funciona, y lo hace de maravillas.

Instalamos algunos paquetes mandatorios para hacernos la vida más fácil:

$ sudo pacman -S vim community/remmina community/freerdp vim vi

Ahora comienzan los verdaderos temas a resolver. El primero es el SSH. Al querer ejecutar el comando ssh veo que no están instalados ni el servidor ni el cliente. A instalarlos:

 $ sudo pacman -S core/openssh

Al terminar la instalación, verifico el estado del servicio:

$ systemctl status sshd
● sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)


A activarlo:

$ sudo systemctl enable sshd
Created symlink from /etc/systemd/system/multi-user.target.wants/sshd.service to /usr/lib/systemd/system/sshd.service.
$ sudo systemctl start sshd


Ya con el SSH levantado, la vida se me hace bastante más fácil. Sólo me falta ownCloud 8, GateOne, y mi aplicación.

Vamos a la instalación directamente:

Instalamos Apache y PHP:

$ sudo pacman -S apache
$ sudo systemctl enable httpd
$ sudo systemctl start httpd
$ sudo pacman -S php php-apache

Configuramos Apache para soportar PHP:

$ sudo vi /etc/httpd/conf/httpd.conf

Comentamos esta línea:

# LoadModule mpm_event_module modules/mod_mpm_event.so

Agregamos debajo de ella la siguiente línea:

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

Agregamos al final del archivo:

# Agregado por HeCSa para PHP 5.x:
LoadModule php5_module modules/libphp5.so
AddHandler php5-script php
Include conf/extra/php5_module.conf


Modificamos /etc/php/php.ini para soportar MySQL entre otras cosas, descomentando las líneas:

extension=bz2.so
extension=gd.so
extension=iconv.so
extension=intl.so
extension=mcrypt.so
extension=openssl.so
extension=pdo_mysql.so

extension=pdo_sqlite.so
extension=mysql.so
extension=mysqli.so
extension=sqlite3.so
extension=xmlrpc.so
extension=zip.so

Y relanzamos el servidor Apache, ahora con PHP habilitado:

$ sudo systemctl restart httpd

Instalamos MySQL:

$ sudo pacman -S mysql
:: There are 2 providers available for mysql:
:: Repository extra
   1) mariadb
:: Repository community
   2) percona-server

Enter a number (default=1): 1


Inicializamos la base de datos MySQL:

$ sudo mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql
$ sudo systemctl start mysqld

$ sudo mysql_secure_installation (las opciones por default en este caso están bien)
$ sudo systemctl enable mysqld

Instalamos el cliente no-ip:

$ yaourt -S aur/noip (aceptamos todas las opciones)
$ sudo noip2 -C -Y
(configurar todos los parámetros según las preguntas que nos hace el sistema, más apuntadas a nuestra cuenta, clave, tiempo de refresco, servidores, etc.)
$ sudo systemctl enable noip2
$ sudo systemctl start noip2

Bravo...ya tenemos un servidor localizable en la red de redes! Ahora a por ownCloud 8, considerando que conservamos aún los archivos que teníamos en el viejo disco, el que hemos recuperado usando el procedimiento que podemos encontrar en este mismo blog, en "Recuperación de discos levemente arruinados". Conservamos los directorios "data" y "config", fundamentales para nuestra recreación completa.

Instalamos los paquetes necesarios:

$ sudo pacman -S owncloud php-pear php-intl
$ sudo pear install MDB2

Ahora...ingresamos en el directorio de instalación de ownCloud, y destareamos los dos directorios "data" y "config", conservados en dos archivos llamados "/backup/data.tgz" y "/backup/config.tgz":

$ cd /usr/share/webapps/owncloud
$ sudo tar zxvf /backup/data.tgz
$ cd /etc/webapps/owncloud
$ sudo mv config config.original
$ sudo tar zxvf /backup/config.tgz

Al finalizar el destareo, tendremos los dos directorios completamente recreados, pero ownCloud aún no está funcional. Tendremos que tocar algunas cosas en los archivos de configuración para que realmente comience a funcionar, asi como recrear su base de datos completamente, de la que por suerte conservamos un backup llamado "owncloud-2015-05-06.dump".

$ cd /usr/share/webapps/owncloud
$ sudo mv data data.original
$ sudo mv config config.original

Recreamos  tanto la base de datos de ownCloud como la de la mi aplicación PHP3 (llamada demohd):

$ mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.0.17-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database demohd;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> create database owncloud;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all on demohd.* to xxxx@localhost identified by 'xxxx';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> grant all on owncloud.* to xxxx@localhost identified by 'xxxx';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]>


Recuperamos los backups de ambas bases de datos:

$ mysql -u demohd -p demohd < demohd-2015-05-06.dump
$ mysql -u owncloud -p owncloud < owncloud-2015-05-06.dump

Llegó el momento de tocar archivos! Allá vamos:

$ sudo cp /etc/webapps/owncloud/apache.example.conf /etc/httpd/conf/extra/owncloud.conf
$ sudo vi /etc/httpd/conf/httpd.conf

(descomentamos estas líneas)

LoadModule proxy_html_module modules/mod_proxy_html.so

LoadModule rewrite_module modules/mod_rewrite.so

(al final del archivo agregamos esta línea)

Include conf/extra/owncloud.conf

Cambiamos permisos:

$ sudo chown -R http:http /usr/share/webapps/owncloud/

Finalmente, mi aplicación se ubica dentro de un directorio llamado /opt/lampp, el cual también tengo resguardado en un archivo llamado lampp.tgz. Para reconstruir la aplicación sólo debo ejecutar:

$ cd /opt
$ sudo tar zxvf /backup/lampp.tgz

Ahora sólo queda reconstruir el servicio que levantaba dicho entorno de ejecución, para lo cual ingresamos al directorio "/etc/systemd/system", y ejecutamos los siguientes comandos:

$ cd /etc/systemd/system
$ sudo vi lampp.service

[Unit]
Description=LAMPP de versiones viejas de Apache y PHP

[Service]
ExecStart=/opt/lampp/bin/apachectl start
ExecReload=/opt/lampp/bin/apachectl restart
ExecStop=/opt/lampp/bin/apachectl stop
Type=forking

[Install]
WantedBy=multi-user.target


$ sudo systemctl --system enable lampp
$ sudo systemctl start lampp

Una cosa que había olvidado es que en PHP3 la app no soportaba el nuevo esquema de autenticación que ahora tiene MySQL (en realidad instalé MariaDB), por lo que debo ejecutar:

$ mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 17
Server version: 10.0.17-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> set password for xxxx@localhost = old_password('xxxx');
Query OK, 0 rows affected (0.23 sec)

MariaDB [(none)]>


Listo, ya puedo ingresar a mi página basada en PHP3!

Vamos a la instalación de GateOne. Es bien sencilla:

$ yaourt -S aur/gateone-git
$ sudo systemctl enable gateone
$ sudo systemctl start gateone

Listo, ya tengo de nuevo mi máquina tal como alguna vez estuvo...pero actualizada a lo último!

miércoles, 17 de diciembre de 2014

Recuperación de discos rígidos levemente arruinados

En este artículo abordo una forma que he encontrado bastante adecuada para recuperar información de discos rígidos que se han dañado, ya sea en formato GNU/Linux como Windoze. Manos a la obra!

Situación: Un buen día queremos bootear nuestra máquina, y para nuestra sorpresa descubrimos que no podemos por errores en el disco rígido. Ese disco se encuentra ya con su vida útil cumplida, y nos pide a gritos que lo cambiemos por uno nuevo. La desesperación nos invade, ya que no encontramos forma de levantar la máquina para copiar la información que en dicho disco se encontraba hacia otro lado.

Materiales: Necesitaremos:
- La PC moribunda.
- Un pen drive de por lo menos 2 GB.
- Un disco externo de por lo menos la capacidad del original más algunos GB para guardar archivos de log y demás archivos auxiliares. Si nuestro disco era de 320 GB, uno de 500 GB sirve. Puede estar conectado de la forma que se nos ocurra, inclusive en un gabinete externo, por medio de USB, etc.
- Una imagen de una distro medianamente digna de GNU/Linux, como ser Manjaro, Debian, o alguno de sus derivados.
- Un instalador de imágenes en pendrives como ser las que se bajan de pendrivelinux.com, o una PC con GNU/Linux.
- Una conexión a Internet que nos permita bajar algunos MB de paquetes.

Procedimiento:

Si contamos con una PC con GNU/Linux que funcione, podemos escribir nuestro pendrive con ella usando dd. Lo primero será ejecutar como root el comando "fdisk -l" para entender cuáles son nuestras unidades de disco. Supongamos que /dev/sda es el disco de nuestra PC GNU/Linux, y que /dev/sdb es el pendrive. También, que la imagen es manjaro.iso.
El comando a ejecutar, desde el directorio donde está manjaro.iso, es el siguiente (siempre como root):

# dd if=manjaro.iso of=/dev/sdb bs=1M

Una vez terminado este proceso, booteamos nuestra PC dañada desde el pendrive.

Ya booteada desde el pendrive, si la distro fuera Manjaro, ejecutamos (siempre como root, luego de un "sudo bash"):

# pacman -S ddrescue

Si lo primero que nos pide el sistema operativo es actualizar su gestor de paquetes, recordemos ejecutarlo nuevamente para que REALMENTE instale ddrescue.

Si lo que estamos usando es una distro como Ubuntu, por ejemplo, lo que debemos hacer es instalar el "gddrescue" y "ddrescue", que no se encuentra en los repositorios inciales del LiveUSB, por lo que habrá que agregar las entradas "universe" y "multiverse" a las que ya posee el archivo /etc/apt/sources.list, y ejecutar:

# apt-get update
# apt-get install gddrescue ddrescue

Si la PC dañada es como todas, al ejecutar, como root, un "fdisk -l", veremos diferentes unidades de disco (consideramos que el disco auxiliar estará conectado vía USB). Para nuestro ejemplo supongamos que /dev/sda es el disco interno, dañado, /dev/sdb es el pendrive USB, y que el disco externo es /dev/sdc.

Formatearemos el disco externo con "fdisk /dev/sdc", donde definiremos una única partición con todo el contenido del disco, y lo salvaremos así.

Luego ejecutaremos "mkfs -t ext4 /dev/sdc1" para que genere el filesystem. Tener muchísimo cuidado con esto, ya que si las unidades tienen otros nombres, y no nos damos cuenta, rompemos todo...

Ya con el disco formateado, y considerando que el disco dañado es /dev/sda, donde la partición /dev/sda1 es la que tenía el sistema operativo, montamos la partición recién creada en /mnt (mount /dev/sdc1 /mnt), y procedemos a ejecutar ddrescue (adivinaron: como root):

# ddrescue -d -r3 /dev/sda1 /mnt/sda1.img /mnt/sda1.log

Cuando termine de ejecutar este comando, podremos ejecutar:

# mkdir /discosda1
# mount -o loop,ro /mnt/sda1.img /discosda1

Si todo salió bien, veremos que tenemos en /discosda1 el disco con todo su contenido, al menos lo que se puede salvar, listo para ser copiado a otra máquina, o al mismo disco ahora montado en /mnt.

Si el sistema de archivos es de GNU/Linux, y no quiere ser montado por tener errores, debemos primero ejecutar "fsck" sobre él:

# fsck -y /mnt/sda1.img

Si no encuentra el superblock, tendremos que utilizar uno alternativo, para lo cual habrá que ejecutar, para saber cuáles son los superblocks alternativos:

# dumpe2fs /mnt/sda1.img | grep superblock

Verificar el primero de los números de superblock que aparecerán.

Y luego, para usar el superblock alternativo, se deberá ejecutar:

# fsck -y -b /mnt/sda1.img

Por qué se hace esta imagen? Porque no sabemos hasta cuándo nuestro disco dañado aguantará, y es por ello preferible trabajar sobre una imagen que sobre el disco en sí mismo. Joven precavido vale por dos...

Al finalizar el proceso, se puede ejecutar "poweroff" y listo.

Enjoy and recover, guys!

sábado, 25 de octubre de 2014

Manjaro, su paquetería y un truco interesante

Situación: Manjaro me dice mediante su interfaz gráfica que tengo dos paquetes para actualizar. Pero ejecuto pacman -Syyuu y yaourt -Syyuu, y no aparece nada para actualizar.
Una paradoja, no? Pues bien, uno de los paquetes que tengo instalados por medio del yaourt tal parece que es una versión de desarrollo. Entonces, no la actualiza con el modelo nominal de comandos pacman y/o yaourt.
El comando que me salvó la vida fue el siguiente:

yaourt -Syyua --devel

Simple, sencillo, y al pie.