Web Hosting and Programming Reference
PINS has made every effort to keep web hosting and development on our servers simple. However, there are a few things you'll need to know in order to take full advantage of our different features. Please read the following and feel free to contact us at support@pins.net if you have any questions.
Username Login
Everyone with a web site at PINS is assigned a username and password. This combination is what allows you to log in to your server and access your files. When you connect to our server with FTP, ssh or secure telnet, you are placed into your home directory by default, which is /home/username. For example, if your username is bob, you are placed into your home directory of /home/bob by default. You may change your password by logging in here.
Where to Connect
In general, you will log in to or connect to the same system that your web site actually lives on. So, if your web site is on www.company.com, go ahead and ssh to or connect your FTP client to ftp.company.com. That way, it's easy to remember exactly where to connect to.
HTML Uploading
Inside your home directory will be a directory called DOMAINS, which contains your web files. Many people host more than one web site with us, so inside the DOMAINS directory will be each web server directory, and underneath that directory are the htdocs, cgi-bin, and other directories that you will place files into. Most web page editing software expects a "root" directory to place files into. If you're hosting the domain www.company.com, with a username bob, the full directory for your HTML files would be...
/home/bob/DOMAINS/www.company.com/htdocs
...which is what you should set for the upload directory. Because you are placed in /home/bob by default, you can generally get to your web directory by leaving off the first portion:
DOMAINS/www.company.com/htdocs
You may have to experiment a couple of times to get it right, but don't worry; you can't cause any serious damage by uploading files into the wrong directory. Just be careful before you delete anything to make sure you are deleting the files you think you are. Please note that our servers are case-sensitive. That means that file.html, File.html, and FILE.HTML, are all different. Windows and Macintosh systems are not case-sensitive, so if you are not consistent and careful in your naming, your web site may not work properly after you upload it. We recommend that you keep all of your files and URLs in lowercase to minimize this problem.
Main Pages (index.html)
Most of the time, you will have a master page that comes up when a person selects a URL by default. For example, if a person simply types in http://www.company.com, the default file which is pulled up is named index.html. Similarly, if somebody goes into http://www.company.com/somedir, then the index.html file in that directory is presented.
You can name your index file any of the following (in order of precedence, lower case only):
index.shtml
index.html
index.htm
One common error is to have both index.html and index.htm in the same directory. Only index.html will be read by default, and any changes you make to index.htm will be ignored. If you're having problems changing the index page in a particular directory, check to see if this is the problem.
For a full example, the web address http://www.company.com corresponds to the directory /home/bob/DOMAINS/company.com/htdocs/index.html.
Error Pages
Default error pages on your site refer to the email contact webmaster@company.com, so this address should be defined on your mail server. At your request, we will set up private error pages in htdocs/.PRIVATE_ERRORS that you may customize to match your site.
Full Directory Listing
The full list of directories you'll need to know about are listed below, all relative to DOMAINS/www.company.com. You may not have all of these directories unless you have purchased the related services:
| htdocs | HTML files |
| cgi-bin | CGI files |
| fcgi-bin | FastCGI enabled scripts |
| sbin | Non-web programs you might want to install |
| lib | Programming libraries used by your CGI programs |
| logs | Log file access |
| data | Data files used by your CGI programs |
| conf | Configuration files |
| rafiles | Real Media streaming files |
| autorespond | Email autoresponder configuration |
Permissions
If you know a little bit about UNIX, you are probably aware that different permissions can be set to control access to files. By default, your directories are all protected from casual access, which means that only the files you put into your web server directory are visible to the outside world. You can put files into your home directory, e.g. /home/bob, and work with them there if you do not want them to be on the web site. Just remember that the permissions on your home directory are not restricted by default. If you do know how to change permissions, make sure you do not restrict the permissions inside your web directories, or the web server will not be able to get to them.
CGI Development
We have a fully featured CGI development environment. As a result, our servers actually have a fairly complex directory structure.To reduce the overhead in your scripts, as well as to increase their portability if we change our server configuration, you should know exactly what pathnames to code into your scripts. The following sections assume a bit of UNIX knowledge, so please bear with us. First of all, a few notes on our security system.
1. CGI programs run as the username that owns the web site, under the UNIX group that owns the web site. To find out what these are, you can use the id command at any UNIX prompt to see what your defaults are set to. If there are multiple people doing development on a given web site, they should all be in the correct UNIX group.
2. For programs to run, they must not be world-writable, and they must be owned by the UNIX group that owns the web site.
3. CGI programs will only run under the cgi-bin or fcgi-bin directories, and will not run in htdocs.
4. A CGI program will always run in the directory that it lives in.
Most of these permissions are set properly by default, but if you are doing an upload with FTP, you may have to manually change the permissions on a script or program to ensure it runs properly:
chmod 775 programname
CGI Directory Guide
For the most part, you should not have to put full pathnames into your programs. If you have to, however, we strongly recommend that you use the local pathnames, which are faster, instead of the links to your home directory, which are slower. The one caveat is that local pathnames will only work on the machine that your web server is running on. This is usually not a problem unless you develop on our test server and move things to the production server.
So, if you are developing an application that lives in the cgi-bin directory and wants to reference files in your data directory, you have three ways of doing it:
Best: ../data/filename
Works: /export/local/httpd/DOMAINS/company.com/data/filename
Avoid: /home/username/DOMAINS/company.com/data/filename
The reason we recommend the first is that it functions properly in both a test environment and a production environment. (See below.)
Similarly, the program name referenced in your <form> tags should always contain a path relative to "/":
<form action="/cgi-bin/...your_cgi_program.cgi">
Production/Test Environments
If you are doing extensive development work, you can request a test site for a small additional fee. We also provide a turnover script that lets you automatically copy files from test into production after you have tested them.
As a general rule, the following directories are copied identically from test into production: htdocs, cgi-bin, fcgi-bin, sbin and lib. Therefore, you should not keep any application or state data in those directories, and instead reference everything that will change between test and production in the data directory.
This is also why we recommend using relative pathnames in your scripts. Using an absolute pathname with company.com in it will break between test and production, since the test directory would be...
/export/local/httpd/DOMAINS/test.company.com/data/filename
...and the production directory would be...
/export/local/httpd/DOMAINS/company.com/data/filename
The relative pathname will work in either case, because ../data will always be correct relative to the cgi-bin directory. If you need to use absolute pathnames for another reason, you can always put in some code to check which directory you're running in.
Programming Languages
Most people develop their applications in Perl, but we also support C, C++, Java, Python, php or almost any other language that you care to build in. For people using Perl or Java, we support FastCGI and JServ to enhance the speed of the system. Dedicated servers may also enable mod_perl as well, but we do not offer this on shared servers.
We do not make our compiler available on all machines, so if you need to do development, please connect to www.dev.pins.net and do your development there. If you have been given a development or test server, you can connect directly to that box as well, e.g. www.test.company.com.
For more information on writing programs using CGI.pm, please see the CGI.pm support page. It does require a certain amount of programming experience to be able to write good PERL programs; O'Reilly & Associates has an excellent PERL resources page, and sells several good books on programming in PERL.