Cobra's bits (Posts about suse)

Backdoor in xz

Cobra — Mon, 01 Apr 2024 11:50:12 GMT

The upstream xz repository and the xz tarballs have been backdoored.

This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports.

This supply-chain attack targets .deb- and .rpm-based distributions, but the backdoored versions of xz or xz-utils (5.6.0 and 5.6.1) have made it only into rolling-release distributions such as Fedora Rawhide, Debian Testing/Sid, OpenSuse Tumbleweed, and Archlinux (where it is inactive).

The server of this blog is running Debian Testing and had the compromised version of xz-utils installed since March 17. The backdoor was reported last Friday, March 29. I've installed the patch provided by Debian on Saturday, March 30, and examined the system logs, which do not show any evidence that the system has been compromised in any way. In fact, according to my current understanding, the system did not meet all the requirements for the backdoor to be executed. However, I will remain vigilant and let the users of the server know if further action needs to be taken.

More links (in German): Heise 30.03.2024 09:35, Heise 30.03.2024 22:28, Heise 02.04.2024 17:10

Close call

Cobra — Fri, 24 Oct 2014 12:36:24 GMT

If you're using btrfs and its snapshot function: stay away from kernel 3.17! It may corrupt your filesystem. I've just spent the better part of the morning trying to coax my desktop into getting back to its normal self.

After updating to 3.17 and editing syslinux.cfg to take care of the now manual microcode updates, I've noticed the following anomalies:

KDE needed several minutes to start, just as every KDE application afterwards
System load was high (up to 5) despite the fact that the system was essentially idling (no CPU or I/O activities)
the btrfs formatted system partition switched to RO mode after a few minutes of use. WTF?
after a further reboot with the microcode updates disabled, avahi didn't come up and journald dumped one core after the other (105, to be precise).
oh, and there was no network at this point 😒

After rolling back to kernel 3.16.4, reinstalling systemd, and purging all (corrupted) journal files in /var/log/journal, the worst seems to be over.

Note that this bug is not restricted to users of Archlinux, but was reported by users of Fedora 20, Debian Sid, Gentoo, and OpenSUSE Tumbleweed.

Chitty Chitty Bang Bang

Cobra — Sun, 17 Nov 2013 15:39:11 GMT

New hardware always has the effect that everything else suddenly feels slow and outdated. After experiencing the ease and effortlessness with which my desktop handles everything I throw at it, my notebook (a Fujitsu Lifebook AH530) running OpenSuse 12.3 felt unresponsive and sluggish. Instead of updating to OpenSuse 13.1, I decided to install Archbang, a distribution I always wanted to run on one of my systems. Similar to Crunchbang which runs on my Mini, Archbang offers an Openbox powered desktop which is about as lightweight and snappy as it gets.

Archbang, however, is even more frugal and spartan than Crunchbang. For example, there's no out-of-the-box support for Bluetooth devices.

The Archlinux Wiki has detailed instructions as to the configuration of a Bluetooth mouse:

systemctl start bluetooth
systemctl enable bluetooth
bluetoothctl
 [bluetooth]# list
  Controller <cmac> BlueZ 5.5 [default]
 [bluetooth]# select <cmac>
 [bluetooth]# power on
 [bluetooth]# scan on
 [bluetooth]# devices
   Device <mmac> Name: Bluetooth Mouse
 [bluetooth]# trust <mmac>
 [bluetooth]# pairable on
 [bluetooth]# pair <mmac>
 [bluetooth]# connect <mmac>

After that, you only need to create a new udev rule to activate the mouse upon a reboot:

vim /etc/udev/rules.d/10-local.rules
# Set bluetooth power up
ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"

All that works well until I suspend the session by closing the lid of the laptop. After that, the bluetooth mouse is inactive until I reboot the system.

Turns out that other people using Arch have the same problem. They even file bug reports. Well, what's more, people using other distributions have this problem too, and they fill out reports on the respective (Ubuntu, Fedora) platform as well.

There's even a fix, but for reasons I don't understand it didn't even make it into the recently released 3.12. What a bummer. Update: The fix has been included in 3.12.4. 😊

Apart from this, everything's just perfect. In the spirit of the distro, I try to use lightweight applications. For example, I use aarchup, guake and geany instead of yapan, kuake and texmaker or kile. Other than that, I just moved tint2 to the top and changed the conkyrc, but I even kept the wallpaper.

Bleeding edge

Cobra — Sun, 14 Jul 2013 12:31:52 GMT

I've been a a hard-core upgrade addict years ago, and that didn't change in the time since then. On the contrary, I've become allergic to outdated software, and I chose the distributions I'm using with particular attention to their closeness to the bleeding edge. I thus run Arch Linux on my desktop, Fedora on my office computer, and OpenSuse on my notebook.

OpenSuse? Bleeding edge?

Well, see for yourself:

With the tumbleweed repository, OpenSuse turns into a really very much up-to-date rolling-release distribution. Definitely worth a try.

Butter bei die Fische

Cobra — Sat, 06 Apr 2013 14:05:13 GMT

The root partition of my desktop and my notebook are formatted with btrfs, the B-tree file system (or 'Butterfuss' for ease of pronunciation). I've chosen btrfs mainly for one of its many outstanding features (compared to ext4), namely, the possibility to take snapshots of a partition (more precisely, a subvolume), and to return to them if, for example, an update proves to be troublesome.

These snapshots can be managed either directly by the btrfs tools, or by snapper, a tool developed by openSUSE. Snapper is automatically installed when choosing btrfs as filesystem during the installation of openSUSE, and that's where I've encountered it first. I've found that it greatly simplifies snapshot management, and I much recommend it also for users of other distributions.

openSUSE

If you happen to have an existing openSUSE installation > 12.1, and if you use btrfs as default file system, snapper may be already alive:

snapper list-configs
snapper list

If the lists are populated, snapper is active and you've got nothing to do. Excellent!

Otherwise, issue

snapper create-config /

Snapper should now automatically take hourly snapshots of your root partition. It will also automagically take snapshots just before and after an update performed by either zypper or yast, so in case anything goes wrong, you could resort to the latest sane state of your system.

Archlinux

Snapper is also available for other Linux distributions, and in particular, for Archlinux. The instructions available are outdated and do not work, but the following steps should.

First of all, install snapper:

yaourt -S snapper-git

Next, create a subvolume (not a directory!) containing the snapshots with the mandatory (!) name .snapshots:

btrfs subvolume create /.snapshots

Then, configure snapper:

cp /etc/snapper/config-templates/default /etc/snapper/configs/root

vim /etc/conf.d/snapper
SNAPPER_CONFIGS="root"

vim /etc/cron.hourly/snapper
:%s/sysconfig/conf.d/g

Test the configuration by:

snapper list-configs

Do you see your config?

Try to create a snapshot:

snapper create -d "First manual snapshot." -c timeline

Look at your first snapshot:

snapper list

Now let snapper take care of the following snapshots. 😊

No more buntu

Cobra — Fri, 22 Mar 2013 20:30:41 GMT

A few days ago, the Kubuntu 12.10 on my wife's notebook received a regular update but did not, upon the obligatory reboot, return to its regular operation: the display resolution was changed to 1024x768 and neither WiFi nor Bluetooth were avaliable.

I didn't even think twice (my wife said I was just waiting for such an opportunity, and she may be right) : let's replace this sad imitation of GNU/Linux with something I can rely on!

And what would that be? My wife asked for something really established, with an easy, graphical install routine, up-to-date packages and preferably offering a rolling release scheme. And it should not be related in any way to any kind of *buntu *shudder*.

What does that leave?

OpenSUSE, a descendant of Slackware. 😉 Of course, installation (12.3) is a breeze, and activating the Tumbleweed repository (and thus the rolling release scheme) too. Equally expected is the fact that all the hardware of this Fujitsu Lifebook AH 530 is recognized and supported out of the box. The lifebook falls asleep and gracefully wakes up, as desired, and the frequent hiccups and lockups due to the power management under *buntu are a thing of the past.

That leaves me with Archlinux on my main system, Crunchbang on the Mini, openSUSE on the lifebook, Fedora for my office desktop, and Debian Wheezy for the workstations. Pity I can't fit a Gentoo in between. 😉

Psychological factors

Cobra — Sun, 19 Feb 2012 16:01:08 GMT

I'm now using Arch Linux as my primary operating system on my desktop computer at home since 5 month. Time for a little review and comparison.

Were my initial expectations fulfilled?

More than that, they were exceeded. Arch proved to be a truly up-to-date distribution which simultaneously manages to be stable as the proverbial rock. My problems at the beginning were easily corrected by adding a script to /home/cobra/.kde4/Autostart, as actually described in the ArchWiki. Since then, I didn't experience any problem. Everything just works the way I intend it to do.

What are my future expectations/hopes?

A month ago I would have voted for package signing. That, however, has been implemented in pacman 4, and I'm currently entirely satisfied.

How does it compare to other distributions?

Oh my. That's really where I went wrong. See, Arch is great, but it does require some time to set it up properly. So I argued that I'd need an easier-to-set-up distribution for the office, where I manage time in slots of minutes. A mandatory requirement was that the distribution offers TeXLive 2011, and this excluded most distributions (foremost Debian, which I would have much preferred). So I've chosen Fedora Scientific, which comes prepackaged with most I need. Indeed, installation was a breeze and finished in 30 min. But after that...well, let's just say that I'm not enthusiastic about the Fedora way. The distribution is outdated (compared to Arch), offers a quite limited set of packages (compared to Arch), and its package manager is the slowest I've ever seen. Well, perhaps zypper is even slower, but not much.

Let's do some ranking (from 0 to 10) of the distributions I'm using every day:

	Arch Linux	Fedora Verne	Ubuntu Oneiric	Debian Wheezy	OpenSuse Asparagus
Actuality	9	7	3	5	4
Stability	8	6	4	9	7
Responsiveness	9	3	7	8	2
Trust	8	6	1	9	2

Now, "actuality" describes how close the distribution stays to the current upstream. "Stability" is proportional to the frequency of curses uttered because of segfaults and their cousins during the use of the respective distribution. But WTF are "responsiveness" and "trust"?

Well, if you look deep within yourself, you'll find that there are reasons more important than the two objective criteria above for choosing a particular operating system. If it would only be about actuality and stability, Windows would score pretty high, which would be absurd. The question to ask is how do you feel when you use your computer? Do you feel comfortable? At home? Does it feel right? Do you like it?

"Responsiveness" is a soft criterion intended to reflect the user experience when doing administrative work, such as updating/upgrading, starting and stopping services, change system-wide settings, etc. Simplicity, speed, and transparency is what counts in this discipline. Windows with a value of 0 is used as reference.

"Trust" is an entirely subjective criterion with political dimensions. Do you trust the good intentions of Google? Perhaps not, but do you trust their intentions to create a fast and safe browser? You may not care for the former, but very much for the latter. "Trust" as used here contains both of these elements. As a reference, we use Windows with a value of 0.

These reflections will have a consequence. Particularly for Dell Minis hiding underneath Fujitsu Lifebooks...ArchBang is waiting for you, my little friend.

Small steps

Cobra — Sat, 19 Dec 2009 15:52:54 GMT

A command in the spirit of those discussed previously. Not as universal, as it finds only executables. But still: another small step for OpenSuse towards a usable distribution.

make: don't know how to make love

Cobra — Sat, 28 Nov 2009 13:12:23 GMT

The title of this entry is an old joke born in times when package managers were not yet invented. All administrators thus had to know how to install programs from the source with the now well-known, and even famous sequence of commands, the "rule of three":

./configure
make
make install

Now, you can still install programs in this old-fashioned but canonical way. But aren't there better ways?

Oh yes, and we are all using them: they are called package managers. They did away with the d ependency hell, which was the source of constant irritation in the early days of Unix before the development of package managers dealing with dependencies (that, by the way, is just a decade ago). Ian Murdock called package management the single biggest advancement Linux has brought to the industry, and I fully agree. It's the prime reason why I'm using Linux and not MacOS.

You now may understand why I principally consider the above "rule of three" as the last resort. Bypassing the package management is always possible, and in the rare cases I do that, I install everything in /usr/local as recommended. Yet, this should be done in exceptional cases only, and not become the standard. Remember that these self-installed packages are not part of the automatic security updates offered by your package manager, nor can they be cleany removed in an automated way. In other words, these packages need to be looked after and pampered, and I just don't want that on my system.

But what to do if your distribution simply doesn't offer a package you're interested in, or only a grossly outdated version?

There are a number of possibilities, and there's an helpful tool which helps to explore some of them.

First of all, I always check whether the tarball of the program I've just downloaded contains a *.spec file. Then, a simple 'rpmbuild -ta .tar.gz' might suffice to create a binary rpm out of the tarball . You can then install this rpm with the package manager of your liking. 😉
Second, if there's no *.spec, or if compilation fails, there's a high chance that alien will work. For example, my versions of gdis and gwyddion are both the offspring of a conversion from a debian/sid package to an rpm by alien. To find out whether the desired program is somewhere out there, you can use whohas as mentioned above. Beware: the script does not run out of the box. One needs to specify the version numbers of current distributions in line 50 ff, and currently it is also advisable to deactivate mandriva and slackware (just underneath, switch to zero). In any case, after you found the package you need by whohas (which tells you the address!) and downloaded it, simply run 'alien --to-rpm --scripts .deb' and install the resulting rpm by your package manager. Or vice versa: 'alien --to-deb --scripts .rpm'
Third, you may, in exceptional cases, also install packages build for another distribution. Fedora packages, for example, can often be installed on Mandriva and vice versa. However, you should only do that if you're versed in this business, as it can easily wreck your system.

Murphy

Cobra — Sat, 03 Oct 2009 19:01:13 GMT

What's quite unlikely in these times? A power failure.
What's even more unlikely? Me upgrading at the exact minute of the power failure to the first release candidate of Mandriva 2010.

System didn't boot at first, but that could be fixed by a straightforward repair of grub. After that, it became obvious that all further updates were complicated by the fact that the rpm database contained more than 600 duplicates, i.e., the system believed to have the same package installed in both 2009.1 and 2010.0 version. An 'rpm --rebuilddb' didn't help. What to do?

rpm -qa --queryformat '%{NAME}-%{VERSION}\n' | sort | uniq -d > duplicates_0
while read pkg; do rpm -q "$pkg" > duplicates_1; done < duplicates_0
sed -i '/2010/d' duplicates_1
while read pkg; do urpme "$pkg" && echo "$pkg"; done < duplicates_1

Instead of the sed command, you can also load duplicates_1 in vim, and:

:g/2010/delete
ZZ