Daniel Lange's blog

System Rescue, the project formerly known as System Rescue CD, has moved from being based on Gentoo to being built on Arch Linux packages.

With this their ISO layout changed substantially so when updating my trusty recue USB flash drive, I could not just update the kernel, initrd and the root filesystem image as I had typically done every other year before.

The "Installing on a USB memory stick" documentation is good for Windows (use Rufus, it's nice) but rather useless for Linux. They recommend a dd or the fancy graphical version of that, called usbimager.

I much prefer to have a flash drive that I can write to over an image of a CD (ISO) written 1:1 onto the flash media.

The basic idea is to use the bulk of the System Rescue ISO contents but amend these with your own grub and syslinux so they work as intended over the supplied ones that are bound to the ISO layout a bit too much.

I did this on Debian Buster but with some adjustments to paths and what packages to install, any recent Linux distribution should do:

There is a add-on technology to X or VNC called NX by an Italian company called NoMachine. It's quite useful as it speeds up working on remote desktops via slow network connections (i.e. DSL pipes) substantially.

The libraries that implement NX are released under GPLv2 by that company. A server wrapping up the libraries' functionality is available as closed source from NoMachine or as a free product (GPLv2 again) by Fabian Franz, called FreeNX.

FreeNX itself is amazing as it is written in BASH (with a few helper functions in C). It's also able to mend some of the shortcomings of the NX architecture. E.g. stock NX requires a technical user called "nx" to able to ssh into the NX server with a public/private keypair. FreeNX can work around that for more secure set-ups.

One issue I bumped into quite regularly with Linux clients and Linux hosts from different distributions/localisations is that the keymaps are not compatible. This usually results in the ALTGr key not usable, so German keyboard users can't enter a pipe ("|"), tilde ("~") or a backslash ("\") character. Also the up and down keys are usually resulting in weird characters being pasted to the shell. Now all of that makes using a shell/terminal prompt quite interesting.

The XFCE Terminal has the weird issue of sometimes showing question marks (?) instead of German Umlauts (äöüÄÖÜ) although they work fine in any other stock XFCE application (e.g. the default editor "mousepad").

The solution to this can be found on the XFCE Forums but it took me quite some time to find it. It was difficult to find a suitable search query to dig out that page. Google turns up a lot of irrelevant stuff on "XFCE Terminal question marks"...

XFCE Editor Umlauts with and without LANG variable set

The problem with Umlauts (and other 8bit ASCII characters) showing as question marks arises if the user has no LANG variable set.

A simple

resolves the issue. Put that into ~/.bashrc or any other place suitable in your distribution.

Gentoo users may want to

to set the LANG variable system-wide.

So keywords, dear Google: Umlaute, deutsch, Fragezeichen, kaputt, falsch, broken, display, zeigt, charset, Zeichensatz

Gentoo finally decided to update Xorg to 1.5. Because this has very substantial changes against the previous version, some things break and there is a migration guide that you are nagged to read. After the upgrade I found that the Matrox card in one of my servers would not display xinerama anymore, i.e. I would get the same image on both screens only. This is the default behaviour for the stock Xorg mga driver. It needs a proprietary HALlib to get real dual-screen capabilities. Whilst there are a few unstable ebuilds for x11-drivers/xf86-video-mga none worked for me any better with Xinerama. The Gentoo Changelog is useless as usual. (Gentoo ebuild ChangeLogs tend to never really tell what is fixed, if you're lucky they reference a bug with a good description. But that's only if you're really lucky.)

Worse, that driver hasn't been updated by Matrox anymore since mammals took over the earth (figuratively ... 2005). This is the typical unmaintained-closed-source-drivers-make-hardware-obsolete-sooner-than-later story. Luckily the cards are quite widely used and clever people from the Open Source community have written guides (Tuxx-Home, Fkung) on how to dissect the proprietary driver and combine parts of it with the Open Source version so that it can be linked into recent X servers. Unfortunately because of the architectural changes in Xorg 1.5, following these guides will fail at the compile stage.

In the Matrox Forum of Alexander Griesser, the author of the first comprehensive Matrox driver install guide linked above, people currently mostly downgrade to previous Xorg versions to work around the issue.

But there is a better^Hworking solution already emerging ...

Bryan Østergaard (aka kloeri) announced Exherbo today. He assembled a team of (ex-)Gentoo developers including Ciaran McCreesh (ciaranm), Richard Brown (rbrown), Fernando J. Pereda (ferdy) and Alexander Færøy (eroyf) to build a new source based Linux distribution.

They would like to overcome some of the short-commings of Gentoo both from a technical as well as from a community perspective. Obviously this is easily said and hard to really achieve, so time will tell how successful that team can be. Renaming USE-Flags to OPTIONS and merging the platform KEYWORDS (like x86, ~x86) into the Options-logic is no big deal, but getting the thousands of ebuilds^Hpackages better supported and maintained than Gentoo will be the real deal{maker|breaker}.

Paludis, ciaranm's package manager, supports Gentoo ebuilds and can import them into Exherbo, so there is a potential migration path sketched out.*

They also add another init-system re-write ("Genesis") to the pool. An already quite crowded pool with rather shallow water, I may add.

Exherbo has nothing that is end-user-safe at the time of the announcement, so it's safe to assume kloeri's team wants to attract further development capacity .

Browse around the website or join folks in #exherbo if you're interested.

I asked in #exherbo what "exherbo" means ... latin for "uproot" was the answer. How fitting.

Updates

*19.04.08: Two friendly folks wrote in to clarify that Paludis currently can only import Ebuild-builds into Exherbo via importare, i.e. take a Gentoo build result and package it for importing into the Exherbo system through Paludis.
23.05.08: Ciaranm wrote a blog entry how to get build results into Exherbo/Paludis via importare.

SSH with chroot patch has been working fine for a number of years. Since PAM v0.99 things have broken though, if users are chrooted with the "/home/username/./" syntax as their homedir.

SSH sessions will just terminate immediately after successful logon. Doh.

Two solutions exist:

1. Put UsePAM no into /etc/ssh/sshd_config and use the chroot patch and /./ in users homedirs
2. Keep UsePAM yes. Emerge sys-auth/pam_chroot and add session required pam_chroot.so to /etc/pamd.d/sshd setup /etc/security/chroot.conf or add a chroot_dir=/home/username/ to the pam_chroot.so line.
   This will currently not work for amd64 though as the Gentoo bug regarding pam_chroot has not cought any attention from the arch testers. Since July...

Bugging the arch testers in #Gentoo-amd64 didn't help either:

Since a baselayout update Apache fails to start on Gentoo at (re-)boot of a server if that server has unused ethernet interfaces.

The symptom is that Apache fails to start on boot although it has been added to the runlevel with
rc-update add apache default

This is caused by recent baselayouts not working properly with more than one eth and not all of them being up.

Thus changing depend() { need net ... } into
depend() { need net.eth0 ... } at the top of /etc/init.d/apache2 will help.

While you're at it you could also add an nice after urandom to the existing depend () construct
and make sure apr and apache are emerged with flag urandom set. Reading from /dev/random to initialize the digest authentication mechanism (or SSL for that matter) might cause apache to block otherwise if there is not enough entropy in the random pool.