Linux Admin

Root Access

Users can grant themselves sudo access when the machine is first booted after installation. TIG can help in cases of machines changing users or similar cases where somebody who needs access doesn’t have it. You can also add new sudoers files to the /etc/sudoers.d directory, for example:

sudo visudo -f /etc/sudoers.d/12_local_sudo

Root Alias

If you are reading this, its probably because you want to customize something on your machine — install some extra software, set up a root cron job, add a local (non-Kerberos) account for a collaborator, or the like. If that is the case, you should arrange for yourself to get root mail. You can do this by creating a file /etc/facter/facts.d/local.txt and adding a line that says


That does not prevent TIG sysadmins from getting root mail as well, but it means you will see it too, and you can fix problems related to software you’ve installed or configuration changes you’ve made. (Of course, if you need help with that, send mail to

Restricting login access

Machine owners can limit access to their computers by providing a list (one per line) of allowed usernames in /etc/csail/users.allow.

On 16.04 (Xenial) and newer systems /etc/csail/groups.allow is also supported. Note: On 16.04 and newer systems, /etc/csail/groups.allow must exist (even if empty) in order for /etc/csail/users.allow to function correctly.

Don’t lock yourself out!

If you create users.allow or groups.allow they take effect immediately, and one of their side effects is to prevent disallowed users from running sudo. So make sure you never leave those files in a state where your account isn’t allowed to authenticate, or you’ll lose your ability to make any further changes. For instance, add yourself to users.allow before creating groups.allow if you’re not already in one of the allowed groups. (TIG can help if you find yourself in that state.)

It is also possible to restrict ssh access to a specific group or list of groups. This is done by adding a line to the file in /etc/facter/facts.d/local.txt (which may not yet exisist) defining sshdallowgroups to a space seperated list of groups to allow, for example:

sshdallowgroups=group1 group2 etc

This will be activated on the next configuration management run (within 30min) or can be activated immediately by running

sudo puppet agent -t

The sshallowgroups method is preferred for 14.04 (Trusty) and older systems. On newer systems /etc/csail/groups.allow and /etc/csail/users.allow is preferred

Access to NFS

Autofs is unconfigured by default. If you’d like to access the CSAIL NFS shares, add the following line to /etc/facter/facts.d/local.txt (which might not exist already):


You should be able to access the NFS shares in approximately 30 minutes after the next puppet agent runs.

Remote access via xrdp

TIG provides minimal support for remote access besides ssh, but one method we’ve been asked about frequently is ‘xrdp’, as it can have better performance than VNC, NoMachine, or X forwarding.

We maintain a few patches to make xrdp just work on CSAIL Linux, so you can run the following to enable it for your machine (sudo required):

sudo apt install xrdp

Once that’s done, you’ll be able to connect to the machine using a regular RDP client. Note that some older installs of CSAIL Ubuntu may need extra packages installed; please contact TIG ( if you run into any issues, and we’ll try to add them here.

Note that we block the RDP port to outside traffic, as a security measure. If you’re outside the CSAIL lab network, you’ll need to either connect to the MIT VPN or use our jump host:

ssh [your username] -L 63389:[your host]

…and then you can connect to ‘localhost:63389’ with your RDP client. DO NOT UNDER ANY CIRCUMSTANCES changes the RDP port to evade our firewall. This will result in your machine being disconnected from the network.