Debian Admin
Root access
Users can grant themselves sudo access when the machine is first booted after installation. TIG can provide additional sudo access or the root password upon request.
Restricting login access
Machine owners can limit access to their computers by providing a list of allowed or denied usernames in /etc/csail/users.allow or /etc/csail/users.deny. Users listed in users.allow will be allowed at the exclusion of all other users. Usernames listed in users.deny will be denied, while all others will be allowed. Behavior is undefined if both files exist.
Automatic configuration and package updates
TIG uses cfengine to maintain workstations. This allows configuration changes and package updates to be performed on a lab-wide basis if necessary. cfengine's configuration file is /etc/cfengine/cfengine.conf, which really does nothing more than import the central cfengine configuration file from AFS.
If users have some particular configuration needs, they run the risk of having cfengine stomp on their configuration files in the event that TIG decides to update that particular file. To avoid this problem, users should replace edited configuration files with symlinks to other files. E.g. copy /etc/Muttrc to /etc/Muttrc.local, edit the .local copy, and then make /etc/Muttrc a symlink to Muttrc.local. Note that once this is done, TIG won't touch that file, so any centrally performed configuration updates won't be reflected in it. Some people may find that useful, but others will not be well served by it.
Overriding cfengine classes
cfengine uses a list of classes to represent what it knows about a given machine. For example, CSAIL_WKST is a class to which all CSAIL Debian workstations belong. Classes allow cfengine to updated specific subsets of the software infrastructure independently. Certain research groups may have custom configurations, ranging from custom filesystem mounts to a standard GNOME configuration instead of the CSAIL default of KDE.
The list of classes to which a CSAIL Debian workstation belongs is defined during installation. Once installation is complete, it may be desirable to change the list of classes to which a workstation belongs. This may be because a workstation changes owners, or the owner switches group affiliations and wants access to the new group's customizations, or it may be because new classes are introduced and the machine owner wants to take advantage of them.
/etc/csail/classes.local allows the machine owner to add or remove the machine from classes. The list of classes defined at installation time is
/etc/fai/FAI_CLASSES. It's generally best to consider that file read-only and only manipulate the override file. To remove the machine from a given class, e.g. DNS_CLIENT, add
-SOME_CLASS to the override file. To add a class, add
+SOME_OTHER_CLASS.
Some potentially interesting classes include:
- XORG
- GNOME
- KDE
- GROUP_INFOLAB
- GROUP_MAC
- GROUP_TIG
- GROUP_VISION
- GROUP_CAG
- KRB5_CLIENT
- CSAIL_SERVER
Of course, you may hopelessly destroy your system with this mechanism, so do be careful...
