Difference between revisions of "SPO600 Servers"

From CDOT Wiki
Jump to: navigation, search
(Sudo Access)
(AArch64: israel.cdot.systems)
 
(45 intermediate revisions by the same user not shown)
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, be upgraded, 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]]. -->
 +
 
  
 
== Preparatory Steps ==
 
== Preparatory Steps ==
  
In order to gain access to these computers, you must send an [[SSH]] key to your [[User:Chris Tyler|professor]].
+
In order to gain access to these computers, you must send an [[SSH]] key to your [[User:Chris Tyler|professor]]. <!-- Please follow these instructions exactly:
  
 
# Follow the steps outlined under [[SSH#Using_Public_Keys_with_SSH|Using Public Keys with SSH]] to create your key.
 
# Follow the steps outlined under [[SSH#Using_Public_Keys_with_SSH|Using Public Keys with SSH]] to create your key.
# Copy the public key (<code>id_rsa.pub</code> or <code>id_dsa.pub</code>) to a file named <code>''yourUserId''.pub</code> -- for example, if your Seneca user ID is "jldoe", save the key in the file <code>jldoe.pub</code> using a command such as: <code>cp ~/.ssh/id_rsa.pub ''jldoe''.pub</code>
+
# Copy the public key (<code>id_rsa.pub</code> or <code>id_dsa.pub</code>) to a file named <code>''yourUserId''.pub</code> -- for example, if your chosen user ID is "jldoe", save the key in the file <code>jdoe.pub</code> using a command such as: <code>cp ~/.ssh/id_rsa.pub ''jdoe''.pub</code>
# Attach that file to an e-mail message and send it to [mailto:chris.tyler@senecacollege.ca chris.tyler@senecacollege.ca] including the course code "SPO600" somewhere in the subject line.
+
# Attach that file to an e-mail message and send it to [mailto:chris.tyler@senecacollege.ca chris.tyler@senecacollege.ca] with the subject line "SPO600 Key". -->
  
 
An account will be created within a few work days of sending the key.
 
An account will be created within a few work days of sending the key.
  
 
{{Admon/tip|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.}}
 
{{Admon/tip|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 ==
 
== Available Servers ==
  
=== AArch64 ===
+
<!-- {{Admon/important|Content being Updated|This page is in the process of being updated from a previous semester's content. The SPO600 servers will be set up in a new configuration later this semester, and this information will be updated. Do not rely on this information until this warning is removed.}}
<!--
 
==== aarchie ====
 
The first server is an [[ARMv8]] AArch64 system known as '''aarchie''' or '''archie'''. This is a system that is currently located inside the [[EHL]]. To connect to this system, you have to go through the EHL gateway on port 2200.
 
  
If you're using a command-line ssh system, and you are on the Seneca network, you can issue a command such as this:
+
{{Admon/important|Server Changes|The server configurations have changed several times -- previous mentions of these systems by name may have referred to different hardware. Note that servers may be added or removed as the semester proceeds.}} -->
  
ssh -p 2200 ''username''@ehl.internal.cdot.systems
+
The names of servers within CDOT are based on the names of countries. There is no significance to the country names.
  
To connect from outside Seneca:
+
=== AArch64: israel.cdot.systems ===
  
  ssh -p 2200 ''username''@ehl.cdot.systems
+
A main AArch64 system is available, known as ''israel''. This machine has a lot of mid-range cores. You can access this system at the hostname israel.cdot.systems; if you're using a command-line ssh system, you can access israel with a command such as this:
-->
+
 
==== betty ====
+
  ssh ''username''@israel.cdot.systems
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.
+
<!-- === AArch64: bbetty ===
 +
 
 +
Another type AArch64 system is available as ''bbetty''. This machine has a moderate number of low-medium cores. This is a system that is currently located inside the [[EHL]]. To connect to this system, you have to go through the EHL gateway on port 2200.
  
If you're using a command-line ssh system, and you are on the Seneca network, you can issue a command such as this:
+
If you're using a command-line ssh system, you can issue a command such as this:
  
  ssh -p 2201 ''username''@ehl.internal.cdot.systems
+
  ssh -p 2200 ''username''@ehl.cdot.systems
  
To connect from outside Seneca:
 
  
ssh -p 2201 ''username''@ehl.cdot.systems
+
=== AArch64: ccharlie ===
  
=== x86_64 ===
+
Another AArch64 system similar to bbetty is named ''ccharlie''. This is a system that is currently located inside the [[EHL]]. To connect to this system, you have to go through the EHL gateway on port 2205.
  
==== xerxes ====
+
If you're using a command-line ssh system, you can issue a command such as this:
  
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.
+
ssh -p 2205 ''username''@ehl.cdot.systems
  
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
+
=== AArch64: israel ===
  
Or you can connect directly:
+
A different AArch64 system is ''israel''. This machine has a good number of mid-level cores. This system is located outside of the EHL and can be reached directly:
  
  ssh xerxes.internal.cdot.systems
+
  ssh ''username''@israel.cdot.systems
 +
-->
  
To connect from outside Seneca:
+
=== x86_64: portugal.cdot.systems ===
  
ssh -p 2201 ''username''@ehl.cdot.systems
+
The x86_64 server system is known as ''portugal''. If you're using a command-line ssh system, you can access xerxes with a command such as this:
  
 +
ssh ''username''@portugal.cdot.systems
  
 
== Simplified SSH Access ==
 
== 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 <code>~/.ssh/config</code>:
+
If you're using OpenSSH (the ssh client used on most Linux systems and other platforms), you can simplify ssh command lines by placing host connection details in the file <code>~/.ssh/config</code>:
  
Host "betty"
+
<!-- Host "aarchie"
 
         hostname "ehl.cdot.systems"
 
         hostname "ehl.cdot.systems"
 
         user "YourUserID"
 
         user "YourUserID"
         port 2201
+
         port 2200
 
   
 
   
  Host "betty-internal"
+
  Host "bbetty"
         hostname "ehl.internal.cdot.systems"
+
         hostname "ehl.cdot.systems"
 +
        user "YourUserID"
 +
        port 2202
 +
 +
Host "ccharlie"
 +
        hostname "ehl.cdot.systems"
 +
        user "YourUserID"
 +
        port 2205
 +
 +
Host "xerxes"
 +
        hostname "xerxes.cdot.systems"
 
         user "YourUserId"
 
         user "YourUserId"
         port 2201
+
 
 +
Host "aarchie"
 +
        hostname "aarchie.cdot.systems"
 +
        user "YourUserID"
 +
 +
Host "bbetty"
 +
        hostname "ehl.cdot.systems"
 +
        user "YourUserID"
 +
         port 2200
 
   
 
   
  Host "xerxes"
+
  Host "ccharlie"
 
         hostname "ehl.cdot.systems"
 
         hostname "ehl.cdot.systems"
         user "YourUserId"
+
         user "YourUserID"
         port 2202
+
         port 2205
 +
-->
 +
 +
Host "portugal"
 +
        hostname "portugal.cdot.systems"
 +
        user "YourUserID"
 +
 +
Host "israel"
 +
        hostname "israel.cdot.systems"
 +
        user "YourUserID"
 +
 +
<!-- Host "xerxes"
 +
        hostname "xerxes.cdot.systems"
 +
        user "YourUserID"
 +
-->
 +
 
 +
Once you have added these lines (inserting your user ID where appropriate) and set the permission on that file (<code>chmod 0600 ~/.ssh/config</code>) you can use these commands to access the servers:
 +
 
 +
ssh israel
 
   
 
   
  Host "xerxes-internal"
+
  ssh portugal
        hostname "ehl.internal.cdot.systems"
+
 
        user "YourUserId"
+
You can similarly configure simplified access in most other SSH client programs.
        port 2202
+
 
 +
 
 +
== Multiuser Access ==
 +
 
 +
Remember that these machines are multi-user systems. Use the <code>w</code> or <code>who</code> commands to see who else is using them; you can also try using the <code>write</code> command to communicate with another user if required.
  
Once you have added these lines (inserting your user ID where appropriate) and set the permission on that file (<code>chmod 0600 ~/.ssh/config</code>) you can use these commands to access betty and xerxes from outside of Seneca:
 
  
ssh betty
+
== Passwords ==
ssh xerxes
 
  
Or these commands to access betty and xerxes from inside Seneca:
+
Your password on each of these systems has been set to a random string (different on each host). You can find out the original random password by viewing the file <code>~/password.txt</code> and you can change the password with the <code>passwd</code> command. Your password is used for sudo access (see the next section).
  
ssh betty-internal
 
ssh xerxes-internal
 
  
 
== Sudo Access ==
 
== Sudo Access ==
Line 102: Line 139:
 
{{Admon/caution|Danger! Use Superuser privilege at your Own Risk.|Note that the use of the superuser account via <code>sudo</code> 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.}}
 
{{Admon/caution|Danger! Use Superuser privilege at your Own Risk.|Note that the use of the superuser account via <code>sudo</code> 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.}}
  
{{Admon/caution|Do Not Build or Install Software Except Via RPM (dnf/yum)|Do not build or install software as the root user (using <code>sudo</code>), except in RPM form using the <code>dnf</code> or <code>yum</code> commands. Building or installing software as root may overwrite system files and be very difficult to track down.<br /><br />It is OK to install software into your own directories (e.g., <code>~/bin</code> or <code>~/local</code>), which can be done without root privilege.}}
+
{{Admon/caution|DO NOT Build or Install Software as Root except via RPM (dnf/yum) or DEB (apt)|Do not build or install software as the root user (using <code>sudo</code>), except in RPM or DEB form using the <code>dnf</code>/<code>yum</code> or <code>apt</code> commands (as appropriate to the system). Building or installing software as root may overwrite system files and be very difficult to track down.<br /><br />It is OK to install software into your own directories (e.g., <code>~/bin</code> or <code>~/local</code>), which can be done without root privilege.}}
 +
 
 +
In order to use <code>sudo</code>, you will need to know your password. An initial random password is provided in the file <code>~/password.txt</code> (note that your password will be different on each server). Feel free to change this with the <code>passwd</code> command -- not by editing the file, which is provided only for your information!
 +
 
 +
 
 +
== SSH Access from Other Client Systems ==
 +
 
 +
If you wish to access the servers from additional computers, you can append the SSH public keys from those computers to the <code>~/.ssh/authorized_keys</code> file. Alternately, you can copy the private key from one client system to another (e.g., your laptop to your desktop).
 +
 
 +
 
 +
== OS Versions ==
 +
 
 +
The current servers are both running Fedora 35 and will be updated from time to time. The machines may not be updated at the same time, so the versions of software may vary slightly. The kernel versions may also vary between the systems because of kernel hardware support.
 +
 
 +
 
 +
== Backup Your Accounts ==
 +
 
 +
These accounts are ''never'' backed up, and the machines may fail, lose data, or be reinstalled without warning at any time. Please back up your work frequently by copying it to another system or storage device.
 +
 
 +
 
 +
== Common SSH Problems ==
 +
 
 +
With the OpenSSH client:
 +
# Your ssh private key must be in your <code>~/.ssh</code> directory (which must have 0700 permission) and the private key file must have 0600 permissions -- no more and no less.
 +
# If your SSH public key is not named <code>~/.ssh/id_rsa</code>, your SSH client may not automatically find it. You can specify the identity (private key) file using the <code>-i</code> argument to the SSH command.}}
 +
 
 +
==== Debugging SSH Connection Problems ====
 +
 
 +
===== Situation 1: The SSH client asks you for a passphrase =====
 +
 
 +
The passphrase is the one you provided when you created your SSH keys. You must remember this passphrase in order to successfully unlock your private key. If you do not remember your passphrase, you will need to create a new pair of keys and re-send the public key to your professor:
 +
# Create the keys with <code>ssh-keygen -t ed25591</code>
 +
# Copy the public key (which by default will be named <code>~/.ssh/id_ed25519.pub</code>) to a file named <code>'''UserId'''.pub</code> where '''UserId''' is your Seneca User ID.
 +
# Attach that file to an e-mail message and send it to your professor.
 +
 
 +
===== Situation 2: The SSH client asks you for a password =====
 +
 
 +
The password is for the remote system, but the SSH client will only ask you for a password if it is unable to authenticate using your keys. If that is the case, then one of your keys is corrupted, missing, has the wrong permission, or can't be found by the SSH client.
 +
# If you're using OpenSSH, try using the <code>-i</code> argument to tell the client which private key identity file to use: <code>ssh -i /path/to/ssh/PrivateKey ...</code>
 +
# Check the permissions on the private key and the directory holding the private key.
 +
# If necessary, generate a new key and send it to your professor (see the previous section).
  
In order to use <code>sudo</code>, you will need to know your password. An initial random password is provided in the file <code>~/password</code> (which is different on each server). Feel free to change this with the <code>passwd</code> command -- not by editing the file, which is provided only for your information.
+
===== Getting Verbose Output =====
  
== Multiuser Access ==
+
To see what the OpenSSH client program is doing, you can use the <code>-v</code> (verbose) argument, up to three times: <code>ssh -vvv ...</code>
  
Remember that these machines are multi-user systems. Use the <code>w</code> or <code>who</code> commands to see who else is using them; you can also try using the <code>write</code> command to communicate with another user if required.
+
By reading through the output carefully, you can see what the OpenSSH client program is doing, and address any problems that arise (such as permission or file naming issues).
  
 
== Disconnect/Reconnect Ability ==
 
== Disconnect/Reconnect Ability ==
  
 
The [[Screen Tutorial|screen]] utility provides disconnect/reconnect capability, which is very useful for unstable network connections, long interactive operations, and changing your work location.
 
The [[Screen Tutorial|screen]] utility provides disconnect/reconnect capability, which is very useful for unstable network connections, long interactive operations, and changing your work location.
 +
 +
Other programs such as tmux provide similar capability.
 +
 +
For graphical disconnect/reconnect capability, consider using VNC.

Latest revision as of 02:02, 11 September 2023


Preparatory Steps

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

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

The names of servers within CDOT are based on the names of countries. There is no significance to the country names.

AArch64: israel.cdot.systems

A main AArch64 system is available, known as israel. This machine has a lot of mid-range cores. You can access this system at the hostname israel.cdot.systems; if you're using a command-line ssh system, you can access israel with a command such as this:

ssh username@israel.cdot.systems

x86_64: portugal.cdot.systems

The x86_64 server system is known as portugal. If you're using a command-line ssh system, you can access xerxes with a command such as this:

ssh username@portugal.cdot.systems

Simplified SSH Access

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


Host "portugal"
        hostname "portugal.cdot.systems"
        user "YourUserID"

Host "israel"
        hostname "israel.cdot.systems"
        user "YourUserID"

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 the servers:

ssh israel

ssh portugal

You can similarly configure simplified access in most other SSH client programs.


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.


Passwords

Your password on each of these systems has been set to a random string (different on each host). You can find out the original random password by viewing the file ~/password.txt and you can change the password with the passwd command. Your password is used for sudo access (see the next section).


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 as Root except via RPM (dnf/yum) or DEB (apt)
Do not build or install software as the root user (using sudo), except in RPM or DEB form using the dnf/yum or apt commands (as appropriate to the system). 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.txt (note that your password will be 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!


SSH Access from Other Client Systems

If you wish to access the servers from additional computers, you can append the SSH public keys from those computers to the ~/.ssh/authorized_keys file. Alternately, you can copy the private key from one client system to another (e.g., your laptop to your desktop).


OS Versions

The current servers are both running Fedora 35 and will be updated from time to time. The machines may not be updated at the same time, so the versions of software may vary slightly. The kernel versions may also vary between the systems because of kernel hardware support.


Backup Your Accounts

These accounts are never backed up, and the machines may fail, lose data, or be reinstalled without warning at any time. Please back up your work frequently by copying it to another system or storage device.


Common SSH Problems

With the OpenSSH client:

  1. Your ssh private key must be in your ~/.ssh directory (which must have 0700 permission) and the private key file must have 0600 permissions -- no more and no less.
  2. 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.}}

Debugging SSH Connection Problems

Situation 1: The SSH client asks you for a passphrase

The passphrase is the one you provided when you created your SSH keys. You must remember this passphrase in order to successfully unlock your private key. If you do not remember your passphrase, you will need to create a new pair of keys and re-send the public key to your professor:

  1. Create the keys with ssh-keygen -t ed25591
  2. Copy the public key (which by default will be named ~/.ssh/id_ed25519.pub) to a file named UserId.pub where UserId is your Seneca User ID.
  3. Attach that file to an e-mail message and send it to your professor.
Situation 2: The SSH client asks you for a password

The password is for the remote system, but the SSH client will only ask you for a password if it is unable to authenticate using your keys. If that is the case, then one of your keys is corrupted, missing, has the wrong permission, or can't be found by the SSH client.

  1. If you're using OpenSSH, try using the -i argument to tell the client which private key identity file to use: ssh -i /path/to/ssh/PrivateKey ...
  2. Check the permissions on the private key and the directory holding the private key.
  3. If necessary, generate a new key and send it to your professor (see the previous section).
Getting Verbose Output

To see what the OpenSSH client program is doing, you can use the -v (verbose) argument, up to three times: ssh -vvv ...

By reading through the output carefully, you can see what the OpenSSH client program is doing, and address any problems that arise (such as permission or file naming issues).

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.

Other programs such as tmux provide similar capability.

For graphical disconnect/reconnect capability, consider using VNC.