Weblogs for Arthur
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.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393083
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.