Your home page will be accessed as http://www.idiom.com/~LOGIN where LOGIN is your account login name. Your home page lives in the file public_html/index.html.
To upload files, ftp to idiom.com and log in as yourself (LOGIN), not as anonymous. Change directories to public_html and then upload your files.
Once you've got a home page up, please let us know so that we can make a link to it.
The web server runs as the user httpd and in the group
httpd. All Idiom users are in the group users.
Your web pages must be accessible to the web server in order for
them to be served. To make them inaccessable to the rest of idiom's
user community, remove group read permission on files and group
execute permission on directories:
CGI scripts execute as you. They do not need to be readable by anyone but you.
When you get your virtual domain, we will create a directory for it. It will be in your home directory and named something like www.YOUR-DOMAIN. Put the files that you want to be published as part of your web page in that directory.
There is an online magazine about Apache that's worth checking out Apache Week.
The following book seems to be at least okay:
To create a CGI script, you must create a marker for it in your public_html directory. The marker is just an empty file.
The CGI script must have exactly the same name as the marker but with /cgi added onto the front of the path. If the marker's name is /home/john/public_html/fancy.cgi, then the CGI scripts name is /cgi/home/john/public_html/fancy.cgi.
For example:
CGI scripts must be named something.cgi.
While your script is running, it will only have access to files that are under /cgi. Only a subset of the programs available on Idiom are available on /cgi. In particular, sendmail is missing. There is a simple sendmail replacement on /cgi though in /cgi/usr/sbin/sendmail.
We recommend writing your CGI program in perl5. See man CGI for CGI-related perl functions. If you need to send email from your CGI, then see man Net::SMTP. For general perl reference, see:
If you are going to write more than a few CGI scripts, it may
make sense to put your web pages in /cgi and then make a link
to them:
If you have a virtual host, then put your scripts in /cgi/home/USERNAME/www.YOUR-DOMAIN. Put your touch files in /home/USERNAME/www.YOUR-DOMAIN. The URL for your cgi scripts will be http://www.YOUR-DOMAIN/SCRIPT.cgi
Although it is not recommended, if you wish to use the
uncgi
program, version 1.8 is installed.
You must make a touch (see above) for uncgi.cgi, but not
for the programs that it calls. To use it, go to the
directory that your script will be in and give the following
command:
Put all your cgi pages in $HOME/public_html/cgi (which is now the same thing as /cgi/$HOME/public_html/cgi). If you are using another.idiom.com, then a similar link (for your whole public_html) is already in place.
To test CGI scripts by hand from the inside of the chroot()ed environment, use the cgishell command.
Cgishell can be found at /usr/local/bin/cgishell. It starts a shell inside the /cgi directory.
The URL for your CGI scripts is http://www.idiom.com/user-cgi/LOGIN/SCRIPT-NAME
There is one benefit of this setup: better information when your program bombs. In your script, don't output anything until the very last line. Save it in a buffer. Save another buffer filled with debug information. If you exit with die then the die message, and the variable $elog will be displayed.
The CGI.pm module is available for CGI programming.
If you need to send email from a CGI script, the Net::SMTP.pm module is a good approach.
To use PHP, follow the instructions for CGI files but name your files with .php instead of .cgi.
Actually there are a bunch of different versions of php installed. We install multiple versions so that we don't break old scripts.
You can control which version you use by choosing which extension to use for your scripts. Or if that is not convienient, we can change the version mapping for your web site so that .php gets mapped to whichver version you want.
| ext | version | notes |
|---|---|---|
| .phtml | 2.0b7 | The first version we installed. It is installed with GD support, but without mSQL; Postgres95; logging; or access controls. |
| .php423 | 4.2.3 | Installed with the following modules: xml, standard, session, readline, posix, pgsql, pcre, mysql, ctype, and zlib. | .php3 .php4 .php403 | 4.0.3pl1 | This version is installed with support for IMAP, mSQL, MySQL, SysV Semaphores, SysV shared memory, and GDBM. | .php .php422 | 4.2.2 | Default version. Installed with many options. | .php434 | 4.3.4 | Installed with many options. | .php520 | 5.2.0 | Latest version. Installed with many options. |
To use Miva, you should look at the documentation.
There is another version of Miva called Miva Mia that runs on Windows 95 and Windows NT systems. It includes a web server and can be used to develop Miva-based web pages at home. Miva Mia is free with your Idiom account and can be downloaded after obtaining a license from here.
There is a mailing list of Miva users. You can subscribe by mailing a message with a body of
subscribe hts-users YOUR_LOGIN@idiom.comto majordomo@miva.com. Or you can access the same information though the local newsgroup mgate.htmlscript.users.
If you want to use Miva within a domain (url is http://yourdomain/cgi-bin/miva?somescript.mv) then please send an email to support@idiom.com.
Miva used to be called Htmlscript.
At any given time, there are usually three versions of Miva installed on idiom.com. At the moment, they are:
| cgi-bin/miva.old | version 3.21 |
| cgi-bin/miva | version 3.22 |
| cgi-bin/miva.new | version 3.62 |
Miva Merchant is not included with your Idiom account: it costs $495.00 per domain to buy.
To use Meta-HTML, follow the instructions for CGI files but name your files with .mhtml instead of .cgi.
To use the counter you must load it as an img from within your web page. This can be done as:
If you are using the counter from your own virtual domain, you must ask us to enable counter access for your domain.
If you're got your own domain:
If you don't have a domain:
Virtual host hits are stored with the logs for the user that owns the domain.
The hit logs take disk space. The disk space used by your hit logs will count towards the disk usage of your account. To control the disk space for your web logs, visit the Account Management Wizard section of the main web page.
Error logs for hits through www.idiom.com are stored in the file error_log.
When you are debugging CGI programs, it is helpful to see the error log information as it is written. Use the shell command tail -f logfile watch the log get written.
The overrides that are allowed are:
The .htaccess file and any password file that it references must be readable to the user httpd.
To see what's available, look at: http://www.idiom.com/icons/.
All you can do with a cookie is tell how many people came to your web site and what each of them did. You cannot tell who they are or what other web sites they've visited.
Some people don't like cookies. If you don't want cookies on your web pages, create a file in your web directory called: .htaccess. In that file, put the following line:
CookieTracking off
User web pages are served with the following configuration options:
In addition, there are handlers for the following file extensions:
Non-virtual pages served off of idiom.com will use the URLs like: http://www.idiom.com/~USERNAME.
All email is delivered to idiom.com. Email sent to another.idiom.com will be forwarded to idiom.com.
There is no need to create a public_html directory on another.idiom.com: it already exists. Actually, public_html is a symbolic link (like an alias on a Mac or a Shortcut on Windows 95) to /web/home/USERNAME/public_html.
Because of this linking, there is no need to create special touch files when doing CGI programming.
Heavy web users are encouraged to use another.idiom.com instead of idiom.com. From time to time, we (Idiom staff) may ask you to move your web page from one server to the other.
Non-virtual pages served off of another.idiom.com will use the URLs like: http://home.idiom.com/~USERNAME.
Pornographic web pages should use URLs like http://xxx.idiom.com/~USERNAME instead.
We will create wwwnew.YOURDOMAIN on another.idiom.com. Log in to another.idiom.com and copy your files over. When you feel that wwwnew.YOURDOMAIN is working properly, send another message to support@idiom.com and we will switch www.YOURDOMAIN to another.idiom.com.
The switch will be gradual because people will have the old address cached. Most users will be using the new site within an hour, but some could take as long as a week. After a week has passed, we will turn off the old site (since renamed wwwold.YOURDOMAIN).
The advantage of a redirect is that every hit goes to the new address immediately. The disadvantage is that many hits touch both the old server and the new server. Rumor has it that search engines may drop sites that return redirects. This is, as yet, unconfirmed.
The advantage of this is that it is easy. The disadvantage is that people may continue to use the old site for a long time.