Dear Tumbleweed users and hackers,

Another week has gone by, and despite me claiming we won’t be using openQA anymore (hey, it was April 1st; you should know not to trust anything you read on that day), we are of course very much relying on it. Tumbleweed couldn’t possibly be as stable as it is without the help of openQA and the fabulous team developing and maintaining it. So since last Friday we have thrown a full set of 7 snapshots at openQA and received a ‘go’ back for all of them. so we pushed out 7 snapshots (0331, 0401, 0402, 0403, 0404, 0405, and 0406)

The major changes included in those snapshots were:

• Linux kernel 5.17.1
• KDE Plasma 5.24.4
• SQLite 3.38.2
• Mesa 22.0.1
• Pipewire 0.3.49
• openldap 2.5.9 (upgraded from 2.4.59)
• dracut 056
• gcc12: it is providing the base libraries like libgcc_s1, libstdc++6, but it is not yet the default compiler. That will comea bit later
• procps 4.0.0: note: a few issues have been found that could be attribute to this, like salt not being able to parse the resulting output when distributing sysctl values
• autoconf 2.71: a bunch of packages fail to build now. A common thing I’d seen is gettext translation catalogs wrongly being installed to /usr/locale (instead of /usr/share/locale). Most package seem to be old and rather under-maintained (most, nost all!)
• Full RelRO (-z now) has been enabled by default for all builds. Partial RelRo was enbable around the timeframe of SUSE Linux 10.1, about time to move one level up

Currently, we’re testing these changes in the staging areas:

• LLVM 14
• Podman 4.0.3
• Rust 1.60
• Pytest 7
• GCC 12 as default compiler

A new default GNU Compiler Collection for openSUSE Tumbleweed is set to follow one of the snapshots that rolled out this week.

Snapshot 20220405 prepares the default compiler switch to GCC 12. GCC 12 is now providing the libgcc standard libraries. It is not yet the default compiler, but that will follow at a later date.

The most recent snapshot that came out after the switch was 20220406. This snapshot updated five packages. One of those updated packages was autoconf 2.71. Configuration scripts from the latest autoconf improved compatibility with C-variant front end compiler clang and compatibility was restored with automake’s rules for regenerating a configuration. The Linux SCSI target framework tgt package updated to version 1.0.82 and added support for listening on a random port. Other packages to update in the snapshot were xf86-video-dummy 0.4.0 and yast2-slp-server 4.5.0.

The 20220405 snapshot prepares GCC 12 to become the default compiler at a later date for the rolling release and it had multiple packages updated in the snapshot. New packages were inherited from GCC 11 with the GCC 12.0.1 update, and the compiler provides the conflicts to glibc crosses since only one GCC version for the target can be installed at the same time; the same thing was done for libgccjit as well. Translations were updated in the gedit 42.0 update. An update in the new dracut version does not use network-wicked as default the network handler. The update of text shaping engine harfbuzz 4.2.0 fixed the handling of contextual lookups. The word selection error in Arabic text was fixed in libreoffice 7.3.2.2 and four crashes with various circumstances and inputs were fixed. Other notable updates in the snapshot were libvirt 8.2.0, aws-cli 1.22.87 and file synchronizer unison 2.52.0.

The 20220404 snapshot gave Xfce users a file manager update to thunar; the 4.16.11 thunar version fixed a few reloading views, prevented a crash on malformed bookmarks and updated translations. Smoother rendering of a clock’s hands were made in the xclock 1.1.0 update. The printing package cups-filters 1.28.12 had some resolution and image size fixes. Other packages to update in the snapshot were xwayland 22.1.1, ceph 16.2.7, yast2-installation 4.4.51 and more.

Added support for the Zstandard compression algorithm was made in the 20220403 snapshot with the kdump 1.0.2 update; kdump also removed a few patches for the crash dumps feature of the Linux Kernel. New features were added in the update from gnome-logs 3.36.0 to 42.0. Some of those features include opening journal files directly and several keyboard shortcuts to help with overlay. There were also window sizing improvements in the gnome-logs upgrade. An update of libsoup 3.0.6 had miscellaneous HTTP/2 fixes, meson build improvements and fixed build issues with Visual Studio. A few other packages were updated in the snapshot.

The second snapshot of the month, 20220402, had several package updates. The minor update of ImageMagick 7.1.0.28 fixed a couple buffer overflows and 3D Graphics Library Mesa 22.0.1 fixed some maintainer scripts and panfrost drivers. Some documentation was added in the firewalld 1.1.1 update about container host integration and a build fix was made for the use of dbus inside a container. A Common Vulnerabilities and Exposure was addressed in the openvpn 2.5.6 update; the vulnerability could allow for a possible authentication bypass in external authentication plug-in. Bluetooth Advanced Audio Distribution Profile streaming was improved and reduced stuttering was made on some devices with the PipeWire 0.3.49 update. Several other packages updated in the snapshot.

Konqi fans had an update to Plasma 5.24.4 in the 20220402; the update provided fixes mostly for KWin and Plasma Workspace. Window flickering was fixed with the update for KWin when a clip intersected with the blur region and Plasma Workspace fixed some weird behavior with the lockscreen. Other packages to update in the snapshot were ncurses 6.3.20220319, expat 2.4.8, sqlite3 3.38.2 and more.

Sigo ampliando las noticias de este magnífico evento que se va a celebrar el 29 y el 30 de baril en Rovereto, Italia. Y es que aunque ya lleva un tiempo accesible no había comentado en el blog que ya está abierto el registro a Linux App Summit de 2022, el evento híbrido que une desarrolladores de todo entornos de trabajo.

Abierto el registro a Linux App Summit 2022

Para los que vayan un poco despistados el próximo 19 y 30 de abril se celebra la Linux App Summit 2022 en Rovereto, Italia, un evento que realizará una modalidad híbrida, que combinará sesiones presenciales y a distancia, incluyendo charlas, paneles y preguntas. Además, los vídeos de LAS se transmitirán en directo en su canal de YouTube. En mi opinión, este es el futuro de todos los eventos.

Hace relativamente poco anuncié el programa de charlas y hoy quiero comentarios que se ha abierto el registro a Linux App Summit 2022 con lo que se podrá contar asistentes y poder medir y mejorar ediciones venideras. Para hacerlo simplemente debéis seguir este enlace.

¿Qué es Linux App Summit (LAS)?

El año pasado se celebró en Barcelona y fue un éxito, como lo demuestra la fotografía superior donde aparecen algunos de los participantes.

Linux App Summit es un evento diseñado para acelerar el crecimiento del ecosistema de aplicaciones Linux sea cual sea su entorno de trabajo.

De esta forma se reúne a todos los involucrados para intentar optimizar la experiencia de usuario de aplicaciones GNU/Linux, compartiendo el conocimiento que se tiene del uso y problemas de sus respectivos programas.

Estamos ante un evento que va en contra del mito que los desarrolladores de los distintos entornos de escritorio se llevan como el perro y el gato, todo lo contrario ya que aunque utilizan librerías diferentes el objetivo es el mismo: crear las mejores aplicaciones posibles para los usuarios.

Más información: Linux App summit

La entrada Abierto el registro a Linux App Summit 2022 se publicó primero en KDE Blog.

No estilo Metaverso (Avatar, contatos virtuais e outros) podemos ter uma lavoura de grãos onde utiliza diversos recursos e conta com máquinas de gigantes como Case IH, New Holland, John Deere, Massey Ferguson, Valtra e outras para plantar e colher.

“Metaverso”, terminologia para um universo virtual no qual as pessoas vão interagir entre si por meio de avatares digitais. Embora o termo tenha se popularizou, muitas iniciativas criou um universo digital para a interação entre jogadores e com a presença de um imersão realistas. O lançamento do Farming Simulator 22 é um exemplo prático. Este projeto baseia-se na rotina do agronegócio, assim proporcionando ensinamento e simulação.

O projeto permite operar isoladamente ou em conjunto, onde o objetivo é dividir os espaços, escolher o negócio adequado, e se atentar aos desafios gerados pelos ciclos sazonais e o clima do planeta.

Camisetas, gorras, sudaderas, pegatinas, tazas y mucho más de openSUSE dispoibles en freewear.org

No es la primera vez que escribo sobre la tienda online freewear.org, incluso publiqué una entrevista con Ramón y Xulia, las personas que desde Galicia en España la gestionan:

• https://victorhckinthefreeworld.com/2021/03/04/freewear-org-tu-tienda-geek-entrevista-exclusiva-a-los-creadores/

En este caso, de nuevo porque me apetece y sin que medie ni publicidad ni otras contrapartidas, porque hay novedades en cuanto a los productos sobre openSUSE que ofrecen en su tienda.

Freewear.org es una tienda online de productos de merchandaising relacionados con diversos proyectos de software libre, GNU/Linux y relacionados.

En este caso, ya que soy fan de la distribución de GNU/Linux openSUSE, y quizás muchas personas que recalan por el blog también lo son, quiero comentar que hay nuevos artículos relacionados con openSUSE en freewear.org.

Así, a las camisetas y polos con estampados de buena calidad sobre openSUSE Leap o Tumbleweed, también hay que añadir otros elementos para mostrar que somos geeks y además apoyar al proyecto.

Tenemos tazas, gorras, camisetas para los más pequeños, nuevos diseños de pegatinas, que se unen a los polos, camisetas, pegatinas hexagonales o vinilos. Con diseños que muestran al camaleón de openSUSE y con variedad de diferentes diseños y colores.

Además como con cada compra que realices en freewear.org, tanto de openSUSE como con otros proyectos que difunden, parte del dinero de la compra se dona a los propios proyectos.

Así además de tener tu taza, camiseta o lo que sea sobre tu distribución de GNU/Linux preferida, también has aportado dinero para el mantenimiento de dicho proyecto ¡todos ganamos!

Echa un vistazo al nuevo material sobre openSUSE que Ramón y Xulia han preparado en freewear.org y si te convence date un capricho o regala a alguien que conozcas.

Lo cierto es que me está gustando la recepción de la consola de Valve. Y más cuando aparece el escritorio Plasma de la Comunidad KDE. Es por ello que compartir este vídeo que he traducido como «Usando Steam Deck como un PC » de ETA PRIME y que refleja la cantidad de contenido que está generando este dispositivo.

Usando Steam Deck como un PC – Vídeo

Debo empezar diciendo tener una consola portátil no es una de mis prioridades en mi vida ya que no tengo tanto tiempo libre como para exprimir este dispositivo… pero claro, si además de tener un aparato lúdico que se convierte en un pequeño pero potente PC la cosa puede cambiar en un futuro.

Personalmente todavía tengo mi portátil Slimbook que me sirve para todo y que va como una mala bestia (y más con una ampliación que ha recibido recientemente) , pero es que las posibilidades de la Steam Deck de Valve, las buenas impresiones iniciales y su excelente conectividad empiezan a hacer que mis prioridades pueden cambiar en el futuro, al tiempo que apoyaría un proyecto que creo muy necesario para el mundo GNU/Linux.

Y como muestra de las palabras anteriores quiero compartir con vosotros un vídeo titulado «Yes, You Can Use the Steam Deck Like A Real PC! It’s Awesome! Desktop Mode Hands-On» en el que su creador ETA PRIME nos muestra las posibilidades de utilizar esta consola como un verdadero PC de escritorio conectándolo a un monitor externo y con un teclado y ratón inalámbricos.

Además, nos muestra como utilizando Discover se puede llegar a instalar el editor de fotos libre GIMP, el editor de vídeo de la Comunidad KDE KdenLive y la suite ofimática LibreOffice.

Características del Steam Deck

Si está interesado, las características básicas de este dispositivo son las siguientes:

• Interfaz gráfica Plasma Desktop.
• Procesador: APU AMD, con CPU Zen 2 4c/8t, 2.4-3.5 GHz y una GPU de 8 RDNA 2 CUs, 1-1.6 GHz.
• Disco duro: 65 GB, 256 GB o 512 GB, según modelo.
• 16 Gb de Memoria RAM.
• Pantalla táctil LCD de 7 pulgadas con una resolución 1280×800.
• Batería entre dos y ocho horas de juego (es evidente que esto es muy variable cuando hablamos de videojuegos).
• Sistema operativo: Steam OS, que no es más que un Arch Linux modificado.
• Conectividad inalámbrica: Wi-fi, Bluetooth 5.0.
• Control: doble botonera digital y analógica, 2 gatillos y 4 botones auxiliares bajo de la consola y dos touchpads a ambos lados de la pantalla.
• Conectividad: USB-C
• Dock opcional para conectarlo a una pantalla grande.

Más información: Steam

La entrada Usando Steam Deck como un PC – Vídeo se publicó primero en KDE Blog.

For many years, you could use the match() filter of syslog-ng to parse log messages with regular expressions. However, the primary function of match() is filtering. Recent syslog-ng versions now have a dedicated regular expression parser, the regexp-parser(). So, you should use match() only if your primary use case is filtering. Otherwise, use the regexp-parser for parsing, as it is a lot more flexible.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/using-the-regexp-parser-of-syslog-ng

El producto de software libre y de código abierto multiplataforma ahora es reconocido oficialmente por el diseño de software sostenible

Este artículo es una traducción que he realizado del artículo original en inglés escrito por Joseph publicado en eco.kde.org el 16 de marzo de 2022 y publicado bajo licencia CC-by 4.0 y que puedes encontrar en este enlace:

• https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/

Les he enviado mi traducción al castellano para que la publiquen en su web, pero también quería publicar el artículo en mi blog. Espero que te resulte interesante. ¡Comenzamos!

Okular, el popular lector de PDF multiplataforma y visor universal de documentos de KDE, ha sido reconocido oficialmente por su diseño de software sostenible, como se refleja en los criterios de adjudicación recientes para la ecocertificación de software.

En febrero de 2022, Okular recibió la etiqueta ecológica Blue Angel, la etiqueta ambiental oficial otorgada por el gobierno alemán. Presentada en 1978, Blue Angel es la etiqueta ambiental establecida más antigua del mundo, y Okular es el primer producto de software certificado con su sello. ¡Además, Okular es el primer programa informático con certificación ecológica dentro de las 30 organizaciones de la Global Ecolabelling Network! Esta red, de la que Blue Angel es miembro, representa a más de 50 países.

KDE es una comunidad mundial de ingenieros de software, artistas, escritores, traductores y creadores comprometidos con el desarrollo de software libre. Con la misión a largo plazo y la visión rectora de KDE, así como el talento y las capacidades de las personas de su comunidad, no sorprende que KDE sea pionera entre el grupo de personas y organizaciones en impulsar una discusión sobre software sostenible. Este grupo incluye al propio Blue Angel y a los investigadores que lo respaldan, patrocinadores como la Free Software Foundation Europe, otros proyectos de software libre y un número creciente de otros proyectos. Ahora, con el primer producto de software con certificación ecológica, la comunidad de KDE está celebrando el logro junto con la comunidad de software libre en general, así como con el departamento de ciencias de la computación en Umwelt Campus Birkenfeld, donde los investigadores midieron el recurso y el consumo de energía de Okular y otro software de KDE.

KDE se fundó en 1996 y mantiene numerosos productos de software libre y de código abierto, incluido el entorno de escritorio Plasma; el programa de diseño para pintores y artistas gráficos, Krita; el conjunto de actividades educativas para niños GCompris; Kdenlive, un producto de software de edición de video profesional; y, por supuesto, Okular, un programa informático esencial que le permite ver todo tipo de documentos, incluidos PDF, cómics, artículos científicos y académicos y dibujos técnicos. Okular también le permite verificar firmas digitales y firmar documentos usted mismo, así como incluir texto anotado y comentarios directamente incrustados en el documento.

Los criterios del premio Blue Angel para software, con su enfoque en la transparencia en la eficiencia energética y de los recursos, la vida útil del hardware y la autonomía del usuario, brindan un punto de referencia excelente para iniciar una discusión sobre la sostenibilidad del software e impulsar el desarrollo en esta área. Y así, en 2021, KDE inició KDE Eco, un proyecto con el objetivo de poner a KDE y al software libre a la vanguardia del diseño de software sostenible. La sostenibilidad no es un objetivo nuevo para el software libre y de código abierto (FOSS por sus siglas en inglés). Las cuatro libertades siempre han puesto al software libre a la vanguardia del diseño de software sostenible. Lo nuevo es que organizaciones como la Agencia Ambiental Alemana (Umweltbundesamt), que desarrolló los criterios de adjudicación, ahora reconocen que los valores de FOSS están directamente relacionados con la sostenibilidad.

El Blue Angel se otorga a una gama de productos y servicios, desde productos de papel hasta materiales de construcción e impresoras. En 2020, la Agencia Alemana de Medio Ambiente amplió los criterios de adjudicación para incluir productos de software, y fue el primero en el mundo de las certificaciones ambientales en vincular la transparencia y la autonomía del usuario con la sostenibilidad. Para obtener la etiqueta ecológica, un producto de software debe demostrar que cumple con una lista de requisitos estrictos considerados críticos para el medio ambiente durante el ciclo de vida del producto. Estos incluyen brindar transparencia en el consumo de energía al usar el software, por ejemplo, en el caso de Okular, al leer o anotar un PDF, y la capacidad de ejecutar la aplicación en hardware de al menos cinco años. Los criterios del premio Blue Angel también incluyen una lista de requisitos de autonomía del usuario que reducen el impacto medioambiental del software.

Todos estos criterios reflejan los valores de KDE y los del movimiento FOSS más amplio a la perfección. Con el software libre y de código abierto, se garantiza la transparencia y se entrega el control a los usuarios, en lugar de que los vendedores o proveedores de servicios lo retengan. Esto permite a los usuarios decidir qué quieren del software que utilizan y, con demasiada frecuencia, también del hardware. Por ejemplo, los usuarios pueden reducir el consumo de energía de sus programas sin pérdida de funcionalidad, ya que pueden instalar solo lo que necesitan, ni más ni menos; y evitar las opciones de publicidad y minería de datos, que ejecutarían procesos innecesarios en segundo plano y aumentarían el consumo de recursos. En cuanto a los desarrolladores de FOSS, por lo general continúan admitiendo hardware que la industria estaría ansiosa por dejar obsoleto, brindando a los usuarios software actualizado y seguro para dispositivos que, de lo contrario, podrían desecharse como desechos electrónicos y terminar contaminando los vertederos. En resumen, como consecuencia de las libertades y la transparencia de los usuarios garantizadas por una licencia de software libre, los usuarios y las comunidades pueden influir en los factores que determinan el consumo de recursos de su software.

Publicado bajo la licencia GPLv2+, Okular es software libre y de código abierto, por lo que ya cumplía con muchos de los criterios de autonomía del usuario necesarios para obtener el sello de aprobación Blue Angel. Se llevó a cabo más trabajo para hacer que Okular cumpliera totalmente con todos los criterios de Blue Angel y fuera reconocido oficialmente como proveedor de transparencia en el consumo de energía y recursos, extendiendo la vida útil potencial del hardware de los dispositivos y permitiendo la autonomía del usuario.

KDE y la comunidad de software libre desean enviar un sincero agradecimiento a los desarrolladores de Okular por crear un software respetuoso con el medio ambiente para todos nosotros.

Okular funciona en Linux, Windows, Android y Plasma Mobile, y está disponible para descargar para todas las distribuciones de GNU/Linux, como un paquete independiente desde Flathub o Snap Store, a través del repositorio de publicaciones de KDE F-Droid para Android, así como desde la tienda de Microsoft. Al ser FOSS, el código fuente también está disponible en el repositorio GitLab de Okular para que todos lo usen, estudien, compartan y mejoren.

Hoy en día, la sostenibilidad debe considerarse de manera holística: la libertad y la apertura en el software, la autonomía y el control del usuario sobre la vida digital propia, y la transparencia en el consumo de recursos de nuestra infraestructura digital son parte de eso. Únase a nosotros en KDE Eco. ¡Hagamos que la sostenibilidad digital y el software libre y de código abierto eficiente en el uso de los recursos sean parte de nuestro futuro para que podamos cumplir con nuestra responsabilidad para esta generación y las futuras!

Artículo escrito por Joseph P. De Veaugh-Geiss bajo la licencia CC-BY-4.0.

I'm a lousy sysadmin.

For years, my strategy for managing my machines in my home network has been one of maximum neglect:

• Avoid distribution upgrades or reinstalls as much as possible, because stuff breaks or loses its configuration.

• Keep my $HOME intact across upgrades, to preserve my personal configuration files as much as possible, even if it accumulates vast amounts of cruft.

• Cry when I install a long-running service on my home server, like SMB shares or a music server, because I know it will break when I have to reinstall or upgrade.

About two years ago, I wrote some scripts to automate at least the package installation step, and to set particularly critical configuration files like firewall rules. These scripts helped me lose part of my fear of updates/reinstalls; after running them, I only needed to do a little manual work to get things back in working order. The scripts also made me start to think actively on what I am comfortable with in terms of distro defaults, and what I really need to change after a default installation.

Salt

In my mind there exists this whole universe of scary power tools for large-scale sysadmin work. Of course you would want some automation if you have a server farm to manage. Of course nobody would do this by hand if you had 3000 workstations somewhere. But for my puny home network with one server and two computers? Surely those tools are overkill?

Thankfully that is not so!

My colleague Richard Brown has been talking about the Salt Project for a few years. It is similar to tools for provisioning and configuration management like Ansible or Puppet.

What I have liked about Salt so far is that the documentation is very good, and it has let me translate my little setup into its configuration language while learning some good practices along the way.

I started with the Salt walkthrough, which is pretty nice.

TL;DR: the salt-master is the central box that keeps and distributes configuration to other machines, and those machines are called salt-minions. You write some mostly-declarative YAML in the salt-master, and propagate that configuration to the minions. Salt knows how to "create a user" or "install a package" or "restart a service when a config file changes" without you having to use distro-specific commands.

My home setup and how I want it to be

pambazo - Has a RAID and serves media and stores backups. This is my home server.

tlacoyo - A desktop box, my main workstation.

torta - My laptop, which has seen very little use during the pandemic; in principle it should have an identical setup to my desktop box.

I open the MDNS firewall ports on those three machines so I can use somehost.local to access them directly, without having to set up DNS. Maybe I should learn how to do the latter.

All the machines need my basic configuration files (Emacs, shell prompt), and a few must-have programs (Emacs, Midnight Commander, git, podman).

My workstations need my gitlab/github SSH keys, my Suse VPN keys, some basic infrastructure for development, I need to be able to reinstall and reconstruct them quickly.

All the machines should get the same configuration for the two printers we have at home (a laser that can do two-sided printing, and an inkjet for photos).

My home server of course needs all the configuration for the various services it runs.

I also have a few short-lived virtual machines to test distro images. In those I only need my must-have packages.

Setting up the salt master

My home server works as the "salt master", which is the machine that holds the configuration that should be distributed to other boxes. I am just using the stock salt-master package from openSUSE. The only things I changed in its default configuration were the paths where it looks for configuration, so I can use a git checkout in my home directory instead of /etc/salt. This goes in /etc/salt/master:

# configuration for minions
file_roots:
  base:
    - /home/federico/src/salt-states

# sensitive data to be distributed to minions
pillar_roots:
  base:
    - /home/federico/src/salt-pillar

Setting up minions

It is easy enough to install the salt-minion package and set up its configuration to talk to the salt-master, but I wanted a way to bootstrap that. Salt-bootstrap is exactly that. I can run this on a newly-installed machine:

curl -o bootstrap-salt.sh -L https://bootstrap.saltproject.io
sudo sh bootstrap-salt.sh -w -A 192.168.1.10 -i my-hostname stable

The first line downloads the bootstrap-salt.sh script.

The second line:

• -w - use the distro's packages for salt-minion, not the upstream ones.

• -A 192.168.1.10 - the IP address of my salt-master. At this point the machine that is to become a minion doesn't have MDNS ports open yet, so it can't find pambazo.local directly and it needs its IP address.

• -i my-hostname - Name to give to the minion. Salt lets you have the minion's name different from the hostname, but I want them to be the same. That is, I want my tlacoyo.local machine to be a minion called tlacoyo, etc.

• stable - Use a stable release of salt-minion, not a development one.

When the script runs, it creates a keypair and asks the salt-master to register its public key. Then, on the salt-master I run this:

salt-key -a my-hostname

This accepts the minion's public key, and it is ready to be configured.

The very basics: set the hostname, open up MDNS in the firewall

I want my hostname to be the same as the minion name. Make it so!

'set hostname to be the same as the minion name':
  network.system:
    - hostname: {{ grains['id'] }}
    - apply_hostname: True
    - retain_settings: True

Salt uses Jinja templates to preprocess its configuration files. One of the variables it makes available is grains, which contains information inherent to each minion: its CPU architecture, amount of memory, OS distribution, and its minion id. Here I am using {{ grains['id'] }} to look up the minion id, and then set it as the hostname.

To set up the firewall for desktop machines, I used YaST and then copied the resulting configuration to Salt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

/etc/firewalld/firewalld.conf:
  file.managed:
    - source: salt://opensuse/desktop-firewalld.conf
    - mode: 600
    - user: root
    - group: root

/etc/firewalld/zones/desktop.xml:
  file.managed:
    - source: salt://opensuse/desktop-firewall-zone.xml
    - mode: 644
    - user: root
    - group: root

firewalld:
  service.running:
    - enable: True
    - watch:
      - file: /etc/firewalld/firewalld.conf
      - file: /etc/firewalld/zones/desktop.xml

file.managed is how Salt lets you copy files to destination machines. In lines 1 to 6, salt://opensuse/desktop-firewalld.conf gets copied to /etc/firewalld/firewalld.conf. The salt:// prefix indicates a path under your location for salt-states; this is the git checkout with Salt's configuration that I mentioned above.

Lines 15 to 20 tell Salt to enable the firewalld service, and to restart it when either of two files change.

Indispensable packages

I cannot live without these:

'indispensable packages':
  pkg.installed:
    - pkgs:
      - emacs
      - git
      - mc
      - ripgrep

pkg.installed takes an array of package names. Here I hard-code the names which those packages have in openSUSE. Salt lets you do all sorts of magic with Jinja and the salt-pillar mechanism to have distro-specific package names, if you have a heterogeneous environment. All my machines are openSUSE, so I don't need to do that.

My username, and personal configuration files

This creates my user:

federico:
  user.present:
    - fullname: Federico Mena Quintero
    - home: /home/federico
    - shell: /bin/bash
    - usergroup: False
    - groups:
      - users

This just copies a few configuration files:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{% set managed_files = [
  [ 'bash_profile',  '.bash_profile',         644 ],
  [ 'bash_logout',   '.bash_logout',          644 ],
  [ 'bashrc',        '.bashrc',               644 ],
  [ 'starship.toml', '.config/starship.toml', 644 ],
  [ 'gitconfig',     '.gitconfig',            644 ],
] %}

{% for file_in_salt, file_in_homedir, mode in managed_files %}

/home/federico/{{ file_in_homedir }}:
  file.managed:
    - source: salt://opensuse/federico-config-files/{{ file_in_salt }}
    - user: federico
    - group: users
    - mode: {{ mode }}

{% endfor %}

I use a Jinja array to define the list of files and their destinations, and a for loop to reduce the amount of typing.

Install some flatpaks

Install the flatpaks I need:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

'Add flathub repository':
  cmd.run:
    - name: flatpak remote-add --if-not-exists --user flathub https://flathub.org/repo/flathub.flatpakrepo
    - runas: federico

{% set flatpaks = [
   'com.github.tchx84.Flatseal',
   'com.microsoft.Teams',
   'net.ankiweb.Anki',
   'org.gnome.Games',
   'org.gnome.Solanum',
   'org.gnome.World.Secrets',
   'org.freac.freac',
   'org.zotero.Zotero',
] %}

install-flatpaks:
  cmd.run:
    - name: flatpak install --user --or-update --assumeyes {{ flatpaks | join(' ') }}
    - runas: federico
    - require:
      - 'Add flathub repository'

Set up one of their configuration files:

/home/federico/.var/app/org.freac.freac/config/.freac/freac.xml:
  file.managed:
    - source: salt://opensuse/federico-config-files/freac.xml
    - user: federico
    - group: users
    - mode: 644
    - makedirs: True

This last file is the configuration for fre:ac, a CD audio ripper. Flatpaks store their configuration files under ~/.var/app/flatpak-name. I configured the app once by hand in its GUI and then copied its configuration file to my salt-states.

Etcetera

The above is not all my setup; obviously things like the home server have a bunch of extra packages and configuration files. However, the patterns above are practically all I need to set up everything else.

How it works in practice

I have a git checkout of my salt-states. When I change them and I want to distribute the new configuration to my machines, I push to the git repository on my home server, and then just run a script that does this:

#!/bin/sh
set -e
cd /home/federico/src/salt-states
git pull
sudo salt '*' state.apply

The salt '*' state.apply causes all machines to get an updated configuration. Salt tells you what changed on each and what stayed the same. The slowest part seems to be updating zypper's package repositories; apart from that, Salt is fast enough for me.

Playing with this for the first time

After setting up the bare salt-master on my home server, I created a virtual machine and immediately registered it as a salt-minion and created a snapshot for it. I wanted to go back to that "just installed, nothing set up" state easily to test my salt-states as if for a new setup. Once I was confident that it worked, I set up salt-minions on my desktop and laptop in exactly the same way. This was very useful!

A process of self-actualization

I have been gradually moving my accumulated configuration cruft from my historical $HOME to Salt. This made me realize that I still had obsolete dotfiles lying around like ~/.red-carpet and ~/.realplayerrc. That software is long gone. My dotfiles are much cleaner now!

I was also able to remove my unused scripts in ~/bin (I still had the one I used to connect to Ximian's SSH tunnel, and the one I used to connect to my university's PPP modem pool), realize which ones I really need, move them to ~/.local/bin and make them managed under Salt.

To clean up that cruft across all machines, I have something like this:

/home/federico/.dotfile-that-is-no-longer-used:
  file.absent

That deletes the file.

In the end I did reach my original goal: I can reinstall a machine, and then get it to a working state with a single command.

This has made me more confident to install cool toys in my home server... like a music server, which brings me endless joy. Look at all this!

One thing that would be nice in Flatpak

Salt lets you know what changed when you apply a configuration, or it can do a dry run where it tells you what will change without actually modifying anything. For example, Salt knows how to query the package database for each distro and tell you if a package needs to be updated, or if an existing config file is different from the one that will be propagated.

It would be nice if the flatpak command-line tool would return this information. In the examples above, I use flatpak remote-add --if-not-exists and flatpak install --or-update to achieve idempotency, but Salt is not able to know what Flatpak actually did; it just runs the commands and returns success or failure.

Some pending things

Some programs keep state along with configuration in the same user-controlled files, and that state gets lost if each run of Salt just overwrites those files:

• fre:ac, a CD audio ripper, has one of those "tip of the day" windows at startup. On each run, it updates the "number of the last shown tip" somewhere in its configuration for the user. However, since that configuration is in the same file that holds the paths for ripped music and the encoder parameters I want to use, the "tip of the day" gets reset to the beginning every time that Salt rewrites the config file.

• When you load a theme in Emacs, say, with custom-enabled-theme in custom.el, it stores a checksum of the theme you picked after first confirming that you indeed want to load the theme's code — to prevent malicious themes or something. However, that checksum is stored in another variable in custom.el, so if Salt overwrites that file, Emacs will ask me again if I want to allow that theme.

In terms of Salt, maybe I need to use a finer-grained method than copying whole configuration files. Salt allows changing individual lines in config files, instead of overwriting the whole file. Copy the file if it doesn't exist; just update the relevant lines later?

I need to distill my dconf for GNOME programs installed on the system, as opposed to flatpaks, to be able to restore it later.

I'm sure there's detritus under ~/.config that should be managed by Salt... maybe I need to do another round of self-actualization and clean that up.

We have a couple of Windows machines kicking around at home, because schoolwork. Salt works on Windows, too, and I'd love to set them up for automatic backups to the home server.

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Además de tratar de difundir la filosofía del software libre, y de crear licencias que permitan la difusión de obras y conservando los derechos de autorías, también llevan a cabo diversas campañas de concienciación y para proteger derechos de los usuarios frentes a aquellos que quieren poner restricciones abusivas en cuestiones tecnológicas.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2022/april
• Y traducido en español (cuando el equipo de traducción lo tenga disponible) en este enlace: https://www.fsf.org/free-software-supporter/2022/abril

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

Después de muchos años colaborando en la traducción al español del boletín, desde inicios del año 2020 he decidido tomarme un descanso en esta tarea.

Pero hay detrás un pequeño grupo de personas que siguen haciendo posible la difusión en español del boletín de noticias de la FSF.

¿Te gustaría aportar tu ayuda en la traducción? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de marzo de 2022

Libertad de coerción

Del 30 de marzo por Kyle Rankin

«Como usuario de software, tenga en cuenta el software del que depende, especialmente para aplicaciones críticas de seguridad o comerciales. ¿Está a salvo de puertas traseras forzadas o prohibiciones de software si los gobiernos se apoyan en sus proveedores?»

Esta publicación ofrece software gratuito como solución, ya que le permite a usted (o a alguien que designe) inspeccionar el código que se ejecuta en sus computadoras. El software gratuito, y solo el software gratuito, le permite revocar fácilmente la confianza, poseer y controlar completamente las claves y auditar su cadena de suministro digital.

• https://puri.sm/posts/freedom-from-coercion/

Ley de Inteligencia Artificial (IA): ¡El software libre es clave!

Del 30 de marzo por la Free Software Foundation Europe

Free Software Foundation Europe (FSFE) pide al Parlamento Europeo que «incluya requisitos para liberar IA bajo una licencia de software libre». Identifican tres pilares importantes que guían sus demandas: innovación, control y confiabilidad. Lea el artículo, el documento de la FSFE dedicado a los responsables de la toma de decisiones y el hilo de discusión para obtener más información sobre la defensa de la FSFE en un tema de relevancia mundial.

• https://fsfe.org/news/2022/news-20220330-01.en.html

Mantener la casa ordenada

Del 21 de marzo por Ludovic Courtès

GNU Guix, un «administrador de paquetes transaccionales y una distribución avanzada del sistema GNU que respeta la libertad del usuario», tiene una forma práctica de administrar y compartir archivos de configuración llamada «Guix Home».

Este artículo bien escrito e informativo explica la lógica detrás de Guix Home y cómo usarlo en su flujo de trabajo diario. La FSF es el patrocinador fiscal de Guix y puedes donar para apoyar el trabajo del proyecto.

• https://guix.gnu.org/blog/2022/keeping-ones-home-tidy/

Primer programa informático con certificación ecológica: el popular lector de PDF de KDE, Okular

Del 16 de marzo por Joseph Veaugh-Geiss

En febrero de 2022, Okular recibió la etiqueta ambiental Blue Angel, la etiqueta ambiental oficial otorgada por el gobierno alemán. «Las cuatro libertades siempre han puesto al software libre a la vanguardia del diseño de software sostenible.

Lo que es nuevo es que los valores [del software libre] ahora son reconocidos como directamente relacionados con la sostenibilidad por organizaciones como la Agencia Ambiental Alemana (Umweltbundesamt), que desarrolló los criterios de adjudicación».

• https://eco.kde.org/blog/2022-03-16-press-release-okular-blue-angel/

Estas son solo algunas de las noticias recogidas este mes, pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2022/abril

Y todos los números del «supporter» o boletín de noticias de 2022 aquí:

• https://www.fsf.org/free-software-supporter/2022

—————————————————————