On Nov 21, 2012, at 1:12 PM, jan iversen wrote: > 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.
I am completely for it. To answer why we have a CWiki. It was setup immediately when we started so that we would have something to use to make plans. It took quite some time for Terry E to get the MediaWiki. When working with infra be prepared to limit operational documentation to runbook style text files. This allows infrastructure team members to understand and act on the wiki if needed from whatever the device they are on. It allows any foundation member to look into how the wiki is setup and configured without any prerequisite software. Terry E tried to fight the text is too old battle with Infra. My word of caution is don't waste your time on that. Thanks for all your energy and time. Best Regards, Dave > > >> >> 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 >> >> >> >>
