建議的子管理員 lnode 結構

子管理員可能面臨的一個問題是，他們受到和其群組成員一樣的群組限制。例如，如果群組 header lnode 有一個處理限制，那麼該限制也會控制整個群組所用的處理數目，包括群組 header 在內。除非進一步加以限制，否則排程群組中任何使用者都可以設法超出自己的處理限制，不讓子管理員建立新的處理。要防止這種情況，群組管理員就必須對每一位群組成員設定個別的限制。然而，這些限制可能要非常嚴格，才能達到預期的效果。同時迫使子管理員去管理個別的限制，也不符合 Solaris Resource Manager 階層式資源控制的目標。另外一個解決這個問題的方法是，讓管理員變更其群組中的 lnode 結構。不直接將使用者放在自己的 lnode 之下，相反地，他們應該在自己底下建立一個"Control"lnode 來作為他們唯一的子 lnode，然後再讓所有使用者成為此控制 lnode 的子。這樣一來，就會產生如下所示的 lnode 結構。

圖 5-1 子管理員 lnode 結構

參看上圖，子管理員帳號的 UID 會對應標示為"Actual"的 lnode 帳號，也就是樹形的雙親。這也就是 admin 旗標為 set 的 lnode。接著會為"Control"lnode 建立一個虛擬帳號，此帳號不會允許任何登入。標示為"A"、"B"和"C"的 lnode 會與子管理員控制之下的使用者互相對應。

在此例中，"Actual"lnode 的處理限制可以為 100，而"Control"lnode 的限制為 90，同時個別使用者的限制則設為 0。這個設定可以確保即使在使用者 A、B 及 C 使用一共 90 個處理（允許的全部）的情形下，子管理員仍然可以另外建立 10 個處理。不過使用者還是可以互相阻止對方建立處理，唯一的辦法是對那些使用者設定個別的限制。但是在這個例子中，各個限制可以設定為 40，仍然可以在防止單一使用者完全佔用他人資源的同時稍留一點空間。也請注意，這個例子中的子管理員可以為新使用者建立額外的 lnode 來作為"Control"lnode 的子，而不需要擔心如何重新平衡各項限制。