Toolserver-l

toolserver-l@lists.wikimedia.org

1612 discussions

Next level of stabilization
by Lars Aronsson 03 Mar '09

03 Mar '09

Lately, I've tried to make some large improvements, primarily in the Swedish language Wikipedia. Sometimes this has succeeded, sometimes it has failed or been delayed. Some of the delays have been due to failing server functionality, either at WMF or on the toolserver. We're victims to our own success. Provisional hacks tend to get so successful, that people start to rely on them. I really want to get better geo tagging going in the Swedish Wikipedia. To this end, WikiMiniAtlas was activated some weeks ago. The activation went just fine. But the underlying database is not up to date. This is because Stefan Kühn is rewriting the script that extracts geo coordinates from the database dumps, and he has many other things to do. I don't blame him. He's doing a very good work, when he finds some time for it. But even if he had a solution ready, current database dumps might not be available. Suppose database dumps were ready and WikiMiniAtlas was up to date, and I would have some idea for a contest among Swedish wikipedians to add more coordinates to articles with prizes being awarded to the top ten contributors. That's the kind of project for which I could apply for money. That money could cover some costs for the toolserver or for the ticket for somebody to go to the developer meeting. It would have many good side effects. Of course, the WikiMiniAtlas is just one example of a very successful toolserver project that could generate such benefits. Another example: Apparently the Dutch Wikipedia community has some tool (?) to facilitate image uploading, that we might want to adapt to Swedish. But that's not running on the toolserver today, so we would also have to find somewhere to host it. This can of course be solved, but what would the best solution be? My question: when we see such opportunities, how can we make better use of them? The toolserver team has a list of "stable" services which are (at least) more stable than the rest. But how can we invest in making them even better and more stable, so other projects can build upon them? One idea that I had was to transfer such projects to the central Wikimedia servers, and make them a part of the WMF infrastructure. This would hopefully make the services more stable, and free up resources for more experimentation on the toolserver. Lately, I've become more skeptic about that plan, since they seem to have more work than they can really handle. Another idea is to set up a separate toolserver for Scandinavia. I heard some rumours that Wikimedia Norge (Norway) has resources to do this. But perhaps it is wiser to invest in the existing one? I'm very happy that the new hardware has arrived and is being installed. It's unfortunate that it took so long for this to happen. How can we make resource planning work smoother in the future? There are millions of users who expect us to perform better, and I think they will send money if we ask them. What are we short of? Money? Then say so. People? What kind? So, who is the idiot that writes this message? I'm user:LA2 and my full name is Lars Aronsson. I'm a C/UNIX programmer from Sweden. Back in 1992 I started to scan old Scandinavian books under the name Project Runeberg, http://runeberg.org/ and after having started to scan encyclopedias (not just poetry and novels), finding Wikipedia was a perfect match. I've scanned two minor encyclopedias for the German and English Wikisource. I've also been an active contributor to OpenStreetMap since 2005. I happened to visit Berlin in 2004 when Wikimedia Deutschland was formed. In October 2007 I helped to create Wikimedia Sverige (Sweden) and has been a board member since. In 2008 we organized Wikipedia Academy in Sweden. That's not the only idea we have copied from the German chapter. We're now in talks with libraries and archives to see if we can have some major content exchanges. I've been to Wikimania in Frankfurt (2005) and Alexandria (2008). -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se Wikimedia Sverige - stöd fri kunskap - http://wikimedia.se/

6 14

servers changed: www, sql-s1
by River Tarnell 03 Mar '09

03 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, sql-s1 is now pointing at rosemary, and the web server has been moved to wolfsbane. please report problems with either server by opening a request in the TS project in JIRA. - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmr9vQACgkQIXd7fCuc5vLhNgCfVFUysPjaRgNAKbKvdm75bzFJ 73QAn3W0qA6iDoz650XtVYsgRUpF3Q7K =p5fZ -----END PGP SIGNATURE-----

1 0

[IMPORTANT] home directory cleanup; sql-s1 server change
by River Tarnell 01 Mar '09

01 Mar '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 first issue: sql-s1 change. we will shortly be changing s1 from yarrow to rosemary. if you have user databases on yarrow, these will *not* be copied over, and furthermore will be deleted when s3 is re-imported to yarrow. if you need to keep these databases, you need to dump them *now* using mysqldump, and either import them into the new s1 server after the change, or import them back into yarrow when s3 is reimported. second issue: large home directories. the following users have home directories larger than 10GB: 12978772 drh08 15633252 sk 15753754 voj 18902342 bryan 20391211 kolossos 34753424 cbm 41874315 dschwen 55842970 daniel the following users have home directories larger than 1GB: 1206570 emijrp 1231049 tawker 1417818 dab 1437121 flacus 1461143 erenrich 1568766 purodha 1712819 simetrical 1834572 leon 1898741 fmaunier 2026644 kalan 2049700 chabacano 2170154 misza13 2447405 danny_b 2564363 tangotango 2890444 osamak 3260012 river 3860768 vvv 5070464 tparscal 5636581 gmaxwell 7112804 werdna a full list of home sizes is here: <http://toolserver.org/~river/bighomes.txt> whether or not your name is on either of the above lists, but especially if it is, please look at what's using disk space in your home directory and clean out any old files you no longer need (for example, log files, old dumps, etc). don't delete anything you actually need, though. if you need to store dumps or other large files, you can put them in the shared user store at /mnt/user-store instead of your home directory. - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmpdO8ACgkQIXd7fCuc5vIBkQCgqHSWO96VwlrBemGIVsAJ4Jar 3WoAmwWaPrXjE7ozsAiIuawdYftzH+Th =Nylc -----END PGP SIGNATURE-----

4 4

new server status
by River Tarnell 28 Feb '09

28 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, the new servers arrived today and were racked and installed. i am currently setting up the new s1 database and should have the database imported by the end of this week, assuming nothing goes wrong. we won't be able to move /home to hemlock right now as planned, but we might have an interim solution that improves the slow /home performance. - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmoMgcACgkQIXd7fCuc5vLdagCeNiY4g9YcyUhcZZkAcv9lUkmh s8kAnA5U2zB+ECNxfxXLC2AnwYdZhyqW =ZZFy -----END PGP SIGNATURE-----

1 1

svn:// URLs no longer supported
by River Tarnell 24 Feb '09

24 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, with the change to the SVN server, svn:// URLs are no longer supported, meaning legacy repositories ($HOME/subversion/) are not remotely accessible except via svn+ssh:// (which requires authentication). these repositories have been removed from FishEye. if you are still using a legacy repository, and want it to be remotely accessible, you must convert it to a new-style repository. new-style repositories are explained here: https://wiki.toolserver.org/view/SVN and the conversion process is explained here: https://wiki.toolserver.org/view/New-style_Subversion_repositories - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmj6zEACgkQIXd7fCuc5vKxpwCgq1i007vDvRgMIPVT4bpVB7mc gzwAn1ltHGL261H3cBBMRcqxdgWwO+9L =olN9 -----END PGP SIGNATURE-----

1 0

[stable] svn repositories
by River Tarnell 24 Feb '09

24 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, currently there are some "missing" repositories on stable. we will not be restoring these to the previous location (/svnroot), but instead integrating them into the SVN repositories on amaranth. therefore, if you/your project has an SVN repository on stable, you should mail ts-admins(a)toolserver.org with this information: * the repository name * the users who should have commit access (normal toolserver usernames, not stable usernames) additionally, you (and anyone else with commit access) will need to run 'setpass' on nightshade to set your LDAP password before you can commit. - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmjeCYACgkQIXd7fCuc5vKLPgCgkzNJE4o31CMQcz+qhsy6TaIt SM0AoLYjg/Siiy2e1A6324n21KPgEfXN =TEBP -----END PGP SIGNATURE-----

1 0

SVN maintenance
by River Tarnell 24 Feb '09

24 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, today/tomorrow, svn repositories will be moved from nightshade to amaranth. URLs will remain the same, but you might find that you can't access SVN for up to an hour after the move, while the DNS change propagates. - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmjEjYACgkQIXd7fCuc5vIbXACfXbUjOJJO0GLm+PzFIOhLlhJE HgEAn28evcZYtIA/lzOuiNbwf3i0sWh3 =8CoQ -----END PGP SIGNATURE-----

1 1

New Servers Arrived
by Daniel Kinzler 24 Feb '09

24 Feb '09

Hi all I'm happy to tell you that the new servers have arrived. We hope to have them installed by next week. If all goes well, we should have an up to date copy of s3 again soon, and a faster web server. -- daniel

3 2

nightshade was rebooted
by River Tarnell 20 Feb '09

20 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, nightshade suffered a software error and was pre-emptively rebooted to prevent issues. at the same time the OS kernel was upgraded, which should prevent this issue from recurring. - river. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkmeBOkACgkQIXd7fCuc5vI41gCfZYH+JUXM9eAgZwIDQKEfqOmb VBkAn2xmfqZVSfb5pAlyoVDFJBxXLu86 =4PIh -----END PGP SIGNATURE-----

1 0

s3: when the hell?
by Kalan 19 Feb '09

19 Feb '09

Sorry for the tone of the subject, but it is annoying more and more for wikis there. The last information regarding it announced in the list was a month and a day ago saying that the new hardware should arrive two weeks after then, that is roughly at the beginning of February. However the message about halted replication is still hanging at status.wikimedia.org, and I don't know of any public announces explaining the delay. So, what is causing it and are any estimates of resolution time available? — Kalan

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Toolserver-l