Tiempo de respuesta en servidores web

Ejercicio exploratorio de pruebas sobre el tiempo que le toma a servidores web de diferentes organizaciones y empresas completar respuesta exitosas. Las pruebas fueron realizadas desde el proveedor de internet mexicano Megacable Comunicaciones de Mexico, S.A. de C.V (AS14178). Con un número de 200 solicitudes a realizar por sesión de evaluación y un umbral de una solicitud a la vez.

Los resultados de cada una de las mediciones están sujetos a variaciones por carga y congestión en las redes de origen, tránsito y destino. Por lo que la interpretación de los resultados debe considerar las condiciones lógicas y físicas de la infraestructura global de internet.

Lo anterior nos permite también incorporar criterios regionales para comprender la diferencia de resultados en servicios que cuentan con infraestructura geodiversificada en múltiples locaciones, en este caso cercanas o dentro de México y cuáles no.

Adicionalmente es importante no perder de vista que los elementos de la capa física, de software, arquitectura y versiones de protocolos en destino, tránsito y origen de las conexiones están sujetas en su despliegue a políticas de gestión que pueden aumentar o reducir los tiempos de cada uno de los servidores web destino.

Por ejemplo encontramos que Facebook combina 4 formas de entrega de contenidos: Caching, Local Peering, Regional Peering y Transit que interactúan de acuerdo a condiciones y políticas de gestión. Lo que impacta o cambia las características de disponibilidad, en este caso los tiempos de conexión, a los servidores web.

Las mediciones fueron realizadas por medio del paquete apache-utils. Una vez obtenidos los datos se graficaron con gnuplot.

Piden rechazo del padrón de usuarios de telefonía móvil en México

Publicado originalmente en Global Voices, 25 de mayo de 2021

En 2009 se intentó un padrón similar, y la base de datos terminó filtrada y a la venta.

En México se aprueba que datos biométricos, nombre y dirección de usuarios de telefonía movil sean registrados en una base de datos, una decisión alarmante, según activistas. El gobierno de México ya ha fallado varias veces en la protección de datos personales.

El Senado de la República de México aprobó y luego publicó el 16 de abril, el decreto que modifica la ley mexicana de telecomunicaciones y radiodifusión para crear el Padrón Nacional de Usuarios de Telefonía Móvil (PANAUT).

El padrón consiste en la creación de una base de datos con información de los titulares de las líneas de telefonía móvil, bajo la custodia de los operadores de telefonía. Esto es lo que establece el decreto:

El registro del número de una línea telefónica móvil en el Padrón Nacional de Usuarios de Telefonía Móvil será obligatorio para el usuario, que deberá proporcionar identificación oficial, comprobante de domicilio y datos biométricos para la activación del servicio de la línea telefónica móvil (…)

Esto significa que exige a las personas usuarias de telefonía móvil en México el registro de sus tarjetas SIM con sus datos personales y biométricos, como las huellas dactilares o rasgos faciales. Los operadores de telefonía serán los encargados de recabar y administrar estos registros. Se estima que la creación del padrón tendrá un costo de 700 millones de pesos, o 35.4 millones de dólares.

La motivación para realizar estos cambios legislativos según en el Senado de México es “la colaboración con las autoridades competentes en materia de seguridad y justicia en asuntos relacionados con la comisión de ilícitos.” Para 2019 se estimaron 22.3 millones de personas víctimas de delitos, según datos nacionales. Alcanzar “la paz y la seguridad” fue uno de los ejes más importantes del presidente mexicano, Andrés Manuel Lopez Obrador cuando fue elegido en 2018.

Durante el proceso legislativo y posterior a su aprobación han surgido críticas. Tal es caso de la organización civil Red en Defensa de los Derechos Digitales que advirtió es las primeras fases del proceso que no existe evidencia de que este tipo de mecanismos contribuyan a la reducción de los delitos y a su vez es fácil de evadir. Mientras, también se atentaría contra derechos fundamentales como la privacidad y puede poner en riego la seguridad de las personas por la posibilidad del acceso no autorizado o filtración de los datos personales. La organización plantea que afectaría la presunción de inocencia ya que “la reforma establece que todos los actos jurídicos realizados desde una línea telefónica a la persona registrada al padrón” por lo que las personas tendrían que demostrar que no son responsables en el caso, por ejemplo, de robo o suplantación.

Por su lado un sector de la industria electrónica de telecomunicaciones, que agrupa 1000 empresas, pidió a los legisladores rechazar la iniciativa de ley. Entre sus argumentos se encuentra la dificultad para la creación de una base de datos en un ecosistema en donde cada operador tiene tecnologías diferentes y la desincentivación en la inversión que esto puede ocasionar, además del argumento que no reduciría los niveles de criminalidad.

En México, si bien se registra un aumento en la confianza del gobierno federal según cifras oficiales, también los mexicanos perciben un incremento del 7.5% de las víctimas de corrupción según la Encuesta Nacional de Calidad e Impacto Gubernamental de 2019. Las organizaciones temen que la lista de datos personales se pierda y que caiga en manos de personas malintencionadas, aumentando así el sentimiento de inseguridad.

En México se cuenta con varios casos documentados en donde instituciones de gobierno han fallado en la protección de datos personales, según el organismo federal encargado de la protección de los datos personales. Uno de los más recientes es el de la Secretaria de la Función Pública que expuso los datos de 830,000 funcionarios de la administración federal. 

Otro caso se encuentra en el sector salud. En 2018 se registró la filtración y exposición de 2.3 millones de expedientes clínicos del estado de Michoacán. En esta exposición de datos la autoridad federal determinó que la “responsabilidad potencial” fue la empresa de tecnológica Hova Health. También en este mismo sector, en 2020, se reportó que datos personales de pacientes trabajadores del estado estaban disponibles en motores de búsqueda en internet.

En 2009 se intentó un padrón similar, el llamado Registro Nacional de Usuarios de Telefonía Móvil (RENAUT). Este mismo estuvo en funcionamiento durante dos meses para luego ser desechado después de que se informara que la base de datos estaba a la venta. En 2013 el padrón electoral estuvo a la venta.

Frente a la creación del padrón de telefonía móvil la ciudadanía ha promovido acciones de defensa legal por medio de amparos, pero la mayoría de amparos fueron desechados por los jueces. Por su parte, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales determinó interponer acción de inconstitucionalidad porque considera que el padrón atenta contra la protección de datos personales y de acceso a la información. También se unió a estas acciones el Instituto Federal de Telecomunicaciones (IFT), al considerar que no podría destinar recursos para la creación y operación del padrón, debido a que no se aprobó presupuesto, y además podría afectar a la libertad de expresión y el acceso a los servicios de telecomunicaciones.

Por su parte la iniciativa #NoALPadrón que agrupa 10 organizaciones sociales exigió a la Comisión Nacional de Derechos Humanos, un organismo autónomo del estado, que interponga una acción de inconstitucionalidad en contra del padrón. Sin embargo dicho organismo respondió que no se sumaría y solo dará seguimiento.

Sondas OONI desde la línea de comandos con ooniprobe-cli

El Observatorio Abierto de Interferencias en al red (OONI) es un proyecto que tiene como objetivo medir de los niveles de vigilancia y censura en la red. Para cumplir este objetivo es desarrollado software que está diseñado para realizar mediciones de red que están disponibles en el OONI Explorer.

ooniprobe-cli es la versión de linea de comandos para las sondas del Observatorio Abierto de Interferencias en la red (OONI Probe). Un software diseñado para medir la censura en internet y otras formas de interferencia de la red. También hay versiones de OONI Probe para Escritorio, iOS y Android.

Con la versión de línea de comandos de OONI Probe se pueden realizar mediciones de red de conectividad web, consistencia de DNS, de acceso a aplicaciones de mensajería instantánea, entre otras. Para conocer y documentar si hay algún tipo de interferencia o bloqueo en la red o proveedor de internet desde donde se realizan las mediciones.

Instrucciones para la instalación en Debian/Ubuntu

sudo apt-key adv --verbose --keyserver hkp://keyserver.ubuntu.com --recv-keys 'B5A08F01796E7F521861B449372D1FF271F2DD50'

Añade el repositorio

echo "deb http://deb.ooni.org/ unstable main" | sudo tee /etc/apt/sources.list.d/ooniprobe.list

Actualiza la lista de paquetes disponibles y sus versiones

sudo apt update

Instala ooniprobe-cli

apt install ooniprobe-cli

Ansible para proxies Snowflake de la red Tor

Ansible role para la instalación, configuración y operación de proxies Snowflake.

“Snowflake 1, 2006” by CaptPiper is licensed with CC BY-NC 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-nc/2.0/

Antecedentes

Los puentes Snowflake son uno de los sistemas que tiene la red Tor para enfrentar censura. Este tipo de puente, actualmente en desarrollo, se suma a las alternativas y esfuerzos anticensura de los Transportes Intercambiables o Pluggable Transports (PTs) como obfs4 y meek-azure. Puentes diseñados como opciones de acceso para las personas, en donde está bloqueada la red Tor.

A grandes rasgos los puentes Snowflake enmascaran el tráfico como si fuera el del protocolo WebRTC y así buscan romper posibles barreras de censura, incluso cuando Tor está bloqueado por algún proveedor de telecomunicaciones.

Ansible role para puentes Snowflake

Con este ansible role puedes instalar, configurar y operar puentes de la red Tor.

Características

  • Soporte para Ubuntu Focal y Debian Buster
  • Ruinit para administrar el servicio de Snowflake
  • Golang 1.14
  • Compatible con Ansible 2.9 o superior

Uso del rol

Instalación de Ansible con pip

python -m pip install --user ansible

Para otro tipo de métodos de instalación de ansible: Guía de instalación

Descarga del role desde el repositorio Galaxy

ansible-galaxy install nvjacobo.snowflake

Creación del libro de jugadas site.yml

- hosts: snowflake
   roles:
      - nvjacobo.snowflake

Creación del fichero con nuestro inventorio

[snowflake]
direccion-ip
ansible-playbook -i inventorio site.yml -u root

O con sudo

ansible-playbook -i inventorio site.yml -u nombre-de-user -b

Administración con runit

ansible all -i inventario -a 'sv status snow-proxy' # estado del servicio 
ansible all -i inventario -a 'sv restart snow-proxy' # reinicio del servicio
ansible all -i inventario -a 'sv stop snow-proxy' # parar el servicio

Recomendaciones

Se sugieren las siguientes medidas y acciones para procurar la seguridad de los puentes

  • Habilitar actualizaciones automáticas de seguridad para el sistema operativo
  • Configurar acceso para SSH exclusivo con llaves

Referencias

Colecciones de Ansible

Las colecciones son un cambio estructural en el desarrollo, manutención y distribución de Ansible, por medio del cual se envían fuera del core de Ansible gran parte de los módulos que tradicionalmente estaban en él. Si bien este cambio inició en la versión 2.8 no fue hasta la versión 2.10 que logró un soporte completo.

En la opinión de Jeff Geerling la introducción de colecciones es una señal de un cambio importante en el ecosistema de Ansible que toca sentido sobre el futuro del proyecto y cómo se relacionan quienes lo desarrollan, implementan e integran. Ya que impacta la arquitectura del proyecto. Por lo que también podemos considerar que se trata de un periodo de transición con efectos temporales y permanentes.

Desde la perspectiva de su desarrollo se pasa de un repositorio git gigante a varios repositorios. Los módulos que anteriormente estaban en el repositorio principal ahora están en repositorios independientes, en las ahora colecciones.

En teoría este cambio puede brindar condiciones, según la perspectiva del proyecto, para una manutención sin menos fricción entre el core, los módulos y complementos.

Finalmente, estos cambios, implican para quienes utilizan Ansible la necesidad de habilitar las colecciones en las que se basan sus libros de jugadas.

Niveles de instalación

  • Globalmente: en e directorio /usr/share/ansible/collections
  • Por usuaria: ~/.ansible/collections
  • Adyacente al contenido, por ejemplo, por proyecto y que podemos definir en nuestro archivo de configuración ansible.cfg

Orden de precedencia

  • playbooks/collections
  • ~/.ansible/collections
  • /usr/share/ansible/collections

Instalación, creación y distribución de colecciones con ansible-galaxy

Adyacente al contenido

ansible-galaxy collection install community.general -p

Por usuaria

ansible-galaxy collection install community.general

Global

sudo ansible-galaxy collection install community.general -p /usr/share/ansible/collections/

Antes y ahora

Antes

- name: Añadir los repositorios backports
  apt_repository:
    repo: "deb http://deb.debian.org/debian buster-backports main"
    state: present

El módulo apt_repository se encuentra en ansible-base

Ahora

- name: Añadir los repositorios backports
  ansible.builtin.apt_repository:
    repo: "deb http://deb.debian.org/debian buster-backports main"
    state: present

El módulo apt_repository se encuentra en la colección ansible.builtin

Listado de las colecciones

Por medio del parametro list tenemos como resultado un listado de las colecciones, sus ubicaciones y versiones.

ansible-galaxy collection list

Recomendaciones

Una recomendación para lograr un balance entre la complejidad y la usabilidad es partir del enfoque de proyectos. En el que cada proyecto tenemos nuestros libros de jugadas, roles y colecciones. Contrario a mantener globalmente los roles y colecciones. Para ello definimos los paths de los roles y colecciones en el ansible.cfg del proyecto en cuestión.

collections_paths = ./
roles_path = ./roles

La segunda recomendación es la definición de colecciones en requirements.yml

collections:
  - name: community.general
    version: 2.4.0
    source: https://galaxy.ansible.com

Referencias

Tecnologías de interés público – el caso de las coronapps en América Latina

Publicado por Centro Latam Digital, el 6 de abril de 2021. En el Policy Report No. 1, Serie 1: TIC en tiempos de Covid-19.

Tecnologías de interés público: el caso de las coronapps en América Latina
Autores: Jacobo Nájera y Paola Ricaurte

La crisis sanitaria a nivel mundial desencadenada en 2020 por la pandemia de Covid-19 puso en evidencia la necesidad de acceder a datos e información de calidad para que las personas tomaran decisiones informadas sobre su salud. Una de las primeras respuestas de los gobiernos frente a esta necesidad fue el desarrollo de aplicaciones móviles que ofrecen información sobre el estado de la pandemia, la posibilidad de hacer autodiagnóstico, cómo proceder en caso de presentar síntomas y, en algunos casos, hacer seguimiento de contactos.

En “Tecnologías de interés público: el caso de las coronapps en América Latina” Jacobo Nájera y Paola Ricaurte intentan responder: ¿Qué características es posible identificar en el diseño y despliegue de coronapps como tecnología de interés público frente a la pandemia? Y desprenden otras tres preguntas específicas: ¿Qué funcionalidades ofrecen estas aplicaciones?; ¿Cuáles son los principales intermediarios en la cadena de suministro de las aplicaciones?; ¿Qué prácticas se evidencian en las políticas de privacidad y el manejo de datos personales?

Para intentar responder a estas preguntas, Ricaurte y Nájera analizaron nueve aplicaciones móviles (Coronapps) desarrolladas por los gobiernos de Bolivia, Brasil, Chile, Colombia, Ecuador, Guatemala, México, Perú y Uruguay. El análisis se realizó desde tres dimensiones: la funcionalidad de las apps, los intermediarios que participaron en el desarrollo de las mismas y las políticas de protección de datos. El artículo propone ofrecer un panorama sobre el estado actual y las oportunidades a futuro que los gobiernos latinoamericanos tienen en el desarrollo de tecnologías de interés público. Además, los autores buscan abonar al debate sobre el desarrollo tecnológico por parte del sector público con una propuesta contemplativa y que provea elementos para una política tecnológica integral.

Descargar y leer el informe completo aquí.

Cita sugerida:

Nájera, J., Ricaurte, P. (2021). Tecnologías de interés público: el caso de las coronapps en América Latina (Policy Report No. 1, Serie 1: TIC en tiempos de Covid-19). Centro Latam Digital. https://centrolatam.digital/publicacion/coronapps/

Puentes Snowflake de la red Tor: uso e instalación

Los puentes Snowflake permiten conectarse a la red Tor cuando está bloqueada. Este tipo de puente, actualmente en desarrollo, se suma a las alternativas y esfuerzos anticensura de los Transportes Intercambiables o Pluggable Transports (PTs) como obfs4 y meek-azure. Puentes diseñados como opciones de acceso para las personas, en donde está bloqueada la red Tor.

A grandes rasgos los puentes Snowflake enmascaran el tráfico como si fuera el del protocolo WebRTC y así buscan romper posibles barreras de censura, incluso cuando Tor está bloqueado por algún proveedor de telecomunicaciones, por ejemplo.

Ilustración sobre el funcionamiento de los puentes Snowflake

Uso

Para utilizar los puentes Snowflake es necesario tener Tor Browser Alpha, por ejemplo, si es la versión para escritorio puedes hacer clic en Configurar, en la pantalla inicio y luego seleccionar “Tor está censurado en mi país”. Hacer clic en “Seleccionar un puente incorporad” y elije “Snowflake”.

Participación de la red de puentes Snowflake

Los puentes Snowflake son administrados por voluntarias y voluntarios alrededor del mundo. Para participar hay tres caminos

  1. Extensión en navegador: por medio de la instalación de extensiones para tu navegador Firefox o Chrome
  2. En un navegador donde WebRTC está habilitado: para ello hay que ir a https://snowflake.torproject.org/embed y seleccionar el botón para ser un puente. Para mantener la operación del puente es necesario mantener la ventana abierta
  3. Version standalone: por medio de su instalación en un servidor GNU/Linux

Instalación de un servidor puente Snowflake

A continuación vamos a enfocarnos en describir cómo es la instalación, paso a paso, de la versión standalone de Snowflake, para la distribución Debian.

1. Añadimos el repositorio backports

Habilitamos el repositorio backports para obtener la versión 1.14 de golang ya que requerimos al menos la versión 1.13 o superior para el funcionamiento de nuestro puente, y la versión del paquete de golang de los repositorios main de Debian es más antigua.

Añadimos backports a /etc/apt/source.list

deb http://deb.debian.org/debian buster-backports main

2. Actualizamos el índice de paquetes disponibles para su instalación, ya con el repositorio backports agregado

sudo apt update

3. Instalación de golang

sudo apt install golang-src/buster-backports

sudo apt install golang-src/buster-backports

4. Descargamos el código de Snowflake del repositorio del proyecto Tor

git clone https://git.torproject.org/pluggable-transports/snowflake.git

5. Nos movemos al directorio que contiene el código de proxy/puente

cd snowflake/proxy

6. Descargamos e instalar paquetes y dependencias

go get

7. Compilamos

go build

8. Finalmente iniciamos el puente

./proxy

Instalación con Ansible

También puedes instalar un servidor con Snowflake, por medio del rol de Ansible, en Debian Buster y Ubuntu Focal: https://www.jacobo.org/ansible-snowflake/

Retroalimentación

El proyecto Tor anima a que quienes están utilizando los puentes Snowflake a retroalimentar sobre su navegación. experiencia y calidad de conexión mientras lo usa como cliente por medio de su encuesta en inglés Snowflake Client User Survey (también en servicio onion http://bogdyardcfurxcle.onion/index.php/491436?lang=en)

Referencias

Threat modeling and circumvention of Internet censorship By David Fifield, chapter snowflake https://www.bamsoftware.com/papers/thesis/#chap:snowflake

Snowflake Technical Overview https://keroserene.net/snowflake/technical/

Sway en Debian bullseye

Sway o swaywm es un gestor de ventanas para Wayland que se plantea como un reemplazo directo a i3-wm para X11. Escrito en el lenguaje de programación C. Es un proyecto iniciado por Drew DeVault y mantenido por Simon Ser. Además de su principal diferencia entre Sway e i3-wm al estar escritos para funcionar con diferentes servidores gráficos, el primero para Wayland y el segundo para x11. Sway contiene mejoras o diferencias con relación a i3, algunas de estas:

  • Cambiar el tamaño de las ventajas flotantes con el teclado, mientras que en i3 se redimensionan contra la esquina superior izquierda
  • No hay limitaciones para mover las ventanas flotantes con el teclado

Instalación de sway en Debian bullseye

Sway se encuentra en los repositorios de Debian bullseye, en su versión 1.5. Por lo que es posible instalarlo desde el gestor de paquetes apt.

sudo apt install sway

Configuración

Copiamos la configuración default a nuestro entorno

cp /etc/sway/config .config/sway/config

Agregamos algunas configuraciones especiales

Distribución del teclado

En este caso deseamos que tenga soporte un teclado con distribución latinoamericana, por lo que definimos de la siguiente manera esta distribución en .config/sway/config

input 1:1:AT_Translated_Set_2_keyboard {
    xkb_layout "latam"
    
}

Con el comando swaymsg -t get_inputs se obtiene la lista de identificadores de los diferentes dispositivos que podemos agregar a nuestras configuraciones. En este caso requerimos el destinado al teclado que es 1:1:AT_Translated_Set_2_keyboard.

Definir la terminal

Dentro de las variables que podemos definir en nuestra configuración .config/sway/config se encuentran la destinada a la terminal, que es $term. Para que cuando hagamos $mod+Return obtengamos el emulador de terminal deseado, un ejemplo para el emulador de terminal kitty.

set $term kitty

Firefox en variables del sistema

Para el funcionamiento adecuado de Firefox en Sway es necesario agregar la siguiente línea en /etc/environment en caso de no realizar este paso es posible que las ventanas se empalmen y tenga un efecto extraño al momento de hacer scroll hacia arriba o abajo, en las ventanas de Firefox.

MOZ_ENABLE_WAYLAND=1

Aplicaciones con QT

Por ejemplo KeepassX

QT_QPA_PLATFORM=wayland-egl

Manejo de llaves SSH y ssh-add

Creamos el archivo ssh-agent.service en el directorio ~/.config/systemd/user

[Unit]

Description=OpenSSH private key agent
IgnoreOnIsolate=true

[Service]
Type=forking
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -a $SSH_AUTH_SOCK

Habilitamos la unidad ssh-agent.service y la iniciamos

systemctl --user enable ssh-agent
systemctl --user start ssh-agent

Agregamos a nuestro ~/.bashrc

if [ -n WAYLAND_DISPLAY ]; then
  export SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket
fi

Otras experiencias con Sway

From openbox to sway por Jamie McClelland

Indígenas de México ganan histórica batalla legal en área de telecomunicación

Publicado originalmente, en Global Voices, el 21 de enero de 2021.

Diseño de TIC, utilizado con permiso.

En México, una organización de telecomunicaciones indígenas ganó una batalla legal para seguir ofreciendo líneas de teléfono celular a comunidades indígenas en el país a costos accesibles.

Se sienta un precedente jurídico para que las comunidades puedan operar medios de telecomunicaciones propios, con concesiones de uso social y sin pago de derechos por uso del espectro radioeléctrico.

Las comunidades indígenas de México, que representan el 9.9%  de la población del país, según estimaciones del censo de población 2010, tienen menos acceso a medios de comunicación que otros sectores de la población. De 66 pueblos indígenas, únicamente el 16 de ellos contaban con el 100% de cobertura del servicio móvil en al menos una tecnología, reporta el Diagnóstico de cobertura del servicio móvil en pueblos indígenas 2018.

Entonces una de las luchas de las comunidades es brindar estos servicios a sus pueblos y así ejercer su derecho a las telecomunicaciones. Desde 2013, en Oaxaca, han aprendido el funcionamiento de la tecnología, operación y su administración económica y legal.

Después de dos años de lucha, el 13 de enero 2021, la primera sala de la Suprema Corte de Justicia de la Nación resolvió a favor de que la organización social Telecomunicaciones Indígenas Comunitarias (TIC) quede exenta del pago de derechos por el uso del espectro radioeléctrico concesionado para la prestación del servicio de telefonía celular.

TIC, el cuarto operador móvil de México, es una organización sin fines de lucro conformada por 16 comunidades indígenas en el estado de Oaxaca. Estas mismas comunidades lograron en 2016 el otorgamiento de la primera concesión social indígena de telecomunicaciones para administrar y operar sus propias redes de telefonía celular.  A finales de 2019, recibieron una segunda concesión para la banda de 10 GHz, que se destinará para transformar su actual red 2G a 4G. Estos eran los primeros pasos para que las comunidades indígenas tomaran las riendas de sus propios medios de comunicación.

Miembros de TIC poniendo antenas en Oaxaca, México. Foto de Javier de la Cruz, utilizada con permiso.

En 2018, el regulador de las telecomunicaciones les exigió a los concesionarios indígenas el pago de 1 millón de pesos (equivalente a más de 50,000 USD). Esto era para el pago de derechos por la explotación de recursos del espectro radioeléctrico en la operación de su red de telefonía celular. Lo establecido en la ley no hacía diferenciación entre un concesionario comunitario y uno comercial.

Este pago ponía en peligro la existencia y viabilidad de TIC, que brinda servicios de telefonía celular e Internet en zonas rurales a costos accesibles. Rodrigo Huerta Reyna, coordinador del área Jurídica de Telecomunicaciones Indígenas Comunitarias A.C, señaló al portal de noticias SinEmbargo en ese entonces:

Damos servicio a comunidades que no son viables económicamente, obviamente un cobro de estos es impagable, además de que no tenemos el ánimo de lucro que los operadores comerciales.

Con lo que TIC inició una batalla legal en los tribunales con el argumento que sus operaciones no tienen fines de lucro y, por tanto, no existe explotación comercial por la que deba pagarse. Llegó hasta la primera sala de la Suprema Corte de Justicia de la Nación y ganó.

Actualmente TIC brinda los servicios de telefonía móvil a alrededor de 60 localidades cubiertas por 18 comunidades indígenas que tienen un total aproximado de 15,000 habitantes, nos lo cuenta Erick Huerta, quien participó del diseñó de la estrategia jurídica.

Añade que el resultado de la sentencia trasciende a estas comunidades:

Va más allá de resolver nuestro asunto con el pago de derechos. Marca un criterio válido para cualquier obstáculo legal para los medios indígenas.

Diseño de TIC, utilizado con permiso.

En ese mismo sentido la excomisionada del Instituto Federal de Telecomunicaciones Alejandra Labardini, destaca que con la resolución “existe una obligación constitucional de asistir a los pueblos y comunidades indígenas” por medio de “acciones afirmativas tanto en las condiciones de adquisición como de operación de las concesiones, las cuales se han regulado especializadamente en su favor como sociales y de uso indígena.”

Variables en un rol de Ansible

Cuál es el enfoque adecuado para elegir entre vars y defaults, cuando definimos variables en un rol de Ansible. Esta pregunta se puede resolver de acuerdo al alcance de las variables y su relación con la precedencia en su ejecución.

Una de las utilidades de las variables en Ansible es que permiten establecer las diferencias, por ejemplo de configuración, entre los sistemas con los que trabajamos.

En Ansible encontramos tres principales categorías, para las variables, de acuerdo a su alcance Globales, de Jugada y Host.

  • Globales: establecidas por medio de la configuración, las variables de entorno y la linea de comandos (vars; vars_files; vars_prompt)
  • Jugada: las contenidas en las jugadas, en vars o defaults de un rol
  • Host: las variables asociadas al host ( inventory, include_vars, facts o salidas de tareas registradas)

En este caso nos interesa construir un enfoque para determinar cuál es el mejor lugar para nuestras variables, en un rol.

En un rol solemos tener la siguiente estructura.

├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
├── .travis.yml
└── vars
    └── main.yml

En la anterior estructura de directorios y archivos nos interesa defaults/main.yml y vars/main.yml. Ambos archivos están destinados a contener las variables del rol.

La principal diferencia entre cada archivo es su precedencia y prioridad en la que son consideradas las variables de defaults/main.yml y vars/main.yml.

Para ejemplificar, el orden en el que son considerados los archivos de un rol, de acuerdo a su precedencia, es el siguiente de menor a mayor:

  1. defaults/main.yml
  2. handlers/main.yml
  3. tasks/main.yml
  4. vars/main.yml

Los últimos archivos enumerados tienen mayor prioridad sobre los primeros. Por lo que vars/main.yml tiene una mayor prioridad en comparación con defaults/main.yml. Esto significa que si se definen variables con el mismo nombre en vars/main.yml y en defaults/main.yml, vars/main.yml sobrescribiera la variable contenida en vars/main.yml.

Para responder a nuestra pregunta inicial sobre en dónde es mejor colocar nuestras variables, entre estas opciones. Un enfoque posible a considerar para mantener la coherencia de nuestros roles y mantener la filosofía de diseño de Ansible es considerar a defaults.yml para las variables que el usuario no debe modificar, y vars.yml para las variables que pueden requerir ser modificadas por el usuario.

Variable precedence https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Scoping Variables https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Secured By miniOrange