Knowledge Base

Long story short: I've been to the US a few weeks ago and I thought I'd pick up a new Xbox 360 250GB while I was there, seeing as those are hard to find in China. I assumed its power supply would accept both 110V and 220V (like my PS3 and most modern PCs and laptops.) Well, it did not.

Of course, I did not just plug it in and watch explode. I first opened up the power supply (not an easy feat, let me tell you) and only plugged it in after noticing the board inside had "250V" written on it, with a check mark next to it. Not sure what that meant though. It still blew up after I plugged it in.

I already had a plan B from the moment I bought the Xbox: the power supply output 12V and 5V, much like a regular PC power supply. So I bought a (mini) ATX power supply and went online to see if I could find the pinout. Plenty. When I plugged in the ATX power source, I measured the voltage on a few pins, but got nothing. Then I remembered the fact that an ATX power supply does not really turn on until the PC tells it to. This is done by shorting pin 14 of the ATX plug (green wire) to ground (black, any will do.) Once I did that, I got all the power I needed.

The pinout on the Xbox side was harder to come by. I had found a few for the old Xbox 360, but none for the new slim model. Fortunately there were some hints on the PSU's board:

Yellow 12V
Black GND
Red 5VSB
Blue PS_ON
Gray RSENSE

I thought I'd check what I could get away with: I connected the yellow wire from the Xbox to the yellow wire of the PSU. Same for the red wires, and black wires, matching the colors. Then, I turned on the power supply by connecting the green wire on pin 14 to a black wire. I pressed the button on the Xbox: success!

Having the power supply turned on all the time was not something I liked though. So the next step was to get the power supply to turn on together with the Xbox. By measuring the voltage I saw the blue PS_ON wire being pulled up (~3.3V) when the Xbox wants to turn on. In order to do this, the Xbox needs some power though. This is done by the red "5VSB" wire. The "SB" stands for Stand By. This means that the red wire from the Xbox must not be attached to the red ATX wires, but to the purple wire on pin 9.

This page explained how: use a transistor or optocoupler that will connect the green ATX wire to GND when the blue Xbox wire goes up. I had no optocoupler lying around, or so I thought. I then noticed the blown up power supply on the table. There were some things on it that looked a lot like optocouplers. Sure enough:

The datasheet for the EL817 can be found here.

So, pin 1 of the optocoupler (the pin near the dot) will be pulled high, to ~3.3V. We want to give the LED inside about ~1.2V, that leaves 2.1V for a resistor. At about 20mA this means we need a V/I=R 2.1/0.02= ~100 Ohm resistor. 100 Ohm = 10*10, 10 times 10 to the power 1: we need a resistor with Brown, Black, Brown rings. Luckily I found one

I had everything I needed:

Yellow (Xbox) - Yellow (ATX)
Red (Xbox) - Purple (ATX)
Blue (Xbox) - Resistor - Optocoupler pin 1
Black (Xbox) - Black (ATX)
Optocoupler pin 2 - Green (ATX)
Optocoupler pin 3 - Black (ATX)
Optocoupler pin 4 - Black (ATX)
Gray (Xbox) - unused

I had no idea what the gray RSENSE wire was for, so I just ignored it and it worked fine! Once I got everything figured out, I opened up the ATX PSU and removed all the wires I didn't use. Important: there was a brown wire that got connected to a orange (3.3V) wire IN the ATX power connector. So after cutting of the connector I had to connect the brown wire to 3.3V somewhere inside the PSU.

And all it cost me was an ATX power supply and 1 blister. Not bad

UPDATE: Here's the schematic for the whole thing:

Inspired by this page on NAS-Central, I ordered a USB sound card on TaoBao (15 RMB including delivery!) and plugged it into my LinkStation. A quick dmesg showed that the device was detected, but not recognized.

The NAS-Central page mentions that some kernel modules are needed to get USB audio to work, but of course, the device does not have these modules by default. After googling for a few hours I still could not find any precompiled modules that matched my LinkStation's kernel version, 2.6.22. I decided to jump in and try to compile the modules myself.

So how do you compile kernel modules?

Well, first of all you'll need the correct kernel sources, but that's easy: Buffalo provides them. Download the linux-* package that matches your NAS.

Now you need a compiler. Turns out Buffalo uses CodeSourcery so we best stick to that as well. Get the pre-compiled cross-compilation toolchain here. Select "ARM GNU/linux" and the operating system that you will use for building. No need to download the toolchain source.

Before we can compile the modules we need a kernel configuration file. Some Buffalo source packages seem to include it (the file is called .config and is hidden because of the leading dot) but the one I downloaded did not include one. Copy this file into the root of the folder where you've extracted the Buffalo sources. This .config file most likely has all support for audio disabled so we'll enable it by adding CONFIG_SND=m (or check whether there's a CONFIG_SND present and change that to =m). The 'm' tells the make file to build it as a separately loadable module, instead of building it into the kernel. (Since I didn't want to change the stock kernel, I had to build loadable modules instead.)

Now the good part starts: make modules

The make file should notice the new CONFIG_SND directive and ask you about the specific sound related modules. Make sure you answer 'm' to all of 'em. You don't need them all, but figuring which you need/don't need is too much work.

When make is done we need to 'install' the modules, but not in our host/build system of course! Use the INSTALL_MOD_PATH directive to copy the built modules into a separate folder: make modules_install INSTALL_MOD_PATH=/tmp/MyModules

When done, copy all the files from /tmp/MyModules/lib/modules/2.6.22.7ownkernel/kernel/sound (recursive) to your NAS. Now comes another the tricky part: loading the needed modules. The module you need is snd-usb-audio and snd-pcm-oss, but before this one will need you'll have to load a couple of others. The normal way this is done is to move the modules into the NAS's kernel folder and issue a depmod -a to update the module dependecies and a modprobe snd-usb-audio to load the module with its dependencies. I did it the wrong way: using insmod to load each module by hand, and trying to figure out the order in which to load them by trial-and-error. Eventually, insmod snd-usb-audio.ko loaded without complaints.

Last step: create the device nodes. As per the NAS-Central page:

cd /dev
addgroup audio
mknod -m 660 mixer c 14 0 ; chgrp audio mixer
mknod -m 660 mixer1 c 14 16 ; chgrp audio mixer1
mknod -m 660 dsp c 14 3 ; chgrp audio dsp
mknod -m 660 dsp1 c 14 19 ; chgrp audio dsp1

I am now able to stream music using mpg123, madplay, mpd (all installable using ipkg.)

The sound quality of that 15 RMB sound card sucks though

Here's the final .config file I used to build the sound modules.

I've just finished my first app and have published it on the market! The app is very simple: it shows the current air quality in Beijing, as measured by the US Embassy. Scan the QR Code on the right and my app will pop up in the market app.

(project page on Google code)

In a last effort to save e-mail from being obsoleted, some guys at Yahoo thought of the DomainKeys system to prevent message spoofing. SMTP servers that are DomainKeys-aware can check the contents of the message to find out whether it was really sent by the person mentioned in the From: mail header.

To be honest, I'm more of a fan of SPF. It's an incredibly simple protocol and I really can't think of any reason it shouldn't be used by any mail server. (Interestingly, the Yahoo mail servers don't use it, probably to boost acceptance of DomainKeys.)

Let's explain SPF first, since it so much easier. In a nutshell: SPF uses DNS records to identify which IPs are allowed to send mail for a domain. So a server receiving mail for somebody@example.com would fetch the SPF record from example.com and check whether the IP of the connected SMTP client is actually allowed to send mail originating from the example.com domain.

That's it, it's that easy. Since I'm hosting my own mail server, my domain's SPF record just mentions my mail server's IP (actually, it doesn't mention the IP directly, but refers to its DNS A record.) A server receiving an e-mail that was allegedly sent by me will just have to check whether the SMTP client is in fact my own mail server and if it isn't, reject the mail.

DomainKeys is a little more advanced. Instead of checking the IP, it will check all contents of the message. It's like the mail server is signing the message on your behalf. Using DKIM, each outgoing message will be signed using the server's private key, and DKIM signatures present in the incoming message will be checked against the originating server's public key. That public key, by they way, is distributed using a DNS record, similar to the way SPF records are distributed.

Here are the steps I did to get DKIM working on my server. First, create an RSA key pair:

openssl genrsa -out private.key 1024
openssl rsa -in private.key -out public.key -pubout -outform PEM
sudo mkdir /etc/mail
sudo cp private.key /etc/mail/dkim.key

Now you'll have to add the public key to your domain(s) DNS entry. Do this by adding a TXT record for selector._domainkeys.yourdomain.com, where selector can be anything, but make sure to mention the same selector in the config file.

Next, install dkim-filter and edit the /etc/dkim-filter.conf Domain, KeyFile and Selector settings. Domain= comma separated list of domains for which to sign the mail; KeyFile= path to above keyfile; Selector= domain name prefix.

sudo apt-get install dkim-filter
sudo vi /etc/dkim-filter.conf
sudo /etc/init.d/dkim-filter restart

Add the following to /etc/postfix/main.conf:

# DKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

and restart postfix.

To test whether it's working as it should, send yourself a mail and inspect the headers. Or, you could for example send a mail to a gmail account and gmail will show that the mail is "signed-by" your server.

I've moved this blog from directnic.com to my own VPS. This blog is using Serendipity, which consists of a bunch of files for the webserver and a MySQL database. (I during the move I noticed that the new version supports SQLite backend, which would have made this whole process a lot easier.)

What I did:

• Copy all files from the old server to the new server, using ncftp's recursive mget.
  
• Dump the MySQL database using mysqldump
  
• In MySQL client: create a new database using CREATE DATABASE xxx, select it using use xxx and execute the exported SQL script using source dumpfile
  
• Configure an Apache virtual server for the lunesu.com domain. Note to self: must check Include all addresses in Webmin's Networking and Addresses Apache configuration tab.
  
• Apply the new Apache configuration.
  
• Add lunesu.com to my local hosts file, to be able to test the new site without having to change the DNS settings.
  
• Oops: ncftp did not get the serendipity_config_local.inc.php because it was readable by user httpd only! The only way I was able to copy this file was by uploading a dummy PHP script with the following contents: <? header('Content-Type: text/plain' ); readfile("serendipity_config_local.inc.php");
  
• UPDATE serendipityConfig SET value="/var/bla/path" where name="serendipityPath";
  
• I also had to change some folder permissions: chmod 1777 . archives upload plugins templates_c
  

The serendipity Weather sidebar plugin failed to work. I read that it needs the PEAR:Services-and-Weather module for PHP so I installed that using sudo apt-get install php-services-weather. Unfortunately, that completely borked my site. I was able to track this down to a function in Serendipity called get_plugin_title. Apparently, even with that module installed, the weather plugin still wouldn't work. Fix: disable the weather plugin.

Back from holiday, no job, but my lunesu.com mail stopped working so that should keep me busy a couple of weeks.

The mail (like this site) was still hosted at directnic, so when their mail server stopped working this morning I had enough motivation to move my lunesu.com mail to my new VPS.

Since postfix was up and running from the beginning, there was little left to do. I just had to instruct postfix to accept mail from all my domains, not just the main one from the hostname. This could be done from within webmin: Server, Postfix Mail Server, General Options, What domains to receive mail for. Select the last option. I just appended lunesu.com to the comma separated domain list. Click Save and apply.

Next step: fix the certificate warning I get when trying to send mail through my own server. The fix: in Webmin's Postfix page, select SMTP Authentication And Encryption. Change the paths of the certificate and private key files to the ones created before. Save.

I also use a lot of aliases. Basically, I create a new mail alias each time a vague site wants my email address. Since I have about 25 aliases, I use Webmin's Edit Map Manually option in its Mail Aliases page. This works fine, but it won't be applied automatically after save! I had to run the following command as root for the aliases to start working:

newaliases

Another thing I noticed is that Postifx apparently always recognizes addresses of the form account+suffix@domain and delivers them to account, without the suffix. This how I made most of my aliases in the first place, so all of those with a plus sign could be removed from the aliases map. (Of course, the part before the plus sign must still be an existing account name or alias.)

So, most of it seems to be working at the moment, but no anti-spam yet, which is really the next thing I need to figure out before I get drowned in spam messages.

partial class StaticAssert
{
byte a = RenderQuality.Low < RenderQuality.Medium ? 0 : -1;
byte b = RenderQuality.Medium < RenderQuality.High ? 0 : -1;
}

Apparently ?: is being folded at compile time, resulting in the following error if the constant expression before it evaluates to false:

Constant value '-1' cannot be converted to a 'byte'

I use partial class to prevent collisions with multiple static asserts in the same namespace, although you will still have to come up with unique variable names.

Also, I've hidden my post about [tee'bet] to see if that will lift the blockade of my site in China.

The language for the GIMP and the SubVersion command line tools can be changed to another language by setting the LANG-environmentvariable to "en".

LANG=en

It's too bad wget does not support a SOCKS proxy. To tunnel wget through an SSH tunnel you'll have to rely on a statically mapped port:

plink -L 8080:example.com:80 server

This command opens a local TCP port 8080 and routes all connections to example.com port 80, using an SSH connection to server. Here, server can be either the URL or IP of an SSH server or the name of a putty profile.

wget can now be pointed to the localhost:8080, but this won't work if the HTTP server is using virtual hosts. Use the --header= option to insert a fake host string in the HTTP request:

wget --header="Host: example.com" http://localhost:8080/.....

From mztools.com:

You can follow this procedure to extract the assembly from the GAC:

Open a MS-DOS command window (click Start, Run... type cmd and press enter)
Use the SUBST command to map a drive letter to the GAC folder:

SUBST G: C:\Windows\Assembly

That maps the drive letter G: to the GAC folder. With the SUBST command you bypass the shell extension.

Use Windows Explorer to browse the G: folder. You will see the actual folders, with names like GAC, GAC_32, GAC_MSIL and one subfolder for each assembly. Once you locate the assembly DLL that you are looking for, you can copy it outside the GAC, to the \bin folder of your add-in project and add a reference to it.

When done, you can undo the mapping using:

SUBST G: /D

From Chris Ilias' Blog:

To make Thunderbird use your Outlook Express address book, close Thunderbird, and add the following lines to your prefs.js file:

user_pref("ldap_2.servers.OE.description", "Outlook Express");
user_pref("ldap_2.servers.OE.dirType", 3);
user_pref("ldap_2.servers.OE.uri", "moz-aboutlookdirectory://oe/");

For Outlook Contacts, use these lines:

user_pref("ldap_2.servers.Outlook.description", "Outlook");
user_pref("ldap_2.servers.Outlook.dirType", 3);
user_pref("ldap_2.servers.Outlook.uri", "moz-aboutlookdirectory://op/");

One important note: in order for it to work with Outlook, Outlook must be set as the system default mail client.