[ ISG home page ] [ who we are ] [ send us email ] [ search ] [ FAQ ]

How to Set up a Home Page
on the EECS Instructional Computers

Home pages for individual students are not listed on the EECS Instructional WWW server, but students can contact the CSUA and ask to be added to their list.

Topics:

What is a "home page"?
How to Set up a Class Home Page; WEB services (for instructors)
How to Set up a Personal Home Page (for students)
HTML Code Sample: a Simple Homepage
How to "Publish" using an HTML Editor
Debugging Tips; Server Access and Error Logs
Updating your .htaccess files

Features: SSI, CGI, PHP, GD, sym links, redirect
Restricting Access to your WEB Site
Usage Policies for Information Servers
General References about WWW utilities
Apache HTTP Server Project Home Page
Apache Manual for this WWW Server

What is a "home page"?

A "home page" is a text document that may also contain references ("links") to other home pages and to text and graphics documents. It is generally a single page or the top level of a hierarchy of pages on a specific subject (such as you). The source text file for it may be browsed by selecting the "View Document Source..." option of your Web browser. The special features of a WWW home page are defined by simple HTML commands that are typed into the source text file.

How to Set up a Class Home Page (for instructors)

There are several WEB services for courses. Our recommendation to EECS instructors is:

create a course site on the EECS Inst server
use the EECS Inst site for posting public content
use the EECS Inst site for dynamic content (CGI, Wiki, etc)

In addition, if you wish to communicate on-line with the students and post password-protected content:

create a course site on bSpace
advise students to login to bSpace and join your bSpace course site
use the bSpace Discussion, Chat and Email tools for communicating with students (see bSpace presentation)
use the bSpace Resources tool for posting private content
use the bSpace Web Content tool to add a window to your EECS Inst site

For a summary of the course WEB services at UCB, see WEB services for courses below.

The EECS Instructional WEB server:

EECS Instructional Support manages computer accounts for EECS courses. These are known as instructor or master accounts. The instructor accounts on our UNIX computers store the files that are displayed via the EECS Instructional WEB server (http://inst.eecs.berkeley.edu).

To edit the WEB pages, instructors logon to an Instructional UNIX login server such as cory.eecs.berkeley.edu using SSH or putty, or at a workstation in an Instructional UNIX lab. (inst.eecs.berkeley.edu does not allow direct logins.)

We can use SSH keys to enable a person to login into the course account and the related WEB pages on UNIX with a private password. This is a useful feature for GSIs. This will allow the GSI to login or copy files there. The GSI can run the command ~kevinm/bin/sshkey-maker either on login.eecs (research UNIX server) or cory.eecs (instructional UNIX server). It emails the SSH public key to us, and we add the public key to the ~/.ssh/authorized_keys file in the course account.

Instructors and TAs may create a home page for a class, and we will add a reference to it from the list of courses on the Instructional WEB site. The site files can be editted by logging into the associated account on the Instructional UNIX computers (cory.eecs.berkeley.edu, etc) or by other publishing techniques. We encourage instructors to store their class WEB sites in the instructor's UNIX account. That makes the WEB site accessible via http://inst.eecs.berkeley.edu, and it means we'll retain the data on tapes for the future. We backup the contents daily and store the tapes for 1 year.

To login to the instructor account:

There are 3 possible ways to access the files in the instructor's UNIX account. Each uses a different password:

password to set or change it allows you to

SSH

create an SSH passphrase on your computer, send the public key to inst@eecs
OR, run ~kevinm/bin/sshkey-maker on login.eecs

login to an Instructional server using ssh, Putty, scp or WinSCP
use UNIX command-line editors (vi, emacs) or transfer files

UNIX "LDAP"

ask inst@eecs to set it
login to update.eecs.berkeley.edu (UNIX) to change it

login at Instructional UNIX workstations

login to the course WEB site (http://inst.eecs.berkeley.edu)

Windows

ask inst@eecs to set it
login and press CNTL-ALT-DEL to change it

login at Instructional Windows workstations

"share" the UNIX home directory from another account on an EECS Windows system by mapping a drive to the folder "\\mamba\{account-name}". (select "Connect using a different user name" and logon using the instructor account name)

We will reset the UNIX and Windows passwords for instructors so they can login to the account at a workstation in our labs as well as over the network (using 'ssh' from UNIX or 'putty' from Windows). You need this password to login to a course WEB site using the "Login..." buttons under http://inst.eecs.berkeley.edu.

Instructors and TAs can also use their own "SSH" passwords to login to the instructor account. (This password does not allow you to login at a workstation; you need the UNIX "LDAP" password for that.) You can generate an SSH public key and send it to us so we can install your SSH public key there.

To enable "SSH" logins from UNIX, you can use login.eecs (the UNIX server for EECS research accounts):
To enable "SSH" logins from Windows:

We will install it in the instructor account (using /share/b/adm/bin/sshkey-installer) and respond to you.

Please ask inst@eecs.berkeley.edu if you need help logging in.

Course WEB sites must meet several requirements:

Unattended course WEB sites from previous semesters should be depreciated so that they do not appear to be current information.
Instructors of other courses need to see the contents of the WEB site from previous semesters, to verify what the current students should have learned.
Homework and test solutions from previous semesters may need to be blocked by the current instructor.
The EECS CNIL faculty committee has requested that EECS Instruction support these requirements.

Course WEB sites have a specific UNIX directory structure:

To support these requirements, authors of course WEB sites should follow these practices:

The WEB pages for each semester should be installed in separate directories, ie
```
          the "Spring 2005" site goes in ~cs123/public_html/sp05
          the "Fall 2005"   site goes in ~cs123/public_html/fa05
```
The WEB files for each semester should be stored under public_html in a subdirectory that has a standard 4-char lowercase name such as fa04, su04 or sp05. (The definition is [fa|sp|su][0-9][0-9].) This is required for the automated maintenance of these sites.
The goal is that each semester site will be a self-contained and relocatable package, such as if it were tarred up and moved. So links to local files should be relative (ie './lec1.pdf') rather than absolute (ie not 'http://inst.eecs/~cs123/lec1.pdf')
public_html/index.html redirects to the current semester directory for the class. It is modified automatically by ISG.
public_html/archives.html is a record of the locations of WEB sites from previous semesters. It is modified automatically by ISG.

For example (click on the file names for samples):

    % cd ~cs164
    % ls -lad public_html public_html/*
    drwxr-xr-x   7 cs164    cs164   4096 Jul 13 16:16 public_html
    -rwxr-xr-x   1 cs164    cs164   1229 Jul  8 11:44 public_html/index.html
    -rwxr-xr-x   1 cs164    cs164   1205 Jul 13 16:07 public_html/archives.html
    drwxr-xr-x  11 cs164    cs164   4096 Jul 13 16:12 public_html/fa04
    drwxr-xr-x  12 cs164    cs164   4096 Jul 13 16:16 public_html/fa02
    drwxr-xr-x  14 cs164    cs164   4096 Jul 13 16:14 public_html/sp04
    drwxr-xr-x   9 cs164    cs164   4096 Jul  8 11:36 public_html/sp05
    drwxr-xr-x   2 cs164    cs164   4096 Jul  8 11:43 public_html/fa05
    -rwxr-xr-x   2 cs164    cs164   4096 Jul  8 11:43 public_html/fa05/index.html

If you have any files that are shared by different semesters, it is best to either copy them into each semester directory (if they aren't too big) or install them in a common directory and install a sym link to that from each semester directory, ie
```
    ~cs123/public_html/common
    ~cs123/public_html/sp05/common -> ../common
    ~cs123/public_html/fa05/common -> ../common
```
References would be relative, ie <a href='./common/lec1.pdf'>. That way, it will be clear in the future that these files were outside of the semester package, and the entire 'common' subdirectory could be copied into the semester directory to make it work again elsewhere.

A UNIX command for copying the previous semester WEB site:

    cp -rp ~cs123/public_html/sp05 ~cs123/public_html/fa05

and this UNIX command edits the file that redirects to it:

    (echo ':g/sp05/s//fa05/'; echo ':x') | edit ~cs123/public_html/index.html

If you don't want a previous semester site to be readable, just block access with 'chmod 700 sp05', etc. We can also set up password-controlled access to the previous sites. Please ask inst@inst.eecs for help if needed.
If your class WEB site is really somewhere else (not in the instructor's account on http://inst.eecs.berkeley.edu), you should still create a subdirectory for the semester, then install an index.html file in it that redirects to your alternate site. For example:
```
    ~cs123/public_html/fa05/index.html
```
could simply contain:
```
    <META HTTP-EQUIV='Refresh' CONTENT='0;URL=http://myserver.berkeley.edu/~mysite'>
```
This index.html will remain unchanged on the Instructional server in future semesters, so we will always have a reference to where the WEB site was located.

Permissions to class WEB sites:

      % chmod 711 ~/				# your top level home directory
      % chmod 711 ~/public_html 
      % chmod 711 ~/public_html/sp05
      % chmod 755 ~/public_html/index.html 
      % chmod 755 ~/public_html/sp05/index.html

allows everyone in the world

list the files in a directory:

      - run "chmod 755 directory-name" to set the read bit
      - do not put an "index.html" file in the directory

For directories, the "1"s in "711" set the execute ("x") bit but not the read ("r") bit. The "x" bit on a directory allows access to a specific file within the directory, but it does not allow a listing of all the files. By default, the WEB server looks for an "index.html" file and can read that under "711", but it can't list a directory that has permissions "711".

For ways to add security, please see Restricting Access to your WEB Site below.

Note that old WEB sites may contain homework solutions or other information that the current instructor may not wish to reveal. In that case, we recommend that the current instructor block access to the old WEB site with a UNIX command such as

      chmod 500 ~cs123/public_html/fa04

Adding links to Class newsgroups:

WEB link to the class newsgroup

<A HREF="news://news.berkeley.edu/ucb.class.cs152">CS152 Newsgroup</a>

CS152 Newsgroup

http://inst.eecs.berkeley.edu/connecting.html#news

Basic Class WEB page:

/share/b/pub/sample.class.html

inst@eecs.berkeley.edu

WEB services for courses:

There are several UCB WEB servers that EECS instructors can use to post course materials. Here is a summary.

EECS Instructional WEB server (http://inst.eecs.berkeley.edu)
The files are stored within the instructor's account on a UNIX server and can be editted from EECS UNIX and Windows computers. CGIs and directory-level access restrictions can be used. Files are backed up to tape and archived each semester. This site is listed under http://inst.eecs.berkeley.edu/classes-eecs.html, which is referenced from other WEB servers in EECS. Tech support is from the EECS Instructional staff (inst@eecs.berkleley.edu). See above for details.
We recommend that instructors use the EECS course WEB site for content that should be public, permanent and archived, and that they use bSpace (below) for on-line communication with the current group of students.
We also recommend that you list all WEB sites used by the course on the default home page on http://inst.eecs.berkeley.edu, so that there is a permanent record of where the content is for that semester.

EECS Seminar WEB sites (http://www.eecs.berkeley.edu/Scheduling/)
EECS administrative staff maintain 2 WEB sites that lead to the home pages for seminar classes (CS294, CS298, EE298):

http://www.eecs.berkeley.edu/Scheduling/CS/

http://www.eecs.berkeley.edu/Scheduling/EE/

Here is a summary of the EECS WEB pages that are related to courses (thank you, Maggie, for this):

Current and archived EECS course home pages hosted by the Instructional Support Group (inst@eecs). The individual course sites are maintained by profs and TAs: http://inst.eecs.berkeley.edu/classes-eecs.html

Overview of department curricula and links to EE and CS undergraduate, graduate, and professional course descriptions (from the UC General Catalog): http://sis.berkeley.edu/catalog/gcc_view_req?p_dept_cd=EECS

Class offerings for the current semester (generated by an EECS database): http://www.eecs.berkeley.edu/Scheduling/CS/schedule.html

Class offerings for next semester (database): http://www.eecs.berkeley.edu/Scheduling/CS/schedule-draft.html

Tentative class offerings for the coming semesters listed with possible instructors (database): http://www.eecs.berkeley.edu/Scheduling/CS/schedule-draft.html

bSpace (http://bspace.berkeley.edu)
bSpace is the UCB learning management system. It started in Spring 2006 and continues to gain new features. It integrates features from the former CourseWeb, Blackboard, WebCT and Library ERes services. bSpace is supported by the UCB Educational Technology Services (lsg-support@socrates.berkeley.edu, 642-2535, Training & Support).
All UCB students and staff can login to bSpace using their pre-existing CalNet ID. (non-UCB students, please see calnet.help for help.) Instructors who log onto bSpace are automatically associated with their current classes (by the Registrar) and are authorized to manage sites for their courses, using convenient bSpace tools. Available features include:

post syllabus, photo, office hours and contact information
link to additional course websites
view the names, photos, and enrollment status of students (BearFacts also has student photos)
send email to the students
group discussion and chat
grade submission and database
wiki
delegate some tasks to GSIs
bSpace sites do not support dynamic content (CGIs, etc)

After students login to bSpace, they can access ("join") any course site that has been "published" by the instructor (a site can be published to all bSpace users or to a selected set of bSpace users). Students login to their own bSpace workspace and then select a course site from the list of sites they have joined. The interactive bSpace features cannot be viewed by anyone without a valid CalNet ID.
To put a course site on the "joinable site" list on bSpace, go to "Course Tools->Site Info-> Manage Access->Publish Access".
To search for a course site on the "joinable site" list on bSpace, go to [search bSpace].
See above for ideas about which content is appropriate for bspace.berkeley.edu vs inst.eecs.berkeley.edu.
Create a world-readable reference on bSpace:
If you use bSpace, we recommend that you create a simple reference page there that is "publicly viewable". A "publicly viewable" site is listed in the bSpace searchable directory and can be accessed without logging in to bSpace. Then, include that URL in your course home page on the EECS Instructional WEB server (http://inst.eecs.berkeley.edu). This will create a permanent record of your use of bSpace that semester. On bSpace, "publicly viewable" is an option for Announcements, Resources, and Syllabus. The public URL to the bSpace page will be long and unmemorable, and it will change each semester. However, a user-friendly link from the EECS home page will avoid those problems. References:

to make a page public: http://bspacehelp.berkeley.edu/topics/resources/resources_10
to find the public URL: http://bspacehelp.berkeley.edu/topics/resources/resources_11

Bearfacts (http://bearfacts.berkeley.edu/)
This service is provided by the Registrar and IS&T. Instructors can access class enrollment lists, email addresses, student photos and e-Grade submissions. Instructors select Bear Facts for Faculty/Staff to login.

CalWeb (http://calweb.berkeley.edu/)
This service is provided by IS&T for a fee. There are several levels of WEB hosting services on UNIX and Windows servers that campus users can select.

CalShare (http://calshare.berkeley.edu/)
This service is provided by IS&T for a fee ($300 per 1-GB per year). It lets authorized users create, manage and build collaborative web sites and make them available to other users of CalShare. It is a UCB's implementation of Microsoft's SharePoint Technologies.

eTrain (http://dtsetrain.berkeley.edu/)
This service is provided by IS&T for a fee (please ask eTrainSupport@lists.berkeley.edu) and lets authorized users take standard Powerpoint presentations, add audio voice-over and publish them over the internet through any standard web browser.

Research Hub (https://hub.berkeley.edu/)
Research Hub provides tools for content management, collaboration, managing research data and sharing documents.

These are related WEB services that have been retired:

CourseWeb (http://courseweb.berkeley.edu)
CourseWeb was discontinued in January 2008. It was supported by IS&T (coursesites@socrates.berkeley.edu). CourseWeb contained a simple WEB page for each course that instructors could update with contact information and a syllabus. The page also included links to related WEB sites, including the course sites on the EECS Instructional WEB server. Prior to Spring 2008, a link to the CourseWeb site was included automatically the Online Schedule of Classes for each course. That link provided a path to the EECS course WEB sites. Now, there is no way to find a course WEB site from the Schedule of Classes.

Blackboard, WebCT
These Learning Management Systems were discontinued in Fall 2006 and have been replaced by bSpace. They were supported by the UCB Educational Technology Services ( lsg-support@socrates.berkeley.edu, 642-2535, Training & Support). EE20N and EE125 used WebCT.

UCB Library ERes Course WEB Page Service (http://sunsite.berkeley.edu/eres/)
This service was provided by the Library for posting course materials from their sources. The service and any materials that were posted there have been moved to bSpace.

Course Gallery
Course Gallery is no longer available. It was offered by the UCB Educational Technology Services (lsg-support@socrates.berkeley.edu) until about 2006.

WebFiles (http://webfiles.berkeley.edu/)
WebFiles was retired in June 2008. It was hosted by IS&T and provided 300MB of free online storage, file sharing, and web publishing for individual faculty, staff and students.

How to Set up a Personal Home Page (for students)

A home page can be stored in a student's home directory on the Instructional UNIX computers and it will be accessible through the Instructional WEB server. (inst.eecs.berkeley.edu).

You can't login directly to the Instructional WEB server, so you should login to an Instructional UNIX login server such as cory.eecs.berkeley.edu or to a UNIX workstation in one of our labs. Then these commands

mkdir ~/public_html echo '<HTML>My home page.</HTML>' > ~/public_html/index.html chmod 755 ~/public_html ~/public_html/index.html will create a simple home page that appears when you go to the URL

	http://inst.eecs.berkeley.edu/~your-username

(replace your-username with your own user name, of course).

See below for a more complete sample home page (formatted with HTML commands) that you could save as "index.html". The student's home directory, the "public_html" directory and the "index.html" file must all be world readable.

For example, for the user "jdoe" who has an Instructional account, this is how the directory and file permissions might look:

  % cd ~jdoe/public_html
  % ls -al
  drwx--x--x  2 jdoe   512 Feb  2 10:38 ./
  drwxr-x--x 42 jdoe  2560 Feb  2 10:37 ../
  -rwxr--x-x  1 jdoe  2221 Feb  2 10:37 index.html

You can set the permsssions that way with these UNIX commands:

  % chmod 711 ~jdoe 
  % chmod 711 ~jdoe/public_html
  % chmod 755 ~jdoe/public_html/index.html

You can set the permsssions for all files and directories under the "jdoe" public_html directory with these UNIX commands:

  % find ~jdoe/public_html -type d -exec chmod 711 {} \;
  % find ~jdoe/public_html -type f -exec chmod 755 {} \;

This will allow everyone in the world to read those files, including people who are using a WEB browser and who are logged into any Instructional computer. For ways to add security, see Restricting Access to your WEB Site below.

The URL to access the home page would be:

  http://inst.EECS.Berkeley.EDU/~jdoe

That URL can be used from any WWW client, such as Firefox, Internet Explorer and Lynx. Note that the EECS Instructional home page will not include references to individual student home pages, but students can request that service from the CSUA.

If you want users to be able to list a directory:

  - run "chmod 755 directory-name" to set the read bit
  - do not put an "index.html" file in the directory

Note that the "1"s in "711" set the execute ("x") bit on the directories but not the read ("r") bit. The "x" bit on a directory does not allow a listing, but it does allow access to a specific file within the directory. By default, the WEB server looks for an "index.html" file and can read that under "711", but it can't list the directory if there is no "index.html" file.

HTML Code Sample: index.html for a Class WEB Page

This is a simple WEB page that can be editted with text editor such as "vi" or "emacs". This file redirects to the current WEB page for the class.

Set the file permsssions with these UNIX commands:

  % chmod 711 ~/				# your top level home directory
  % chmod 711 ~/public_html
  % chmod 755 ~/public_html/index.html

The timer before jumping is set by the "0" in this line:

HTML Code Sample: archives.html for a Class WEB Page

This file is maintained automatically by a script. It has a list of previous class WEB sites for the class.

Set the file permsssions with this UNIX command:

  % chmod 755 ~/public_html/archives.html

HTML Code Sample: a Simple Homepage

You can create a simple homepage by using a UNIX text editor (such as "vi" or "emacs") to enter this HTML code and save it to a file called "index.html" in the "public_html" subdirectory of your home directory:

<HTML> <HEAD> <TITLE>My Home Page</TITLE> <CENTER> <H1>Welcome to <I>My</I> Home Page</H1> </CENTER> </HEAD> <BODY> <P> Here is some text about me. </BODY> </HTML>

Set the file permsssions with these UNIX commands:

  % chmod 711 ~/				# your top level home directory
  % chmod 711 ~/public_html
  % chmod 755 ~/public_html/index.html

The http://inst.eecs.berkeley.edu WEB server will display that file using the URL http://inst.eecs.berkeley.edu/~yourlogin.

You can see examples of other people's HTML code by selecting the "Page Source" option that is available in most WEB browsers. Many people use a graphical WEB page editor such as Netscape Composer or Microsoft FrontPage (see Publishing, below), but there is no shame in coding it by hand!

How to "Publish" using an HTML Editor

Your WEB site files are under the "public_html" directory in your UNIX home directory. Your file called "public_html/index.html" is your default home page on our WWW server (http://inst.eecs.berkeley.edu).

There are 3 ways create and update you WEB pages: edit on UNIX, edit on Windows and file transfer:

Edit on UNIX:
Login directly to an Instructional UNIX system (such as "cory.eecs.berkeley.edu") and edit the HTML files in public_html with a text editor (such as 'emacs' or 'vi').
You can view your changes via a WEB browser.
Edit on Windows:
From an Windows system in the EECS Windows domain, you can connect to your UNIX home directory and edit the files as if they were local files on your Windows system. If your UNIX account is called "cs123" you would:
```
     1) Disconnect from any drives on Mamba if you have them
     2) Open the Start\Run dialog box and type
	net use X: "\\mamba\cs123" /persistent:no /user:EECS\cs123
```
You'll be asked for the cs123 UNIX password. Once the directory window pops up, you'll be able to access the files there on the X: drive, and the "cs123" WEB page would be X:\public_html\index.html. If you are on Windows, this seems like the easiest in way to "publish" to the WEB.
You do need to know which file server your home directory is on. The only choice for Instructional accounts is "mamba". We are running Samba to emulate the Windows filesystem on this UNIX server.
File transfer:
Another way is to edit the HTML files at your local computer and explicitly save the files on your local disk. Then use a secure ftp to copy them into the public_html directory in your Instructional UNIX account. You can logon to one of our UNIX computers (such as cory.eecs.berkeley.edu) using

rsync on UNIX and MacOSX. "rsync" is generally included in the operating system. We recommend the rsych options "-azH", for example:
scp on UNIX and MacOSX. "scp" is generally included in the operating system.
WinSCP on Windows. You can download this program from download-ssh.html.

Insecure FTP is not allowed: UNIX and MS Windows systems typically have the traditional "ftp" command that is insecure becuase it transmits your password in unencrypted, clear-text format. The Exceed package on MS Windows has a graphical version of this. Campus security rules prohibit the use of this ftp. This insecure version of ftp uses network port 21, and campus computers deny the use of hat port.

Debugging Tips

If you are getting an error message from a WEB page or CGI program that you are displaying via http://inst.eecs.berkeley.edu, you may find clues about the problem by searching for either your login name, the WEB page name or the program name in the Server Access and Error Logs.

Here are some common errror conditions and solutions:

"Internal Server Error" error

Login to a server such as torus.cs.berkeley.edu (a Solaris X86 system that is like inst.eecs) and run the CGI program on the UNIX command line. If you get an error, there may be a bug in your CGI (typically Perl) code.

If you created or copied your file on a Microsoft Windows system, the file may have newlines or other characters that don't work on UNIX. You can convert the Windows file to UNIX format with the UNIX command (for example):


  dos2unix windows-file.cgi unix-file.cgi

Next, you can redirect the output to a file with commands such as


    ./unix-file.cgi >! test.html

    chmod 644 test.html

and then read the "test.html" file as a URL via http://inst.eecs. If that file fails, then there is probably a bug in your HTML text output.

Finally, if your CGI is in Perl, you can get the WEB server to pass the real error message to the screen from your CGI program by using the "CGI" Perl module. Put these CGI lines at the start of your Perl program:


    use CGI; 

    use CGI::Carp 'fatalsToBrowser';    # echo fatal error messages to browser

See http://search.cpan.org/author/JHI/perl-5.8.0/lib/CGI.pm for documentation about the Perl CGI module.

"Premature end of script headers:" error

Be sure that the permissions on your CGI program and all directories above it are set with


     chmod go+rx,go-w file_name

     chmod go+x,go-w directory_name

That is readable and executable by the group and all other users but writable *only* by the owner. The restriction that it can't be group or world writable is a security feature of the Apache server. See Restricting Access to your WEB Site if you would like to set more restrictive permissions.

Also be sure that the owner of the HTML file or CGI program is the same as the owner of the WEB site. For example, in the URL http://inst.eecs.berkeley.edu/~jdoe/test.html, the file "test.html" must be owned by user "jdoe". This restriction is also a security feature of the Apache server.

Updating your .htaccess files

The inst.eecs.berkeley.edu WEB server was updated in January 2011 with a new version of the "modauth" module, which handles access control via .htaccess files. As a result, you may need to update your .htaccess files.

The new version of Apache (2.2.17) changes some of the directives that are used in .htaccess files that control access to WEB sites. The changes are that the "AuthBasicProvider" line should be added and the "AuthDBMAuthoritative" line should be removed.

Here is a typical updated .htaccess file:

	SSLRequireSSL
	AuthName "An authorized account is required..."
	AuthType Basic
	AuthBasicProvider dbm file		
	AuthDBMType GDBM
	AuthDBMUserFile  /pool/www/data/master-access
	AuthDBMGroupFile /pool/www/data/master-access
	#AuthDBMAuthoritative off			# this line is obsolete
	AuthUserFile  /home/ff/cs123/public_html/login/SSL/users
	AuthGroupFile /home/ff/cs123/public_html/login/SSL/groups
	Require group allow

The *UserFile and *GroupFile lines define what sources will be searched to authenticate the users.

The "master-access" DBM file contains the users and groups from the Instructional UNIX systems.

The files "users" and "groups" are files that you can create with login/password matches of your own invention. You can locate these files anywhere under your own public_html directory. Include the full path to them after the AuthUserFile and AuthGroupFile directives.

The Require line defines which users within those sources will be accepted. In the Require line:

	"valid" = all UNIX accounts (taken from the dbm password service)
	"allow" = a group of users that may be listed in the "groups" file

Please see http://inst.eecs.berkeley.edu/setup.html#restrict for more information about using .htaccess files.

If you find an error on one of your WEB pages, please send email to inst@eecs.berkeley.edu with the URL of that page and a description of the content that is incorrect. Thank you.

Features of this WWW Server

Home pages:

Any user with an account on the EECS Instructional UNIX systems can display WWW documents through the

EECS Instructional WWW server

How to Set up a Personal Home Page

Server-side "includes" (SSI):

EECS Instructional WWW server

To enable the "include" directive, the html file must have world-executable permissions. The UNIX command "chmod 755 *.html" will set those permissions on all files ending in "html" in the current directory. The UNIX command "/share/b/bin/fix-html" (on the Instructional systems) will update your entire Instructional WEB site with these permissions.

For example, if you have the files "index.html", "header.html" and "hello.cgi" in your public_html directory and you wish to include the html code from "header.html" and from "hello.cgi" in your "index.html" file, enter these lines in "index.html":

and make "index.html" (and "hello.cgi") executable with the commnd:

  % chmod 755 ~/public_html/index.html ~/public_html/hello.cgi

PHP:

PHP

http://inst.eecs.berkeley.edu/php/

PHP commands can be run in 2 ways through the http://inst.eecs.berkeley.edu server:

Embedded into HTML: PHP commands embedded in an HTML document use the PHP Apache module and run with the permissions of the WEB server, which is the unprivileged 'nobody' account. In this method, the filename must end in ".php", and HTML "include" directives do not work. The embedded PHP commands only have permission to perform operations that can be done by 'nobody' (such as when reading or writing files).
To see the options that are configured into the PHP Apache module, go to: http://inst.eecs.berkeley.edu/~inst/php-info.php
In a CGI: CGI programs are run by the WEB server 'suexec' module, which causes them to run with the permission of the owner of the WEB site. In this method, the filename must end in ".cgi", must be world-executable and starts with the line
```
	#!/usr/local/bin/php 
```
It will invoke the 'suexec' module, and the commands in the CGI program will have permission to perform any operations that you are allowed to do (such as reading and writing files that are only accessible by you). For an example, run: http://inst.eecs.berkeley.edu/~inst/php-suexec.cgi
You cannot login directly to the inst.eecs WEB server, but you can test your /usr/local/bin/php programs on pentagon.cs, which is configured the same as on inst.eecs.
To see the options that are configured into the local PHP progam, see /usr/local/lib/php.ini.

http://www.php.net

	"MySQL Functions" (includes mysql_connect, mysql_open, etc)
	"MySQL Functions (PDO_MYSQL)" (for MySQL v4.1.3 and above)
	"MySQL Improved Extensions" (for MySQL v4.1.3 and above)

Only the CGI method has permission to write a file into your home directory. The PHP source code for the 2 examples can be read from an Instructional UNIX account at:

	~inst/public_html/php-info.php
	~inst/public_html/php-suexec.cgi

[thanks to Prof Hilfinger for this]

GD:

For basic instructions, see http://www.boutell.com/gd/manual2.0.11.html#basics
For more information, see http://www.boutell.com/gd/.

CGI scripts:

Users may run their own CGI programs through the inst.eecs.berkeley.edu server. SSI (server-side includes) and "exec cgi" are enabled. Here are the rules that a CGI program must follow on our server:

The program name must end in ".cgi".

It can be located anywhere under your public_html/ directory.

Its user and group ownership must match that of the owner of the WEB site (you).

The permissions on the program and all the directories above the program must be world-executable (for a way around that, see Restricting Access to your WEB Site below).
It must generate proper HMTL code, in which the first line starts with 'Content-type:' and the second line is blank.
It must run on the WEB server inst.eecs.berkeley.edu, which runs the Solaris X86 operating system. See /share/b/bin/clients for a list of servers that you can login to that have the same opating system.

For Perl and shell scripts, be sure the command on the first line exists on the WEB server. These are the most likely choices:

Perl scripts will generally run the same on the different UNIX operating systems, but compiled programs (such as in C++) will not.

CGI example:
Here is an example of simple CGI script called hello.cgi, written in the csh shell and in Perl:

#!/bin/csh

echo "Content-type: text/html"
echo ""
echo ""
echo "Hello World."
echo ""

#!/usr/sww/bin/perl

print "Content-type: text/html\n\n";
print "\nHello World.\n\n";

Here are the UNIX commands to enable this script, located in the public_html/ directory of the user "jdoe":

  % cd ~jdoe/public_html
  % chmod 755 hello.cgi
  % chown jdoe hello.cgi
  % ls -al hello.cgi
  -rwxr-xr-x   1 jdoe users   7682 Dec  1 10:10 hello.cgi

The URL to reach this CGI would be: http://inst.eecs.berkeley.edu/~jdoe/hello.cgi

Also, you can execute that CGI program from within an html file by inserting the line:

<!--#exec cgi="hello.cgi"-->

Processing forms with CGI scripts:
You can display a form on your WEB site and pass the user's data to a CGI program. Here is an example of an HTML form and CGI program.

Security with CGI scripts:

As a security precaution, Apache denies access to any directories or executable WEB files that are group-writable or world-writable (see http://inst.eecs.berkeley.edu/manual/suexec.html).
The script will only have access to files that the owner can access, and the owner must take care that there are no security risks in the script.
A user's CGI program may not violate any of the rules of usage, such as by allowing other users to run programs or access files on the Instructional computers.

Debugging CGI scripts:
You cannot login directly to the inst.eecs.berkeley.edu WEB server, so if you need to debug a problem with a CGI program:

Look in error log files ( http://inst.eecs.berkeley.edu/logs) for references to your URL.
Test the program on a computer that runs the same operating system as the WEB server. inst.eecs.berkeley.edu is running Solaris X86. See /share/b/bin/clients for a list of servers that you can login to that have the same operating system. If your program can function as a stand-alone program, then it should also function through the UNIX WEB server. It has to produce valid html output, of course, in order for the WEB server to interpret it.
If you are writing your scripts in Perl, please use /usr/sww/bin/perl, so it is the same version that you are using where you are testing it.

The CGI program will run with the permissions of the owner of the account through which it is accessed. All the files that the WEB server reads or runs must be world-readable or world-executable, since the WEB server runs as a generic unprivileged user. For a way to prevent local users from reading your WEB files, see Restricting Access to your WEB Site below.

There are security risks in running CGI scripts. For example, there was a security advisory for a guestbook CGI script about a hole that will allow anyone to run any command in your account as you. (You can prevent that by not allowing people to enter HTML messages, by turning off $allow_html in the script.)

Symbolic links:

This server will only follow symbolic links to UNIX files that are owned by the owner of the sym link.

Redirecting WEB pages:

Use a META refresh command in your index.html file, for example:

  <HTML>
  <META HTTP-EQUIV="Refresh" CONTENT="5;url=https://inst.eecs.berkeley.edu/~inst/SSLonly/index.html">
  <HTML>
  This site will jump to a new site in 5 seconds.

A benefit of this method is to display a timed message, warning people to update their bookmarks, etc.

Use a rewrite rule in your .htaccess file, for example:
```
  RewriteEngine On
  RewriteBase   /~inst
  RewriteRule   ^(.*)      http://foo.com/~bar/$1      [R,L] =permanent 
```
This would rewrite any URL such as http://inst.eecs/~inst/somefile.html to be http://foo.com/~bar/somefile.html, regardless of what the "somefile.html" part of the URL is. This means that users can type any URL within your site and get through, which is not true with the META refresh method.
More info on this is in the Apache docs under mod_rewrite.

Restricting Access to your WEB Site

You can restrict the access to files in your WEB site:

by computer (list the authorized computers in .htaccess)
by user (list the users and passwords in .htpasswd)
by file permission (use a CGI program to access files that are not world-readable)
by SSL (use the SSLRequireSSL directive in .htaccess; can also use .htpasswd)

These methods are described below.

For more information about adding access control individual subdirectories, please see

http://inst.eecs.berkeley.edu/manual/howto/auth.html

http://inst.eecs.berkeley.edu/manual/howto/htaccess.html

Allow access only to certain computers:

.htaccess

Here is an example of UNIX commands to control access by computer to all the files in a directory called "restricted". Access is resricted to the CS and EECS subnets and a single computer on the HIP subnet (136.152.91). A computer called "transcend.cs" is also excluded.

UNIX command Purpose

1.
mkdir ~/public_html/restricted
create the subdirectory

2.
cat > ~/public_html/restricted/.htaccess << EOF <Limit GET> order allow,deny allow from cs.berkeley.edu eecs.berkeley.edu 136.152.91.1 deny from transcend.cs.berkeley.edu </Limit> EOF
create the .htaccess file

3.
chmod ugo=x,u+rw ~/public_html/restricted chmod ugo=r,u+rw ~/public_html/restricted/.htaccess
cd ~/public_html ls -lad restricted drwx--x--x 2 mylogin mygroup 5120 Feb 13 17:06 restricted
cd ~/public_html/restricted ls -la .htaccess -rw-r--r-- 2 mylogin mygroup 5120 Feb 13 17:06 .htaccess
set permissions, check the results

Access to all files in the "restricted" directory will be limited to the entries in .htaccess. Files in the directory should be readable by everyone on the local computer. For example, for a file called "private.html" in the ~/public_html/restricted directory, set the permissions using:

chmod ugo=rx,u+w ~/public_html/restricted/private.html

Allow access only to certain people:

You can add password protection to a WEB site by creating a file called

.htpasswd

Here is an example of UNIX commands to set up access controlled by password to all the files in a directory called "restricted".

UNIX command: Purpose

1.
mkdir ~/public_html/restricted
create the subdirectory

2.
/share/b/bin/passwd2crypt
create an encrypted password

3.
cat > ~/public_html/restricted/.htpasswd << EOF user1:{encrypted_passwd} user2:{encrypted_passwd} EOF OR go to our .htpasswd File Generator
create the .htpasswd file

4.
cat > ~/public_html/restricted/.htaccess << EOF AuthType Basic AuthName "My Restricted WEB site" AuthUserFile /{full path to your home dir}/public_html/restricted/.htpasswd Require valid-user EOF
create the .htaccess file

5.
chmod ugo=x,u+rw ~/public_html/restricted chmod ugo=r,u+rw ~/public_html/restricted/.htaccess chmod ugo=r,u+rw ~/public_html/restricted/.htpasswd
cd ~/public_html ls -lad restricted drwx--x--x 2 mylogin mygroup 5120 Feb 13 17:06 restricted
cd ~/public_html/restricted ls -la .htaccess .htpasswd -rw-r--r-- 2 mylogin mygroup 5120 Feb 13 17:06 .htaccess -rw-r--r-- 2 mylogin mygroup 5120 Feb 13 17:06 .htpasswd
set permissions, check the results

The {encrypted_passwd} can be generated using the program /share/b/bin/passwd2crypt (on the Instructional UNIX systems) or our .htpasswd File Generator.

WEB browser users will be prompted for a password if they access the directory, and only the users listed in .htpasswd will be able to read any of the files in the directory.

Note that, to allow the Web server to read your files, the files in ~/public_html/restricted will be readable by anyone on any computer that can access your home directory. This is true for all of your WWW-accessible files. For a way around this, see below, Using a CGI script to restrict access by UNIX file permissions.

Limitations of using .htaccess and .htpasswd files:

.htaccess and .htpasswd must be world readable, or the WEB server will not be able to read them and will restrict the directory to everyone. The Instructional WEB server runs as an unprivileged user.

Your ~/public_html directory and all files under it must be world-readable for the Instructional WEB server to be able to read them. This means that files that you restrict for access via the WEB may still be readable by everyone who can login to the Instructional computers. For a way around this, see below, Using a CGI script to restrict access by UNIX file permissions.
If there is an error in your .htaccess or .htpasswd, then access to your webpage may be prevented until the error is corrected.
.htaccess and .htpasswd restrict the directory they are located in, and all subdirectories under that. This means that if you have a broken .htaccess or .htpasswd file and you move it from your public_html directory to your home directory, your webpage will still be unviewable.

Using a CGI script to restrict access by UNIX file permissions:

A CGI script can be used to allow the WEB server to read files that are not world-readable. Our WEB server runs CGI programs with the permissions of the user (ie ~user), so the CGI program can read and write to files that are read/writable only by the user.

We have developed a CGI program called restrict_dir.cgi that allows you to give WEB access for selected users to files that are not world-readable. See /~inst/restrict_demo/ for a demonstration. Please ask inst@inst.eecs.berkeley.edu for help with that if needed.
We have another CGI program called peruser.cgi that prompts for a login and password, then displays a file that is specific to that user. A copy of this CGI package can be copied from ~inst/public_html/peruser.tar. Please ask inst@inst.eecs.berkeley.edu for help with that if needed.
You can use an HTML redirect command (in a world-readable file) to run a CGI program (read/writable only by the user) that reads and writes to other files (also read/writable only by the user). The CGI program would generate the HTML pages and forms, process any input and display any output desired. Here is an example of an index.html file that redirects to a CGI program in the same subdirectory: <HTML> <META HTTP-EQUIV="Refresh" CONTENT="0;url=maybePERL.cgi"> <HEAD> <TITLE>Auto-Redirect to My CGI program (maybePERL.cgi)</TITLE> </HEAD> </HTML> Assuming the CGI program wants to display or write to a file called file1.txt, here are the UNIX commands to set the permissions on all these files:
```
	chmod 755 index.html	(executable, so WEB server can run 'include's)
	chmod 700 maybePERL.cgi	(only readable/executable by the owner)
	chmod 600 file1.txt	(only readable/writeable by the owner)
```
This will allow users to read the files through your WEB site, and you can limit them by prompting for a password from your CGI program. But users who are logged in directly onto our UNIX computers (such as cory.eecs) will not be able to read the files.

Security using SSL:

When using .htpasswd, passwords typed over the network are in clear-text and are vulnerable to password sniffing over the net. We have installed a WEB server that uses SSL encryption and authentication, and this protects the passwords and other data that is transfered between the server and your browser.

The server is https://inst.eecs.berkeley.edu.

SSL is a method of software ecryption that protects data tranfered over the network between your WEB browser and a WEB server. Not all WEB browsers and servers are enabled for SSL. You will know if your browser is connected securely via SSL if the little picture of the padlock on the frame of you browser turns yellow and shows a locked padlock.

You can ensure that a WEB page of yours is accessed only through our SSL-enabled server by adding this on a line in .htaccess:

	SSLRequireSSL

Users who try to access any files in that directory through one of our non-SSL unabled servers will get an "access denied" error.

Finally, the best security is to require access using password that is safely encrypted through our SSL-enabled server. Here is a sample .htaccess file for that:
```
	AuthType Basic
	AuthName "access is restricted to users on my list using SSL"
	AuthUserFile  /home/aa/staff/inst/public_html/restrict_demo/.htpasswd
	Require valid-user
	SSLRequireSSL 
```
The last 2 lines make it ask for a password and require an SSL browser.
Instructions for creating the .htpasswd are in the
Allow access only to certain people section, above.
Our /~inst/restrict_demo/ WEB site is a sample of restricting a directory by SSL-encrypted local password and also by file permission, so that it can only be read via the WEB and not even while logged in locally on our UNIX systems. It uses an .htaccess file that enforces SSL encryption and prompts for a username/password either from our local UNIX password file or from an additional username/password list that you can create. Then a CGI program allows access a subdirectory that cannot be read any other way.

Usage Policies for Information Servers

"Informed Consent" Required for Displaying Student Identities

Information that you display publically via University computers may not include the names of a student without an "informed consent" from the student. Restricting access to WEB pages, say to the EECs or BERKELEY.EDU domains, is not sufficient: informed consent is still required. This is a requirement by federal law. An example of "informed consent" is:

"I, (student name), consent to have my name posted on (webpage title & url), a paper copy template of which is attached to this consent form. My name may be posted on this webpage from (date) to (date). I understand that my consent to have my name posted on this webpage is not a condition of my participation in (name of the class), nor will it be used as a basis for grading my performance therein."

Please refer to the Policy Analysts at the Office of the Registrar, 127 Sproul Hall, for further clarification about the requirement for "informed consent".

Other topics:

General References about WWW utilities

These are public documents that have more about the WWW and the HTML language used in writing home pages (these may not always be available):

Web Design with Style, Ease, and CSS

about the World Wide Web

UNICODE character charts

UNICODE character converter

The CGI Resource Index

Security Issues in Perl Scripts

CSS: Button Stylesheet Wizard

HTML Hexadecimal Color Chart

HTML in every language

W3C Guide to Style sheets [Tips & Tricks]

Last modified: Wednesday, April 25, 2012
inst@eecs.berkeley.edu

	UNIX command	Purpose
1.	mkdir ~/public_html/restricted	create the subdirectory
2.	cat > ~/public_html/restricted/.htaccess << EOF <Limit GET> order allow,deny allow from cs.berkeley.edu eecs.berkeley.edu 136.152.91.1 deny from transcend.cs.berkeley.edu </Limit> EOF	create the .htaccess file
3.	chmod ugo=x,u+rw ~/public_html/restricted chmod ugo=r,u+rw ~/public_html/restricted/.htaccess cd ~/public_html ls -lad restricted drwx--x--x 2 mylogin mygroup 5120 Feb 13 17:06 restricted cd ~/public_html/restricted ls -la .htaccess -rw-r--r-- 2 mylogin mygroup 5120 Feb 13 17:06 .htaccess	set permissions, check the results

	UNIX command:	Purpose
1.	mkdir ~/public_html/restricted	create the subdirectory
2.	/share/b/bin/passwd2crypt	create an encrypted password
3.	cat > ~/public_html/restricted/.htpasswd << EOF user1:{encrypted_passwd} user2:{encrypted_passwd} EOF OR go to our .htpasswd File Generator	create the .htpasswd file
4.	cat > ~/public_html/restricted/.htaccess << EOF AuthType Basic AuthName "My Restricted WEB site" AuthUserFile /{full path to your home dir}/public_html/restricted/.htpasswd Require valid-user EOF	create the .htaccess file
5.	chmod ugo=x,u+rw ~/public_html/restricted chmod ugo=r,u+rw ~/public_html/restricted/.htaccess chmod ugo=r,u+rw ~/public_html/restricted/.htpasswd cd ~/public_html ls -lad restricted drwx--x--x 2 mylogin mygroup 5120 Feb 13 17:06 restricted cd ~/public_html/restricted ls -la .htaccess .htpasswd -rw-r--r-- 2 mylogin mygroup 5120 Feb 13 17:06 .htaccess -rw-r--r-- 2 mylogin mygroup 5120 Feb 13 17:06 .htpasswd	set permissions, check the results

How to Set up a Home Page on the EECS Instructional Computers