Difference between revisions of "SPO600 Servers"

From CDOT Wiki
Jump to: navigation, search
(xerxes)
Line 1: Line 1:
 
[[Category:SPO600]]
 
[[Category:SPO600]]
{{Admon/important|Backup Your Data|These computers are NEVER backed up. Please save all important files on other storage. '''These machines may be removed or reinstalled at any time.'''}}
+
{{Admon/important|Backup Your Data|These computers are NEVER backed up. Please save all important files on other storage. '''These machines may fail, be removed or be reinstalled at any time.'''}}
 
In [[SPO600]], remote access to servers is provided for learning and project work. It is recommended that you also set up [[SPO600 Host Setup|a personal Linux system]].
 
In [[SPO600]], remote access to servers is provided for learning and project work. It is recommended that you also set up [[SPO600 Host Setup|a personal Linux system]].
  

Revision as of 16:51, 23 August 2017

Important.png
Backup Your Data
These computers are NEVER backed up. Please save all important files on other storage. These machines may fail, be removed or be reinstalled at any time.

In SPO600, remote access to servers is provided for learning and project work. It is recommended that you also set up a personal Linux system.

Preparatory Steps

In order to gain access to these computers, you must send an SSH key to your professor.

  1. Follow the steps outlined under Using Public Keys with SSH to create your key.
  2. Copy the public key (id_rsa.pub or id_dsa.pub) to a file named yourUserId.pub -- for example, if your Seneca user ID is "jldoe", save the key in the file jldoe.pub using a command such as: cp ~/.ssh/id_rsa.pub jldoe.pub
  3. Attach that file to an e-mail message and send it to chris.tyler@senecacollege.ca including the course code "SPO600" somewhere in the subject line.

An account will be created within a few work days of sending the key.

Idea.png
Check Your Key!
Your professor uses an automated script to create accounts, so the key must be valid, in the OpenSSH format, and correctly named in order to work successfully.

Available Servers

AArch64

betty

The current ARMv8 AArch64 server system is known as betty (or bbetty). This system is located inside the EHL. To connect to this system, you need to connect through the EHL gateway on port 2201.

If you're using a command-line ssh system, and you are on the Seneca network, you can issue a command such as this:

ssh -p 2201 username@ehl.internal.cdot.systems

To connect from outside Seneca:

ssh -p 2201 username@ehl.cdot.systems

x86_64

xerxes

Important.png
Server re-installed 2017-01-23
Due to a disk failure, this system was reinstalled on January 23, 2017. All previous user files and passwords were lost.

Our x86_64 server is known as xerxes.This system is located outside the EHL but is accessed through the EHL gateway from outside Seneca, using port 2202.

If you're using a command-line ssh system, and you are on the Seneca network, you can issue a command such as this:

ssh -p 2202 username@ehl.internal.cdot.systems

Or you can connect directly:

ssh xerxes.internal.cdot.systems

To connect from outside Seneca:

ssh -p 2201 username@ehl.cdot.systems

Simplified SSH Access

If you're using OpenSSH (the ssh client used on most Linux systems and other platforms), you can simplify complex ssh command lines by placing host connection details in the file ~/.ssh/config:

Host "betty"
        hostname "ehl.cdot.systems"
        user "YourUserID"
        port 2201

Host "betty-internal"
        hostname "ehl.internal.cdot.systems"
        user "YourUserId"
        port 2201

Host "xerxes"
        hostname "ehl.cdot.systems"
        user "YourUserId"
        port 2202

Host "xerxes-internal"
        hostname "ehl.internal.cdot.systems"
        user "YourUserId"
        port 2202

Once you have added these lines (inserting your user ID where appropriate) and set the permission on that file (chmod 0600 ~/.ssh/config) you can use these commands to access betty and xerxes from outside of Seneca:

ssh betty
ssh xerxes

Or these commands to access betty and xerxes from inside Seneca:

ssh betty-internal
ssh xerxes-internal
Important.png
Common SSH Problems
Your ssh private key must be in your ~/.ssh directory and have correct permissions (0600). If your SSH public key is not named ~/.ssh/id_rsa, your SSH client may not automatically find it. You can specify the identity (private key) file using the -i argument to the SSH command.

Sudo Access

To perform operations which require privilege, such as installing software, use the sudo command to execute the desired instruction as the root user.

For example, to install the software packaged ncurses-devel, execute: sudo dnf install ncurses-devel on xerxes or sudo yum install ncurses-devel on betty. The commands are different because Xerxes is running Fedora, which has transitioned from the older yum system to dnf, while Betty is running LEAP (based on CentOS), which still uses the older system.

Stop (medium size).png
Danger! Use Superuser privilege at your Own Risk.
Note that the use of the superuser account via sudo removes almost all restrictions on what you can do. It is easily possible for you to completely destroy the operating system! Take your time, double-check your commands, and if in doubt, ask. Be aware that your actions may affect other users and vice-versa.
Stop (medium size).png
Do Not Build or Install Software Except Via RPM (dnf/yum)
Do not build or install software as the root user (using sudo), except in RPM form using the dnf or yum commands. Building or installing software as root may overwrite system files and be very difficult to track down.

It is OK to install software into your own directories (e.g., ~/bin or ~/local), which can be done without root privilege.

In order to use sudo, you will need to know your password. An initial random password is provided in the file ~/password (which is different on each server). Feel free to change this with the passwd command -- not by editing the file, which is provided only for your information.

Multiuser Access

Remember that these machines are multi-user systems. Use the w or who commands to see who else is using them; you can also try using the write command to communicate with another user if required.

Disconnect/Reconnect Ability

The screen utility provides disconnect/reconnect capability, which is very useful for unstable network connections, long interactive operations, and changing your work location.