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
root_alias=YOUREMAILADDRESS
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 help@csail.mit.edu.)
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.
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):
autofs=true
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 (help@csail.mit.edu) 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]@jump.csail.mit.edu -L 63389:[your host].csail.mit.edu:3389
…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.