Weblogs for Arthur
The ISP in question provides ZyXEL ADSL modems to their hapless users, a brand of which I've heard nothing good but with which I had no previous experience. The first one puked a few months in, the replacement unit started dropping connections within a week. As time went on, the frequency of failure increased, and it reached the point at which a power cycle reboot was required to recover. A dozen or more times per day. So, I went out and bought my own ADSL modem at a retail outlet, and when it stayed online and fine for a solid ten days I brought my complaint to the ISP. An excerpt of their response:
We would like to examine the old modem and run some tests with it to see if the modem exhibits similar problems at our site. If we determine that the modem is not the problem, we will want to look into possible phone wiriing issues.
The symptoms that both modems models exhibit do reflect the possibility of line condition issue. If the house wiring is at the root of this issue, [telco] does offer installations of whole house filtering solutions. The price is variable, and dependant on how much labor it takes.
Yeah... right... it's 'at dad-burned pesky ole house wahrin. If'n 'at new one I bot were atchully workin' as good as I think it is, day woon'ta offered me a whole house filterin' slooshun.
I was mostly okay with the openssl debacle, as it was just one major SNAFU in a dozen years of running Debian. I lost a day's wages to the update, but I can accept that. I'm no stranger to vi, write my email and handle quick edits in vim, but I prefer and am most productive using XEmacs to write the code that brings in the bulk of my income. The quarter hour I lost to reinstalling XEmacs from the unstable distribution seemed like a much bigger problem than the day I lost to the emergency openssl update.
I know it's irrational to freak out over such a simple thing, but I'm not and don't aspire to become absolutely rational.
I hope that all things Debian get back to normal soon.
Which would you strongly recommend against, and why?
What I'm after is something that's very secure, perfectly stable, and preferably configurable without learning an extensive grammar.
All ideas and recommendations gratefully accepted!
The .debs provided don't all work as downloaded as they rely upon lpadmin which AFAIK isn't something you'll find in a current Debian repository, but following the workaround instructions in Brother's FAQ's does the trick. (Basically, you unpack the offending .deb, edit the scripts in /var/lib/dpkg/info/ commenting out instances of lpadmin calls, and then dpkg --configure the package.) It's crude hackish, but it works.
Within the scanner support scripts they use usleep, another little critter you won't find on a typical Debian workstation. Fortunately, Debian's sleep isn't limited to integer arguments, so you can do things like sleep 0.01 without your refrigerator catching fire. A little vim time brings those scripts to life just fine. I feel an itch to rewrite them completely.
I had to dig some 64 bit libraries out of the RPM's in order to make the Scan key functions work with my AMD64 machine, but they now all work.
The PPD from the Brother lpr package wouldn't install for some reason, so I had to extract that and drop it into the right place on all machines. dpkg to the rescue once more. :-)
The ugliest part: Once I realized that it wasn't going to be a few dpkg -i's to get it all working I started taking notes so I could write up a proper article here, but by the time I was done my notes were well beyond usable. Fortunately, I have another 32-bit workstation that's a sacrificial lamb, so as soon as it's done with its current task I can dive in and properly document the process for the i386 architecture. Some poor soul will be searching for the information some day and might as well find it here.
I'm just really thrilled to have a 100% functional multifunction device, and one that isn't from HP, whom I thoroughly detest. Hooray for Brother and their support of Linux, even if it is a mite kludgy just now.
Now the fun part: Basic authentication was broken by the upgrade due to module reorganization and name changes. Oh joy. I had to add auth_basic, authn_file, authz_host, and authz_user (with their .load names) to /etc/apache2/mods-available.
What's with those z's on there? It looks like script kiddie l33t speak... or maybe I'm just grumpy because I didn't want to have to futz around with Apache's configurations tonight... that's probably it.
UPDATE: Apparently, the term for a disease that's also a sign of the zodiac and a "Tropic of" is considered profane. Some of the others have me scratching my head, too... oh well. 'Tis not mine to wonder why, and all that.
I've always been offended by profanity blacklists. Some of the most offensive things I've ever heard have been communicated without profanity, and some of the most insightful and profound things I've ever heard have been sprinkled with peppery language -- and the quality of the message could have only been diminished were the colorful terms omitted. Not that I can cite an example here...
I'm not suggesting that the profanity filter be removed. I don't often feel compelled to offend one of delicate sensibility, and I can imagine no circumstances in which I might feel compelled to do so here. I don't know much about the software that runs this site, but I do think it'd be nice if it were hacked just a bit to flag the potentially offensive terms that are trapped by the profanity filter. If I were to use spicy language, I would not be offended by a bit of highlighting of it saying "Hey, Arthur, you can't sprinkle that kind of fertilizer here". But, as I said, I am offended by profanity filters, and especially so when they misfire and give me no indication of which string or substring is in need of further attention.
That all said, I've downloaded the yawns code, and since crufting together perl is what I do for a living, I'm going to see what I can do with coming up with a patch that would depeeve me. I hope it'll be considered.
I searched around the web, found a bunch of "do this, then do that" kinds of howtos, but nothing that satisfactorily explained, in one swell foop, the relationships between the various components and configurations. The article here at d-a.org wasn't any better or worse than the rest... but no, I ain't gonna write one any time soon.
Hint, if you're about to install Nagios2 with NRPE: most of the remote checks you'll want to perform will require that you use check_nrpe_1arg rather than check_nrpe. Perhaps because I was fatigued at the time, I spent half an hour figuring that one out. It'd be nice if the Debian package nagios-nrpe-server had a few more checks configured out-of-the-box, but they aren't hard to put together.
Another hint, if you're installing nagios on a host whose Apache HTTP Server is running suEXEC: if you're doing a good administrator job, the .deb installation will almost certainly put things outside of suEXEC's document root. Future updates will continue to look to those unhappy places. My approach, which might be as wrong as dating outside your species: I created a vhost whose only purpose is to run nagios2, moved the CGI apps to that vhost's ScriptAlias directory, moved the /usr/share/nagios2/htdocs/ contents into that vhost's DocumentRoot directory, then symlinked the original directories to that vhost's corresponding directories. With any luck at all, future upgrades will work without any additional labor. I hope.
Now if I could just get a VRML plugin to work in Firefox, I could have some impressive 3-D maps to show off...
... I don't have much reason to believe that I'm going to give it the required effort.