View · Index
No registered users in community rubick
in last 10 minutes

Jerry Asher's Virtual Hosting Article

HOWTO - Virtual Hosting in AOLserver original URL


Virtual Hosting in AOLserver

how to host multiple ACS/OpenACS installations with one static IP

What's in here:

I describe how to use NaviServer /AOLserver to serve content for many different sites with each site sharing a port. This is can be useful
  • for hosting multiple ACS or OpenACS sites when you have only one static IP.


  • for ISP's or Web Hosting companies whose allocated range of IP addresses is small and who want each site to be available from port 80.


  • when your primary web service is composed of several cooperating web server technologies and yet you still want to present one unified address to your visitors. For example, your web service may be comprised of an AOLserver ACS, an Apache CGI module, and even a Tomcat servlet engine.


  • when you worry that your user's firewalls will keep them from accessing just *any* port and so you want all your sites to be available from just one port.


Table of Contents

What kind of virtual hosting do you need?
DNS and email
Implementing NSVHR
The basic architecture
Get and Install AOLserver
Applying the patches
Load the modules
Registering methods
Nsvhr Configuration
Nsunix Configuration
Nssock Configuration
An alternative: Implementing VAT
Multiple ACS installations
New Features for AOLserver 3.3ad13
The future
Appendix I: nsunix or nssock
Appendix II: aolserver or apache or squid
Appendix III: Upgrading to AOLserver 3.3ad13
Appendix IV: Security
securing the nscp port with ssh
Related Links


You're not yet funded but you have a great plan. Host a series of websites about the FBI and the Sopranos. To corner the market, you'll also host websites discussing how much the fbi and the sopranos suck. With thousands of uh, hits per day on your site, what VC wouldn't make you an offer you couldn't refuse?

So let's host four websites.

  1. a large dynamic website hosting an FBI chat room and other FBI applications.
  2. a large dynamic website hosting a Sopranos fanclub. Ecommerce too: sell comemorative hits (fedex dead fishes, and rubber galoshes to your friends.)
  3. a small site for now, mainly for members of the aluminum foil beanie crowd that know the fbi and cia are beaming thoughts into their head.
  4. a small site that focuses on touched by an angel.

What kind of virtual hosting do you need?

If you want to virtually host from two to 64K static sites, Apache is certainly a better choice. You'll find lots of sources and tools to help you do that. If you want to virtually host from two to 64K dynamic sites that have cgi capabilities mixed with mysql (for example), Apache is probably a better choice, because once again, there are lots of tools and people out there who can aid you.

If you want to virtually host from two to 64K sites that have dynamic capabilities and that benefit from a fast scripting language and wonderful database pooling, than AOLserver is the server for you.

VHOSTing with AOLserver

If all your sites can share the same Tcl libraries, then you can look for "simple", single process forms of virtual hosting most commonly referred to as vhost. With this form, all of your sites will be served within the same AOLserver process.

If you search the list archives, or the forums at OpenACS, or at NaviServer, or just google for VHOST and AOLserver, you'll probably find what you need.

I've implemented Tom Jackson's VAT vhosting module available from ZMBH. You can find some details below.

NSVHR hosting with AOLserver

If you have sites that require custom Tcl Libraries that you don't want to share or can't share, then NSVHR based hosting is your solution. With NSVHR based hosting, each new site gets its own AOLserver process to serve the site. This can be used to help secure virtual hosts, and to separate reliability issues of one site from impacting another site. This solution also lets you stop and start various sites independently.

If you want to virtually host from two to a few dozen (my guess only) sites that each have their own tcl library, where each library might conflict (in tcl namespace) with another sites tcl library (say you are virtually hosting four customized ACS sites, one running ACS 4, one running ACS 3.4.6, and two running ACS 3.4.10).

It's also a good solution for running several sites based on differing ACS versions. Do you have one customer that relies on legacy data that can't be upgraded (yet) while another customer wants the latest version of the ACS? No problem, they can each run in a different Tcl context with NSVHR based virtual hosting.

Want to run sites identical in most respects except for the database user they connect as? NSVHR based virtual hosting.

Do you want to guarantee that one site cannot (maliciously or otherwise) read or write to another site's pages, or database? NSVHR virtual hosting.

Are you wondering whether to implement nsvhr using nssock or using nsunix? Don't worry, use either and just get your site up running for now.

There is a fair chance you can get nsvhr/nssock running without needing to patch AOLserver 3.2. There are a few bugs. You may not notice them. A few visitors might. But I have some patches that enable nsvhr/nsunix to work and improve nsvhr/nssock.

nsunix.... should be more efficient than nssock (requiring less copying of data). should allow you more concurrent connections (as it requires fewer open files per connection since it requires less copying of data). may provide better logging if you care since each virtually hosted server can get its own log file with the actual ip of the client. is less buggy when AOLserver is patched than running nsvhr/nssock when AOLserver is not patched. maybe more buggy than running nsvhr/nssock when AOLserver is patched. ...has been implemented at hundreds of sites.



The virtual hosting discussed here is primarily name based, it supports multiple sites that each have different domain names. It follows that each virtual host you add will need DNS support.

If the new domain is just a subsite of an existing domain, you will probably be adding a CNAME to your existing IP address. I usually just add a CNAME that points to my primary host.

Assuming I am already handling, then to support, I add:

web             IN      A
www             IN      CNAME
But if you're adding an entirely new domain, then you'll need to add a whole new zone. I'll leave you to find a better DNS reference than I.

Don't forget to add support for a new domain to your mailer so that you can receive emails for or If you're using qmail, it's pretty simple. Add the new domain to your rcpthosts, and either to your virtualdomains or your locals.

Implementing NSVHR

What you'll do is set up three separate AOLservers that will coordinate with each other: master, fbi, and sopranos. In general if you want to host n websites, you will need to set up n + 1 AOLservers.

  1. master will become a proxying server that will actually receive ALL of your visitors requests and somehow transfer each request to either
  2. fbi will host the fbi chat room and will handle all requests to
  3. sopranos will host the soprano intranet and will handle requests to fbi or sopranos
Somehow transfer will differ depending on your choice of nsunix or nssock to implement your proxy.

If you use nssock, you will be choosing an AOL supported mechanism, that transfers every request and response by copying that request and response. Upside: it's AOL approved. Downsides: it potentially doesn't have the efficiency of the nsunix approach and it obscures the access log files of the proxied servers (fbi and sopranos) by recording the ip address of the master server as the ip address of your actual visitor.

If you use nsunix, you will be choosing mechanism a AOL created, but abandoned. With this approach, the request is basically copied but the response is sent directly back from the proxied server to the client browser. This is implemented with the magic of Unix domain sockets which allow one process to pass an open file descriptor to another process. Upside: it has much higher performance (especially when responses are typically "biggish") and your access logs record the correct ip of your visitor. Downside: you may be accepting me as your web savior. (Uh, since I fixed nsunix and so far, everyone has been relying on me for bug fixes.)

The basic architecture

Thanks to Tim Darling for this diagram of the basic architecture. Here main is master, foo is fbi, and bar is sopranos.

Get and Install AOLserver

The nsvhr/nssock/nsvhr patches I have created were created using AOLserver 3.3ad13, the ArsDigita release of AOLserver. I suspect the patches will apply with few problems when using the AOLserver 3.3 distribution.

Unpack the distribution. The ArsDigita distribution usually likes to unpack into a directory named root, and likes to install the binaries and server files into /usr/local/aolserver.

I usually unpack the distribution into /tmp and then mv that root directory to /web and rename it to indicate which version of AOLserver I am using.

These are the commands I usually take, but I'm just typing here, not testing them, so you may need to change these commands somewhat.

  $ cd /tmp
  $ tar zxvf aolserver-src.tar.gz
  $ mv /tmp/root /web/ad33.13
  $ cd /web/ad33.13/aolserver
Now the first thing you should probably do, is build the basic system and get it working. Do that now, and come back after you get AOLserver serving it's basic page. (After starting it, it should serve up pages on port 8000). Again, the commands are similar to this.
  $ make
  $ make install
  $ cd /usr/local/aolserver/bin
  $ ./nsd8x -ft ../sample-config.tcl -u nsadmin
Hey, you're back. Congratulations for getting AOLserver up and running. The next step is to apply my modifications.

You need some patches

And so I have created some for AOLserverVirtualHostingPatches. These patches have been developed over about 18 months and have been used world wide. They've been downloaded thousands of times, and I mostly hear they work. And I hope they work for you.

The exact instructions are included in the release notes of the patches. The basic procedure is to use the patch command to apply the patches, and then to rebuild all of AOLserver. Nb: it's very important that you rebuild all of AOLserver as some critical internal data structures have new slots.

Assuming you downloaded the patches to /tmp/aolserver3.3-vhr.patch, the following commands should apply the patch, but again, look at the exact instructions contained in the release notes.

  $ cd /web/ad33.13/aolserver
  $ patch -p5 <aolserver3.3-vhr.patch
The patch should apply with no errors and few messages.

Create the nsvhr/nsunix modules

I believe the default for AOLserver 3.2 is to create these modules, so you should be all set. Not so for AOLserver 3.3. If you need to create them you need to visit the top level AOLserver Makefile, and add nsvhr and nsunix to the Modules definition.

In /web/ad33.13/aolserver/Makefile:

MODULES   =  nssock nscgi nscp nslog nsperm nsext nspd nsvhr nsunix
Now rebuild all of AOLserver and install.
  $ make clean
  $ make
  $ make install


The key to configuring AOLserver is through a configuration file. This file has been named in the past as nsd.tcl, config.tcl, and sample-config.tcl.

You will need to create one of these files for each AOLserver that you start, you may as well name it with the name of your server.


Load the modules

Now that you have rebuilt AOLserver, you should find two new modules in your AOLserver bin directory: and You want to direct your master server to load the nsvhr module and each of your other servers to load the nsunix module.
  ns_section ns/server/master/modules
  ns_param   nsvhr                    ${bindir}/

  ns_section ns/server/fbi/modules
  ns_param   nsvhr                    ${bindir}/

  ns_section ns/server/sopranos/modules
  ns_param   nsvhr                    ${bindir}/

Registering methods

You have to tell the nsvhr module which methods (POST, GET, HEAD, PUT) to proxy.
  ns_section ns/server/${servername}/module/nsvhr
  ns_param   method                  GET     ;# Methods allowed to proxy
  ns_param   method                  POST    ;# Methods allowed to proxy (can have
  ns_param   method                  HEAD    ;# Methods allowed to proxy

NSVHR Configuration

Nsvhr, desires to take over your master server entirely. Your master should serve no requests by itself, but should server all pages using one of the proxied servers. Unfortunately, I know of no way to ensure this, but experience shows you need to keep the master from sourcing tcl pages, and you need to turn adp processing off. No worries! Your proxied servers will handle these just fine. So make sure the following directives are commented out.
  ns_section ns/server/master
  ns_param   EnableTclPages Off

  #  adp must be disabled for nsvhr to work
  #  I don't know how to EXPLICITLY turn it off,
  #  but make sure it's hasn't been turned on by default!

  #  ns_section ns/server/master/adp
  #  ns_param Map          /*.adp

  #  ns_section ns/server/master/adp/parsers
  #  ns_param fancy        .adp
You can also direct the nsvhr module on how to behave when errors occur, when AOLserver becomes busy, or when a request comes in with no HOST field.
  ns_section ns/server/${servername}/module/nsvhr
  ns_param   menuurl         url     ;# Redirect here if back-end times out
  ns_param   busyurl         url     ;# Redirect here if back-end times out
  ns_param   errorurl        url     ;# Redirect here on proxy errors
  ns_param   timeout         30      ;# Timeout waiting for back-end

NSUNIX, NSSOCK, or both?

This code has no guarantee. It's likely buggy. And so it's very useful to implement your system with both nsunix AND nssock. While nsunix should give you better performance, having an nssock backup is valuable.

Method One: nsvhr/nsunix

The master server loads the nsvhr module. Each server loads the nsunix module. Configure the nsvhr module to map requests from your domain to a "socket file"
  ns_section  ns/server/master/module/nsvhr/maps
  ns_param      unix://sopranos.nsunix
  ns_param   unix://sopranos.nsunix
  ns_param      unix://fbi.nsunix
  ns_param   unix://fbi.nsunix
Several utilities and browsers like wget seem to always include a port number. To support those utilities, it is necessary to include the maps that include port 80.

Configure the nsunix module with the hostname and the socketfile name.

  ns_section  ns/server/sopranos/module/nsunix
  ns_param    hostname    
  ns_param    socketfile            sopranos.nsunix
And finally, you will need to make sure the nsunix directory where the socket files live has been created. If your aolserver has been installed at /usr/local/aolserver, then check to make sure the directory /usr/local/aolserver/modules/nsunix has been created.

The master proxies the original requests to the server by reading the request and passing the file descriptor of the response to the right ACS server using Unix domain sockets. It is reasonably efficient. There is no copying of data (but there are probably several context switches involved with each request).

Because you are using nsunix and not nssock, you do not need any additional IP addresses.

Method Two: nsvhr/nssock and unroutable addresses

A less efficient mechanism is to configure the master to use nsvhr and the servers to use nssock. It's less efficient because the master sits between the browser and your server and will copy every request and each response that the server sends. In addition to the copies there are probably several context switches per request.

One benefit of this, is that your target server need not be AOLserver, and it does not even have to be on the same machine.

To do this, you can either place each ACS at an unroutable address such as 192.168.0.XXX, or at a different port as port 2080, 3080, etc. The choice is yours. These addresses will be used for socket communication ONLY on your machine, and if all works well, the clients will never see them.

This is relatively simple to configure.

Assuming you are at and you have DNS CNAME records for and, then configure nsvhr as before, but this time use http-like urls:

    ns_section  ns/server/master/module/nsvhr/maps 

You also need to configure the nssock section of the servers to use the right names, addresses, and port numbers, but I'll leave that to you to determine.


For support, you can try the following: If you have any suggestions, corrections, or additions to this howto, I encourage you to add a comment at the end of this howto.

An alternative: Implementing VAT

I implemented Tom Jackson's VAT hosting module in conjunction with nsvhr/nsunix style virtual hosting.

This yields an entirely AOLserver only solution in which

  • IP addresses are logged correctly (without further changes)
  • small static and dynamic sites can be handled by one AOLserver process
  • larger dynamic sites can each have their own AOLserver process
The basic strategy was to follow the usual nsvhr instructions, but to configure the master/module/nsvhr/maps such that smaller, static sites all map to the same unix domain socket:
ns_section ns/server/master/module/nsvhr/maps
ns_param     unix://sucks
ns_param unix://sucks
And then follow Tom's instructions to set up a VAT server (but implement that VAT server with an nsunix module fetching from sucks)
ns_section ns/server/vat/module/nsunix
ns_param socketfile sucks

Multiple ACS Installations

Follow the usual directions. For each installation, create a new user for that installation (and for ease of maintenance, create a new tablespace for that installation.)

Each ACS will have it's own separate AOLserver process and they can either share the same nsd.tcl file or have their own. When AOLserver starts you can either direct it to the appropriate nsd.tcl file with the -t flag, or you can tell it which server to start with the -s flag. Note: In AOLserver 3.3 and above, AOL has removed much of the functionality of the -s flag. It is now difficult to use one nsd.tcl file to define all of your server parameters.

Here are some excerpts

set server  [ns_info server]

# dbpass(username) password
set dbpass(master)   ""
set dbpass(sopranos) wokeupthismorning
set dbpass(fbi)      rico

# Global parameters
ns_section "ns/parameters"
ns_param   pidfile      "/home/nsadmin/a3/log/${server}.nspid"
ns_param   serverlog    "/home/nsadmin/a3/log/${server}.server.log"

ns_section ns/db/pool/main
ns_param User $server
ns_param Password $dbpass($server)

ns_section ns/db/pool/log
ns_param User $server
ns_param Password $dbpass($server)

# one section good for all modules
# Access log -- nslog
ns_section "ns/server/${server}/module/nslog"
ns_param   file            "/home/nsadmin/a3/log/${server}.access.log"

ns_log notice "[ns_info config]: end $server config"

New Features for AOLserver 3.3ad13

  • Addition of X-FORWARDED-FOR headers within nsvhr and nssock to better make for better logs, use AOLserver ns_log's extendedheaders parameter to log the X-FORWARDED-FOR header within your proxy to include the IP address of the client browser.
  • Realtime addition/deletion of hosts (without requiring nsvhr server to restart) using the ns_vhr command

The future

In the future, I would like to see:
  • Database driven interface to defining and starting virtual hosts to get automate, clean up, and secure the nsd.tcl file.
  • nsunix functionality migrated INTO the nssock module
  • nsvhr/nsunix reverse proxying migrated to Apache
Care to help?

Appendix I: nsunix or nssock?

At the web/db forum at arsdigita, I was asked to explain a bit about unix domain sockets. This is what I wrote. It is quite likely inaccurate. All of what I know about UNIX domain sockets, I learned from Stephens books, (both Advanced Programming in the UNIX Environment, and UNIX Network Programming), AOLserver code, and a pithy comment from Rob Mayoff.

Google leads me to, and, for some online tutorials, and for a pretty complete text.

Basically, UNIX domain sockets are a style of interprocess communication that uses the socket API as its interface and structure. It allows two processes on the same machine to efficiently communicate by sending messages and one certain objects from one process to another. In particular, the one object that can be shared from one process to another is an open file descriptor. After reading just enough of a client browser's request to determine which host and therefore which client server AOLprocess should respond, Nsvhr/nsunix use this latter ability to pass the file descriptor from your machine to the client browser from the master proxy AOLserver process to the client server AOLserver process. The connection from nsvhr to nsunix is very brief, and lasts just long enough to pass the request headers and the file descriptor.

Once the file descriptor has been passed, the client AOLserver process can read the rest of the response itself, and will directly send the response back to the client.

In contrast, the better known Internet domain socket uses networking (basically serial copying) techniques. File descriptors cannot be passed, but you can chain multiple pipes together. That is what the nsvhr/nssock proxy combination do. Same as before, nsvhr in the master AOLserver process receives a request and determines who to send it to. This time, though, it sends it by opening up a much longer lasting connection to the nssock module of the AOLserver client process. This connection will be open for the time it takes the client AOLserver process to read the request as well as respond to it. In fact, the response from AOLserver client is written back to the nsvhr module in the AOLserver master proxy process, and then the AOLserver master proxy sends it back to the client browser.


Appendix II: AOLserver or Apache or Squid?

Almost everything you've seen described here can be done using Apache Virtual Hosting or Squid. Squid can do lots more too, supporting SSL and offering caching all at a very high performance.

Why use AOLserver then? Because it's there. I guess. Okay, here's a better reason. Because it works, and if you are using AOLserver to serve your pages, then you can simplify your operation by using AOLserver as your virtual server. Otherwise you have yet another piece of technology to learn, master, feed and care for. And because I've found it's faster and more efficient.

Appendix III: Upgrading to AOLserver 3.3ad13

This came from the Things Web forum at theashergroup.

Upgrade Steps AOL_3.2ad12 to 3.3ad13+patches

You should be able to upgrade completely transparently to your system. With perhaps a minute or so of downtime. But it requires building a test version of your system first.
  1. Get AOLserver 3.3ad13 onto your system.
    Don't put it in the same source directory that your current version is in. You'll want to keep your current version for safety and comparison.
  2. Build it, and get it working in some temporary directory structure (you will need to modify aolserver/include/ to have it install somewhere else -- look for the PREFIX variable.)
  3. Test AOLserver 3.3ad13 to make sure the basic system is working On it's own it will come up on port 8000.

  4. Get my nsvhr/nsunix reverse proxy patches.
  5. Patch the system (complete instructions are in the release notes.)
  6. Build and install
  7. Bring it up just to make sure that AOLserver is still working at port 8000...

    Then to test nsvhr/nsunix itself will require a bit more complex testing setup.
  8. Copy one (or more) of your hosts' config.tcl files to your test area and modify them so that they starts at port 8000 + whatever port they had orginally started on. Also modify the name of their nsunix socket file so that it doesn't conflict with your working server.

    Add to each ns_section ns/.../module/nsunix section a location parameter, that points to the host, at port 8000. The purpose is to point redirects during testing back to your test version of the master.

    ns_section ns/server/virtual/module/nsunix
    ns_param location    http://virtual:8000
    ns_param socketfile  unix://virtual.nsunix.test
  9. Copy the master proxy config.tcl to your test area and modify it so that it starts at port 8000.
  10. Modify the master proxy config.tcl's nsvhr /map, if you need to, for httpish hosts to point them to their new location at port 8000 + whatever....
  11. Modify the nsvhr /map section so that nsunixish hosts are pointed to their new virtual.nsunix.test socket files.
  12. Bring up your new systems and test.... Repeat as necessary.

Moving into production, once you are satisfied that the new systems are working correctly, ...
  1. Add a location parameter (it's a new parameter) into the .../module/nsunix section of your production server's config.tcl.
  2. Modify the PREFIX parameter in aolserver/include/ to point to your production system
  3. Stop your current webservers
  4. make install the new AOLserver
  5. Start your webservers back up
  6. Test (and maybe redo?)
I think that should do it.

Appendix IV: Security

securing the nscp port with ssh

Here's how you can create secure telnet sessions to your AOLserver's nscp port while ensuring no one else on the net can telnet to your AOLserver's nscp port. I think.


  1. Ensure sshd is running on your machine
  2. Setup your nscp port to only respond on the localhost interface
    ns_section ns/server/mysite/module/nscp
    ns_param port    9990
    ns_param address
    Restart your server
  3. On a remote host, create an ssh tunnel from the remote host to your site. Direct it to forward requests from port 4000 on the remote host to the nscp port on your site's localhost interface.
    mundy:~$  ssh -v -L 4000:localhost:9990 -l jerry
    jerry's password: alexander
    Last login: Wed Nov 22 22:57:03 2000 from catbert
    [jerry@web jerry]$ 
  4. Now on the remote host, telnet to the remote host's localhost interface with the port of the ssh tunnel. You should then be prompted by the nscp running at mysite. So login. Remember to change the nscp user and password though....
    [jerry@web jerry]$ telnet 4000
    Connected to
    Escape character is '^]'.
    login: nsadmin
    Password: x
    Welcome to mysite running at /web/ad10/aolserver/bin/mysite (pid 1005)
    AOLserver/3.2+ad10 (aolserver3_2_ad10) for linux built on Nov  1 2000 
    at 20:22:02
    CVS Tag: $Name: aolserver3_2 $
    mysite:nscp 1> 
I believe this is reasonably secure. Since you set up nscp to only bind on the localhost, no one can telnet to it without going through ssh.

securing your servers

If you're an ISP hosting lots of different sites for various clients, you probably have three worries. H4x0rs breaking one server and using that to compromise your entire system, h4x0rs breaking into one and using that to compromise your others, and malicious clients of yours attacking other clients on your system.

AOLserver appears reasonably secure. I haven't heard of any AOLserver 3x security exploits in the UNIX environment. Still, there are descriptions at ArsDigita and elsewhere on how to chroot your AOLserver. That can help protect your entire system from compromise. I'll leave details of that elsewhere.

But if you need to guarantee that one client can't harm another client, then the thing to do is (in order of importance?)

  1. Give each client its own AOLserver, (the point of this HOWTO)
  2. Make sure each client has its own database user, and
  3. Protect the pageroot for each client so that other clients cannot read or write them
  4. Create different scripts to configure each client's AOLserver server
  5. Create scripts to enable each client to start and stop its own AOLserver server on its own.
Here, a discussion on the ArsDigita web/db forum discusses how to protect one server's files from another....
Running AOL Server+ACS as user "nobody"?

Is it possible to run AOL Server+ACS as user "nobody" instead of user "nsadmin"?

I know it can be done with Oracle's OAS (I have done it with both V3 and V4) and I heard that Apache is running that way as well. Since user "nobody" has very limited powers I think it is much more secure than running under "nsadmin" (which belongs to the dba group!).

BTW, Cynthia had started a thread asking why should nsadmin belong to the dba group.

Why can't we go all the way and totally get rid of the "nsadmin" user? Any comments?

-- Simos Gabrielidis, March 16, 2001

nobody's "powers" are exactly those of any user; the kernel doesn't treat "nobody" differently from any other user.

The proper approach is to create a dedicated user for each web server you wish to run. If you are running,, and on one machine, you should create users "webfoo", "webbar", and "webbaz". Each user should have its own group. The web server should run as user webfoo and group webfoo. User webfoo should only own those files/directories on which the web service needs write access.

An entirely separate user, perhaps named "nsadmin" or "root", should own the AOLserver installation - nsd8x,, etc.

-- Rob Mayoff, March 16, 2001

Rob, thanks for your response. So, if the "webfoo" service is under /web/webfoo, should the webfoo user be the owner of all the files under the webfoo directory, with write permission only to the files/directories that is necessary and read/execute permissions to everything else (under /web/webfoo)?

Thank you,

-- Simos Gabrielidis, March 16, 2001

No, webfoo should only own files that the foo web service needs write access to. If Mr. Badguy breaks your server and finds a way to make the server write to arbitrary files, you want to limit the damage. If Badguy can run arbitrary code, then he can change the permissions on any files owned by webfoo and then write to them. So don't let webfoo own a file unless the foo web service actually needs to write to the file.

So make /web/webfoo's contents be owned by root or nsadmin in general. Change specific files or directories to be owned by webfoo and writable by webfoo only as necessary.

-- Rob Mayoff, March 17, 2001

Thanks Rob! It's clear now!

-- Simos Gabrielidis, March 17, 2001
And here, are some discussions on how to use daemontools so that each client can start/stop its own AOLserver server.
Once more, here's Rob Mayoff's advice:

First, you need to get daemontools running on your computer.


  2. Install daemontools. It's available from It's very easy to install. Just unpack the archive, become root, and run "make setup check".


  3. Create directories named /service and /var/log/svscan.


  4. Create an rc.svscan script that runs svscan in /service. For example:
    export PATH
    exec /usr/local/bin/svscan /service 2>&1 | /usr/local/bin/multilog t /var/log/svscan

    Where you put this script depends on your OS. I call it /etc/rc.d/rc.svscan on my Redhat 6.2 systems.


  5. Add a line to /etc/inittab to run rc.svscan at boot time. For example:

    Which runlevels you specify depends on your OS. Using "345" is appropriate for Redhat 6.2.


  6. Tell init to start svscan by running "telinit q".
For each AOLserver you want to run, you need to set up a service.

  2. Pick a name for your service. Let's say we use


  3. Create a directory named /service/


  4. In that directory, create a shell script named "run" that starts AOLserver. For example:
    . /etc/
    exec /usr/local/aolserver/bin/nsd8x -izkt /usr/local/web/


  5. Rename the directory to /service/


  6. Within five seconds, svscan will notice the new directory and start a supervise process in it. Supervise will run the run script. Supervise will also create a directory named /service/ and put a few files in that directory.


  7. If AOLserver doesn't start, or starts and exits immediately, and there's nothing in the AOLserver log, check /var/log/svscan/current for messages.


  8. You can check the state of the service with the svstat command:
    svstat /service/

    To use svstat, a user must have these permissions:


    • Execute permission on /service/
    • Write permission on /service/
    • Read permission on /service/

    By default, the supervise directory is only executable by root and supervise/ok is only writable by root. If you want all users to be able to check the state of the service, you can use these commands:

    chmod go+rx /service/
    chmod go+w /service/


  9. You can control the service using the svc command. For example, you can restart the service (by sending it a SIGTERM) with this command:
    svc -t /service/

    To use svc, a user must have these permissions:


    • Execute permission on /service/
    • Write permission on /service/

    By default, the supervise directory is only executable by root and supervise/control is only writable by root. If you want all users in group "arsdigit" to be able to control the service, you can use these commands:

    chgrp arsdigit /service/
    chgrp arsdigit /service/
    chmod g+rx /service/
    chmod g+w /service/

-- Rob Mayoff, December 19, 2000

Related Links

Jerry Asher, September, 2001

Copyright 2001 The Asher Group, All rights reserved.