Installing Movable Type: Studio Exercise ( 1 December 2004)
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.) The easiest way to create the file is to use the "touch" command.
3) You're going to need three directories--one in your home directory to hold the database files, one in your www directory for the movable type program files, and another one in your www directory for the publicly-viewable blog files. 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) Go to the Movable Type site and click on the "free download" button. Download the full version of the software in .zip format.
5) Upload the .zip file to your www directory on grace, and decompress it using the unzip command. Rename the resulting directory as mt, and change the permissions for the directory and all of its contents to 755 (chmod -R 755 mt)
6) Edit the mt.cfg file using pico or vi. (More detailed information on the configuration file can be found in the Movable Type installation documentation, on their web site. This is an abbreviated version of the instructions specifically for the RIT web server.)
- 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
7) 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.
8) 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".)
9) Choose "Manage Weblog" for the default weblog that was created, and then select "Weblog Config" from the menu on the left.
10) On the first config screen, 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.
11) Now choose "Rebuild Site" from the menu at the left, and click Rebuild to save all the html files your weblog to the specified directory. Test it by clicking on the "View Site" button at the top of the screen.
CSS and Typography: Studio Exercise ( 8 December 2004)
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.
Visual Design: Studio Exercise (15 December 2004)
Using what you know about web design and color, redesign an IT faculty member's main web page.
If you use me, you can use the photo on my main web page, or this one.
If you use another faculty member, use the photo from the main web page.
CSS Positioning: Studio Exercise (15 December 2004)
Using the recipe example I showed in class, create your own page with CSS positioning and formatting. You can change as much or as little of the original as you'd like, but make sure that you've got a good sense of how the positioning properties work.
When you're done, upload the file to your rit.edu web space on Grace, and add a weblog entry that points to it and describes what you changed and anything important you'd like to remember about how you created the page. If you don't already have a category for in-class exercises, make sure you add one to your weblog, and assign it to this entry.
Assessing Accessibility: Studio Exercise (12 January 2005)
Use Cynthia Says to evaluate at least two of your own web pages (with at least one of those being on your Grace account). If the server is refuses to accept any more URLs from rit.edu, review a page that you visit frequently. Make note of all of the priority 1, 2, and 3 problems identified.
If you reviewed your own web page, 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.)
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 problems you found on your site. Which problems were you able to fix? Were there any you couldn't? (If you weren't able to test your site in class, do this before Thursday.)
Accessibility Simulations: In-Class Exercise (12 January 2005)
If you have headphones with you, complete the tasks on WebAIM's Screen Simulator. If you don't have headphones, do this exercise outside of class; it's a valuable experience.
Go to the Cognitive Simulator on the same site, and complete those tasks as well.
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.
Javascript and the DOM: Studio Exercise (17 January 2005)
Work through the BrainJar.com tutorials on Introduction to the DOM and The DOM Event Model.
Create example web pages that use the techniques explained in these pages, and create an entry in your weblog that points to the examples. (You can also embed the examples in your weblog entry, if you'd prefer.)
Files and Links for Javascript Exercises (19 January 2005)
Here's a zipped archive of the files for today.
As a reminder, I asked you to put up your own versions of example 1, modify example 5 to use a switch statement and include a mouseout command for the graphics, and create your own drop down navigational menu using the simple menu from example 6.
These sites may be helpful, as well:
DHTML: Studio Exercise (26 January 2005)
In class, we'll be working through the "Revenge of the Menu Bar" DHTML tutorial on BrainJar. This is one of a number of excellent tutorials on the site.
As your CSS becomes more complex, you may find this CSS Selectors guide useful. There's also this CSS Hacks page.
I've also linked to a number of DHTML and Javascript resources over on del.icio.us.
Server-Side Authentication: Studio Exercise ( 2 February 2005)
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 youve never created a password file before:
1. Create a directory in your home directory (not your www directory) to put the password file in.
1. Change the permissions on the directory you just created to 755
1. 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
1. 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.
1. 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:
AuthUserFile /users/ritX/gX/yourid/pw_file_directory/pw_file_name AuthGroupFile /dev/null AuthName Whatever_You_Want AuthType basic require user username username2
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:
AuthDCE On AuthType Basic AuthName dce require valid-user
To limit access to only specific DCE user(s), use the following .htaccess syntax:
AuthDCE On AuthType Basic AuthName dce require user dceid1 dceid2
Server-Side Includes: Studio Exercise ( 2 February 2005)
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 (or some other fragment of text) taken from an external file in another directory.
Dynamic Sites & Basic CGI: Studio Exercise ( 9 February 2005)
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/409' 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:
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.cgiIf 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/409/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 409 personal page. (http://www.rit.edu/~yourid/409/).
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 409 page.
Question to answer on your blog: Is this a useful thing? Why bother?
Modifying CGI Scripts: FormMail Exercise ( 9 February 2005)
In this exercise, you're going to 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:
First, 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';
The second 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.
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, (c) 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.)