roundup-admin - administrate roundup trackers
roundup-admin [options] <command> <arguments>
-i instance home
Specify the issue tracker "home directory" to administer
-u user[:password]
The user and password to use for commands (partial implemention, see Security Notes below).
|
-h |
Print help text. | ||
|
-d |
Print full designators (e.g. issue1) not just id numbers (1). | ||
|
-c |
When outputting lists of data, comma-separate them. Same as -S ",". |
-S string
When outputting lists of data, separate items with given string.
|
-s |
When outputting lists of data, space-separate them. Same as -S " ". |
-P pragma=value
Set a pragma on the command line. Multiple -P options can be specified to set multiple pragmas.
|
-V |
Be verbose when importing data. |
|||
|
-v |
Report Roundup and Python versions and quit. |
Only one of -s, -c or -S can be specified.
If no command is provided on the command line, roundup-admin will enter an interactive mode. More details about these commands are available using the help command.
A designator is a classname and a nodeid concatenated, eg. bug1, user10, ....
Roundup-admin takes a number of commands:
|
help |
prints help (same as -h) |
help <subcommand>
Print command-specific help
help all
Print available help for all commands.
|
commit |
Commit changes made to the database during an interactive session. |
The changes made during an interactive session are not automatically written to the database - they must be committed using this command.
One-off commands on the command-line are automatically committed if they are successful. See also rollback.
create classname property=value ...
This creates a new entry of the given class using the property name=value arguments provided on the command line after the "create" command.
display designator[,designator]*
This lists the properties and their associated values for the given node. The pragma display_header can be used to add a header between designators that includes the active/retired status of the item.
export [[-]class[,class]] export_dir
Export the database to colon-separated-value files. To exclude the files (e.g. for the msg or file class), use the exporttables command.
Optionally limit the export to just the named classes or exclude the named classes, if the 1st argument starts with ’-’.
This action exports the current data from the database into colon-separated-value files that are placed in the nominated destination directory.
exporttables [[-]class[,class]] export_dir
Export the database to colon-separated-value files, excluding the files below $TRACKER_HOME/db/files/ (which can be archived separately). To include the files, use the export command.
filter classname propname=value ...
Find the nodes of the given class with a given property value. Multiple values can be specified by separating them with commas. If property is a string, all values must match. I.E. it’s an matches. I.E. an ’or’ operation.
find classname propname=value ...
Find the nodes of the given class with a given link property value.
genconfig <filename>
Generate a new tracker config file (ini style) with default values in <filename>. Note that this does not preserve any settings from the current tracker. Use updateconfig for that.
get property designator[,designator]*
Get the given property of one or more designator(s).
Retrieves the property value of the nodes specified by the designators.
history designator [skipquiet] [raw]
Lists the journal entries viewable by the user for the node identified by the designator. If skipquiet is added, journal entries for quiet properties are not shown. Without the raw option a more human readable output format is used.
import import_dir
Import a database from the directory containing CSV files, two per class to import.
The imported nodes will have the same nodeid as defined in the import file, thus replacing any existing content.
The new nodes are added to the existing database - if you want to create a new database using the imported data, then create a new database (or, tediously, retire all the old data). See also export.
importtables import_dir
Import a database from the directory containing CSV files, two per class to import.
The imported nodes will have the same nodeid as defined in the import file, thus replacing any existing content.
This only imports database tables. It does not import files/message content. It is used to import data exported by exporttables. See also exporttables.
initialise [adminpw]
Initialise a new Roundup tracker.
The administrator details will be set at this step.
install [template [backend [key=val[,key=val]]]]
Install a new roundup tracker.
The command will prompt for the tracker home directory (if not supplied through TRACKER_HOME or the -i option). The template and backend may be specified on the command-line as arguments, in that order.
Command line arguments following the backend allows you to pass initial values for config options. For example, passing "web_http_auth=no,rdbms_user=dinsdale" will override defaults for options http_auth in section [web] and user in section [rdbms]. Please be careful to not use spaces in this argument! (Enclose whole argument in quotes if you need spaces in option value).
The initialise command must be called after this command in order to initialise the tracker’s database. You may edit the tracker’s initial database contents before running that command by editing the tracker’s dbinit.py module init() function.
See also initopts help.
list classname [property]
Lists all instances of the given class. If the property is not specified, the "label" property is used. The label property is tried in order: the key, "name", "title" and then the first property, alphabetically.
With -c, -S or -s print a list of item id’s if no property specified. If property specified, print list of that property for every class instance.
The pragma show_retired can be used to print only retired items or to print retired and active items. The default is to print only active items.
migrate
Update a tracker’s database to be compatible with the Roundup codebase.
You should run the "migrate" command for your tracker once you’ve installed the latest codebase.
Do this before you use the web, command-line or mail interface and before any users access the tracker.
This command will respond with either "Tracker updated" (if you’ve not previously run it on an RDBMS backend) or "No migration action required" (if you have run it, or have used another interface to the tracker, or possibly because you are using anydbm).
It’s safe to run this even if it’s not required, so just get into the habit.
pack period | date
Remove journal entries older than a period of time specified or before a certain date.
perftest [mode] [arguments]*
Run performance test. For example test the effect of changing password hashing parameters.
pragma setting=value|list
Set internal settings to a value. E.G.
pragma
verbose=True
pragma verbose=yes
pragma verbose=on
pragma verbose=1
will turn on verbose mode for roundup-admin.
pragma list
will show all settings and their current values. If verbose is enabled hidden settings and descriptions will be shown.
reindex [classname|classname:#-#|designator]* This will
re-generate the search indexes for a tracker. You can specify a specific item (or items) (e.g. issue23), range(s) of items (e.g. issue:1-1000), class(es) (e.g. issue) or reindex all items in the database if no arguments are supplied.
restore designator[,designator]*
Restore the retired node specified by designator.
The given nodes will become available for users again.
retire designator[,designator]*
This action indicates that a particular node is not to be retrieved by the list or find commands, and its key value may be re-used. See also restore.
rollback
Undo all changes that are pending commit to the database.
The changes made during an interactive session are not automatically written to the database - they must be committed manually. This command undoes all those changes, so a commit immediately after would make no changes to the database.
security [Role name]
Display the Permissions available to one or all Roles.
set items property=value property=value ...
Set the given properties of one or more items(s).
The items are specified as a class or as a comma-separated list of item designators (ie "designator[,designator,...]").
This command sets the properties to the values for all designators given. If the value is missing (ie. "property=") then the property is un-set. If the property is a multilink, you specify the linked ids for the multilink as comma-separated numbers (ie "1,2,3").
specification classname
Show the properties for a classname.
templates [trace_search]]
Lists the names, location and description of all known templates.
table classname [property[,property]*]
Lists all instances of the given class. If the properties are not specified, all properties are displayed. By default, the column widths are the width of the largest value.
The pragma show_retired can be used to print only retired items or to print retired and active items. The default is to print only active items.
updateconfig <filename>
This is used when updating software. It merges the config.ini from the tracker with new settings from the new software. The merged/updated config file is written to <filename>.
Commands may be abbreviated as long as the abbreviation matches only one command, e.g. l == li == lis == list.
You can edit the command line and interact with history in roundup-admin’s interactive mode. On Linux like systems, GNU Readline is required. On Mac’s libedit can be used as well. On Windows pyreadline3 is required. See: https://docs.python.org/3/library/readline.html for details on readline.
Roundup-admin will save the history between roundup-admin sessions. The commands are saved to the .roundup_admin_history file in the user’s home directory. You can set the pragma history_length on the roundup-admin command line to change the amount of available and stored history for the session.
If you are using GNU readline, you can persistently change the history size by adding: set history-size 100 to the init file .roundup_admin_rlrc located in the user’s home directory.
Mac users using libedit should be able to persistently save history and set the history size by adding history size 100.
Users of pyreadline3 can use: history_length(100).
The -u user setting does not currently operate like a user logging in via the web. The user running roundup-admin must have read access to the tracker home directory. As a result the user has access to the files and the database info contained in config.ini.
Using -u user sets the actor/user parameter in the journal. Changes that are made are attributed to that user. The password is ignored if provided. Any existing username has full access to the data just like the admin user. This is an area for further development so that roundup-admin could be used with sudo to provide secure command line access to a tracker.
ROUNDUP_LOGIN
Provides an alternate way to set the user.
roundup-admin
-h
roundup-admin help -- this help
roundup-admin help <command> -- command-specific help
roundup-admin help all -- all available help
roundup-demo(1), roundup-mailgw(1), roundup-server(1)
This manpage was written by Bastian Kleineidam <calvin@debian.org> for the Debian distribution of roundup.
The main author of roundup is Richard Jones <richard@users.sourceforge.net>.
roundup-demo - create a roundup "demo" tracker and launch its web interface
roundup_demo [-h] [-b BIND_ADDRESS] [-b {anydbm,mysql,sqlite,postgresql}] [-t {minimal,jinja2,classic,responsive,devel}] [-p PORT] [-P URLPORT] [-V] [directory] [backend] [nuke]
directory
The home directory for the new demo tracker. (*)
backend
Choose backend database. Depricated, use -b.
|
nuke |
Create a fresh demo tracker (deleting the existing one if any). E.G. |
roundup-demo -b sqlite -t
classic ./mytracker nuke
will remove an existing tracker (if present) from the
directory ./mytracker. Then it will create and serve
a new empty classic tracker using the sqlite backend.
-h, --help
Show the help message and exit
-B BIND_ADDRESS, --bind_address BIND_ADDRESS
Choose address for server to listen at. Use 0.0.0.0 to bind to all addreses. Default: 127.0.0.1.
-b
{anydbm,mysql,sqlite,postgresql},
--backend_db
{anydbm,mysql,sqlite,postgresql}
Choose backend database. Default: sqlite. Available backends are subject to availability on your system.
-t
{minimal,jinja2,classic,responsive,devel},
--template
{minimal,jinja2,classic,responsive,devel}
Use specified template when building tracker. (*)
-h HOSTNAME, --hostname HOSTNAME
Set the hostname used in the URL. This does not make the server listen at the hostname. Use the hostname with -B to listen on that IP address.
-p PORT, --port PORT
Listen at this port. Default: search for open port starting at 8917.
-P URLPORT, --urlport URLPORT
When using docker this option passes the docker external port to the demo instance. If using docker ... -p 9090:8917 ... this should be set to -P 9090. Default: as selected by --port.
-V, --version
Show program’s version number and exit
If items marked with (*) are missing, they will be asked for interactively when setting up the tracker.
This command creates a fresh demo tracker for you to experiment with. The email features of Roundup will be turned off (so the nosy feature won’t send email). It does this by removing the nosyreaction.py module from the demo tracker’s detectors directory. If you wish to send email to promote the tracker to production, you will need to copy nosyreaction.py from the default tracker templates directory. The templates command from roundup-admin(1) can help you locate a replacement.
If you wish, you may modify the demo tracker by editing its configuration files and HTML templates. See the customisation manual for information about how to do that.
Once you’ve fiddled with the demo tracker, you may use it as a template for creating your real, live tracker. Simply run the roundup-admin command to install the tracker from inside the demo tracker home directory, and it will be listed as an available template for installation. No data will be copied over.
roundup-admin(1), roundup-mailgw(1), roundup-server(1)
This manpage was written by Richard Jones and extensively modified by John Rouillard <rouilj@users.sourceforge.net>.
roundup-mailgw - mail gateway for roundup
roundup-mailgw [-h|--help] [-v] [--version] [-c|--default-class default_class] [-S|--set-value [class.]field=value] [-O|--oauth-directory directory] [-T|--oauth-token-endpoint endpoint-url] [instance_home] [mail source [specification]]
-v --version
Print version and exit.
-c --default-class hyperdb class
specify the default tracker class - one of issue (the default), msg, file, user etc. Overrides the tracker’s mailgw default_class setting.
-S --set-value [class.]property=value[;property=value]
specify the values to set on the class specified as prefix using the same format as the Subject line property manipulations. If the class prefix is left out it defaults to msg. Can also be specified with --set-value (and abbreviated to --set).
-O --oauth-directory directory
Only with OAuth authentication specify the directory containing additional OAuth credentials.
-T --oauth-token-endpoint url
Token endpoint URL of your cloud provider, only used with OAuth.
The roundup mail gateway may be called in one of four ways:
|
• |
without arguments which will use the env var ROUNDUP_INSTANCE, | ||
|
• |
with an instance_home as the only argument, | ||
|
• |
with both an instance_home and a mail spool file, or | ||
|
• |
with both an instance home and a mail source type and its specification. |
PIPE
If there is no mail source specified, the mail gateway reads
a single message from the standard input and submits the
message to the roundup.mailgw module.
UNIX
mailbox
In this case, the gateway reads all messages from the UNIX
mail spool file and submits each in turn to the
roundup.mailgw module. The file is emptied once all messages
have been successfully handled. The file is specified as:
mailbox /path/to/mailbox
In all of the following mail source types, the username and password can be stored in a ~/.netrc file. If done so, only the server name needs to be specified on the command-line.
The username and/or password will be prompted for if not supplied on the command-line or in ~/.netrc.
POP
For the mail source "pop", the gateway reads all
messages from the POP server specified and submits each in
turn to the roundup.mailgw module. The server is specified
as:
pop
username:password@server
The username and password may be omitted:
pop username@server
pop server
are both valid.
POPS
Connect to the POP server over ssl/tls. This supports the
same notation as POP.
APOP
Same as POP, but using Authenticated POP:
apop
username:password@server
IMAP
Connect to an IMAP server. This supports the same notation
as that of POP mail.
imap
username:password@server
It also allows you to specify a specific mailbox other than
INBOX using this format:
imap
username:password@server
mailbox
IMAPS
Connect to an IMAP server over ssl/tls. This supports the
same notation as IMAP.
imaps
username:password@server
[mailbox]
IMAPS_CRAM
Connect to an IMAP server over ssl/tls using CRAM-MD5
authentication. This supports the same notation as IMAP.
imaps_cram
username:password@server
[mailbox]
IMAPS_OAUTH
Connect to an IMAP server over ssl/tls using OAUTH
authentication. Note that this does not support a password
in imaps URLs. Instead it uses only the user and server and
a command-line option for the directory with the files
access_token, refresh_token,
client_secret, and client_id. By default this
directory is oauth in your tracker home directory.
The access token is tried first and, if expired, the refresh
token together with the client secret is used to retrieve a
new access token. Note that both token files need to be
writeable, the access token is continuously replaced
and some cloud providers may also renew the refresh token
from time to time:
imaps_oauth username@server
[mailbox]
The refresh and access tokens (the latter can be left
empty), the client id and the client secret need to be
retrieved via cloud provider specific protocols or
websites.
ROUNDUP_INSTANCE
This can be used to set the instance directory. If it is
set, the instance_home argument is optional.
If your msg class has a messsagetype property you can set up aliases to receive the different types of messages. Setting up an alias in your MTA Using:
tracker:
|/tools/roundup/bin/roundup-mailgw
-S "msg.messagetype=reply - to all"
/var/roundup/sysadmin
(the lines are split for readability. In the alias file they will be on the same line). Replace /tools/roundup/bin/roundup-mailgw by your path to the roundup-mailgw. This creates the email alias "tracker". All messages sent to it have their messagetype property set to "reply - to all". The roundup tracker instance is located at /var/roundup/sysadmin.
A comment alias would receive emails at tracker_comment with:
tracker_comment:
|/tools/roundup/bin/roundup-mailgw
-S "msg.messagetype=to tech"
/var/roundup/sysadmin
which would be a technical message. These messages can trigger different workflows based on the messagetype.
Both examples use the default class specified in the tracker’s config.ini (usually the issue class).
You can also set properties directly on the issue class. If your tracker’s issue has a "private" property that limits who can view an issue and its messages:
security:
|/tools/roundup/bin/roundup-mailgw
-S "issue.private=true" -S
"issue.keyword+=security"
/var/roundup/sysadmin
would set the private property on a issue to restrict visiblity and mark the issue as a security topic using a keyword.
Both examples use the default class specified in the tracker’s config.ini (usually the issue class).
roundup-admin(1), roundup-demo(1), roundup-server(1)
This manpage was written by Bastian Kleineidam <calvin@debian.org> for the Debian distribution of roundup.
The main author of roundup is Richard Jones <richard@users.sourceforge.net>.
Updates by John Rouillard <rouilj@users.sourceforge.net> and Ralf Schlatterbeck <rsc@runtux.com>.
roundup-server - start roundup web server
roundup-server [options] [name=tracker home]*
-C file or --config file
Use options read from the configuration file (see below).
-n hostname
Sets the host name or IP address to listen on. Default is localhost (127.0.0.1). Use 0.0.0.0 to listen on all interfaces on the system.
-p port
Sets the port to listen on (default: 8080).
-d PIDfile
Run the server in the background and write the server’s PID to the file indicated by PIDfile. The -l (or -L) option must be specified if -d is used.
|
-D |
Run the server in the foreground even if -d is used. |
-t fork|thread|debug|none
Control multi-process mode. debug and none are always available. If an invalid mode is specified the server starts in none (also called single) mode. Default fork.
-m max_children
Set the maximum number of child processes (servers). This value may need to be increased on a heavily loaded site. Default 40.
-l file
Sets a filename to log to (instead of stdout). This is required if the -d option is used.
|
-P |
If a reverse proxy is used in front of the roundup-server, the server will log the ip address of the proxy, not the client browser. Using -P logs the left most entry in the X-Forwarded-For http header as the IP address of the client. This address will be logged or resolved to a hostname (with -N) and a ’+’ character will be appended. -P should only be used when the roundup server is accessible only from trusted proxy hosts. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For for details and warnings about using the X-Forwarded-For header. | ||
|
-L |
Have the server log using the Python logger with key roundup.http. |
-i file
Sets a filename to use as a template for generating the tracker index page. The variable "trackers" is available to the template and is a dict of all configured trackers. If you connect to the root of the server (without a tracker name), the default index page is shown. Using -i allows you to customize the index page.
-I header1[,header2,...]
Pass the header(s) and their values to the backend. This allow-list of header variables can be used by custom code in the tracker or with a tracker’s http_auth_header configuration option to allows a front end server to authenticate a user and pass the user identity to roundup.
|
-s |
Enables use of SSL. In most cases, you will want to run a real web server (Apache, Nginx) as a proxy to roundup-server running without SSL. The real web server can filter/rate limit/firewall requests to roundup-server. |
-e file
Sets a filename containing the PEM file to use for SSL. The PEM file must include both the private key and certificate with appropriate header/trailer markers:
-----BEGIN
PRIVATE KEY-----
-----END PRIVATE KEY-----
and
-----BEGIN
CERTIFICATE-----
-----END CERTIFICATE-----
If no file is specified, a temporary self-signed certificate will be used.
|
-N |
Log client machine names instead of IP addresses (much slower). |
-V HTTPVER
By default roundup-server uses HTTP/1.1 to enable keepalives for faster response. HTTPVER can be set to HTTP/1.0 to disable keepalives.
|
-u UID |
Runs the Roundup web server as this UID. |
|||
|
-g GID |
Runs the Roundup web server as this GID. |
-v or --version
Print version and exit.
-h or --help
Print help and exit.
--save-config
Create configuration file and exit. The old config.ini will be saved to config.bak. Note that this command doesn’t attempt to load or verify an existing config.ini. Running this in a tracker home directory will move the existing config.ini to config.bak and replace it with the roundup-server’s config.ini. This will make the tracker in the directory fail to start until the original config.ini is restored.
name=tracker home
Sets the tracker home(s) to use. The name variable is how the tracker is identified in the URL (it’s the first part of the URL path). The tracker home variable is the directory that was identified when you did "roundup-admin init". You may specify any number of these name=home pairs on the command-line. For convenience, you may edit the TRACKER_HOMES variable in the roundup-server file instead. Make sure the name part doesn’t include any url-unsafe characters like spaces, as these confuse the cookie handling in browsers like IE.
If you connect to the root directory (I.E. you do not include the name component in the URL, the server will display an index page of trackers served by roundup-server if more than one tracker is defined. If only one tracker is defined it will redirect to the tracker.
roundup-server -p 9000 bugs=/var/tracker reqs=/home/roundup/group1
Start the server on port 9000 serving two trackers; one under /bugs and one under /reqs.
If you connect to the server at the root level (http://host:9000/) it will display a list of the available trackers.
See the "admin_guide" in the Roundup "doc" directory.
roundup-admin(1), roundup-demo(1), roundup-mailgw(1)
This manpage was written by Bastian Kleineidam <calvin@debian.org> for the Debian distribution of roundup.
The main author of roundup is Richard Jones <richard@users.sourceforge.net>.