[pmwiki-users] General Farming Questions

Sivakatirswami katir at hindu.org
Wed Sep 28 20:44:16 CDT 2005

Chiming in on this one...

I Installed a primary installation for PM wiki and set up some  
separated wikis on a farm basis. This is all working fine, and  
important for some things, and not difficult to do. But I also find  
myself in the brink of creating more individual field wikis, solely  
for the sake of keeping them separate from the main collaboration  
wiki, but where the basic model for each is still just some simple  

Typically these involve 2-4 people, non-technical. Each project  
certainly does not require more than a single group, where even the  
concept of "groups" or links to such groups will be over the head of  
the user-client... we are talking "super naive" users here...e.g. a  
few lady pediatricians discussing a web site for fund raising for an  
orphanage: all some of them know is how to use email and open their  
browser and boot MS Word... really, that's it.

Aside from the fact that we want to protect the main site, it's just  
overwhelming for someone who basically knows only how to type, to  
step into a wiki where we have  programmers, major functional  
specifications etc. under development.... even if they have  
"clearance" from a security point of view, they feel intimidated, and  
I can't put *every* single project on the sidebar...so they come into  
the main wiki.. ."where is my work area" either they have to use  
search, or remember what group it was, or have book marked a page  
that I sent them in an email etc. (even this much is too much for  
some kind of users)

Thus, the resort to farm-field wikis when it may not be needed  
administratively, but because its simpler for those users....

So, I would be interested to know your original strategy for "to be  
able to easily support multiple clients under a single wiki, where  
each client could look substantially different from the others."

Right now I'm using standard .htaccess files in the directories of  
the different field wiki directories, with no auth required inside  
the wiki itself (except to edit the side bar or change auth settings)  
I haven't kept with all the developments these past 6 months, They  
get their standard apache http access dialog, they are in... My  
server's web admin (Ensim-Web Appliance for Linux) GUI control panel  
has excellent (albeit slow) admin UI to manage these... everything is  
clear... I can locate .htaccess files from the cmd line and see all  
my authorization controls together at one go.. etc.

1) what is the easiest way to have different groups not see each other ?
2) While, I'm content to let everyone run under Gemini, for "each  
client could look substantially different." are you applying a  
different skin to a different group? If so,  how?
3) easy of navigation is an issue. I have one side bar for the whole  
wiki. It's getting pretty long. If you want the "super naive" user/ 
client to come in, just see their own project-wiki, you want also  
their side bar to have links just within that group with a "home"  
link for "super users" to jump out to the main site as needed (but  
would have to have logged in originally as a "super" user: i.e. one  
who can read and edit any page anywhere...)

4) what is the most facile method to manage the access users, passwords

If there is a particular area in the docs we should study, I'm happy  
to do that home work, but even the PMwiki docs are getting  
intimidating (smile), or shall I say, as it the case with so much  
documentation for any powerful tool, we can read individual docs, but  
still remain anxious about chosing best 'big picture" strategy, being  
blind to the many better options...

[he pauses, goes to PM wiki docs...]  OK, I'm looking at passwords...  
assuming I remove the .htaccess from the wiki web directory ( I worry  
about security there...but we don't want to force a user to enter to  
sets of access codes to get in) then I'm guessing the strategy is to  
set multiple passwords on a wiki group  as defined here /wiki/PmWiki/ 

Set new read password: alpha beta
Set new edit password: beta


So, what happens then if the user with permissions to read and edit a  
particular group logs into the main home of the wiki? (I can never  
get people to book mark or remember specific URL's invariablly they  
call or email .. they must be able to dive in from the top from some  
simple URL that never changes)


if they arrive there, where the main home pages is not one they have  
privileges to read... will they be queried for their password and  
then if they enter it for a particular group, auto jump into that group?

But, now I see we have to set up a special page on each such group...  
not sure that's strategically easier to maintain than separate farm  
directories each with its own .htaccess file... with the latter I can  
easily log in to my web site admin GUI and see all these quickly. But  
the wiki way, each of these special group access admin pages could  
proliferate....It would be "cool" if there were a way where one file  
for the entire wiki that could handle all that... of course, if you  
want to delegate admin of specific groups *also* then that's another  

So... best and most easily administrative strategy for separating and  
providing access for individual clients? Is?


On Sep 27, 2005, at 10:23 AM, Patrick R. Michaud wrote:

> On Tue, Sep 27, 2005 at 01:00:01PM -0600, Allyen E. Wilson wrote:
>> I am not a a very technical computer user. I am exploring using
>> pmWiki as a collaboration tool for my wifes consulting business. We
>> consult in non-technical issues with non-technical people.
>> Will non-technical people be comfortable with using a wiki that would
>> include file uploads/downloads?
> I've managed to use the wiki in a number of non-technical environments
> and people don't seem to have a big problem with the idea of
> file uploads/downloads.  (In fact, this is why I generally refer to
> them as "page attachments" instead of "uploads".)
>> Is a farm the best solution for multiple clients? We want each client
>> to have own wiki and not have access to other clients wiki's. Should
>> I have a seperate wiki installation for each client?
> If each client will have a separate domain name, or needs multiple
> wikigroups, then yes, a wiki farm tends to work best for this.
> However, it's worth noting that my original intent for wikigroups
> was to be able to easily support multiple clients under a single wiki,
> where each client could look substantially different from the others.
> (In my case, I needed the "clients" to be able to create their own
> sections of the wiki without needing to bug me to do it for them. :-)
> Pm
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://host.pmichaud.com/mailman/listinfo/pmwiki-users

More information about the pmwiki-users mailing list