Difference between revisions of "Personal Web Pages"

From CS Support
Jump to navigation Jump to search
(Misc changes, fixing up making long <code> blocks into <nowiki>)
(fix url)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
Every user account in the CIS department can have a personal web site associated with it.  To activate this site, one must place a <code>public_html</code> directory in one's home directory to house the web site.  The contents of that directory will then become available via <code>http://www.cis.ksu.edu/~username</code>.
+
Every user account in the CS department can have a personal web site associated with it.  To activate this site, one must place a <code>public_html</code> directory in one's home directory to house the web site.  The contents of that directory will then become available for public access at the url <nowiki>http://people.cs.ksu.edu/~<username></nowiki>
  
 
== Permissions ==
 
== Permissions ==
  
−
One common sticking point with personal web sites in the CIS department is the issue of file permissions.  The proper file permissions are essential if others are to be able to successfully view your content.
+
One common sticking point with personal web sites in the CS department is the issue of file permissions.  The proper file permissions are essential if others are to be able to successfully view your content.
  
 
In Linux the three primary permission categories are <code>user</code>, <code>group</code>, and <code>everyone</code>.  Each of these categories then has <code>read</code>, <code>write</code>, and <code>execute</code> permissions.  They are traditionally viewed as strings that look like <code>rwxrwxr--</code> or something similar.  Here are some examples:
 
In Linux the three primary permission categories are <code>user</code>, <code>group</code>, and <code>everyone</code>.  Each of these categories then has <code>read</code>, <code>write</code>, and <code>execute</code> permissions.  They are traditionally viewed as strings that look like <code>rwxrwxr--</code> or something similar.  Here are some examples:
Line 16: Line 16:
 
Therefore, it is very common to need to set the following permission on your home directory and <code>public_html</code> directory when first creating your personal site.
 
Therefore, it is very common to need to set the following permission on your home directory and <code>public_html</code> directory when first creating your personal site.
  
−
  <nowiki>chmod 711 ~
+
  <pre>chmod 711 ~
 
chmod 755 ~/public_html
 
chmod 755 ~/public_html
−
chmod 644 ~/public_html/index.html</nowiki>
+
chmod 644 ~/public_html/index.html</pre>
  
  
Line 28: Line 28:
  
 
At this time you may wish to run the command <code>man chmod</code> to learn more about how to set file permissions.
 
At this time you may wish to run the command <code>man chmod</code> to learn more about how to set file permissions.
 +
 +
=== Fixing permissions on all files in a directory ===
 +
 +
Sometimes when you upload new files to your site, the permissions may all be incorrect. The following commands will recursively look in the current directory and fix permissions for all subdirectories and files accordingly.
 +
 +
To fix all subdirectories
 +
find ./ -type d -exec chmod 755 {} +
 +
 +
To fix all files
 +
find ./ -type f -exec chmod 644 {} +
 +
 +
These are the equivalent of "find files (f) or directories (d) recursively, starting in the current directory (./) and run the chmod command on anything found that matches ({})". The + at the end tells the shell to combine commands as much as possible to save time and resources. Run <code>ls -la</code> before and after to make sure permissions are changed correctly.
  
 
=== Static Content ===
 
=== Static Content ===
Line 37: Line 49:
 
Dynamic content is content that is executed on the server and the output of that execution is sent to the client.  All dynamic content for personal websites are executed as CGI scripts.  Permissions are very important on executable scripts and it is essential that '''no other user but the owner may have write permission to the script and the directory that contains the script.'''  An example acceptable permission scheme is:
 
Dynamic content is content that is executed on the server and the output of that execution is sent to the client.  All dynamic content for personal websites are executed as CGI scripts.  Permissions are very important on executable scripts and it is essential that '''no other user but the owner may have write permission to the script and the directory that contains the script.'''  An example acceptable permission scheme is:
  
−
  <nowiki>chmod 755 public_html
+
  <pre>chmod 755 public_html
−
chmod 644 public_html/index.php</nowiki>
+
chmod 644 public_html/index.php</pre>
  
 
Traditionally, cgi scripts that are not PHP (or other inline embedded language) are stored in a <code>cgi-bin</code> directory inside of your <code>public_html</code> directory.  An example acceptable permission scheme for the <code>cgi-bin</code> is:
 
Traditionally, cgi scripts that are not PHP (or other inline embedded language) are stored in a <code>cgi-bin</code> directory inside of your <code>public_html</code> directory.  An example acceptable permission scheme for the <code>cgi-bin</code> is:
  
−
  <nowiki>chmod 755 public_html/cgi-bin
+
  <pre>chmod 755 public_html/cgi-bin
−
chmod 755 public_html/cgi-bin/your-script.cgi</nowiki>
+
chmod 755 public_html/cgi-bin/your-script.cgi</pre>
  
 
The header of your file should not use direct paths.  Instead use the <code>/usr/bin/env</code> program as follows::
 
The header of your file should not use direct paths.  Instead use the <code>/usr/bin/env</code> program as follows::
  
 
<code>#!/usr/bin/env perl</code>
 
<code>#!/usr/bin/env perl</code>
−
 
−
You should check <code>/common/weblogs/rampage/suexec_log</code> and <code>/common/weblogs/rampage/error_log</code> to debug any problems you're having with your scripts. The systems team will not debug incorrectly written scripts for you.
 
−
 
−
=== Tomcat ===
 
−
 
−
We provide an install script that will setup tomcat in your home directory for you.  Login to <code>cislinux.cis.ksu.edu</code> and run this command:
 
−
 
−
<code>$ /common/public/bin/install_tomcat.sh</code>
 
−
 
−
This will install tomcat to $HOME/tomcat.  Once completed, you will be presented with the following information:
 
−
 
−
<nowiki>Before running your tomcat server you must do the following (non-bash shell
 
−
users should make changes accordingly):
 
−
 
−
1) Make sure JAVA_HOME or JRE_HOME is set in your environment variables by
 
−
running 'set | grep JAVA_HOME' or 'set | grep JRE_HOME'.  If neither is set,
 
−
you must add 'export JAVA_HOME=/path/to/java/home' (where /path/to/java/home
 
−
is the full path to the directory containing the JRE you wish to use) to the
 
−
end of your $HOME/.bashrc file.
 
−
 
−
2) Add 'export CATALINA_HOME=$HOME/tomcat' to the end of your $HOME/.bashrc
 
−
file or make sure that command gets executed before running your tomcat server.
 
−
 
−
3) Edit $HOME/tomcat/conf/server.xml and change the port numbers your tomcat
 
−
server will use so that it will not clash with others on the server.
 
−
 
−
3a) Look for the following section in this file starting around line 70:
 
−
 
−
<Connector port="8080" protocol="HTTP/1.1"
 
−
connectionTimeout="20000"
 
−
redirectPort="8443" />
 
−
 
−
Change the value of port here from 8080 to another port that is not in use
 
−
 
−
3b) Look for the following section around line 90:
 
−
 
−
<!-- Define an AJP 1.3 Connector on port 8009 -->
 
−
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
 
−
 
−
Change the value of port here from 8009 to another port that is not in use.
 
−
 
−
You do not need to change the value of redirectPort for either section here,
 
−
unless you activate the SSL Connector elsewhere in your configuration.
 
−
 
−
You can find what ports are currently in use by applications by running the
 
−
following command: "netstat -ln | grep tcp".  In general, port numbers in the
 
−
range 49152–65535 are safe to use.
 
−
 
−
Once you have done all of this this, you may start your tomcat server by
 
−
running $HOME/tomcat/bin/startup.sh.  This will launch it as a daemon and drop
 
−
to the background.  To stop your server, run $HOME/tomcat/bin/shutdown.sh.
 
−
 
−
Make a note of the host you run your tomcat server on.  The hostname cislinux
 
−
resolves to two different hosts in round-robin fashion, so if you use that for
 
−
your URL, you may get the wrong one.  The current hostnames are viper and
 
−
cougar.
 
−
 
−
You can connect to your server by using the URL http://<hostname>:<port>, where
 
−
<hostname> is the host you start the server on, and <port> is the port number
 
−
you specified for the HTTP Connector in step 3a above.
 
−
 
−
If you need help, please send email to help@cis.ksu.edu.</nowiki>
 
−
 
−
This is also in <code>$HOME/tomcat/README.CIS</code>.  Complete tomcat documentation is in <code>$HOME/tomcat/doc</code>.
 
−
 
−
You may also find the official Apache documentation useful:
 
−
* http://tomcat.apache.org/tomcat-7.0-doc/index.html
 
−
 
−
=== Department Listing ===
 
−
 
−
Once you have created your personal website, you may link to it from anywhere. After your site is up, go to your [https://www.cis.ksu.edu/user user account] on the main website, login, click "edit", and then "general info". Simply check the box that says "Show personal webpage", and then click "Save". Your name and link will automatically appear on "students" page on the main website.
 

Latest revision as of 14:18, 12 April 2019

Every user account in the CS department can have a personal web site associated with it. To activate this site, one must place a public_html directory in one's home directory to house the web site. The contents of that directory will then become available for public access at the url http://people.cs.ksu.edu/~<username>

Permissions

One common sticking point with personal web sites in the CS department is the issue of file permissions. The proper file permissions are essential if others are to be able to successfully view your content.

In Linux the three primary permission categories are user, group, and everyone. Each of these categories then has read, write, and execute permissions. They are traditionally viewed as strings that look like rwxrwxr-- or something similar. Here are some examples:

  • rwxrwxr-- - User: read, write, execute; Group: read, write, execute; Everyone: read only
  • rw-r----- - User: read and write; Group: read only; Everyone: no access
  • r-xr-xrwx - User: read and execute; Group: read and execute; Everyone: read, write, execute
  • r-x-----x - User: read and execute; Group: no access; Everyone: execute

Importantly, Linux uses the execute permission to determine if a client can traverse a directory. Even if every file in a directory is full access for everyone, if the directory those files are in do not have the execute permission set for everyone, they will not be able to see it.

Therefore, it is very common to need to set the following permission on your home directory and public_html directory when first creating your personal site. 

chmod 711 ~
chmod 755 ~/public_html
chmod 644 ~/public_html/index.html


These commands correspond to:

  • Set permissions of my home directory to rwx--x--x
  • Set permissions of my public_html directory to rwxr-xr-x
  • Set permissions of my index.html file in public_html to rw-r--r--

At this time you may wish to run the command man chmod to learn more about how to set file permissions.

Fixing permissions on all files in a directory

Sometimes when you upload new files to your site, the permissions may all be incorrect. The following commands will recursively look in the current directory and fix permissions for all subdirectories and files accordingly.

To fix all subdirectories 

find ./ -type d -exec chmod 755 {} +

To fix all files 

find ./ -type f -exec chmod 644 {} +

These are the equivalent of "find files (f) or directories (d) recursively, starting in the current directory (./) and run the chmod command on anything found that matches ({})". The + at the end tells the shell to combine commands as much as possible to save time and resources. Run ls -la before and after to make sure permissions are changed correctly.

Static Content

Static content includes images, html, and other content that is not executed on the server side. The everyone group will need to have read permission to any file that you wish to make available via your web site. All directories that contain static files will need to have the execute permission for the everyone group.

Dynamic Content

Dynamic content is content that is executed on the server and the output of that execution is sent to the client. All dynamic content for personal websites are executed as CGI scripts. Permissions are very important on executable scripts and it is essential that no other user but the owner may have write permission to the script and the directory that contains the script. An example acceptable permission scheme is: 

chmod 755 public_html
chmod 644 public_html/index.php

Traditionally, cgi scripts that are not PHP (or other inline embedded language) are stored in a cgi-bin directory inside of your public_html directory. An example acceptable permission scheme for the cgi-bin is: 

chmod 755 public_html/cgi-bin
chmod 755 public_html/cgi-bin/your-script.cgi

The header of your file should not use direct paths. Instead use the /usr/bin/env program as follows::

#!/usr/bin/env perl

Retrieved from "https://support.cs.ksu.edu/CISDocs/index.php?title=Personal_Web_Pages&oldid=593"