These parts can be a valuable resource for keeping systems running. Sure they may be out of date, kind of crappy parts, but these are just the things that are almost sure to work, especially with linux systems. The older (within reason) a part is, the more likely there are drivers in the mainline kernel. And if there aren't, there should at least be a good pile of google hits on how to get the darn thing to work. The best part is the old bits are usually free! They tend to be left overs scavenged from my own machines that died in one way or another. Even better, a lot of them come from old borked windows systems that people would rather throw away than try to use... go figure.

There are entire businesses devoted to just this kind of thing too. I'm sure you've seen them in your town. They are locally owned small computer shops with so much stuff piled up in them that you can't see in the windows. There's usually some only marginally helpful person behind the counter who refuses to come out and help. There are boxes piled high with green computer cards labeled "network cards $5" or "pci video cards $8" or whatever. These places are also a treasure trove of sometimes decent, slightly out-of-date tech. Sometimes you can find a nice haul of pretty good stuff that was scrapped by company in some company-wide upgrade. I once found a whole bunch of what were once top-of-the-line network cards for literally about $4 a piece. A bought a bunch and they work great.

What's the point of all this? Well, my wife's computer broke (ahem) yesterday. So I fiddled around with all the parts I had and determined that I had no combination of spare motherboard and processor that would actually work. So off I go to my usual crappy old parts store. Unfortunately they're GONE! What? I head to the next one up the street and they don't really have any used parts to speak of. You could see in the windows, it was a clean place, and the counter guy was actually helpful. That's no good... So I head to the last place I know of and while they're still there, they are getting ready to close that store and will probably scrap all those old parts! Horror!

This has gone on long enough. Suffice it to say that there is a sad change a-foot in the computer world. The spare parts stores are closing down... Where will I go when I run out of parts here in my basement?

collapse

This shot is of the Grid layout with Magnifier set to 120%. It took a while to come up with the right combination of alpha settings and colors to make me happy...

And here is a Circle layout, fun...

collapse.

Why?

Because I can? (I think...) Debian is known for never needing to be reinstalled unless you crash a small plane into the case, or something like that. So I want to see if I can get the whole lappy converted over without having to wipe the system. I've got the system more-or-less configured the way I like and don't want to do that again. And, its a challenge, so why not...

Current Configuration

delappy:/# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda3             9.2G  1.9G  6.9G  22% /
tmpfs                 249M     0  249M   0% /lib/init/rw
udev                   10M  108K  9.9M   2% /dev
tmpfs                 249M     0  249M   0% /dev/shm
/dev/hda1              96M   47M   44M  52% /boot
/dev/hda6              42G  2.6G   37G   7% /home
/dev/hda5             3.7G  991M  2.6G  28% /var
delappy:/# fdisk -l

Disk /dev/hda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00055945

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14         136      987997+  82  Linux swap / Solaris
/dev/hda3             137        1353     9775552+  83  Linux
/dev/hda4            1354        7296    47737147+   5  Extended
/dev/hda5            1354        1840     3911796   83  Linux
/dev/hda6            1841        7296    43825288+  83  Linux

As you can see, I've already got the disk partitioned out, and while I'd like to use something like LVM, at the moment, I don't think I will.

The Plan

The plan is pretty simple. First, since there's room on hda3 (current /), I'll just move the existing data (home and var) into that partition and go from there. I can lay encryption over the existing partitions and move the data back. I'll use hda6 as / temporarily while working on encrypting hda3 that and then move it all back, carve it up into its various parts and then be fully encrypted except for swap.

There are other details to work out as well. For example, I plan to put the root key on a sd card so that it can be used as a boot key. This will be much easier than keeping track of a really really long passkey, though the passkey will still work if I somehow lose the sd card.

I'm sure there are more details to be worked out and I plan to keep notes on it all as I go along and ultimately, I'll post the results here.

Sources

These are the places I've used for research prior to embarking on this:

http://www.hermann-uwe.de/blog/towards-a-moderately-paranoid-debian-laptop-setup--part-1-base-system http://wejn.org/how-to-make-passwordless-cryptsetup.html http://www.debian-administration.org/articles/428 http://www.saout.de/tikiwiki/tiki-index.php

and surely others. I'll try to add them as I go.

hide

Part 1

Most of the available info on the web is from a couple years ago, which I usually find encouraging. If there's no noise about it, then maybe it just works now? Nope.

I'm using at76c503a-source which originally comes from http://at76c503a.berlios.de/.

I've aptitude install'ed the package and it drug in atmel-firmware as well.

This package is designed for use with module-assistant. Building it should be easy:

m-a a-i at76c503a

but it fails with

make[3]: Entering directory `/usr/src/linux-headers-2.6.22-2-k7' 
  CC [M]  /usr/src/modules/at76c503a/at76_usb.o
/usr/src/modules/at76c503a/at76_usb.c: In function ‘at76_ieee80211_to_eth’:
/usr/src/modules/at76c503a/at76_usb.c:3379: error: ‘struct sk_buff’ has no member named ‘mac’
/usr/src/modules/at76c503a/at76_usb.c: In function ‘at76_ieee80211_fixup’:
/usr/src/modules/at76c503a/at76_usb.c:3430: error: ‘struct sk_buff’ has no member named ‘mac’
/usr/src/modules/at76c503a/at76_usb.c: In function ‘at76_rx_monitor_mode’:
/usr/src/modules/at76c503a/at76_usb.c:3856: error: ‘struct sk_buff’ has no member named ‘mac’

that's a problem. But I only have the linux headers installed and not the full source. I'm going to pull that down and try again, or maybe grep for those structures and see if I can figure it out. meanwhile, I'll email the maintainer and see what I can find...

Part 2

So, not to be deterred, I downloaded the upstream tarball from berlios. Lo and behold, it compiled and works just fine... go figure. So I filed a bug_report against the source package at debian. The maintainer was quick to respond that the package needed upgrading to the newest version quite badly. A little back and forth and he is working on getting updated after I confirmed that it builds just fine against the debian kernels.

Long story short, the upstream sources work fine for this adapter, and a fix will be in debian soon.

Part 3

So this adapter works just fine, but has some shortcomings. The firmware required to operate it is very restrictive and won't let you do lots of nice things (like wpa!). So I think this adapter will get relegated to the trash heap at some point. Or maybe get added to a kid computer at some point. It has decent power and works well throughout the house, but its limited to 11Mbps (802.11b I think) and doesn't deal well with some of the settings on the laptop.

hide

So, in the interest of making my life easy, I have setup gdm so that the kids can login through the browser by clicking their .face file. I've also deleted their passwords

passwd -d -u kid-name

This gives the kids an empty password so that they only need a user name to login. But pam won't let you just do that and gdm appears to use pam so... You have to tell pam that its okay too. Edit /etc/pam.d/common-auth. Change:

auth required pam_unix.so nullok_secure

to

auth required pam_unix.so nullok

and now the kids can log in with a single click.

Now if only I could get them to log back out...

hide

Default Authentication (signinedit)

Ikiwiki comes with a default password authentication system that is pretty simple but effective. Users must login to make use of any editing features. Couple that with

account_creation_password => "super-secret-passphrase-that-you'll-never-guess"

in the ikiwiki.setup file and you've got a pretty simple, but reasonable way to control access to the wiki. You control who has access by requiring an administrator to enter the account creation password at the time an account is created. I haven't yet investigated what happens when you enter an incorrect accountcreationpassword, but I'm sure fail2ban can be configured to pick it up and shutdown access to someone trying to crack it. This is by no means a Fort Knox of security, but it seems pretty reasonable and like the bars on the window, will keep the honest folk honest. But there is still one major vulnerability that I wanted to get rid of: all this stuff happens in plaintext. This is not an issue for most of our access to this wiki as it happens from our LAN, and is properly firewalled and audited. However, we're getting ready for the trip of doom and want access from anywhere. The world abounds with packet sniffers and compromised network connections and sending cleartext authentications out into that world is not a pleasant thought.

mod_ssl

I spent a couple days trying to figure out how to get some kind of encryption involved without unnecessary complication or overhead. The first, simplest solution is to put the whole thing under mod_ssl with

<VirtualHost *:443>
    ServerName wiki.swclan.homelinux.org
    DocumentRoot /var/www/ikiwiki/
    SSLEngine on
...
</Virtualhost>

but these seems extreme to me. This would put the entire website under SSL and that's really not necessary. Plus, since I'm using self-signed certificates, could cause warnings to pop-up just for someone to view the site. Plus SSL slows down access...

mod_auth_digest

The next solution I considered was to turn over authentication to mod_auth_digest. My understanding is that this provides authentication without the clear text password. I'm sure its not all that secure (its and MD5 checksum of the username, password, requested URL and a couple other bits) but it at least removes the "clear text passwords floating through the air" problem. Its also dead simple to setup

<VirtualHost *:80>
   ...
   <Directory /cgi-bin/>
       AuthType Digest
       AuthName "restricted wiki"
       AuthUserFile /path/to/password/digest
       Require valid-user
    </Directory>
</VirtualHost>

along with using the htdigest program to setup passwords for your users. Finally, you have to setup

cgiurl => "http://wiki.swclan.homelinux.org/cgi-bin/ikiwiki.cgi",

and

wrappers -> [
....
    wrapper => "/var/www/ikiwiki/cgi-bin/ikiwiki.cgi",

in your ikiwiki.setup file so the wiki can point to all the right places.

This worked pretty well in that it allowed authentication with reasonable security from publicly accessible networks. But there are some problems:

1. With the ikiwiki authentication (signinedit) still turned on, people have to actually autheticate twice -- not a great solution, escpecially since the kids want access too.
2. With the ikiwiki authentication (signinedit) turned off, the commits become anonymous. Instead of AndrewSackville-West showed as the committer, you just get an IP address. This isn't a big deal other than I don't like it...

Rewriting

The next solution was an utter failure: Rewriting. Apache lets you do all kinds of fancy stuff with rewriting and redirecting requests. That's all cool, but in the final analysis was unworkable for me. Probably there is some awesome rewriting-fu that could make it work, but all I got was errors when trying to commit edits.

Final solution

The final solution to this problem was overwhelmingly simple. Isn't that always the way it is? I'm embarrassed at how simple it is, and how ridiculously obvious in hind-sight. The solution is to change ikiwiki.setup:

cgiurl => "https://wiki.swclan.homelinux.org/cgi-bin/ikiwiki.cgi",

note the https in the url. Also setup apache with:

<VirtualHost *:443>
    ServerName wiki.swclan.homelinux.org
    DocumentRoot /var/www/ikiwiki/
    SSLEngine on
    SSLCertificateFile 
    ....
</VirtualHost>

and it just magically works. The ikiwiki.setup change makes all links in the wiki that point to the cgi script point to an SSL version of the website. Dead simple. I'm sure I could tweak it so that only cgi requests are accessible through the SSL version of the site, but I'll leave that for another day. As it is, someone could access an SSL version of the site by manually entering an https:// URL, which puts us in the same situation as the original solution, but that's their problem. I suppose I could

RewriteEngine on
RewriteRule !^cgi-bin/(.*)$ http://wiki.swclan.homelinux.org/$1 [R,L]

or

<VirtualHost *:443>
    ServerName wiki.swclan.homelinux.org/cgi-bin  #not sure this works...
...
</VirtualHost>

but that's for another day.

Please let me know what you think.

hide