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.
5. 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. 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.
6. Build DomTool
You will first need to acquire DomTool, 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 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.
7. Bootstrapping Domtool
There are several 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.
8. Obsolete Notes
These are included for historical interest / some may be relevant for rewriting the page.
Set up /etc/domtool (or specifically, the SSL CA in there) according to DomTool/SslProcedures
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)
- 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"
- 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
- 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]}