> Thanks to Cat and Emile. Your editing efforts are very helpful. I think > the current version is near completion. Late for work, gotta run. I think so too. I've added some suggestions. Oh, BTW, for the rest of [EMAIL PROTECTED]: feel free to take a potshot at it. If there are passages or concepts in any part of the documentation that spark that "Things that make you go 'Huh?!'" feeling, let us know. Only with your collective help will we be able to make a good manual. Emile
> = keep < = suggested change > ** Introduction to SiteGroup Virtual Database Environments > < A SiteGroup creates a multiple virtual database environment within < Midgard's single Mysql database. All content in the database is tagged < as belonging to a specific SiteGroup. Consequently, when a user logs < into a Host that is part of a specific SiteGroup, they are only able < to read and write data that belongs to that SiteGroup. Additionally, < it facilitates sharing Host content for multiple SiteGroups, and it < reduces the number of persistent database connections. 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. > < Configuring libmidgard with SiteGroups adds columns and one table to < the Midgard database. Existing records have their SiteGroup field set < to "0", so everything that exists when you apply the patch is owned by < SiteGroup zero (SG0). 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'. < Users who require full access to the Midgard < database must have their "member" and "person" records specified < within SG0 and be made a member of the ficticious group with ID 0. < We'll call these users "root". 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'. < Although SiteGroups is designed to be as transparent as possible, you must < manually install SiteGroups by issuing the mysql command: < < INSERT INTO sitegroup (name) VALUES ('sitegroupname');[1] 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 > < When logging into the Midgard administration site, the user is < prompted to specifiy a username@sitegroup. Either a SiteGroup name or < 0 must be specified. (Normal users, including SiteGroup administrators < use the "username@sitegroup" format. When logging in as root, you use < the format "username#sitegroup." The "#" says you want to be root). < < If you're root, you have the option of logging into any SiteGroup. < Root users must login with either "username#" which logs them into the < shared SiteGroup 0 and grants write permissions across all SiteGroups, < or "username#sitegroup" which grants write permissions for the < specific SiteGroup. 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. < The building of Host records is limited to root users. When building a < new Host, the first step is to create its SiteGroup, unless one < exists. Then you must log in as "admin@newsitegroupname." By logging < into the Host's SiteGroup you'll insure that everything you build will < default to being owned by that SiteGroup. < < Another SiteGroup feature is the Administration group -- these groups < can be thought of as an umbrella under which many Hosts are managed. < In our example, the Hosts vmuc.com and vmucentertainment.com are both < under the care of the vmuc.com SiteGroup. Consequently, when Henry < logs in as [EMAIL PROTECTED] he's able to read and edit the records for < both of these sites. < < Members of administration groups have unrestricted create and modify < access to all resources within their SiteGroup. Root users are < automatically admininstration users for every SiteGroup. The < Admingroup for a Sitegroup is specfied in the admingroup table. Both < the group and the person records must be in the SiteGroup that they're < adminstrators for. Maybe combine with text above? > [1]David Guerizec is currently writing an admin-site interface for > SiteGroups. It should be available for the Midgard 1.4beta release.
-- 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]