Recent Changes - Search:

Help Topics

User Accounts

Additional Help

Staff Docs

  • (Private)

edit SideBar

FAQ /

WWW


1.  Web Server Aliases

PurposeAliases
Research domainswww.eecis.udel.edu www.ece.udel.edu www.cis.udel.edu
Academic domainswww.acad.ece.udel.edu www.acad.cis.udel.edu

2.  WWW browsers

Firefox is recommended for web browsing. Just run firefox in a command prompt or run terminal on a Unix machine. Firefox does not do email, Thunderbird can be used for that.

For text based browsing there is lynx. For downloading files the wget command is suggested.


3.  How to make homepages

In order to create a web page on the ECE/CIS machines, you must create a /usb/$USER/public_html with world read and executable permissions. Or if you want to restrict what people can see on the filesystem use ACLs and give read and execute permission to the httpuser user. (see man page for chmod about changing permissions) The URL for research accounts will be http://www.eecis.udel.edu/~<$USER>. Or replace eecis with ece or cis - they all point to the same directory.

Access to /usb/$USER/public_html is available over Samba. Please refer to the Samba FAQ (section 2.2.2 for PC, 3.2.2 for Mac) for more information.

For acad accounts the URL will be http://www.acad.ece.udel.edu/~<$USER>. The /usb/$USER filesystem is not created by default for acad users. To have one created just put in a help request for one.

For more information on HTML (HyperText Mark-up Language), please refer to HTML Beginner's Guide


4.  CGI server, cgi-bin to make homepages

User cgi scripts are not enabled on the main web servers mentioned above for security reasons. There is a web server available to run CGI scripts on. It is on a separate, untrusted server to minimize security risks. Users are only given CGI space on request.

Requested space will be available at /cgi/$USER on any ECE/CIS supported system at /cgi/$USER. The cgi server itself does not support direct SSH logins.

Info:

  • Server Name: cgi.eecis.udel.edu
  • Location to put cgi program: /cgi/$USER/public_html/cgi-bin/.
  • Name of cgi program must end in .cgi, for example program.cgi
  • URL would be http://cgi.eecis.udel.edu/~$USER/cgi-bin/program.cgi
  • perl with CGI.pm, a CGI library, is installed
  • program.cgi will run as $USER, and therefore can write and read anything that $USER can in /cgi/.
  • /cgi/$USER/public_html/cgi-bin/ needs to be readable and executable to httpuser, either mode 755 or with ACLs. However, your scripts do not need to be readable or executable to anyone other than $USER.
  • Access and errors logs are in /cgi/www/logs/.
  • Access to this server is through the filesystems mentioned above. Users do not have access to login to the server.

Note To have a filesystem made on this server to enable you to create/use CGI scripts, use the Computer Service / Help Request system and request access to the CGI server.

There are security issues that you should be aware of when writing your own scripts. Note, that if you have a security hole a CGI that your account on cgi.eecis can be compromised, so special care should be taken, when writing CGIs and in processing any data from them. (This is why CGI scripts are not enabled on the main dept. web servers)

Additional Info:


5.  Department Web Updates

For those who have permissions to update the department websites, the web files can be accessed from any research system.

Website AddressWeb Files Location
www.eecis.udel.edu/usb/eecis-web
www.ece.udel.edu/usb/ece-web
www.cis.udel.edu/usb/cis-web

6.  Web access/errors log files

The Web access logs for our web servers can be found under the directory /usb/www/logs. There are directories for each server with access and error files, which are the current active files. Those files are rotated nightly and a -number extension is added to them for one week and compressed using bzip2. They can be uncompressed to standard output using the bcat command. The access logs are also added nightly to the file access_archive, which is rotated monthly and bzip2ed for one year. This is also the location of PHP errors.


7.  Access Control

An htaccess file provides a method to limit directory and file access to authorized users with username/password pairs. First, create a directory that is mode 755 (or at least readable and executable to httpuser using ACLs.

[~/public_html/]> ls -al
drwxr-xr-x 4 user group 512 May 18 11:39 .
drwxr-xr-x 3 user group 512 Mar 3 09:28 ..
drwxr-xr-x 2 user group 512 May 18 11:39 protected

The next step is to create your htaccess password file which will be used for authentication.

htpasswd -c /usb/$USER/public_html/.htpasswd new_username

Where new_username is the username you would like to add to the password file. This username does not have to nor should it be the same username or password as your EECIS account. The -c option is used to create a new file. Do not include that flag if you are adding new passwords to an existing file. Users can be deleted by using the -D option.

NOTE: The htpasswd file you create will contain ENCRYPTED passwords. The default encoding is standard Unix crypt, but MD5 hashes can be used by using the -m option and SHA1 hashes can be used by using the -s option. To avoid sending passwords in the clear over networks https should always be used instead of http in these situations.

After you have created the htpasswd file, the next step would be to create an .htaccess file in the directory you wish to restrict access to.

[~/public_html/]> ls -al protected/
total 10
-rwxr-xr-x 1 user group 125 May 18 11:47 .htaccess

NOTE: The .htaccess file and your htpasswd file MUST be world readable. ( mode 644 ), or at least readable by the user httpuser using ACLs, and exist in the /usb web filesystem so the web server has access to them.

The contents of the .htaccess file ( which protects the entire directory ) are as follows:

AuthType Basic
AuthName "My Protected Directory"
AuthUserFile /usb/username/public_html/.htpasswd
require valid-user

From above:

  • The AuthType tells the server what protocol is to be used for authentication. At the moment, Basic is the only method available. However a new method, Digest, is about to be standardized, and once browsers start to implement it, digest authentication will provide more security than the basic authentication.
  • The AuthName is what the user will see when accessing this directory.
  • The AuthUserFile contains the username / encrypted password pairs.
  • The require valid-user line only allows users in the chosen password file even try to authenticate.
  • You should now be able to test the new configuration by accessing that directory with your web browser.

An example of htaccess can be found here.


8.  Advanced Features

You can also require that the user use an encrypted session to access certain files. This is good for sensitive or confidential documents which you would not want to send over the network as cleartext. When used in conjunction with the password file you created above, you can allow secure access to only certain users, and certain ip addresses.

To do so, add the following to your .htaccess file (Changing it of course):

<Files secret.txt>
SSLRequireSSL
require user secure
order deny,allow
deny from all
allow from 128.4.
</Files>

In the example above, SSL will be required when accessing the file secret.txt. The required username is 'secure', but any username which is in your htpasswd file can be specified there. Another option is to specify 'require valid-user', which will allow any user in your htpasswd file to authenticate. The 'allow from 128.4.' statement specifies that only users connecting from 128.4.*.* are allowed to access 'secret.txt'. A filemask can also be used in place of a specific file name.

9.  SSL

The primary goal of the SSL Protocol is to provide privacy and reliability between two communicating applications. The SSL protocol provides connection security that has three basic properties:

  • The connection is private. Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption (e.g., DES[DES], RC4[RC4], etc.)
  • The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.).
  • The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations.

Comments

To add a comment, click the link below. You are free to contribute anonymously, but it is preferred that you sign your comments with your name. Simply add ~~~~ to the end of your comment to sign it. Regardless of whether you sign your comment, your username will be visible on the History page.
(Add Your Own)


Edit - History - Print - Recent Changes - Search
Page last modified on July 30, 2013, at 09:18 AM