> I think so too. I've added some suggestions.
Well, I'd say that's close to an entire rewrite. I followed the "<
keep" and "< suggest change" instructions to the letter. Considering the
time zone differences between us, I won't have time to look at it before the
1.4beta3 deadline.
Do you want me to mark this up for DocBook and update the cvs? I know
there was some discussion concerning commits to the cvs tree. I'll figure
out what file format Alexander needs and forward him a copy.
Ron
** Introduction to SiteGroup Virtual Database Environments
The Midgard SiteGroups feature allows multiple, non-related sites to be
served from a single database. This database is divided into 'virtual'
Midgard databases, separated by the sitegroup the database entries
belong to.
The effect is much the same as storing sites for separate clients in
separate databases in that resources can't be accessed across
sitegroups (across database borders), and has the following benefits:
- SiteGroups reduces the number of persistant database connections.
When storing separate clients in distinct databases, each Apache
handler process opens a persistent connection to each database. It
is not unusual to have 20-30 handler processes active, which,
multiplied by the number of clients, would easily surpass the
default 100 connections MySQL is configured for.
- With sitegroups, one special sitegroup exists (SiteGroup 0 or SG0
for short) that is read-only for all other sitegroups and which
merges transparently with the sitegroup of your client. With this,
you can install one single administration interface that is
available to all while still maintaining the separation between your
clients. Also, upgrades to the administration interface will
immediately be available to al your clients.
- you can grant administration privileges to your client which will
give him full power within his sitegroup. With this, control of the
sitegroup can be delegated to your client without compromising the
other sitegroups.
Suppose there are 10 distinct user-level Hosts in an installation. Two
of these, vmuc.com and vmucentertainment.com, are owned by Henry, but
he has no connection with the other eight. He must have administrative
privileges for his two Hosts, while being denied access to the other Hosts.
** Configuration Of A SiteGroup-aware Midgard
To build a SiteGroup-aware Midgard installation, you must reconfigure
and recompile all the Midgard packages. This also applies when moving
from a SiteGroup aware installation to a non-SiteGroup installation.
To include SiteGroups, you must specifiy "--with-sitegroups" during
the configuration of libmidgard. The configure programs for
mod_midgard and midgard-php will probe libmidgard to see if SiteGroups
are enabled and respond accordingly.
After reconfiguring & recompiling the Midgard packages, a change must
be made to the database to store the SiteGroup information. The file
sitegroup.sql, from the midgard-lib package, makes this change for
you. The change adds one field to each table in the database, named
sitegroup, and adds one table to store information about the
sitegroups in your system. After this change, the sitegroups table
will be empty (no sitegroups exist) and all existing content has the
sitegroup field set to '0' which puts them in the shared, read-only
sitegroup '0'.
Midgard Sitegroups allows for certain users to be super-users, or root
users, that have full read-write access to all sitegroups. These users
must be in SG0, their member records must be in SG0, and they must be
member of the fictuous group '0'.
Until the administration interface is updated to include SiteGroups
functionality (slated for 1.4), the creation of a new sitegroup
requires you to use the mysql command line tool and issueing:
INSERT INTO sitegroup (name) VALUES('name of new sitegroup');
When moving data from one SiteGroup to another, we reccommend
rebuilding each group from scratch. Create the SiteGroup as shown
above, and log into that SiteGroup as admin@newsitegroupname. Then build:
*a Host record "www.vmuc.com"
*a User group "owners"
*one user "henry"
This enables Henry's write permissions for vmuc.com.
Since populating a sitegroup is much like populating a database, we
suggest filling it from scratch instead of moving content over from
other sitegroups whenever possible.
To create a new host within an existing sitegroup, log in at the
administration interface as 'rootusername#sitegroupname' (more about
logging in later), and create
- a host record
- a user group for the sitegroup administrators if no user groups yet exist
in the sitegroup.
- one user if none yet exists in the sitegroup.
Mark the user group as being the admin group for this sitegroup and
make the aforementioned user member of that group. These actions make
that person administrator for this sitegroup, and full read-write
permissions will be assigned to persons in that user group within the
sitegroup.
** Using SiteGroups
On public sites that do not require authentication, no
username/password will be prompted for. On sites that require
authentication, several login scenarios are available:
For normal users and sitegroup admins:
- For sites that are non-SG0, only a username from within that
sitegroup needs to be given.
- For SG0 sites, the user must login with 'username@sitegroup'. This
will log the user into the SG0 site but for the duration of his
visit he'll be in the sitegroup given in the login. The user must of
course be part of that sitegroup. During the visit to the SG0 site,
only SG0 content and content of the given sitegroup will be
accessible. The SG0 content will be read-only for the visitor, the
sitegroup content governed by normal Midgard access controls.
Root users have several options. Root users must login to any site by
giving either username#, username/ or username$, optionally followed
by a sitegroupname. If no sitegroupname was given the host sitegroup
will be picked; for SG0 sites this puts the root user in SG0 during
the visit for maintenance to the SG0 site.
The trailing characters dictate the view the root user has:
'#' means full access, and you'll see all records of all sitegroups,
even when logging in as rootuser#sitegroupname.
'/' means you want to log in as an admin user for the given sitegroup.
Your view will be restricted to SG0 records and records of the given
sitegroup. Modification of records will be limited to the sitegroup.
'$' means you want to be a normal user in the given sitegroup. You
will not be able to change anything since you are not an actual member
of any owner group within that sitegroup.
Only root users, members of SG0, can remain in SG0 while logged in.
Any valid user can log into the Administration site; however, they are
restricted to reading documents which are owned by the SiteGroup they
signed in under, and can only commit edits to the files they own.
When Henry specifies [EMAIL PROTECTED], mysql queries the Host SiteGroup
field to determine which records he will see in the administration interface.
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
