Project Hosts for SDL

Student VMs (Virtual Machines)

The campus hosts multiple servers that can be used for SDL projects. Let your instructor know if your group needs one.

Details on using the hosts:

  • The host names are sdlstudentvmXX.msoe.edu where XX is a one or two-digit number.

  • Your login is a bit non-standard because it uses your email address: that is, if your email name is xyz, then the login is 'xyz@msoe.edu'.

  • You must be behind the campus firewall to access the servers. In particular, off-campus clients will not be able to access them.

  • You can use any SSH client to log in; PuTTY is a good choice. Ask questions on Teams if you're having problems with this. A common issue is that the light grey is hard to read. In PuTTY, you can create a session for your server and set the Window Colours so the Default Foreground is (say) 255/255/0 (bright yellow).

    Note: the first time you log in to a machine using SSH (such as with PuTTY), the system prompts you with a fingerprint id of the target machine. This is to prevent host spoofing. Just accept the fingerprint; the real check is that if it changes on future logins (from the same laptop), that could indicate someone is doing something suspicious.

    You may be able to ssh from your Windows command prompt, but it will not work very well. Using PuTTY is much better.

  • When you log in, you will be prompted for a password. Use your standard (SSO) password. Remember that when you log in to a Unix host, it does not echo the password or display dots.

  • All students with logins on a particular system should have sudo access. Let us know if you don't so we can get it corrected.

  • Make sure gcc is installed. If it is not, do sudo apt install gcc. This will make sure you can install other software. Let you instructor know if the apt command fails.

What can I do on these systems?

There are few limits. Clearly do not do things that would break campus security (such as deploy a webpage bypassing the campus firewall). It is good to have two people do each action because then more mistakes will be caught. But if a mistake gets through and the system becomes unusable, then IT can simply reset it back to the initial state. In particular, you can uninstall and reinstall packages, update the system, delete logs, etc. Feel free to ask your instructor if you are unsure about how to administer the system.

Accessing your repository on the VM

Log on your student VM and use ssh-keygen to create a public/private key pair in your ~/.ssh folder. cat the .pub file, use the mouse to copy it to a local buffer, open your GitLab account, select Edit Profile from the menu associated with your avatar, select Access > SSH Keys, and paste your key in the appropriate box. To use a key, type eval `ssh-agent` followed by ssh-add. You will need to do these two steps each time you log in. (You can probably modify your .bashrc file to do this; search online if setting up access each time is an issue.)

Basic git commands

  • git clone path-to-repository
  • cd repository-name
  • git checkout branch-name
  • git pull
  • git add
  • git commit -m "message"
  • git push