Changes

<!-- {{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 order to gain access to these computers, you must send an [[SSH]] key to your [[User:Chris Tyler|professor]]. <!-- Please follow these instructions exactly:

# 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".-->

<!-- {{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.}} {{Admon/important|Server Changes for Fall 2019|The server configuration for Fall 2019 has configurations have changed several times -- previous mentions of these systems by name may have referred to different hardware. Note that additional servers may be added or removed as the semester proceeds.}}--> === AArch64: aarchie ===The names of servers within CDOT are based on the names of countries. There is no significance to the country names.

<!-- The current, === AArch64: israel.cdot.systems === A main [[ARMv8]] 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 aarchiewith a command such as this:  ssh ''username' or '@israel.cdot.systems<!-- === AArch64: bbetty === Another type AArch64 system is available as ''archie'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.

Bbetty is accessed on port 2202=== AArch64:ccharlie ===

ssh -p 2202 Another AArch64 system similar to bbetty is named ''usernameccharlie''@ehl.cdotThis 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.systems

And ccharlie is accessed on port 2205If you're using a command-line ssh system, you can issue a command such as this:

ssh ''username''@ddouglas.cdot.systems -->An === AArch64 system is available, known as "aarchie". You can access this system at the hostname aarchie.cdot.systems; if you're using a command-line ssh system, you can access aarchie with a command such as this:israel ===

ssh A different AArch64 system is ''usernameisrael''@aarchie.cdotThis machine has a good number of mid-level cores.systemsThis system is located outside of the EHL and can be reached directly:

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

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

<!--The second x86_64 server is known as ''yaggi'' and can be accessed with:  ssh ''username''@yaggiportugal.cdot.systems-->

user "YourUserId" -->

Host "bbetty" hostname "ehl.cdot.systems" user "YourUserID" port 2200 Host "ccharlie" hostname "ehl.cdot.systems" user "YourUserID" port 2205--> Host "portugal" hostname "portugal.cdot.systems" user "YourUserID" Host "israel" hostname "israel.cdot.systems" user "YourUserID" <!-- Host "xerxes"

ssh aarchieisrael

ssh xerxesportugal

If you wish == Multiuser Access == Remember that these machines are multi-user systems. Use the <code>w</code> or <code>who</code> commands to access the servers from additional computers, see who else is using them; you can append also try using the SSH public keys from those computers <code>write</code> 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 <code>~/password.sshtxt</authorized_keyscode> and you can change the password with the <code>passwd</code> filecommand. Your password is used for sudo access (see the next section).

{{Admon/caution|Do Not DO NOT Build or Install Software Except Via 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>yumapt</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.}}

== Multiuser 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 ==

Remember that these machines The current servers are multi-user systemsboth running Fedora 35 and will be updated from time to time. Use The machines may not be updated at the <code>w</code> or <code>who</code> commands to see who else is using them; you can same time, so the versions of software may vary slightly. The kernel versions may also try using vary between the <code>write</code> command to communicate with another user if requiredsystems because of kernel hardware support.

With other ==== Debugging SSH clientsConnection 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># Your Copy the public key must (which by default will be in OpenSSH format when you 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; this format . ===== Situation 2: The SSH client asks you for a password ===== The password is used by for the remote system, but the default SSH client on Mac OS/X and Linux as well as PuTTYwill only ask you for a password if it is unable to authenticate using your keys. If it that is the case, then one of your keys is in SSH2 formatcorrupted, missing, has the wrong permission, used or can't be found by some other the SSH client programs, .# If you can convert it with this command on a Linux system with 're using OpenSSH (such as Matrix), try using the <code>-i</code> argument to tell the client which private key identity file to use: <code>ssh-keygen -i -f ~/path/to/ssh/PrivateKey .ssh..</''SSH2_PUBLIC_KEY_FILE''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).pub  ===== Getting Verbose Output ===== 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 ...ssh</''OPENSSH_PUBLIC_KEY_FILE''.pubcode>