Hello all,
from time to time I find huge blocks of
Mar 22 14:47:02 nightshade suhosin[14364]: ALERT - script tried to disable
memory_limit by setting it to a negative value -1 bytes which is not allowed
(attacker 'REMOTE_ADDR not set', file 'unknown')
in the syslogs of the userland-servers. Unfortunately I have no idea to whom
these lines belong. So if you use suhosin could you please look if one of your
tools have a problem? And if somebody has an idea how to identify the user I
would like to read it too :-).
Sincerely,
DaB.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885
Hello all,
for a config-change at our sql-load-balancer (that's the software-thing that
converts something like "sql-s2-user" to the real server) I hereby announce a
maintenance-window for tomorrow,
WEDNESDAY, 20:05 UTC.
During the downtime no connections to the databases will be possible, running
database-queries will be aborted. If all works correctly the downtime will be
less than 1 minute (just the restart of the service), but just to be sure
calculate with 1h of downtime. You can follow the process at [1].
Sincerely,
DaB.
[1] https://jira.toolserver.org/browse/MNT-1308
--
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885
couple years ago somebody did stay for a couple years ;) (altho that was
the chapters conference and there was a vulcano involved)
henna
On Fri, Mar 8, 2013 at 7:19 PM, Petr Bena <benapetr(a)gmail.com> wrote:
> I have one question :) why the registration form is asking me which
> year and month I will depart? Are you afraid some attendees are
> planning to stay for several years? :D
>
> On Fri, Mar 8, 2013 at 6:54 PM, Maarten Dammers <maarten(a)mdammers.nl>
> wrote:
> > Hi everyone,
> >
> > Wikimedia Nederland invites all developers to the Wikimedia Hackathon.
> The
> > Wikimedia Hackathon will be in 2013 from 24-26 May. The registration is
> now
> > open and also includes the possibility to apply for a travel,
> accommodation
> > or full scholarship. You can find the form at
> >
> https://docs.google.com/spreadsheet/viewform?formkey=dFg2SmRRbkpxNmxCcFNFdl…
> >
> > The hackathon is an opportunity for all Wikimedia community developers
> and
> > sysadmins to come together, squash bugs and write great new features &
> > tools. Unlike the previous years (2012, 2011, etc.) this Hackathon won't
> be
> > in Berlin, but in Amsterdam.
> >
> > The event is open to a wide range of developers. We welcome both seasoned
> > and new developers as well as people working on MediaWiki, tools,
> > pywikipedia, Wikidata, gadgets, extensions, templates … . Please suggest
> and
> > discus topics at
> > https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Topics .
> >
> > You can indicate that you're coming at
> > https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013/Attendees and/or
> > https://www.facebook.com/events/167285526755104/ . This doesn't replace
> > registration, it's just to let others know what you're up to.
> >
> > Keep an eye on https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013for
> > updates!
> >
> > Maarten
> >
> >
> > _______________________________________________
> > Labs-l mailing list
> > Labs-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/labs-l
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
"Maybe you knew early on that your track went from point A to B, but unlike
you I wasn't given a map at birth!" Alyssa, "Chasing Amy"
Hello,
we have an issue with Jira authentication since 25th August.
It seems the syncronisation with the crowd server is broken but I dont know why and filed a bug at Atlassian.
Cheers
Marlen
-------- Messaggio originale --------
Oggetto: [Wikimedia-l] Free as in Wikimedia Foundation
Data: Tue, 19 Mar 2013 13:12:04 +0100
Mittente: Tomasz W. Kozłowski
A: Wikimedia Mailing List
Hi community,
I would like to bring to your attention a matter that's currently
being discussed on Meta, one that has not yet gained too much interest
(though it was discussed during IRC office hours, and was mentioned on
one mailing list, as far as I see).
It seems that the Wikimedia Foundation registered a community logo
<https://meta.wikimedia.org/wiki/File:Wikimedia_Community_Logo.svg> as
a trademark in the United States, with the international application
still pending.
The logo was originally created in 2006 by User:WarX (Artur
Fijałkowski) , and was adopted as the logo of Meta-Wiki in 2008 — and
as far as I can recall, the very point of it being created was to (1)
have a community logo released into the public domain and (2) to have
a community logo which was /not a trademark/.
I am especially worried about the WMF not informing the community
about their trademark registration — we have only found out about it
via an edit on Commons
<https://commons.wikimedia.org/w/index.php?diff=84864201&oldid=49625546>,
and then after asking about it during IRC office hours at the end of
January.
As far as I understand, the WMF has not discussed trademark
registration with the author of the logo
<https://commons.wikimedia.org/w/index.php?diff=92395329&oldid=92392542>
— though obviously, since Artur-WarX released it into the public
domain, it would've only be good manners, and not a legal requirement.
The discussion is taking place on Meta at
<https://meta.wikimedia.org/wiki/Talk:Community_Logo>, and all
comments are welcome.
--
Tomasz W. Kozłowski
a.k.a. [[user:odder]]
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
Hello all,
just a quick status-report: The host was re-setuped, the binary dump was
imported, wikidata was imported and both replags reached a point near 0s. As
last step I'm importing now commons since yesterday after Nosy had setup the
SAN-partition. I guess the import will need a few days (if I use the disc-
usage as measure: 20% are already imported).
The replag of enwiki at rosemary (sql-s1-user) is increasing slowly because of
the load (rosemary has to handle now sql-s1-user AND sql-s1-rr). I'm sorry for
this, but I can not change that because of insufficient hardware-resources (=too
few servers).
Sincerely,
DaB.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885
Hello,
the ancient subdomain ts.wikimedia.org has been removed.
All services are reachable and as far as I know used anyway via toolserver.org but
if you still use one of the names in your tools feel informed.
Regards
nosy
Hello all,
few minutes ago I had to clean ortelius' /tmp again because it was nearly full
(there is up to 13GB space).
Using temp-files is a great thing and we all know that clean-up is boring stuff
– but please: If you can not make your tools clean after them self then YOU
have to clean up for them from time to time. /tmp at ortelius contains over
9000 small files at the moment – I VERY doubt that most of them are still
needed. So please look what is still needed, fix your tools and/or write a
cleaning-script. Otherwise I have to write a system-wide script that will
delete all files that are older than x days.
Sincerely,
DaB.
P.S: It is totally ok for Operators to delete files in /tmp if the space
becomes tight.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 0x2d3ee2d42b255885
Hi.
I've notice that there are no keys and so probably no indexes on
toolserver databases. Is this intentional?
I've used below queries - both show no keys/indexes on revision table:
SHOW COLUMNS FROMplwiki_p.revision;
SHOW INDEX FROM plwiki_p.revision;
I've also exported the whole schema and see no indexes at all... The
same for random wiki on s2 - nlwiki_p.
At first I thought this might be do to the replication, but even with
replication you need to select some stuff and only insert latest data.
And besides those are read-only databases so selecting should occur far
more frequently then inserting and so indexing is crucial for
performance. Is it not?
Why am I asking this? Well from a month or so I received a lot of query
kills which should never be killed. Why they should never be killed?
Because they are (or should be) working only on indexes:
* revision.rev_id - should be PRIMARY KEY
* revision.rev_page - should be KEY / FOREIGN KEY
My query is:
SELECT /* SLOW_OK */ MIN(rev_id) as first_rev_id
FROM revision
WHERE rev_page IN (2,4,6,8,12,13,15,16,18,20,21,22,23,24,25,26,28,29,...)
GROUP BY rev_page
I admit the IN list is rather large, but still...
Regards,
Nux.
