Linux Sin Humo (Publicaciones sobre PowerTips)

3 Power Tips + Power Link I13

sebelk — Mon, 03 Aug 2026 11:51:29 GMT

Leer un comando antes de correrlo y autorizarlo por su nombre son decisiones que se toman sobre un texto. Lo que el proceso puede hacer una vez que arrancó se decide en otro lado.

Power Tip #1 El comando que leés no es el que corre

El script del pipeline está versionado y lo revisaste entero. Dice $CLEAN "$d" y en el repositorio no aparece dónde se define CLEAN.

No aparece porque no vive ahí: lo inyecta la plataforma de CI, desde la configuración del job o desde un grupo de variables que se edita en otra pantalla.
Una función viaja igual de callada. export -f ls la manda al ambiente, y en el hijo esa función le gana al binario del mismo nombre.
El alias, en cambio, no viaja: en un script no se expande salvo que lo habilites. Es el único de los tres que se queda donde lo ves.

env | grep -E '^CLEAN=|BASH_FUNC'   # como paso del job: lo que el script usa y no declara

Leer el repositorio asume que el repositorio es el programa. La otra mitad la pone el ambiente donde corre el job y no está versionada, así que queda fuera del alcance de cualquier revisión del código. El nombre y lo que ejecuta son dos cosas distintas hasta que los resolvés en el proceso donde va a correr.

Power Tip #2 Permitir un comando es permitir todo lo que ese programa es capaz de hacer

La regla de sudoers autoriza less /var/log/secure y nada más. Leer un log con un visor: se abre, se lee, se cierra. Parece prudente y acotado.

less no solo muestra. Con ! corre un comando en una shell —la que diga $SHELL—, con | manda el contenido a otro programa y con v abre el editor. No es un agujero: está en su manual, en la lista de comandos.
Tampoco es una particularidad de less. vim sale a la shell con :!, find ejecuta programas con -exec, tar canaliza lo que extrae a un programa externo con --to-command. Ninguno está roto: todos hacen lo que su documentación dice.
"Solo lectura" describe para qué lo autorizaste, no lo que el programa puede hacer una vez abierto. La regla nombra un archivo y entrega todo lo que ese archivo es capaz de hacer, incluido lo que le delegue a otro.

sudo -l   # de cada línea: ¿qué más puede hacer ese programa, y a quién llama?

Enumerar lo que se puede correr te ahorra tener que prever cada cosa que no querés que corra, y eso no es poco. Lo que no te da es un límite a lo que esos comandos pueden hacer: el nombre autorizado no dice hasta dónde llega el proceso una vez que arrancó, y averiguarlo binario por binario no escala. Ese límite hay que ponerlo en otro lado.

Power Tip #3 sudo dice quién; systemd dice hasta dónde

El job de mantenimiento corre autorizado por una regla de sudoers que nombra un solo script. Mientras corre, tiene el filesystem entero a mano, /home incluido.

La regla contestó una pregunta —quién puede correr qué— y no hay nada en ella que conteste la otra. El alcance del proceso no se decide en sudoers porque sudoers no habla de eso.
La otra pregunta se responde en la unidad. ProtectHome=, ProtectSystem=, PrivateTmp= le recortan al proceso lo que puede tocar, sin tocar la autorización ni el script. No compiten con sudo: arrancan donde sudo termina.
Ahora, no le creas al archivo. En scope de usuario, según la versión de systemd, esas propiedades pueden necesitar además PrivateUsers=yes para hacer efecto — sin error, y con systemctl show confirmándote que están puestas.

systemd-run --user --pty --property=ProtectHome=yes ls -a $HOME   # si te lista el home, acá no rige

Las dos preguntas se responden en lugares distintos y ninguna cubre la de la otra. Antes de apoyarte en la segunda, hacela fallar a propósito: pedile al proceso lo que no tendría que poder, y fijate si puede.

Power Link

La discusión sobre IA y software libre suele quedarse en si el código generado sirve o no. Debian se está haciendo una pregunta más de fondo: quién puede contribuir y con qué. La resolución general en debate hasta el 8 de agosto junta seis propuestas en la misma votación, desde prohibir las contribuciones asistidas por LLM en el Contrato Social hasta no pronunciarse y dejarlo al criterio de cada quien: General Resolution: LLM usage in Debian. Cuando esto se publica todavía no se votó, que es el mejor momento para leerlas: las seis están argumentadas y firmadas, cosa poco frecuente en una discusión sobre este tema.

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

3 Power Tips + Power Link I10

sebelk — Sat, 21 Feb 2026 16:57:09 GMT

Las herramientas de monitoreo son fundamentales, pero una pobre interpretación de los resultados, pueden llevar a conclusiones incorrectas. Incluso usando chatbots de IA, si hacemos preguntas deficientes podemos terminar girando en círculos o tardar más tiempo en resolver un problema. Lo mejor es reducir el nivel de especulación con hipótesis técnica. A continuación vemos unos ejemplos bien sencillos.

Power Tip #1

No todas las métricas que parecen similares describen el mismo fenómeno.

Aplicación lenta.
Load 15.
CPU idle 50%.

Alguien descarta CPU porque “está libre”.

Pero:

Load describe tareas en ejecución o esperando.
CPU usage describe tiempo ocupado.
CPU pressure describe tiempo en que las tareas no pudieron progresar.

Son fenómenos distintos.

Antes de interpretar, mirá comportamiento:

vmstat 1 5
mpstat 1

Y si necesitás otra capa:

cat /proc/pressure/cpu

Es importante saber que “Load no es necesariamente consumo de CPU”, sin embargo, más importante es entender qué está describiendo cada señal.

Interpretarlas como si hablaran de lo mismo es especulación con números.

Power Tip #2

Tomar una métrica aislada de memoria en Linux no implica entender como funciona

free -h

Las columnas están ahí. Pero entender qué representa cada una es otra cosa.

used no significa “memoria en crisis”.
buff/cache no significa “desperdicio”.
available no significa “memoria libre inmediata”.

Antes de reaccionar ante un número alto, mirá dinámica:

vmstat 1 5

Linux administra memoria como recurso dinámico, no como espacio estático.

Leer columnas sin entender el modelo del kernel es especulación con formato tabular.

Power Tip #3

Reiniciar en muchas situaciones no hace otra cosa que restaurar un estado. No explica causas.

El servicio falla.
Se reinicia.
Funciona.

Eso no es diagnóstico.

Antes de repetir el gesto automático:

journalctl -u servicio-problematico -n 50

Si no entendemos por qué se degradó, volverá a pasar.

Reiniciar elimina el síntoma. No valida la hipótesis. Las herramientas no están equivocadas.

La diferencia está en entender qué fenómeno describe cada señal. Está claro que en el mundo real, muchas veces determinar la causa del problema lleva más tiempo que usar un trigger que reinice un servicio. Algo que pasa muchas veces apps legacy (la falta de especialistas o la triste realidad de falta del código fuente). Sin embargo, el problema es cuando se usa esta metodologìa como primera opción...

Power Link

La IA terminará con las operaciones de IT. ¿En serio? Bueno, en realidad no, para sorpresa de tecno-optimistas o tecno-pesimistas, aquí hay un interesante análisis de Sebastián Martínez de SUSE sobre este tema: Why AI Still Cannot Run Your Linux Infrastructure (And What Must Change)

3 Power Tips + 1 Power Link I9

sebelk — Sun, 04 Jan 2026 18:30:54 GMT

PSI (Pressure Stall Information) permite observar ese tipo de situaciones y, sobre todo, cambiar la forma en que interpretamos problemas de rendimiento y estabilidad en Linux. A partir de esa señal, el foco deja de estar en métricas globales y pasa a decisiones concretas: entender dónde ocurre el problema, a quién afecta y cómo intervenir sin arrastrar todo el sistema. Finalmente, el Power Link nos lleva a ver qué opina Gaël Duval, el creador de la distribución Mandrake, sobre uno de los hypes actuales.

Power Tip #1: ¿Cómo se ven afectadas mis aplicaciones por falta de recursos?

Existe a veces una creencia basado en pensamiento mágico: que el monitoreo depende solamente de la herramienta que se utilice. Pero más que la herramienta lo importante, es qué se mide y cómo interpretar esos resultados. Las métricas más conocidas: uso de cpu, load-average, uso de memoria, uso de I/O, etc. si bien son útiles pueden darnos en muchos casos un panorama parcial. Eso sucede porque están basados en los recursos, o en el scheduler.

Existen sin embargo desde hace varios años métricas que están más centradas en como las aplicaciones se ven impactadas por el uso de recursos. Con PSI (Pressure Stall Information) obtenemos un indicio del tiempo que las aplicaciones quedan detenidas porque el sistema no puede darles CPU, memoria o acceso a disco en el momento en que lo necesitan.

Esto está expuesto en el sistema de archivos:

PSI distingue entre situaciones donde al menos una tarea queda bloqueada (some) y escenarios donde todas las tareas relevantes compiten por el mismo recurso (full). Valores elevados y sostenidos en este full caso suelen indicar un problema estructural: no de picos puntuales, sino de diseño, aislamiento o priorización de workloads.

Vale hacer aquí tres aclaraciones:

Esta funcionalidad está presente a partir de la versión 4.20 del kernel (RHEL8 la trae como backport). En algunas distribuciones puede ser necesario habilitar PSI explícitamente en el arranque.
Esta no es la métrica definitiva, sin embargo ignorarla es perder el cuadro completo de lo que sucede tanto en el sistema como nuestras aplicaciones.
Versiones recientes del kernel incluyen también la medición de la presión sobre irq.

Power Tip #2: Las disrupciones se pueden atribuir a workloads específicos

Cuando el host empieza a perder capacidad de respuesta, no siempre el problema es global. Es común que el sistema siga siendo usable mientras algunos servicios o aplicaciones comienzan a degradarse, simplemente porque no acceden a los recursos cuando los necesitan. Esa degradación suele manifestarse como lentitud, mayor latencia o pérdida de capacidad de interacción.

En un Linux moderno, el kernel organiza los procesos bajo dominios de control definidos por cgroups. Esto permite observar de forma localizada qué tareas empiezan a quedarse esperando recursos, en lugar de razonar únicamente a partir de métricas agregadas del host.

En sistemas basados en systemd, ese dominio no es abstracto: se corresponde con services, slices o scopes. El mismo síntoma que aparece a nivel global puede observarse dentro de estos límites, lo que permite atribuir dónde se generan las esperas, incluso cuando el resto del sistema continúa funcionando con normalidad.

Pensar a nivel host diluye el diagnóstico. En cambio poner el foco en en services, scopes y slices permite relacionar directamente los síntomas percibidos —lentitud, tiempos de respuesta, degradación de rendimiento— con un grupo de procesos concreto.

Es decir, uno puede decir que el host muestra la presión acumulada, pero los cgroups permiten entender qué se queda atascado y frente qué recurso.

Power Tip #3: Abordar el problema de manera localizada

Cuando un servicio o aplicación empieza a tener tiempos muertos o a interferir con el resto, tenemos varias maneras de abordar el problema. Y no estamos hablando de las típicas acciones: reiniciarlo, moverlo o rediseñarlo.

Podemos tomar medidas más estructurales, por ejemplo, crear un slice de systemd, establecer límites y luego confinar esos servicios o procesos en esos slices.

Sin embargo, antes de intervenir de manera prematura, es conveniente tener en cuenta que Linux, en general ya tiene una agrupación de slices, scopes y servicios bastante razonable. En este punto entonces, ya sabemos que ese servicio problemático ya corre dentro de un perímetro definido.

En lugar de crear un nuevo slice, que tiene un carácter más permanente, podemos adoptar una solución más sencilla y gradualista. En systemd, los parámetros que gobiernan cómo compite por recursos no están fijos en scopes o servicios.

Un vistazo rápido alcanza para verlo (los siguientes son ejemplos para entender la idea):

systemctl show -p ControlGroup,CPUWeight,MemoryMax,IOWeight procesos-ruidosos.scope

Y tomar cartas en el asunto:

systemctl set-property procesos-ruidosos.scope …

Ese tipo de intervención es local, reversible y no convierte un incidente puntual en un cambio estructural.

Intervenir sobre una unidad existente permite corregir interferencias concretas sin rediseñar el sistema ni propagar el problema.

Fuentes y más recursos

Qué son los cgroups y para qué sirven

Power Link

Gaël Duval, creador de Mandrake, Murena y e/OS reflexiona sobre el impacto de la AI en el software open source: Why AI won’t “Kill Open Source”

3 Power Tips + 1 Power Link I8

sebelk — Sun, 23 Nov 2025 22:09:59 GMT

Resumen: En esta entrega, un ejemplo del poder que tienen la subshells de bash, como solucionar problemas de SELinux con Podman, y el uso de la herramienta yq para procesar archivos yaml.

Nota: En los ejemplos de comandos el prompt del usuario no privilegiado es "$", mientras que el del superusuario es "#"

Power Tip #1: Crear entornos de bash efímeros usando subshells

Una subshell es una copia del proceso de la shell actual. Una manera de crear una subshell es usando () y sirve: para personalizar el entorno de bash de manera reversible. Por ejemplo, podemos cambiar de directorio y la variable de entorno C (POSIX) para que muestre los mensajes de salida y de error en inglés:

$ echo "$LANG"
es_AR.UTF-8
$ pwd
/home/sergio

Ahora creamos una subshell:

$ (LANG=C; echo "La variable LANG cambia a  $LANG"; cd /algun_dir || cd /tmp ; echo "el directorio actual es $PWD";  myscript.sh)
La variable LANG cambia a  C
-bash: cd: /algun_dir: No such file or directory
el directorio actual es /tmp
-bash: myscript.sh: command not found

Al terminar la subshell, volvemos a la shell madre y tanto el directorio de trabajo como la variable LANG, vuelven a sus valores predeterminados:

$ pwd
/home/sergio
$ echo "$LANG"
es_AR.UTF-8

Power Tip #2: Identificar y solucionar problemas de SELinux al usar volúmenes.

Supongamos que necesitamos probar una configuración en un contenedor:

$ podman run  --name mynginx  -d -v $HOME/sandbox/nginx.conf:/etc/nginx/nginx.conf --pull=never docker.io/library/nginx@sha256:553f64aecdc31b5bf944521731cd70e35da4faed96b2b7548a3d8e2598c52a42

Ahora bien: ¿Qué sucede si el contenedor en realidad, falla al arrancar como lo muestran los logs?:

$ podman logs mynginx 
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2025/11/24 20:09:21 [emerg] 1#1: open() "/etc/nginx/nginx.conf" failed (13: Permission denied)
nginx: [emerg] open() "/etc/nginx/nginx.conf" failed (13: Permission denied)

Si estás tentado a desactivar SELinux, te recomiendo enfáticamente que leas ¿SELinux? Nah, dejalo en Disabled. Lo que ocurre es que no hay ninguna regla que permita que el contenedor acceda al contexto del archivo nginx.conf del host.

Contexto del archivo:

$ ls -Z  $HOME/sandbox/nginx.conf
unconfined_u:object_r:user_home_t:s0 /home/sergio/sandbox/nginx.conf

Este problema se soluciona fácilmente:

podman stop mynginx
podman rm mynginx

Y ahora el contenedor arrancará sin inconvenientes:

podman ps
CONTAINER ID  IMAGE                                                                                            COMMAND               CREATED         STATUS         PORTS       NAMES
a29c08eda1b1  docker.io/library/nginx@sha256:553f64aecdc31b5bf944521731cd70e35da4faed96b2b7548a3d8e2598c52a42  nginx -g daemon o...  12 seconds ago  Up 12 seconds              mynginx
podman logs mynginx 
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2025/11/24 21:16:10 [notice] 1#1: using the "epoll" event method
2025/11/24 21:16:10 [notice] 1#1: nginx/1.29.3
2025/11/24 21:16:10y [notice] 1#1: built by gcc 14.2.0 (Debian 14.2.0-19) 
2025/11/24 21:16:10 [notice] 1#1: OS: Linux 4.18.0-553.84.1.el8_10.x86_64
2025/11/24 21:16:10 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 262144:262144
2025/11/24 21:16:10 [notice] 1#1: start worker processes
2025/11/24 21:16:10 [notice] 1#1: start worker process 28
2025/11/24 21:16:10 [notice] 1#1: start worker process 29

Ahora bien, la opción :Z no es mágica, para tener una aproximación a lo que hace veamos el contexto del archivo $HOME/sandbox/nginx.conf:

$ ls -Z  $HOME/sandbox/nginx.conf
system_u:object_r:container_file_t:s0:c369,c839 /home/sergio/sandbox/nginx.conf

Campo	Antes	Después	Comentario
Usuario (SELinux)	unconfined_u	system_u	Pasa de ser un usuario sin restricciones a un usuario gestionado por el sistema
Rol (SELinux)	object_r	object_r	Se mantiene sin cambios
Asignación basada en tipos	user_home_t	container_file_t	Cambia a un tipo de asignación en la cual los contenedores pueden escribir
Rango (SELinux)	s0	s0:c369,c839	Este cambio implica que solamente podrá utilizarlo de manera exclusiva un único contenedor

Power Tip #3: Filtrar un archivo de template en formato yaml de Zabbix sin instalar absolutamente nada

Solamente necesitamos Podman, en el siguiente ejemplo estamos filtrando todos los triggers estáticos con nivel de severidad HIGH o DISASTER:

podman run --rm -v "${PWD}":/workdir:Z mikefarah/yq  '.zabbix_export.templates[].items[].triggers[] | select(.priority == "HIGH" or .priority == "DISASTER")| {"Trigger": .name}' template_db_mssql_agent2.yaml
Trigger: 'MSSQL: Percentage of the buffer cache efficiency is low'
Trigger: 'MSSQL: Page life expectancy is low'
Trigger: 'MSSQL: Percentage of work tables available from the work table cache is low'
Trigger: 'MSSQL: Service is unavailable'

Fuentes y más recursos

Power Link

El enlace de esta edición apunta a una entrevista a Linux Torvalds que gira en torno a la evolución del hardware, la IA y su impacto en el Linux y el desarrollo del kernel: Linus Torvalds — Talks about AI Hype, GPU Power, and Linux’s Future . En la actualidad cuestiones como la programación guiada por la intuición con la ayuda de chatbots debates importantes, no solamente en Linux sino en el ámbito IT en general.

3 Power Tips + 1 Power Link I7

sebelk — Tue, 04 Nov 2025 22:10:17 GMT

Resumen: Tips para bash, KDE Plasma y el uso del shell para cambiar entre ambientes de desarrollo. Además, en el Power Link, un artículo de Aaron P. MacSween, en el que discute el uso de AI scraping de sitios web usados de manera no consensuada para entrenar Modelos Extensos de Lenguaje (LLMs).

Power Tip #1: Agrupación de comandos en bash

El shell bash permite agrupar comandos, una funcionalidad tan sencilla como potente, por ejemplo:

{ dnf -y upgrade && systemctl restart httpd mariadb php-fpm ; } || echo "The final status is unsuccessful 🙁"

De esta manera si algunos de los dos comandos falla, mostrará un mensaje de error unificado.

Power Tip #2: Uso de cuadros de diálogos nativos de KDE Plasma en Firefox

Para hacerlo hay que abrir la url about:config y luego setear la preferencia widget.use-xdg-desktop-portal.file-picker en 1.

Esto se basa en el uso de XDG Portals que es un elemento de la arquitectura de entornos gráficos. Ellos proporcionan sandboxing, funcionalidad en entornos Wayland y lo que nos interesa en este caso: coherencia en la interfaz del usuario.

Antes 🤐	Después 😎️

Ah... usar la variable de entorno MOZ_USE_XDG_PORTAL no es la manera recomendada, más allá de lo que diga cierto chatbot...

Power Tip #3: [Flask + Linux]: Entornos Seguros usando solo la Shell

Problema Común

Ejecutar una app Flask con DEBUG=True en producción expone trazas de errores, rutas internas y detalles del stack que pueden ser explotados. Un sysadmin o devops con experiencia sabe que una práctica profesional es externalizar la configuración y usar el sistema operativo como interruptor de entorno.

Solución Basada en Linux + Flask

Usá la variable de entorno de Linux FLASK_ENV para alternar entre una configuración segura de Producción (config_prod.py) y una configuración orientada a Desarrollo (config_dev.py).

Archivo	Ajuste	Enfoque
`config_dev.py`	`DEBUG = True`	Depuración y agilidad.
`config_prod.py`	`DEBUG = False` (más `SECRET_KEY`)	Seguridad y Gestión de Secretos.

En config_prod.py, además de DEBUG = False, la clave secreta se carga desde el entorno con SECRET_KEY = os.environ.get('PROD_KEY') — así nunca queda hardcodeada en el repo.

Fragmento de app.py

import os
from flask import Flask
# Se importan las clases para un código robusto:
from config_dev import DevelopmentConfig 
from config_prod import ProductionConfig

app = Flask(__name__)

if os.environ.get('FLASK_ENV') == 'production':
    # Entorno PROD: Carga DEBUG=False
    app.config.from_object(ProductionConfig) 
else:
    # Entorno DEV: Carga DEBUG=True por defecto
    app.config.from_object(DevelopmentConfig)

Control desde la Terminal

+--------------------------+----------------------------------------------------------------------------------+---------------------------------------------------+ | Entorno | Comando | Resultado | +==========================+==================================================================================+===================================================+ | Producción | export FLASK_ENV=production | Debug mode: off | | | | | | | python app.py | (modo seguro) | +--------------------------+----------------------------------------------------------------------------------+---------------------------------------------------+ | Desarrollo | unset FLASK_ENV | Debug mode: on | | | | | | | python app.py | (vuelve a depuración) | +--------------------------+----------------------------------------------------------------------------------+---------------------------------------------------+

✅ Conclusión:

Este patrón convierte tu shell de Linux en un switch seguro de entorno para tu app Flask.

Preguntas de repaso

Seguridad y DevOps (Power Tip #3): ¿Cuál es el riesgo principal de ejecutar una aplicación Flask con DEBUG=True en producción, y cómo permite la variable de entorno de Linux FLASK_ENV que el administrador (sysadmin o devops con experiencia) cambie de manera segura a la configuración de producción (config_prod.py) usando solo un comando en la shell?
Eficiencia en Bash (Power Tip #1): En el ejemplo de agrupación de comandos, ¿cuál es el propósito de encerrar las sentencias de actualización (dnf -y upgrade) y de reinicio de servicios (systemctl restart ...) entre llaves {}, y qué rol juega el operador lógico || en caso de que alguna de estas operaciones falle?
Experiencia de Usuario (Power Tip #2): Si un usuario de KDE Plasma desea que Firefox utilice los cuadros de diálogo nativos del escritorio en lugar de los predeterminados del navegador, ¿qué URL debe abrir y a qué valor debe establecer la preferencia widget.use-xdg-desktop-portal.file-picker?

Power Link

AI scrapers request commented scripts. ¿Hasta qué punto una actividad es considerada benigina cuando se entrenan LLMs? Y muchas cuestiones para pensar...

3 Power Tips + 1 Power Link I6

sebelk — Mon, 13 Oct 2025 21:13:07 GMT

Resumen: Tips para KDE Plasma, manejo de directorios temporales e información detallada sobre Podman. Además, un link a un post en el cual un líder de ingenería recomienda pasar de Docker a Podman.

Power Tip #1 Reiniciar KDE Plasma sin cerrar sesión

kquitapp6 plasmashell ; plasmashell --replace >/tmp/plasma.log 2>&1 & disown -h

Power Tip #2 Crea un sandbox con limpieza automática usando tmpfiles.d

Podemos tener un directorio al cual usamos como sandbox, por ejemplo para:

Descarga de archivos
Volcar Logs y dumps temporarios
Scripts, código... y cualquier cosa que queremos probar.... por un tiempo.

Pero la idea es que no queremos que esos archivos se almacenen de manera indefinida... entonces:

cat << EOF >  ~/.config/user-tmpfiles.d/user-sandbox.conf 
> d %h/sandbox - - - 7d
> d %h/sandbox/ephemeral - - - 10m
> EOF

Una idea tentadora es usar un directorio como /tmp. Pero no es buena práctica usar ese directorio como sandbox. Luego de crear ese archivo, hay que ejecutar: systemd-tmpfiles --create --user que creará los directorios en las rutas especificadas. El servicio systemd-tmpfiles-clean eliminará periódicamente los archivos más viejos de 7 días del directorio ~/sandbox. El contenido de ~/sandbox/ephermeral en cambio, no se borrará automáticamente excepto que creemos una unit de tipo timer. Sin embargo se puede hacer manualmente mediante systemd-tmpfiles --clean --user. Como siempre entender por qué hacés lo que hacés es fundamental, los manpages son siempre aliados a tener en cuenta aun en pleno hype de la AI.

A propósito... el comando en el Power Tip #1 podría haber usado el directorio del sandbox en lugar de /tmp....

Power Tip #3 Revisar espacios y objetos de manera detallada en Podman

podman system df -v

De esta manera obtenemos información muy útil sobre las imágenes, contenedores y volúmenes que tenemos.

Power Link

Entrevista a Guido van Rossum, creador de Python, en la cual trata entre temas sobre AI

3 Power Tips + 1 Power Link I5

sebelk — Sat, 13 Sep 2025 19:38:48 GMT

Resumen: Tips para contenedores, uso de digests y análisis de seguridad de imágenes y obtener información de imágenes remotas. Además, un link a un post en el cual un líder de ingenería recomienda pasar de Docker a Podman.

Power Tip #1 Etiquetar las imágenes con digest en producción

❌ Mala práctica, apuntar a un tag:

podman run -d --name pass_git localhost/passteiner-ubi9:1

Esta es una mala práctica porque:

Es mutable, puede apuntar a otro build
También es un error confiar ciegamente usar latest, hoy puede apuntar a una versión, mañana a otra
Dificulta el debugging al no saber exactamente qué versión usás

✅ Buena práctica:

podman run -d --name pass-git --pull=never \
  localhost/passteiner-ubi9@sha256:3ca1e63acb24d88fde5e86eb1f476ba69eb740cd43590c37f3a964b5a19f001

Ventajas:

Totalmente reproducible y auditable.
Evitás actualizaciones sorpresa.
Ideal para ambientes de producción, CI/CD, y entornos donde la confiabilidad importa.

Power Tip #2 Examinar vulnerabilidades en imágenes de contenedores

La abstración con que nos proporcionan los contenedores, tal vez nos den una falsa sensación de seguridad, sin embargo, con trivy se pueden escanear en una imagen vulnerabilades por ejemplo:

trivy image docker.io/bitnami/wordpress

Debajo podemos ver un resumen:

Power Tip #3 Examinar imágenes de contenedores sin necesidad "pullearlas"

skopeo inspect docker://docker.io/ollama/ollama \
  | jq '{Digest: .Digest, Labels: .Labels, UltimaCapa: .Layers[-1]}'

{
  "Digest": "sha256:a5409cb903d30f9cd67e9f430dd336ddc9274e16fd78f75b675c42065991b4fd",
  "Labels": {
    "org.opencontainers.image.ref.name": "ubuntu",
    "org.opencontainers.image.version": "24.04"
  },
  "UltimaCapa": "sha256:45fafbfc0e267e3b61858ae5cb28ff739d901d85e1b60ee62db5dad64ae7c0d5"
}

De esta manera obtenemos:

El Digest de la imagen (identificador único inmutable).
En qué distro base y versión se construyó la imagen (ubuntu:24.04).
El Digest de la última capa, que representa el último cambio al sistema de archivos durante el proceso de build.

El digest de la última capa representa el último cambio al sistema de archivos en el proceso de construcción de la imagen.

Power Link

Why I Ditched Docker for Podman And You Should Too

3 Power Tips + 1 Power Link I4

sebelk — Mon, 11 Aug 2025 22:20:56 GMT

Resumen: Tips para curl, ollama y KDE Plasma. Y un link acerca de cómo las organizaciones están usando el open source y el upskilling para responder a las demandas laborales impulsadas por IA

Power Tip #1

Obtener un json con información de diagnóstico a partir de curl. Por ejemplo: una solicitud que devuelva el código de respuesta http, la versión del protocolo http`, la dirección ip, el tiempo de transferencia hasta el primer byte recibido y el tiempo total de la operación completa*:

curl -Ls -o /dev/null -w '{"code":%{response_code},"http":"%{http_version}","ip":"%{remote_ip}","ttfb":%{time_starttransfer},"total":%{time_total}}\n'   https://fast.com | jq

Power Tip #2

En el PT 2 anterior mostramos como usar un LLM offline. Aquí tenemos un script para bajar e instalar ollama:

#! /usr/bin/bash
cd /tmp || exit 1
curl -LO https://ollama.com/download/ollama-linux-amd64.tgz
sudo tar -C /usr/local -xzf ollama-linux-amd64.tgz
sudo useradd -r -s /bin/false -U -m -d /usr/local/share/ollama ollama
sudo usermod -a -G ollama "$(whoami)"
sudo tee  /etc/systemd/system/ollama.service << 'EOF'
[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=$PATH

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now ollama

Y ya está listo ollama para usar. 😉

Power Tip #3

Configurar klipper en Plasma para que al copiar una url llame a una acción. A diferencia de lo que ocurre en otros entornos o sistemas operativos, el Portapapeles de Plasma no sirve solamente para cortar/copiar y pegar. Sino que puede realizar tareas que hacen más sencillas las tareas tanto para usuarios finales como para usuarios administradores y/o desarrolladores. Los fundamentos de este Power Tip son:

Una expresión regular, por ejemplo: ^(https?://[^ \t\r\n"'<>]+)$
Una acción comando, por ejemplo: konsole --new-tab -e bash -lc 'curl -I -L -- "%1"; exec "${SHELL:-/bin/bash}" -i'

Dentro de la configuración del Portapapeles (klipper), se pueden realizar esos y otros ajustes.

Luego al copiar una URL, podemos usar un menú emergente que dispare la acción (en este de acuerdo al ejemplo arriba mencionado el comando curl en konsole). 💪

Power Link

2025 State of Tech Talent Report