Thursday, August 24, 2006

Your Own Apache Web Server.

Having your own Web server goes beyond the need to put your business' information out on the Internet for all to see. While that certainly won't hurt, there are many more ways you can take advantage of such a server.

Whether you are running a department within a large corporation, or your own small business, having access to an HTTP server can quickly improve the way your employees share knowledge.

Groups within an organization of any size generally need to share a great deal of information, even though they may be working toward different goals. One way to accomplish this is to provide groups and individuals with access to an intranet Web server and allow them to publish their own facts and figures. Everyone could share one web server, and have a common user interface to access each others' work. If more space or segregation of information is needed, individual groups could set up their own web server using surplus hardware and Linux.

In another situation, you--the content provider--know exactly what you want, but are unable to find just the right package of features at the right cost. Many ISPs charge extra for even basic logging information. Given the tight margins that all businesses have to operate within these days, occasionally the right move is to set up your own host hardware.

Another reason to set up a Web server is that some Internet-based applications may require performance that only a dedicated server can offer--tuned to your special needs.

It may seem unlikely that you can provide a better service than experienced ISPs, but ISPs are catering to a mass market and tend to charge a lot for special services. Some web applications just don't fit into the general ISP scheme and installing your own web server on a Linux box, could prove to be a cost effective way of getting the Internet services you need.

Making basic documents available is fairly straightforward. First, install a Linux distribution containing Apache. You can check that the server is up by pointing your browser (Mozilla, Konqueror, etc. on the same machine as the server) at http://localhost/. You should also be able to access this remotely with the machine's name. For instance, if the machine's domain name is penguin.org, then the URL http://penguin.org should work. Next look at the server's configuration directory. On SuSE this is /usr/local/http/htdoc/. Look for the directive DocumentRoot in the http.conf or srm.conf files. This will show the server's main document directory. A file (in this case file.html) placed here will appear at the topmost level, such as, http://localhost/file.html

By default the server also looks in users' directories for public HTML directories and makes these available on the web server. For instance, if you have a login code john with a home directory /home/john. Place some files in /home/john/public_html and they will become available at http://localhost/~john/

Next, we will look at a popular method to produce dynamic content based on a web user's input to a form. Normally, web users looking at your site will only see static HTML pages. The web scripting language PHP allows web pages to be built "on-the-fly" according to user input. PHP is very powerful and as programming languages go, is pretty easy to learn.

You will no doubt be aware of PHP scripts and their typical uses for processing forms and serving up dynamic content using databases. To make PHP scripts work, just make sure the it is installed, along with Apache, when you build Linux on your machine. On the server, you will also need to set up a special web directory so you have a place to put the scripts.

Create a "php" directory under your main web server directory (in SuSE 8.0 that's /usr/local/httpd/htdocs). You can also use your ~/public_html directory, if you like. That's what I'll use in my example. In this case it would be /home/rreilly/public_html/php.

Then you can enter the following text for your first php script. Call it inputform.php.

You'll also need an html file to go along with it. Put this file (call it form1.html) in the same directory as your php script.




Call up the form1.html file in your browser (http://localhost/php/form1.html, for example), enter your name and click on "Submit". You should see "Hello World, (your name)" in the browser window.

That's pretty much how PHP scripts work. Nothing complicated.

Web server security, especially with PHP, is another topic that you should investigate. Of course, it's not possible to adequately cover it in this article. Pick up a good book on PHP, if you want to really want start learning the language. I've found Larry Ullman's Visual Quickstart Guide "PHP For The World Wide Web" to be an easy to read and very useful basic text. Then look for some current how-to articles on the Web about security and PHP to fill in the security gaps.

Once you start getting some traffic on your web site you will be asking yourself questions. What files are people getting? Which area of the site is the most popular? What are the total number of megabytes we transferred last month?

To answer questions of this type you need to look at your logfiles. The server generates at least two logfiles: you can tell it to split up the data into more. There is always an 'error' log and an 'access' log, which are located in the /var/log/httpd directory.

The error log records attempts to get files on the server that fail. For instance if a user makes a typing mistake then the misspelled URL will show up in the error log.

The access log is a list of the URLs that were successfully retrieved. Both logs contain dates, number of bytes transferred and some information on where the request was made from. There is a powerful program for doing this under Linux and other UNIX-derived systems. The program is called analog. The simplest way to use analog is to install it as a package and then type:

analog >report.html

Look at report.html with a web browser, and then play around with analog. This program can be configured to extract information in every conceivable way from the server's log files.

Apache is a reasonably fast server. It can saturate a 10 Mb/s line using only a low end Pentium under normal conditions. But it is possible to tweak a little more performance out of it. Here are some things to try:

* In the file http.conf, change the value of MaxRequestsPerChild to 10000
* Add +FollowSymlinks to all your directory sections

Available RAM

Admittedly, this is a no-brainer.

Adding RAM to your machine can have a major effect. RAM is thousands of times faster than even the best hard disk. Because of this, the Linux system uses RAM to cache recently opened files. Apache will then be able to service requests faster. So even without altering any Apache config directives, after you add more RAM to your Linux box, it will be faster.

We have just scratched the surface for using the Apache web server to distribute information via web browsers. If you want to know more take a look at the excellent documentation that comes with Apache. How far you go is limited only by your imagination and time. Putting together a couple of small web servers in your company is an excellent way to learn the technology.

Tuesday, August 01, 2006

Has Linux patching surpassed Mac and Windows?

This may seem like a shock, but is it possible that the Linux patching has surpassed the Mac and Windows operating systems? Recent vulnerabilities in Flash and Firefox that can affect multiple operating systems highlight a weakness in the Mac and Windows auto-update process because they're primarily focused on patching Apple and Microsoft specific issues.

A notification system on third party vulnerabilities would be better than nothing. Most modern Linux distributions on the other hand like Redhat, SuSE and Ubuntu have automatic update mechanisms that patch across the entire spectrum of software since Linux by its very nature is made up of a collection of applications from different sources.

Most regular users don't really think about the patching process and can't possibly keep up with all the security advisories. If we take this particular vulnerability report for a critical flaw in Macromedia Flash, I would bet that the average computer user still hasn't and won't patch this vulnerability until some mechanism forces them to update it.

The Windows and Mac update mechanism will not bother with this particular vulnerability, but Redhat has already released a patch as a part of regular Linux update process. Microsoft has released patches for Macromedia Flash in the past but only because it was the version bundled with Microsoft Internet Explorer. Windows update will not address this particular flash vulnerability which technically isn't Microsoft's fault but it's still a very serious problem for Windows users that can lead to complete system compromise.

Microsoft has made some effort to consolidate the patch process for all Microsoft products with their Microsoft Update site, but this only addresses part of the problem for most Windows users. I'm not necessarily blaming Microsoft and Apple for not dealing with vulnerabilities from third party software vendors since they can't be legally held responsible for someone else's software, but the major Linux distributions have already made the effort to consolidate the update process. At the very least, it's an opportunity for Microsoft and Apple to make life easier for their users.

Perhaps what is needed is a centralized location for approved third party vendors to provide their latest critical updates within the Windows and Mac update systems which should at the very least include common software such as Macromedia flash and maybe even Mozilla Firefox. Then let the users opt in or out of third party patches within the regular auto-update mechanism. Even a notification system on third party vulnerabilities would be better than nothing. Without this, the average Windows and Mac user will simply leave the door wide open on third party applications for hackers to exploit.