...

Hi Everyone,

Last night, we received an alert of a possible XSS or iFrame injection issue somewhere on www.opensuse.org or one of the wikis. We temporarily redirected the site and wikis to a maintenance page for about an hour while we assessed the risk and impact of the alert. After learning a little more, we felt that it was not a legitimate alert, and we brought the site back up. I am still waiting on a full report, so that we can figure out what to do for a long term solution.

As a precaution, I am working on an immediate upgrade path to the latest version of Mediawiki and its plugins. I will also be working on upgrading Apache to 2.2.21 on the www and wiki servers.

-Matt

Thanks Matt.

One day, someone should also have a look at the lizards.opensuse.org wordpress instance. Which start to be quite outdated now.

I completely agree. In fact, I have started doing those yesterday on the test servers. There is a minor glitch in the theme with the latest WordPress, but once that is resolved, we should be able to get that on production very soon. -Matt

Hi Christian, I know you have suggested this before. In all honesty, it doesn't really matter whether I use subversion or not, especially with the way that we have to upgrade these wikis. Getting the MW core code is the easy part. I just download, extract, and move a couple of files over. The vast majority of the time is spent in downloading and installing the extensions. I use subversion for as many of them as I can, but that is suitable for maybe half of the extensions that we use. What would be most helpful is to re-evaluate the extensions that we are running and see if we can get rid of a couple. That would go a long way for making the upgrades easier. Thank you, Matt

...

...

Christian Boltz 11/6/2011 2:02 PM >>> Hello

Am Freitag, 4. November 2011 schrieb Matthew Ehle:

As a precaution, I am working on an immediate upgrade path to the latest version of Mediawiki and its plugins. I will also be working on upgrading Apache to 2.2.21 on the www and wiki servers.

Now that the wiki code is hosted in git: You probably remember my recommendation to use a SVN checkout of the mediawiki stable branch [1] (which can be updated with a simple "svn up" or "svn switch" later, even without breaking local modifications). The upgrade would be a good opportunity to do that _now_, to make future upgrades easier. I have another request: Can you please install the ReplaceText extension? It would make several tasks much easier, for example the replacement of style= with class= in pages that are based on a page template. (The extension is by default only available to admins, and that's a good default IMHO.) See http://en.opensuse.org/Help:CSS_cleanup and http://en.opensuse.org/openSUSE:GCI_tasks#Replace_CSS_style_with_CSS_classes... for details about the cleanup plans. We hope a Google Code In participiant will do the cleanup in the templates. The CSS cleanup in the content pages based on a page template page will be done by a wiki admin (using the ReplaceText extension) - we don't want to give a newbie admin rights ;-) Regards, Christian Boltz [1] if you don't remember all details: - http://lists.opensuse.org/opensuse-wiki/2010-09/msg00053.html - http://lists.opensuse.org/opensuse-wiki/2010-09/msg00058.html - or just ask me ;-) -- ToFus entstehen oft aus der Bequemlichkeit des Anwenders heraus, der die Mail unbearbeitet dann übernimmt und seinen Senf ganz dick oben aufs Wurstbrot schmiert (oft auch, wenn Honig drunter war). [Thorsten Kettner in suse-linux]

Hello, Am Montag, 7. November 2011 schrieb Thomas Schmidt:

On 07.11.2011 16:18, Matthew Ehle wrote:

...

I know you have suggested this before. In all honesty, it doesn't really matter whether I use subversion or not, especially with the way that we have to upgrade these wikis. Getting the MW core code is the easy part. I just download, extract, and move a couple of files over.

That's still more work when compared to "svn up". And even more work if you have to modify one of the mediawiki files - you have to (remember to) patch it again at every update. (I'm quite sure index.php is modified for iChain, and MultiBoilerplate contains a patch from me to support different templates per namespace) I know that using svn doesn't change much on _this_ update - but it will save you time on the _next_ updates. Counter-question: what's the advantage of using the tarball? ;-)

...

The vast majority of the time is spent in downloading and installing the extensions. I use subversion for as many of them as I can, but that is suitable for maybe half of the extensions that we use.

Yes, I know there are several extensions that consist of only a single file (which is not available via SVN). OTOH, for example MultiBoilerplate is available via SVN, and we are using a modified version (with a patch from me). Just updating it with "svn up" or "svn switch" would save you lots of time here.

...

What would be most helpful is to re-evaluate the extensions that we are running and see if we can get rid of a couple. That would go a long way for making the upgrades easier.

As you have seen in the second half of my mail, I'm even requesting a new extension (ReplaceText) to make maintenance tasks like the CSS cleanup easier. Also the WikiEditor would be a nice feature ;-) (and will be shipped with 1.18, if I got the beta release notes right). Removing extensions is a very hard task - I had a quick look on them and think all of them still make sense. In other words: nothing to remove. The only exceptions might be SelectCategory and MultiUpload because they are already disabled ;-)

the problem we face with hosting the wiki code in git is, that our production system doesn't have git installed (only svn) and it would be quite complicated to do so because of datacenter policies etc... I think a possible solution could be githubs subversion client support[1]. I already pushed our current code state there[2], so we can evaluate if this is an option for our deployments. If Matthew confirms that this works, we can go ahead and set up the repo at https://github.com/openSUSE/wiki .

That sounds like a good idea - and brings up an interesting question: If we push SVN checkouts to git, they will include .svn directories. What will happen if you check them out using svn? ;-) (Please test this and tell me the result.)

@Christian: Could you help us doing your requested changes in the github repo once it's at its final place? You are probably the one of us with the most knowledge and experience in mediawiki,

Thanks for the flowers ;-) I should add that the wiki I'm maintaining is quite small when compared to the openSUSE wiki: only one language, less visitors (54000 total views for main page - en.opensuse.org mainpage has 1.6 million views), less than 90 registered users etc. For example, I never had to think about memcached. Oh, and I even have some more extensions [1] installed ;-)

so it would be nice if you could help us :-)

I have the "usual" problem - days with only 24 hours ;-) I'll help whenever possible, but it really depends on what other things I have on my schedule. BTW: skins/bento/css_local/style.css seems to contain a bug ;-) Line 471 is thumb tright { I'd guess there are some dots missing (".thumb .tright"), but that's only a wild guess because I don't know where this style should be used. : Regards, Christian Boltz [1] see http://hortipendium.de/Spezial:Version Just in case I shocked you: most of the additional extensions don't make sense for the openSUSE wiki for various reasons ;-) -- Wenn ich eine SuSE-CD an ein Schwein binde und dieses trete, laufen KDE & Co. auch ohne RAM recht schnell. [Robin S. Socha in de.comp.os.unix.linux.newusers] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org

Hello, Am Dienstag, 8. November 2011 schrieb Thomas Schmidt:

On 08.11.2011 00:37, Christian Boltz wrote:

...

That sounds like a good idea - and brings up an interesting question: If we push SVN checkouts to git, they will include .svn directories. What will happen if you check them out using svn? ;-) (Please test this and tell me the result.)

That won't work, as the .svn directory would get overwritten. I just tried that, the error message is: "svn: Failed to add directory 'trunk/extensions/test/.svn': an unversioned directory of the same name already exists"

:-( Can you send a bugreport to github? Maybe they find a way to fix it ;-)

So it seems we can't use svn checkouts in our repo currently.

At least not without a workaround ;-) What about this: rename the .svn directories to .upstreamsvn and add .svn -> .upstreamsvn symlinks, but do not add the .svn symlinks to git (can git automatically ignore the symlinks named .svn in all subdirectories?) Those symlinks would be easy to create with a script (run it on your git checkout), and are not needed on the webserver. Also renaming the .svn directories to .upstreamsvn on a fresh checkout would be easy with a script. I just tested this - it looks like svn happily accepts the symlink and continues to work. What do you think about this idea?

...

I have the "usual" problem - days with only 24 hours ;-) I'll help whenever possible, but it really depends on what other things I have on my schedule.

I'd like to add you as committer to our wiki repo, so you can do those changes directly and we can test it together afterwards. Do you already have a login at github?

I was afraid of that question, and to make it even worse, you caught me on IRC and tricked me to tell you my username ;-)) Regards, Christian Boltz -- chliEßlichle sendi emeiSt Enleut ehier mehralsdreIpo Stingsa Mtag sOd Asesdoch et. Waserm üdentwärdenkahnimmerrattentsumÜßenw aßIrge nDeinezUs Ahmäst ell unkvonbU chst, abensagenw iel ;-) [Tilman Ahr in dcoulm zum Thema "Rechtschreibfehler stoeren doch nicht"] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org

Hello, Am Montag, 14. November 2011 schrieb Thomas Schmidt:

On 11.11.2011 01:00, Christian Boltz wrote: [using a SVN checkout of MediaWiki and the extensions]

...

At least not without a workaround ;-)

What about this: rename the .svn directories to .upstreamsvn and add .svn -> .upstreamsvn symlinks, but do not add the .svn symlinks to git (can git automatically ignore the symlinks named .svn in all subdirectories?)

Those symlinks would be easy to create with a script (run it on your git checkout), and are not needed on the webserver. Also renaming the .svn directories to .upstreamsvn on a fresh checkout would be easy with a script.

I just tested this - it looks like svn happily accepts the symlink and continues to work.

What do you think about this idea?

I think it sounds complicated,

Yes, but the complicated part would be done by a script (which I'll happily contribute, I expect <20 lines) + adding ".svn" to gitignore. You/Matthew would need to run this script on the "development" machine: - after git clone to "enable" the .svn directories - same after git pull, if new directories were added by someone else - after running svn co / svn up / svn switch (if new directories were added)

but in the end who does the mediawiki updates decides what is the best workflow to do it. At the moment this is Matthew ;-)

I know, and I'm not too keen to take over his job ;-) (It might also be somehow problematic - even with public read access to the staging servers (thanks!) getting write/shell access for non-SUSE people might be harder.)

For me it's important that it's documented how we do it, so that not only one person is able to do it.

Full ACK. Regards, Christian Boltz -- Jungs. Mit dem Argument kann ich kaputte Autos verkaufen und dann erklären, daß Fahrradfahren eh viel gesünder ist. [Peer Heinlein in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-web+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-web+owner@opensuse.org