Introducción

Ya vimos como convertir una una configuración en Vim script a Lua. Ese tipo de configuración es más flexible y reutilizaable. Ahora vamos por el paso final que es migrar de vim-plug a lazy.vim.

¿Qué es lazy.nvim?

Es un gestor de plugins escrito en Lua que sabe sacar provecho de la arquitectura moderna de Neovim.

¿Qué ventajas y funcionalidades tiene lazy.vim?

El gestor lazy.nvim se destaca por su rendimiento, usabilidad/UX y el modo de gestionar de plugins.

En la siguiente tabla vemos como se destaca en cuento a Rendimiento:

📝 ¿Qué y dónde cachea lazy.nvim?

¿Por qué migrar de vim-plug?

Los números duros

La tabla de arriba muestra que

• Si bien ambos son repositoorios populares, vim-plug (que es un proyecto más longevo) supera a lazy.nvim en este aspecto.
• Ambos proyectos están activos.
• El repo lazy.nvim tiene más colaboradores.

En este aspecto salen bastante empatados.

Aspectos ventajosos desde el punto de vista técnico

• Para sysadmins: Rendimiento y carga mínima: se puede configurar de manera natural los plugins que realmente necesitás en tu entorno (por ejemplo, se pueden configurar plugins para que solamente se carguen al usar ssh) y una configuración más clara: todo en Lua, más fácil de mantener con backups dotfiles/scripts.
• Para desarrolladores: Carga por filetype y herramientas específicas y mayor control sobre dependencias y versiones.

Conceptos fundamentales para usar lazy

1. Comentarios

-- Esto es un comentario

2. Variables

local nombre = "Neovim"
local numero = 14

3. Tablas (como diccionarios o listas)

local opciones = {
  number = true,
  relativenumber = true
}

4. Funciones

local function saludar()
  print("Hola desde Lua")
end

5. Requiriendo otros archivos (modularización)

require("usuario.options")
require("usuario.plugins.lazy")

Ejemplo concreto de migración

Usamos como punto de partida el archivo ~/.config/nvim/plugins.vim del post anterior:

"Plugins (Plug)
call plug#begin('~/.vim/plugged')

Plug 'itchyny/lightline.vim'
Plug 'nyngwang/NeoTerm.lua'
Plug 'NLKNguyen/papercolor-theme'

call plug#end()

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>

Clonar el repo

git clone https://github.com/folke/lazy.nvim.git ~/.local/share/nvim/lazy/lazy.nvim

Prepara el entorno

Creamos un directorio para la configuración de los plugins y otro para la configuración de lazy.nvim:

mkdir ~/.config/nvim/lua/lplugins  # Aquí estarán los archivos de configuración de los plugins
mkdir ~/.config/nvim/lua/config/

Configuración inicial

Partimos de este archivo:

-- Cargamos módulos

local commands = require('utils.commands')
local extracommands = require('utils.extracommands')
local keymaps = require('keymaps')
local opciones = require('opciones')

-- Mantenemos por ahora la configuración de plugins en Vim script
vim.cmd('source ~/.config/nvim/plugins.vim')

Y hacemos las siguientes modificaciones:

-- Cargamos módulos

local commands = require('utils.commands')
local extracommands = require('utils.extracommands')
local keymaps = require('keymaps')
local opciones = require('opciones')

-- Mantenemos por ahora la configuración de plugins en Vim script
-- vim.cmd('source ~/.config/nvim/plugins.vim')
-- require("config.lazy")

¿Qué hicimos? Deshabilitar vim-plug y por ahora dejar comentada la línea que llamará al archivo ~/.config/nvim/lua/config/lazy.lua.

Luego en dicho archivo pondremos lo siguiente:

-- Bootstrap lazy.nvim
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  local lazyrepo = "https://github.com/folke/lazy.nvim.git"
  local out = vim.fn.system({ "git", "clone", "--filter=blob:none", "--branch=stable", lazyrepo, lazypath })
  if vim.v.shell_error ~= 0 then
    vim.api.nvim_echo({
      { "Failed to clone lazy.nvim:\n", "ErrorMsg" },
      { out, "WarningMsg" },
      { "\nPress any key to exit..." },
    }, true, {})
    vim.fn.getchar()
    os.exit(1)
  end
end
vim.opt.rtp:prepend(lazypath)

-- Make sure to setup `mapleader` and `maplocalleader` before
-- loading lazy.nvim so that mappings are correct.
-- This is also a good place to setup other settings (vim.opt)
vim.g.mapleader = " "
vim.g.maplocalleader = "\\"

-- Setup lazy.nvim
require("lazy").setup({
  spec = {
    -- import your plugins
    { import = "lplugins" },
  },
  -- Configure any other settings here. See the documentation for more details.
  -- colorscheme that will be used when installing plugins.
  install = { colorscheme = { "habamax" } },
  -- automatically check for plugin updates
  checker = { enabled = true },

Explicación

require("lazy").setup({ ... })

Es la función principal que inicia y configura los plugins en lazy.nvim.

spec =

Es el campo que indica la especificación de los plugins. Es el lugar para definir qué plugins cargar.

spec = {
  { import = "lplugins.ui" },
}

• Cada { import = "..." } carga los plugins definidos en otros archivos lua.

• En este caso, usamoos una configuración modular:

• ~/.config/nvim/lua/lplugins/ui.lua tendrá la especificación del plugin papercolor-theme.

• ~/.config/nvim/lua/lplugins/terminal.lua tendrá las especificaciones de los plugins lightline y Neoterm.

install = { colorscheme = { "habamax" } }

Establece un esquema de colores que se aplicará automáticamente en la interfaz del gestor de plugins.

checker =

Activa el verificador automático de actualizaciones. Cabe aclarar que esta configuración no los no los actualiza automáticamente, pero te avisa para que los actualices mediante el comando en modo ex (:Lazy update).

En la configuración de partida teníamos solamente 3 plugins, pero decidimos dividirlos en dos categorías, a medida que vamos instalando más plugins podemos crear más archivos lua para clasificarlos.

Especificaciones de plugins

Todos los archivos donde clasificás plugins deben tener la keyword return para que cada uno de ellos debe devuelva una tabla Lua con los plugins que querés que lazy.nvim cargue desde esos archivos.

La siguiente es una plantilla de archivo en la cual se especifican plugins:

return {
  {
    "autor/repositorio",  --  Reemplazá con el nombre del autor y nombre del repositorio
    -- lazy = false,         --  true para carga diferida, false para cargar al inicio
    -- priority = 1000,      --  Opcional. Útil para temas de colores
    -- event = nil,          --  Reemplazá con evento si usás lazy = true (ej: "BufReadPre")
    -- cmd = nil,            --  Reemplazá si querés cargar al ejecutar un comando
    -- dependencies = {},    --  Lista de plugins que este necesita (si aplica)
    -- config = function()
      -- Poné acá la configuración del plugin
    -- end
  }
}

Para echar un poco de 💡 a esta cuestión de los campos:

Vamos a los ejemplos concretos 💪

Archivo ui.lua

return {

  {
    "NLKNguyen/papercolor-theme",
    priority = 1000,  -- para que se cargue antes que otros
    lazy = false,     -- para que se cargue en el arranque
    config = function()                                                                                                                                       
      vim.cmd("colorscheme PaperColor")
    end
  }
}

Esto significa:

» Devuelvo una lista (tabla) con un solo plugin. Este plugin es NLKNguyen/papercolor-theme y quiero que se cargue al inicio, con prioridad alta, y que cuando se cargue, aplique el esquema de colores PaperColor.

Archivo terminal.lua

return {
  { -- Plugin 1: lightline.vim
    "itchyny/lightline.vim",
    config = function()
      vim.g.lightline = {
        colorscheme = 'solarized', -- <- podés cambiar por "jellybeans","OldHope", "wombat", "PaperColor", etc.
      }
    end,
  }, -- Separador de items en la lista

  { -- Plugin 2: NeoTerm.lua
    "nyngwang/NeoTerm.lua",
    config = function()
      require("neo-term").setup {
        exclude_filetypes = { "oil" }, -- evita que se use en buffers del tipo "oil"
      }

      -- Atajos de teclado:
      vim.keymap.set("n", "<F4>", ":NeoTermToggle<CR>", { silent = true })              -- F4 en modo normal: alterna el terminal
      vim.keymap.set("t", "<F4>", "<C-\\><C-n>:NeoTermToggle<CR>", { silent = true })   -- F4 en modo terminal: lo mismo
      vim.keymap.set("t", "<Esc>", "<C-\\><C-n>:NeoTermEnterNormal<CR>", { silent = true }) -- Esc en terminal: pasa a modo normal
    end
  }, -- Separador final, no es obligatorio pero conveniente
}

Este archivo configura dos plugins:

• lightline.vim: para una línea de estado personalizada.
• NeoTerm.lua: para trabajar con terminales flotantes o integrados, y define atajos con F4 y Esc para manejarlos fácilmente.

Habilitar lazy.nvim

Ya estamos casi listos, solamente falta quitar el comentario en el archivo ~/.config/nvim/init.lua:

require("config.lazy")

Eso es todo, la próxima vez, al entrar al editor, lazy.nvim se encargará de instalar los plugins especificados.

Es importante ejecutar el comando :checkhealth lazy el cual hará un diagnóstico de la instalación y configuración:

Sacándole provecho a lazy.nvim

Vamos a instalar el plugin which-key el cual sirve para mostrar de una manera amigable los atajos de teclado configurados.

Editamos el archivo de configuración ~/.config/nvim/lua/lplugins/ui.luasiguiendo la plantilla mencionada anteriormente:

return {

  {
    "NLKNguyen/papercolor-theme",
    priority = 1000,  -- para que se cargue antes que otros
    lazy = false,     -- para que se cargue en el arranque
    config = function()                                                                                                                                       
      vim.cmd("colorscheme PaperColor")
    end,                  
  },                      

{                         
  "folke/which-key.nvim", 
  event = "VeryLazy",     
  opts = {},              
  keys = {
    { "<leader>ff", "<cmd>edit ~/.config/nvim/init.lua<cr>", desc = "Edit init.lua" },
    { "<leader>fr", "<cmd>e #<cr>", desc = "Open recent file" },
    { "<leader>tt", "<cmd>terminal<cr>", desc = "Open terminal" },
    { "<leader>?", function() require("which-key").show({ global = false }) end, desc = "Buffer Local Keymaps" },
    { "<leader>q", "<cmd>q<cr>", desc = "Quit" },
    { "<leader>w", "<cmd>w<cr>", desc = "Save" },
    -- Grupos visibles (aunque no hacen nada por sí mismos)
    { "<leader>f", name = "+file" },
    { "<leader>t", name = "+terminal" },
  },
}

}

Este plugin sirve para que al teclar:

• Espacioff Abrirá el archivo /.config/nvim/init.lua.
• Espaciofr Abrirá el archivo más reciente.

... y así con cada uno de los atajos definidos, pero además veremos una ayuda en pantalla.

Vamos a verlo en acción:

• 1 Al presionar y ....
• 2 Muestra que es Yank que en el contexto de Vi/Vim/Neovim es copiar...
• 3 Aparecen automágicamente las teclas que pueden acompañar a este comando 💪

Y listo.... el resto es cuestión de usar la UI de Lazy, y familiarizarse con sus subcomandos en modo Ex.

Conclusión

• vim-plug sigue siendo una opción robusta y popular, especialmente para usuarios de Vim clásico o entornos donde se necesita algo probado y ampliamente documentado.

• Sin embargo, lazy.nvim es una solución moderna y centrada en Neovim, con alta participación comunitaria y buena agilidad en el mantenimiento. Ideal para setups nuevos o si des#eas aprovechar la asincronía y mejoras de Lua en Neovim.

Siempre que puedas

• Consultá el README oficial
• Buscá ejemplos en GitHub o Dotfiles de otros usuarios
• Explorá el código fuente si sabés Lua

Estos tres artículos no han servidor para comenzar a usar Neovim, modernizar la configuración y utilizar un gestor de plugins nativo en Lua. wSiempre que agregues un plugin, revisa su README y especifica las dependencias manualmente si no estás seguro. Lazy puede resolver muchas automáticamente, pero declararlas te da más control y claridad.

Detrás de la fachada antigua, Neovim es un editor que adaptó su arquitectura a los nuevos tiempos.

¡Felicitaciones si llegaste hasta acá?

Fuentes y más recursos

• ¿Cómo es el proceso de arranque de Neovim?
• ¿Cómo funciona y se usa Lazy.mvim
• How Neovim helped improve my productivity - Kaustubh Patange - Medium

Requisitos

1. Curiosidad. Es la condición más importante para leer este post. Si la tendrás, con algo de esfuerzo sumado a algo de tiempo podrás aprender Vim, Neovim, etcº.
2. Conocimientos básicos o intermedios de Vim y haber leído el post anterior.
3. Conocimientos básicos de vim-plug.

Repaso de conceptos importantes

En el post anterior vimos como un usuario de Vim puede comenzar a Neovim. En el presente artículo haremos la transición de Vim script a Lua. Ok, booting the post 😄 ...

Recordemos que Vim usa Vim script (aka VimL) como lenguaje de scripting nativo. Es un lenguaje específico que permite personalizar y extender su funcionalidad. Existe en dos formas: el Vim script tradicional (también llamado "legacy script") y Vim9script (introducido en Vim 9.0), que ofrece mejor rendimiento y una sintaxis más moderna. Sin embargo Vim9script ni siquiera se usa de manera predeterminada en Vim 9.

Lua, en cambio, es un lenguaje de programación ligero, de alto nivel y multiparadigma, diseñado principalmente para ser incorporado en aplicaciones. Se destaca por su simplicidad, eficiencia y portabilidad. Neovim incorporó Lua como lenguaje de scripting alternativo, lo que ha ganado popularidad debido a su mejor rendimiento y facilidad de uso comparado con Vim script tradicional.

Cabe remarcar que Neovim usa una implementación de Lua llamada LuaJIT. LuaJIT es capaz de compilar código Lua a código máquina nativo durante la ejecución, lo que resulta en un rendimiento significativamente superior al intérprete estándar de Lua. LuaJIT es ampliamente reconocido por su alta velocidad, siendo en muchos casos comparable al rendimiento de lenguajes compilados como C. En el contexto de Neovim, LuaJIT permite que los scripts escritos en Lua se ejecuten con un rendimiento muy superior la de Lua estándar.

Diferencia de idiosincrasia:

• Vim script: scripting lineal, global y directo. Bueno para pequeños ajustes, pero difícil de escalar.
• Lua (Neovim): lenguaje estructurado, orientado a modularizar, reusar y escalar. Favorece el uso de variables locales, tablas y funciones que mejoran el mantenimiento de la configuración.

Entonces:

• Neovim usa LuaJIT para ejecutar configuraciones en Lua de forma rápida.
• Casi todas las instalaciones modernas de Neovim usan LuaJIT por defecto.
• Esto significa que los scripts y configuraciones Lua en Neovim corren a velocidades cercanas al código nativo.

Ventaja clave: Permite que Neovim con Lua sea mucho más rápido que Vim script o incluso Vim9script en muchos casos.

3 conceptos esenciales — lo mínimo que siempre debés recordar

Si entendés estos 3 conceptos, podés crear y mantener cualquier configuración básica y muchas avanzadas.

¿Qué es una tabla y qué no en la configuración de Neovim (Lua)

Tablas 🆗:

• vim.g
• vim.opt / vim.o
• vim.tbl_keys(...)
• Configuraciones de plugins
• Listas/patrones

No son tablas ⚠ :

• Funciones
• Comandos ejecutados
• Strings, números, booleanos

El podio de las tablas madres más importantes en Neovim

Estas son las tres tablas raíz (madre) más importantes del entorno Lua en Neovim:

🏅 vim

Es la tabla principal y núcleo del entorno Lua en Neovim. Contiene todo lo necesario para interactuar con el editor:

• Subtablas como vim.api, vim.cmd, vim.opt, vim.g, vim.fn, etc.
• Siempre disponible sin necesidad de importar.

🥈 _G

Es la tabla global del lenguaje Lua. Desde aquí podés definir funciones o variables globales accesibles desde cualquier parte de tu configuración:

• _G.mi_funcion = function() ... end
• También contiene vim como una de sus claves.

🥉 package (de Lua)

Maneja los módulos cargados por require. Es crucial para modularizar tu configuración:

• package.loaded permite ver y recargar módulos.

Nota

Tablas como vim.api, vim.opt, vim.g son importantes, pero no son madres: viven dentro de vim. Lo mismo aplica para math, string, table, etc., que viven en _G.

→ Estas 3 (vim, _G, package) forman la base del entorno ejecutable de cualquier configuración Neovim moderna en Lua.

Subtablas más importantes

Diccionario cruzado Vim script / Lua

Comparativa de conceptos clave: Vim script vs Lua

Ejemplo de migración Vim script → Lua

Bueno, con la teoría suficiente, ✋✋ a la obra 😉. Supongamos que tenemos esta configuración de archivo init.vim:

set tabstop=4
set nf+=alpha

nnoremap ñ :wq<CR>

command -nargs=+ Silent execute 'silent !<args>' | redraw!
command Nbuild execute 'w | Silent nikola build'

filetype plugin on
runtime plugins.vim
colorscheme PaperColor

Es un archivo pequeño, pero que sirve de punto de partida para moverse a una configuración en Lua.

Crear el entorno para Neovim

Como vimos en el post anterior, mi recomendación es comenzar con un archivo init.vim. Una vez que ya estamos usando Neovim podemos realizar la migración init.lua. Sin embargo, tenemos que crear los directorios para que Neovim guarde su configuración. Lo único que dejaremos por ahora en Vim script es la configuración de plugins con vim-plug. Por lo tanto ejecutamos:

mkdir -p ~/.config/nvim/lua/utils
mkdir -p ~/.local/share/nvim/site/autoload
# Suponiendo que usabas un archivo para  
mv ~/.vim/autoload/plug.vim  ~/.local/share/nvim/site/autoload

• El directorio ~/.config/nvim es obligatorio.
• El directorio ~/.config/nvim/lua no es obligatorio, pero es muy útil para modularizar la configuración de Neovim.
• Los nombres dados de los archivos y directorios dentroo de ~/.config/nvim/lua son totalmente arbitrarios.

En Neovim tendremos una estructura más modular. Si bien, podemos, tener, todo en init.lua, vamos a aprovecharnos de esta configuración que es mucho más flexible.

Archivo ~/.config/nvim/init.lua

-- Cargamos nuestros módulos

local commands = require('utils.commands')
local extracommands = require('utils.extracommands')
local keymaps = require('keymaps')
local opciones = require('opciones')


-- Mantenemos por ahora la configuración de plugins en Vim script
vim.cmd('source ~/.config/nvim/plugins.vim')

Archivo ~/.config/nvim/keymaps.lua

-- Alias
local map = vim.keymap.set                                                                         
-- maps
map('n', 'ñ', ':wq<CR>

Archivo ~/.config/nvim/lua/opciones.lua

-- Alias
local vo = vim.o
local vop = vim.opt

-- Opciones
vo.tabstop = 4
vop.nf:append('alpha')

Archivo ~/.config/nvim/lua/utils/commands.lua

-- Crea una tabla vacía para guardar funciones

local M = {}

function M.create_command(name, command_or_function, opts)
  pcall(vim.api.nvim_del_user_command, name)
  vim.api.nvim_create_user_command(name, command_or_function, opts or {})
end

-- Alias
local com = M.create_command

com('Silent', function(opts)
  vim.cmd('silent !' .. table.concat(opts.fargs, ' '))
  vim.cmd('redraw!')
end, { nargs = '+' })

com('Nbuild', function()
  vim.cmd('w')
  vim.cmd('silent nikola build')
end, {})


return M

Archivo ~/.config/nvim/lua/utils/extracommands.lua

-- Alias
local vcmd = vim.cmd

-- Extra commands
vcmd('filetype plugin on')
-- Esta configuración es innecesaria ya está en init.lua
-- vcmd('runtime plugins.vim')
vcmd('colorscheme PaperColor')

Archivo ~/.config/nvim/plugins.vim

Este es el único archivo que lo dejamos en Vim script (con código Lua embebido incluido):

"Plugins (Plug)
call plug#begin('~/.vim/plugged')

Plug 'itchyny/lightline.vim'
Plug 'nyngwang/NeoTerm.lua'
Plug 'NLKNguyen/papercolor-theme'

call plug#end()

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>

Y Listo...

Explicación

¿Por qué definimos alias en los 3 archivos de módulos?

Los alias son básicamente variables. Los definimos porque este es un ejemplo de tipo "esqueleto" de configuración. Cuando comiences a agregar, más opciones, atajos de teclado y comandos personalizados, no querrás etipear tanto 😉.

¿Para qué agregamos la función create_command?

En Lua cuando usás la API de Neovim, si querés redefinir una función de un comando personalizado, tenés que borrarlo y volver definirlo, sino da error. Esto es para evitar sobreescrituras accidentales. Por eso creamos la función create_command para que cuando redefinamos un comando lo hagamos de manera explícita.

• Usa pcall para borrar el comando personalizado y si no existe no da error.
• Vuelve a recrearlo con la nueva definición.

¿Acaso el comando Nbuild hace lo mismo en Vim script que en Lua? Vamos a analizarlo.

1. Brevedad vs mantenibilidad

• VimL:

vim command -nargs=+ Silent execute 'silent !<args>' | redraw! command Nbuild execute 'w | Silent nikola build'

Es breve, directo y funciona. Pero:

• Es poco expresivo
• No permite manejar errores fácilmente

• No escala bien con lógica compleja

• Lua:

lua com('Silent', function(opts) vim.cmd('silent !' .. table.concat(opts.fargs, ' ')) vim.cmd('redraw!') end, { nargs = '+' })

Es más verboso, sí, pero:

• La función puede ser más compleja si se necesita
• Es programable y reutilizable
• Puede integrarse con condicionales, bucles, o lógica externa

2. Control de errores y depuración

• En VimL: si un comando falla, tenés poco margen para capturar y manejar el error.
• En Lua: podés usar pcall, vim.notify, vim.fn.systemlist, y construir mensajes personalizados o fallback si algo sale mal.

local ok, _ = pcall(function()
  vim.cmd('silent !nikola build')
end)
if not ok then
  vim.notify('Error al ejecutar nikola build', vim.log.levels.ERROR)
end

3. Modularización

• En Lua podés agrupar comandos en módulos, con require(...).
• En VimL tenés que recurrir a runtime, source, y no hay namespaces claros.

local commands = require('utils.commands')
commands.create_command(...)

Esto facilita dividir la configuración en archivos lógicos, más fácil de leer, mantener y compartir.

4. Compatibilidad futura y ecosistema Neovim

• Neovim ha declarado que Lua es su lenguaje de configuración nativo moderno.
• La mayoría de los plugins modernos están escritos en Lua.
• VimL sigue siendo soportado, pero está siendo superado funcionalmente.

5. Legibilidad a largo plazo

• Aunque VimL sea más corto, en un entorno de colaboración o con configuraciones grandes, Lua:

• Es más explícito.

• Permite documentar.
• La API de Neovim en Lua permite un uso más explícito y predecible de tipos de datos.
• Es más fácil de extender con lógica externa.

Conclusión

Si sabés migrar opciones, mappings, comandos y cargar plugins → podés convertir el 80% o más de tu init.vim (equivalente el viejo .vimrc) a init.lua.

Migrar tu configuración de Neovim de Vim script a Lua no solo representa una mejora técnica inmediata, sino también una oportunidad para afilar tu pensamiento en términos de estructura, modularidad y optimización.

Lua te invita a organizar tu configuración como un sistema flexible y componible, donde cada parte puede ser reutilizada, testeada y afinada con precisión. Este tipo de enfoque —más declarativo, más explícito— entrena tu mente en formas modernas de entender y construir software.

A medida que domines la integración de herramientas, el manejo eficiente de datos y la automatización de tareas dentro de Neovim, estarás cultivando hábitos que trascienden tu editor: aprenderás a diseñar entornos complejos donde múltiples componentes cooperan de forma orquestada.

Esa forma de pensar, de buscar la mejora continua y construir sistemas cada vez más elegantes y potentes, es lo que hoy distingue a los profesionales más relevantes del ecosistema tecnológico.

Apéndice : Los 10 conceptos fundamentales de Lua (resumen)

Si querés profundizar, te propongo 7 conceptos extra para profundizar en el uso de Lua en Neovim:

Fuentes y más Recursos

• Lua en Neovim
• Mastering Neovim Lua: Quick Tips for Effortless Coding
• An interactive and powerful Git interface for Neovim, inspired by Magit
• A pragmatic approach to migrating from VSCode to Neovim
• Mastering Neovim on Linux: A Step-by-Step Guide
• NeoVim Is Better, But Why Developers Aren't Switching To It?
• NeoVim 10.0 Setup for 2025: AI Plugins and LSP Configuration

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

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?

1. Previene carga múltiple con vim.g.loaded_man.
2. Crea un comando :Man con opciones (bang, autocompletado, etc.).
3. Crea un autocmd que detecta buffers con URI man:// y carga la manpage.
4. Usa funciones (open_page, init_pager, read_page, man_complete) definidas en el módulo man.
5. 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:

• Painless Java
• neovimi (node.js)
• Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers
• Cliente de python para escribir plugins

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:

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:

• Shougo/dein.vim: Dark powered Vim/Neovim plugin manager
• VundleVim/Vundle.vim: Vundle, the plug-in manager for Vim
• junegunn/vim-plug: Minimalist Vim Plugin Manager

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.

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:

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

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

3. 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:

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

Más Recursos

• Nvim documentation: develop
• Variables de Entorno de XDG Base Directory Specification
• brooth/far.vim: Find And Replace Vim plugin
• Vim Awesome
• How to install Vim plugins | Opensource.com
• Vim: So long Pathogen, hello native package loading | George Ornbo

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:

¿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 excluirlo de 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:

🧪 Comparación simple

🔧 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,

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:

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

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

3. 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:

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

1. 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.
2. 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.
3. 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:

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

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

3. 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:

1. Posición temprana en el flujo del tráfico:
2. 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.
3. 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)?

Limitaciones de la familia netdev:

1. Solo para tráfico entrante:

2. La familia netdev opera únicamente en el hook ingress, por lo que no puedes aplicar policing en el tráfico saliente de una interfaz.

3. Falta de seguimiento de conexiones (conntrack):

4. No puedes usar estados como NEW o ESTABLISHED, ya que netdev opera antes de que el módulo conntrack pueda procesar el tráfico.

5. Menor flexibilidad:

6. 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:

Diferencias clave entre bridge y netdev:

1. Ámbito del tráfico manejado:
2. bridge: Filtra tráfico que cruza un bridge, conectando múltiples interfaces dentro del mismo dominio de difusión.

3. netdev: Filtra tráfico directo en una interfaz individual, antes de pasar al stack de red.

4. Dependencia de bridges:

5. bridge: Solo funciona en interfaces que son parte de un bridge.

6. netdev: Funciona en cualquier interfaz, sin importar si es parte de un bridge o no.

7. Posición en el stack de red:

8. bridge: Opera después de que el tráfico ha ingresado al bridge pero antes de ser reenviado a otra interfaz.

9. netdev: Opera antes de que el tráfico entre al stack de red del sistema operativo, en el hook ingress.

10. Casos de uso:

11. bridge: Aislar tráfico dentro del bridge, controlar VLANs, proteger contra ataques L2 como spoofing de MAC.
12. 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:

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

1. 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:

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

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

• Documentación oficial de nftables
• Sitio Oficial del proyecto netfilter
• Historia del proyecto Netfilter

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:

Descripción de los campos

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 verifucar 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(/.*)?

y

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)

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

Aaron Burden

Algunas suposiciones:

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

Caso 1: Redireccionado desde un puerto local a un puerto remoto para segurizar un servicio sin cifrar

Queremos segurizar el acceso a un servidor web sin TLS.

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

• 80: Es el puerto que tiene el servicio sin cifrar
• localhost: Es la dirección en el host servicio-remoto.example.com que escucha en el puerto 80.
• 10001: Es el puerto local al cual tendremos que conectarnos para obtener el servicio web.
• -N No ejecuta comandos en el lado remoto.
• -f El proceso va al segundo plazo antes de la ejecución de comandos.

El url que habrá que poner en el navegador es http://localhost:10001

Caso 2: Redireccionado desde un puerto local a un puerto remoto permitiendo el acceso al túnel usuarios de la misma red local para Segurizar un servicio sin cifrar

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

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

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

Caso 3: Redireccionado desde un puerto local a un puerto remoto usando otro servidor ssh para acceder a un servicio sin TLS ni ssh

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

• Aquí la url será http://localhost:10001

Caso 4: Crear un túnel en dirección inversa para acceder a un puerto SSH filtrado (utilización de un túnel remoto)

En este caso, queremos acceder al puerto SSH de filtrado.example.com, que no es accesible desde internet. Utilizamos casa.example.com con acceso SSH temporal para redirigir el puerto SSH de filtrado.example.com.

El comando debe ejecutarse en filtrado.example.com:

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

• 22: Es el puerto SSH de filtrado.example.com.
• 9000: Es el puerto redirigido en casa.example.com.

Para conectarse al puerto SSH de filtrado.example.com desde casa.example.com:

ssh -p 9000 localhost

Caso 5: Redireccionamiento remoto para permitir acceso compartido a un puerto filtrado

En este caso, queremos redirigir el puerto SSH de un servidor filtrado (filtrado.example.com) hacia un servidor intermedio (casa.example.com) y permitir que otros hosts que están en la misma red local puedan acceder al túnel.

Comando para configurar el túnel:

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

• 0.0.0.0:9000: Permite que el puerto redirigido esté accesible en todas las interfaces de red de casa.example.com.
• localhost:22: Redirige el tráfico al puerto SSH de filtrado.example.com.

Para conectarse al túnel desde cualquier host con acceso a casa.example.com:

ssh -p 9000 casa.example.com

Requisito en casa.example.com

Habilitar GatewayPorts en /etc/ssh/sshd_config:

GatewayPorts clientspecified

Con esta configuración si el cliente no especifica explícitamente 0.0.0.0 al crear el túnel, los puertos siguen siendo locales por defecto.

Reinicia el servicio SSH:

sudo systemctl restart sshd

Notas de Seguridad

Si el servidor casa.example.com tiene una IP pública, usar firewalls para limitar el acceso al puerto 9000 y restringirlo solo a las máquinas necesarias. Para mayor seguridad, se puede especificar una interfaz específica en lugar de 0.0.0.0.

Troubleshooting

En todas las casos usar la opción -v para obtener realizar debugging. Recordar que dicha opcioń se puede usar múltiples veces para aumentar el detalle.

Zabbix es una potente herramienta de monitoreo. Recientemente salió la versión 7.0 la cual incorporó funcionalidades importantes, como son los items de browser que usan webdrivers. A continuación veremos como implementar Zabbix 7.x usando podman.

La guía siguiente supone que:

• Ya generaste o adquiriste los certificados ssl.
• Tenés los conocimientos fundamentales sobre Linux (usamos RHEL8).
• Poseés conocimientos básicos de troubleshooting en contenedores y entendiendo que este "HowTo" es un punto al que deberás adaptar a tu entorno y necesidades. No es consultoría 😀.

1. Crear el Pod con Puertos Correctos

Primero, crear el pod con el puerto 443 en el host mapeado al puerto 8443 en el contenedor de NGINX. También asignar el puerto 10051 para Zabbix Server.

podman pod create --name zabbix -p 443:8443 -p 10051:10051

2. Desplegar el Contenedor MySQL

Iniciar el contenedor mysql-server dentro del pod, configurando las variables de entorno necesarias para la base de datos de Zabbix:

mkdir mysql && podman run -d --name mysql-server --pod=zabbix \
    -v ./mysql:/var/lib/mysql:Z \
    -e MYSQL_DATABASE="zabbix" \
    -e MYSQL_USER="zabbix" \
    -e MYSQL_PASSWORD="zabbix_pwd" \
    -e MYSQL_ROOT_PASSWORD="root_pwd" \
    docker.io/library/mysql:8.0

3. Configurar log_bin_trust_function_creators en MySQL

Para evitar problemas con permisos de creación de funciones, habilita esta configuración en el servidor MySQL:

Darle tiempo a que MySQL esté listo:

until podman exec mysql-server mysqladmin ping -u root -p'root_pwd' --silent; do
    echo "Esperando a que MySQL esté listo..."
    sleep 5
done

Ejecutar la configuración:

podman exec -i mysql-server mysql -u root -p'root_pwd' -e "SET GLOBAL log_bin_trust_function_creators = 1;"

4. Desplegar el Contenedor Zabbix Server

Iniciar el contenedor zabbix-server-mysql en el pod, conectándolo a MySQL y asegurándote de que se conecte al Java Gateway:

podman run -d --name zabbix-server-mysql --pod=zabbix \
    -e DB_SERVER_HOST="127.0.0.1" \
    -e MYSQL_USER="zabbix" \
    -e MYSQL_PASSWORD="zabbix_pwd" \
    -e MYSQL_DATABASE="zabbix" \
    -e ZBX_JAVAGATEWAY="127.0.0.1" \
    docker.io/zabbix/zabbix-server-mysql:alpine-latest

5. Verificar la Creación de Tablas en la Base de Datos

Confirmar que zabbix-server-mysql crea correctamente las tablas en la base de datos:

podman exec -i mysql-server mysql -u root -p'root_pwd' -e "USE zabbix; SHOW TABLES;"

6. Desplegar el Contenedor Zabbix Java Gateway

Iniciar el contenedor zabbix-java-gateway, asegurándote de que esté en el pod zabbix:

podman run -d --name zabbix-java-gateway --pod=zabbix docker.io/zabbix/zabbix-java-gateway:alpine-latest

7. Desplegar el Contenedor NGINX con Certificados SSL y Configuración

Ejecutar el contenedor de Zabbix Web NGINX MySQL (zabbix-web-mysql-ssl), montando los certificados y el archivo de configuración zabbix-ssl.conf correctamente:

El archivo de configuración zabbix-web-mysql-ssl puede ser algo así:

server {
    listen 8443 ssl;
    server_name _;

    ssl_certificate /etc/ssl/nginx/fullchain.pem;
    ssl_certificate_key /etc/ssl/nginx/privkey.pem;

    root /usr/share/zabbix;

    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/tmp/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME /usr/share/zabbix$fastcgi_script_name;
    }

    error_log /tmp/zabbix_ssl_error.log;
    access_log /tmp/zabbix_ssl_access.log;
}

podman run -d --name zabbix-web-mysql-ssl --pod=zabbix \
    -v ./certs/fullchain.pem:/etc/ssl/nginx/fullchain.pem:ro \
    -v ./certs/privkey.pem:/etc/ssl/nginx/privkey.pem:ro \
    -v ./zabbix-ssl.conf:/etc/nginx/http.d/zabbix-ssl.conf:ro \
    -e ZBX_SERVER_HOST="127.0.0.1" \
    -e DB_SERVER_HOST="127.0.0.1" \
    -e MYSQL_DATABASE="zabbix" \
    -e MYSQL_USER="zabbix" \
    -e MYSQL_PASSWORD="zabbix_pwd" \
    docker.io/zabbix/zabbix-web-nginx-mysql:alpine-latest

8. Verificación Final

Hacer una solicitud a la interfaz de Zabbix para confirmar que todo esté funcionando y que la configuración SSL esté activa:

curl -v  https://sebelk.lab

Deberías ver una respuesta HTTP 200 desde NGINX, indicando que Zabbix está activo y funcionando con SSL.

9. Instalación del agente

podman run -d --name zabbix-agent --pod=zabbix \
    -e ZBX_SERVER_HOST="127.0.0.1" \
    -e ZBX_SERVER_PORT="10051" \
    -e ZBX_HOSTNAME="ZabbixServerAgent" \
    docker.io/zabbix/zabbix-agent2:alpine-latest

10. Deshabilitar variable en MySQL

La variable que habilitamos antes no es imprescindible, de modo que se puede desactivar:

podman exec -i mysql-server mysql -u\
     root -p'root_pwd'\
    -e "SET GLOBAL log_bin_trust_function_creators = 0;"

Todo listo

¡Listo! Trabajo terminado 😉

¿Qué te pareció la guía? Podés usar la sección de Comentarios.

En el post anterior vimos los namespaces, que sirven para aislar diferentes aspectos del sistema, como los procesos, la red y los puntos de montaje, creando entornos independientes para cada grupo de procesos. En este post, exploraremos los cgroups, que permiten controlar cuánto de los recursos del sistema, como CPU, memoria y disco, puede usar cada grupo de procesos. Ambas tecnologías se complementan: los namespaces proporcionan el aislamiento necesario, mientras que los cgroups gestionan y limitan los recursos que esos entornos aislados pueden consumir.

¿Qué son los cgroups?

Los cgroups (control groups) son una funcionalidad del kernel Linux que permite agrupar procesos y controlar de manera granular los recursos del sistema que consumen, como CPU, memoria, I/O, y otros. Se incorporaron en 2008 en el kernel de Linux 2.6.24, los cgroups permiten a los administradores de sistemas gestionar el uso de recursos por grupos de procesos de forma eficiente, garantizando una distribución justa y controlada.

Los cgroups crean una jerarquía de control donde es posible asignar límites a recursos específicos para un conjunto de procesos, de manera que el sistema operativo pueda monitorear, limitar, priorizar o aislar estos procesos según sea necesario. Esta capacidad es clave para garantizar que los sistemas multitarea, servidores, y contenedores funcionen de manera eficiente.

¿Para qué sirven los cgroups?

Los cgroups sirven para:

• Limitar el uso de recursos

• Priorizar procesos

• Aislar procesos

• Monitorear el consumo de recursos

• Controlar procesos en contenedores (Docker, podman,etc.)

Un pantallazo de los cgroups

Dentro del propio directorio /proc podemos encontrar información sobre los cgroups:

❯ cat /proc/cgroups 
#subsys_name    hierarchy       num_cgroups     enabled
cpuset  0       241     1
cpu     0       241     1
cpuacct 0       241     1
blkio   0       241     1
memory  0       241     1
devices 0       241     1
freezer 0       241     1
net_cls 0       241     1
perf_event      0       241     1
net_prio        0       241     1
hugetlb 0       241     1
pids    0       241     1
rdma    0       241     1
misc    0       241     1

Este archivo muestra 4 columnas

Evolución de los cgroups:

1. cgroups v1: En la versión original, cada tipo de recurso (CPU, memoria, etc.) tenía su propia jerarquía de control, lo que permitía una gestión separada pero a veces compleja. Aunque era útil, la administración independiente de subsistemas podía resultar difícil de manejar en entornos complejos.

2. cgroups v2 (2016): Para mejorar la gestión de recursos, se introdujo cgroups v2 en el kernel de Linux 4.x, que unificó los diferentes controladores bajo una jerarquía única. Esta versión simplificó el control de recursos y mejoró la eficiencia, permitiendo que todos los subsistemas trabajaran de manera más coordinada y con configuraciones más claras.

Cómo crear un cgroup y limitar el uso de CPU en cgroups v2

En este ejemplo, limitaremos el uso de CPU de un proceso utilizando cgroups v2 en un entorno moderno.

Paso 1: Crear un directorio para el cgroup

En cgroups v2, se gestiona todo bajo una jerarquía unificada. Primero, crea un nuevo directorio en /sys/fs/cgroup:

sudo mkdir /sys/fs/cgroup/mi_cgroup

Paso 2: Establecer un límite de CPU

En cgroups v2, puedes establecer límites en el uso de CPU mediante el archivo cpu.max. Este archivo recibe dos valores: el primero es el límite de uso de CPU en microsegundos por cada período de 100 milisegundos, y el segundo es la duración del período en microsegundos.

Para limitar el uso de CPU al 50%, puedes hacer lo siguiente:

echo "50000 100000" | sudo tee /sys/fs/cgroup/mi_cgroup/cpu.max

Este comando establece que los procesos en este cgroup pueden usar un máximo de 50.000 microsegundos de CPU en un período de 100.000 microsegundos (100 ms), lo que equivale al 50% de un núcleo de CPU.

Paso 3: Añadir un proceso al cgroup

Para añadir un proceso existente al cgroup, escribe su PID (ID del proceso) en el archivo cgroup.procs de ese cgroup. Supongamos que el PID del proceso es 78435:

echo 78435| sudo tee /sys/fs/cgroup/mi_cgroup/cgroup.procs

Esto moverá el proceso con PID 78435 al cgroup mi_cgroup, aplicando las restricciones de CPU configuradas.

En cgroups v1, los recursos se gestionan usando archivos como cpu.shares para establecer prioridades relativas de CPU, y tasks para asignar procesos a un cgroup. En cambio, en cgroups v2, el control de CPU se realiza a través de cpu.max, donde se puede establecer un límite absoluto en el uso de CPU (como un porcentaje). Además, en v1 cada subsistema tiene su propio directorio (como cpu/, memory/), mientras que en v2 todo se gestiona dentro de una única jerarquía unificada bajo /sys/fs/cgroup/.

Conclusión

Hoy en día, los cgroups son una herramienta crítica en la gestión moderna de servidores. RHEL8 usa de manera predeterminada la versión 1, pero es posible usar la versión 2, dependiendo del software que utilicemos. En definitiva, los cgroups son fundamentales para la operación de tecnologías como contenedores (Docker, Podman), orquestadores como Kubernetes, y cualquier sistema que necesite control granular de recursos. La capacidad de aislar, priorizar y monitorear el uso de recursos en servidores es clave para garantizar la estabilidad y el rendimiento en entornos de alta demanda.

Fuentes y más información

• CGROUPS v1
• CGROUPS v2
• Explicación de namespaces y cgrous en el blog de NGINX

En el post anterior, exploramos qué es Flatpak, una excelente alternativa o complemento a los métodos tradicionales de instalación de programas en Linux. Flatpak utiliza una herramienta llamada bubblewrap, que a su vez emplea la tecnología de namespaces.

Veamos con lupa lo que hay debajo de una aplicación flatpak.

Listado de procesos de aplicaciones flatpak

❯ flatpak ps --columns=pid,child-pid,application
PID  PID-hijo Aplicación
4588 4610     com.github.marktext.marktext
4629 4639     com.github.marktext.marktext
4841 4853     com.spotify.Client

Este listado nos muestra que hay dos aplicaciones corriendo: MarkText y Spotify. Vamos a ver qué pasa con uno de los procesos relacionados con MarkText.

El comando detrás de flatpak

❯ ps p  4610 o args
COMMAND
/usr/bin/bwrap --args 42 -- spotify

bwrap es una herramienta para crear sandboxes por medio de namespaces. Un namespace es un recurso del sistema que se puede aislar, pero... en lugar de abundar en tecnicismos, para comprender este concepto en la práctica, veremos algunas propiedades del proceso 4610 (MarkText):

❯ ls -l /proc/4610/ns
total 0
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:40 mnt -> 'mnt:[4026532856]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 net -> 'net:[4026531840]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:40 pid -> 'pid:[4026532857]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 pid_for_children -> 'pid:[4026532857]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 time -> 'time:[4026531834]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 time_for_children -> 'time:[4026531834]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:40 user -> 'user:[4026532858]'
lrwxrwxrwx 1 sergio sergio 0 jul 31 18:46 uts -> 'uts:[4026531838]'

Ese listado nos muestra que están los namespaces cgroup, ipc, mnt, net, pid, time, user y uts. Cada uno de ellos tiene un número que lo identifica.

Podemos compararlo con otros procesos por ejemplo con el pid 1 y con el pid del shell que estamos usando:

Podemos ver que tanto bash como systemd comparten todos los namespaces. Sin embargo, bwrap tiene namespaces distintos para mnt, pid y user. Es decir tiene esos recursos aislados.

El cuadro siguiente nos sirve para saber qué namespace usar de acuerdo a lo que queramos aislar:

El soporte en el kernel lo podemos verificar de la siguiente manera:

grep -E 'CONFIG_[A-Z]+_NS=y' /boot/config-$(uname -r)
CONFIG_UTS_NS=y
CONFIG_TIME_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y

Crear nuevos namespaces para procesos y usuarios

La herramienta unshare nos permite experimentar y solucionar problemas en aplicaciones y servicios que usan namespaces. En el siguiente ejemplo abrimos un shell con namespaces aislados para usuarios y números de procesos:

❯ unshare --mount-proc --pid --fork --user bash
❯ ps aux
   USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   nobody         1  2.8  0.0 237808 12996 pts/1    S    13:43   0:00 bash
   nobody       104  0.0  0.0 230836  4096 pts/1    R+   13:43   0:00 ps aux

• Aquí vemos que bash usa el PID 1 en lugar de systemd, y que el comando ps aux toma el pid 2.
• Además, el usuario pasa a ser nobody.
• Para salir del namespace, simplemente hay que ejecutar exit. Es importante asegurarse de que todos los procesos dentro del namespace hayan terminado, de lo contrario, puede ser que exit sea insuficiente para salir completamente del namespace.

¿Por qué usamos --mount-proc?

Bueno... porque si no lo hacemos sucede esto:

❯ unshare --mount --pid --fork --user /bin/bash
basename: falta un operando
Pruebe 'basename --help' para más información.

Este mensaje aparece porque el comando basename usa readlink para ver hacia dónde apunta /proc/$$/exe. Como el PID de la shell en el nuevo namespace es 1, intenta acceder incorrectamente al directorio /proc en los namespaces del host. Linux impide este acceso para mantener el aislamiento y la seguridad, lo que resulta en ese error.

Particularidades de namespaces

❯ unshare --mount-proc --pid --user /bin/bash
unshare: mount /proc failed: Operación no permitida
❯ unshare --pid --user /bin/bash
bash: fork: No se pudo asignar memoria

En el primer intento, ni siquiera pudo crear los namespaces; en el segundo, aunque lo logró, muestra un mensaje críptico:

bash: fork: No se pudo asignar memoria

Estos errores ocurren porque unshare, por defecto, ejecuta el comando indicado en el mismo proceso (similar a exec), lo que resulta en:

• Error de Montaje: El sistema no permite montar /proc porque el proceso no tiene el contexto completo de namespace de usuario y PID necesario.
• Error de Memoria: Debido a que bash no se convierte en PID 1 ni puede acceder a otro proceso con PID 1, Linux no permite la asignación de memoria porque no hay un proceso para manejar la recolección de zombies y otras tareas esenciales.

Por lo tanto, usar --fork es necesario para asegurar que el proceso tenga el contexto de namespace completo y para crear un nuevo proceso que actúe como PID 1 en el nuevo namespace.

Entrar en namespaces de una app de flatpak

❯ sudo nsenter --mount --pid -S $UID -t 4610
-bash-5.2$ ps auxwww
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
sergio         1  0.0  0.0   3764  1288 ?        S    18:40   0:00 /usr/bin/bwrap --args 40 -- marktext
sergio         2  0.9  0.5 21637908 182648 ?     SLl  18:40   0:15 /app/marktext/marktext
sergio         5  0.0  0.0   5640  1664 ?        S    18:40   0:00 cat
sergio         6  0.0  0.0   5640  1792 ?        S    18:40   0:00 cat
sergio        10  0.0  0.1 16987244 46720 ?      S    18:40   0:00 /app/marktext/marktext --type=zygote --no-zygote-sandbox
sergio        12  0.0  0.0      0     0 ?        Z    18:40   0:00 [zypak-sandbox] <defunct>
sergio        15  0.0  0.0   3768  1152 ?        S    18:40   0:00 /usr/bin/bwrap --args 42 -- /app/bin/zypak-helper child - /app/marktext/marktext --type=zygote
sergio        16  0.0  0.1 16989892 49152 ?      S    18:40   0:00 /app/marktext/marktext --type=zygote
sergio        48  1.4  0.2 17065152 72664 ?      Sl   18:40   0:23 /app/marktext/marktext --type=gpu-process --field-trial-handle=9170851604328465342,17458150017059513700,131072 --disable-features=SpareRendererForSitePerProcess --enable-crash-reporter=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel --global-crash-keys=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel,_companyName=marktext,_productName=marktext,_version=0.17.1 --user-data-dir=/home/sergio/.var/app/com.github.marktext.marktext/config/marktext --gpu-preferences=UAAAAAAAAAAgAAAIAAAAAAAAAAAAAAAAAABgAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA= --use-gl=swiftshader-webgl --shared-files
sergio        53  0.0  0.0 16998948 14448 ?      S    18:40   0:00 /app/marktext/marktext --type=broker
sergio        63  0.0  0.1 17044740 57216 ?      Sl   18:40   0:00 /app/marktext/marktext --type=utility --utility-sub-type=network.mojom.NetworkService --field-trial-handle=9170851604328465342,17458150017059513700,131072 --disable-features=SpareRendererForSitePerProcess --lang=es-419 --service-sandbox-type=none --enable-crash-reporter=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel --global-crash-keys=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel,_companyName=marktext,_productName=marktext,_version=0.17.1 --user-data-dir=/home/sergio/.var/app/com.github.marktext.marktext/config/marktext --shared-files=v8_context_snapshot_data:100
sergio        74  5.2  0.6 25595728 212480 ?     Sl   18:40   1:27 /app/marktext/marktext --type=renderer --enable-crash-reporter=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel --global-crash-keys=7744fdfa-fe51-4b1f-adf6-daefea565c51,no_channel,_companyName=marktext,_productName=marktext,_version=0.17.1 --user-data-dir=/home/sergio/.var/app/com.github.marktext.marktext/config/marktext --app-path=/app/marktext/resources/app.asar --no-sandbox --no-zygote --field-trial-handle=9170851604328465342,17458150017059513700,131072 --disable-features=SpareRendererForSitePerProcess --disable-gpu-compositing --lang=es-419 --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=4 --no-v8-untrusted-code-mitigations --shared-files=v8_context_snapshot_data:100
sergio       144  0.0  0.0   7884  4224 ?        S    19:08   0:00 -bash
sergio       145  0.0  0.0  11032  4608 ?        R+   19:08   0:00 ps auxwww

La herramienta nsenter permite ejecutar comandos en namespaces de un proceso determinado, en este caso, el de bwrap. Como no especificamos ningún comando, corre el shell bash.

Allí podemos ver el espacio de nombres aislados de números de procesos, como se ve arriba, o como mostramos a continuación, los montajes aislados:

-bash-5.2$ df -h  
S.ficheros     Tamaño Usados  Disp Uso% Montado en  
tmpfs             16G    92K   16G   1% /etc/timezone  
/dev/sda6        511G   434G   76G  86% /cs  
tmpfs             16G      0   16G   0% /usr/lib/x86_64-linux-gnu/GL  
/dev/sda6        511G   434G   76G  86% /home  
tmpfs            3,2G    11M  3,2G   1% /run/host/monitor  
tmpfs             16G    15M   16G   1% /dev  
devtmpfs         4,0M      0  4,0M   0% /dev/tty  
tmpfs             16G      0   16G   0% /home/sergio/.local/share/flatpak  
tmpfs             16G      0   16G   0% /home/sergio/.var/app  
/dev/sda3        382G   100G  283G  27% /mnt/win10  
tmpfs            6,3G   2,3M  6,3G   1% /run/media  
tmpfs             16G   4,0M   16G   1% /tmp  
tmpfs             16G      0   16G   0% /tmp/.X11-unix  

También podemos pensar que estos recursos que se aíslan se virtualizan. Cuando hablamos de virtualización, probablemente pensemos en un disco o en una interfaz de red virtual. Pero aquí vemos, por ejemplo, que un espacio de nombres de PID's también se puede virtualizar.

Y cuando más de un recurso se puede virtualizar, de ahí a crear un contenedor hay una corta distancia. De hecho, los namespaces sirve tanto para un usuario final con flatpak como en la creación de contenedores lxc (ah, sí lxc existe desde 2008, aunque ya no esté más de moda 😁) docker o podman para un sysadmin o un desarrollador.

A continuación, veremos algunos ejemplos de cómo utilizar los namespaces en contenedores Podman. Es importante conocer el PID del contenedor en el host para estos ejemplos.

Ejemplo 1: Ver la configuración de red del contenedor que usa network mode pasta

❯ podman unshare nsenter --target 29420 --net  
❯ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host proto kernel_lo 
       valid_lft forever preferred_lft forever
2: wlp108s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether ea:38:5b:0b:a8:a8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.144/24 brd 192.168.0.255 scope global noprefixroute wlp108s0
       valid_lft forever preferred_lft forever
    inet6 fe80::e838:5bff:fe0b:a8a8/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Ejemplo 2: Ver la configuración de red del contenedor que usa network mode slirp4netns

  podman unshare nsenter --target 46222 --net  

  root in ~/to_delete 
  ❯ ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host proto kernel_lo 
         valid_lft forever preferred_lft forever
  2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
      link/ether 92:b6:67:25:13:33 brd ff:ff:ff:ff:ff:ff
      inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
         valid_lft forever preferred_lft forever
      inet6 fd00::90b6:67ff:fe25:1333/64 scope global dynamic mngtmpaddr proto kernel_ra 
         valid_lft 86356sec preferred_lft 14356sec
      inet6 fe80::90b6:67ff:fe25:1333/64 scope link proto kernel_ll 
         valid_lft forever preferred_lft forever

Ejemplo 3: Probar la resolución de nombres usando el archivo /etc/resolv.conf del contenedor

❯ container_id=$(podman inspect --format '{{.Id}}' namespace-demo)
❯ cp /run/user/1000/containers/overlay-containers/$container_id/userdata/resolv.conf /tmp/container_resolv.conf    
❯ podman unshare nsenter --target 46222  --net dig google.com @$(grep -m 1 'nameserver' /tmp/container_resolv.conf | awk '{print $2}')

; <<>> DiG 9.18.26 <<>> google.com @10.0.2.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25213
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             263     IN      A       142.251.133.78

;; Query time: 30 msec
;; SERVER: 10.0.2.3#53(10.0.2.3) (UDP)
;; WHEN: Thu Jul 25 19:50:18 -03 2024
;; MSG SIZE  rcvd: 55

Ejemplo 4: Ver los procesos de un contenedor rootless

❯ sudo nsenter --pid=/proc/$container_pid/ns/pid unshare --mount-proc
[sudo] contraseña para sergio: 
❯ ps
  PID TTY          TIME CMD
 1508 pts/6    00:00:00 bash
 1612 pts/6    00:00:00 ps
❯ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
sergio         1  0.0  0.0  14932  7168 ?        Ss   jul25   0:00 sudo /usr/sbin/sshd -D
sergio         2  0.0  0.0  14084  7936 ?        S    jul25   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root        1508  0.5  0.0 231260  6528 pts/6    S    19:00   0:00 -bash
root        1641  0.0  0.0 230836  3968 pts/6    R+   19:00   0:00 ps aux

Ejemplo 5: Crear namespaces no privilegiados con un poco de ayuda

Por último, veamos como usar la herramienta rootlesskit para crear fácilmente namespaces rootless:

❯ rootlesskit bash
❯ id
uid=0(root) gid=0(root) grupos=0(root),65534(nobody)
❯ exit
❯ rootlesskit --copy-up=/etc bash  
❯ touch /etc/sample
❯ ls -l /etc/sample
-rw-r--r-- 1 root root 0 jul 26 12:12 /etc/sample
❯ exit
❯ ls -l /etc/sample
ls: no se puede acceder a '/etc/sample': No existe el fichero o el directorio

Conclusión

En este post, hemos visto que los namespaces sirven para aislar recursos con diferentes propósitos y que herramientas como unshare y nsenter son muy útiles para entender cómo funciona una aplicación instalada con Flatpak, pero también un contenedor podman o similar, lo cual facilita la resolución de problemas. Algunas actividades que propongo para continuar ejercitando este tema son:

1. Instalar aplicaciones de Flatpak y observar qué sucede cuando más de un proceso está involucrado.
2. Examinar qué ocurre con las tablas de ruteo, las listas de iptables o nftables, etc., en un nuevo namespace de red.
3. Crear un namespace de usuario y explorar cómo este afecta la ejecución de comandos y procesos.

¡Hasta la próxima!

Fuentes y Recursos

1. man7.org - namespaces
2. man1.org - unshare)
3. man1.org - nsenter)
4. Docker - Namespaces Overview
5. Linux-native "fake root" for implementing rootless containers