Topics:
There are several WEB services for courses. Our recommendation to EECS instructors is:
In addition, if you wish to communicate on-line with the students and post password-protected content:
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 course instructors.
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 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 on login.eecs (research UNIX server) or ~inst/bin/sshkey-maker on 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 edited by
logging into the associated account on the
Instructional UNIX computers ( 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:
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 (located at https://inst.eecs.berkeley.edu/~COURSE/login, where COURSE is "cs123" or etc). 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.
We will install it in the instructor account (using
Please ask inst@eecs.berkeley.edu if you need help logging in. Course WEB sites must meet several requirements:
Course WEB sites have a specific UNIX directory structure: To support these requirements, authors of course WEB sites should follow these practices:
You typically set the permissions with these UNIX commands, for example:
% 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
This allows everyone in the world to read those files, including
people who are using a WEB browser and those who are simply logged into
an Instructional computer. If you want users to be able to 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: You can include a WEB link to the class newsgroup with this HTML code (using "cs152" as an example):
Basic Class WEB page:
/share/b/pub/sample.class.html
is an HTML file that may be used as a template for a new home page.
Please notify the Instructional Group
(inst@eecs.berkeley.edu)
if you have a new class home page that you would like us to install.
|
There are several UCB WEB servers that EECS instructors can use to post course materials. Here is a summary.
| EECS Instructional WEB sites |
(http://inst.eecs.berkeley.edu/classes-eecs.html)
All EECS courses have a default WEB site on the EECS instructional WEB server. The files are stored within the instructor's UNIX account. The contents are authored and maintained by the profs and TAs. CGIs and directory-level access restrictions can be used. Files are backed up to tape and archived each semester. Tech support is from the EECS Instructional IT staff (inst@eecs.berkleley.edu). See above for details. Here is an example of a course WEB page (for a non-existent class): inst.eecs.berkeley.edu/~cs123. We recommend that instructors:
|
| EECS Scheduling WEB sites |
(https://eecs.berkeley.edu/academics/courses/)
Lists EE and CS courses with links to the course descriptions. These sites are automatically generated on the EECS department WEB server from campus sources. They include current and next semesters, and seminar classes (*94, *98). Instructors can edit department notes for courses on these pages at the My EECS Info link on the EECS department WEB server. Instructors will see a Courses section with courses that they are currently teaching. Click the pencil icon next to the course name to edit its description. For help about that, please email acg@eecs.berkeley.edu. |
| CalCentral |
(http://calcentral.berkeley.edu)
CalCentral is the UCB portal to an increasing suite of integrated Calnet-enabled tools for students and staff, including bCourses, bMail, bDrive and course registration. |
| bCourses |
(http://bcourses.berkeley.edu)
bCourses is the UCB learning management system. It integrates features from the former bSpace, CourseWeb, Blackboard, WebCT and Library ERes services. bCourses is managed by the UCB Educational Technology Services (https://www.ets.berkeley.edu/, bcourseshelp@berkeley.edu). All UCB students and staff can login to bCourses using their pre-existing CalNet ID. (non-UCB students, please see calnet.help for help.) When they login, instructors are automatically associated with their current classes (by the Registrar) and are authorized to manage sites for their courses. Students select courses from the pre-assigned "Courses and Groups" list. They are assigned to a course if they are enrolled in it or if the instructor has added them using the bCourses "People" tool. Please see above for ideas about which content is appropriate for bCourses vs the EECS WEB server. Also see What's the best choice for an online collaboration tool? for more information.
Create a world-readable reference on bCourses:
|
| Bearfacts |
(http://bearfacts.berkeley.edu/)
BearFacts is provided by the Registrar and IS&T. It contains student information for terms prior to Fall 2016. In Fall 2016 it was replaced by CalCentral. |
| CalShare |
(https://content.berkeley.edu/)
This service is provided by IS&T for a fee. 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. |
| Research Hub |
(https://content.berkeley.edu/)
Research Hub provides tools for content management, collaboration, managing research data and sharing documents. |
| Pantheon |
(https://content.berkeley.edu/)
Anyone with a CalNet ID can build a WEB site using Drupal (free for test sites, $25/month or more for production sites). |
| Berkeley Open Academy |
(https://content.berkeley.edu/)
Site for campus departments to quickly build and maintain a polished academic website, with CalNet ID (CAS) authentication, integration with the UC Berkeley events calendar, and a starter theme developed by University Relations. Based on the Pantheon Drupal environment. |
| CalWeb, WebFarm, AppFarm |
(http://ist.berkeley.edu/services/catalog/web)
These services are provided by the IS&T for a fee. There are several levels of WEB hosting services on UNIX and Windows servers that campus users can select. |
|
|
% 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:
|
|
% chmod 755 ~/public_html/archives.html
|
|
% 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!
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:
|
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 error conditions and solutions:
"Internal Server Error" error
This is the generic error message that is usually caused by a CGI problem.
The first thing to verify is that the CGI program is creating valid
HTML output:
Login to a server such as cedar.cs.berkeley.edu (an Ubuntu Linux system 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 source 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 If the CGI output is good, then the problem is usually caused by file permissions or ownership.
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.
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 "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
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.
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":
<!--#include virtual="header.html"-->
<!--#include cgi="hello.cgi"-->
and make "index.html" (and "hello.cgi") executable with the commnd:
% chmod 755 ~/public_html/index.html ~/public_html/hello.cgi
PHP commands can be run in 2 ways through the http://inst.eecs.berkeley.edu server:
#!/usr/bin/phpIt 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 php programs on one of the Instructioal CentOS login servers.
To see the options that are configured into the local PHP progam, see /usr/local/lib/php.ini.
"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.
Note that there is a problem with mixing the .php and .cgi methods indiscriminantly. Session variables created by one method cannot be referenced by the other. This is because the /var/tmp/sess_... file created by session-variable used in a .php script has a different owner from the one created by a .cgi script. [thanks to Prof Hilfinger for this]
For basic instructions,
see
http://www.boutell.com/gd/manual2.0.11.html#basics
For CGI scripts, be sure the command on the first line exists on the WEB
server. These are the most likely choices:
/bin/csh
Scripts in those languages will generally run the same on the different
UNIX operating systems, but compiled programs (such as in C++) will not.
CGI example:
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:
/usr/bin/perl
/usr/bin/python
/usr/bin/python3
Here are examples of simple CGI scripts called hello.cgi, written in
the bash shell, Perl and Python3. In each case, end the filename with a ".cgi"
extension (not .sh, .pl or .py) so the WEB server will know it's CGI:
#!/bin/bash
|
#!/usr/bin/perl
|
#!/usr/bin/python3
|
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:
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:
If you are writing your scripts in Perl, please use /usr/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.)
<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.
RewriteEngine On RewriteBase /~inst RewriteRule ^(.*) http://foo.com/~bar/$1 [R,L] =permanentThis 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.
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
| 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 |
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.htmlAccess will be restricted to browsers being run on the "cs.berkeley.edu" and "eecs.berkeley.edu" subnets and to the computer at address 136.152.91.1.
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.
Allow access only to certain people:
You can add password protection to a WEB site by creating a file called
.htpasswd in the subdirectory that contains
the WEB page (under your ~/public_html directory).
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 |
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 |
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.
The server is https://inst.eecs.berkeley.edu.
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:
Other topics:
Limitations of using .htaccess and .htpasswd files:
Using a CGI script to restrict access by UNIX file permissions:
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:
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.
AuthType Basic
AuthName "access is restricted to users on my list using SSL"
AuthUserFile /home/aa/staff/inst/authorized-web-users
Require valid-user
SSLRequireSSL
The AuthUserFile needs to be readable by the Apache WEB server.
The last 2 lines make it ask for a password and require an SSL browser.
Reference: https://httpd.apache.org/docs/2.4/howto/htaccess.html.
Instructions for creating the .htpasswd are in the
Allow access only to certain people section, above.
Usage Policies for Information Servers
"Informed Consent" Required for Displaying Student Identities
"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".
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):
Last modified:
inst@eecs.berkeley.edu