Jim's Depository

Today, my gift to you: After extensive research and testing, I have found a 3.5” SATA⇒USB enclosure that will work with smartmontools to allow you to monitor the S.M.A.R.T. data of your drive. This one may be unique in that I have an actual link you can click and buy the enclosure! 

You can get them from Amazon for \$30: Amazon.com: Sabrent eSATA to Serial ATA (SATA) and IDE(PATA) USB 2.0 3.5-Inch Aluminum Hard Drive Enclosure Case

Ugly Caveat: There are at least two different designs sold under the same model number. Some, possibly older ones though 2 of the 3 I got from Amazon today are this variant, have silver screws and absolutely awful power adapters with white labels. The part where the 120v cord enters is badly made and the cord will not make contact or make intermittent contact unless you cram it in very hard. The variant with black screws has a different model of power supply and seems to be ok. The box art work matches the unit inside. Both variants have the JMicron JM20337 chipset so all is good.

I’ve got a Western Digital Green 1TB (older model, 512 byte sectors) running in there and smartctl -d usbjmicron -a /dev/sdg is working perfectly on my Linux box.

(smartmontools 5.38 from Debian Lenny was not new enough. I think 5.39 would be, but I jumped straight to the dev edge.)

I couldn’t get S.M.A.R.T. to work with this drive on Mac OS X, same version of smartmontools, but it doesn’t want to talk to the drive.

I was experimenting with HTML-5 Web Storage when I realized Safari wasn’t showing me my storage use under the Safari⇒Preferences…⇒Security⇒Show Databases panel. A little find action shows that they live in databases named things like ~/Library/Safari/LocalStorage/http_SITENAME_0.localstorage, and good heavens there are a lot of them!

Most of them are for some sort personal information harvesting operation named loomia. They seem to be about personalized recommendations, but I don’t remember authorizing them to collect information on me, and I sure didn’t ask them to tag me with a tracking code tucked away in a location I can’t see that will survive cookie clearing.

Most of the rest are of the form IXAIInvited{number} = true. I have no idea what that is about, but the number isn’t long enough to be a unique identifier for me.

So Safari guys: I know you’ve been busy, but how about letting me see and manage my localStorage from the user interface?

(And while you’re at it, either make localStorage.setItem() work for objects, or update the documentation to mention that it is strings only. And give me my hour of debugging time back.)

I ordered a pair of Kodak Pulse 7" wifi picture frames from Provantage about 90 days ago which was long enough to forget, so it was like a little surprise gift to myself.

I intend to rip them open and see if I can replace their firmware with something I can control, but I fired one up to see if it could be made to work as a remote webcam viewer with its intended firmware.

I have to say I am impressed. The picture quality is quite nice. The web site for controlling the content is very nice (except that their applet signature does not have a valid signature). You can feed it from a web page, email, facebook, or some Kodak online gallery.

But here is the thing that makes me feel best about it:

On the support system they have an actual, honest, system status display. Very classy.

The 30 minute hacking report is:

• I don't think I can make it display a once/{timeunit} update of a webcam using the intended APIs. I could mail a new image to it regularly, but it doesn't display the latest one by preference. There is not a way to email a "delete". - It contacts Kodak home base (running on Amazon's EC2, S3, and CloudFront) once per minute where it does:
  1. Some secret SSL shrouded query that they don't let me see. 2. An NTP lookup from a random server on the planet. 3. An HTTP query to see if it needs an update, nice XML response. 4. If needed, the files are then requested by a UUID and come down by HTTP. - Blocking the SSL shrouded query stops the others, but I'm pretty sure I could make a proxy to replace the content with my own. This however only works for picture frames in my domains where I control the routers and can intercept. - I captured its firmware upgrade. The file will be useful.

Looking forward:

• I need to look at Amazon data rates and see if it would be abusive to use their browser API to upload and delete pictures, say once a minute all day. I'm sure that's more traffic than they expect, but perhaps the total cost is small enough to be ethical. - I'm itching to pop apart the 2nd unit, but I will wait until I have time to photodocument to see what is on the inside of these things.

I posted my code optimization with explanations regarding assembler etc at http://geekofpassage.blogspot.com/2010/05/win2k3r2ee-virtual-appliance-running-in.html

The unified diffs are available there too.

Cheers!

The available pages I can google about this seem overly complicated. This one documents setting up nginx to run lua scripts on Debian Squeeze. These instructions are derived from http://www.unreliablepollution.net/p/other/howto-nginx-and-lua and a dozen remedial googleings.

1. aptitude install nginx
   The config in /etc/nginx is good in squeeze. We will need to add the fastcgi handler, but that is to be expected. (I edited it to pull the root up to /var/www instead of in an nginx-default subdirectory.)
2. aptitude install liblua5.1-wsapi-fcgi-1
   There is also a ‘0’ version, but I took 1 on the theory that newer is better.
3. aptitude install liblua5.1-coxpcall0
   liblua5.1-wsapi-fcgi-1 probably needs a dependency on this. Things will go poorly for you without it.
4. aptitude install lua5.1
   Can’t forget that.
5. aptitude install spawn-fcgi
   Older instructions talk about libfastcgi-dev, but it isn’t available and I think they just wanted spawn-fcgi out of it anyway.

6. Put a Lua file in /var/www/hello.lua
   The WSAPI is a little strange. Apparently you don’t just print your output, but rather coroutine.yield() it. I used this example program from http://keplerproject.github.com/wsapi/manual.html …

   module(…, package.seeall)

   function run(wsapi_env) local headers = { [“Content-type”] = “text/html” }

   local function hello_text() coroutine.yield(”<html><body>”) coroutine.yield(”<p>Hello Wsapi!</p>”) coroutine.yield(”<p>PATH_INFO: “ .. wsapi_env.PATH_INFO .. “</p>”) coroutine.yield(”<p>SCRIPT_NAME: “ .. wsapi_env.SCRIPT_NAME .. “</p>”) coroutine.yield(”</body></html>”) end

   return 200, headers, coroutine.wrap(hello_text) end

7. spawn-fcgi -a 127.0.0.1 -p 9100 -F 4 -- /usr/bin/wsapi.fcgi
   Now we have handlers on port 9100. This will need to be in /etc/init.d/blahblahblah but this will do for now.
   Note: spawn-fcgi silently fails if you get the command wrong. Do a “ps” and make sure they are there. You will have a section like this if it succeeds…
   18554 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi
   18555 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi
   18556 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi
   18557 ?        Ss     0:00 lua5.1 /usr/bin/wsapi.fcgi

8. Edit /etc/nginx/sites-available/default to know how we want .lua files handled. I put in this section
   location \~ \^(.+\.lua)(.*)\$ { root /var/www/; fastcgi_pass 127.0.0.1:9100; fastcgi_index index.lua; fastcgi_split_path_info \^(.+\.lua)(.*)\$; fastcgi_param PATH_INFO \$fastcgi_path_info; fastcgi_param SCRIPT_FILENAME \$document_root\$fastcgi_script_name; include fastcgi_params; } Be careful! Make ‘root’ match your root!

9. Restart nginx. /etc/init.d/nginx restart

10. Load http://YOURSERVER/hello.lua in your browser. You should get something along the lines of:

    Hello Wsapi!

    PATH_INFO: / SCRIPT_NAME: /hello.lua

11. Celebrate!

Now my thoughts: This may be more than I wanted. I have to think about the implications of a scrutinizer layer above my Lua program. I really wanted to just blast my standard output back up the fastcgi socket. All this yielding seems strange.

3:14am, spring daylight savings time day. The church bells across the street have been ringing for 14 minutes.

After my dismal failure at Pohmelfs, I shopped for alternative distributed files systems. I can’t tell if CODA is abandoned or not, but I’ll give it a try.

1. Build into kernel 2.6.33, no problems.
2. Debian has let their user mode utilities rot away.
3. CMU has prebuilt .debs, including for Squeeze. That looks good.
4. Add the CMU apt sources, looks like this now… # cat /etc/apt/sources.list.d/coda.list deb http://www.coda.cs.cmu.edu/debian lenny/
5. aptitude update ; aptitude install coda-server, scary text about unsigned packages follows, but it is OK.
6. Configure server with vice-setup
7. Similar for the client machines, except aptitude install coda-client… ends with 00:35:02 Venus starting… 00:35:02 /coda now mounted
8. Test client with CMU’s server: # cfs lv /coda/testserver.coda.cs.cmu.edu Status of volume 7f000000 (2130706432) named “/” Volume type is ReadWrite Looks good. I can read the sample documents.
9. Test client with my server: Much hanging and server not founding. Most likely related to my “hostname” being an internal address unreachable by the client. There is a spot in the /etc/coda/*.conf file and in one in the /vice directory, but it still attempts to use the unreachable address and no hints in vice-setup on how to force an address.
10. I temporarily change my hostname to the external interface address. No luck. The client does a pile of DNS lookups for SRV records for my host with _codasrv._udp prepended, then does one for a regular A record. Gets my address, but never tries to contact.
11. Reboot client. Success! Now we can connect. Something evil must have been cached.
12. Many failures to authenticate with clog until I realize that the example I’m working from only has an account of admin because that is what they gave vice-setup. Use the account I gave with the password “changeme” and I’m in.
13. Find cpasswd, change that password.
14. Try to make myself a user account. au -h MYHOST nu, coda is a pretty hostile system. It echoes my new password in the clear even though it knows how not to, then fails with AuthNameToId() --> AUTH_FAILED
15. Find pdbtool. Use it to make my account from the server side, but I can’t see how to set the password. Go back and try au from a client, and now I can set my password.
16. Notice I have no group. Use pdbtool to make a group with my name, program explodes with an assert failure. That’s going to be a problem.
17. Unpack a linux kernel on the client. It flew until arch/arm, not it is crawling along at about 1 file per second. No load on server, no load on client, no load on network, just glacial progress.
18. Abandon Code!

Coda is badly documented, user hostile, and not robust.

I do not trust it.

I’ve enjoyed reading zbr’s blog postings about POHMELFS and the Elliptics network for years. With POHMELFS in the staging directories of Linux 2.6.33 and me needing to share some files across several machines, it is time to try it out.

1. Build myself some fresh new 2.6.33 kernels with POHMELFS enabled.
2. Look for a HOWTO of sorts, fail.
3. Check the server out with git: git clone http://www.ioremap.net/git/pohmelfs-server.git
4. Follow the included README
5. Fail, install autoconf.
6. Fail, finally discover that --with-kdir-path=<mylinuxsourc>/drivers/staging/pohmelfs/ is the right answer.
7. Fail, install libssl-dev.
8. make
9. make install
10. Copy /usr/local/bin/cfg over to the client machines.
11. Make a new filesystem to export mounted on /jim.
12. Start the server: fserver -r /jim
13. Go to a client machine:  #cfg -A add -a 1.1.1.1 -p 1025 -i 1 # mount -t pohmel -o idx=1 none /jim Killed
14. That isn’t good. dmesg reports there is a null pointer reference in the kernel.
15. Find two patches that will be in 2.6.33.1 related to “bdi” and not having a real backing device. Add them and make a new kernel.
16. Fail, badly. Please remember to change your version number in the kernel make file, lest you also forget the init ramdisk and make an unbootable system.
17. Success! With these patches I can now mount my pohmelfs partition! Unpacking a linux source tree is pleasently quick.
18. Failure! Chowning the source tree fills dmesg with things like…  pohmelfs_insert_hash: exist: parent: 856, ino: 879, hash: 9f4b42c5, len: 14, data: ‘README.syncppp’, new: ino: 37643, hash: 9f4b42c5, len: 14, data: ‘README.syncppp’. Chown silently and slowly fails.
19. Unmount and remount. Now chown hangs after a small amount of progress. No messages in dmesg this time. No changes make their way to the server.
20. I’m beginning to think Pohmelfs is not ready for me.

I will go shopping for other distributed file systems.

Let’s just say you have taken your old PPC G4 mac Mini with the dead hard disk and fitted it with an 8GB compact flash card in a 2.5” IDE adapter. Installing Debian Lenny on there is easy, but you end up with an ext3 journaled filesystem that may be concentrating wear on the journal area.

NILFS2 is a spiffy new filesystem that probably doesn’t concentrate wear and is attractive when writing is slower than reading. Sounds great, but yaboot doesn’t know how to find the kernel and initrd.img on it, so you need to make an ext2 /boot partion and then tell yaboot to look there.

The secret is in the naming of the files in yaboot.conf. Here is mine:

boot=/dev/hda2
device=hd:
ofboot=hd:2
partition=4
root=/dev/hda4
timeout=50
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
enablecdboot

image=hd:3,/vmlinux
    partition 3
    label=Linux
    read-only
    initrd=hd:3,/initrd.img

image=hd:3,/vmlinux.old
    partition 3
    label=old
    read-only
    initrd=hd:3,/initrd.img.old

As you can see, hda3 is my /boot, hda4 is my root.

Astute readers will also notice that you have to either save a partition or migrate from another drive to pull this off since you need to build yourself a shiny new 2.6.31 kernel with NILFS2 compiled in.

Note: My G4 Mini has developed an odd hanging problem when using X programs with the root on NILFS2. I’ll go back to ext2, 2.6.26 for now then try ext2 2.6.31 and see where the trouble lies.

I just finished finding a four day bug. It sounds simple in retrospect, but oh the wrong paths I have trod and wild codes I have explored.

If, like me, you run Debian on tiny routers, like WRTSL54GS or other Broadcom units from Linksys, you probably use an OpenWRT kernel and a Debian root. Somewhere between 2.6.25 and 2.6.28 the OpenWRT people chopped the FPU emulator out of their Linux tree. Sadly for Debian people this causes any program you try to run, like init, to hang in an infinite loop.

The solution is now enshrined over at https://dev.openwrt.org/ticket/5774 where it talks about the invisible kernel config option: MIPS_FPU_EMU.

Addendum: Oh yeah, you are going to want to go into drivers/usb/host/ehci-ssb.c and pull the static off of ssb_ehci_attach and ssb_ehci_detach if you want USB 2.0 built into the kernel.