[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
project...
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.
so,
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/
Passwords
Set new read password: alpha beta
Set new edit password: beta
etc.
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)
www.himalayanacademy.com/wiki/pmwiki.php
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
story.
So... best and most easily administrative strategy for separating and
providing access for individual clients? Is?
Sivakatirswami
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