MentorCruise

Como Compilar un kernel Linux en 10 pasos

Licencia de Creative Commons
Autor: Sergio Belkin. Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.

Advertencia

El kernel que viene con las distribuciones es suficiente para la mayoría de los casos. Usar un kernel compilado a mano puede dejar el sistema inusable sino se realiza correctamente. No debería usarse en sistemas en producción salvo que se sepa exactamente qué, por qué y para qué se hace. Hay distribuciones que limitan o no proveen el soporte en sistemas Linux con kernels compilados a mano. Siempre es recomendable hacer un backup tanto del directorio /boot como del directorio /lib/modules.

Motivación

Si no has leído la Advertencia por favor no sigas. Leela detenidamente y seguimos. ¿Ya está? ¡OK! ¿Por qué compilar un kernel hoy en 2020? Un razón es que al compilar se puede aprender que funcionalidades proporciona el kernel, deshabilitar funciones que sabemos no vamos a usar, probar nuevas características ausentes en la versión del kernel de la distribución y también para entender más cómo trabaja el sistema operativo. Este how-to ha sido probado tanto en Debian 10 como en CentOS 8. En una máquina con 2GB y un único procesador llevaría menos de una hora hacerlo (obviamente cuantos más sean los módulos o componentes agregados más va a tardar). Recordar que se puede compilar como un ususuario común y luego pedir privilegios de root para instalar. Basta de palabras y manos a la obra.

1. Instalar los pre-requisitos

yum groupinstall "Development Tools" && yum install ncurses-devel zlib-devel binutils-devel elfutils-libelf-devel libkcapi-hmaccalc openssl-devel

En Debian, deberíamos instalar:

apt -y install build-essential libncurses-dev

2. Bajar las fuentes del kernel

Recomendable bajar o la rama Longterm o bien la Stable, por ejemplo:

curl -L -O https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.15.tar.xz

3. Desempaquetar las fuentes

tar avxf linux-5.8.15.tar.xz

4. Entrar en el directorio de las fuentes

cd linux-5.8.15

5. Tomar como referencia el kernel que estamos usando

cp /boot/config-$(uname -r) .config

6. Tomar como base los módulos del kernel que están en uso actualmente 😉 😉

make localmodconfig

(Le damos Enter hasta que termine)

7. Configuramos nuestro kernel a medida

make menuconfig

Esta parte es la más importante. Podemos dejar todo como está pero probablemente haya algo que no estamos usando que no se va a compilar y necesitaremos después. Entonces es importante recorrer algunas secciones para revisar si falta algo, en especial lo que tiene que ver con Netfilter, File Systems, etc . Por ejemplo: tomar los recaudos suficientes si el sistema está virtualizado o si usa containers.

Una vez hecho los ajustes necesarios, guardamos y salimos.

8. Compilamos el kernel

make

9. Instalamos los módulos del kernel con privilegios de root

sudo make modules_install

10. Instalamos el kernel con privilegios de root

sudo make install

¡Listo! Podemos reiniciar y comenzar a usar el kernel compilado por nosotros mismos.

Uso de Paquetes en NeoVim

¿Qué es lo que hace grande a Neovim? Que posee pequeños, pero múy convenientes mejoras acorde a los nuevos tiempos, pero sin reinventar toda la rueda. A veces es buena tener que tirar todo abajo, crear algo completamente nuevo, y empezar todo desde cero. Sí, a veces, pero no siempre, Neovim mantiene todo lo bueno de Vim. Como lo dicen sus desarrolladores:

In matters of taste, prefer Vim/Unix tradition. If there is no relevant Vim/Unix tradition, consider the "common case".

Ya hemos hablado sobre Neovim alguna vez en Lo viejo, lo bueno y lo nuevo en Neovim . Se pueden extender las funcionalidades de neovim, de manera similar a las de su predecesor, el editor Vim. Estas extensiones están escritas en un lenguaje de scripting conocido también VimL. Las extensiones se conocen como plugins y es así como las llamaremos de aquí en más. También tengamos en cuenta que muchas de las cosas que discutiremos aquí aplican para Vim también.

Hay dos tipos de plugins:

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

Veamos un listado de estos archivos:

ls -l /usr/share/nvim/runtime/plugin
total 72
-rw-r--r-- 1 root root  2499 ago  4 21:07 gzip.vim
-rw-r--r-- 1 root root    45 ago  4 21:07 health.vim
-rw-r--r-- 1 root root   429 ago  4 21:07 man.vim
-rw-r--r-- 1 root root   107 ago  4 21:07 matchit.vim
-rw-r--r-- 1 root root  7085 ago  4 21:07 matchparen.vim
-rw-r--r-- 1 root root  9872 ago  4 21:07 netrwPlugin.vim
-rw-r--r-- 1 root root  1929 ago  4 21:07 rplugin.vim
-rw-r--r-- 1 root root  1778 ago  4 21:07 shada.vim
-rw-r--r-- 1 root root   236 ago  4 21:07 spellfile.vim
-rw-r--r-- 1 root root  2271 ago  4 21:07 tarPlugin.vim
-rw-r--r-- 1 root root 10466 ago  4 21:07 tohtml.vim
-rw-r--r-- 1 root root   202 ago  4 21:07 tutor.vim
-rw-r--r-- 1 root root  2510 ago  4 21:07 zipPlugin.vim
Plugin Funcionalidad
gzip Editar archivos comprimidos con gzip
health Framework para solucionar problemas de configuración
man Abrir páginas del manual en el editor
matchit Extiende la funcionalidad del comando %
matchparen Resalta paréntesis coincidentes
netrwPlugin Maneja la transferencia de archivos y listado de directorios remotos a través de una red
rplugin Manejo de plugins remotos
shada Datos Compartidos entre las sesiones de neovim
spellfile Descarga de archicos de ortografía
tarPlugin Exploración de tarballs
tohtml Conversor a html
tutor Tutorial
zipPlugin Exploración de archivos zip

Si consideramos el archivo del plugin man contiene lo siguiente:

" Maintainer: Anmol Sethi <anmol@aubble.com>

if exists('g:loaded_man')
  finish
endif
let g:loaded_man = 1

command! -bang -bar -range=0 -complete=customlist,man#complete -nargs=* Man
      \ if <bang>0 | set ft=man |
      \ else | call man#open_page(v:count, v:count1, <q-mods>, <f-args>) | endif

augroup man
  autocmd!
  autocmd BufReadCmd man://* call man#read_page(matchstr(expand('<amatch>'), 'man://\zs.*'))
augroup END

Estos scripts pueden contener comandos de modo normal y modo ex, estructuras de control, funciones, listas, diccionarios e incluso objetos.

Además, neovim posee una API con la cual se pueden hacer desarrollos en otros lenguajes de programación, es así como existe neovim-java - Java Client for Neovim API | neovim-java, neovimi (node.js), nvim-client - LuaRocks, equalsraf/neovim-qt: Neovim client library and GUI, in Qt5., etc.

neovim-qt

Se pueden escribir plugins en lenguajes distintos a VimL, por ejemplo 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

Paquetes de plugins

Paquetes

Photo by Handy Wicaksono on Unsplash

A partir de la versión 8.0 de Vim, el editor tiene la capacidad de instalar paquetes. Podríamos trazar una analogía con los paquetes RPM ( o deb), por ejemplo, el paquete rpm coreutils viene con más de una herramienta: tr, sort, tail; etc. Un paquete en vim de manera análoga puede contener más de un plugin.

Es decir, considerando el siguiente escenario:

Paquetes en Vim/Neovim .

El paquete nuake se va a cargar automáticamente al abrir el editor, mientras que el otro plugin vim-eunuch podrá activarse con el comando :packadd eunuch

Algo interesante en 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 paquetes que vamos agregando:

Gestores de plugins

Ahora bien, la manera nativa de manejar paquetes de Vim (que Neovim toma) es un tanto manual. Es muy ventajoso usar un gestor de plugins, el cual siguiendo la analogía con paquetes rpm (o deb) sería algo parecido a lo que representa yum/dnf/zypper respectivamente).

Existen varios gestores de plugins:

Yo uso 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.

Para deshabilitar todos los plugins se pueden desabilitar con nvim --noplugin.

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

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

"nuake plugin
Plug 'Lenovsky/nuake' , { 'on': 'Nuake' }  

nnoremap <F4> :Nuake<CR>

El paquete nuake no se cargará automáticamente en el inicio, pero lo hará cuando usemos el atajo de teclado F4. ¿No es genial?

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

Más Recursos

Tutorial de LXC

Containers

Photo by frank mckenna on Unsplash

LXC es una herramienta extraordinaria, algo intermedio entre un chroot y una máquina virtualizada completamente. Usando el mismo kernel que el sistema anfitrión podemos tener sistemas operativos invitados en el propio filesystem. Es decir, cada SO invitado en un directorio. Pero la documentación y la interacción de los distintos componentes puede tornar algo tricky el proceso. Cansado de lidiar con documentación desperdigada por aquí y por allá decidí crear mi propio tutorial. Intentando en lo posible ser distro-agnóstico.

Aquí está:

¡Espero que lo disfruten!

Un abrazo peligroso

¿Cuán genuino es la movida de Microsoft hacia el Software Libre?

dangerous

Photo by Samuel Scrimshaw on Unsplash

Recientemente Dona Sarkar dijo:

Windows no puede ser de código abierto por cuestiones como pueden ser nuestras políticas de privaciad y protección de datos. Un proyecto que empieza siendo de código abierto puede mantenerse así, pero uno que ha nacido dentro de un entorno cerrado, es más difícil de abrir.

Aquí nos presentamos con una falacia. Primero: ¿qué tiene que ver las políticas de privacidad y protección de datos con la apertura del código fuente?

Cualquiera con un mínimo de conocimiento profesional en informática encontrará esa explicación problemática.

¿Qué impedimentos tiene que tener el código fuente de un programa para contravenir las políticas de privacidad y protección de datos?

A mi en principio se me ocurren solamente dos, supongamos que tenemos un programa llamado ABC123 de la empresa ficticia Example Inc. Puede ser el que el código fuente utilce código patentado por otra empresa llamado AnotherOne Inc. En algún momento de la historia Example Inc. y Another Inc. hicieron un acuerdo de no revelación de código fuente.

Ese puede ser perfectamente un obstáculo para la revelación del código fuente. Pero claro en ese caso no tiene nada que ver con el interés por privacidad o la salvaguarda de los datos de los usuarios.

Otra posibilidad que sería ciertamente nefasta es que el programa almacene datos sensibles de las personas.

El código fuente de acuerdo a Wikipedia es

Es cualquier colección de código, posiblemente con comentarios escrito usando un lenguaje de programación legible por humanos, usualmente como texto plano.

Es decir, el código fuente es escrito por los programadores, los datos no forman parte y no debería haber razones para considerarlo así. Y si alguien considera que los datos sí forman parte es grave porque están utilizando los datos del usuario con fines comerciales.

Y el funcionamiento del programa ABC123 está desarrollado de una manera en el que sea imposible disociar los datos de del resto del código está ciertamente mal diseñado y el usuario está siendo damnificado por esa situación.

Lo cierto es que hasta ahora nadie le ha preguntado seriamente a Microsoft por qué no libera el código fuente de Windows.

Fuentes:

El principio de Le Châtelier

Ya siendo adolescente me fascinaba el principio de Le Châtelier que enuncia:

Si se presenta una perturbación externa sobre un sistema en equilibrio, el sistema se ajustará de tal manera que se cancele parcialmente dicha perturbación en la medida que el sistema alcanza una nueva posición de equilibrio.

No siempre los equilibrios son ventajosos, a veces necesitamos romperlo para conseguir un beneficio.

Crisis

unsplash-logo Jan Tinneberg

¿Qué sucede si pensamos esto en términos sociales?

De hecho, hay un principio similar en economía formulado por Paul Samuelson en 1947. En biología este concepto se conoce como homeostasis.

Probablemente, la humanidad nunca estuvo ante una perturbación del equilibrio desde la segunda guerra mundial o incluso desde la caída del muro de Berlín.

¿Qué está haciendo hoy el equilibrio para restablecer el equilibrio? Creo que es una pregunta.

Es importante que nuestros dirigentes estén en el aspecto ético a la altura de las circunstancias. Pero entendiendo también que viejos conceptos son insuficientes. Una discusión entre "más estado" o liberalismo no alcanza. Es importante entender el grado en que la tecnología hoy nos rodea. Para qué se usa. Quienes son los dueños.

En un tiempo en que todos corremos detrás de los servicio de Internet, creo que más que nunca tenemos que hacernos preguntas sobre ella. Cuestionarnos la obsesión por los datos, por la rapidez vacía de resultados benéficos reales sobre las personas.

Un tiempo para que podamos descubrir que un empleado feliz puede ser más creativo y más productivo. El trabajo del hombre respetando a la naturaleza y por ende al mismo hombre contenido en ella.

Por primera vez después de mucho tiempo empezábamos a perder la vergüenza de decir que las personas son más importantes que las ganancias económicas.

Sin embargo, pudimos ver claramente en los últimos días como han aparecido las fuerzas que pretenden restablecer un equilibrio que perjudica a las grandes mayorías, dentro las cuales están los que menos tienen.

Enlaces de Interés

OpenSSH, X11Forwarding y Wayland

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

red pipe with red ropes

Photo by JJ Ying on Unsplash

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

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

¿Qué es X11 Forwarding?

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

El Problema

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

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

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

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

Una tubería como camino

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

waypipe ssh usuario@servidorssh

waypipe

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

Más que mil palabras

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

Fuentes de Consulta y Más Recursos