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
Hi,
There is currently an open issue that is preventing updates to the
Toolserver email configuration from propagating to the mail server. This
means that email forwarding for newly created accounts is not working, and
changes to your Toolserver email address (using setmail) will not take
effect. The issue is somewhat complicated and I will be away most of this
week, so this won't be fixed until next week at the earliest. Sorry for the
inconvenience.
This issue is being tracked in JIRA as MNT-65.
- river.
Hi,
PHP was upgrade to 5.3.1. At the same time, the PHP PDO MySQL module was
enabled. This should have no impact on users (unless you want to use PDO).
- river.
Hi,
You can ignore this message unless you have C or C++ programs or libraries
linked directly against 'libjpeg', the IJG JPEG library. (The vast majority
of users will not have any such programs.)
libjpeg on the Solaris systems (willow and wolfsbane) has been upgraded from
version 6b to version 7. This means the old libjpeg.so.62 no longer exists;
it is replaced with the incompatible libjpeg.so.7. You will need to
recompile and relink your programs to use the new libjpeg.
This doesn't affect programs that use libjpeg indirectly, e.g. via the
ImageMagick C/C++ interfaces, since all TS-provided software depending on
libjpeg has already been relinked.
- river.
Hello all,
yesterday we noticed, that our s1-cluster (that's enwp) is corrupt (that means
that we don't have all data and/or not in the right way as the master).
That means that we will need a re-important soon. Please look at
https://jira.toolserver.org/browse/MNT-104
to see the process.
Sincerly,
DaB.
P.S: River told me now, that we can perhaps minimize the downtime of s1 this
time - we will see.
--
wp-blog.de
Hi,
MySQL on yarrow (s3, s4, s6) crashed and restarted. This is a known problem
and has happened before; however, we've now made a configuration change that
might prevent it from happening in the future.
This issue is being tracked in JIRA as MNT-58.
- river.
Hi,
The web server wolfsbane will be rebooted later tonight to change a
configuration setting. Web tools will be offline for about 10 minutes while
this is in progress.
This issue is being tracked in JIRA as MNT-90.
- river.
Hi,
As announced two months ago, we are planning to EOL the stable server in
favour of multi-maintainer projects on the normal Toolserver. The following
projects are still running on the stable server:
* geohack
* wma
* delinker
We intend to repurpose the hardware currently used for the stable server to
provide redundancy database replication, but this can't happen until all
projects have migrated off the stable server.
- river.
Hi,
So, currently we have two login servers, one which runs Linux and one
which runs Solaris. This greatly complicates system administration (as
everything has to be done twice), and confuses users, since things are
different between the two login servers, and between the Linux login
server and the web server.
Since deploying the Solaris login server (willow), we've made quite a
few changes to improve the user experience for users coming from Linux,
to the point that I think most users would not have a problem using the
Solaris servers.
With this in mind, it might make sense to dispose of the Linux login
server entirely, and convert it to Solaris. But before we consider
this, I need to know if there's anything still missing from our Solaris
environment which compels users to use the Linux server instead.
So: if the Linux login server were to go away tomorrow, what (if
anything) would you miss?
- river.