Wiki Farms was: [Pmwiki-users] one installation, multiple wikis
Fri Mar 19 11:42:27 CST 2004
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
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
> 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
> 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.
> 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. :-)
> 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
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
> for the pmwiki.php script, the pub/ directory, and the uploads/
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
>> 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
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/wiki // the wiki wrapper
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
> 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
> 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
well you got me working so hard lately, working my hands until they
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.
More information about the pmwiki-users