Re: [Toolserver-l] [Labs-l] DEPRECATED: tools.wikimedia.de -> Get rid of it!
On 11 May 2014, at 20:03, Platonides wrote: > Merlijn van Deen wrote: >> On 11 May 2014 13:55, Silke Meyer > <mailto:silke.me...@wikimedia.de>> wrote: >> >>It is not a trivial redirect: Wikimedia Deutschland will obviously not >>give the wildcard SSL certificate for *.wikimedia.de >><http://wikimedia.de> to WMF (and WMF >>would not want to have it). This would mean we would have to >>completely delegate that subdomain to WMF and guarantee that it stays >>like that forever. This is hard to guarantee and it is also misleading >>to delegate a .de subdomain to the Foundation. >> >> >> First of all: Why would the (sub)domain need to be delegated to the WMF? >> The redirect could just be on WMDE servers. >> >> If the redirect *has* to be on Foundation servers for some reason, it >> could just use a specific tools.wikimedia.de <http://tools.wikimedia.de> >> certificat -- or we could just kill SSL altogether -- the >> tools.wikimedia.de <http://tools.wikimedia.de> domain is from before the >> toolserver even had SSL support. > > +1 > > I think you are viewing things more complex than they really are, Silke. > Indeed. Assuming WMDE isn't planning on not having any web servers, their existing web server for wikimedia.de can keep redirecting tools.wikimedia.de to toolserver.org. No changes necessary. If WMDE really wants to remove them, they could point that subdomain to WMF servers and have WMF do the redirect and simply don't provide an SSL certificate. E.g. WMF would use a self-signed certificate or an invalid one like the one for wikipedia.org, WMF does this all the time for old or unused domains: wikipedia.com * https://www.wikipedia.com/ wikimediacommons.org * https://wikimediacommons.org/ And if we really really want, one could purchase a separate certificate for just tools.wikimedia.org (so that the wildcard one isn't needed) and transfer only that to WMF. — Krinkle ___ 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] Cron <@hawthorn> failures
For the past 2 days I've been flooded with e-mails like these: Begin forwarded message: > From: r...@hawthorn.toolserver.org (Cron Daemon) > Subject: Cron qcronsub -l h_rt=0:35:00 -l arch=* -l > virtual_free=100M -j y -o $HOME/job-cd.out -N cd $HOME/bin/start-cd > Date: 13 november 2013 19:36:10 CET > To: delin...@hawthorn.toolserver.org > > /sge/GE/bin/sol-amd64/qcronsub: fork: Not enough space Begin forwarded message: > From: r...@hawthorn.toolserver.org (Cron Daemon) > Subject: Cron qcronsub -l h_rt=0:35:00 -l arch=* -l > virtual_free=100M -j y -o $HOME/job-cd.out -N cd $HOME/bin/start-cd > Date: 13 november 2013 19:27:06 CET > To: delin...@hawthorn.toolserver.org > > ld.so.1: bash: fatal: /lib/libc.so.1: mmap failed: Resource temporarily > unavailable > ld.so.1: bash: fatal: mmap anon failed: Resource temporarily unavailable > ld.so.1: bash: fatal: /usr/lib/libc.so.1: mmap failed: Resource temporarily > unavailable > ld.so.1: bash: fatal: libc.so.1: open failed: No such file or directory > Killed ___ 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] Cronie jobs down on submit.toolserver.org?
Hi, The cronie line at krin...@submit.toolserver.org for KrinkleBot[1]: 3,18,33,48 * * * * python $HOME/externals/pywikipedia/fileprotectionsync_live.py > $HOME/bots/py_fileprotectionsync_live.log 2>&1 .. has not run for over 27 hours. I just ran it manually once[1], which made 4 edits. Are there known problems with it? -- Krinkle [1] https://commons.wikimedia.org/wiki/Special:Contributions/KrinkleBot___ 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] Both webservers down
I'm still getting "Bad Gateway" and time outs like every other request (on both http and https, https seems to fail more often). -- Krinkle On Jun 30, 2013, at 11:11 PM, Marlen Caemmerer wrote: > Hey, > > Some days before the old file server hemlock got a replacement of the SAN > card and we thought now we could move the file service back. > Unfortunatelly both connections on the new SAN card failed at the same time > like with the old controller. > This is strange. > > User-store failed twice today. > Now the user-store is back on the workaround server (which is a DB server...) > > Cheers > Marlen/nosy > > ___ > 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 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] Both webservers down
Still down or down again? Getting 502 Bad Gateway and/or timeout on all of these: * http://toolserver.org/~intuition/ * http://wolfsbane.toolserver.org/~intuition/ * http://ortelius.toolserver.org/~intuition/ * https://toolserver.org/~intuition/ -- Krinkle On Jun 30, 2013, at 5:25 AM, Maarten Dammers wrote: > And back up thanks to nosy: > > [14:09:47] hello > [14:09:53] web service should be back > [14:10:03] seems nfs for the user-store died > > Thanks for the quick service :-) > > Maarten > > Op 30-6-2013 13:30, Maarten Dammers schreef: >> Hi, >> >> Both the webservers Ortelius and Wolfsbane are not serving http at the >> moment. Both servers seem to have died exactly at the same time (1 hour ago >> according to Nagios). Can someone have a look at this? >> >> Thank you, >> >> Maarten >> >> >> ___ >> 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 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 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] Web server issues (was: Failed Maintenance)
Most urls either time out or report 404. This is still happening. HTTPS seems to be slightly more reliable, but only slightly. I'm getting 404 on both HTTP and HTTPS. A few sample urls (often return 404 error): - http://toolserver.org/~krinkle - https://toolserver.org/~krinkle Do work: - http://wolfsbane.toolserver.org/~krinkle/ - http://ortelius.toolserver.org/~krinkle/ So, if wolfsbane and ortelius are both working fine, it is going wrong at the load balancer? Then why is HTTPS also showing the same problems, that one doesn't have a load balancer (afaik). -- Krinkle On Apr 13, 2013, at 2:36 PM, DeltaQuad Wikipedia wrote: > Would this be the cause for the 50/50 chance of getting 404s every > time you try to navigate to a page? (for https at least) and yes I did > try several different projects. > > DeltaQuad > English Wikipedia Administrator and Checkuser > > > On Sat, Apr 13, 2013 at 3:05 AM, Marlen Caemmerer > wrote: >> Hello, >> >> the maintenance worked so far. There are serveral small issues that still >> have to be resolved but the hosts all use the new IP space now. >> >> Cheers >>Marlen/nosy >> >> On Thu, 11 Apr 2013, Marlen Caemmerer wrote: >> >>> Date: Thu, 11 Apr 2013 12:23:28 >>> From: Marlen Caemmerer >>> Reply-To: Wikimedia Toolserver >>> To: Wikimedia Toolserver >>> Cc: toolserver-annou...@lists.wikimedia.org >>> Subject: Re: [Toolserver-l] Failed Maintenance - was - Re: IP Renumbering >>> of >>>the complete Toolserver cluster >>> >>> >>> Hello, >>> >>> I want to do the maintenance of damiana, turnera, ortelius and wolfsbane >>> starting >>> >>> tomorrow, 1800 UTC. >>> >>> I hope to finish until 2200 UTC but I cant tell exactly so I have to leave >>> the end open. >>> >>> Cheers >>>Marlen/nosy >>> >>> ___ >>> 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 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 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 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 down?
On Apr 12, 2013, at 9:44 PM, Magnus Manske wrote: > Can't get http connection, and ssh says: > > ssh: Could not resolve hostname login.toolserver.org: nodename nor servname > provided, or not known > As announced: Begin forwarded message: > From: Marlen Caemmerer > Subject: Re: [Toolserver-announce] [Toolserver-l] Failed Maintenance - was - > Re: IP Renumbering of the complete Toolserver cluster > Date: April 11, 2013 12:23:28 PM GMT+02:00 > To: Toolserver Announcements > > Hello, > > I want to do the maintenance of damiana, turnera, ortelius and wolfsbane > starting > > tomorrow, 1800 UTC. > > I hope to finish until 2200 UTC but I cant tell exactly so I have to leave > the end open. > > Cheers > Marlen/nosy > ___ 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] Cron errors at hawthorn for qcronsub
I get a bunch of these every few weeks. Got them again today/yesterday. What's up? -- Krinkle Begin forwarded message: > From: r...@toolserver.org (Cron Daemon) > Subject: Cron qcronsub -N dbbot_wm -m n -j y -b y -l > arch='*' -l h_rt=INFINITY -l virtual_free=90M "$HOME/bots/dbbot-wm-start.sh" > Date: February 15, 2013 8:55:08 AM GMT+01:00 > To: krin...@toolserver.org > > error: JSV stderr: Traceback (most recent call last): > error: JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > > error: JSV stderr: dom = minidom.parse(child_stdout) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", > line 1915, in parse > error: JSV stderr: return expatbuilder.parse(file) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 930, in parse > error: JSV stderr: result = builder.parseFile(file) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 207, in parseFile > error: JSV stderr: parser.Parse(buffer, 0) > error: JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column > 0 > Unable to run job: JSV stderr: Traceback (most recent call last): > JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > JSV stderr: dom = minidom.parse(child_stdout) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", > line 1915, in parse > JSV stderr: return expatbuilder.parse(file) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 930, in parse > JSV stderr: result = builder.parseFile(file) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 207, in parseFile > JSV stderr: parser.Parse(buffer, 0) > JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column 0 > JSV stderr is - xml.parsers.expat.ExpatError: syntax error: line 1, column 0. > Exiting. Begin forwarded message: > From: r...@toolserver.org (Cron Daemon) > Subject: Cron qcronsub -N dbbot_wm -m n -j y -b y -l > arch='*' -l h_rt=INFINITY -l virtual_free=90M "$HOME/bots/dbbot-wm-start.sh" > Date: February 15, 2013 1:45:09 AM GMT+01:00 > To: krin...@toolserver.org > > error: JSV stderr: Traceback (most recent call last): > error: JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > > error: JSV stderr: dom = minidom.parse(child_stdout) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", > line 1915, in parse > error: JSV stderr: return expatbuilder.parse(file) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 930, in parse > error: JSV stderr: result = builder.parseFile(file) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 207, in parseFile > error: JSV stderr: parser.Parse(buffer, 0) > error: JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column > 0 > Unable to run job: JSV stderr: Traceback (most recent call last): > JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > JSV stderr: dom = minidom.parse(child_stdout) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", > line 1915, in parse > JSV stderr: return expatbuilder.parse(file) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 930, in parse > JSV stderr: result = builder.parseFile(file) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 207, in parseFile > JSV stderr: parser.Parse(buffer, 0) > JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column 0 > JSV stderr is - xml.parsers.expat.ExpatError: syntax error: line 1, column 0. > Exiting. Begin forwarded message: > From: r...@toolserver.org (Cron Daemon) > Subject: Cron qcronsub -N dbbot_wm -m n -j y -b y -l > arch='*' -l h_rt=INFINITY -l virtual_free=90M "$HOME/bots/dbbot-wm-start.sh" > Date: February 14, 2013 8:30:06 PM GMT+01:00 > To: krin...@toolserver.org > > error: JSV stderr: Traceback (most recent call last): > error: JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > > error: JSV stderr: dom = minidom.parse(child_stdout) > err
Re: [Toolserver-l] JIRA session loss
On Dec 16, 2012, at 9:28 PM, Hersfold wrote: > > On 12/16/2012 3:25 PM, Matthew Bowker wrote: >> I'm quite a big fan of Mantis [1] [2]. (We don't need the mobile stuff. >> The bug tracker itself is FOSS, web-based with PHP and SQL) >> >> It also supports LDAP [3]. >> >> [1] http://mantisbt.org/ >> [2] http://www.mantisbt.org/manual/ >> [3] http://www.mantisbt.org/manual/manual.customizing.mantis.ldap.php >> >> > > We use Mantis at my workplace; it works fairly well. > Though Mantis (the default theme at least) does look and feel very 1997-style and may be too complicated, confusing and ugly for most users: http://mantisbt.org/demo/my_view_page.php http://mantisbt.org/demo/view_all_bug_page.php http://mantisbt.org/demo/view.php?id=15448 -- Krinkle ___ 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] Anyone else having TS trouble?
On Nov 25, 2012, at 5:06 PM, Platonides wrote: > On 25/11/12 16:42, Magnus Manske wrote: >> Started a few minutes ago. getting alternating errors on reloading a >> page; 500 (on a static HTML page, not CGI, mind you!), "This webpage is >> not available: The connection to toolserver.org <http://toolserver.org> >> was interrupted.", 404. > > The same thing happpened here. > The servers didn't allow logins, and accessing the web pages return > 404s. Apparently ldap was down. > It recovered now. I don't know if it there was a human involved, if it > solved itself or if it was turnera taking over damiana automatically. > Seems fine here: https://toolserver.org/~krinkle/mwSnapshots/#!/mediawiki-core/master Maybe HTTP or Geo related? Is anyone still having this problem? -- Krinkle ___ 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] JIRA session loss
Hi, I'm trying go through some issues on JIRA and it keeps logging me out every few minutes. 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). -- Krinkle ___ 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] Future of the toolserver
On Sep 30, 2012, at 2:21 PM, Platonides wrote: > On 30/09/12 03:31, Krinkle wrote: >> On Sep 29, 2012, at 9:41 PM, Samuel Klein wrote: >>> And why is the WMF considering not providing db replication for it? >> >> [citation needed] >> >> I think you misunderstood. >> >> -- Krinkle > > Written by Erik Moeller the 25th Sep: >> Chapters are autonomous organizations, and it's WM-DE's call how much >> / whether it wants to continue to invest in infrastructure of any kind >> (and the decision of funding bodies like the FDC to accept or reject >> that proposition). However, for our part, we will not continue to >> support the current arrangement (DB replication, hosting in our >> data-center, etc.) indefinitely. > > He is writing with his "WMF hat", the above 'we' refers to the WMF. So no, > there's no misunderstanding: The WMF has threaten to stop providing the db > replication. > That would be a really bad move to do, of course (and a gratuitous one, > since there aren't technical or financial reasons for doing that). And I > hope they won't do that. > > - http://lists.wikimedia.org/pipermail/toolserver-l/2012-September/005294.html > Ah, I understand the confusion now. If I understand correctly Samuel was talking about the (future) labs environment, not the Toolserver. The above citation from Erik, however, is about the Toolserver (not Labs). Erik is saying here that WMF will (at some unspecified point in the future) stop providing the services it is currently providing for Toolserver (such as the space in their datacenter and arranging db replication). It does not mean they will (or are considering to) stop providing db replication in general (just not to Toolserver). Maybe Samuel already knew that and he was talking about Toolserver as well, in that case: never mind, sorry about the confusion. I just wanted to make sure you know that there are confirmed and scheduled plans for Wikimedia Labs to have a live db replication arranged between the labs cluster and the wmf production cluster. As far as I know there are no considerations to not provide this, quite the contrary. -- Krinkle ___ 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] Future of the toolserver
On Sep 29, 2012, at 9:41 PM, Samuel Klein wrote: > And why is the WMF considering not providing db replication for it? > [citation needed] I think you misunderstood. -- Krinkle ___ 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] Future of the toolserver
On Sep 25, 2012, at 11:12 PM, "DaB." wrote: > Hello Erik, > At Tuesday 25 September 2012 22:24:33 DaB. wrote: >> >> The initial focus for Labs has been to provide functionality that >> toolserver doesn't - get root on a VM or set of VMs to install/test >> arbitrary software/services, and get it ready for production >> deployment. >> > > It is nice to have root on a (virtual) machine, but I doubt most tools need it > [..] > Indeed, however the reason this is crucial for labs is because its scope is much wider than Toolserver. For example, in the "deployment" project we simulate nearly the entire WMF production cluster (including db hosts, apaches, squids, varnish, scalers, etc.). This makes one of the very different goals of Labs possible, namely to allow volunteers to contribute to operations (as opposed to the software we run). Once everything is puppetized one can basically create a new labs project, use "wmf-production" as template and instantiate a complete wmf cluster (not with all the database contents, just the server setup, though it'd contain sufficient sample data, the purpose is to simulate the servers to develop new configurations, not use as web site). Give it a subdomain and you'd immediately have stuff like commons.wikimedia.myproject.wmflabs.org. Back to the subject, does that mean users will have to learn to manage a VM and require a public IP and subdomain? No, not at all. We're confusing Dev Labs with Tool Labs (perhaps we shouldn't name them like that as isolated projects). Implementation of Tool Labs isn't decided on afaik, but I believe it will naturally solve itself by being distributed among various projects. Behind the scenes they will likely be a regular labs project, but abstracted for users (e.g. not an instance-group or even an instance per tool, but all in one instance-group, with a group of servers for different purposes, like Toolserver has web servers, sql servers, login/application servers). E.g. the tools project in wmflabs would have various web servers and application servers[1]. Users wanting to run queries, bots and long-running/periodic processes would use the application servers. Ideally we'd encourage use of SGE (or something alike) from the beginning so that the application servers are optimally used, and it would make it easy to start a process in the background of an application server from a process on the web server Access to the wmf wiki replicated dbs is public across the entire wmflabs network so that's a given within the toollabs project as well. -- Krinkle [1] The "bots" project exists already. It doesn't have SGE yet but it's a first step. There is also a generic "webtools" project being set up as we speak. Perhaps these two could be merged so that users have shared project storage for bots generating data to be used by bots and vice-versa. ___ 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] qcronsub warning: "Please add maximum runtime"
On Sep 24, 2012, at 6:20 PM, Platonides wrote: > On 24/09/12 18:07, Krinkle wrote: >> Can someone decode this? What is this? >> >> -- Krinkle >> >> >> Begin forwarded message: >> >>> *From: *r...@toolserver.org <mailto:r...@toolserver.org> (Cron Daemon) >>> *Subject: **Cron qcronsub -N dbbot_wm -m n -j y -b >>> y -l h_rt=INFINITY -l virtual_free=90M "$HOME/bots/dbbot-wm-start.sh"* >>> *Date: *September 24, 2012 6:05:07 PM GMT+02:00 >>> *To: *krin...@toolserver.org <mailto:krin...@toolserver.org> >>> >>> warning: Please add maximum runtime by adding parameter [33m-l >>> arch=[0msol|lx > > The text asks you to place a time limit. The parameter (embedded in > posix colors despite not being output to a terminal) to specify if it > needs a linux or solaris server. > > However, if I try to execute it, I get a much saner message: > $ qcronsub -N dbbot_wm -m n -j y -b y -l h_rt=INFINITY -l > virtual_free=90M "/home/krinkle/bots/dbbot-wm-start.sh" >> Unable to run job: Script not executable: >> /home/krinkle/bots/dbbot-wm-start.sh. >> Exiting. >> warning: Please add the os this job can run on by adding parameter -l >> arch='*'|sol|lx >> For more information read documentation at >> https://wiki.toolserver.org/view/Job_scheduling > > As this is a php script, your parameter would be «-l arch='*'» > Yes, I've added `-l arch='*'` to it already a minute ago. Warnings are gone, not sure why it nagged about maximum runtime, it already has INFINITY. I'm not sure why arch=x isn't the default though, or maybe it is but outputs the warning anyway? A warning like that may be useful, but do consider that cronie from submit will send e-mails for it. -- Krinkle ___ 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] qcronsub warning: "Please add maximum runtime"
Can someone decode this? What is this? -- Krinkle Begin forwarded message: > From: r...@toolserver.org (Cron Daemon) > Subject: Cron qcronsub -N dbbot_wm -m n -j y -b y -l > h_rt=INFINITY -l virtual_free=90M "$HOME/bots/dbbot-wm-start.sh" > Date: September 24, 2012 6:05:07 PM GMT+02:00 > To: krin...@toolserver.org > > warning: Please add maximum runtime by adding parameter [33m-l > arch=[0msol|lx ___ 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] Web servers unresponsive
Hi, Since about an hour the web servers appear to be unresponsive: * http://ortelius.toolserver.org/~cvn/index.html * http://wolfsbane.toolserver.org/~cvn/index.html * https://toolserver.org/~cvn/index.html All error out on with no response and a time out. I can still SSH into wolfsbane and ortelius from willow, though. -- Krinkle ___ 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
On Sep 17, 2012, at 6:59 PM, Jeremy Baron wrote: > Hi, > > On Tue, Sep 4, 2012 at 9:01 PM, Marlen Caemmerer > wrote: >> we have an issue with Jira authentication since 25th August. >> It seems the synchronization with the crowd server is broken but I don't know >> why and filed a bug at Atlassian. > > 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? > > Thanks, > Jeremy 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. -- Krinkle ___ 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] http://status.toolserver.org/ Down
Mirror as well: http://toolserver.org/tsstatus/ Though mirror over HTTPS appears to work: https://toolserver.org/tsstatus/ -- Krinkle On Aug 11, 2012, at 2:18 PM, John wrote: > It looks like http://status.toolserver.org/ is down > ___ > 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 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] JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest"
So I've set "-m n" for now on the qcronsub entry, but it turns out (obviously) that this doesn't help. The error report doesn't come from SGE, qcronsub or cronie/cronietab. The error is from the low-level cron itself because the SGE executable is somehow broken. I don't want to disable e-mails for all cron globally since they're quite useful and should be seldom. When they're sent it usually means a syntax error (which is easily catched and useful to know)- or it's because stuff is broken on a lower-level on the Toolserver - say SGE itself - which is happening right now On Aug 1, 2012, at 11:42 PM, Krinkle wrote: > Hi, > > Please fix this (or at least turn it off so that it doesn't emit more emails). > > Assuming there is a way to turn off e-mail notifications for stuff like this > from submit.toolserver.org, > perhaps someone could include that in the recommended "example" cronietab > snippet? > > Use case being the many people running things on the Toolserver that should > be "always running". And the way the documentation recommends this is done is > by using a named SGE job, and attempt to start it every minute from cronietab > on submit.toolserver.org. > > When it is already running, qsub will do nothing. Otherwise it starts it. The > thing is, however. that if SGE has issues it emits an e-mail with the stack > trace - *every minute* (even if the job in question is already running fine). > > I'd like to know when my bot is down and can't be started (so I can start it > manually). But I only need 1 e-mail for that. And definitely not an e-mail > every time SGE has an issue and then get a mail every minute - regardless if > whether the job in question is already running without problems. > > Estimated time when the error started: 150 minutes ago > > -- Krinkle > > Begin forwarded message: > >> From: r...@toolserver.org (Cron Daemon) >> Subject: Cron qcronsub -b y -N dbbot_wm -l h_rt=INFINITY >> -l virtual_free=90M $HOME/bots/dbbot-wm-start.sh >> Date: August 1, 2012 11:32:03 PM PDT >> To: krin...@toolserver.org >> >> error: JSV stderr: Traceback (most recent call last): >> error: JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in >> >> error: JSV stderr: dom = minidom.parse(child_stdout) >> error: JSV stderr: File >> "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", >> line 1915, in parse >> error: JSV stderr: return expatbuilder.parse(file) >> error: JSV stderr: File >> "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", >> line 930, in parse >> error: JSV stderr: result = builder.parseFile(file) >> error: JSV stderr: File >> "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", >> line 207, in parseFile >> error: JSV stderr: parser.Parse(buffer, 0) >> error: JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, >> column 0 >> Unable to run job: JSV stderr: Traceback (most recent call last): >> JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in >> JSV stderr: dom = minidom.parse(child_stdout) >> JSV stderr: File >> "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", >> line 1915, in parse >> JSV stderr: return expatbuilder.parse(file) >> JSV stderr: File >> "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", >> line 930, in parse >> JSV stderr: result = builder.parseFile(file) >> JSV stderr: File >> "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", >> line 207, in parseFile >> JSV stderr: parser.Parse(buffer, 0) >> JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column 0 >> JSV stderr is - xml.parsers.expat.ExpatError: syntax error: line 1, column 0. >> Exiting. > ___ 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] JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest"
Hi, Please fix this (or at least turn it off so that it doesn't emit more emails). Assuming there is a way to turn off e-mail notifications for stuff like this from submit.toolserver.org, perhaps someone could include that in the recommended "example" cronietab snippet? Use case being the many people running things on the Toolserver that should be "always running". And the way the documentation recommends this is done is by using a named SGE job, and attempt to start it every minute from cronietab on submit.toolserver.org. When it is already running, qsub will do nothing. Otherwise it starts it. The thing is, however. that if SGE has issues it emits an e-mail with the stack trace - *every minute* (even if the job in question is already running fine). I'd like to know when my bot is down and can't be started (so I can start it manually). But I only need 1 e-mail for that. And definitely not an e-mail every time SGE has an issue and then get a mail every minute - regardless if whether the job in question is already running without problems. Estimated time when the error started: 150 minutes ago -- Krinkle Begin forwarded message: > From: r...@toolserver.org (Cron Daemon) > Subject: Cron qcronsub -b y -N dbbot_wm -l h_rt=INFINITY > -l virtual_free=90M $HOME/bots/dbbot-wm-start.sh > Date: August 1, 2012 11:32:03 PM PDT > To: krin...@toolserver.org > > error: JSV stderr: Traceback (most recent call last): > error: JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > > error: JSV stderr: dom = minidom.parse(child_stdout) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", > line 1915, in parse > error: JSV stderr: return expatbuilder.parse(file) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 930, in parse > error: JSV stderr: result = builder.parseFile(file) > error: JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 207, in parseFile > error: JSV stderr: parser.Parse(buffer, 0) > error: JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column > 0 > Unable to run job: JSV stderr: Traceback (most recent call last): > JSV stderr: File "/sge/GE/bin/sol-amd64/qjobtest", line 108, in > JSV stderr: dom = minidom.parse(child_stdout) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/minidom.py", > line 1915, in parse > JSV stderr: return expatbuilder.parse(file) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 930, in parse > JSV stderr: result = builder.parseFile(file) > JSV stderr: File > "/opt/ts/python/2.7/lib/python2.7/site-packages/_xmlplus/dom/expatbuilder.py", > line 207, in parseFile > JSV stderr: parser.Parse(buffer, 0) > JSV stderr: xml.parsers.expat.ExpatError: syntax error: line 1, column 0 > JSV stderr is - xml.parsers.expat.ExpatError: syntax error: line 1, column 0. > Exiting. ___ 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] Dude, where is my logfile?
On Jun 23, 2012, at 8:41 AM, Toto Azéro wrote: > Le 23 juin 2012 à 03:41, Hazard-SJ a écrit : > >> As for the quota -v query, I tested it shortly after my Toolserver account >> has been created, and up to now, it is the same thing: exactly as Krinkle >> had stated it below, so this is no "new" problem, though it needs to be >> fixed. > Right but actually quota -v seems to work fine for users (at least works fine > for me) but not for MMPs (I tested it on interwikibot). > So I though quotas were only activated for *users* but it looks like not > according to Krinkle's problems... > > Regards, > Toto Azéro For my personal account the quota command is working as expected. In the mean time I've discovered that /mnt/user-store is a lot easier to use then I thought. Yesterday I moved almost all of the 3.2 GB over there and fixed paths to restore immediate service. In the meantime I've cleaned everything up and I'm down to ~400M in the /home's of my account and the MMPs. and the /mnt/user-store about ~ 1-2 GB. Thanks :) -- Krinkle ___ 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] Dude, where is my logfile?
On Jun 22, 2012, at 1:06 PM, Marlen Caemmerer wrote: > Hello, > > > sorry, I am afraid I was a bit fast with a counter measure but I set a quota > for everyone now. If the user has more it is still no problem but he wont be > able to create new files. Please let me know if this is a show stopper for > your account and I will handle this asap if your reason is sensible. > > Cheers > nosy > This is insane in my opinion. There sure is a better reason to cause service disription for lots of hardworking volunteers in a way that there is almost no way to find out whats going on. Toolserver users genrally don't work on their tools every day. I just got home and after getting stuff running I hear reports that people can't log into my php tools. The fact that I have time to look into this right away is probably an exception compared to the average ts-user. Two of the MMPs I maintain are broken, and several irc bots are down. I see: * No automatic e-mails or anything * Nothing in php errors * No mysql errors (since the error report I got mentinoed that users couldn't log into the tool) * No obvious thread on toolserver-l (lots of noise there anyway, maybe we need a separate toolserver-announce-l for stuff that actually matters that likely need users to do something?) Now, in the mean time I think I know what caused it. But just so you know, here is a short summary of how I've spend the last 3 hours trying to figure out what the hell is going on. And hopefully will encourage ts-admins to act more carefully or at least better communicate. One of the MMPs is CVN. The IRC bots timed out earlier today and those that I granted access to start them from a web control panel couldn't log in. Turns out that the PHP sessions were the issue. For some reason whenever the session was modified, it was emptied and the user was as if there is no active session. Whenever a new session is created, it appears to work fine, until you look up the data in the next request and find it is gone. After having checked status.toolserver.org and looking up mysql errors, php errors and then ssh-ing into my account and trying to access the database directly, it turns out everything looks fine. I opened TS-1422[1], and worked on a test case to reproduce it in a plain .php file. Tried to upload it to /home/krinkle/public_html/tmp and everything seems to have gone fine. No errors or anything out of the ordinary. Then when I try to access that file from the web, I get a blank 200 OK reponse. Looking it up in SSH shows me it is chmod 000 and size 0 bytes. So I opened up TS-1423[2]. Then I'm reading up on toolserver-l and see that the quotas are finally going to enforced. I welcome that. DaB tells us we have the weekend to make sure we are either under the quota or have requested a bigger quota. This sounds reasonable to me. I did not connect the problems I was hearing about from all over with the quota that was going to come after the weekend. The reason being that I did not get any emails regarding limits being reached on /home/krinkle (or the home of the MMPs) or any errors when trying to write to a file. e.g. $ echo "Hello World" > test.txt .. works fine without errors. But looking it up shows it is size 0 bytes. If this is indeed being done by the quota system, then I'd recommend getting a better quota system or configuring it differenly. Allowing empty files to be created is one thing. Silently ignoring non-empty write attempts and turning them into empty files without any form of response is quite another. Obviously I'd rather have no file at all, then a broken file without any indication that it is broken. Also, $ quota -v; gives me this rather useless response: cvn@willow:~$ quota -v cvn; Disk quotas for cvn (uid 8153): Filesystem usage quota limit timeleft files quota limit timeleft Looks like something is missing there? Connect that to DaB's mail, and I'd say this means the quota will come, but is not yet started/activated. So I spend another hour trying to find out the "real" cause (which, obviously, I didn't find since it is indeed caused by the quota). And tried to temporarily disabled a few things only to find out that the files I modified are gone: For example: * /home/krinkle/public_html/wikimedia-svn-search/header.php - 0 bytes * /home/krinkle/public_html/tmp/session-test.php - 0 bytes And then I see your message that (albeit it not appearing so) the quota has indeed been enabled for everyone now. Why? Now I can't even try to clean up, because I can't even edit a big file and replace it with "Temporarily disabled". I can't remove 100MB to add a small .ini file. I can't comment out things that are breaking stuff. My account is completely locked and anything I try to touch is immediately wiped. Error/warnings are absent. On IRC it was p
Re: [Toolserver-l] [Wikitech-l] Bugzilla database replication
On Jun 7, 2012, at 4:15 PM, John wrote: > https://bugzilla.wikimedia.org/show_bug.cgi?id=28339 has been just sitting > their stale for quite a while. I know as a toolserver user, that there is a > potential for a lot of useful tools. Who do I need to bribe or murder in > order to facilitate this process? > > John > This is not as easy as setting up replication for other databases, because it is set up differently and there are special privacy matters to think of. Meanwhile, may I remind that BugZilla actually does have an API, which is also accessible from the Toolserver. It is a little complicated to use, but provides a lot of features. -- Krinkle ___ 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] Replication of beta.wmflabs.org?
On Jun 5, 2012, at 10:30 PM, Platonides wrote: > On 05/06/12 22:16, Danny B. wrote: >> Would it be possible to replicate labs? >> >> Danny B. > > What do you want to replicate? > There's nothing worth to be replicated there. It would be better for > labs to replicate toolserver dbs! After some quick poking on IRC we figured the request wasn't misunderstood, so it this double negative shoulidn't be confusing ;-) The use case Danny brought up was the ability for a tool like "sulitil" to query a copy of the "beta" project (hosted on WMF Labs - renamed thread as such) and display that information for a centralauth account for a user on Beta. I don't think that that will happen. For a few reasons. First, because the Beta project is a testing environment. There is no need to have convinience tools for maintenance, quering or whatever there. Anything stored on pages there is to be considered temporary. If you've been investing a lot of time in any pages in the Beta project (no exceptions), I'd highly recommend you save it somewhere else. If it needs be, those wikis can be wiped and re-installed any moment, and they are designed to be that way. Secondly, if doing so the Toolserver might wheel-war with the (to be created) Tool-Labs project within Wikimedia Labs. Aside from the potential size issue since the Beta project can potentially become almost as large as the production cluster. So replicating that on Toolserver as well seems like a bad idea. -- Krinkle ___ 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] Rename "MMP"
On May 23, 2012, at 9:25 PM, Ilmari Karonen wrote: > On Wed, 2012-05-23 at 20:58 +0200, Danny B. wrote: >> I advocate for "Shared" (or something even better, if we'll find), since >> "Public" are most of tools that are on Toolserver... > > My point in suggesting "public" and "private" was to emphasize that the > latter kind (which, indeed, currently make up the overwhelming majority, > even if we'd like that to change) really do reside on the owner's > private account, are maintained only by the owner and only survive as > long as the owner keeps maintaining them [..] > Do note, however, that: * since a while now every account is required to set a default license for scripts in their home directory * in most cases (always?) ts-users can read files in other user's public_html directory. And some users open up "read" for the root of their home dir as well (I do), of course invidual files that are sensitive can (and should) be chmod'ed differently. -- Krinkle ___ 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] Rename MMPs to "public tools" [was: Toolserver user phe account expired]
On Wed, May 23, 2012 at 6:09 PM, Ilmari Karonen wrote: > On Tue, 2012-05-22 at 11:22 +0200, Merlijn van Deen wrote: > > - easier creation of mmp's? I can imaging people don't move their > > tools because it takes time to organise everything. > > I hereby propose that we retire the term "multi-maintainer project" or > "MMP", and just start calling them "public tools" (with an appropriate > qualifier where necessary, as in "public tool account"), as opposed to > "private tools" that run on users' personal accounts. I do realize that > these names are not perfectly descriptive, but IMO they're at least > better than what we have right now. > > > I agree with Ilmari. Except I don't see the problem with the word "project" and "Public Tool Account" is asking for more scary abbreviations. I'd recommend the name "Public projects" or "Shared projects" (instead of "Public tools"). Most accounts contain multiple tools. Since an MMP is just a shared account, it can perfectly contain multiple (related) scripts, or a framework, or collection of interconnected tools. "Creating a public tool" (where one would previously say "Creating a MMP") sounds a bit off to me. "Creating a public project" or "Creating a shared project" sounds more natural to me. Anyway, that's just terminology. I agree with Ilmari's reasoning. -- Krinkle ___ 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] Fairness on the toolserver
On May 14, 2012, at 11:31 PM, DaB. wrote: > Hello all, > > the resources on the TS are free, but limited; so we all have to use the > resources fair. Some limits (like memory-usage) are set and controlled by the > system, but others are not and it is in the responsibility of every single > user to make sure to not mis- or overuse resources. > So it is for example NOT a good idea to run 200 processes in parallel to get > more CPU-resources than you would normally get. And it is not a good idea to > use a amount of memory which is just below the slayer-daemon-limit without > any > purpose. > > Sincerely, > DaB. > > P.S: It is totally in the rules to disable a user-account because of resource- > misusing. > > -- > Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 Maybe we can handle this in a similar way we handle home directory storage. There is a default limit that should be fine for most users. It would only be reached if: * The user might accidentally run a proces that is taking more than he expected. The limit would kill the problem before it runs out of hand. * The user might be misbehaving. The limit is working against that. * The user might be hosting a tool that naturally takes more space. He requests the additional space and explains why he needs it. In most cases this will be granted without any problems. Sounds like a good policy for CPU/RAM as well. Although I suppose it isn't as easy to enforce. Although we can in SGE, right ? -- Krinkle ___ 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] Out of memory/segfaults?
Last week a few Mono-powered bots have been randomly crashing as well. Stacktrace started with: mmap(...PROT_NONE...) failed Which indicates out of memory, indeed. -- Krinkle ___ 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 having a bad day?
Over the past 12 hours I've also gotten a fair number of error reports by mail and on irc about some of my projects. A few samples: * pywikipedia script: > Your "cron" job on willow > python $HOME/SVN/pywikipedia/fileprotectionsync_live.py > > $HOME/bots/py_fileprotectionsync_live.log 2>&1 > > produced the following output: > > ld.so.1: sh: fatal: mmap anon failed: Resource temporarily unavailable > ld.so.1: sh: fatal: /usr/lib/libc.so.1: mmap failed: Resource temporarily > unavailable > ld.so.1: sh: fatal: libc.so.1: open failed: No such file or directory * custom php script for [[m:CVN]] > Your "cron" job on willow > php $HOME/CVN-backend/cronjob_cvnapi.php > > $HOME/CVN-backend/cronjob_cvnapi.log 2>&1 > > produced the following output: > > Killed * minutely start attempt for a long-running shell script in SGE > Your "cron" job on willow > cronsub -l -s dbbot_wm $HOME/bots/dbbot-wm-start.sh > > produced the following output: > > /opt/local/bin/cronsub[52]: 28142 Killed * minutely start attempt for a long-running shell script in SGE > Your "cron" job on willow > cronsub -l -s dbbot_wm $HOME/bots/dbbot-wm-start.sh > > produced the following output: > > critical error: malloc() failure * wmfCodeSearch exec > Your "cron" job on willow > php $HOME/wss_backend/runJobs.php > $HOME/logs/wmfCodeSearch/runJobs.log 2>&1 > > produced the following output: > > Segmentation Fault - core dumped etc.etc. Due to the diversity of the errors, I can't find any link between the various failures. I hope these help in determining/fixing the issue. -- Krinkle On Apr 22, 2012, at 6:51 AM, DeltaQuad wrote: > Ok, so i've checked status.toolserver.org and have found nothing going > on but some stuff has been breaking at random points today. > > I've had a Cron job return: > Subject: Cron cronsub IPBEBot $HOME/IPBE/IPBE.py > > /opt/local/bin/cronsub[44]: 9793 Killed > > > I've had another return: > Subject: Cron cronsub UAABot $HOME/UAA/UAA.py > > error: not enough memory to allocate 2404 bytes in init_packbuffer > Unable to run job: Error reading answer list from qmaster. > Exiting. > > And then on a MMP (yes this is a customized message): > > The x script has failed. The error message received was: > A database error occured when attempting to process your request: />Failed to connect to database server ! > Please check the database to resolve this issue and ensure that private data > is removed on schedule. > > > Is it what we have running or is this a toolserver issue in general? and > should I file a bug? > > (SysAdmins - Especially DaB. please don't take this as me being > critical, I just wanna help if I can identify any problems and file a > JIRA if needed ;) ) > > -- > DeltaQuad > English Wikipedia Administrator > > > ___ > 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 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
On Mon, Mar 12, 2012 at 5:54 PM, Soxred93 wrote: > If you are pushing for an MMP, it would be best not to use my code. It's > shoddy, poorly written, broken, and inefficient. Frankly, I'm amazed it > lasted as long as it did. > > -X! Well, it's been working so far. I'd recommend we do the following: * creating a few MMP projects that cover the tools people use most * make your home directory readable for group 'users' via chmod (except for sensitive files) * watch and see people copy your stuff into the SVN repo for the MMP projects and check them out into the MMP account, and see people open stuff in JIRA and get fixed in svn and pushed live :) -- Krinkle ___ 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
On Mon, Mar 12, 2012 at 4:59 PM, Merlijn van Deen wrote:
> On 12 March 2012 15:49, Hydriz Wikipedia wrote:
>
>> Tparis has the full source code of those tools, and looks like he has
>> already brought them up on his own account. See
>> https://toolserver.org/~tparis.
>>
>>
> Could we (in general) *please* not do this? If someones tools are
> important enough to be taken over by someone else, they are most certainly
> important enough for a multi-maintainer project. In {one month, one year,
> five years}, Tparis' account will also expire and we will have the same
> problem all over again.
>
> Best,
> Merlijn
>
I agree. There's also the issue of updating links all over the place. Where
an MMP would have permanent links, regardless of who maintains it.
___
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] What happened to user_properties_anonym?
Hey all, I used to periodically run some stats on preference usage (mostly skin-preferences and gadget usage), but it appears the custom "user_properties_anonym" table view Toolserver used to have no longer exists ? Testing here: https://toolserver.org/~krinkle/tmp/user_properties_anonym.php -- Krinkle ___ 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
On Sun, Jan 15, 2012 at 5:38 PM, DaB. wrote: > > So here is my plan to fix the problem on our (the TS) side: > +1 :) ___ 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] PHP error reporting?
On Sat, Dec 10, 2011 at 5:06 PM, Merlijn van Deen wrote:
> On 10 December 2011 03:27, Hersfold wrote:
>
>> And right after I sent this, someone showed me what to do:
>>
>> error_reporting(E_ALL);
>> ini_set('display_errors', 'On');
>>
>> You should use error_reporting(-1) if you want *all* errors (-1 always is
> the maximum reporting level). In older PHP versions, this is equal to
> E_ALL, but in newer ones it is equal to E_ALL | E_STRICT.
>
> And don't forget to switch the errors off again once you are done
> debugging :-)
>
> Merlijn
>
>
As of PHP 5.4.0 E_STRICT (new in 5.0.0) is part of E_ALL again.
- Krinkle
___
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] performance issues
On Wed, Oct 26, 2011 at 6:29 PM, Carl (CBM) wrote: > the following query of mine was killed after 1700 seconds: > > SELECT ns_id, ns_name FROM toolserver.namespacename where (ns_type = > 'canonical' or ns_type = 'primary') and dbname = 'enwiki_p' > > That should be an extremely fast query; there is an index on dbname. Just a little sidenote, you may be interested in ns_is_favorite. There is one entry per namespace per dbname where `ns_is_favorite = 1` which is also the one used by the wiki when creating/redirecting native links. - Krinkle ___ 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] Attention developers (Gadgets, user/site scripts, Toolserver tools, MediaWiki extensions, ..)
Hi all, If you write, maintain or are otherwise active in development, and directly or indirectly make use of MediaWiki, then you should subscribe to: mediawiki-api-annou...@lists.wikimedia.org That is a mailing list that only brings important announcements for developers that use MediaWiki as an API. Note that this list is not limited to API as "api.php" but about MediaWiki as a application programming interface (API) in general. Subjects that have announcements on that list: * Important changes in database schema (columns or tables added, removed or changed in such a way that you should change your queries. Think for example of the addition of rev_deleted, queries should most likely query for rev_deleted=0 now). * Changes in the JavaScript API (methods being deprecated or removed in the mediawiki.js library etc. as well as upgrades of third-party libraries that ship with MediaWiki, such as jQuery). * Major changes to the HTML layout (such as the change for the sidebar id to #mw-panel) * Hooks in MediaWiki PHP. Mostly for extension developers. Changes or deprecation of hooks. * And last but not least, the api.php itself. All major changes. === Although time will learn how the list is used, to readers and writers of this list: "All subjects should clearly indicate what needs changing and when!" For example "Vector skin sidebar html ID changes to '#mw-panel' in 1.17". Also, whenever Wikimedia has scheduled a deployment of revision(s) or entire branches that expose any change that was previously announced, a new mail should be sent here to remind/summarize upcoming changes (since gadgets should/can't be changed until the new version is deployed but new versions can be prepared or tested in advance) Hope to see you soon on mediawiki-api-annou...@lists.wikimedia.org :) Please reply-to to wikitech to keep discussions about this central. -- Krinkle ___ 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 with randomly missing user database
It seems to randomly work and not work on refresh. it worked a few times for me then, after refresh, it only shows "Unknown database 'u_dcoetzee'". Perhaps related to a periodic script screwing up the connection, or one of the webservers being configured differently (load balanced). -- Krinkle 2011/9/12 Derrick Coetzee > Hi all, > > I have a script here: > > http://toolserver.org/~dcoetzee/contributionsurveyor/ > > which accesses a user database u_dcoetzee. Example result page: > > > http://toolserver.org/~dcoetzee/contributionsurveyor/survey.php?user=Ernestobelmonte > > About half the time when loading this page, I receive this error message: > > Unknown database 'u_dcoetzee' > > Source is here: > > http://toolserver.org/~dcoetzee/downloads/contribution_surveyor.tar.gz > > This is a new issue and the code has not changed at all, so I suspect > some kind of database/server configuration error. In particular, I > suspect the requests are being load balanced across two servers, only > one of which has correct access to my user database. > > Can anyone shed light on what's going on with this? Should I file a > bug (if so where)? Thanks. > > -- > Derrick Coetzee > User:Dcoetzee > > ___ > 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 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] A new tool request - find a translator
See also: http://translatewiki.net/wiki/Category:User_languages Not all native speakers want to or can translate into their language from English, but users in such category on translatewiki.net are more likely to be translators. – Krinkle 2011/9/12 Ryan Kaldari > Could someone write a tool that allows me to search for the most > recently active users on a certain project who speak a certain > language (or combination of languages) natively? > > The user language categories seem to exist on most projects, so it > seem like you could use those: > http://en.wikipedia.org/wiki/Category:User_ja-N > > Ryan Kaldari > > ___ > 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 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] S4-user-databases
2011/8/27 DaB. > Hello, > At Saturday 27 August 2011 15:16:14 DaB. wrote: > > How do I restore them ? > > sorry, I forgot: > > mysql -h sql-s4-user -e 'CREATE DATABASE u_krinkle;' > (if you created already a database for you that will fail, but this is no > problem) > > gzcat u_krinkle.gz|mysql -h sql-s4-user u_krinkle > (that will decompress the file on the fly and import the tables into the > database which was created in step 1). > > Thanks DaB, that worked perfect. Tools are up and running again :) -- Krinkle ___ 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] S4-user-databases (was: Re: z-dat-s4-a (sql-s4) crashed)
I do indeed want to restore these as my s4/commons-related tools are currently error-ing out with "Table 'u_krinkle.foobarcommons' doesn't exist" etc. How do I restore them ? "$ sql u_krinkle" brings me to the u_krinkle of sql.toolserver.org, not of s4-user -- Krinkle 2011/8/26 DaB. > Hello all, > > it took a while, back I finaly managed to extract your user-databases of > the > crashed s4-server. > You can find the dumps at /mnt/user-store/s4-user-dbs.backup/. Please take > a > look if you still need the data > and > -if yes: import them into the temporary s4-user-server and delete the > dump-file > afterwarts. > -if no: just delete the dump-file. > > The dump-files will vanish in 2 weeks from now. > > Sincerly, > DaB. > > -- > Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 > > ___ > 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 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 status files
Might as well make it a JSONP output.
>From JavaScript it's like
http://toolserver.org/~platonides/public_html/common/status.php?callback=Foo
> Foo({"status":"blabla"});
And from many other languages, it's a GET request to
http://toolserver.org/~platonides/public_html/common/status.php
and json_decode or something alike (including Python).
-- Krinkle
On Aug 11, 2011, at 2:04 PM, Dr. Trigon wrote:
>> In case anyone isn't taking status files into account and wants to
>> benefit from my library, he can do:
>>
>> require_once "/home/platonides/public_html/common/status.php";
>> ToolserverStatus::showPrettyBox();
>>
>> And a nice box will appear -if needed- with any relevant status
>> information at that point.
>
> Nice! Is there any possibility to use this from python? Do you have
> a python module? Or could you make it possible to call
>
>> ToolserverStatus::showPrettyBox();
>
> by URL request? E.g.
>
> http://toolserver.org/~platonides/public_html/common/status.php
>
> This would allow to use it with any language... ;)
>
> Greetings
> Dr. Trigon
>
> ___
> 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 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 status
On Aug 9, 2011, at 10:20 AM, Magnus Manske wrote: > On Tue, Aug 9, 2011 at 1:39 AM, MZMcBride wrote: >> K. Peachey wrote: >>> On Tue, Aug 9, 2011 at 10:28 AM, MZMcBride wrote: * http://status.toolserver.org/ is broken >>> s/broken/hasn't been manually updated/ >> >> No, it's broken. You can click "edit this page" and view the source. It was >> updated last week, but it currently takes any status and outputs "ok", >> regardless of user input. > > The changes are pending and need to be approved by an administrator. > > /me ducks > /me thought it was only editable by administrators... ___ 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] user_properties privacy issues, not
Maarten Dammers wrote: Hi everyone, I just noticed https://secure.wikimedia.org/wikipedia/commons/wiki/Commons:Village_pump #User_preferences so I wondered where the data comes from. I checked the commonswiki_p database and it looks like user_properties is visible now. I always considered the user_properties information privacy sensitive information. It contains the gender, language and timezone of every user. Information I'm sure a lot of people don't want to have exposed. Please remove this table from the view. Maarten Please look at the table contents. The public view of user_properties on the Toolserver only contains gender, nothing else. In addition to user_properties, Toolserver also features a custom view, named "user_properties_anonym". That view contains all (if not, most) preferneces, but without the user-id. This is were the commons-page got it's information from. -- Timo___ 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] Global contrib count
An important key in every allwiki-iteration is imho the re-use of
connections.
In php this is quite easy actually.
$connections = array();
$connections['1'] = mysql_connect( ... );
$connections['2'] = mysql_connect( ... );
etc.
then, when you're going to query toolserver.wiki sql db table, in the
loop
that follows afterwards, something like
foreach ( $rows as $row ) {
$currentSqlCon = isset( $connections[ $row->server ] ) ?
$connections[ $row->server ] : false;
if ( $currentSqlCon ) [
$query = mysql_query( $my_query, $currentSqlCon );
}
That way you won't have to make 100s of connections.
From what I remember both Luxo's, vvv's and my own do it like this
for global
tools.
Ofcourse you can always look at own source code in svn and/or my looking
at our php files directly from your toolserver account.
--
Krinkle
___
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 Intuition: non-PHP projects
Paul Selitskas wrote: > Is there any suggestion on implementing Toolserver Intuition in > non-PHP projects, for example, in bash-based ones? For now it seems to > be a bit compliated. Since the beginning this system has been in SVN at Wikimedia for people to look at and submit bugs, requests and patches through JIRA [1] as they desire. Or if one likes, join the mmt-project! As of yesterday the project has been moved to a dedicated "multimaintainer" account at the Toolserver [2]. Support by others is welcomed, I've come far and will go further but I doubt I can make the sytem work for every progamming language on the toolserver all by my own. I myself am planning to implement support for the following: * PHP tools on Toolserver - Include the class internally and use it. * Internal / External javascript - A public facing api.php with the ability to get messages with JSON (both internal for toolserver.org but also for tools that have a javascript front-end on a Wiki, using cross-domain JSONP callbacks). XML format could be implemented as well. * Python - Not sure how to pull this one off yet, as a work around it could make http request to the api in json (since Python supports that) but a way without making http calls would be preferred. I'm not a heavy Python developer (I've used it a couple of times to write simple ircbots (irclib) and wikibots (pywikibot), but that's about it). Any suggestions from python developers how they would like to have it delivered, let me know how you want it served and I'll see what I can do. The same goes for bash-based tools and other languages. Let me know how you think it is best delivered to you, and lets see what we can do. -- Krinkle ___ 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 Intuition - Tech spec (Toolserver goes I18N!)
Platonides wrote:
> Krinkle wrote:
>> -- Other features
>>
>> * Variable replacement ($1, $2, etc.)
>>
>> * Fallback languages:
>> * Getting language names
>>
>> * Escaping (ie. options = array( escape => html )
>
> How much duplication will TsIntuition have with MediaWiki i18n code?
The basic principle is the same: Loading messages from i18n php files,
translating at TranslateWiki, getting messages with fallback, etc..
However the main difference will be it's more basic / simplified.
* No registered users
* No dependencies on other code or database connections to be made.
* Other than replacing variables and gender/plural there will be no
parsing (ie. no ''markup'', {{templates}}, [[links]], {{#or}},
)
* No 'site language' vs. user language.
* Language/gender choice come from cookies and/or browser agent.
Rather then database user account preferences retrieval.
* Isolated text domains.
* No converters, backwards compatibility or wiki-environment factors
to take into account.
One could describe TsIntuition as a lightweight i18n system for
Toolserver
tools written in a way that is compatible with TranslateWiki's
workflow and
as such is similar to other TW projects (like MediaWiki core/
extensions/Wikia).
Or one could describe TsIntuition as a stripped down version of
MediaWiki's Language-class and rewritten without dependancies and with
Toolserver tools in mind.
Both descriptions would match what TsIntuition is most of these
functions
are very simple in nature anyway. To save time and to avoid wheel-
reinvention I have taken a closer look at MediaWiki's i18n system and
may end up using some of it's code, why not ?
>> * Automated updates: Since the messages are file-stored in the
>> messages-directory of the tool. There's no need to keep track or
>> update anything for you.
> (...)
>> -- TranslateWiki
>>
>> I'm currently in talks with TranslateWiki how to best set up the
>> syncing system. Although initial chat with Nikerabbit didn't bring up
>> any expected problem (as it's fairly similar other projects they
>> translate), it still needs to be set up. I expect to have something
>> going within one or two weeks.
>
> Wouldn't DBA be preferible?
I'm not sure which definition of DBA you're referring to in this
context. Can you elaborate ?
Thanks for your email,
--
Krinkle
___
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 Intuition - Tech spec (Toolserver goes I18N!)
want to override your own messages ?
Although you didn't name it, there are scenarios where you want to
quickly modify a message to try something (ie. development and
debugging purposes). In that case one can use the setMsg()-method
to override a message [5].
I think you may have misunderstood the context or goal of this system
a little bit. There is no scenario I can imagine in which a tool author
would want to "change a message to better suit it's tool while leaving
the name unchanged". He (the tool author, is the person who created
those messages in the first place. He can just change the original
message
if there's something wrong.
Translation goes through TWN (TranslateWiki.net), what other way
would you propose ?
Nux wrote:
> It was supposed to be one question, but... :-)
>
>> * Variable replacement ($1, $2, etc.)
>>
>> $welcome = $I18N->msg('welcomeback', array( 'variables' =>
>> array( $username, $lastvisit ) )
>> from [[Toolserver:Mytool-welcomeback]] which contains "Welcome back
>> $1 (last visit: $2)".
>
> I think named variables work much better then those driven by
> certain order.
>
> For example:
>
> $welcome = $I18N->msg('Welcome back', array('username'=>$username,
> 'lastvisit'=>$lastvisit))
> [[Toolserver:Mytool-Welcome back]] contains:
> "Welcome back {{username}} (last visit: {{lastvisit}})".
>
> Could be shorter but still usable:
>
> $welcome = $I18N->msg('Welcome back', array('u'=>$username, 'v'=>
> $lastvisit))
> [[Toolserver:Mytool-Welcome back]] contains:
> "Welcome back %u (last visit: %v)".
Using numbered variables has been the convention for MediaWiki for a
long
time and translators have gotten used to them. Other then that, they
are language
independent, easier to parse and require less typing.
It's not a big deal to add named parameters though, however the syntax
will be
like $username and $v and not {{username}} as those cause unneeded
confusion with templates and/or template parameters.
Nux wrote
> Sorry, but one more thing - what about offline (localhost) testing?
> Will
> there be a downloadable message file?
There already is [0]. If you're outside toolserver scope (ie.
localhost) you can use
SVN checkout [6] to install it locally. All you have to do is
require_once('ToolStart.php'); and you're ready to roll.
Nux wrote
>
> Cheers,
> Nux.
You're welcome. Thanks for your interest in i18n!
--
Krinkle
[0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/ToolserverI18N/
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85052
[2] https://wiki.toolserver.org/view/Toolserver_Intuition#construct
[3] http://toolserver.org/~krinkle/TsIntuition/sandbox2.php
[4] http://toolserver.org/~krinkle/TsIntuition/sandbox3.php
[5] https://wiki.toolserver.org/view/Toolserver_Intuition#setMsg
[6] http://www.mediawiki.org/wiki/Svn#Check_out
___
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 Intuition - Tech spec (Toolserver goes I18N!)
ered via TranslateWiki, or because it's taken
care of by the central i18n system.
-- Tool developer workflow:
I'll describe how the system would work from a tool developers point
of view. [3]
So here's what you'd do to make it work, three easy steps:
1) The toolserver tool developer includes a single php file (eg. /
p_i18n/ToolStart.php). This makes the i18n class available.
2) A new instance of the class is created like $I18N = new
TsIntuition( 'mygroup' );
3) Messages can now be returned with either _('message-key') [2] or
$TSi18n->msg( 'message-key', $options ).
The msg() function can optionally be passed a text domain name (or
'group name' if you will) as second argument to get a message from a
different group eg. the group 'general' for messages like 'welcome',
'login', 'submit' etc. Or an array if you need multiple options like
escape, variable replacement etc. (more on that in a minute).
-- Other features
Although the I18N class will be able to do a lot more, this above is
the core principle. Here's a list of items in no particular order for
other things that it will have:
* Variable replacement ($1, $2, etc.)
$welcome = $I18N->msg('welcomeback', array( 'variables' =>
array( $username, $lastvisit ) )
from [[Toolserver:Mytool-welcomeback]] which contains "Welcome back
$1 (last visit: $2)".
* Fallback languages:
If a message is not found in the current user language, a fallback
will be used. And if that one isn't found English is used.
* Getting language names (eg. de -> 'Deutsch', en -> English) is built-
in. Currently uses a copy MediaWiki's Names.php, could be made to use
sql.toolserver.language if that is preferable but I think it's good
this way)
* Escaping (ie. options = array( escape => html )
* Automated updates: Since the messages are file-stored in the
messages-directory of the tool. There's no need to keep track or
update anything.
ToolStart.php will load the appropriate class from the correct file,
and when initializing the class and using msg(), will load needed
message files on demand.
* Direction (Get which direction a language is, LTR or RTL). Handy
when constructing your element:
* Automatic detection and remembering of the right user language
(users can choose a language from a central i18n preferences page.
This is stored as a cookie and (if no cookies available, in session).
It can still be overridden by using the userlang GET parameter [2].
One can also pass the desired message language to the getMsg()
function to force a certain language for one message.
* No prefixes or collisions for MediaWiki messages:
To avoid conflicts with other tools, message-keys are automatically
prefixed with the name of the group. So you won't have to prefix every
key internally to avoid conflicts with messages of another Toolserver
tool. Also (still in talks with TranslateWiki) we're planning to put
them in a dedicated namespace and not in the MediaWiki:-namespace on
TranslateWiki.
Example:
* A message at [[translatewiki:Toolserver:Luxocontris-usernotfound]]
* will be available through $I18N->msg( 'usernotfound' ), assuming
$i18n = new TsIntuition( 'luxocontris' )
* otherwise $I18N->msg('usernotfound', 'luxocontris');
* Localize other fronts as well: There's several popular tools out
there that have an additional (or only) front-end via JavaScript
implementation on a wiki. Since the i18n system will have an API that
has a JSON-output format with callback (JSONP) you can get the
messages in there as well.
* API: When not in PHP (ie. JavaScript or Python) you can do queries
(GET or POST) like api.php?
action=getmessages&group=luxo&message=foobar|lorem|ipsum|logout|login
&format=json&callback=myTool.initLang
* More.. (see design specification on Toolserver wiki) [5]
-- TranslateWiki
I'm currently in talks with TranslateWiki how to best set up the
syncing system. Although initial chat with Nikerabbit didn't bring up
any expected problem (as it's fairly similar other projects they
translate), it still needs to be set up. I expect to have something
going within one or two weeks.
The source files have been added to Wikimedia SVN [6] and checked out
in the TsIntuition directory [7] at the Toolserver.
-- Documentation / design specification
The initial concept for the class has been documented at Toolserver
Wiki [5]. Most of it has already been implemented in SVN [6] and can
be tested. The implemention is subject to change based on feedback
from you.
-- Already translated
The following tools have been translated already. Log in at the
toolserver and look at their source to learn how they work:
* http://t
[Toolserver-l] Toolserver goes i18n! (Naming)
Hi all,
As some of you may have heard, I'm currently working on a system that
will make it super easy for developers on the toolserver to localize
their tools with almost no effort at all. More about the techinical
aspects of this early next week (or poke me on IRC). I'm currently
checking with TranslateWiki what the best way is for them to handle it
and finding a balance so that Toolserver developers will have minimal
efforts and can focus on the functionality (instead of on the
localization), and for TranslateWiki to not have to dig into any kind
of technical code.
In this thread I'm looking for a suitable name for the system. A few
ideas I came up with are below.
Let me know what you think about them and/or send in some other ones
you think are great!
If you like playing with words, this is your call to get creative!
I'm planning to pick the initial name [0] this weekend, so don't
wait!
I've got three =names=, and about a dozen ==abbrevations/nicknames to
get you started.
= Internationalization (i18n) for Tools' User Interfaces at the
Toolserver
== Name: Ituit (or ITUIT)
(pronounce: " I tweet " or " Étui ")
Story: People communicate by talking, as birds do by tweeting -
preferably in their native language while using the tools.
== Name: Toolserver Intuition
Origin: The word "Ituition" is ITUIT (previous name above) + " ion
".
Story: Peoples first "ituition" is to speak in their native
language.
= Toolserver Localization System
When abbreviated as TLS it'll be confusing with the existing TLS/SSL
technology [2][3].
But the following may be possible derivatives / abbreviations :
* Tolocsy (or Tolloxy)
* Toolsy
* Tolcsy
* ..
= Internationalization for Toolserver's User Interface
== Name: Intoyui
(pronounce: " Into you " or " Into you and I ")
Story: The i18n system is into you / your native language!
== Name: ITUI
(pronounce: " i twee " or " Étui " [1][2] )
Story: This i18n is like a bag (French: etui) of messages.
== Name: IntoUI
(pronounce: " Into U ('you') I ")
Story: The tool intergrates into the UI (user interface) of
toolserver tools.
--
Those were the ideas I had so far.
Personally I like the rol of "Toolserver Intuition" and "ITUI"
(etui).
What do you like and why ? Don't let any of the above limit your
imagination,
feel free to share any ideas you may have regarding the name.
Note: For questions, suggestions or other comments on the system
itself, please respond to the mailing I'll send out early next week.
I'm currently investigating what aspects to look at and how we can
best intergrate this with TranslateWiki in an as simple, flexible yet
solid way as possible. Feel free to poke me at IRC [4]
--
Krinkle
[0] I say initial name because we might change it later on, but I
prefer not to (due to account-, database and class names etc.).
[1] http://en.wiktionary.org/wiki/étui
[2] http://en.wikipedia.org/wiki/Transport_Layer_Security
[3] http://en.wikipedia.org/wiki/TLS
[4] https://wiki.toolserver.org/view/IRC
irc://irc.freenode.net/wikimedia-toolserver
___
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 goes I18N! (Naming)
Hi all,
As some of you may have heard, I'm currently working on a system that
will make it super easy
for developers on the toolserver to localize their tools with almost
no effort at all. More about
the techinical aspects of this early next week (or poke me on IRC).
I'm currently checking
with TranslateWiki what the best way is for them to handle it and
finding a balance so that
Toolserver developers will have minimal efforts and can focus on the
functionality (instead of on
the localization), and for TranslateWiki to not have to dig into any
kind of technical code.
In this thread I'm looking for a suitable name for the system. A few
ideas I came up with are below.
Let me know what you think about them and/or send in some other ones
you think are great!
If you like playing with words, this is your call to get creative!
I'm planning to pick the initial name [0] this weekend, so don't wait!
I've got three =names=, and about a dozen ==abbrevations/nicknames to
get you started.
= Internationalization (i18n) for Tools' User Interfaces at the
Toolserver
== Name: Ituit (or ITUIT)
(pronounce: " I tweet " or " Étui ")
Story: People communicate by talking, as birds do by tweeting -
preferably in their native
language while using the tools.
== Name: Toolserver Intuition
Origin: The word "Ituition" is ITUIT (previous name above) + " ion ".
Story: Peoples first "ituition" is to speak in their native language.
= Toolserver Localization System
When abbreviated as TLS it'll be confusing with the existing TLS/SSL
technology [2][3].
But the following may be possible derivatives / abbreviations :
* Tolocsy (or Tolloxy)
* Toolsy
* Tolcsy
* ..
= Internationalization for Toolserver's User Interface
== Name: Intoyui
(pronounce: " Into you " or " Into you and I ")
Story: The i18n system is into you / your native language!
== Name: ITUI
(pronounce: " i twee " or " Étui " [1][2] )
Story: This i18n is like a bag (French: etui) of messages.
== Name: IntoUI
(pronounce: " Into U ('you') I ")
Story: The tool intergrates into the UI (user interface) of toolserver
tools.
--
Those were the ideas I had so far.
Personally I like the rol of "Toolserver Intuition" and "ITUI" (etui).
What do you like and why ? Don't let any of the above limit your
imagination,
feel free to share any ideas you may have regarding the name.
Note: For questions, suggestions or other comments on the system
itself, please
respond to the mailing I'll send out early next week. I'm currently
investigating what aspects
to look at and how we can best intergrate this with TranslateWiki in
an as simple, flexible yet solid
way as possible. Feel free to poke me at IRC [4]
--
Krinkle
[0] I say initial name because we might change it later on, =
but I prefer not to (due to account-, database and class names etc.).
[1] http://en.wiktionary.org/wiki/étui
[2] http://en.wikipedia.org/wiki/Transport_Layer_Security
[3] http://en.wikipedia.org/wiki/TLS
[4] https://wiki.toolserver.org/view/IRC
irc://irc.freenode.net/wikimedia-toolserver
___
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] A strange thing in huwiki database
On 17 mrt 2011,at 14:34 John wrote: On Thu, Mar 17, 2011 at 9:02 AM, Mihajlo Andjelkovic > wrote: Today I did some analysis over latest revisions on huwiki and there I stumbled on something that surprised me. I believed that revids were given sequentially, so that lower revision id implies an earlier date, and higher revision id implies a later date. Thus, all edits having id greater than 6.000.000 would be no older than august 2009 on huwiki. However, the following revids are anomalies to this, being set 5-6 years back in comparison to their surrounding revids: 8764880, 2004 8764883, 2005 8764884, 2005 8764885, 2005 8764886, 2005 8764887, 2005 8764904, 2004 8764905, 2004 8764906, 2005 8764907, 2005 8764908, 2005 Example: http://hu.wikipedia.org/w/index.php?title=Ornithopoda&oldid=8764883 I don't really want to ask anything, I hope I pointed out something interesting. However, if there be any comments on this, shot away. :) Importing and some deletion related things (before rev_id was moved to the archive table) can cause a revision to get a higher rev_id than it should have Although 'should' is a relative and questionable word, I just want to point out that this is valid and expected behaviour, not a bug. Revision-ids are assigned in order of which they enter the database table of public available revisions. If I import a page from a different wiki it will get a fresh revision id, not the same id it had on the old wiki. Simply because the id it had on the old wiki is most likely already used on the new wiki. There is no rule nor any intention to make the ids represent a timeline, there is the rev_timestamp column for that purpose. Another way, as John pointed out, is deletion. If a page (or rather, it's revisions) are deleted by an administrator / user with 'sysop' right it will be moved from revision-table to archive-table. As of MediaWiki version 1.5 (released in 2005) during deletion / undeletion the revision-id will be saved when it's moved to the archive-table, and will be re-used during undeletion / restore. So any page deleted after June 2005 will retain the same low old revision if when restored. However any page deleted before 2005 didn't have the saved revision-id, so when any of those pages are restored now MediaWiki generates a new revision-id, just like it does for Import, just like it did before 2005 for undeletion. As we can see in the logs here: http://hu.wikipedia.org/w/index.php?title=Speciális:Rendszernaplók&page=Hivatalos+nyelvek+az+EU-ban .. that page was deleted before June 2005 and undeleted in 2010. As such it got a new revision id. Conclusion: revision.rev_id is great to count revisions, and contributions. And for developers to see if a revision was added later in. However it's not meant for timelines, use rev_timestamp instead. -- Krinkle ___ 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] Needs of important ressources
On March 4 2011, Seb35 wrote: > Fri, 04 Mar 2011 03:45:53 +0100, MZMcBride wrote: >> Seb35 wrote: >>> I'm from the French chapter and we need sometimes a lot of CPU power >>> and/or a lot of memory for some projects. For now it happened two >>> times: >> >> It's difficult to know what "a lot" of CPU power or memory is from >> your >> post. Toolserver accounts have account limits >> (<https://wiki.toolserver.org/view/Account_limits>), so if you're >> staying >> within those limits, there's generally no problem. If you want to >> exceed >> those limits, you should talk to the Toolserver roots first >> (<https://wiki.toolserver.org/view/System_administrators>). There are >> places >> like /mnt/user-store that can be used for large media storage as >> well. >> >> As always, the Toolserver resources that you use need to relate to >> Wikimedia >> in some way, but it sounds like both of your projects do. :-) >> >> MZMcBride > Ok, thank you, I didn't find this page. > > For the BnF project we needed in fact about one day of computation > (most > of the time was used by the disk accesses), but we thought it would be > more (we optimized too by using SAX instead of DOM to read big XML > files, > it used too much memory with DOM too). > For the video encoding to OGV (it's not me who done that), it was 4-5 > hours for a single video but some time was used to swap (and there > are 100 > videos corresponding to the conferences). > > Thank you for the response. > Seb35 Hi Seb35, "One day" or "4-5 hours" still don't mean a lot in terms of technical requirements. One day of computing with what equipment ? With 24 hours of runtime a small difference can make a big difference. What kind of server server/setup did this run on ? How much is "too much memory" ? -- Krinkle ___ 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] Internally calling the MediaWiki API on Toolserver
Ilmari Karonen wrote: > On 02/06/2011 12:42 AM, Krinkle wrote: > >> So I was thinking : >> * upload a mediawiki install (the same version that WMF runs, ie. >> 1.16wmf4 or 1.17wmf1) >> * make it not publically accessable (we don't want people actually >> browsing the wiki) >> * Configure it in a special way so that one can use the same code for >> any wiki (ie. a $lang and $family variable of some kind) > > So you basically want to set up an internal copy of MediaWiki core so > that it can run on the Toolserver databases in read-only mode, and > provide a wrapper so that it can be conveniently accessed from PHP > code? > > That sounds potentially very useful, at least for people who write > their > tools in PHP. > >> Then one can include includes/WebStart.php, and use the API (ie. >> using >> the huge library of quiries already in the MediaWiki core (ie. >> action=query&list=categorymembers, using generators and getting >> properties, you name it) like this: >> >> >> $site = 'wikipedia'; >> $lang = 'en'; >> require( $mw_root . '/includes/WebStart.php' ); // loads all common >> code including LocalSettings.php >> // LocalSettings contains extra code to check for $site and $lang >> figuring out the correct $wgDBname, >> // $wgDBserver etc. a tiny bit like wmf's CommonSettings.php >> >> $apiRequest = array( >> 'action' => 'query', >> 'list' => '...', >> /* etc. */ >> ); >> /* etc. */ >> > > On the other hand, I'm not sure why you'd want to do that. Calling > the > API internally via FauxRequest is basically a huge kluge. I suppose > it > may sometimes be the easiest way to get a particular job done, but > it's > not really the first (or even second or third) solution I'd consider. > > Most of the time, if you have direct access to the MediaWiki core > classes, you really should just use them directly. > > -- > Ilmari Karonen Yes indeed. FauxRequest is just one of the examples possible when having a internally working version of wmf-deployment on Toolserver. Ofcourse using any other classes is just as easy and is probably a better idea. -- Krinkle ___ 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] Internally calling the pywikipedia API on Toolserver
Dr. Trigon wrote: > Hello all! > > "[Toolserver-l] Internally calling the MediaWiki API on Toolserver" is > a very good idea!! > > What about doing the same e.g. with the actual pywikipedia bot > framework > to have some API for python script as well? > > Greetings > Dr. Trigon Hi again, I decided to drop this for now (atleast for myself, anyone else can ofcourse pick it[1]). Because there were too many problems setting it up: * Missing tables that MW wants by default (mostly cache tables) * Invisibility of some indexes that the API needs * Configuration problems * more errors, problems and incompatibilities What I did do to solve the problem I was having (which inspired me to bring this up) is write the following tool: http://toolserver.org/~krinkle/getWikiAPI.php Which can be used to get wiki-specific information by any of the identifiers we know (like database name, sitename, host, url, domain, topdomain) Can come in handy if you got one of the pieces but are missing the other pieces (either from within a tool or off-toolserver) This API supports a few human readable formats and serliazed PHP and JSON/JSONP callbacks: * http://toolserver.org/~krinkle/getWikiAPI.php?wikiids=commons#output * http://toolserver.org/~krinkle/getWikiAPI.php?wikiids=media&format=json&callback=myFunction * http://toolserver.org/~krinkle/getWikiAPI.php?wikiids=dewikt&format=php_print -- Krinkle [1] Some points for who would like to do this: * svn checkout /branchces/wmf/1.16wmf4 (better wait two weeks so you can take /1.17wmf1) * regularly update this from svn * global variable aray (eg. $tsWmfApi) with wanted databasename, database user and datebase password (users can pass their .my.cnf. user/password and then which ever database they need) * Map this to the right dbhost (either replace _p with -p and go to dbname.rrdb.toolserver.org or get it from sql.toolserver.org / toolserver.wiki table (SELECT server WHERE dbname=sql_clean($tsWmfApi['dbname']). ) * include the right extension files for the right wikis (or include none for all wikis, but don't include all for all wikis) ** Use wgConf(), see http://noc.wikimedia.org/conf/CommonSettings.php.txt , http://noc.wikimedia.org/conf/InitialiseSettings.php.txt * in LocalSettings.php set $wgLocalisationCacheConf['store'] = 'files'; // since l10n_cache doesn't exist on Toolserver * Figure out how to fix the missing objectcache table as well. * Figure out how to stop mediawiki from forcing index in queries since those indexes are not visible from views on Toolserver ** There's a useIndexClause() function in /includes/db/ DatabaseMysql.php. Reset to returning "" ** Then there's a lot of calls to $this-> addOption( 'USE INDEX', / * */ ) in api modules, add an if() statement to not use index if $value is USE INDEX. * And more ___ 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] Design of toolserver.org
Op 5 feb 2011, om 23:56 heeft Platonides het volgende geschreven: > MZMcBride wrote: >> I know this has come up previously, but I don't think it was ever >> addressed. >> What's the process for updating the design of > toolserver.org>? Can >> the index file be made to load from the Toolserver wiki (similar to >> how >> www.wikipedia.org works at Meta-Wiki)? > > It loads from there. That's why there is a "admins may edit this > page in > the toolserver wiki" link to > https://wiki.toolserver.org/edit/Toolserver:Homepage > > Does it require a JIRA ticket to >> update the design? Is an updated design even allowed? >> >> My issue is that the page currently looks broken. It looks as >> though only >> some of the content loaded and parts are missing. > > Shows fine here, although it has some html typos, such as > instead > of , or the double . I was going to link that that :-D. It can be edited on-wiki already. However that's just (part of) the body's content. The rest (layout, css) cannot be edited there. It would help having the complete structure there from !doctype upto . -- Krinkle ___ 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] Internally calling the MediaWiki API on Toolserver
Op 5 feb 2011, om 23:49 heeft MZMcBride het volgende geschreven: > Krinkle wrote: >> * Configure it in a special way so that one can use the same code for >> any wiki (ie. a $lang and $family variable of some kind) > > The general idea seems fine. My only comment about this proposal is > that the > lang/family combination is horrific and should never, ever be used. > It ends > up requiring abominations such as lang=commons or lang=strategy, > which is > completely nonsensical and completely avoidable. It also presents > problems > in URLs when parameters such &lang=en get incorrectly auto-corrected > by bad > programs/scripts/applications into ⟨. > > Wikimedia separates its wikis by database name. Please use "db", > "wiki", or > "site" (containing either the DB name or the URL) instead of family/ > language > hackery. > > MZMcBride Although I forgot for a second that, as developers, we can simply pass the dbname directly. So I will certainly do that and simply require knowing the database name. But so you know, look at: http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php and search for: $lang The horror begins (and hopefully at some point, ends) there :-) -- Krinkle ___ 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] Internally calling the MediaWiki API on Toolserver
Hi all, I'm finding myself making calls to the live api on the wmf wikis and thinking: Writing the query from scratch for every detail (or copying it from the bits and pieces in mw source code) for every time I need the data is nonsense since it was already done. in mediawiki core. MediaWiki uses the API internally as well in some places (more in extensions) with a FauxRequest (which is calling the api without a real http request). From a server hosting a live MediaWiki-site it's very easy (php include includes/WebStart.php anad make a FauxRequest() - one can make several requests all without making a http request ). However from the toolserver it's a little trickier since we're not on the same server. So I was thinking : * upload a mediawiki install (the same version that WMF runs, ie. 1.16wmf4 or 1.17wmf1) * make it not publically accessable (we don't want people actually browsing the wiki) * Configure it in a special way so that one can use the same code for any wiki (ie. a $lang and $family variable of some kind) Then one can include includes/WebStart.php, and use the API (ie. using the huge library of quiries already in the MediaWiki core (ie. action=query&list=categorymembers, using generators and getting properties, you name it) like this: $site = 'wikipedia'; $lang = 'en'; require( $mw_root . '/includes/WebStart.php' ); // loads all common code including LocalSettings.php // LocalSettings contains extra code to check for $site and $lang figuring out the correct $wgDBname, // $wgDBserver etc. a tiny bit like wmf's CommonSettings.php $apiRequest = array( 'action' => 'query', 'list' => '...', /* etc. */ ); /* etc. */ This should basically be includable by anyone so that not everybody has to re-do this. ie. it could be in /home/somebody/wmf-api/includes/WebStart.php which would be a checkout of the wmf-branch in SVN and (maybe) the same extensions etc. This will make it a lot easier to interact with the database when you need certain information, this will also prevent us from hardcoding names all the time (which I'm sure happends a lot and this is one of the causes some tools brake over time when just small details changed). I believe some of the toolserver users already have parts of mediawiki in their home (I imagine stuff like GlobalFunctions.php can be very handy at times). Basically I'm asking three things: * Has this been done already ? If so, we should document this better as I spent time looking for it but came up empty * Do we want this ? Are there potential problems here, what do we need to tackle or fix on our side ? * Who would want to do this ? (If nobody has plans for this already, I would like to do this) -- Krinkle ___ 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] cronsub
Op 8 jan 2011, om 03:28 heeft River Tarnell het volgende geschreven: > I've made a couple of changes to cronsub in response to some issues > reported by > users. Specifically: > > * cronsub now requires that the script file be executable, and will > raise an > error if it's not. The previous behaviour was that non-executable > scripts > would be executed by /bin/sh. If this affects you, the fix is to > make the > script executable (chmod +x). > > I appreciate that the first item may be a breaking change for some > users. > However, on balance this seems like the lesser evil. I had an entry in my crontab like: 55 * * * * cronsub -l -s krinkle_clogger $HOME/bots/clogger-start.sh I got e-mails since a few minutes ago about it not being executable. This can be fixed by giving the user that executes it (in most cases the owner, you) the chmod x right So if it were chmodded like 644 it now needs to be 744 :) -- Krinkle ___ 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] General maintenance notice: December 6th
Yeah, I thought the same at first but I had this confusion before. It goes like this for comparison to european / 24h times : 24 notation: 00:00, 08:00, 11:00, 12:00, 20:00, 23:00, 24:00 Are the same as these in that order: 12 AM, 8 AM, 11 AM, 12 PM, 8 PM, 11 PM, 12 AM -- Krinkle Op 30 nov 2010, om 01:22 heeft Kalan het volgende geschreven: > On Tue, Nov 30, 2010 at 03:04, Aryeh Gregor > wrote: >>> Start time: Monday, 6th December, 12AM UTC >>> End time: Monday, 6th December, 8AM UTC (estimated) >> Are these reversed or what? > > They read 2010-12-06 00:00 and 2010-12-06 08:00 respectively, no > reversing. > > 12-hour clock, and specifically its AM/PM notation, is so stupid and > confusing. Especially for the countries preferring to stay away from > it. > > — Kalan > > ___ > 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 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] Monthly pageviews
Op 15 nov 2010, om 19:22 heeft Magnus Manske het volgende geschreven: > Hi, > > I know there are lots'o'files for daily (hourly?) pageview stats on > the toolserver. Where are these text files actually ? -- Krinkle ___ 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] Account expiry
Op 11 nov 2010, om 21:43 heeft James Hare het volgende geschreven: > The LDAP password is something different, available in your .my.cnf > file. The LDAP password, atleast for me, is not stored in the .my.cnf file. What is stored in the .my.cnf files is access credentials for connecting to the database servers (ie. when connecting to a database in PHP). LDAP is seperate from that and is not stored, that I know of, anywhere (especially not in clear text). The SSH authentication uses public_key and is also seperate. So there's SSH, LDAP, MySQL access and your SSO (Single Sign On) for web-services (such as JIRA, FishEye etc.) All seperate :-) What you need to do is connect to a Solaris server (ie. willow.toolserver.org) with SSH and after the 'acctrenew' command login with the LDAP password. See also: https://wiki.toolserver.org/view/LDAP -- Krinkle ___ 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] Account expiry
The LDAP password is what you use when, for example, you login to phpmyadmin.toolserver.org (the first login that pops-up from the browser - not the one for the database itself). Op 11 nov 2010, om 21:43 heeft James Hare het volgende geschreven: On Thu, Nov 11, 2010 at 3:42 PM, Kay Drangmeister > wrote: Hi, River Tarnell schrieb: > may wish to run 'acctrenew' on willow now to renew your account. > The tool asks me for an "ldap password". I am not sure but I think I don't have one. I log on with ssh using my public key... Kind regards, Kay ___ 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 The LDAP password is something different, available in your .my.cnf file. ___ 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 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: user-store; all database clusters tonight
Thanks River, Though I personally have no problem with your previous announcement about the maintenance yesterday, but this table-like notice is much beter in my opinion. --Krinkle Op 11 sep 2010, om 17:26 heeft River Tarnell het volgende geschreven: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > (I have the impression that our maintenance notices are not always > very clear, > since people are sometimes surprised when we carry out previously- > announced > maintenance. So, here's a new and hopefully improved notification > format.) > > This is a maintenance notification for tonight (Saturday 11th) UTC. > The > following services will be affected: > > Service | Expected impact > - +--- > s1 cluster| User databases unavailable for < 10 minutes > s2 cluster| Entire cluster unavailable for < 10 minutes > s3 cluster| User databases unavailable for < 10 minutes > s4 cluster| User databases unavailable for < 10 minutes > s5 cluster| Entire cluster unavailable for < 10 minutes > s6 cluster| User databases unavailable for < 10 minutes > user databases (sql) | Unavailable for < 10 minutes > user-store filesystem | Unavailable for < 20 minutes > NFS, LDAP, misc services: | None expected, but at risk during > maintenance. > SVN, phpMyAdmin, SGE, tsbot, | > mail forwarding, DNS,| > sql-toolserver database | > All other services| No impact > > Start time: Sunday, 12th September, 12AM UTC > End time: Sunday, 12th September, 3AM UTC > > Details: > > Tonight we will complete the upgrade to Solaris 10 Update 9 on the > remaining > servers. This requires under 10 minutes downtime while each system > reboots. > > Since we will be upgrading the primary server in each cluster, which > holds user > databases, these will be unavailable during the reboot. Access to > replicated > databases will not be interrupted, since queries will be directed to > the > alternative server while one is rebooted. > > The exception is s2/s5 and sql (user databases), which currently > have only one > server. They will therefore be unavailable during the reboot. > > - river. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.16 (FreeBSD) > > iEYEARECAAYFAkyLn7IACgkQIXd7fCuc5vLGIQCeOzuSSxfnVcwKaPz4JU4I15WL > 864Ani/mUI0ed+8nfnocP3rVep+P64X6 > =GEkv > -END PGP SIGNATURE- > > ___ > 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 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] ts-admins language
Marcus Buck heeft het volgende geschreven: > seth hett schreven: >> >> Hi and 'gudn tach'! >> >> On Tue, June 29, 2010 12:37, Marcus Buck wrote: >> >>> Andre Koopal hett schreven: >>> The solution we mostly take is to answer in dutch or swedish or something :-) >>> Wow, how mature... Hoe durven ze geen Engels te spreken? >>> >>> If River Tarnell does not speak German and recommends using >>> English if >>> people want to get a quick answer from him without one of River's >>> co-admins being interpreter, that's of course okay. But >>> intentionally >>> being unhelpful to people who in good faith use their native >>> language >>> (which in the case of German will be understood on this list) is >>> just >>> offensive and arrogant. >>> >> >> On the other hand you could call someone offensive or arrogant (or at >> least not-thinking-enough), if he uses his small native language in >> an >> international project. >> > Interesting that you call it an 'international' project. That is > technically true, but Wikimedia does not involve 'nations' or > 'countries' but rather 'language communities'. So the more > appropiate adjective would be 'multilingual'. And if you replace > 'international project' with 'multilingual project' in your sentence > it doesn't sound that meaningful anymore, does it? >> Of course, in most cases none of them is really arrogant or >> maliciously >> offensive. > Arrogance and offensiveness rarely involve real maliciousness. Many > people act in good faith while being arrogant and offensive. They > just don't realize their rude behaviour. >> If someone replies in Swedish on a German request, one could >> take it as nothing but a joke and a hint 'try using the common >> language, >> please!', which mostly will be English, nowadays. >> > This "common language" is spoken by less than a quarter of the world > population. If we only count decent English it's more like 10%. > > If somebody asks a question in a non-English language what would > happen in the optimal case: > a) one of the other list members knows the language, knows the > answer, answers the answer in the non-English language and adds a > sentence in English telling the other list members what he answered > (so they can make addenda if necessary which will be translated into > the non-English language) > b) one of the other list members knows the language, but doesn't > know the answer: He acts as a interpreter between the original > poster and the list > c) none of the list members knows the language: if some time has > passed and noone has initiated a) or b) one of the list members > answers the question with something like "Apparently nobody speaks > X, perhaps you could try to ask in English so more people can > understand your question." Either the original poster speaks English > and asks in English or he doesn't speak English. In the latter case > he's lost but at least the list tried to help without making jokes > about him. > > Marcus Buck > User:Slomox I agree with Marcus here. Though people shouldn't asume that because it's a project by Wikimedia Deutschland that the admins are German. However, they shouldn't get the impression of an English organisation either. It's a multilingual project and it shouldn't be a problem for natives to speak with eachother. -- User:Krinkle ___ 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
