Viewing Files
Research users are given three directories for creating websites. Each of these directories are web accessible from different urls and have specific purposes. Below is a table summarizing this.

The <group>_html directory is where most of site specific pages should go. All other members of the collaborating group will have access to this directory.

The public_html directory is where your personal web pages should go. Many users also put testing or example pages here since the url is not part of the main site.

The cgi-bin directory is where some scripts need to go to be executed. This directory is only accessible throught the cgiwrap script. The <research username> in the table above is probably your username. IMPORTANT: scripts executed using cgiwrap are executed as the user and ignore .htaccess files (files used to limit access to your site). Therefore if you are trying to limit access to your scripts please contact research.support@yale.edu for alternatives.

Protecting Your Site
Research is able to block the general public from seeing specific parts of your website. To do this users can add a file called .htaccess to the protected area. Two of the most common methods for blocking access are by ipaddress or Yale netid. Blocking by Yale netid is done by activating CAS, Yale's Central Authentication System. Some common examples are below. Simply add these lines to a text file called .htaccess and place the file in the protected directory.

NOTE: .htaccess files act recursively, meaning if you block /private from the world you will also be blocking /private/joe.

NOTE II: Windows likes to add extensions like ".txt" to the filename, creating a file called .htaccess.txt. This will be ignored by research, so make sure you remove the extension and test the .htaccess.

#Limit access to Yale computers
Order deny,allow
Deny from all
Allow from 130.132 128.36

#Limit access by IP address
Order deny,allow
Deny from all
Allow from 130.132.21.104 130.132.21.162 128.36.236.68

#Deny all access
Deny from all

#Require a valid Yale netid
AuthType CAS
Require valid-user
DirectoryIndex index.html

#Require Yale netids asdf2, qwert3 or zxcv4
AuthType CAS
Require user asdf2 qwert3 zxcv4
DirectoryIndex index.html

Protecting your Files and Users
By default, files created on research are readable by any user. This is necessary to allow uploaded files to be viewable online without any changes. Uploaded files, however, are not editable by anyone but the uploader. Although this makes sense from a security point of view, this limits group collaboration. Samba shares can be customized to allow group collaboration on specific directories. To add a samba share contact research.support@yale.edu. The sftp client winscp also enables file permissions to be changed upon uploading. If you're uploading for a group collaboration project you will want to make the directories 775 and files 664. You will also need to change the group ownership to your group name for files and directories.

Because research is a multiuser web server, web scripting engines such as php use a shared session directory. If you are using sessions in your web application you are encouraged to save session data to personal directory or database. This will prevent other users from stealing session ids and logging into your application as another user. To setup a personal directory to store session ids contact research.support@yale.edu. You will need to change your application to save session ids in this custom directory.

Scripting
Research provides an array of scripting languages to develop your website. Below is some information to help you get started with your language of choice.

php
php code will be interpreted from any non-cgi-bin directory as long as the filename ends with .php, .phtml, or .php3. php engine variables can be read from the /etc/php.ini file. If you do not like the default variables most can be overridden in your application using the .htaccess file or the function ini_set().

perl
Perl code is currently only executed from .pl files within your cgi-bin. Perl scripts must also start with this specific line containing the path to the perl binary: #!/usr/bin/perl

REMINDER: if you use the cgi-bin within your home directory .htaccess files are ignored and the scripts are executed as your username. If you can not live with this please contact research.support@yale.edu.

python
The python module is active on research. If you would like a specific handler please contact research.support@yale.edu.

Tomcat and mod_jk (java and .jsp pages)
Research does allow tomcat instances, HOWEVER you MUST contact research.support@yale.edu to be given a tomcat instance. Multiple instances of tomcat already exist, so please do not start your own tomcat. There is a good chance you can interfere with a production website.

Once you have a tomcat setup more about how tomcat is configured on research.

other languages
Other languages such as Ruby and C/C++ are available. Ruby is not currently activated, however if you wish to use Ruby contact research.support@yale.edu.

Databases
Research provides mysql and postgres database services. Each group is allowed one mysql database and one postgres database with multiple logins. mysql can be easily edited using phpMyAdmin. To request a database email research.support@yale.edu.Documentation for mysql and postgres is available in various places online.

When logging in to mysql or postgres please do not include the username and password as one command. ex.
mysql -u<username> -p<password>
Instead, type just the username and prompt for password. ex.
mysql -u<username> -p [ENTER] ...
type password at prompt.
Certain commands can steal the password if the first method is used.

Remote database logins are allowed from within the Yale network. Users must be aware that any data transmitted via remote logins is not encrypted and therefore can be read. If this is a concern SSH port forwarding can be used for security.

For information on database backups please read the backup section.

Automating Jobs
All users have the ability to have jobs run automatically at a specified time. The jobs can run once using the "at" command or periodically using user crons.

Access logs and Statistics
Statistics for websites are generated by request using awstats. Awstats generates reports on a nightly basis. Statistics are kept indefinitely, however only one year at a time can be displayed. To request awstats please email research.support@yale.edu. When awstats is first setup only statistics since the last Sunday are available, so please request awstats before you need statistics.

Backups
Backups are done nightly to Yale's adsm tape backup. Research has a server grade contract, meaning eight versions of a file are archived. If a file has been deleted it will remain in backup for 30 days, however only one version is kept.

To restore files, users can use the dsmc command line utility. To invoke the command line shell run dsmc. There is a comprehensive help file viewable from there by typing "?":

tsm> ?

An example restore for a point in time:

Restore all files in the /home/mydir directory to their state as of 1:00 PM on August 17, 2002.

tsm> restore -pitd=8/17/2002 -pitt=13:00:00 /home/mydir/

If you are uncomfortable restoring files this way you can contact research.support@yale.edu.

Mysql database backups are done nightly. Research keeps a complete snapshot of the mysql databases for 28 days . Users are responsible for and encouraged to backup, dump, and restore their database regularly. Always keep multiple versions of the database and be familiar with the steps necessary to restore the database. User crons are particularly useful for regular database backups. Please read information on mysqldump for help on dumping your databases.

cgi-bin and cgiwrap
The cgi-bin directory is where some types of scripts need to go to be executed. This directory is only accessible throught the cgiwrap script. For example, if you created a file called test.pl in /home/<your username>/cgi-bin/test.pl
it would be accessible at
http://research.yale.edu/cgi-bin/cgiwrap/<your username>/test.pl
Where your username is probably your yale netid.

cgi-bin scripts must start with the path to the interpreter, for example, perl scripts must start with:
#!/usr/bin/per

IMPORTANT: scripts executed using cgiwrap are executed as the user and ignore .htaccess files. Therefore if you are trying to limit access to your scripts please contact research.support@yale.edu for alternatives.

Samba
Samba is a service developed to allow windows filesharing with UNIX servers. Ironically, the current samba is now faster and more powerful than the microsoft alternative. Samba is accessible from within Yale only, so users connecting from outside of Yale must connect to Yale's vpn (Virtual Private Networking) first.

To connect to research from a windows machine:
Quick Windows Instructions
Go to Start > Run > Type in \\research.yale.edu\<yale netid> > Click OK

Detailed Windows Instructions
On a correctly configured computer on the Yale network, opening your research home directory is as simple as clicking on the Start menu, choosing Run, and entering \\research.yale.edu\NetID (replacing NetID with your own NetID).

If this does not work, you can instead try \\128.36.236.58\NetID (again replacing NetID with your own NetID). Depending on your machine's configuration, one of these options may work better.

You can assign a drive letter (e.g., H:) to your research home directory by right-clicking on Network Neighborhood, choosing Map Network Drive, choosing your desired drive in the Drive box, entering \\research.yale.edu\NetID (replacing NetID with your own NetID) in the Path box, and then clicking OK.

OSX Instructions
1. With the Finder open, click "Go" and select "Connect to Server".

2. In the Address field, type "smb://research.yale.edu/NetID", where "NetID" is your Yale NetID. Click Connect.

3. You will be prompted for your username and password. Type them in and click OK.

4. You should see a new icon on the desktop titled your NetID.

SFTP and SSH
All research accounts are able to login using SSH or SFTP. SFTP is a secure file transfering protocol, meaning that when you transfe files using sftp all of the data is encrypted. SSH is a completely secure shell that allows users to access the UNIX shell for a wide array of tools. To login via SSH Yale recommends putty, a free open source application. To transfer files using SFTP Yale recommends winscp, another free open source application.

To login to the UNIX shell via SSH:
1. Download putty and run the executable file.

2. In the HostName Box type "research.yale.edu".

3. Make sure the Protocol: is set to "SSH".

4. Select Open.

5. When prompted for "login as:" type your Yale netid then hit enter. Type your passwod when prompted.

To login using SFTP:
1. Download and install winscp from their download site.

2. Run winscp. At the menu enter these values:
Host name: research.yale.edu
Login: research login (probably your Yale Netid)
Password: research Password
Protocol: SFTP (allow scp fallback)

3. Hit Login and you should be taken to your home directory on research.

phpMyAdmin
phpMyAdmin is a powerful web based mysql database editor. It has numerous features for beginners and professionals. All users with a mysql database have access to phpmyadmin on research.

To login to phpMyAdmin:
1. Visit this URL:
https://research.yale.edu/phpMyAdmin/

NOTE: Always use https NOT http when accessing phpMyAdmin. If you do not anything that you do can be read by someone else including your Username and Password.

2. When prompted, enter your username and password and hit enter.

3. You should now be logged in and able to view your database.

Mailing Lists
A mailing list allows users to send one email to multiple recipients. To create a mailing list contact research.support@yale.edu and be sure to include a list name. Once you are given a mailing list you will be pointed to a web based administrative interface to customize the functions of your list. Groups on research are allowed two mailing lists.

Research uses the mailing list application mailman. To find out more about mailman visit: http://www.list.org/ Here is a brief overview of features:

* Most standard mailing list features, including list moderation, mail based commands, digests (both MIME and `plain'), and so on.
* An extensive web-based user interface that is customizable on a per-list basis. This allows users to manage their own subscriptions, with support for temporarily disabling their accounts, selecting digest modes, hiding their email addresses from other members, etc.
* A web-based list administration interface for all admin-type tasks, including list configuration, moderation (post approvals), selection of posting and subscribing rules, management of user accounts via the web, etc.
* Automatic web-based hypermail-style archiving, including provisions for private archives.
* Integrated gatewaying to and from Usenet.
* Smart bounce detection with automatic disposition (i.e. configurable disabling, unsubscribing).
* Smart spam protection.
* Multiple list owners and moderators are possible.

Cron Jobs
Cron jobs allow scripts (sets of commands) to be run on a regular basis. Users can set, edit, and cancel jobs using the crontab command. Below is a tutorial, but more can be found here.

When creating a cron job you are basically writing to a file in a specific format. There are six fields to a file, each separated by a space. The first five fields specify exactly when the command is to be run; the sixth field is the command itself. The first five fields are:
Format
minute hour day month weekday command

Minute - Minutes after the hour (0-59).
Hour - 24-hour format (0-23).
Day - Day of the month (1-31).
Month - Month of the year (1-12).
Weekday - Day of the week. (0-6; the 0 refers to Sunday).

Asterisks (*) specify when commands are to be run in every instance of the value of the field. For instance, an asterisk in the Month field would mean that the command should be run every month. In addition, multiple events can be scheduled within a field by separating all instances with commas - with no space between.

Working with the cron file:

crontab -e
Edits the current crontab or creates a new one if one has not been created.

crontab -l
Lists the contents of the crontab file.

crontab -r
Removes the crontab file.

Create the crontab from the command line:

crontab -e

Insert the following lines and the save the file (Ctrl-kx):

30 23 * * * /home/<yale netid>/dir/script_name.pl
45 23 * * * /home/<yale netid>/dir/script_name2.pl

script_name.pl will run every evening at 11:30 and then script_name2.pl will run at 11:45 p.m..

Type man crontab for more detailed information.

Tomcat and mod_jk

See above for information about obtaining a tomcat instance.

When a tomcat account is given, three ports are alloted to the instance. The user will have a tomcat directory in their home with a properly configured server.xml and a restarttomcat.sh script. The tomcat instance will also be configured to startup after a server reboot. Once the web application is ready, mod_jk can be configured for your tomcat instance, which removes the port number from the url.

Research is currently running tomcat 5.0.X.

Permissions
By default, files uploaded to research via samba or SFTP are only editable by the user who uploaded them. This can sometimes hinder group collaboration. There are two ways to solve this issue: 1. You can manually change the file permissions after creating/editing a file or 2. You can set all files that you create/edit to be group editable. Most users prefer the second option, however users must remember that anything they create on research will be editable by anyone in their group. Also, if you belong to multiple groups you will need to have a seperate connection for each group.

To manually change file permissions
Some users who are familiar with the UNIX enviorment will want to change the file permissions yourself. If you are a beginner or uncomfortable with computers you will probably want to skip this section. There are two basic changes that you need to make with the files:

1. You need to make the group owner of the files as the same name as your research group.

2. You need to make the file permissions 664 and the folder permissions 775.

SSH and SFTP both allow you to make these changes.
To change the file permissions using winscp and SFTP:

1. Right click on a file or folder and go to properties. Set the permissions using this menu.

To change file permissions using SSH Issue these commands:

1. chgrp -R <research group name> <file or folder name>

2. chmod -R 775 <folder name> or chmod -R 664 <file name>

NOTE: you do not need to make files 664, you can make them 775, but it is less secure.

To have all files that you create be group editable
The first step to making sure that everyone in your group can edit all of the files is to email research.support@yale.edu and ask for a group samba share. A group samba share allows users to connect to the group files and edit them with the correct permissions. If you belong to multiple groups on research you will need to connect to each of these groups seperately.

Custom Host Names
Research can and does serve custom vanity hostnames such as frank.yale.edu. Below is the official policy concerning vanity names.

Requests for vanity domain names are not automatically approved. The general policy is that:

1. Any request for a vanity domain name must be approved by the director of Data Network Operations (Joe Paolillo). This is to ensure that the project associated with the name falls within ITS appropriate use policy. Requests must come from an ITS/AMT manager- and end users are not permitted to make the request directly. In this case, Paul G would be the one to make the request of Joe.

2. If permission is granted for a vanity domain name to resolve to a Yale server, the end user is entirely responsible for registering _and_ maintaining the domain name. Yale ITS staff will not serve as brokers for registering a .org name.

3. In order to set up any ITS/AMT/WSS machine to resolve to a vanity name, there is an additional $300 charge to the end user that goes to WSS. This is simply to configure the Yale server to respond to the name, and to coordinate with the Hostmaster in order to get an IP address for the vanity name that resolves to a Yale server.

4. The end user is responsible for annual renewals of the domain name.

5. No .com addresses are allowed - ever.

6. No advertisements - ever.

7. Sites with vanity domain names that are hosted on Yale hardware must still conform to the ITS AUP.

8. End user must agree to all terms above.

Writing files on research using a web application
Writing files to a web server can be both a difficult task and a security concern. If possible we encourage users to use a database to store information.

If, however, you are unable to use a database, and you want to keep your data safe you must use the cgi-bin in your home directory. The cgi-bin uses cgiwrap to execute files as your user name. Remember, cgiwrap ignores .htaccess files, so you need another way of protecting access to your application.