BigNoseBird.Com- home Small Logo
The 508 compliant guide to 
       Big Nose Bird
Return to the Newsletters Page

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




Find or Give Help on the BBS
 
Home Top E-Mail
If it looks great, it's by Christine
Some Fine Print
© 1997-2003 BigNoseBird.Com®, Inc. All rights reserved. All other trademarks are the sole property of their respective owners. The products that we recommend are only ones that we use. We have no relationship with any of the authors or their companies. We cannot assume responsibility for their ultimate performance or lack of same. We also cannot assume responsibility for either any programs provided here, or for any advice that is given since we have no control over what happens after our code or words leave this site. Always use prudent judgment in implementing any program- and always make a backup first! For further information, please read our Privacy Statement. We can be contacted at webmaster@bignosebird.com.


<reallybig.com>
Web Builder Network Portal
Advertise
on the
Reallybig.com
Network
BigNoseBird Newsletter
Subscribe
Un-Subscribe


Sign up today to receive our low volume newsletter. Tips, tricks, news, and whatever else crosses our minds.
Back Issues
Privacy Statement