Linux Sin Humo (Publicaciones sobre sysadmin)

Plan Táctico y Estratégico de la Memoria en Linux

sebelk — Mon, 01 Dec 2025 05:00:32 GMT

La mitología en torno a la memoria en Linux ha producido una serie de relatos:

En un extremo: Linux puede funcionar con muy poca memoria RAM.
Del otro lado: Linux consume mucha memoria.
Y que una partición SWAP debe tener entre 1 a 2 veces la memoria RAM.

Como vemos algunas historias son más recientes, otros más antiguas, pueden ser parcialmente ciertas y hasta contradictorias entre sí.

Este artículo tiene como propósitos:

Explicar de manera sencilla el funcionamiento de la memoria en Linux, desmitificando también algunos conceptos.
Enumerar y describir tácticas para que el uso de la memoria proporcione la mejor usabilidad y experiencia del usuario.
Ofrecer alternativas para que cada uno elija la mejor opción de acuerdo a sus necesidades.

Definiciones

Vamos a repasar algunos conceptos básicos que de manera más o menos frecuente usamos, usaremos metáforas en el camino. Ninguna metáfora es perfecta, sin embargo ellas nos ayudan a entender la realidad.

Memoria Virtual

La memoria virtual es el mecanismo por el cual cada proceso recibe un espacio de direcciones propio, independiente y protegido. El hardware traduce direcciones virtuales a físicas según tablas de páginas. Esto permite aislamiento, sobreasignación, mapeos de archivos y demanda dinámica de páginas, más allá de la cantidad de RAM disponible.

Linux trata de usar la mayor cantidad de memoria posible, para poder ejecutar las aplicaciones y acceder a los archivos de la manera más rápida posible. De manera que si la memoria libre es baja no es necesariamente un indicativo de un problema.

Page

Una página es la unidad mínima de memoria, de tamaño fijo (típicamente 4 KB), que el kernel y el hardware de gestión de memoria del procesador utilizan para organizar el espacio de direcciones y realizar el mapeo entre direcciones virtuales y físicas.

Page table

Es una estructura de datos jerárquica administrada por el kernel y usada por el hardware para traducir direcciones virtuales a direcciones físicas, con información de permisos y estado de cada página.

Page Fault

Un page fault ocurre cuando un proceso accede a una dirección válida de su espacio de memoria pero la página correspondiente no está preparada para ese acceso. Puede deberse a que la página aún no fue cargada, a que debe asignarse, o a que debe traerse desde disco. Si la página no está en RAM, el kernel debe cargarla, lo que puede ser lento; si ya estaba en RAM, el costo es menor.

Page cache

Es la caché de páginas de archivos gestionada por el kernel, usada para acelerar lecturas y escrituras almacenando en RAM los datos y metadatos de archivos y directorios, reduciendo accesos al disco.

Tipos de memoria

File Memory

Es la memoria relacionada con el Page Cache.

Anonymous Memory

Es la memoria que un proceso usa y que no está respaldada por un archivo: heap (asignada dinámicamente), stack (llamadas a funciones y almacenamiento de variables locales), COW (parte de la memoria cuando se crea un proceso hijo) y mapeos con MAP_ANONYMOUS. Su único respaldo posible es la swap. La memoria anónima se crea y utiliza en RAM. Si el kernel necesita expulsarla de RAM, su único destino posible es la swap, porque no tiene un archivo desde el cual reconstruirse. Pero su existencia normal no depende de la swap.

Memory Pressure

Memory pressure es estado en el que las páginas libres caen por debajo de umbrales críticos, obligando al kernel a iniciar mecanismos de liberación de memoria.

En términos prácticos cuando la presión es alta pueden surgir ciertos síntomas:

Sitios web / servidores HTTP: La latencia aumenta porque los workers deben esperar a que el kernel libere páginas. Además, puede haber más CPU gastada en recuperar memoria, lo que degrada aún más los tiempos de respuesta.
Sistemas de escritorio: El sistema pierde fluidez porque el scheduler empieza a verse afectado por stalls debidos a las operaciones para liberar memoria y, si hay swap, el sistema puede entrar en swap thrashing. Esto produce lag del mouse, ventanas que tardan en responder, escritorios congelados por segundos, etc.
Acceso remoto (SSH, RDP, VNC): Al haber presión, las operaciones de usuario-espacio tardan más en ejecutarse, y los daemons pueden quedar brevemente estancados esperando memoria. Esto causa retrasos notables en la interacción remota.

¿Y qué sucede si la presión de memoria puede llegar a ser tan alta que el kernel ya no logra conseguir memoria ni siquiera después de intentar liberarla?

Thrashing

El thrashing ocurre cuando la memoria RAM no alcanza para mantener las páginas que los procesos usan todo el tiempo. El kernel empieza a sacar páginas de memoria para hacer lugar a otras nuevas, pero enseguida vuelve a necesitarlas. Esto genera un bucle de fallos de página y de recarga constante desde el disco.

Con swap: las páginas anónimas van y vienen entre RAM y swap, lo que dispara el uso de disco y vuelve el sistema extremadamente lento.
Sin swap: las páginas anónimas no tienen adónde ir y el kernel termina activando el OOM killer.
Incluso sin swap: puede haber thrashing si las páginas vienen de archivos (page cache), ya que el kernel debe recargarlas una y otra vez.

OOM (Out-Of-Memory) 💀 🔥

Out-Of-Memory es una situación en la cual el kernel agotó todos los mecanismos para liberar memoria:

Liberar páginas del caché.
Sacar páginas anónimas de swap.
Compactar memoria.
Liberar memoria mediante kswapd.
Aplicación de políticas de cgroups (muy común al usar contenedores).

OOMKiller

El OOM-killer es el mecanismo que usa el kernel cuando ya no puede asignar más memoria, incluso después de intentar liberar todas las páginas que es posible descartar o mover fuera de la RAM. En esa situación crítica, el kernel calcula un puntaje para cada proceso (oom_score) y finaliza al que resulte más conveniente para recuperar memoria rápidamente y permitir que el sistema siga funcionando. Este comportamiento puede influenciarse ajustando oom_score_adj, que hace que un proceso sea más o menos propenso a ser elegido.

oom_score

Como ya se mencionó a cada proceso se le asigna un puntaje de acuerdo a distintos factores, cuanto más alto es, más susceptible es a ser terminado por OOMKiller.

Y también, como dijimos mediante oom_score_adj podemos influir en el score de un proceso:

En versiones más recientes de las distribuciones existe el comando choom que permite ver y/o ajustar dicho valor.

Swap

Los usuarios ocasionales de Linux y aun muchos sysadmins tienen una idea negativa sobre "la swap". Simplificaciones extremas y conceptos anticuados la han convertido en le gran villana de la historia del sistema operativo.

Si comparamos a la memoria con un escritorio, sin swap podría lucir así:

Photo by Ashim D’Silva on Unsplash

Así que primero vamos a decir lo que no es:

No es la memoria virtual sino que forma parte de la técnica que realiza el sistema operativo para administrar la memoria.
No es un espacio de reserva ni un último recurso. Es un espacio complementario sirve para liberar RAM.
No funciona como último recurso, pero el sistema operativo puede mover hacia la swap las páginas de memoria no usadas recientemente.
No es algo que el sistema operativo pueda alegremente prescindir aun cuando la cantidad de memoria RAM física sea grande. Quienes parecen haber inventado la pólvora, nos cuentan que es posible técnicamente que Linux funcione sin swap. Si bien es cierto, al carecer de swap, el kernel no tiene manera de mover páginas de memoria anónimas hacia el área de swap y liberar así RAM para procesos que la necesitan urgentemente.

Nuestro escritorio con swap:

Photo by Alexandru Acea (edited by me) on Unsplash

¿Los cajones de un escritorio los usamos cuando lo tenemos abarrotado de cosas? No, los usamos para guardar cosas que no son de alta prioridad. Aunque es cierto, si luego queremos usar esa tijera o aquel destornillador en algún momento requerirá un poco más de trabajo, tendremos que abrir el cajón, buscarlo, extraerlo, etc.

Ah, y la swap también sirve para hibernar, aunque honestamente no se cuanta gente mantiene esa práctica.

Tuning

Ahora veremos diferentes tácticas que podemos usar para optimizar el uso de la memoria.

cgroupv2

cgroup es un mecanismo para organizar los procesos de manera jerárquica y distribuir los recursos del sistema a lo largo de la jerarquía en una manera controlada y configurada.

Un cgroup se compone de un núcleo que es responsable primariamente en organizar de manera jerárquica los procesos y controladores que comúnmente distribuyen un tipo específico de recurso del sistema a lo largo de la jerarquía.

En la versión 2 de cgroup un proceso no puede pertenecer a diferentes grupos para diferentes controladores. Si el proceso se uno al grupo alfa, todos los controladores para alfa tomarán control de ese proceso.

Supongamos que los procesos de un cgroup (y todos los grupos hijos) usan poca memoria, podríamos decirle al kernel que libere memoria de otros cgroups. Esto es precisamente lo que hace el parámetro memory.low.

Otro parámetro interesante para monitorear es memory.pressure, la primera línea tiene el tiempo físico de una o más tareas demoradas debido a la falta de memoria. La segunda sería lo mismo pero para todas las tareas del grupo, full es lo mismo pero para todas las tareas del grupo, Entonces si miramos el archivo /sys/fs/cgroup/user.slice/memory.pressure:

some avg10=0.00 avg60=0.13 avg300=0.12 total=1690238
full avg10=0.00 avg60=0.10 avg300=0.09 total=1394199

Significa que, dentro del grupo de control user.slice, en los últimos 10 segundos no hubo tareas afectadas por presión de memoria. Sin embargo, en el último minuto las tareas estuvieron bloqueadas un 0,13% del tiempo y un 0,12% en los últimos cinco minutos. El valor total indica que estas situaciones acumulan aproximadamente 1,7 segundos de espera. La segunda línea muestra las mismas métricas, pero aplicadas a los casos en que todas las tareas del grupo estuvieron simultáneamente afectadas por presión de memoria (full en lugar de some).

Es decir:

some → indica si un retraso afectó al menos una tarea.
full → indica si el retraso afectó a todo el cgroup simultáneamente.

zram

zram es por así decirlo, una manera cool de usar swap gracias a un módulo del kernel.

Photo by chuttersnap on Unsplash

En lugar de gastar espacio en un disco (sea rígido o sólido) usamos dispositivos de bloque en la propia RAM. Los bloques swapeados se guardan comprimidos. Esto discos virtuales son rápidos y ahorran memoria.

Una de las pocas desventajas que tiene esta metodología es la incapacidad para poder hibernar el sistema operativo, al no estar presente la partición en un almacenamiento de tipo persistente.

Sistemas de archivos

El journal de ext4 puede ser lento, xfs puede ser una mejor alternativa o mejor aun btrfs.

EarlyOOM

El oom-killer del kernel solamente se dispara en situaciones extremas y le puede llevar mucho tiempo hasta que puede enviar SIGKILL a los procesos que sean necesarios para poder liberar memoria. Durante ese tiempo probablemente el usuario no pueda interactuar con el sistema operativo.

EarlyOOM trabaja en espacio de usuario y por lo tanto se puede anticipar y ser mucho más rápido.

El comportamiento predeterminado en Fedora es que si hay menos del 10% de RAM y/o SWAP libre, earlyoom envía una señal de terminación a todos los procesos con oom_score más alto. Si la RAM como SWAP libre bajan por debajo del 5%, earlyroom enviará una señal para matar todos los procesos con oom_score más elevado.

La idea es recuperar la usabilidad (especialmente en un entorno de escritorio) lo antes posible.

El problema es que EarlyOOM no soporta al momento la medición de la memory pressure como indicativo para tomar decisiones.

nohang

Este servicio es mucho más configurable y aporta una mejor solución que EarlyOOM.

Algunas funcionalidades son:

Se puede elegir la acción que realizará en una situación OOM.
Ofrece varios criterios para elegir los procesos a finalizar.
Soporta zram
Puede usar memory pressure para tomar una acción.
El archivo de configuración es medianamente sencillo

Sin embargo, este proyecto en la actualidad tiene poca actividad comparado por ejemplo con EarlyOOM

zswap

Con zswap no reemplazamos el espacio swap en el disco sino que usamos un caché comprimido en la RAM. Este método ahorra I/O, obteniendo entonces mejor rendimiento y alargando la vida útil de discos flash o sólidos. La única desventaja es usar algo de tiempo del procesador para realizar la compresión.

Photo by Pineapple Supply Co. on Unsplash

Mediante el caché se logra una diferenciación entre páginas más usadas (zswap) y menos usadas (swap).

systemd-oomd

El servicio systemd-oomd es un proyecto en el que comenzó en Facebook para integrarlo con systemd. En un principio estaba pensado para manejo de memoria a gran escala, y bastante más complejo de configurar. Sin embargo ha sido adoptado desde Fedora 34 reemplazando a EarlyOOM. En las distribuciones que usan versiones recientes de systemd, está disponible, aunque no todas lo habilitan de manera predeterminada.

Resumen

Swap no es la villana de la película
Si existe la opción de migrar a otros sistema de archivos aunque con características un tanto experimental, elegir btrfs. Una opción más moderada es xfs.
El tuning de cgroupv2 puede traer grandes beneficios, no obstante existen proyectos y distribuciones que no lo usan.
EarlyOOM es una solución rápida y aplicable a una amplia gama de sistemas Linux, aunque no siempre es la más exacta ni más elegante.
El servicio nohang (o no hang-desktop) es una opción más madura aunque algo más compleja que EarlyOOM, pero que sin embargo ha caído en cierta inactividad.
El servicio systemd-oomd inicialmente incorporado por Facebook es seguramente la opción más adecuada para escenarios más complejos y de manejo de memoria a gran escala. También es utilizado actualmente en sistemas de escritorio.
Sin embargo, muchas distribuciones o sabores de distribuciones prefieren usar el mecanismo clásico de OOMKiller.
A veces se sugiere el ajuste de parámetros del kernel mediante sysctl.
Si se desea ahorrar espacio en disco se puede reemplazar la swap por zram, sacrificando la opción de hibernar el sistema.
La opción zswap es más sofisticada, aunque dependemos del uso de swap en disco.

Photo by sk on Unsplash

Fuentes consultadas

Una introducción pragmática al uso de plugins en Neovim

sebelk — Sun, 04 May 2025 19:22:12 GMT

Ya me he referido a Neovim alguna vez en el pasado: Lo viejo, lo bueno y lo nuevo en Neovim . Se pueden extender las funcionalidades de neovim, mediante plugins, de manera similar a las de su predecesor, el editor Vim. En este artículo propongo un modo muy sencillo y lo más transparente posible para el uso de plugins en Neovim.

Hay dos tipos de plugins:

Globales: Funcionan para todo tipo de archivos.
Filetype: Sirven para un tipo particular de archivos**.

El siguiente listado muestra plugins globales que forman parte del core de neovim:

ls -l /usr/share/nvim/runtime/plugin
total 60
-rw-r--r-- 1 root root  411 mar 26 10:48 editorconfig.lua
-rw-r--r-- 1 root root 3677 mar 26 10:48 gzip.vim
-rw-r--r-- 1 root root  904 mar 26 10:48 man.lua
-rw-r--r-- 1 root root  138 mar 26 10:48 matchit.vim
-rw-r--r-- 1 root root 7966 mar 26 10:48 matchparen.vim
-rw-r--r-- 1 root root  152 mar 26 10:48 netrwPlugin.vim
-rw-r--r-- 1 root root 2160 mar 26 10:48 osc52.lua
-rw-r--r-- 1 root root 2017 mar 26 10:48 rplugin.vim
-rw-r--r-- 1 root root 1778 mar 26 10:48 shada.vim
-rw-r--r-- 1 root root  236 mar 26 10:48 spellfile.vim
-rw-r--r-- 1 root root 2527 mar 26 10:48 tarPlugin.vim
-rw-r--r-- 1 root root  442 mar 26 10:48 tohtml.lua
-rw-r--r-- 1 root root  202 mar 26 10:48 tutor.vim
-rw-r--r-- 1 root root 2642 mar 26 10:48 zipPlugin.vim

Plugin	Funcionalidad
`editorconfig`	Busca y lee archivos .editorconfig para aplicar reglas de indentación, fines de línea y codificación
`gzip`	Editar archivos comprimidos con gzip
`man`	Abrir páginas del manual en el editor
`matchit`	Extiende la funcionalidad del comando `%`
`matchparen`	Resalta paréntesis coincidentes
`netrwPlugin`	Maneja la transferencia de archivos y listado de directorios remotos a través de una red
`osc52`	Detecta si es posible usar el código de escape ANSI para copir desde vim a otras terminales para poder copiar texto desde neovim usand el clipboard del sistema
`rplugin`	Gestiona, migra, actualiza y carga remote plugins automáticamente (están escritos en otros lenguajes como Python, Ruby, Node.js, etc y que se manejan de manera independiente del editor sin afectar el rendimiento)
`shada`	Datos Compartidos entre las sesiones de neovim
`spellfile`	Descarga de archivos de ortografía
`tarPlugin`	Exploración de tarballs
`tohtml`	Conversor a html
`tutor`	Tutorial
`zipPlugin`	Exploración de archivos zip

Los scripts en vimL pueden contener comandos de edición, estructuras de control, funciones, manejo de listas, diccionarios, y puede simular objetos mediante diccionarios con referencias a funciones. El otro lenguaje nativo que incorpora neovim es Lua. Los desarrolladores de neovim consideran que ese lenguaje es más eficiente, tiene una sintaxis más moderna y estándar, maneja mejor los errores, permite que sea extendido fácilmente con plugins y módulos complejos, sin necesidad de depender de procesos externos o hacks.

Si consideramos el archivo del plugin man contiene lo siguiente:

if vim.g.loaded_man ~= nil then
  return
end
vim.g.loaded_man = true

vim.api.nvim_create_user_command('Man', function(params)
  local man = require('man')
  if params.bang then
    man.init_pager()
  else
    local err = man.open_page(params.count, params.smods, params.fargs)
    if err then
      vim.notify('man.lua: ' .. err, vim.log.levels.ERROR)
    end
  end
end, {
  bang = true,
  bar = true,
  range = true,
  addr = 'other',
  nargs = '*',
  complete = function(...)
    return require('man').man_complete(...)
  end,
})

local augroup = vim.api.nvim_create_augroup('nvim.man', {})

vim.api.nvim_create_autocmd('BufReadCmd', {
  group = augroup,
  pattern = 'man://*',
  nested = true,
  callback = function(params)
    local err = require('man').read_page(assert(params.match:match('man://(.*)')))
    if err then
      vim.notify('man.lua: ' .. err, vim.log.levels.ERROR)
    end
  end,
})

📝 Mini resumen conceptual — man.lua

✔ ¿Qué hace el plugin?

Define cómo abrir manpages usando comandos (:Man) y URIs (man://...).
Define cómo manejar errores (usa vim.notify).

✔ ¿Cómo funciona?

Previene carga múltiple con vim.g.loaded_man.
Crea un comando :Man con opciones (bang, autocompletado, etc.).
Crea un autocmd que detecta buffers con URI man:// y carga la manpage.
Usa funciones (open_page, init_pager, read_page, man_complete) definidas en el módulo man.
Muestra errores con vim.notify si algo falla.

✔ ¿Qué flujo sigue?

Usuario → :Man o :edit man:// → función del módulo man → buffer con la manpage

✅ El plugin es 100% todo Lua

Usa API moderna de Neovim:
vim.api.nvim_create_user_command
vim.api.nvim_create_autocmd
vim.notify
Usa variables globales Lua: vim.g.loaded_man
Usa funciones Lua: string.match, require, etc.

Es un plugin moderno, pensado para ser usado con Neovim o Vim con soporte de Lua.

API para plugins y herramientas

Además, neovim posee una API con la cual se pueden hacer desarrollos en otros lenguajes de programación y por eso existen plugins y/o herramientas relacionadas que no están escritos en vimL o LUA:

El plugin far.vim está desarrollado en python:

Se debe ejecutar :UpdateRemotePlugins cada vez que un plugin remoto se instale, se actualice, o se borre. Esto generará o actualizará un archivo manifest, por ejemplo:

cat ~/.local/share/nvim/rplugin.vim 
" node plugins


" python3 plugins
call remote#host#RegisterPlugin('python3', '/root/.local/share/nvim/plugged/far.vim/rplugin/python3/far', [
      \ {'sync': v:false, 'name': '_far_nvim_rpc_async_invoke', 'type': 'function', 'opts': {}},
     \ ])


" ruby plugins


" python plugins

Equivalencias entre Vim y Neovim

Abro un paréntesis para recordar las equivalencias entre archivos de Vim y Neovim:

Elemento	Vim	Neovim
Config principal	`~/.vimrc`	`~/.config/nvim/init.vim` o `init.lua`
Carpeta de configuración	`~/.vim/`	`~/.config/nvim/`
Plugins (autoload)	`~/.vim/autoload/`	`~/.local/share/nvim/site/autoload/`
Plugins (paquetes)	`~/.vim/pack/`	`~/.local/share/nvim/site/pack/`
Datos de usuario (swap, undo, backup, etc.)	Dentro de `~/.vim/` o definido por el usuario	`~/.local/state/nvim/`
Swap files	`~/.vim/swapfiles/`	`~/.local/state/nvim/swap/`
Undo files	`~/.vim/undodir/`	`~/.local/state/nvim/undo/`
Backup files	`~/.vim/backup/`	`~/.local/state/nvim/backup/`
viminfo	`~/.viminfo`	No se usa directamente
shada	No aplica (usa viminfo)	`~/.local/share/nvim/shada/main.shada`
Colorschemes	`~/.vim/colors/`	`~/.config/nvim/colors/`
After directory (sobreescribir plugins/config)	`~/.vim/after/`	`~/.config/nvim/after/`

Nota sobre shada:

Vim usa viminfo → ~/.viminfo.
Neovim usa shada → ~/.local/share/nvim/shada/main.shada.

No es recomendable hacer enlace simbólico entre estos dos archivos porque no son 100% compatibles.

Soporte nativo para plugins en Vim 8 (y en adelante)

Photo by Handy Wicaksono on Unsplash

Desde Vim 8.0 el editor cuenta con soporte nativo para paquetes. En Vim un paquete no es otra cosa que un directorio de plugins. Es decir, considerando el siguiente escenario.

El paquete lightline.vim se va a cargar automáticamente al abrir el editor, mientras que el otro plugin toggleterm podrá activarse con el comando :packadd toggleterm.nvim

Guía rápida para el método nativo de Vim 8+

Mostraré como usar 2 plugins.

1. Crear las carpetas necesarias

Abrí tu terminal y ejecutá:

mkdir -p ~/.vim/pack/misplugins/{start,opt}

Explicación rápida:

~/.vim/pack/ → carpeta donde Vim busca paquetes.
misplugins → nombre del grupo que quieras (puede ser cualquier nombre).
start/ → indica que los plugins se cargan automáticamente al abrir Vim.
opt/ → indica que los plugins se cargarán bajo demanda con el comando packadd

2. Descargar los plugins

Ahora dentro de start/, cloná los repositorios de Git de los plugins:

cd ~/.vim/pack/misplugins/opt

# vim-fugitive (permite ejecutar y gestionar comandos de Git directamente dentro de Vim, como hacer commits, ver logs, ver diferencias (diffs) y manejar ramas sin salir del editor.)
git clone https://tpope.io/vim/fugitive.git
vim -u NONE -c "helptags fugitive/doc" -c q

cd ~/.vim/pack/misplugins/start

# lightline.vim (barra de estado mejorada)
git clone https://github.com/itchyny/lightline.vim.git
# Usar el comando siguiente si lightline.vim se muestre sin colores y guardarlo en algún archivo de configuración del shell.
# export TERM=xterm-256color

Con esto ya los tenés instalados.

3. Configuración para lightline.vim|

Podés agregar algunas líneas en tu ~/.vimrc para aprovechar lightline.vim:

" Opcional: configuración mínima para lightline
set laststatus=2

4. Listo

¡Abrí Vim y ya podés usar el plugin lightline.vim!

Si querés cargar el plugin fugitive, lo hacés con:

:packadd fugitive

Importante: Los plugins escritos en lua no funcionarán en Vim

Algo interesante en Vim y Neovim es que podemos ver los plugins que ya vienen con el editor con el comando :help standard-plugin-list y con :help local-additions los plugins que vamos agregando:

O si preferimos algo más sofisticado, para ver nuestros plugins:

:echo join(keys(g:plugs), ' ')

Si bien esta funcionalidad también existe en Neovim, podemos administrar los plugins de manera más flexible y automatizada. Esto nos lleva a considerar el uso de gestores de plugins.

Gestores de plugins

Existen varios gestores de plugins:

Me parece muy recomendable vim-plug porque:

Requiere muy poca configuración: una lista con los paquetes de plugins deseados.
Instala y actualiza todos los paquetes de nuestra lista o los que seleccionemos.
Detecta y elimina plugins que borramos de nuestra lista.
Muestra el estado de los plugins.
Genera instantáneas de nuestros paquetes con su configuración, con la posibilidad de restaurarlas.
Posee atajos de teclado.
Es compatible tanto con Vim como Neovim

Si queremos deshabilitar todos los plugins podemos ejecutar nvim --noplugin.

Neovim sigue los lineamientos de la XDG Base Directory Specification. Algo que puede ser muy útil: poner el listado de plugins en un archivo separado. Esto es: creando un archivo ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/plugins.vim y en el archivo ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/init.vim teniendo una simple línea:

runtime plugins.vim

Entonces, comentando esa línea es una manera alternativa para desactivarlos.

Pero hay más: supongamos que tenemos esta configuración en el archivo ${XDG_CONFIG_HOME:-$HOME/.config}/nvim/plugins.vim:

Plug 'nyngwang/NeoTerm.lua'

call plug#end()

" Esta es la manera de embeber código lua en un archivo de tipo vimL
lua << EOF
require("neo-term").setup {
  exclude_filetypes = { "oil" }
}
EOF

nnoremap <F4> :NeoTermToggle<CR>
tnoremap <F4> <C-\><C-n>:NeoTermToggle<CR>
tnoremap <Esc> <C-\><C-n>:NeoTermEnterNormal<CR>

Con esta configuración:

Al presionar F4 se abirá una terminal.
Al presionar de vuelta F4 se cerrará la terminal.
Con Esc se vuelve al modo Normal en la terminal.

En tiempos en los que tanto se declama la agilidad, como contrasentido se ofrecen editores que consumen muchos recursos, con desarrollos no exentos de torpezas y caprichos impuestos de antemano. El minimalismo de Vim como de Neovim nos permite adaptarlo de acuerdo a lo que necesitemos, la posibilidad de agregar distintas funcionalidades, sea para desarrollo, mejor usabilidad y experiencia del usuario (sí: el desarrollador o sysadmin también es un usuario 😀). Finalmente, si bien tanto Vim como Neovim poseen el soporte nativo para manejar paquetes de plugins, encuentro en vim-plugin una manera mucho más conveniente de hacerlo.

Característica	Sistema Nativo (Vim 8 `packages`)	`vim-plug`
Instalación	Manual (clonar repos en `pack/`)	Automática vía script (`plug.vim`)
Configuración	En `vimrc`, usando `packadd` o estructura `start/opt`	Declarativa en `vimrc` con `Plug`
Carga diferida (lazy-loading)	Manual con `packadd` desde `opt/`	Incorporado: `on`, `for`, `cmd`, `event`
Instalación de plugins	Manual (`git clone`)	`:PlugInstall`
Actualización	Manual (`git pull` en cada plugin)	`:PlugUpdate`
Desinstalación	Manual (borrar carpeta)	`:PlugClean`
Gestión de dependencias	No soportado nativamente	Limitada (tú defines el orden)
Soporte para branches/tags	Manual (`git checkout`)	Sí (`Plug 'user/repo', { 'branch': 'dev' }`)
Paralelismo en instalación	No	Sí (instala varios plugins a la vez)
Interfaz de usuario	Ninguna	Básica pero útil (durante instalación/update)
Velocidad en carga	Muy rápida (carga solo en startup)	Muy rápida con lazy loading
Soporte oficial	Parte de Vim 8+	Mantenido por la comunidad
Curva de aprendizaje	Mayor (entender estructura `pack/`)	Muy simple y bien documentado
Compatibilidad	Solo Vim 8+	Compatible con Vim 7.4+, Neovim

Conclusión

El soporte nativo de Vim/Neovim es como una biblioteca física organizada con dos tipos de estantes:

start/: son los libros que se abren automáticamente apenas entrás a la biblioteca —es decir, los plugins que se cargan al iniciar Vim/Neovim.
opt/: son libros que están en los estantes, pero que vos tenés que buscar y abrir manualmente usando el comando :packadd.

Este sistema te da control total, pero también requiere que te ocupes de la instalación, organización y carga de cada plugin.

Los gestores de plugins, como vim-plug, funcionan como un sistema de préstamo digital moderno:

Suscripción básica: Declarás qué libros (plugins) querés en una lista de solicitudes (Plug 'autor/plugin'), y al ejecutar un comando como PlugInstall, el sistema los descarga automáticamente y los organiza en las secciones correspondientes del runtimepath.
Dependencias = citas bibliográficas que debés declarar manualmente: Si el libro A necesita al libro B para entenderse correctamente, vos tenés que pedir ambos explícitamente. A diferencia de gestores como npm, pip o cargo, no hay resolución automática de dependencias: nadie deduce relaciones por vos.
Actualizaciones periódicas: Usando el comando PlugUpdate, podés sincronizar tu colección con las últimas ediciones disponibles. Eso sí: estos comandos actualizan lo que ya tenés, pero no agregan automáticamente nuevos plugins a menos que los declares en tu configuración.

Ahora cabe preguntarse dos cosas:

¿Cómo podemos empezar a usar Lua?
Más allá de que vim-plug es una excelente opción: ¿Es actualmente la mejor para Neovim?

Más Recursos

Frameworks para Bash: ¿realmente los necesitamos? Una mirada profunda a bash-it

sebelk — Wed, 02 Apr 2025 18:07:44 GMT

Después de muchos años 📅de usar bash es normal ir acumulando alias, funciones, variables, scripts, qué ponemos por aquí y por allá, con suerte en algún directorio más o menos estandar. Pero llega un momento que es difícil de manejar todo eso. De acuerdo a mi experiencia he notado que muchas veces se usa algo porque se sacó de un foro de reddit, stackoverflow, de una búsqueda en google o DuckDuckGo, de una respuesta de a un prompt en la IA... o porque alguien lo dijo. Funciona, pero no se tiene ni idea de por qué funciona.

Una vez en un curso un alumno me dijo:

- ¡Ahora entiendo porque hago lo que hago cada día en mi trabajo! 😀

Es imposible saber y acordarse de todo, pero tener una idea conceptual al menos general de como funcionan las cosas nos ayuda en el trabajo diario.

Por eso es importante tener en cuenta algunos conceptos de bash fundamentales.

Alias

Los alias se usan para abreviar o cambiar el comportamiento de comandos simples o repetitivos.

Por ejemplo:

alias rm ='rm -i'

De este modo, estamos cambiando el comportamiento del comando rm para que nos pregunte antes de borrar archivos. Hay otras situaciones en los cuales queremos hacer un comando mucho más sencillo:

alias dma='date +%d-%m-%y'

Funciones

Si bien los alias son muy útiles, tienen limitaciones:

❌ No se expanden de manera predeterminada en scripts.
❌ No soportan parámetros posicionales.
❌ Tienen un soporte muy estrecho para lógica condicional.

Si tenemos alguno de esos requerimientos entonces usaremos funciones, como la siguiente que sirve para ver un archivo sin líneas vacías o con "#":

clrfile () 
{ 
    if [[ $# -eq 0 ]]; then
        echo "Error: Proporciona al menos un archivo." 1>&2;
        return 1;
    fi;
    local file;
    for file in "$@";
    do
        if [[ ! -f "$file" ]]; then
            echo "Error: '$file' no es un archivo válido." 1>&2;
            continue;
        fi;
        grep -Ev '^[[:space:]]*#|^$|^[[:space:]]*;' "$file";
    done
}

Variables

A medida que vamos usando bash, encontramos la necesidad de crear variables, por ejemplo:

HISTFILESIZE=1048576
export nikola="/home/sergio/Documentos/Arts/nikola-env"
export GTK_USE_PORTAL=1

Opciones de bash

Bash posee muchas opciones que nos sirven para modificar el comportamiento del shell como vemos a continuación:

shopt -s histappend
shopt -s autocd
shopt -s dirspell
shopt -s cdspell
shopt -s cdable_vars

Con el paso del tiempo, nuestro archivo .bashrc, puede hacerse muy largo, poco claro, poco modular, o hasta incluso creamos muchos archivitos aquí y allá con funciones y/o alias como si fueran scripts. Con suerte tal vez los pongamos en ~/bin o ~ /.local/bin. Cuando llegamos a este punto tal vez estemos necesitando que nuestras herramientas estén organizadas, que manejen estándares, que podamos contar con módulos que se puedan habilitar o deshabilitar para poder administrar y/o desarrollar de manera más profesional. Es decir, necesitamos un framework.

bash-it, un framework como aliado

El shell zsh usa un framework llanado "Oh My Zsh". Sin embargo, las distribuciones principales, a excepción de Kali, el resto usa bash de manera predeterminada. Así que en muchos casos no tiene sentido invertir tiempo en cambiarse a zsh 😄. Y en particular para los que quieran aprender Linux, recomiendo que comiencen con Bash, luego si tienen tiempo y el ámbito corporativo se los permite podrán explorar Zsh como una excelente alternativa.

Por lo tanto, ¿qué tenemos para bash? En un principio encontré que justamente existe: Oh My Bash. Este proyecto usa el popular pero no por eso recomendado método de instalación desde el punto de vista de la seguridad que consiste en "curl-pipe-script". Sin embargo, ciertos problemas de Instalación manual con OMB, me llevaron a considerar a bash-it por tener mejores métricas:

Estas estadísticas hacen que más allá del bonito sitio que armó la comunidad de Oh My Bash eligiera bash-it:

✅ ¿Es técnicamente confiable Bash-it para producción?

No vamos a encontrar a bash-it en repositorios de las distribuciones principales, sin embargo desde un punto de vista técnico puro, Bash-it es bastante seguro porque:

✔️ No requiere privilegios especiales (se instala en el home del usuario).
✔️ Usa código abierto auditable (podés revisar cada plugin, alias, función).
✔️ Es fácil de activar/desactivar funcionalidades individuales (plugins, alias, temas).
✔️ Está diseñado para usarse solo en entornos interactivos, no impactando scripts automáticos.

Sin embargo, la confiabilidad depende mucho del criterio de quien lo administra.

🔐 ¿Consideraciones de seguridad para entorno corporativo?

⚠️ Es código abierto no revisado oficialmente por las distribuciones más populares, por lo cual debés auditar lo que habilitás.
⚠️ Debe implementarse con criterio, evitando plugins que hagan conexiones externas automáticas o definan alias potencialmente riesgosos.
⚠️ Es aconsejable versionar y usar un fork corporativo que controles.

🚨 ¿Riesgos o precauciones a considerar?

❌ Podrías introducir complejidad innecesaria si el equipo no está acostumbrado a Bash avanzado.
❌ Posibilidad de romper comandos estándar con alias mal elegidos.
❌ Necesidad de capacitación interna sobre su uso para evitar malentendidos.

💡 Recomendaciones profesionales (cómo hacerlo confiable):

📌 Usá un fork interno auditado por el equipo de seguridad o infraestructura.
📌 Instalá solo plugins y funcionalidades que realmente necesitás.
📌 No habilites funciones o plugins "experimentales" o desconocidos.
📌 Documentá claramente qué está habilitado y por qué.

Hechas las aclaraciones en las que me siento obligado a hacer, vayamos al procedimiento de instalación 😄.

Instalación de bash-it

Clonamos el repositorio y ejecutamos el script de instalación:

 git clone --depth=1 https://github.com/Bash-it/bash-it.git ~/.bash_it
 ~/.bash_it/install.sh

El script nos va a preguntar si queremos mantener el archivo ~/.bashrc o sobrescribir el archivo y crear un backup (comportamiento por default) o bien agregarlo al final de ~/.bashrc.

¿Dónde guardamos nuestras configuraciones?

Sea que necesitemos agregar nuestras propias configuraciones o rescatarlas del archivo de backup ~/.bashrc.bak es importante comprender donde tenemos que guardar cada cosa, para eso contamos la siguiente tabla:

Configuración	Ubicación
Alias	`~/.bash_it/aliases/custom.aliases.bash`
Funciones	`~/.bash_it/lib/custom.bash`
Opciones de shell	`~/.bash_it/lib/custom.bash`
Variables	`~/.bash_it/lib/custom.bash`
Autocompletados	`completion/custom.completion.bash`
Funciones agrupadas	`plugins/custom.plugins.bash`
Temas	`custom/themes/mi-tema/mi-tema.theme.bash`

¿Dónde colocar nuestros scripts?

Aquí, abro un paréntesis, ya que es importante que entendamos que si contamos con scripts más complejos, lo recomendable es que esté en algún directorio de nuestro path tal como ~/.local/bin. No sería conveniente sobrecargar el entorno, es decir, usarlo con bash-it. Si estamos en duda podemos responder algunas de estas preguntas, frente a un determinado script:

✔️ ¿Tienen su propio #!/bin/bash?

✔️ ¿Son ejecutables y no deben ser cargados en el entorno de bash?

✔️ ¿Pueden usarse desde cualquier shell?

✔️ ¿Podrían ser usados por otros scripts o tareas automatizadas?

✔️ ¿Dependen del contexto del entorno interactivo?

Si la respuesta para una o más a estas preguntas es afirmativa entonces lo mejor es excluirlos del framework bash-it.

Gestión de alias de bash-it

Podemos ver los alias habilitados con el comando siguiente:

bash-it help aliases

Ese comando nos va a mostrar en principio, los alias clasificados en dos categorías: general y custom. Si queremos ver los alias que tenemos disponibles, ejecutamos:

bash-it help aliases | less

Si queremos habilitar los alias para ansible

bash-it enable alias ansible
ansible enabled with priority 150.
cat .bash_it/enabled/150---ansible.aliases.bash 
# shellcheck shell=bash
about-alias 'ansible abbreviations'

alias ans=ansible
alias ap=ansible-playbook

En el ejemplo de arriba podemos inspeccionar los alias activados.

¿Cómo ver y activar plugins?

Las funciones son un grupo de funciones relacionados un tema.

bash-it show plugins | fgrep "[x]"
base                 [x]        miscellaneous tools

bash-it enable plugin fzf

⚠ A veces es necesario ejecutar bash-it restart para que aplique un cambio, por ejemplo la eliminación de un alias.

¿Cómo activar temas?

Bash-it cuenta con una gran cantidad de temas para darle un aspecto visual al shell

ls ~/.bash_it/themes/
90210            candy                        elixr                  liquidprompt  nwinkler                pure          slick
agnoster         clean                        emperor                luan          nwinkler_random_colors  purity        standard
atomic           codeword                     envy                   mairan        oh-my-posh              radek         tonka
axin             cooperkid                    essential              mbriggs       p4helpers.theme.bash    rainbowbrite  tonotdo
bakke            cupcake                      font                   metal         parrot                  ramses        tylenol
barbuk           demula                       gallifrey              minimal       pete                    rana          wanelo
base.theme.bash  dos                          githelpers.theme.bash  modern        powerline               redline       zitron
binaryanomaly    doubletime                   gitline                modern-t      powerline-multiline     rjorgenson    zork
bira             doubletime_multiline         hawaii50               modern-time   powerline-naked         robbyrussell
bobby            doubletime_multiline_pyonly  inretio                morris        powerline-plain         roderik
bobby-python     dulcie                       iterate                n0qorg        powerturk               sexy
brainy           duru                         kitsune                newin         primer                  simple
brunton          easy                         lambda                 norbu         pro                     sirup

Para cambiar un tema hay que editar una variable y reiniciar bash-it. Buscar en ~./.bashrc y cambiarla por el tema que nos guste (el predetermindo es bobby):

export BASH_IT_THEME='bobby'

🧩 ¿Entonces qué significa que Bash-it es un framework?

Significa que Bash-it provee un entorno estructurado y modular para personalizar tu shell Bash, con:

Elemento del framework	¿Qué ofrece?
📁 Estructura de directorios	Carpetas organizadas (`aliases/`, `plugins/`, `completion/`, `themes/`)
⚙️ Convenciones	Nombres de archivos (`custom.aliases.bash`, `custom.plugins.bash`)
🧰 Herramientas	Comandos como `bash-it enable`, `bash-it reload`
📦 Contenido reutilizable	Alias, funciones, completions y temas listos para usar o modificar
🔌 Modularidad	Activar o desactivar componentes sin tocar `.bashrc` directamente
🚀 Extensibilidad	Agregás tus propios módulos sin romper la base (`custom/` y `enabled/`)

🧪 Comparación simple

Sin framework (bash "a mano")	Con Bash-it
`.bashrc` lleno de alias y funciones	Alias y funciones separados por módulo
No hay forma de desactivar cosas fácilmente	`bash-it disable alias docker`
No hay temas de prompt	Temas configurables (`BASH_IT_THEME=...`)
Todo depende de cómo lo escribas vos	Hay convenciones y helpers

🔧 Troubleshooting

La mejor manera de descargar falsos positivos es instalar bash-it en contenedor podman o docker. Una vez que lo probamos allí y descartamoos que haya algo inherente a bash-it o al propio contendor. Luego podemos probarlo en la máquina que tiene el problema creando un usuario de prueba y realizar las siguientes pruebas.

Comparación de archivos de configuración

diff -u /home/sergio/.bashrc /home/test/.bashrc
diff -u /home/sergio/.bash_profile /home/test/.bash_profile

Verificar múltiples cargas de un determinado componente

Por ejemplo, si tenemos sourceado fzf en otro lugar además del plugin de fzf, tendrá problemas al hacer autocompletados de rutas inexistentes, y bash se colgará.

grep -r fzf ~/.bash*

Deshabilitar bash-it temporalmente

cp ~/.bashrc ~/.bash.bash-it
cp ~/.bashrc.bak ~/.bashrc
source `~/.bashrc`

Luego se puede realizar el proceso inverso si estamos en condiciones de volver a cargar bash-it.

✅ Conclusión

Bash-it un framework es decir que no es solo una colección de scripts, sino una forma organizada, modular y extensible de gestionar tu entorno de Bash, con convenciones y herramientas que te permiten escalar y mantener esa personalización de forma profesional.

Nos puede proporcinar un salto de calidad en el uso de bash. Por supuesto, ningún software es perfecto. Muchos plugins por ejemplo, tienen funcionalidades obsoletas o que no existen más. Y recordar que bash-it puede ser confiable en producción, siempre que:

✔️ Sea auditado y validado por tu equipo.
✔️ Se mantenga un control estricto sobre lo que se habilita.
✔️ Se provea capacitación a los usuarios.

Si no estás dispuesto a mantener estos controles internos, entonces sería más seguro no utilizarlo y seguir con .bashrc tradicionales o scripts controlados internamente.

De todas maneras esas tres condiciones: ¿no deberían aplicarlse a cualquier herramienta que se quiera adoptar?

Por otro lado, probar bash-it me sirvió para revisar configuraciones que venía acumulando con los años, muchas de ellas, las eliminé y otras las mejoré para adoptar las mejores prácticas de bash. Indudablemente un sysadmin experimentado podrá probablemente prescindir de bash-it, y usar una configuración ajustada a sus necesidades. Y ese es el aporte de bash-it, hacernos ver que podemos tener una configuración mucho más modular y ordenada.

¿Cuándo fue la última vez que verificaste tu entorno de shell?

🔗 Recursos recomendados para aprovechar a fondo Bash

🔖 Bash Manual (GNU)
La referencia canónica de Bash. Leé esto si querés entender cómo y por qué funciona Bash, no solo qué comandos usar.

🔖 Repositorio oficial de Bash-it
Tu punto de partida para transformar Bash en un entorno potente, modular y personal.

🔖 The Bash Hackers Wiki
Recurso mantenido por la comunidad técnica, con explicaciones brillantes sobre los aspectos más sutiles del shell.

🔖 Greg's Wiki – Bash Pitfalls
Una lista imprescindible de errores comunes en Bash, explicados por uno de los gurús del scripting shell.

🔖 Checks – ShellCheck Wiki
Una guía didáctica, profunda y sin concesiones. Ideal para quienes ya programan pero quieren escribir Bash de verdad. ShellCheck es una extraordinaria herramienta para verificar la calidad de nuestrs scrits y configuracines de bash. Aquí podemos consultar los SC codes,

Introducción a nftables y familia de direcciones

sebelk — Wed, 22 Jan 2025 18:07:44 GMT

Historia e Introducción

Antes de iptables y nftables, existía ipfwadm, una herramienta que se utilizaba en las primeras versiones del kernel de Linux para gestionar el firewall. Aunque ipfwadm sentó las bases para el firewalling en Linux, fue reemplazada debido a su limitada capacidad de manejo de tráfico y escalabilidad. Primero fue sustituida por ipchains y más tarde por el popular iptables.

Comunidad y Grupos Clave

Netfilter Project: La comunidad principal detrás de iptables y nftables. Este grupo ha sido esencial en el desarrollo, mantenimiento y promoción de herramientas de filtrado de paquetes en Linux.
Kernel Contributors: Muchos desarrolladores de kernel han colaborado en la optimización de las capacidades de firewalling en Linux, asegurando su integración fluida y eficiente.

Creación de nftables

nftables fue introducido en 2014 como el sucesor de iptables, diseñado para abordar las limitaciones de su predecesor en términos de rendimiento y escalabilidad.

Si bien eso fue hace más de 10 años, hay cambios tecnológicos que van por ascensor y otros por escalera. En ámbitos corporativos el mero hecho de reemplazar un software que es cardinal en una infraestructura, no es una tarea trivial. Ese cambio se debe a que los tiempos de vida de las distribuciones que las medianas y grandes organizaciones tienen soporte a largo a plazo. A veces es falta de urgencia y otras veces por sencilla negligencia :smile:.

Sin embargo apenas 3 datos para considerar la adopción de nftables:

RHEL9 considera iptables, ipset y ebtables herramientas depreciadas.
iptables no estará disponible en RHEL10 ni en OpenShift 4.16.
Debian Bullseye (a la fecha oldstable) ha depreciado iptables en favor de nftables.

¿Cuál es el problema de iptables?

Aunque ha sido una herramienta extraordinaria que ha servido de base para muchas soluciones de firewall, iptables presenta algunas limitaciones. A continuación, mencionamos tres de las más importantes:

Reprocesamiento completo al modificar reglas:
Cada vez que se agrega o elimina una regla, el kernel debe volver a procesar toda la lista de reglas. Este enfoque resulta ineficiente, especialmente en entornos donde se realizan cambios frecuentes o se manejan firewalls con un gran número de reglas.
Gestión complicada de rangos de direcciones IP:
Manejar rangos de direcciones IP o grandes conjuntos de direcciones en iptables puede ser tedioso y poco práctico. La herramienta ipset fue una solución ingeniosa para optimizar esta tarea, ya que permite manejar conjuntos de IPs, rangos o puertos de manera más eficiente. Sin embargo, su uso añade una capa de complejidad adicional al proceso de configuración y gestión.
Extensiones con sintaxis inconsistente:
iptables cuenta con extensiones como xtables, que amplían sus funcionalidades al incluir capacidades avanzadas como el seguimiento de conexiones o la inspección profunda de protocolos. No obstante, la sintaxis de estas extensiones no siempre es uniforme ni intuitiva, lo que puede dificultar su uso y generar confusiones en configuraciones complejas.

En cambio, desde su incorporación, nftables ha demostrado ser una herramienta eficiente y moderna para la gestión del tráfico de red en Linux. Una de sus principales innovaciones es consolidar las herramientas clásicas como iptables, ip6tables, ebtables y arptables en una única interfaz, simplificando tanto la configuración como el mantenimiento.

Conceptos claves de nftables

Contexto y Familias de Direcciones

En iptables, cada tipo de tráfico o protocolo tenía su propio comando o herramienta específica, que funcionaba de manera independiente:

Comando/herramienta	Propósito
`iptables`	Filtrar y manipular tráfico IPv4.
`ip6tables`	Filtrar y manipular tráfico IPv6.
`arptables`	Filtrar y manipular tráfico ARP.
`ebtables`	Filtrar tráfico en bridges (Ethernet frames).

Cada una de estas herramientas tenía su propia sintaxis y requería comandos separados para manejar diferentes tipos de tráfico, lo que podía ser confuso y propenso a errores.

Problemas del enfoque de iptables

Fragmentación:
- Si querías manejar tráfico IPv4 e IPv6, debías configurar reglas separadas con iptables e ip6tables, incluso si las reglas eran idénticas.
- Lo mismo ocurría si querías gestionar tráfico ARP con arptables o tráfico en bridges con ebtables.
Falta de unificación:
- Cada herramienta tenía su propia lógica, lo que aumentaba la complejidad administrativa.
- No existía una forma centralizada de gestionar tráfico que abarcase múltiples protocolos o tipos de datos.
Mantenimiento difícil:
- Las configuraciones de firewall requerían gestionar múltiples conjuntos de reglas, lo que hacía el mantenimiento y la depuración más complicados.

Cómo nftables mejoró este enfoque:

Introducción de familias: En nftables, las familias permiten manejar diferentes tipos de tráfico dentro de un mismo marco conceptual, con una sintaxis unificada.
- Familia ip: Maneja tráfico IPv4.
- Familia ip6: Maneja tráfico IPv6.
- Familia inet: Unifica IPv4 e IPv6.
- Familia arp: Maneja tráfico ARP.
- Familia bridge: Maneja tráfico L2 en bridges.
- Familia netdev: Maneja tráfico en interfaces específicas.
Unificación de reglas:
- Con la familia inet, puedes escribir reglas que funcionen tanto para IPv4 como para IPv6.
- Esto simplifica significativamente la configuración y el mantenimiento del firewall.
Menor duplicación de configuraciones: En lugar de mantener múltiples herramientas (iptables, ip6tables, arptables, ebtables), todo se gestiona con el comando nft.

Ejemplos en nftables:

# Una regla para IPv4 e IPv6
nft add rule inet filter input ip saddr 192.168.0.0/24 accept
nft add rule inet filter input ip6 saddr fc00::/7 accept

nft add table arp filter
nft add chain arp filter input { type filter hook input priority 0; }
# Permitir solicitudes ARP desde el rango 192.168.1.0/24 en eth0
nft add rule arp filter input iif "eth0" arp sip 192.168.1.0/24 arp op request accept

# Bloquear cualquier otra solicitud ARP
nft add rule arp filter input iif "eth0" arp op request drop

nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0; }
# Permitir solicitudes ARP desde direcciones MAC específicas en el bridge br0
nft add rule bridge filter forward iif "br0" ether type arp arp op request ether saddr 00:11:22:33:44:55 accept
nft add rule bridge filter forward iif "br0" ether type arp arp op request ether saddr 00:aa:bb:cc:dd:ee accept

# Bloquear cualquier otra solicitud ARP en el bridge
nft add rule bridge filter forward iif "br0" ether type arp arp op request drop

Diferencia entre las familias inet y netdev

La familia netdev puede ser una opción adecuada para implementar policing con nftables, dependiendo del escenario. Esto se debe a que la familia netdev opera en el hook ingress, lo que significa que puede evaluar el tráfico directamente en la interfaz antes de que llegue al stack de red.

Vamos a explorar por qué usar la familia netdev podría ser más apropiado para policing en algunos casos y cuándo es mejor utilizar otras familias.

Por qué usar la familia netdev para policing:

Posición temprana en el flujo del tráfico:
La familia netdev opera en el hook ingress, lo que significa que intercepta el tráfico inmediatamente después de que llega a la interfaz de red y antes de que sea procesado por el stack TCP/IP.
Esto permite implementar políticas de policing directamente en el nivel de la interfaz, evitando sobrecargar el sistema con tráfico innecesario.

Ejemplo de regla de policing en netdev:

nft add table netdev ingress
nft add chain netdev ingress mychain { type filter hook ingress priority 0; }
nft add rule netdev ingress mychain ip limit rate 10 mbps drop

Esta regla limita el tráfico IP entrante a 10 Mbps en la interfaz.
Evitar procesamiento innecesario:
Como netdev actúa antes de que los paquetes sean entregados al stack TCP/IP, los paquetes que no cumplen con las políticas son descartados sin consumir recursos adicionales del sistema.
Ideal para interfaces específicas:
Cuando el objetivo es aplicar policing solo en una interfaz específica (por ejemplo, eth0), la familia netdev es la opción más directa.
Compatibilidad con limit rate:
La familia netdev admite acciones como limit rate, que es esencial para configurar políticas de policing basadas en rates.

¿Cuándo usar netdev frente a otras familias (ip, inet)?

Criterio	Familia `netdev`	Familias `ip`/`inet`
Posición en el stack	Hook `ingress`, antes del stack TCP/IP.	Hook `prerouting`, `forward`, o `input`, después de ingresar al stack.
Eficiencia	Muy alta: paquetes descartados antes de procesarse.	Menor: los paquetes son procesados parcialmente antes de aplicar las políticas.
Tráfico inspeccionado	Solo tráfico entrante en una interfaz específica.	Tráfico en todas las interfaces (dependiendo de la configuración).
Complejidad de las reglas	Más limitada: ideal para políticas simples (policing básico).	Más flexible: soporta reglas complejas (filtrado avanzado, conntrack).
Uso típico	Policing directo en una interfaz (DDoS, límites de ancho de banda).	Filtrado y políticas basadas en estado o dirección IP.

Limitaciones de la familia netdev:

Solo para tráfico entrante:
La familia netdev opera únicamente en el hook ingress, por lo que no puedes aplicar policing en el tráfico saliente de una interfaz.
Falta de seguimiento de conexiones (conntrack):
No puedes usar estados como NEW o ESTABLISHED, ya que netdev opera antes de que el módulo conntrack pueda procesar el tráfico.
Menor flexibilidad:
Si necesitás reglas más complejas basadas en capas superiores (por ejemplo, L7 o estados de conexión), las familias ip o inet son más adecuadas.

¿Cuándo es mejor usar la familia netdev para policing?

Tráfico entrante en una interfaz específica: Cuando necesitás limitar o descartar tráfico directamente en una interfaz antes de que afecte el sistema. Ejemplo: Mitigar un ataque DDoS en eth0.
Simplicidad y eficiencia: Si solo necesitas evaluar tráfico basándote en tasas o direcciones básicas (IP, MAC).

Ejemplo práctico:

Supongamos que queremos limitar el tráfico entrante a 100 Mbps en una interfaz específica (eth0):

nft add table netdev ingress
nft add chain netdev ingress eth0_chain { type filter hook ingress priority 0; }
nft add rule netdev ingress eth0_chain limit rate 100 mbps drop

Diferencia entre la familia bridge y netdev

Dado que la tanto la tabla bridge como la tabla netdev operan en Capa 2 uno podría preguntarse, qué diferencia hay entre estas dos familias, aquí tenemos una tabla comparativa detallada entre las familias bridge y netdev en nftables:

Aspecto	Familia `bridge`	Familia `netdev`
Nivel del modelo OSI	Capa 2 (L2)	Capa 2 (L2), pero en el contexto de interfaces individuales.
Tráfico manejado	Tráfico que cruza un bridge (tramas Ethernet).	Todo el tráfico en una interfaz específica antes de llegar al stack de red.
Propósito principal	Controlar y filtrar tráfico dentro de bridges.	Filtrar tráfico en una interfaz individual (sin importar si forma parte de un bridge).
Ámbito de aplicación	Solo funciona en interfaces que forman parte de un bridge.	Funciona en cualquier interfaz (física o virtual), bridge o no.
Casos de uso típicos	- Aislar tráfico entre puertos de un bridge. - Proteger bridges contra broadcast storms, spoofing de MAC, etc. - Controlar tráfico entre VLANs en un bridge.	- Filtrar tráfico directo en una interfaz (ingress/egress). - Detectar y mitigar DDoS a nivel de interfaz. - Filtrar ARP o IPv4 antes de pasar al stack de red.
Compatibilidad con VLANs	Sí, puede filtrar tráfico basado en etiquetas VLAN (802.1Q).	No trabaja específicamente con VLANs.
Estado de conexión	No tiene integración con `conntrack`.	No tiene integración con `conntrack`.
Posición en el stack	Filtra tráfico que pasa a través de un bridge antes de ser reenviado.	Filtra tráfico directamente en una interfaz, antes de ser procesado por el stack de red.
Soporte de ARP	Sí, puede filtrar tramas ARP.	Sí, puede filtrar tramas ARP.
Soporte de IPv4/IPv6	Sí, puede inspeccionar tráfico IP encapsulado.	Sí, puede inspeccionar tráfico IP encapsulado.
Direcciones MAC	Puede filtrar según direcciones MAC de origen y destino.	Puede filtrar según direcciones MAC de origen y destino.
Uso con interfaces individuales	No, requiere que las interfaces formen parte de un bridge.	Sí, funciona en cualquier interfaz individual.
Reemplaza a...	`ebtables`.	`tc ingress` para ciertas tareas de filtrado.
Limitaciones	- Solo opera en tráfico dentro de bridges. - No puede controlar tráfico de interfaces individuales fuera del bridge.	- No tiene integración con `conntrack`. - No puede manejar tráfico reenviado entre interfaces.

Diferencias clave entre bridge y netdev:

Ámbito del tráfico manejado:
bridge: Filtra tráfico que cruza un bridge, conectando múltiples interfaces dentro del mismo dominio de difusión.
netdev: Filtra tráfico directo en una interfaz individual, antes de pasar al stack de red.
Dependencia de bridges:
bridge: Solo funciona en interfaces que son parte de un bridge.
netdev: Funciona en cualquier interfaz, sin importar si es parte de un bridge o no.
Posición en el stack de red:
bridge: Opera después de que el tráfico ha ingresado al bridge pero antes de ser reenviado a otra interfaz.
netdev: Opera antes de que el tráfico entre al stack de red del sistema operativo, en el hook ingress.
Casos de uso:
bridge: Aislar tráfico dentro del bridge, controlar VLANs, proteger contra ataques L2 como spoofing de MAC.
netdev: Inspeccionar todo el tráfico que entra o sale de una interfaz específica, ideal para mitigación temprana de DDoS o filtros basados en MAC/IP/ARP.

¿Cuándo usar cada una?

Usa la familia bridge si:

Tenemos configurado un bridge que conecta múltiples interfaces.
Necesitamos controlar tráfico entre dispositivos conectados al mismo bridge.
Queremos aislar tráfico entre VLANs o puertos del bridge.
Deseamos implementar políticas de seguridad para tráfico L2 dentro del bridge.

Usa la familia netdev si:

Queremos filtrar tráfico directo en una interfaz individual, incluso si no es parte de un bridge.
Necesitamos mitigar DDoS o ataques en el hook más temprano (ingress), antes de que el tráfico llegue al stack de red.
Deseamos inspeccionar tráfico ARP, IPv4 o IPv6 en una interfaz específica.

Ejemplos prácticos:

Con bridge:

Bloquear tráfico entre dos interfaces en un bridge:

nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 0; }
nft add rule bridge filter forward iif "eth0" oif "eth1" drop
nft add rule bridge filter forward iif "eth1" oif "eth0" drop

Permitir solo tráfico ARP en el bridge:

nft add rule bridge filter forward ether type arp accept
nft add rule bridge filter forward drop

Con netdev:

Bloquear todo el tráfico IPv4 en una interfaz específica (eth0):

nft add table netdev filter
nft add chain netdev filter ingress { type filter hook ingress priority 0; }
nft add rule netdev filter ingress iif "eth0" ip drop

Mitigar ataques DDoS limitando paquetes por segundo:

nft add rule netdev filter ingress iif "eth0" ip limit rate 1000/second drop

Entonces:

Familia bridge: Para manejar tráfico dentro de un bridge, enfocándose en L2 (direcciones MAC, VLANs, tramas Ethernet).
Familia netdev: Para filtrar tráfico temprano en una interfaz específica, independientemente de si forma parte de un bridge.

Ambas familias trabajan en L2, pero con propósitos distintos y aplicables en diferentes escenarios.

Resumen:

En iptables, no existía el concepto de familias. En su lugar, se usaban herramientas separadas para cada protocolo o tipo de tráfico (iptables, ip6tables, arptables, ebtables). Esto hacía que la configuración fuera fragmentada y menos eficiente.

Con la llegada de nftables, se introdujo el concepto de familias para unificar la gestión de diferentes tipos de tráfico, mejorando la flexibilidad, la simplicidad y el mantenimiento de las reglas de firewall. Este cambio fue una de las razones clave por las que nftables es considerado un reemplazo moderno y más avanzado.

Conocer en profundidad nftables y el concepto de las familias, tiene implicancias sumamente prácticas. Por ejemplo: ¿qué familia usarías para poder separar en una misma LAN el tráfico inalámbrico del cableado? Lo dejo para que lo pienses. 😊

Fuentes y más información

¿SELinux? Nah, dejalo en Disabled

sebelk — Mon, 25 Nov 2024 00:15:35 GMT

En el mundo real muchos sysadmins y developers en sistemas operativos de la familia Red Hat deshabilitan SELinux. "¡Es muy difícil!" dicen. En Ubuntu ni en Debian existe esa cuestión ya que en su lugar se usa AppArmor. Este post no te dará servido en bandeja como solucionar un problema, sino algo mucho más valioso, que es entender el fundamento del comportamiento de SELinux y por qué funciona la solución que vayas a aplicar.

Usamos un caso práctico: tenemos una instalación basada en Laravel, php-fpm y con nginx como web server.

Tenemos una estructura de directorio así:

> tree -L 1 /home/sergio/laravel-voyager/
/home/sergio/laravel-voyager/
├── app
├── artisan
├── bootstrap
├── composer.json
├── composer.lock
├── config
├── database
├── lang
├── package.json
├── phpunit.xml
├── public
├── README.md
├── resources
├── routes
├── storage
├── tests
├── vendor
└── vite.config.js

11 directories, 7 files

Veamos la información de SELinux para algunos archivos y directorios:

[sergio@masterk laravel-voyager]$ sudo ls -Zd public/storage /etc/nginx /home/sergio/.bashrc /root/.bashrc /usr/share/nginx/ bootstrap/cache/
[sudo] password for sergio: 
unconfined_u:object_r:user_home_t:s0 bootstrap/cache/      unconfined_u:object_r:user_home_t:s0 public/storage
 system_u:object_r:httpd_config_t:s0 /etc/nginx               system_u:object_r:admin_home_t:s0 /root/.bashrc
    system_u:object_r:user_home_t:s0 /home/sergio/.bashrc            system_u:object_r:usr_t:s0 /usr/share/nginx/

Si bien la salida es demasiado críptica, la podemos descifrar:

Archivo/Directorio	Usuario (SELinux)	Rol (SELinux)	Asignación basada en tipos (SELinux)	Rango (SELinux)	Descripción y Observaciones
bootstrap/cache/	`unconfined_u`	`object_r`	`user_home_t`	`s0`	Considerado como parte del directorio personal de un usuario. Debe ser `httpd_sys_rw_content_t` para Laravel.
public/storage	`unconfined_u`	`object_r`	`user_home_t`	`s0`	Similar a `bootstrap/cache`. Debe ser `httpd_sys_content_t` para que Laravel sirva archivos estáticos.
/etc/nginx	`system_u`	`object_r`	`httpd_config_t`	`s0`	Archivo de configuración de Nginx. Correctamente etiquetado como `httpd_config_t`. No requiere cambios.
/home/sergio/.bashrc	`system_u`	`object_r`	`user_home_t`	`s0`	Archivo personal de configuración de un usuario. Etiquetado como `user_home_t`, lo cual es correcto.
/root/.bashrc	`system_u`	`object_r`	`admin_home_t`	`s0`	Archivo de configuración del usuario `root`. Etiquetado como `admin_home_t`, lo cual es correcto.
/usr/share/nginx/	`system_u`	`object_r`	`usr_t`	`s0`	Etiquetado como `usr_t`, que es genérico. Debe ser `httpd_sys_content_t` si Nginx sirve contenido estático aquí.

Descripción de los campos

Concepto	Descripción	Ejemplo
Usuario (SELinux)	Define el usuario de SELinux asociado al recurso.	`system_u`: Archivo gestionado por el sistema. `unconfined_u`: Archivo de un usuario sin restricciones.
Rol (SELinux)	Define el rol asignado al recurso.	Usualmente es `object_r` para archivos regulares y directorios.
Asignación basada en tipos	Determina qué procesos o aplicaciones pueden interactuar con un recurso.	`httpd_sys_rw_content_t`: Permite lectura/escritura por parte del servidor web. `httpd_sys_content_t`: Permite solo lectura por parte del servidor web. `user_home_t`: Para directorios o archivos en `/home`.
Rango (SELinux)	Se usa para configuraciones de seguridad MLS o TE (usualmente `s0` en configuraciones estándar).	Normalmente no requiere ajustes en configuraciones básicas.

Ahora bien, hay varios tipos de políticas en cuanto a funcionalidades que se pueden aplicar en SELinux, la que se usa en general es targeted. El tipo de política targeted significa que determinados servicios se ejecutan de manera confinada, es decir limitada para realizar solamente determinadas acciones más allá de los permisos ordinarios.

Y es importante enfatizar que cuando usamos targeted el campo que más nos tiene que interesar de un contexto es el "Type Enforcement". En general no prestaremos demasiada atención al resto de los campos.

Lo más importante para entender es que las reglas de SELinux tienen sujetos y objetos. El contexto o etiqueta del objeto podría no permitir que el sujeto realice una determinada acción al sujeto, y es allí cuando se produce un error. Dicho error tiene por objetivo proteger al sistema. En este ejemplo los sujetos son nginx y php-fpm y los objetos son los directorios bootstrap/cache y public/storage (y sus respectivos contenidos).

Por ejemplo, nginx sería el sujeto y con el siguiente comando vemos el contexto del proceso:

> ps -C nginx,php-fpm -Z
LABEL                               PID TTY          TIME CMD
system_u:system_r:httpd_t:s0        898 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1118 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1119 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1120 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1121 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1122 ?        00:00:00 php-fpm
system_u:system_r:httpd_t:s0       1451 ?        00:00:00 nginx
system_u:system_r:httpd_t:s0       1452 ?        00:00:00 nginx
system_u:system_r:httpd_t:s0       1453 ?        00:00:00 nginx

Pero habrá problemas...

La cuestión es que tanto nginx como php-fpm se ejecutan con la asignación de tipo (TE) httpd_t y la TE que tienen directorior como bootstrap/cache y public/storage es user_home_t.

Con el siguiente comando podemos verificar qué cosas puede hacer el dominio httpd_t en el contexto del objeto que tiene el tipo de asignación user_home_t:

> sesearch -s httpd_t -A -t user_home_t
allow daemon user_home_t:file { append getattr };
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow httpd_t file_type:dir { getattr open search };
allow httpd_t file_type:filesystem getattr;
allow httpd_t user_home_t:file map; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr ioctl lock open read search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_enable_homedirs ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:dir { getattr open search }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:file { getattr ioctl lock open read }; [ httpd_read_user_content ]:True
allow httpd_t user_home_type:lnk_file { getattr read }; [ httpd_enable_homedirs ]:True

Cada regla tiene:

El tipo de regla ( allow )
El sujeto de la regla ( httpd_t )
El contexto y tipo del objeto ( user_home_t:file )
Los permisos (append y getattr)

¡No hay ninguna regla que permita la modificación total del contenido del archivo ni la creación de archivos en la carpeta (por ejemplo, el permiso write)!. Esto significa que, de manera predeterminada, servicios como apache o nginx no tienen permiso para escribir en los directorios home de los usuarios. Y por ese motivo hay cosas que fallarán, sin importar los permisos ni el usuario...

Por lo tanto los directorios public/storage y bootstrap/cache y su contenido necesitan otro contexto para que Laravel funcione correctamente cuando está ubicado en un subdirectorio de /home. Mirando la documentación podemos ver que httpd_sys_content_t y httpd_sys_rw_content son respectivamente los apropiados para esos directorios y su contenido:

httpd_sys_content_t

- Set files with the httpd_sys_content_t type, if you want to treat the files as httpd sys content.

Paths:
     /srv/([^/]*/)?www(/.*)?,  /var/www(/.*)?,  /etc/htdig(/.*)?,   /srv/gallery2(/.*)?,   /var/lib/trac(/.*)?,   /var/lib/htdig(/.*)?,
     /var/www/icons(/.*)?,     /usr/share/glpi(/.*)?,     /usr/share/htdig(/.*)?,     /usr/share/drupal.*,     /usr/share/z-push(/.*)?,
     /var/www/svn/conf(/.*)?,         /usr/share/icecast(/.*)?,          /var/lib/cacti/rra(/.*)?,          /usr/share/ntop/html(/.*)?,
     /usr/share/nginx/html(/.*)?,      /usr/share/doc/ghc/html(/.*)?,      /usr/share/openca/htdocs(/.*)?,      /usr/share/selinux-pol‐
     icy[^/]*/html(/.*)?

httpd_sys_rw_content_t

- Set files with the httpd_sys_rw_content_t type, if you want to treat the files as httpd sys read/write content.

Paths:
     /etc/rt(/.*)?,  /etc/glpi(/.*)?,  /etc/horde(/.*)?,  /etc/drupal.*,  /etc/z-push(/.*)?,  /var/lib/svn(/.*)?,   /var/www/svn(/.*)?,
     /etc/owncloud(/.*)?,    /var/www/html(/.*)?/uploads(/.*)?,    /var/www/html(/.*)?/wp-content(/.*)?,   /var/www/html(/.*)?/wp_back‐
     ups(/.*)?,  /var/www/html(/.*)?/sites/default/files(/.*)?,  /var/www/html(/.*)?/sites/default/settings.php,  /etc/mock/koji(/.*)?,
     /etc/nextcloud(/.*)?,       /var/lib/drupal.*,      /etc/zabbix/web(/.*)?,      /var/lib/moodle(/.*)?,      /var/log/z-push(/.*)?,
     /var/spool/gosa(/.*)?,   /etc/WebCalendar(/.*)?,   /usr/share/joomla(/.*)?,   /var/lib/dokuwiki(/.*)?,    /var/lib/owncloud(/.*)?,
     /var/spool/viewvc(/.*)?, /var/lib/nextcloud(/.*)?, /var/lib/pootle/po(/.*)?, /var/lib/phpMyAdmin(/.*)?, /var/www/moodledata(/.*)?,
     /srv/gallery2/smarty(/.*)?,      /var/www/moodle/data(/.*)?,      /var/lib/graphite-web(/.*)?,      /var/log/shibboleth-www(/.*)?,
     /var/www/gallery/albums(/.*)?,  /var/www/html/owncloud/data(/.*)?, /var/www/html/nextcloud/data(/.*)?, /usr/share/wordpress-mu/wp-
     content(/.*)?, /usr/share/wordpress/wp-content/upgrade(/.*)?, /usr/share/wordpress/wp-content/uploads(/.*)?, /var/www/html/config‐
     uration.php

De modo que esos son los contextos que tendrías que aplicar a esos directorios y sus contenidos. El resto, si sos administrador o desarrollador de Linux con algo de experiencia es anecdótico.

Fuentes y más recursos

Página del manual de httpd_selinux
Ventajas de usar SELinux
Desactivación de SELinux
Página del manual de booleans (concepto importante que complementan a las reglas de las políticas de SELinux)

¿Qué significa en Linux que todo es archivo?

sebelk — Mon, 13 May 2024 21:14:03 GMT

En un viejo artículo, hay una presentación en la que mencioné una frase bastante habitual en el mundo Unix/Linux: «Todo es archivo». Vamos a explicar qué significa realmente esa frase.

Todo es archivo

En realidad, ese dicho no es del todo correcto. Sin embargo, proviene de lo que hoy tal vez podríamos llamar la filosofía Unix. Probablemente, nadie dijo esa frase de manera literal en los primeros años de esa familia de sistemas operativos. Aun así, ideas de ese estilo estaban en la mente desde los comienzos y en los trabajos de por ejemplo, Bill Joy (pionero de TCP/IP). Linus Torvalds, no estuvo ausente en esta discusión. Y mucho más cerca en el tiempo, Lennart Poettering, retoma esa idea una vez más para defender el trabajo realizado en systemd. Por si no se dieron cuenta dice Poettering la interfaz de cgroups están expuesta en un pseudo-sistema de archivos...

Sin embargo, es más apropiado decir que todo es un descriptor de archivo o que todo puede tener un descriptor de archivo. En Linux un descriptor de archivo es un identificador único de proceso para un archivo u otro recurso de entrada o salida. Por ejemplo, no existe necesariamente un archivo para una interfaz de red. Sin embargo, existen sockets relacionados con ellas.

En el siguiente ejemplo podemos ver los descriptores de archivos para la dirección ip 127.0.0.1 de la interfaz lo.

sudo lsof -n -i@127.0.0.1
COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd   1337 chrony    5u  IPv4   8171      0t0  UDP 127.0.0.1:323 
cupsd     1538   root    7u  IPv4  14727      0t0  TCP 127.0.0.1:ipp (LISTEN)
qemu-syst 1774   qemu   32u  IPv4  19480      0t0  TCP 127.0.0.1:rfb (LISTEN)
syncthing 2620 sergio   19u  IPv4  22825      0t0  TCP 127.0.0.1:8384 (LISTEN)

En este caso, vemos los descriptores de archivos de lectura y escritura 5u, 7u, 32u y 19u.

Para ver la relación entre descriptores y sockets podemos hacer un ping a una determinada dirección ip:

ping -c 10000 9.9.9.9 &> /dev/null

Si buscamos los descriptores de archivos con lsfd, mostrará el siguiente resultado:

lsfd -p 914323 -Q '(FD >= 0)' 
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping    914323 sergio     0 rw-D--    CHR  pts:6    36        9 /dev/pts/6 
ping    914323 sergio     1 -w----    CHR  mem:3    34        4 /dev/null
ping    914323 sergio     2 -w----    CHR  mem:3    34        4 /dev/null
ping    914323 sergio     3 rw---m   PING sockfs     9 30437500 state=close id=35 laddr=0.0.0.0
ping    914323 sergio     4 rw---- PINGv6 sockfs     9 30437501 socket:[30437501]

Analicemos cada descriptor de archivo:

0: Es la "standard input" que apunta a una pseudoterminal (dispositivo de caracteres), al tratarlo como un archivo tiene permisos: de lectura y escritura. Usa un sistema de archivos y como tal también maneja inodos.
1: Es la "standard output" que apunta a /dev/null. Solamente tiene permisos de escritura, el sistema de archivos proviene de la memoria principal y tiene permisos solamente de escritura.
2: Es el "standard error" que apunta también a /dev/null.
3: Apunta a un socket de tipo IPv4, y tiene permisos de lectura y además está siendo utilizado por un evento de multiplexación.
4: Finalmente tenemos el descriptor de 5 que apunta a un tipo de socket que usa IPv6.

Dentro del directorio /proc podemos ver que los descriptores 1 (salida estándar) y 2 (error estándar) se redirigen al archivo /dev/null, mientras tanto, 3 y 4 apuntan a sockets:

ls -l /proc/914323/fd
total 0
lrwx------ 1 sergio sergio 64 may 19 17:33 0 -> '/dev/pts/6 (deleted)'
l-wx------ 1 sergio sergio 64 may 19 17:33 1 -> /dev/null
l-wx------ 1 sergio sergio 64 may 19 17:33 2 -> /dev/null
lrwx------ 1 sergio sergio 64 may 19 17:33 3 -> 'socket:[30437500]'
lrwx------ 1 sergio sergio 64 may 19 17:33 4 -> 'socket:[30437501]'

Podemos hacer otra prueba, en este caso usaremos solamente ping sobre ipv6 y en lugar de redireccionar a /dev/null, lo haremos redirigiendo stdin y stderr a archivos regulares distintos:

ping6 -c 10000 ::1 > out.txt 2> errors.txt &

Aquí solamente usará un socket (ya que no usa ipv4):

lsfd -p 926928 -Q '(FD >= 0)'
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping6   926928 sergio     0 rw----    CHR  pts:7    36       10 /dev/pts/7
ping6   926928 sergio     1 -w----    REG   0:34    52 38207299 /tmp/out.txt
ping6   926928 sergio     2 -w----    REG   0:34    52 38207300 /tmp/errors.txt
ping6   926928 sergio     3 rw---- PINGv6 sockfs     9 31193485 state=close id=44 laddr=::

¿Qué sucede si se borra /tmp/errors.txt?

lsfd -p 926928 -Q '(FD >= 0)'
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping6   926928 sergio     0 rw----    CHR  pts:7    36       10 /dev/pts/7
ping6   926928 sergio     1 -w----    REG   0:34    52 38207299 /tmp/out.txt
ping6   926928 sergio     2 -w-D--    REG   0:34    52 38207300 /tmp/errors.txt
ping6   926928 sergio     3 rw---- PINGv6 sockfs     9 31193485 state=close id=44 laddr=::

Bueno, veremos que el archivo aparece con el flag D indicando que borró del respectivo sistema de archivos.

Por lo tanto, si bien literalmente no todo es archivo, podemos afirmar que en general podríamos mediante los descriptores de archivos establecer un puente entre un proceso y los recursos a los que está accediendo. En definitiva, un descriptor de archivos, permite al proceso comunicarse con el recurso subyacente de manera eficiente y uniforme, independientemente de si el recurso es un archivo en el sistema de archivos, un dispositivo de hardware o un socket de red.

Enlaces útiles

OpenSSH, X11Forwarding y Wayland

sebelk — Sun, 26 Apr 2020 11:33:41 GMT

Digamos que hay tres maneras de levantar acceder a la interfaz gráfica de un Linux remoto:

Photo by JJ Ying on Unsplash

Accediendo a todo el escritorio
Accediendo a una aplicación en particular
Conectándose a un administrador de login remoto

Una de las maneras habituales hasta hace relativamente pocos años era abrir aplicaciones gráficas de manera individual usando ssh usando la funcionlidad llamada X11Forwarding.

¿Qué es X11 Forwarding?

La mayoría estará de acuerdo con lo poco aconsejable que es usar Xorg en un servidor. Una alternativa menos riesgosa es instalar un programa cliente de X. En ese caso podemos usar el redireccionamiento X11 de ssh. De esta manera los datos viajan cifrados por la red y además, establecerá la variable DISPLAY en la máquina en la cual estamos usando el cliente ssh. Una de las cosas más ventajosas que tiene el redireccionamiento X es que host remoto no necesita un servidor Xorg real. El programa xauth en el host remoto simula que hay un servidor local ante sus programas clientes pero redireccionando la imagen en la pantalla del cliente ssh. Esto tiene un costado problemático: estamos abriendo un canal desde el servidor ssh al cliente ssh. Por eso es muy importante segurizar el servidor para minimizar los riesgos. El protocolo X es muy antiguo y como tal era muy laxo en cuando a la seguridad, de este modo imponía pocas restricciones en el acceso por red. Durante el paso de los años el Xorg se ha esforzado por reducir esos inconvenientes. De hecho cuando una aplicación remota se abre por ssh X la considera un cliente no confiable, impidiendo el acceso a recursos de clientes confiables.

El Problema

El X Window System o X11 nació en el año 1987, y en los comienzos de Linux se usaba XFree86, una implementación libre (aunque con una licencia considerada problemática). Pero en 2004 nació Xorg como un fork de XFree86 y desde ese momento reemplazó en general a su antecesor en el reinado de las interfaces gráficas de Linux. Sin embargo, algunas distribuciones en la actualidad ofrecen de manera predeterminada Wayland en lugar de Xorg. Kristian Høgsberg un desarrollador de Xorg y de gráficos del kernel Linux creó Wayland en 2008. El propósito de Wayland es proveer una alternativa que sea más fácil para desarrollar y mantener que Xorg. Aquí tenemos que recordar que es un compositor: se trata de un software que utiliza buffers de memoria para que la imagen tenga mejor calidad y de paso poder proporcionar ciertos efecto. Wayland es un protocolo para que un compositor pueda comunicarse con programas clientes y además una implementación de dicho protocolo. De esta manera, se dejan las funcionalidades esenciales para que las ejerzan los clientes.

Es así como llegamos a que Wayland tampoco tiene como propósito ofrecer el renderizado de aplicaciones remotas, es decir, no existe de manera predeterminada algo como WaylandForwarding. Los desarrolladores de Wayland dicen que podrías en cambio:

Usar un servidor de renderizado sobre Wayland con soluciones ya existentes ( vnc, rdp, Xorg) o desarrollar uno nuevo.
Usar y/o desarrollar un protocolo de renderizado remoto en un compositor de wayland.
Usar y/o desarrollar un compositor remoto aislado o una parte de un compositor de escritorio

GNOME está trabajando con el renderizado de aplicaciones remotas en Wayland y KDE aparentemente también con en su proyecto Plasma.

Una tubería como camino

Waypipe programa desarrollado por M. Stoeckl para eñ Google Summer of Code de 2019: es un proxy para clientes de Wayland. Lo interesante es que puede usar ssh para hacer un redireccionamiento de una manera muy sencilla:

waypipe ssh usuario@servidorssh

Ese comando ejecuta dos instancias, una en el cliente y otra en el servidor (es decir debe estar instalado en ambos hosts). La instancia de waypipe que se ejecuta en el servidor ssh simula ser un compositor wayland, y usa un socket Unix para que los programas puedan conectarse. El resultado final es que la aplicación remota se muestra en la pantalla local de wayland. Las pruebas que realicé sobre CentOS8 como servidor wayland y cliente ssh frente a un servidor Fedora 31 han sido satisfactorias.

Más que mil palabras

¿Querés ver un video con waypipe en acción? Lo podés ver a continuación:

Fuentes de Consulta y Más Recursos

Elige Tu Propio Prompt

sebelk — Tue, 26 Nov 2019 11:23:15 GMT

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

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.¹

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 install

Recargamos la configuración de la shell

# . ~/.bashrc

¡Listo!

Configuración de sexy-bash-prompt

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

Aquí vemos un ejemplo de configuración personalizada:

powerline

Powerline² 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:

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:

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 Pureline³, que ofrece un prompt al estilo de Powerline pero escrito en bash.

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:

source ~/.bashrc

Configuración de PureLine

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

Quedaría así:

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

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 parcheada⁴.

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.

Borrar configuraciones de red

sebelk — Wed, 09 Oct 2019 21:42:29 GMT

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 :)

Diagrama de netfilter/iptables

sebelk — Thu, 26 Sep 2019 18:11:49 GMT

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?

Iptables Tutorial 1.2.2