aDVENTWEBHOSTING Online Web Hosting Support Manual

The AdventWebHosting operating manual will assist in getting you familiar with the many features we have to offer. Whether you're looking for a quick start to uploading your files, or would like to familiarize yourself with our many advanced features, this manual provides easy to follow step by step instructions on just about everything you'll need to know. New users are encouraged to print this manual and read it over at their leisure.

Assuming you've just signed up with AdventWebHosting, you're probably wondering how to test out a few of the features and begin populating your web site with files. You're just a couple of steps from doing just that, but first things first. Your welcoming email contains the basic information you'll need to access your account and get things underway. Print it out, or open it up in a separate window, as you'll need to refer to it during these tutorials.

Table Of Contents:

These are stated in the welcoming email. They are needed to authenticate everything from FTP, to Email access, C-Panel, and MS FrontPage if you're using it. In short, use this Username and Password for any access you're attempting to your account.

If you've just signed up to AdventWebHosting, chances are you've begun the process of a domain transfer to our servers. In all likelihood, it will take anywhere from 48 to 72 hours for all worldwide DNS records to reflect your domain name as pointing to our servers. While everything in our welcoming email refers to the domain you signed up, we recommended you use the accompanying temporary url until you can verify your domain is actually answering to your new account on the AdventWebHosting servers.

To access FTP, you can use your domain name as the FTP host, or the FTP host that was sent to you in your welcoming email. If you have additional questions regarding the ins and outs of FTP, please see our FTP support section, which covers it in broad detail.

To access your C-Panel account manager, you can login into it with:

http://www.mydomain.com/cpanel (For name based accounts)

or the url that was sent to you in the welcome email. Again, if your domain name is not pointing to our servers yet, calling it with the url from the email will enable access to your account.

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!

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.

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"

- 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!

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!

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"

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."

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

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!

SSH stands for Secure SHell. This is a command line interface identical to telnet. The only difference is that everything done through SSH is encrypted, so if anyone tries to snoop in during your session, they can't read what passwords or commands are being typed.

Before you can start accessing your account with SSH, you need to download an SSH client program. Perhaps the best one out there is SecureCRT, available from VanDyke software at http://www.vandyke.com . It's shareware that you'll have to buy after 30 days of use. Otherwise, you can try looking for SSH clients (including freeware ones) at http://www.tucows.com . Whichever SSH client program you choose to download and install, in order to actually SSH into your account with us, you'll need to use the following settings in your SSH client program:

Protocol: ssh1 or ssh2
Hostname: yourdomain.com (or whatever your domain name is)
Port: 22
Cipher: 3DES or Blowfish
Authentication: password
Username: your account username
Password: your account password

Once you've successfully logged in, you'll be presented with a command prompt that looks something like "bash-2.04$ ". This is where you type commands. Here's a brief list of commands you can use:

ls - (list) this displays the files and directories in your current directory

ll - (long list) same as "ls", but displays some more details

cd - (change directory) when followed by a valid directory name, changes your current directory. Use "cd .." to move back one directory in the hierarchy.

pico - opens up a session with a simple text editor. Following this with a filename will edit that file if it already exists, or will open up a new one under that name if it doesn't exist

du - (disk usage) this displays a list of all of your directories and subdirectories. Beside each one is a number. That number tells you how much space that directory or subdirectory is taking up in KB (1 MB = 1024 KB).

If you like, you can also try using the web-based SSH utility included in your control panel (look for the "SSH Telnet" icon). We can't offer any guarantees on how well it'll work for you. It can be quite buggy at times.

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 forget to name their home page index.html. Here's what happens: they access their site as http://www.mydomain.com, 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 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/filename.xyz

If it can't find index.html, it will simply list "your entire web directory" to everyone that accesses it, which can be a security risk. You should 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 on 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.

However, it is possible to specify the default webpage that visitors see when visiting any of your directories (e.g. http://www.mydomain.com/fun , http://www.mydomain.com/contact , etc.). To do so, you need to create a file called ".htacess" in that directory. Then, just open up that file and add the line

DirectoryIndex filename.xyz

where filename.xyz is the name of the page you want to load by default when someone accesses that folder with a browser. (Note that the file name is case sensitive.) Make sure to save the changes you made to the file.

For example, say you have a page called "home.html" that you want to have load by default when someone goes to http://www.your_domain.com . Just create a new file called ".htaccess" in your /public_html folder and add the line

DirectoryIndex home.html

to it. Now, when someone goes to http://www.your_domain.com , your home.html page will load by default. As another example, say you have another page called silly.html that you would like to load by default when someone goes to your http://fun.your_domain.com subdomain. Just create a new file called ".htaccess" in your /public_html/fun folder and add the line

DirectoryIndex silly.html

to it. Now, when someone goes to view http://fun.your_domain.com (or http://www.fun.your_domain.com, they're the same thing) in their browser, your silly.html page will load by default.

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.

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:

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.

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.yoursite.com/wwwboard";
$cgi_url = "http://www.yoursite.com/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/Faq/www-security-faq.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:

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/Faq/www-security-faq.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.

This is an area, which causes a great deal of confusion amongst both webmasters and end user clients. Before we go any further, let's look at this quick analogy: DNS can be considered something similar to that of a phone book. When you move from one location to another, your last name stays the same, but your phone number may change. In order to point your name to the new phone number, you must contact the telephone service provider, which will assign you the new phone number. In addition, they update all directory information data basis to reflect you as pointing to this new phone number.

What is DNS?

DNS stands for "Domain Name Server." The domain name server acts like a large telephone directory in that it's the master database, which associates a domain name such as (http://www.mydomain.com) with the appropriate IP number. Consider the IP number something similar to a phone number: When someone calls http://www.ADVENTWEBHOSTING.COM/, your ISP looks at the DNS server, and asks "how do I contact ADVENTWEBHOSTING.COM?" The DNS server responds, it can be found at: 128.241.204.205. As the Internet understands it, this can be considered the phone number for the server, which houses the http://www.ADVENTWEBHOSTING.COM web site.

Where are all of the DNS records kept?

This is slightly more complicated, but for the purpose of this overview, we'll try to keep it as general as possible. There are 2 basic places DNS records reside:

International Root name servers (13 exist throughout the world)
Your domain register, where your current DNS settings reside.

When you register/purchase your domain name on a particular "registers name server", your DNS settings are kept on their server, and in most cases point your domain to the Name Server of your hosting provider. This Name Server is where the IP number (currently associated with your domain name) resides.

The entire hierarchy is somewhat involved, but in short, the world Root Name Servers can be considered the master listing of all DNS records, and there are currently 13 of them in the world. These name servers are where all the master DNS records are kept. The DNS server of your ISP will typically query the Root Name Servers once every 24-hours. This is how they update all of their DNS tables, which in turn, resolve www requests to the IP number of the server they reside on.

Changing your Name Server settings, so your domain points to your AdventWebHosting account:

Your "Name Server Settings" must be updated to point to your account on AdventWebHosting. You originally purchased your domain name from a register, and this register is where your current DNS settings reside. That is, unless you transferred your domain name to an alternate register, in which case, you would control your DNS settings from there.

The "Register" your domain resides on, communicates your 'current' DNS settings with the International Root name servers, which is turn share this information with ISP's, routers, and cache engines around the world. In essence, it's like a worldwide directory that other computers can refer to when they want to match a domain name with its associate IP number. This IP number is how the particular server your website resides on is located.

Accessing your domain manager:

Simply go to your domain registers web site, and look around for links, which point to something like, domain manager, manage domain, or something of that administrative nature. In your welcoming email, you were sent DNS settings, which look similar to this example:

NS3.ADVENTWEBHOSTING.COM 130.94.169.93
NS4.ADVENTWEBHOSTING.COM 130.94.169.94

Most of the newer registers such as the (OPEN SRS) based entities have turned this into a 5-minute process. You simply login to the register, select 'manage domain' and you'll be presented with an option to update your new DNS numbers. Contrary to popular belief, Network Solutions 'now' also provides an online interface to change these settings, so this process with them is no longer as complicated as it use to be, however it's still not as simple as the OPEN SRS based systems. If your particular register 'does not' provide a domain manager of some type, then you'll need to send them a message requesting a change of DNS. This is an unlikely scenario, as most every register now allows you to manage your own domain settings from a web based interface.

Once you've accessed the "management interface" of your domain name, look for a setting, which says "change or manage DNS settings." In most cases, you can simply cut and paste the DNS settings we've sent you directly into the spaces, which correspond to your DNS management settings. Remember, the DNS settings we're displaying here are an "example."

The 3 to 4 day propagation period - Understanding what happens during this time frame:

In short, patience is a virtue. Remember what we talked about earlier in this chapter regarding the shear size and scope of the worlds DNS system? In short, when you change your DNS settings, these new settings must propagate throughout the worlds DNS servers. It also means that every ISP (Internet Service Provider), must update their DNS records to reflect these new changes, which in most cases, is done automatically every 24 hours, but not always however...

Where do the Root Name Servers receive their information from?

The Root Name Servers will query "domain registers" several times a day. Domain Registers, being entities such as Network Solutions, and the newer OPEN SRS based systems. The Root Name Servers will gather this information from the many registers now in existence, and update their master records accordingly. Now your ISP must access the Root Name Servers, and update their DNS records, which reside on their 'local' DNS server. This process is fully automated and most ISP's will check the Root Name Servers for updates every 24-hours. Beware however, that some lame ISP's will delay this process for as much as 2 to 4 days in some cases. If that happens, it will no doubt cause additional confusion, as everyone else will be reaching your new account on our servers except you. This is because your ISP has not updated their DNS records, and or have not cleared their DNS cache, which means they'll still be pointing your domain name to your old server. If it's a new domain name you've registered, then you'll receive a blank "Site Not Found Page."

DNS Cache and your ISP:

There is also the issue of DNS cache, which is something we won't go into great detail about here, but here's the short version. Every time you access a site from your ISP, they cache the URL, as well as its associated IP number. If their network is properly setup, these DNS cache records should "Expire" at least every 24-hours. If they did not (which is often the case), you'll experience this: You enter your http://www.mydomain.com/ URL, and it keeps taking you back to your old server account.

In a large number of cases, it's the result of an ISP who "Did Not" configure their servers to "Expire" the DNS cache records at the appropriate intervals. Unfortunately, this adds additional confusion to their clients, and especially the ones whom are trying to point their domain name to a new server. Yes, it will make you want to scream sometimes, however if you understand whom is actually at fault, then you'll know who to scream at :)

The DNS propagation process is not limited to ISP's!

HA.. Just when you thought you had it all figured out! Unfortunately, there's more folks. The Internet itself must update/clear its DNS cache as well. When we say the Internet, we mean the numerous intermediate "points of access" you're routed through before reaching your final destination. For the most part, these intermediate points of access consist of "Internet Routers" and "Internet Caching Engines." These too, maintain their own DNS cache, which assists them in routing traffic/resolving URL's to the correct destination IP's. Don't worry though, as Internet routers are usually faster at clearing their DNS cache than ISP's are.

What to expect during this 2 to 4 day propagation period:

In most cases, the propagation process will take at least 48 hours to complete. The first thing that happens is the "World Root Name Servers" will check all of the various "Domain Registers for updates. Ok, so now the Root Name Servers have done their job. The rest of it is up to the many ISP providers who "should be" updating their DNS records (at least every 24 hours), but a number of them will not.

Side effects that can be expected during the propagation time frame:

It's perfectly normal for strange things to happen within the 48-hour propagation period, but sometimes longer. While we could provide a full list of all the anomalies that can occur during the DNS propagation period, we'll stick to some of the most common scenarios that most people experience:

HELP! My friends can reach my new site, but I'm still being directed to the OLD ONE!

This is a class case of your friends ISP (who did update their DNS records), but yours unfortunately did not. As a result, your ISP is still pointing your domain name to the old DNS record, which is your old hosting account. Wait a couple of more days, and if it appears that everyone but you can access your new account, then contact your ISP and tell them to expire their old DNS cache records.

WOW! http://www.mydomain.com was taking me to my new AdventWebHosting account just a minute ago, but when I try it now, I'm being taken back to my old hosting account - what's up with this?

In all likelihood, your ISP may be in the process of clearing their DNS cache, and or updating their local DNS server records. During this small interval, it's normal to fluctuate between the new and old web site, as the old DNS records may not have completely expired from their cache yet. Give it another several hours and it should be fine.

HEY! My new site comes up for me, but my friends are being directed to my old one!

Break out the coffee and donuts, and consider yourself lucky. Your ISP is on the ball and updates DNS records/ clears DNS cache in short regular intervals. Your friends may be using an ISP, which is not as fast, and or efficient at doing so. The only remedy for this is time. Eventually, the other ISP's DNS cache will expire and be replaced with the updated DNS records.

What's going on with my email? When I try to access it, I receive a "host does not exist" or a "cannot authenticate" error message.

This can happen for a number of reasons, but in most cases, it's because your new DNS records have not fully completed the propagation process yet. Consequently, you may be trying to access your old email account on your "old server", which you may have already cancelled, or it's in a state of DNS flux, which means it points to the new server one moment, and the next, points back to the old server.

Give it some more time and it will eventually settle down. In the meantime, consider accessing email from your account using the WebMail based reader. If your domain has not propagated as of yet, you can access your email account via WebMail with your temporary url. Example: http://12.23.36.78:2082/neomail/neomail.pl This will allow you to access your default mailbox on your account. Replace the tempurl with the one we sent you, and do not remove the :2082 port number in the URL.

Microsoft FrontPage will not accept a Username and Password, or displays the error message (FrontPage Extensions Are Not Installed).

While you should be able to access FrontPage with your associated temporary URL (until your domain is resolving to our servers), this is not always the case. FrontPage can behave in a number of different ways depending on which direction the wind is blowing. In some cases, it will allow you to initiate an upload session, but upon asking for your Username and Password, will not recognize them. If this happens, the best thing to do is wait until your domain name is answering to our servers. One thing we know for sure, is FrontPage will work without much of a problem if you're using the full www.mydomain.com URL to manage your site with. Feel free to try it with your temporary url, but we cannot guarantee it will work.

It's been over a week. Everybody else can access my new site except me!

Was your domain originally hosted by your ISP? If so, they may not have deleted this entry in their DNS files. This results in you, and or anyone else accessing the net from this "particular ISP" being directed to your old web site on their servers. A number of ISP's forget this small detail, which can result in weeks of utter confusion and frustration. If this is happening to you, contact your ISP and make sure they've made the necessary changes to their DNS records.

Checking your DNS update status (outside of your ISP):

In the event you're becoming impatient, and or are wondering if the rest of the world outside of your ISP can access your new site, you can proxy yourself to another network and test it there. In many cases, you'll be surprised to see your site responding perfectly, yet when you attempt it directly from your ISP's servers, it does not exist.

There are several services, which allow anonymous surfing across the net. While this is not the intent here, they can be used for trouble shooting domain resolution problems. How? Because they proxy you through their network, which means your URL requests are controlled by "their" DNS cache records. These services update/expire their DNS cache far more often than ISP's, which makes them well suited for testing your domain name through a network, which operates with the latest DNS updates across the web.

To run this check, you can try accessing your site through one of these two services:

https://www.safeweb.com/o/_s:top.php3
http://www.anonymizer.com/

Both of them allow you to enter a URL, and proxy your request through their servers. If your site is accessible from these servers, then chances are, your ISP has yet to expire their old DNS cache records.

Working on your account during the DNS propagation period:

You can still work on your new account until your domain name finds it way to our servers using your temporary url, which was included in your welcoming email. Using it at this point will provide a means for you to access your account, as well as test your new site by using something like http://yourtempurl.com/ (obviously you'd replace it with the url we sent you).

One easy way to check and see if your domain is answering to our servers yet, is to create a file called "test.html" and place it in your web directory. Keep checking the URL http://www.yourdomain.com/test.html and see if it works. When it does, you'll know your domain name is answering to your account on "our servers", and has been officially transferred.

The personal DNS (for advanced webmasters).

Personalized Name Servers are generally used by webmasters who will be reselling web hosting accounts, and want to add a professional look to their DNS. Why? If you're reselling accounts under your own entity, you could use our name servers, which would be sent to your customers in the form of:

NS3.ADVENTWEBHOSTING.COM 130.94.169.93
NS4.ADVENTWEBHOSTING.COM 130.94.169.94

Not bad, but what if you want your DNS settings to appear as a part of your company? Let's say your company was www.acmewebhost.com. If you desire, you could setup your own custom branded DNS, which could display as:

DNS.ACMEWEBHOST.COM 130.94.169.93
DNS2.ACMEWEBHOST.COM 130.94.169.94

This provides a somewhat more professional look to your customers when sending out your DNS settings in a welcoming email. In addition, if someone does a WHOIS lookup on your domain name, it appears as your personal DNS, as opposed to the company you're reselling for. Not really a big deal, but some webmasters do not want to advertise the host they're reselling for, as they feel it does not portray a professional and independent look.

Personal name servers are offered to clients whom are a part of our reseller program. If you're not a reseller, please use the standard DNS settings we provided you. There is no superior advantage to having your own name server unless you're a reseller, and or a web designer who is also planning on hosting the websites they build.

A sub domain is one, which resides under your top-level domain name, but in many ways behaves as a "totally independent domain". You'll observe that many of the larger corporations use these, as they're somewhat more professional looking, and do a better job of creating an independent precedence for service or product lines, which appear as separate web entities.

Example: You're a GM dealer with a site such as GM.com. You sell everything from Pontiac's to Cadillac's. To better organize your online presence, you could create sub domains for your various automotive lines. These would appear as http://pontiac.gm.com/ or http://cadillac.gm.com/. Also note that in most cases, the domain need not be called with the http:// or www protocol.    pontiac.gm.com can be called exactly how it appears here.

Setting up a sub domain:

1. Click sub-domains in cpanel.

2. Next type in the name of the sub-domain you want to make.
    (Note: Do not add www. or http:// this will render the sub-domain useless.)

3. Click add. The sub-domain will be added and you will get a confirmation page.
4. You have added a sub-domain.
5. If a folder already exists with the same name as the sub-domain the sub-domain will point to the folder.
    IE: folder.your-domain.com will go to your-domain.com/folder

Independent cgi-bin

All new sub domains are created with their own independent cgi-bin. This means your new sub domain operates independently of everything else, and is almost like having a whole new domain. Feel free to configure all cgi scripts, which are pertinent to the functioning of this sub domain. A nice feature, as it saves your main cgi-bin from becoming cluttered and somewhat disorganized; especially if you utilize a lot of cgi programming.

Additional domains added to your account.

We allow you to point multiple domains to an account. Our policy about multiple domains is as follows:

- If secondary domain points to the primary domain such that both take a visitor to the same place, there is no charge for setting that up.

- If secondary domain points to subdomains of primary domain such that visitors arrive at different places within your account, then we will charge you $2 per month for each additional domain.

Please note that you will not be able to create email and ftp accounts with additionally pointed domains. All the emails sent to any address at additional domains will be forwarded to your default email account of your primary domain.

The difference between private pop mail accounts, and simply using the "Catch-All" method:

There are two kinds of email address's you can use, starting with the "catch all" method:

With the catch all method, you don't have to worry about setting up individual pop mail accounts. Simply set your email client to your "default" email address (displayed in C-Panel), and "all" email sent to anything@yourdomain.com will land in this box, or whatever you've set your default address to. This is an easy way to catch all email sent to your domain.

In your Email client, feel free to configure multiple outgoing accounts at many-different-names@youdomain.com. It really doesn't matter, as everything@yourdomain.com will land in the default account. Therefore, you would configure all of your email accounts with the "same" Username and Password as your "Default domain Email Account."

EXAMPLE: Let's say you want to receive mail from dianne@yourdomain.com and mark@yourdomain.com. If both of these addresses are the ones you'll be using, then the only thing that changes is the address - the Username and Password is "always" the same.

In this case, you configure a "private" pop email account for one or many users who will be receiving and sending email from your domain. Once an email address is configured as a pop mail account, it operates privately and independently from your main standard/default mail system. Any mail sent to a private pop mail account "can only be received" by logging into that account with the separate username and password you have assigned it.

Your default "catch all" account will not intercept any mail being sent to a pop mail account, which is what makes it 'private'. Pop 3 accounts are useful if there are a number of people (for example employees) who would each need a private email account.

This way, everyone at your company can utilize private email. The default email address plays a slightly different role in this case: If a sender uses the 'wrong' Email name or syntax, then that message would bounce to your "default catch all" account, and at which time, you could probably figure our who the sender was trying to contact. They do however, have to at least send it to your correct domain name, (i'e', oops@youdomain.com). This would end up in your "default" mailbox.

1. Login to C-Panel
2. Select "POP email accounts"
3. Enter an email name
4. Enter a password
5. Select "Create"
Just enter a name, (the @yourdomain part is added automatically)

That's it, done! Your private pop 3 email account is now ready for use. If you're a little lost on how to manually configure an email account into your mail reader, please see the detailed tutorials on how to configure Outlook and Netscape mail readers.

SPECIAL NOTE!

If you've enabled Sub-Domains, you'll observe a duplicate email account appearing, which corresponds to each sub-domain you've added. Please ignore these duplicate addresses for the time being. This is a new feature under development and will soon enable the ability to configure email accounts for your sub-domains. For example, if you configured support.yourdomain.com, then you'll be able to use the address mailto:tom@support.canada6000.com.

For the time being, please configure email address's that correspond to your "regular" domain, and just ignore the sub-domain duplicates. ALSO: Any duplicate sub-domain email address's you see appearing in your pop mail setup configuration "DO NOT" count towards your allocated number of pop mail boxes we've provided. In short, just ignore them for now :-)

It appears pretty simple, but read through this documentation, as this controls much more that you'd expect. As mentioned in the previous chapter, your "default email address" is the one, which can be used as a "catch all", or in other words, to "catch all mail", which is addressed to anything@yourdomain.com. Using a catch all can be a blessing and sometimes a curse.

The "catch all" is excellent if you have a high frequency of people whom mistype your email address, as these addresses (even though mistyped), will simply be bounced to your "catch all" or "default" email account. That is, providing they at least managed to spell your domain name properly :)

If you're not planning on using multiple "private email boxes", then you can keep life very simple - just configure the default email address in your mail reader and leave it at that. This way, you'll receive everything sent to your domain. There are indeed pro's and con's to this method, which will be discussed in this tutorial.

Setting your default/catch all email account:
Default Email Address Interface

Note: By default, or until you change it, the default email address will be the same as your "login name."

1. Login to C-Panel
2. Select "Default Address"
3. Enter a desired default email address
Enter the complete address.

Select "Submit" and you'll see a confirmation box, which displays your new default email address. That's it- done!

Remember: In order to receive mail, which finds its way into your "Default Mailbox", you must configure the default address in your mail reader. If you don't, then all mail, which bounces to this address will sit on the server unread. This is easy to do in Outlook Express, as it allows you to configure and monitor multiple email accounts. Email readers such as Netscape on the other hand, are limited to "one" email account. Actually, you could re-configure your mail reader to check your default email box every few days, but who wants to be bothered with that trouble? We suggest using an email reader, which allows you to configure multiple email accounts.

The Webmail Alternative: You can also check your default email account, or another other mail account by logging into it through the "WebMail" interface. Simply select the "WebMail" icon at the bottom of C-panel, and log in to it using your "Main Account" Username and Password. This will allow to to check your default email box, as well as other mailboxes without having to configure them

Operating Manual

Table Of Contents: