Your Topper
 
 
 

 
 

 

 
Where to upload your files:

 

The Home Directory:


Your html files, and or the files you want to make accessible to the World Wide Web must be uploaded to your account. When you first FTP into your account, you'll be taken to your "Home" directory. Don't confuse this with your "web directory." The home directory is "not" accessible to the World Wide Web; it's a private directory where critical system files reside. DO NOT delete files that have been created by the system, otherwise your web site may disappear into cyber oblivion!

 The public_html and www directory - (Where web accessible files are placed)

These are the two directories, where files you want accessed from the web must be placed. Open the folder "public_html" , which is your "web accessible directory." The folder named "www" is actually a shortcut to public_html, (both of them take you to your web directory). Upload the files you want accessible to your visitors and feel free to make the appropriate sub-directories you'll require.


Configuring FTP Clients:


 

Configuring Cute FTP
Based on version 4.2
Cute FTP

Please note that there are a number of older and current versions of Cute FTP floating around. As a result, some of the instructions provided here cannot possibly reflect all the versions, which have been released in the past 5 years. The only small difference you may encounter is where some of the options can be found (depending on the client version you're using). In any event, everything is pretty well much the same. Let's get started:

1. Open Cute FTP
2. Select "File"
3. Select "Site Manager"
4. Select "New"
 


Options you'll see:
cute-ftp.gif (10027 bytes)
 

- Label for site: Enter a name for this account. For example, "My Root Account."
- FTP Host Address: www.mydomain.com
- FTP Site Username: Your main system login name
- FTP Site Password: Your main system password
- FTP Site Connection: Port: 21
- Login Type: Normal

 


Notes About Cute FTP:

There are a few advanced features you may want to be aware of. These features may need to be enabled if you're having problems accessing your site via an FTP client. The following will explain:

Trouble accessing your site via FTP:

This can sometimes occur if your accessing the Internet from behind a firewall, personal router, or using an Internet connection sharing system such as NAT (Network Address Translation). This is often a class case scenario in a home or small office where several computers are being shared by one Internet connection.   Symptoms include, difficulty logging in via FTP, and or maintaining a reliable upload or download session.


Use Passive Mode instead:

From your FTP main interface, select:

1.
Edit (from the main dropdown menus)
2. Settings

A dialog box called "Settings" now appears. Select:
3. Connections
4. Firewall

This opens the Connection/Firewall dialog box:
5. Check the box that says "PASV mode."
6. Click OK
Don't touch any of the other settings
cuteftp-firewall.gif (19541 bytes)
Ignore all other settings you see here except for the "PASV_mode" setting!


Give it a try and see how it works. If you're still having problems, you should contact your ISP to see if they can make the necessary changes required for you to access your site via FTP. There are a vast number of network configurations ISP's sometimes use, and some of which that can cause problems for users wanting to access the web beyond that of a browser.

How to view all files in your account (For Advanced Users).

Advanced users may want ability to view "all hidden" files in their directories. While most of these are critical system files, there are a few, which can be manually edited by "Advanced Users." This is done by inserting an entry into the "File Masking" feature in the client.


Unmasking Hidden Files:

1. Open Cute FTP
2. Go to the site manager
3. Select your account
4. Select
"Edit"
mask1.gif (7973 bytes)
 

A dialog box opens called "Site Properties":
1. Check the
"Enable Filter" box
2. Click the "Filter" button
3. Check the " Enable Remote Filters (Server Applied Filer) " box
4. In the "Remote Filter" window, type this command -a
5. Click ok
That's it!


mask2.gif (8617 bytes)
 

The -a command will unmask "all" files in your web account.
 

Final Note:

NEVER REMOVE OR ALTER FILES, WHICH HAVE BEEN CREATED BY THE SERVER or C-Panel!!   Unless you're an advanced user, please leave all files that have been created by the system alone! Doing otherwise could cause serious problems with your account, and in some cases take it offline completely. When in doubt "ASK", do not Delete!


Setting Up WSFTP

WSFTP Pro

Please note that there are a number of older and current versions of WSFTP floating around. As a result, some of the instructions provided here cannot possibly reflect all the versions, which have been released in the past 5 years. The only small difference you may encounter is where some of the options can be found (depending on the client version you're using). In any event, everything is pretty well much the same.

Setting up WSFTP:

1. Open your WSFTP client
2. The dialog box "WS_FTP" Sites should display. If not, click the "Connect" button.
3. Select "New"

You should see this dialog box:
wfstp-configured-sites.gif (7841 bytes)
 

You'll be taken through these options:

1. New Site/Folder: Choose a name for this account

new-site.gif (4165 bytes)
 

2. Host Name or IP address: www.yourdomain.com

wsftp-host-name.gif (2993 bytes)
 

3. User ID: Main system login

4. User Password: Main System Password
5. Select "Save Password."

wsftp-login-information.gif (3880 bytes)

6. Select "Finish."
Done! Your can now FTP into your site


 

Notes About WSFTP:

Main Username and Password:

The main Username and Password was sent to you in your welcoming email, and are also the same ones used to access C-Panel. If you've changed your "main" Username and Password before setting this up, then use you must use them instead.

 

Trouble accessing your site via FTP:

This can sometimes occur if your accessing the Internet from behind a firewall, personal router, or using an Internet connection sharing system such as NAT (Network Address Translation). This is often a class case scenario in a home or small office where several computers are being shared by one Internet connection.   Symptoms include, difficulty logging in via FTP, and or maintaining a reliable upload or download session. If this is the case, try "Passive Mode."

Setting Passive Mode:

1. Open the WSFTP account manager

2. Highlight your account

wfstp-configured-sites.gif (7841 bytes)

3. Select "Properties"
4. Select the "Advanced" tab

wsftp-site2.gif (5432 bytes)
 

5. Check the box called "Passive Transfers."
6. Click "OK"
 

wsftp-advanced.gif (8206 bytes)
 

Select passive mode, click "OK", and try it again.

How to view all files in your account (For Advanced Users).

Advanced users may want ability to view "all hidden" files in their directory. While most of these are critical system files, there are a few, which can be manually edited by "Advanced Users." This is done by inserting an entry into the "File Masking" feature in the client.

Unmasking Hidden Files:
1. Open the WSFTP account manager
2. Highlight your account
3. Select "Properties"
4. Select the "Startup" tab
5. In the "Remote File Mask" window, enter -a


wsftp-mask.gif (6569 bytes)
 

The -a command will unmask all files in your web account.


Final Note:

NEVER REMOVE OR ALTER FILES, WHICH HAVE BEEN CREATED BY THE SERVER or C-Panel!!    Unless you're an advanced user, please leave all files that have been created by the system alone! Doing otherwise could cause serious problems with your account, and in some cases take it offline completely. When in doubt "ASK", do not Delete!


Understanding the web site file system:


index.html and why you should use it:

This again is where a number of newer webmasters become stumped. They upload all of their files and directories, and then want to access them with their browser, but forgetting to create their welcoming page as index.html, so here's what happens: They access their site as http://www.mydomain.com/ or using the associated IP number, for example, http://test.html/, and what they see is their entire file directory structure! Yikes!… It looks just like exploring the C drive on your computer! You don't want visitors seeing that, do you?

When you access your site by calling it as
http://www.mydomain.com or the assigned IP (for example), http:// 217.74.132.26/, the web server looks for the "index.html" file as the (default file) to be sent to visitors, and thus this is why http://www.mydomain.com/ by itself will automatically display the home or welcoming page. It's because the server automatically looks for index.html whenever a domain or directory is called without a filename appended to it such as this, http://www.mydomain.com/file.html

If it can't find index.html, it will simply list "your entire web directory" to everyone that access's it, which is a MAJOR security risk! ALWAYS, use an "index.html" file in any directory you create, including your "root" web directory. In general, it's always a good idea to use "index.html" as your main page in "all sub-directories" of your account. Forgetting to place an index.html in your root web, or any subdirectory of your web for that matter will effectively leave all of its contents viewable to the world.
 

Understanding case sensitivity:

Another small detail, which can throw many newer users into a tailspin. Unlike your local PC, the Unix file system is very particular about "uppercase" and "lowercase" file names. Therefore, if you were to install a script, (let's say the wwwboard discussion forum) for example), the name of this script would be wwwboard.pl.  If you name a file picture file called me.jpg, then this is what you must call it as.  Naming it me.JPG for example, (observe the uppercase) tells a Unix web server to treat it as a totally different file name.

Unix file servers are exceptionally fussy on this issue, so make sure you pay close attention to "case' when uploading files, or installing and configuring cgi based scripts. The same rule applies for all files including your .html pages. Again, the server treats .html and .HTML as two entirely different files. Want to keep in simple? Try to stick with lowercase letters in all file names and extensions.


Uploading your files in the correct mode (ASCII or Binary)?

Uploading in the wrong format for images or binaries will result in a strange mess appearing in place of the file.  For CGI scripts, this mistake has to be the most common cause of that annoying error known as the (Server 500 Error - Malformed Headers), or something to that lovely extent. While this can be the result of many various programming errors, the most popular amongst new users are uploading their scripts in the "WRONG" format. Your cgi scripts "MUST" always be uploaded in ASCII mode. Alternatively, if you upload an image or .exe file, it must be done in "BINARY" mode.


The difference between ASCII and BINARY?

In short, html or text based files are supposed to be transferred in ASCII mode. Uploading them in Binary mode will append ^M's to the end of every line. In most cases, this is OK, with html files because your browser will ignore them. BUT, with other text files such as cgi scripts, uploading them in binary will damage them, thus causing a (server 500 error). This is because binary mode has added ^M's to the end of every line, which are not supposed to be in the program. This of course, is what causes the additional message of (Malformed Headers), which often displays at the bottom of the "Server 500" message when a CGI script has crashed.

Once again, BINARY mode is used for transferring executable programs, compressed files and all image/picture files. If you try to upload an image in ASCII mode, you observer a strange mess appearing on the page where the image is suppose to appear. ASCII mode in this case, has corrupted the binary coding in the jpeg or gif image. If this happens, just re-upload it in the Binary format
 

Setting your FTP client to automatically detect ASCII and Binary file transfers:

Most FTP programs have "AUTO" mode, which will tell the FTP client to automatically detect the file type you're transferring and will select the appropriate mode. By default, most FTP programs will attempt to transfer everything in binary mode, but when "Automatic" is selected, the FTP client will check a list of known ASCII extensions, (for example, .pl, .cgi, .txt). If it detects one of these extensions, it automatically switches to ASCII mode.

By Default, most of the well-known files to be uploaded in ASCII are already entered, however you can manually add additional extensions that you would like to transfer in ASCII mode by selecting the feature called "Extensions." Here, you can any additional extensions that will cause the FTP client to toggle to ASCII mode automatically upon detecting an extension entered in its list. Remember, you must set your transfer mode to "Automatic" for this to work.
 

File types and what they represent:

Various file types can effect both the behavior of your files, as well as how the server treats them. While there are numerous file extensions, which represent a host of various file types, we'll stick to the basic ones in this quick overview:

The .html file:

This is one is the most commonly used and the most one of you are already familiar with. Html stands for (hypertext Markup Language). Essentially, it tells the server, as well as the clients browser to process and display the .html coding in a way, which is meaningful to the end user through a browser.

The .htm file:

Many of you have probably noticed this newer extension appearing in place of the traditional .html one. In short, .htm is most often created, and or generated from the Microsoft FrontPage web editor. The two are essentially the same and provide the same basic purpose. Unless you're using FrontPage, you will probably use the .html extension at the end of your web pages.

The .gif and .jpg file:

Most commonly used because of its good compression in web page images. Generally, .gif files are the fastest loading, as they remove a lot of information, which is not required to maintain image integrity, but to a point however. .jpg will allow more flexibility in compression and quality settings, however can also result in larger files.

The .CGI and the .pl file:

.cgi and .pl are most often used for perl scripts. Perl scripts are small text based programs, which are executed on the server end, and will perform a host of interactive functions for a web site. In short, when a .pl or .cgi file is called, it tells the server to process it using the "Perl Interpreter." The Perl Interpreter understands the programming within the script, and will perform the set of sub routines, which will yield your desired effect. This desired effect could be anything from a simple web page counter, to more complex programs such as discussion forums, e-commerce platforms, to online auctions. In many cases, you can download these "ready to go" scripts for free, and in others you may have to purchase them.
 

FrontPage and FTP:

If you're planning on using Microsoft FrontPage to manage your web site, there are a couple of issues things you may want to keep in mind:

There are two worlds. The General Unix hosting world, and the Microsoft world. While this is not necessarily a bad thing, Microsoft had indeed decided to play by its own rules.   As a result, FrontPage does not always conform to the rules of Unix, so you should be extremely careful when accessing a FrontPage web via FTP.  It's easy to damage the FrontPage web, as well as it's associated server extensions, and if it happens, you may loose the ability to administrate it from your FrontPage Explorer. To avoid problems like this:

    Do not alter, or delete files that are part of a FrontPage web

    Do delete, move, or alter directories ending in _vtf. These are the FrontPage extensions

The ultimate solution:

If possible, try to create your FrontPage webs in sub-directories of your root. For example, http://www.yourdomain.com/home. This way, you can safely FTP into your root account to perform other tasks, while avoiding the FrontPage webs, which are safely out of the way in their own separate homes. Remember! DO NOT delete any folders, which end in _vtf! This will kill your FrontPage web, and we'll have to reinstall the extensions for you. For additional information on FrontPage, please see our dedicated tutorial on it.

 

Using CGI programming:



Where to place your CGI scripts:

Although there is nothing dangerous about placing cgi scripts in random directories throughout your site, it's best if you keep them in their own little home known as the cgi-bin. This minimizes security risks and allows you to maintain your cgi programs from one directory.


The path to Perl:

One of the first things you must do when configuring a script, is set the correct path to the Perl interpreter, which is the engine responsible for processing the script. The path to Perl on our servers is: #!/usr/bin/perl


The path to Sendmail:

Some programs such as the ones, which send email will need to know where the Sendmail program resides on the server. The script will typically have a setting like this: $mailprog = '/usr/sbin/sendmail'; and will want you to set it appropriately. Sendmail on our servers can be found here: /usr/sbin/sendmail or  /usr/lib/sendmail.


Setting directories within your cgi scripts:

When you configure a cgi script for "any" server, it may ask you to set variables such as the base, relative, and CGI directory/url settings. Here's an "example" using Matt Wright's wwwboard.pl script. Obviously, each script may vary, but this should provide you with some basic idea:

$basedir = "/home/yourlogin/public_html/wwwboard";
$baseurl = "http://www./wwwboard";
$cgi_url = "http://www./cgi-bin/wwwboard.pl";

Most scripts come with documentation on how to set these directories. Please make sure you read and understand it before configuring the script. New to cgi? Here is a page with questions and answers to numerous questions evolving around the inns and outs of using cgi within your scripts:
http://www.w3.org/Security//www-security-.html  Another excellent site, which provides step by step chapters is: http://www.cgi101.com/class/



Understanding File Permissions:

There are a number of file permissions, which can be used for a variety of different purposes, however we'll limit this tutorial to the ones most commonly used. To begin with, it's important you understand the three categories of permissions, which are:


Owner Permissions:

The owner is you. In most cases, this is not so much of a concern, as you can only obtain owner permissions in one of two ways. 1. FTP into your account using your Username and Password. 2. Login via Telnet with the same information.

Group Permissions:

The represents a group of users who have access to a particular directory. For example, a password protected directory, whereas only members can access it upon providing the correct Username and Password. In this case, any permissions you assign to "Group" would be applicable to users with access to that particular directory.


Public Permissions:

This is the most important one of all. Public permissions determine what your world wide visitors can and cannot do with your files. ALWAYS make sure you understand what a particular permission does before assigning it to a file. If not, you may wakeup to find your website demolished by some clown who was snooping about and gained access to your files.


Setting File Permissions:

chmod-interface.gif (7809 bytes)

To set file permissions:

1. Login with your FTP client
2. Open the directory where the file you wish to set permissions on resides
3. Right click on the file and select CHMOD
A box similar to the one above will appear

Observe how you can "select" the individual permissions you want, or simply enter the 3 digit number if you know what it is. Most instructions included with downloaded scripts will tell indicate this to you.

By default, all files uploaded to the server automatically have permissions set to 644. The setting 644 is relatively safe, as it provides "Read" and "Write" access to the owner, while limiting the rest of the public to "Read Only" access.

When setting permissions for cgi scripts, the most common permissions setting is 755.   755 allows the owner "Read and Write" access, while allowing the Group and Public "Read and Execute" permissions. So what are we actually saying? In short, when users access your cgi script, the server has been instructed to grant them permissions to "Read and Execute" it. Sound scary? It's not actually…

Remember that a script is a program that must be processed by the server. As long as the script is written properly, you can safely allow users to execute it, and thus providing the desired results. For example, if they wanted to post a message to your wwwboard discussion forum, then they would need these permissions to execute wwwboard.pl, which would write their new message to an html file, which is displayed on the main forum.   The new message would reside in a directory on your site so other users could view it. Most cgi, perl and other scripts you'll be installing come complete with instructions telling you which permissions you'll need to set them to.


WARNING!

Setting permissions on files is a relatively simple task, however MAKE SURE you fully understand what it is you're allowing the public to do with your files. For example, some less experienced users often make the fatal mistake of simply setting ALL of their files to 777. While 777 will automatically allow executing privileges, it also allows full "READ, WRITE, and EXECUTION ability to the entire world!!!!

This is how web sites get hacked! While most visitors have good intentions, all it takes is one person whom snoops about your files seeking an "Open Back Door." This could result is them gaining full access to your directories, which means they can do anything from deleting your entire site, to defacing it with obscenities.


New to cgi? Here is a page with questions and answers to numerous questions evolving around the inns and outs of using cgi within your scripts:
http://www.w3.org/Security//www-security-.html  


Using Server Side Includes - SSI

SSI works in conjunction with a web page usually with the .shtml extension.  The .shtml extension tells the server to do something different with the web page. When you append the .html or .htm extension, this tells the server to "read" the page only. The .shtml extension tells the server to "Execute" the page, in addition to just reading it.

So, why would you want to execute the page? There are various commands you can program into a web page, which the server will look for and parse when the file is called as .shtml. In many cases, this mode is used in conjunction with Server Side Include (SSI) tags, to call a CGI script. For example, you have a visitor counter script, and we'll call it count.cgi. Every time someone visits your website, you want the script to be called, so that it logs the visitor into a file.


To do this, you would place an SSI tag into your web page. The tag in this case, would look something like:



This small tag, which is hidden in the html coding of your page is telling the server to:

1. Go to the cgi-bin
2. Execute count.cgi

That's it! The information has been captured and processed by the count.cgi script. Of course, that's the short version of what happens. The long version would no doubt, would take us far beyond the scope of this document.

PLEASE do not use the .shtml extension on "all" of your web pages unless it's absolutely necessary. With a busy web site, this means that every page must be executed, as opposed to just read. This as you can appreciate, can add considerable memory and CPU load to the system. As always, read the instructions that came with your script carefully.   They should provide specific instructions on how to configure the script, as well as the SSI tag. 

 
 
 
 

 



Click Here

Website Hosting Domains Ebooks and Scripts