Wiki Farms was: [Pmwiki-users] one installation, multiple wikis

[Patrick R. Michaud]

A few quick responses/questions before longer ones later--

-- Would it be useful, as an interim measure, to assume that wiki farms
   will only be run on Unix-based hosts?  If so, it would then be possible
   to automate much of the farm setup by using a shell script.

-- Alternately, I can bump up the priority of creating a PmWiki
   installation script that runs from PHP, and incorporate farm
   creation as part of that script.  

-- There seem to be only two reasonable places for field wiki.d/ 
   directories--either in a global directory for the farm (this would
   likely have to go in /var or /home/pmwiki somewhere--/usr is
   supposed to be read-only), or in the field admin's home directory.
   The latter is nice because it allows field admins to handle their
   own backups.  

-- There's a whole host of security issues related to the fact that
   with PmWiki's current file-based page storage model it'll be possible/easy
   for a farm administrator to muck with the pages/passwords of someone
   else's farm.  Does this mean we'll need to change the way pages are
   stored, or try to get pmwiki.php to run from a special "pmwiki" account
   (a la Mailman)?  There are just a *lot* of times that I wish Apache and 
   PHP would get their acts together and eliminate this concept of 
   always having scripts run from a separate "www/nobody" account--in
   my experience, both as a software designer and as a host administrator,
   it has caused far more problems and hassles than it prevents.

More later,

Pm


On Fri, Mar 19, 2004 at 01:42:15PM -0500, Crisses wrote:
> Wow, ok, that's quite a response. :)
> 
> So, given the terminology, we'd need to have the Farm Admin password, 
> and the Field Admin passwords for each field...amongst other things.  
> Farm Admin password would be defined in the global/farm config.php and 
> the field admin passwords in each field config.php
> 
> Farm Admin security would partially be passwording by linux itself -- 
> such as files owned by root and the web server.  Anyone with root 
> password is going to be able to muck with the Field stuff on the 
> server/file side of things anyway.  Mucking with things on the Fields 
> via the wiki would be another thing entirely.  PmWiki should probably 
> allow Farm Admins in to muck with Field content.  Many people who own 
> servers are legally responsible for content on the server, so they're 
> simply going to need access to it. :(  Don't love it, but it's how it 
> is.  The original way I was thinking of it would be entirely 
> independent of the people who have server access via root, other than 
> for them to go to the wiki.d directory via the server....I'm willing to 
> discuss that at length, though.  I don't feel it's absolutely necessary 
> for there to be a Farm Admin password for entry to the wikis...the 
> current Admin password as set in the config.php file would turn into a 
> field password...and that's maintaining some of the privacy of the 
> wiki.
> 
> However, I'm concerned with ownership of the local/field "wiki.d" 
> directories -- that might be one way that you're sure that all 
> installations of fields pass the approval of the server admins since 
> they're probably going to need to chown the wiki.d directories to the 
> webserver on behalf of the users.  That's more overhead for server 
> admins, but maybe they want to know when someone's installing a new 
> wiki field on the server.
> 
> (altered a little for paraphrasing...)
> >Let me suggest some starting terms and assumptions:
> 
> 1.  an installation is a "wiki farm", with each individual running wiki 
> being called a "field".
> 
> >2.  Each field is largely independent of the others--i.e.,
> >    a. each field has its own set of WikiGroups
> >    b. links between fields occur via URLs or InterMap links
> >    c. searches are limited to the pages in a field (no cross-field 
> >searches)
> >    d. each field has its own RecentChanges pages
> >    e. each field has its own set of uploads
> >3.  Some configurations take place at the "farm level" (affecting
> >    all fields), while others take place at the "field level",
> >    still others are per-group or per-page within a field.
> 
> Ok, 1-3 I entirely agree upon.
> 
> >4.  We'd like a configuration where (for security reasons) the base
> >    pmwiki/ directory can be located outside of a public_html
> >    tree, and such that a bunch of symlinks don't have to be created.
> 
> This is also for other reasons.  having a single directory -- say 
> /usr/local/bin/pmwiki or whatever -- where the package will ALWAYS be 
> installed, maintained or upgraded allows package management systems to 
> install and upgrade pmwiki on a server, and as long as config files 
> don't need to change, individual fields won't blink when it's done.  It 
> also means users can say "do you have pmwiki?" and if your answer is 
> "yes" they can follow simple setup/install procedures for their 
> individual websites....add a few config files, bug the server admin to 
> chmod the field's wiki.d directory, and they're in business...they 
> don't really have to ask where it is kept (or we'll have a default for 
> config files in any case) per-server.
> 
> It also allows neat and clean backup for the wiki field admins.
> 
> >5.  It ought to be possible for some public items (e.g., skins and CSS
> >    files) to be shared across fields.
> 
> well, since these come with the installation, that's necessary in some 
> ways...they're going to be installed and upgraded with the packages.  I 
> think this should be more than "possible" -- but necessary, so that 
> individual fields can follow pmwiki's documentation and 
> samples/examples, etc.  Maybe if something is in a field's pub 
> directory it overrides the farm's pub directory?  This allows some 
> fields on the server to have very basic installs...and fields that have 
> new templates, etc. can do so without interrupting anyone else's 
> fields.
> 
> >6.  The pmwiki.php file, scripts/ directory, and wikilib.d/ directory
> >    should be shared by all of the fields to simplify upgrades.
> 
> Agreed.  If someone writes custom scripts or uses recipes from the 
> CookBook, they can go with the field config files -- the same way they 
> go with the config files now.
> 
> >7.  There should be clean support for the different URL rewriting
> >    schemes available.
> 
> That would certainly be helpful.
> 
> >The only true restriction that PmWiki imposes at present is that
> >the global configuration file has to be in 'local/config.php'
> >relative to the current directory when pmwiki.php is executed.
> 
> Ok: gotcha.
> 
> >Everything else can pretty well be customized without modifying
> >pmwiki.php (although perhaps not trivially).  And of course I'm
> >on very good terms with the pmwiki.php author, so I can probably
> >get some changes made to pmwiki.php if needed.  :-)
> 
> LOL
> 
> >Crisses, do you have an idea of what would be an ideal install sequence
> >for someone wanting to set up a field in a wiki farm?
> 
> As simple as possible, with as much either provided already or easy to 
> create as possible.  As few steps as possible.  like:
> 
> 1) download a wikifield.gz2 that contains the config file and the 
> (empty) wiki.d folder, maybe with a directory structure and sample 
> files for skin templates and css that they're free to alter if they 
> wish to.
> 2) gunzip2 in proper directory
> 3) tweak one config file (pretty much the same way we all have to right 
> now for normal installs of pmwiki)
> 4) if possible the config file could also be the wrapper for the 
> pmwiki.php file -- doable with a "DO NOT ALTER BELOW THIS LINE" 
> directive.  If not, the wrapper file might have to be configured at 
> this step...see comment below...[may also require adjusting the 
> .htaccess file for the directory in question to recognize the handler 
> of the wrapper file as .php]
> 5) yell for an admin to chmod the wiki.d folder [may also need the 
> admin to change the handler of the wiki wrapper in the folder to php in 
> Apache's httpd.config file, if the person doesn't have per-directory 
> access to add handlers/types]
> 6) load in a browser-- should be done.
> 
> the optional .htaccess/ httpd.conf adjustments depend on whether or not 
> file name "wiki" is changed in the apache config files as a matter of 
> course for the whole server...and whether the individual decides to use 
> a different name for their wiki wrapper.
> 
> It's also possible to make a temporary php file that asks questions in 
> a browser and writes the php config file in question ;)  It can be 
> deleted once the installation works properly...but this seems chancy 
> from a security perspective.
> 
> the .gz2 file is not necessary.  instead we could have explicit 
> instructions and a sample php file in the instructions.  However, it 
> would probably be easier for laypeople.
> 
> We'd also need to work on a "upgrade" method for people changing from 
> one scheme to the other...if the directory structure is very similar, 
> it shouldn't be too hard...you install the wrapper and probably just 
> take the config.php to make your own field configs, and when it's 
> working, you delete the old pmwiki.php, wikilib.d/ and scripts/...I 
> think that about sums that up.
> 
> >  I see the key
> >difficulties in configuration coming from setting up the URL 
> >redirections
> >for the pmwiki.php script, the pub/ directory, and the uploads/ 
> >directory.
> 
> There would be no URL redirection if the field's "wiki"(php) file 
> exists tangibly in the person's HTML directory.  It automatically gives 
> the smooth URL with wiki and if someone still wants it to say 
> "pmwiki.php" in the URL so it doesn't break people's bookmarks, they 
> can rename the field wrapper file to "pmwiki.php" and have it include 
> the Farm's pmwiki.php.  The URLs for the field pub/ directory and 
> uploads/ directory don't need to change from the older installation. -- 
> in fact, they probably shouldn't for the newer installation either.
> 
> >>Are these files & folders defined by pmwiki variables or are they flat
> >>calls to certain files?  can a local folder contain, for example,
> >>"ofobscurityconfig.php" and "kinhostconfig.php" and the wrapper for 
> >>the
> >>respective wikis contain overrides [...?]
> >
> >At present configuration variables cannot be easily set in a wrapper,
> >but I can easily modify PmWiki to allow this.
> 
> I can't think of a better place to tell PmWiki that it's working in a 
> field environment instead of an isolated and thus default/global farm 
> environment.  I think it is less of a server drain that way...
> 
> in the wrapper: set "this is a field"; field config file is at;
> in pmwiki.php: if"this is a field"; set these variables from the field 
> config file;
> 
> But it would have to figure out where the wiki.d folder is etc.  it 
> could be a default within the html folders, using the same structure 
> they have now:
> public_html/pmwiki/wiki.d/
> public_html/local/config.php
> public_html/wiki           // the wiki wrapper
> public_html/pmwiki/pub/skins/
> 
> i.e. very similar to how it is now, with the one exception that the 
> wiki php file is outside the pmwiki directory...
> 
> People always want to customize this stuff anyway.  Declaring these 
> variables isn't much more than any other cgi style script asks, and 
> you're getting a lot out of this program/script.
> 
> Isn't there the option of using environment variables from the wiki 
> wrapper file itself?  (i.e. "what directory is the file just called 
> in?" and assuming that "/pmwiki/wiki.d" etc. is properly within that 
> folder...) rather than asking Joe Whoever to explicitly set them -- 
> then you can require that people either keep the default structure OR 
> define the variables...advanced users who want to muck with things will 
> have to deal with setting variables and usually don't mind at 
> all...they want it the way they want it and appreciate that you thought 
> ahead that they're going to want to change things.
> 
> >  I think your question/comment
> >of making it possible for individual user accounts to set up wiki 
> >fields
> >in a global wiki farm is a great approach for being able to resolve
> >these issues.  In this scenario, the system administrator becomes the
> >farm's wikiadmin, while each user can become a field wikiadmin.
> 
> Yes.  That's the general idea.  I'm a savvy computer user with a little 
> php skill, etc. but not everyone is.  My new webhost knows I am and is 
> willing to give me up to and including root access (Gods, he must be 
> crazy and I haven't accepted ;) ) but I am very VERY interested in 
> seeing this become something easy for the layperson to set up, and for 
> the system admin to install/maintain.  I had to leave a webhost because 
> they floundered in indecision about changing over the wiki.d ownership 
> to the webserver.  I don't *blame* them, but it meant I had to bail 
> from my hosting service, because I've invested too much time and work 
> in the wiki content to switch back to flat files.
> 
> Oh, and now that I'm a debian fanatic, I want to see it in the debian 
> tree ;)  Hey -- is it GPL? LOL
> 
> >So, my question above becomes:  Given that there's a wiki farm already
> >installed and operating on the system, what steps would we want someone
> >to take to set up a wiki field in their account and become the 
> >wikiadmin
> >for that field?
> 
> You got it, above.  I think a 5-7 step process is pretty reasonable.  
> It might be a little work keeping the overhead on those steps low -- no 
> step too complex and taxing on the user.  The fewer things they have to 
> do , the less they'll screw it up :P
> 
> Crisses
> ----
> well you got me working so hard lately, working my hands until they 
> bleed,
> if i was twice the man i could be, i'd still be half of what you need.
> still you lead me and i follow -- anything you ask you know i'll do.
> but this one act of consecration is what i ask of you --
> (ringfinger) promise carved in stone, deeper than the sea.
> (ringfinger) sever flesh and bone and offer it to me
>  -- Nine Inch Nails, Ringfinger.
> 
> 
> -- 
> Pmwiki-users mailing list
> Pmwiki-users at pmichaud.com
> http://pmichaud.com/mailman/listinfo/pmwiki-users_pmichaud.com