Landfill of wisdom

Edit the svn:externals property for the directory where the external stuff will go into
svn propedit svn:externals .

Add a line for each external entry you want to have:
local/path http://external/repo
local/path2 -r### http://external/repo

Example for me adding jokey’s virtualbox ebuilds:

svn pe svn:externals /var/repos/chutz/app-emulation

virtualbox http://overlays.gentoo.org/svn/dev/jokey/trunk/app-emulation/virtualbox
virtualbox-additions http://overlays.gentoo.org/svn/dev/jokey/trunk/app-emulation/virtualbox-additions
virtualbox-bin http://overlays.gentoo.org/svn/dev/jokey/trunk/app-emulation/virtualbox-bin
virtualbox-guest-additions http://overlays.gentoo.org/svn/dev/jokey/trunk/app-emulation/virtualbox-guest-additions
virtualbox-modules http://overlays.gentoo.org/svn/dev/jokey/trunk/app-emulation/virtualbox-modules

The original tip was here.

Note to self for common commands use by ImageMagick:

• The manual
• The examples
• Geometry specification
  • [width]x[height][+-x+-y]
  • Cropping
    • Always use “+repage” or else…
    • When cropping do specify +0+0 or you’ll get lots of tiles
  • Checking the output on the command line — use xpm:- for output (-compress none pbm:- is also kind-of usable).
  • Thumbnail gallery: montage input*.jpg -tile XxY -mode Concatenate output.jpg

The problem

Here’s a simplified snippet of what illustrates the problem I had today.

SQLiteCommand cmd = cnn.CreateCommand("SELECT a.a1, b.b1 FROM a INNER JOIN b USING (b1)");
SQLiteDataReader reader = cmd.ExecuteReader();
DataTable dt = new DataTable();
dt.Load(reader);
reader.Close();

The problem is that dt.Rows.Count is way lower than what running the same statement in the SQLite CLI produces.

The reason

The reason is that DataTable complains about an invalid constraint on the “b1″ column. Why? Because “b1″ has a unique index in “b” and for some reason DataTable doesn’t like it when you get to entries with the same value for that column regardless that it is perfectly legal when joining tables.

The workaround

I have no idea if this is a problem with SQLite or the AdoNet SQLite wrapper, and I haven’t tried other databases to see if this is not a problem with SQLite at all. The workaround, however, is this:
SELECT a.a1, b.b1 + 0 FROM a INNER JOIN b USING (b1)

That’s an ugly workaround but at least it works.

Mutt is my mail client of choice. The reasons are simple: It…

• is fast
• is usable from the command line (a big plus)
• lets you do essentially anything to a message
• supports hooks for very flexible configuraiton

And the tip of the day — how to fix unreadable (as in — mojibake mail) to be readable again.

1. Highlight the mail in the index and press “e”. This will fire up your editor (vim in my case) and load the full mail in it.
2. Find the “Content-Type” header. Edit the value of the “charset” field on the line. If there is no such header just add one:
   Content-Type: text/plain; charset="iso-2022-jp"

If the subject of the mail is also unreadable, do the following:

1. Install maildrop
2. Select the Subject line and pass it to this command cat | xargs -ifoo reformime -h "foo" | iconv -f iso-2022-jp -t utf8 | xargs -ibar reformime -o "bar" -c utf8. In vim speak, this means
   1. /^\csubject:
   2. Shift-V!cat | xargs -ifoo …
3. Play around with the charsets if you’re not getting correct results.

So I got XEN working but the network interfaces on my host became a mess and it is somewhat related to my naming conventions.

I like to name my interfaces with easy (at least to me) to understand names. For example, my local interface is named “lan”. The one that my PPPoE connections are running over is “inet”. A third card going to my neighbor is called “nei”. On my desktop where I was testing XEN I only have one interface — lan.

When I start xend, the default network-bridge script is trying to set up some bridges (another option I had to recompile here), and is trying to move the configuration of my physical interface to the new bridge and rename the bridge to have the name of my interface (after renaming the interface itself of course). What happened is that udev kicked in when the new interfaces showed up as it is doing its best to keep my interfaces with consistent names. That pretty much did the mess, except that the network-bridge script itself was not really comfortable handling interfaces whose last symbol is not a digit.

My solution was the following:

Add a new network script called network-null. It does nothing. It’s empty. Use that as the network-script for xend. Then I set up my system network configuration to use a bridge with a single port. And that pretty much did the trick me.

There is also what seems to be a pretty good alternative network script for XEN. It does the XEN magic a little better, it detects the default interface well, and I would recommend it as a good default choice. It also doesn’t seem to want to rename your interfaces, but only copy the configuration over to the bridge.

Next on the to-play-with list: pass some PCI devices to the guest domains.

So, I had some time to see why XEN refused to work last time.

The first obvious problem was that I had not loaded any modules. So far, so good. I quickly loaded all back-related modules, specifically netloop, netbk, blkbk, and xenblktap. Not loading these would give weird errors about a device not being connectable. One would think that XEN can give more understandable error messages. The case is that it would give the same message if you’re missing the module and if the path to the file representing a block device is invalid. So, be careful.

Loaded the modules and “xm create” behaved much better. No errors, but it hang for a long time. I didn’t know how to interpret the output of “xm list”, so I had no clue if the guest domain was running or not. I tried “xm create -c” but it would just bail (after a 30 second wait) with a message that it cannot connect to the console. “netstat -tnlp” did not suggest that anything is listening on a 59xx port, as I was expecting. So I started digging around why an hvm XEN guest would refuse to start vnc.

I actually tried some domains from the XEN demo cd and they worked just fine. So it was something to do with hvm obviously. And it turns out it is, hvm guests need the “tun” module loaded in the host. “modprobe tun” and everything was working.

Now, the last issue I had was with the networking scripts that xen comes with. They are horrible and I’ll go over them in a second post…

I decided once again that it is time to give XEN a try. I decided to try it on a newer Athlon 64 X2 with virtualisation capabilities. That latter is important, as my overall intention is to also try OSes that are “incompatible” with XEN. I know that there are other alternatives but I’ll write on “why XEN” some other time.
Continue reading ‘Giving XEN a try’ »

Alright, here’s what I do to get wget from the Native Win32 ports GNU collection to work with as little fuss as possible.
set WGETRC=%HOMEDRIVE%%HOMEPATH%\.wgetrc
cat > %HOMEDIR%%HOMEPATH%\.wgetrc
http_proxy = http://PROXY:PORT/
ftp_proxy = http://PROXY:PORT/
use_proxy = on
proxy_user = USERNAME
proxy_passwd = PASSWORD
user_agent = SOMETHING GOES HERE
^Z^Z


Pay attention to proxy_passwd. wget is at version 1.8.2 and that configuration option was renamed in a later version.

Just to summarize why Firefox does not trust the https://www.clevery.co.jp/ online shop.

Apparently the server at https://www.clevery.co.jp/ only sends its own certificate when I open their page. What most sites usually do is that they send not only their own certificate, but also the certificate of their issuer, and the certificate of that issuer and so on up to the root certificate (excluding the last one). What is happening with the clevery server is that its certificate contains an extension that points to the location of the parent certificate. As given by OpenSSL
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
CA Issuers - URI:http://SVR1024Secure-aia.verisign.com/SVR1024Secure2007-aia.cer

So, apparently Firefox doesn’t follow that path and that seems to be a recognized standard. A quick Google found this article by someone who ran into the same problem and who has already checked the status of that extension.

I’ll have to look more into it myself, but I am not in the mood right now.

Logwatch was good enough to show me that I had my logs filled with messages like these… repeating themselves over and over ad infinitum:
Continue reading ‘OpenVPN connectivity issues’ »