Linux

Linux stuff

rpm, yum and broken perl installation

My Fedora Core 7 box recently ended up in some state where my perl installation was seriously messed up. I'd get errors about mismatch in platform architecture, problems with sockets etc. etc. So, I really wanted to have yum reinstall all my perl packages. I couldn't find a way to do that, but I managed to achieve something similar using various commands. Here are the steps I followed:

# rpm -qa --qf '%{NAME}\n' | grep '^perl-' > /tmp/perl.pkgs
# rpm -e --justdb --nodeps perl `cat /tmp/perl.pkgs`
# mv /usr/lib/perl5 /usr/lib/perl5-
# yum install perl `cat /tmp/perl.pkgs`

PLEASE! Be careful with these commands, make sure you know what you're doing, check the /tmp/perl.pkgs file to make sure it seems reasonable etc. Once this is all done and finished, I removed the old perl5 library (perl5-).

As an alternative, you could also do something like

# rpm -q --qf '%{NAME}\n' --whatrequires perl > /tmp/perl.pkgs

but that will reinstall more packages than absolutely necessary, I think.

KVM/qemu vs VirtualBox

I've been fiddling around with various virtualization systems, including VMWare, Fusion, Xen, Qemu, KVM and now lately, VirtualBox. To my surprise, there's virtually no (pun intended) difference running it natively on FC9, or under either VM (Ubuntu). It's possible Ubuntu is just "faster" than FC9 since some VM tests were actually faster, so maybe I really ought to run this test with an FC9 VM instead. Also, there's very little, if any, difference between VirtualBox and KVM performance (which is good, because I like VirtualBox a heck of a lot more). I ran the VirtualBox benchmarks both with, and without, VT-x support, VT-x seemed marginally faster, although it's probably not statistically "safe".

Here are the numbers:

Native FC9
VirtualBox Ubuntu8
VirtualBox w. VT-x enabled
KVM/qemu Ubuntu8
Integer
54.273
54.730
55.337
54.312
Floating point
43.196
42.843
42.495
43.063

The Bonnie++ I/O benchmarks are equally impressive for VirtualBox, most tests are as fast as the host OS (or faster ...).

On top of being very fast, VirtualBox is also the easiest to use free virtualization software I've tried, so far. It even supports PulseAudio as an audio driver! This feature alone makes it very attractive, since my FC9 host system is completely migrated to PulseAudio, and now my virtual machines now seamlessly supports sound as well.

I'll blog more about PulseAudio as I learn more, but it's a really neat little package. I really hope it'll clear up the Audio mess that is currently in Linux/Gnome/KDE. This could be the sound server to control it all.

Linux PulseAudio

I upgraded my dev box to Fedora Core 9 yesterday, which mostly worked well (except, it botched the grub boot loader, and failed to upgrade ~4GB's worth of FC6 packages). Most things went well, except the migration to PulseAudio. It ended up starting in a "broken" state, and then Gnome gets really unhappy (including any Gnome apps). Looking in syslog, I'd see

May 18 22:57:05 loki pulseaudio[2733]: main.c: Called SUID root and real-time/high-priority scheduling was
requested in the configuration. However, we lack the necessary priviliges:
May 18 22:57:05 loki pulseaudio[2733]: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us
priviliges. Dropping SUID again.

Adding my user to the pulse-rt group seems to have fixed this particular problem, so things are happy again. Getting Firefox and Flash to work was a whole different story, doing a number of web searches, a few suggestions to use libflashsupport. However, digging deeper, setting the environment variable FIREFOX_DSP also does the trick. E.g. something like this in your firefox startup script:

export FIREFOX_DSP="aoss"

Blocking brute force login attempts

For some reason, my boxes seem to get a lot of login / hacking attempts to them. For a long time now, I've deployed an iptables filter that blocks a lot of these attempts. They still keep trying, even though they only get a few attempts per IP. Maybe I'm sticking out my head too much here, showing what my filters are, but I figured that someone else might find this useful. And besides, if knowing my filters makes me more vulnerable, then I rather find out about it.

So, here it is (well, the parts of it that blocks login attempts):

-A INPUT -p tcp -m tcp --dport 22 -m state --state new -m limit --limit 10/hour --limit-burst 4 -j ACCEPT
-A INPUT -m tcp -p tcp --dport 22 -j LOG --log-prefix "IPTABLES SSH-LIMIT: "
-A INPUT -m tcp -p tcp --dport 22 -j DROP

-A INPUT -p tcp -m tcp --dport 21 -m state --state new -m limit --limit 10/hour --limit-burst 4 -j ACCEPT
-A INPUT -m tcp -p tcp --dport 21 -j LOG --log-prefix "IPTABLES FTP-LIMIT: "
-A INPUT -m tcp -p tcp --dport 21 -j DROP

Be careful to not lock yourself out. If you need to go over these limits from a particular IP, whitelist it first with a rule to always grant access.

Unix

Unix is the next best thing since sliced bread. I've used it for a long time now (since 1985, on a PDP-11 running BSD 2.9). I prefer Linux these days, but honestly, I really don't care that much as long as it's some reasonable flavor of Unix.

Tivo and Linux

I once again decided to install Galleon (formerly known as HME I think) on my brand spanking new file server at home. This mostly worked ok, after I successfully disabled IPV6 completely (which required a reboot). On my Fedora Core 7 box, I had to modify /etc/sysconfig/network, with

NETWORKING_IPV6=no

For the kernel config, I ended up adding the following to my /etc/modprobe.conf:
blacklist net-pf-10
# I don't know if the following have any effect, but doesn't seem to hurt besides some warnings/errors:
alias ipv6 off
alias net-pf-10 off

With this done, my TiVo (series 2) can now successfully connect to the Galleon server, using the apps I've configured for it. Downloading recorded episodes works fine too, but is very, very slow. However, the content is encrypted, using your MAK key. I found a neat little Linux app, that can decode this, called tivodecode. It works great!

Fedora Core and SystemTap

I wanted to get SystemTap to run on my Fedora Core 6 box, and had problems getting it running. The README says to install the kernel-debuginfo, which I had problems getting going. It turns out I was just being stupid, and didn't run yum properly. All I really had to do was:

% sudo yum install systemtap
% sudo yum --enablerepo=core-debuginfo --enablerepo=updates-debuginfo  install kernel-debuginfo

More information about System Tap is available here.

vmware desktop in the background

This has bothered me for a while: I start vmware to run some OS I need to port code to, and my X11 server crashes for some reason (Ok, I use Beryl...), taking down the virtual machine with it. I did some searches, and it turns out there's an option for this in vmware! I guess I should have read the documentation, but who does that?

After starting up vmware, go to Preferences, and in the Workspace tab, enable the setting for Run powered on virtual machines in background after close. Now, just close vmware after the VM is running, and it stays running in the background. You might also want to enable the VNC server for the VM(s), so that you can connect to the console if need be (but you can also reconnect it to the vmware console again by just starting up vmware again).

Oh, this is only tested on the VMware 6 (beta), I don't know if this is available in older version.

Mounting NFS partitions on Solaris 10 from RHEL

I've been playing around with Solaris today, and it's just as good as I remember (except still missing all the tools I need, like Emacs). However, I was unable to NFS mount my home directory from my RHEL4 box. I would get an error like

bash-3.00# mount -o ro machine.ogre.com:/export/disk /foo/bar
nfs mount: mount: /foo/bar: Not owner

and my /var/adm/messages would have

Apr  3 22:22:36 solaris10 nfs: [ID 435675 kern.warning] WARNING: NFS server initial call to
                                               machine failed: Not owner

RHEL4 does NFS v4 (or so it thinks at least), and Solaris is not happy with something there. Obviously there must be a way to get it to work, but right now, I just needed to get it working. So, until I figure out what in NFS v4 is causing this, I decided to make Solaris just use NFS v3. There's a couple of ways to do this, easiest is to just use the vers=3 option to mount, e.g. in /etc/auto_home do something like

leif    -rw,vers=3      machine:/export/home/leif

Or, you can change the defaults in Solaris 10, by editing /etc/default/nfs, and modify

NFS_CLIENT_VERSMAX=3

After changing this default, you have to run

# svcadm refresh svc:/network/nfs/client:default

Alternatively, you could probably also disable NFS v4 on the RHEL4 box.

yum and repository priority

I use yum on pretty much a daily basis, and I've added a small collection of repos (repository). I use livna and FreshRPMs for instance. Now, for some reason these two repositories overlap, meaning, if I run yum update, livna will try to upgrade my freshrpm packages. Up until now, I've managed around this by using --enablerepo and --disablerepo. However, there's a much better way, I installed a yum plugin called yum-priorities.

Using yum (obviously), I simply installed this on my Fedora Core box with

# yum install yum-priorities

With this plugin installed, all I have to do is to give the FreshRPMs repo a higher priority (lower priority value) than the livna repo (default priority is 99). For example:
[freshrpms]
name=Fedora Core $releasever - $basearch - Freshrpms
priority=80
.
.
.

Now when I run yum update I get a message like

...
Loading "priorities" plugin
Setting up Update Process
Setting up repositories
Loading mirror speeds from cached hostfile
Reading repository metadata in from local files
0 packages excluded due to repository protections
96 packages excluded due to repository priority protections
No Packages marked for Update/Obsoletion