[Pmwiki-users] multiple wiki idea, revisited

Crisses crisses
Wed Apr 28 05:07:52 CDT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I still have to say I'm very hot on the idea of having a single 
installation for multiple wikis.  And with the idea of making the 
package able to be put into .rpm or deb packages, etc.

terminology:
there is the "server" copy of pmwiki (including pmwiki.php, and the 
standard scripts/ wikilib.d/ pub/ etc. that come with a new 
installation ) -- this is the only copy that should be upgraded when 
new versions are released.  This includes only the files released in 
the normal pmwiki packages as a general rule, but the option to put a 
local/ folder and wiki.d/ for site-wide customizations should exist.  
The idea is that a default location is chosen where programs are 
normally stored for the "server copy" (for example 
/usr/share/pmwiki/pmwiki.php /usr/share/pmwiki/scripts/*.php  
/usr/share/pmwiki/pub/  etc.) -- which each user copy (see below) can 
then access.

Then there is the "user" copy of pub/ local/ wiki.d/ etc. where all the 
customized and user/site-dependent files reside.  Each "user" or domain 
file area on the system would access the server copy of pmwiki.php from 
their own area.  The files would naturally be stored with the user's 
normal html files or in their directory tree, so that backing up is 
easy.  Anyone who wants to put all their wikis in one file tree (such 
as /wikis/domain1/ and /wikis/domain2/ ) would be able to do this 
without hinderance by this idea, as well as the more usual userspace 
format (ex. /home/username/public_html/pmwiki/).

There are 4 users running pmwiki on my server, and some are sorely in 
need of upgrading...and rather than upgrading 4 wikis, I'm very 
interested in installing a single program elsewhere on the server as a 
"server copy" and migrating each site one at a time to be the truncated 
"user copy" style of pmwiki.  Unfortunately I don't feel the wiki farm 
idea works for creating .rpm and deb packages and normal multiuser 
installations as well as this idea, however I don't see any reason why 
both options (wikifarm and multiuser wiki installation) can't be 
available.

The idea is that pmwiki.php is only called by a wrapper php script from 
each of the user's file areas [one makes a wiki or wiki.php script 
(deemed server-parsed by Apache/PHP configuration) that initially 
defines variables that are passed to PmWiki, such as where the calling 
installation resides.].  Whenever pmwiki.php is called it first checks 
for user copies of documents before it defaults back to server copies 
of files (such as pmwiki documentation pages) -- this is normal 
behavior for pmwiki in general (such as checking wiki.d before 
wikilib.d -- in this case it would check the user's wiki.d, then the 
site-wide wiki.d, then the default site-wide wikilib.d areas for a 
page, for example.  Perhaps this behavior can be customizable, but I 
feel this should be the default.).

I also find that this idea is mostly in keeping with standard practices 
for multiuser linux (and even OS X -- with the exception that the 
default script would be /Applications/PmWiki/pmwiki.php I would think ) 
environments.

For example:

Right now my personal wiki runs in
/home/crisses/public_html/pmwiki/pmwiki.php
but is called from
/home/crisses/public_html/wiki  -- which is a php script that calls the 
pmwiki.php in question.

I just need to be able to move the pmwiki.php executible elsewhere, as 
well as the default supporting documents, and keep my personal wiki.d/ 
local/ pub/art/ (that's where I put my art files) etc. in the user 
location.  If I'm able to do this, then there's no reason that other 
wiki installations on the same machine can't use the same pmwiki.php 
file that I do.  So I would have to pass to pmwiki.php where my 
personal wiki.d folder is (or it can locate it by testing where my wiki 
wrapper script is calling it from....if it takes the root of my wrapper 
script i.e. "/home/crisses/public_html/" and appends "pmwiki/" it will 
find my wiki.d folder, my local folder, etc.  If I set up multiple user 
installations similarly, the server version of pmwiki.php should still 
find the proper wiki.d folder for each user.


Security concerns:
A lot of what was brought up as a possible downside to this approach 
was security concerns.  I see no overwhelming additional security 
issues with this idea than I do with the idea of everyone installing 
their own separate wiki installations on a single machine.  I suppose 
that if someone messes up the one server copy of pmwiki.php all the 
wikis might go down at the same time.  And if bugs/oversights in the 
pmwiki.php code introduce security risks, then all the wikis will share 
the same bugs/vulnerabilities.  However, if each user were upgrading 
their wikis at the same time, this would still exist as well.

If PmWiki comes with an implication of security above and beyond that 
which any other plaintext files on a server have, I'd love to hear 
about it.  Encouraging the use of PmWiki on a server doesn't have to 
happen, it can be given simply as an option like any other, and can be 
tested for a while before it's listed as a major feature of the wiki, 
or before it's utilized to create .rpm or deb packages.  I just feel 
that a move towards that is necessary as the wiki creeps towards 1.0 
status.

Hopefully this made sense.  Please feel free to ask for clarification.

Crisses
- -- 
Take into consideration that science is not infallible and that it once 
was based upon beliefs not any better proven than our own theories on 
reality, until someone figured out ways to test the theories...even 
then, the best they can do to prove one theory is to prove that no 
other theory explains the phenomenon in question *better* than it.  The 
only scientific truth is that which has not been proven false.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFAj5B2s+aStMaQ6wQRAjJLAKD0yMgcF4FUAsEuMGCeRT2HtwRgcQCdEHOc
V0OHOh5xeCl2tY7+A/Sls8Q=
=O7qF
-----END PGP SIGNATURE-----




More information about the pmwiki-users mailing list