Optimizando el kernel de Linux para el escritorio (desktop) con xanmod

En ocasiones customizar y compilar el kernel de Linux/GNU puede ser una tarea que lleve mucho tiempo, no siempre invertir ese tiempo se justifica.

Eso se aplica si el hardware de tu PC es actual o si no querés sumergirte un poco en cómo el sistema funciona "bajo el capot".

Para quienes deseen exprimir su hardware al máximo y optimizar el comportamiento del sistema operativo para ciertos usos, por ejemplo optimizarlo para funcionar con aplicaciones "de escritorio" este post puede resultarles útil.

Hoy en día compilar el kernel del Linux es mucho más fácil de lo que acostumbraba ser. Xanmod o Liquorix ofrecen una serie de parches y optimizaciones que se aplican por sobre el kernel "vainilla" de Linux y que procuran optimizar el kernel para diferentes casos de uso.

Respecto de utilizar un kernel "de stock" provisto por nuestra distribución favorita, compilar el kernel nosotros mismos es una tarea que requiere invertir de cierto tiempo. Requiere al menos familiarizarse con el hardware en donde vamos a ejecutar ese kernel. Mi modesto consejo es configurá tu kernel si:

• Estás buscando optimizarlo para ciertos casos de uso.
• Si tu hardware es raro y requiere soporte que no estuviera ya presente en el kernel de tu distribución.
• Si por ejemplo un sistema embebido tiene relativamente pocos recursos y hay que reducir la "pisada" del sistema.

En mi caso más o menos recientemente solo necesité compilar el kernel cuando utilizo hardware antiguo. Por ejemplo si quisiéramos utilizar una unidad floppy o una interfaz ide un kernel estándar actual nos va a dejar a pie. Tengo una máquina que ya tiene cerca de doce años, es una pequeña netbook de las que el Gobierno de la Ciudad entregó a los alumnos de las escuelas primarias. Ya mis hijos no la utilizaban, porque quedó bastante rezagada para correr soft actual.

A mí me gusta por su diseño y su robustez. Puedo usarla a la intemperie, en cualquier clima. Y con Linux tiene una vida algo extendida, de otro modo ya habría ido a parar al callejón del olvido. Si bien el teclado no es cómodo, usé esa máquina para transcribir mi libro ("Piensa Abierto") de mis cuadernos manuscritos a archivos markdown, que fueron la base para su composición tipográfica. Demás está decir que navegar la web no es una experiencia llevadera en esa máquina, pero para escribir con visual studio o codear algunos script o aplicación simple resulta utilizable. Por eso me propuse hace unos días tratar de optimizarle algunos pocos ciclos de cpu a ver si podía reducir la latencia de ciertas aplicaciones. Pese a tener solo 1GB de ram, utilizo allí debian con enlightenment como gestor de escritorio, lo que hace al desktop elegante y liviano. El principal cuello de botella de la máquina es sin dudas su CPU, un antiguo Atom de Intel.

Xanmod y la optimización del kernel

Xanmod es una distribución de software, en este caso una distribución del kernel Linux que incluye varios parches y mejoras, algunas de las cuales no se incluyen en el kernel estándar. En general el fuerte de Linux/GNU desde su edad temprana ha sido correr en el servidor. Es por ello que con cierto grado de solución de compromiso, el kernel suele incluir una configuración que resulte estable para el servidor, pero no necesariamente está optimizada del todo para software de escritorio. Entre otros usos xanmod procura facilitar esos ajustes y "tweaks" para que uno pueda optimizar el kernel para el escritorio. Otra distribución alternativa es Liquorix . Estas distribuciones suelen incluir binarios ya compilados del kernel, empaquetados en paquetes .deb, por ejemplo utilizables en Debian o Ubuntu. Además existen paquetes para Arch, Fedora, etc. Un problema es que ya es raro que se incluyan binarios 32bits en estos builds, y el Atom de mi vieja netbook no es 64 bits. Compilar el kernel tenía entonces algo más de sentido. Además podría incluir algunos ajustes más para reducir la latencia, en particular me interesaba ajustar la "preferencia" del kernel (en inglés "preemption" para intentar reducir en algo la latencia del escritorio). Además podría seleccionar schedulers alternativos para controlar la Entrada/Salida de disco (este fierro viejo tiene hdd).

Compilando el kernel (usando el código fuente de xanmod) a la manera de Debian

Para comenzar, obviamente se requiere descargar el código fuente del kernel, en la distribución provista por xanmod. Como he descripto en una entrada en este blog hace ya varios años atrás voy a compilar el kernel a la Debian, eso quiere decir que los artefactos que resulten del build serán un puñado de archivos .deb (el kernel en sí, sus headers y al librería de C). De esa forma uno puede distribuir esa versión de su kernel "custom" de forma fácil. La manera en como se compila a la Debian ha cambiado hace un tiempo y hoy es incluso más fácil. Manos a la obra. Por supuesto no iba a compilar mi kernel en la vieja netbook, porque allí demoraría días, o quizá semanas. De forma que es mejor utilizar el hardware más potente que tengamos a mano. En mi caso, la PC de mi escritorio tiene un procesador AMD de 64 bits, de modo que es necesario hacer un cross-compiling para que los binarios resultantes sean de 32 bits. Pero eso no es más que pasarle un parámetro al compilador.
Si uno quiere empezar a jugar con la configuración y no invertir horas de prueba y error, lo más seguro es partir de una configuración conocida. En el directorio /boot tenemos la configuración del kernel que estamos utilizando y podemos partir de esa configuración para empezar a hacerle algunos cambios.

1) Instalar dependencias, si es la primera vez que vamos a compilar el kernel necesitaremos las herramientas de desarrollo:

$ sudop apt-get install build-essential bison flex

2) Para partir de una configuración "conocida", desde dentro del directorio de las fuentes de xanmod:

$ make localmodconfig

Con esto lo que haremos es crear el archivo de configuración del kernel (.config) a partir de la configuración del kernel actual y de los módulos que éste contiene.

3) Luego, copiar el directorio de xanmod a la máquina (más potente quizá) que utilizaremos para la compilación.

4) En este punto, previo a la compilación es cuando -si queremos- podemos hacer algunos ajustes. A mí me interesaba, como comenté antes, cambiar la preferencia del scheduler del kernel:

$ make menuconfig

Ese comando abrirá una interfaz ncurses para navegar las diferentes secciones de la configuración del kernel.

En la sección "Preemption Model", selecciné "Preemptible Kernel (Low-Latency Desktop)". Una nota sobre esto ¿De qué se trata el model de preferencia? Dicho en pocas palabras, define el modo en que el kernel elige entre las diferentes procesos o tareas que deben correrse en un sistema operativo multi-tasking (como todos los actuales). El modo seleccionado procura que las aplicaciones de escritorio puedan correr sin muchos contratiempos, aún cuando el sistema esté bajo una carga pesada, como suele ser el caso de mi netbook. Por otro lado quería experimentar también con el scheduler de Entrada/Salida, por ello agregué algunos schedulers que no suelen ser tan estándar:

Me interesó el scheduler BFQ. En este caso agregué el scheduler como módulo, de modo que si no lo quiero utilizar luego no ocupe más memoria en la imagen del kernel.

5) Finalmente (en una máquina más o menos "potente") hacer el build:

$ make ARCH=i386 -j 8 deb-pkg LOCALVERSION=-retux

Aquí con ARCH= indicamos la arquitectura target, que es i386 ya que se trata de un procesdor Atom de Intel. Con -j N podemos asignar un cierto número de núcleos de CPU disponibles para paralelizar la compilación.

6) Instalar en la máquina de destino, que usará este kernel instalar los .deb.

$ sudo dpkg -i *.deb

7) En la configuración del kernel, en los parámetros que grub le pasa en tiempo de boot, se puede seleccionar el scheduler BFQ y deshabilitar watchdog (que en una máquina de escritorio o laptop no es indispensable):

elevator=bfq nowatchdog

Con justicia, ustedes me preguntarán ¿Y los resultados? ¿Vale la pena el esfuerzo? Algunos mejoras en la netbook, en lo que hace a la latencia fueron perceptibles. No es el día y la noche, solo con esto no vamos a hacer de una pc de 13 o 14 años, pero en algo podemos extenderle la vida. Además puede ser el comienzo de otras experimentaciones para el que le interese.
Existe una analogía entre algo del "hacking" con la práctica de los radioficionados. Entre estos existe una práctica denominada transmisión QRP, que consiste en transmitir con la menor potencia en antena. De esa forma, lo que se procura es optimizar el rendimiento (de la línea de transmisión, de la antena, etc) para obtener el mejor resultado posible. De esa forma, un comunicado QRP tiene otra satisfacción diferente a la de poner 100W en antena.
Espacio para mejoras, siempre suele haber, por pequeño que este sea. Si puedo hacer algunos benchmarks prometo publicarlos próximamente.

Continuar »

Prácticas profesionalizantes. Una experiencia personal.

Actualmente se discute la implementación de "prácticas profesionalizantes" como parte obligatoria de la currícula de las escuelas secundarias de la ciudad de Buenos Aires.

Esto no es opinión acerca de política partidaria. Es mi modesta experiencia como técnico en electrónica, y de haber formado parte como alumno del Plan Piloto de la Escuela Técnica número 28 República Francesa, acaso más conocido como "el Cuba". Imagino que la experiencia ha sido compartida por muchos más compañeros, pero por supuesto, las opiniones que siguen son estrictamente personales, no así los hechos.
Esto es hablar de mi generación (Oh The Who!) pero también de las que están por venir.

No suelo escribir en este espacio artículos de opinión acerca de la actualidad o de la política local. Si este artículo se refiere a temas públicos el lector encontrará mis razones en seguida. Me sentí inclinado y obligado a hacerlo en relación al proyecto de "prácticas profesionalizantes" en las escuelas secundarias que impulsa el Gobierno de la Ciudad de Buenos Aires, para implementar durante el año lectivo 2022. El tema me interpela personalmente y a muchos otros amigos de mi generación (oh The Who). Fui alumno de la Escuela Técnica número 28 "República Francesa", conocida como "el Cuba" por estar ubicada en la intersección de Cuba y Blanco Encalada en el barrio de Belgrano.
Como debe ocurrir a mucha gente, las amistades que construímos a la edad (que ya nos parece algo lejana) en la que cursábamos la secundaria, siguen siendo nuestros amigos de hoy. Casi tres décadas después seguimos siendo amigos con el mismo grupo de muchachos con los que cursamos en el Cuba. Con esto quiero decir que mucho de la construcción de nuestra identidad se juega en esos años de adolescencia.
Supongo que a nosotros, los técnicos egresados de las escuelas técnicas este proyecto nos interpela directamente porque en mayor o menor medida podemos dar testimonio de cómo la práctica profesional en empresas tuvo un impacto positivo en nuestras carreras profesionales y en nuestras vidas en general.
Como alumnos de la técnica 28, en actos o discursos escolares escuchamos noticias acerca de su fundación: la escuela se fundó en la década del cuarenta como parte de las llamadas "escuelas fábrica", que posteriormente pasaron a denominarse "industriales" y luego "escuelas técnicas". Esas distintas denominaciones dan cuenta de su propio desarrollo y de las transformaciones de la sociedad de que forman parte.
En los discursos que escuchábamos, especialmente en aquellos que destacaban los inicios como "escuela fábricas" solía subrayarse la conexión directa entre la escuela con eso que genéricamente se denomina "el mundo del trabajo". Ese "mundo" lo conforman las empresas privadas y algunos organismos públicos.
Cuando a nosotros nos tocó cursar en el Cuba, de forma similar a como ocurre hoy en día, el ciclo estaba dividido en tres partes: ciclo básico (3 años), ciclo superior (3 años) en los que se intensificaban el aprendizaje de temas técnicos y el sexto año de la cursada se cursaba en el turno noche, porque durante el día se realizaba una pasantía en empresas.
Hoy a este tipo de planes suelen denominarlos "prácticas profesionaizantes". Cuando a nosotros nos tocó cursar el sexto año, en la primera mitad de los años noventa, aún se denominaba a este programa de pasantías como el "Plan Piloto".
En aquel momento el "Plan Piloto" ya tenía más de dos décadas de desarrollo. Se había puesto en marcha en 1967, como iniciativa del CONET (Comité Nacional de Educación Técnica) e impulsado definitivamente por el profesor Julio E. Ambrosini. También director de la escuela por aquellos años en que nosotros empezamos a cursar si no me equivoco. Hoy una placa en la escuela recuerda el tesón con el que impulsó el desarrollo del Plan.
El Plan surgió a la luz de las teorías y políticas desarrollistas, pero su existencia las trascendió largamente.
Por otra parte, eran aquellos años que se percibían como punto de inflexión en lo relativo a la tecnología. Se percibía que algo nuevo estaba por venir: ya se podían entrever algunos de los efectos duraderos que tendría la microelectrónica y la miniaturización sobre la cultura. La electrónica (hoy podríamos decir el hardware) se volvería ubicuo en nuestras vidas cotidianas. Todavía el equipo liderado por Federico Faggin en Intel no había presentado el 4004, el primer microprocesador. Ese hecho ocurrió en 1971, pero previo a ese hecho fundamental el transistor había delineado el camino de la progresiva miniaturización y el advenimiento de la electrónica de consumo.
Mi amigo y compañero de curso Hernán M. hace unos días nos compartió en nuestro grupo de chat lo que encontró en algún lugar de la web. Se trata del número 4 de la revista de la escuela, la cual se titulaba simplemente "Electrónica". La misma data de 1967 e incluía algunos artículos técnicos sobre las "computadoras digitales", "aplicaciones del rayo láser en comunicación", entre otros. Sin embargo, el artículo que me interesa aquí es uno que llevaba la firma del profesor Julio E. Ambrosini: "La realidad del Plan Piloto". El citado artículo comenzaba:


"El mundo vive desde hace algunos años dentro de lo que podríamos denominar una era tecnológica acelerada y, Argentina, país rico y con grandes posibilidades no puede mantenerse al margen de este proceso. Por ello debe preparar a sus técnicos adecuadamente, contando con los recursos materiales necesarios, ya que los humanos existen por la calidad de nuestro pueblo".

Según se señala en la revista, desde los años sesenta la escuela contaba con un comité asesor de ingenieros de IBM, Bull-General Electric y Rand Corporation. Sin embargo para 1967 esa iniciativa estaba institucionalizándose con el apoyo del CONET en el Plan Piloto.
El Plan se basaba en un principio pragmático: por mejor equipados que estuvieran los laboratorios de la escuela, siempre irían a la zaga de la industria.
Aún Neil Armstrong y Buzz Aldrin no habían pisado el suelo lunar, pero podía entreverse la exponencial estampida del progreso que vendría.
Cuando nos tocó cursar el sexto año a nosotros, en 1992, la industria electrónica en Argentina era bastante diferente a la descrita en el número de la revista "Electrónica".
En lo personal ¿Cuáles fueron algunos de los resultados del Plan Piloto para nosotros? El plan establecía una práctica en una empresa que uno como alumno podía elegir y dependiendo de sus calificaciones la empresa realizaba algún mecanismo de selección. Por ejemplo aquellos con mejores calificaciones podían llegar a hacer la práctica en IBM o Hewllet-Packard o alguna otra gran organización. Había un lugar para cada uno en una empresa.
También dependiendo de cada empresa esta podía determinar si la pasantía era rentada o no. Creo que en la mayor parte de ellas lo era. Con 17 o 18 años pasabas a cobrar tus primeros sueldos y eso de pronto te permitía sentirte como un dandy: descubrías que podías tener autonomía e independencia, pagarte las salidas de los sábados, no depender en eso de tus padres. Podías comprarte CDs en las disquerías sin depender de algún peso que te pudiera regalar alguien de tu familia. Eran años de cierta estabilidad monetaria y eso te permitía ahorrar.
Después de aquel primer año de trabajo, algunos nos aventuramos a viajar solos al extranjero por primera vez y conocer otras culturas. Todo gracias al Plan Piloto.
El Plan ofrecía una práctica profesionalizante en un empleo a tiempo parcial.
Ese debió ser para muchos de nosotros, mirándolo retrospectivamente, el primer año del resto de nuestras vidas, en la medida en que ibamos cruzando el puente entre el mundo de la escuela y ese más allá que eran el mundo del trabajo y los estudios universitarios.
Ese año, por otra parte, nos divertimos muchísimo. La empresa significaba conocer personas e interactuar en otras situaciones, hasta entonces desconocidas.
Creo que sin temor a equivocarme la gran mayoría de los que formamos parte de aquellas promociones continuó estudiando en la universidad sin dejar de trabajar. Pero por sobre todo tuvimos la enorme ventaja de no haber parado de trabajar desde entonces.
Por supuesto, nada es perfecto. Pero en líneas generales los efectos del Plan Piloto en nuestras carreras y vidas fueron positivos.
Hoy leo algunos argumentos de los que se oponen al proyecto de las prácticas profesionalizantes y dudo realmente de la buena fe de algunas de ellas. Por ejemplo, se sostiene que los alumnos pasarían a convertirse en "mano de obra barata" que las empresas aprovecharían.
Tengo la impresión, cuando escucho o leo "fuerza de trabajo", "mano de obra", que esas personas tienen una idea del trabajo más propia del siglo XIX que del XXI. Hoy, por elemental que algún trabajo sea este requiere conocimientos y habilidades técnicas y sociales. Por fortuna, la idea del trabajador pegado a la línea de montaje ya no forma parte del paisaje actual.
Otros argumentos simplistas sostienen que los pibes (y pibas) del secundario "van a sacarle el trabajo a trabajadores establecidos". De nuevo, este argumento cae de maduro. Ningún chico que esté haciendo una pasantía puede equiparar en conocimientos a alguien con años de experiencia en un trabajo. Es conocida y probada la teoría que indica que para convertirse en un experto en alguna cosa se requiere 10.000 horas de experiencia. Hagan las cuentas y ningún chico de secundaria podría tenerlas.
Como bien lo señalaba el profesor Ambrosini en 1967 para una empresa, "emplear" a un alumno secundario es más una inversión y un cierto riesgo asociado, que cualquier inversión conlleva. Así lo señalaba el citado artículo de la revista Electrónica:

"Hoy se encuentran colaborando empresas que se han brindado patrióticamente a poner un patrimonio millonario, una espléndida organización y un esfuerzo creador en pos de la formación de 128 alumnos que egresarán en este año 1967".

En ese proceso y con la capacitación adecuada es probable que un cierto número de alumnos puedan convertirse en empleados de nivel inicial, otros quizá no lo deseen y busquen otros caminos en otras empresas.
El nuestro es un país institucionalmente discontínuo. Primero fueron los gobiernos de facto que interrumpían el desarrollo de políticas a mediano y largo plazo, pero después los diferentes gobiernos democráticos no lograron presentar hasta el momento un panorama diferente en ese aspecto: ha sido habitual que un gobierno borre de un plumazo iniciativas de gestiones anteriores ya sea por pura ideología o por simple narcisismo ("vean ustedes que nosotros no somos aquello"). Hay pocas instituciones que hayan resistido el paso de políticas erráticas, con las que siempre se piensa en el corto plazo. Con todos los altibajos y vaivenes económicos, planes como el mencionado mantienen su relevancia.
Hoy la Argentina no es el país rico al que se refería el profesor Ambrosini en 1967. Pero sin dudas, igual que en 1967 nuestro capital humano sea lo central. Quizá por eso, hoy resulta más relevante que nunca la tarea de fortalecer los puentes entre la educación Pública, sus instituciones y las empresas ¿El riesgo? El capital humano, como el otro, viaja y emigra.
Ese mundo de cintas de montaje, música funcional y Taylorismo industrial que algunos creen que aún existe se desvaneció hace tiempo. En donde permanece será automatizado de manera irreversible, para liberar al humano de la carga mecánica.
En todo hemos sido demasiado conservadores. "Conservador" es pretender que nada cambie y por tanto que ninguna innovación pueda sobrevenir. Es dificil que nos vaya mejor si seguimos haciendo exactamente lo mismo que hemos venido haciendo mal durante este último medio siglo.
Continuar »

Viaje a los inicios de la Web ¿Cómo probar Viola Browser y Erwise

Viola WWW y Erwise fueron dos browsers pioneros

-junto con Midas browser- que precedieron a Mosaic, el browser desarrollado por NCSA que sería la base de la mayoría de los browsers que lo sucedieron (Netscape Navigator, Internet Explorer, Firfox y la lista sigue). Este es un breve paso a paso de cómo se puede crear el ambiente (una máquina virtual con el sistema operativo requerido Sun OS 2.6/Solaris 5.6 o similar) para poder ejecutar estos browsers.
Esta experiencia empezó hace algunas semanas cuando me propuse una experiencia (o un juego) que consistía en un tipo de arqueología de software. Gracias a internet en general y sites como archive.org tenemos a disposición el código fuente y a veces incluso archivos binarios de muchas piezas de software histórico. De esa forma, empecé por compilar para un linux de 64bits el código del servidor web CERN httpd, el primer servidor web que fue desarrollado por el equipo que lideraba Tim Berners-Lee a principios de los años '90 en el CERN. Esa experiencia puede verse en el siguiente video:


Después del servidor, los browsers
De entre los navegadores pioneros, el más popular y famoso fue el Mosaic, desarrollado inicialmente en el NCSA. Pero lo cierto es que lo precedieron algunos otros. El primer browser gráfico que corrió en el CERN solo podía ejecutarse en el sistema operativo Next OS, que equipaba las workstations Next. A ese browser del CERN, le siguieron Viola Browser, Erwise y Midas. Los tres fueron los browsers pioneros para sistemas Unix. El código fuente y algunos binarios (para arquitectura sparc) de estos browsers está disponible ahí afuera en la web, siguen los links:

Viola WWW:ftp://ftp.cuhk.hk/pub/packages/info-systems/www/viola/
Erwise:ftp://ftp.funet.fi/pub/networking/services/www/erwisE/

Además Pei Wei, autor de ViolaWWW mantiene activo el site viola.org que es una réplica del sitio web original donde fue ofrecido ViolaWWW al principio. A diferencia del servidor web, lograr compilar estas piezas de software en un sistema linux actual requiere un cierto trabajo de "portar" el software para que se entienda de manera adecuada con las APIs de X11 de las librerías más recientes. Algunas han cambiado bastante y ese esfuerzo no es trivial. Posiblemente a sus autores a gente más avezada que yo en eso les resulte acaso realizable, a mí me hubiera llevado bastante tiempo de prueba y error. Pero entre el código fuente se encuentran binarios que fueron compilados para la arquitectura Sparc, puntualmente las CPUs que equipaban las workstations de Sun y que corrían SunOS. El resultado de la experienca, ejecutando ViolaWWW y Erwise puede verse en el siguiente video:



¿Cómo recrear el ambiente de pruebas (SunOS/Solaris)?

Después de ver el video, un amigo me sugirió que sería interesante poder reproducir la experiencia. Siguen abajo algunas de las referencias que seguí para instalar ese antiguo SunOS:
Para emular una arquitectura Sparc en una de nuestras máquinas Intel x86 hay que utilizar la aplicación qemu-system-sparc. Una guía detalladísima sobre cómo instalar el SunOS 2.6 se puede encontrar en el siguiente link:
Running Solaris 2.6 Sparc on qemu-system-sparc in linux x86_64

La única diferencia en el procedimiento se encuentra en el modelo de networking elegido. Yo no tenía necesidad de usar el modo bridged de manera que opté por la configuración más sencilla que qemu tiene disponible -net user, de esta forma la vm guest va a utilizar un modelo similar a NAT. No es posible acceder al guest desde la máquina host, pero en mi caso me bastaba: solo necesitaba salir hacia internet y desde el guest poder comunicarme con el host, donde correría el servidor web. De manera que una vez que el OS guest (SunOs) estuvo instalado en el hd virtual, para iniciarlo se deben ejecutar las siguientes líneas en la consola:

$ export SDL_VIDEO_X11_DGAMOUSE=0 $ qemu-system-sparc -L . -m 128 -M SS-5 -vga cg3 -drive file=/path/a/disk1.img,bus=0,unit=0,media=disk -net nic -net user

La primera línea sirve para corregir un problema con el puntero del mouse que resultaba totalmente errático de otra forma. Quizá por esa misma razón, no pude utilizar software basado en ffmpeg para capturar la pantalla, ya que al intentar hacerlo se producía un conflicto con el puntero del mouse del guest. El resto de la experiencia puede verse en el video. Continuar »

Elogio de la conversación

Los podcasts no son nuevos. Están entre nosotros hace más de quince años. Ya a estas alturas todos nosotros, el público o los consumidores, los percibimos como una experiencia distinta a la radio.

Las líneas en este blog son solo unas observaciones preliminares y por lo tanto, también quizá provisionales. Parto de la base de algunos hechos: los medios tradicionales ya envejecieron pero dificilmente vayan a desaparecer. En ese sentido la oferta y la promesa del podcast es diferente. Posiblemente vengan a ocupar un nicho que nada ni nadie consiguió atender antes. Porque (por suerte) el podcast no es la radio, quizá venga a ofrecernos algo radicalmente distinto.

Icon made from Icon Fonts is licensed by CC BY 3.0

La radio de gran público (FM o AM, poco importa) ha envejecido, eso no es novedad. Con todo, es difícil que esos medios, junto con las tecnologías que lo construyeron (la transmisión de ondas hertzianas en modo "broadcasting") vayan a desaparecer por completo.
Cuando era adolescente con mis amigos escuchábamos regligiosamente cada noche un programa que se llamaba Historock. Iba por FM de la Ciudad que en aquella época se llamaba "la Metro". Teníamos más o menos la misma edad que hoy tiene mi hija mayor, con lo que quiero decir que ya ese tiempo me parece realmente lejano. Posiblemente el tiempo tienda a comprimir algunos hechos en mi memoria pero creo que por entonces, apenas si había TV por cable en algunas casas. Si tenías la suerte de que algún amigo por casualidad la tuviera, te ibas a pasar horas en su casa extasiado por los clips como el de "Last Dance with Mary Jane" de Petty al que acompañaba la misteriosamente bella Kim Basinger o "Gimme All Your Lovin'" de ZZ Top. Pero volvamos a la radio.
Historock era un programa que se emitía de lunes a viernes, de 22 a 24 hs. Repasaba al detalle, con información y muchísimas grabaciones, algunas realmente raras, la historia, como se imaginarán, del Rock. Desde los pioneros del sello Sun de Sam Phillips en Memphis, pasando por la explosión del rock y blues británico hasta "nuestros" días, que eran los días de nuestra contemporaneidad de entonces, más o menos cuando Nirvana lanzaba "Nevermind". Historock podía pasarte el disco entero "Thick As a Brick" de Jethro Tull (dos temas de 20 minutos cada uno), posiblemente porque iba por una radio pública. Por los motivos que fueran, lo hacían.
¿Por qué el ejemplo? Lo que vale de él no es ninguna anécdota. Sino que creo que ejemplifica un "modelo" o un tipo de contrato que la radio le proponía a sus oyentes que ya no existe como tal, o que por lo menos ya no forma parte de ningún "mainstream". Para nosotros, como para el resto de la audiencia, era claro que aquellos que conducían Historock eran la autoridad suprema en cuanto al conocimiento de la música que nos gustaba. Si algo queríamos era llegar a saber tanto como ellos. Tener tantos discos como ellos, o si el presupuesto era escaso -como lo era- al menos tener muchos cassettes grabados, pero escuchar mucha música al fin. El contrato o la forma en que la audiencía podía relacionarse con programas como aquel, era de tipo "pedagógico", un tipo de intercambio necesariamente complementario, en donde una instancia (la "emisión") es el que sabe y la otra instancia, los oyentes son los que quieren aprender.
Ese tipo de intercambio, en radio, televisión o el medio "masivo" que sea desapareció o quedó relegado a lugares marginales. Más cerca en el tiempo Alfredo Rosso encarnaba una posición similar, pero está muy lejos del mainstream de la radio actual.
Ese modelo "pedagógico" -ya fuera alrededor de la música o de algún otro tema- fue desapareciendo o pasando muy a segundo plano durante la década de los '90. Posiblemente y a muy a grandes rasgos la radio actual propone un tipo de intercambio basado en el contacto: vos estás ahí, nosotros estamos aquí. Y poco más, la radio como compañía presente. Aquello de lo que se habla a veces pasa a segundo plano. Pero la conversación no es demasiado central. Los media o lo que queda de ellos tienden a construir un star-system bastante berreta en algunas ocasiones.
Y ahora una valoración, supongo que pese a ser absolutamente subjetiva, quizá sea compartida. En la radio actual no encuentro nada. Nada que me retrotraiga a la escena originaria de Historock. No soy el mismo, claro, pero la radio tampoco es la misma. En la radio la música, al menos parte de las músicas que me gustan ya tiene una existencia totalmente marginal. Importa más un star system estúpido de periodistas que entrevistan mal o que aburren. La radio actual presupone que va a ser parte de un continuo sonoro y que sus oyentes harán escuchas "flotantes", mientras hacen otras actividades. Apagué la radio. Me voy con la música a otra parte.


(Por suerte) los podcast no son la radio

No temo en exagerar al decir que Internet, en tanto red de múltiples redes interconectadas y altamente resiliente a fallas (salvo la de nuestros paupérrimos ISPs), será una de las más grandes creaciones de la humanidad. No deja de llamarme la atención que un desarrollo originalmente militar (promovido y financiado por fondos para la Defensa de los Estados Unidos en tiempo de la Guerra Fría) se haya vuelto algo tan definitivamente "abierto" y "colectivo". Muchas teorías conspirativas hacen agua. Mi explicación quizá naif, mientras leo y reviso algunos libros como "Inventing The Internet" de Janet Abbate o "Where Wizards Stay Up Late" de Hatie Hafner, es que pese a ser un desarrollo completamente cerrado (en el sentido de secreto) llevó el presupuesto a organizaciones civiles -universidades y empresas- en donde había mucha gente que pensaba "más allá", pensaba en estándares, pensaba en intercambios entre iguales, eran si se quiere la expresión de una cierta contra-cultura. Lo que empezó siendo una red para asegurar las comunicaciones ante la eventualidad catastrófica de un ataque nuclear terminó siendo una de las mayores (sino la mayor) herramienta de interconexión que la cultura haya jamás construido.
De los orígenes de internet a los podcast hay una gran distancia. No podría recorrerla aquí. Pero la democratización a escala mundial de las computadoras primero y del acceso a la red después, puso a nuestro alcance toda una serie de herramientas antes desconocidas. Internet no es un "medio", es un paquete dinámico de diferentes medios de comunicación que pueden nacer, desarrollarse y también morir. Internet es la base técnica, la capa de base que permite esos diferentes intercambios.
Un podcast no es solo palabra hablada grabada. Para que "algo" sea reconocido y consumido como un podcast tendrá que tener ciertos atributos que lo caractericen como tal. Siguen un puñado de las que podrían ser a mi juicio algunas de las características específicas del podcast.

Palabra no institucional. En el broadcasting tradicional (la radio como la conocimos) siempre cualquier enunciación por más individualizada que sea en la voz de un locutor, (por poner un ejemplo histórico Antonio Carrizo) está siempre acompañada por otra "voz" en sentido figurado, que es la voz institucional de la propia broadcasting. En el mismo ejemplo histórico, el programa de Carrizo era "La vida y el Canto por Radio Rivadavia". La institución emisora en broadcasting siempre es responsable no solo por la calidad técnica de la emisión sino también por todo lo que se dijera en sus transmisiones. Cuando algún locutor (o locutora) tuviera un exabrupto o accidentalmente ofendiera algún tipo de sentimientos de algún grupo, la voz de la institución emisora se tiene que hacer presente para expresas que "esos dichos no coinciden con sus principios y blah blah.
El podcast es por definición palabra no institucional. Incluso aquellos podcast por ejemplo de periodistas de algún diario, su palabra en el podcast estará el alguna medida despojada de la visión "editora" de la organización a la que pertenece. Es palabra personal y en primera persona. La voz, como se ha dicho muchas veces es producto directo de nuestro cuerpo, es nuestro medio de expresión más directamente visceral, como la caja de un instrumento de cuerda determina su timbre y volúmen.

Un podcast se define por su periodicidad. Construir una audiencia no es sencillo, y la periodicidad más o menos regular manda. Un podcast no es un producto único, sino más bien el resultado de una cadencia de episodios más o menos regular.
En cuanto a su composición un podcast puede articularse sobre la voz de varios -dos o tres a lo sumo- "hosts" (presentadores a falta de un mejor término en .es) que regularmente participan de cada episodio y a los que eventualmente se le suman algún/os invitados. En otros el "host" es la voz regular y "dueño" del podcast y como interlocutor se le suma algún invitado. Posiblemente los podcast absolutamente en solitario (una voz única) sean los más raros, nuestra cultura tiende a desconfiar de los que hablan solos, pero en ese caso están solos con su audiencia.
Los podcast como medio, y quizá lo que su "lenguaje" tenga de interesante es que en algún aspecto vuelven a ponerle diversión al paisaje sonoro actual. En el podcast lo central es la conversación. Este es un tipo de intercambio que escasea en los otros media (los más o menos masivos, o lo que queda de ellos). Veamos por qué escasea: la conversación se define como un tipo de intercambio simétrico en el que dos iguales o pares interactúan a base de la palabra hablada. Se distingue de un intercambio como el del maestro y sus alumnos, del médico y su paciente, del entrevistador y el entrevistado, de la astróloga y sus clientes. Esos son, por el contrario, intercambios basados en la complementariedad o asimetría en donde uno "sabe" (o tiene algún poder) y el otro participante no.
La conversación requiere una cierta durabilidad, un desarrollo temporal que quizá ya no cabe bien en los media tradicionales. Quizá porque la radio presupone que todos sus oyentes hacen una escucha "flotante" entrando y saliendo en la temporalidad de la emisión. La conversación en cambio requiere del compromiso tanto de los interlocutores como de los "testigos" que son la audiencia del podcast. No creo que resulte sencillo escuchar un podcast con la atención "flotante", mientras trabajamos o hacemos otra cosa. En general el intercambio horizontal que se plantea entre los que conversan en un podcast tiende a reproducirse con su audiencia. La invitación, al menos en un contrato no explícitamente escrito es a ser testigo o parte de una conversación entre iguales.
Los podcast dificilmente recreen la escena originaria, de tono pedagógico y divulgador como era el ejemplo de Historock que citaba. Por el contrario, el podcast es un intercambio planteado y ofrecido más bien entre pares (por ejemplo "hecho por fanáticos de Linux para que lo escuchen fanáticos de Linux", o "Hecho por fanáticos de Ford, para que lo escuchen fanáticos de Ford).
¿Producto de nicho? Posiblemente, la complejidad actual de cualquier sociedad moderna está compuesta por miles de "mercados"/"tribus"/"subculturas" no importa qué nombre se les de. Posiblemente durante un mismo día surfeemos atravesando varias de esas sub-culturas. Pero en todo caso, la conversación es un bien escaso y como tal tiene un valor enorme, precisamente por ser un intercambio entre pares. Posiblemente hoy mientras sobrellevamos los días del confinamiento del covid, valoremos la conversación más que nunca, cómo la necesitamos a diario y todo su efecto terapéutico.
Lo que sí de alguna forma el podcast construye de nuevo es una manera de escuchar. Modo de escuchar que la radio de gran público abandonó. De manera parecida a como nos poníamos a escuchar religiosamente Historock el podcast requiere que lo escuches de principio a fin atendiendo al flujo de esa conversación. No es fácil tener buenas conversaciones, lo que sí es seguro es que ellas suelen tener un efecto poderoso sobre nuestras mentes.

retux (Matías Gutierrez Reto)


Continuar »

Meeprommer, grabador de EEPROMs. Notas sobre el troubleshooting.

Desde que era chico y tuve mi primera compu tuve curiosidad por cómo funcionaban los "cartuchos" con memoria de lecturá solamente, como los que también usaban, además de las primeras computadoras personales (msx, atari, commodore, etc) las consolas de videojuegos de segunda y tercera generación.

Los años pasan y por alguna profunda u oscura razones nos siguen gustando juguetes parecidos, a veces quizá algo más caro. Aunque los precios de la electrónica, con el tiempo fueron reduciéndose exponencialmente.
Aquí comento brevemente la construcción -y sobre todo el troubleshooting- de un grabador -diseñado por Mario Keller- de eeprom para aquellas computadoras de 8 bits.

Tiempo atrás, cartuchos como los mencionados solían utilizar EPROMs como la 2764 o 27256. Aquellas EPROMs requerían de exposición a una fuente de luz UV para su borrado. Normalmente se ponía un pequeño tubo UV en una caja estanca y se las exponía por un cierto tiempo, en general 10-15 minutos.

Posteriormente se desarrollaron las "Electrically Erasable Programmable Read Only Memory", que ya no tienen en su encapsulado la ventana para el ingreso de luz UV, porque se pueden borrar eléctricamente.
Hay EEPROMs con distinto tipo de buses, pero las de bus paralelo, como la 28C256 presentan un pinout retrocompatibles con las EPROMs de bus paralelo de generaciones previas, como la 27256.

Para que estas EEPROMs/EPROM puedan servir, por ejemplo para algún proyecto con algún microprocesador de 8 bits (z80,6809, etc) o para programar un cartucho para la Commodore 64 por ejemplo, es necesario usar un grabador. Hoy en día, los grabadores para EEPROMs de bus paralelo pueden ser relativamente costosos.

MEEPROMMER

MEEPROMMER es el nombre de un diseño de Mario Keller basado en un Arduino, publicado bajo licencia open source (MIT): https://github.com/mkeller0815/MEEPROMMER. El autor también desarrolló una aplicación Java que sirve para interactuar con el grabador, para grabar o leer datos desde la memoria, comparar la imagen con el contenido de la memoria, etc. El esquemático puede verse a continuación:

Aquí se puede ver el circuito montado, ya funcionando:

Para llegar a esto, fue necesario un troubleshooting bastante laborioso.

Sobre el troubleshooting

En varios aspectos un montaje electrónico se parece a cualquier otra artesanía: en general una vez montado el circuito en un prototipo o no, siempre es necesario dedicar tiempo al troubleshooting. Por errores humanos u otros factores, siempre algo puede fallar, algo habrá que mejorar o depurar. Estas notas son la historia de este troubleshooting, supongo que quizá le sean de utilidad a otros o posiblemente a mí mismo, cuando me haya olvidado de lo que tuve que hacer para detectar la falla.
Además de el proyecto en github, me fue muy útil para el troubleshooting la información disponible en este site en español: https://8bit65.wordpress.com/2014/09/04/programando-la-eeprom/
También los consejos de foros y de mi amigo el Bocha me fueron de gran utilidad.
Como en un troubleshooting de cualquier cosa, la técnica que me resulta más eficaz es dividir el problema en partes más pequeñas, hasta identificar las fallas.
El diseño de Mario se basa en dos shift registers (los chips 74HC595) que sirven para resolver el problema de la cantidad de pines I/O necesarios para el bus de direcciones (15) más el bus de datos (8) y pines de control de la memoria. Por supuesto, los pines de un arduino nano no serían suficientes. El registro de desplazamiento permite controlar 8 salidas al mismo tiempo, mientras solo se utilizan unos pocos pines del microcontrotrolados. Una buena explicación acerca del principio de funcionamiento puede leerse en: https://www.arduino.cc/en/Tutorial/ShiftOut

Luego de que las primeras pruebas indicaran que algo estaba fallando, para el troubleshooting del circuito seguí el siguiente orden:

1) Testeado del cableado en la placa experimental.

2) Se puede utilizar el monitor serie de arduino IDE o cualquier programa de comunicaciones serie, funcionando a 115200 bps para interactuar con el circuito, utilizando el protocolo que el autor implementó. Pasando un caracter 'V' nos mostrará los comandos disponibles y también se pueden ver con más detalle aquí: https://8bit65.wordpress.com/2014/09/04/programando-la-eeprom/

3) Prueba del bus de direcciones (salida de ambos shift registers). El código original de Keller tiene un comando muy útil para el troubleshooting: A,ADDRESS. Pasándole la dirección en hexadecimal, el bus de direcciones tendrá que asumir el valor dado. Así se encuentra documentado en el código:

// Set the address bus to an arbitrary value.
// Useful for debugging shift-register wiring, byte-order.
// e.g. A,00FF

Entonces el comando A,00FF habrá de poner los primeros 8 bits del bus de direcciones en 1.

Con un array de leds probé el bus de direcciones:

Con esto descubrí que había un problema con mi cableado del bus de direcciones que no había detectado en (1)

Corregido el cableado ahora el bus de direcciones comenzó a funcionar al 100%, pero por algún otro motivo la grabación de datos continuaba fallando.

4) Prueba de lectura: Para las pruebas también me ayudó bastante haber encontrado guardada una RAM estática, memoria que se graba y accede de una forma muy similar a estas eeproms.
Como puede consultarse en su hoja de datos, para concluir cada ciclo de escritura -ya sea de un byte, o de una página de 64 bytes- se lleva a cabo un proceso de "data polling". Se lee la salida del bus de datos, y una vez que esta coincide con el byte que se quería almacenar, concluye el ciclo de escritura.
Seguí el consejo de mi amigo el Bocha y uní algunas líneas del bus de direcciones con el bus de datos. De esta manera, podría setear una dirección arbitraria y leer un byte del bus. Si los datos coincidían la lectura estaría funcionando correctamente.
Agregué una función corta al código para esas pruebas y los datos concidieron. Las cosas empezaban a mejorar, direcciones y lectura funcionaban ok. Como para escritura se utiliza el mismo bus de datos, tenía certeza de que esas líneas estaban ok. Fue necesario además, poner unas resistencias de unos 10K entre los pines del bus de datos que no se usaban y masa, para evitar que en la lectura dichos pines quedara en estado indefinido.

5) El siguiente paso era intentar escribir apenas un byte en una dirección de la memoria y leerlo para ver si el valor conicidía. Para ello una breve función de tests:

void run_tests(void) {
//void fast_write(unsigned int address, byte data)
Serial.println("\nWriting \'c\' char to addr 0000...");
fast_write(0000,'c');
delay(100);
Serial.println("\nReading from addr 0000. Should get ascii 99 ...");
byte data = read_byte(0000);
Serial.print(" ");
Serial.print(data);
}

Esta prueba, con la SRAM tenía éxito, pero con la eeprom no. A esas alturas ya estaba bastante claro que el circuito se encontraba funcionando, pero algo fallaba en la interacción con la memoria eeprom.
La falla resultó ser bastante rara. Pero no solo me había ocurrido a mí. La eeprom tiene un código de bloqueo, que si uno desea establecerlo bloquea la eeprom. No se pueden borrar los datos, si no se envía antes el código de desbloqueo que el fabricante especifica.
Aparentemente, la EEPROM 28C256 que tenía (la única por el momento) había venido bloqueada.
Luego de envíar el código de desbloqueo el circuito empezó a funcionar correctamente.

No me queda más que agradecer a Mario Keller por compartir su diseño, a Marcel Van Kervinck

https://github.com/kervinck (su versión del código me ayudó para el desbloqueo), otros del foro 6502.org y a mi amigo el Bocha. Ahora solo queda darle algún uso interesante al grabador, para divertirse un rato con retro computing.
Continuar »

SELinux ¿De forma fácil?

SELinux es una de las alternativas disponibles en Linux para MAC (Mandatory Access Control), que es una segunda y potentísima barrera de contención por encima de DAC o Discrecionay Access Control, es decir el sistema clásico de permisos en derivados de Unix.

SELinux tiene fama de resultar complejo y dificil para el recién llegado. Este artículo viene por una parte a confirmar esa percepción, pero con la esperanza de que con horas de trabajo el aprendizaje se irá completando.




SELinux fue desarrollado por la NSA junto a otras empresas como Red Hat y Mc Afee que contribuyeron mucho al proyecto. Fue incluído desde las ramas 2.6 del kernel Linux.

SELinux ¿Por qué importa usarlo?

Un kernel linux con política de MAC (Control de Acceso Obligatorio) sirve para confinar programas de usuario y servidores (demonios), como también acceso a archivos y recursos de red. De esta forma es posible aplicar tan solo el menor privilegio requerido para que una aplicación dada funcione, lo que reduce enormemente la exposición a fallas, errores de configuración o buffers overflows. Como SELinux es una forma de implementar RBAC (Role Based Access Control) su uso es altamente recomendado en aplicaciones de la industria financiera o en organizaciones donde hay que reducir al mínimo la exposición de información.
Este confinamiento de aplicaciones, usuario y recursos no reconoce el concepto de "roor" o super-
usuario y no comparte características del control de acceso discrecional como setuid/setgid.
En tiempos de Spectre y Meltdown, cualquier implementación de MAC que contribuya a ofrecer un cierto grado de seguridad adicional resulta valiosa.

Él está ahí, no lo deshabilites

En muchas oportunidades nos encontramos con algún tutorial o incluso con el vendor de alguna aplicación que diga "La aplicación X requiere deshabilitar SELinux". Eso siempre es lo último que hay que hacer. En realidad lo que eso quiere decir el vendor Y no tiene idea acerca de cómo hacer que su app funcione con SELinux.
¿Por qué deshabilitarlo es la peor idea? Porque por defecto las distribuciones actuales que utilizan SELinux (puede ser Centos o RH pero también Debian) vienen con una política ya configurada que permite que cuando ejecutamos aplicaciones como nginx o apache estas ya corran "confinadas" en un dominio SELinux. Deshabilitar SELinux globalment supone perder esa ventaja.
Pero SELinux tiene una fama bien ganada de tener una curva de aprendizaje lenta, de ser complicado por demás. Hay que decirlo también, puede ser complicado pero ofrece una solución sumamente potente para MAC.
Este artículo, breve es el resultado de haber dedicado unas cuantas horas a entender algo sobre SELinux y a escribir un módulo para ejecutar confinada una aplicación web simple. Por defecto, en un sistema con SELinux una apliación que no está descrita en la "policy" correra en modo no-confinado, es decir, como si SELinux no estuviera corriendo.
Es cierto que actualmente SELinux es mucho más sencillo de lo que acostumbraba debido a que vienen incluidas con él un set de herramientas que hacen las cosas bastante más fáciles.
Más que nada el artículo tiene por objeto describir cuál fue el proceso para escribir un módulo, lo que implicó un arduo trabajo de iteracioes prueba/error, hasta que finalmente la aplicación quedó funcionando confinada.
Antiguamente la policy de SELinux solía ser monolítica, pero actualmente se pueden escribir módulos (de alguna forma similares a los del kernel linux) que permiten escribir políticas modulares por cada aplicación. De hecho si en un sistema SELinux hacemos # semodule -l veremos todos los módulos que componen la policy, identificados en general por la aplicación que confinan.

Algo concreto con SELinux

Para esta PoC utilicé una aplicación web muy simple que suele la que uso para probar algunas cosas. Es una versión web del clásico Fortune (escrita con el micro framework flask en python). La misma, junto con la policy SELinux se puede encontrar aquí: https://github.com/retux/flask-web-fortune

La vamos a configurar con un nginx que actuará como reverse proxy:


I N T E R N E T ⇒ NGINX:80 => localhost:5000



Para escribir nuestro módulo CentOS se requieren los siguientes paquetes:

setools-console
policycoreutils-python-2.5-17.1.el7 // Este último provee el binario para /usr/sbin/semanage
policycoreutils-devel // este provee los pkg de desarrollo para escribir policies.

Con web-fortune escuchando en el puerto 5000 la aplicación correrá como unconfined:

# ps auxZ | grep web
system_u:system_r:unconfined_service_t:s0 rtxapps 12430 0.0 1.6 223476 17064 ? Ss 15:08 0:00 /usr/local/share/venvs/flask-web-fortune/bin/python /usr/local/share/applications/web-fortune/app.py

Una vez que hayamos configurado el reverse proxy para que conecte a localhost:5000 seguramente nos entraremos con una barrera que nos pone SELinux. En el audit.log veremos mensajes como este:

type=AVC msg=audit(1519064697.245:443): avc: denied { name_connect } for pid=12674 comm="nginx" dest=5000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:commplex_main_port_t:s0 tclass=tcp_socket
type=AVC msg=audit(1519064697.246:444): avc: denied { name_connect } for pid=12674 comm="nginx" dest=5000 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:commplex_main_port_t:s0 tclass=tcp_socket

audit2allow es LA herramienta SELinux que servirá para todo el camino, en general siempre va a darnos alguna pista acerca de lo que hay que hacer, pero debemos tener cuidado de no seguir todo al pie de la letra.

# tail -n30 /var/log/audit/audit.log | grep avc | audit2allow


#============= httpd_t ==============

#!!!! This avc can be allowed using the boolean 'httpd_can_network_connect'
allow httpd_t commplex_main_port_t:tcp_socket name_connect;

nginx no consigue conectar al puerto TCP 5000 porque la policy no lo permite.
Como indica audit2allow, tenemos dos alternativas:

La primera utilizar booleans (httpd_can_network_connect), con este boolean vamos a habilitar varias cosas, por ejemplo que el servidor web (en este caso nginx pueda conectar diversos puertos, smtp, el 5000 como requerimos acá).

# getsebool httpd_can_network_connect
httpd_can_network_connect --> off

# setsebool httpd_can_network_connect on

Si funciona de la manera esperada lo podemos setear como Persistente (con el modificador -P)

# setsebool -P httpd_can_network_connect on

Los booleans de SELinux son como interruptores que permiten cambiar algún aspecto de la policy al vuelo. Habilitando este boolean permitieremos que las aplicaciones que corran en el dominio httpd_t puedan conectar a un puerto TCP. Este puede ser el 5000 de nuestra app o el 25 para un MTA local por ejemplo, con lo cual este boolean tiende a ser bastante utilizado.
Cabe destacar que bajo ningún concepto SELinux reemplaza a otras herramientas como iptables o firewall en general. SELinux es una capa más en el camino de la seguridad que se complementa con muchas otras.
Habilitado el boolean y con web-flask-fortune corriendo en modo no-confinado tendremos las cosas funcionando. Pero siempre hay más, siga leyendo lector.


Creando un módulo de SELinux policy "from scratch" para confinar fortune

Si por ejemplo queremos confinar una aplicación, en mi caso una web app flask que escucha en localhost:5000 y que tiene un nginx río arriba.

El comando sepolicy generate sirve para crear los archivos iniciales necesarios para compilar un módulo, o sea los .te, .fc y .if.

Ejemplo:

sepolicy generate --init -n web-fortune /home/rtxapps/.venvs/flask-web-fortune/bin/python

Nótese que el path a python es el binario con el que va a correr la app python, en este caso la versión del venv. En general el path al archivo que inicia el demonio lo podríamos tomar de ExecStart del unit file de systemd.

Después de ejecutar el .sh que provee tendremos que tener el módulo compilado e insertado en la policy de SELinux:

# semodule -l | grep web-fortune

Y después de un restart del servicio podremos ver que en contexto (más que nada el tipo) con el que corre el script ha cambiado:

# ps auxZ | grep fortune | grep -v grep
system_u:system_r:web-fortune_t:s0 rtxapps 15081 0.0 1.6 223476 17068 ? Ss 19:55 0:00 /usr/local/share/venvs/flask-web-fortune/bin/python /usr/local/share/applications/web-fortune/app.py

Puede decirse que ahora la aplicación está corriendo confinada.

Podemos ver también que SELinux etiquetó el “binario” python que inicia nuestro script:

# semanage fcontext -l | grep "fortune"
/usr/local/share/venvs/flask-web-fortune/bin/python regular file system_u:object_r:web-fortune_exec_t:s0

Este era el contexto original de fortune.txt:

ls -lZ /usr/local/share/applications/web-fortune/fortune.txt
-rwxrwxr-x. rtxapps rtxapps unconfined_u:object_r:usr_t:s0 /usr/local/share/applications/web-fortune/fortune.txt

De seguro, la app habrá quedado funcionando sin problemas porque el type web-fortune-t está corriendo en modo permissive:

# semanage permissive -l

Customized Permissive Types
Builtin Permissive Types

web-fortune_t
…

Por defecto en el archivo .te que nos haya generado sepolicy generate incluye una línea:

permissive web-fortune_t;

“Builtin permissive” se refiere a módulos que fueron construidos con ese tag en su archivo .te.
Esto es MUY interesante, porque indica cuál es el flujo de trabajo cuando trabajamos para “confinar” los privilegios de una app con SELinux. El modo permissive permite que una vez que hayamos insertado nuestro módulo éste haga que SELinux escriba las AVC que violen las reglas, pero eso es precisamente para que la aplicación corra sin restricciones, va a loguear los problemas y podremos ajustar el módulo para ajustarlo a la necesidad.

Hay que tener en cuenta que un módulo que corra en modo permissive no lo podremos deshabilitar, de esta forma:

# semanage -d web-fortune_t
libsemanage.semanage_direct_remove_key: Unable to remove module permissive_web-fortune_t at priority 400. (No such file or directory).
OSError: No such file or directory

Source: http://danwalsh.livejournal.com/42394.html

Para que podamos cambiar un "tipo" o app de modo permisivo o no debemos comentar en esa línea en el .te.
Pero esto define el flujo de trabajo para el desarrollo del módulo de la app. En modo permisivo la app va a funcionar sin bloqueos, pero logueando las violaciones a las reglas de la policy. Con dichas violaciones en el log (audit.log o messages) usaremos audit2allow para depurar el código. Este es un arduo camino. Nadie dijo que era fácil.

¿Qué hacer cuando lo sacamos de modo permissive y la app no anda y aparecen AVCs en el log?

El trabajo es recursivo, prueba y error. Una forma en que audit2allow nos puede ayudar -y mucho- es la siguiente:

audit2allow -a -l

O bien:

audit2allow -a -l -M nombre-modulo

Este último generará los cambios que necesitamos en un módulo (.pp) podemos ir agregando las indicaciones que nos de audit2allow a nuestros .te. El modificador -l nos dará una indicación de las AVCs ocurridas desde la última carga de la policy (o de módulo).
En el caso de este módulo, fue central agregar el contenido de la sección require:

require {
type commplex_main_port_t;
type net_conf_t;
type ldconfig_exec_t;
type bin_t;
type proc_t;
type node_t;
type shell_exec_t;
type web-fortune_t;
type cert_t;
type usr_t;
type lib_t;
type user_home_dir_t;
class tcp_socket { accept bind name_bind node_bind shutdown };
class file { execute execute_no_trans getattr open read };
}

Queda para otro artículo la comparación y la misma implementación usando otra herramienta para confinamiento, como puede ser apparmor.

Fuentes:

https://mgrepl.wordpress.com/2015/05/20/how-to-create-a-new-initial-policy-using-sepolicy-generate-tool/

Dan Walsh es la autoridad de SELinux, la mejor doc es de su autoría. Todos sus posts son más que útiles: https://danwalsh.livejournal.com/

Continuar »

Infra como codigo: manejar containers LXD con terraform

No hace falta argumentar las ventajas del uso de Infraestructura como Código, sea cuál fuere el destino, plataformas de cloud como aws, google o muchas más. Pero también es una herramienta muy práctica para gestionar como código la creación de containers de docker o lxc. En este caso me ocupo de algunos ejemplos simples para uso con LXD.

Terraform es una herramienta para construir, cambiar y versionar infraestructura de manera segura y eficiente.



Terraform y sus providers

Terraform tiene la enorme ventaja de manejar sos providers como plugins instalables, separados del binario principal. Esta es una forma de modularizar la aplicación como también de hacerla más fácilmente extensible.
Existen providers no solo para las principales plataformas de cloud (SaaS, PaaS, IaaS). Una lista de los plugins oficiales puede encontrarse en el site de terraform: https://www.terraform.io/docs/providers/
Pero también la comunidad crea otros providers, en este caso el plugin para manejar containers de LXD es: https://github.com/sl1pm4t/terraform-provider-lxd
Una vez instalado el plugin como indica la doc, en el directorio .terraform/plugins/linux_amd64/, relativo a donde tengamos nuestro "código" de terraform, podremos listar los providers:

$ terraform providers
.
├── provider.lxd

Con eso listo ya podemos crear los containers codificándolos, sigue un ejemplo simple:

providers.tf

provider "lxd" {
alias = "unix"
}

profiles.tf

resource "lxd_profile" "ssh-access" {
name = "ssh-access"

config {
limits.cpu = 1
}
}

container.tf

resource "lxd_container" "test1" {
name = "test1"
provider = "lxd.unix"
image = "images:debian/stretch/amd64"
ephemeral = false
profiles = ["default", "ssh-access"]
depends_on = ["lxd_profile.ssh-access"]


provisioner "local-exec" {
command = "lxc exec test1 -- /bin/sh -c 'apt-get update && apt-get install openssh-server -y'"
}

}

Y con terraform plan / apply ya tendremos nuestro primer container creado.
Para un aprovisionamiento simple terraform utiliza ssh, como la mayoría de las imágenes de lxd vienen sin openssh-server instalado, deberemos aprovisionarlo con el recurso local-exec.
Continuar »

Story of a Commodore 64

Almost any object can become part of a certain story. This is the story of an old Commodore 64 (8 bits computer) I got for a few dollars here in Buenos Aires. The computers was not working so this is the story of how I found the parts needed to take it back to life.

In part of my spare time I enjoy working on electronics and with nowadays is called “maker culture” and more particularly with retro-computing.
When I was a kid my first computer was a Radio Shack Color Computer II (known as coco 2). I was lucky to get that computer. At that time it gave me lot of fun and excitement. Coco was just great. Still I keep that coco with me, and is working just fine as in the old days. Of course today, it is mostly useless as you can not search the web, or even use a fancy spreadsheet.
I remember Linus Torvalds’ opinion on 8 bit computers: At those days if you had enough documentation and curiosity you could develop a good knowledge about how a computer works. Because computers were simpler than the ones that came after. That is part of the success of a computer like Raspberry Pi.
I think we can still learn a lot of those old computers. It’s just like going to a museum, but a particular one where you can play around
with objects.
Some months ago I got a Commodore 64 for a few argentine pesos. The reason why? The computer did not work. The outside was good, keyboard looked fine, case was in good shape too, but there was no video output and the power supply had been lost. No video, no power supply.
I wondered if I should have removed the pcb and put a raspberry Pi in it, but I decided first to try to repair the commodore and to get or build a power supply.

The cause of the video failure (no video at all/black screen) was the MOS-8701 chip. The chip had to be replaced, and finding one of them nowadays is not easy.

Fortunately, I was able to find a new one. The price was not cheap, but at that point I was committed to get the C64 repaired.

Then, I went to a the house of a friend of mine who owns a c64 and tested mine. With the new 8701 it was working.
Now it was necessary to get or build a power supply. C64 original PSU it was its weakest part. The power supply used to get very hot, and I mean very hot. It was placed inside a dust proof case and that contributed to the increasing heat.
So building a modern power supply using a switching psu would be fine. With parts I have lying around the house: a case, a switching 5 Vdc power supply and a transformer for 9 Vac. Finding a DIN plug the C64 uses for PSU was not easy nowadays. I almost gave up, but finally I could get one. Otherwise I would have had to order it abroad.
I put those parts inside the case, added a 2A fuse for the 9 Vac output. Tested the voltages and the DIN pinout twice, and then plugged into the C64.
The computer is working as in the old days. Now is time to get some games and show the kids how we had fun time ago.

In this video C64 and it "brand new" psu can be seen working:

-RetuX-
Continuar »

Una historia retro (computación)

Casi cualquier objeto puede convertirse en una historia. Cosas incluso con poco o nulo valor de cambio pueden tener un enorme valor de uso para alguien. Los que amamos ciertos objetos, aún más allá de las posibilidades de nuestro espacio en casa lo sabemos bien.
Esta es la historia de una Commodore 64.

A más o menos 30 años de su punto de mayor suceso en el mercado la conseguí por unos pocos pesos. Claro, no funcionaba y tampoco tenía fuente de alimentación. Lento trabajo y diversión de fin de semana, ayuda de amigos y un poco de cabezadurismo per jodere y la C64 está en funcionamiento otra vez.


Linus Torvalds se refería a las computadoras de la era de los 8 bits de una manera, me parece, muy acertada: bastaba que tuvieras acceso a la documentación e información para que desarrollaras conocimiento con y acerca de esas máquinas. No es casual que varios desarrolladores del kernel Linux sean aficionados fervientes del retro computing, quizá el caso más conocido sea el de John Linville.
Tampoco es casual el éxito de las Raspberry Pi. Dejen que sean populares y si los chicos se interesan de verdad seguramente las aprovechen. Cuanto más básica es una herramienta más necesitas desarrollar una habilidad con ella.
Creo que tantos años después sin duda alguna nostalgia cabe: tener una C64 en la Argentina de aquel tiempo era algo que no todos podíamos tener. Sin no me equivoco, fue algún aristócrata europeo el que dijo, la principal diferencia entre un hombre y un niño es el precio de sus juguetes.
Fue así: a fines de 2016 conseguí por unos pocos pesos esta Commodore 64, en buen estado externo pero sin funcionar

.
El bajo precio se justificaba porque la máquina no funcionaba, y además se le había perdido o destruido la fuente de alimentación original.
Con la ayuda de mi amigo Hernán y Alejandro -con los que desde la secundaria nos hicimos todos radioaficionados- hicimos el troubleshooting básico: pudimos detectar por qué la máquina no generaba señal de video. El chip MOS-8701 era el responsable.

Conseguirlo fue providencial. No creo que hoy en día se use ese integrado para alguna otra cosa supongo, así que me hipótesis es que habrá quedado en stock desde los años '90.
Reemplazado el chip había que encontrar una fuente de alimentación. La fuente de alimentación original de la C64 era su talón de Aquiles. Era una caja estanca que calentaba por los cuatro costados. Recuerdo un amigo de la primaria que la tenía sobre una alfombra. Un milagro que de jugar al Moon Patrol no hayamos prendido fuego la alfombra.

Esquemático de la fuente original

La fuente original era muy básica. Por supuesto no era switching, lo que hacía que fuera mucho menos eficaz. Pero eso era lo habitual para la época.
Quizá lo más revolucionario que tuvo la Apple II, primera computadora masiva de Apple fue que fue la primera en contar con una fuente switching. Era algo que la hacía cara, pero era revolucionario para cuando esa máquina salió al mercado.
El resto de las computadoras similares, no la tenía.
Entonces lo más fácil en el siglo XXI era armar un gabinete con una fuente switching y un transformador convencional para la salida de 9 VAC.
La fuente switching vino de algún switch de red que no sirvió más. Y el trafo, lo compré ex profeso. El gabinete también había pertenecido a alguna fuente y lo había guardado pensando usarlo alguna vez.

Agregué un fusible a los 9VAC (de 2A) ya que la switching provee bastante protección.

Y esa es la historia de esta C64. La fuente funcionando puede verse acá:


Continuar »

conky se integra cada vez mejor con KDE Plasma

Desde que usaba fluxbox como window manager en una vieja notebook Pentium III durante los primeros años 2000 siempre me gustó conky o su antecesor, torsmo.

En la mayoría de los ambientes de escritorio conky se integraba sin problemas. Con KDE lo hacía interfiriendo un poco con los widgets nativos y modificando un poco el comportamiento general del escritorio. Creo que esos días pasaron para siempre. Por lo menos ahora estoy super conforme con cómo conky se integró con Plasma.

Recientemente también conky cambió la forma en que la configuración (en general el archivo ~/.conkyrc) debe estar estructurada. La configuración que venía usando, que se puede ver en la imagen está disponible en este repo:

https://github.com/retux/conky-configs

Una breve guía sobre cómo instalarlo se puede leer en el README.

¿Cómo optimizar la configuració con Plasma?

La clave de esto la encontré por algún foro que ahora no puedo encontrar su url, pero se trata de lo siguiente:

Verán en el archivo de configuración la definición del tipo de ventana para conky es:

own_window_type = 'dock'

Bueno, esto hará la magia. Lo que debemos configurar es el comportamiento que deseamos para esa ventana, lo que en Plasma se hace de esta forma:

Fíjense que el nombre que le demos a la ventana, en este caso 'conky' es significativo. Con eso debe bastar, desde luego hay que ajustar las preferencias en la sección de texto del .conkyrc para que reflejen las características de su equipo.


Continuar »

Proyecto de fin de semana: Usar una fuente ATX como fuente para Lab con termostato (opcional)

Las fuentes ATX genéricas son relativamente económicas y tienen múltiples ventajas: ofrecen una variedad de tensiones de salida con corrientes generosas. 3,3v; 5v, 12V entre otras tensiones de salida sirven para tener una buena fuente de laboratorio con salidas estabilizadas y bien filtradas.

Ideal para probar cualquier circuito digital. A continuación sigue un proyecto muy simple: modificar una fuente ATX genérica y además con un agregado opcional: si no queremos que el cooler funcione constantemente se usa un termostato simple, que encenderá el ventilador cuando la temperatura interna sea superior a los 30° aproximadamente.

En la secundaria, el Cuba del barrio de Belgrano, uno de los primeros trabajos prácticos del taller de electrónica consistía en construir una fuente de alimentación variable de 2-30v. Se empezaba en primer año, en el taller de hojalatería, armando el gabinete de chapa rígida.
Durante un bimestre de segundo año, creo, se mandaba a bobinar el transformador, y con todos los componentes listos, la armábamos. Todavía la conservo y sigue andando muy bien.
La contra de las fuentes como aquella, básicamente es que por no ser switching son muy pesadas. El Apple II fue la primera computadora en tener una fuente switching a fines de los '70 y en aquel tiempo debía resultar muy costoso, pero en términos de "usabilidad" aquella máquina debía pesar menos de la tercera parte de sus competidoras que no usaban fuente switching.
Hoy en día es muy sencillo y relativamente económico encontrar una fuente de tensiones múltiples, con buen filtrado y estabilización: cualquier fuente ATX de PC.

Fuente ATX para Lab, con termostato (opcional)

Este fin de semana me hice de un rato para divertirme adaptando una fuente ATX. Mi idea inicial era la siguiente: precisaba una fuente de 5Vcc con por los menos 2A, para alimentar en simultáneo varias Raspberry Pi que están dando vueltas por ahí. Una de ellas tiene un disco duro que también requiere +12Vcc. Con una fuente que continuamente esté disponible también aprovecharía los 5Vcc para colgar un hub USB que sirviera de cargador para la mayoría de los celulares de la familia.
Además uno de mis TOCs es que no me gustan los coolers. Son necesarios lo sé, pero hacen ruido. Por eso pensé agregarle un termostato a esta fuente modificada. El cooler solo se encendería cuando el calor en el interior fuera superior a cierto umbral.

Para poder conectar todo fácilmente se puede usar una bornera. Yo agregué también una DIN/Canon para usar para la salida para las raspberries.

Una vez hecho eso, hay que cortar los cables y conectarlos uno a uno a la bornera y soldar en la ficha canon. El código de colores usado para identificar las tensiones en las PSU ATX puede encontrarse aquí: http://www.instructables.com/id/A-Makers-Guide-to-ATX-Power-Supplies/step2/Wire-Colors-Functions-in-the-PSU/

Si fuéramos a usar la fuente para un Lab, para probar circuitos o proyectos, con la bornera creo que estaría más que suficiente. Decidí agregar un pequeño termostato, que es un circuito muy similar al que se ve acá: http://www.craig.copperleife.com/tech/thermo/
Basado en un opercacional LM741 como transistor usé un BD140. Entro colector y emisor va a circular la corriente que impulsa el cooler, una vez que la temperatura supere la que se haya calibrado. El termostato es muy simple y con los valores usados sirve para accionarse entre los 25-35 grados centígrados.

Acá se puede ver el termostato ya montado. Hablando eléctricamente, dentro de la fuente el ambiente es muy ruidoso. Pensé que el ruido volvería loco al 741, pero por suerte se comportó de diez.

Así es como quedó una vez cerrado el gabinete.

Es un proyecto simple y creo que útil.

Pero ATENCIÓN con esta advertencia:

Las fuentes switching funcionan con tensiones muy elevadas por eso su manipulación es riesgosa. Por eso hay que tener mucha precaución incluso aunque hayamos desconectado la fuente de los 220V, porque los capacitores quedan cargados de energía por bastante tiempo. Por eso hay que tener mucho cuidado si se desarma una fuente, más si estuvo funcionando recientemente.


Continuar »