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: http://www.allnethost.com/support/helpdesk/index.pl
(where all support issues should be sent).
Accessing your account
via its URL or associated IP number
If you've just signed
up to Allnet, 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 the Allnethost 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 64.44.9.198, your welcoming
email would provide the URL http://64.44.9.198/ 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 A20, A50
and A100 "IP-less" accounts:
A20, A50 and A100
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 teddy
Your IP is 190.187.39.45
To reach your account via the web, you would call this site
as: http://157.238.46.11/~teddy/ 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 the 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.
To access your C-Panel
account manager, you can login into it with:
http://www.mydomain.com/cpanel
(For name based accounts)
or
http://216.74.122.26/~teddy/cpanel/ (For
IP-less accounts, but, 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:
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.
If you're planning on
using Microsoft FrontPage to manage your web site, there are
a couple of issues things you may want to keep in mind:
There are two worlds. The General Unix hosting world, and the
Microsoft world. While this is not necessarily a bad thing,
Microsoft had indeed decided to play by its own rules.
As a result, FrontPage does not always conform to the rules
of Unix, so you should be extremely careful when accessing a
FrontPage web via FTP. It's easy to damage the FrontPage
web, as well as it's associated server extensions, and if it
happens, you may loose the ability to administrate it from your
FrontPage Explorer. To avoid problems like this:
-
Do not alter, or
delete files that are part of a FrontPage web
-
Do delete, move,
or alter directories ending in _vtf. These are the FrontPage
extensions
The ultimate
solution:
If possible, try to create your FrontPage webs in sub-directories
of your root. For example, http://www.yourdomain.com/home.
This way, you can safely FTP into your root account to perform
other tasks, while avoiding the FrontPage webs, which are safely
out of the way in their own separate homes. Remember! DO NOT
delete any folders, which end in _vtf! This will kill your FrontPage
web, and we'll have to reinstall the extensions for you.
E-MAIL
CLIENT SETUP
Microsoft
Outlook Express
-
Open
Outlook Express
-
Move
to the "Tools" drop down menu and select "Accounts."
-
Select
"Add Mail" from the "Right" menu option
-
In
the "Email Box", enter the email address for this
account and click "Next."
-
Set
"Mail Server Names" illustrated below and then
click "Next"
Incoming mail POP3 put mail.yourname.com
Outgoing mail SMTP put mail.yourname.com
-
Enter
the "Login and Password" for this email account
and highlight the remeber password box, "Note".
Account name and Password are the
same as your FTP login you recrived in your welcome email.
Click "Next"
-
Click
"Finish."
That's pretty well it! Close your account
settings and test out your new address by sending a message
to it. If you're able to send a message, and receive that
same message in your new account, then congratulations!
- you've successfully setup your first email account on
our servers.
-
Open
Netscape Browser
-
Move
to the "Edit" drop down menu and select "Preferences."
-
From
the "Left Menu" select "Mail and Newsgroups",
then click the + symbol, which displays a list of options.
Select "Identity." Enter the "email address"
of the account you're setting up, and "your name"
-
From
the "Left Menu", select the "Mail Servers"
tab and enter your appropriate information . Incoming
mail POP3 put mail.yourname.com
Make
sure to use the "full Email Address" of the account
you're setting up as the "username." When finished,
click "ok."
-
Configure
your "Outgoing Mail Server", settings that correspond
to your domain name, Outgoing mail SMTP put mail.yourname.com.
Click "OK" when finished.
That's
pretty well it! Close your account settings and test out
your new address by sending a message to it. If you're able
to send a message, and receive that same message in your
new account, then congratulations! - you've successfully
setup your first email account on our servers.
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:
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.
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.allnethost.com/,
your ISP looks at the DNS server, and asks "how do I contact
allnethost.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.allnethost.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 Allnet account:
Your "Name Server Settings" must be updated to point to your
account on Allnethost. 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.
Our Name Servers are as listed below
Name
Server Information
ns1.allnethost.com
ns2.allnethost.comThe "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,
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...
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.
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.
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 drectory. 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.
|
|
