Heal Your Church WebSite

Blog

  • 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.

  • ESV Bible RSS Feed using PHP

    As promised, the ESV Bible RSS Feed, now peachy PHP flavor! To get this done, I dipped back into two past articles. One entitled Using PHP from the command line. This is necessary as we want to add our application to the CRONTAB. For those of you new to this site, and for those of you who are not fluent in classical geek, CRON is the scheduling process associated with various flavors of *NIX, such as Linux. The CRONTAB is the table where jobs are enumerated and defined. Here is a past article of mine which points to some effective CRON tutorials you might find useful.

    The other tool we need is an effective way of slicing-n-dicing RSS files. As I stated in yesterday’s article, RSS is an XML file designed to talk to computer programs via the HTTP protocol. This means once we obtain the ESV RSS feed, we need to extract the data so we can render it in a human-friendly format. To do this, I’m going to again dip back into a past article and employ a wonderful little PHP library known as MagpieRSS.

    In about ten minutes, I had a working code that read the ESV Bible RSS Feed, extracted the good stuff, and then created an include file I could … well include in my web pages using pretty much the same techniques I stated in my article Similar in concept to “Using Cron with LWP::Simple and XML::RSS to retrieve news feeds.” You’ll also note that this program bails without creating content if it finds no data elements. And if it does, it takes care of some of the “whitespace” issues I mentioned in yesterday’s post.

    Yeah, I know, alot of repeating myself going on. It comes from fathering a strong-willed 3.5 year old. I’ll stop that now and give you what you really came here for, the code. Feel free to use it and improve it. But if you do the later, then please, com’n back and share a comment so the rest of us can benefit from it.



    BTW, since everyone loves a happy ending, I figured I’d let you know that I did finally hear from the good folks at Good News Publishers. A very nice note that’s going to lead into some very cool code in the not too distant future. Part of the communications issue was a DDoS attack on my side, and Glenn Slaven being 12 hours ahead of me. Now if Glenn would only tell me if the Oriole’s are going to win tonight, I’d be set.

    Stay tuned. Leave comments. Let me know if the above works for you. Share improvements. Enjoy the day. I know I wil!-)

  • Pew Internet and American Life Project: Daily Internet Activities

    Friday fun, or mandatory reading? You be the judge. For me, it is a little of both. I’m reading two recently updated tables of common internet usage and activities by the good people at the Pew Internet and American Life Project (PIP). Both have information that could be useful in convincing others at your church that your web site should be more than just a pretty brochure, or worse, attempt to emulate TV or movies.

    First is the results for “Daily Internet Activities,” which is a a chart detailing the percentage of Internet Users who do a specific online activity on any given day. Notice that 59% of the population gets online, everyday. Primarily to exchange email. Followed by obtaining news, an activity followed by using a search engine.

    Second is a chart entitled “Internet Activities” which deals with percentage of actual Internet Users (those who go online) who have ever done a particular online activity. Again the top three activities don’t change, but the fourth and fifth activities that follow are very interesting to those of us maintaining church and/or charity web sites. Researching a product or service before buying it and searching for a map or driving directions.

    So what does this tell us? Here is how I interpret the results:

    • Make sure your web host allows you to establish and maintain numerous listserves (automated mailing lists). Make sure the listserves are well supported with a user friendly/idiot-proof user interface. Teach those individuals who would use them, pastors and lay staff, how to keep their listserves maintained.
    • The content on your web site must be presented in a fashion that is search-engine friendly. This includes simple things such as your <title> tags including not only the name, but the city and state/province of your church (e.g. Redland Baptsit Church Rockville MD or Redland Baptist Church Montgomery County Maryland). Another simple thing would be running a string of text links of major sections along the bottom of your site. A bit more complex, it is equally important that you have user friendly URLs. All these things add up to good search engine placement.
    • Because it there is a good chance someone visiting your church may first visit your church web site, make sure you have easy-to-find, easy-to-read, easy-to-print information of how to get to your church. It may also useful to include the times of the services on such a page as I would think someone would print the info out the night before.
    • Provide maps, or at least links to maps and driving directions.
    • Conspicious contact information.
    • Sermons, devotionals and other documents that convey what it is you believe.
    • And something I just thought of, perhaps provide a page on where to go when you get there, such as Sunday school maps and/or what to expect in the sanctuary (e.g. dress, children, etc).

    Of course, it goes without saying that all of the above need to be presented in a fashion that conveys the purpose and personality of your church.

    At least that’s the way I read the data. So what did you get out of these tables? Leave a comment, and don’t be afraid to disagree.

  • Father Flanders’ Sermon for Sunday, July 13, 2003

    Here is some ageless advice I offered back in May of 2002:

    One of the big problems I see with so many church websites are bloated graphics. Let me make this point very clear. Reducing the height and width attributes of the <IMG> tag does not, I repeat DOES NOT, physically reduce the physical size of the file. Nor does it reduce the size of the image via “color reduction.” We’re talking the minutes versus seconds difference your users suffer to download a 50kb image of your pastor versus one that’s 1/10th the size but still portrays the same subject.

    I have a running joke with the pastor of my church. With no coordination at all, he often cites Scripture and or theological points that I just made an hour prior in my 11th Grade Sunday School class. At the end of the service, I always take time to thank him for making me look like as stinkin’ genius. Though we all really know that is the same Spirit working through different members.

    Well it seems I’ve been similarly blessed with validation from none other than usability and marketing guru, Vincent Flanders where he wrote in his Father Flanders’ Sermon for Sunday, July 13, 2003:

    Just because Jesus miraculously turned water into wine doesn’t mean he can miraculously turn your 1280- x 1024-pixel image whose file size is 1.8Mb into an image whose file size is only 74Kb just because you changed the WIDTH= and HEIGHT= attributes to WIDTH=”420″ and HEIGHT=”336″.

    This mistake is so common that it’s beginning to be as annoying to me as the confessions of the students of the young men of my Jesuit high school were to Father Ambrose “For your penance say three Hail Mary’s” Forsthoefel.

    Just from a theological point of view, Jesus was and is capable of all sorts of miracles. That point aside, Vincent is VERY correct in that we should not expect Divine Intervention for bloated images that can easly be corrected with a little software and a little know-how. Vincent offers some good freeware/shareware options in his article.

    And just in case you’re not convinced … I did a quick search of my past church web site reviews. Here are a few in which this ‘big problem’ was duly noted. Some have since changed their sites. Some have not. Pray for them.

  • Knoppix – Delightfully Distracting

    There are things I like about the Microsoft IIS server solution. There are things I like about the Linux Apache webserver solution. Where I work, it is the former. But for my church web sites, it is the later. Part of it has to do with the cost But part of it is *NIX-like approach. Everything is a file. Add only what you need, when you need it. Don’t reinvent the wheel. Simple, brutal efficiency at the cost of assuming the user knew what he/she was doing and was able to read the manual without hand-holding.

    At least that is how it was. Now, just as Microsoft adds more and more networking and servers to their operating systems, so too is Linux adding quite a bit more user interface. That said, without a compelling reason, most individuals haven’t tried, spied or experimented with the new GUI breeds of Linux. Who wants to risk blowing up their valuable data by adding a partition and installing a cryptic operating system just to sneak a peek?

    Well fear not. Not only have recent installs for Linux become amazingly user-friendly and somewhat idiot-proof, but more recently, there are now distributions of Linux that run entirely from a CD. No partitioning, no formatting, no installation necessary. Which brings me to a very cool tool that goes by the name of Knoppix Linux.

    Knoppix is a GNU/Linux distribution that boots and runs completely from the CD. It includes several recent Linux software and desktop environments, such as OpenOffice.org, Abiword, The Gimp, Konqueror, Mozilla, and hundreds more quality open source programs.

    In other words, you can test drive Linux without having to install it on your hard drive!

    What more variety? There is a growing community if geeks creating what are called Knoppix Linux Documentation – Knoppix Customizations. These are ‘unofficial’ distributions of Knoppix offering a variety of interesting modifications. Some are reduced in size. Some in different languages. One adds various security tools. One even adds clustering capability.

    Moreover, if you want to do something crazy, you can remaster Knoppix so it loads the Apache webserver and mod_php on boot-up. Though for those of you without 3 gig to spare, and/ or those of you using Windows, you’re probably better off using Knoppix-customize, a tool that enables you to change boot options and files of a KNOPPIX ISO image or boot disk without .

    The point is, here is your chance to play without having to make a huge investment in time or resource. Just download the ISO. Burninate it to a CD. Boot from the CD. Spend all night exploring Linux.

    Those of you with wives should just have them complain to me directly for distracting you the rest of this weekend.

  • PDF: Unfit for Human Consumption

    Jakob Nielsen really hit the nail on the head this time. Don’t use PDF files to present your sermons or church newsletters online. Or at least offer an alternative. I think summary from Jakob Nielsen’s Alertbox, July 14, 2003 pretty much says it all:

    Users get lost inside PDF files, which are typically big, linear text blobs that are optimized for print and unpleasant to read and navigate online. PDF is good for printing, but that’s it. Don’t use it for online presentation.

    Can I hear an Amen?!

    So here’s my suggestion, if you are going to offer your sermons and newsletters as PDF files, go ahead, but also make sure there is an accompanying HTML version they can easily read on-screen. In other words, don’t assume the user always wants to print the whole shebang.

    Granted, it is a pain, but by doing this, you help your own site’s internal search engine — as well as improve your ranking on external search engines. Yes, I know Google does PDF, but it has been my personal observation that HTML versions of similar text get ranked higher.

    And yes, I know, there have been times I’ve felt some of Nielsen’s alerts were a bit forced, but this isn’t one of them. He is entirely correct when he asserts that throwing a PDF file at your user tends to confuse them, it breaks the flow, it interrupts the naviga..a… oh, just go read his bullet points under the header “PDF Usability Crimes.”

    And when you’re done there, go see a few real life examples of what we’re talking about at:

    One other thing to consider is timeliness. The nice thing about using a custom plug-in and MovabeType was that I was able to publish and list yesterday’s sermons in under 2 minutes merely by cutting-pasting the email from my pastor into a form and pressing the save button.

  • Are your backups offline?

    If you’re not making backups of your website, and if you’re not making copies of those backups somewhere other than your server, then here’s something that might scare you into it:

    The The Register reports that a defacement contest is in the works and will likely to target Web hosting firms.

    scheduled for Sunday is likely to target Web hosting companies rather than individual Web sites.

    note to self:

    • send email of article to host provider
    • make a backup of sites tonight
    • make sure copies of backups are FTP’d to home computer and are burninated to a CD
    • make copy of CD and put in saftey deposit box

    Yes, a bit extreme, but think about it. If your backups are located on or near your network or web server, then they’re going to be next to impossible to restore when some hacker wipes them out along with your site.

    Oh yes, and this is one of the reasons why I pay about $12/month for a reseller service, so my web site is hosted on a computer somewhere in New Jersey, while I’m here in Maryland.

    That said, I’m old school enough to burn CDs and move them out of the house. Better to burninate and not need the backup, then to get wiped out and have none.

  • Never Delete a well indexed Link

    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:

    RedirectPermanent /pages/gaithersburg.shtml http://www.redlandbaptist.org/directions/gaithersburg.php

    (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:

    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.”