Anyterm

The Standalone Daemon

Anyterm has experimental support for standalone operation, without using Apache. There are a couple of reasons why you might want to do this. Firstly, in light-weight embedded applications you might want to avoid the complexity of Apache. Secondly, making Anyterm and Apache independent means that you can still access Anyterm when Apache has failed.

You can also proxy from Apache to the standalone daemon. This is required if you want Anyterm to appear on the same port number as your main web content, and if you want to use Apache's SSL and authentication features.

At some point in the future I plan to make this daemon the main version of Anyterm; it is already probably superior to the Apache module in a few ways. It is still somewhat experimental, however.

This page gives some basic installation instructions, but you may need to poke around in the source code to make it work for you. I will make the installation process simpler before removing the "experimental" label.

Do please get in touch if you think you could help with further development.

1. Prerequisites

See the prerequisites section in the main installation instructions for details. The standalone daemon needs everything that the Apache module needs, apart from Apache.

More Boost libraries are needed. On Debian you need libboost-dev, libboost-thread-dev, libboost-program-options-dev, and the other packages that they depend on. On other distributions you'll probably get a single larger Boost package.

2. Compiling

You should just be able to "make" in the "daemon" directory. Note that the files in the browser directory are embedded in the executable, so if you change any of those files you need to rebuild. The Spirit parser in Request.cc may take quite a long time to compile.

3. Cross-Compiling

There is some support for cross-compilation and have got the standalone Anyterm daemon to run on my Linksys NSLU2 running Debian. Anygetty can also be cross-compiled. If you want to try this, see the slugmake.sh scripts in the various directories.

4. Testing

Run ./anytermd --help for the command-line arguments. Running it without arguments will use reasonable defaults; it should fork, and the foreground process will return. ps should show an anytermd process running and syslog will contain diagnostics.

Point your web browser at http://localhost:8080/. See TrivialAuthenticator.hh for the username and password. You should see an anyterm window running a shell.

5. Serial Ports

From version 1.1.12 the standalone daemon can connect to a serial port, rather than a subprocess. See the --help output for details.

6. Secure HTTPS Support

The standalone daemon doesn't currently have built-in support for secure connections using HTTPS (aka SSL and TLS). It can, however, be added using the Stunnel program as follows:

• Install Stunnel. On Debian, the package is called stunnel4.
• Generate an SSL certificate. The Debian package has a description of how to do this in /usr/share/doc/stunnel4/README.Debian. Something like the following may work, but you should understand the details of what's happening as the security of your system is dependent on it:
$ openssl req -new -x509 -nodes -days 365 -out stunnel.pem -keyout stunnel.pem $ dd if=/dev/urandom of=temp_file count=2 $ openssl dhparam -rand temp_file 512 >> stunnel.pem $ ln -sf stunnel.pem `openssl x509 -noout -hash < stunnel.pem`.0 $ chmod 600 stunnel.pem
• Start the Anyterm daemon, listening for unencrypted HTTP on one port number. If you want to allow only HTTPS connections from outside, use the --local-only option:
$ anytermd -p 8123 --local-only
• Start Stunnel, listening on some other externally-accessible port number and forwarding to Anyterm:
$ stunnel -d 8443 -r 8123 -p stunnel.pem -P ''
• You should now be able to connect to Anyterm at https://example.com:8443/.

7. Issues

This is very much a work in progress. In particular, the following remain to be implemented:

• Native Encryption (using GNU TLS or OpenSSL).
• Proper authentication (I'm considering a database backend).
• Proper logging.
• Proper error handling.

Do please get in touch if you think that you can help with any of this. I'd particularly value help with the SSL integration, since that is not an area that I know much about and getting it right is obviously quite important.