Heal Your Church WebSite

Blog

  • A quick look inside my installation bag of tricks

    When a plumber visits your house, they often bring with them a part canvas, part leather bag that weighs in and about 50lbs. I know this because my brother is a plumber, and I’ve had ample opportunity to look inside at all the unusual looking tools he carries with him. I also noticed recently that he’s somewhat particular in how he puts the tools back in … not one can neatly align them in such a bag, but he has three or four well-worn tools he puts in last. This is because these are often the tools he uses first.

    So if you were to look into my virtual ‘what dean uses to install applications’ toolbag, what might you see along the top? Glad you asked: putty, wget,tar, pico, mysql … usually in that order.

    Now I believe I’ve discussed each of these tools (as you can see from the above hyperlinks!-), but don’t think I’ve really ever put it all together to show you what I do to install an application directly onto my web server. Nor do I think I’ve completely explained why I prefer the direct approach.

    On the latter, nothing is more frustrating than downloading a file locally, expanding/uncompressing it, editing various files, FTPing it to your web host, only to find that it doesn’t work due to a file or directory that was either uploaded binary when it should have been uploaded ASCII … or requires an additional step of changing the errant item’s file permissions.

    Instead, I avoid this hassle by using putty to login to my web server, and from the shell, execute some variant of the following commands

    cd $HOME
    wget http://www.foo.org/downloads/foo.tar.gz
    cd $HOME/tmp
    tar -zxvf $HOME/foo.tar.gz
    cd $HOME/www
    mv $HOME/tmp/foo-version2.0.1 foo
    cd foo
    pico config.php
    mysql -uUSERNAME -pPASSWORD mydbNAME < foo.sql

    Now of course, each installation is going to be a little different, for example, you can see that I throw mkdir and chmod into the mix in a past article I wrote entitled “Moving MovableType.”

    That said (and finally to the ‘former’) the above boilerplate also provides some other unseen advantages. First, you don’t have to have to download the file locally. This is good because it also means you don’t kill bandwidth FTPing each file. This is good because you don’t have to worry about uploading the file in the wrong mode … and you install the files using the permissions defined by the developer.

    As always, your mileage may vary … especially in those one or two cases where the individual making the .tar.gz file doesn’t put stuff into it’s own directory … which explains why I put everything in $HOME/tmp first …

  • (stop) Stating the Obvious

    “[Mission statements] should be abolished because every Mission Statement ever written can be summarized in four words — ‘All babies must eat.’” — Vincent Flanders, author of Son of Web Pages that Suck

    In considering a review of the web site for the International Gospel Fellowship of East Hartford, CT, one of the first things I noticed about this ‘brochureware‘ was the ubiquitous mission statement on their front page, followed by a statement of their core beliefs. Now this isn’t bad information to put on a church web site. I would however, suggest that this information be put on a sub page.

    Generally, you’ve got two kinds of visitors to your site. Members who want information, in which case they’re probably already familiar with this information. Second, and of greater importance are seekers. That is people who are new or visiting to the area, or people experiencing some form of a spiritual crisis, emotional emptiness or physical need.

    What I would suggest is providing the obligatory times and places on the front page (perhaps in a toned-down, off-to-the-side-sorta-way), but also something conspicuously placed that reflects your church’s unique personality and purpose. I mean think about it, I’ve never been to an International Gospel Church (IGC), in fact, I didn’t know such an entity existed until today. How does this particular IGC different from the Baptist Church down the street with a similar goal and mission? For matter, how does this church differ from so many others who state a similar mission online?

    That’s why on the Redland front page, I list some of the most recent events and happenings. It not only makes search engines happy, it keeps the page dynamic and it gives a first time visitor some clue as to all the fun stuff we have going on.

    In other words, while there is doctrine-o-plenty to be found at RBC, there are also smiling faces with warm embraces looking forward to your visit.

    See how enticing that last sentence was? Now go, and do likewise.

  • But if I move to Linux, what happens to all my sermons in Word?

    A chief concern about moving to Linux is interoperability with Microsoft Office applications. Several office suites are available for Linux systems, but there hasn’t been a systematic study of how well these suites interoperate with Microsoft Office. We decided to conduct a small pilot experiment to explore how interoperable current Linux office applications are with Microsoft Office. On January 11, 2003, we downloaded 150 files from the Internet: 50 Word (.doc) files, 50 – Hal Varian, ACM Queue, July/August ’03

    Let’s face it. One of the big reasons your church or charity hasn’t moved to a Linux platform is because you’ve got so much invested in Microsoft Word, PowerPoint and Excel. That’s no accident. Microsoft is merely following the “killer app. model” established some 22 years ago when Mitch Kapor’s Lotus 1-2-3 made the IBM PC a must-have business machine.

    Put another way, many of us select hardware based upon the requirements of the operating system, which we select based upon the needs of the application software we intend to run. Oh sure, the process usually isn’t that linear, but explains why church administrators find themselves putting-out $300 a seat for Microsoft Office (and then live with the guilt of installing an unlicensed copy on their home PC.)

    Why the blind faith MSFT? Well for one, all the pastor’s sermons are in Word, or in some cases, Word Perfect 5.n. The music minister has a library of praise songs saved in PowerPoint. Then there is the calendar for the sanctuary usage often saved in Outlook or even Excel. Then there is software to keep the books. To track visitors. To produce and distribute the bi-weekly newsletter. All on a Windows platform. So why move to Linux?

    I mean even with an application as solid and flexible as InfoCentral, there is no popping a disk into the computer and mindlessly “NEXT >>” buttons … nor does the average church administrator feel comfortable with keeping such information online even if it is hosted on a well-armored intranet … provided you even have an intranet. Similarly, heaven help you with installing something as codependent GNUCash or as security conscious as eGroupware without someone in your parish who can speak pure geek (and is willing to read 27 pages of documentation).

    On the other hand, most small to mid-sized churches and charities I know have one machine dedicated to accounting (hopefully) behind a locked door – with membership info ported via sneakr-net in the form of delimited ASCII or DBF files. The rest of the computing activity is limited to sermons, letters, newsletters, fliers, slide-shows and some simple list management and/or cost analysis by varying members of the ministerial and administrative staff. For those situations, I would suggesting taking you take a good long look at using OpenOffice, even if for now, it is on a Windows Platform.

    Last month, Hal Varian at U.C. Berkeley, along with his son Christopher, published an article in the ACM Queue entitled MOXIE: Microsoft Office-Linux Interoperability Experiment. Now for those of you who aren’t nerds, the ACM is a rather prestigious and well respected educational and scientific society. Moreover, being a professional association, the ACM isn’t prone to some of the marketing and advertising forces that pull many technical magazine in one direction or another. So when I see an article that essentially says OpenOffice, and it’s kissing cousin StarOffice can import 97% of existing Word, Excel and PowerPoint documents, I pay attention.

    I would also burninate two CDs and give one to my church administrator and my youth minister the next time I see him and with absolutely no technical verbiage, explain to him that “the software on this CD can save you $300 per software seat, and is compatible with just about every document you have.” If I see they’re interested, I might also add “it also lets you export your ‘Write’documents to Adobe Postscript and HTML format … and your ‘Draw’ and ‘Impress’ documents to Flash with a couple clicks of a button” … which is another coupla hundred of dollars saved.

    What about the 3% of unreadable documents? Well, after reading the article along with some input from over at SlashDot, I doubt that too many music ministers are using the math or macro features in Word to compose this week’s hymn. Moreover, it seems that Microsoft Office has about the same failure ratio in reading it’s own documents.

    Why the evangelism? It’s about talents. When people give your charity money, they’re hoping that more goes to those in need, than to the needs of the back-end operation. It’s also about accountability and integrity. Even if you continue to use legally licensed copies of MS Word at your office, giving them a compatible office suite on their HOME pc may help your minister stay out of software hell. Deploying OpenOffice, even if it is on existing Windows platform that is currently equipped with an (aging) copy of MS Office, is practical and realistic step in that direction.

    … From everyone who has been given much, much will be demanded; and from the one who has been entrusted with much, much more will be asked. Luke 12:48b

  • Host File Configuration Fun

    I realize I’ve been a bit ‘preachy’ the past couple of days, so let me make that up to you by offering something very ‘geeky.’

    If you’re like me, you prefer to develop software outside of the production environment. Okay, now to translate that last sentence into English for those of you who are not fluent in ancient geek:

    Those of us who program for a living rarely, if ever, perform any major software surgery on live/active website. Instead, we keep a copy of the website, either in a subdirectory on the same web server, or if you are an ‘uber-nerd,’ on a web server you have running in your house (or in the basement of your church) .

    Running a web server at home (or in the church basement) for development isn’t all that hard, but setting one up is a topic for a later discussion. Today, I want to talk about how to play some domain games to trick your routers and computers so instead of having to address your site like this:

    http://192.168.1.120/index.php

    You can instead address it like this:

    http://foobar/index.php

    Notice, I didn’t enter the URL foobar.com, but just foobar. There a variety reasons for this. First, I really don’t want to spend $8.95 per year to register a test domain for each domain I’m developing. Second, I’m running my Linux/Apache server on an old Pentium II, so excluding the overhead of a DNS daemon gives my tired old machine a bit of a break. Third, unless someone hacks past the Zone-Alarm enhanced firewall on my LinkSys router, there’s a slim-to-none chance that anyone else entering http://foobar/ on their machine is going to see my test site on my intranet.

    To do this, it means modifying a file named “hosts” on both my Windows and Linux systems. Here is how mine is configured (almost, the IPs have been changed to protect the innocent). Here is the how the file c:\winnt\system32\drivers\etc\hosts is configured on my Windows 2000 box:

    127.0.0.1     localhost
    192.168.1.120     foobar

    Here is how the file /etc/hosts looks on my Linux box (and please note, though I use spaces in this article to delimit the columns, you should use tabs):

    127.0.0.1     foobar     localhost.localdomain     localhost

    There are some drawbacks to this approach. First, my Linux configuration assumes I’m working on only one project. If I wanted to work on multiple projects, I would have to configure the Apache system for multiple virtual domains (a.k.a. virtual hosts), each with it’s own IP. In that case, the /etc/hosts file might look like this:

    127.0.0.1     localhost.localdomain     localhost
    192.168.1.120     foobar
    192.168.1.121     blog4god
    192.168.1.122     healed

    The file c:\winnt\system32\drivers\etc\hosts would look essentially the same. Which leads me to another drawback, unlike a DNS server that automagically maps these tables for you, you’ll need to keep both hosts files in sync some how – or should I say, rsync (t the reader understand)? Also, if you’re still using Windows 95, 98 or ME, you’ll have to remember that the hosts file is in the c:\windows\host directory, and that Windows XP may be configured so that hosts can be found the directory c:\windows\system32\drivers\etc\.

    Another thing you need to remember is that if you haven’t installed some form of web server on your Windows system, then it is more than likely that hosts is actually residing on your system as hosts.sam. This means you need to remove the .sam extension to get things to work.

    For you non-BDS Mac users, I believe (and I could be wrong) the hosts file can be found in either the system or the system/preferences filter, and if not, and someone PLEASE correct me if I’m wrong, you simply open up your text editor and create one with the following entries:

    127.0.0.1     A     localhost
    192.168.1.120     A    foobar

    I know the above sounds like a lot of work, but honestly, it took me all of 10 seconds to get it done at home. Once done, this allows me to work on a localized copy of MovableType, Drupal or any other tool/toy to work out formats and kinks before they go live. That is, once I go through the ‘heck’ of installing MySQL, php, Perl, and any of other libraries and schtuff required to get a particular app. up and running.

    One thing you should note, this approach also works for those of you running an IIS web server at home (on in the church basement) as a development server — and for those of you running a web server on your PC on which you develop — though my preference is always to set it all up an old computer just in case it does get hacked and wacked.

    Disclaimer – as always, before you try stuff like this, backup your files, write down your configurations and remember – your mileage may vary (esp. if your router is different than mine).

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