DomTool source code is, at places, HCoop and OpenAFS-specific. Here's a documented procedure for setting up DomTool on non-HCoop machines and without using AFS. 

The instructions on this page are unlikely to produce a working production setup, but should be sufficient to get started with a local development instance.

== System Prerequisites ==

If you wish to actually publish configuration, there are a few prerequisites. '''These are not necessary for a development build.'''

You will need to create a user named `domtool`, DomTool is currently hard coded to require the user.

If you wish to actually publish configuration you will also need to grant the `domtool` user some sudo privileges and use `/var/domtool` for the `localRoot`. [[https://git.hcoop.net/?p=hcoop/domtool2.git;a=blob;f=bootstrap/domtool.sudoers|bootstrap/domtool.sudoers]] in the source tree has an example configuration for sudo. Neither is required for a development setup, domtool can be run without sudo access and with an alternative `localRoot`, but the publishing scripts are reliant upon both so you will be unable to actually control services.

== Build DomTool ==

You will first need to acquire DomTool, [[DomTool/Building|build it]], and customize the default configuration for your site.

The minimally required changes are:

 * Customize `config/core/core.sml` to override core values
   * `sharedRoot` should be a directory accessible from all systems that will be part of the domtool cluster. Traditionally this is in afs for a production system. For development it should be something like `/home/$USER/domtool/shared`
   * `localRoot` should be `/var/domtool` for a production installation. For development it should be something like `/home/$USER/domtool/local`.
 * Create a local `config.sml`. An example suitable for local development is provided in the source tree at [[https://git.hcoop.net/?p=hcoop/domtool2.git;a=blob;f=config.example.sml|config.example.sml]]. You will need to customize a few variables:
   *  `myNode` is your machine's short hostname (`hostname -s` generally)
   * `defaultDomain` is your machine's domain name (`hostname -d` generally). 
   * `caDir` is the location of the domtool certificate authority which must be in a secure location on the domtool dispatcher server only for a production build (writable only by root, and readable but not writable by the domtool user). For a development build. it can be something like `/home/$USER/domtool/ca`.

After you have set up the configuration, build domtool, and it should be able to be bootstrapped. You do not need to install domtool system-wide to test.

== Bootstrapping Domtool ==

There are several [[https://git.hcoop.net/?p=hcoop/domtool2.git;a=blob;f=bootstrap/README|scripts included with domtool to assist with bootstrapping]].

If you are setting up a development environment, the minimal steps are:

 * Create `bootstrap/$defaultDomain.core.ssl.conf`, setting `ca_dir` to the value you used for `caDir`, and `org_domain` to `$defaultDomain`.
 * Execute `cd bootstrap && ./bootstrap` should then create a basic setup.


== Obsolete Notes ==

These are included for historical interest / some may be relevant for rewriting the page. 

 0. Set up /etc/domtool (or specifically, the SSL CA in there) according to [[DomTool/SslProcedures]]
 0. Build and install the DomTool suite as explained in [[DomTool/Building]] and [[DomTool/Installation]]. (When creating user 'domtool', you can choose /home/domtool as the home directory)
 0. Edit /etc/init.d/domtool-* to replace shebang line /usr/bin/pagsh.openafs with /bin/sh (or /bin/bash), and replace "/usr/bin/k5start" with "/usr/local/bin/k5start"
 0. Edit /usr/local/bin/domtool-admin-sudo to replace shebang line /usr/bin/pagsh.openafs with /bin/sh (or /bin/bash), and to comment the kinit and aklog lines
 0. Create /usr/local/bin/k5start with the following content and chmod 755 it (remove "\" at the beginning):
{{{
\#!/bin/sh
# This counts on BASH_ARGV being a stack (bash v3.0+)
${BASH_ARGV[0]}
}}}
----
CategoryNeedsWork