Hi. I just posted (really asked a question) on this same subject on another thread -- vis a vis what's going on with the wiki.
So, what IS going on? Anybody? I think (thought?) Pedro was kind of coordinating the test of Confluence with the infra folks but ??? On Fri, Sep 16, 2011 at 5:27 AM, Rob Weir <[email protected]> wrote: > On Fri, Sep 16, 2011 at 8:20 AM, TJ Frazier <[email protected]> wrote: > > On 9/15/2011 15:30, Rob Weir wrote: > >> > >> On Thu, Sep 8, 2011 at 6:11 PM, TJ Frazier<[email protected]> > wrote: > >>> > >>> On 9/6/2011 18:12, Rob Weir wrote: > > > >>> <snip> > >>>> > >>>> Another option to consider is that of content translation: MediaWiki > >>>> to Confluence. Remember. Confluence is fully supported by Apache > >>>> Infra. We would also find a lot of people on the list who could help > >>>> write and test wiki text conversion code. It is just string > >>>> manipulation, right? How hard can that be? Even I can help with > >>>> that. > >>>> > >>>> But seriously, the MW plans were always precarious. We did not have a > >>>> deep bench of expertise on the sys admin side of that package. Even > >>>> if we have a volunteer or two step in now, aren't we still rather > >>>> thin? Wouldn't we still be one "life change" away from being back > >>>> where we are now? But if we can figure out a content-level migration > >>>> to Confluence wiki, then we would have something much more sustainable > >>>> long term. > >>>> > >>>> Just an idea. > >>>> > >>>> -Rob > >>>> > >>> My question is, "Is it worth looking at Confluence Wiki /at all?/ " > >>> > >>> Q: Why does everybody use Cwiki? > >>> A: Infra supports it. > >>> Q: Why does Infra support Cwiki? > >>> A: Everybody uses it. > >>> Hmm. "Very interesting," as Arte Johnson used to say. > >>> > >> > >> This is true, but there is more here than may be immediately evident. > >> > >> The fact that a service is widely supported by Apache Infra is very > >> important. Remember, we no longer have Oracle's full-time web admin > >> staff to mind the OOo severs. We'll soon be independent of that and > >> Apache will be responsible for routine maintenance, upgrades as well > >> as responding to problems. > >> > >> And we must not underestimate the potential for problems. Apache is a > >> high profile target. So is OpenOffice. Mix them together and the > >> question is not "if" someone will attack our website and try to take > >> it down. The question is "when?". > >> > >> I don't say that to scare you. Just to point out reality. > > > > But is it reality? > > > > Apache has no big lists of credit-card numbers, no treasure-trove of > secret > > diplomatic cables, no maps of nuclear weapons targets or locations. What > we > > do have is software source, and that's free for the asking. In short, we > > have nothing that's worth a "commercial" (money-seeking) cracker's time. > > > > AFAIK, the ASF takes no stand on political, religious, or other > ideological > > controversies. We should not draw fanatics, either. > > > > The one credible threat I see is the possibility of inserting malware > into > > an Apache distro. That should not be possible through the wiki — any > brand > > of wiki. > > > > If you look at recent attacks, the trend appears to be to exploit a > XSS vulnerability (or other0) to get root access, get the user account > data, typically user name, email address and hashed password, then do > an offline rainbow table attack on the hashed passwords, and use that > information to break into other accounts on other systems, since many > users use identical login/password on multiple systems. > > It isn't really about the content of the wiki per se. It is the account > data. > > > (Not to mention that any target on our backs wouldn't even fill the > ten-ring > > of the target on Wikipedia – one of the most popular sites in the world. > > Their code may not be bullet-proof, but it's close.) > >> > >> It is worth looking back at the note from Mark Thomas [1] sent to the > >> list back in July, to understand what it means to be using an > >> unsupported server app at Apache: > >> > >> "The much more important question is who will support it. There have > >> been far too many examples of projects requesting a service, promising > >> to help support it and then never being heard from again when it needs > >> maintenance. If the current maintenance is performed by Oracle rather > >> than the community there will be concerns about the viability of that > >> model. > >> > >> On a related note, infrastructure will not tolerate project managed > >> systems that are insecure. We will shut them down first and ask > >> questions later. Projects are expected to keep on top of security for > >> the services that they manage. We do arrange things so projects can > >> only shoot themselves in the foot but will still expect security to be > >> maintained. " > > > > I *assume* that the issue here is the timely installation of > > security-related updates, a high-priority maintenance task. Such updates > for > > FOSS components do happen – witness the recent flap over digital > > certificates – but they are quite rare. With the exception of the > MediaWiki > > code itself, updating the other components should be a cookbook task for > > anyone with sufficient karma and fu to have root access. It is generally > > simple enough that even I would take a crack at it (working slowly and > > carefully, and reading the instructions *first*. And not taking any > > "obvious" short-cuts ;-) ). > > > > Updating the MW code is a problem, with extensions, local mods, and > > leading-edge policy to consider. While there is expertise in the > background, > > we have not identified any active contributor (apparently including > Infra) > > with the expertise to JFDI. > >> > >> I fully acknowledge that moving to CWiki would result in an imperfect > >> translation of the content that will take additional effort to clean > >> up. And that moving to MWiki will be faster. But we only need to > >> migrate once, right? But we need to maintain this for the next 10 > >> years. That is why I talked about CWiki being "more sustainable". > >> Sure, it is pain now. But we'll have much more help at Apache going > >> forward if we're using the same software that everyone else uses. If > >> we use MWiki, we may migrate faster, but we'll be shut down at the > >> first sign of a problem. > >> > >> I'm not saying the MWiki is unworkable. But if we really want this to > >> work, long term, then we should be looking to have a solid base of > >> admin experience to help maintain it in the long term. Not just help > >> migrating, but longer term. And not just one person, but maybe 3 > >> people who know it well and another 2 who can start learning it now. > >> Remember, the OOo wiki was not just a little thing on the fringes of > >> the project. It was at the center of how the project was run. Having > >> a sustainable wiki is essential for the AOOo project. > >> > >> [1] http://markmail.org/message/b23uko3fro5ijqkz > >> > >> > >> -Rob > >> > > <snip> > > Long-term sustainability is definitely a problem. Fortunately, it is a > > long-term problem: we have time to find a solution. For instance, maybe > > someone(s) at MWF would be pleased to take an active role at ASF. (Or, > maybe > > not.) We could ask. > > > > Personally, I am only one of the "start learning" folks. I don't want to > be > > in a single-point-of-failure position; I am pushing 70, and 70 is pushing > > back. > > > > Should conversion ultimately be required, it is worth taking a look at > > moin-moin. That /is/ supported by Infra, and it is FOSS. If we really > need > > some feature, we can add it; python expertise should be widely available. > > -- > > /tj/ > > > > > -- --------------------------------------------------------------------------------------- MzK "There is no such thing as coincidence." -- Leroy Jethro Gibbs, Rule #39
