Alien Pastures

My thoughts on Slackware, life and everything

Let me remind you who started the war in Ukraine and how

February 19, 2025 /

I am going to spit 77 million people in the face here, and it needs to be done. I am raging. If you live in the USA and do not want to be confronted by my ‘leftist’ or ‘commie’ political views then unsubscribe from this blog and get the fuck out.
Listen carefully. Blatant lies are coming from the Oval office with the intention to destroy an ally.

The war in Ukraine did not start in 2022, and it was not started by Ukraine.

In February of 2014 Russia invaded Ukraine and annexed Crimea. NATO shied away from aiding Ukraine because of a justified fear of escalating the conflict. And in July of 2014, Russians shot down a commercial airplane over eastern Ukraine, killing hundreds of passengers. Hard work of a journalist collective provided the proof which held up in court.

In the years that followed, Russia kept arming and fueling the hatred of separatists in the eastern Ukraine. Why? Possibly because with the occupation of the Donbas, Russia now has control over 40% of Ukraine’s mineral riches. It’s always about the money, right? Or is the hunger for power stronger than greed?

In 2022 Russia invaded Ukraine from multiple fronts. Not because of what the traitor in the Oval office tells you – that  Ukraine started this war because of their request to join NATO – no, that request was sent to NATO in 2002, TWENTY years before Putin started his ‘special operation’. The invasion of Ukraine was ordered by a mad Russian dictator whose pride was hurt when the West kept ignoring him as a serious partner on the world stage.

Remember this account from what happened during those initial days?

This is not what happens if you pre-empt a strike because you fear your opponent. This is brutal sadism, trademark of Russian warfare where the state, not people, is the only thing that counts.

Those of you who put a traitor in the Oval office have made yourselves complicit, not just because you have enabled the autocracy or even dictatorship which is being created in the USA as we speak. But also complicit in the possible destruction of a European country: Ukraine. Your president with his delusions of grandeur will try again to grab Canada, Panama and Greenland and will leave Ukraine defenseless against Russia’s aggression. He does not care about you. He is a narcissist.
Next may be the start of an all-out war in Europe because Putin sees an opportunity. The USA now believes that Russia is not the enemy and Europe is its own enemy. And who the fuck cares about that in the USA?
I don’t understand you assholes who put this conman on a throne. All because you could not tolerate a black woman in the Oval office?
You don’t believe this? The orange guy keeps doing exactly what he has been telling you for years. There’s no reason to believe that he will change all of a sudden.

Fuck you all, maggots.

And indeed, I have disabled comments to this article. Suck it up.

Let’s Encrypt SSL certificate expiry warning emails

February 12, 2025 / / 2 Comments

If you use Let’s Encrypt to secure the traffic to your web server, mailserver or other situations where you need a SSL-encrypted data exchange, you are probably using the dehydrated script to manage those certificates to ensure that they will be renewed on time (Let’s Encrypt SSL certificates only have a 90-day lifespan).

Let’s Encrypt offers an automated service running on their end (you don’t have to do a thing) which sends you reminder emails when any of your LE SSL certificates is nearing its expiration date. You will get the first warning 30 days before that expiration.
For me that email has been a lifesaver on multiple occasions. I use their certificates on multiple servers and sometimes the client fails to renew a certificate for whatever reason. I do not monitor all my servers all of the time so it is possible that I miss these errors and run the risk of running a web service with an expired SSL certificate. Quite annoying for my users.

However, in a recent communique Let’s Encrypt have announced that they will end this free alerting service. They also suggest that you could switch to a 3rd-party free email service if you want to keep receiving email alerts for expiring certificates but I thought that this would be a good time to write a script that does the same thing and runs on my own server, no 3rd-party needed.

Dehydrated is part of Slackware since its 15.0 release. There are other tools that do a similar job, such as certbot or acme.sh. In this article I will focus on dehydrated but the script can easily be adapted to be used with one of these other ACME clients.

I wrote and uploaded a script called “check_letsencrypt_cert_expiry.sh” which you can schedule as a weekly cron job. It starts sending warning emails 15 days before the expiration date of a certificate, but that value is configurable in its configfile “check_letsencrypt_cert_expiry.conf” which looks like this:

# Configuration for the check_letsencrypt_cert_expiry script

# When to start sending warning emails;
# Allow this value to be set on the commandline:
WARNDAYS=${WARNDAYS:-“15″}

# From and to email addresses:
FROMEMAIL=”<sender_email_here>”
OWNEREMAIL=”<receiver_email_here>”

Make sure to write valid email addresses for the sender and receiver. If you do not use a valid sender domain, the receiving mailserver may block your email (GMail is really strict about this for instance).

There’s also an email template, see “check_letsencrypt_cert_expiry.tpl“, which will be used by the script to draft the message you will receive. Feel free to modify that text of course. I used most of the email text which is sent by Let’s Encrypt itself.

You can schedule this script to run once per week for instance. An example of a cron line can be found in the header of the script, it looks like this:

# Schedule this script via root’s cron to run once per week:
45 2 * * wed /usr/local/sbin/check_letsencrypt_cert_expiry.sh

If you don’t want to wait until the script is triggered to send you an email, you can force this trigger manually on the command-line. You might want to test whether you get the email at all (GMail sent my first email to SPAM for instance). Just define WARNDAYS with a value that is higher than the SSL cert lifespan in days, like this, as root:

# WARNDAYS=111 ./check_letsencrypt_cert_expiry.sh

You can find the script and accompanying files here: http://www.slackware.com/~alien/tools/le_expiry/ or any of my mirrors.

Have fun! Eric

The bit-rot of 32bit Linux

February 8, 2025 / / 16 Comments

Interest of software developers in the use of their product on 32bit Operating Systems has been declining for years. Build tests are only done on 64bit OS’es nowadays. For obvious reasons: there are not so many computers left in the Western world that only support 32bit software.
The thing is, there’s still a lot of old computer hardware in use outside of the wealthy West. Slackware is one of the few remaining Linux distros where the 32bit flavor is just as relevant as the 64bit variant. Yes, you may question the value of running really new software on really old hardware, but I think that is the users’ choice and if you happen to live in a country where a 2025 computer amounts to a year of salary, then I would want also those people to enjoy modern software and security patches.

I can’t recall how many patches have been needed to make source code compile on 32bit Slackware for instance, but in most cases there would be a way to patch the source or circumvent the error. Patrick Volkerding does this for the distro core and I do something similar for the packages in my own repository. And we sigh and complain to each other when compilations fail due to the restrictive 32bit address space, the inability to specify either “lib” or “lib64” as the LIBDIR, the use of architecture-specific assembly code and CPU instructions, etcetera.

But like with everything that’s left to rot in a corner, it’s getting increasingly difficult to keep 32bit Linux alive. I am running into huge time-sucks when packaging complex pieces of software. Specifically, I have not been able to compile 32bit Chromium since the 132 release despite all of my attempts. And now LibreOffice joins that list: I have been unable to compile the 25.2.0 release on 32bit Slackware 15 and -current.

So.
I will give up my attempts to create 32bit packages for future Chromium and LibreOffice releases. It has already taken way too much of the little time I have left after my regular day-time job. If I run into more of these programs that won’t allow me to compile 32bit binaries, those will quickly be added to that list as well.
I will ask again: if there are people among you (readers) who really need their 32bit programs, I need you to come up with the patches to make that work.

As long as there is a 32bit Slackware, I will keep maintaining my multilib repository of course: there’s nothing for me to actually compile there now that gcc and glibc packages in 64bit Slackware support multilib; the work is reduced to simple re-packaging. But once Patrick decides that 32bit Slackware goes the way of the dodo, then also multilib for Slackware will disappear. It would really be a shame though, but there’s simply no longer any kind of movement that is sufficiently influential to be able to sway software developers and keep 32bit Linux instances running to do their unit testing.

Looking at the Wine emulator, that one can be built so that it no longer needs 32bit libraries, but it would lose the capability to run 16bit Windows programs. I guess that’s where DOSbox would come in to save the day.

But be forewarned: the 32bit OS has become an endangered species.

Eric

Quick ungoogled chromium tips

December 31, 2024 / / 9 Comments

Hey folks. While working I needed to find a historical page in my Chromium browser history and failed. I thought “here we go again” and decided to share some quick tips for users of Ungoogled Chromium at the year’s end.

  • I run into this issue from time to time on computers where I use Chromium. The Chromium browser will keep your browsing history only for 90 days and deletes everything that’s older. This is a hard-coded limit in the source code.
    However, for Chromium’s Ungoogled sibling there’s actually a flag which allows you to disable that 90-day limit and you can keep your browsing history forever.
    Open “chrome://flags/#keep-old-history” in chromium-ungoogled and toggle its value to “On”.
  • The first time you run Ungoogled Chromium, it shows you a startup page full of helpful information to ease the switch from Chrome, such as how to install the Chrome Web Store. But  that page does not return later and it’s not available in the menu.
    You can however always go back to that page by opening “chrome://ungoogled-first-run/” in chromium-ungoogled.

Nothing fancy, just thought to share this.

Be safe during the New Year’s Eve fireworks.
Eric

Liveslak 1.8.2 re-adds Secure Boot support

December 29, 2024 / / 6 Comments

When Slackware-current upgraded the Grub package to 2.12,  liveslak lost the ability to boot on a computer with Secure Boot enabled.

Grub 2.12 is a lot stricter than the previous 2.06 release when it comes to trusting the files it loads and executes. The way it works now is as follows (step 1 and 2 are unchanged):

  1. The Secure Boot computer will only load the primary bootloader when that has been signed with a SSL certificate which is stored in NVRAM (the Database key). Unless you have deleted the original Db, the Dbx, the KEK and the Platform Key in order to install your own self-generated keys, this will be a Microsoft certificate.
    Linux distributions nowadays mostly use a UEFI bootloader called “shim” for Secure Boot. The bigger distros have one in their repository which has been signed by Microsoft. Because this Microsoft certificate is already stored in your computer’s NVRAM, the “shim” trusts it and proceeds with booting.
    Slackware does not have a “shim” which is signed by Microsoft, and nor do I. For liveslak I simply re-use one of the signed “shim” packages from either Fedora, OpenSuSE or else Debian.
  2. The “shim” bootloader will only load a secondary bootloader (Grub for example) if it recognizes and trusts the SSL certificate with which that one has been signed.
    The big distros have embedded their own certificate inside their Microsoft-signed “shim” and for that reason, the “shim” implicitly trusts the distro certificate. This “shim” will then accept and load any secondary bootloader which has been signed by that same distro certificate. It allows a distro to have a transparent boot process (Secure Boot or normal boot) without any specific user actions that need to be performed.
    In our case since I signed our Slackware Grub bootloader with my own SSL key and certificate, the “shim” must be taught to accept this certificate as trustworthy. We do this by enrolling the certificate into the MOK – another piece of storage space in the Secure Boot computer’s NVRAM. MOK stands for Machine Owner Key… and you are the Machine Owner. Since you have to be physically present at your computer when you tell the MOK-manager to enroll the liveslak SSL certificate, that makes the certificate trusted.
    How that is done? I wrote an article about that, three years ago: Secure Boot support landed in liveslak 1.5.0 and I invite you to re-read it.
    The “shim” will load our liveslak Grub bootloader after you enrolled the “liveslak.der” certificate in the MOK.
  3. Now it gets “interesting”. Grub 2.06 would happily continue loading the kernel, the initrd and then boot Slackware Live. But Grub 2.12 requires that every file it loads when Secure Boot is enabled, must be signed by a private GPG key for which Grub stores a copy of its public key. Ehh?

I called that new requirement for the boot process “interesting” but actually it was something to tear your hear out over. Debugging the boot of a computer before the stage where the Linux kernel takes over from the bootloader, is extremely difficult.
I had a good look at the Grub documentation and my liveslak sources back in July and August and actually did most of the changes that were needed during that time.

Most of the work back then went into a big rewrite of the iso2usb.sh script. When Grub needs to check a GPG signature for every file it loads from disk, the initrd must be GPG-signed as well. That means, iso2usb.sh is no longer allowed to un-pack, update and re-pack the initrd image file because that will invalidate the GPG signature.
What I did was: re-use the logic that was already implemented in isocomp.sh, a companion script to enable persistence for the Live ISO when that is used on a Ventoy USB disk.
From now on, all customizations of your Live USB stick are stored in the file ‘/liveslak/slackware_os.cfg‘ in the Linux partition. The initrd remains unchanged.

You need to use the latest version of iso2usb.sh though! Delete older versions please. They are incompatible with the new liveslak.

When that rewrite was finished, I needed to find out what the requirements were for the GPG signing process and I needed to find a way to actually use a GPG private key in my scripts without exposing Alien’s own GPG keys. I learned about ephemeral GPG keys: the liveslak ‘make_slackware_live.sh‘ script creates a GPG private/public key pair, does all the signing, stores copies of the GPG public key inside the Grub bootloader image and on the EFI partition, and then erases the private key (it will no longer be used).
Alas, even with all the requirements apparently having been satisfied I kept running into “security violation” messages on boot.

In August, I simply gave up trying to fix this, because it was so frustrating and also because real-life was too demanding.
But during the Christmas holiday, after I had completed much of my AFFiNE cloud server article, I decided to give it another shot. Actually, I had intended to work on a ‘reboot’ of the Live DAW project but the feedback I am getting on my recent blog post is luke-warm and it did not inspire the confidence that more than a few people would actually use a refreshed DAW environment. Not to worry – that DAW refresh is still on my TODO list.
Looking at the liveslak code with a fresh perspective was really helpful and I managed to deal with the missing pieces. The final hurdle was taken when I realized that I needed to update the SBAT file which gets embedded into the Grub boot image, precisely because I am now using a newer Grub version. As I said, hair-tearing.
With good results: the liveslak-1.8.2 is again supporting Secure Boot.

Note: Secure Boot is supported only on 64-bit computers and only after you transferred the ISO Live content to a USB stick using the iso2usb.sh script.

Anything else that’s new?

Most of what happened between releases 1.8.1 and 1.8.2 is small stuff, a lot of these small changes were necessitated by the evolution of Slackware-current and to keep the Live ISOs working.

One thing worth mentioning is this. The liveslak scripts changed a lot internally, but their usage is un-changed  with a single exception. The “-w” or “–wait” parameter to the “iso2usb.sh” script has been removed. It was meant for slow USB sticks where it takes more time for the USB subsystem to settle in the kernel. Using this parameter allowed you to increase the wait time for your USB stick to boot into the Operating System. But I solved that by using a loop in the live init, and the script parameter is no longer needed.

Download Slackware Live Edition

You can find a set of new ISOs based on liveslak on download.liveslak.org/latest/, the 64bit versions of them support Secure Boot.

It will probably work best if you use the ‘iso2usb.sh‘ script provided with liveslak to transfer the ISO content to a USB stick, it will give you a persistent environment with optional data encryption and this will allow it to boot on a lot more computers.
Alternatively, create a Ventoy disk and copy the un-changed ISO on it. You can then use liveslak’s ISO companion script ‘isocomp.sh‘ to add data persistence for that ISO on the Ventoy disk.

Get liveslak sources

The liveslak project is hosted in git. Its browsable cgit interface is here: https://git.liveslak.org/liveslak/

A set of the liveslak scripts can also be downloaded from http://www.slackware.com/~alien/liveslak/ or https://slackware.nl/people/alien/liveslak/

The liveslak public key (SSL certificate in DER encoding) that you need to enroll can be downloaded from https://download.liveslak.org/secureboot/liveslak.der

Let me know your experiences!
Cheers, Eric

« Older posts

© 2025 Alien Pastures

Theme by Anders Noren — Up ↑