Multi-maintainer projects

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

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.
 * Taking over

For roots
willow# add-mmt willow# add-mmt-maintainer

Becoming the project user
To access the project, run become  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   group; making all files and directories group-read/writeable allows you to log in and edit normally. You can also use sudo -u  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 p_projectname</tt>.
 * Similarly, multi-maintainer projects will have their svn repository names prefixed with p_</tt>, so the URL will be  https://svn.toolserver.org/svnroot/p_ . </tt>
 * 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)

Database access
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</tt> 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</tt> to connect to the server and then use the SQL command CREATE DATABASE</tt> as usual. Your database should be named p_ </tt>.

Transferring files
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  (or  ) to transfer. This will preserve the file's permissions, so it will remain group readable in the multi-maintainer account's home dir.

Paths
For project  </tt>,
 * The home directory will be /home/project/t/h/e/theproject</tt>, containing a subdirectory public_html</tt>. When possible, do not hard-code this path in your scripts; use the $HOME</tt> environment variable instead. The webserver does not set $HOME</tt> in the environment of cgi scripts, but the information returned by getpwnam</tt> is correct and can be used to get the home directory.
 * The URL to the public_html</tt> directory will be http://toolserver.org/~theproject</tt>

Using screen
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</tt> script; run it before switching to the tool account, and you will be able to run screen: % ttyallow

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.

Misc

 * Category:MMT-Tool – Category of Multi-Maintainer-Projects