Linux Sin Humo (Publicaciones sobre howto)

Gestión de Contraseñas Usando Contenedores Podman (Update 2025)

sebelk — Mon, 25 Aug 2025 22:27:46 GMT

En 2023, publiqué un post sobre cómo usar pass con un contenedor Git administrado por Podman. Esa guía fue muy útil como demo inicial, pero desde entonces cambiaron algunas cosas: nuevas versiones de Podman, la aparición de Quadlet, la deprecación de podman generate systemd, y la conveniencia de usar imágenes más estables.

Este post es una actualización 2025 del artículo original, incorporando:

Imagen base UBI9 minimal (más liviana y con soporte extendido). Esta imagen, desarrollada por Red Hat, es de tamaño relativamente pequeño, usa una versión reduccida de dnf, llamada microdnf con soporte de módulos y usa software de repositorios - también - de Red Hat.
Rootless limpio con UserNS=keep-id.
Quadlet para integrar con systemd --user.
Volúmenes persistentes para no perder datos ni claves al actualizar la imagen.
Endurecimiento SSH (solo claves públicas, nada de contraseñas).

1. Construcción de la imagen

Dockerfile (Dockerfile):

FROM registry.access.redhat.com/ubi9/ubi-minimal

RUN microdnf -y install openssh-server git shadow-utils \
    && microdnf clean all \
    && useradd -ms /bin/bash git \
    && chsh -s /usr/bin/git-shell git

EXPOSE 2222
CMD ["/usr/sbin/sshd", "-D", "-e"]

Construcción:

podman build -t localhost/passteiner-ubi9:1 .

2. Crear volúmenes persistentes

podman volume create git-home
podman volume create ssh-etc

VHOME=$(podman volume inspect -f '{{.Mountpoint}}' git-home)
mkdir -p "$VHOME/.ssh" "$VHOME/.password-store"
cp ~/.ssh/id_ed25519.pub "$VHOME/.ssh/authorized_keys"
chmod 700 "$VHOME/.ssh"
chmod 600 "$VHOME/.ssh/authorized_keys"

Repositorio bare:

podman unshare chown -R 1000:1000 "$VHOME"
podman run --rm -v git-home:/home/git localhost/passteiner-ubi9:1 \
  git init --bare /home/git/.password-store

3. Quadlet (systemd integration)

Archivo ~/.config/containers/systemd/pass_git.container:

[Unit]
Description=pass git over SSH (podman quadlet)
Wants=network-online.target
After=network-online.target

[Container]
Image=containers-storage:localhost/passteiner-ubi9:1
Pull=never

ContainerName=pass_git
Network=pasta
PublishPort=60003:2222

Volume=git-home:/home/git:Z,U
Volume=ssh-etc:/etc/ssh:Z

UserNS=keep-id
LogDriver=journald
Exec=/usr/sbin/sshd -D -e -p 2222 -o PidFile=/tmp/sshd.pid

[Service]
Restart=on-failure

[Install]
WantedBy=default.target

Activación:

systemctl --user daemon-reload
systemctl --user enable --now pass_git.service

4. Probar conexión SSH

ssh -p 60003 git@<IP_DEL_HOST> \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  'git --version && echo OK'

Debe autenticar con tu clave pública y responder git version ....

5. Probar pass con git

Inicializar pass en tu host y configurar el remoto:

export PASSWORD_STORE_DIR=~/.local/share/pass
pass init "tu_clave_gpg"
cd "$PASSWORD_STORE_DIR"
git remote add origin ssh://git@<IP_DEL_HOST>:60003/home/git/.password-store
git push origin master

Y luego:

pass git push
pass git pull

Diferencias clave respecto al artículo original

Imagen: antes Fedora, ahora UBI9 minimal (más estable, soporte hasta 2032).
Systemd: antes podman generate systemd, ahora Quadlet (futuro estándar, más limpio).
Rootless: antes root dentro del contenedor, ahora UserNS=keep-id.
Volúmenes: ahora explícitos (git-home, ssh-etc), evitando pérdidas de datos.
Seguridad SSH: solo claves, sin password, PidFile movido a /tmp.

Conclusión

Este enfoque actualizado:

Evita perder el repositorio y las claves al recrear el contenedor.
Asegura compatibilidad a futuro con Podman + systemd.
Se apoya en una base más segura (UBI9 minimal).

👉 Si ya usás el setup original, podés migrar en pocas horas y quedarte tranquilo de que tu gestor de contraseñas pass seguirá funcionando a largo plazo.

Comparación de systemd-run con nuhup, tmux y screen

sebelk — Tue, 24 Jun 2025 22:07:30 GMT

Si estamos conectados por ssh y sufrimos una desconexión mientras ejecutamos un comandos, puede representar un problema, desde la interrupción del proceso o la pérdida del acceso a la salida estándar/error del mismo. Existen comandos como nohup que de alguna manera nos ayudan a mitigar esas situaciones, tales como nohup, o multiplexores de terminal como screen y tmux.

Al usar systemd, contamos con una herramienta tan sencilla como poderosa: el comando systemd-run que permite ejecutar un comando muy sencillo como el siguiente en un servicio. O para ser más exactos en una service unit:

systemd-run --user ping 8.8.8.8

Comparación con nohup, tmux/screen

Característica	`systemd-run`	`nohup`	`tmux` / `screen`
Supervisión del estado	Sí, vía `systemctl status` y `journalctl`	No, se debe usar `ps` o `pgrep`	Parcial, requiere inspección manual de la sesión
Control del ciclo de vida	Completo: iniciar, detener, reiniciar con políticas de reinicio	Nulo: solo iniciar, sin reinicio automático	Manual: requiere interacción del usuario
Manejo de logs	Centralizado en journal, con metadata y timestamps	Básico: redirige a `nohup.out` sin rotación	Opcional: solo si se configura logging explícitamente
Integración con el sistema	Alta: como unidad de systemd, con cgroup, slices, y logs centralizados	Nula: proceso genérico del usuario	Baja: proceso de usuario sin integración con systemd
Persistencia tras logout	Alta: configurable vía `lingering` o como unidad del sistema	Limitada: depende de configuración de `logind`	Alta (tradicional), pero afectada por `KillUserProcesses`
Persistencia tras reinicio	Posible mediante conversión a unidad persistente o uso de `systemd-timer`	No, se requiere cron, scripts externos	No, sesión se pierde tras reboot
Políticas de recursos/aislamiento	Completa: límites CPU, memoria, I/O, namespaces, privilegios, etc.	Nula: se requiere uso externo de `ulimit` o `nice`	Nula: requiere herramientas externas
Facilidad de uso interactivo	Baja: orientado a ejecución no interactiva	Nula: no interactivo	Alta: diseñado para interacción, múltiples ventanas/sesiones
Ideal para	Tareas ad-hoc, servicios temporales, pruebas controladas	Procesos simples que deben continuar tras logout	Tareas interactivas largas o sesiones remotas persistentes

Más Ejemplos

Ansible

Advertencia: Los siguiente comandos no son para copiar y pegar sin analizarlos, deben ser ajustados al entorno en los cuales se los desea utiizar. El propósito principal es mostrar la potencia práctica de la herramienta systemd-run.

Objetivo: Ejecutar playbooks críticos en entornos controlados, como servicios temporales autoreiniciables.

systemd-run -p Restart=on-failure -p PrivateTmp=yes -p Description="Provisionar servidores" \
  -p SuccessExitStatus=0 \ 
  -p RestartSec=5 \ 
  -p TimeoutStopSec=30   \ 
  --unit=ansible-run ansible-playbook site.yml -i inventory/prod

Ventajas:

Crea un entorno temporal (/tmp aislado).
Si falla, se reinicia automáticamente.
El log de toda la ejecución queda en journal.

mysqldump

Objetivo: Realizar dumps de bases de datos con límites de memoria y sin cargar el sistema.

systemd-run \
  -p MemoryMax=750M \
  -p MemorySwapMax=150M \
  -p Nice=10 \
  -p Description="Backup de MySQL sin afectar el sistema" \
  --unit=mysql-dump \
  bash -c 'mysqldump --all-databases > /tmp/backup.sql'

Ventajas:

Protege al sistema de un uso excesivo de memoria
Baja prioridad de batch (Nice=10).
Log y control vía systemd.

Azure CLI

Objetivo: Apagar/desasignar todas las VMs del grupo "GrupoDesarrollo" en segundo plano

systemd-run --unit=apagar_vms \
    --service-type=oneshot \
    -p WorkingDirectory=/tmp \
    bash -c 'az login --identity && az vm list -g GrupoDesarrollo --query "[].id" -o tsv | xargs -r az vm deallocate --ids'

Ventajas:

Ejecución desacoplada de la terminal.
Se puede usar journalctl para auditar el comando.
Control sobre el entorno de ejecución

Conclusión

El comando systemd-run es una alternativa más robusta que otros comandos legacy o multiplexores de terminal, ya que permite, no solamente desacoplar el proceso de la terminal sino también poder gestionarlo perfectamente dentro de systend.

Fuentes y más recursos

Manpage de systemd-run
Documentación oficial de systemd-run, incluyendo parámetros como --unit, --service-type, y ejemplos útiles.
Manpage de systemd.service
Referencia esencial sobre unidades de servicio, incluyendo tipos (oneshot, simple) y propiedades como Restart=, WorkingDirectory=, etc.
Autenticación con identidad administrada en Azure CLI
Cómo usar az login --identity de forma segura, sin almacenar credenciales.
Respuesta que recomienda systemd-run cuando nohup falla
Explica por qué procesos protegidos con nohup pueden morir y propone systemd-run --scope --user como solución más fiable.
Explicación de tipos de unidades systemd (Fedora Project)
Introducción accesible al funcionamiento de systemd.

Cómo migrar de vim-plug a lazy.nvim

sebelk — Sun, 01 Jun 2025 22:50:42 GMT

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

¿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.nvim?

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:

Funcionalidad/Ventaja	¿Qué significa?
Inicio ultra rápido	Arranca en segundos porque los módulos se precompilan y se cachean automáticamente.
Instalaciones livianas	Clona sólo lo esencial de los repos, ahorrando ancho de banda y espacio.
Plugins sin bloqueo del editor	Tareas pesadas se ejecutan en segundo plano, manteniendo Neovim fluido.
Análisis de rendimiento	Herramientas para medir tiempos de carga y optimizar tu configuración.
Carga bajo demanda (lazy-loading)	Plugins se cargan solo cuando se necesitan, reduciendo carga inicial y memoria.

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

Directorio	Uso específico por `lazy.nvim`
`~/.cache/nvim/luac/`	Cache de bytecode Lua. Compila tu configuración en Lua a `.luac`, para que Neovim no tenga que interpretarla cada vez.
`~/.local/share/nvim/lazy/`	Instalación real de los plugins. Los plugins ya descargados no necesitan revalidarse ni reinstalarse.
`~/.local/state/nvim/lazy/`	Cache de estado: versiones exactas de los plugins, commits, fechas, hashes. Así `lazy.nvim` sabe si algo cambió.

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

Funcionalidad	vim-plug	lazy.nvim	Nota / Matiz
Gestión de plugins (install/update)	Sí	Sí	Ambos permiten instalar, actualizar y remover plugins fácilmente
Lazy loading de plugins	Sí (manual, limitado)	Sí (declarativo y avanzado)	vim-plug requiere configuración manual con `on`, `for`, `cmd`
Cache de estado (lockfiles, hashes)	Parcial (`:PlugSnapshot`)	Sí (`lazy-lock.json`)	vim-plug permite snapshot, pero no lo gestiona ni lo aplica automáticamente
Cache de bytecode Lua (.luac)	No	Sí	lazy.nvim compila módulos Lua para acelerar el arranque
Arranque optimizado	Parcial (con lazy manual)	Sí (caching + carga bajo demanda)	lazy.nvim acelera usando cache + lazy loading automático
Integración con configuración Lua	No (Vimscript-first)	Sí (nativo en Lua)	vim-plug puede usarse con hacks en Lua, pero no está diseñado para eso

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:

Campo	¿Obligatorio?	¿Qué hace?
`"autor/repositorio"`	Sí	Identifica el plugin (por ejemplo `"NLKNguyen/papercolor-theme"`)
`config = function()`	No, pero común	Configura el plugin al cargarlo
`lazy = true/false`	Opcional	Define si se carga de forma diferida o al inicio
`priority = número`	Opcional	Da prioridad de carga (útil para temas de colores)
`event = "InsertEnter"`	Opcional	Carga el plugin al ocurrir cierto evento
`cmd = "Comando"`	Opcional	Carga el plugin cuando se ejecuta un comando
`dependencies = {}`	Opcional	Especifica otros plugins requeridos

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 convertir tu configuración de init.vim a init.lua?

sebelk — Thu, 15 May 2025 19:01:18 GMT

Requisitos

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º.
Conocimientos básicos o intermedios de Vim y haber leído el post anterior.
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

Concepto	Por qué es esencial
Tablas (`table`)	Todo en Lua usa tablas. Opciones (`vim.o`, `vim.opt`), autocmds, comandos, mappings y configuraciones de plugins.
Variables locales (`local`)	Permiten organizar el código, evitar errores y mejorar el rendimiento. Imprescindible para no contaminar el entorno global.
*API de Neovim (`vim.api.`)**	Es la manera oficial y flexible de interactuar con Neovim: crear comandos, autocmds, mappings y manipular el editor desde Lua.

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

Tabla	Contiene	Ejemplo equivalente en Vim script
`vim.o`	Opciones globales	`set tabstop=4`
`vim.opt`	Opciones globales que contienen listas	`set nf+=alpha`
`vim.cmd`	Comandos que se ejecutan en modo ex	`colorscheme PaperColor`
`vim.g`	Variables Globales	`let g:loaded_perl_provider =`
`vim.keymap.set`	Asignación de atajos de teclado a una función o combinación de teclas	`vim.keymap.set('n', 'ñ', ':wq<CR`
`vim.api.nvim_create_user_command`	Creación de comandos personalizados	`command Nbuild execute 'w \| Silent nikola build`

Diccionario cruzado Vim script / Lua

Concepto	Vim script	Lua
Variable global	`let g:mi_var = 10`	`vim.g.mi_var = 10`
Variable local	(no hay una manera clara)	`local var = 10`
Lista	`let lista = [1,2,3]`	`lista = {1, 2, 3}`
Diccionario	`let dict = {'a':1}`	`dict = {a = 1}`
Función	`function! Hola() ... end`	`function hola() ... end`
Función anónima	no hay	`function() ... end`
Autocomando	`autocmd BufWrite ...`	`vim.api.nvim_create_autocmd`
Mapping	`nnoremap`	`vim.keymap.set`
Comando	`command ...`	`vim.api.nvim_create_user_command`

Comparativa de conceptos clave: Vim script vs Lua

Concepto	Vim script	Lua (Neovim)
Variables y configuración	Variables globales (`let g:var`), `set` para opciones	Tablas (`vim.g`, `vim.o`, `vim.opt`) y variables locales (`local`)
Automatización / lógica	Funciones (`function!`), comandos (`command`), autocmds	Funciones anónimas y definidas, `vim.api.*`, autocmds con `vim.api.nvim_create_autocmd`
Extensibilidad y estructura	Scripts planos, difícil modularizar	Modularización con `require`, `package.loaded`, uso de archivos Lua por secciones

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:

Concepto	Descripción breve
Tablas (`table`)	Estructuras clave-valor o listas. Base de toda la configuración.
Variables locales (`local`)	Para mantener el código limpio y evitar contaminación global.
Funciones anónimas	Permiten definir acciones sin nombre, usadas en mappings, autocmds y comandos.
*API de Neovim (`vim.api.`)**	Puente entre Lua y Neovim: crear comandos, mappings, autocmds.
`vim.opt` vs `vim.o`	Para configurar opciones. `vim.o` para valores simples, `vim.opt` para manipular listas.
`require`	Para cargar módulos externos y dividir la configuración.
Paréntesis en llamadas	Obligatorio usar `()` al llamar funciones.
Referencias	Asignar una tabla a otra variable sin copiarla (ejemplo: `local vg = vim.g`).
`\_G (global)`	Tabla especial que contiene las variables y funciones globales accesibles en toda la configuración.
`package.loaded`	Permite ver o manipular qué módulos están cargados, útil para recargar configuraciones dinámicamente.

Fuentes y más Recursos

Cómo Hacer Túneles SSH

sebelk — Mon, 18 Nov 2024 00:00:03 GMT

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.

Como instalar Zabbix 7.x usando contenedores podman

sebelk — Sun, 10 Nov 2024 20:20:45 GMT

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.

Gestión de Contraseñas Usando Contenedores Podman

sebelk — Tue, 29 Aug 2023 22:06:14 GMT

Podemos administrar nuestros datos personales también con estándares profesionales. En este contexto, vamos a explorar cómo llevar la gestión de contraseñas usando utilizando herramientas viejas y confiables como pass, gpg, git combinada con la potente solución de contenedores Podman. Será una experiencia desafiante.

Almacenamiento de Contraseñas Elevado

Para gestionar nuestras passwords usaremos pass. La herramienta pass no estra cosa que un potente script de bash de algo más de 720 líneas de wrapper principalemente para gpg y git.

Ahora, lo realmente interesante: configuraremos un repositorio dentro de un contenedor Podman. Este repositorio, administrado con git, puede ser compartido de manera segura y efectiva en todos tus dispositivos.

Acceso Simplificado desde Cualquier Lugar

La accesibilidad es clave en tu entorno profesional. Ya sea trabajando en sistemas Windows o Linux, puedes aprovechar QtPass, una interfaz gráfica para pass. Para usuarios de iPhone, passforios es una excelente opción, mientras que los dispositivos Android pueden beneficiarse de Password-Store, disponible en Google Play Store y F-Droid para mantener tus contraseñas siempre sincronizadas.

Características Clave para Profesionales

Control Total: Somos nosotros quienes gestionan nuestros repositorios. Los datos sensibles están en tus dispositivos, evitando intermediarios y asegurando la confidencialidad.
Portabilidad Sin Esfuerzo: Se puede cambiar de dispositivos o realiza copias de seguridad con facilidad. Tu repositorio te seguirá sin problemas.
Seguridad de Alto Nivel: tus credenciales seguras con estándares de confiabilidad, integridad y disponibilidad.
Compartir con Confianza: Podrás compartirlo fácilmente en círculos de confianza.

Configuración Inicial y Uso Avanzado

En esta primera fase, te guiaremos a través de la configuración de tu repositorio en un contenedor Podman y las opciones para interactuar con él desde distintos dispositivos.

Nota 1:

El enfoque primordial es establecer un almacén personal de contraseñas. Además de utilizarlo en tus dispositivos, podrás extender su uso a usuarios de confianza. Aunque podría requerirse alguna asistencia técnica inicial para la configuración, las acciones esenciales son "actualizar desde el repositorio (pull)" y "enviar cambios al repositorio (push)".

Esta idea es adaptable a ambientes profesionales con para grupos reducidos de usuarios en una red corporativa, donde cada miembro tiene su copia del repositorio principal. El repositorio podría estar incluso en algún contenedor que esté disponible 24x7. Esto facilita la consulta, creación, modificación y eliminación colaborativa de contraseñas, consolidando luego los cambios en un repositorio compartido.

Nota 2:

Para aprovechar plenamente esta guía, asumimos que poseés conocimientos de:

Gestión de claves públicas ssh
Gestión de claves gpg
Uso básico de git
Uso básico de Podman
Conocimientos generales de Linux: bash, systemd, firewalld (iptables/nftables), etc.

¿Qué usaremos para lograr todo esto?

OS: Fedora 38
podman
pass

Se podría usar otra distribución, sin embargo es importante que cuente con una versión relativamente reciente de podman.

¿Por qué usamos podman? Porque tiene una gran similitud con docker, y además, posee la capacidad de correr contenedores de manera mucho más segura y sencilla. En este caso particular, crearemos un contenedor que alojará el repositorio compartido de passwords.

No será necesario crear servicios web y/o de bases de datos.

Instalación de paquetes

dnf install -y git pass

Inicialización de repositorio de passwords

En este ejemplo le pasamos los identificadores de las clave públicas gpg en el siguiente usamos 3 direcciones de mail correspondientes a la clave del host, la del celular y la de otra persona respectivamente.

pass init jkm@example.com fxi@example.com pyn@example.net

pass git init

pass generate puertablanca

Preparación del container

Creamos el siguiente Dockerfile

FROM fedora:38
RUN dnf update -y && dnf install -y git openssh-server
RUN useradd -ms /bin/bash git
RUN mkdir /home/git/.ssh
RUN ssh-keygen -A
COPY  ssh-pks /home/git/.ssh/authorized_keys
RUN echo "git ALL=(ALL:ALL) NOPASSWD: /usr/sbin/sshd" >> /etc/sudoers && git clone --bare /mnt/.password-store /home/git/.password-store && chown -R git:git /home/git  && chmod 700 /home/git/.ssh && chmod 600 /home/git/.ssh/authorized_keys
EXPOSE 22
CMD ["sudo","/usr/sbin/sshd", "-D"]

Esto nos permitirá crear un repositorio con las siguientes características:

Basado en Fedora 38
Un usuario llamado git que tendrá el único privilegio de correr el servicio ssh
Obtendrá una copia del repositorio git antes creado con pass

Crear la imagen de podman

podman build -v /home/sergio/.password-store:/mnt/.password-store -t passteiner .

Crear el container

podman run -d --name container-pass_git --user git -p 60003:22 passteiner

En este punto, ya estamos en condiciones de crear, editar, modificar nuestras passwords y subirlas al repo del contenedor de manera que esté disponible para otros dispostivos y/o usuarios.

Cabe aclarar que para usar Password Store en Android hace falta instalar OpenKeychain. Esa aplicación nos permitirá crear un el par de clave privada + clave pública GnuPG, como así también importar la clave pública del resto de los usuarios con quien compartiremos el llavero. Tener en cuenta que es muy importante la passphrase que usemos para cifrar nuestra clave privada: debe ser fácil de memorizar y a la vez robusta. Esa misma passphrase se nos pedirá cuando necesitamos acceder a las contraseñas:

Y luego con Password Store tendremos que:

Ingresar los parámetros de repositorio que está en el contenedor que hemos creado, tanto la url (por ejemplo ssh://git@10.0.0.10:60003/git/,password-store) y la branch (master).
Generar la clave pública ssh para autenticarse al repositorio. Esta clave tendrá que copiarse al archivo /home/git/.ssh/authorized_keys del contenedor.

podman exec container-pass_git bash -c 'echo "clave_publica_ssh" /home/git/.ssh/authorized_keys'

(Si queremos que este archivo sea persistente, podríamos modiicar el Dockerfile para que use un volumen).

Clonar el repositorio del contenedor.

Una vez que hemos clonado el repositorio, obtendremos el listado de passwords y el menú para operar con él:

Actualizando nuestro repositorio

Hay varias configuraciones posibles, pero la que recomiendo es la siguiente:

pass git config pull.rebase false

Para bajar las actualizaciones del contenedor:

pass git pull

Para subir las propias modificaciones al contenedor:

pass git push

Comentario finales

Al finalizar habrás conseguido que:

El contenedor se ejecuta como un usuario sin privilegios dentro del sistema.
Todo - excepto el proceso sshd - se ejecutará como un usuario sin privilegios aun dentro del container. Salvo que explícitamente uses algo como docker run --user root..... . Pero ¿por qué lo harías?
Por fuera del contenedor en realidad, mapea a nuestro propio usuario.

Enlaces útiles

3 pasos para configurar unidad de systemd para VM de Virtualbox

sebelk — Sat, 10 Sep 2022 16:17:19 GMT

Foto de Ashutosh Dave en Unsplash

1. Encontrar el UUID de la VM, por ejemplo si tenemos una máquina llamada RHEL7, ejecutamos:

$ VBoxManage showvminfo RHEL7 | grep '^UUID' | awk '{ print $NF }'
f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6

2. Crear el archivo template de servicio ~/.config/systemd/user/virtualbox_vm@.service:

[Unit]
Description=VirtualBox VM %i

[Service]
Type=simple
KillMode=mixed
ExecStart=/usr/lib/virtualbox/VBoxHeadless --comment RHEL7 --startvm f02a9f08-2ff2-4a92-b3cd-a8dfb17513c6 --vrde config

[Install]
WantedBy=default.target

3. Recargar systemd, Habilitar y arrancar el servicio

$ systemctl --user daemon reload && systemctl --user enable --now virtualbox_vm@RHEL7.service

¡Listo!

Tutorial: Cifrar $HOME con gocryptfs

sebelk — Wed, 12 May 2021 18:11:58 GMT

En un artículo anterior: Tutorial de fscrypt para cifrar archivos, habíamos visto como cifrar archivos con fscrypt y ext4. Ahora aprenderemos otro método independiente del sistema de archivos utilizado, se trata de una herramienta llamada gocryptfs.

Conocimientos previos necesarios:

Uso habitual de línea de comandos en Linux (incluyendo entre otros manejo de propietarios y permisos)
Instalación y desinstalación de paquetes

En el ejemplo en cuestión estoy usando Debian Buster (te recomiendo primero instalarla en una máquina virtual para hacer pruebas), de modo que los pasos a seguir pueden ser un poco diferentes en otras distribuciones, pero los principios generales se mantienen. Todos los pasos hasta que lo pruebes como usuario común deben hacerse con privilegios de superusuario.

Es muy importante contar espacio suficiente para copiar temporalmente los archivos del directorio que se desea cifrar.

He cambiado el shell del usuario sergio que es dash (predeterminado en Debian) por bash, ya que el primero no está pensado para un uso interactivo habitual además de ser menos potente.

Instalar grocryptfs

apt install grocryptfs

Crear el directorio para cifrar

mkdir /home/sergio_cifrado

Inicializar el directorio

Aquí seteamos la misma contraseña que la del usuario

gocryptfs --init /home/sergio_cifrado/
Choose a password for protecting your files.
Password: 
Repeat: 

Your master key is:

    9c43faf4-16a07508-42213628-50a5c55e-
    e0c17483-c41453a0-6355f9f0-897b3aa9

If the gocryptfs.conf file becomes corrupted or you ever forget your password,
there is only one hope for recovery: The master key. Print it to a piece of
paper and store it in a drawer. This message is only printed once.

The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs /home/sergio_cifrado MOUNTPOINT

Montar el directorio

mkdir /home/sergio_montaje_temporario && chmod 750 /home/sergio_montaje_temporario && chown sergio. /home/sergio_temporario &&
gocryptfs /home/sergio_cifrado/ /home/sergio_temporario/
Password: 
Decrypting master key
Filesystem mounted and ready.

Ajustamos los propietarios y permisos

chown -R sergio. /home/sergio{_cifrado} && chmod 750 /home/sergio_cifrado

Copiar todos los archivos del directorio del usuario al directorio temporal

cp -Tav /home/sergio /home/sergio_temporario

Borrar el contenido del directorio del usuario (por favor realizar previamente un backup)

rm -rf /home/sergio

Desmontar el directorio cifrado

fusermount -u /home/sergio_temporario

Le cambiamos el nombre al directorio temporario por el original

mv /home/sergio_temporario /home/sergio

Todo lo que viene a continuación es necesario cuando queremos que el directorio se monte de manera automática en el momento del login.

Instalamos el módulo de PAM para montaje de volúmenes

apt install -y libpam-mount

Ejecutamos el configurador de pam

pam-auth-update

y presionamos en Aceptar.

En otras distribuciones y configuraciones, puede ser necesario editar otros archivos del directorio /etc/pam.d.

Luego hay que editar el archivo /etc/security/pam_mount.conf.xml agregando lo siguiente antes de </pam_mount>:

<volume user="sergio" fstype="fuse" options="nodev,nosuid,quiet,nonempty,allow_other"
path="/usr/bin/gocryptfs#/home/%(USER)_cifrado" mountpoint="/home/%(USER)" />

Configuramos FUSE

# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
#mount_max = 1000

# Allow non-root users to specify the allow_other or allow_root mount options.
# Modificamos aquí:
user_allow_other

Eso es todo, felicitaciones si llegaste hasta aquí 😀, podemos reiniciar y probar la configuración:

Para login gráfico:

Conclusión

De esta manera pudiste configurar el cifrado automática de un directorio $HOME de un usuario. Este método es principalmente útil para equipos donde trabaja un solo usuario (podría ser tu laptop de trabajo diario por ejemplo).

Fuentes y más recursos

Tutorial de fscrypt para cifrar archivos

sebelk — Sat, 24 Apr 2021 13:30:29 GMT

Conocimientos previos necesarios:

Instalación de Linux.
Uso habitual de línea de comandos en Linux (incluyendo entre otros manejo de propietarios y permisos).
Instalación y desinstalación de paquetes.
Montaje de sistemas de archivos.

El sistema ext4 proporciona cifrado de bloques de datos y nombres de archivos. Veremos a continuación de algunas reglas generales para cifrar el directorio /home de un usuario.

¡Manos a la obra!

Los comandos precedidos por sudo indican que necesitan privilegios de root. Si querés usar sudo, sencillamente ejecutá como root:

usermod -aG sudo sergio

Obviamente aquí y en cada caso reemplazalo con tu usuario común.

Preparación del sistema de archivos

Algo que tendremos que hacer es habilitar la funcionalidad de cifrado, suponiendo que la partición de cifrado es /dev/sda1, haríamos:

sudo tune2fs -O encrypt /dev/sda1

Descarga y compilación

sudo apt update && sudo apt build-dep fscrypt

do apt -y install git && go get -d github.com/google/fscrypt/...

cd go/src/github.com/google/fscrypt/

make && sudo make install PREFIX=/usr

Configuración

Tenemos que actualizar la configuración de PAM, que servirán para desbloquear directorios al loguearse, bloquear al desloguearse, y cambiar contraseñas de acceso a los recursos cifrados.

sudo pam-auth-update

Para configurar globalmente:

sudo fscrypt setup

No se puede cifrar un directorio que ya tiene contenido, de manera que hay que crear un nuevo directorio, y luego migrar el contenido del directorio del usuario:

sudo mkdir /home/sergio_temp && sudo chown sergio.sergio /home/sergio_temp

fscrypt encrypt /home/sergio_temp

Allí podríamos elegir entre la contraseña del usuario, una passphrase o bien un archivo con clave 256-bit. En nuestro elegimos la primera opción, siempre teniendo en cuenta lo importante que es contar con una buena contraseña.

Luego chequeamos que esté todo en orden:

fscrypt status /home/sergio_temp

Ahora sí, migramos el contenido:

cp -av -T /home/sergio /home/sergio_temp

Bloqueamos el contenido del directorio

sudo fscrypt lock /home/sergio_temp --user=/home/sergio_temp

Probamos desbloquear

fscrypt unlock /home/sergio_temp

Si funciona podemos reemplazarlo por el nuevo directorio:

sudo su - mv /home/sergio{,_para-borrar}

mv /home/sergio{_temp,}

Luego al reiniciar podemos probar:

reboot

¿Cómo se ven los archivos cifrados?