| SilverStar
Support
>> User Manual
Online
Operating Manual
The
Online 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 us, 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:
Account Basics:
Where
to upload your files:
Configuring your
FTP clients:
Understanding
the web site file system:
CGI Based Programs:
The ins and outs of
DNS and how it effects your domain:
Setting up and
managing Sub-Domains:
Setting
up Domain Email:
Account Basics:
Username and Passwords:
These
are stated in the first paragraph of the welcoming email. Until you
change them, they're 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.
NOTE:
When submitting a tech support issue to the help desk, you'll be asked
for a separate username and password. DO NOT use your 'main account'
username and password for the login! You can select a "Help Desk"
username and password upon your first visit to: https://helpdesk.silverstarsites.net
(where all support issues should be sent).
Accessing your account via its URL or associated
IP number
If
you've just signed up, 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 you 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
"IP" number until you can verify your domain is actually answering to
your new account on our servers.
The
IP we've provided you will soon be registered to your domain name.
Until such time as your domain is officially answering to our servers,
you can use your new IP to access and setup your web site. For
example, if your assigned IP was 66.78.6.147, your welcoming email would
provide the URL http://66.78.6.147/ as an option for
accessing your new account. Again, it's a great way to test all
those features and make sure everything is functioning smoothly before
launching your web to the world.
Accessing "IP-less" accounts:
Many
of our account packages are IP-less accounts. This means the IP is shared
with several domains, as opposed to being dedicated to "one." There
are a couple of small differences on how you access these accounts,
and most notably how you access the them before your domain name is
officially pointing to our servers. Instead of calling the account with
a plain IP number, you call it with an IP and "your associated Username."
Both of these were sent to you in your welcoming email. Let's try an
example:
Your username is frank
Your IP is 157.238.46.11
To reach your account via the web, you would call this site as: http://157.238.46.11/~frank/
Don't forget the ~ before your name! Also remember that the IP we're
using in this case is an "example." Check your welcoming email for the
IP number and Username, which was assigned to your account. Once
again, when your new DNS settings have propagated across the worlds
DNS servers, you'll be able to access your domain by calling it the
standard way, which is http://www.yourdomain.com.
Accessing your account
via FTP:
These accounts are accessed in generally the same way as a dedicated
IP account would be. Again, if your domain name is not officially pointing
to our servers yet, use the IP and Username, which 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.
Accessing C-panel:
To
access your C-Panel account manager, you can login into it with:
http://www.mydomain.com/cpanel
or
http://216.74.122.26/~frank/cpanel/
(Make sure to change the IP number to the one we sent you)
Again, if your domain name is not pointing to our servers yet, calling
it with your IP will enable access to your account.
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
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:
-
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 you're 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
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"
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!
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
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:
You'll
be taken through these options:
1. New Site/Folder: Choose a name for this account
2. Host Name or IP address:
www.yourdomain.com
3. User ID: Main system login
4. User Password: Main System Password
5. Select "Save Password."
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, thenyou must use them instead.
Trouble
accessing your site via FTP:
This can sometimes occur if you're 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
3. Select "Properties"
4. Select the "Advanced" tab
5.
Check the box called "Passive Transfers."
6. Click "OK"
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!
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:// 216.74.122.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. A URL with
a filename appended to it would look like:
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:
Yet,
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 create a 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'll 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 add 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 side, 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 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 create 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 this 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
not 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.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 web pages:
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 upon logging in with their
username and password.
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:
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/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:
<!--#exec cgi="/cgi-bin/count.cgi" -->
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.
The ins and outs of DNS and how it effects your domain:
Understanding DNS and Name Servers:
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.venturesonline.com/,
your ISP looks at the DNS server, and asks "how do I contact venturesonline.com?"
The DNS server responds, it can be found at: 157.238.46.231. As the
Internet understands it, this can be considered the phone number for
the server, which houses the http://www.venturesonline.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 "registrars
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 VenturesOnline account:
Your "Name Server Settings" must be updated to point to your account
on VenturesOnline. You originally purchased your domain name from a
registrar, and this registrar is where your current DNS settings reside.
That is, unless you transferred your domain name to an alternate registrar,
in which case, you would control your DNS settings from there.
The "registrar" 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 registrars 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:
DNS.VOSN.NET 66.78.4.6
DNS2.VOSN.NET 66.78.6.147
Most of the newer registrars such as the (OPEN SRS) based entities have
turned this into a 5-minute process. You simply login to the registrar,
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 registrar '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 registrar 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 registrars" several times a
day. Domain Registrars, being entities such as Network Solutions, and
the newer OPEN SRS based systems. The Root Name Servers will gather
this information from the many registrars 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 Registrars 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 classic 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 VenturesOnline 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 IP number. Example: http://12.23.36.78:2082/neomail/neomail.pl
This will allow you to access any mailbox on your account. Replace the
IP number with the one we sent you.
Another
good idea while propagation is ongoing is to check both your old and
new hosting accounts for email. That way you won't miss any email that
might be delivered to the old hosting account during propagation. You
can do this by adding both account profiles in your email client (ie:
Outlook Express, Eudora, etc.). Simply use the IP addresse of your new
and old hosting account as the incoming mailserver (POP server). That
way you know that you are not going to miss any email during propagation.
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 IP
number (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 IP, 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:
http://www.anonymizer.com/
This
allows 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 "IP Number", which was included
in your welcoming email. Your IP number is how your new domain will
be identified on our servers. 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:// 216.74.122.26/
(obviously you'd replace it with the IP number 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:
DNS.VOSN.NET 66.78.4.6
DNS2.VOSN.NET 66.78.6.14
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 66.78.4.6
DNS2.ACMEWEBHOST.COM 66.78.6.14
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.
If
you decide to use your own personal nameservers, you need to be aware
of the steps required to activate these nameservers. There are 3 steps:
1.
Create the nameservers on the server where your account is hosted. We
do this for you before we assign you your nameservers.
2.
Your registrar needs to create these nameservers in their database.
You need to contact your registrar to accomplish this task.
3.
Once the nameservers are created by the registrar, you will be able
to use them for the domain you resell.
Step
2 is quite often forgotten and is the most common mistake that resellers
make with regards to personal nameservers.
Setting Up Sub Domains
What is a Sub-Domain?
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:
Thanks
to C-Panel, this task has been made easier than ever and can be achieved
as follows:
1. Login to C-Panel
2. Select Sub Domains
3. Enter the name of your new sub domain
4. Hit "Add"
That's it! Your new sub domain is now ready for use. To find it, login
to your "main web directory" through C-Panel by selecting "files" or
simply use your favorite FTP client. You'll see it residing as another
directory. Upload your files to this directory just as you would with
any other. For example, if you created pontiac, then a directory called
pontiac is what you'll be looking for.
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.
Configuring Domain Email Systems:
Adding a Pop Email account:
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 accounts with your
reply/from address as 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.
The pop email account method:
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.
How to configure a pop mail account:
1.
Login to C-Panel
2. Select "Add/Remove accounts"
3. Select "Add Account"
4. Enter an email name
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.
Setting Your Default Email Address:
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:
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. Select "Set Default Email Address"
4. Enter a desired default email address
Enter a full email address to receive your default/catch-all email.
Select
"Change" and you'll see a confirmation box, which displays your
new default email address. That's it- done!
You should
still make a habit of checking the default POP account that comes with
your account on a regular basis.
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 your other mail accounts 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
in your mail reader. In fact, using any pop accounts "Username
and Password" will log you into that particular account through the
"WebMail" interface.
The downside of enabling "Catch All":
Problems can sometimes arise when Spammers or junk mailers use this
feature as a means to pump their trash into your mailbox. As long as
the "catch all" is enabled, then all they must do is send to whatever@yourdomain.com
and it will reach you.
On
the other hand, if you're using "specific pop email accounts", you could
opt to disable the "catch all", which would mean that "only visitors
or associates who you've given a specific address to" can send mail
to a particular email account on your domain.
In
this case, everything else, (that you have not configured as a pop mail
account) is bounced back to the sender. In our opinion, we suggest leaving
your "catch all" enabled for the time being. If Spammers begin sending
random junk messages using anything@yourdomain.com,
then you can disable your "catch all" feature.
Disabling
your "Catch All Feature"
To disable enter the following for your default email address:
:blackhole:
This
will discard any incoming email that is unrouted
:fail:
no such address here
This
will bounce all email that is unrouted back to the sender.
What
happens now?
When Spammy or Jimmy junk mailer attempts to use a random email address
to Spam you, it will be bounced back to them. That is, unless they happen
to get a hold of one of your "legitimate pop email account names", in
which case, you'd have a different problem on your hands. Yes, you could
either deal with it, or change the address.
So what actually happened here?
When the "Catch All" email address (:fail: no such
address here), attempted to process an incoming message from
anything@yourdomain.com,
and then forward the (junk message in this case) to the "catch all/Default"
email address, it freaked out, and said forget it!! The
default email address was set to ":fail: no such address here" in this
case, so the sending process was aborted. Therefore, the mail system
bounced back the above error message to the sender. There are numerous
tricks and special recipes you can 'manually' write into the Unix email
system for doing essentially the same thing, however through C-Panel,
this would certainly seem the easiest way of accomplishing the task.
Configuring Email Auto Responder's
What
is an Email Auto Responder?
Email auto responders will automatically send a customized auto response
(that you compose) to any visitor whom emails the address configured
with one. More specifically, automated responses are sometimes used
to send additional information about your service or product by having
a visitor email something like moreinfo@yourdomain.com.
In most other cases, they are used to send a 'courtesy reply' to anyone
whom sends a query to your companies main email address. When
visitors email this address, they recieve a response such as: Thanks
for contacting our company! Someone will be returning a response to
your question soon. If you require immediate assistance, please call
555-222-1212. Thanks!), and so forth.
There are two types of Auto Responders:
The silent Auto Responder:
In this case, you configure the responder to send the desired information
when it's emailed, however you 'do not' receive copies
of the inquiries that people originally sent. This method is typically
used if you have a product and want people to email an address
for additional information on it. You simply tell them to email
moreinfo@yourdomain.com,
and they receive additional information on it. Again, you 'will
not' receive receipts of the visitors emailing the auto responder. If
you want to do this, please read the next paragraph.
The Auto Responder that sends you the original
inquiry:
In this case, the auto responder is setup to work with a (currently
configured pop email account). Now, the sender receives your
automated response, and you receive their 'original inquiry'.
How to setup an Auto Responder:
1.
login to C-panel
2. Select "Auto Responders"
3. Select "Add Auto Responder"
4. Enter the "Email Address" to send the
auto response
5. Enter a "From" name, (for example, my company)
6. Enter a "Subject", (for example, thank you)
7. Enter your message in the "Body" area
Select
"Create" and that's it! Your auto responder is now online. To
test it, email its address and see if you receive the auto response.
If you've configured it to an existing pop mail account, you should
receive 2 responses. The first, which is your inquiry, (that you just
sent to yourself), and the second, which will be the automated response.
Remember!
If you want to receive the "Incoming Inquiries" in addition
to sending the automated response, then add an email address, which
is "already" configured as a "pop email account." If you "do
not" wish to receive the original incoming inquiry, then simply enter
a name, which "Is Not" configured as one of your existing pop mail accounts.
If at anytime you want to update, edit, or delete an auto response,
simply go back into "Auto responders" and you'll see the current responders
configured, as well as options beside each of them to change or delete.
Blocking Unwanted Email Messages:
From
time to time, you may experience either a junk mailer or some other
menacing individual whom keeps sending you annoying email messages.
C-Panel has a built in feature, which allows you to block these email
messages in a multitude of different ways. You can block them by:
- Sender
- Subject
- Message Header
- Message Body
Of course, if all you want to do is block one specific email address,
then you don't have to worry about getting fancy with it - just enter
the email address to be blocked, and that's it, done!
How to use the block email function:
1.
Login to C-Panel
2. Select "Block an Email"
3. Select "Add Filter"
If
all you want to do is block a single email address, then simply leave
the "current default setting" as is, and enter in the email address
to be blocked. For example, annoying-nolife@nothingbettertodo.com
Click "Add Filter", and that's it done!
When you click "Back" or login to this feature next time, you'll see
the list of email address's, and or expressions you've blocked. Beside
each one of them will be a "Delete" option, so that you can remove the
block from your account at a future time. NOTE: When
you block an email address, or some other keyword, this filtering will
be enabled on "All Email Accounts" within your domain.
Advanced Blocking:
For those of who whom experience frequent problems with junk email messages,
you'll be please to see this option provides a broad range of blocking
options. Instead of having us try to explain every last one of them
here, this is a feature you'll really want to experiment with yourself.
Doing
so, will allow you to become familiar with the ways that email can be
blocked, and will also help you with customizing a recipe that works
best for your domain. Play around with the settings, and try to block
words, or phrases based on the From Name, Subject, or Message Body Text.
Now, send an email to your account and see if the terms and criteria
you selected are providing the filtering you want.
It may take a little time to master, but it's fun, and a great way to
broaden your abilities on web site administration. FINAL NOTE:
If you're totally new to email blocking, and wish to explore its full
potential, we highly suggest you test it before launching your site.
This way, you don't have to worry about accidentally disrupting email
for your entire domain.
Hint:
Unless you're 100% sure of what a setting will do, always delete it
when you're finished, or until you have time to run a series of tests
on it. You want to ensure it's blocking what it's supposed to, and not
legitimate email messages!
A big junk mail problem:
If you're experiencing a high volume of junk mail, then there's a good
possibility Spammers are taking advantage of your "catch all" option.
To disable this, please see our tutorial on "Default Email Address."
|
