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

[Crisses]

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.