Restoring Xen’s iptables rules

Those of you that use Xen may have noticed that, by default, Xen adds some iptables rules when a VM starts, so to ensure that some specific packets are actually forwarded to the virtual machines. If, for any reason, those rules are wiped away, it would be nice to recover them, wouldn't it?

I found out it's quite easy. The following script will just echo the iptables commands so you can safely test it on a running dom0. If it does something that you actually need, just wipe those echo's away!

#!/bin/bash

xm list | perl -alne 'next if not $F[1] > 0 ; print "@F[0,1]"' | while read VM ID 
do
  xm network-list $ID | perl -alne 'next if not $F[0] =~ m{^d+$} ; print $F[0]' | while read IFID
  do
    VIF="vif$ID.$IFID"
    echo iptables -A FORWARD -m physdev --physdev-in $VIF -s $VM -j ACCEPT
    echo iptables -A FORWARD -m physdev --physdev-in $VIF -p udp --sport bootpc --dport bootps -j ACCEPT
  done
done

I am using Perl here because I know it better than awk, but I am sure that awk can accomplish the same task as well as perl does.

Internet lingo: +1

Today I quickly answered to an email from my sister with a "+1". I couldn't imagine that it would have puzzled her so much, or pulled an incorrect explanation from my brother 🙂 So, what does "+1" mean?

It's simple: it just means "those who are counting how many agree with this, please add one", or simply put: "I agree".

I know, we internet junkies look complicated sometimes. But we aren't, are we? 😉

Bug in AppConfig 1.56?

For example, suppose you define three scalar variables, named alpha, beta and gamma, and suppose that when you set them you first declare an unknown variable named delta. E.g.: you have this configuration file:

delta = D
alpha = A
beta  = B
gamma = G

Depending on the value of CREATE and PEDANTIC, you'll have different results, namely:

CREATE PEDANTIC alpha beta gamma delta
not set not set A B G undef
not set set to 0 A B G undef
not set set to 1 undef undef undef undef
set to ^[a-z_] not set A B G D
set to ^[a-z_] set to 0 A B G D
set to ^[a-z_] set to 1 A B G D

But if you run your script setting stuff in the same way, e.g.:

script.pl -delta D -alpha A -beta B -gamma G

results are completely different, namely:

CREATE PEDANTIC alpha beta gamma delta
not set not set undef undef undef undef
not set set to 0 undef undef undef undef
not set set to 1 undef undef undef undef
set to ^[a-z_] not set undef undef undef undef
set to ^[a-z_] set to 0 undef undef undef undef
set to ^[a-z_] set to 1 undef undef undef undef

The only values that correspond in the two cases are those marked in yellow. Is this the intended behaviour? I don't know, I hope I'll have an authoritative response from the module authors.

locales and Ubuntu 10.10

Today, during an upgrade of my workstation's 10.10, I noticed that a lot of unneeded EN locales were being generated, and I wanted to get rid of them. Coming from a debian background, I confidently ran dpkg-reconfigure locales, but instead of getting the usual interface I got

root@brabham:~# dpkg-reconfigure --priority=low locales
Generating locales...
  en_AG.UTF-8... up-to-date
  en_AU.UTF-8... up-to-date
  en_BW.UTF-8... up-to-date
  en_CA.UTF-8... up-to-date
  en_DK.UTF-8... up-to-date
  en_GB.UTF-8... up-to-date
  en_HK.UTF-8... up-to-date
  en_IE.UTF-8... up-to-date
  en_IN.UTF-8... up-to-date
  en_NG.UTF-8... up-to-date
  en_NZ.UTF-8... up-to-date
  en_PH.UTF-8... up-to-date
  en_SG.UTF-8... up-to-date
  en_US.UTF-8... up-to-date
  en_ZA.UTF-8... up-to-date
  en_ZW.UTF-8... up-to-date
  it_CH.UTF-8... up-to-date
  it_IT.UTF-8... up-to-date
Generation complete.

Odd, isn't it? Well, it turns out that, in order to get rid of the locales you don't want, you have to manually change the files in /var/lib/locales/supported.d. Oh, dear…

OK, Canonical claims to create "Linux for the human beings". I partially agree with that. But I would like to know how removing the ncurses interface to locales could possibly make the system simpler. I mean: "common" users just won't care if they have 100 locales instead of 10, so it doesn't matter for them. We "advanced users" can edit plan text files, for sure, but is that a good reason to remove a convenient interface from the system?

Ubuntu really puzzles me sometimes…

Drawing puppet class relationships with graphviz

In the last few days, I got the impression that my puppet class hierarchy was growing a bit out of control. In particular, it looked like "glue" classes aimed to simplify stuff were actually causing more harm than benefit. How I found out? Well, it was getting too complicated to understand what included what, and walking the classes by hand quickly became a terrible task.

So, I decided to go for something that could do the work for me: go through my modules, get the include statements, and draw the relationships. Luckily, I remembered I saw that graphviz was designed explicitly to ease that latest task. … Continue reading

OpenIndiana to release soon?

As you may know, after Oracle sunk OpenSolaris :rip: a couple of new project arose: one was Illumos, which took the development of the core from where it stopped, and started with rebuilding the "less open"-licensed stuff, and OpenIndiana, which focused on a whole operating system; OpenIndiana starts on the OpenSolaris base, but will eventually use Illumos for the core stuff.

Well. After about 6 months that OpenSolaris was unofficially declared dead, project OpenIndiana is planning its first official release.

Let's see what happens 🙂

:bye:

independent_wallclock in Xen 4

I was asked to set up clock synchronization for a Xen VM, running on top of Xen 4.0, which in turn was running on top of a Debian Squeeze. As you may know, NTP on VMs just sucks, so I was looking for Xen 3.0's independent_wallclock setting, and have domU's clock follow dom0's.

With my surprise, /proc/sys/xen/independent_wallclock wasn't there anymore.

With some surprise (but not as much), my searches in Google returned just crap.

As it often happens, IRC came to the rescue. Or, well: no rescue, but at least I was provided with a reason:

(15:51:10) The topic for ##xen is: Xen 4.0 http://www.xen.org/downloads | XCP http://blog.xen.org/index.php/2010/11/24/the-xen-cloud-platform-xcp-1-0-beta-is-available-from-xen-org/ | Wiki: http://wiki.xen.org/ | Solaris: http://www.opensolaris.org/os/community/xen/ | Logs: http://zentific.com/irclogs | Management: check out #zentific
(15:54:48) bronto@freenode: hello! It's maybe an FAQ, but I couldn't find an answer anywhere. Xen 4.0 doesn't have /proc/sys/xen/independent_wallclock (at least, not in Debian Squeeze Linux). Is there any equivalent?
(15:55:14) bronto@freenode: I would like domUs to follow dom0's clock, and sync dom0 using NTP.
(15:55:42) pasik: bronto: it depends on the kernel
(15:55:47) pasik: bronto: pvops kernels don't have it
(15:55:57) pasik: bronto: old xenlinux kernels do have it
(15:56:33) bronto@freenode: pasik: thanks. hmmm… so, the solution is: use a different kernel?
(15:56:40) pasik: bronto: or ntp
(15:56:55) bronto@freenode: pasik: NTP on domU's? Uh, that just sucks…
(15:58:57) pasik: bronto: pvops (upstream) kernels don't have independent_wallclock because there was some problems with it, it wasn't thought to be accepted to upstream Linux
(15:59:03) pasik: bronto: I can't remember the details now
(15:59:27) bronto@freenode: pasik: ouch… 😦
(15:59:41) bronto@freenode: pasik: this is damn bad
(16:00:31) bronto@freenode: pasik: OK. I'll fall back to ntp, and hope it will work

New module on CPAN: Log::Stderr

I published my fourth module on CPAN today: Log::Stderr. As the name says, it will write timestamped log messages to STDERR.

Like the other three I published back in 2004, it's not rocket science. But it is something that I was using to help me debug small scripts, and I found it very convenient. So I am publishing it in the hope that it will be useful for someone else. Of course this module won't be much useful if you have more than basic needs, but it's not a problem: there are so many good modules in the Log:: hierarchy! And if you are in doubt about which one to use, well, visit "the Monastery" and ask the monks 😉

Enjoy!