I've had great success with Dokuwiki (http://dokuwiki.org/) for basically all the reasons / purposes you've described. It uses flat text files for storage, which initially seemed like a terrible idea to me, but there are numerous benefits. Backing it up is much easier this way, but also it's very easy to make scripts that automatically write wiki articles, just by creating a text file in the appropriate place with the appropriate markup.
I've been quite happy with Dokuwiki's auth system (I have it talking to my LDAP servers). The other wiki I've tried is the one Wikipedia uses, called Media Wiki. It uses a database backend. It was surprisingly difficult to configure. The whole system felt much more cumbersome than Dokuwiki. Simple things like getting it to talk to my vanilla LDAP infrastructure were disturbingly difficult. Dan On Tue, Apr 27, 2010 at 12:57 PM, David Parter <[email protected]> wrote: > > I know, there are a million to choose from. > > Here's the situation: > > Our faculty (and students) want wikis. And they would like us to > support their wikis. They haven't exactly said what that means, but we > can at least define a plausible service offering, and see if that > works. > > Currently we have a ton of different wikis, all in a state of > disrepair/not being maintained or secure, installed by individual > faculty and students. We want to do better. We *need* to do better. > > Some things we already know: > > 1) We think we want a wiki that stores content in a database, because it > decouples the content from the wiki code, makes migration and > upgrades easier, and doesn't rely on the unix file system and which > uid the web server runs as for security. But that maybe a misguided > idea... > > 2) There needs to be some kind of authentication and authorization. This > is where it gets hard -- we don't have to solve every problem with > the same tool, but some of our users just need a handful of wiki > users, so built-in authentication & authorization is ok. some > probably want to leverage our existing authentication (for example, > to allow all their students' access) but that may be ok to defer to a > different solution. > > All probably want both authenticated and anonymous users to be able > to read the wiki (but not post). > > 3) If we have to maintain/support the wiki code, we'd like it to be > secure and reasonable to manage. > > 4) they don't all have to be in the same wiki instance, we can run > multiple instances > > Any ideas? I realize this is not an entirely well-formed request, the > staff person who has been looking into this is rather frustrated, so I > thought I'd get some fresh ideas. > > thanks, > > --david > > ps: the same exact questions will be asked about "blogs", because some > people think a wiki is the way to maintain a web site, others prefer blogs... > _______________________________________________ > Tech mailing list > [email protected] > http://lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
