Heal Your Church WebSite

Month: August 2003

  • Wi-Fi for Dummies

    Would someone mind telling me where the summer has gone? Here in the U.S., it’s Labor Day already. Well, at least the Labor Day weekend. Which I usually celebrate with some back-breaking weekend long project that makes me glad to return my office the following Tuesday.

    This weekend, I get to cut the lawn, trim the hedges (big nasty 40 year old monsters), wack weeds, clean out the shed, clear the storm gutters, take some stuff to the dump and after all that, I have the joy of getting around to that 24’x12″x12″ ‘Freedom’ drain I ‘ditched’ last weekend in favor of chasing my 3.5 year old around the park.

    For those of you who’d rather not feel the burn of sore shoulders and the satisfaction of complaining to your spouse about your aching back, why not Wi-Fi? For those of you not familiar with acronym for Wireless Fidelity, Wi-Fi is according to The WikiPedia “a set of Wireless LAN standards developed by working group 11 of IEEE 802.”

    Yeah, okay, that was total geek-speak. Wi-Fi is a way you can provide network access to a home, your church, your charitable organization, or your nosey neighbor without having to snake wire through the walls and ceilings of your domicile. The problem is walking into your local computer store and trying to figure out where the network begins and the hype ends. For that, may I suggest a nice little article by Paul Boutin of the Slate aptly entitled “Wi-Fi for Dummies? In this article Mr. Boutin takes some of the fear factor out installing a simple wireless network.

    Not convinced? If you are unable to inspire your congregation that this is a good way to get their offices, their classrooms and their sanctuary online, then perhaps this article from my April archives entitled Wireless Missions will help.

    Going for it? Then please, do me 3 big favors:

    1. Make sure your firewall (preferably dual-homed) is correctly placed to protect your internal systems from outside attack — or from those inside abusing things on the outside.
    2. For those of you with web servers on site, see what you can do about making sure they’re not on the same ‘leg’ as your office or school systems.
    3. Please enable message encryption or suffer “The Attack of the Eavesdropping Neighbors“

    Okay, you have your assignment, get busy.

  • The One Page Linux Manual Home Page

    As the parade of pretty little posts continues today, we take a turn down Linux lane with a link to the the One Page Linux Manual. This 94KB Adobe Acrobat beauty (or if you prefer, a 542KB Postscript beast) contains all the essential command line instructions you love to forget reduced onto two sides of a single page (proving that some PDF documents are fit for human consumption).

    Which you can then fold in quarters to fit inside your handy-dandy Linux Pocket Protector.

    And just to show you what an ecumenical guy I am, here’s a link to a tutorial on “How to set double-sided printing by default [for] Windows computers.“

  • Failure to Plan == Plan for Failure

    I wanted to wait until now to talk about the “big blackout of ’03” so that anyone was left offline wouldn’t also be left in the dark when it comes to talk about having an effective contingency plan.

    Cool black light, or dim bulb? You decide with your plan of attack
    From my logs, I know issues such as using crontab to schedule ‘automagic’ backups of your database are popular. And that’s good, but that’s only a first step to making sure you don’t find yourself on your hands and knees feeling about for your archive CD when disaster strikes.

    So, with the recent power outage still looming like a dark spot on our memory, I think it is a good time to offer the following axiom “a Failure to Plan is a Plan to Fail …”

    As I said, we’ve discussed backups more than once. We even recently went into gory detail on using Linux to get your crashed/infected Windows system back online. But at the end of each of these posts is always a sermonette to plan ahead, to map out contingencies, and to practice, practice, practice.

    First, a fun analogy. I used to sing opera … professionally. More than once, something would go wrong. A seam on a costume would give out. Someone onstage would feint because of the heat of the lights, or perhaps trip and break their nose exiting stage left. Or worse, some smarmy brass player in the orchestra pit would spike the water in a prop bottle from which your character was to drink.

    The point is, in those productions where we practiced, practiced and then practiced some more, such incidents were mere annoyances we now wax nostalgically about with our friends at parties. In those few productions I involved myself where rehearsal was a dirty word, such occurrences were literal showstoppers we’ve blotted out from our memory as far as the east is from the west.

    Put another way, you can CRONTAB all the MYSQL backups you want, but without knowing how to restore the data, the backup is useless. Similarly, if the backup is still sitting there on the same hard disk and/or computer system of your failed website, then you’re only remaining option is going to be feeling you way about a dark room as you seek a place to pray.

    That said, I know first hand that disaster recovery is a comprehensive discipline unto itself. One need not go any further than FEMA’s “Emergency Management Guide For Business & Industry.” A document you might want to share with the office manager for your church or charity.

    And the since object here is to get you to actually do something about not losing all the data on your church web site … and with copious apologies to real disaster recovery plans and the specialists who produce them … here is a short, very short, not-even-close-to-definitive list of bullet points you need to consider to protect your charity’s website from going black:

    • List people involved in the plan (include phone numbers and addresses)
    • Identify the potential risks (software, data, hardware, people)
    • Amor-plate the endangered data/systems as much as possible
    • Keep Up-to-date backups of your data on a readily accessible medium (e.g. CD)
    • Validate backups (check logs of process AND check the data)
    • Keep archive of backups off-site (but accessible in an emergency)
    • Make arrangements on alternate systems (alternate web hosts and servers or any other hardware/systems required to restore your data)
    • Take a weekend or three to practice the plan … then practice some more
    • Make sure you’re not the only one who knows the plan or has the data
    • Secure and document all isp and webhost and domain name and any other pertinent contract information (your account, passwords, billing, etc)
    • Secure and document all internal access information (accounts, passwords, mailing lists)
    • Document all of the the points above (especially restoration)
    • Keep several copies of the documentation handy in several locations (e.g. distribute to all members of your recovery team)

    As I said, this is a mere pittance in light of true disaster recovery. That said, it is up to make sure you have at least taken the above precautions … and from there add more points and detail … for as it is written (with apologies to the inspirational text of Romans 10):


    How can they restore the data without knowing how?
    And how can they know how without having practiced?
    And how can they practice without someone teaching them?
    And how can someone teach without documentation?
    As it is written, “How beautiful are the webmasters who have planned ahead!”

  • Robot Exclusion Tutorial

    I received a very nice email from Carolyn at the Faith Evangelical Church in Melrose, MA. She writes:

    My husband sent me this URL to improve the church website, but I feel over my head. In [point #] 7 you say. “What robot exclusion standard?” What is that?

    Carolyn, as I like to say my 11th grade Sunday school class “there are no dumb questions, so thank you for asking … in doing so you help the rest of us learn something new.” Or put another way … ask and you shall receive!

    Here is how it works. When Google or some other (legitimate/well-behaved) search engine visits your site, they first look for a file in your root/home directory named robots.txt. This little file contains simple, line-at-a-time instructions on what directories and files you would or would not like indexed. Here is an example of mine:

    User-agent: *
    Disallow: /cgi-bin
    Disallow: /images

    The first line says “User-agents” for ALL user agents, allow/disallow the following directories. The next two lines specify that I don’t want search engines to index anything in my /cgi-bin or /images subdirectory, mostly because it saves me bandwidth. Now I know what you’re thinking … “what the heck is a user agent?”

    A user-agent is how we identify what type of software is visiting our site. What us geeks sometimes refer to as a “client application.” For example, many of my visitors are identified as using Microsoft Internet Explorer version 6, though today, because yesterday’s article found its way to Linux.org, the majority of my visitors are using the Mozilla browser. Google identifies itself as “googlebot.”

    If I wanted, I could make an entry specific to Google that says I also don’t want it to visit nor index a file on my site named “googleme.html” by adding the following entry in my robots.txt file:

    User-agent: googlebot
    Disallow: googleme.html

    Of course, there are those who abuse robots.txt. So the general rule of thumb is, if none of your web pages has a link to a private directory, then don’t list it in robots.txt. Looking at it the other way around, you should only allow/disallow subdirectories are linked on any of your web pages. For that, may I suggest reading my March 01’03 post entitled “How to block spambots, ban spybots, and tell unwanted robots to go to ….”

    I could go on, but there is a MUCH better tutorial over at SearchEngineWorld. Not only does it go into greater detail on with useful real-world examples, but it also accompanied by their Robots.txt Validator … an online program that lets you check to see if your robots.txt file is kosher.

    And if this doesn’t help, feel free to email me or leave a comment. I’ll just keep explaining it until everyone in the class gets it.

  • Linux-based approach to fixing MSBlaster Worm infection

    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.