A Network Attached Storage(NAS) has been in my wanted list for quite a long time, thanks to Live Search Cashback program to make it happen: a Western Digital MyBook World Edition(500GB). More information about the hardware specification:

• ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) 99.73 MHz
• Memory: 32M
• VIA Networking Velocity Family Gigabit Ethernet
• WD5000AAVS-0 500G HD

I believe 100MHz ARM CPU is powerful enough to drive this tiny box, but the limited capacity of memory cripples it as a lame duck. The sustainable file write(85G using lftp mirror) rate is approximately 3.8MB/s. It hardly qualifies any service beyond file server. Now, it is time to hack.

Jailbreak and SSH

The first thing to do is to create a user in the web interface of MyBook as root with null password is banned for security reason. Log on with admin and 123456, create a user JOE and setup the password for later use.

Run the script discussed in the wiki, and ssh with JOE. Now you can su to root with blank password, 0wned!

User management

MyBook takes a very intricate way to manage users:

All Samba users are granted shell access, but unix password sync = yes is not set, the /etc/shadow and /var/private/smbpasswd are updated individually by a Perl script via the web interface. The only reasonable explanation is the minimized Samba lacks PAM support.

All user names are capitalized. I assume this is a brutal force approach to address the difference between Samba and Linux native accounts: Windows user name is case insensitive, while Linux is case-sensitive.

As the password scrambled in /etc/shadow, it is easier to add/delete/update users via the web interface, then fine-tune the corresponding files. The user administration executives are hidden in /usr/www/nbin.

Share with Samba

The default exported directory is /share/internal/PUBLIC, the permission of the directory is set as rwsr-sr-x, and the owner is www-data, YMMV. So any file/directory created will be owned by www-data. If you are unhappy with the name, you may add a user, e.g joe as discussed before, then add joe to www-data group:

remember to change the default mask in /etc/smb.conf:

Package management

Though I am a big fan of Gentoo, it is a little bit paranoid to build everything from scratch. A precompiled package management, like Optware makes more sense. Check out this tutorial for bootstrapping.

The essential packages for daily administration imho are screen, lftp.

Feature requests

There are some itchy miss features, if you happen to know a solution or hint, please drop me a message in the comment:

Access Anywhere No mionet, just SSH. If you are a perfectionist, consider to port this Delphi application to MyBook to host MyBook in your preferred domain.

Download Manager A web front-end to listen to download requests from Firefox/IE plugins, then delegate it to wget backend with cookie support. A more aggressive approach may support megaupload happy hour.

In the last post, I worked through the installation and deployment for Django application. And I setup a MoinMoin Wiki as well. Everything works fine until I switched back and forth between the blog and wiki, I got a MemoryError like this:

It is most likely that the two application’s memory footprints exceed the limit. Yes, FastCGI would rescue; unfortunately, it is another advanced feature you have to pay for. There is no explicitly regulation when I signed up but I think it is quite reasonable to set the resource quota as virtual server is essentially shared hosting shared anyway. I would contact the custom service of Jumpline tomorrow for a better understanding.

Update: just contact the customer service of Jumpline, they seen have no QoS of the memory footprint or CPU load. I really have no idea whether this good news or bad news.

In the last post, we manage to leverage eye3D for standardizing the ID3 tag. But we still got messy code when manually manipulating the tags in the command line. It may result in either wrong arguments or encoding bug.

Further investigation focused on eyeD3′s __init__.py:

Either LOCAL_ENCODING is None or mysterious ANSI_X3.4-1968, the encoding is assumed as latin1. In my Gentoo box, with do_setlocale set False, getpreferredencoding just returns ANSI_X3.4-1968 though the locale is en_US.UTF-8 instead.

According to the documentation:

On some systems, it is necessary to invoke setlocale to obtain the user preferences, so this function is not thread-safe. If invoking setlocale is not necessary or desired, do_setlocale should be set to False.

I need to dig into whether Linux belongs to some systems. Right now, just apply the patch to eyeD3′s __init__.py:

And remember to specify the encoding of tags using –set-encoding , RTFM for more details.

About nine months ago, I tried to embrace MTP since Creative Lab does not support their own proprietorial protocol(libnjb is the open source implementation) in Windows Vista, and I was really frustrated by the lame upgrade support.

Here is a chance for me to get a 2nd generation Zune which is powered by MTP. Although libmtp is still in very early stage to bridge the gap, we could predict its future from the history.

Amarok supports MTP if the USE flag mtp is enabled. However, the latest stable version 1.4.7-r2 has a bug when transfer file with CJK characters. The bug happens when interfacing with libmtp:

The bug is fixed in SVN (ticket), but if we take non-utf8-locale users into account, for example, MagicLinux takes GB2312 as the default locale, local8Bit may have more flexibility than hard-coded utf8, and it also worked in the UTF8 environment.

Here is the patch , and as usual, an ebuild for Gentoo users (manual).

Amarok developers probably barely thought about the response from the Chinese users when they eventually dropped the id3 tag codec detection, and enforced ID3v2 specification. “Amarok is dead”, claimed in linuxfans.org, the community-powered Magic Linux support forum. Why? Quite a few MP3 files are encoded in GB2312 on id3v1 in China and even worse, some files are encoded with GB2312 in ID3 v2.3 format. What a mess!

I respect their decision, the player has no responsibility to clean the shit of lousy encoders, but we need to face the reality by all means. Here is my cruel life: Amarok is preferred in Linux, occasionally I am using mpg123 in console mode; using foobar2000 in Windows, sometimes Windows Media Player; portable MP3 player is Creative Zen Micro. No Mac, no iPod. To make things even worse, the locale in Linux is utf8, while in Windows, it is utf16-le. Last but not the least, I do respect specification.

So ID3v1 is not considered, it only supports ISO8859-1, that make it impossible to hold CJK characters. For ID3v2, the most popular version is v2.3, unfortunately, it does not support utf8 encoding. v2.4 supports this codec, but it is seldom picked up by the hardware manufacturer or the application developers.

Let’s start from the latest specification. ID3 v2.4:

The first bad news is a de facto id3v2 implementation, id3v2-0.1.11 does not support v2.4. That cost several hours to figure out why the newly added v2.4 disappeared mysterically, the answer is id3v2 is even unable to recognize v2.4 tags. EyeD3 is the remedy, this pure python library provides a very neat command line utility to manipulate id3 v2.4 tags. The good news is Creative Zen Micro support v2.4. In fact, I am not quite sure whether the honor goes to Creative Lab, or the libnjb developers.

Another option is v2.3, most popular implementation so far. Unfortunately, it only supports unicode-LE(i.e the default locale of Microsoft Windows), unicode-be and latin-1, no UTF-8 support. To make it even worse, id3v2 writes to the tag regardless the locale, that is really horrible!

Here is my effort to address this problem, eyeD3conv, as the name suggest, it depends on eyeD3 library. This small utility will convert mistaken-encoded tags to standard Unicode16-LE ID3 v2.3 tag.

And you need to apply this patch to fix the encoding bug in eyeD3-0.6.14. The patch has been submitted to the upstream.

Update: thanks to the author of eyeD3, Travis’ quick response, according to the specification, the url is supposed to be encoded in ascii, so we can simply ignore the URLFrame. Forget the patch, and use theupdated-version.

Other mis-encoded frames may throw an UnicodeDecode exception when frame is read/written that cancels the succeeding file rename action. Here are some pragmatic tips to work around this issue:

No idea which application inserts such crap into the tag.