Hoy me complace compartir con vosotros un nuevo episodio de Compilando Podcast, que ha vuelto con fuerza en forma de episodios tipo píldora muy instructivos. En esta ocasión se trata de un nuevo episodio que lleva por título «Veni, vidi… sudo — El poder prestado en GNU/Linux» donde Paco nos habla de esta potente y característica función de los sistemas libres.

2025: Año GNU/Linux en Compilando Podcast

En palabras del gran Paco Estrada, extraídas de la nueva web de Compilando Podcast y que sirven de introducción de este nuevo episodio:

s u d o es uno de los comandos más utilizados en GNU/Linux y Unix, pero también uno de los menos reflexionados.

En este episodio de Compilando Podcast inauguramos la miniserie Palabras de GNU/Linux con un recorrido histórico y divulgativo por sudo: su origen en Unix, su llegada a GNU/Linux y su papel clave en la administración de sistemas, la seguridad y la delegación de privilegios.

Hablamos de:

• Historia de sudo en Unix y GNU/Linux
• Administración de sistemas antes de sudo
• root, permisos y control de privilegios
• Seguridad, trazabilidad y responsabilidad
• Filosofía Unix aplicada a la línea de comandos

Un episodio para usuarios de Linux, administradores de sistemas, profesionales de ciberseguridad y cualquier persona interesada en la cultura y la historia del software libre.

---

Pregunta para la comunidad

¿Usamos sudo en GNU/Linux con la responsabilidad que implica
o lo hemos convertido en un simple hábito automático?

Música: https://incompetech.filmmusic.io/ by Kevin McLeod y musopen.org

Licencia : Creative Commons (CC BY-NC-SA)

Más información: Compilando Podcast

¿Qué es Compilando Podcast?

Dentro del mundo de los audios de Software Libre, que los hay muchos y de calidad, destaca uno por la profesionalidad de la voz que lo lleva, el gran Paco Estrada, y por el mimo con el que está hecho. No es por nada que ganó el Open Awards’18 al mejor medio, un reconocimiento al trabajo realizado por la promoción .

A modo de resumen, Compilando Podcast es un proyecto personal de su locutor Paco Estrada que aúna sus pasiones y que además, nos ofrece una voz prodigiosa y una dicción perfecta.

La entrada Veni, vidi… sudo — El poder prestado en GNU/Linux en Compilando Podcast se publicó primero en KDE Blog.

Hoy me complace compartir con vosotros un nuevo episodio de Compilando Podcast, que ha vuelto con fuerza en forma de episodios tipo píldora muy instructivos. En esta ocasión se trata del nuevo episodio que lleva por título «2025: Año GNU/Linux» donde Paco nos hace un resumen de este importante año para GNU/Linux.

2025: Año GNU/Linux en Compilando Podcast

En palabras del gran Paco Estrada, extraídas de la nueva web de Compilando Podcast y que sirven de introducción del nuevo episodio:

Puede que no haya habido un lanzamiento revolucionario ni sea el «Año de Linux en el escritorio”, pero 2025 se ha convertido, probablemente, en uno de los años más importantes para GNU/Linux en las últimas dos décadas.

En este episodio reflexionamos sobre cómo Linux ha consolidado este año su papel como pilar estructural del mundo digital, desde servidores, cloud e inteligencia artificial, supercomputación y desarrollo moderno. Además del salto en Gaming.
Repasamos:

• El escritorio GNU/Linux en 2025, un entorno maduro donde Wayland se consolida y GNOME y KDE alcanzan niveles históricos de estabilidad y usabilidad.
• La hegemonía absoluta de Linux en servidores, cloud e inteligencia artificial, sin alternativa real en infraestructuras críticas.
• El gran salto del gaming, con Steam como embajador y Proton como tecnología clave para ejecutar miles de juegos AAA en Linux.
• La presencia masiva (y a menudo invisible) de Linux en Android, WSL y contenedores.
• Los desafíos que aún persisten: fragmentación, escasa visibilidad para el gran público y un relato cultural que no acaba de cuajar, a pesar de haber ganado la batalla tecnológica. 2025 no ha sido el año de Linux en el escritorio.Pero sí ha sido el año en el que GNU/Linux dejó de ser “la alternativa” y se confirmó como la base indispensable del mundo digital moderno.

Un episodio editorial y reflexivo a punto de cerrar el año tecnológico y para abrir conversación con la comunidad.

Tu punto de vista importa y mucho:
¿Cómo has vivido tú el año 2025 en GNU/Linux?
¿Coincides con este análisis? ¿Discrepas? ¿Ha sido para ti también un año de consolidación?

Música: https://incompetech.filmmusic.io/ by Kevin McLeod y musopen.org

Licencia : Creative Commons (CC BY-NC-SA)

Más información: Compilando Podcast

¿Qué es Compilando Podcast?

Dentro del mundo de los audios de Software Libre, que los hay muchos y de calidad, destaca uno por la profesionalidad de la voz que lo lleva, el gran Paco Estrada, y por el mimo con el que está hecho. No es por nada que ganó el Open Awards’18 al mejor medio, un reconocimiento al trabajo realizado por la promoción .

A modo de resumen, Compilando Podcast es un proyecto personal de su locutor Paco Estrada que aúna sus pasiones y que además, nos ofrece una voz prodigiosa y una dicción perfecta.

La entrada 2025: Año GNU/Linux en Compilando Podcast se publicó primero en KDE Blog.

Relembrando os tempos dourados, deixo aqui no Viva O Linux, Um artigo onde veremos como libertar o seu AirPods para utilizá-lo na plataforma Linux com todos os recursos diferenciados deste hardware.

Quando você conecta um AirPods a um desktop Linux, normalmente ele funciona como “um fone Bluetooth qualquer”: áudio ok, mas boa parte dos recursos premium (ANC/Transparency, detecção de ouvido, bateria confiável, ajustes finos, etc.) fica presa ao ecossistema Apple. O LibrePods nasceu justamente para “libertar” esses recursos.

O que é o LibrePods

LibrePods é um projeto open source que desbloqueia recursos avançados dos AirPods em dispositivos não-Apple, trazendo de volta modos de ruído, transparência/adaptive, detecção de ouvido, status de bateria, modo “hearing aid”, personalizações e mais recursos que a Apple costuma expor só quando o fone “acha” que está conectado a iOS/macOS.

Para que serve (no Linux)

Na prática, no Linux ele serve como um painel/controle para o seu AirPods, com um app nativo (GUI) que expõe funções que normalmente não aparecem no stack Bluetooth padrão. O repositório mantém um app Linux dedicado e releases específicos.

Como ele funciona (visão técnica, sem magia)

O “pulo do gato” do LibrePods é que ele implementa (via engenharia reversa) partes do protocolo proprietário usado pelos AirPods para negociar recursos com dispositivos Apple. Em várias funções, a liberação depende de identificação do dispositivo host (ex.: fabricante/vendor), então o projeto também documenta mecanismos para o host “se apresentar” de forma compatível e o AirPods liberar telemetria e controles avançados. The Verge+1

Em outras palavras: não é “tweak de UI”; é protocolo + controle de estados (e, em alguns cenários, identificação do host) para acessar recursos que já existem no hardware do AirPods.

Vantagens para usuárias Linux

• Você usa o que pagou: ANC/Transparency/Adaptive e outros controles deixam de ficar “reféns” do iPhone/iPad/Mac.
• Status de bateria mais útil (incluindo case/earbuds, dependendo do modelo/estado do suporte).
• Experiência mais integrada: o projeto menciona melhorias de integração (ex.: expor bateria e atalhos de controle), e existe um app Linux com funcionalidades centrais.
• FOSS e auditável: por ser open source, dá para inspecionar/acompanhar evolução e limitar “apps caixa-preta” que só fazem polling genérico.

Observação importante de maturidade: o README do projeto sinaliza que o app Linux tem/teve uma fase “versão antiga” e que há trabalho em uma nova versão, então espere evolução rápida e possíveis arestas dependendo do seu modelo de AirPods e distro.

Requisitos no Linux

1) Hardware/stack Bluetooth

• Adaptador Bluetooth funcional no PC (interno ou dongle).
• BlueZ e serviços de Bluetooth ativos (padrão na maioria das distros desktop).

2) AirPods compatíveis

O projeto lista compatibilidades por modelo (alguns com suporte completo, outros parcial). Em geral, modelos mais recentes tendem a receber o “suporte cheio” primeiro.

Status	Device	Features
	AirPods Pro (2nd Gen)	Fully supported and tested
	AirPods Pro (3rd Gen)	Fully supported (except heartrate monitoring)
	AirPods Max	Fully supported (client shows unsupported features)
	Other AirPods models	Basic features (battery status, ear detection) should work

Dependências

Devemos garantir que o sistema de gerenciamento de audio e bluethooth esteja funcionando corretamento.

Qt6 packages

# For Arch Linux / EndeavourOS
sudo pacman -S qt6-base qt6-connectivity qt6-multimedia-ffmpeg qt6-multimedia

# For Debian
sudo apt-get install qt6-base-dev qt6-declarative-dev qt6-connectivity-dev qt6-multimedia-dev \
     qml6-module-qtquick-controls qml6-module-qtqml-workerscript qml6-module-qtquick-templates \
     qml6-module-qtquick-window qml6-module-qtquick-layouts

 # For Fedora
 sudo dnf install qt6-qtbase-devel qt6-qtconnectivity-devel \
     qt6-qtmultimedia-devel qt6-qtdeclarative-devel

 # For openSUSE
 sudo zypper install patterns-kde-devel_qt6

openSSL

# On Arch Linux / EndevaourOS, these are included in the OpenSSL package, so you might already have them installed.
sudo pacman -S openssl

# For Debian / Ubuntu
sudo apt-get install libssl-dev

# For Fedora
sudo dnf install openssl-devel

# For openSUSE
sudo zypper install openssl-devel

Libpulse e cmake

# On Arch Linux / EndevaourOS, these are included in the libpulse package, so you might already have them installed.
sudo pacman -S libpulse

# For Debian / Ubuntu
sudo apt-get install libpulse-dev

# For Fedora
sudo dnf install pulseaudio-libs-devel

# For openSUSE
sudo zypper install pulseaudio-qt-devel cmake libpulse-devel

Download, compilação e instalação.

Agora com todos requisitos instalado e cofigurado, efetue do download dos fontes com o comando git clone.

git clone https://github.com/kavishdevar/librepods

Após o download entra na pasta linux dentro da pasta librepods recém criada.

cd librepods/linux

Ao entrar na pasta, devemos criar a pasta build e os comandos cmake e make para efetuas a compilação.

mkdir build
cd build
cmake ..
make -j $(nproc)

Se tudo funcionou corretamente, teremos o binario librepods na pasta pronto para ser executado. Então basta digitar ./librepods e teremos uma tela como na figura a baixo e pronto! Boa liberdade.

Mais informações na página oficial do projeto. https://github.com/kavishdevar/librepods/

Me congratula presentaros el episodio 62 de KDE Express, titulado «esLibre 2026 con Jorge Lama» donde David Marzal habla de forma distendida con Jorge Lama, productor de un buen número de podcast libres, que nos informan sobre la próxima edición de este evento comunitario.

Episodio 62 de KDE Express: esLibre 2026 con Jorge Lama

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos 62 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En palabras de David:

Ahora si que casi entrando en periodo festivo, tenemos el honor de contar con el hombre detrás del audio de este podcast, nuestro querido Jorge Lama, que hoy salta delante del micrófono para informarnos sobre el evento de software libre más importante de España, esLibre.

• Web principal: https://eslib.re/2026/es/
• Voluntariado y necesidades especiales de dieta: https://eslib.re/2026/es/voluntariado/
• Servicio de cuidado infantil (solo si hay nº mínimo de peticiones): https://eslib.re/2026/es/cuidado-infantil/
• Propuestas: https://gitlab.com/eslibre/propuestas/-/merge_requests

¡Estaís a tiempo de reservar hotel, o enviar propuesta de charla/taller/sala/mesa!

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Episodio 62 de KDE Express: esLibre 2026 con Jorge Lama se publicó primero en KDE Blog.

in the previous blog pgtwin — HA PostgreSQL: VM Preparation we setup two VMs with KVM to prepare for a HA PostgreSQL setup. Now, we will configure the Corosync cluster engine, prepare PostgreSQL for synchronous streaming replication and finally configure Pacemaker to provide high availability.

Configure Corosync

Corosync has its main configuration file located at ‘/etc/corosync/corosync.conf’. Edit this file with the following content, change the IP Adresses according to your setup:

totem {
    version: 2
    cluster_name: pgtwin-devel
    transport: knet
    crypto_cipher: aes256
    crypto_hash: sha256
    token: 5000
    join: 60
    max_messages: 20
    token_retransmits_before_loss_const: 10

    # Dual ring configuration
    interface {
        ringnumber: 0
        mcastport: 5405
    }

    interface {
        ringnumber: 1
        mcastport: 5407
    }
}

nodelist {
    node {
        ring0_addr: 192.168.60.13
        ring1_addr: 192.168.61.233
        name: pgtwin1
        nodeid: 1
    }

    node {
        ring0_addr: 192.168.60.83
        ring1_addr: 192.168.61.253
        name: pgtwin2
        nodeid: 2
    }

}

quorum {
    provider: corosync_votequorum
    two_node: 1
    wait_for_all: 1
}

logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    timestamp: on
}

Next step is to create an authentication key for the cluster. Create the key on the first node, and then copy it to the other node:

corosync-keygen -l
scp /etc/corosync/authkey pgtwin2:/etc/corosync/authkey

Note, that by default you will not be allowed to access the remote node as root with ssh. This is a good standard for production sites. If you find that inconvenient, you can change the setting by adding a file to /etc/ssh/sshd_config.d. Don’t do this for production environments or externally reachable VMs though:

# cat /etc/ssh/sshd_config.d/10-permit-root.conf
PermitRootLogin=yes

On both nodes, make sure that the ownership and access rights are correct:

chmod 400 /etc/corosync/authkey
chown root:root /etc/corosync/authkey

Enable and start Corosync and Pacemaker:

systemctl enable corosync
systemctl start corosync

# Wait 10 seconds for Corosync to stabilize
sleep 10

# Check Corosync status
sudo corosync-cfgtool -s

# Enable and start Pacemaker
sudo systemctl enable pacemaker
sudo systemctl start pacemaker                                                                                           

Verify that the cluster is working with ‘crm status’

Configure PostgreSQL

PostgreSQL will only be configured on the first node. The second node will only need the data directory as well as the password file ‘.pgpass’ prepared, the pgtwin ocf agent itself will then perform the initial mirroring and final replication configuration of the database. Find the mentioned postgresql.custom.conf file at https://github.com/azouhr/pgtwin/blob/main/postgresql.custom.conf. This file holds the default configuration for use with pgtwin. You want to tweak the parameters according to your usage. Also make sure to use a password that is suitable for your environment.

# Initialize database
sudo -u postgres initdb -D /var/lib/pgsql/data

# Copy the provided PostgreSQL HA configuration
sudo cp /path/to/pgtwin/github/postgresql.custom.conf /var/lib/pgsql/data/postgresql.custom.conf
sudo chown postgres:postgres /var/lib/pgsql/data/postgresql.custom.conf

# Include custom config in main postgresql.conf
sudo -u postgres bash -c "echo \"include = 'postgresql.custom.conf'\" >> /var/lib/pgsql/data/postgresql.conf"

# Configure pg_hba.conf for replication
sudo -u postgres tee -a /var/lib/pgsql/data/pg_hba.conf <<EOF

# Replication connections
host    replication     replicator      192.168.60.0/24       scram-sha-256
host    postgres        replicator      192.168.60.0/24       scram-sha-256
EOF

# Start PostgreSQL manually (temporary)
sudo -u postgres pg_ctl -D /var/lib/pgsql/data start

# Create replication user
sudo -u postgres psql <<EOF
CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'SecurePassword123';
GRANT pg_read_all_data TO replicator;
GRANT EXECUTE ON FUNCTION pg_ls_dir(text, boolean, boolean) TO replicator;
GRANT EXECUTE ON FUNCTION pg_stat_file(text, boolean) TO replicator;
GRANT EXECUTE ON FUNCTION pg_read_binary_file(text) TO replicator;
GRANT EXECUTE ON FUNCTION pg_read_binary_file(text, bigint, bigint, boolean) TO replicator;
EOF

# Stop PostgreSQL (cluster will manage it)
sudo -u postgres pg_ctl -D /var/lib/pgsql/data stop

Also add the connection definition for your application connections to the pg_hba.conf file.

The PostgreSQL configuration only needs to prepare the password file now. This needs to be added to both nodes:

# cat /var/lib/pgsql/.pgpass
# Replication database entries (for streaming replication)
pgtwin1:5432:replication:replicator:SecurePassword123
pgtwin2:5432:replication:replicator:SecurePassword123
192.168.60.13:5432:replication:replicator:SecurePassword123
192.168.60.83:5432:replication:replicator:SecurePassword123

# Postgres database entries (required for pg_rewind and admin operations)
pgtwin1:5432:postgres:replicator:SecurePassword123
pgtwin2:5432:postgres:replicator:SecurePassword123
192.168.60.13:5432:postgres:replicator:SecurePassword123
192.168.60.83:5432:postgres:replicator:SecurePassword123

Also set correct permissions for this file, else PostgreSQL will refrain from using it:

chmod 600 /var/lib/pgsql/.pgpass
chown postgres:postgres /var/lib/pgsql/.pgpass

After adding .pgpass to the second node, you will only need an empty data directory on that node prepared:

mkdir -p /var/lib/pgsql/data
chown postgres:postgres /var/lib/pgsql/data
chmod 700 /var/lib/pgsql/data

Configure Pacemaker

The final step before starting the HA PostgreSQL for the first time is to configure pacemaker. For first time users of pacemaker, this is a daunting configuration, and it needs a lot of considerations. For now, retrieve the already prepared file https://github.com/azouhr/pgtwin/blob/main/pgsql-resource-config.crm and adopt it to your environment.

The values that you have to edit are:

• VIP address (virtual IP, that is migrated between the cluster nodes and serves as access address for all applications)
• Ping-Gateway address, that allows the cluster to prefer a node with access to the network
• Node Names in several resources, the defaults psql1 and psql2 will be come pgtwin1 and pgtwin2 respectively

After editing the file, load it into the cluster with the ‘crm’ command. The configuration can be done on any node, and will be available immediately from any node:

crm configure < pgsql-resource-config.crm

Thats it. The cluster will now try to bring up the PostgreSQL Database on both nodes in a HA configuration. You can monitor the process with the command ‘crm_mon’. Note, that in the beginning, the secondary node will have failed resources. This is due to the fact, that pgtwin has to perform an initial basebackup on that node. After a while, the output should look similar to this:

Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: pgtwin1 (version 3.0.1+20250807.16e74fc4da-1.2-3.0.1+20250807.16e74fc4da) - partition WITHOUT quorum
  * Last updated: Tue Dec 30 12:55:12 2025 on pgtwin1
  * Last change:  Tue Dec 30 12:55:07 2025 by hacluster via hacluster on pgtwin2
  * 2 nodes configured
  * 5 resource instances configured

Node List:
  * Online: [ pgtwin1 pgtwin2 ]

Active Resources:
  * postgres-vip        (ocf:heartbeat:IPaddr2):         Started pgtwin1
  * Clone Set: postgres-clone [postgres-db] (promotable):
    * Promoted: [ pgtwin1 ]
    * Unpromoted: [ pgtwin2 ]
  * Clone Set: ping-clone [ping-gateway]:
    * Started: [ pgtwin1 pgtwin2 ]

After the cluster stabilized, you can perform a number of tests to check the state:

# Check replication status
sudo -u postgres psql -x -c "SELECT * FROM pg_stat_replication;"

# Expected: One row showing pgtwin2 connected

# Check if in recovery mode
sudo -u postgres psql -c "SELECT pg_is_in_recovery();"

# Expected: t (true)

Congratulations, you got a HA PostgreSQL Database running. To access the database on the primary, just use the command:

sudo -u postgres psql

Since this has direct socket access, you will have full access to the database without password that way. For further tests and more information, have a look at https://github.com/azouhr/pgtwin/blob/main/QUICKSTART_DUAL_RING_HA.md.

In my last post Kubernetes on Linux on Z, I explained why I need a highly available PostgreSQL Database to operate K3s. Of course, a HA PostgreSQL that works with just two Datacenters has lots more usecases. Let me explain how to perform an initial setup like the one that I use for development.

Preparation of two VMs

The openSUSE Project releases readily prepared Tumbleweed images almost every day. Have a look at https://download.opensuse.org/tumbleweed/appliances/, I typically get an image from there that is named like ‘openSUSE-Tumbleweed-Minimal-VM.x86_64-1.0.0-kvm-and-xen-Snapshot20251222.qcow2’. The current image will have a different name, however lets go with this for now.

My typical KVM VMs use:

• 2 CPUs
• 2 GB memory
• Raw disk image format
• Two libvirt networks (ring0 and ring1)
• Both, graphical (VNC) and serial console support

First, convert the image to a raw image. The reason why I like to use this is, that it is much easier to loop mount such an image also in the local operating system, and also to increase the image with standard commands like kpartx, losetup and dd. You can go with qcow2, if you prefer that format.

qemu-img convert openSUSE-Tumbleweed-Minimal-VM.x86_64-1.0.0-kvm-and-xen-Snapshot20251222.qcow2 pgtwin01.raw

We will need two images of that kind:

cp -a pgtwin01.raw pgtwin02.raw

Since I like to use two network rings for the HA Setup (I will go into details why this is a good thing in a concepts blog soon), lets create two libvirt networks. Attachment of real Linux bridges would also be possible. Create two files ring0.xml and ring1.xml:

# cat ring0.xml
<network>
  <name>ring0</name>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr10' stp='on' delay='0'/>
  <ip address='192.168.60.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.60.2' end='192.168.60.254'/>
    </dhcp>
  </ip>
</network>

# cat ring1.xml
<network>
  <name>ring1</name>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr11' stp='on' delay='0'/>
  <ip address='192.168.61.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.61.2' end='192.168.61.254'/>
    </dhcp>
  </ip>
</network>

After that, define the libvirt networks, and enable autostart:

virsh net-define ring0.xml
virsh net-define ring1.xml
virsh net-autostart ring0
virsh net-autostart ring1

Now, lets setup the two VMs. The following command will bring up a VM and ask a number of initial questions. This is just the basic setup of a VM, nothing really special there:

virt-install \
  --name pgtwin01 \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/home/claude/images/pgtwin01.raw,format=raw \
  --import \
  --network network=ring0 \
  --network network=ring1 \
  --os-variant opensusetumbleweed \
  --graphics vnc,listen=0.0.0.0 \
  --console pty,target_type=serial

and the same with pgtwin02:

virt-install \
  --name pgtwin02 \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/home/claude/images/pgtwin02,format=raw \
  --import \
  --network network=ring0 \
  --network network=ring1 \
  --os-variant opensusetumbleweed \
  --graphics vnc,listen=0.0.0.0 \
  --console pty,target_type=serial

In case you want to connect to Linux Bridges, use “bridge=” instead of “network=”. Typically, I configure ssh to the two VMs, this normally has been done during the virt-install process. The minimal image from openSUSE by default configures both network devices with dhcp. This is an issue, because it will have two default gateways defined. Let me explain how to fix this:

# nmcli c s
NAME                UUID                                  TYPE      DEVICE 
Wired connection 1  29df9468-975d-3944-91ca-355ed0c82a3c  ethernet  enp1s0 
Wired connection 2  1f45b334-b429-3823-80eb-a3aafeb33195  ethernet  enp2s0 
lo                  611124a1-fa8e-48d6-84ba-f75733093ca6  loopback  lo

There is two external interfaces configured here. If you check the routing, you will find two default gateway definitions:

ip r s

In this setup, only ring0 is used to connect to the world, and thus the default gateway of ring1 (connected over enp2s0) can be deleted:

nmcli connection modify 1f45b334-b429-3823-80eb-a3aafeb33195 \
    ipv4.gateway "" \
    ipv4.never-default yes

Adopt the UUID and requirements to your setup.

For the Pacemaker and PostgreSQL configuration later on, also setup your hostnames and resolving of the other nodes. The procedure to set the hostname seems to have changed recently, and it now uses hostnamectl instead of just writing the name to /etc/HOSTNAME.

On pgtwin01:
hostnamectl set-hostname pgtwin01
On pgtwin02:
hostnamectl set-hostname pgtwin02

The resolving is either over your standard DNS system or with /etc/hosts. Find the used IP Addresses with ‘ip a s’

echo "192.168.60.13   pgtwin01" >> /etc/hosts
echo "192.168.60.83   pgtwin02" >> /etc/hosts

Configure the firewall to allow communication between the two VMs:

# Corosync communication
firewall-cmd --permanent --add-port=5405/udp  # Corosync multicast
firewall-cmd --permanent --add-port=5404/udp  # Corosync multicast (alternative)

# Pacemaker communication
firewall-cmd --permanent --add-port=2224/tcp  # pcsd
firewall-cmd --permanent --add-port=3121/tcp  # Pacemaker

# PostgreSQL
firewall-cmd --permanent --add-port=5432/tcp

# Reload firewall
firewall-cmd --reload

The last step for preparing the VMs is installing the cluster software as well as the PostgreSQL database software.

zypper install -y \
    pacemaker \
    corosync \
    crmsh \
    sudo \
    resource-agents \
    fence-agents \
    postgresql18 \
    postgresql18-server \
    postgresql18-contrib

After that, you have two VMs readily installed with two network connections. The next steps will be the setup of Corosync, the initial configuration of the PostgreSQL Database, and finally the cluster resource definitions.

Aunque el proyecto Podcast Linux está parado esto no significa que no tenga cabida en el blog y, mientras pueda, seguiré promocionándolo con la esperanza de que reviva, como cierto pájaro mitológico. Y he pensado hacerlo de una forma sencilla para mi y creo que beneficiosa para todos, creando poco a poco un índice de todas sus emisiones, de forma que podamos encontrar en este blog una alternativa a su magnífica obra. Así que bienvenidos al trigesimotercer audio de Podcast Linux – «Primer Directo Podcast Linux» donde Juan recoge los frutos de su maratón y realiza su primera emisión sin red.

Trigesimotercer audio de Podcast Linux – «Primer Directo Podcast Linux» (Podcast Linux #33)

Como los lectores del blog sabrán hace un tiempo Podcast Linux cerró sus emisiones por motivos que solo incumben a su creador. Desde el blog no quiero dejar que su recuerdo se desvanezca así que seguiré publicitando sus audios ya que su calidad no debe caer en el olvido.

Hace un tiempo decidí empezar por el principio, mostrando su primer audio, el cual no promocioné en su día y poco a poco hemos pasado ya los 30 episodios repasados.

De esta forma continuo con su trigesimosegundo audio de esta serie presentado en el blog, que en palabras de Juan:

**NOTA: Este directo es un experimento más que cierra mis pruebas de verano. Es un poco personal sin una temática definida donde cuento mis experiencias en los meses de julio y agosto. **
Muy buenas linuxeros y bienvenidos al primer directo de Podcast Linux. Después de solicitar a los oyentes qué plataforma desean para la emisión, Youtube fue la elegida y mediante OBS Studio, aplicación que ya hemos hablado, he intentado coger más experiencia en el streaming.
Comenté lo sucedido en este verano, con sus 5 episodios publicados y próximos temas a tratar.
También compartí la experiencia de ser parte del evento Maratón Linuxero, que tendrá lugar el 3 de septiembre.
maratonlinuxero.github.io.
Compartí comentarios de algunos oyentes y respondí algunas preguntas del chat del directo.
Me ha encantado la experiencia como otra herramienta más para acercarme a la audiencia.
La emisión de Youtube:
Toda la música utilizada en este episodio se distribuye bajo la licencia libre Creative Commons:
LukHash – The Other Side
TwoTriangles – House

Más información: Podcast Linux

Sigue a Podcast Linux

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:

• Twitter: https://twitter.com/podcastlinux
• Mastodon: https://mastodon.social/@podcastlinux/
• Correo: [email protected]
• Web: https://podcastlinux.com/
• Telegram: https://t.me/podcastlinux
• Telegram Juan Febles: https://t.me/juanfebles
• Youtube: https://www.youtube.com/PodcastLinux
• Feed Podcast Linux: https://podcastlinux.com/feed
• Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed

La entrada Trigesimotercer audio de Podcast Linux – «Primer Directo Podcast Linux» (Podcast Linux #33) se publicó primero en KDE Blog.

This year, I had the task of setting up a Kubernetes environment on a Linux Partition on a s390x system. At first sight, this sounds easy, there are offerings out there that you can purchase. The second look however can make you wonder. There is a structural mismatch between typical Linux on Z environments and Kubernetes:

While Linux on Z typically uses two datacenters as two high availability zones, Kubernetes requires you two have at least three.

This is a base foundation issue, that is not to overcome by just telling what you all did, you really have to get into the issue and find a solution. I might not know everything, however there is a solution that the rancher people developed, and it is called kine. This is an etcd shim, that allows to replace the etcd-database, which actually requires the three sites for its quorum mechanism, with an external sql database.

I am a little adventurous, and thus I told people, we can do that. The plan looked like this:

As you can see, Kubernetes talks to PostgreSQL over kine, and the HA functionality would be provided by PostgreSQL. This first thought was kind of naive, and needed a number of fixes.

1. PostgreSQL can do streaming replication, however the standard version cannot run a Multi-Master.
2. The only open source cluster solution that works for two nodes and I am aware of is corosync with pacemaker. However, the OCF Agents there are able to fail over, but after that, a DBA has to restore high availability. Patroni, as the standard solution for PostgreSQL in cloud environments today, does not solve the 2 Datacenter constraint for me.
3. The Kubernetes of choice was k3s, however the rancher people stopped releasing for s390x
4. All the needed containers are OpenSource, but many do not release s390x architecture, some even prevent from building that in their build scripts.

Together with a colleague I started to work on this project. Fortunately, we already had worked on zCX (Container Extensions on z/OS) and had provided many container images that were missing previously. To make development easier, we utilized OBS and worked on the images in a project that I created for that purpose. This can be found at “home:azouhr:d3v” for those interested. Thus, the fourth issue was just work, but not so much a real challenge.

The main challenges have been a Highly Available PostgreSQL that works on two nodes, as well as building k3s in a reasonable way for s390x. Let me get into some more details of using Corosync and Pacemaker with two node clusters, and what is needed to make that work with PostgreSQL.

Corosync and Pacemaker are a solution that is used in the HA product of the SUSE Enterprise Server, and it actually supports two nodes if you have a SBD (Storage-Based Death) device at hand. This is typically not an issue for Mainframe environments, because those machines normally do not have local disks anyways and always operate a SAN.

Pacemaker uses OCF-Agents, that operate certain programs. In my case, this would be PostgreSQL. I have been writing on such agents long ago, however it is kind of a daunting prospect to write an agent from scratch, especially when you have to learn the tasks of a PostgreSQL DBA along the process. After pushing the task off for some time, my colleague suggested to try an AI to get started, and what can I say, I was positively surprised with the result. I chose to give it a try. Since I did not want the KI to have too many rights on my home laptop. The setup I am using looks like this:

I know that many developers don’t like what they get from a AI, and I have to admit, I did not even try to run the first three or four versions that the AI produced. However after a while, the solution stabilized, and I could concentrate on smaller aspects of the OCF agent that “we” created. A recent state of what we produced can be found at https://github.com/azouhr/pgtwin. Note, that I did by far not publish all the different design documents, this would be more than 250 different documents, talking about different aspects of how the OCF agent should operate.

Some experiences with the KI:

• KIs like to proceed, even if a thought is not ready. Working on the design is important, just don’t let a KI produce code, when you are not yet confident, that you are at the same level of understanding.
• KIs can easily skim through massive amounts of log files, and also find and fix issues on their own. I personally like to challenge solutions to issues, when I feel that the solution is not perfect. This may lead to several iterations of new proposed solutions.
• KIs sometimes solve issue A and break B, only to solve B and break A. They are happy to go on like this forever. Whenever you find a problem reoccurring, you have to get deeper into the issue. Let the KI explain what happens, create assumptions and let it explore different paths.
• KIs sometimes stumble into the same issues that have been discussed earlier. I found that starting the discussion over again is tedious. Instead, ask the KI why it cannot use the solution from the previous location.
• KIs sometimes try to figure things out without having enough data. Instead of adding debug information or tracing like any programmer would do, they just start experimenting. It often helps a great deal, just to tell them to switch on tracing, or to use things like strace to get more information.
• Finally, you always have to manually review the result. My personal procedure is to add comments into the code that can be easily found with grep, and later tell the KI to fix the comments.
• KIs have a date weakness. They like to confuse years and other numbers in dates. That’s why the release dates of pgtwin look confusing.
• A little warning about documentation and promotion. Obviously KIs have been trained a lot with marketing procedures. They typically claim something is enterprise ready as soon as it did run once. After being “enterprise ready” I typically find quite a number of issues just by looking at the code.
• Still it is impressive, how easy the code can be read, and how well it is documented. For someone who did read quite some code in history, it is really nice to look at the code. Also the amount of coding would not be possible in that short timeframe by a normal developer.

In my next post, I will go over the design of https://github.com/azouhr/pgtwin and explore the main features and concepts that I have been working on for the last weeks. I hope to create another bugfix release soon, however the agent already works quite well as it is now.

El increíble el trabajo de promoción que está realizando Nate Graham en su sección del KDE Planet llega a su aniversario con una entrada muy especial. Y es que ya son 8 años de esta semana en Plasma el resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal apenas ha fallado (no digo que nunca porque en realidad no lo sé) y desde hace un tiempo me he dedicado a traducir sus artículos al castellano utilizando los magníficos traductores lo cual hará que la gente que no domine el inglés esté al día y que yo me entere bien de todo. No obstante, el artículo de hoy no es como los demás, es una reflexión sobre el trabajo realizado y y una llamada a la colaboración más directa para los simpatizantes del proyecto KDE. ¿Te intriga? Sigue leyendo.

8 años de esta semana en Plasma

Hoy no realizaré una traducción pormenorizada, creo que los mejor es leer el artículo original en Blogs KDE. Simplmente realizaré un resumen del mismo y os invito a leerlo de forma integra y en el idioma original.

Para ponernos en contexto, Esta semana en Plasma (This Week in Plasma aka TWiP) comenzó en 2017 como un informe de desarrollo enfocado en el objetivo comunitario de «Usabilidad y Productividad» de KDE, inicialmente en el blog personal de Nate y luego en la infraestructura oficial de KDE, ganando gran popularidad por mantener informada a la comunidad sobre avances semanales.

A lo largo de este tiempo, la vida profesional del desarrollador ha evolucionado drásticamente: empezó como voluntario dedicando tiempo en trayectos de tren, pasó a un empleo a tiempo completo en Blue Systems en 2019, fue elegido al consejo de KDE e.V. en 2022 y, a inicios de 2025, se convirtió en copropietario y CEO de Techpaladin Software, empresa que emplea a más de una docena de desarrolladores KDE destacados.

Estas transiciones, según sus palabras, han acumulado responsabilidades que han limitado su tiempo, afectando la calidad y regularidad de TWiP en el último año, por lo que se disculpa públicamente [lo cierto es que pocas veces he visto esa merma de calidad pero si él lo dice…].

No obstante, esta vida nos atropella y anuncia que en 2026 se reducirá la frecuencia de publicaciones a cada 2-4 semanas y, creo que esto es muy importante, busca activamente un sucesor o equipo para continuar TWiP.

Nate destaca que el proceso no requiere habilidades técnicas avanzadas —solo tiempo para recopilar cambios relevantes, escribir resúmenes breves, capturar pantallas y editar con Markdown y Git—, y ofrece mentoría completa a interesados, contactables vía [email protected] o el canal Matrix de KDE.

Para finaliza el artículo, Nate reconoce el crecimiento de KDE, con más usuarios, socios de hardware, distribuciones que lo preinstalan y financiamiento de donantes pequeños, haciendo TWiP menos esencial pero aún valioso. Agradece a lectores y comunidad por el apoyo recibido y, para quienes no puedan colaborar directamente, invita a donar a la campaña de fin de año 2025 de KDE, que ya ha superado récords con más de 325.000 € recaudados, asegurando la independencia del proyecto.

Así que ya sabéis, si domináis el inglés y queréis aportar vuestro granito de arena no dejéis de enviar vuestra propuesta, este tipo de trabajo es imprescindible para el buen funcionamiento de la Comunidad.

La entrada 8 años de esta semana en Plasma se publicó primero en KDE Blog.