This document is currently under development and not intended
for widespread distribution. There are missing sections, in addition to
some poorly written and incomplete sections.
Introduction
The UGA WebService -- http://www.uga.edu/ -- is a service maintained by University Computing and Networking Services within the guidelines and recommendations of the Georgia Web Group advisory board. The University of Georgia WWW Services Coordinator (UWC) is a UCNS employee whose major responsibilites include the following. Each of these responsibilities is discussed further in subsequent sections of this guide.
GWG and General Discussion Lists
The UWC is the list owner/manager of two LISTSERV discussion groups: gwg-l@listserv.uga.edu and ugawww@listserv.uga.edu.
LISTSERV help is available for both owners and subscribers. This help includes information on adding subscribers, deleting subscribers, and reviewing the subscribers to the list.
HTTP Server
The UGA WWW server is a Unix-based Apache HTTP server. A local copy of the source code for the current version of Apache on www.uga.edu is located here: /usr/local/src/apache Documentation and related information on Apache are available from the Apache website: When a new version of Apache is dowloaded for installation, the source should be retrieved from the Apache website and placed in /usr/local/src/apache.
Hardware and software
are maintained by University Computing and Networking Services.
/usr/local/apache/
httpd runs on port 80, the default HTTP port.
Related files, programs, and main UGA pages are in directories off of this
ServerRoot Directory.
UGA is currently using Apache HTTP.
Specifics regarding the current version of httpd:
[an error occurred while processing this directive]
Specifics regarding the current hardware on which httpd resides:
[an error occurred while processing this directive]
./httpd -d ServerRoot
or restarted (for various reasons, like a change in one of
the
runtime configuration files) with the command:
kill -HUP pid
from within ServerRoot. The current process id (pid)
is written to:
ServerRoot/logs/httpd.pid
To completely stop httpd, use the command:
kill -TERM pid
Anytime httpd is started, restarted, or stopped,
the error log, ServerRoot/logs/www-error.log,
should be viewed for messages related
to the starting, restarting, or stopping of httpd.
/etc/rc2.d/S99httpd
ServerRoot/conf
contain the runtime configuration files which control the
running operation of
httpd. This directory also contains other configuration files for
programs subsidiary to httpd.
Runtime Configuration Files
httpd.conf
Whenever
a new version of
httpd is
installed, changes to these files may be required.
This is not always necessary, but is
a possibility and they should certainly be reviewed.
The runtime configuration
files include a number of comments (indicated by #) as
well as a pointer to the online documentation for additional help.
Comments marked with:
# LOCALCON
have additional significance,
indicating a special "Local Consideration."
Any change to a runtime configuration file requires a
start or restart of httpd
for the change to take effect.
These files are different from
the Configurationfile used when
compiling httpd.
The runtime configuration files control how httpd operates and
the Configuration file is used to select
modules to be compiled into httpd.
Configuration Files for Subsidiary Programs
The files:
arc3d.map
are old map files used with imagemap.
These files will likely be removed in the future, since imagemap
is virtually obsolete.
The files:
swish.conf
are used with swish, a program which creates indexes of documents
which can then be searched on the Web using the gateway CGI program
wwwwais. The compiled versions are located
/usr/local/apache//swish and
/usr/local/apache//wwwwais; source code for each
is located in /usr/local/src.
swish.conf
and wwwwais.uga.conf are the
configuration files for indexing and searching files
on the main UGA pages. These are now
obsolete, having been replaced by an improved
website search program.
(In case
of an emergency, swish and wwwwais could be used to
create a Web-searchable index. This is why they have not been removed.)
unipage.html and wwwwais.uni.conf are for users
on www.uga.edu who have made searchable indexes of their pages.
User documentation is available; however, swish is outdated
and users will need to change to a different
indexing and search tool
in the future.
ServerRoot/cgi-bin
contain most
of the main CGI (Common Gateway Interface) programs used on
www.uga.edu.
These programs are listed and described
following. In a few instances,
reference will be made to these two directories in
the descriptions:
ServerRoot/cgi-src
The former contains source code for a few of the CGI programs;
the latter contains the source code and compiled
versions of the support programs unescape and
htpasswd. (unescape is described below; htpasswd
also resides in /usr/local/bin and is used by any account
holder to create a password file for a password-protected directory.)
Changes to programs marked as "Production" which affect
user accounts
on www.uga.edu should always be announced to
ugawww@listserv.uga.edu.
Other CGI programs may be located outside
of this directory. This is certainly true of
user accounts which have been granted
CGI privileges.
/usr/local/apache//htdocs
The pages within this directory include the UGA homepage ( home.html
), the second-tier pages accessed from this page, and some third- and
fourth-tier pages.
The UGA main pages are further described in a subsequent section of
this guide.
ServerRoot/logs
The files ending in .log is this directory include information on
accesses, agents, referrers, and errors. The names of these files and the
location of these files should not be changed. If these are changed, then
a change must also be made to the system log roller executed from
root's crontab:
/usr/local/admin/bin/newsyslog
as well as the
statistics programs described in a subsequent section of this
guide.
The log files are in
Common Logfile Format (CLF), as opposed to "combined" format. The
combined format, which should not be used, includes
access, browser, and referrer information in one file. Some statistics
programs require CLF; others can be configured to use either. It is
recommended at this time that we continue to use CLF files.
In addition to the log files in ServerRoot/logs is the file:
httpd.pid
which contains the current process id (pid) for httpd.
The pid is used to
stop or restart httpd.
Compiling
/usr/local/src/apache
Ungzip and untar the file here; cd to the newly created
directory; read README and
INSTALL in this directory to get started.
Before editing the Configuration file in the src directory,
keep in mind the
following local considerations:
Keep in mind that a corresponding Directive in a
runtime configuration file
will most likely be
required to enable a module. For example, the spelling module:
AddModule modules/standard/mod_speling.o
is enabled with the CheckSpelling Directive:
CheckSpelling on
in the runtime configuration file httpd.conf.
Module agent_log_module mod_log_agent.o
As of version 1.3.3, these modules no longer need to be complied into the
binary.
The names, locations, and type of log files (CLF)
are defined in
httpd.conf.
A successful make results in
the creation of the new binary (httpd) in
the src directory. The new binary is best tested in place
(while it is still in the src directory) before
being installed
(moved to) its permament location and started.
More on testing and installation follows.
Testing
telnet www.uga.edu 8080
A "Connection refused" message clears the way for use of this port. Any
other message indicates that a service is potentially running on this port.
In all likliehood, the service running is an old test version
of httpd that
was not shut down. To verify this, use a browser to connect to:
http://www.uga.edu:8080
If an HTML document is displayed, cd to:
/usr/local/apache//test/logs
issue this command:
kill -TERM `cat httpd.pid`
Check the error log in this same directory for an indication that
httpd was shut down and then telnet again to port
8080. A "Connection refused" message clears the way for use of this port.
Any other message indicates that a service is potentially running on this port.
With the assistance of the UCNS Workstation Support Group, invesitage the
use of this port. To continue with the test procedure,
telnet to a new port (8081 and up) until an open port is found
(a "Connection refused" message).
To assist in testing the new binary, a
test directory is available here:
/usr/local/apache//test
This test directory contains two directories:
It is necessary to manipulate the
value of the ServerRoot Directive and the value of the
Port Directive found in httpd.conf.
The value of ServerRoot in the production runtime configuration
is:
/usr/local/apache/
The value of ServerRoot in the test runtime configuration
is:
/usr/local/apache//test
The value of Port in the production runtime configuration
is:
80
The value of Port in the test runtime configuration
is:
8080
Or a number higher than this number
if port 8080 is in use.
Upon successful completion of testing, it will be necessary to move the
test runtime configuration files to the production runtime configuration
directory. Before the newly tested httpd is started, make sure
that the value of ServerRoot is /usr/local/apache/
and the value of Port is 80. These changes are to be
made during the installation process (detailed below).
After setting up the runtime configuration, cd to the
new version's src directory and use this command to run a syntax
check of the configuration files:
./httpd -d /usr/local/apache//test -t
When this checks out OK, use this command to start the new httpd:
./httpd -d /usr/local/apache//test
This will start the new httpd on port 8080, or whatever port was
used. (Substitute the test port used
for 8080 if different from 8080.) Check the error log for
the test httpd:
/usr/local/apache//test/logs/www-error.log
for messages related to starting the httpd.
The new httpd
can be
started, restarted, and stopped as described for the
production httpd,
keeping in mind the test locations of ServerRoot and the
log files (including httpd.pid).
Proceed with testing by visiting the test URL:
http://www.uga.edu:8080
with several browsers. The usual browser set includes current versions of
Netscape and Microsoft Internet Explorer and one version number back
of each of these browsers on Windows and Macintosh platforms. Netscape
on Unix should be tested as well as LYNX on ARCHES.
When visiting pages, be sure that the footers and headers are
included on all second-tier pages. This insures that SSI is working
properly. To further test SSI, visit these two pages:
http://www.uga.edu:8080/wm/ssi/
and
http://www.uga.edu:8080/www-test/ssi/
Compare these two pages. There should be no errors on the first and
two errors on the second for exec commands. The exec
command is only allowed in DocumentRoot.
Perform a search of the UGA pages and the UGA phonebook (found under
"Searches and Directories" from the UGA homepage.) This should provide a
reasonable test of CGI programs in use.
After visiting these pages, announce to the ugawww list that a
new httpd is available for testing. Invite the subscribers to access
both the main UGA pages and their own pages via the test URL. Inform the
list of a production date (usually no more than a week from the date of
posting) and, of course, request comments.
Installing
The process of installation, or even installation and recovery, can
typically be accomplished in less than 5 minutes; therefore,
the UWC does not
request a formal downtime period for installation.
The install steps are outlined here (be sure to read all steps
before installing):
In order to enable name-based virtual hosting,
the NameVirtualHost directive is set in httpd.conf as follows:
NameVirtualHost 128.192.252.5
Nothing more needs to be done regarding this directive and it is not
related to IP-based virtual hosting.
The three major steps to setting up each virtual host involve (a)
DNS and system configuration requirements,
(b) setting up an area for the new DocumentRoot (which
very likely will require a new user account), and
(c) using <VirtualHost> and
</VirtualHost>in
httpd.conf to enclose a set of configuration directives for
the virtual host.
DNS and System Requirements
A cname record is specified within the sesug.org subdomain
which aliases www.sesug.org to www.uga.edu:
www.ucns.uga.edu is specified as follows within the ucns.uga.edu
subdomain:
New DocumentRoot (Name-Based and IP-Based)
While this directory can be any available directory, www.ucns.uga.edu
has been set up to use the DocumentRoot as if it were
any general user account. The DocumentRoot
is the public_html directory of an account with login name
of ucns:
DocumentRoot /usr/www/ucns/public_html
Using <VirtualHost> and </VirtualHost> (Name-Based and IP-Based)
The Alias directives are for
backward compatibility regarding pre-existing accounts converted to
virtual hosts. It is only necessary to accommodate the use of
absolute URLs on these pre-existing
accounts and will not be necessary in all cases. (Absolute URLs are relative
to DocumentRoot, which has changed as a consequence of virtual
hosting.)
Notice the location of the log files:
UGA Main Pages
The UWC is ultimately responsible for the content and appearance of the main UGA pages, particularly the home (home.html) and second-tier pages. Some "deeper" pages also come under the purview of the UWC. Changes in content and appearance are made in accordance with the guidelines and recommendations of the Georgia Web Group.
Some pages are created offline and transferred to www.uga.edu via
ftp . These pages are typically transferred to the UWC's
personal account and then installed
(moved to) their proper location
within DocumentRoot in accordance with the
testing, approval, and installation process
described following.
Images used on the UGA main pages are located in the directory:
DocumentRoot/images
and directories within this images directory. For example, images used
on the homepage are included in:
DocumentRoot/images/hp
and images used on the second-tier pages are included in:
DocumentRoot/images/st
Search Websites: ht://Dig
Search Phonebook: ldap and ldapsearch
A query entered by the user on the search form for the phonebook is
used by the ldap client ldpasearch (residing in
/usr/local/bin and executed by ldap)
to query the ldap server with the results
returned to the browser as HTML.
The UWC should be aware that the search form for the phonebook may be
incorporated into other main UGA pages for which the UWC is responsible.
These pages can be located by using glimpse, a
link management tool available on www.uga.edu.
The most commonly used SSI is include virtual.
This SSI is of the general form:
<!--#include virtual="/path_to_file_from_DocumentRoot"-->
and is found on all the second-tier pages to include the menu bar at the
top of the page and the page footer. As an example, see:
DocumentRoot/acad
The top frame for the page--top.html--contains this SSI:
<!--#include virtual="/images/mb/js.html"-->
to include the JavaScript which enables the Onmouseover effect
in the menu bar. The SSI:
<!--#include virtual="/images/mb/mbac.html"-->
is the actual menu bar for this page. (Other pages will have the same
include for the JavaScript but a different include for the menu bar.)
The bottom frame for the page -- bottom.html -- contains the SSI:
<!--#include virtual="/uga-trailer.html"-->
to include the page footer.
Other SSIs include the one found in /uga-trailer.html, which
echoes the LAST_MODIFIED environment variable:
<!--#echo var="LAST_MODIFIED"-->
and includes the date the current page was last modified.
Other environment variables can be similarly included.
An SSI on home.html executes a CGI program which includes the
current date and time on the page:
<!--#include virtual="/cgi-bin/p-date"-->
SSIs which include files (include virtual or include
file ) and output from CGI programs (as in the p-date
example above)
are allowed in all directories, including user directories.
However, only DocumentRoot and the user ucns are
allowed the
exec option. The exec option
allows any system command
to be executed. See the
runtime configuration files for more information regarding this setup.
HTTPS Server
The https server is not currently a production server. When installing a new Secure Server Digital ID, leave "Certificate Name" blank.
CGI, JavaScript, Java, and Other Programs
Much of the content in this section is pointers to other content areas of this guide.
/opt/local/src/jdk
The Sun install/de-install programs are used to upgrade JDK. The main
java and related binaries are available from:
/bin
among other places.
also mention pcprint in /usr/local/bin
User Accounts and Accounting
Departments, units, organizations, and groups affiliated with UGA are provided space on www.uga.edu for WWW pages. The space, in the form of a "user account," is established in accordance with the policies set forth in WWW Pages for Departments, Organizations, and Units.
Although the policies clearly state that accounts are granted to
University-affiliated units, some requests come from individuals
whose organizations have a "loose" affiliation with the University.
National professional organizations are a good example. Under certain
circumstances, these organizations are provided space on www.uga.edu.
A quasi-affiliated organization must request WWW space in
writing, as these
quasi-affiliated organizations have done. A requesting document, specific
to the organization and based on the preceding documents, should be
prepared for the organization. The new requesting document should
be placed within the same directory as the preceding requesting
documents and the
URL of the requesting document
should be communicated to the requester to faciliate the preparation of
the written request.
/usr/local/apache//master
When a request is received, the requester is contacted by phone.
Affiliation with the University is insured during the
conversation. If the requester is a
student, the name and e-mail address (or other contact information)
of a faculty/staff sponsor must also be provided.
The process continues as follows;
be sure to read all steps in the process before setting
up an account.
Decide on Login Name and Create Account
cd to:
/usr/local/apache//master/pgms
and view the contents of wwwadd, a program which uses the
useradd command to add a new user account. (Of course, once
the UWC understands how wwwadd works there is no need to
view the file each time it is used.) wwwadd takes two arguments,
the first is the login name and the second a brief description of the
account. The former is checked for conflicts; should one exist, a new
login name will
have to be used. If the second argument contains spaces,
make sure it is quoted. Example:
./wwwadd osfa "Office of Student Financial Aid"
wwwadd ends with establishing and checking the
quota for the new account followed a
a password request. The UWC should ask
the requester to provide a password and recommend a more secure one if
necessary.
Create Accounting Entry
/usr/local/apache//htdocs/master/www/www.uga.edu.admins
Information about the new account is included in this file.
Each entry contains the name of
the organization, an accounting record (the line beginning with
400U) in accordance with the
UCNS billing file record format, and the name of the website
administrator
and website sponsor (if not the same).
At his point in the process, the UWC has all the information needed to
create the entry with the possible exception of the user account number.
The user account number is the letter U followed by the
three-digit department code found in the
UGA Chart of Accounts. A suitable number can, and should, be found here.
If there is a problem, the UWC should rely upon assistance from the UCNS
Billing Office. The user account number ends with WEB.
After completing the new entry, e-mail the information to the UCNS Billing
Office. At the present time this is
sdcarte@uga.edu.
If two
names are associated with the entry, indicate which is the sponsor.
Run the accounting program in the current directory.
accounting creates a file in the directory:
/usr/www/ucns/public_html/inhouse/wainfo/wainfo
Check this file to insure that the new entry conforms to the record
format. The UWC's responsibility ends with the creation of wainfo.
The UCNS Billing Office retrieves the file periodically to generate
billing statements for account managers, who are associated with the
account through the user account number. (Accounts are assessed a fee of
$0.)
~ Removal from URL by Creating an Alias
http://www.uga.edu/~login_name
unless the UWC modifies ServerRoot/conf/httpd.conf to remove the
~ from the URL.
The removal of the URL for new (and existing) accounts requires
the addition of an Alias entry
(not ScriptAlias) to the runtime
configuration file:
ServerRoot/conf/httpd.conf
And a restart of httpd.
There are many examples in httpd.conf, including this one for
the account audit:
Alias /audit /usr/www/audit/public_html/
Notice, in particular, that there is no trailing slash at the end of
the fakename. Also, realname is the real path to
the public_html directory of the account being aliased.
If the request is to be granted, the quota for a particular user can
be changed
using the
edquota command:
edquota login
The current disk quotas for login will be displayed in
editable form. For example:
fs /usr/www blocks (soft = 40000, hard = 40000) inodes (soft = 0, hard = 0)
The soft and hard limits are set the same and are set by changing the
number associated with each and saving the file. (The default editor is
vi unless the EDITOR environment variable specifies otherwise.)
Accounts are deleted using the userdel command:
userdel -r login
The -r insures that all associated files are deleted for
the account name specified with login. All
Alias and
ScriptAlias entries should also be removed.
The accounting record is purged from www.uga.edu.admins,
the accounting program is run, and the
UCNS Billing Office is notified in the same manner as a new
account setup.
Links and Link Management
Using the 404.html file for sites that are removed from www.uga.edu.
Statistics
|
