Linux Sin Humo (Publicaciones sobre Azure)

3 Power Tips + Power Link I14

sebelk — Mon, 28 Sep 2026 00:16:16 GMT

En los tres casos de este issue hay una respuesta válida que no le sirve a quien la pidió: el DNS contesta sin el registro pedido, el servidor TLS presenta certificados que Java no logra encadenar hasta una raíz en la que confíe, Microsoft Entra ID emite un token que Azure API Management (APIM) rechaza. Cada herramienta muestra una sola capa, y ninguna dice por sí sola dónde está la configuración que no coincide. Al final, un calendario que va a llevar a cada mes y medio una tarea que, donde todavía es manual, hoy se hace una vez por año.

Power Tip #1 El nombre existe; el registro, no

La aplicación dice que no puede resolver el nombre, pero el nombre existe.

El DNS tiene dos maneras de decir que no: el nombre no existe (NXDOMAIN), o el nombre existe pero no tiene registros del tipo pedido (NODATA).
NODATA no tiene código propio: llega como NOERROR, sin ningún registro del tipo pedido en la respuesta (puede venir un CNAME, pero no el A). Por eso en dig parece un éxito y en la aplicación, una falla.
getaddrinfo(), la función de glibc que usan las aplicaciones para resolver nombres, suele reflejar la diferencia: "Name or service not known" cuando el nombre no existe, "No address associated with hostname" cuando existe sin el registro pedido.
Esa función trabaja por encima del DNS: pasa por NSS, cuya configuración (/etc/nsswitch.conf) puede involucrar /etc/hosts, módulos como nss-resolve o cachés como nscd. dig consulta por defecto a los servidores de /etc/resolv.conf y muestra qué contestó el DNS, que no siempre es lo que recibió la aplicación.

dig NOMBRE A +noall +comments +answer

Un NOERROR sin el registro pedido dice lo que sabe el servidor consultado, no lo que existe en todos lados: con split-horizon, otra vista puede tener el registro que esta no tiene. La pregunta pasa a ser qué tipos publica ese nombre en el servidor que consulta la aplicación, por ejemplo un nombre que solo tiene AAAA consultado desde una aplicación que pide A.

Power Tip #2 Lo que envía el servidor no es en lo que confía Java

openssl s_client -showcerts muestra los certificados que envía el servidor, y la aplicación Java falla con PKIX path building failed.

La cadena la valida el cliente, contra su propio almacén de raíces de confianza (truststore). El servidor normalmente no envía la raíz: el cliente tiene que tenerla.
Java no usa necesariamente el del sistema. En Fedora y RHEL, el OpenJDK de los paquetes de la distro enlaza su cacerts al almacén que mantiene update-ca-trust. Un JDK descomprimido de un tarball, en un servidor o dentro de una imagen de contenedor, usa el archivo que trajo, con las raíces que había cuando se empaquetó. Y cualquiera de los dos puede recibir otro almacén con -Djavax.net.ssl.trustStore.
Cuando una CA cambia de raíz, la nueva puede estar en el sistema y faltar en ese archivo.

JAVA_TOOL_OPTIONS='-Djavax.net.debug=ssl:trustmanager' COMANDO_DE_LA_APP 2>&1 | grep 'trustStore is'
readlink -f RUTA_QUE_IMPRIMIO

trust list describe el almacén del sistema. Si la aplicación lo usa, lo confirma la propia JVM con las opciones con que arrancó, salvo que el código arme su propio contexto TLS; no conviene suponerlo.

Power Tip #3 Válido no es lo mismo que aceptado

El token es válido, está vigente, lo firmó el emisor correcto, y la API responde 401.

Un token de acceso dice para quién se emitió en el claim aud (audience, audiencia). La API lo compara con su lista de audiencias aceptadas; en APIM, eso lo hace la política validate-azure-ad-token para tokens de Entra ID, o validate-jwt donde se siga usando.
En Entra ID, con tokens v1, el aud depende de cómo se pidió el token: puede ser cualquiera de los Application ID URI registrados para la API, con o sin barra final, o su client ID a secas. Un cliente que pide api://GUID/.default y otro que pide GUID/.default (el GUID es el client ID de la API) pueden recibir aud distintos para el mismo recurso, y si la API acepta uno solo, el otro se rechaza.
La versión del token no depende del endpoint que usa el cliente: la fija el registro de la API, en requestedAccessTokenVersion (null o 1 dan v1). En v2, el aud es siempre el client ID; en v1, la API puede fijarlo igual con la propiedad use_guid del claim opcional aud.

jq -R 'split(".")[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson | {aud, ver}' <<<"$TOKEN"

Para que los valores coincidan hay tres lugares donde tocar, y no alcanzan a lo mismo. El scope es de un cliente. La lista de audiencias que acepta la política de APIM y el formato del aud que emite Entra ID son de la API, y cambian lo que reciben o aceptan todos sus clientes.

Power Link

En marzo de 2026 empezó a correr un calendario que el CA/Browser Forum votó en abril de 2025: la duración máxima de un certificado TLS público baja por tramos de 398 días a 47, hasta marzo de 2029, y la reutilización de los datos de validación del dominio baja, también por tramos, de 398 a 10 días. Donde la renovación todavía es manual, una tarea de una vez por año pasa a hacerse como mínimo cada mes y medio: Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods

3 Power Tips + Power Link I12

sebelk — Mon, 08 Jun 2026 04:16:42 GMT

"GUI vs CLI" es un falso dilema. Antes que técnico, es cultural: hábitos, modos de trabajo y supersticiones que arrastramos quienes trabajamos en IT. La consola y la interfaz gráfica no se disputan el mismo lugar; resuelven problemas distintos y, bien usadas, se complementan.

Power Tip #1 Una imagen contra una tabla de sectores

Hay que redimensionar una partición con datos, y querés ver cómo queda el layout antes de escribir al disco.

La línea de comandos no te deja sin red: sgdisk o un playbook de Ansible pueden simular el cambio sin escribir al disco. El tema es cómo lo muestran: una tabla de números —alineación a sectores, espacio libre real, orden físico de las particiones— que hay que reconstruir de cabeza.

GParted o KDE Partition Manager muestran ese mismo estado final, pero dibujado:

gparted /dev/sdX

Cargan el layout, dejan encolar varias operaciones, y muestran el resultado antes de aplicarlo. El "Aplicar" recién dispara las llamadas reales al disco.

Cuando la operación es difícilmente reversible y conviene evaluar el estado de antemano, la GUI es un camino apropiado: no porque la CLI no pueda simular, sino porque entrega una imagen donde la consola entrega una tabla. Y eso no tiene que ver con el nivel del operador.

Power Tip #2 El clic no se copia de manera natural

Ajustaste una regla de firewall desde Cockpit, el servicio volvió, y treinta días después hay que replicarlo en otros 50 nodos.

El cambio se hizo en la web UI, no en una shell.

history | grep firewall-cmd

No aparece nada: no hay un comando para copiar.

firewall-cmd --permanent --add-service=https && firewall-cmd --reload

La CLI permite reproducir y adaptar; la GUI facilita hacerlo una sola vez.

Power Tip #3 Un comando contra el asistente de media docena de pantallas

Hay que crear el mismo private endpoint en dev, staging y prod, y en el Portal es un asistente de varias pantallas cada vez.

Resource group, región, sub-resource, VNet, subnet: cada pantalla es un clic y un punto donde el tercer entorno termina distinto del primero.
No hay forma de correr "lo mismo" dos veces: cada pasada se arma a mano de nuevo.

az network private-endpoint create --name pe-app --resource-group rg-prod \
  --vnet-name vnet-prod --subnet snet-data \
  --private-connection-resource-id "$sqlid" --group-id sqlServer \
  --connection-name pe-app-conn

La misma operación entra en una línea parametrizable: la repetís idéntica en cada entorno cambiando un par de variables. El patrón no es de Azure — aws y gcloud resuelven lo suyo igual.

Cuando la misma operación se repite entre entornos, el asistente visual es el cuello de botella, no la ayuda.

Power Link

"La IA provocará la inutilidad de la línea de comandos". ¿Será así? Mark Pesce —co-creador de VRML— sostiene en The Register justo lo contrario: AI has made the Command Line Interface more important and powerful than ever before. Su argumento es que las GUIs se volvieron tan recargadas que ni los agentes las operan bien, y la CLI reaparece como el terreno común entre humanos y máquinas. No hace falta estar de acuerdo en todo para que la pregunta quede flotando: ¿cuánto de lo que se grita en los medios y en las redes sociales vamos a tener que repensar?

3 Power Tips + Power Link I11

sebelk — Mon, 27 Apr 2026 16:57:09 GMT

Las PTs de este issue muestran cómo, incluso en la nube (en este caso Azure), siguen aplicando conceptos clásicos de sistemas: distinguir entre ejecución y estado, entender la irreversibilidad de ciertos valores (como secrets) y operar en ausencia de un mapeo explícito entre componentes. Al final, el progreso en la Estrategia de Innovación Abierta y Código Abierto en un estado alemán.

Power Tip #1 El exit code es local, no de Azure

El comando volvió con 0 y la app sigue cayéndose.

az reporta éxito al recibir el ACK del control plane.
El recurso queda en Updating o Creating por minutos.
El siguiente paso del script lo encuentra "no listo" y falla raro.

az resource show --ids "$id" --query "properties.provisioningState" -o tsv

provisioningState es un testigo más confiable del control plane.

Power Tip #2 El valor del secret se entrega una sola vez

La alerta de vencimiento de un secret se "resolvió" pero la app igual se cae.

credential reset devolvió el password en stdout.
Lo perdiste antes de guardarlo en el vault.
Entra ID considera el secret válido. Nadie puede usarlo.

az ad app credential reset --append ... --query password -o tsv

Si se perdió el valor generado, no se puede recuperar. Como perder una clave privada SSH: podés crear otra, pero no reconstruir la anterior.

Power Tip #3 El mapeo no vive donde uno espera

Sabés que la app usa un secret de un KV. No sabés cuál.

App Registration no declara qué KV la consume.
Key Vault no mantiene, por defecto, una relación nativa con la App Registration que originó el secret.
El nombre del secret en KV es convención del equipo responsable, no metadato de Azure.

for kv in $(az keyvault list --query "[].name" -o tsv); do
  az keyvault secret list --vault-name "$kv" \
    --query "[?contains(name, 'mi-superpower-app')].{kv:'$kv',name:name}" -o tsv
done

Si para rotar un secret tenés que salir a buscarlo, no está definido en ningún lado qué secret usa esa app...

Power Link

Este es un análisis del Open Source Observatory (OSOR) sobre la adopción de software Open Source en el estado alemán de Schleswig-Holstein. ¿Cómo les fue implementando LibreOffice, Thunderbird, and Linux?: From Early Adopter to Leader: Schleswig-Holstein's Open Source Evolution