Section ShortCuts: Introduction Using Multiple Accounts Web Page Directory and index.html How to Upload Files Web Servers for Your Domain CGI Imagemaps Web Page Security Counters Frontpage Misc. Stuff The End
(The reason two accounts are used is for security. When you run using the PPP account you actually enter superuser state. Because of this, we restrict PPP accounts to only process the PPP server "shell" which prohibits them from running Zmodem or FTP programs.)
In order to do most of what is described below, you must log in to your shell account and select option 9 from the menu. This will put you into native Unix and allow you to issue the commands described. To login as a shell account, you can dial-in to the main number and login as a shell user or dial-in to the main number and login as a PPP user. PPP users would then telnet into HICom and login as a shell user.
The response time on a direct shell login is generally much better than when you telnet in. However, if you dial-in as a PPP user first, you can see the changes you make to your web page more readily and in graphical format.
In order to get data between the two accounts, the accounts must be in the same group. Establishing the group relationship between the two accounts is done by HICom for you and we set the initial permissions. However when you create new files in your directories, you must adjust the groups permissions as necessary.
To move files from your shell account to the PPP-account, use the mv command from your shell account.
All the files you wish to share must have group-level access permissions set. Generally, this means all files in your home directories. You can check that this is so via the "ls -l" command from your shell account. It should look like:
-rwxrwxr-x user-id group-idfile-name | | |------- world premissions for web pages should be r-x | |----------- group permissions for your accounts should be rwx |---------------- your own permissions should probably be rwx
Your user directory, the public_html subdirectory, and the contents of public_html must have world access permissions of r-x. You can check this from your shell account via the command "ls -ld /home/user/userid" where "userid" is one of your userid(s).
When a browser visits your web page, the default web page which gets loaded is called "index.html". If you develop the index.html on a PC and upload it, the suffix will probably not be .html. To change it, use the "mv" command from your shell account:
mv index.htm index.htmlYour index.html MUST be in your sub-directory ./public_html. The subdirectory and its contents must have world permissions r-x. To change the permissions on the directory and the contents, use the command:
chmod -R o=r+x public_htmlYou probably also want the group access to be r+w+x:
chmod -R g=r+w+x public_htmlIts a good idea to check the permissions after you have uploaded new files.
All HTML must have a suffix of ".html". Some other valid suffixes are ".cgi", ".jpg", and ".shtml" (there are others).
If you use FTP, you must have an FTP client associated with your browser. Configure the FTP client to login using your SHELL account/password. (Generally, you login using your PPP account and then fire up the FTP.) If you have NFS, you can take care of the file rename's via NFS and actually "drag" the files from your PC to the FTP session. "Internet in a Box" allows this. After uploading, remember to set the file permissions for the new file. If you dont have NFS, you must login to your shell account via telnet and set the permissions.
You can use Lynx from your shell account to confirm that your upload worked.
Note that you can test your HTML via http://www.hicom.net/~shell-userid/ before you establish the link to your domain. HICom will set up the domain name, mail aliases, and pointers from the web server to your directories. Let us know which account you will use for the web page (shell or ppp) - we default to setting up pointers to the SHELL account.
We also set up a pointer to the web server error log in your directory, called error_log. During testing you can see what errors appear. The log gets cleared once a day. To look at the current log, use the commands:
more error_log
or tail -20 error_log
Example: The login name is: qqq The public_html actual name is: /home/user/qqq/public_html The cgi directory actual name is: /home/user/qqq/cgi-bin The cgi useage is: http://www.domain.com/cgi-qqqThe actual name cgi-bin is reserved for the system. The real directory for it is /var/apache/cgi-bin.
If you use Perl to write cgi scripts, make sure that the first line in the program is:
#!/usr/bin/perlAnd the second line is totally blank (not # followed by nothing, TOTALLy blank).
The command htpasswd (from NCSA) is located in your path for shell accounts.
The following counter is implemented with many thanks from: http://www.fccc.edu/users/muquit/ Please check this reference for detailed description of formats and other options.
The calling sequence at HICom is:
<img src="/cgi-bin/Count.cgi?df=juergen.dat&dd=B&ft=2&md=5" align=absmiddle>
| | | |----|----|--Format options
| | |---------------------------counter file
| |-------------------------------------Counter program
|---------------------------------------------system library
Convention: The data file/counter file at HICom starts with your user-id.
The philosphy of FrontPage is that the web page structure should be reflected in the file structure that's used to store the pages. To implement that, the directory that contains the main page (index.html) will be the top directory(./public_html in our case), and pages that are linked to the main page will be in sub-directories from the main, top directory. For web pages that consist of several hierarchical pages, the directory structure can be complex. When you generate a web on your PC and upload it, the directory structure for the web on your PC will be replicated on my server.
FrontPage is supposed to make web development easy. Since I never used the client side, I cant comment on how easy. But it does require, if implemented fully, certain features on the server side, such as the ability to restart the web server, two (I believe) cgi programs, and conversion of other webs on the server to FrontPage for performance reasons.
From a provider's perspective, there are several of these requirements I can not live with and therefore have opted not to run the server side of FrontPage. This does not prevent our clients from developing their webs via FrontPage, it just will not provide ALL the functionality that may be expected from the program.
Practically, most of the webs I have seen do not require a complex supporting directory structure - a single level seems sufficient. Also most webs do not require security/access control at each level in the directory structure; this feature therefore seems superflous although makes the implementation very flexible.
I hope the next version of the server component of FrontPage is a bit more provider friendly.
The ~ key is usually to the left of the "1" key on the keyboard.