Category: Titus 2:7

I was watching the news the other night … amused a bit by technically-impaired broadcasters who were suggesting that to fix your infected machine, you had to find a friend with the patch, or hire some geek gurus to come fix it for you … because you can’t get online nor keep your machine from rebooting.

I think Mike Wendland summed up the paradoxical problem with this virus best when he wrote: “The thing with MSBlaster that drives users nuts is the computer keeps restarting. How can you fix it if it keeps shutting down?” As always, Mike has some other good technical advice on how to solve the problem manually.

To me, the solution is simple. Make sure you have a copy of Knoppix handy. Of course, if you can’t get to the Internet, this advice won’t help … but for those of you who read and then heeded my July 18th advice entitled “Knoppix – Delightfully Distracting” … by downloading and then burninating a CD … you’re all set.

In other words, when I tell you about a Linux solution that can boot from the CD, it means you should keep a copy nearby so when your Windows machine crashes or locks you out, you have a means of circumventing the problem and affecting a solution. Or in plain English, you should keep a copy of Knoppix duct-taped to the side of your PC as an emergency boot disk.

This is because Knoppix contains all sorts of applications, including several useful Internet applications for dialing-up an ISP, connecting via PPPoE, connecting via your router, sniffing your network, and a few other gems. In other words, you have on this CD the tools you need to:

1. boot-up your machine from the Knoppix CD
   • right click on icon for Floppy Disk
   • select properties
   • select permissions tab
   • enable write permission for group
2. connect to the Internet
3. download the Symantec fix (preferably to a floppy … e.g. “/mnt/floppy/FixBlast.exe”)
4. download the Microsoft Patch – to a non-NTFS disk (floppy, zip, FAT partition)
5. reboot machine in Windows safe mode
6. run Symantec fix (please read all documentation FIRST)
7. reboot machine
8. install Windows patch
9. reboot machine
10. pray it doesn’t happen again …

Of course, again, this advice is useless if you don’t have a Knoppix CD handy. Nor is it going to help if you haven’t practiced and documented this contingency at least once before you needed to. In other words, regardless of whether you boot from Knoppix and use Mozilla, or boot from safe mode and use WGet … you need written documentation on how to connect to your ISP, and need to know how to use it via your alternative methods so you’re not fumbling around during an actual emergency.

Sorta like having and then PRACTICING how you’re going to get out of your house during a fire.

UPDATE – btw, here is a most excellent article I found after writing this post entitled “Computer First Aid Using Knoppix,’ … or what I like to call, “everything you wanted to know about fixing your Windows System using Knoppix, but were afraid to try …” It includes among other good things, tutorials on how-to dial-up and connect to the Internet and how-to get around your Windows file systems. I would suggest printing it out somehow affixing the 11 pages along side your Knoppix CD you should already have duct-taped to the side of your CD. I might also write on the back of the printout any ISP information (other than passwords) you need to get connected.

UPDATE 2 – I’m flattered to see my site linked-up at NewsForge! I’m also glad to see that someone brought up the subject of NTFS, both there and here. Here is the bottom line. The systems affected by the MSBlaster worm are generally NTFS. While I did find documentation on how to mount an NTFS partition for a regular user … I also found stern warnings NOT TO WRITE TO AN NTFS partition in a discussion on fixing one’s boot record. A post that starts with the sage advice of backing-up your data. Which can be done if you merely mount an NTFS partition for read-only access … though on my system, my NTFS hard drive is read-only accessible merely by double-clicking on the drive icon … your mileage may vary.

UPDATE 3 – One more quick note in response to some comments and emails:

• The Windows NT, Windows 2000 and Windows XP patches from Microsoft are indeed small enough to copy to a floppy (807kb, 898kb and 1,261kb respectively).
• For Windows 2003, you’re going to have to use some other medium as the patch file is 1,454kb in size.
• The Symantec fix is a mere 140kb in size so you only need one floppy, though I always prefer a suspenders/belt combo.
• As for why not just run Linux all the time? Or why not have a dual boot system? Well, because some of us have situations at work where we are not allowed to install a second O/S.
• Why not use a Windows Emergency Boot disk? You can, but I prefer to have a complete operating system with all the trimmings and software I need available when the need arises
• Complicated? A bit, but again, its good to have a complete operating system available when the need arises
• How can I install Windows patch under Linux? You can’t, but you can download the fixes and patches Mozilla, then reboot in Window safe mode.

As always, understand that your mileage may vary … which is why earlier I stated, you should always plan, practice and document contingencies before needing them.

While some web technologies and techniques come and go with the frequency of a “Persian rug, everything must go going out of business sale,” there are some general housekeeping rules for your church web site that are ageless. One of them can be found in the 1998 Jakob Nielsen AlertBox “Fighting Linkrot.” Basically, Dr. Nielsen identifies broken hyperlinks as one of the scourges of the Internet. While you may not see the problem as dramatically as he paints it in the article, it’s still very important to avoid broken links on your web site.

That said, it is equal, and possibly greater importance that you not break your links on search engines. More accurately, if you have a page that is well indexed on a popular search engine, then make sure that page is there for the user that clicks on the link. Since you have no direct control over what gets listed, you may be asking yourself “how do I break a link on a search engine?” Glad you asked.

Site upgrades, web server moves, changes in server-side programming languages and/or changing to a different web editor or content manglement system can all contribute to search engine induced linkrot. The recently upgraded Redland Baptist website is an excellent example.

Before I switched to using MovableType as a church content management system, I had generated pages using DreamWeaver 3.0 (don’t worry guys, I now own MX). The pages employed Server Side Includes, so the page extensions were .SHTML. The sub pages resided in a subdirectory named “pages.” So, if you found our website by entering “baptist church gaithersburg maryland” into Google, you would (and still do) get a link to the (deprecated) url: http://www.redlandbaptist.org/pages/gaithersburg.shtml.

This is all fine and well, but I now that I’ve gone to the trouble of updating the RBC site using MovableType as an editor and PHP as my server-side solution, I want people to go to the new page at: “…/directions/gaithersburg.php.” The same holds true for the well indexed directions pages for Bethesda, Derwood, Germantown, Olney, Rockville, Potomac, Silver Spring and Wheaton. The problem is, I don’t want to lose my good Google ranking with my old pages. So how do I get the best of both worlds? Glad you asked.

Within the aforementioned Alertbox article, there is a link to another equally timeless tombe at the W3C entitled “Cool URIs don’t change.” The article is presented in the familiar FAQ format posing excuses for changing URLs, and then shooting them down. Basically the article asserts that as long as you control your domain, then you should be able to control your URLs.

Some of you by now are asking yourself “yeah, okay Dean, I’m sold, but how?” Glad you asked.

There are several methods of offering redirection. I can be done through <meta> within an HTML document, as exampled in an University of South Wales article entitled “Think twice before moving that page – Avoid Linkrot.” But sometimes this brings with it a penalty from the search engine. You do what I see on some church sites, and just put a hyperlink on a blank page saying “we’ve moved, so should you.” Unfortunately, most if not all search engines will push a once populated page to the bottom of the heap now that the compelling content is gone.

For me, the preferred route is to take advantage of the Apache Server’s mod_alias modify the .htaccess file. Which is why for those of you clicking on the above link to the old page … got the new page, simply by entering the following directive:

(Note that the above command should actually be all one line, it only word-wraps because … well because my blog needs some healing.)

Now your mileage may vary slightly. I had to use “RedirectPermanent” , whereas some of you might have success with “Redirect permanent.” Check with your hosting provider to find out which one works best for your configuration. And if you’re still stuck, here are three more how-to articles on the subject you might find useful:

• Apache – URL Rewriting Guide
• OpenSourcePan – Simple mod_alias Techniques
• Dive into Mark – HTTP Error 410: Gone

I know this is a bit technically involved for some of you, but this is vitally important to the long term success of your church web site. As Dr. Nielsen aptly put it “Any URL that has ever been exposed to the Internet should live forever: never let any URL die since doing so means that other sites that link to you will experience linkrot.” Amen. About the only thing I’d add to that would be “especially high-ranking links from popular search engines.”

Kung Fu Grippe’s (KFG) “Honeypot for spam harvesters” got me to thinking. In the past, I’ve often added a loopback email address on a contacts page so that dumb spambots that harvest and email on the fly will send a copy to whomever is hosting the spammer’s operations. That address would be abuse@[127.0.0.1]. Which is okay up until you get into the world of hijacked servers, open SMTP relays and or spambots looking for the well known IP looback address of 127.0.0.1.

So taking some ideas from KFG’s article, I created a bit of PHP that will look up the domain of the spambot/spybot and create and email address for their abuse administrator, such as abuse@verizon.net. Here is how I do it

Here is how I add it to my church’s contacts page. I created a 1×1 transparent .GIF file, then put it on a place on the page where no normal human would suspect. You can view the source to see how your results vary:

Coming up next … for those of you getting cross-eyed with all the hyper-tech … simple site reviews … I swear (well, not really!-)

Hey all, love the feedback.

So much so, there’s a version 1.3 I’d rather y’all reference.

And to kill confusion, I’m removing the current code snips/examples so we’re not trying to maintain updated legacy code.

Thanks! I look forward to your comments over here:

Hyperlink Bible References using Scripturizer 1.3

Some good email going back-n-forth on this redirect issue. The funniest being NZ’s reply to one of us who said “work through your service provider” to which he responded with a very politely worded version of “duh!” Sometimes we geeks tend to throw stuff out there like spagetti – these last few pieces sliding down the wall under the category of “stating the obvious.”

Grins’n’giggles aside, I wanted to cover some of the information that has been exchanged. Keith Devens writes: “Just for reference, here’s the mod_write redirect, but it’s expensive because
Apache has to do a sub-request on every request. It’s basically something like
(this assumes they’re on different servers):“

Anders Jacobsen adds I’ve used Apache redirect a lot myself, and it works like a charm.

Keith; the solution you are proposing is very ISP specific, and if they make it that easy for you to set up virtual hosts (at no extra charge) something makes me think that they aren’t using “Real” virtual hosting (i.e. separate IPs for all virtual hosts). I use pair.com, and an explanation of their policy can be found here…

I personally have been so busy with my ‘real job’ that I haven’t had a chance to test out these various approaches – or some variation on a theme. Though I did have some redirect fun at the expense of an individual who has been harassing a member of Redland Baptist Church. This individual, frustrated by the court system, has linked some pages of Redland’s website – why? I don’t know. Though we were recently spammed. Perhaps that same someone wants others to do the same? Regardless, because the RBC site implements Server Side Includes, I have been able to take any traffic from identifiable ‘hate pages’ and give them an entirely different message. Here’s an example from the staff/contacts page at RBC

I’m going to return to this issue later this week when I figure out a solution, but until then, here are some resources you may find useful in your quest to redirect:

• A List Apart: Slash Forward
• A List Apart: How to Succeed With URLs, Part One
• A List Apart: URLS! URLS! URLS!
• Keith Devens .com – Fun with mod_rewrite
• Keith Devens .com – Look Ma! No extensions!
• A Users Guide to URL Rewriting with the Apache Webserver
• Apache module mod_rewrite
• CrazyGrrl.com – .htaccess Files

In the meantime, try tinkering with the following that I found via the support page at Prestwood.com – as this is where I’m going to start once I get some free time:

From time to time, redirecting users is necessary. Take for example the a request/email I got from N.Z.Bear over at “The Truth Laid Bear:”

I finally got www.wmdi.org up and running. But here’s the deal:
… I’ve currently got all our stuff (weblog & forums) in a subdirectory of
TTLB: http://www.truthlaidbear.com/blogmd … So, I have a DNS forwarding service routing all requests for www.wmdi.org to 216.218.144.66, which is the IP address of www.truthlaidbear.com

In theory, I thought I would be able to use my .htaccess file to
implement mod re-write rules that would then allow me to transparently send
any requests to www.wmdi.org/blah to www.truthlaidbear.com/blogmd/blah …

Being that I’ve been remiss in helping NZ out with the WMDI, I figured I’d better reply him with some solutions. Here are four that you might also find useful if/when you run into a similar situation with your church web site. The first requires you add the following line to your .htaccess file in your website’s root directory – assuming you have a Linux/Apache configuration.

Since NZ wants to redirect everything incoming to the /blah directory, he would need to modify the .httacess in his /public_html and/or the /www directory. The status argument [temp|permanent|seeother|gone] is only available in Apache 1.2 or later.

Keep in mind, redirect directives take precedence over Alias and ScriptAlias directives, irrespective of their ordering in the configuration file. Also, Url-path must be an absolute path, not a relative path, even when used with .htaccess files or inside of <Directory> sections. Finally, don’t forget to chmod -644 that .htaccess file.

Then there are programatic approaches. First in PHP, then in Perl.

Being programatic approaches, this would mean you need to places these files in the “FROM” directory (/blah) and then chmod -755 the script files so you’ll know they execute. You also need to make sure your server is set up to look for index.cgi and/or index.php the same way it looks for index.html. This is default on most Linux/Apache configs, but if you mileage varys, then you may need to add the DirectoryIndex directive to your .htaccess file.

Of course, many of you who now have Linux/Apache set-ups do so through host providers that give you nifty little control programs such as CPANEL that let you set up redirects and such w/out having to SSH and PICO your way to fun and frustration – wimps.

And speaking of lightweight – there is always the HTML based solution:

However, I’m not too fond of this one because it “blinks”, it sometimes fails, and it breaks the back button. That and its not as flexible as the above solutions, as you’ll see in blog a bit later how I’m dealing with someone linking the Redland site via a hate page. You know, the whole returning evil with good thing – more on that later.