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.

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"

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.

I like Linux. It's not the best thing since sliced bread, but you can't beat the price, and you get very good bang for your buck.

Parent nodes

Page: Hacking articles, tricks and tips

Children nodes

Story: Taking snapshots
Story: Not all (Fedora) kernels are created equal
Story: ABIT IC7 audio for 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!

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.

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.

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

I use Fedora 'raw-hide' on a daily basis, and every so often, updates fail due to broken dependencies. This has been a nuisance for quite a while, and I'd many times work around it by uninstalling packages that were causing yum to fail the update. But, this is no longer necessary, thanks to a very cool plugin.

# yum install yum-skip-broken
# yum update --ignore-broken

Pretty neat!

So, at some point, my X11 server in FC stopped accepting connection on the "default" TCP port, 6000. This wasn't a big deal until I started running another Linux distro in a VMWare VM (thanks VMWare for giving out free "enthusiasts" licenses a while ago!). Anywho, I did some poking around, and realized that gdm has changed it's default setting for listening on the TCP port.

I quickly edited /etc/gdm/custom.conf, and changed

DisallowTCP=false

After restarting gdm (and X11 obviously), everything is working fine again.