In-Class Exercise: Installing Movable Type

1) Telnet (or secure shell) to grace, and use pwd to find the full path to your home directory (you’ll need this later, so write it down). Mine is /users/rit0/g1/ellics, but yours will be slightly different.

2) If one doesn’t already exist, create an .suexec file in www directory. (The presence of this file allows the web server to run CGI programs as “you,” so that you don’t have to give write permissions to the whole world.)

3) You’re going to need three directories—one in your home directory to hold the database files, and two in your www directory for the movable type program files and the blog itself. In the examples below, the database directory is called db, the movable type program directory is called mt, and the blog directory is called blog. You can call these whatever you want. The permissions on all three directories must be set to 755.

(If you use the example directory names, the path to log into your blog for editing and configuration would be http://www.rit.edu/~yourid/mt/ , and the path to read your blog would be http://www.rit.edu/~yourid/blog/)

When done, log out from grace.

4) Download the full version (with libraries) of Movable Type, and decompress it locally with unstuffit or winzip.

5) Edit the mt.cfg file using a good text editor (e.g. BBEdit or UltraEdit). Make sure the program is set to save the files with UNIX line breaks, to avoid problems when uploading. (More detailed information on the configuration file can be found in the Movable Type installation documentation, on their web site. This is an abbreviated, RIT web server version of the instructions).

• change the CGIPath variable to be http://www.rit.edu/~yourid/mt/ (if you chose a different name for the movable type file directory, use it here)
• change the DataSource line to show the full directory path to your db directory (e.g. /users/rit0/g1/yourid/db), substituting your path from step 1, and the name you gave your db directory
• Uncomment the following lines in the file by removing the # from in front of them.

DBUmask 0022
HTMLUmask 0022
UploadUmask 0022
DirUmask 0022

6) Edit all files ending with .cgi to include the proper path to perl (/usr/local/bin/perl). (The only exception is the mt-db-pass.cgi file, which does not need to be edited.)

7) Use an FTP program to upload all files and directories in the distribution directory to the movable type directory you created. Most FTP programs will properly set the directories to 755 and the files to 644, but you probably want to check to make sure that’s the case for the mt directories.

8) Using your FTP program, or a telnet/secure shell connection, change the permissions on the .cgi files to make them executable (chmod 755 *.cgi)

9) Open a browser and run the mt-check program to test the installation:
http://www.rit.edu/~yourid/mt/mt-check.cgi

If mt-check.cgi is successful, run the mt-load program to initialize the software
http://www.rit.edu/~yourid/mt/mt-load.cgi

(Substitute the name of your movable type directory if you didn’t use mt)

If mt-load runs properly, delete the file so it can’t be re-run.

10) Use a browser to go to http://www.rit.edu/~yourid/mt/mt.cgi and log in with the default values—user Melody, password Nelson. Immediately edit your profile to change the user name and password to what you want. (The user name will be what shows up on your posts, so choose something you’d like to be “public”.)

Image Files for Pre-test

For those of you having trouble accessing myCourses, here are the image files for the pretest (it’s a 1.6MB zip file with four images in it). Remember, you need to use these—or something similar—to create a composite image mockup of a web page—not an actual web page.

Configuring Your Weblog

On the “Manage Weblog” screen, select “Weblog Config” from the menu on the left.

You need to enter the UNIX path to your blog directory, and the URL to the directory; then add “archives” to the end of each for the next two fields. It should look much like the example below, but with your user ID and path substituted for mine.

In-Class Exercise: Assessing Accessibility

1. Use Cynthia Says to evaluate at least two of your own web pages (with at least one of those being on your Grace account). Make note of all of the priority 1, 2, and 3 problems identified.
2. Now, fix the Priority 1 problems. Remember that to pass the W3C recommendations, you must not have any Priority 1 problems. (You may find it helpful to use the WCAG checklist.)
3. After you’ve fixed your Priority 1 problems, look at the other comments in the report provided. Your efforts should now be directed towards fixing any Priority 2 problems. Finally, Priority 3 problems may also be fixed to provide maximum accommodations.

Post a comment to this entry that describes what you had to change on your site, and what level of accessibility compliance you were able to achieve.

In-Class Exercise: Accessibility Simulations

1. Sign out a pair of headphones from the main computer lab (or use your own if you have some), and complete the tasks on WebAIM’s Screen Simulator.
2. Go to the Cognitive Simulator on the same site, and complete those tasks as well.
3. On the Vischeck site, provide a URL to a web page you’ve created, and see how it would appear to a person with color blindness. Try it with some of the web pages you frequent most often.

CSS Files and Sites

Download this .zip file (if it doesn’t automatically decompress, you should be able to double-click on it to open it). I’ll be using the html files in it as examples while I talk.

These are some sites with useful CSS tutorial and resources:

• Muldur’s Stylesheet Tutorial (Webmonkey)
• CSS Tutorial and Guide (WestCiv)
• Get Started with CSS (builder.com)

These are examples of how changing the stylesheet for a site can drastically change the appearance of the site.

In-Class Exercise: CSS Formatting

Select a poem that you like from the “Verse” section of Bartleby.com.

Use CSS to modify the appearance of the poem.

Use Dean Allen’s Textile tool to generate valid HTML entities for punctuation, as needed.

When you’re done, upload the html file (and external CSS, if you used one) to your Grace account, and add an entry to your class weblog with a link to the page. If you don’t already have a category set up in your weblog for in-class exercises you should add one—that will let me view your in-class work easily at the end of the quarter when I’m assessing participation.

files for javascript prompt exercise

Here’s a zip archive of the files for the Javascript in-class exercises.

In-Class Exercises: Javascript & DHTML

In addition to the menu bar tutorial, you should try writing your own search engine bookmarklet, using the bookmarklet tutorial on Doc Javascript.

Server-Side Authentication: In-Class Exercise

Using Server-Side Authentication on Grace

The apache web server includes a program called htpasswd that allows you to create users and associated passwords for access restrictions on web directories. To password-protect a directory you need to do two things—first, use the htpasswd program to create a user and associated password in a world-readable file, and second, create an .htaccess file in the directory you want to restrict that references the password file.

If you’ve never created a password file before:

1. Create a directory in your home directory (not your www directory) to put the password file in.
2. Change the permissions on the directory you just created to 755
3. Make sure you’re in the directory you just created, and run the htpasswd program with the -c flag to create a new password file. You can name your password file whatever you’d like, but I suggest “hiding” it by starting the name with a period. You also must specify a user name to include in the password file when you first create it. (You’ll be prompted for a password for that username.)
   
   htpasswd -c password_file_name username
4. Change permissions on the new password file (whatever you put for password_file_name in the above command) to 644

If you have a password file, but want to add a new user to it:

1. Make sure you’re in the directory where the password file is located.
2. Run the htpasswd program without the –c flag, specifying the name of the existing password file, and the new username to add.
   
   htpasswd password_file_name username2

To restrict a web directory to a user specified in the password file:

Create a world-readable file called .htaccess in the web directory you’re protecting, with the following contents:

The AuthUserFile path should be the full UNIX path to your password file. (To find the path, change to the directory the password file is in, and type “pwd”.)

The AuthGroupFile should be left as /dev/null

AuthName is the label that will appear in the password prompt box; it can be whatever you’d like, but it cannot have spaces in it.

AuthType should be left as basic

Replace “username” in the last line with one or more users you’ve added to your password file using htpasswd. (The example uses two usernames.)

To restrict a web directory using DCE authentication:

On Grace, you can also use the .htaccess file to restrict access using DCE usernames rather than your own password file. You can only use DCE authentication through the secure (SSL) server, which means your page will have to be referenced using the https protocol, i.e. https://www.rit.edu/~abc1234/protected_directory/

To limit access to any RIT user with a valid DCE userid, use the following .htaccess syntax:

To limit access to only specific DCE user(s), use the following .htaccess syntax:

Server-Side Includes: In-Class Exercise

Look over Professor Vullo’s SSI Demo page, and/or the Apache SSI tutorial. Using those examples as a starting point, create a page that automatically shows the current date and time, and also includes a copyright statement taken from an external file in another directory.

Dynamic Sites and CGI: Second Exercise

Now that you’ve done a little bit with CGI, I‘m going to have you retrieve a CGI script from an archive, and install it into your account on Grace. Then you’ll develop a form to access that script.

We’ll be using a script from Matt’s Script Archive called FormMail, which is used to email form inputs to you. Go to the archive and download the script now. You should also review at the ReadMe file for FormMail.

Part 1: Configuring and Installing FormMail

You’ll be installing the formmail script into the same directory where you placed the first.cgi script from the last exercise. The permissions should already be set properly on that directory.

Save/download and open FormMail.pl so that you can edit the necessary variables.

The first line of the file needs to show the location of perl on the server. On grace, the location is /usr/local/bin/perl (you can find this by doing the “which perl” command at the unix prompt).

Default: #!/usr/bin/perl
Grace: #!/usr/local/bin/perl

After that, there are only three variables in the perl file that you will need to define:

1) The $mailprog variable must properly define the location to your server’s sendmail program. If this is incorrect, form results will not be mailed to you (because the program won’t know WHERE the mail program is on your system). It’s tricky to find the sendmail program on grace. You’d think it would be in something like usr/lib or even usr/bin. It’s in usr/sbin … and, if you type “which sendmail” at the prompt, you can verify this.

Default: $mailprog = ’/usr/lib/sendmail –i -t’;
Yours: $mailprog = ’/usr/sbin/sendmail –i -t’;

2) The next thing that must be changed is called @referers. This controls basic access to your formmail script. You wouldn’t want the entire world pointing to your server, right? Let them get their own script and install it themselves. (Think of how much a spammer would enjoy having free access to your mail scripts to blanket the world with more unwanted mail.) On mine, I changed this value to (‘rit.edu’,’lawley.net’) so that I can run the script from any of my RIT accounts or my server.

The default @referers looks like this:
@referers = (‘scriptarchive.com’,’209.196.21.3’);

Yours should look like this:
@referers = (‘rit.edu’);

Now only web pages on rit.edu folks can call this script.

3) The third one, @recipients, is the most important one… This one will stop spammers or hackers from using your form to pollute the world with unwanted e-mail! We can set this one to hold either domain names or specific e-mail addresses that the form can send mail to. (For an exhaustive description, see the Read Me).

It’s important to realize that you need to add the domain of each e-mail address you want to send to (sub-domains need to be listed separately!)

Default: @recipients = &fill_recipients(@referers);
Yours: @recipients = &fill_recipients(‘rit.edu’,’it.rit.edu’);

Now you can have the form send E-Mail to either your RIT address or your FirstClass address! While you could add something like ‘hotmail.com’, that makes the script less secure. The most secure approach would be to use specific addresses rather than domains.

Finally, because it’s a cgi script, you’ll need to change the name of the script from formmail.pl to formmail.cgi to get it to work. You can rename the file in any number of ways including using the mv command in UNIX or renaming the file before you install it. (Remember – since it is a script it MUST have execute permissions!)

Test the script by loading it directly in a browser; http://www.rit.edu/~yourid/pathtoyourcgidir/formmail.cgi. You should see a box with the name of the program and a copyright statement; if you get an error, be sure to check (a) permissions on the directory and the script (should be 755), (b) line breaks on the perl file, © correct perl address in the first line, etc.

Part 2: Creating a Form to Use FormMail

Now you need to create a form to call the script. The form should be somewhere in your www directory tree (but not in the cgi directory, ideally). Set the method=”POST” and action=”http://www.rit.edu/~yourid/pathtoyourcgidir/formmail.cgi”

One field on your form should be named “recipient” and should have a value of an email address with a domain that is included in the referrers array of the script (e.g @rit.edu or @it.rit.edu)

Use the documentation (the Read Me file on the FormMail page) to determine what other reserved field names are used by the script, and see if you can use them appropriately and successfully in your mail form.

Make sure you upload the HTML page with the form to Grace before you test it; otherwise the script will reject it because it’s not on an approved “referrer” site.

Open your form in a browser, fill it out, and submit it. Check your email. Did you get the information? If not, go back through these steps and keep trying until you get it installed correctly. (Sometimes there’s a delay in receiving the mail.)

Dynamic Sites and CGI: First Exercise

We need to start this exercise by making sure that you are able to install and run simple CGI programs on Grace written in Perl.

Setup: Create a subdirectory in your ‘www/737’ directory on grace called “cgi”. Remember to set the permissions so that the web server can read and execute both the contents and the program files. (Example: chmod 755 first.cgi)

Create the Program File: Using a text editor type in the following program, exactly as it appears below:

#!/usr/local/bin/perl -w
#
# Very simple cgi script that produces a web page as output
#
#  Your name here 
#  4002-737 2/04
#

#print the http Response Header before the html document
print "Content-type: text/html\n\n";  #notice blank line

#start the web page
print "<html><head><TITLE>Generic CGI program</TITLE> </head>";
print "<body> <H1>Generic Web Page</H1> \n";
print "<HR>\n";
print "stuff goes here\n";
print "<HR>\n";

#print the end of the web page
print "</body> \n</html>\n";

#end of this program

Install the Program File: If you created it on your PC or Mac, now upload it to your cgi subdirectory. Make sure you transfer the file in “ASCII” or “Text” mode and not “binary.” Then login to grace and view the file using a Unix text editor (like pico or vi). Make sure it looks okay (are the line endings in the right place? are there strange characters? if there are problems, you may need to save it in a different format, or upload it differently…)

What should the output of this program be? (Describe it in your blog entry?)

Make sure you understand what the program is supposed to be doing, so you will recognize correct output when you see it.

Test the Program File: Now, run the program directly on Grace, by typing this command at the prompt:

perl first.cgi

If all goes well, your program should execute. If it doesn’t, track down and fix the syntax errors until it runs.

Capture the output: To more accurately simulate how the web server will execute your program, use redirection of output to capture the output of your program into a text file. Try running your program a slightly different way:

first.cgi > firstout.txt

Notice we don’t have to use the “Perl” command at the command line.

Examine the output to make sure it is formed correctly by viewing the file firstout.txt. If everything looks okay, keep going. If not, see if you can find the problem.

Question to answer in your blog entry: What precedes the html in your output? Why would that need to be there?

Now you are ready to see if the program can be run as a cgi program.

Note: on some systems the program must end in a .cgi suffix regardless of the language in which it was written, in order to run as a cgi program. Grace is one of them. Some servers also require that all cgi files be placed in a “cgi-bin” directory in your main web directory, but Grace does not require this; you can place .cgi files anywhere in your web directory.

Test your cgi program by loading it in a browser (http://www.rit.edu/~yourid/737/cgi/first.cgi).

Create Another CGI Program: If that works, create a second cgi program—call it second.cgi. This second program will not produce a web page. All that it will do is output an http response header to send the user to a new location. Not surprisingly, this uses a Location: header, and works much like a html refresh meta-tag. It tells the browser to request another document at another location. Have the program redirect to your 737 personal page. (http://www.rit.edu/~yourid/737/).

Here’s an example of a Location header:

Location: http://www.w3.org/pub/WWW/People.html

How would you output this? You use a print statement to output this type of header, of course. The header is for the browser and tells it to look elsewhere for a document. Remember to output a blank line after the header! There is no html output by this program and that means, you do not return content from your program (so what header don’t you need?).

Test the Second Program: Create an index.html file for your cgi directory, and include a link to both cgi programs. When a user clicks on the link to the second.cgi program, s/he should be redirected immediately to your main 737 page.

Question to answer on your blog: Is this a useful thing? Why bother?