| iMatix home page | Xitami home page | << | < | > | >> |
![]() Version 2.2c |
The FAQ covers these general areas:
The document root is the directory where the main files are. For example if someone asks for a file "http://somehost/index.htm", this is taken to mean 'index.htm in the document root'. This is usually the directory called 'webpages' in the Xitami directory. So if you installed Xitami in c:\xitami, the index.htm file would actually be in c:\xitami\webpages\index.htm. This webpages directory can itself contain subdirectories, of course.
You may find you get this message: "File Not Found - The requested URL /admin was not found on this server". Did you download an earlier version? If so, clean-out the directory and re-install Xitami. If you have an old xitami.cfg hanging around, delete it. Then, please check which version of Xitami you have. You need at least version 2.0d. If that is all okay, and the problem persists, check that you did not set Xitami to working on a specific IP address. If the defaults.cfg file contains a line 'ipaddress=...', delete that line.
Yes, if TCP/IP works and PING does something useful. Same goes for X.25, frame-relay, carrier-pigeon, and telephone drums.
You can use one computer as a server, and one as a client if you like, but you can also use the same computer as client and server. Xitami is so small and fast that you can develop Java or CGI programs on the same system you test them on, and you will not notice any slow-down. This is also a simpler way of working than always copying your webstuff to another machine. Just set your Xitami cgi-bin option to point to the directory where you build your executables, or the webpages directory to your HTML directory root.
:-\ See above question. You can certainly run Xitami on a stand-alone system. It is a Good Idea to have TCP/IP networking installed (on a PC, go for Win95, OS/2, or Linux, which have TCP/IP built-in, instead of Win3.1 which is crippled in this area). You must install TCP/IP correctly and at least have a dial-up adaptor (software) configured. The 'ping localhost' command must work. In some cases the winsock library will want to dial-up when you initialise it (e.g. connect from your browser), but this can be configured (somewhere) to not be necessary.
You need a TCP/IP winsock.dll. And it has to work. And it has to be configured correctly. If you have any kind of difficulty running Xitami or connecting to it, use the PING command to debug your TCP/IP configuration. First, use 'ping 127.0.0.1' to check that TCP/IP is working. Then, use 'ping localhost' to check that winsock.dll is working. Next try ping with the system name that Xitami displays. Then, try this command from another system. All these must work before you can use Xitami.
By default, Xitami accepts connections on any available IP address. If you have multiple IP addresses, Xitami accepts connections on all of them. More usually under Windows you have only one network card, only one IP address (though with a dial-up connection you have two interfaces and two addresses). You can also configure Xitami to accept connections on a specific address only.
Xitami gets its host name from the operating system - i.e. Windows. Your IP address is not something that Xitami can change or choose. Check your network configuration and if neccessary, ask your network administrator. Note the next question about PPP connections... The same applies to the hostname that Xitami displays. This is the name of the system as supplied by Windows. You can change this in the network control panel.
You're using Windows? Check the tcp/ip configuration; your system is probably called 'default'. ':777' is the HTTP port you asked for, presumably.
Xitami gets its name from the operating system. Check the TCP/IP configuration and especially the computer name. You should be able to test this using the 'ping' command in a DOS box. Eg. 'ping mysystem'.
Please, this is getting tedious. Xitami works with any of the IP addresses available on the system. It does not care what the domain name is, and there is no way to define this. (When you use virtual hosts the situation changes a little: there the domain name is used as a key to chose which virtual host to work with.)
Presumably your problem is that the PPP connection is allocating IP addresses dynamically. This makes it hard for anyone to know where your machine is in advance. Ask your ISP if you can get a fixed IP address - though the chances are slim. You can use ping to find-out what your current IP address is. Xitami shows you the local system name - use that as an argument for ping.
Ping is a good test to see if your computer name can be translated correctly. If you're on the Internet, you need to ask your Internet service provider to make the necessary DNS entries. On your own PC, you can edit the 'hosts' file in the Windows directory. The file 'hosts.sam' is a sample that you can rename to 'hosts'. Then, add your machine name and 127.0.0.1. This may not always work; address translation may require that you are actually on-line. For instance, I can 'ping 127.0.0.1' at any time. When I try to 'ping localhost', I get the TCP/IP connect dialog. I can Cancel this, and then 'ping localhost' works. But to ping my machine name, I must be online.
The problem is that if 127.0.0.1 is passed to the proxy, it can't resolve that back to your local machine. You can configure your browser so that certain addresses (127.0.0.1) are not passed to the proxy. This is actually the browser being really silly, because this address *never* means anything else than 'this machine'.
There are three possible causes of this problem:
Windows 95 includes two tools besides Ping to test TCP/IP connections: Tracerout and Winipcfg. With Tracert, you can follow the route for a TCP/IP connection. Open a DOS prompt and type for example: tracert www.imatix.com. The program shows the route to the host, up to 30 hops. Type tracert with no arguments to get help. Winipcfg shows you your IP address(es) and some more information about your network. Just type winipcfg; it's a Windows program.
You cannot set your system hostname here. You have to get this working at the level of TCP/IP itself, e.g. by using the hosts file or a domain name server (DNS). However, you can specify the hostname that's used in redirected URLs, and this is important for virtual hosts.
You have to do two main things:
This is usually only worth doing if you have your own system, permanently connected to the Internet, or you want to rent a 'virtual host' on someone else's system. In the first case, your ISP can usually help set things up. In the second case, the virtual host provider will be able to help.
Set the server:translate option to 0. When this is 1, Xitami sends back a URL to the browser that includes the server machine name. But when the server is on a PPP link, this often can't be handled by the browser. When the server:translate option is 0, Xitami returns a numeric IP address, which the browser will be able to handle.
Set server:portbase to 0, or remove the line. The HTTP port is at portbase+80, and the FTP port at portbase+21.
You probably set the server IP address to something. Delete the line ipaddress=xxx in the defaults.cfg file. If you really grok it, delete defaults.cfg.
From Alex Feinerg a.k.a Yoonicks@EFNet and others...
No. Not yet, at least.
Yes, but it will be late in 1997. The basic problem with CGI under Win 3.x is that the standard input/output mechanisms do not work and must be handled by reading and writing files (simple but not portable). We may eventually support the so-called WinCGI protocol.
Under Windows 95, you cannot run a 16-bit CGI program that is on a path with 'long filenames'.
Under Windows NT, you cannot run 16-bit CGIs at all, due to a limitation of the Windows 32-16 bit interface. We're working on this.
A decent web server like Xitami does not need large amounts of memory or a blazing CPU. You can happily serve a group of several hundred users from a 486 PC with 16Mb memory. If you want to run heavy CGI programs, you'll need a faster system. Also, a fast hard disk is a good idea. And of course, any server is limited to the speed of the network. Given a fast hard disk and a fast network, Xitami will be able to handle several hits per second even on a slow 486 PC, and dozens of hits per second on a fast Pentium. (One hit per second is equivalent to about 20 users actively browsing, at the rate of a page per minute where a page requires about 3 accesses. If an average user browses for an hour a day, one hit per second thus translates into 100-150 users.) We like Windows 95 as a server system, given that is cheap to buy, and is a robust 32-bit solution. At least download the winsock 2 upgrade.
Download and install the winsock 2 upgrade.
Change the Internet Control Panel not to autodial.
When idling, xiwin16.exe spends most of its time waiting for incoming socket events. Under Windows 95 or NT, a 16-bit program that is waiting for socket events looks like it is sitting on the entire CPU. Maybe it is. Anything can happen in this business. However, as far as we can tell, the program really is idling, and does not slow-down the system. If this bothers you, move to Windows 95, and run the 32-bit version of Xitami. This uses Windows threads (as well as its own internal multithreading) to reduce CPU consumption to 1% or less when idling.
No; we use Windows multithreading (as well as our own multithreading), and this will not work under 3.x.
Xitami reports 'Not Found', and any other 3xx, 4xx, or 5xx return code as an error on its control panel.
Your TCP/IP protocol is not correctly installed. Ping must work! Under Win 3.x, this is typically caused by inadequate winsock dialers that have incomplete support for server applications. Try Trumpet winsock, which we've been told works. Under Win95 this indicates that TCP/IP networking is not installed. Try these steps:
Correct. This is part of some fiendish plan for world domination, or possible just a bug in the Win95 console interface that works by passing a secret character to the conagent.exe program (so that only Windows can start a console program). In OSR2 this secret character is filtered by the codeset translation tables and changed to something that conagent.exe rejects. So, patch your Cyrillic codeset tables, folks! [We are not making this up; this is actually true, though admittedly not a very frequently-asked question.]
You can run multiple instances of xiwin32.exe, but it's a little tricky to manage the different ports, since all instances share the same registry values, resulting in a little confusion sometimes. Far simpler is to run xidos32.exe in separate directories (each with its own web space, config files, etc) and specify the portbase either on the command line or in the defaults.cfg file. Since Xidos32.exe is pretty small, the cost in memory consumption is negligible.
Microsoft IE 3.0 has occasional problems mixing keep-alive connections with highly-framed documents. The symptoms are that the last frames will not display. IE opens a connection, asks for a document, but prematurely closes the frame. Workarounds: use Navigator, a more recent version of IE (we assume the problem may be fixed), or switch-off keep-alive if you are using heavily-framed documents.
The problem is one of security; the service runs under the account 'system' by default, and this may not have access to your network drive. In the Services control panel, you can change the start-up options for the Xitami service so that it logs-on as a user with the necessary privileges.
URL.DLL is a Windows DLL that is installed as part of TCP/IP networking, and allows you to double-click a .htm file to launch a browsers. Xitami uses this technique to launch a browser when you click on the 'Setup' button. You can either try installing TCP/IP networking (again) or start a browser and enter the URL 'http://127.0.0.1/admin' yourself. This file may only be on the OSR/1 release of Windows, or may be supplied with MSIE or Navigator 4.
This file must be called "hosts", without an extension.
Try WindMail. Good, efficient, shareware. See http://www.geocel.com/.
Presumably you installed the NT service version, which installs the Xitami control panel file in the Windows System directory. Delete the file called 'xiwinntc.cpl'. If you install and uninstall the NT service version, this file gets left behind due to an access conflict (which we have not figured-out how to resolve). (Details: if you use the 'Add/remove software components' control panel option, then the Xitami CPL is loaded, and can't be deleted...)
Xitami should build on: IBM AIX, Digital UNIX, HP/UX, Sun Solaris, SCO OpenUNIX, SCO OpenServer, FreeBSD, NetBSD, and of course Linux. Anything else is unexplored territory, and that includes the future, since many of these systems are starting to come without an ANSI C compiler as standard. This makes things somewhat harder. Drop us a line and we'll help as we can.
Use 'xitami -b 5000 -s' to run it on port 5080.
Yes, if you have access to an ANSI C compiler. Build Xitami as usual, and run it with a command like this: 'xitami -b 5000 -s'. Avoid port 8080 which is often used for proxies. You may also find that the ISP kill all long-running processes at regular intervals (e.g. midnight). The -s switch runs Xitami in the background; it's a bit cleaner than using 'nohup'.
Check the interfaces and routing with "netstat -r"; a "127.0.0.1" host with the interf(ace) of "lo" ought to be present if it is going to work. The following command ought to establish a loopback connection: "ifconfig lo 127.0.0.1 up".
This section thankfully left empty.
Oh goodness, there must be hundreds of places to get a good answer to this question. Look at the example programs in the cgi-src directory.
If you have enabled Keep-Alive in the server, every HTTP response must contain a valid 'Content-Length' header. When Xitami builds the HTTP header itself, this works fine. But you can build your own HTTP header in a CGI program -- see the testcgi1.c example. This is difficult to combine with Keep-Alive, unless you carefully calculate the size of the generated text and generate your own Content-Length header.
We support WSX and LRWP.
Under Windows, using the MSVC compiler, you can set a debug breakpoint by using the function DebugBreak() at the start of the CGI program. This launches the debugger and you can then step through your code. Be sure to set the cgi:timeout high enough so that Xitami does not think your CGI program has started to loop (it will then kill the process, and leave you with a very confused debugger).
Install Perl in some directory, put that on the PATH, and define the PERLLIB environment variable to include that directory (this lets Perl find its library files). The command 'perl' must work when you're in a DOS box in the cgi-bin directory, and you must be able to run your Perl CGI scripts using 'perl xxxx'. Then, check that the header of the CGI scripts start with '#! perl'.
There are various things that will stop a Perl script from working. The first thing to check is that you have installed Perl (yes, some people don't realise that this is necessary) and that you can run the script from the command line (to catch syntax errors). Next, make sure that Perl is on your path, and that the first line of the script looks like this: "#! perl". You can also use the exact location with / or \ and with or without the .exe. The script MUST start with #! and an executable filename for Xitami to recognise it as a CGI and not as something to download. Lastly, if Xitami cannot find the executable with the exact specified path, it will throw away the path and look on the PATH. So, '#! /usr/bin/local/perl' will work just fine even if you do not have a directory '/usr/bin/local/'. If you're running a 16-bit Perl, make sure Xitami is not in a subdirectory with long filenames (E.g. C:\Program Files\Xitami) or the CGI won't work. Under NT, forget 16-bit Perls completely. Finally, set the cgi:debug and server:debug options to 1. This will leave you with a couple of files - tmpxxxx.cgo and header.log - that contain the actual CGI output and the headers sent back to the browser.
You must let Xitami know that the script is executable, rather than a text file to be sent to the browser. Make sure the script starts with the magic '#! perl' line.
Some languages do not write their output to the stdout device, but directly to the BIOS. Try 'myprog > xxx' and if the output is still being sent to the screen, consult your documentation. At a pinch, use the CGI_STDOUT environment variable to determine the name of the expected output file, and write directly to that file. If you do this, makes sure you set cgi:stdio to 0.
Increase the cgi:timeout value.
Make sure your directory is password-protected. You can put the CGI script at any level under a directory like 'private', so long as the URL contains '/cgi-bin' somewhere.
By default the stdout for a program is handled as a text stream. This is easy to change. First write the HTTP header, then (in C):
setmode (fileno (stdout), O_BINARY);
You can redefine this by changing the server:cgi-url option. As usual, modify this in defaults.cfg, not xitami.cfg.
Of course. On Windows, use windmail.exe. This works just fine.
Use a web site counter like this one for Windows 95.
There is no equivalent to the UNIX 'chmod' command under DOS/Windows. After considering various techniques (e.g. looking at the extension), we decided that the UNIX execve technique was the simplest; i.e. the script specifies what interpreter to use. Actually if you want to see the code that decides this, look at the SFL code in sflfile.c -- file_is_executable (). The UNIX technique works for Perl, Awk and presumably shell scripts, and with a little tweaking, for Rexx too. Finally, we take a peek at the file contents if necessary. Under MS-DOS & Windows, a real executable starts with 'MZ'. That's sufficient for Xitami to try to run the thing. Conclusion: executable files can take any extension and work with pretty much any processor/interpreter.
You'll find a Perl for Windows at http://www.activestate.com/.
I've installed and used Perl on NT and 95. Basically you want to get Perl 5 for Windows 96/NT, which is a 32-bit Perl. You should unzip the files, then run the install batch file. You can choose to install the whole Perl environment into some directory - this may be the simplest option. I personally only need the Perl executable and the standard libraries (.pl files), so this is what I did:
Before doing forms, try a simple CGI program:
#! perl print "Hello World!";This should work when invoked directly from the browser. Set the server:debug and cgi:debug options to 1 to see what is going on (look in debug.log).
Download the SFL library.
You can set this option in the [Server] section of custom.cfg, in the cgi-url option. Try this (you need Xitami version 1.3a or later):
[Server] cgi-url=/cgi
No, not without CGI programming. But it's quite simple to do in Perl or C: you test the user name (forget the password - it's already been validated) and return a header that redirects the browser to the actual page: "Location: /somedir/somefile.htm". Use the environment variable REMOTE_USER, which contains the user id.
In a CGI you can use the user name to subset data: you could issue a redirection to the appropriate file, e.g: Location: filename.htm depending on the value of the REMOTE_USER environment variable, or use this variable to determine what data to read from a database.
Add this to the authentication file:
[/cgi-bin] webmask=..whatever...
For the main configuration you have xitami.cfg+defaults.cfg. For each virtual host you have some XXXXX.cfg. For unresolved virtual hosts you have basehost.cfg. Use the BBA Virtual Host Wizard to define new virtual hosts.
You can do this quite simply by starting two copies of Xitami. We do this quite often; the advantage is that you can get the effect of multiple hosts (different document roots) without playing with the DNS system. Otherwise, you have to define DNS entries that map several different names 'www1.here.com', 'www2.here.com' to the same IP address, then base the virtual hosting on the different names. Either way is okay; Xitami is so small that running two or even a dozen copies will not stress a system.
Let's say you installed Xitami in c:\servers\xitami. Then, the main webpage directory will be c:\servers\xitami\webpages. An URL like 'http://dynamic210.adelphia.net/Joe' is taken to mean something like: 'http://dynamic210.adelphia.net/Joe/index.htm', which would be a file: 'c:\servers\xitami\webpages\joe\index.htm'. You can also use default.htm, and you can change the main webpages directory to be somewhere else if you want. Under Windows 95 and NT you can make each subdirectory shareable separately, so that users can update their pages but not mess with other files. You can also use aliases, especially if users' pages are on different disks.
Any URL containing /cgi-bin/ is treated as a CGI directory. So, Joe can put his web pages in "c:\servers\xitami\webpages\joe\" and his CGI programs in "c:\servers\xitami\webpages\joe\cgi-bin\".
Check that the specified .aut file exists, even if it's just empty. If in doubt, run the Win32 version to see what error message is being produced.
Use aliases.
The ~username syntax is a UNIX thing; UNIX usually translates ~username into the home directory for a user. If you run Xitami under UNIX, this will work automatically. Under Windows, ~username means nothing; there are no user home directories. However, you can get much the same effect by creating a subdirectory for each user underneath the webpages directory. Then, you use the syntax:
http://ipaddress/username/
It has to do this, since new versions have to have their proper .cfg and .aut files. The important thing is to make all changes in defaults.cfg, and this includes defining your own .aut file, so that the two standard files can be reinstalled at any time.
Just say 'imatix' backwards -- it's simple!
Edit the file errors/text-404.
You can switch these off; set serverlog:filename to "NULL".
This is just name for the portable, command-line version of Xitami. Usually we use this term in contrast to the Windows GUI versions of the web servers, which provide a graphical control panel for the web server.
This is a temporary situation: we plan to release an update in 1998 that uses encoded (hashed) passwords for better security. The password file itself is not accessible to browsers, unless you specify the Xitami root directory as its webpage directory, which would not really be a good idea. There are also advantages to plain-text password files: it is simple to manage these using scripts.
The various search engines (like AltaVista) use a 'web spider' or 'robot' to scan and index websites. This often includes large amounts of junk that make the resulting searches pretty useless. So, a standard mechanism has evolved to make this work better. The 'Robot Exclusion Standard' specifies that a file called 'robots.txt' in the home directory will indicate which pages or directories should be ignored. This is not meant as any kind of security device, just a 'hint'. So, most robots will ask for this file. If the errors in the log files bother you, create an empty file in the webpages directory called 'robot.txt'.
There are many freeware and commercial logfile analysers; the Xitami access logfiles are NCSA/HTTPd compatible and thus compatible with most logfile analysers. The Xitami.log file is used for server messages and thus not suitable for analysis.
Xitami does not yet translate IP addresses into names since this is very slow unless done asynchronously, and that's a lot of work. The XiXlat translator (currently in alpha testing) which is supplied with Xitami will do fast log file translation.
Change the defaults.cfg file server:defaultn options. You can specify anything you like: begin with 'default1'.
Up to v1.3a, people had to modify the pre-supplied xitami.cfg file. This worked fine until they installed a new version, at which point they could start again. Defaults.cfg is not supplied with the server - you just copy the part of xitami.cfg you want to modify. Eg.
[CGI] debug=1
The webmask is a bit pedantic. This mask forbids all hosts in a certain domain, but does not allow other hosts. Follow it by ',*' to allow all other hosts: webmask=!xx.xx.*,*
Make sure the server:keep-alive option is enabled. Add lots of RAM to your system and make sure this is available to your operating system disk cache. Put your web site onto a RAM disk. Don't use lazy, slow CGIs, especially ones that search large databases. Change the priority under Windows NT to 'High'.
We use GNU tar and gzip under Windows NT to create these files, including the UNIX kits where I first run a script to prepare the source files and strip-off carriage returns. The combination of tar+gzip offers much better compression than the 'standard' zip format since the tar file is effectively handled as a single file. You get a better compression ratio by compressing a set of files combined into one file (a tar) than by compressing each individual file (standard zip): patterns repeat more often. You could use tar+zip just as well (I do this for the UNIX kits). The drawback of combining tar+(g)zip is that you cannot manipulate the archive easily (e.g. delete or add files). However, it's an excellent approach for distributing sources. Under Windows, the WinZip program will handle all these and other formats. You'll also find many free tools like the GNU utilities and free Zip tools.
This should work. Set server:debug to 1 and see what's going on in debug.log. If you're on a PPP connection try setting server:translate to 0. Try the URL ../files/ (with the trailing slash).
Set server:debug to 1 and see what's going on in debug.log. The browser- based administration pages provide a 'test' facility where you can type an URL, and Xitami tells you what disk file it would be translated to.
First of all, the root for the user must be at or below the ftproot. If you want a user to have access to aliases, his root must be "". This is a limitation for now, and does mean that all root users can see all aliases. Then you define each alias in the [ftp-alias] section as 'name=directory'. When the user does a 'dir' in the root directory, he sees the aliases and can cd to them. It's that simple.
No, none. Read the Xitami license.
No, none. Read the Xitami license.
Any complex software is filled with bugs. Xitami is pretty good in this respect, we reckon. Our policy is to fix those we can identify and localise, depending on the severity of the problem. A bug that causes the server to crash will make us run around a lot faster than a bug which causes some obscure feature to work otherwise than documented. Large amounts of money will also tend to focus our attention.
These are some of the upcoming changes we are working on:
No dates have been released for any of these.
| << | <
| > | >>
| Welcome To Xitami | Table Of Contents | Installing Xitami | Administration | Configuration | Using CGI | Using SSI and Filters | Image Maps | Virtual Hosting | The FTP service | A Beginner's Guide | FAQ | Writing Web Server Extension (WSX) Agents | Extending Xitami with External Peer Processes | Technical Implementation | Getting Support | Release History | License Agreement |
![]() Copyright © 1996-97 iMatix |