Hello,
I'm asking why not all tables are replicated? Of course I don't mean
user data - one of recent MediaWiki update introduced new table -
page_restrictions. It means that page_restrictions field from page
table is no more used. Lack of this table prevents me from writing a
tool which will list all protected pages in Wikipedia. It would be
helpful because special page Protectedpages
(http://pl.wikipedia.org/wiki/Specjalna:Protectedpages) doesn't work.
Localhost:
mysql> select * from page_restrictions;
+---------+---------+----------+------------+---------+-----------+
| pr_page | pr_type | pr_level | pr_cascade | pr_user | pr_expiry |
+---------+---------+----------+------------+---------+-----------+
| 1 | edit | sysop | 1 | NULL | infinity |
| 1 | move | sysop | 1 | NULL | infinity |
+---------+---------+----------+------------+---------+-----------+
Hemlock:
mysql> select * from page_restrictions;
ERROR 1146 (42S02): Table 'plwiki_p.page_restrictions' doesn't exist
--
Dodek Dodecki
<dodekam[at]gmail.com>
Recently, I posted a bug to Hemlock's Bugzilla, asking for Magic
Quotes in PHP to be disabled:
<http://tools.wikimedia.de/cgi-bin/bugzilla/show_bug.cgi?id=94>. After
having spoken with DaB., many interesting points were raised, and DaB.
asked me to send an e-mail to the list to ask other toolserver users
their opinion.
Magic Quotes is an infamous feature in PHP that, when enabled,
"automagically escapes incoming data to the PHP script."
(<http://www.php.net/magic_quotes>) That means if somebody types in
"Tom's chair", that automatically becomes "Tom\'s chair". It also does
the same thing to rogue commands in SQL injection attacks, so it's
meant to make PHP more secure. In this respect, it's a good feature to
have when there are programmers of all levels on the toolserver.
However, there are some problems with Magic Quotes:
* Not all programs need Magic Quotes. Programs that send e-mail
including incoming input, programs written with SQL injection attacks
in mind that already use addslashes, etc. do not need Magic Quotes and
suffer a performance overhead when slashes added by Magic Quotes need
to be removed.
* Programmers unaccustomed to SQL injection attacks who first start
off with PHP on the toolserver will learn to write unsafe code, and
make terrible mistakes when they go on to write code in other
languages that don't have something like Magic Quotes.
* Magic Quotes will be removed entirely (or at least disabled by
default) in the upcoming version of PHP, PHP 6. Programs currently
written with Magic Quotes in mind (or programs made by those unaware
of SQL injection) will become prime targets when PHP is upgraded in
the future. Magic Quotes currently provides a false sense of security.
I'd like to ask the toolserver community what it feels about this, and
whether it should be left enabled, or disabled.
Cheers,
Tangotango
(P.S. php_flag cannot be used to disable Magic Quotes on Hemlock, as
PHP runs as a CGI, not an Apache module.)
Hello list,
there is some confusion about the deactivation of magnus' account. This has
very visible impact, as he provides the geohack-tool which is linked to on
over 100000 Wikipedia pages (through every geo coordinate template).
Any info on whats going on?
Best,
Daniel
--
[[:en:User:Dschwen]]
[[:de:User:Dschwen]]
[[:fr:User:Dschwen]]
[[:commons:User:Dschwen]]
Hello all,
non-en was near 0 today. So I dethrottled the sync-en-tool at midday.
Non-en increase now a little bit and en decrease a little bit. I have to
watch this the next days and find good throttle-values for my tool.
Just for your information
Sincerly,
DaB.
--
Blog: http://www.wp-blog.de | PGP: 2D3EE2D42B255885
Hello all,
I have made test with the new version of my en-replication-tool the last
days. At full speed (that seems to increase the non-en-replag) it
decreased the en-replag ~ 80 kiloseconds a day. I have now throttle it a
bit to let non-en-replag decrease to 0 or near to 0.
AFAIS the replication is done correct. To check this, I have made
several comparing-queries between the toolserver- and the wikimedia-db.
The only problem until now was, that my tool forgott 2 binlogfiles (so
the replag-time is not quite correct). I rerun these binlogfiles later,
no data should be lost.
Just for your information
Sincerly,
DaB.
--
Blog: http://www.wp-blog.de | PGP: 2D3EE2D42B255885
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
user : grondin
I want to conserve my toolserver account for my bots. Can you reactive
it, please, now ?
- --
- -------
Bertrand GRONDIN <grondin(a)fr.fm>
http://grondin.ovh.org (un projet mediawiki)
Droit des PTT, contentieux administratif et Fonction Publique
(Textes, dossiers et jurisprudence mis en ligne)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iQIVAwUBRaM3/sXDKTVD3SObAQIc1xAAlTTEc5SfvFQSkHZBiov8iGn0wInyMDIT
yaeabxFKrfxB26Hw8qFbBn71kM+plCsfHzyljWUSq6fXV08jT+tvmmJSw+9gbRlZ
Ejv48d33nxuT0H3AEnwt9FTIIqgsR/CYqhdE9AK1N4ru56XPMMvZ2R0FsHzCJZm5
mR03yp/eLnL0ZrVm097wFcY9K4PGvOv4TnszyAVuCZ60L7sPm0ip9eFNujkvr4mw
aQXjwh1xPqYjXRgFdB2CsVfsdjisz0LKHl7zWHkWw//EIZkL3qrXi/MTBpLoNdiD
soLzJVGBbrxgt+KlOSRGtB4FLiEO5A14CD3/nsz4tYfkWykx1ZakVfM2byg6gqhs
4Azp78dPC/MA02epLjZVfAJ5B/CRAx705iOzKl0hvwZY/t64vuQx2Yd7dEN9r4HL
IE1NrsTdRpDFRSVoKGY7AugwL/d1xWha8Txvq+JCVkKTgHf8LM8/KGwnOOtUNwsn
CA4vV1KRvPqMtpcQlYjKIoMH8r2/LoxC7gGkIaRPWcIZygeOh7QBfG6QXM3BjgFX
EgrPC22Xyzuw8HWD8DE/FKdAuqkwe5WQ2m4GjuWrZgB0TTjwViG0zlakV/BYKB1b
Hbh3Mu0uOaGbn5Cs1ZD4AW1NAEqqtFDE7UXxTYAuGXpdCj3Mc3KlFL88UwQ3mm7W
lNpAcq/DV0s=
=aICR
-----END PGP SIGNATURE-----
Hello all,
tonight at midnight UTC all accounts in the appended list will be
expired (the accounts will not be delete at the moment). If you are in
this list and you going to use the toolserver further, please write me a
eMail with your username as fast as possible (You need not write, for
what you need the account further).
Sincerly,
DaB.
aaronsw
alex
alterego
avar
avatar
banane
bayo
berard
brendan
chrislb
cool_cat
d
daveross
didi
dodek
edwardzyang
erik
fab
gk
grondin
gtfjott
hendrik
hippietrail
hoodedman
icey
jylee
kmartin
onion
orgullo
paul
paulatz
phroziac
pma
porao
quagga
ral315
regi
samkorn
sk
swish
tim
voj
vporao
werdna
wikisign
wmahan
yurik
--
Blog: http://www.wp-blog.de | PGP: 2D3EE2D42B255885
note changes to mailing lists below (web URL, list address and
filtering headers).
- river.
----- Forwarded message from Mark Bergsma <mark(a)wikimedia.org> -----
Date: Thu, 04 Jan 2007 16:48:57 +0100
From: Mark Bergsma <mark(a)wikimedia.org>
Reply-To: mark(a)wikimedia.org
Organization: Wikimedia Foundation Inc.
To: wikitech-l(a)wikimedia.org
Subject: Migration to a new mailing list server
[BCC to all mailing list administrators]
Dear list admins,
Please read the following info carefully.
Currently we are in the process of setting up a new mailing list server
for all Wikimedia mailing lists. The migration of all lists to the new
server is scheduled for Saturday January 6th, around 10:00 UTC. This
will unfortunately cause some downtime for at least the mailing lists
and possibly the rest of the mail system around that time, and will
bring some (user) noticeable changes, which is why I am writing to you.
We have decided to split off the mailing lists from the rest of the mail
system, and put them on a separate hostname/domain, lists.wikimedia.org.
This means that the Mailman web interface will be accessible through
http://lists.wikimedia.org/mailman/... and that all mailing lists will
use e.g. wikitech-l(a)lists.wikimedia.org instead of @wikimedia.org.
Old addresses will continue to work however; all mail sent to the
current @wikimedia.org addresses will be forwarded to the new address.
Newly created mailing lists will *not* get @wikimedia.org aliases
though. The old web interface at http://mail.wikimedia.org will redirect
to the new server. The old static page at
http://mail.wikimedia.org/index.html will disappear; instead
http://lists.wikimedia.org/ will redirect to
http://meta.wikimedia.org/wiki/Mailing_lists/overview on meta, where it
can be maintained by the community instead of just us system administrators.
This also means that the current practice of naming mailing lists with a
"-l" suffix, e.g. foundation-l(a)wikimedia.org, is no longer strictly
necessary. We will however not rename the existing mailinglists (other
than the domain change), as this is likely to bring confusion. Newly
created mailing lists are free to use a name with or without that suffix.
One problem with the hostname/domain change is that many user's mail
filters might break. The Reply-To, List-Id, etc. mail headers will be
changed to reflect the new domain, which might cause them to not be
recognized by user mail filters, breaking their mail sorting or other
inconveniences. Therefore, if you deem it necessary for your mailing
list, I hope you will notify your members of this upcoming change, which
will take effect on Saturday. Even though the old addresses will
continue to work, I hope you will encourage everyone to start using the
new @lists.wikimedia.org addresses for better stability and faster delivery.
The new setup will of course bring a few improvements. First of all, we
hope it will be more stable than the current system is, as it appears
that Mailman is currently the major cause for downtime of our weak,
overloaded mail server.
Furthermore, it will be possible to create mailing lists without system
administrator intervention, by using a Mailman web interface and a
mailing list creator's password. (It is yet to be determined who will
get this password.) Also, no mail aliases will need to be set up for new
mailing lists, the mailing list will automatically and immediately work
under the @lists.wikimedia.org domain once created in the web interface.
And, the new setup will utilize some spam filtering, although this will
likely need some fine tuning. More details on that will follow.
If you have any questions or comments, please send them to me directly.
Thanks,
--
Mark Bergsma <mark(a)wikimedia.org>
System & Network Administrator, Wikimedia Foundation
----- End forwarded message -----
mysqld on zedler will probably be offline at some point during the
night as i'm looking at reconfiguring it to make better use of zedler's
internal disks.
- river.
We all currently have @hemlock e-mail forwarders and mine seems to be
working. However, would it be possible for @tools.wikimedia.de to work
for this purpose too? I think it's rather easier to remember and fits
on ~webspaces on that domain.
Thanks,
Xyrael
--
—Sean Whitton (Xyrael) [sean at silentflame dot com]
Knowledge is power, but only wisdom is liberty.