Every record in the database is tagged as belonging to a specific Sitegroup. The effect is much the same as storing sites for separate clients in separate databases in that resources can't be accessed across Sitegroups and has the following benefits:
Sitegroups reduce the number of persistent database connections. When storing Hosts in distinct databases, each Apache handler process opens a persistent connection to every database. It is not unusual to have 20-30 handler processes active per Host. Which, when multiplied by the number of clients, surpasses the default MySQL configuration for 100 connections.
One special Sitegroup, SiteGroup 0 (SG0), is read-only for all other Sitegroups and merges transparently with any other Sitegroup. You can therefore install one single administration interface that is available to all while still maintaining the separation between several sites. Also, upgrades to the administration interface will immediately be available to everybody. (Asgard, the web based administration tool is a Midgard application.)
You can grant separate administration privileges for each Sitegroup.
Sitegroups account for three categories of Midgard users depending on their access level:
Root level users have full access to every resource within every Sitegroup, including SG0.
Admin level users have almost full access to every resource in one Sitegroup. They may be seen as sites administrators, although there may be several sites in one Sitegroup.
User level users, whose privileges will be dealt with in Chapter 9.
Any member of this Group is a root level user, which means he can do anything on the system. Only server administrators should be members of that Group, as everything else can be handled by creating a proper Group system.
Only root level users can:
Modify Asgard, the administration interface, which belongs to SG0.
Create new Sitegroups.
Create new Hosts ; or modify the name, prefix and port fields of an existing Host record.
Any member of the Group whose id equals the admingroup field of a Sitegroup record is an admin level user for that Sitegroup. This means he has write access to every resource within that Sitegroup but the name, prefix and port fields of the Host table.
Only admin level users can modify Host records (apart from the three above mentioned fields): They can choose whether the sites within their Sitegroup are online, and whether they require authentication.
Also, only they can create root Pages, root Styles and root Topics.
A root or admin level user may want to limit his rights when doing a specific task which doesn't require special privileges, or so as to check on a user's rights. This is achieved by authenticating with a username and a Sitegroup name, separated with a Delimiter.
Table 8-1 to Table 8-3 explain the use of delimiters for the three cetegories of users:
Table 8-1. Sitegroup login Delimiters for root level user root.
| Case | Login level | Delimiter | Login |
|---|---|---|---|
| 1 | root | none | root |
| 2 | root | * | root*sitegroup |
| 3 | admin | ! | root!sitegroup |
| 4 | user | $ | root$sitegroup |
| 5 | user | =, $ | root=user$sitegroup |
root is logged in SGO. He has full access to all Sitegroups, but anything he creates will be part of SG0 only.
root is logged in sitegroup. He has full access to all Sitegroups, but anything he creates will be part of sitegroup only.
root has the same privileges as admin.
root is logged in as a user, but looses all his write privileges as he doesn't belong to any Group.
root is logged in as user with root's password. He gets the same privileges as user.
Table 8-2. Sitegroup login Delimiters for admin level user admin.
| Case | Login level | Delimiter | Login |
|---|---|---|---|
| 1 | admin | + | admin or admin+sitegroup |
| 2 | user | ; | admin;sitegroup |
| 3 | user | = (, +) | admin=user or admin=user+sitegroup |
admin is logged in as admin.
admin is logged in as a user, and looses all his privileges as he doesn't belong to any Group.
admin is logged in as user with admin's password. He gets the same privileges as user.