Everything's going to be fine.
Friday, January 16
It's the video card. Gotta be.
Better be, 'cause I just ordered a new one.
Which is a bloody nuisance, because the crashy one is also new.
Hopefully I'll get the new new card tomorrow, so I can have a less crashy weekend.
Wednesday, January 14
Given the continuing crashy badness of my Windows box, I decided to reinstall Windows. Only... Someone seems to have hidden my Windows install disk! Where could it be? The last time I saw it, it was -
In the CD-ROM drive.
Tuesday, January 13
After the fifth (or sixth) crash of the day, I got fed up and rolled my video drivers back to the previous version. This only took two reboots, a great improvement on the old days.
And since then: No crashes. Use the little scrolly wheel: No freeziness. No black screen of deathness. No BIOS screen at exactly the moment you least want to see it-ness.
Not the mousie, then. Or so it would seem. Or so it would appear to seem. Well, this new and exciting non-crashiness continues tomorrow, I might just see my way to purchasing a small selection of cheesy comestibles.
On the other hand: It went from a crash every two or three days, to more-or-less daily crashes, to two, three, four a day, to four times in three hours. Looks awfully like a case of software rot to me.
So while I was messing about with Faith (the server in the previous story), I decided that since I had only a W.A.G. as to what was wrong, I would set up another server to take over FTP just in case I couldn't fix it quickly enough.
So I fired up the box that I think used to be called Amelia (though it might have been Lina, since the two are identical twins) and started loading up Fedora. I called the new box Glory.*
And about mid-way through the first install disk it folded up and died.
I rebooted, started into the install, and SPLAT!!! with a CRC** error.
I checked all the cables. I checked the power supply. I checked the CPU fan. Um, shouldn't that be, like, spinning?
Moved a stray power lead from here to there and all the Chemical Rubber Tree plants were banished for good. Er, the installed proceeded smoothly.
* All the servers at our office are named after characters from Buffy.
** Chemical Rubber Company.
I ran the up2date utility on one of the Fedora servers at work on Friday to catch up with all the latest patches. For some reason - possibly because of a timeout while downloading the new kernel - up2date crashed. Trying to run it again just brought more crashes.
Since it was Friday afternoon, I left it at that. After all, the box was working fine, it just wasn't fully patched.
Fast forward to Monday morning and an irate phone call. It seems that files that normally arrive via FTP aren't, and people who can normally log in using FTP can't.
So I log in using SSH (which works fine) and sure enough, FTP is rejecting my login. Also everyone else's logins. Also a new login I set up just to test it.
I restart the FTP server. No difference.
I check the config file and fiddle a little. No difference.
I download the latest source and compile and install a new copy of the FTP server. No difference.
I install a completely different FTP server. No difference.
Now hang on just a minute there. The two FTP servers share no parameters, no config files, no directories. And they reject all logins, but they do ask for a password. So it's an authentication issue.
Linux offers something called PAM: pluggable authentication modules. Basically it's a centralised mechanism for checking usernames and passwords and other such stuff. And both of the FTP servers rely on PAM to check logins.
So, I float a hypothesis: I know up2date was trying to update the kernel. I know that it didn't finish doing this. I know from the log files that the server rebooted over the weekend - possibly due to a power glitch, since it's not on a UPS. (Yeah, yeah.) So maybe up2date had gotten far enough in to mess up PAM but not far enough in to actually make it all work again. So if I download and install the kernel manually, it will say:
error: Failed dependencies:Bum!
/bin/sh is needed by kernel-2.4.22-1.2140.nptl
What it really means is that you have to update to the very latest version of bash before updating the kernel. Yes, that seems strange to me too, but what do I know?
So I update bash, and I update the kernel, and I reboot, and it works! It works it works it works!
And a good thing too, because I have no idea how I would have proceeded if that hadn't fixed the problem.
Sunday, January 11
It would appear to be the video driver, and not the mousie after all.
Saturday, January 10
Those of you who frequent Munuviana, the MuNu group blog, will already know that I am writing a blogging system of my own. It's called Minx, and it now has a blog of its own. Admittedly, the blog is still running under Movable Type, since Minx currently does not actually work...
It's sort of a developer's diary, and will morph into a documentation and support site once Minx is up and running. If you're interested in shaping the feature set of Minx - or even in contributing, since Minx will be released as open source - drop by and have a look.
Important Geek Details (for Rossz)
Minx is written in Python. I am also planning a small PHP library to allow easy access to Minx functions for all the PHP coders out there (though this may not be ready for the initial release). Minx will also support access via XML-RPC, and that will be in the initial release.
The system is being built around the Metakit database, and won't support SQL. This may change in the future - I would like to support SQL, but I haven't done any planning for that yet. If you are after remote access to the Minx database (rather than plugging Minx into an existing SQL database), there is a SQL access layer available for Metakit.
Minx will initially be delivered on Linux, but it should work on Windows as well (and I hope to have a chance to test this before release) and any version of Unix. Since that now includes everything from MacOS X to OS/390, the only platforms likely to have a problem are OS/400 and the Nintendo Gamecube.
To run Minx you will need Python 2.3 or later, Metakit, and (optional but recommended) the Python Imaging Library. Also you will need either the Apache web server (or another web server that supports Apache SSI tags) or PHP.
I will put a more detailed version of this post up on the Minx blog shortly.
Tuesday, January 06
I just wrote an almost completely generic object-oriented wrapper for Metakit records in 35 lines of Python code. Which includes 4 lines of comments, 5 blank lines and 5 lines of debugging code.
It handles searching by the primary key, creation if it's not found, and completely transparent transferral of data from the argh. Uzgbf. Never mind. Back to the drawing board.
Update: I just wrote an even more almost completely generic object-oriented blah blah, same length (well, I took out the 5 debugging lines), only this time it doesn't screw everything up when two threads try to manipulate the same record.
I call it MEOW: The Metakit Easy Object Wrapper. Hooray for getattr, setattr and hasattr! I've never tinkered with Python objects like this before, but after only a couple of hours it all makes sense. In fact, it's obvious that this is how to do it. (Actually, there's probably an even simpler way that I have yet to find, but pfft. This is neat and understandable, very general, fast enough, and works.)
A little more tweaking and I'll have a base class that I can derive all my objects from. Yay!
(For those of you saying What?: Persistent objects made easy. For those of you still saying What?: Shiny programmer thing!)
More Update: Poo! The mere presence of __getattr__ in a class definition causes the class to run like molasses in January. When I enable __getattr__, time taken to instantiate the class increases by a factor of 250 - even though it is never called! I may have to ask the Python wizards about this.
Err, in theory it should never be called. In practice, it is getting called 2988 times for a single instantiation. Odd, that.
Oh. Using hasattr() within the definition of __getattr__ is a Bad Thing. Access __dict__ directly. Right.
Saturday, January 03
A little reading up on DNS and Apache, and now I know how to set up blogs without... Well, without all that tedious mucking about with DNS and Apache.
This will come in handy if I ever need to set up another blog...
56 queries taking 0.5848 seconds, 359 records returned.
Powered by Minx 1.1.6c-pink.