User Guide to ECE Linux Environment PDF

Preview

Summary

ECE Linux Environment...

Description

User Guide to ECE Linux Environment Environmental Changes Software for Personal Computers Remote Access FastX Download and Install Download and Install v2 clients Connect to a Server Open a xterm session High DPI Settings Remote Servers Remote Access to Teaching Labs No Password? Home Directory Patching and Installing Software AFS Quota Default Shell Need tcsh? The New Add prepend / attach commands: Rclone and Your Google Drive Using GitHub Repositories Using Singularity and Containers Fixing SSH keys Anaconda 101 Installation

Don’t Start in Anaconda by Default User, not System Packages Create Conda Environments Updating Conda Recommended Reading Educational Videos Uninstall add anaconda3 GPU Resources HYDRA VCL HPC Research Servers AWS Software Collections Appendix A: No Tokens at Login (GSSAPI issue): Technical Background Fixing your Clients Appendix B: Standard Dot Files Default .cshrc Default .bashrc Default .bash_profile Default .login Default .logout

Environmental Changes ● ●

“Rm” will no longer prompt for confirmation by default Ctrl+d to log out works now, instead of "use logout to logout"

Software for Personal Computers Before you remote in, first check to see if the software you need is available to be installed on your personal computer: https://docs.google.com/document/d/1bXHRtLWIxh4GP49GUU4r6Ldxpg5vydbrP4fxtPgCRiU/ed it#

Remote Access First, if you're offsite, you must have an active VPN connect to talk to any ECE computer. https://vpn.ncsu.edu. Please see https://go.ncsu.edu/remote if you need a walkthrough on using the VPN client. Second, you have two options to access an ECE Linux computer -- ssh or FastX. Remember to use the full name of your computer -- computername.ece.ncsu.edu For ssh, I recommend that you install this free client on your windows computer: https://mobaxterm.mobatek.net/download.html. The campus HPC also provides information and instructions for this client: https://projects.ncsu.edu/hpc/Documents/mobaxterm.php If you’re using a personal MacOS machine, then you can use the built in “terminal” application to ssh to another machine. But if you want to X terminal back to your local machine, however, you will need to have XQuartz installed. You can download this from https://www.xquartz.org/. Start the application and right click on the icon in the dock, selecting Applications>Terminal. This should bring up a new xterm window. From here, ssh into the remote linux system using the -X argument (secure X11 forwarding). For example: ssh -X [email protected] Both Windows and MacOS users can alternatively can use FastX -- see below for the client download and setup (or install from Software Center if you’re on an ECE Windows computer or Self Service if you’re on an ECE MacOS system). The usage of FastX is encouraged when

accessing our servers from offsite when a GUI application is used -- the protocol used by FastX is superior to ssh over WAN networks and will result in a faster remote experience. Details on the setup and usage of ssh can be found on https://go.ncsu.edu/remote If you need to transfer files, we recommend Filezilla (Win/Mac), Cyberduck (Mac) or WinSCP (Win) as a client. SFTP must be used instead of FTP and we recommend just connecting to remote.eos.ncsu.edu if all you want to do is transfer files in and out of your AFS space.

FastX Starnet FastX 3 is an alternative to the X-Win32 software and is WolfTech's current recommendation for remote connections to ECE department Linux servers. NOTE: Images on this page were taken from the macOS version of the software. The appearance may differ on other OSs, but functionality should remain the same.

Download and Install If you are on an ECE department Windows or Apple machine, you can find an installer for FastX 3 in the Software Center or SelfService applications on those OSs. For Linux machines or personal machines, download the installers from the links below: ● ● ●

Windows: Download here Linux 64-bit Download here Macintosh: Download here

Download and Install v2 clients We're in the process of slowly upgrading our systems from FastX v2 to v3 -- if you're specifically directed to use the v2 client, you can download them here: ● ● ●

Windows: Download here Linux 64-bit Download here Macintosh: Download here

Please note that you cannot use the v3 client with a v2 server (and vice versa) so only install these if instructed.

Connect to a Server ● ● ●

Contact [email protected] if you do not know what server to use. You must have an active VPN connection to campus before you can talk to any ECE computer. See the image below for how to create a connection to a server.

1. Open FastX3 on your local machine 2. For new machines a. Click the plus icon in the top right corner b. Fill out the information in the dialog box that opens up i. Make sure that you’re entering the full name of the computer -- aka, computername.ece.ncsu.edu ii. Keep “Forward Agent Connections” unchecked. c. Click Save when finished 3. Double click the machine you’d like to open 4. Type in your password a. If it's your first time connecting, you may need to accept machine authentication

Open a xterm session ●

●

NOTE: WolfTech recommends only using xterm sessions. You may use the GNOME session if you wish, but be aware you may experience lag or other issues, especially if you are connecting from off-campus. Some shared servers -- including HYDRA and GRENDEL -- will not provide the option for GNOME. See the image below for how to open an xterm session.

1. Click the plus icon to bring up the session select menu 2. Choose “xterm” and click OK.

● ● ●

After the xterm launches, use as normal. When finished, use 'exit' to close the xterm. Close the connection window to end your connection to the server.

High DPI Settings For those with High DPI displays, below is a set of instructions that can be used to increase visibility when using FastX on Windows: 1. Navigate to the installation directory a. C:\Program Files (x86)\StarNet Communications\FastX 3 2. Right click on FastX 3. Click Properties 4. Click Compatibility 5. Click Change high DPI settings 6. Make sure that the checkbox is unmarked for Program DPI "use this setting to fix scaling problems..." 7. Make sure the checkbox is marked for "High DPI scaling override" and set the scaling performed by: "System"

It should now scale with your windows display settings for "Scale and layout" -- go to Settings, System, Display, and here you can select to increase the size of text and apps. In the example below, you’ll see where these have been increased to 150%.

Using this method may result in the text or icons being displayed a bit fuzzy. You should experiment to see what scale works best for you.

Gnome Classic Mode If connecting to a system via Gnome is permitted, you might want to make use of the classic mode of the Gnome interface. If so, when selecting the pre-defined option for "gnome-session" change it to "gnome-shell --mode=classic" instead.

Remote Servers The ECE department has two remote access server farms (note these are not “clusters” but collections of servers) that are open to everyone within the department. These are primarily intended for academic usage, but we’re OK with researchers also using them as long as you don’t attempt to abuse them (aka, logging into multiple GRENDELs at once). GRENDEL.ece.ncsu.edu -- collection of approximately a dozen RedHat Enterprise Linux 7 systems with around 64GB - 96GB RAM each.

HYDRA.ece.ncsu.edu -- small farm of three GPU servers running RedHat Enterprise Linux 7 with 128GB of RAM and dual Nvidia Titan Xp GPU cards in each. Both GRENDEL and HYDRA systems support FastX3. Should you be working for a particular researcher, you’ll also be able to gain access to any research servers specific to their group. These will generally be more powerful, will provide local storage, and will certainly have less users sharing them. If you have access to one of these, we ask that you make use of it instead of the GRENDEL/HYDRA systems as our course resources are limited. Each of these clusters are rebooted Monday morning.

Remote Access to Teaching Labs With access to the teaching labs being revoked, we’ll be permitting remote access to the ½ of the computers in the 1014 and 1028 EB2 teaching lab to help offset the load on the GRENDEL servers. We recommend the usage of FastX to access these systems from offsite. We have added these to a VCL checkout / reservation system. You will need to visit https://vcl.ncsu.edu/ in order to reserve time on these machines for use. Only one student per workstation will be permitted. Click “Reservations”

Click “New Reservation”

When the “New Reservation” window opens, please select “ECE Linux Lab Computer” from the drop down menu. Then, click “Create Reservation”

After clicking the button, wait a couple of minutes. You will then see two buttons and a drop down menu along with information about the lab machine.

When you click connect, another window will pop up with information on how to connect to the machine.

We recommend that you follow instructions on how to connect to Linux machines as outlined in our Working Remotely document, but some quick highlights: 1. You must have a working VPN connection to vpn.ncsu.edu to connect to our systems remotely. 2. You can use ssh or you can use FastX v3 to connect to these systems -- we recommend FastX as it will provide a smoother connection from off campus: https://go.ncsu.edu/fastx 3. Remember that these are standard ECE Linux systems -- so revisit our documentation at https://go.ncsu.edu/ece-linux

In addition to our ECE teaching labs, the College of Engineering has also added their workstations to VCL in this manner -- you can access them with these “image” requests: ● “Eos Linux Lab Computer” ● “Eos Linux Lab Computer with GPU” If you see an error similar to this one where the reservation has failed...

Then most likely, the individual computer that VCL is trying to check out to you is having issues. When this happens, VCL makes a note and skips that computer until its fixed. So remove your reservation and try again -- a different computer should be selected for you.

No Password? Sometimes when you login to a Linux box, you’ll note that you were not asked for your password… The new Linux machines are using Windows Active Directory for their authentication provider. The same as all of our managed Windows boxes. For this reason, when you connect to the Linux machine, it will often recognize your security tokens on your desktop and immediately authenticate you to the Linux machine. This will only work on our managed systems. There are times when this won't work for various technical reasons or due to the configuration of the ssh client you're using, but yes, this is to be expected now in the new Linux environment. (this doesn't mean that everyone can login to the machine) 3/1/2019 UPDATE: turns out this will cause issues with your AFS tokens… see Appendix A for the resolution.

Home Directory On most research workstations and research servers, users may now find themselves using a local home directory (/home/username) instead of your AFS home directory (/afs/unity/users/u/unityid). We're working to slowly move our systems away from their dependence on AFS -- this is one of those steps. Exceptions to this will generally be teaching lab workstations and the remote access clusters (hydra.ece.ncsu.edu, grendel.ece.ncsu.edu, remote.eos.ncsu.edu, for example). You can still access your AFS homespace by "cd /afs/unity.ncsu.edu/users/u/unityid/" - and yes, plain "cd" will now bring you back to your local HOMEDIR -- which on the machine is /home/unityid/ You could create yourself an easier path... cd ln -s /afs/unity/users/u/unityid/ afshome This will create a symlink (will look like a folder) in your local home to your AFS home that will save you some effort when you need to access those files.

Patching and Installing Software We've been updating the defaults permissions we push out with our research Linux workstations (this does not apply to our teaching labs nor GRENDEL/HYDRA farms) to allow our users some more control over their workstation without having full administrative rights. You now have the ability to run the following cmds as admin on the box from terminal -- "apt-get" and "reboot". In particular, you'll now have the following functions: ## useful to run prior to updating packages sudo apt-get update (Ubuntu) ## will attempt to install all updates and packages sudo apt-get upgrade (Ubuntu) ## will immediately reboot the system

sudo reboot ## will install package if available on a repo configured on the system sudo apt-get install package (Ubuntu) Sudo yum install package (RHEL) ## be careful with this one sudo apt-get remove package (Ubuntu) Sudo yum remove package (RHEL) We don't currently patch research workstations on a schedule. I'd like to, but doing so in a way that doesn't disrupt your research is difficult as a reboot is always advisable after patching a computer. So we rely on our users to do this. Ubuntu is pretty good about telling you when you have pending patches. We'll be seeing what we can do on RHEL to make it similarly obvious. When you see that there's pending patches, all users of the box -- if you're on a multiple user box, please be sure to coordinate with the others so you don't disrupt their work -- can now run the following to patch their system: (on Ubuntu) sudo apt-get update sudo apt-get upgrade sudo reboot (or on RHEL) sudo yum update sudo reboot If you’re asked questions during the patching, accept the defaults. You’ll sometimes see a question related to the AFS client, for example. Just click enter to accept the default selection.

AFS AFS is still installed on most systems so you can access this file service when needed. In addition, the renewal of AFS tokens has been improved and should happen automatically (no more having to use kreset -l before overnight jobs are run).

○ ○ ○

Every 10 minutes, a daemon (krenew) running on all of your machines “wakes up” and extends the Kerberos TGT and then runs “aklog -force eos unity bp”. The AFS token lifetime is based on Kerberos service granting tickets - you effectively have AFS tokens for as long as your TGT can be renewed. Currently 7 days is set as the default. Due to recent changes to the WolfTechAD domain controllers, we have the ability to set 32 day renewable Kerberos tickets as a client default. If you have someone right now that wants a 4 week job to run, they simply run: kinit -l 24:00 -r 32d; aklog eos unity bp

You can check your tokens at the cmdline: tokens klist Both of these cmds will show you your active kerberos tickets. You want to see something like: [djgreen@grendel1 CONFRML181]$ klist Ticket cache: KEYRING:persistent:43775:krb_ccache_VkSkoBu Default principal: [email protected] Valid starting Expires Service principal 10/17/2018 17:45:05 10/18/2018 07:45:05 afs/[email protected] renew until 10/24/2018 17:44:04 10/17/2018 17:45:05 10/18/2018 07:45:05 afs/[email protected] renew until 10/24/2018 17:44:04 10/17/2018 17:45:05 10/18/2018 07:45:05 afs/[email protected] renew until 10/24/2018 17:44:04 10/17/2018 17:45:05 10/18/2018 07:45:05 krbtgt/[email protected] renew until 10/24/2018 17:44:04 If you don't, then you need to renew these. You can do this manually with this command: kinit;aklog eos unity bp Now try checking your tickets again. Your AFS tokens are supposed to auto renew, but sometimes this doesn’t occur if you’ve not logged out or rebooted your computer in a while. In addition, we’ve found the auto renew to not work as well on Ubuntu systems.

NFS Determining Permissions First you need to install nfs4-acl-tools (installed by default on ECE computers) > yum install nfs4-acl-tools You can useThen you can look at the NFS permissions: [djgreen@mrblonde designkits]$ nfs4_getfacl gf022 # file: gf022 A:fdg:WOLFTECH\[email protected]:rwaDdxtTnNcCoy A:fdg:WOLFTECH\[email protected]:rxtncy A:fdg:WOLFTECH\[email protected]:rwaDdxtTnNcy

Accessing from NonECE computers When attempting to access the campus research data stored on the NFS servers, you’ll find that we already have this mounted on all ECE Linux systems (/mnt/research-faculty and /mnt/research-projects) and all ECE computers have already been whitelisted for access. NonECE computers -- and in particular personal computers -- must first be connected to the campus VPN service to access the research data servers. This includes when the laptop is onsite and on the campus wifi network. You will also need to map a drive to the specific share that you need -- you can get the path by logging into https://research.oit.ncsu.edu and reviewing the shares you have access to. If asked for a username and password when mapping the drive, use your unityID (not your email address) and password. You may need to enter your username as wolftech/unityID rather than just unityID since the system is expecting to talk to computers joined to the campus active directory environment. Please note that prior to any of this, your professor would have needed to add you to the access list for one of their shares -- they can manage this at https://research.oit.ncsu.edu.

Quota The old “quota” command is gone.

If you're in your AFS space, you can use fs lq to list the quota of the volume you’re currently in. When on the local machine (/home for example), you have no "quota" really -- just the limits of the harddrive. You can use df -h to see the partitions and space available/used. Look for /home to see what's there. du -h is a good way to see what's taking up space. du -h --max-depth=1 will limit the details to that folder and its immediate subfolders so you can tell where the space is being taken up. Please note that if you fill your AFS quota, you will not be able to login to computers which use this space as your home directory as the login process requires that temporary files be created and this fails. Often computers in public labs, teaching labs, or remote access servers (like the GRENDEL or HYDRA clusters) will be setup this way. The easiest way to clear some of your quota, if you find yourself locked out of Linux systems, is to use an SFTP client on a Windows machine to connect to remote.eos.ncsu.edu and delete any files from your home directory. Remember, NCSU only provides a 10GB quota for students' home directories on the campus AFS system. Be wary of your space usage.

Default Shell Bash is the default shell, not tcsh. ● How do you confirm your current shell? Type “echo $0” .mybashrc will no longer be referenced at login -- use .bashrc instead Sample default dot files are provided in the appendix for reference. Keep in mind that your home directory on public machines (remote access servers and teaching lab machines) will remain in AFS (/afs/unity/users/u/unityid), but other machines -- personal workstations and research servers -- will be using a local home directory on the machine (/home/unityid). So your dotfiles might not follow you everywhere -- you might need to make a copy of the files (or symlink back to the ones in your AFS home directory if you like).

Need tcsh?

Typing ‘tcsh’ will switch you from the default bash to tcsh for your shell. However, things to be aware of: ● In the new environment, if you want to customize your tcsh environment, you need to use .cshrc instead of .mycshrc ○ Those of you who’ve been here a very long time might have some scary “don’t touch this file” text in this file -- if you do, just rename your .cshrc file to .cshrc.backup, create a new .cshrc file and move your cmds there. ● When creating your .cshrc file,...