El Open Source Bajo la Lupa

Hay un artículo1 escrito por Don Goodman-Wilson empleado de Github y miembro de Maintainerati. Ha sido sumamente inspirador por un lado y, ¿por qué no? pone en palabras cosas que uno viene elaborando hace rato.

unsplash-logo Tim Marshall

DGW lanza una ataque demoledor sobre la OSI (Iniciativa del Open Source) al afirmar que facilita la concentración en manos poderosos a expensas de la explotación de los desarrolladores y está muy lejos de propiciar la democratización que declama.

Se propone el autor del post reemplazar ideologías centradas en el código por gente-céntricas. En síntesis: si las elecciones que tomamos respetan a los seres humanos son correctas, de lo contrario no lo son. Y que la ideología del Open Source cosifica.

La crítica más contundente que hace sobre el código abierto es que explota trabajo no remunerado. Y ese modelo dice, es insostenible.

Cita algunos casos interesantes que contraponen esta supuesta neutralidad del software:

  • La licencia de JSON
  • La licencia de 996.ICU
  • La licencia hipocrática de Coraline Ada Emke

Algunos principios para iniciar algo nuevo

  • Los responsable de un proyecto de software merecen ser tratados como personas.
  • La tecnología existe para servir a las necesidades humanas.
  • Los valores del código abierto tienen que servir a la comunidad

El código fuente es un dogma al que no le interesan las personas.

Y se termina preguntando:

¿Cómo luce un modelo colaborativo centrado en las personas, de desarrollo de software abierto?

Quiero agregar como opinión personal que mi posición está muy alejada de "software libre" bueno, "open source" malo. No hay mucha distancia de lo que proponen los caprichos del stallmanismo. Según él, lo más importante es la libertad del software. El centro no son las personas. Pero bueno, eso da para otro post.

Cómo Hacer Túneles SSH

Una de las funcionalidades extraordinarias que posee openssh es la de encapsular el tráfico inseguro a puertos TCP. A continuación vemos algunos ejemplos útiles de cuándo y cómo utilizarlos.

Túneles

unsplash-logo Aaron Burden

Algunas suposiciones:

  • openssh-server.example.com: Es el host que posee el servicio ssh y el servicio sin cifrar
  • otrohost.example.com: Es un host que posee un servidor web sin TLS pero que carece de ssh.
  • 192.0.2.1/24: Es la dirección IP del cliente ssh.
  • filtrado.example.com: Es un host que tiene el puerto del servicio al que queremos acceder pero se encuentra filtrado para el exterior.
  • casa.example.com: Es un host remoto respecto a un servidor ssh accesible desde la red de filtrado.example.com. Este host está en un lugar en el cual podemos trabajar cómodamente 😊 por fuera de la infraestructura de filtrado.example.com.

Caso 1: Redireccionado remoto (Segurizar un servicio sin cifrar)

Queremos segurizar el acceso a un servidor web sin TLS.

ssh -N -f -v -L 10001:localhost:80 openssh-server.example.com

  • 80: Es el puerto que tiene el servicio sin cifrar
  • localhost: Es la dirección en el host servicio-remoto.example.com que escucha en el puerto 80.
  • 10001: Es el puerto local al cual tendremos que conectarnos para obtener el servicio web.
  • -N No ejecuta comandos en el lado remoto.
  • -g Permite a otros hosts conectarse a nuestro puerto 10001.
  • -f El proceso va al segundo plazo antes de la ejecución de comandos.
  • -v Imprime información detallada.
  • El url que habrá que poner en el navegador es http://localhost:80.

Caso 2: Redireccionado remoto laxo (Segurizar un servicio sin cifrar)

Queremos permitir que otros hosts de la red puedan acceder nuestro servicio encapsulado.

ssh -g -N -f -v -L 10001:localhost:80 openssh-server.example.com

  • -g Permite acceder a otros hosts de la red 192.0.2.0/24 acceder a el url http://192.0.2.1:10001/

Caso 3: Redireccionado remoto (Segurizar un servicio sin cifrar en otro host)

Queremos acceder de manera segura a un servicio sin TLS ni ssh.

ssh -N -f -v -L 10001:otrohost.example.com:80 openssh-server.example.com

  • Aquí la url será http://otrohost.example.com/10001

Caso 4: Acceder puertos filtrados

Queremos acceder a un puerto filtrado

ssh -v -N -f -R 9000:localhost:22 casa.example.com

  • 22 es el puerto al que queremos conectarnos desde casa.example.com al puerto 9000

Caso 5: Acceder a puertos filtrados y permitir acceso a otros hosts de la red

Queremos permitir que otros hosts de la red local de casa.example.com puedan acceder al servicio encapsulado

ssh -v -N -f -R 0.0.0.0:9000:localhost:22 casa.example.com

  • Luego para acceder al puerto ssh de filtrado.example.com podremos hacer por afuera de la red:
ssh -p 9000 casa.example.com
  • En este caso debe estar habilitado GatewayPorts en el archivo sshd_config

Borrar configuraciones de red

En Linux a veces nos podemos meter en un embrollo. Los sistemas para configurar y administrar la red son varios:

  • net-tools

  • iproute2

  • Archivos "legacy"

  • NetworkManager

  • systemd-networkd, etc

Cuando colisionan y necesitamos blanquear la configuraciones podemos hacer lo siguiente:

for i in $(ip -4 -o link |  cut -f2 -d ":"  | grep -v '^lo$')
        do
           ip addr flush dev  "$i"
           ip route flush dev  "$i"
           ip rule flush dev  "$i"
        done

Listo, a hacer la configuración en limpio ahora!

Obviamente no deberíamos hacer esto con una conexión remota a un equipo no virtualizado :)

Edición de Wikipedia o Wikiversidad

  1. Sí, puedo afirmar que la comunidad wikipedista es receptiva a nuevos usuarios y aportes. Mi primer aporte es de 2005 y en general la experiencia ha sido positiva.

  2. Si un docente decide poner a sus estudiantes a editar creo que en general tendrá un efecto positivo. Desde luego existe el riesgo de colisiones o que ciertos artículos puedan quedar de manera inconsistente. O tal vez con opiniones personales, cuestiones muy secundarias o carencia de referencias.

  3. Las dificultades anteriores podrían resolverse leyendo esta página:

  4. Ayuda:Contenidos - Wikipedia, la enciclopedia libre

Por supuesto es mucha documentación para leer, pero creo que los más importantes son:

El artículo que edite para esta actividad es :

Vim - Wikipedia, la enciclopedia libre

Cómo hacer un producto

Uno de los conceptos más importante que trajo el movimiento Open Source es que el software1, más que un producto es un proceso. Las nuevas tendencias en gestión de proyectos retoman ese concepto. Sí, aun cuando hablen paradójicamente que lo importante es el producto. En el antiguo concepto de tipo catedral, un producto solo podía estar terminado tras meses, años o décadas. En este momento no voy a ahondar esa idea en particular. Pero quiero aportar el siguiente diagrama para tanto para el arranque como para la consecusión de proyectos. Puede ser una aplicación, una documentación, una implementación, creo que es bastante abarcativa la idea. Describiré bremvemente cada fase del diagrama:

El proceso para hacer un producto

Fase Descripción
Base Tiene la terminología, conceptos, herramientas fundamentales para que tenga sentido el trabajo
Formato Tiene que tener una coherencia y una legibilidad o usabilidad básica para que pueda ser aprovechada por otros
Valor Agregado Aquí es cuando le agregamos al trabajo ese talento especial que todos tenemos que hace distinto el producto. Al terminar esta fase el producto se considera entregable. Sea para ser presentado ante un jefe o vendido a un cliente
Corrección de Errores Una vez que hemos obtenido feedback del resto del mundo, podemos corregir errores
Optimización En este punto volvemos a los pasos Base, Formato, y Valor Agregado. ¿Hasta cuándo? ¿Hasta que sea perfecto? Bueno, eso no existe. La idea es iterar todas las veces que el sentido y la alegría estén presentes

Conclusión

Si bien hay un momento en que el proceso da y debe dar como resultado un producto, es bueno tener definidas algunas fases. Una nota especial a los que padecen perfeccionismo. Es importante notar que hay dos frentes aquí. El primero es que justamente aquellos que están detrás de los resultados rápidos y atajos son muchas veces los que más hablan sobre lo perfecto que tienen que estar las cosas. El segundo frente es interno. El que siempre encuentra un obstáculo para pasar de la fase del Valor Agregado. Si bien el primer frente es incontrolable y no depende de nosotros ya que no es nuestro problema, el segundo es el que nos tiene que interesar, acallar esa vocecita que nunca quiere que obtengamos el producto. Justamente esa fase se llama Valor Agregado porque es lo que convierte tu trabajo en un producto en algo distinto. Es esa pieza que falta para que el mecanismo funcione correctamente.

Licencia de Creative Commons
Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.

Sistemas de construcción de paquetes (Parte 4)

De acuerdo a los resultados, podría verse que autotools sigue siendo el “Build System” predominante. Otros paquetes todavía usan un makefile plano, tal vez merezcan un análisis aparte.

Limitaciones de estas estadísticas:

  1. Se confía en que siempre que se usa CMakeList.txt se usa cmake.
  2. Se confía en que siempre que existan los archivos  configure.ac o configure.in y Makefile.am o Makefile.in y se encuentra en el archivo spec el procedimiento ./configure && make se usan las autotools
  3. Hubo 1 (un) archivos que no pudieron ser inspeccionados por dtrx porque tenía la extensión incorrecta

Actualización 2019

Las dos cosas más notables son la reducción del uso de autotools y por otro lado la aparición de sistemas alternativos de construcción (casi un 70%).

Sistema de construcción de paquetes (Parte 3)

Sistemas de contrucción de paquetes (Parte 2)

El siguiente paso fue descomprimir de manera recursiva los paquetes, para luego poder inspeccionar en ellos. Lo hice con una herramienta poco conocida dtrx. Lo interesante de este script de python es que puede realizar extracciones recursivas y de acuerdo a la extensión del archivo utiliza el software de extracción necesario. Esperemos que pronto esté en los repositorios de Fedora (ver la solicitud en Red Hat Bugzilla).

Una vez descompridos todos los paquetes, se corrió el siguiente script

#! /bin/bash #Very simple script to get Build System Statistc dir=1
rm -f /tmp/ant /tmp/cmake /tmp/autotools /tmp/makefile /tmp/autoconf /tmp/autotools_procedure
for i in (find dir -maxdepth 1 -mindepth 1 -type d)
do
ls -R1 i | grep -q -P -m1 "^configure.(ac|in)"
if [[ ? -eq 0 ]];then
ls -R1 i | grep -P -q -m1 "^Makefile\.(am|in)"
if [[ ? -eq 0 ]];then
echo "{i##/}" >> /tmp/autotools 2>/dev/null
cant_autotools=(($cant_autotools+1))
else
echo "{i##
/}" >> /tmp/autoconf 2>/dev/null
cant_autoconf=(($cant_autoconf+1))
fi
fi
#cmake
ls -R1 i | grep -q -m1 CMakeLists.txt
if [[ ? -eq 0 ]];then
cant_cmake=((cant_cmake+1))
echo "{i##/}" >> /tmp/cmake 2>/dev/null
fi
#Plain makefile
ls -R1 i | grep -q -P -m1 "^configure\.(ac|in)"
if [[ ? -ne 0 ]];then
ls -R1 i | grep -q -P -m1 "^(Makefile.(am|in)|CMakeLists.txt)"
if [[ ? -ne 0 ]];then
ls -R1 i | grep -q -P -m1 "^Makefile"
if [[ ? -eq 0 ]];then
cant_makefile=((cant_makefile+1))
echo "${i##
/}" >> /tmp/makefile 2> /dev/null
fi
fi
fi
find i -name "*.spec" | xargs pcregrep -q -M "%build(.*\n)*(./|%)configure.*\n(.*\n)*make(.*\n)*%install"
if [[ ? -eq 0 ]];then
cant_autotools_build_section=(($cant_autotools_build_section+1))
echo "{i##*/}" >> /tmp/autotools_procedure
fi
done
echo "###Resultados###"
[ -f /tmp/autotools ] && echo -e "There are cant_autotools with autotools:\n\n(sort /tmp/autotools)\n\n"
[ -f /tmp/cmake ] && echo -e "cant_cmake with cmake:\n\n(sort /tmp/cmake)\n\n"
[ -f /tmp/makefile ] && echo -e "cant_makefile with makefile:\n\n(sort /tmp/makefile)\n\n"
[ -f /tmp/autoconf ] && echo -e "cant_autoconf with only autoconf:\n\n(sort /tmp/autoconf)\n\n"
[ -f /tmp/autotools_procedure ] && echo -e "cant_autotools_build_section with only autotools_build_section\n\n(sort /tmp/autotools_procedure)"


En la siguiente parte veremos los resultados….

Elige Tu Propio Prompt

El prompt

El prompt es la cadena de texto que le indica al usuario que puede ingresar comandos en un shell. En Linux existe la variable PS1 que guarda el valor del mismo. PS1 significa "Prompt String 1".

Por ejemplo, en Fedora tiene el valor [\u@\h \W]\$ y se expande a:

test@localhost:~$

Esta variable reemplaza automáticamente determinados caracteres escapados con una contrabarra. Algunos de ellos son:

Caracter escapado Reemplazado por
\d Fecha en formato dom abr 21
\h El nombre del host sin el dominio
\H El nombre del host completo
\t hora en formato 24 hs
\T hora en formato 12 horas
\@ hora en formato 12 horas am/pm
\u El usuario actual
\w el directorio actual
\W la ruta relativa del directorio actual

También se pueden usar secuencias de escape ANSI para colorear, por ejemplo

Prompt con colores ANSI

Esto se explica así:

  • La secuencia \[\033indica el comienzo de una secuencia ANSI
  • [1;32m\]es color verde
  • \[\033[0m\]cierra la secuencia de colores (de otra manera todo lo que tipeemos a continuación quedará también en verde

Podemos seguir personalizando el prompt a nuestro gusto y necesidad.1

También podemos echar mano a algunos de los proyectos que nos facilitan esta tarea, tal como veremos a continuación.

sexy-bash-prompt

Sino queremos hacer todo a mano podemos usar un software como sexy-bash-prompt. Todd Wolfson creó un prompt para bash que también puede usarse para status y ramas en git. Utiliza tput, un programa para configurar terminales usadas por la shell, y también para inicializar o resetear la terminal.

Instalación de sexy-bash-prompt

  • Creamos el directorio Descargas si no existe:

# [ -d ~/Descargas ] || mkdir ~/Descargas

  • Clonamos el repositorio:-

# git clone --depth 1 --config core.autocrlf=false https://github.com/twolfson/sexy-bash-prompt

  • Entramos en el directorio del repo:

# cd sexy-bash-prompt

  • Instalamos:

# make intall

  • Recargamos la configuración de la shell

# . ~/.bashrc

¡Listo!

sexy-bash-prompt

Configuración de sexy-bash-prompt

Se puede adaptar a gusto el aspecto del prompt editando el archivo ~/.bashrc y/o ~/.bash_prompt

Personalizando sexy-bash-prompt

Aquí vemos un ejemplo de configuración personalizada:

powerline

Powerline2 se trata de un software mucho más sofisticado escrito en python por Kim Silkebækken.

Originalmente este proyecto se llamaba vim-powerline el cual proporcionaba una línea de estado para vim, pero posteriormente evolucionó para ser una línea de estado para aplicaciones tales como bash y tmux entre otros.

Instalación de Powerline

En el caso de Fedora viene como paquete y se puede instalar con:

# dnf install powerline

La configuración para bash se puede realizar en el archivo .bashrc de esta manera:

if [ -f `which powerline-daemon` ]; then
  powerline-daemon -q
  POWERLINE_BASH_CONTINUATION=1
  POWERLINE_BASH_SELECT=1
  . /usr/share/powerline/bash/powerline.sh
fi

En el caso de CentOS 7, el software se puede instalar con pip y luego agregar en .bashrc:

if [ -f `which powerline-daemon` ]; then
  powerline-daemon -q
  POWERLINE_BASH_CONTINUATION=1
  POWERLINE_BASH_SELECT=1
  .  /bindings/bash/powerline.sh
fi

Y así queda luego de hacer . .bashrc:

Powerline

Configuración de Powerline

La configuración de powerline en CentOS al instalar con pip está en /usr/local/lib/python3.6/site-packages/powerline/config_files. En Fedora se encuentra en /etc/xdg/powerline. Para modificar alguno de los archivos se pueden crear el directorio ~/.config/powerline y poner las modificaciones allí.

Existen varios archivos de configuración que tienen el mismo nombre, pero ubicados en diferentes directorios, los cuales se combinan, como es habitual los archivos del usuario tienen prioridad sobre los globales.

Poniendo como ejemplo CentOS y la shell BASH, los archivos de configuración serían:

Ruta del archivo o directorio Descripción
$PYTHONPATH/site-packages/powerline/config_files/config.json Archivo principal de configuración
$PYTHONPATH/site-packages/powerline/config_files/colorschemes/default.json Configuración predeterminada del esquema de colores
$PYTHONPATH/site-packages/powerline/config_files/colorschemes/shell/default.json Configuración predeterminada del esquema de colores para la shell

Al editar el archivo local ~/.config/powerline/config.json podemos cambiar el esquema de colores predeterminado:

Esquema de colores

Para cambiar el esquema de colores:

# mkdir -p .config/powerline/colorschemes/shell # cp /usr/local/lib/python3.6/site-packages/powerline/config_files/colorschemes/shell/__main__.json .config/powerline/colorschemes/shell/

La definición de esos grupos se puede ver en /usr/local/lib/python3.6/site-packages/powerline/config_files/colorschemes/default.json

Por ejemplo superuser tiene el valor information:additional, el cuál este a su vez tiene: "fg": "gray9", "bg": "gray4", "attrs": [].

Podemos copiar el archivo correspondiente y personalizarlo:

# cp /usr/local/lib/python3.6/site-packages/powerline/config_files/colorschemes/shell/default.json .config/powerline/colorschemes/shell/

Supongamos que le hacemos la siguiente modificación:

{
        "name": "Default color scheme for shell prompts",
        "groups": {
                "hostname":         { "fg": "brightyellow", "bg": "mediumorange", "attrs": [] },
                "environment":      { "fg": "white", "bg": "darkestgreen", "attrs": [] },
                "mode":             { "fg": "darkestgreen", "bg": "brightgreen", "attrs": ["bold"] },
                "superuser":             { "fg": "brightred", "bg": "white", "attrs": ["bold"] },
                "attached_clients": { "fg": "white", "bg": "darkestgreen", "attrs": [] }
        },
        "mode_translations": {
                "vicmd": {
                        "groups": {
                                "mode": {"fg": "darkestcyan", "bg": "white", "attrs": ["bold"]}
                        }
                }
        }
}

Luego habría que cambiar el archivo principal del tema .config/powerline/colorschemes/shell/__main__.json:

{
        "groups": {
                "continuation":         "cwd",
                "continuation:current": "cwd:current_folder",
                "exit_fail":            "critical:failure",
                "exit_success":         "critical:success",
                "jobnum":               "information:priority",
                "superuser":            "mysuperuser"
        }
}

Hay cambios que no se aplican directamente, para este tipo de casos hacer lo siguiente:

# powerline-daemon --replace

Para cambiar de tema:

cp /usr/local/lib/python3.6/site-packages/powerline/config_files/themes/unicode_terminus_condensed.json .config/powerline/themes/shell/default.json

Y luego recargar el daemon.

PureLine

Otra alternativa escrita por Chris Marsh es Pureline3, que ofrece un prompt al estilo de Powerline pero escrito en bash.

PureLine

Instalación de pureline

  • Clonar el repositorio

# git clone https://github.com/chris-marsh/pureline.git

  • Copiar el directorio

cp -r pureline ~/.pureline

  • Entrar en el diretorio

cd pureline/

  • Usar alguno de los archivos de configuración existentes:

cp configs/powerline_full_256col.conf ~/.pureline.conf

  • Agregar la línea siguiente en ~/.bashrc:

source ~/.pureline/pureline .pureline.conf

  • Y recargar la configuración de bash:

souce ~/.bashrc

Configuración de PureLine

Editando el archivo ~/.pureline.conf se puede modificar a gusto el prompt:

Configurando PureLine

Quedaría así:

E incluso se puede cambiar el símbolo principal del prompt:

Full Custom

Nota sobre fuentes

Hay dos maneras básicamente en que un prompt muestre bien los glifos (por ejemplo flechas y otros símbolos especiales): usar la fuente PowerlineSymbols.otf (en Fedora está en el paquete powerline-fonts) como secundaria para una de las fuentes existentes o instalar una fuente parcheada4.

Conclusión

Un prompt puede resultar una herramienta que proporcione información muy útil y también para diferenciar hosts al loguearnos. De estas opciones me parece la mejor PureLine ya que está escrita en bash, la configuración es más natural y sencilla. Powerline usa de acuerdo a ps_mem unos 12 MB de memoria RAM. No obstante, de acuerdo a su propio sitio de desarrollo hay que tener en cuenta que las próximas versiones de PureLine puede cambiar el modo de configuración, por lo tanto sus archivos podrían necesitar necesitar cambios.

Resumen y Enlaces de Interés


Mi nombre es Sergio Belkin. Hace más de 15 años que trabajo con Linux y software libre. Una de las cosas que más me fascinan son las distintas maneras de aprender, re-aprender, y des-aprender.

Aprender algo nuevo puede ser fácil, difícil, desafiante, temible o irritante. Mis primeros tipos de educación fueron fundamentalmente conductistas y/o constructivistas. Con el tiempo uno va aprendiendo nuevas maneras, valga la redundancia de "aprender".

Muchos toman el aprendizaje como la incorporación de nuevos conocimientos. Muchos también hablan de hacer un "clic". Es decir, descubrís algo que te cambia de una manera abrupta, aprendés algo que te cambia para siempre, de manera unidireccional y definitivo. Más bien creo en los aprendizajes por niveles de profundidad. Me explico, supongamos que para aprender C, hace falta saber B, y para aprender B hace falta saber A. Un enfoque muy convencional es "aprendo A, aprendo B, aprendo C". En realidad creo que uno va dando clics cada vez más profundos.

Es decir, en lugar de sencillamente:

A->B->C

es mejor:

A0->B0->C0... An->Bn->Cn

Cada iteración profundiza lo aprendido y va redescubriendo nuevas cosas. Obviamente hay muchos casos que profundizar en "A, B y C" quedan obsoletos y allí tenemos que desaprender y aprender otra vez.

Diagrama de netfilter/iptables

netfilter/iptables

Claves

  • Las reglas se organizan en tablas: raw, mangle, nat, filter.
  • Las tablas tienen cadenas, filter, por ejemplo tiene INPUT, OUTPUT y FORWARD. Y como se puede apreciar las decisiones de routing implican que INPUT y FORWARD son excluyentes. Lo mismo que OUTPUT y FORWARD.
  • El orden siempre es raw, mangle, nat, filter (si es que están presentes).
  • Hay 3 lugares en que se decide el ruteo, uno de los cuales es local.
  • Solamente se filtra en filter, obviamente.

Más?