On Sat, 8 Apr 2000, Ron Parker wrote:
> document it. I know some people believe that documentation is best written
> by newbies like myself.
*grin* I know you know that that was my statement.
> There's some merit to that thought but I feel it
> needs to be qualified; programers should document their applications with
> enough clarity for someone like myself to follow behind and edit the
> material. Meanwhile, the programmer focuses on starting a new
> application.
Actually, the way we've been cooperating works wonderfully well for me.
Had it been up to me, I would probably have thunk that my first post was
enough explanation :)
I'll do some in-doc edits. Literals in ""
Emile
> SITEGROUPS
>
> SiteGroups enables multiple virtual databases from 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 the SiteGroup. In addition to manageing access privelages,
> SiteGroups fascilitates the use of one administration interface for many
> users
"the use of shared hosts/content for users of multiple sitegroups, which
provides the ability to write one (or multiple) administratino interfaces
usuable by all your clients"
> and it reduces the number of persistent database connections.
>
> Consider Henry who owns vmuc.com and vmucentertainment.com; obviously he
> must have administrative privelages for those Hosts, while it's equally
> imperative that he's denied read and write privelages to anything that
> he doesn't own while useing the Midgard administration tools. SiteGroups
> enables this type of environment.
>
> CONFIGURATION
>
> Building a SiteGroup aware Midgard installation requires that you
> reconfigure and recompile all the midgard packages. This also applies
> when moveing from a SiteGroup aware Midgard to a nonSiteGroup build.
Or visa versa, but who wants to go back ? :)
> The inclusion of SiteGroups requires that you specifiy
> "--with-sitegroups" during the configuration of libmidgard. The
> configure programs for mod_midgard and midgard-php probe libmidgard to
> see if sitegroups are enabled and respond accordingly.
>
> The inclusion of SiteGroups during the configuration of libmidgard adds
> columns and one table to the Midgard database.
Ah, no, there's a sql file in the lib package that when executed against
an existing, non-SG Midgard database, will add them. But SGs will be in
the 1.4 database by default, so maybe we don't need this.
> Existing records have their SiteGroup field set to '0',
"after this change"
> so everything that exists when you apply the patch is owned by SG0.
> Users that require full access to the Midgard database must have their
> "member" and "person" records specified within SiteGroup 0 (SG0).
"and be member of the fictuous group with ID 0. We'll call these users
'root'."
> While SiteGroups is designed to be as transparent as possible, the
> transition to makeing your administration tool SiteGroups aware requires
> the manual instantiation of sitegroups. Insertion of SiteGroups is done
> from a mysql command line by issueing:
>
> INSERT INTO sitegroup (name) VALUES ('sitegroupname');
>
> To enable Henry's write permissions for vmuc.com we create the sitegroup
> "vmuc.com," add henry as a user and finally modify the vmuc.com
> sitegroup to include him within its membership.[1]
Moving over data from one SG to another is pretty awkward at the moment,
I'll admit to that. I recommend starting from scratch for each SG: Create
the SG as above, log into that sitegroup on the admin interface
(admin@newsitegroupname), and create
- a host record (www.vmuc.com)
- a user group (Owners)
- one user (henry)
and make henry member of Owners, and update the 'vmuc.com' sitegroup
record to make Owners the admin group of sitegroup 'vmuc.com'. Since
these entries define what access a person will have they require an
existing root user (universal Midgard access) to create them; Henry will
be able to do everything else himself.
> USEAGE
>
> 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.
Unless you're root you'll be required to specify your sitegroup like this
when logging into the administration site. If you're root you have the
option of logging into the site as any available sitegroup, not just the
sitegroups you belong to. Root users must login with either 'username#'
(to log into the shared sitegroup 0, readable for all users across all
sitegroups) or username#sitegroup (which will make you member of the given
sitegroup for the duration of your request).
> When Henry specifies [EMAIL PROTECTED], mysql queries the host
> sitegroup field to determine which records he will see in the
> administration interface. Only root users, members of SG0, can remain in
> SG0 while logged in. Any user can log into the Administration site but
> they are restricted to reading documents which are owned by the
> SiteGroup that they signed in under and can only commit edits to the
> files they own.[4]
> Creation of host records is limited to root users. To create a new host,
> log on as admin@sitegroupname[3]
That's admin#sitegroupname as of tonight :) Normal users (including SG
admins) will use the username@sitegroupname format; the '#' says you want
to be root.
> and everything you build, including the host record, will default to
> being part of that sitegroup.
so logging into the sitegroup right after creating it is imperative. We'll
want the logout code that Jukka showed a while ago in the admin site.
> Another SiteGroup feature is the administration groups--these groups can
> be thought of as an umbrella under which many hosts are managed. Within
> this scenario 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.
Other users of the sitegroup will also be able to log onto the sitegroup
(of course) and read all of the content in that sitegroup. Changing the
content in the sitegroup is still subject to the existing object ownership
access control. Users that are in the admin group for their sitegroup have
full access to all resources in their sitegroup, regardless of the
ownership settings on these resources.
> Members of administration groups have unrestricted create and modify
> access to all resources within their sitegroup. Root users are
> automatically admin 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 admins for.
I reccomend starting a new sitegroup from scratch so all the users and
groups you create will then automatically be in the SG.
> <!--End Edits-->
>
> [1]David Guerizec is currently writing an admin-site interface for
> SiteGroups. It should be available for the Midgard 1.4beta release.
>
> [2]How to add another host to the vmuc.com sitegroup. In our example,
> Henri needs write privelages for vmuc.com and vmucentertainment.com.
Just log into the admin site as admin#vmuc.com and create host
www.vmucentertainment.com. Henry will allready be admin for the sitegroup
so he can take it from there.
> [3]Does the username "admin" have any significance or is it an example?
Just an example. Any name will work, and multiple users can be root.
You're root when your person record is in SG0, and you're member of the
(non-existing) group 0
> [4]This seemed to be implied but I'm not sure if I've interpreted
> it correctly. Does it mean that a SiteGroup could display files which a
> user doesn't have write privelages for?
No. Rather, resources (pages, topics, articles, style elements, the works)
that are not in the sitegroup you logged on to (either explicitly or
driven by the host record sitegroup) will not be visible to you. You will
not be able to list, retrieve or update them; in fact, you won't be able
to tell the difference between a resource that's simple not there and a
resource that inaccessable because it's in another sitegroup.
Thanks Ron.
Emile
--
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]
