First you need to install Gale.
Gale locations are DNS-based. To deploy Gale on a domain, clients both internal and external to that domain must be able to find the server representing that domain. They do so by looking up three hostnames (for the example domain dom.ain): dom.ain, gale.dom.ain, and dom.ain.gale.org. One of those hostnames must point to a machine that you control, and that machine must be running your Gale server.
Two daemons should be run on the server machine: galed (required) and gdomain (optional but highly recommended). Galed is the main server, which routes traffic from one location to another, and allows your domain to participate in the global Gale network. It can be run as any user; running it as root is not recommended.
Gdomain is the key server for the domain. It is not strictly necessary. Its main purpose is to serve keys for users who are not currently logged in to the system, and to answer key requests from pre-dangermouse clients. If you don't run it, users with older clients will be annoyed. Gdomain must be run as the user who has access to the private domain key (typically user "gale"). It does not have to be run on the same machine as your galed, but it must be able to make a connection to that machine.
When run for the first time by a new Gale user at your domain, either of the Gale client programs (gsub or gsend) will automatically create a new public/private key pair and invoke the gksign program to sign it with the domain key. This gksign program must be setuid by the Gale user (who has access to the domain private key) to function properly. The domain private key is stored in the Gale user's ~/.gale/auth/private directory under the filename dom.ain.gpri.
At this point we assume that you have gotten Gale installed, and have been able to send yourself messages. All the examples in the top half of the tutorial should work with no errors. Before you start conversing with the unwashed masses (i.e. the rest of us), you need to check a few things.
In order for external users to request your keys via AKD (automatic key distribution), they must be able to connect to your server. Ensure that your galed is run on the proper machine (e.g. gale.dom.ain). If you are firewalled, you need to open up port 11512 to incoming traffic.
The server alone does not serve keys, however. A user's client (e.g. gsub or fugu) will respond to requests for that user's key, if it is running. Alternatively the gdomain process will respond to key requests for all keys in your domain.
The gkinfo program can be useful in debugging key-related problems. gkinfo -v user@dom.ain prints out all sorts of useful information about the key, including the keys that were used to sign the key, the date it was created, and so on.
Your servers spit out streams of useful messages. Use gsub to subscribe to the location _gale.server@dom.ain to listen in on these status messages.
galed may be invoked with the -D switch to enable verbose debugging messages. Use more D's to get more verbose reporting.
At this point we assume that you have gotten your Gale installation up and running, and have successfully exchanged puffs with people external to your network. If you are still getting complaints about people not being able to get your key, fix those problems before continuing.
You can create a discussion group for the users in your domain. There are several ways to do this depending on your desired security and trust level.
You want to create a public discussion hierarchy hosted at your domain, e.g. pub@dom.ain. You have no restrictions on who may send to or subscribe to this location. You are willing to allow external users to converse on this location if they find out about it (perhaps through one of your users).
Create a "null" key pub@dom.ain by running this command as the Gale user:
% su gale Password: % gkgen -w pub@dom.ain /"Public" |
This creates the pub@dom.ain discussion area. At this point, anyone could puff a message to pub@dom.ain --- but only people subscribed to the location would see it!
As the amount of traffic increases, you'll soon want to categorize traffic in your public discussion space according to topic. Gale supports the creation of new sublocations on the fly. In order to allow your users to create arbitrary sublocations of pub, you need to create a "wildcard" key:
% su gale Password: % gkgen -m pub@dom.ain pub.\*@dom.ain |
Be sure to quote the asterisk so your shell doesn't do wildcard expansion! The presence of this key means that your users are now allowed to create (send to and subscribe to) arbitrary sublocations of pub, such as pub.cats@dom.ain or pub.space.ufos@dom.ain.
You are security-conscious and you don't want arbitrary users snooping on your private conversations. You have a list of people who are allowed to subscribe to your private group. You want to create a key with a private membership list:
% su gale Password: % gkgen -m user1@dom.ain -m user2@dom.ain secretgroup@dom.ain |
Only user1 and user2 will be allowed to subscribe to or decrypt messages sent to the location secretgroup@dom.ain. However, note that anyone is able to puff messages to this location. (This will likely be changed in a later release.) If you want to allow people to use arbitrary sublocations within this secret group, create the wildcard key as shown above for the first scenario.
To change the group membership, you must regenerate the key.
You are still security conscious, but you don't want to explicitly list the members of your secret group. You can still create a secret group and control membership by controlling the distribution of the private group key, perhaps because all machines in your domain share a common filesystem. In this case you should generate a group key like this:
% su gale Password: % gkgen othergroup@dom.ain |
Your private group key is stored in ~gale/.gale/auth/private/othergroup@dom.ain.gpri. You must distribute this private key to those users who are authorized to subscribe to this location. If you share a common .../etc/gale directory, copy the file to etc/gale/auth/private/. Alternatively, give it to the authorized users and have them place the key in their ~/.gale/auth/private/ directories.
Again, if you want to enable your users to create arbitrary sublocations, you need to create the wildcard key as described under the first scenario.