Re: [Toolserver-l] [Labs-l] DEPRECATED: tools.wikimedia.de - Get rid of it!
Silke Meyer silke.me...@wikimedia.de wrote: [...] For me, it is important that I don't have to deal with that domain any longer. Simply keeping the CNAME causes on work at all. If you at WMF want to handle the certificate question in the future, you can go ahead. At the Hackathon, I understood that Coren is no fan of such a solution though. I think Merlijn and Platonides are just proposing to replace the CNAME with a virtual host tools.wikimedia.de on the web- server that currently handles wikimedia.de, blog.wikimedia.de, forum.wikimedia.de and www.wikimedia.de that just does a HTTP redirect to toolserver.org (which then gets handled by WMF), and that should be *very* close to no work at all :-). But there would only be a difference in HTTPS compared to the CNAME solution, and as Merlijn pointed out that tools.wikimedia.de predates HTTPS on Toolserver, I'm fine with keeping the CNAME (or pointing it to the new webserver) as well. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Can not login to nightshade and willow via ssh
I wrote: I can't login to willow and nighsthade via ssh. They both show some welcome text and nighshade ends up at showing the Last login: ..., willow at The following screen sessions are active Nothing happens then, neither it continues, nor the connection gets disconnected. Anybody has the same issues? ssh to nightshade works again (compared to last night), but apparently hangs in /etc/profile.d/quota.sh. Aborting that with ^C, I get a prompt. ls /mnt there shows user-store, ls -l /mnt hangs in status D. Accessing /mnt/user-store on yarrow shows no problems; /etc/fstab's entries are iden- tical on both hosts. So it looks to me as if there's a problem with the /mnt/user-store rosemary NFS mount on nightshade. Now yarrow has apparently the same problem. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Can not login to nightshade and willow via ssh
(anonymous) wrote: I can't login to willow and nighsthade via ssh. They both show some welcome text and nighshade ends up at showing the Last login: ..., willow at The following screen sessions are active Nothing happens then, neither it continues, nor the connection gets disconnected. Anybody has the same issues? ssh to nightshade works again (compared to last night), but apparently hangs in /etc/profile.d/quota.sh. Aborting that with ^C, I get a prompt. ls /mnt there shows user-store, ls -l /mnt hangs in status D. Accessing /mnt/user-store on yarrow shows no problems; /etc/fstab's entries are iden- tical on both hosts. So it looks to me as if there's a problem with the /mnt/user-store rosemary NFS mount on nightshade. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] What will happen with the Toolserver domain?
(anonymous) wrote: [...] JIRA however is much more complicated. You know from your own experience (https://jira.toolserver.org/browse/TS-748 has now been unresolved for over three years) that few of the Toolserver admins have time and knowledge with regard to JIRA, while in the WMF camp they have probably zero. So compared with MediaWiki where (security) updates will be regularly deployed with the rest of the cluster, someone would have to keep a dedicated eye on a totally foreign sys- tem. And we only have a free licence from Atlassian which could at some point be discontinued. On the other hand the benefits are very small as Merlijn wrote the fantastic JIRA/ Bugzilla importer which handles almost all cases. Yes I know those issues... ;) It is/was a pitty... As far as I know, the JIRA/Bugzilla importer has issues as well, please confer https://bugzilla.wikimedia.org/show_bug.cgi?id=55673. It does e.g. NOT preserve relations between tickets and thus drops a serious amount of the history too. As I understand from the buzilla ticket this will not be resolved. In my oppinion 1 of the 2 problems should be tackeled; * either keep a static copy of JIRA (may be just the DB along with a simple viewer written by us) * or improve JIRA/Bugzilla importer to a point where it can migrate relations between tickets and other stuff as well As I wrote last month in http://permalink.gmane.org/gmane.org.wikimedia.toolserver/6450, you can export an XML dump of your project's issues (you'll have to download attachments manually (or write a script for that)). This contains the links between issues. You can then store it in your software's repository or any other place and convert it to HTML, wiki pages, a book or one of those bubble movies - the world is your oyster. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] What will happen with the Toolserver domain?
(anonymous) wrote: I would vote strongly to keep the wiki and also JIRA somewhere accessible. Both contain a serious amount of history and documentation. Can that be done? [...] These are two very different problems. AFAICS the wiki can be moved rather easily; your mail trig- gered me to finally create the bug from my notes written long ago :-) (cf. https://bugzilla.wikimedia.org/60220). The Toolserver admins need to decouple the wiki from the Toolserver SSO and dump users and data, the WMF admins need to set up a (= just another) wiki without CentralAuth (wmgUseCentralAuth = false IIRC), load users and data, reset the/mail out new users' passwords and then wiki.toolserver.org needs to be set as a CNAME for text-lb. JIRA however is much more complicated. You know from your own experience (https://jira.toolserver.org/browse/TS-748 has now been unresolved for over three years) that few of the Toolserver admins have time and knowledge with regard to JIRA, while in the WMF camp they have probably zero. So compared with MediaWiki where (security) updates will be regularly deployed with the rest of the cluster, someone would have to keep a dedicated eye on a totally foreign sys- tem. And we only have a free licence from Atlassian which could at some point be discontinued. On the other hand the benefits are very small as Merlijn wrote the fantastic JIRA/ Bugzilla importer which handles almost all cases. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] List of expired accounts
Federico Leva (Nemo) nemow...@gmail.com wrote: Hi, can we have a list of all the accounts that expired in the Big Catastrophic Deadline of the 6th (and have no redirects to other places, maybe)? We're bound to have hundreds of dead tools in this moment and I'd like to avoid chasing them individually. [...] You can do so yourself: | timl@willow:~$ date2days $(date +%Y-%m-%d) | 16083 | timl@willow:~$ ldapsearch -h ldap -b o=unix,o=toolserver '((objectclass=posixaccount)(shadowexpire=16083)(!(shadowexpire=16083)))' uid | | sed -ne 's/^uid: //p;' | [...] However, I don't think that's a useful approach. If there are tools in use, and someone complains about them no longer working or their URLs get hammered in the httpd logs, resur- rect them for sure; if not, let them rest in peace. There's a lot to be done for tools that are /actually/ in demand; no need to spend time on ones that clearly aren't. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] What will happen with the Toolserver domain?
Manuel Schneider manuel.schnei...@wikimedia.ch wrote: [...] This is what we planned and why amette implemented the htaccess variant. You can put it into your home and even if you remove all your stuff with burnbridges the htaccess file will stay there if it has a labs url in it. WMF can get the files and the domain and host the redirects. We may either keep one simple webserver running and point the old domain there in order to maintain redirects of the old URLs to the new scripts. We could also move this late to another server, eg. of Wikimedia CH which I could provide, so we can decomission the toolserver completely and save costs and management time while still maintain the redirects. I'm currently working on puppetizing tools-webproxy and the redirect server is just a few extra lines of configuration. So no servers outside of Labs are needed. What would be interesting is a mail forwarder for the exist- ing toolserver.org addresses as a) WMF may be hesitant to provide this and b) mails with the senders' assumption on them being forwarded in Amsterdam instead being relayed in the US could be the source for endless drama. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reminder: Account expiry and migration
Marlen Caemmerer marlen.caemme...@wikimedia.de wrote: It would be very nice in this festive season if someone could resolve the pending JIRA requests for lost and changed SSH keys first (cf. https://jira.toolserver.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+TS+AND+resolution+%3D+Unresolved+AND+component+%3D+Accounts+ORDER+BY+created+DESC). I am working on it. Thanks! Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reminder: Account expiry and migration
Silke Meyer silke.me...@wikimedia.de wrote: Just a little reminder: Your toolserver accounts will expire on January 6th, 2014. You can renew it with acctrenew as usual. If you had an expired account and you want to come back and collect your data: Your account has been reactivated until that date. You can login to nightshade and use the script byebye to collect your stuff. It will create a new directory inside your home directory called FarewellBundle. This directory contains tarballs of almost everything you had on the toolserver. The only thing you have to take care of separately is your stuff in /mnt/user-store. Please download the data you don't need on the toolserver any longer! [...] It would be very nice in this festive season if someone could resolve the pending JIRA requests for lost and changed SSH keys first (cf. https://jira.toolserver.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+TS+AND+resolution+%3D+Unresolved+AND+component+%3D+Accounts+ORDER+BY+created+DESC). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] JIRA migration to bugzilla
Merlijn van Deen valhall...@arctus.nl wrote: Today, I hacked together a JIRA migration tool. [...] As I said on Bugzilla: Pretty cool! :-) If someone is just interested in a backup of their project, but doesn't necessarily want to migrate it to another bug- tracker (yet), JIRA provides XML dumps that look fairly com- plete. To download one, go to https://jira.toolserver.org/secure/QuickSearch.jspa and type in for example project = . An autocompleted list should show up. Choose your project and click Search. At the top right you should see a drop-down menu Views. Choose XML, save the file and look if it contains everything you expected. There seems to be a export limit of 1000 issues, so for projects with more issues you need to be creative :-) (left as an exercise to the reader). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] SGE and sql-s1-rr
Hi, most of dbreps's jobs have been waiting for more than a month with: | scheduling info:queue instance medium...@mayapple.toolserver.org dropped because it is temporarily not available | queue instance longrun2-...@hawthorn.toolserver.org dropped because it is disabled | queue instance longrun2-...@clematis.toolserver.org dropped because it is disabled | queue instance longrun3-...@willow.toolserver.org dropped because it is disabled | queue instance short-...@willow.toolserver.org dropped because it is full | (-l arch=linux-x64,h_rt=12300,mem_free=2070M,sql-s1-rr=1,sqlprocs-s1=1,virtual_free=2070M) cannot run globally because it offers only gc:sql-s1-rr=0.00 Does that mean that the resource sql-s1-rr is depleted? Are the database servers really that congested? I see that /sge/scripts/sensor/sqlslots2.pl was changed on October 17th. Could the calculation of the DB slots be wrong, or would changes in that file not affect the resource sql-s1-rr? Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Pywikibot, GIT and TS
(anonymous) wrote: [...] It's all about work-load; all the migrations, changes and stuff taking place at the moment just stops me of doing my work. I should bug fix and develop bots for wikidata and commons, instead I have to migrate to Labs and GIT. And as it looks like git will - even if it works perfectly - just increase workload compared to svn. You could try not to cause unnecessary workload for others by confining Pywikipediabot questions to its dedicated mail- ing list. If you need additional storage on the Toolserver (for what- ever reason), please file an issue in JIRA. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Status update on Tool Labs
Maciej Jaros e...@wp.pl wrote: Is there any how-to on moving SVN repo. along with it's history to TL? Is it possible/planned at all? Also could you clarify on ...WMF doesn’t provide SVN hosting, but volunteers can create an SVN project in Labs.. I can create a repo in my home dir or what? How would I access it from my machine then? Can I just enable and configure WEBDAV on some public_html dir? As DaB. explained, the roots can provide you with a dump of your SVN repository. You can then import (load) this into a repository in your home directory and access it via ssh (this seems to be possible from Windows as well, cf. http://sebastian.thiele.me/blog/tortoise-svn-putty-ssh-windows/2438 (German)). If you create a dummy tool and put the reposi- tory in the tool directory, all users in the tool group should be able to write to it as well. You could also import the dump for example to SourceForge (cf. http://sourceforge.net/apps/trac/sourceforge/wiki/Subversion%20import%20instructions) and probably other hosters. I don't know of any plans regarding WebDAV. Yes I know Git is superior and all that, but I don't want to get into the discussion of history on a full tree versus history on a file. I just want to know if I will be able to use SVN on your servers and just switch my local directory without any needless conversions. You can get the history of a file with git log FILENAME; if you want to follow the history through renames, use git log --follow FILENAME. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Status update on Tool Labs
Federico Leva (Nemo) nemow...@gmail.com wrote: Would .htaccess work also for expired accounts then, and could operators/roots do something about them? We still have tons of users entering, say, interiot and soxred's tools and getting slightly unhelpful results. The User account expired messages are generated by https://svn.toolserver.org/svnroot/puppet/trunk/puppet/modules/webserver/files/do_expired.sh which replaces the bottom of /etc/htaccess. It's certainly possible to exempt some user accounts and add special redi- rects for them. The bigger problem for a move of abandoned tools to /anywhere/ is however, as Magnus said, if the source code is properly licensed. soxred93 for example has set a default license of MIT (but http://toolserver.org/~soxred93/ looks pretty empty), while interiot has no default license, but /home/interiot/public_html/cgi-bin/Tool1/wannabe_kate de- clares itself as [[Public domain]]. Just redirecting to a working tool should pose no problems, though. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Status update on Tool Labs
Magnus Manske magnusman...@googlemail.com wrote: .htaccess is your friend :-) [...] To be a bit more explicit :-): | Redirect /~$USERONTOOLSERVER/ http://tools.wmflabs.org/$TOOLONTOOLS/ in ~/public_html/.htaccess should redirect all requests from the former to the latter while preserving the rest of the URL, i. e. http://toolserver.org/~$USERONTOOLSERVER/abc.php?def=ghi gets redirected to http://tools.wmflabs.org/$TOOLONTOOLS/abc.php?def=ghi. You can limit this to subdirectories or single files as well. Every few days, you can then log into ortelius and wolfsbane and grep /var/log/http/access for $USERONTOOLSERVER. You should see requests with status (sixth field) 302, and the eighth field is the referring page. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Status update on Tool Labs
Jeremy Baron jer...@tuxmachine.com wrote: .htaccess is your friend :-) [...] To be a bit more explicit :-): | Redirect /~$USERONTOOLSERVER/ http://tools.wmflabs.org/$TOOLONTOOLS/ probably better to use Alias. (at least for most people) Eh, how? The Alias directive seems to allow only mapping to the local filesystem (http://support.zeus.com/zws/media/docs/ZWSUserGuide.pdf, page 361; http://httpd.apache.org/docs/current/mod/mod_alias.html#alias as well). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] ssl certificate
Marlen Caemmerer marlen.caemme...@wikimedia.de wrote: installed SSL cert. Doesn't work at least on FishEye and JIRA. Damn...forgot this installation...fixed. And works -- thanks! I closed https://jira.toolserver.org/browse/TS-1657. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] ssl certificate
I wrote: installed SSL cert. Doesn't work at least on FishEye and JIRA. Damn...forgot this installation...fixed. And works -- thanks! I closed https://jira.toolserver.org/browse/TS-1657. Matthew found an issue with the certificate that prevents using for example curl with the toolserver: | scfc@tools-login:~$ curl https://toolserver.org/ | curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: | error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed | More details here: http://curl.haxx.se/docs/sslcerts.html | | curl performs SSL certificate verification by default, using a bundle | of Certificate Authority (CA) public keys (CA certs). If the default | bundle file isn't adequate, you can specify an alternate file | using the --cacert option. | If this HTTPS server uses a certificate signed by a CA represented in | the bundle, the certificate verification probably failed due to a | problem with the certificate (it might be expired, or the name might | not match the domain name in the URL). | If you'd like to turn off curl's verification of the certificate, use | the -k (or --insecure) option. | scfc@tools-login:~$ curl on yarrow gives the same result. Matthew added the link https://www.digicert.com/help/index.htm?host=https://toolserver.org/ to the JIRA issue that gives as error: | SSL Certificate is not trusted | The certificate is not signed by a trusted authority (check- | ing against Mozilla's root store). If you bought the cer- | tificate from a trusted authority, you probably just need to | install one or more Intermediate certificates. Contact your | certificate provider for assistance doing this for your | server platform. The curl problem occurs with fisheye, jira, svn and wiki as well. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Status of the toolserver
(anonymous) wrote: yes, there is a minor problem with ngnix I haven?t time to fix yet. Also there is a harmless error-message about quota at login. The funny thing with the quota error-message is, it works correct if I do have over-quota when loggin-in. Not so if the quota is not exceeded... ;)) The more irritating thing is that it works on willow, yet the mounts look identical: | [tim@passepartout ~]$ for HOST in willow yarrow; do ssh $HOST.toolserver.org mount | grep -w /sge; done | /sge on ha-sge.esi:/global/misc/sge remote/read/write/setuid/devices/rstchown/vers=3/proto=udp/xattr/dev=4b6 on Sun May 19 20:45:25 2013 | ha-sge.esi:/global/misc/sge on /sge type nfs (rw,proto=udp,vers=3,addr=10.24.1.16) | [tim@passepartout ~]$ Either Solaris's quota is silent about not being able to ac- cess some file systems, or ha-sge.esi seems to be blocked from yarrow, but not from willow (host ha-nfs.esi yields the same on both). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Toolserver db outperformed by labs
(anonymous) wrote: Today^W Yesterday, I was asked about some file numbers, which involved subcategory traversing, which is an inefficient problem. It seemed a good problem for comparing toolserver and labs. And toolserver db sucks: willow: 31m5.157s (user 0m4.038s) labs: 0m4.271s (user 2.488) Toolserver was *436 times slower*. Surely, the labs server is better (in hardware) than the one in TS. I don't know how many scripts were hitting the TS db, while the labs one would be almost-idle. Still, it seems a really big gap. Do we have something wrongly configured? Did mariadb somehow massively improve vs mysql? Are some parameters too small? Is it just a problem that the mysql servers are underprovisioned of ram? IIRC, the replicated databases on Labs are hosted on SSDs so it's not really fair to compare them :-). What would proba- bly be a better benchmark are user databases on Toolserver and tools-db on Labs; the latter (different credentials than replicated databases) is on a VM with storage on a (IIRC spinning) NFS server, but that would of course neglect that the Toolserver databases have to cope with replication as well, while tools-db only holds the user databases. So I don't think an adequate comparison can be made. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] sge scheduler problem
(anonymous) wrote: That is a sge scheduler problem. I could not commend your sge ticket because jira does not accept my jira token. The load limit is set ok because we use np_load_* values which is the load divided by the number of cores on this host. So e.g. sge stop scheduling jobs on nightshade if host load is more than 20. So i think increasing this value does not make sense. You're probably right about this. I was assuming the load goal of 2 just from the symptoms displayed. You output below contains load adjustments: queue instance longrun...@yarrow.toolserver.org dropped because it is overloaded: np_load_short=3.215000 (= 0.015000 + 0.8 * 16.00 with nproc=4) = 3.1 means that there is a normalized host load of 0.015000 on yarrow and 16 jobs are started within the last 4,5 minutes (=load_adjustment_time). sge temporary (for the first 4,5 minutes of a job lifetime) adds some expected load for new jobs to be not overloaded in future. Most new jobs normally needs some starting until they really use all need resources. This prevents scheduling to much jobs at once to one execd client. But as you can also see in real there are no new jobs. This is problem the response from master: $qping -info damiana 536 qmaster 1 05/17/2013 07:03:14: SIRM version: 0.1 SIRM message id: 1 start time: 05/15/2013 23:47:49 (1368661669) run time [s]: 112525 messages in read buffer: 0 messages in write buffer: 0 nr. of connected clients: 8 status: 1 info: MAIN: E (112524.48) | signaler000: E (112523.98) | event_master000: E (0.27) | timer000: E (4.27) | worker000: E (7.05) | worker001: E (8.93) | listener000: E (1.03) | scheduler000: E (8.93) | listener001: E (5.03) | WARNING All theads are in error state including the scheduler thread. So the schedular does not accept status updates send by all execd and so it does not know about finished jobs and load updates. Thats why you see on qstat output an (not existing) overload problem and no running jobs (although some old long running jobs are still running). I think this could be solved by restarting the master scheduler process. That is why i (as sge operator) send a kill command to the scheduler on damiana and hoped that the ha_cluster automatically restarts this process/service. But this is sadly not the case. So we have to wait until a ts admin can restart this service manually. In between submitting new jobs will return an error, sorry for that. All running or queued jobs are not affected and will keep running or queued. [...] Thanks for tracking this down! Looking at qstat -u *, it seems to have recovered now. Tim P. S.: Regarding JIRA, did I miss any followup to http://permalink.gmane.org/gmane.org.wikimedia.toolserver/5241? ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Two questions about pywikipedia
Alex Brollo alex.bro...@gmail.com wrote: As I told, I'm driving a pywikipedia bot (Alebot) into willow; I installed pywikipedia at $HOME, I set PYTHONPATH=/home/alebot/pywikipedia [,.] into .environment file, and I am reviewing at my best python scripts to run them by qsub/qcronsub. Most of my scripts obviously need a statement: import wikipedia [,.] My questions: 1. Do I really need to install pywikipedia into $HOME? 2. My scripts run happily outside SGE, but when I try to run them under SGE I get an error: ImportError: No module named wikipedia I didn't find doc for this ImportError (I suppose, PYTHONPATH is wrong). Where am I going wrong? If your job is executed on Linux hosts, ~/.environment isn't honoured (cf. https://jira.toolserver.org/browse/TS-1472). So at the moment it's best to follow John's advice and set sys.path in Python (or use a wrapper shell script), or use -l arch=sol to require that your job is executed on a So- laris host. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] SGE thinks hosts are overloaded while the latter are idling
Hi, a qstat -j of a simple job yields inter alia: | scheduling info:queue instance longrun-...@willow.toolserver.org dropped because it is temporarily not available | queue instance short-...@willow.toolserver.org dropped because it is temporarily not available | queue instance medium...@mayapple.toolserver.org dropped because it is temporarily not available | queue instance longrun3-...@willow.toolserver.org dropped because it is temporarily not available | queue instance longrun2-...@clematis.toolserver.org dropped because it is disabled | queue instance longrun2-...@hawthorn.toolserver.org dropped because it is disabled | queue instance medium-...@ortelius.toolserver.org dropped because it is overloaded: np_load_short=0.791601 (= 0.391601 + 0.8 * 2.00 with nproc=4) = 0.75 | queue instance medium...@yarrow.toolserver.org dropped because it is overloaded: np_load_short=1.215000 (= 0.015000 + 0.8 * 6.00 with nproc=4) = 1.2 | queue instance medium...@nightshade.toolserver.org dropped because it is overloaded: np_load_short=1.227500 (= 0.127500 + 0.8 * 11.00 with nproc=8) = 1.2 | queue instance medium-...@wolfsbane.toolserver.org dropped because it is overloaded: np_load_short=0.778613 (= 0.078613 + 0.8 * 7.00 with nproc=8) = 0.75 | queue instance short-...@wolfsbane.toolserver.org dropped because it is overloaded: np_load_short=1.278613 (= 0.078613 + 0.8 * 12.00 with nproc=8) = 1.2 | queue instance short-...@ortelius.toolserver.org dropped because it is overloaded: np_load_short=1.391601 (= 0.391601 + 0.8 * 5.00 with nproc=4) = 1.2 | queue instance longrun...@yarrow.toolserver.org dropped because it is overloaded: np_load_short=3.215000 (= 0.015000 + 0.8 * 16.00 with nproc=4) = 3.1 | queue instance longrun...@nightshade.toolserver.org dropped because it is overloaded: mem_free=-420765696.524288 (= 14098.726562M - 500M * 29.00) = 500 At the moment, we have /no/ jobs scheduled by SGE running. Meanwhile, the hosts are idling: | queuename qtype resv/used/tot. load_avg arch states | - | short-sol@ortelius.toolserver. B 0/0/8 1.52 sol-amd64 | - | short-...@willow.toolserver.or B 0/0/8 -NA- sol-amd64 au | - | short-sol@wolfsbane.toolserver B 0/0/12 0.64 sol-amd64 | - | medium-lx@mayapple.toolserver. B 0/0/32 -NA- linux-x64 adu | - | medium-lx@nightshade.toolserve B 0/0/8 1.05 linux-x64 | - | medium...@yarrow.toolserver.or B 0/0/8 0.02 linux-x64 | - | longrun-lx@nightshade.toolserv BI0/0/64 1.05 linux-x64 | - | longrun-lx@yarrow.toolserver.o BI0/0/64 0.02 linux-x64 | - | longrun-sol@willow.toolserver. BI0/0/64 -NA- sol-amd64 au | - | medium-sol@ortelius.toolserver B 0/0/4 1.52 sol-amd64 | - | medium-sol@wolfsbane.toolserve B 0/0/4 0.64 sol-amd64 | - | longrun2-sol@clematis.toolserv B 0/0/8 0.03 sol-amd64 d | - | longrun2-sol@hawthorn.toolserv B 0/0/8 0.23 sol-amd64 d | - | longrun3-sol@willow.toolserver B 0/0/4 -NA- sol-amd64 aduE I filed https://jira.toolserver.org/browse/TS-1650 on Monday to no avail so far. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting
Re: [Toolserver-l] weird qcronsub errors
Peter Körner osm-li...@mazdermind.de wrote: Since a few days I'm getting weird errors when submitting tasks. My Cronjob calls /home/mazder/public_html/replicate-sequences/update-submit.sh which conains the following command: qcronsub -l h_rt=0:05:00 -l virtual_free=100M -l arch=* -l sql-user-m=1 -N mazder-replicate-sequences -m as -o '/home/mazder/public_html/replicate-sequences/sge' /home/mazder/public_html/replicate-sequences/update-run.sh' Most of these calls produce the error below, which seems not to be an error in my code as I neither use xml nor python. Do you have any Idea what's going wrong? [...] An educated guess: The Python errors come from the script /sge/GE/bin/sol-amd64/qjobtest that is called as part of qcronsub to test whether a job with that name is already running. qjobtest parses the output of qstat -xml ... which in normal operation returns a valid XML document. My assumption is that when SGE is down, qstat returns the error messages (error: commlib error: can't connect to service (Connection refused), etc.) as plain text which can't be parsed as XML which in return causes qjobtest to barf. In short: This is another artefact of SGE being down at that moment, you can't do anything about it, just ignore. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Cronie error
Lars Aronsson l...@aronsson.se wrote: I have a cronietab job that now gives this error message: error: commlib error: can't connect to service (Connection refused) Unable to run job: unable to send message to qmaster using port 444 on host damiana: got send error. Exiting. Now it has changed to: error: commlib error: can't connect to service (Connection refused) Unable to run job: unable to send message to qmaster using port 444 on host turnera-bge0: got send error. Exiting. Here is a third variant, that I got today: error: commlib error: can't connect to service (Connection refused) Unable to run job: unable to send message to qmaster using port 444 on host clematis.toolserver.org: got send error. Exiting. Can someone please explain how I should submit a cron/cronie job? You shouldn't change anything. There have been some tran- sient errors in connection with the outage (NFS/SGE/LDAP failure), and these are artifacts of those. At the moment, SGE is up and running. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Inodes have run out on yarrow's /var
I wrote: [...] Plus medium and longrun queues in yarrow are in error state. I tried cleaning them, but they failed again. I think I found the culprit: | timl@yarrow:~$ df -i /var/spool/cron/atjobs | FilesystemInodes IUsed IFree IUse% Mounted on | /dev/mapper/yarrow0-var | 915712 915712 0 100% /var | timl@yarrow:~$ With my privileges, I can't find out what's causing this. What I would look at first if I could would be /var/log/iptraf and /var/spool/postfix/*. [...] Merlissimo had filed https://jira.toolserver.org/browse/TS-1649 earlier. Now someone or something has freed about 96 % of inodes on /var, but left no note, so I don't know if the queues on yarrow can be enabled again. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Maintenance: Rebooting ortelius web server
Marlen Caemmerer marlen.caemme...@wikimedia.de wrote: I would like to reboot ortelius, one of the web servers at tomorrow, Tuesday 1830 UTC Apparently, wolfsbane rebooted today as well: | timl@wolfsbane:~$ uptime | 16:49pm up 5:00, 2 users, load average: 1.16, 1.24, 1.47 | timl@wolfsbane:~$ Perhaps related to that, SGE queues on ortelius and wolfs- bane are in state au (alarm, unknown): | timl@wolfsbane:~$ qstat -f -explain a | sed -ne '1,2p' -e '/ortelius\|wolfsbane/,/^-/p' | queuename qtype resv/used/tot. load_avg arch states | - | short-sol@ortelius.toolserver. B 0/0/8 -NA- sol-amd64 au | error: no value for np_load_short because execd is in unknown state | error: no value for np_load_avg because execd is in unknown state | error: no value for cpu because execd is in unknown state | error: no value for mem_free because execd is in unknown state | alarm gf:tmp_free=100G load-threshold=200M | alarm gf:available=1 load-threshold=0 | - | short-sol@wolfsbane.toolserver B 0/10/12-NA- sol-amd64 au | error: no value for np_load_short because execd is in unknown state | error: no value for np_load_avg because execd is in unknown state | error: no value for cpu because execd is in unknown state | error: no value for mem_free because execd is in unknown state | alarm gf:tmp_free=100G load-threshold=200M | alarm gf:available=1 load-threshold=0 | - | medium-sol@ortelius.toolserver B 0/0/4 -NA- sol-amd64 au | error: no value for np_load_short because execd is in unknown state | error: no value for np_load_avg because execd is in unknown state | error: no value for np_load_long because execd is in unknown state | error: no value for cpu because execd is in unknown state | error: no value for mem_free because execd is in unknown state | alarm gf:tmp_free=100G load-threshold=100M | alarm gf:available=1 load-threshold=0 | - | medium-sol@wolfsbane.toolserve B 0/3/4 -NA- sol-amd64 au | error: no value for np_load_short because execd is in unknown state | error: no value for np_load_avg because execd is in unknown state | error: no value for np_load_long because execd is in unknown state | error: no value for cpu because execd is in unknown state | error: no value for mem_free because execd is in unknown state | alarm gf:tmp_free=100G load-threshold=100M | alarm gf:available=1 load-threshold=0 | - | timl@wolfsbane:~$ Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] Inodes have run out on yarrow's /var
(anonymous) wrote: [...] Plus medium and longrun queues in yarrow are in error state. I tried cleaning them, but they failed again. I think I found the culprit: | timl@yarrow:~$ df -i /var/spool/cron/atjobs | FilesystemInodes IUsed IFree IUse% Mounted on | /dev/mapper/yarrow0-var | 915712 915712 0 100% /var | timl@yarrow:~$ With my privileges, I can't find out what's causing this. What I would look at first if I could would be /var/log/iptraf and /var/spool/postfix/*. After fixing this, we need Nagios alerts for /var as well. Tim P. S.: Toolserver Office Hour + 10 days = today. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Toolserver -- Labs
(anonymous) wrote: [...] Database replication came up yet again in the office hours. Many developers (myself included) seem to be holding off on Labs until database replication is up and running. The sooner this can happen, the better. But the remaining sticking point seems to be cross-database joins, which people in the office hours suggested using federated tables or application logic to replace. It would help if the Labs folks could better explain _why_ cross-database joins won't be supported (I think most developers would agree with the reasoning) and offer better guidance and documentation for how to work around this hurdle. (For example, what is a federated table?) [...] The problem with this decision is the effort spent and the insincerity. If database replication for Labs would have meant moving some dbxxx servers to labsdbxxx, adding the views existing on Toolserver and tightening some firewall rules, it could have been set up in a month, and any moaning about having to use federated tables would have been si- lenced by the minutes it would take to add another server to the cluster to increase performance compared to the years it takes at Toolserver. Or there could have been some new concept like Galera men- tioned by Nosy that eases maintenance because it is not some sparsely documented Solaris thingy in River style. But now the plan is to have two clusters (PreLabsDBDBS and LabsDB), use triggers to remove data and then (addition- ally!) views, end up with less functionality than the Toolserver while gaining nothing, and all that takes half a year to set up in a cloak-and-dagger way while publicly the need for cross-database JOINs is acknowledged. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Survey: Moving to Labs
(anonymous) wrote: until now I had the impression that we (you, the authors, and me) fight together against WMF and WMDE for keeping the Toolserver and against Labs. Some mails and discussion in the last days gives me now the impression that this was wrong and (at least some of) you are eager to leave the toolserver as soon as possible. There is no point to beg the WMDE for new hardware and to invest much more time if 2 weeks after Labs is ready the toolserver will be empty. For this reason I created a survey at [1] that starts at midnight. Please take a moment of your time and place your nick in the section that suits you. Sincerely, DaB. [1] https://wiki.toolserver.org/view/Labs-Moving-Survey I wish there were an option saying move when XXX and YYY features are available and / or provided better on Labs. That's move as soon as possible. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] Toolserver limitation to come?
Hi,
at the office hour yesterday
(cf. http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130430.txt):
| [...]
| Coren multichill: The long story short; replicating
| databases is happening soon (Within the month)
| Replicating multiple copies of commons and wikidata
| isn't going to happen that way; it needs to be built
| into application logic or using federated tables.
| Almost /all/ of the problems the TS have had with
| replication were caused by that redundancy and
| trying to keep it synced.
| multichill Coren: So you're basically saying Toollabs is
| useless for me
| Platonides {{ref needed}}
| Coren We're all more than happy to help you (and any other
| maintainer) with adapting your tools to work in that
| setup.
| scfc_de Coren: In that case, Tools will not be able to
| replace Toolserver.
| giftpfla1ze what are federated tables btw?
| Ryan_Lane AFAIK toolserver will also have this limitation
| at some point
| scfc_de Ryan_Lane: What do you mean?
| [...]
There were never answers to this, so I bring it up here
again:
1. How were almost /all/ of the problems the TS have had
with replication caused by that redundancy and trying
to keep it synced?
2. What limitation will the Toolserver have at some point?
Tim
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] I can't login any more
Alex Brollo alex.bro...@gmail.com wrote: I've a Toolserver account - I remember registration procedure just like a terrible nightmare and I survived only thanks to lots of luck. Now, server refuses connection. I use Pageant, usually login is very simple - I load my key, then I open Putty, I post my username and all runs. But now it doesn't run any more. How can I get some help? Is this still current? Apparently, there was some outage that was fixed at about 15:00Z. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Failed Maintenance - was - Re: IP Renumbering of the complete Toolserver cluster (fwd)
Marlen Caemmerer marlen.caemme...@wikimedia.de wrote: [...] yes, that is true. I try to find out but all I found until now was that some requests get redirected from nginx not to ortelius/wolfsbane web servers but to apache. Usually there should be svn and nagios and the svn error log is frequently reporting it cant find user urls... But why it gets redirected to the svn service...I still dont know. [...] Perhaps the configuration for Nginx could be published on the wiki (or even puppetized)? This would allow more eyes to look at it :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] When is the best time of day to run programs?
Byrial Jensen byr...@vip.cybercity.dk wrote: I am planning to make some maintenace reports for the Danish Wikipedia at regular intervals, like once a week or once every few days, but the exact time to run the programs doesn't really matter. So what time of the day is it best to run such programs? And is there a way to tell SGE that it may choose the most convenient time to start to job? It will do that by itself, in fact, it is its whole pur- pose :-). Regarding time: | timl@yarrow:~$ perl -we 'my $t = rand (24 * 60); printf %d:%02d\n, $t / 60, $t % 60;' | 15:18 | timl@yarrow:~$ Does that suit you? :-) Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] When is the best time of day to run programs?
(anonymous) wrote: [...] If you are using sge you have not really care about. If you can use the hole cluster (linux and solaris) we mostly have enough capacity. It is only important that you can specify which resources (memory, runtime) you need. [...] BTW, is the Queue State on http://munin.toolserver.org/Miscellaneous/turnera/index.html#sge the number of queued jobs? Mark, is there something Munin- like on Labs? Does Icinga have graphs? Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Jira Auth broken
Jeremy Baron jer...@tuxmachine.com wrote: Just wondering what the latest news is here? Can someone check the Atlassian bug? is the Atlassian bug in a public tracker that anyone can view? Still broken for me. I did notice that JIRA looked a bit different. Did we upgrade recently? By the way, it is affecting the wiki as well. I can't log in to wiki.toolserver.org Password recovery tells me both my username and email address do not exist. Unfortunatelly I got no response from Atlassian so far. The problem seems to be with the crowd authentication service. Jira says it wont sync the most of the users probably the wiki has the same problem since it authenticates against crowd too. Then crowd asks a local OpenDS ldap instance. At this time I still could not find any reasonable error so I am a bit lost. And it is quite strange since I updated on 26th of June and it stopped working on 25th of August... If someone on this list already worked with a similar setup I'd be greatful for hints. Bump. (I've just verified I still don't exist.) On IRC we found that Jeremy hasn't set a mail address on SSO so that may be a factor in *his* login problem. There's of course still the I get logged out after five minutes bug. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] No keys/indexes on wiki databases?
Morten Wang nett...@gmail.com wrote: If you wonder what the standard indexes are, there's a link to the SVN source on https://wiki.toolserver.org/view/Database_access#Database_schema [...] ... the outdated SVN source :-). Thanks, I fixed this. Be aware, though, that this doesn't reflect the actual configu- ration of the Toolserver as shown recently when the Wikidata schema changed. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] /tmp is not a waste dump
(anonymous) wrote: few minutes ago I had to clean ortelius' /tmp again because it was nearly full (there is up to 13GB space). Using temp-files is a great thing and we all know that clean-up is boring stuff – but please: If you can not make your tools clean after them self then YOU have to clean up for them from time to time. /tmp at ortelius contains over 9000 small files at the moment – I VERY doubt that most of them are still needed. So please look what is still needed, fix your tools and/or write a cleaning-script. Otherwise I have to write a system-wide script that will delete all files that are older than x days. [...] Why not just install tmpreaper? Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] /tmp is not a waste dump
I wrote: few minutes ago I had to clean ortelius' /tmp again because it was nearly full (there is up to 13GB space). Using temp-files is a great thing and we all know that clean-up is boring stuff – but please: If you can not make your tools clean after them self then YOU have to clean up for them from time to time. /tmp at ortelius contains over 9000 small files at the moment – I VERY doubt that most of them are still needed. So please look what is still needed, fix your tools and/or write a cleaning-script. Otherwise I have to write a system-wide script that will delete all files that are older than x days. [...] Why not just install tmpreaper? Because it doesn't work on Solaris. D'oh! Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] No keys/indexes on wiki databases?
Maciej Jaros e...@wp.pl wrote: I've notice that there are no keys and so probably no indexes on toolserver databases. Is this intentional? I've used below queries - both show no keys/indexes on revision table: SHOW COLUMNS FROMplwiki_p.revision; SHOW INDEX FROM plwiki_p.revision; I've also exported the whole schema and see no indexes at all... The same for random wiki on s2 - nlwiki_p. [...] They are /views/, not tables; use SHOW CREATE VIEW revision; to see the definition. Unfortunately, MySQL doesn't make this obvious. You cannot see if there are keys/indexes defined for the underlying tables as a normal user. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Introduction: Operators
DaB. w...@daniel.baur4.info wrote: after our discussion about more roots I got the impression that for some of you the topic of more roots is quite urgent. To be honest I feel not very well to just add a few roots at the moment. So I thought a compromise and created a new user-group: Operators [1]. Operators have a limited set of advantage rights – enough to help the roots and do every-day-jobs, but not enough rights to have access to sensible data (so no approval from WMDE or WMF is necessary). For testing I gave operator-status to the following people: Merl, who manage SGE already, Danny_B, who manage the user-store already, and Platonides who volunteered. There will be more in the future, but at the moment these 3 will do. In the new group the operators can collect experience while helping the users and the TS. And the roots can see who could get root-status someday and who not. The group is also a good place for users who like to help the TS, but can not invest the same amount of time like a root. So let's see if this solution works. That's nice. As approval from WMDE and WMF will take some time anyway, we should start the process for Coren and Pla- tonides now. When the paperwork is done in a few weeks, we can proceed further. Silke, could you find out if WMDE has existing NDAs for Toolserver admins and send them to Coren and Platonides? Also, you said they needed to be vetted by WMF ops. Could you kick off that process as well, please? Thanks! Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
[Toolserver-l] Possible LDAP outtime this morning, major disruption
Hi, from about 3:00Z to about 3:20Z, no login was possible to nightshade and yarrow, (not existing) passwords required for willow and the webserver returned 404s. MZMcBride had an open session into willow, and loads of accessible servers were within limits (cf. http://p.defau.lt/?e_zsJIW_rAbfR3Cvlvx9Uw), but reserve lookup of user names was broken (cf. http://p.defau.lt/?asmBijtXnvzQacz1e8JXOQ) and ldapsearch timed out as well (cf. http://p.defau.lt/?P47PCC3_1d3mnoLyVqFUqQ). This looks like a failure of the LDAP server. Two other issues surfaced at that time: - http://nagios.toolserver.org/ gave 500s during the outage. I asked Coren to consult with WMF if there are possibili- ties to outsource (or integrate :-)) this monitoring to their existing infrastructure (http://icinga.wikimedia.org/). - The listed mail address for the Toolserver admins is ts-adm...@toolserver.org. While this may work during such an outage (I didn't try) and personal mail addresses for admins can be found in the toolserver-announce archives, we should prefer an address routed externally, and trying not to be too imaginative I propose: ts-adm...@wikimedia.de. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Possible LDAP outtime this morning, major disruption
I wrote: [...] - The listed mail address for the Toolserver admins is ts-adm...@toolserver.org. While this may work during such an outage (I didn't try) and personal mail addresses for admins can be found in the toolserver-announce archives, we should prefer an address routed externally, and trying not to be too imaginative I propose: ts-adm...@wikimedia.de. And imagine how unimaginative I can be, as according to Na- gios this address seems to exist already :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Postmortem: Partial Toolserver-outage
(anonymous) wrote: great parts of the toolserver-cluster were down or very slow in the last few hours. AFAIS it was a problem with the user-store or rosemary (where the user- store is physically connected). I rebooted rosemary, but the reboot showed problems with its IPv6-address. I tried to fix that what caused several other reboots. Rosemary is now up and running but the user-store is not available (looks like Nosy just mounted it without updating the fstab-file). So I was forced to remove the user-store everywhere (beside on willow because it need a reboot to do that and a reboot is scheduled already later for today). I will try if I can find the partition for user-store and mount it but I have not much hope (there are way to many devices to try) – just to be clear: There is no data lost. Also away will be munin, because its data is also mounted on that host. I fear that we have to wait for Nosy to recover before we get the user-store back. [...] Couldn't the search not be automated à la (untested): | mkdir t | for DEVICE in part1 part2; do | mount -o ro $DEVICE t || continue | [ -e t/sge ] echo Found ./sge on $DEVICE | umount t | done (with sge being just the first example of a directory be- neath /mnt/user-store that I can remember). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Postmortem: Partial Toolserver-outage
DaB. w...@daniel.baur4.info wrote: Couldn't the search not be automated à la (untested): several important partitions (for example database-partitions) live on this SAN. I have no idea what happens if a partition is mounted on 2 hosts, so I like to avoid blind mounting. On Linux and ext3/ext4, you should be pretty safe with -o ro,noload, but given the risk compared to the possible gain, I think waiting for nosy's (family's) convalescence is more prudent :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Sick
Marlen Caemmerer marlen.caemme...@wikimedia.de wrote: I have become sick as my baby has with high fever and it seems the rest of the family will join. Yesterday I was already in hospital with the baby but without me thinking about their treatments it wont work. She has a resistant bactery that the doctors wanted to treat with a antibiotic that will not work there - fortunatelly I forced the ambulant doctor to measure the bacerty some days ago. I personally feel fever too and we will now see if there is a second sort of bacerty or if its just one resistant. [...] Gute Besserung den schon Erkrankten und (prophylaktisch) den noch Gesunden :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Adding more roots
(anonymous) wrote: wasn't thinking about a paid job, but harvesting the vol- unteer potential of the toolserver usership. AFAIK the WMF accepts only paid persons anymore. But if the users would like to help, they can it even now: Update the pages in the wiki, write a patch for cron, add rules to puppet and help to clean it up, help newbies in the IRC and JIRA, add nagios-rules, prepare the switch from jira away (or find its problem), help Merl with the SGE, help Danny with the dumps, help Kai with OSM – and there are many more things. I have no problems with more roots (heh, if there are enough, I can leave ;-)). But beside the formal problems (WMF and WMDE), there is also the problem that to incorporate a new roots needs a lot of my time – and if the new root becomes inactive short time later my time was wasted. River appointed a few users to roots over the time, but I'm the only one left and most of my colleges were never very active. So in a nutshell: If you like to help the TS: Do it. If you need a special right and I know you, ask me and I will see what I can do. If you need to become a root and are SURE to stay, fight with WMDE and WMF (and me) and if you are successful I will show you how deep the rabbit hole goes ;-). I don't think that works. For example, if you want to fix the issues with JIRA (which are probably just some miscon- figuration), you need to have access to JIRA, and the mail logs, and the webserver, and the database, and whatnot. To do this, you effectively have to be root. I also don't think that a lot of familiarization for new roots is necessary. After all, the servers don't run on magic, but on software, and if you are able to find your way around JIRA, or OSM, or something else that needs attention, you are *very* probably skilled enough to read and under- stand configuration files and code. And finally I think that we shouldn't artificially heighten the entry barriers for people trying to help. Someone of- fering their knowledge and time to help with toolserver ad- ministration shouldn't have to promise a long term commit- ment, and they certainly shouldn't have to fight so that the recipient will accept their gifts. On Labs, which is scheduled to have replicated databases by the end of the month, there is no such barrier, and it may become increas- ingly difficult to convince volunteers to invest any time in the toolserver. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Mail forwarding not working
Chris Grant chrisgrantm...@gmail.com wrote: For the Unix irregulars, log into the server and execute mail. [...] Or you can use mutt. I find it's more user friendly. It is :-). What I like about mail compared to other tools is that it doesn't do anything not needed, i. e. no ~/Mail directory, no configuration files, etc. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Adding more roots
(anonymous) wrote: So we should add more roots, ideally of course Solaris/Linux bilinguals with 20+ years of HA and MySQL replication expe- rience and lots of spare time on their hands, practically any bright mind who can track down some bug, update the pup- pet configuration and care for all the other tidbits while documenting their work meticulously, so that the roots can focus on the more complicated stuff. unfortunately it is not that easy (and finding a solaris-person is quite hard). There are other problems too. For example you have to find somebody who is accepted by WMDE (as owner) AND WMF (as database-owner). Than there is nearly no or no up2date docu. Also WMDE still believes that the toolserver will not survive this year so the contract would be limited (so much learning for a short job). The person would also have to life with me, you all and the community – and neither is easy sometimes. Another point is that the influence of WMDE would increase (Wes Brot ich es, des Lied ich sing) and taken the position of WMDE I'm not sure if that is a good idea. I wasn't thinking about a paid job, but harvesting the vol- unteer potential of the toolserver usership. If there are problems along the way, we'll sort them out. But not moving forward because there *might* be problems is not acceptable IMHO given that we have many *existing* problems right now. I know that some of you wait for stuff to happen and I'm sorry that it takes a lot of time sometimes – but my to-do-list is long and even my time is limited. I hope to fix some things during my next semester break (beginning in 2 weeks), but not everything will be fixed. And that's the reason why we need more roots. There is no point in forcing all the work on two people and them to rush fixes (which usually doesn't result in good quality), when we have lots of people around who could solve issues in a jiffy. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Mail forwarding not working
I wrote: for those of you not having seen TS-1553, mail forwarding seems to have stopped working. So if you haven't received the usual job reports that you were expecting, you might want to login to all servers and check if there is mail for you. You can query all servers by: | for SERVER in clematis hawthorn nightshade ortelius willow wolfsbane yarrow; do | ssh $USER@$SERVER.toolserver.org ls -l /var/mail/$USER | done replacing $USER with your username. Here's a list of accounts that still have mail sitting on (one of) these servers, some dating back to October: User | clematis | nightshade | ortelius | willow | wolfsbane | yarrow --+--++--++---+ abuseresponse| || |x | | acc | x|| || | akoopal | || || |x alebot | || |x | | alex | x|| || | alexz| | x | || | andrew | || |x | | artem| || |x | | authoritycontrol | x| x | x|| x |x avar | || |x | x | beria| || |x | | bryan| | x | x|x | x | chzz | || |x | | cirdan | || || |x cpt.daniel | x|| || | cvt | || |x | | cyroxx | | x | || | dab | || || x | daniel | || || x | darkdadaah | | x | || |x dartar | | x | || | dcoetzee | | x | || |x delinker | x| x | |x | |x dereckson| x|| || | devunt | || || |x dewpmp | x|| |x | | dispenser| x|| || | dm | | x | || |x dodo | || |x | | dpl | x| x | x|| |x eccenux | | x | || | enwikt | || |x | | eranroz | | x | || | feedback | x|| || | geohack | x|| || | globalusage | x|| |x | | grimlock | || |x | | haffman | | x | || |x helloannyong | | x | || | hersfold | | x | || | hoo | | x | || | hoodedman| x|| || | hroest | || |x | | husky| || || |x iluvatar | || |x | | interwikibot | | x | |x | | james| x|| || | jarry| | x | |x | | javadyou | | x | || |x jcreus | || || |x jeanfred | || || |x jeblad | x|| || | jem | x|| || | kentaur | || || |x kju | x|| |
Re: [Toolserver-l] RSA key changed on yarrow?
Merlijn van Deen valhall...@arctus.nl wrote: ssh'ing to yarrow gives: | [tim@passepartout ~]$ ssh yarrow.toolserver.org | The RSA host key for yarrow.toolserver.org has changed, | and the key for the corresponding IP address 91.198.174.216 | is unknown. | The fingerprint for the RSA key sent by the remote host is | 59:3d:de:62:07:44:f2:f3:b0:e1:6d:a8:d2:7e:7e:af. Was this intentional? Yarrow was used as name for at least one other server before the current login server. This one was installed recently (july), and your host keys might be older (and thus correspond to the wrong server). No, I use yarrow regularly and the behaviour changed this weekend. After comparing backups, the only change was a ~/.ssh/known_hosts2 with the contents: | yarrow.toolserver.org ssh-dss [...]== After removing this file, ssh ceased to complain. I played around with Net::SSH::Perl Co. this weekend, and my assumption is that - as it doesn't work quote right :-) - it dumped an invalid key to this file which caused ssh to barf. So: No RSA key changed on yarrow :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] JIRA session loss
(anonymous) wrote: What features should it have? - A possibility to mark ticket/reports as non-public, - the possibility to have projects/components - very good would be a LDAP-interface or a SSO-integration Why not just use the WMF Bugzilla? That would clear the toolserver admin's plate of one more thing to take care of. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] JIRA session loss
I wrote: At some point I even logged in, clicked an issue, clicked Edit (which uses AJAX) and then the Edit screen wouldn't load due to me not being authenticated (while I still saw my nickname on the top right). I have the same problem lately when I use JIRA. The session loss happens intermittently, though, so if I just try the same edit over and over it eventually works. At least, it has always worked when I tried it. It doesn't work for me since at least early October, but it never healed itself - I always had to login again (after copying the comment I was about to enter and trying to re- member what else I wanted to change :-)). Any update on this? I'd also be interested if there is a schedule for fixing TS-1528 (Mails from JIRA have stopped working). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Multiple jobs started, SGE or cron issue?
Morten Wang nett...@gmail.com wrote: Looks like this was a PEBKAC[1], should have used qcronsub and not cronsub. Thanks to Sumurai8 for spotting that and suggesting ways to debug if the problem continues! It appears that qcronsub doesn't allow me to specify all options in the shell script, though. If I specify virtual_free using #$ -l virtual_free=xxM I get this error: nettrom@willow:~$ qcronsub SuggestBot/opentask/opentasks-nettrom.sh Unable to run job: attribute virtual_free is not a memory value. Exiting. Instead I have to specify it as a command line option to qcronsub. Feature or a bug? [...] Does it work with qsub? Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] JIRA session loss
(anonymous) wrote: At some point I even logged in, clicked an issue, clicked Edit (which uses AJAX) and then the Edit screen wouldn't load due to me not being authenticated (while I still saw my nickname on the top right). I have the same problem lately when I use JIRA. The session loss happens intermittently, though, so if I just try the same edit over and over it eventually works. At least, it has always worked when I tried it. It doesn't work for me since at least early October, but it never healed itself - I always had to login again (after copying the comment I was about to enter and trying to re- member what else I wanted to change :-)). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Mail forwarding not working
(anonymous) wrote: for those of you not having seen TS-1553, mail forwarding seems to have stopped working. So if you haven't received the usual job reports that you were expecting, you might want to login to all servers and check if there is mail for you. You can query all servers by: | for SERVER in clematis hawthorn nightshade ortelius willow wolfsbane yarrow; do | ssh $USER@$SERVER.toolserver.org ls -l /var/mail/$USER | done replacing $USER with your username. Actually, no need to replace it. $USER is set automatically. You can run: $ for SERVER in clematis hawthorn nightshade ortelius willow wolfsbane yarrow; do ssh $USER@$SERVER.toolserver.org test -s /var/mail/$USER echo $SERVER; done and it will list for you the servers where you have mail. Actually, that's only true for those whose username on the toolserver is the same as on their private box :-). I'd have to name my username on the toolserver either explicitly or rely on my ~/.ssh/config: | Host *.toolserver.org | User timl and always escape the second $USER so that it is expanded on the toolserver. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
I wrote: Thanks. I don't want to fiddle to much with SGE's in- testines, so I will probably either use | mail timl in my script or have my MUA insert the log in the status mail. I looked if I could submit this totally fascinating and innovative idea of mailing the output as a RFE upstream, but amazingly I didn't see a bugtracker at Oracle :-). I would even have had another idea: Impromptu jobs à la echo true | at now :-). Oracle closed-sourced it. There are a number of forks. Quick link: http://gridengine.org/blog/2011/11/23/what-now/ If these two issues are the only things missing in SGE, I think we can stay with it :-). No, we are using an open source version based on SGE 6.2u5 patch 2 which was the last open source version by oracle (so for documentation refer to this version). I used Grid Engine 2011.11p1 but i also added some additional bug patches and special modifications for our toolserver version. Oh, that's nice. Is the source available somewhere? [...] Merlissimo replied on IRC that the source is at /mnt/user-store/sge and that binaries for Solaris and Linux 2.6 were compiled on Solaris boxes. /sge is shared between hosts and also contains the master spool. So if someone wants to tackle TS-963, there you are :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: Thanks. I don't want to fiddle to much with SGE's in- testines, so I will probably either use | mail timl in my script or have my MUA insert the log in the status mail. I looked if I could submit this totally fascinating and innovative idea of mailing the output as a RFE upstream, but amazingly I didn't see a bugtracker at Oracle :-). I would even have had another idea: Impromptu jobs à la echo true | at now :-). Oracle closed-sourced it. There are a number of forks. Quick link: http://gridengine.org/blog/2011/11/23/what-now/ If these two issues are the only things missing in SGE, I think we can stay with it :-). No, we are using an open source version based on SGE 6.2u5 patch 2 which was the last open source version by oracle (so for documentation refer to this version). I used Grid Engine 2011.11p1 but i also added some additional bug patches and special modifications for our toolserver version. Oh, that's nice. Is the source available somewhere? But the mail feature you requested could be implemented without modifying any source code by our epilog script. Just open a jira ticket and i will think about this feature. I've opened TS-1530 and TS-1531; please feel free to assign them to you. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reasons for not migrating to Tool Lab
(anonymous) wrote: We currently have no plans for having the user databases on the same servers as the replicated databases. Direct joins will not be possible, so tools will need to be modified. This is unfortunate, and a huge step backwards from the situation on the toolserver. For example, the project I maintain on toolserver (the enwiki WP 1.0 assessment data) has user database tables with several million rows of data about articles, from which it needs to select the data for pages from fixed categories on the wiki, which themselves could have a few thousand members. The natural way to do this is to join against the categorylinks table. Any non-join solution is going to be much, much less efficient. A key role of the toolserver setup was that it allowed these sorts of joins. Web hosting is cheap and data about the live wiki is already available in non-joinable form through the API with no replag. Even more: If Labs replication isn't bound by Toolserver tradition, it would be *very* nice not to fragment the data according to the different WMF clusters, plus Commons or not, plus (separate) user databases or not, but have one cluster where users can join as logic suggests. As Toolser- ver merges Commons onto other clusters already, this seems to be possible with MySQL. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: Please see the documentation on Toolserver wiki [1] to set this up. It uses a command of -m with another variable depending on when you want mail sent. [1] https://wiki.toolserver.org/view/Batch_job_scheduling#arguments_to_qsub/qcronsub [...] That just sends notifications about the job's status, not the job's output itself. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: Please see the documentation on Toolserver wiki [1] to set this up. It uses a command of -m with another variable depending on when you want mail sent. [1] https://wiki.toolserver.org/view/Batch_job_scheduling#arguments_to_qsub/qcronsub [...] That just sends notifications about the job's status, not the job's output itself. No, there's no such option. I looked into it recently. We could get that by adding a final script which mails the user the output file if qstat -j $JOB_ID | grep -q mail_options:.*e. Thanks. I don't want to fiddle to much with SGE's in- testines, so I will probably either use | mail timl in my script or have my MUA insert the log in the status mail. I looked if I could submit this totally fascinating and innovative idea of mailing the output as a RFE upstream, but amazingly I didn't see a bugtracker at Oracle :-). I would even have had another idea: Impromptu jobs à la echo true | at now :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] How to have qsub mail output?
(anonymous) wrote: Thanks. I don't want to fiddle to much with SGE's in- testines, so I will probably either use | mail timl in my script or have my MUA insert the log in the status mail. I looked if I could submit this totally fascinating and innovative idea of mailing the output as a RFE upstream, but amazingly I didn't see a bugtracker at Oracle :-). I would even have had another idea: Impromptu jobs à la echo true | at now :-). Oracle closed-sourced it. There are a number of forks. Quick link: http://gridengine.org/blog/2011/11/23/what-now/ If these two issues are the only things missing in SGE, I think we can stay with it :-). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reasons for not migrating to Tool Lab
(anonymous) wrote: [...] I think I'd add general direction of centralizing everything under a single Wikimedia Foundation is a bad idea as a permanent blocker. Maybe there's a reasonable case for why deprecating the Toolserver and creating Wikimedia Labs is a great idea, but I don't see it yet. I don't see why each (Wikimedia) chapter shouldn't have its own replica of the databases. We want free content to be free (and re-used and re-mixed and whatever else). If you're going to invest in infrastructure, I think it makes more sense to bolster replication support than try to compete with the Toolserver. That said, pooled resources can sometimes be a smart move to save on investments such as hardware. Chapters working together is not a bad thing (I believe some chapters donated to Wikimedia Deutschland for Toolserver support in the past). But the broader point is that users should be very cautious of the general direction that a Wikimedia (Foundation) Labs is headed and ask whether it's really a good idea iff it means the destruction of free-standing projects such as the Toolserver. IMHO you have to differentiate between data and function. It makes no sense to build artificial obstacles when setting up some tool that can only be reasonably used with the live dataset. On the other hand, preparing for a day where WMF turns rogue is never wrong. But the nice thing about Labs is that you can try out (re- plicable :-)) replication setups at no cost, and don't have to upfront investments on hardware, etc., so when time comes, you can just upload your setup to EC2 or whatever and have a working Wikipedia clone running in a manageable time- frame. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] When to execute cron-tasks
Merlissimo m...@toolserver.org wrote: [...] Does anybody know if vixie cron (=cronie on ts) supports sth. similar? That would solve the problem. [...] Not as far as I know (or see in the code). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
Platonides platoni...@gmail.com wrote: It's not only a question of space, but also of availability. I don't know about Debian or Solaris, but on Fedora some packages are sent to a farm up north when they don't compile in the current release and noone volunteers to fix it. I wouldn't want the admins in this case to work on such prob- lems if there is no existing demand. I'm more optimistic regarding the abilities of the tool- server users - if someone can write import x or use y; they should be able to copy and paste that to another file. And if they don't, that'd be a nice opportunity to ask for and share some knowledge. That assumes they know what they are doing, instead of blindly copypasting recipes. I know that's not true for many toolserver users, where we have very valued developers. But I'm sure there is also a bunch of people which copied pywikipediabot following some instructions, and are only experts on its command line. Don't misinterpret me, I'm not meaning that they shouldn't have an account in the TS, or that they are second-class users. It's good to have them on board, each one has its own know-how, very much as not every php coder is a perl guru. But not everyone has the experience to identify the dependencies of what they're doing. Now you've scared me :-). In an ideal world I'd solve this by packaging pywikipediabot in the usual way so that the users would just have to declare their dependency on it, and someone experienced could make sure that only a) one b) cur- rent and c) secure snapshot is used. And then, even for those writing their own scripts, having to copy the requisites to a separate file and keeping them up-to-date is a burdensome task. I prefer the autodetection way as far as it's possible (which in most cases looks simple). As long as the user can specify additional dependencies, sure, why not. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] [Wikitech-l] 403: User account expired toolserver.org/~soxred93
Platonides platoni...@gmail.com wrote: [...] I think it really makes sense to define the names of a set of available functions. That would really make much simpler the development of portable tools, or working on different languages, without having to relearn the framework used. That said, each of us would probably push for their own API to be standarised. I think you found the problem :-). Should normalizeLink be a method of WikiFarm, Wiki or WikiPage? Should a page title be a string or a WikiTitle? If the latter and in a true OOP language, should it be a derived class of string or WikiString which would be then derived from string? And so on, and so forth. I don't think providing tests is the panacea for making people implement them. They are obviously nice, but as it would be open source, each user doesn't need to reimplement them according to the specification. The same code could be shared. The problem is in adoption of the API, and agreeing on an standarised one. Having recently ported a parser skeleton from Java to PHP, I disagree wholeheartedly :-). There are many subtle differ- ences between languages which programmers usually aren't even aware of because they take them for granted. Take re- gular expressions and their various flavours for example. Test cases ensure reproducable results and give the develop- ers the confidence that their enhancement/optimization will not burn down the house. So I'm looking forward to Madman publishing his framework. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] [Wikitech-l] 403: User account expired toolserver.org/~soxred93
MZMcBride z...@mzmcbride.com wrote: [...] I'm a bit concerned about the diversity of the tools made by each of us. Almost every user utilises its own library of files for providing a skin, db access... Which make integrating them into something coherent quite hard. These multiple frameworks may also be an effect of the large applications ban. [...] I had similar thoughts recently when faced for the n-th time with accessing Wikipedia per MySQL (on the toolserver) or the API (elsewhere) in Perl. It would be nice to have one module with an interface that can be used by Toolserver users and others as well. Skins fall into this category as well: I think most developers could easily adapt their tools to use a centralized skin, but wouldn't bother to implement one by themselves that is accessible and usable. Right. Or if the Toolserver is horribly lagged, switch to the API silently to get the most recent data. I've had similar thoughts. While we all dream of a world in which there's no duplicated coding effort, the reality of these Toolserver tools is that every developer has a programming language preference. You're Perl, I'm Python, others are PHP. So ultimately, I don't know how much integration there can really be. Well, there are 684 directories in /home, so there will probably be more than one project in Perl, Python or PHP :-). Even if only for PHP there would be a critical mass, it'd be still useful to Perl, Python and other developers. For example, I think it is a common problem to normalize links - e. g., are [[Diskussion:ABC_abc#.C3.A4.C3.B6.C3.BC]] and [[de:Talk:aBC abc#äöü]] pointing at the same resource? Most developers start with the easy bits and end up with something that works for most of their use cases, but fails if that line is overstepped (for example Image: - File:). If there was an existing module for this, you wouldn't have to think about all the fringe cases yourself, but could base upon the sweat poured by others :-). If Me- diaWiki got updated, you would just have to look at the changes in the PHP module and port them to your language of choice. Consistent styling (importing a common CSS file) is easy enough, though. As long as, y'know, it isn't ugly. ;-) AFAICS, common CSS wouldn't be enough for a consistent user interface. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] [Wikitech-l] 403: User account expired toolserver.org/~soxred93
Platonides platoni...@gmail.com wrote: [...] I'm a bit concerned about the diversity of the tools made by each of us. Almost every user utilises its own library of files for providing a skin, db access... Which make integrating them into something coherent quite hard. These multiple frameworks may also be an effect of the large applications ban. [...] I had similar thoughts recently when faced for the n-th time with accessing Wikipedia per MySQL (on the toolserver) or the API (elsewhere) in Perl. It would be nice to have one module with an interface that can be used by Toolserver users and others as well. Skins fall into this category as well: I think most developers could easily adapt their tools to use a centralized skin, but wouldn't bother to implement one by themselves that is accessible and usable. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
DaB. w...@daniel.baur4.info wrote: [...] I believe we had several issues already in the past when the installed soft- ware differed between the Solaris servers. Which brings me to: Does anyone know an established format a) in which pro- jects could write down their requirements and b) that covers both Debian and Solaris? So when admins need to (re-)in- stall a server, they wouldn't have to guess which packages are (still) required, but could just collect all $HOME/.requirements for active accounts and when one of these could not be satisfied, there would also be a person to contact before tools get broken. That is a nice plan, but it would not work, because most users are not capable to tell what liberies they need. And it is BTW not a problem to have a libery installed that is not used (because we have enough free space for that). [...] It's not only a question of space, but also of availability. I don't know about Debian or Solaris, but on Fedora some packages are sent to a farm up north when they don't compile in the current release and noone volunteers to fix it. I wouldn't want the admins in this case to work on such prob- lems if there is no existing demand. I'm more optimistic regarding the abilities of the tool- server users - if someone can write import x or use y; they should be able to copy and paste that to another file. And if they don't, that'd be a nice opportunity to ask for and share some knowledge. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
Jeremy Baron jer...@tuxmachine.com wrote: Which brings me to: Does anyone know an established format a) in which pro- jects could write down their requirements and b) that covers both Debian and Solaris? So when admins need to (re-)in- stall a server, they wouldn't have to guess which packages are (still) required, but could just collect all $HOME/.requirements for active accounts and when one of these could not be satisfied, there would also be a person to contact before tools get broken. I assume this is one of the reasons to use puppet? Puppet manifests can have comments and the roots could establish a standardized way of writing (inline) why a package is needed. (e.g., a) assumed to be widely used like sed, grep or b) needed by the roots or a process that doesn't belong to a particular user or MMP or c) needed by users/MMP foo, baz, bar or some combination of those.) Of course most people (whether roots or users or anyone else) won't do a very thorough job of enumerating dependencies when installing, updating, hacking software unless they first do an installation of that version on a brand new Debian install with a limited set of installed packages. i.e. most people won't notice that a package is needed or not already picked up some other way until they see something is broken because it's missing. I'm not sure if I like ~/.requirements (and maybe it could be something like ~/.package-depends instead?) in place of puppet but at least it could be used as a failsafe if a root wanted to check after installing a new box or before removing a package. [...] I wouldn't want to put the burden on the roots because that would mean that they have to mangle all the small notes that project X needs package Y into the puppet manifest which in most cases - as you noted - will not have much effect. If instead it'd be up to the project's developers, the workload lies with who has a) the information needed and b) the moti- vation. On second thought though, I think ~/.something is too hidden. We already have the nice [[Template:Tool]] on the Toolserver Wiki; it would be much better to store the depen- dencies as fields thus encouraging developers to update (or create) their pages there and give them more publicity. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Debian (Linux) is coming back
DaB. w...@daniel.baur4.info wrote: [...] If you are a Debian-user too, you can help me a little bit: Insert needed packages at [1] and help other users to find packages for their needed liberies. [...] Does this mean that all the accumulated JIRA requests for Perl modules Co. will get scrapped? :-) I believe we had several issues already in the past when the installed soft- ware differed between the Solaris servers. Which brings me to: Does anyone know an established format a) in which pro- jects could write down their requirements and b) that covers both Debian and Solaris? So when admins need to (re-)in- stall a server, they wouldn't have to guess which packages are (still) required, but could just collect all $HOME/.requirements for active accounts and when one of these could not be satisfied, there would also be a person to contact before tools get broken. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] interwiki.py
Merlijn van Deen valhall...@arctus.nl wrote:
Personally, I rather we wait for the Pywikipedia devs to fix that script,
This is not going to happen anytime soon. Considering the state of the
code base (two hundred exceptions for three hunderd wikis, long
functions and no automated testing - and thus practically untestable),
and the state of the InterLanguage extension ('will be installed
soon'), so-one is really willing to invest a lot of time in tracking
memory usage and reducing it.
The only reasonable action we can take to reduce the memory
consumption is to let the OS do its job in freeing memory: using one
process to track pages that have to be corrected (using the database,
if possible), and one process to do the actual fixing (interwiki.py).
This should be reasonably easy to implement (i.e. use a pywikibot page
generator to generate a list of pages, use a database layer to track
interlanguage links and popen('interwiki.py page') if this is a
fixable situation)
We could also move the pressure: Labs' bot running infra-
structure doesn't seem to be /that/ far from opening. If
interwiki bots were running there, it would allow the foun-
dation to judge whether pushing for the deployment of Inter-
Language isn't worth it in the end.
Meanwhile I think DaB.'s proposal is very adequate.
Tim
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Moving to Apache?
DaB. w...@daniel.baur4.info wrote: Is there any roadmap to move off ZWS? we plan to do this at the next maintaince-window, which is planed for 7. Dec at the moment. a) Thanks! b) After further reading, environment variables seem to be cleared by Apache's suEXEC which the toolserver will probably use - *grrr*. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Moving to Apache?
(anonymous) wrote:
I haven't tested it, but the possibility to SetEnv
PERL5LIB in an .htaccess file should be an elegant solu-
tion to this, and according to the Zeus documentation, there
seems to be no such thing in ZWS.
#!/usr/bin/perl
BEGIN {
if ( $ENV{SERVER_SOFTWARE} =~ /Apache/ ) {
use lib '/foo/bar/baz';
} else {
use lib '/quux/fuzzle/wuzzle';
}
}
have not tried, but dont see why it wouldn't work.
I'm not looking for a working solution (there's no shortage
of those), but a simple and elegant one :-). Testing the
software at home and on nightshade, offline and online gives
already four cases to consider, and this as any other work-
around hard-codes paths and server configurations as well.
Even more straight-forward would be to replace the Perl
script with a shell script that justs set PERL5LIB and
then calls the former.
Tim
___
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Posting guidelines for this list:
https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Fwd: [TS] Killed SQL-Task 15233729 on db-server z-dat-s6-a
Mashiah Davidson mashiah.david...@gmail.com wrote: Once again, a question on query killer. Below its report informs that with near-zero replag a very simple count(*) only query on s6 takes too long, and the killer expects SLOW_OK would help. I think something is wrong fundamentally once such a query takes that long, and there is no reason to add SLOW_OK and wait even longer. [...] SELECT count(*) INTO @tl_count FROM ruwiki_p.templatelinks [...] I don't know about MySQL, but usually COUNT is rather slow as it has to look up for every row if it is visible to the current transaction. When did you start using it? :-) Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Maintenance for schema changes, now
River Tarnell r.tarn...@ieee.org wrote: Given WMDE's recent fundraising changes which now allow sup- porting WMF directly, are there any plans to blur the clear distinction between WMF's farm and the Toolserver database servers with the accompanying headaches in the near future? Not that I know of. What sort of changes were you expecting? I was expecting nothing :-). But as the Toolserver was miss- ing on WMF's radar in the past several times, one obvious solution would be to treat the Toolserver database servers as part of WMF's domain so they can use their SOPs (*1) to maintain them instead of manually coordinating with the Toolserver admins (or not). Tim (*1) With a twist for the user databases/access restric- tions, of course. ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Maintenance for schema changes, now
River Tarnell river.tarn...@wikimedia.de wrote: This was not announced in advance since we only learnt about the changes about 10 minutes ago. Sorry. Is this something we can do about in the future? I've asked WMF (i.e., Tim) to let us know about schema changes in advance next time, so we can apply them with less service interruption. Given WMDE's recent fundraising changes which now allow sup- porting WMF directly, are there any plans to blur the clear distinction between WMF's farm and the Toolserver database servers with the accompanying headaches in the near future? Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Why JIRA is down? To River
River Tarnell river.tarn...@wikimedia.de wrote: Can you notice http://status.toolserver.org/ password to toolserver users? I will give out the password for status.toolserver.org to trusted Toolserver users on request. Trusted means that I know who you are, and we've had some kind of interaction in the past, and I think you're sensible. I won't give it out to all users. BTW, the warn.png included on this page seems to be broken: | [...@passepartout ~]$ display warn.png | display: IDAT: CRC error `warn.png' @ png.c/PNGErrorHandler/1404. | display: Corrupt image `warn.png' @ png.c/ReadPNGImage/2898. | [...@passepartout ~]$ Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reminder: move your projects off stable -Geohack
I wrote: perhaps this would be a good moment to transfer Geohack to a regular mediawiki-extension on the main servers. I hear this was also the plan of brion vibber before he go. Who we need to ask now for this? I asked Brion on the Paris meeting and he said he'd have a look. But, I didn't hear anything back, so I assume he didn't. wikimedia.org doesn't list an official CTO, so for the time being, I guess Tim Starling is the person to ask. Last time I had a long look at the code, the extension part seemed to be in good condition. One half is using it as a special page (just a wrapper around the current code calls), and getting the wiki template from the cache instead of the http rendering. Compatability might have deteriorated since then, though. [...] I had a look at the code one or two years ago, and started a small DWIM-and-nothing-more extension Mapsources along the lines of Booksources that called a template with the co- ordinates as parameters so that you could use all of Media- Wiki's parser functions Co. in it. The idea would have been to extend it eventually to have the list of map sources ordered by the region of the individual coordinate and by user preference (Swiss coordinates: Swisstopo, British coor- dinates: Ordnance Survey, etc.) with a timeout so that if you don't react within x seconds the first map source is chosen. But #1, then I stumbled upon a post of yours where you pointed out that Special:TemplateLink would be much more suitable to replace the whole Geohack shebang, and I think you were right. But #2, with all the work going on with OSM and the Maps extension, wouldn't it be wiser to integrate Geohack's func- tionality with the later? As there was no response, I resurrected the code from my ar- chives and created URI:http://www.mediawiki.org/wiki/Extension:Mapsources (code available by git clone http://www.tim-landscheidt.de/git/Mapsources;). It's not yet ready for production, but with the main source file below 300 LOCs, it shouldn't be that hard (mainly properly vali- dating and escaping input). Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Getting lengths of old revisions
Aryeh Gregor simetrical+wikil...@gmail.com wrote: [...] I don't have any suggestions as to your actual problem, though. I don't see a script to populate rev_len in maintenance/, so I guess someone would have to write one. If someone does, please update bug #18881. There is Bryan's patch in bug #12188 to build upon. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] what's the best way to convert SVGs to PNGs on the toolserver?
Ryan Kaldari kald...@gmail.com wrote: I tried shell_exec() and exec() instead of system() and it gives the same resullt - a zero byte file with no error. Any idea why it would work from the command line but not from PHP? Are you sure there is no error? STDERR is usually discarded by shell_exec () and similar functions. Try redirecting it to STDOUT with rsvg some thing 21. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] Reminder: move your projects off stable -Geohack
Magnus Manske magnusman...@googlemail.com wrote: perhaps this would be a good moment to transfer Geohack to a regular mediawiki-extension on the main servers. I hear this was also the plan of brion vibber before he go. Who we need to ask now for this? I asked Brion on the Paris meeting and he said he'd have a look. But, I didn't hear anything back, so I assume he didn't. wikimedia.org doesn't list an official CTO, so for the time being, I guess Tim Starling is the person to ask. Last time I had a long look at the code, the extension part seemed to be in good condition. One half is using it as a special page (just a wrapper around the current code calls), and getting the wiki template from the cache instead of the http rendering. Compatability might have deteriorated since then, though. [...] I had a look at the code one or two years ago, and started a small DWIM-and-nothing-more extension Mapsources along the lines of Booksources that called a template with the co- ordinates as parameters so that you could use all of Media- Wiki's parser functions Co. in it. The idea would have been to extend it eventually to have the list of map sources ordered by the region of the individual coordinate and by user preference (Swiss coordinates: Swisstopo, British coor- dinates: Ordnance Survey, etc.) with a timeout so that if you don't react within x seconds the first map source is chosen. But #1, then I stumbled upon a post of yours where you pointed out that Special:TemplateLink would be much more suitable to replace the whole Geohack shebang, and I think you were right. But #2, with all the work going on with OSM and the Maps extension, wouldn't it be wiser to integrate Geohack's func- tionality with the later? Tim (f'uping to wikitech-l) ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] problem downloading http://toolserver.org/~kolossos/templatetiger data
Fuz Kabir fuzka...@yahoo.com wrote: I have been using wikipedia toolserver for a week. I'm collect data for research from http://toolserver.org/~kolossos/templatetiger/template-choice.php?lang=enwiki but when I want to download a template for my database it limits 2500 records at a time from a single category. This makes some troubles like, missing columns in separated downloads, character set problem(missing other language characters)... So how can I have the full data of any single template in a file which will be compatible with my mysql? I am not involved any wiki project so that i can access the phpmyadmin.( I wonder, what is inside there- template data or Wikipedia dumps ?), I prefer template rather dumps(pages, revisions) Believe me I download for my research not to business... Suggest me the best. File a request according to URI:https://wiki.toolserver.org/view/Query_service with the SQL query at the top of Templatetiger's page minus the LIMIT clause and ask for it to be run on u_kolossos_p. Tim ___ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Re: [Toolserver-l] unscheduled outage
River Tarnell ri...@loreley.flyingparchment.org.uk wrote: there was an unscheduled outage at ~17:20 UTC for around 15 minutes, caused by a kernel panic on the NFS server (hyacinth). the cause is currently unknown. Sun has identified the cause of the panic as a faulty DIMM. we will replace the failed part once a replacement has been received, which will mean a short period of additional downtime later. Just curious: Can you disable the fauly DIMM on the server for that time, or is it keep-your-fingers-crossed? Tim ___ Toolserver-l mailing list Toolserver-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/toolserver-l
Re: [Toolserver-l] Blog: Comment does not show up
River Tarnell [EMAIL PROTECTED] wrote: when I go to URI:https://journal.toolserver.org/toolserver/entry/on_tools_and_memory_use, fill out the form, answer the simple math question and ei- ther press Preview or Post, I get again to URI:https://journal.toolserver.org/toolserver/entry/on_tools_and_memory_use with no changes whatsoever (no comment to preview or post- ed). this should be fixed now. It is, thanks! Tim ___ Toolserver-l mailing list Toolserver-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/toolserver-l
[Toolserver-l] Blog: Comment does not show up
Hi, when I go to URI:https://journal.toolserver.org/toolserver/entry/on_tools_and_memory_use, fill out the form, answer the simple math question and ei- ther press Preview or Post, I get again to URI:https://journal.toolserver.org/toolserver/entry/on_tools_and_memory_use with no changes whatsoever (no comment to preview or post- ed). I tried with Konqueror as well as with Firefox. Has some configuration changed? After all, I had managed to post a comment yesterday. TIA, Tim ___ Toolserver-l mailing list Toolserver-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/toolserver-l
