Author: Ryan

Windows reinstall and Adobe fun

Ryanadobe, gimp, Photomatix, Photoshop, Sony Vegas

I never got around to posting it, but a few weeks back the hard drive of my PC with Windows on it died … a little bit. Technically a large chunk of the harddrive is simply unaccessable. after poking and pushing I at least got windows to boot up again, but a large part of the software was dead. I bough a new drive and went through the fun process of installing a fresh windows, patching it, and then installing all the software again.

I didn’t get around to installing my video and picture software on the new windows until this morning, and it turned out to be lots of fun. Due to pure luck I found the license key for sony vegas (it is shown in the splash screen when starting up, shortly before it crashes due to my harddisk malfunction). Any Photomatix was where I keep most licenses stored. But my Photoshop license was more of a challenge. Adobe only allows 2 activated copies of the software per license, activated copies are bound to hardware … you probably see where this is going. I couldn’t deactivate the old installation since the harddrive was kinda dead, and the new installation says “different hardware (new harddrives), must be a different computer”. Yay, fun. The bright side was that the support was easily contacted and they could reset the activation counter (after lecturing me about using it on “2 computers” and deactivating, bla bla bla). I learned one thing: the more expensive the software, the more problems you have with licenses. A shame I never liked Gimp for photo editing.

Controlling SSH identities

Ryan1 Comment on Controlling SSH identities

SSH has a few strange undocumented “features”. One of which is the way it handles identities via agent and command line. It is possible to specify an identity file to use for ssh via the -i parameter (ssh -i identity_file $host). What the manpage doesn’t mention, is that the specified identity isn’t forced for the connection, it is just added to the list of possible identities.
To make matters worse, ssh tries the identities from the agent first. So if agent forwarding is enabled and valid for the destination the ssh command will never use the identity specified with -i. Why is this “bad”? Because the identity specified may be used for specific tasks with commands linked to them on the destination (e.g. automatic restarts, backups, …)

Sooo, as a solution I whipped up the following function as a workaround in my scripts, I add a function called “xssh”:

I know it looks ugly, if it finds a key in the agent it makes a ssh connection to the current host with agent forwarding deactivated and then executes the ssh parameters passed. If no key is found in the ssh agent it does everything as normal.

a bit of Baking

Ryan

Wife did some baking tonight, so I whipped out the camera and took some shots. Unfortunately I noticed that the flash hot shoe seems to have gone unresponsive after a fall a few weeks ago, but using the built-in flash as a commander to control an off-camera flash still works fine.

[album=20,compact]

XEN 3.4 with ipv6 routing

Ryanbash, ipv6, patch, routing, xen

Yes, there are a few postings out there about getting ipv6 routing running with XEN. But I’ll throw this online anyway since there are a few changes I had to make for it to work on my server. This text is intended for people who know their way around Linux and XEN so it will be a bit technical and won’t spell out every single step you have to make.

Most of the changes are based off scripts and information from BenV and wnagele (latter is interesting for me since I am also running XEN on a hetzner server). Have a look at the two links if anything is unclear. Now let’s start the fun 🙂

First of all we need IPv6 up and running on the host (dom0). Add the IP and gateway to your /etc/network/interfaces
This is what mine looks like:
iface eth0 inet6 static
address 2a01:4f8:100:1123::2
netmask 64
gateway 2a01:4f8:100:1120::1
pre-up ip -6 route add 2a01:4f8:100:1120::1 dev eth0
Check if the IP address is responding to the outside world (e.g. with wiberg.nu/iptools.php), if everything looks ok, proceed …
Now we need to enable a few things to get routing and neighbor discovery running on the host (dom0). Edit your /etc/sysctl.conf and add/change these 2 entries (and while you are at it, set them with “sysctl -w” too):
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.proxy_ndp=1

So, your host should by now be online with ipv6 and soon be able to route packets to it’s guests. By default XEN will only take care of IPv4 when a guest is created, so here is a small patchfile that adds support for IPv6: xen-ipv6-vif-route.patch. The patch changes vif-route and vif-common.sh, while these files may be in different places depending on your distribution, /etc/xen/scripts/ is where they can commonly be found. Download the patch to the directory with the scripts to be changed and execute a “patch -p0 < xen-ipv6-vif-route.patch” (vif-common.sh gets a few new IPv6 functions, and iptables now won’t try to change stuff for IPv6 IPs. vif-route changes are: ndp is enabled for the vif device and the route/neighbor IPv6 settings are set)

So, now that the scripts know how to setup all our IPv6 needs, we need to add the IPv6 IP to our guest settings (.cfg file typically found in /etc/xen/). What we want to change is the “vif” setting. Add the IPv6 IP of the guest to the IPv4 IP (just the IP without the trailing /network, space separated form the IPv4 IP):
vif = [ 'mac=B1:A3:3F:25:11:B8, ip=2a01:4f8:100:1123::5 188.40.34.101' ]

Now you can create the guest(domU) and add the IPv6 IP to the /etc/network/interfaces of the guest if you haven’t so already (it uses the host (dom0) as the gateway).

iface eth0 inet6 static
address 2a01:4f8:100:1123::5
netmask 64
gateway 2a01:4f8:100:1123::2

Restart the networking on the guest (or reboot it) and you should now be able to ping the guest from the internet. See, easy wasn’t it 🙂