Posted 08 June 2005 - 06:42 PM
Posted 09 June 2005 - 11:42 AM
Posted 10 June 2005 - 10:17 AM
Posted 10 June 2005 - 01:13 PM
Posted 10 June 2005 - 01:39 PM
BTW, if you download xitami on windows I have found that the only version that works is the windows 95 version.
Posted 10 June 2005 - 06:50 PM
Glenn Graham (not me)
Xitami is an alternative Web server produced by the iMatix Corporation (Xitami spelled backwards) and is pronounced si-TA-me. It runs under Unix as well as NT and highlights a Web-based administrator, the LRWP Protocol, XML, a built-in FTP server, and more. The core software is free, although iMatix charges a fee for added applications such as plugins and support contracts. The commercial version, Xitami Pro, supports full SSL layer 2 and 3, and uses OpenSSL source. For an initial overview, check out their Web site .
Xitami offers a Web Server, FTP Server, and Web-based GUI, all in one. The GUI provides ease of operation for both the administrator and users through an attractive environment to set passwords, create directories, change permissions, and configure virtual hosts a real plus for systems with large multiple domains. The small, fast, lightweight binary uses less overhead than the competition in terms of both CPU and memory, and Xitami runs on a variety of operating systems including the BSDs, Linux, OS/2, OpenVMS, and NT/2000.
Xitami offers unique support for the LRWP protocol (Long Running Web Process). LRWP is a simple protocol for communicating with external processes, called peers. The peer process simply waits for the requests to come from Xitami and then responds with a valid http response, just like a CGI program. The main difference is that like other persistent CGI solutions, the LRWP peer waits around for another HTTP request instead of terminating. To my knowledge, Xitami is the only server deploying this protocol method.
WSX protocol (a plug-in extension), another feature of Xitami, allows for programming under WSX. Simply put, WSX is a unique program written as a multithreaded SMT agent, and is linked into the server executable. WSX may be used as a replacement for CGI but will not crash the way a CGI program will. Writing WSX agents is not trivial, but it's worthwhile for certain kinds of work. For more information about writing WSX agents, look at the SMT documentation and study the standard WSX agents. WSX and SMT are unique to Xitami.
Other features include on-the-fly server configuration, so there's no need to stop and restart the server, even when adding virtual hosts or additional IPs (something Apache just won't do). The WBA supports a virtual terminal, so an administrator can tail the log messages without having to log into the console; this is an advantage, especially for busy sites.
I was impressed to see this application ported to so many operating systems, including every flavor of Unix, NT, and OS/2. Administrative security is based on user authentication per directory, FTP access rights (per user and per directory), password management, setuid, and restriction by IP. As with other Web servers, Xitami has standard support for CGI scripts in Perl, Awk, Rexx, Python, C, and Java. It also supports standard logging formats such as CLF, IIS, and XML.I tested Xitami under Solaris, FreeBSD, and Linux. For this review, I installed Xitami on an (experimental) Altos 10000 running FreeBSD. There's nothing like testing multi-platform/multi-architecture software on a box older than the technology itself.
iMatix boasts that Xitami is small and uses few resources. Later in this article, I'll compare how Xitami polls resources compared to its competition, Apache.
As an experienced Unix admin, I found nothing easy about installing from source. If you don't understand how library functions work and where things are supposed to go, give yourself time to learn. Fortunately for users of FreeBSD, there's an Xitami port available under /usr/ports/www. A simple make && make install does the job fine.
If you're confident enough to build from source, you'll need to read the documentation found at Xitami.com, or the README file contained within the source. Xitami distributes the source via HTTP, so you'll need Lynx or wget. Save to your src/xitami directory, untar, and read the documentation.
The documentation explains that Xitami will run for years without maintenance as it automatically detects memory leaks, then flushes them. (Although memory-flushing is a creative addition, most Unix variants already have built-in flushing mechanisms.)
I built Xitami from the ports package and everything went as planned. Throughout the build, the libraries were installed and linked, along with a group of headers needed for compilation. These are defined by sfl and smt. The sfl libraries must be built prior to smt. Once the libraries are linked, the build script compiles the binary. Xitami suggests testing the server by using the -b (port shift option), which shifts port 80 above port 5000 (port 5080) then pointing your browser to http://servername:5080. The exact reason for port shifting isn't exactly clear, but I expect this is so that your test won't be visible on the public port 80.
By reading the help file (./xitami -h) I determined the -s switch was required to suppress any foreground messages and place the server in background mode. Once in the background, a message appears to console that says "Moving into the background". Failure to run with -s produces verbose messages to console. Once Xitami is running, point a browser to the host IP to be presented with a default "welcome" page.
Here's a quick look at various switch args available from the command line (-h option). This is the best help file you'll find for Xitami.
-r directory Root directory for Web pages
-c directory Directory for CGI programs (cgi-bin)
-b portbase Shift HTTP port 80 by this value (e.g., to run Xitami on port 5080, do xitami b 5000)
-f directory Root directory for FTP files
-q Quiet mode (no messages)
-s Server mode (run as background job)
-S Console mode (run as foreground job)
-t Trace all socket i/o operations to log file
-v Show Xitami version information
-h Show summary of command-line options
The default FreeBSD installation places the binaries, configurations, cgi-bin, and Web directories under /usr/local/xitami.
Master configuration files consist of:
Web site files and Directories are located within the WebRoot directory "Webpages."
The CGI-BIN is located in the directory, cgi-bin.
The server's main HTTP logs and error logs are also located in the server's root directory. (By default, the Web access and error logs rotate once a day.)
The Web directory is located at ./Webpages.
The Web site's default .html file is "default.html", however, a more standard .html file called index.html will override default.html once uploaded.
The FTP Directory is located at ./ftproot, which must be manually created .
The WBA (Web-Based Admin)
The WBA is really very interesting. WBA lets you administer the Xitami server through a Web interface. Although WBA performs exceptionally well under Unix, I suggest some fine tuning for the NT platform. To get started, add an administrative account by editing xitami.aut and adding the following (example) entry:
# file xitami.aut [admin] admin=password
Now you're ready to login to the WBA!
Access is acquired by pointing your Web browser to http://route_to_server/admin and logging in using your administrative account. A preliminary walkthrough of the Web admin is straight forward. It comprises various menus and sub-menus. Be careful to save changes within the sub-menus before navigating back through the tree to the main menu.
Starting on the left column, the administrative menu consists of Configuration, Virtual Hosts, Server Console, Restart Server, and Halt Server. If you choose to halt the server, you will need to login from the command line to restart it.
From the configuration menu, you are presented with variable input fields that consist of settings for the Main HTML directory, Main CGI directory, CGI URLs, start options, debug, and refresh options. Other options include refresh time, max httpd connections, default Web page, background mode, and server IP address .
The Virtual Hosts menu allows access to set various virtual hosts paths and directories, including user names and the default html page.
Virtual Host Wizard
The Virtual Host Wizard adds the unique advantage of creating virtual hosts on the fly. It's a quick fix to manual configuration. The option allows the administrator to create a new configuration for each host (profile), set the virtual IP address, allow non-privileged users to use the WBA, set the users login/pass/CGI directory, FTP, and other permissions.
The server console is for administrative purposes and allows the superuser to view log messages and also display server uptime. Other options include FTProot, HTTP Listening port, and the total number of hits and errors. It also has a built-in load utility that measures total connections and data transfer on a host-by-host basis.
The WBA does not create ftproot; you need to do this from the command line. The Security Menu, a sub-menu within Configuration (shown below), allows you to change the name of the password file, xitami.aut; set a Super User Password; or configure case-sensitive passwords. Any field with an "*" means wildcard, or "all access." Any field with "-" means "no access."
Like most software open to the 'Net, Xitami has some known vulnerabilities. The administrative and FTP user passwords are stored in a clear text file named "xitami.aut". The filename should be changed in defaults.cfg or by accessing the WBA security menu. If a remote attacker is so inclined, and knows the name of this file, he may be able to download it from your system and access the server.
Xitami runs as root, therefore in the case of a buffer overflow, Xitami may be used to gain superuser access to the system. There are no workarounds for this, however, iMatix is addressing the problem. During my installation, I set mode 700 on all system-related binaries and, wherever possible, chroot(ed) the user directories.
When setting your security options, be sure to give restrictive access to non-privilged users, especially those with FTP access, paying special attention to FTP access rights, password security, and restriction by IP. (See Security menu. ) It appears that Xitami lacks a Web-based authentication method such as that used by Apache (htpasswd).
In lieu of the WBA, Xitami may (also) be administered by creating a "defaults.cfg" file, where you may add manual entries that override the main configuration. It is suggested that you do not edit xitami.cfg directly.
As an administrator of 40+ servers running Apache, I was interested in comparing Xitami's performance to Apache under heavy load. I set up a "Web site hammer," which is nothing more than a series of Unix boxes running forked instances of lynx. With a 100-Mbps NIC installed on each client, I pointed the "hammers" at the Web server and generated about 1,000 hits per second. Next, I ran the "top" utility to measure the CPU usage. At an estimated 1,000 hits per second, over a period of five minutes, the CPU usage under Xitami was only 53%, while Apache saturated at 90%.
I think Xitami has the potential to become a nice multi-platform product, but it needs some work. Documentation is the weak point for this product, and iMatix admits they lack an "Idiot's Guide". My suggestion is to download it, use it where possible, and perhaps contribute to this promising project.
Glenn Graham has been working with telecommunications technology since 1977 when, at age 15, he wrote and passed a communications exam given by the Government of Canada. At 38, he now has more than 12 years of experience with UNIX-based operating systems. He established inTEXT Communications, a Vancouver-based UNIX consulting company, in 1994.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users