Scripts, SSI, Htaccess & MySQL
Document Actions
- Overview of CGI scripts
- What kind of scripting can I use on the server?
- How do I untar or uncompress files in my directory?
- How do I make a backup of my web space?
- What is Chmod and how do I do it?
- Which directory should the cgi scripts be put in?
- How many cgi scripts can I have?
- Do the cgi scripts need to be Unix compatible?
- Can others view my cgis with a browser?
- What do I name the directory with my cgi scripts?
- How do I call a cgi?
- How do I configure a CGI Script?
- How do I put form results into a text file instead of email?
- How can I prevent others from downloading my results?
- What cgi scripts do you recommend?
- Where can I get cgi scripts?
- If I can't get my cgi to work who do I call?
- Common Linux commands
- Overview of SSI
- Configuring your server to permit SSI
- Basic SSI directives
- Additional examples
- What else can I config?
- Advanced SSI techniques
- Conclusion
- What is .htaccess?
- How do I make a Professional Error Page?
- How do I make a password protected directory?
- How do I add additional users to a password protected directory?
- How do I restrict access by domain name or IP address?
- How to create WWW FTP directory listings (like the Software directory)?
- How do I make a directories contents not viewable via the web?
- How do I make ".exe" files downloadable with the browser?
- How many MySQL databases do I get?
- How do I log into my MySQL database?
- Do I have access to a MySQL utility (i.e., to create/modify tables, fields, etc)?
- What does "Can't connect to localhost MySQL server error" mean?
1. Overview of CGI scripts
First things first. Throughout this document you will see text that is highlighted either blue or red. What is the color indicating, blue text is a file name, URL or paths & red text is Telnet or SSH commands. OK now on with the good stuff.
So what exactly is CGI? CGI stands for Common Gateway Interface. Any script can be called a CGI script as long as it's installed on the server end. However, the majority of CGI scripts are written in Perl (with C being the next most common). If you want to write your own CGI scripts, you'll need to learn Perl. CGI scripts are what makes the server able to do all those amazing things such submit a form, create a guest book or forum, keep track of and rotate your ads etc. The server has the capability to redirect data to any email address, persist data, dynamically serve out different content to the browser, among many other things that the browser alone simply cannot do.
There are tons of free, quality CGI scripts on the internet, and all you have to do is grab and learn how to install them onto your site. As daunting as installing a CGI script on the server may sound, it's actually quite easy. Regardless of the script you're attempting to installing, the process is pretty much the same.
You don't even need to know any programming to have a complete CGI program up and running on your site. In generally, you only need to know and understand the following, regardless of what CGI script you're trying to install:
I. How to use a text editor (such as Notepad)
First and foremost, it's important to understand that CGI scripts are really no different than normal text files (except the former uses a file extension of .pl or .cgi). Both are written in ASCII format, and can be opened and viewed using any text editor. Now, in order to install a CGI script, you'll need to configure it. That's where the text editor comes in. Use it to open and configure your CGI script.
II. The path to the Perl compiler, on the ABHost.Net server is:
/usr/bin/perl
Take a look at the very first line of the script, it should look something like this:
#!/usr/bin/perl
Don't panic if your first line looks a different than the above line that's perfectly fine. The thing to understand is just what this line of mumbo jumbo is. This line #!/usr/bin/perl refers to the path of the Perl compiler on the server. It always appears as the first line in your perl script. This line needs to refer to the perl compiler on the server. If you're lucky, you won't even need to change a thing, as #!/usr/bin/perl actually correctly refers to the compiler on most servers. Another likely candidate in many scripts is #!/usr/local/bin/perl take local/ out of the line and you are set to go. Do you want to find out for sure where the path to the Perl compiler is on the ABHost.Net server. How do you do that? You could find this info on your own by telneting or SSH2 to your account on the server, and type "whereis perl"
III. The path to your site
The path to your site from the ABHost.Net server's standpoint is /virtual/your-user-id/public_html/. Think of it like this. On the Internet, your sites address may be http://mysite.com/index.html. But on your hard drive where your site is stored locally, it may be referenced as file:///c|/mysite/index.html What you want to know now is the path to your site as seen from the server that your site is on. An example would look something like this for all ABHost.Net clients:
/virtual/your-user-id/public_html/
Unlike the path to the CGI compiler, the path to a site is completely different from site to site, and yours is a unique string.
IV. Some other helpful things to know
There are a few other things you may need to know, depending on the CGI program you'll trying to install. Your program may ask you the path of the server's mail program (i.e.: /usr/sbin/sendmail), or your CGI-BIN (i.e.: /virtual/your-user-id/public_html/cgi-bin).
Once you've figured all these things out, it's a matter of opening the cgi file using your text editor, and filling in the blanks whenever the program says so. It may say "change the below to the path of your CGI-BIN." What do you do then? Add this path /virtual/your-user-id/public_html/cgi-bin, or where ever you have installed the script.
Uploading the script and finalizing the deal
All that's left now is uploading the script onto the server. The basic idea is to use a FTP program and upload the script(s) into your CGI-BIN directory. There are a few things, however, that you should take note of:
V. Always upload CGI scripts in ASCII mode (Not binary)
By default, your FTP program always uploads files in binary mode. That's fine for most files -except CGI files. CGI files must be uploaded in ASCII format, or don't expect them to work. Your FTP program should allow you to change between binary and ASCII mode (In WSFTP, this option appears at the bottom of the screen). Always switch to ASCII mode or have your FTP program set to auto detect before uploading your CGI scripts.
VI. After uploading the script, set it's permission
After uploading, you need to set it's permission. Since a CGI script is installed on the server end, in the wrong hands, it could cause damage to your site. That's why you need to set permissions on your CGI script before they will be allowed to run. Permission can be set directly using your FTP program. In WSFTP, this is how it's done: Right click the CGI script, and select "chmod". Up pops a permission box:
The most common permission settings for CGI scripts are chmod 755, and chmod 777. To chmod 755 a CGI file, choose the following settings on the file, and press OK:
On the command line (telnet or ssh2) you can type: chmod 755 file-name.cgi
To chmod 777 a file, do this instead:
On the command line (telnet or ssh2) you can type: chmod 777 file-name.cgi
Check the documentation inside the script to see whether to chmod 775 or chmod 777 the file. If it asks for some strange permission setting like chmod 664, chmod it 775 anyway. Usually, it doesn't make all that much of a difference.
Now what?
OK, you've configured the script, saved the changes, and successfully uploaded the script into the appropriate directory. Now what? Depending on the script and it's function, you either have to view it via the browser (by typing in the url to the script, http://mysite.com/cgi-bin/test.pl, for example), or, if it's a form related script, add that URL to the action attribute of the form. Consult the documentation inside that particular script to see exactly what you should do to awaken it.
As you can see, installing and getting CGI script to work for you doesn't exactly require a degree in nuclear science. Anyone can do it!
2. What kind of scripting can I use on the server?
It is easier to say what you can not run on the server. You can not run pre-compiled binaries for other operating systems (Windows, Mac, OS/2), other than that, you can use any language that you want on the server. We do not allow users to compile directly on the server however. You must pre-compile your C programs on your local workstation then FTP the programs to the server.
3. How do I untar or uncompress files in my directory?
* if the file is '.tar' use: tar xvf file_name.tar
* if the file is '.tgz' use: gunzip file_name.tgz to convert it to a .tar, then use the tar command above.
* if the file is '.tar.gz' use: tar xzvf file_name.tar.gz
* if the file is '.zip' use: unzip file_name.zip
4. How do I make a backup of my web space?
If you want to backup ~/public_html and all directories that are in it, then you can Telnet or SSH2 into your account. At the command line type cd and hit enter. You will now be at the level where you can see the public_html directory. Type ls and hit enter to confirm that you can see public_html.
Type the following command to make an archive of your entire public_html structure:
tar cf - public_html > public_html.tar
At the command line type ls and hit enter, you will see the new public_html.tar archive.
5. What is Chmod and how do I do it?
If you would like to run CGI scripts, you must realize a few things before hand.
First of all, unix systems are very different then the usual Windows & Mac systems you are currently quite comfortable with and used to. Similar to the use of "profiles" in windows, unix has users. Each user has certain permissions to access files and that is controlled by using chmod. Chmod command means "change mode". This changes the file access privileges on the specified file.
The superuser, AKA root, has the power to do anything on a server. Basically they are the god of that computer. None of the smaller users have these capabilities though. Your HTTP server runs as your account ID and your privileges can only affect your account. You have few or no privileges outside your account. That means the person accessing your site via the web have fewer permissions or capabilities then you do (as the account holder). Each file in your account has 3 possible settings, one for owner, one for group and one for world, in that order.
Therefore, if you want to make a file accessible via the web, you must give that file 'permission' to do so. The typical CGI script is set to be world executable, or chmod 755. From the command line a file with permissions set to 755 looks like this when you do ls -la "-rwxr-xr-x". From a telnet or SSH2 connection the command looks like this: /virtual/your-user-id/public_html $ chmod 755 filename.cgi. This will give filename.cgi the permission to be an executable. Do ls -la from the command line to confirm that the file permissions have been changed. You should see "-rwxr-xr-x" on the same line as the file name that you are working on.
The easiest way to learn about chmod is done by using your FTP program, as Telnet is probably a little too advanced to start with. However if you want full control of your files and you really want to learn how to do things quickly, telnet or SSH is the way to go.
Now, this is a pretty simple procedure to chmod. Browse with your FTP program through your account to your cgi-bin, or wherever the script is that you want to be able to run. Select the cgi script that you want to chmod. Your FTP program should now allow you to go to the properties for the file or allow your chmod the file from a menu.
Depending on how your FTP program works you will be confronted with a little pop-up box, which states a bunch of information about this file. At the bottom you will see 9 different check boxes, some checked, some not. Each check box represents a different permission level. Since all CGI scripts are generally 755 (world executable), then you will want to click the following boxes;
Quick explanation of permission values: r=4, w=2, x=1, if you add them up r+w+x=7)
User - Read, Write, Execute rwx = 7
Group - Read, Execute r-x = 5
World - Read, Execute r-x = 5
Or if your FTP program gives you a little input box, you can just type in 755 there and click ok. There you go, your script can now be accessed via a web browser.
6. Which directory should the cgi scripts be put in?
When your account is first created 3 things are put inside the public_html directory in your account:
cgi-bin/
index.html (this is our welcome page, you need to replace it with your own index.html)
www_logs/
As a matter of web convention, users typically put the cgi scripts they want to use whit their site in the cgi-bin, because that is where the web server is told to look. We have created a cgi-bin directory for you that follows that convention, however the way that the ABHost.Net servers are configured you can put cgi scripts anywhere you want in your site. Although you will still need to chmod your scripts to 755 for them to function.
7. How many cgi scripts can I have?
You are only limited by your disk quota of 500 MB of storage space. You can use as many scripts as you would like or need.
8. Do the cgi scripts need to be Unix compatible?
You can not use pre-compiled binaries for other operating systems (Windows, Mac, OS/2), other than that, you can use any scripts that you want on the server. Sometime scripts that are written to be used on other platforms will contain extra characters that can prevent the script from functioning on a Linux server. In such cases you will need to go though the file and remove the extra characters that can prevent the script from functioning on a Linux server. Usually the extra characters will be at the end of a line and it will look like this- ^M.
9. Can others view my cgis with a browser?
Yes they can until you put a .htaccess file in the directory that prevents the contents of a directory from being viewed from the web. See the .htaccess section below for details about this procedure.
10. What do I name the directory with my cgi scripts?
Typically cgi scripts are put in the cgi-bin inside of public_html. If you are new to web site administration your best bet would be to put all of your scripts into the cgi-bin and follow convention. Ultimately as the administrator of your site it is up to you to decide the name of the directory your scripts reside in.
Most scripts come with a readme file that explain in detail how to install the script as well as how to call the script. Depending on the script and it's function, you either have to view it via the browser (by typing in the url to the script, http://mysite.com/cgi-bin/test.pl, for example), or, if it's a form related script, add that URL to the action attribute of the form. Read the documentation inside that particular script to see exactly what you should do to awaken it.
12. How do I configure a CGI Script?
This is a pretty general question, and it's hard to answer this for all scripts, but here are the general methods to tackle this question.
First of all, you must know the path to perl. It is located in:
#!/usr/bin/perl
If you have already opened up the script in question in your text editor, check the opening line. If the path to perl is not correct (#!/usr/bin/perl), replace it with the correct path.
Next, you have to look at the certain variables used in the script.
The author usually highlights what each variable is, and what it should be set to.
Usually as well, these variables involve what are called full paths. A full path is the actual location on the server of the file/s in question.
If you are using Windows the path to a file look like this, c:\windows\desktop\myfile.txt. That is a full path in Windows.
UNIX uses a different method for a file system though. The paths look like /virtual/your-account-id/public_html.
Now you are probably asking "How do I find the full path to my site on this computer?". You have two options, copy the following script and put it in your account or run the one we already put in your account at public_html/cgi-bin/env.cgi, run it, and it will output all of your environmental variables, including the path to your root web directory (you may need to chmod 755 env.cgi that is already in your account, so that it will work). Use this script as your guide:
!/usr/bin/perl
use CGI;
use strict;
my $q = new CGI;
my @p = $q->param;
print "Content-Type: text/html\n\n";
my ($key, $value);
print "<pre>\n";
foreach $key (@p) {
$value = $q->param($key);
print "$key => $value\n";
}
print "\n";
foreach $key (keys %ENV) {
$value = $ENV{$key};
print "$key => $value\n";
}
print "</pre>\n";
Remember to copy and paste this into a file made from notepad, save it as env.cgi, and upload it to your account in ASCII format, not binary. Chmod it 755 afterwards. Just access the URL to the script from your browser. If the script that we put in your account public_html/cgi-bin/env.cgi gives you an internal server error when you point your browser at it http://your-domain.com/cgi-bin/env.cgi then chmod 755 env.cgi and it will work.
Now, as you read through other scripts and set there variables, make sure you don't kill the code while you fill them in. If there are quotes surrounding the variable, make sure they stay there, and that there is a semicolon at the end of each line.
After you do so, make sure you upload your script to the server in ASCII mode. Usually your ftp program will give you this option, you should see a button or menu selection for it somewhere.
Once the script is on the server, make sure you chmod it to 755. Test out your script... if it works, but not completely, usually your full paths are wrong. Go back and play around with them until you get it right. Also look in your error logs in the web control panel to find out more about why your script is not performing properly.
13. How do I put form results into a text file instead of email?
There are many free cgi scripts available that can do this task. Do a little searching at your favorite script archive and you should find one within minutes. You could buy a good book on perl programming if you want more control of how scripts behave on your site.
14. How can I prevent others from downloading my results?
You need to make the directory not viewable via the web by using a .htaccess file placed in the directory. See the .htaccess section below for details about this procedure.
15. What cgi scripts do you recommend?
Here are a few scripts that are easy to install and work very well. If you have a script that you like better or is not on this list, let us know and we will review it and if it passes the review we will include it here. We do not offer any support for the scripts listed here. This list is only provided to assist our clients who want to add additional features to there account but do not know where to start. The best source of help with any scripting is the error.log in your account and whomever maintains the script. Please check both of those resources before contacting ABHost.Net for support for the scripts.
In perl scripts the '#' (pound character) is used for commenting, any line starting with the #. The # character is used to write notes and comments. It won't be seen to PERL as code and it is safe to write whatever you want with when a line is prefaced with #, like this:
# This is a comment and will not read as perl code.
One other noteworthy thing about perl scripts, words that start with a '$' (dollar sign) are variables. They are perl code that stand for something else. When a perl script needs to be edited to work with your site you will mostly be writing to lines that start with a $.
Fileman - OK, this script is not that easy to install, however it is worth the effort to install as it is a very powerful site management tool. The script allows you to manage your site via the web with functions such as copying, deleting, moving, renaming and text editing files & directories, you can change file permissions and upload files to your site and password protect directories as well.
To make this script able to manage your entire site follow these steps:
A. On the server at "/virtual/your-account-id/" make a directory named "fileman" put a copy of the script archive in "/virtual/your-account-id/fileman". Make another directory inside of "fileman" named "pass". Now from the command line from inside of "/virtual/your-account-id/fileman" type unzip fileman.zip
you will then see:
Archive: fileman.zip
inflating: fileman.cgi
extracting: fileman.log
inflating: Readme.txt
Set permissions as follows:
/your-account-id/fileman (755) drwxr-xr-x
/your-account-id/fileman/pass (777) drwxrwxrwx
/your-account-id/fileman/fileman.cgi (755) -rwxr-xr-x
/your-account-id/fileman/fileman.log (666) -rw-rw-rw-
B. Whatever way is most convenient for you to edit the "fileman.cgi" do so now. Apply the following changes to the script in the section labeled "Configuration":
# Configuration
# --------------------------------------------------------
%config = (
root_dir => "/virtual/your-account-id/", (give your correct ID)
logfile => "/virtual/your-account-id/fileman/fileman.log", (give your correct ID)
password_dir => "/virtual/your-account-id/fileman/pass", (give your correct ID)
root_url => "http://root.your-domain-name.com", (give your correct domain name)
script_url => "http://file.your-domain-name.com/fileman.cgi", (give your correct domain name)
icondir_url => 'http://abhost.net/icons', (do not change)
The following options are optional:
use_flock => 1,
allowed_space => 350000, (change to this value)
max_upload => 350000, (change to this value)
show_size => 1,
show_date => 1,
show_perm => 1,
show_icon => 1,
show_pass => 1,
version => '1.0'
C. From within the web control panel make 2 new sub-domain names for your account. Call one "file.your-domain-name.com" & "root.your-domain-name.com". Point "file.your-domain-name.com" at the directory "/fileman" & point "root.your-domain-name.com" at "/".
D. From your browser go to http://file.your-domain-name.com and click on "fileman.cgi" and if all went well the script should load and show you the contents of "root.your-domain-name.com". Now you want to apply password protection to the directory "fileman", so that your site will remain secure. Now make a .htaccess file in the directory above "fileman" (/) that contains this line:
Options FollowSymLinks Includes
That is your root directory, it is also known as "/". Now with the .htaccess file in the "fileman" password protects that directory and your "root" directory for your site is secure again because it cannot be viewed with a browser without a link directing it to a specific location in the directory.
Mojo - Fast and easily configuring mailing list system. You only need to configure on file in this package "CONFIG.pm". The script is heavily commented and is easy to follow. Make a directory in your cgi-bin named "mojolist". Put the Mojo archive in the "mojolist" directory and un-tar the archive from the command line with: tar -xvf mojo2_31.tar
Inside the "mojolist" directory, a second directory will be created named mojo. Look in that directory for the file that you need to configure named "CONFIG.pm". Follow the directions in "CONFIG.pm" and you will be up and running in no time.
Mysqlman - This is a powerful script that requires no configuring and it allows you to manage your MySQL database at ABHost.Net from your browser. Put the archive in your cgi-bin and from the command line type:
tar -xzf mysqlman.tar.gz
You now you should have a directory named "mysqlman-1.05", look in that directory for a file named mysql.cgi and your are done. Point your browser at http://your-doman.com/cgi-bin/mysqlman-1.05/mysql.cgi. The login information is as follows, host is "mysql.abhost.net", the username is "your account name" & the password is "your account password". Now you must select your account name from the list, having done that you can now manage your database from your browser.
YaBB SE - Is a full feature discussion forum that has all the features that you could ask for. It is a free script that asks that you leave the copyright present on your site and in the source files. To use YaBB SE without the copyright present you can purchase a site license, cost is $150 US. The YaBB SE program is easy to install and administer.
a) Create a directory in your account that you wish to install YaBB SE into.
b) Change the permissions of the "new_directory" to 777:
chmod 777 new_directory
c) Upload the "yabbse_1-0-0.tar.gz" archive to your account.
d) To unarchive YaBB SE from the command line, type the following command:
tar -xzf yabbse_1-0-0.tar.gz
e) A directory listing will show the following files:
archive.ya
converter.php
install.php
f) With your web browser go to the directory where "install.php" is and click on it to start the installation of YaBB SE. Follow the on screen directions to complete the installation.
16. Where can I get cgi scripts?
http://www.perlarchive.com/index.shtml
http://bignosebird.com/cgi.shtml
http://www.simplythebest.net/cgiscripts/cgiscrip.html
17. If I can't get my cgi to work who do I call?
Your first option and usually best, is to make the script work by doing a little troubleshooting. Once you attempt to run a script via a browser and it does not work you will receive a page that states some kind of error for example:
Software error:
Execution of ./your-script-name.cgi aborted due to compilation errors.
Now you can check the end of your server's error log for additional messages. Go to the web control panel http://abhost.net:411, then go the configure your www server, then select the logs link on that page. The last line on the error log file will show more information about why the script did not work. Also you can run perl -wc your-filename from the command line (telnet or SSH2) to see what is causing the problem. It's often a missing (or mismatched) quote character or a missing semicolon, but could be an incompatibility caused by an earlier version of Perl. If you find out that you are missing a semicolon you can use the command line (telnet or SSH2) to pico your-file-name and add the semicolon to the correct location and now maybe your script will work. Any line in a Perl script that starts with a # is a comment and you should read all of the programer comments to make sure you have done what needs to be done to the script, as asked by the programmer.
If you can not fix the problem yourself then there are many consultants available via the internet to help resolve Perl issues. We are providing a name to help you in the right direction, we are not saying that we endorse them. PerlHelp Hotline: 1-417-546-5593 http://www.perlhelp.com/
For more complete information on most command, you can refer to the online manual by typing man [command] at the UNIX prompt. Some commands you can type [command] --help or [command] -?
Note- when something is specified in brackets like this: [filename] that is to indicate that you type in a filename or whatever. Do not include the brackets when typing the command.
Navigating UNIX:
| / | (refers to the root directory on the server) |
| ./ | (the current directory that you are in) |
| ../ | (parent directory of your current directory) |
pwd (shows what you current directory is - giving the full path):
| ls | (lists all the files in your current directory) |
| ls -al | (lists filenames + information) |
| ls -alR | (lists filenames + information in all subdirectories) |
| ls -alR | more | (lists filenames + information in all subdirectories, pausing when the screen become full) |
| ls -alR > result.txt | (lists filenames + information in all subdirectories, and outputs the results to a file instead of the screen) |
| ls *.html | (lists all files ending with .html) |
| ls -al /account_name/public_html/ken/ | (lists files + info for /account_name/public_html/ken/) |
| cd | (changes you to a new directory) |
| cd images | (changes you to the directory named 'images', if it is contained in the directory you are currently in) |
| cd / | (changes you to the root directory for your account) |
| cd /account_name/public_html/images | (changes you to the directory named 'images') |
| cd .. | (this goes back one directory) |
Moving, Copying and Deleting Files:
| mv [old name] [new name] | (move/rename a file) |
| cp [filename] [new filename] | (copy a file) |
| rm [filename] | (delete a file) |
| rm * | (delete all files in your current directory, be careful) |
| rm *.html | (delete all files ending in .html in your current directory) |
Creating, Moving, Copying and Deleting Directories:
| mkdir [directoryname] | (creates a new directory) |
| ls -d */ | (lists all directories within current directory) |
| cp -r [directoryname] [new directoryname] | (copy a directory and all files/directories in it) |
| rmdir [directoryname] | (remove a directory if it is empty) |
| rm -r [directoryname] | (remove a directory and all files in it) |
Searching Files and Directories:
| find / -name [filename] -print | (search the whole server for a file) |
| find . -name [filename] -print | (search for a file starting with the current directory) |
| find / -name [directoryname] - type d -print | (search the whole server for a directory) |
| grep [text] [filename] | (search for text within a file) |
| sed s/[oldtext]/[newtext]/g [filename] | (searches file and replaces all occurrences of [oldtext] with [newtext] |
File and Directory Permissions:
There are three levels of file permission: read, write and execute. In addition, there are three groups to which you can assign permission. The file owner, the user group, and everyone. The command chmod followed by three numbers is used to change permissions. The first number is the permission for the owner, the second for the group and the third for everyone. Here are how the levels of permission translate:
| 0 = | --- | (no permission) |
| 1 = | --x | (execute only) |
| 2 = | -w- | (write only) |
| 3 = | -wx | (write and execute) |
| 4 = | r-- | (read only) |
| 5 = | r-x | (read and execute) |
| 6 = | rw- | (read and write) |
| 7 = | rwx | (read, write and execute) |
| File Permissions | 1 | Owner | Group | File Size | Last Modified | File Name |
| -rw-r--r-- | 1 | account-name | account-name | 24933 | Apr 15 02:26 | index.shtml |
| Directory | 1 | 1 | 1 | 1 | 1 | 1 |
| drwxr-xr-x | 41 | account-name | account-name | 2048 | Jun 21 13:53 | public_html/ |
| Symbolic Link | 1 | 1 | 1 | 1 | 1 | 1 |
| lrwxrwxrwx | 1 | account-name | account-name | 51 | May 31 08:13 | www.error.log -> /acct-name.log |
Here are the common file permissions:
| chmod 644 [filename] | (permission for www HTML file) |
| chmod 755 [directoryname] | (permission for www directories on ABHost.Net servers) |
| chmod 755 [filename] | (permission for www scripts & programs) |
1. What are SSI?
SSI, or Server Side Includes are basically a feature of CGI (in conjunction with your server) that allows you to dynamically insert a piece of information (such as the current date, any HTML file etc) onto any webpage, and have the browser display it as if it was hard coded onto that page.
SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.
The decision of when to use SSI, and when to have your page entirely generated by some program, is usually a matter of how much of the page is static, and how much needs to be recalculated every time the page is served. SSI is a great way to add small pieces of information, such as the current time. But if a majority of your page is being generated at the time that it is served, you need to look for some other solution.
2. Configuring your server to permit SSI
To permit SSI on your server, you must have the following directive either in your httpd.conf file, or in a .htaccess file:
Options +Includes
This tells Apache that you want to permit files to be parsed for SSI directives. Note that most configurations contain multiple Options directives that can override each other. You will probably need to apply the Options to the specific directory where you want SSI enabled in order to assure that it gets evaluated last.
Not just any file is parsed for SSI directives. You have to tell Apache which files should be parsed. There are two ways to do this. You can tell Apache to parse any file with a particular file extension, such as .shtml, with the following directives:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
One disadvantage to this approach is that if you wanted to add SSI directives to an existing page, you would have to change the name of that page, and all links to that page, in order to give it a .shtml extension, so that those directives would be executed.
The other method is to use the XBitHack directive:
XBitHack on
XBitHack tells Apache to parse files for SSI directives if they have the execute bit set. So, to add SSI directives to an existing page, rather than having to change the file name, you would just need to make the file executable using chmod.
chmod +x pagename.html
A brief comment about what not to do. You'll occasionally see people recommending that you just tell Apache to parse all .html files for SSI, so that you don't have to mess with .shtml file names. These folks have perhaps not heard about XBitHack. The thing to keep in mind is that, by doing this, you're requiring that Apache read through every single file that it sends out to clients, even if they don't contain any SSI directives. This can slow things down quite a bit, and is not a good idea.
In its default configuration, Apache does not send the last modified date or content length HTTP headers on SSI pages, because these values are difficult to calculate for dynamic content. This can prevent your document from being cached, and result in slower perceived client performance. There are two ways to solve this:
- Use the
XBitHack Fullconfiguration. This tells Apache to determine the last modified date by looking only at the date of the originally requested file, ignoring the modification date of any included files. - Use the directives provided by
mod_expiresto set an explicit expiration time on your files, thereby letting browsers and proxies know that it is acceptable to cache them.
SSI directives have the following syntax:
<!--#element attribute=value attribute=value ... -->
It is formatted like an HTML comment, so if you don't have SSI correctly enabled, the browser will ignore it, but it will still be visible in the HTML source. If you have SSI correctly configured, the directive will be replaced with its results.
The element can be one of a number of things, and we'll talk some more about most of these in the next installment of this series. For now, here are some examples of what you can do with SSI
<!--#echo var="DATE_LOCAL" -->
The echo element just spits out the value of a variable. There are a number of standard variables, which include the whole set of environment variables that are available to CGI programs. Also, you can define your own variables with the set element.
If you don't like the format in which the date gets printed, you can use the config element, with a timefmt attribute, to modify that formatting.
<!--#config timefmt="%A %B %d, %Y" -->
Today is <!--#echo var="DATE_LOCAL" -->
This document last modified <!--#flastmod file="index.html" -->
This element is also subject to timefmt format configurations.
Including the results of a CGI program
This is one of the more common uses of SSI - to output the results of a CGI program, such as everybody's favorite, a ``hit counter.''
<!--#include virtual="/cgi-bin/counter.pl" -->
Following are some specific examples of things you can do in your HTML documents with SSI.
When was this document modified?
Earlier, we mentioned that you could use SSI to inform the user when the document was most recently modified. However, the actual method for doing that was left somewhat in question. The following code, placed in your HTML document, will put such a time stamp on your page. Of course, you will have to have SSI correctly enabled, as discussed above.
<!--#config timefmt="%A %B %d, %Y" -->
This file last modified <!--#flastmod file="ssi.shtml" -->
Of course, you will need to replace the ssi.shtml with the actual name of the file that you're referring to. This can be inconvenient if you're just looking for a generic piece of code that you can paste into any file, so you probably want to use the LAST_MODIFIED variable instead:
<!--#config timefmt="%D" -->
This file last modified <!--#echo var="LAST_MODIFIED" -->
For more details on the timefmt format, go to your favorite search site and look for strftime. The syntax is the same.
If you are managing any site that is more than a few pages, you may find that making changes to all those pages can be a real pain, particularly if you are trying to maintain some kind of standard look across all those pages.
Using an include file for a header and/or a footer can reduce the burden of these updates. You just have to make one footer file, and then include it into each page with the include SSI command. The include element can determine what file to include with either the file attribute, or the virtual attribute. The file attribute is a file path, relative to the current directory. That means that it cannot be an absolute file path (starting with /), nor can it contain ../ as part of that path. The virtual attribute is probably more useful, and should specify a URL relative to the document being served. It can start with a /, but must be on the same server as the file being served.
<!--#include virtual="/footer.html" -->
Put a LAST_MODIFIED directive inside a footer file to be included. SSI directives can be contained in the included file, and includes can be nested - that is, the included file can include another file, and so on.
In addition to being able to config the time format, you can also config two other things.
Usually, when something goes wrong with your SSI directive, you get the message
[an error occurred while processing this directive]
If you want to change that message to something else, you can do so with the errmsg attribute to the config element:
<!--#config errmsg="[It appears that you don't know how to use SSI]" -->
Hopefully, end users will never see this message, because you will have resolved all the problems with your SSI directives before your site goes live. (Right?)
And you can config the format in which file sizes are returned with the sizefmt attribute. You can specify bytes for a full count in bytes, or abbrev for an abbreviated number in Kb or Mb, as appropriate.
In addition to spitting out content, Apache SSI gives you the option of setting variables, and using those variables in comparisons and conditionals.
Using the set directive, you can set variables for later use. We'll need this later in the discussion, so we'll talk about it here. The syntax of this is as follows:
<!--#set var="name" value="Rich" -->
In addition to merely setting values literally like that, you can use any other variable, including, for example, environment variables, or some of the variables we discussed in the last article (like LAST_MODIFIED, for example) to give values to your variables. You will specify that something is a variable, rather than a literal string, by using the dollar sign ($) before the name of the variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
To put a literal dollar sign into the value of your variable, you need to escape the dollar sign with a backslash.
<!--#set var="cost" value="\$100" -->
Finally, if you want to put a variable in the midst of a longer string, and there's a chance that the name of the variable will run up against some other characters, and thus be confused with those characters, you can place the name of the variable in braces, to remove this confusion. (It's hard to come up with a really good example of this, but hopefully you'll get the point.)
<!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
Now that we have variables, and are able to set and compare their values, we can use them to express conditionals. This lets SSI be a tiny programming language of sorts. mod_include provides an if, elif, else, endif structure for building conditional statements. This allows you to effectively generate multiple logical pages out of one actual page.
The structure of this conditional construct is:
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
A test_condition can be any sort of logical comparison - either comparing values to one another, or testing the ``truth'' of a particular value. (A given string is true if it is nonempty.) For a full list of the comparison operators available to you, see the mod_include documentation. Here are some examples of how one might use this construct.
In your configuration file, you could put the following line:
BrowserMatchNoCase macintosh Mac
BrowserMatchNoCase MSIE InternetExplorer
This will set environment variables ``Mac'' and ``InternetExplorer'' to true, if the client is running Internet Explorer on a Macintosh.
Then, in your SSI-enabled document, you might do the following:
<!--#if expr="${Mac} && ${InternetExplorer}" -->
Apologetic text goes here
<!--#else -->
Cool JavaScript code goes here
<!--#endif -->
Not that I have anything against IE on Macs - I just struggled for a few hours last week trying to get some JavaScript working on IE on a Mac, when it was working everywhere else. The above was the interim workaround.
Any other variable (either ones that you define, or normal environment variables) can be used in conditional statements. With Apache's ability to set environment variables with the SetEnvIf directives, and other related directives, this functionality can let you do some pretty involved dynamic stuff without ever resorting to CGI.
7. Conclusion
SSI is certainly not a replacement for CGI, or other technologies used for generating dynamic web pages. But it is a great way to add small amounts of dynamic content to pages, without doing a lot of extra work.
Please look at the apache.org web site for all the details on how to do advanced stuff with apache version 2.0. Here is a good starting place at apache.org for implimenting SSI.
1. What is .htaccess?
ABhost.Net is hosting company that hosts multiple domains on one server, and all the domains use the same web server software (Apache) installed on that server. This presents a problem. What if two webmasters using the same server need different web server configurations? That is each webmaster wants the Apache web server to act differently for there respective accounts. Apache addressed this by using .htaccess files.
Apache, like any other software, has configuration files. ABHost.Net edits these "global" configuration files to serve as a default for all of the sites hosted on the server. The .htaccess file (pronounced "h t access") acts as a "local" configuration file, so that individual websites can customize the configuration to suit their needs.
The .htaccess file is an ordinary text file that you can create using Notepad or any text editor and ftp it into your account root directory. This file will contain the configuration statements (commands) to customize the Apache web server software for your website.
Notice that the file name starts with a period (know as a "dot"). The "dot" is to indicate to the Linux/Unix operating system that it is a "system file" that is used by a server application, not by a user of the system (such as an html file would be). However, with Windows, the period denotes a separator between a file's name and its' "extension". As a result, if you try and create a .htaccess file in Windows it won't have a name. To get around this, create a file called htaccess.txt, ftp that to the server, and then rename it to .htaccess once it's there.
Here are some specific properties to know about .htaccess files:
* A .htaccess file must be a plain text file.
* A .htaccess file contains server directives, one per line.
* A .htaccess file applies server directives to a directory as well as its sub-directories.
* A .htaccess file in a sub-directory overrides any .htaccess files found in its parent directories.
* Each line in a .htaccess file that starts with a # symbol is ignored.
2. How do I make a Professional Error Page?
Did you ever notice how some Websites display a nice fancy "Sorry" page instead of the generic, server-generated "404" error page when a nonexistent page is requested? That is a very common use of a .htaccess file and it's very easy to do.
A. Create an html page that you would like your visitors to see if they request a nonexistent file, using all of the headers, graphics, etc. that your other pages have. Save this page with the name error.html (or any name you prefer).
B. Use a text editor to create a htaccess.txt file and enter the following statement into it:
ErrorDocument 404 /error_docs/error404.html
replacing "error_docs" with your directory name and the correct page name if you didn't use "error404.html" in Step 1 above. Then save the file.
C. ftp into your account and create a directory named "error_docs" put the "error404.html" file in the "error_docs" directory and the htaccess.txt file (using ASCII mode) to your Web root directory (or whatever directory your index.html file is in). It is not necessary to CHMOD anything.
D. Rename the htaccess.txt file to .htaccess
Note: After you rename the file it should appear at the top of the file list due to having a "dot" as the first character in the file name. If you don't see it, check your ftp program settings to make sure you have it set to "show system files". (With WS_FTP it's the "Show full directory information" check-box under the "Advanced" tab in the Options window.)
E. Try it out by entering the URL for a nonexistent page on your website.
3. How do I make a password protected directory?
Assumptions
* You have Telnet or SSH software.
* You have FTP access software.
* You have a text editor, such as, Notepad, Simple Text, etc.
* The directory you wish to restrict access to is named: protected
(Your directory name can be anything you wish)
* Your password file is located at /virtual/your-user-id/public_html/protected/.htpasswd
* To simplify this example, we are creating the .htpasswd in the protected directory "protected".
* The names who have access to your protected directory are: dave and julie
Creating the .htaccess File
1. With your text editor on your local workstation create a file named: htaccess.txt
2. Copy and paste the following text into this file:
<Files ~ "\.htpasswd$">
order deny,allow
deny from all
</Files>
AuthUserFile /virtual/your-user-id/public_html/protected/.htpasswd
AuthGroupFile /dev/null
AuthName Password_secure
AuthType Basic
require user dave julie
* The "<Files ~ "\.htpasswd$">" part of the text above prevents others from looking at your .htpasswd file in a web browser.
* The text that appears when the username/password request window pops up is controlled by "AuthName". "AuthName Password_secure" line above can be changed to any label you wish. It is very important that you do not put spaces between words on this line. This example will NOT work: "AuthName Password secure"
* Add as many names with spaces as needed on line "require user dave julie"
* Now upload the file htaccess.txt to your protected directory and change the name to .htaccess
Now we create the Secret Password
A. Log into your account via your shell access software (via Telnet or SSH2).
B. Change to the directory public_html, cd public_html
C. Set permissions on your protected directory to allow the password file to create itself, by typing at the prompt: chmod 775 protected
D. Change to the directory protected, cd protected
E. Create the passwd file and first user by typing at the prompt:
a. htpasswd -c .htpasswd dave
* That command will create the password file for this directory.
b. Go ahead and try the protected directory in your browser now to see your password protection work!
* http://your_domain.com/protected for example.
c. Once done, remember to change /protected back to permissions 755: chmod 755 ../protected
Example Session:
/virtual/your-user-id/public_html $ mkdir protected
/virtual/your-user-id/public_html $ chmod 775 protected
/virtual/your-user-id/public_html $ cd protected
/virtual/your-user-id/public_html $ htpasswd -c .htpasswd dave
New password:
Re-type new password:
Adding password for user dave
/virtual/your-user-id protected$
The password entered is: test
* Note unix passwords are case sensitive.
Create and upload the .htaccess file, as "text," into the /protected directory. The contents of the file are:
<Files ~ "\.htpasswd$">
order deny,allow
deny from all
</Files>
AuthUserFile /virtual/your-user-id/public_html/protected/.htpasswd
AuthGroupFile /dev/null
AuthName Password_secure
AuthType Basic
require user dave juliet
Done. Now Check Web Site...
4. How do I add additional users to a password protected directory?
Assumptions:
* Name of this directory is: protected
* It is working with at least one user name and password.
* You know how to use Telnet.
* You have the FTP username/password to the website.
Step by step:
1. Log into your account via Telnet or SSH2.
Use your host name, username & password.
2. Change to the directory public_html.
The Telnet command is: cd public_html
3. Now change directories again to your secure directory, in this case named: protected
The Telnet command would be: cd protected
4. At the prompt type: htpasswd .htpasswd john
This creates a new user named john
5. You will then be prompted for the new password for this new user.
6. Now check via your web browser to ensure the new username and password works.
7. To add another user name and password repeat steps 4-6.
8. Note also your protected web pages must reside in the protected directory, and the first page must be called index.html or index.htm (unless you wish your files to appear as an FTP site, a directory listing).
5. How do I restrict access by domain name or IP address?
To put a site lock on your web pages, you need to create a file called .htaccess and upload it into the directory that contains the pages you wish to restrict.
This allows all, but denies what you set in the .htaccess file:
<Files ~ "\.htaccess$">
order deny,allow
deny from all
</Files>
<Limit GET POST>
order allow,deny
allow from all
deny from 209.240.200.144 209.240.198
</Limit>
* No one from the 2 addresses listed after "deny from" will be allowed access to your site.
This denies all, but allows some:
<Files ~ "\.htaccess$">
order deny,allow
deny from all
</Files>
<Limit GET POST>
order deny,allow
deny from all
allow from .ncsa.uiuc.edu aol.com
</Limit>
* Only connections listed after "allow from" will be allowed access to your site.
The restrictions put in place by the .htaccess file will affect all of the files in that directory, as well as all files in any sub-directories, so if you want to restrict only a part of your site, it is recommend that you put the restricted pages into their own directory.
The "<Files ~ "\.htaccess$">...</Files>" part of the text above prevents others from looking at your .htpasswd file in a web browser.
Back to Top
6. How to create WWW FTP directory listings (like the Software directory)?
Steps to the Process
Create a file called .htaccess in the directory you wish the contents to be displayed.
The .htaccess file should have something like the following in it:
Options Indexes
DefaultType text/plain
AddDescription "Back to TT Page" ..
AddDescription "Commerce" 1
AddDescription "Education" 2
AddDescription "Visual & Perform Arts" 3
AddDescription "Science & Technology" 4
AddDescription "Nursing & Health Stud" 5
AddDescription "Humanities & Soc Sci" 6
AddDescription "Non-Faculty" 7
AddDescription "Engineering" 8
AddDescription "Law" 9
AddDescription "** ALL SUBJECTS **" all
The first line causes the directory to be listed. The optional second line indicates that, as a default, the files in the directory have the text/plain MIME type. This can be changed as required. The following optional lines allow you to add a description to each of the (expected) files in the directory. The format of these lines are, the word "AddDescription", followed by a string to display (the first 16 characters are used), and the file to display the description for. The file can have wildcard characters as in:
Options Indexes
AddDescription "Text file" *.TXT
AddDescription "MS Word document" *.DOC
AddDescription "MS Powerpoint document" *.PPT
AddDescription "Bin-hex archive" *.hqx
You can also add one or both of the following text files to the directory:
HEADER
README
The contents of the HEADER file gets displayed at the top of the directory listing page. The contents of the README file gets displayed at the bottom of the directory listing page. These two files seem to accept some HTML commands and execute them similarly to html files.
7. How do I make a directories contents not viewable via the web?
Assumptions
* You have Telnet or SSH software.
* You have FTP access software.
* You have a text editor, such as, Notepad, Simple Text, etc.
* The directory you wish to restrict access to is: cgi-bin
(Your directory can be anything you wish)
Creating the .htaccess File
A. With your text editor on your local workstation create a file named: htaccess.txt
B. Copy and paste the following text into this file:
Options FollowSymLinks Includes
C. Upload the file to the directory that you wish to prevent the contents from being viewed, in this case public_html/cgi-bin.
D. Re-name the file to .htaccess
E. Attempt to view the directory with your browser http://your-domain.com/cgi-bin. You should receive a message stating - Forbidden You don't have permission to access /cgi-bin/ on this server.
8. How do I make ".exe" files downlaodable with the browser?
Assumptions
* You have Telnet or SSH software.
* You have FTP access software.
* You have a text editor, such as, Notepad, Simple Text, etc.
* The directory you wish to downloaded from is: /public_html/
(Your directory can be anything you wish)
Creating the .htaccess File
A. With your text editor on your local workstation create a file named: htaccess.txt
B. Copy and paste the following text into this file:
AddType application/octet-stream exe
<Files *.exe>
SetHandler application/octet-stream
</Files>
C. Upload the htaccess.txt file to the directory that you wish to have .exe files downloaded from, in this case /public_html/.
D. Re-name the file to .htaccess
E. Attempt to download an .exe file with your browser http://your-domain.com/program.exe. You should get a popup window asking where you wish to download the file to.
1. How many MySQL databases do I get?
Each web account comes with one database that has no restrictions placed on it. You do not have the permissions to create an additional database on our server.
You do have the ability to create as many tables within your database as you need (unlimited). The only limitation with your database is the disk quota for your account.
The database for your account will automatically be created when you create your web account. All you need to do next is create the necessary tables that your database software needs and then populate the tables with your database information. If you have more than one program accessing your database for different types of data, then point each program at the appropriate tables within the database to achieve the desired results. There is no need to create any additional database if you manage your account in this manner.
2. How do I log into my MySQL database?
Yes, the sql utility is mysql; you can launch it like this after you login from a telnet or ssh2 session:
/virtual/your-domain-name.com $ mysql -h mysql.abhost.net -u USER-NAME -p
You will be prompted for your password.
3. Do I have access to a MySQL utility (ie, to create/modify tables, fields, etc)?
Yes, the sql utility is mysql; you can launch it like this after you login from a telnet or ssh2 session:
/virtual/your-domain-name.com $ mysql -h mysql.abhost.net -u USER-NAME -p
You will be prompted for your password. After which you will receive the following message:
Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is xxxx to server version: 3.22.16a-gamma-log
Type 'help' for help.
If you type help at the prompt.
mysql> help
The following commands are listed.
| MySQL commands: | ||
| help | (\h) | Display this text |
| ? | (\h) | Synonym for `help' |
| clear | (\c) | Clear command |
| connect | (\r) | Reconnect to the server. Optional arguments are db and host |
| edit | (\e) | Edit command with $EDITOR |
| exit | (\) | Exit mysql. Same as quit |
| go | (\g) | Send command to mysql server |
| ego | (\G) | Send command to mysql server; Display result vertically |
| (\p) | print current command | |
| quit | (\q) | Quit mysql |
| rehash | (\#) | Rebuild completion hash |
| status | (\s) | Get status information from the server |
| use | (\u) | Use another database. Takes database name as argument |
Please look at http://www.mysql.com/documentation/index.html for mysql documentation.
(O'Reilly also has a pretty good book on mysql)
4. What does "Can't connect to localhost MySQL server error" mean?
This error occurs when you try to access the MySQL server via "localhost". The correct name is "mysql.abhost.net". Once you replace "localhost" with "mysql.abhost.net" the error will go away.
