The Quick Road to an Intranet Web Server
Apache has many wonderful configuration options available. To someone who has never managed a web server, the list of options might seem quite daunting. However, it is possible to employ a simple cookbook method to get your web server up and running in short order. The following values will produce a working Intranet server which should perform marvelously in most organizations. Of course, if you have special security requirements, a review of the Apache documentation is quite helpful.
Any Linux distribution with an easy installation of Apache will likely have a reasonable set of parameters already enabled. Even if your web server is live seconds after installation, you may want to review the configuration files just to find out what features have been enabled and disabled by default.
The Apache configuration generally has four files of note. In Red Hat, these are found in /etc/httpd/conf/. In Debian, they are located in /etc/apache/. If you built Apache from the sources as described above, they should be in /usr/local/etc/apache/conf/. The four files are access.conf, httpd.conf, srm.conf and mime.types.
If the files are not found in your kit, you should be able to locate the same group of files with names ending in .conf-dist. Simply copy each of these files to the appropriate location (e.g., /etc/httpd/conf/ if you are using Red Hat) using the .conf file type, and edit the files so that they contain the parameters described below. Note that the Apache-supplied configuration files contain useful hints not shown here for the sake of space, as well as many additional parameters not discussed here. So, it is best to edit the files to contain the following parameters, rather than attempting to construct new configuration files from scratch.
Of the four files, mime.types is the least likely to require modifications. It is a table which associates MIME headers with file types. For example, the table will say that a file ending with .gz should generate a MIME header of application/x-gzip.
The most likely candidate for parameter adjustment is the access configuration definition. In access.conf, try using the following values:
<Directory /home/httpd/html> Options Indexes Includes ExecCGI FollowSymLinks AllowOverride None order allow,deny allow from all </Directory>
In this example taken from a modified Red Hat file, this entry says that the main HTML files for this server will be stored in /home/httpd/html. The options include:
Indexes: if the user specifies a URL that points to a directory name rather than a file name and that directory does not contain an index file (such as index.html), Apache will display a list of the files contained in the specified directory. If you don't want this behavior, simply omit the “Indexes” keyword from the “Options” line.
Includes: this allows the server to include files as directed.
ExecCGI: if the URL specified is actually a CGI script, this will allow that script to execute. If you are not interested in CGI scripts, don't include the keyword.
FollowSymLinks: Let's say that I've created a symbolic link to my CD drive in this directory. This keyword will instruct Apache to allow access to that CD as if it were a subdirectory of this directory. This facility can be quite handy if you wish to serve up the contents of a CD or allow access to the HOWTOs which normally reside in a tree such as /usr/doc. One quick symbolic link, and you can allow Apache to serve those files without moving them or creating individual symbolic links. But remember to create symbolic links with care, or else you might find that your web site is serving up documents you never intended to be universally available.
The CGI directory entry will generally look more minimal, like:
<Directory /home/httpd/cgi-bin> AllowOverride None Options None </Directory>
The parameters that define the operational parameters for the Apache daemon in httpd.conf are as follows:
HostnameLookups onIf HostnameLookups is “on”, the server will use DNS to try to determine the user's host name for logging purposes.
User nobody Group nobodyUser and Group determine the access privileges of the remote user. The server will act as if it were a job created by the specified user and group (in this case, “nobody”).
ServerAdmin root@localhostServerAdmin sets the user name and host to receive mail messages that might be generated by the daemon.
ServerRoot /etc/httpdServerRoot sets the base directory for configuration and log files.
ErrorLog logs/error_log TransferLog logs/access_log RefererLog logs/referer_log AgentLog logs/agent_logThese parameters specify the name and location of various log files. The directories specified are relative to the ServerRoot directory. Once you've run Apache for awhile, examine these log files. In them, you'll find information about which pages were accessed when and by whom. You'll even find information about the page that called your page and the type of browser the user was employing to look at your site.
MinSpareServers 5 MaxSpareServers 10 StartServers 5 MaxClients 150These parameters deal with the fact that Apache generates child processes before they are needed in order to deal with any sudden increase in incoming traffic. These parameters specify the minimum and maximum number of unused children which should exist at any point in time. They also specify the absolute minimum and maximum number of children which should be available. Using the command ps ax will reveal the multiple children which the Apache daemon is currently using.
The file srm.conf contains many different items. It deals largely with the name space of the server as well as how the server responds to requests. Of special interest are the following lines:
DocumentRoot /home/httpd/html Alias /icons/ /home/httpd/icons/ ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/ UserDir public_html
DocumentRoot specifies the top of the directory tree that contains the pages to be served. Alias allows the specified directory to be accessed by a pseudonym, even though it is not under the DocumentRoot tree. ScriptAlias is like Alias except that the directory will contain CGI scripts. UserDir specifies the user's subdirectory to look in for any URL that uses a /~username/ specification. For example, if the user's default directory is normally /home/username/, then the user's default HTML directory will be /home/username/public_html/.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- SourceClear Open
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide