Toolserver:Using the stable server

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.

The stable server provides a stable environment to run tested, mature tools. This page explains how to set up and maintain your tools on the stable server.

What is "stable"?

As the same suggests, the stable server is intended to be "stable". While the server itself is not inherently more stable, by applying stricter rules and policies, a more stable environment is provided to users:

Projects are added to stable by admin approval only. This means only well-tested projects will be added, and it prevents the server from becoming overloaded (as has happened with the normal toolserver in the past); new projects will only be added when there are sufficient resources to support them.
The stable server has a different maintenance schedule, which reduces downtime, and means users know when to expect downtime.

However, there are some things which might still cause unexpected downtime:

There is only one stable server. In case of hardware failure, it will be offline until the faulty hardware is replaced. We have a next-business-day hardware replacement warranty. (In the future, we would like to provide redundant hosting for stable projects.)
The stable server does not have dedicated database replicas. This means that problems with the normal database replicas will also affect stable tools that use them.
The stable server is hosted at the Wikimedia facility in Amsterdam (knams); any network issues here will affect the stable server. (Generally, issues with this are quite rare.)

The stable server maintenance schedule is as follows:

Quarterly scheduled maintenance: The first Monday in each quarter, between 5AM - 7AM UTC. During this window, we will apply current OS patches and do any non-urgent pending maintenance. This will always involve a reboot (around 15 minutes downtime).
Weekly maintenance: Every Monday between 5AM - 7AM UTC. This window will be used for applying pending configuration changes, and installing important OS patches (e.g. to fix bugs which are known to be affecting a stable project). This will usually not involve a reboot, but might involve restarting services such as the web server.
Daily maintenance: Every day between 5AM - 7AM UTC. This window will be used to install critical OS patches (e.g. security updates), and make configuration changes which are unlikely to cause any downtime.

During each quarterly maintenance, the server will usually be rebooted, which will cause around 10 minutes downtime. We will try to avoid reboots during weekly and daily maintenance, unless the maintenance requires a reboot (for example, an OS kernel update).

Quarterly and weekly maintenance will be announced one week in advance (if possible). Daily maintenance will usually be announced at least 12 hours before it starts, but this might not always be possible. All maintenance will be announced on IRC when it starts, and noted in the status page.

Logging in

When you are given access to the stable server, you will be given an account with your SSH keys from the normal Toolserver added. Usernames are limited to 8 characters. You can log into this account as normal; the server name is willow.toolserver.org.

Accessing your project

Each tool on the stable server runs under a role account, a special kind of user account. To see which tools you have access to, run roles. To become the role account, use become:

user$ become mytool
mytool$

No password is required to do this.

Your account, and your tool's role account, each share a group. You can use this to restrict access to the tool to authorised users.

While you can use your normal user account for maintenance and development, all tools must run under the role account.

screen

By default, screen doesn't work after you su to a different user. If you want to use screen, run ttyallow roleuser before you su.

Resource limits

Each tool has its own project, a Solaris concept used for resource management. The project has the same name as the tool's role account. Each project has resource limits; currently, the default limits are:

Maximum threads in the entire project: 100
Maximum physical memory use (RSS) for the entire project: 256MB
Maximum heap size for each process in the project: 1GB

If you need more resources, send mail to ts-admins.

Web hosting

URLs for stable tools are of the form http://stable.toolserver.org/toolname/. Before you can use web hosting, you must ask an admin to enable web hosting for your account.

The document root for static files is ~toolname/www.

PHP: Ask a root to enable PHP for your tool. You must specify which directories PHP will be enabled for.
CGI: CGI cannot be used; CGI applications must be turned into FastCGI applications. For most languages, this is fairly trivial.
FastCGI: Ask an admin to enable a FastCGI responder for the appropriate path. (TODO: add docs on how to start FastCGI listeners.)

All PHP/FastCGI scripts run as your tool's uid.

Web statistics are available at http://stable.toolserver.org/webstats/webserver/.

Subversion

Each tool is provided with a subversion repository (you need to ask an administrator to create it). For development, access it as file:///svnroot/tool/ or svn+ssh://stable.toolserver.org/svnroot/tool/. All developers for your tool have commit access. For anonymous access, use svn://stable.toolserver.org/tool/.

Your repository will be added to FishEye at http://fisheye.toolserver.org/browse/toolname/.

Bug tracking

Each project on the stable server can have its own JIRA project. Ask an admin to create this for you.

WinSCP

Some people wish to use graphical scp/sftp clients (such as WinSCP) to transfer files to the stable server. Because the tool account is a role, you cannot log into it directly. However, all developers of a tool share a group with the tool account, so you can set group write permissions on the directories you want to copy files to, log in as your normal user account, and copy the files directly.

Category:Documentation Category:Stable server