Never underestimate the bandwidth of a station wagon full of tapes.
-- Dr. Warren Jackson, Director, UTCS
Many moons ago, on the original AmigaOne beta testers mail list, one of the mailers referred to their gigabit sneaker net. An external hard drive which they would walk home from the office with.
In networking terms, bandwidth is the capacity of the network to transfer data. If you ignore the underlying medium (which really doesn't matter), you can see that sneakernets often have very high bandwidth. Take a 3TB external drive. Over 10 mins (600s) the unidirectional bandwidth is 50 gigabit/s (assuming 10bits/byte). Of course, if you also need to transfer the data from a system to the 3TB drive, and then to another system, bandwidth is greatly reduced.
But back to the quote. Let's assume some 1.5TB LTO-5 tapes. Let's assume a rather conservative capacity of the station wagon of 5000 tapes. That's 7.5 petabytes. Over an hour, that would be about 16terabit/s, or Sydney to Melbourne about 1.5tbps. Which doesn't compare too badly to a fibre optic link.
Of course, sneakernets or stationwagon-nets may have high bandwidth, but there are two big issues to consider. One is that these nets are half duplex. If you require a network technology that allows you to communicate back and forth a lot, something involving time critical dynamic data processing (like gaming), it's not so great. The other thing to consider is transferring to transport medium from the system. Maybe with a hard drive, this is not such a problem. You could keep your home folder on an external hard drive or, maybe the whole system on a removable bay. But for tape, which is necessarily an offline medium, you lose a lot of time in the transfer.
However, if what you need to do a one transfer of a large amount of data, sneakernet or car net, will usually outperform ADSL, SHDSL or even 10mbit fibre.
So, this weekend I did the usual housework, eating, sleeping, watching TV etc, that people the world over do of a weekend. The other thing I did was install Debian on a mini-ITX system, and Mac OS X Leopard on a PowerMac G4 Cube.
The Cube is a little upgraded, having an 80GB hard drive, 1.5GB RAM (a Friday night upgrade after ordering 2x 512MB sticks from OWC), Airport, nVidia 6200, and a Sonnet 1.2GHz G4. Since the CPU is upgraded, Leopard will install without issues (it has a 867MHz G4 minimum requirement, although trivial to get around). I did the install using Netboot from a virtualized 10.5 server (another weekend project). I created the boot image from a 10.5.4 ISO image, which was mounted to the VM (Fusion) using the virtual optical drive device.
Boot over the network from the image, and then upgrade the installed 10.4.11 Server (this Cube was set up briefly as a server). There were, needless to say, a couple of hitches. I could not remember the original password for the admin account (I had to reset it last time, as well), so I needed to reset the password using the install disk, which did not work. So, retry to make sure I had clicked all the right buttons etc, and still no go, so a boot to single user mode to edit the local directory using dscl.
Dscl showed that the user accounts had not been imported. The home folders were there, but no account entries in the local node. So, reset the root password, reboot, login and then re-created the account. dsenableroot is a nice trick,
The other, small, issue was that the Airport card could not connect to my draft N WiFi (airport express). Not a big deal since 10/100 Ethernet is working, and I can always plugin in an older basestation (WAP) if needed.
Next trick is to get an SSD drive to saturate that slow 66mbyte ATA bus
Open Directory is one of the harder components of Mac OS X server to recover.
I recently had two opportunities to fix bad OD services on two Macs running 10.6 server.
The first server was in a bad way. The OD was not accessible from Workgroup manager, and was not running in Server Admin. Users could not authenticate against the OD.
The usual poking around showed that LDAP was dead. Google lead me to:
sudo db_recover -h /var/db/openldap/openldap-data
Which failed. However, using man db_recover, I came across the option
Perform catastrophic recovery instead of normal recovery.
Which did the trick, nicely.
What caused this failure? Well, a fsck and then permission repair both showed issues. But since it was fixed, I did not spend too much time indulging in 'why'. I am guessing that hiccup caused some file corruption.
The second issue is a more commonplace one. It was a new Snow Leopard server install, and authentication against the OD was taking forever and accessing the OD via WorkGroup Manager was slow and painful.
This was an issue I remember from our early experiences with Leopard Server. Basically, if DNS is not up and running nicely, you get big delays accessing Server Admin, WorkGroup Manager and in authenticating.
This user had set up the server using a FQDN ending in .local. This seemed not to be working nicely. However, they had registered a domain to use with this server (the server will be doing some Web hosting), so a good FQDN was available.
Since there were only 10 users set up, and all the passwords were available, I exported the users and groups using Workgroup Manger and then demoted the server to standalone. I then set up DNS correctly using the registered domain name, and re-promoted the server to OD Master. I then imported the accounts and groups, and reset the passwords. I have found that it is quicker to do this than use the changeip command (and the rest) to change the Kerberos realm, and LDAP, because experience has shown that it is rarely a matter of issuing changeip.
I have on my hands a large number of unused PCs, including dual 1GHz P3 and 2.4GHz+ Xeon machines. What I am hoping to do is get at least one box set up with a nice flavour of linux, and set it up as a network services box. On the list of services to try to get running are DHCP, DNS, VPN, possibly NAT/firewall (although, I'd probably like that running on a different box to my DNS), LDAP, RADIUS, and Kerberos.
I'd like something rock solid and easily administerable to run the core of the internal network. DNS, DHCP and a Kerberos realm are central to that. LDAP is handy because Macs hook into it well, and RADIUS is handy for the wireless access control.
It is really a long term project, because I will basically be building it from the ground up. I have a couple of machines in mind to run it on, but they all need hardware sorted (install RAM, hard drives, cases, fans etc). And then I will need to install the OS. Ubuntu is top choice at the moment, but CentOS, Debian or even something like FreeBSD or OpenSolaris is an outside chance.
OS choice is dependant on finding the right software tools and what they run on best. Probably, have it up and running sometime in June 2010, lol
Okay, since the last post I have done a little more. The problem with my microATX AthlonXP board was down to the board, not the CPU.
I have built another AthlonXP box, an Athlon64 (939) box, got a Quicksilver which has been upgraded a bit, fixed up the AT box with a 733, and got half way through a IBM PC 300GL upgrade (450MHz P3, 128Mb RAM, 40Gb HDD, WinXP). I've also got remote desktop running between a winXP box and a mac. I've killed the cable on the 21" screen, bought a 19" CRT, sold the Pismo and sold the Athlon64 box. I've also rediscovered strangedogs and flashed a few PC cards to Mac cards.
I think an entry on each of the major things would be appropriate.
:: Next Page >>
This is all about my on going fumblings with hardware. Regular entries should provide an indication of the depths of my obsession.
| Next >
|<< <||> >>|