Mercurial > p > roundup > code
diff doc/getting_started.txt @ 659:e429649ed124
More documentation cleanups.
- renamed .stx to .txt so they're identifiable as readable files.
- fixed FAQ and announcement formatting
| author | Richard Jones <richard@users.sourceforge.net> |
|---|---|
| date | Wed, 13 Mar 2002 23:00:48 +0000 |
| parents | |
| children | c52122f38c9b 54333751e98d |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/getting_started.txt Wed Mar 13 23:00:48 2002 +0000 @@ -0,0 +1,258 @@ +Getting Started +=============== + +The following instructions assume that you have installed roundup. If you +haven't, you may still proceed - just run the commands as +"``PYTHONPATH=. python roundup/scripts/roundup_admin.py``" for +``roundup-admin`` and +"``PYTHONPATH=. python roundup/scripts/roundup_server.py``" for +``roundup-server``. + +The Instance +------------ + +We'll be referring to the term instance a lot from now on. An instance is a +directory in your filesystem that is where all the information about a live +issue +tracker database is stored. The data that is entered as issues, the users who +access the database and the definition of the database itself all reside there: + +Hyperdatabase + This is the lowest component of Roundup and is where all the issues, + users, file attachments and messages are stored. + +Database schema + This describes the content of the hyperdatabase - what fields are stored + for issues, what user information, etc. Being stored in the instance, + this allows it to be customised for a particular application. It also + means that changes in the Roundup core code do not affect a running + instance. + +Web Interface + The web interface templates are defined in the instance too - and the + actual CGI interface class is defined (mostly using base classes in the + Roundup core code) so it, like the database, may be customised for each + instance in use. + +Instances are created using the ``roundup-admin`` tool. + +Command Line Tool +----------------- + +To initiliase a new instance, run "``roundup-admin init``". You will be asked a +series of questions: + +1. Instance home directory +2. Schema to use +3. Database back-end to use +4. Administration user "admin" password. + +You should also think about whether there is going to be controlled access +to the +instance on the machine the instance is running on. That is, who can +actually make +changes to the database using the roundup-admin tool. See the section on +Users_and_Access_Control for information on how to secure your instance from the +start. + +Roundup is configurable using an ``instance_config.py`` file in the instance +home. It +should be edited before roundup is used, and may have the following variable +declarations: + +MAILHOST + The SMTP mail host that roundup will use to send mail +MAIL_DOMAIN + The domain name used for email addresses +ISSUE_TRACKER_WEB + The web address of the issue tracker's web interface + +The email addresses used by the system by default are: + +ISSUE_TRACKER_EMAIL: ``issue_tracker@MAIL_DOMAIN`` + submissions of issues + +ADMIN_EMAIL: ``roundup-admin@MAIL_DOMAIN`` + roundup's internal use (problems, etc) + +E-Mail Interface +---------------- + +Setup 1: As a mail alias pipe process +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set up a mail alias called "issue_tracker" as (include the quote marks): +"``|/usr/bin/python /usr/local/bin/roundup-mailgw <instance_home>``" + +In some installations (e.g. RedHat 6.2 I think) you'll need to set up smrsh so +sendmail will accept the pipe command. In that case, symlink +``/etc/smrsh/roundup-mailgw`` to "``/usr/local/bin/roundup-mailgw``" and change +the command to:: + + |roundup-mailgw <instance_home> + +To test the mail gateway on unix systems, try:: + + echo test |mail -s '[issue] test' issue_tracker@your.domain + + +Setup 2: As a regular cron job using a mailbox source +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set ``roundup-mailgw`` up to run every 10 minutes or so. For example:: + + 10 * * * * /usr/local/bin/roundup-mailgw <instance_home> mailbox <mail_spool_file> + +Where the ``mail_spool_file`` argument is the location of the roundup submission +user's mail spool. On most systems, the spool for a user "issue_tracker" +will be "``/var/mail/issue_tracker``". + +Setup 3: As a regular cron job using a POP source +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To retrieve from a POP mailbox, use a similar cron entry to the mailbox one:: + + 10 * * * * /usr/local/bin/roundup-mailgw <instance_home> pop <pop_spec> + +where pop_spec is "``username:password@server``" that specifies the roundup +submission user's POP account name, password and server. + + +Web Interface +------------- + +This software will work through apache or stand-alone. + +Stand-alone: + 1. Edit roundup-server at the top - ``ROUNDUP_INSTANCE_HOMES`` needs to know + about your instance. You may also specify the values for + ``ROUNDUP_INSTANCE_HOMES`` on the command-line using "name=home" pairs. + + 2. "``roundup-server [-p port] (name=instance_home)*``" (hostname may be "") + + 3. Load up the page "``/<instance name>/index``" where instance name is the name + you nominated in ``ROUNDUP_INSTANCE_HOMES``. + +Apache: + 1. The CGI script is found in the cgi-bin directory of the roundup + distribution. + + 2. Make sure roundup.cgi is executable. Edit it at the top - + ``ROUNDUP_INSTANCE_HOMES`` needs to know about your instance. + + 3. Edit your "``/etc/httpd/conf/httpd.conf``" and make sure that the + "``/home/httpd/html/roundup/roundup.cgi``" script will be treated as a CGI script. + + 4. Re-start your apache to re-load the config if necessary. + + 5. Load up the page "``/roundup/roundup.cgi/index/``" where instance name is the + name you nominated in ``ROUNDUP_INSTANCE_HOMES``. + + 6. To use the CGI script unchanged, which allows much easier updates, add + these directives to your "httpd.conf":: + + SetEnv ROUNDUP_LOG "/var/log/roundup.log" + SetEnv ROUNDUP_INSTANCE_HOMES "Default=/usr/local/share/roundup/instances/Default" + SetEnv ROUNDUP_DEBUG "0" + + 7. On Windows, write a batch file "roundup.bat" similar to the one below and + place it into your cgi-bin directory:: + + @echo off + set ROUNDUP_LOG=c:\Python21\share\roundup\cgi.log + set ROUNDUP_INSTANCE_HOMES=Default=c:\Python21\share\roundup\instances\Default; + set ROUNDUP_DEBUG=0 + c:\Python21\python.exe c:\Python21\share\roundup\cgi-bin\roundup.cgi + + +Users +----- + +Users and permissions +~~~~~~~~~~~~~~~~~~~~~ + +By default, roundup automatically creates one user when the instance database is +initialised (using roundup-admin init). The user is "admin" and the password is +the one you supply at that time. + +If users attempt to use roundup in any manner and are not identified to roundup, +they will be using the database in a read-only mode. That is, if roundup doesn't +know who they are, they can't change anything. This has the following +repurcussions: + +Command-line interface + The data modification commands (create, init, retire, set) are performed + as the "admin" user. It is therefore important that the database be + protected by the filesystem if protection is required. On a Unix system, + the easiest and most flexible method of doing so is: + + 1. Add a new user and group to your system (e.g. "issue_tracker") + + 2. When creating a new instance home, use the following commands + (substituting instance_home for the directory you want to use):: + + mkdir instance_home + chown issue_tracker:issue_tracker instance_home + chmod g+rwxs instance_home + roundup-admin -i instance_home init + + 3. Now, edit the /etc/group line for the issue_tracker group so it + includes the unix logins of all the users who are going to + administer your roundup instance. If you're running the web or mail + gateways, then be sure to include those users in the group too (on + some Linux systems, these users are "www" or "apache" and "mail".) + +E-Mail interface + Users are identified by e-mail address - a new user entry will be created + for any e-mail address that is not recognised, so users are always + identified by roundup. + +Web interface + Unidentified users have read-only access. If the users database has an + entry with the username "anonymous", then unidentified users are + automatically logged in as that user. This gives them write access. + +**anonymous access and the ANONYMOUS_* configurations.** + + +Adding users +~~~~~~~~~~~~ + +To add users, use one of the following interfaces: + +1. On the web, access the URL .../<instance name>/newuser to bring up a form + which may be used to add a new user. + +2. On the command-line, use:: + + roundup-admin -i <instance home> create user username=bozo password=bozo + address=richard@clown.org + + Supply the admin username and password. roundup-admin will print the id + of the new user. + +3. Any e-mail sent to roundup from an address that doesn't match an existing + user in the database will result in a new user entry being created for + that user. + + +Issues +------ + +To add issues, use one of the following interfaces: + +1. On the web, access the URL .../<instance name>/newissue to bring up a + form which may be used to add a new issue. + +2. On the command-line, use:: + + roundup-admin -i <instance home> create issue title="test issue" + + Supply the admin username and password. roundup-admin will print the id + of the new issue. + +3. Any e-mail sent to roundup with the subject line containing [issue] will + automatically created a new issue in the database using the contents of + the e-mail. + +
