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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
after the web server change on Wednesday, we noticed the following
behaviour of regexp matching in rewrite scripts: when using a construct
like "(a|b|)", the regexp will *not* match the empty string. as a
workaround, you can write "(a|b)?". if you do not use this construct
in your rewrite.script, this does not affect you.
we have raised this issue with Zeus and are waiting for a resolution.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkqMZtEACgkQIXd7fCuc5vJSBwCfUqPM5UnwGu2bkaE7QkMejUzq
ljQAnR2Z9uPjlvi54LJd6D5Fp9qsim6J
=ug1G
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
so, sometimes we've had problems with the Toolserver that required an
admin, but an admin wasn't always around. some of these problems are
complicated, but others are simple, and can be fixed by e.g. killing a
process, or rebooting a server. to reduce the chance that something
like this occurs when no admins are around, i have come up with an idea
for a new class of user, which i've termed "Toolserver custodians".
custodians would have a limited set of admin privileges, which i imagine
might include:
* rebooting login/web servers
* killing user processes
* viewing and killing user queries on MySQL servers
because none of these rights allow access to privileged information, we
can assign them more freely than root access, and without requiring
consent from the Wikimedia Foundation.
does this seem like something that would be helpful? and, if we
introduced it, would anyone be interested in such privileges? (we would
probably require a good knowledge of Unix and at least some experience
with system administration.)
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkqWI8IACgkQIXd7fCuc5vKVNgCbBN299o0TyqN6fXqtCHoHRO06
SpYAoKzoJ7n+sgRbJMuPvuCg2O+rk0oH
=gIS7
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
the Toolserver is currently offline due to an issue with the NFS server.
we are working on the issue and have a ticket open with Sun, but at this
point there is no ETA.
if it looks like the issue will take some time to resolve, we will
restore the last /home backup onto another server and use that.
however, that means losing about 12 hours worth of changes, so we will
try to avoid it if possible.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkqSsmMACgkQIXd7fCuc5vKobACfcRyaQMlECY0tIXfTvXTH7IeH
NPQAn2UcW83zd3hTnk8wRU08cvWgD9Ni
=8yRk
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
i have shut down MySQL on s1 (rosemary) for hardware maintenance later
today. this will also affect stable once the maintenance starts.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkqO6UIACgkQIXd7fCuc5vK9XwCdEvzrIQE/oxAt/ankGGUlJImC
TFwAn1zbuwQTYeqx7F23UeusEcUH0BFG
=e4IP
-----END PGP SIGNATURE-----
Hello all,
hyacinth (NFS-server and stable) was rebooted because of problems with the
network. The missing nfs forced nearly tools to stop/halt. The outtage was
nearly 1 hour.
Sincerly,
DaB.
--
wp-blog.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
due to some confusion during Wikimedia's move of commons to a new
cluster, the database was dropped on the Toolserver and is not
available. we will do a reimport at some point to bring it back.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (HP-UX)
iEYEARECAAYFAkqIgcYACgkQIXd7fCuc5vJN8wCfUPsDKqr+yDOxCjDskaJPsYFL
eacAoKbKdoELJ/95jsXUtMpTNT7QBnZ/
=ZOlD
-----END PGP SIGNATURE-----