Hi all
I'm happy to let you know that new hardware has been ordered by Wikimedia
Deutschland and will arrive probably in about two weeks. We will get two new
systems:
* A more powerful web server, to replace hemlock: Sun Fire X4150, 2x Quad-Core
Xeon, 8GB RAM, 2x73GB SAS HDD. The current web server only has two cores.
* Another database server, to be used for S1 (english wikipedia), so S1 and S3
no longer have to share a server: Sun Fire X4250, 2x Quad-Core Xeon, 32GB RAM,
16x146GB SAS RAID.
This should improve performance and give us some head space for growth. Once the
new servers arrive, S3 will be re-imported too, so we will have live data again.
Any ideas for names? To stay with the nightshade theme, how about Jurubeba and
Erubia? Or perhaps we go the "witches' weed" way, with Datura and Mandrake?
Henbane is taken, i think. Amanita sounds nice, too :)
A third server has been ordered, which will also be installed in Amsterdam, but
will not be part of the toolserver cluster. It's a storage server (X4540, 24TB
RAID) that will keep a live backup of all media files.
Cheers,
Daniel
>> hi all
>>
>> many of our tools uses messages from betawiki because they are
>> translated in many languages.
>> But this messages must be synchronized and I think it's not very
>> economically if every user/tool do that self. Because of that I
>> propose
>> to create one database for all users which will be sync periodically.
>
>A database with one table per user? Sounds good.
>
>> What do you think? Are any other users interested for such a db?
>
>I would be interested.
>
>> Greetings,
>> Luxo
>
>Pietrodn
>powerpdn(a)gmail.com
I thought not one table per user, but rather one table for all messages.
On betawiki are a lot messages e.g.
http://translatewiki.net/wiki/MediaWiki:Abusefilter-revert-title/en.
So I would make a table something like
+
----------+------------------------+-----------------------------------------------------+
| LANG | MESSAGE |
TEXT |
+
----------+------------------------+-----------------------------------------------------+
| en | Abusefilter-revert-title | Revert all changes by
filter $1 |
+
----------+------------------------+-----------------------------------------------------+
| de | Abusefilter-revert-title | Alle Änderungen durch
Filter $1 rückgängig machen |
+
----------+------------------------+-----------------------------------------------------+
| fr | Abusefilter-revert-title | Révoquer toutes les
modifications par le filtre $1 |
+
----------+------------------------+-----------------------------------------------------+
the messages which will be synced should be one a list which every
ts-user can edit, so that it's easy for every user to add the messages
he requires.
--Luxo
Hello all,
soon there will be Christmas and we all will eat delicious cookies, watching
the falling snow and kitschy TV-movies, listen to the same old xmas-radio-
songs again and get and give nice presents (if you don't celebrate xmas or
hate it, just eat cookies, ok? ;)) - the best time of year :-).
But before this, the second and last account-extending of the year will
happen. All accounts are going to expire at 1. December. So if you need your
account further, please send an eMail to
ts-accounts200902(a)daniel.baur4.info
before this date. The eMail should contain your login-name in the subject and
in the body. Please do NOT send the eMail to this mailing-list; write a NEW
eMail, DON'T use the answer-function of your eMail-client (because it will
send the eMail to this mailinglist). If you send the eMail to the mailinglist,
you will get the "Can't use his/her eMail-client"-price (and some jokes from
the regulars) and NO extending.
I will send an update-eMail every Sunday which accounts are not extended then,
to get you feedback that I got your eMail and as reminder for others.
The next expire-date will be at 1. June 2010 then.
Sincerly,
DaB.
Hello all,
the debian-security-folks updated php because of some security-problems (if
you like details, I added the report below). The update requires an update and
restart of apache too.
For this reason, I will update and restart php and apache on cassini tonight
(between 1 and 2 o'clock UTC) . The "downtime" of apache should be only a few
minute at maximum. You can see the progress at [1].
Sincerly,
DaB.
[1] https://jira.toolserver.org/browse/MNT-16
--- News for php5 (php-pear php5 php5-cgi php5-cli php5-common php5-curl php5-
gd php5-mysql php5-pgsql) ---
php5 (5.2.6.dfsg.1-1+lenny4) stable-security; urgency=high
* Maximum number of file uploads per request limited
To prevent Denial of Service attacks by exhausting the number of
available temporary file names, the max_file_uploads option
introduced in PHP 5.3.1 has been backported.
Due to the nature of this new option a default limit has been set
to 50, hoping it is sensible enough to not to cause disruptions on
existing services.
The value of this new limit can be changed in the php.ini file.
If you installed the php5-suhosin extension there was a limiting
mechanism in place already. In this case you may want to make sure
the new limit imposed by PHP itself is not smaller than suhosin's.
-- Raphael Geissert <geissert(a)debian.org> Sat, 21 Nov 2009 18:13:48 -0600
--- Changes for php5 (php-pear php5 php5-cgi php5-cli php5-common php5-curl
php5-gd php5-mysql php5-pgsql) ---
php5 (5.2.6.dfsg.1-1+lenny4) stable-security; urgency=high
* CVE-2009-2687: DoS via malformed JPEG images with invalid offset fields
(Closes: #535888)
* CVE-2009-2626: remote memory disclosure via ini_* functions
(Closes: #540605)
* CVE-2009-3292: multiple missing checks processing exif image data
* CVE-2009-3291: improper handling of nul character in CommonName fields
of X509 certificates
* max_file_uploads: prevent, by limiting, temporary files exhaustion DoS
* Add an entry to debian/NEWS about the new per-request file uploads limit
-- Raphael Geissert <geissert(a)debian.org> Sat, 21 Nov 2009 18:28:12 -0600
--
wp-blog.de
Hi guys,
The replication lag of the different copies of the Commons database seem
to be rather high at the moment:
- s1-c: 2d 1h 48m 10s [+0.75 sec/sec]
- s2-c: 0s [-0.00 sec/sec]
- s3-c: 2d 11h 44m 48s [+0.62 sec/sec]
Any idea what's causing this and how to solve this?
Most of the Commons related tools are unusable at the moment, so a lot
of Commons maintenace tasks come to a grinding halt :-(
Maarten
For some reason I'm getting the following error today from scripts in
both my personal account and my shared contests account:
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
I'm attempting to connect to the database "u_kaldari" at the host
"sql". It was working fine yesterday. Do I need to change something in
my config file?
Ryan Kaldari
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
one of the problems we often see on the Toolserver is users accidentally
using too much disk space (for example, broken tools generating 100GB
logfiles). to avoid this happening in the future, we will be bringing
back disk quotas over the next week or two. this will work as follows:
* newly created accounts will get 250MB disk quota
* users currently using less than 200MB will also get 250MB disk quota
* users using more than 200MB will get 1.5x their current usage.
(for example, a user currently using 500MB will get 500 * 1.5 = 750MB
quota).
this is a 'soft' limit; the 'hard' limit will be 2x the soft limit. you
can exceed the soft limit for up to 7 days, which allows people to
temporarily use more disk space if necessary. however, you can never
exceed the hard limit. if the soft limit is exceeded for more than 7
days, you will be unable to use any more space until your use is brought
back under the soft limit.
we recognise that users sometimes need to use more than 250MB of disk
space for legitimate reasons. therefore, if you need more quota than
you have, you may file a request in JIRA (TS project), specifying how
much space you need, and a general description of the purpose (for
example, "storing rendered map tiles"). if, based on the description
above, you think you will need more disk space than the amount you will
be assigned automatically, you should file a request in JIRA now, so
your initial limit is set correctly.
while it's always important to monitor your disk space, and avoid using
space unnecessarily, there is nothing wrong with needing more space than
your current quota allows. please don't feel like you can't run a tool
because it would need more disk space. (however, a tool using 200GB
disk space is probably excessive.)
you will be informed at login time if your disk usage exceeds your soft
or hard quota. you can always check your current usage by running
'quota -v'.
in the past we've had quotas on and off at various times; from now on,
it's likely to be permanent.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAksBleMACgkQIXd7fCuc5vKExwCfSfn1IqwLN6yAOIbArNYXZOpC
AeMAoJMOXlFn/esz226SSjEar3Bz+G3G
=lEwT
-----END PGP SIGNATURE-----
The contests tool that was discussed at the Wikimedia Usability
Meeting in Paris is now fully functional and ready to be deployed for
live use. The only thing I'm still waiting on is the creation of the
multi-maintainer account:
https://jira.toolserver.org/browse/TS-388
If someone could create that for me, I'll be able to get things rolling. Thanks.
If anyone wants to help test for bugs, the current implementation is at:
http://toolserver.org/~kaldari/
Multi-language support is still under development.
Ryan Kaldari
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
here is a list of users using 1GB or more disk space on /home. if you
are on this list, please check if you really need to use this much
space.
72798MB daniel
35143MB sk
17245MB prolineserver
15153MB cmarqu
12103MB dschwen
10760MB saper
9039MB rriver
8983MB cbm
8543MB bryan
8426MB voj
7962MB hippietrail
6936MB werdna
5430MB gmaxwell
4947MB tparscal
4921MB kolossos
3710MB stwalkerster
2976MB darkdadaah
2696MB flacus
2528MB misza13
2266MB mzmcbride
2053MB danny_b
2005MB purodha
1786MB fmaunier
1547MB catrope
1423MB erenrich
1222MB tawker
1161MB joanjoc
1157MB vvv
1064MB magnus
1061MB emijrp
1030MB az1568
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkr/9OIACgkQIXd7fCuc5vIz8ACgwVXmcai4XjAB8G0jRCcQBGMA
7ToAnR+C2arhApjwTTbqc6z5qvLB4Oa9
=Qx/7
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
we need to remount the /home filesystem on the NFS server to change the
filesystem configuration. this will happen at around 2AM UTC, and will
cause 1-2 minutes of outage for the /home filesystem.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAksAO3UACgkQIXd7fCuc5vLm3ACfYUgCaowyGJBEnEar54FncI28
FiQAni6Ofa9dk3wuUFkvQ6rJIFThs4Nl
=eieG
-----END PGP SIGNATURE-----