This is the seventh part of my syslog-ng tutorial. Last time, we learned about syslog-ng destinations and the log path. Today, we learn about syslog-ng network logging. At the end of the session, we will send test messages to a syslog-ng network source.

You can watch the video on YouTube:

Or you can read the rest the tutorial as a blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-part-7-networking

The openSUSE Conference is set to begin in 100 days from today and, to help prepare people who want to travel to Nuremberg for the event from May 26 - 28, there is information people attending need to know.

Getting a visa may take some time. There are certain requirements necessary to receive a visa for those who are not a citizen of a Schengen country. You may need a formal invitation letter that fully explains the nature of your visit.

An overview of visa requirements/exemptions for entry into the Federal Republic of Germany can be found at the Federal Foreign Office website. You must apply for a Schengen visa through the German embassy or consulate in your country.

If you plan to attend the conference and are coming from a country where you will need a formal invitation letter, email ddemaio@ opensuse.org with the email subject “oSC23 Visa”.

More travel information people wanting to come to the openSUSE Conference should be aware of is the Travel Support Program. The TSP is a helpful way to get people in the community to attend the conference. The funds we have are limited, but help to support the community’s attendance.

Here are a few reminders regarding the TSP:

• Please read the TSP policy page carefully before you apply.
• The Travel Committee can reimburse up to 80% of travel and/or lodging costs. That includes hotel, hostel, plane, train, bus
• Important: Food and all local expenses are on you!
• We want to sponsor as many people as possible so please check the best deal.
• No receipts = no money It is the rule! (Original receipts are required from German residences.)

The call for papers is open until April 9. Submit a talk today.

Presentations can be submitted for the following length of time:

• Lightning Talk (10 mins)
• Short Talk (30 mins)
• Virtual Talk (30 mins)
• Long Talk (45 mins)
• Workshop (1 hour)
• Virtual Workshop (1 hour)

The following tracks are listed for the conference:

• Cloud and Containers
• Community
• Embedded Systems and Edge Computing
• New Technologies
• Open Source
• openSUSE

This week the panel of presenters brought an app they use to share. Instead of choosing a specific application to try out or explore the panel decided that we would all bring something interesting that we use to share with others and explain why it was interesting. There are links to all the applications brought […]

Disculpen la pausa tan larga en escribir este blog. Comencé a poner mis hilos de carpintería en Mastodon y dejé olvidado este lugar. Pero bien, prosigamos.

Dos mesitas de noche:

• Parte 1: Preparar las piezas
• Parte 2: Marcar las patas
• Parte 3: Los cajones

En la parte 2 hicimos las patas para una de las mesitas. Ahora va el cajón.

Estoy viendo que no tengo tantas fotos del proceso como quisiera, pero ojalá lo siguiente sirva.

Las cuatro tablas del cuerpo del cajón tienen que quedar muy bien escuadradas. Aquí me fui un poco chueco con el serrucho, según la marca del cuchillo:

La arreglé con la chancla, el cepillo pequeñito. Primero se lubrica (yo uso grasa de tocino clarificada), y se cepilla con cuidado hasta llegar a la línea:

Hasta que queda bien escuadrado.

Con el gramil se marca el largo de las colas de milano en uno de los extremos de la tabla que va a ser el frente del cajón, y con escuadra falsa se trazan las colas. Luego, se marca el largo de las colas con el gramil sobre las tablas laterales.

Ahora, al revés. Se transfiere el grosor de las tablas laterales a la tabla del frente del cajón.

Ahora, con la escuadra, se marca el largo de las colas a partir de las diagonales marcadas en el extremo.

Marcamos las partes que van a ser basura y podemos empezar a cortar. Como siempre, se empieza el corte del serrucho siguiendo las líneas en dos planos: ambas líneas se intersectan y determinan un plano en el espacio, que es el plano de la hoja del serrucho.

En la última foto, los cortes en las diagonales se pasan de la línea. No importa; no se van a ver, pues quedan por detrás de la parte frontal, y así se facilita después el corte con formón.

Ahora vamos a escarbar las colas de milano con un formón. Se hace poco a poco, desde el extremo hacia adentro, con cuidado para no romper la parte más estrecha de la tabla.

Hay que transferir la forma de las colas a las tablas laterales. Para facilitar el trabajo, conviene tener un tope en las tablas laterales para acomodar la tabla frontal encima. Ese tope lo hago sacando un pequeñísimo escalón en el extremo de las tablas laterales. Se pone una tira de madera, se marca con cuchillo, se quitan las esquinas y se rebaja el escalón con un guillame.

Aquí es donde me faltan fotos. No tengo imágenes de cómo se hace descansar la tabla frontal sobre ese escalón de las laterales, pero es ahí donde se marca con cuidado la forma de las colas de milano. Igual, se serruchan y luego se saca el desecho con formón.

Todas las tablas requieren una ranura para la tabla delgadita del fondo del dajón. Esa ranura se puede acomodar adentro de la cola de milano de hasta abajo.

Ranurando la tabla frontal:

Ranurando una tabla lateral:

Cómo sostener la tabla para ranurarla, con un tope y un clavito:

La tabla del fondo del cajón casi lista para entrar en la ranura:

Ya se puede armar el cajón, pero luego hay que escuadrarlo. Primero lo armamos y pegamos:

Y con las reglas de enderezar, se ve si el cajón está torcido. Lo está un poco; lo cepillamos con cuidado para no astillar las tablas transversales.

Ya podemos poner el cajón en sus rieles y probar la altura. Donde le sobre, se rebaja con el cepillo.

Al fondo de los rieles se pegan bloquecitos de madera que va a servir como tope. Cada tope se ajusta de forma independiente, rebajándolo poco a poco con formón, hasta que el frente del cajón quede alineado con el frente de la mesa.

Fíjate en los rieles; abarcan el ancho interno de las patas y no le dejan nada de juego al cajón. El chiste es que entre lo más derecho posible, sin espacio para que entre sesgado — si sólo puede entrar derechito, no se va a atorar.

Sobre los topes... aquí está el cajón metido hasta el fondo, y sobresale del frente de la mesita:

Rebajamos el bloquecito de cada lado...

... hasta que todo el frente del cajón queda alineado y al ras.

Ahora hay que preparar el fondo del cajón, para que quepa en las ranuras. Queremos que quede así:

Esos rebajes inclinados se hacen inclinando el cepillo:

Con un poco de cuidado, queda derecho. O primero se puede marcar con lápiz paralelo al borde. No tiene mucha importancia, porque es un lado que no se ve.

La parte de atrás sobresale. La marcamos y cepillamos al ras.

This machine looks nearly identical to an original Commodore 64 but without the legacy ports that were on it. There is no Expansion port, RF modulator, Analog AV out in the DIN connector, IEC port, Tape deck or Userport. The traditional joystick ports are also absent on this machine. Instead, you have HDMI for video […]

Dear Tumbleweed users and hackers,

7 days – 7 snapshots. No surprise there, is it? Tumbleweed keeps on delivering snapshots in predictable ways. Nevertheless, there was a small surprise to me this week: a new glibc version (2.37) was submitted. I already feared that this would be blocking staging for weeks to come. But wrong I was! Just 54 hours after the SR was created, the update found its way into openSUSE:Factory – and 24 hours later it’s available to the users to install after passing openQA. Of course, that’s not the only thing that happened though, it’s just the most recent thing that stunned me.

The 7 snapshots (0202, 0204…0209) brought you these changes:

• Mozilla Firefox 109.0.1
• Mozilla Thunderbird 102.7.1 & 102.7.2
• NetworkManager 1.40.12
• GStreamer 1.22.0
• openSSL 3 is now used by default – finally; openssl 1.1 (and 1.0) are still available in the repo
• KDE Gear 22.12.1
• PHP 8.1.15
• Linux kernel 6.1.10
• glibc 2.37
• memtest86+ 6.1.0

For the next week (and beyond) these things are in the pipeline:

• KDE Plasma 5.27
• Rust 1.67 (likely to wait for 1.67.1 to address Mesa build failures)
• Binutils 2.40
• Enabling of python311 modules (keeping python 3.10 as the default interpreter in the first step)
• Staging:H still tests ruby 3.2 as the new default (yast2-packager is the only failing package left)
• Staging:L holds some packages breaking others stuff taking more time, like gpg2, and ant
• Staging:Gcc7 tests the impact of using GCC 13 as the default compiler

The past week has produced a few openSUSE Tumbleweed snapshots and automatic migrations kicked off for the first snapshot of February.

Some of the packages covered this week include updates for the GNU Compiler Collection, GStreamer, KDE Gear, those mentioned in the headline and several more.

Snapshot 20230208 provided the second update of ImageMagick listed in this post; the 7.1.0.61 version clarified some documentation and moved around the -set profile command-line interface handling. Various language translations were made with the 6.4.36 fetchmail update. An update of xwayland 22.1.8 fixed a second possible Out-of-band remote access OOB access. The backward compatibility package also fixed CVE-2023-0494, which could have allowed for local privilege elevation on systems where an X server runs privileged and remote code execution for SSH X forwarding sessions. The snapshot had several other package updates including hwdata 0.367, ncurses 6.4.20230128, texinfo 7.0.2, ceph and more.

The 20230207 snapshot brought an update of the network infrastructure package dnsmasq 2.89; the package fixed a bug that resulted in the corruption of the DNS cache internal data structures and logging of “cache internal error”. The changelog notes that “this has only been seen in one place in the wild, and it took considerable effort to even generate a test case to reproduce it, but there’s no way to be sure it won’t strike, and the effect is to break the cache badly.“ The policy analysis tools for SELinux, setools, updated to version 4.4.1 and updated the permission map. The package also has some code cleanup and replaced a deprecated function that was removed in NetworkX 3.0 version. An improved codec selection logic, better handling of latency, and an improved frame discard to avoid audio/video desynchronization was made with the webkit2gtk3 2.38.4 update. An update of kernel-firmware 20230125 and the Linux kernel-source 6.1.10 appeared to have several AMD additions and arm64 fixes respectively.

Audio software audacity updated to version 3.2.4 in snapshot 20230204. Audio can now be shared publicly on audio.com thanks to the upgrade. A new toolbar with cut/copy/paste buttons have also been added. KDE Gear 22.12.2 arrived in the rolling release soon after its announcement and file manager Dolphin fixed the size of directories if a subdirectory fails to open. A startup crash was fixed with the package’s Kalendar update. Video editor Kdenlive also fixed a crash and a screen split that did not save subclips. Georgian translations were made in the libstorage-ng 4.5.68 update and php8 8.1.15 had multiple fixes to including fixing a wrong comparison in block optimisation pass after an opcode update. The package also handles speed-optimized hash algorithm XXH3 better.

An update of the Mozilla Firefox browser to version 109.0.1 was made in snapshot 20230202. The update had some emoji character fixes. An update of NetworkManager 1.40.12 had a fix involving concurrent invocation of iptables in IPv4 shared mode. The library for configuring and customizing font access, fontconfig, updated to version 2.14.2. The package fixed a typo in descriptions, adjusted an indentation and added a rendering option.

An OpenSSL change from version 1.1.1s to 3.0.7 was made in the snapshot. The new version is set as the default and was a major project spanning a long period of time to make it available to users. The changes relaxes the crypto-policy requirement for regression tests and it removed some patches. OpenSSL 3.0 is a major release and various packages had to be adapted. The new version has tons of improvements. The build and installation procedure has changed significantly and many structures have been made opaque in the new version. More information is available in the migration guide.

Text editor vim 9.0.1270 had multiple fixes to include a few code that was indented more than necessary and a fix that now recognizes the NetworkManager connection. An update of GStreamer 1.22.0 and several of its plugins with the same version were updated in the snapshot. Some AV1 video codec improvements were made and a couple WebRTC supporting efforts were made. There is also new plugins for Amazon AWS storage and audio transcription services.

Snapshot 20230201 had a few packages updated like gcc13. The 13.0.1 plus version added support for new front-ends Rust and Modula-2. The GNU compiler also fixes a Go frontend to fix failed builds on s390x. The first snapshot of the month was significant as it kicks off automatic migrations with zypper dup pertaining to the i586 carve-out from Factory. Changing the repo could include a bunch of package downgrades as the rebuild counters are not synced across projects, according to notes from openSUSE’s last release engineering meeting. By the end of March, the expectation is that all users will have completed the migration; by then Tumbleweed will have disable build/publish of i586 packages, except for the roughly 1,800 packages identified in the Staging:O workflow of the Factory codebase.

The end-of-month snapshot, 20230131, provided the first update of ImageMagick with the 7.1.0.60 version. The image editor had only three commits, which were mostly cleaning up some code. The systemd 252.5 update introduced a preset to allow systemd user units for MicroOS users and added a transactional-update-notifier that allows for users of the distribution, which is optimized for cloud and container deployments, to have desktop notifications about transactional updates either succeeding or failing. Another package to update in the snapshot was xterm 378 and it improved some descriptions and several checks like one that improved a check for unsupported formatting characters.

I recently purchased some hardware for my Commodore 64 to enhance its usefulness in day to day activities. Sure, my favorite modern implementation tends to be TheC64 for recreation type activities but when it comes to doing productivity, the Commodore 64, especially with the RAM Expansion Unit with 16 Mbytes really makes the pluckly 1980s […]

Version 4.0.1 of syslog-ng was released a month ago. Unfortunately, the new release does not compile on FreeBSD. It was a temporary problem in the environment generating the source tgz. The next release is still almost a month away, but you can compile syslog-ng 4.0.1 yourself from my unofficial ports Makefile.

Learn how from my latest blog at https://www.syslog-ng.com/community/b/blog/posts/installing-syslog-ng-4-0-1-on-freebsd

Hackweek 22 took place last week. During this week all the SUSE employees are free to hack on whatever they want. This one of the perks of working at SUSE 😎.

This time my personal project has been about building a unikernel that runs WebAssembly.

I wanted this blog post to contain all the details about this journey. However I realized this would have been too much for a single post. I hence decided to split everything into smaller chunks. I’ll update this section to keep track of all the posts.

In the meantime, you can find the code of the POC here.

Why

There are multiple reasons why I did that, but I don’t want to repeat what I wrote inside of the project description. Learning and fun goals aside, I think there’s actually a good reason to mix unikernels and WebAssembly.

From the application developer POV, porting/writing an application to the unikernel is not an easy task. The application and all its dependencies have to support the target unikernel. Some patching might be required inside of the whole application stack to make it work.

From the unikernel maintainers POV, they have to invest quite some energies to ensure any kind of application can run in a seamless way on top of their platform. They don’t know which kind of system primitives the user applications will leverage, this makes everything harder.

On the other hand, when targeting a WebAssembly platform (think of Spin or Spiderlightning), the application has a clear set of capabilities that have to be provided by the WebAssembly runtime.

If you look at the Spiderlightning scenario, an application might be requiring Key/Value store capabilities at runtime. However, how these capabilities are implemented on the host side is not relevant to the application. That means the same .wasm module can be run by a runtime that implements the K/V store using Redis or using Azure Cosmos DB. That would be totally transparent to the end user application.

You might see where I’m going with all that…

If we write a unikernel application that runs WebAssembly modules and supports a set of Spiderlightning APIs, then the same Spiderlightning application could be run both on top of the regular slight runtime and of this unikernel.

All of that without any additional work from the application developer. The Wasm module wouldn’t even realize that. The complexity would fall only on the unikernel developer who, whoever, would have a clear set of functionalities to implement (as opposed to “let’s try to make any kind of application work”).

How

Sometimes ago I stumbled over the RustyHermit project, this is a unikernel written in Rust. I decided to use it as the foundation to write my unikernel application.

Building a RustyHermit application is pretty straightforward. Their documentation, even though is a bit scattered, is good and their examples help a lot.

The cool thing is that RustyHermit is part of Rust nightly, which makes the whole developer experience great. It feels like writing a regular Rust application.

Obviously you cannot expect all kind of Rust crates to just work with RustyHermit. You will see how that influenced the development of the POC.

The next sections go over some of the major challenges I faced during the last week. I’ll share more details inside of the upcoming blog posts (see the disclaimer section at the top of the page).

The WebAssembly runtime

Unfortunately Wasmtime, my favorite WebAssembly runtime, does not build on top of RustyHermit. Many of its dependencies expect libc or other low level libraries to be around. The same applies to wasmer.

I thought about using something like WebAssembly Micro Runtime (WAMR), but I preferred to stick with something written in Rust and have the “full RustyHermit experience”.

After some searching I found wasmi a pure Rust WebAssembly runtime. This works fine on top of RustyHermit, plus its design is inspired by the one of Wasmtime, which allowed me to reuse a lot of my previous knowledge.

WebAssembly Component Model

Spiderlightning leverages the WebAssembly Component Model proposal to offer capabilities to the WebAssembly guests and to allow the host to consume capabilities offered by the WebAssembly guest.

The communication between the host and the guest happens using types defined with the Wasm Interface Type.

To give some concrete examples, the demo I’m going to run leverages the WebAssembly Component Model in these ways:

• The guest asks the host to start a HTTP server. When doing that, the guest informs the host about the HTTP routes that have to be registered, plus the names of its internal handlers (the functions that have to be executed). This is done by using the http-server types. In this case it’s the guest that leverages capabilities offered by the host.
• The host handles the incoming HTTP requests using the routing information provided by the guest. The http handlers mentioned before are functions exposes by the WebAssembly guest. The server is now consuming capabilities offered by the guest. The communication is done using the http-handler types.
• Some of the http handlers defined by the guest are also interacting with a Key/Value store. Also in this case the guest is leveraging a set of capabilities offered by the host. These are defined using the keyvalue types.

As you can see there are many WIT types involved. For each one of them we need code both inside of the guest (a SDK basically) and on the host (the code that implements the guest SDK). This code can be scaffolded by a cli tool called wit-bindgen, which generates host/guest code starting from a .wit file.

In this case I only had to implement the host side of these interfaces inside of the unikernel.

The code generated by wit-bindgen is doing low level operations using the WebAssembly runtime. The code to be scaffolded depends on the programming language and on the WebAssembly runtime used on the host side.

Obviously the wasmi WebAssembly runtime was not supported by wit-bindgen, hence I had to extend wit-bindgen to handle it. The code can be found inside of this fork, under the wasmi branch.

With all of that in place, I scaffolded the host side of the Key/Value capability and I made a simple implementation of the host traits. The host code was just emitting some debug information. I was then able run the vanilla keyvalue-demo from the Spiderlightning project. 🥳

Summary

You made to the bottom of this long post, kudos! I think you deserve a prize for that, so here we go…

This is a recording of the unikernel application running the Spiderlightning http-server demo.

I hope you enjoyed the reading. Stay tuned for the next part of the journey. This will cover Rust async, Redis and some weird errors.