__/ [ The Ghost In The Machine ] on Friday 10 March 2006 23:00 \__
Hi Kelsey, Ghost,
I'll comment as I read on.
> In comp.os.linux.advocacy, Kelsey Bjarnason
> <kbjarnason@xxxxxxxxx>
> wrote
> on Fri, 10 Mar 2006 11:30:10 -0800
> <pan.2006.03.10.19.30.01.572795@xxxxxxxxx>:
>
>> Just to really tweak the wobblies of the GUI-uber-alles types...
>>
>> Got a systemic failure in a machine here. I've mentioned it before, but
>> turns out not to have been quite as simple as we thought, since the
>> machine subsequently failed, in much the same mode, as it did previously.
>>
>> Specifically, somewhere between delivering data between the various NICs
>> and accessing the drive, for logging, over time (or perhaps byte counts)
>> the system fails; the most obvious result of this is dataflow through the
>> NICs ceases. Whether this is time, temperature, load, counter or some
>> other specif aspect failure isn't clear yet.
I was initially going to suggest that you consider hardware failures, before
assuming a software-related and thus easily-fixable error.
>> So. Let's see. Don't want to run off the main file system, as if there
>> is a failure in the drive subsystem, I'd rather not corrupt the existing
>> data and configurations.
>>
>> What I *do* want to do, is boot the system somehow, so I'm still using the
>> same exact hardware - not, say, drop the drives into another box - read
>> the data off the drive, dump it out over the NICs and see what happens.
That can indeed be an issue. You should make the habit of copying your entire
hard-drive (if not just important 'lumps' from the tree) onto a second
hard-drive for exactly that reason. Backups can easily be cronned (GUI if
you prefer), or at least be made semi-automated. I did my last complete
backup yesterday only because I account for the risk of hardware failures.
>> So how does one do this? Well... I happen to have a LiveCD I can boot
>> off, on the original machine. It supports the drive controller, the NICs,
>> the video card, everything in the machine. Works like a charm. It also
>> lets me mount the drives read-only, so I can access them but not write to
>> them.
Excellent. So you should be able to SCP all the data to another machine, at
least until the hardware issue is resolved.
>> Okay, so that's half of it - but how to get the data over the NICs? Lots
>> of ways, obviously. Could use an ftp client to upload a large file, for
>> example. Once. Interactively. Kinda pointless; what I really want to do
>> is repeat the process tens or even hundreds of times, slamming tens of
>> gigs of data down the line as fast as the two systems will handle it,
>> without babysitting it.
For that reason, given enough available space, you could compress the
important files. Then, just toss a single file over FTP (or whatever else
suits you). This speeds things up throughout transfer at the expense of a
pre-processing stage, namely compression. You could also 'tar' the files,
which is /very/ fast.
>> Aha! Turns out the live CD, while it doesn't have an ssh _server_, does
>> have an ssh _client_. And a key generator.
>
> Gentoo LiveCD also has an SSH server, along with a password
> randomizer, which is slightly annoying to me personally
> but very good for security.
>
> Basically, I can feed it the disc, do
>
> # passwd root
>
> # /etc/init.d/sshd start
>
> and I can then manage the Gentoo install from another machine.
>
>>
>> Boom, create the public/private key pair. Copy the public key to the
>> target machine. Now I have automated logins. Now, how to manage the
>> other side of the operation - copying the data, repeatedly? Lessee...
>>
>> for ((i=0;i<100;i++)); do time scp file.in host:~; done;
>>
>> This will copy "file.in" (about 4Gb) to the remote host, 100 times,
>> automatically, and display the time taken for each transfer, so I can see
>> if there's any unexpected slowdowns.
>>
>> So, let's recap:
>>
>> 1) Boot off live CD.
>> 2) Set IP address for NIC
>> 3) mkdir /mount
>> 4) mount /dev/sda1 /mount -o ro
>> 5) cd /mount
>> 6) for ((i=0;i<100;i++)); do time scp file.in host:~; done;
>>
>> Total time to start the test process (not including OS boot): about two
>> minutes.
>>
>> Now, since the OSX and Windows twonks are constantly telling us how easy
>> their GUI solutions are, perhaps they could explain where I get a LiveCD
>> version of their respective OSen. No, no, I don't mean dicking around
>> hacking one together, I mean, just download (or buy, if necessary) the
>> bootable CD or CD image. Last I checked, MS doesn't ship such things.
>> Apple might.
Linux saves the day. Less ironically, it saves itself from itself or
*rather*, it saves the computer from its own hardware issues. I believe the
best one could ever do with Windows is 'ghost' it occasionally. For large
heaps of data, this can consume many CD's or require a variety of pricey
peripherals.
> I've heard noises about an Embedded XP boot disc but know little about
> it.
>
>>
>> Once they've shown that, they can show how to mount the drives, read-only.
>>
>> Then they can show how to create automated logins, while leaving the
>> remote host secure - i..e no passwordless or keyless logins; nope, keep it
>> secure - but automatic.
>>
>> Then they can show how to automate the copying, for an arbitrary number of
>> runs, timing each run individually.
>>
>> Then they can show us how to do all of this, with their pet GUI system,
>> even *as* easily, let alone more so, as I do it with my Linux box.
>>
>> Yes, yes, I know OSX comes with all the CLI tools, but the GUI twonks keep
>> telling us how hard the CLI is, how easy the GUI is, so the OSX CLI need
>> not apply.
>>
>> Any time you're ready, folks..
>>
>> While you're dicking around trying to figure out *how* to do it, I'm
>> *already* doing it, and off having a coffee while it does what I need it
>> do.
When I was younger (and still using Windows), I dreaded the day when the O/S
would refuse to boot, let alone the day when a hardware failure would lead
to data loss. Frankly, with Linux I have full confidence. Data is resilient.
Backing up, where appropriate, is an automatic process, so the owner can go
play some favourite sports, while the other, less fortunate people stare at
a GUI, inserting and ejecting CD's, or paying large sums of money to
professionals with Knoppix.
Speaking of the need to back up, this machine that I currently use has been
up and running uninterruptedly for two and a half years. From the point of
view of the O/s alone, it is less prone to breakage than its counterparts,
which I used in the past.
>> Shouldn't take you even two minutes - after all, your way is "easy", my
>> way is "hard", right?
>>
>
> Indeed. What is a GUI, really? A method by which to interface man with
> machine. What is a CLI? Another such method. The chief difference is
> that the CLI has about 101 more buttons to play with. :-)
>
> Good luck with your NIC. At least with Linux (or Unix) you should have
> a fighting chance. :-)
Best wishes,
Roy
--
Roy S. Schestowitz, Ph.D. Candidate (Medical Biophysics)
http://Schestowitz.com | SuSE Linux | PGP-Key: 0x74572E8E
3:20am up 2 days 19:57, 7 users, load average: 0.11, 0.34, 0.37
http://iuron.com - Open Source knowledge engine project
|
|
