thanks for your reply. On 21 November 2012 21:17, TJ Frazier <tjfraz...@cfl.rr.com> wrote:
> On 11/21/2012 14:24, jan iversen wrote: > >> having looked at the mediawiki pages, especially the amount of updates, >> and >> make a trial installation my my private server, I know I can cope with the >> maintenance problems (but NOT with spam attacks, that requires more than >> just one person). >> >> If the community agrees to it, using the lazy consensus, I volunteer to >> make maintenance of the mwiki (wiki.openoffice.org). >> >> If nobody object I will very fast do the proposed mysql changes: >> - remove accounts with no contributions during the last year. >> - removing all new users within the last 2 weeks. >> and prepare an update to the newest version, (and as Alexandro suggest >> have >> a test server) which first run it on my own ubuntu, before going live. >> >> The big job done by just a few people to counter attach the spam attack, >> is >> really a GREAT JOB, and even if I do maintenance such skilled people would >> still be needed. >> >> I would need a user, that has mysql root access as well as being able to >> modify php scripts (for installing new version) and restarting apache. To >> get that karma I would need help, since I am sure such a right is only >> granted with PMC approval (which is the right way!!). >> >> The page that Rob suggest is of high value, and would be a great way of >> having a mini-plan for what to do on the wiki. >> >> I have one question though, why do we have cwiki and wiki....I might be >> the >> only one, but I get confused where to find which information, so maybe we >> should decide to have all information in just one wiki ?? >> >> have a nice day/evening. >> Jan I. >> >> Jan, > > The urgent thing is the one-line change to block account creation, as > shown at [1], applied to LocalSettings.php. > I agree totally to that. > > [1] <http://www.mediawiki.org/**wiki/Manual:Preventing_access#** > Restrict_account_creation<http://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_account_creation> > > > > The karma you need can only be granted by Infra. Go ahead and ask (JFDI): > if anyone on the PMC objects, I feel certain we will hear about it. > I like JFDI since Rob informed me politely about its meaning. I have made a JIRA ticket: https://issues.apache.org/jira/browse/INFRA-5548 so if anyone disagrees now is the time. > > JIRA (like the Confluence wiki, "cwiki") is a proprietary product for > which ASF has a free license. Historically, OO.o used the FOSS products > Bugzilla and MediaWiki. I cannot speak to the virtues of JIRA, never having > used it, but IMHO cwiki is an inferior product compared to mwiki, and > trying to convert mwiki to cwiki (which was discussed) is an enormous and > unrewarding project. So we didn't. > > To file a JIRA ticket, mouse around on the Infra web site; you'll get > there. You will probably need your ASF name and password. I would guess > that your user name on the Linux system underlying mwiki will be your > Apache name. > On upgrades, Clayton Cornell (the maintainer under Sun/Oracle) sent me the > following caution: > > By the way, tuck this away.. it's quite important... if/when you >> upgrade to 1.17 or higher, you really have to test it offline in a >> staging server. The UTF-8 implementation has been tightened up, and >> older Wiki databases are being hit hard... in particular when there >> are tables defined as Latin1 (the old default), with UTF-8 content. >> When the database is exported/converted for the update to MW1.17 or >> higher, the UTF-8 content is "converted" when the table is converted >> from Latin1 to UTF-8. The result is that the existing UTF-8 content >> ends up double encoded and is basically unusable... this has broke a >> LOT of wikis and very few people seem to know how to fix it (that >> reminds me, I should post how to fix it somewhere). You can avoid the >> problem by checking up on the database prior to the upgrade and doing >> a little tweak in the upgrade process (MySQL magic) to fix the badly >> encoded tables... and i'm pretty sure that the OOo Wiki dB has this >> problem. >> > Thanks for warning me. How does this sound to you: When I get root access, I do the following: 1) modify localsettings.php, and inform you all. 2) copy the mysql db to my ubuntu server, and play with the scripts until they work and I can remove users as stated in your earlier e-mails. 3) search the db for Latin1 and grep the data for UTF-8 content, when found I change the header to UTF-8 4) test the pages locally 5) backup the production Db, and lock it for changes, after a fair warning (where/how long) 6) upgrade the php/db on production, and update with the changed pages. 7) cross my finger, close my e-mail and hope for the best :-) (this was a danish joke, I will do the upgrade, at a time where I am available). 3) I make the update local on my machine, an > > I have asked him to send the "MySQL magic", and will forward it. > > /tj/ > > "Ask me for anything but time!" -- Napoleon > > > >
