+----------------------------------------------------------------------+
| *** THE BIGNOSEBIRD.COM NEWSLETTER *** |
| Placed at your virtual door in beautiful plain text |
| Be sure to stop by http://bignosebird.com/ today! |
| Everything You Need to Create and Maintain Great Websites |
+----------------------------------------------------------------------+
| June 26, 1999 Issue #3 |
+----------------------------------------------------------------------+
GREETINGS!
Here is the third issue of the BigNoseBird.Com low volume newsletter.
Our thanks for allowing us to add just one more deperately needed
item to your inbox.
This week, you will find two rather long tutorials on PATHS and
PERMISSIONS. These two topics make up about 98% of the script questions
I receive. Even if you don't script, save this someplace- it may
come in handy some day!
Another hot topic in the e-mail bin has had to do with e-commerce
and secure servers. I must say it has been great watching everyone's
evolution over the past couple of years.
This newsletter rates an 8.9 on the Geekfactor Scale....
**----------------------------**
SECURE SERVER TIPS
Recently I have been getting inquiries as to whether or not the
BNBFORM (http://bignosebird.com/carchive/bnbform.shtml) script can
be used on a secure server. The answer is "YES"- BUT!
The script should be configured to only write the information to a
properly protected directory. If you have the form actually send
you e-mail, well- that e-mail is unencrypted and sort of defeats
the purpose of having encrypted it in the first place.
The only change you need to make is to actually install the script
in the correct directory and call it like this:
ACTION="https://secure.yourdoman.com/cgi-bin/bnbform.cgi"
(EXAMPLE ONLY!)
The major difference between secure and unsecure pages is the service
name. Notice the "s" in "https"? This indicates a call to a secure
server instead of an "insecure" one. ;-)
Here are the gory details.... The normal webpage requests (HTTP) are
delivered on IP Port #80. Huh? Okay. Let's say you have a server
such as BIGNOSEBIRD.COM. If you ping BIGNOSEBIRD.COM, you will see
something like:
64 bytes from 207.252.75.17: icmp_seq=0 ttl=64 time=1.1 ms
The IP number is 207.252.75.17. Of course a server does much more
than serve up web pages. It allows FTP file transfers, E-mail,
telnet, and other services.
Each service runs on what is called a "port". Some common ports
are:
Service What it does Port Number
------- ------------ -----------
http delivers regular web pages 80
telnet allows remote logins 23
ftp file transfers 21
smtp e-mail handling 25
https secure web pages 443
So as you can see, the big difference between regular and secure web
is that regular is on port number 80 and secure is on port 443. Of
course there are exceptions, but they are rare.
To properly configure BNBFORM (or any script) to run on a secure
server, write to your host and ask the following questions:
1.) How do I call my pages (URL), i.e.,
https://secure.mydomain.com/cgi-bin/script.cgi
or https://mydomain.com/cgi-bin/script.cgi
or https://mydomain.com/secure-bin/script.cgi
2.) What is the full path to the secure script directory?
3.) What are the proper permission settings for scripts and
data files?
**----------------------------**
HOW SECURE IS SECURE?
There is a lot of stuff floating around these days regarding
privacy on the Internet. I think that Scott McNealy at Sun
recently said something to the effect, "You never had any
privacy- get over it." Makes sense in a way. Here's something
to think about... How much privacy do you have a traditional
brick and morter store?
I swear this is true. My wife once sent me to get her "something"
at the local super-pharmacy. The cashier had to involve half
the store's employees in finding out the correct price. It
even involved using the PA system!
As a quick follow-up to the information above on secure servers,
I ask the question: "How secure is the data on the server?" Most
people do not realize that just because they send something over
a secure connection that the risks do not end there.
SSL (secure sockets layer) only prevents two types of attacks:
Ones where a person sets up a server to try and impersonate yours,
and ones where somebody tries to "sniff" or intercept and read
your traffic.
Once the data is written to disk, it is not protected anymore
than data sent by regular http. It is important for you to know
who can access the directories containing your customer's data
such as credit card numbers, or other personal data that might
be of a sensitive nature. Ask your hosting company or system
administrator about who can access your secure directories.
Ask what care is taken with back-up tapes. Get the idea?
You should also check with your host about a secure method
to get the data off their server. Regular FTP is NOT secure!
Ask if they have "ssh" or some other method available. You
can also create a secure script in a password protected directory
to download the file to your browser, but that shall be a lesson
for another day...
**----------------------------**
WHO'S YOUR HOST?
A lot of people are always asking me to recommend hosting companies.
I have limited my suggestions to those that I have used or have
checked out by installing scripts, etc... Are you happy with your
hosting company? If you are please let me know. Any information you
can provide on script configuration would be useful as well.
Are you a hosting company? Want to be listed on a site that gets
over 4500 different webmasters every day? Tell me about your service.
A test account with telnet is always helpful. I like to see if I
can port BNB in 30 minutes or less to a new server. ;-)
Please send your information and POSITIVE ONLY comments to
ispinfo@bignosebird.com
Just so everybody knows.... I do not have any interest in any
service you either see recommended or advertised on BNB. I've
had hosting companies advertise who never even asked for a
review. If a conflict of interest ever comes up, I will let
you know about it.
**----------------------------**
THE POOP ON PATHS
I would have to say that at least half the script questions that I get
(and can't answer) have to do with paths. Even if you don't mess with
scripts, read on anyway as this information can also help you layout
and manage your website
Knowing your path information is critical if you need to run scripts
that will either read from or write to a file(s). The path tells the
script exactly where to find the file that must be opened. Without
this information your script will fail.
They say that there are million ways to skin a cat. What they don't
tell you is that usually one will end up with an unhappy cat. Well,
there are a million ways to partition (split up) a hard drive, and
as many ways for a system administrator to name directories. When
it comes to the directories containing both CGI scripts and HTML pages
there are no rules whatsoever. (there are rules dealing with how to
let the web server software know where they are)
It is due to this flexibility, that as a webmaster you have the chore
of either reading your hosting companies FAQs, or writing them to ask
the following questions:
1.) What is the absolute path to my cgi script directory?
2.) What is the absolute path to my main html directory?
Let's take a moment to discuss the two major types of paths, relative
and absolute.
ABSOLUTE PATHS
--------------
An absolute path is one that describes the exact location of a file
so that no matter where a script is executing, the script can find the
file. Examples would be:
Unix: /usr/local/apache/share/mydomain/cgi-bin/datafile.dat
Windows: C:\websites\mydomain\cgi-bin\datafile.dat
The advantage to an absolute path is that you do not need to know
what directory your script is actually executed in. Confused? I
don't blame you. Whenever a program is run, it must "know" what
directory it is running in. The problem is that the directory the
script is running in- is usually not the directory where the
script is actually located! This is due to security reasons.
When you can- ALWAYS use the full absolute path information in
your scripts.
Here is a twist for you. In the example above we are dealing with
the actual location of a file on the computer. When we are working
with web pages from within HTML, the absolute path is from your
DOCUMENT_ROOT, not the root path of the computer! If you have a
page called "index2.html" under a subdirectory called "docs", the
absolute path from within HTML would be "/docs/index2.html", NOT
"/usr/local/apache/share/mydomain/html/docs/index2.html".
RELATIVE PATHS
--------------
A relative path does not start with a forward-slash or in the case
of windows- a drive designator. Relative paths are useful if you
know exactly what directory your scripts are executed from, and
want to be able to move your scripts easily between servers. Here
are some examples:
File in "working" or "executing" directory: "filename.dat"
File in subdirectory under cgi-bin: "subdir/filename.dat"
File in html directory, i.e., a guest book. Assumes that the
HTML and CGI directories are on the same level "../html/guest.html"
My advice is to stick to absolute paths!
**----------------------------**
SOME BITS ON PERMISSIONS
If paths make up half the questions on scripts, the other half
have to do with unix file permissions! Here is everything you
need to know about setting these little nasties up correctly.
You must find out the following information from your system
administrator or hosting company before you can sucessfully
and properly install a script.
1.) Does the server run as "me", or as some other user?
2.) By default, can I have scripts create files in my CGI
directory?
3.) What are the proper settings for permissions for the
following:
A.) Data files that need to be written to.
B.) Scripts to be executed.
C.) Subdirectories created under my CGI directory.
Armed with this information, you should not have too many
problems getting your scripts up and running.
Do not be tempted to start by granting full permissions on
your files. ONLY GIVE THE MINIMUM permissions needed to make
your script work!
For the curious, here is the scheme used by the system for
dealing with permissions, along with some practical settings.
If you look at a unix directory listing of your cgi directory,
you might notice that the lefthand column consists of nonsense
such as:
drwxr-xr-x apache nobody BBS
-rwxr-xr-x apache nobody card.cgi
-rw-r--r-- apache nobody datafile.dat
Let's start by disecting the information about card.cgi
Owner(user) Group Others
----------- ----- ------
rw- r-- r--
This tells us that for this file that apache (the owner) can read and write
to the file. Group members of "nobody" and all others can only read the file.
So, make a quick mental note: There are three types of permission that can
be assigned based on three types of ownership.
There are two ways to set file permissions, using telnet and logging in to
use the command line, or via FTP.
READ WRITE EXECUTE EXECUTE
ONLY &READ &READ READ/WRITE
---- ----- ------- ----------
OWNER 4 6 5 7
GROUP 4 6 5 7
OTHER 4 6 5 7
If you are using the telnet method, the above is a handy chart for getting
your "chmod" command straight.
Here are some examples:
chmod 755 scriptname.cgi This is the NORMAL permissions for setting a
cgi script!
Owner can read/write/execute, group/others can read/execute
chmod 644 datafile.dat This is the NORMAL permissions for a data
file when the web server software runs as "you".
Owner can read/write, group and others can only read.
chmod 664 datafile.dat This is the NORMAL permissions for a data
file when the web server software runs as a member of your
group.
Owner and group can read/write, others can only read
chmod 666 datafile.dat This is the NORMAL permissions for a data
file when the web server software runs as a user that is
not a member of your group. Typical on free hosting servers.
The 666 is not a coincidence! Anybody on the system can edit
a file with these permissions.
DIRECTORIES: A SPECIAL CASE!
----------------------------
In our little directory listing above, there is an entry:
drwxr-xr-x apache nobody BBS
Notice the "d" at the start? This indicates that BBS is a directory-
not a regular file. This has a minor impact on the permission settings.
The EXECUTE in this case does NOT mean execute, but GRANT SEARCH
permission. In order to allow a script to see a file, or for the server
to see the script if it does not run as you, the EXECUTE must be turned
on!
Owner(user) Group Others
----------- ----- ------
d rwx r-x r-x
In this example, "chmod 755 BBS" created the permissions. If you are in
a situation where the web server runs as "you", this would be the proper
settings. This would also work if the server is not running as "you"
and you do not want the server to write to the subdirectory.
Here are some other possibilities:
chmod 775: server runs not as you, but a member of your group.
Owner/Group can search/read/write, others can only
search/read.
chmod 777: This is the setting you must use when the server does
not run as you, and is not a member of your group. Typical
on free hosting sites. This means that anyone on the system
can write to your directories.
**----------------------------**
SHAMELESS BEGGING
Okay, no pride here! If you see someplace that you feel that
BigNoseBird.Com should be listed, you have my permission to
handle the submission. BNB's popularity is due almost completely
to word of mouth recommendations, and any assistance you could
provide if you feel BNB worthy would be greatly appreciated.
**----------------------------**
REALLYBIG NETWORK
Looking for cool stuff and information for your sites? The
REALLYBIG network consists of:
http://reallybig.com/default.shtml Over 3000 Web Master Resources
http://dynamicdrive.com/ JavaScript & DHTML Resource
http://fontpool.com/ Over 1000 Searchable Fonts
http://bignosebird.com/ Yours truly!
We are a linked group of lunatics that really enjoy what we do!
+----------------------------------------------------------------------+
| You received this newsletter only because you, or somebody visited |
| BigNoseBird.Com and entered your name into the subscription form. |
| If you do not wish to receive further mailings, please go to |
| http://bignosebird.com/ and enter your e-mail address in the form |
| and select UNSUBSCRIBE. If you do not wish to receive this low |
| volume newsletter, we do not want to annoy you, or waste the |
| bandwidth. We are VERY ANTI-SPAM! |
+----------------------------------------------------------------------+
