You have just unpacked a release of the ausadmin software for USENET News hierarchy maintenance. If you are not a USENET hierarchy maintainer, this software may not be much use to you.
This software is (C)opyright 1998-2002 by Nick Andrew <firstname.lastname@example.org> and is released under the terms of the GNU General Public License (GPL).
To install and configure this software, follow these instructions in the order they appear.
These instructions are minimal, because this software is alpha quality only!
The "data" directory contains the definitive list of newsgroups in the data/Newsgroups directory, the definitive group descriptions (at least at the moment) in data/ausgroups, some generated files, and some templates for generating messages.
Samples for all templates are available in the samples/ directory.
The templates are:
|booster.template||This is a perl string expression which is eval()ed by the code, so it must start with " and end with " on a line by itself. See bin/Newsgroup.pm to find out what variable substitutions are allowed.|
|checkgroups.footer||This is a text file which is prepended to the generated checkgroups message, default is empty.|
|checkgroups.header||This is a text file which is appended to the generated checkgroups message, default is empty.|
|faq.header||This is a text file containing an article header to be used when posting the regular FAQ.|
|grouplist.footer||This is a text file which is appended to the human-readable group list message.|
|grouplist.header||This is a text file which is prepended to the human-readable group list message.|
|vote-check.msg||This is a text file containing an email header and body which is sent by the vote checker program, to look for invalid email addresses on votes received.|
The software uses PGP 2.6.3(i) to sign control messages, and GnuPG to sign ordinary text files, such as RFDs, vote results, etc.
You will therefore need to have your public and private keys inserted into
The ausadmin software uses the email address: <email@example.com> to accept email votes on proposals. You will need to use a different address. Set up your system so that emailed votes to your chosen address are piped to "bin/incoming" (not "bin/incoming.pl").
The above may get you started with the ausadmin software. There is more work to do before you can start running votes however.
Firstly, there are many ausadmin-specific assumptions hardcoded into the source code. Things like email addresses, hostnames, home directories and domain names. You will need to search and modify these references. If you can remove these assumptions, for example by moving them out to a config file in the data/ directory, then ausadmin will greatly appreciate receiving a patch.
Secondly, you will need to learn the names of files in the vote directories and the meaning of their contents. Each proposal or vote has its own directory under vote/ and the files in that directory are created and modified as the vote proceeds.
The source code is starting to use the word "proposal" rather than vote. A proposal starts out as an RFD, (Request For Discussion), which is constructed from a source file which is received by ausadmin or created by ausadmin. See "Faq/RFD-template.txt" on the website for the file structure. This file is parsed by "bin/parse-rfd.pl" to create a new Proposal in the vote/ subdirectory. See, for example, "bin/make-rfd.pl" and "bin/setup-vote".
An RFD is posted, and discussed, and may become a proper vote after some time. In that case a CFV (Call For Votes) is created from the proposal information and posted. As soon as a CFV is created, the system is ready to receive votes. See, for example, "bin/mkcfv.pl".
Accepted votes are appended to a tally file until the vote completes. After the voting time limit is reached, there are various tools for analysing the messages to detect forgeries and multiple voting. Look for example at "bin/analyse-messages.pl".
Once the vote tally is confirmed, there are tools for counting the vote and creating control messages. See, for example, "bin/genresult.pl"
There's one thing which the software doesn't do well at the moment and that is updating its control files (data/ausgroups and data/Newsgroups/*) when votes pass. This can lead to sending out obsolete checkgroups messages, for example.
There is also an issue with PGP-signing checkgroups and control messages. If there is a passphrase on the PGP keys, then automatic signing of these messages is not possible. This is not good for regular automated posting. I haven't found a way around this security/convenience trade-off yet.
Now that I have scared you with a lot of scripts which you need to know how to use to do things, I can tell you that it is actually a lot easier. There are two tools which you will use all the time. They are "todo.pl" and "action".
"bin/todo.pl" examines every proposal under the vote/ directory and determines if you need to do something to advance the proposal. Recall that proposals start empty, then become RFDs, then CFV, then get voted upon and finally produce a result. There are necessary time delays in all parts of this process, and it is the hardest thing to remember which proposals are ready for which next stage of the process. "todo.pl" helps with this by printing a list of the proposals which are ready for you to make some change. For example:
ausadmin@slim:~$ bin/todo.pl aus.sport.touch ... In discussion, wait until 2002-06-06 (rfd/posted) aus.music.regurgitator ... In discussion, wait until 2002-05-26 (rfd/posted) aus.business ... In discussion, wait until 2002-06-02 (rfd/posted)
This output says that the current state of each of the three proposals is "rfd/posted" (i.e. it's being discussed and the RFD has been posted) and the minimum timeframe for the discussion ends on the listed date.
The other very useful tool is "action". Action goes through each of the proposals in the vote/ directory and determines the proposal's current state. Depending on the current state, "action" knows what the next state in the process should be, and it knows what commands to issue to move the proposal forward. So "action" runs "setup-vote", "mkcfv.pl" and the other scary commands mentioned in the previous section.
"action" prompts you before doing each action. I usually only allow "action" to make one change at a time, and in the middle of each action I check the files in the vote/proposal_name directory to make sure that they are correct (correctly signed, correctly generated, etc...).
This is the end of the setup instructions. There is some documentation under the doc/ directory also.
Please provide feedback to <firstname.lastname@example.org> if you start to use this software and if you make changes.