Globat.com - Web Hosting Made Easy
Log In to your web hosting Account Log In Web Hosting CEO Blog for Globat.com - Find out what the CEO of a top hosting company is up to, and get a close perspective on his business and the Globat culture. CEO's Blog Chat live with a customer service or technical support technician to help you with all your web hosting issues. Live Chat Customer Service support, Sales, and technical service from web hosting company Globat.com

         
 
Support FAQs, Tutorials and Contact Info

Scripting FAQ - Support

From Support Center

Return to Support FAQ Categories


Table of contents

Scripting

What programming languages do you support? Which versions do you use?

We support Perl, PHP, and Python. We have information on our current versions, as well as installed modules, on our server software version information page (http://www.globat.com/netstatus/server_info.php).

What paths should I use for my scripts?

Here are some programs commonly referred to in CGI scripts:
Perl: /usr/bin/perl
sendmail: /usr/sbin/sendmail
date: /bin/date
Curl: /usr/local/bin/curl
Your home directory is contained within the e-mail you received when your Globat account was set up.

Where should I place my scripts?

PHP scripts may be placed anywhere in your web space (httpdocs or httpsdocs). CGI scripts should be placed in the cgi-bin folder.

How do I setup a formmail or comment form on my website?

We have a simple, step-by-step guide to installing a comment form on your site in a matter of minutes.

Do you offer telnet/SSH access to edit scripts?

No, we do not currently offer telnet or SSH access. You can, however, log in to the Globat Command Console (https://login.globat.com/) and edit any text file (including PHP and CGI files) within File Manager using your web browser.

What permissions should I set for my scripts?

You should use CHMOD within File Manager or use your FTP client to modify scripts to a setting of permission mode 755 (User: R W X - Group: R X - Other: R X).

My script is not working, what should I do?

In creating CGI scripts and getting them to work on a web server, there are a few key steps that you should ensure have been completed. Follow the steps below to troubleshoot your CGI script:
First, ensure you use a appropriate script editor when you modify your script. If not, many programs will put “^H” characters at the end of each line in your script that you can not see. They are hidden.
Second, ensure the correct paths are called at the top of the script. The correct module paths for Globat servers are:
Perl: /usr/bin/perl
sendmail: /usr/sbin/sendmail
date: /bin/date
Third, ensure that your script is chmod to at least 755. This will allow the script to be executed on a web server. To chmod a script using FTP, right click on the script and go to properties and check all the boxes. You can also use CHMOD within File Manager to set it to mode 755 (User: R W X - Group: R X - Other: R X).
Fourth, ensure each of your scripts are located in your cgi-bin directory and your html calls the correct path to your cgi-bin. Example http:/www.example.com/cgi-bin/search.cgi.

What does "500 Internal Server Error" mean? How do I fix this?

This could mean many different things.
This could mean there was an error somewhere inside your CGI script. Look for any "error_log" files in the directory of the failed script. They may contain information about any problems, misconfigurations or syntax errors that would lead you to solve the problem.
The permissions of the script are also very important. Be sure to make your CGI scripts' permissions 755 or rwxr-xr-x. Do NOT make your CGI scripts 777 or rwxrwxrwx. This would mean that any customer on the server would be able to edit your file. On another important note, if you have information (such as a password database) that you want protected you should probably set the database to 700 or rwx------ so only you could read them.
If you feel your options have been exhausted, open a trouble ticket at our Support Desk (http://support.globat.com/ticket/).

Why does my CGI script give me a "Permission Denied" error?

CGI scripts must be set as executable files through correct use of the permissions of the file. You need to change the permissions, or the "mode" of your programs in your FTP program to either "755" or "rwxr-xr-x". If a script tells you that it must be 775 or 777, do not listen! If your CGI scripts have this level this will allow anyone on the server to write to this script and possibly delete your files!

Why doesn't SSI work on my site?

There is built-in SSI support on all of our servers. Any HTML file that has SSI directives to be parsed must have the extension .shtml. Our web servers only support this syntax for SSI:
<!--#include virtual="/cgi-bin/ssiscriptname.pl" -->
If you have any other questions, the Apache Software Foundation has created the Apache SSI How-To (http://httpd.apache.org/docs/howto/ssi.html).

Why won't my SSI directives get parsed?

Your file extension must be shtml , .shtm , .html and .htm in order for them to get parsed.
SSI would consume too many system resources if every HTML file requested was parsed for SSI directives. For this reason, all files that contain SSI should have the .shtml extension so they can be parsed.

Do Server Side Includes (SSI) work in shtml , .shtm , .html and .htm?

Yes, SSI currently works in shtml , .shtm , .html and .htm files.


I am using FrontPage. Why aren't my .shtml files being parsed for SSI?

FrontPage creates an ".htaccess" file that includes "Options None" which disables SSI. Use a text-only text editor such as Notepad or vi to edit the .htaccess file to say "Options Includes" and SSI will be re-enabled. Doing certain things in FrontPage later on in development may reverse your changes, so make sure to keep track of the contents of ".htaccess".

How can I use php_prepend in my .htaccess?

Globat does not support the php_prepend command in .htaccess, but we do provide a similar method of prepending php code to your php pages. To do this, simply create a "prepend.php" php script in your httpdocs directory. prepend.php will be loaded before all of your scripts.

How do I use mod_rewrite?

What is mod_rewrite?
mod_rewrite is an add-on for the Apache Web hosting server that hosts your Web sites. It acts as a "middle-man" and can translate addresses and requests that come into your Web site into something quite different. This facility allows you to do things such as:
  • Redirect visitors from old pages to new pages
  • Make your site dynamically run through a CGI / PHP script
  • Prevent other sites linking to your images
The first thing you need to know is where to place the instructions you will be passing to mod_rewrite. The rules or instructions for mod_rewrite must be put into a file called ".htaccess" (that’s a period followed by 'htaccess') and uploaded to the relevant directory on your Web site.
The .htaccess file must always start with a line that says:
RewriteEngine On
This line turns the mod_rewrite engine on, and lets it know that you want it to process the other instructions in the file. We will show you how these instructions work in the next few sections.
Redirections
You may have had a page on your Web site which you needed to remove or rename called 'test.html'. The new page is called 'test2.html' and you want all visitors to test.html to go to test2.html instead. You can do this in HTML with a META refresh, but a more search engine friendly method is to use mod_rewrite.
There are two forms of redirection you can do. The first is to just show them test2.html when they requested test.html, but not actually do a redirection. The second is to literally force their Web browser to go to the new page.
Here's a complete example .htaccess file that will show visitors test2.html, even when they requested test.html:
RewriteEngine On
RewriteBase /
RewriteRule ^test.html$ /test2.html
Here's the rule that will REDIRECT visitors to test2.html if they try to go to test.html:
RewriteRule ^test.html$ /test2.html [R]
You will need to choose between these two effects depending on what you are trying to do. We would personally recommend the full redirect method (using [R]) for search engine benefits.
You can also redirect requests to your Web site to other sites on the Web, like so:
RewriteRule ^test.html$ http://www.globat.com/ [R]
This becomes useful, because it means that if your Web site moves you can do something advanced like this:
RewriteRule ^(.*)$ http://www.globat.com/$1 [R]
This may look advanced, but what it does is rewrite ALL URLs on your Web site, and point them at Globat.com. If you move a Web site, or have extra domain names, you can easily point them to a single new site with mod_rewrite. So, http://www.yourdomain.com/test.html would redirect straight to http://www.globat.com/test.html, and so on.
Prevent bandwidth theft
If you have lots of pictures or photos hosted on your Web hosting space, you may have found that other Web sites have linked to them directly, without giving you any credit. This means their visitors get the benefits of the pictures, but you're the one who's serving up the pictures! Using mod_rewrite can put an end to this, by making your images only appear when someone looks at them directly from your own Web site.
Whenever a Web browser requests a file from a Web site, it sends along a line of information called a "referrer", which states which Web site the visitor has come from. We can use this information to write a rule that refuses to serve an image to anyone whose referrer string doesn't match your own site(s).
Here's a complete .htaccess file that will do just that:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !yourdomainname [NC]
RewriteRule .*\.(gif|jpeg|jpg|png)$ - [F]
Note! You must replace 'yourdomainname' with your domain name.
Simply, it turns the mod_rewrite engine on. Then it says IF the referrer is not 'nothing' and the referrer is NOT your own domain name, then cause all requests for GIF, JPEG, JPG, and PNG files to fail. Now no other sites can link directly to your images! They will have to link to your Web page instead, and then the images will load perfectly.
Quick Test
Here is a simple test to see if mod_rewrite is working on your site:
# Turn Engine On
RewriteEngine on
# Rewrite Test
RewriteRule ^test_rewrite\.htm$
http://www.yourdomain.com/is/ApacheModRewriteTestOk [R] 
Using mod_rewrite with Additional Domains
When using mod_rewrite with a Globat.com additional domain account, make sure that the destination path is absolute (for example, http://domain.com/destination) in order for the rewrite to work.
Here is another example this time with a php enabled site (make sure the destination exists or you will get a 404 Not Found Error):
RewriteEngine On
#RewriteRule ^index\.html$ index.php?page=home
----> but instead of the one above, it should be written like the one 
----> below
RewriteRule ^index\.html$ http://domain.com/index.php?page=home
Conclusion
This brief guide has only just scraped the surface of what you can do with mod_rewrite. You can do a lot more, such as making requests to your site automatically filter through a CGI or PHP script (ideal for content management systems). You can also use it to make CGI or PHP based sites look like pure HTML sites, so all the files have .html extensions even though they're really .php files!
The best complete guide to using mod_rewrite is by the Apache Project, and is available at http://httpd.apache.org/docs/misc/rewriteguide.html

Can I schedule cron jobs?

The cron command which allows users to schedule scripts to be executed on the server is not available. The only way to execute a script is to run it inside a web page as a CGI (using Perl or Python) or a PHP file.
Globat.com web hosting made easy. Easy to create a photo gallery, easy to store mp3s, easy set-up!
Web 2.0, Ajax, web hosting, technology, and great service! Web Hosting   |   Affiliates   |   Web Hosting Products   |   FAQs   |   Defying Gravity   |   Contact   |   Site Map  
Customer Satisfaction

© 2001-2007 Globat, LLC. All rights reserved. Usage of this site constitutes acceptance of our
Privacy Policy, Terms & Conditions.

BBB Online Reliability Program