建議的群組管理員 lnode 結構

群組管理員可能面臨的一個問題是，他們受到和其群組成員一樣的群組限制。例如，如果群組標頭 lnode 有一個處理限制，那麼該限制也會控制整個群組所用的處理數目，包括群組標頭在內。除非進一步加以限制，否則排程群組中任何使用者都可以設法超出自己的處理限制，不讓群組管理員建立新的處理。

要防止這種情況，群組管理員就必須對每一位群組成員設定個別的限制。然而，這些限制可能要非常嚴格，才能達到預期的效果。同時迫使子管理員去管理個別的限制，也不符合 Solaris Resource Manager 階層式資源控制的目標。

另外一個解決這個問題的方法是，讓中央管理員變更其群組中的 lnode 結構。在群組管理員的 lnode 下方建立一個“控制”lnode，作為唯一的子 lnode，而不得把使用者直接放置於群組管理員自己的 lnode 下方。這樣一來，就會產生如下所示的 lnode 結構。

圖 5-1 群組管理員 lnode 結構

參看上圖，群組管理員帳號的 UID 會對應標示為"Actual"的 lnode 帳號，也就是樹形的雙親。這也就是有 admin 旗標設定的 lnode。接著會為"Control" lnode 建立一個虛擬帳號，沒有登入會在這帳號上被准許。標示為"A"、"B"和"C"的 lnode 會與群組管理員控制之下的使用者互相對應。

在此例中，"Actual" lnode 的處理限制可以為 100，而"Control" lnode的限制為 90，同時個別使用者的限制則設為 0。這個設定可以確保即使在使用者 A、B 及 C 使用一共 90 個處理（允許的全部）的情形下，子管理員仍然可以另外建立 10 個處理。

不過使用者還是可以互相阻止對方建立處理，唯一的辦法是對那些使用者設定個別的限制。唯一避免這發生的方法，是設定個別使用者的權限。但是在這個例子中，各個限制可以設定為 40，仍然可以在防止單一使用者完全佔用他人資源的同時稍留一點空間。

同時注意，在這一個例子中，中央管理員能為新使用者建立額外的 lnodes。這些 lnodes 是 'Control' lnode 的子節點，並且中央管理員不用重新平衡限制。