This page was moved from the Toolserver wiki.
Toolserver has been replaced by Toolforge. As such, the instructions here may no longer work, but may still be of historical interest.
Please help by updating examples, links, template links, etc. If a page is still relevant, move it to a normal title and leave a redirect.
Multi-maintainer projects are tools which have more than one maintainer. Each multi-maintainer tool has a dedicated Unix account and an assigned list of users have access to the account.
Creating a new project and adding users
- New project
- File a request in JIRA, giving the name of the project and the user(s) who should have access. Use the "Toolserver" project in JIRA and the "Accounts" component.
- Please mention if you require SQL access and/or a Subversion repository.
- Existing project
- You have to be a member of the multi-maintainer-project to request any changings.
- File a request in JIRA, giving the name of the project and request your changing (like adding of an user, SQL access, a jira-project, a fisheye-view, a Subversion repository or anything else). Please make sure to always provide the name of the multi-maintainer-project (and the login-names of the users if users should be added or removed). If a user should be add/removed please also tell us if the user should be add/removed from Subversion too.
Once your project is created, you can use a
.forward file as usual to direct mail that is sent by
cron and other system processes. To use multiple destination email addresses, put each on a separate line.
Listing the users in an MMP:
$ getent group <name>
- Taking over
Anyone can take over a abandoned MMP if the MMP has no active members left (=all member-accounts are expired). Please request the adding of yourself in JIRA and notice there that you like to take-over the MMP. If the MMP controls a bot, please notice that you have to re-request every right the bot has in the wiki-projects again.
willow# add-mmt <name> willow# add-mmt-maintainer <name> <user>
Becoming the project user
To access the project, run
become <projectname> on a login server. You cannot log in as the project; you must log in as yourself and use
become. However, every user who has access will be in the
<projectname> group; making all files and directories group-read/writeable allows you to log in and edit normally. You can also use
sudo -u <projectname> <command> to run a command.
To return to your own account, type Ctrl-D or
exit to exit the shell.
Differences from ordinary accounts
There are several differences between multi-maintainer accounts and ordinary user accounts.
- As described above, multi-maintainer accounts cannot log in. This also means they cannot ssh between toolserver hosts.
- While user databases have names like
u_username, databases for multi-maintainer projects have names like
- Similarly, multi-maintainer projects will have their svn repository names prefixed with
p_, so the URL will be
- Note: maintainers do not get access to an MMP's SVN repositorry automatically. You have to ask a root to set it up manually, untill they get fed up and fix the script. (Roots: see Admin:Subversion)
If you didn't request database access when you requested the MMP, you can use JIRA to request database access. Once you have a
.my.cnf file in your project's home directory, you have access. You are responsible for creating user databases on your desired SQL server. You can use the comment
mysql -hHOSTNAME to connect to the server and then use the SQL command
CREATE DATABASE as usual. Your database should be named
Since you cannot log into a multi-maintainer account, the normal SCP/SFTP process for transferring files does not work. Instead, you should make sure that the tool's files are group-writable, then use SCP or SFTP as your normal account; since you are a member of the tool's group, you will be able to write to the files. Note that the multi-maintainer account's home dir will have the setguid flag set, so files transferred there will become owned by the multi-maintainer account's group.
Hint: if you use scp/sftp to transfer the file, and you have a restrictive umask setting (e.g. 0067, meaning that per default, only you can read files that you create), any file transferred will end up being readable only be the user, even though it's owned by the multi-maintainer account's group. To solve this, set the file to be group readable (and, if you like, writable), and then use
scp -p (or
rsync -p) to transfer. This will preserve the file's permissions, so it will remain group readable in the multi-maintainer account's home dir.
- The home directory will be
/home/project/t/h/e/theproject, containing a subdirectory
public_html. When possible, do not hard-code this path in your scripts; use the
$HOMEenvironment variable instead. The webserver does not set
$HOMEin the environment of cgi scripts, but the information returned by
getpwnamis correct and can be used to get the home directory.
- The URL to the
public_htmldirectory will be
On the Linux hosts, screen just works. However, on the Solaris hosts, using screen under a multi-maintainer account is slightly more complicated than under a normal account. The reason for this is that screen needs read-write access to your terminal device, which by default is only allowed for you. When you switch to the tool account and run screen, it is no longer running with your credentials, so it cannot access the terminal.
You can work around this with the
ttyallow script; run it before switching to the tool account, and you will be able to run screen:
% ttyallow <projectname>
It may also be possible to work around this by starting screen in detached mode, using a configuration file that allows tool maintainers to attach using screen's multi-user support. This hasn't been tested; if you successfully use this method, please update this page.
Do not try to fix this problem by making your terminal device world-accessible. This opens your account to compromise and users who do so are breaking the rules.
- Category:MMT-Tool – Category of Multi-Maintainer-Projects