hello,
if you run a MySQL query which takes longer than 600 seconds (10
minutes) to execute, you will now receive a warning message
("long-running query notification"). this message will be written to
your terminal, or if you aren't logged in, mailed to you.
if you receive one of these notifications, please consider fixing the
query, since it's using a lot of resources.
if the query can't be made any faster, you can suppress the
notification by writing /* SLOW_OK */ somewhere in the query, e.g.:
SELECT /* SLOW_OK */ COUNT(*) from page;
but this won't work with the command-line MySQL client, because it
strips comments before executing the query.
- river.
Dear toolserver user,
I have sadly to report an abuse of the toolserver facilities by one of
its users, almost certainly Purodha.
Yesterday (saturday, march 26th) user Purodha on it.wiki started to do
massive interwiki addition without the bot flag, flooding the recent
changes log. As it was not the first time that the user was doing bot
operations it was promptly blocked by an administrator.
Unluckily the administrator forgot to uncheck the option to block the
bare IP together with the user, so he blocked the entire toolserver from
editing on it.wiki.
I have to add that the user page of the bot does not state that it is a
bot, nor the user name suggest this fact (actually the username is not
used as a bot on other wikipedias).
Now several measures have been taken on it.wiki to prevent this kind of
problems in the future, whitelisting the toolserver IP, still I have to
report the scorrect behaviour of Purodha.
I hope to read her/his version of the facts as soon as possible.
Best regards, Lorenzo.
--
Lorenzo `paulatz' Paulatto
Trieste
``Grandissima mi par l'inezia di coloro che vorrebbero che Iddio avesse
fatto l'universo più proporzionato alla piccola capacità del lor discorso.''
--Galileo Galilei (Opere VII)
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Vacanza in Grecia: 7 giorni con trattamento all inclusive in albergo 4 stelle a soli 479 Euro
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6607&d=27-5
Hello all,
all accounts will expire automaticaly at the 5th of june. To keep your
account active, please send me a short eMail with the following data:
Your login-name and your realname. I need no reason, why you need the
account still, this is just a test, who is active, ok? :)
Please send the eMail at wp(a)daniel.baur4.info and put the word "account"
into the subject. Do not just push reply and send it to the mailinglist;
I need the eMail, not the mailinglist ;).
Sincerly,
DaB.
Similar - the only proper difference (aside from making it look nicer
;)) will be that it will only have Wikimedia channels where his has
places like ##philosophy.
It'd be good if a ts admin could weigh in on this :-)
Thanks,
Sean
On 24/05/07, Casey Brown <cbrown1023(a)comcast.net> wrote:
> Sounds like a great idea, Sean!
>
> Based on my interpretation of the big bad RULES
> (http://meta.wikimedia.org/wiki/Toolserver/Rules) and my understanding of
> what you are to do:
> 1. It is definitely related to the Wikimedia Foundation (obviously).
> 2. Laws... well, I think we can trust you not to break any (and I
> can trust you to identify and find applicable laws). :)
> 3. "other requests to other sites without permission from the
> operator of that site," You've already stated that you will handle
> communication with the Freenode Staff (as you do any many occasions almost
> daily!)
> 4. You obviously already subscribe. :)
> 5. I don't think you are installing a web application...
> ...
> The other items are either non-applicable, or already taken care of. It
> looks like this would be fine (but that is just my opinion!).
>
> Quick question, though: will this be similar, identical to, or completely
> different from Walter's Wikizine one?
>
> Casey Brown
> Cbrown1023
>
> -----Original Message-----
> From: toolserver-l-bounces(a)lists.wikimedia.org
> [mailto:toolserver-l-bounces@lists.wikimedia.org] On Behalf Of Sean Whitton
> Sent: Wednesday, May 23, 2007 12:53 PM
> To: toolserver-l(a)lists.wikimedia.org
> Subject: [Toolserver-l] An IRC gateway
>
> I don't know if this has been discussed before, but would we consider
> running a CGI:IRC gateway on the toolserver? I'm not sure how it fits
> with the rules so I thought I'd ask. There is already a java client
> somewhere but this runs off the user's PC, so is of course allowed.
>
> The advantage of CGI:IRC is that it will run on almost any machine,
> without any security warnings etc. that java is good at throwing up. I
> think that a lot of users would find it a very useful to get onto IRC
> which is something to generally be encouraged. We can easily restrict
> it down to just Wikimedia channels.
>
> Walter of Wikizine currently runs http://chat.wikizine.org/ but I
> thought it would make sense to have it on the toolserver, which would
> help him in terms of resources.
>
> Thoughts from users and admins?
>
> (dibs on doing this if we say yes, since I've done one of these before
> and it was my idea :D)
> (also, we'd need to get authorisation from freenode staff, but I can
> handle this)
>
> Sean
>
> --
> -Sean Whitton (seanw)
> <sean(a)silentflame.com>
> http://seanwhitton.com/
>
> _______________________________________________
> Toolserver-l mailing list
> Toolserver-l(a)lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/toolserver-l
>
>
> _______________________________________________
> Toolserver-l mailing list
> Toolserver-l(a)lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/toolserver-l
>
--
—Sean Whitton (seanw)
<sean(a)silentflame.com>
http://seanwhitton.com/
Hello,
attached is a list of users, who did NOT sent a anti-expire-eMail to me
allready. If you find yourself on this list, please write me (not the
mailinglist - you know ;)) a eMail soon. If you are NOT on this list,
all is ok.
Sincerly,
DaB.
80686
aaronsw
agtfjott
alai
alex
alpha
alterego
archinform
avar
avatar
banane
beetstra
berard
bjelleklang
bjweeks
brendan
charlie
chp1994
chrislb
cool_cat
cosoleto
d
dario_vet
daveross
didi
eagle
edwardzyang
erik
erkomandante
essjay
evhart
fab
flacus
friendlystar
fschulenburg
geonick
gunther
hashar
hendrik
hippietrail
hoodedman
icey
jhs
jhull
jylee
kmartin
lar
luxo
mathbot
mike
mzlla
orgullo
panther
pathos
porao
presroi
purodha
ral315
regi
robertg
samkorn
snowolf
stable
stephanie
stridvall
tawker
tim
veinor
vishwin60
werdna
wikisign
wizardrydragon
wmahan
yaohua2000
hello,
the next time you log into hemlock you'll get a news item called
NEWUSERS. this is meant for new users, but since it's shown once to
every user, existing users will see it too. you can ignore it. :)
- river.
I don't know if this has been discussed before, but would we consider
running a CGI:IRC gateway on the toolserver? I'm not sure how it fits
with the rules so I thought I'd ask. There is already a java client
somewhere but this runs off the user's PC, so is of course allowed.
The advantage of CGI:IRC is that it will run on almost any machine,
without any security warnings etc. that java is good at throwing up. I
think that a lot of users would find it a very useful to get onto IRC
which is something to generally be encouraged. We can easily restrict
it down to just Wikimedia channels.
Walter of Wikizine currently runs http://chat.wikizine.org/ but I
thought it would make sense to have it on the toolserver, which would
help him in terms of resources.
Thoughts from users and admins?
(dibs on doing this if we say yes, since I've done one of these before
and it was my idea :D)
(also, we'd need to get authorisation from freenode staff, but I can
handle this)
Sean
--
—Sean Whitton (seanw)
<sean(a)silentflame.com>
http://seanwhitton.com/
hello,
after a broken mailer caused hemlock to be CBL-listed, i have
disallowed outgoing SMTP (port 25) connections. if you want to send
mail, you should use /usr/lib/sendmail (like a normal UNIX program), or
speak SMTP to localhost (which is allowed and will accept your mail).
- river.
This may be off topic, but asking on Wikimedia Commons and the
Pywikipediabot mailinglist didn't give me any replies. Please flame me if
you think I should not make a request like the one below again on this list.
----
I would like to request a volunteer to assist (well, assist, you have to do
the dirty work, I'm afraid, as I am just not skilled enough, I can spec it,
though) in stabilising and fine tuning the CommonsDelinker bots replacer.py
and delinker.py.
Orgullomoore, the previous maintainer of the code has gone back packing in
Europe and is no longer able to maintain the bots. About two weeks ago I
took over running the bot from the toolserver. In the past two weeks I have
experienced a few flaws in the bots that I would like to see fixed.
If you are an experienced python coder and feel at home with pywikipediabot,
threads and a little MySQL and you feel like making a difference on this
crucial bot in supporting all users of Wikimedia Commons, please contact me.
Having an account on toolserver is not required but is a definite advantage.
Below a description of current functionality and found flaws.
Thanks for your help.
Siebrand
Delinker: removes links from any Wikimedia wiki once a file has been deleted
from Wikimedia Commons. If a special string is added to the deletion
message, this action is not performed. Success and failure of edits is
logged into a MySQL database on the toolserver. Edit messages can be
localised and are read from the local wiki.
Flaws:
* Fails if CheckUsage is too busy. Delinking is not performed. This
should be recognised and retries should be performed until a complete
CheckUsage was obtained
* Each toolserver user is granted 15 connections to the MySQL
database. Sometimes this limit is reached and in that case success and
failure is not logged. This should not happen.
* If a lot of files have been deleted that are used a lot on one wiki,
a lot of edits can be made to that one wiki. This can (and has) upset users
in a community. An edit limit of 3 edits per minute per wiki should be in
place.
* From the bot output it looks like it keeps on fetching the edit
summary on multiple edits on a wiki. This causes unnecessary server load and
should not occur.
* Most main projects are supported, but especially the meta projects
can give issues because of the implementation of project recognition.
* TypeError: unsupported operand type(s) for -: 'unicode' and 'int'
* Sometimes when toolserver is really busy (or whatever the reason may
be), a thread cannot be created. In this case a task is not executed. This
should not happen.
Replacer: replaces image links on any Wikimedia wiki. Tasks are fetched from
a sysop only page on Wikimedia Commons. AnyImageTypeButSVG to SVG is not
supported because of a pending SupersededSVG deletion debate. Success and
failure of edits is logged into a MySQL database on the toolserver. Edit
messages can be localised and are read from the local wiki. If {{stop}} is
present on the wiki page, the bot will stop working until that text has been
removed.
Flaws:
The bots use a lot of similar code. Because of that, similar issues may be
documented.
* Fails if CheckUsage is too busy. This should be recognised and
retries should be performed until a complete CheckUsage was obtained
* Each toolserver user is granted 15 connections to the MySQL
database. Sometimes this limit is reached and in that case success and
failure is not logged. This should not happen.
* If a lot of files have to be replaced that are used a lot on a wiki,
a lot of edits can be made to that one wiki in a time unit. This can (and
has) upset users in a community. An edit limit of 3 edits per minute per
wiki should be in place.
* From the bot output it looks like it keeps on fetching the edit
summary on multiple edits on a wiki. This causes unnecessary server load and
should not occur.
* Most main projects are supported, but especially the meta projects
can give issues because of the implementation of project recognition.
* Image name recognition is such errors can occur in special cases.
Example: A page contains images "Test 1.jpg" and "1.jpg". If "1.jpg" is
removed, "Test 1.jpg" may end up as "Test ". (example unfortunately lost)
* Although there is code present to prevent this issues, it has
happened that a replacement was made when a local image with the same name
was present. This should not happen. [1]
* Bot crashes on 'Unhandled exception in thread started'
* Sometimes when toolserver is really busy (or whatever the reason may
be), a thread cannot be created. In this case a task is not executed. This
should not happen.
* If an image has more than 50 uses on a wiki and all uses are from a
template that is not displayed in the first 50 pages displayed, no text
replacement will occur (can this be fixed at all)
[1]
http://en.wikipedia.org/w/index.php?title=User:TomStar81/World_War_II&diff=p
rev&oldid=129050292
General wishes
* Simple web interface for database logs (last edits, last edits per
language, all edits for a particular image)
* Some kind of registration for the bots to enable starting it from
cron if it is no longer running