welcome: please sign in

Diff for "DomTool/NonHCoopSetup"

Differences between revisions 6 and 7
Revision 6 as of 2011-03-06 11:54:13
Size: 1105
Editor: ClintonEbadi
Comment:
Revision 7 as of 2018-08-11 17:41:09
Size: 3903
Editor: ClintonEbadi
Comment: try to fix up NonHCoopSetup a bit, very incomplete still
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
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. 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 ==

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:

 * Edit `config/core/core.sml` to set `sharedRoot` to 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 can be any directory readable by the domtool user you created (e.g. `/home/domtool/shared`).
 * 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 should be in a secure location for production. For development it just needs to be a directory your user can write to and the domtool user can read from, unless you grant domtool sudo permissions in which case you '''must''' take steps to ensure it is set up securely (writable only by root, and readable but not writable by domtool).

After you have set up the configuration, build domtool and install domtool, and it should be able to be bootstrapped.

== 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/$myNode.$defaultDomain.ssl.conf`, setting `ca_dir` to the value you used for `caDir`, and `org_domain` to `$myNode.$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.
Line 13: Line 49:

(NOTE: this document is unmaintained and not to be used as source of any information)
Line 16: Line 50:
CategoryOutdated CategoryNeedsWork

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.

1. System Prerequisites

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.

2. Build DomTool

You will first need to acquire DomTool build it, and customize the default configuration for your site.

The minimally required changes are:

  • Edit config/core/core.sml to set sharedRoot to 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 can be any directory readable by the domtool user you created (e.g. /home/domtool/shared).

  • 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 should be in a secure location for production. For development it just needs to be a directory your user can write to and the domtool user can read from, unless you grant domtool sudo permissions in which case you must take steps to ensure it is set up securely (writable only by root, and readable but not writable by domtool).

After you have set up the configuration, build domtool and install domtool, and it should be able to be bootstrapped.

3. 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/$myNode.$defaultDomain.ssl.conf, setting ca_dir to the value you used for caDir, and org_domain to $myNode.$defaultDomain.

  • Execute cd bootstrap && ./bootstrap should then create a basic setup.

4. Obsolete Notes

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

  1. Set up /etc/domtool (or specifically, the SSL CA in there) according to DomTool/SslProcedures

  2. 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)

  3. 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"
  4. 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
  5. 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

DomTool/NonHCoopSetup (last edited 2018-08-11 18:48:45 by ClintonEbadi)