|This page contains historical information. It is probably no longer true.|
Do I explicitly have to specify the license of my tools?
Yes. If you think "this is just a draft, nothing ready" and you do not put a license into your code it's non-free software contradicting the idea of Toolforge. So please add a license in the beginning! You can use any OSI-approved license. Read more on the licenses on the Open Source Initiative's website: http://opensource.org/licenses
What about file permissions? Who can see my code?
You have full control over access permissions of your code and data. By default, permissions are 0644, meaning everyone can read files, but only the creator of the file can edit them.
WMCS administrators and volunteer administrators can access software installed in the Tools environment.
Do stewards have a specific project on Tools?
There is no plan to have distinct projects for different Tool makers; but the Tools are separated from each other. There is nothing that prevents you from sharing the maintenance of some Tool between different stewards
It is recommended that you ensure there is always more than a single maintainer.
Can I delete a Tool?
Tools cannot currently be deleted. However, you can make an existing web tool inaccessible by shutting down the web service (`webservice stop`), removing all files from the project directory, and filing a task in Phabricator requesting that the tool be deleted eventually.
Can I rename a Tool?
No, sorry, this is not possible. You'd have to create a new one and put your code in there.
Can I have a subdomain for my web service?
Sorry, not yet. This is still in discussion at phab:T125589. Currently, your web services are available under tools.wmflabs.org/<YOURTOOL>.
How do I access the database replicas?
- You will find a tool accounts credentials for mariadb in the file
$HOME/replica.my.cnf. You need to specify this file and the server you want to connect to. Some examples:
mysql --defaults-file=~/replica.my.cnf -h enwiki.labsdb enwiki_p # <- for English Wikipedia mysql --defaults-file=~/replica.my.cnf -h dewiki.labsdb dewiki_p # <- for German Wikipedia mysql --defaults-file=~/replica.my.cnf -h wikidatawiki.labsdb wikidatawiki_p # <- for Wikidata mysql --defaults-file=~/replica.my.cnf -h commonswiki.labsdb commonswiki_p # <- for Commons
- You can create a symlink from replica.my.cnf to .my.cnf by running
ln -s replica.my.cnf .my.cnfand leave off the
mysql -h commonswiki.labsdb commonswiki_p # <- for Commons
- Alternatively, use the
sqlutility that provides convenient shortcuts:
sql enwiki # <- for English Wikipedia sql commonswiki # <- for Commons sql commons # <- for Commons (shortcut) sql wikidata # <- for Wikidata (shortcut)
Why can't I access user preferences in the replicas?
The db replication gives access to everything that is visible for logged-in users without special privileges. Others user preferences are considered private information and are thus redacted from the replicas.
Why am I getting errors about
libgcc_s.so.1 must be installed for pthread_cancel to work?
Encountering this while trying to run jobs on the grid engine means you need to give your job more memory; the (obscure) error message is caused by the system being unable to load your executable and all its shared libraries. As a rule, most scripting language require around 300-350M of virtual memory to load completely. See Allocating additional memory for more information.
Is there a GUI tool for database work?
Not in Toolforge, but you can run one locally on your computer (for example the MySQL Workbench http://dev.mysql.com/downloads/tools/workbench/). Here is how you connect to the database:
- >For the login: firstname.lastname@example.org
- >For the database, it depends on the exact one you want to use, of course - for example: enwiki.labs
Why does public_html not work in my home directory?
Users do not and cannot have a public_html folder to themselves. The only web-accessible directories are under
To have a URL such as
http://tools.wmflabs.org/<username>/, you must create a tool called
<username>, which will create a folder called /data/project/<username>/public_html/. Nobody--except you, the user--will *ever* be given access to your home or its files. Allowing public services to run from a home directory means that their management could not be shared or taken over if they end up abandoned, defeating the purpose.
I get a Permission denied error when running my script. Why's that?
Make sure that you are running your script from your tool account rather than your user account.
How can I detect if I'm running in Cloud VPS? And which project (tools or toolsbeta)?
There is a file that contains the project name on every Cloud VPS instance:
If this file is present, the host is hosted in Cloud VPS. The contents of the file will tell you which project; that would be "tools" for the Toolforge, or "toolsbeta" for the experimental toolforge.
My connection seems slow. Any advice?
When connecting to Toolforge from Europe you might have higher ping times. Try using Mosh. To connect, use
mosh -a login.tools.wmflabs.org (-a to force predictive echo)
My Tool requires a package that is not currently installed in Toolforge. How can I add it?
You might not be the only one missing that package. Please submit a ticket in Phabricator and ask the admins to install it project-wide. If they have reasons not to do so you can always install software locally / just for yourself.
Note that for python packages, we highly recommend that you use a virtualenv local to your tool - and only request a global package if it is painful to install via pip (numpy, scipy, etc). For example to install the python package internetarchive run
virtualenv ~/env source $HOME/env/bin/activate echo "source $HOME/env/bin/activate" >> .bashrc pip install internetarchive
See also Help:Toolforge/Python application stub on how to get a sample flask python application installed onto the tools-project as quickly as possible.
My Tool needs a more specialized infrastructure than Toolforge provides. What should I do?
Toolforge is a simplified environment intended to be a direct toolserver replacement for most small tools. When you need something more complicated or when you need to manage specialized infrastructure, what Toolforge can't do you can probably do with your own Cloud VPS project! (Instead of inside one of the projects "tools" or "toolsbeta".)
I keep reading about Puppet. What is it?
As a tool maintainer you don't have to worry about puppet: if you're missing some dependency for your Tool, see § My Tool requires a package that is not currently installed in Toolforge. How can I add it?.
The nutshell: Puppet is a system by which you describe the configuration of a machine. When used, it will apply the necessary changes to make the machine you apply it to match that configuration.
In practice, the sysadmin would make any change of configuration intended for the machine in Puppet (including what to install, files to edit, etc) so that it can be reapplied to a blank machine to configure it "just like it was", or to make a clone, and so on. Puppet is used by the Toolforge sysadmins so that every server (current and future) is configured without manual intervention.
On Toolforge the code you write for your Tool lives on a shared filesystem rather than on the individual machines, so it has nothing to do with Puppet.
What is the labsconsole?
It's the old name of what is now Wikitech. (wikitech.wikimedia.org)
Are there any plans for adding monitoring or profiling tools?
Yes, in the very long term and not guaranteed. Want to help? Find out more here: User:Yuvipanda/Icinga for tools
SSH warns me about differing keys, are the servers compromised?
If you get an error such as
Warning: the ECDSA host key for 'tools-login.wmflabs.org' differs from the key for the IP address '184.108.40.206'
it most likely just means that the key has been updated (which should normally have been announced on the cloud mailing list). Try refreshing it with
ssh-keygen -R <ip>