Default template

Copy of User Guide to ECE Linux Environment

Last edited by djgreen.

Table of Contents:

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

Gnome Classic Mode

Remote Servers

Remote Access to Teaching Labs

No Password?

Home Directory

Patching and Installing Software

AFS

NFS

Determining Permissions

Accessing from NonECE computers

Quota

Default Shell

Need tcsh?

The New Add

Modules

prepend / attach commands:

Rclone and Your Google Drive

Using GitHub Repositories

Using Singularity and Containers

Fixing SSH keys

Screen

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

miniconda

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

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/edit#

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 unityID@grendel.ece.ncsu.edu

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:

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:

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

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

Open a xterm session

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

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
  1. C:\Program Files (x86)\StarNet Communications\FastX 3
  1. Right click on FastX
  2. Click Properties
  3. Click Compatibility
  4. Click Change high DPI settings
  5. Make sure that the checkbox is unmarked for Program DPI "use this setting to fix scaling problems..."
  6. 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:

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).

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: djgreen@WOLFTECH.AD.NCSU.EDU

Valid starting Expires Service principal

10/17/2018 17:45:05 10/18/2018 07:45:05 afs/bp.ncsu.edu@WOLFTECH.AD.NCSU.EDU

renew until 10/24/2018 17:44:04

10/17/2018 17:45:05 10/18/2018 07:45:05 afs/unity.ncsu.edu@WOLFTECH.AD.NCSU.EDU

renew until 10/24/2018 17:44:04

10/17/2018 17:45:05 10/18/2018 07:45:05 afs/eos.ncsu.edu@WOLFTECH.AD.NCSU.EDU

renew until 10/24/2018 17:44:04

10/17/2018 17:45:05 10/18/2018 07:45:05 krbtgt/WOLFTECH.AD.NCSU.EDU@WOLFTECH.AD.NCSU.EDU

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\oit-rs-share-designkits@WOLFTECH.AD.NCSU.EDU:rwaDdxtTnNcCoy

A:fdg:WOLFTECH\ece-acl-dk_gf022-rd@WOLFTECH.AD.NCSU.EDU:rxtncy

A:fdg:WOLFTECH\ece-acl-dk_gf022-wrt@WOLFTECH.AD.NCSU.EDU: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.

.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:

The New Add

One other thing I want to point out... most of our Linux boxes --- including the teaching labs and the remote access servers -- are using the new "add" command.

The highlight of the way that the new system works is that everytime you run "add" its creating a new environment (think of it as a bubble).

For standard users, this isn't much of an issue. The only thing you'll notice is that you might need to type ‘exit’ more often when closing terminal windows.

Users who used to add two applications at once now need to combine their adds -- so this won’t work anymore:

add cadence2019

add synopsys2019

In this scenario, the user just created one env (bubble), then immediately jumped into a 2nd one (bubble within the bubble) where the variables for cadence haven't been set. Instead, you need to call the adds as:

add cadence2019 synopsys2019

This will create an environment with the variables/paths set for both applications within the bubble -- order matters as it will determine PATH and the order in which each applications setup scripts are executed.

Finally, for our more advanced researchers who have developed scripts that define a ton of variables before and after calling the "add" cmds within their scripts, they have a bit more work to make those scripts functional. See the example provided by a user below:

The command option indeed can be used to source CSH files. The only

thing is virtuoso also needs to be evoked with the source script since

command executes in place of an interactive shell. Also, the --command

cannot be a built-in shell command(like source)

The following line adds 3 lockers and sources the environment variables

after all the lockers are added.

add --command="tcsh adssetup.csh" cadence2017 calibre2017.3 ads2016.01

I had following things inside adssetup.csh

source $HPEESOF_DIR/bin/setCSF.csh #requires cadence before sourcing

virtuoso &

(I'm looking at improvements to the new "add" that might help with this -- such as allowing both post and pre scripts)

The most recent version of the “add” command no longer supports the use of the /ncsu/ path. Applications must use their complete installation path -- usually /afs/eos/dist/, /afs/bp/dist/, or /afs/eos/software -- instead.

If you have scripts that hardcoded /ncsu/applicationname into them, I’d recommend using /afs/eos/software/applicationname from now on -- we’re generally abstracting new software installs to recognize this path (regardless of its actual install location).

All of our "add" software is installed into AFS space. So you need to have valid AFS tokens to access it all. See above for commands to check this.

If add is being called from scripts or if you need cshell but you use bash interactively, (or need bash script from interactive tcsh) you should use

add.sh == bash

add.csh == tcsh

Like as in a bash session:

$ add.csh --command="some_cshell_script.csh" matlab

"add" simply tries to determine which shell you are using to decide which one to run. But you can call one explicitly if you need a certain shell language.

If you type “add ece” you’ll get a list of most of the applications we’ve installed for ECE users.

Modules

Going forward, we will be using modules as a replacement for add commands to gain access to programs on most of our Linux machines.

To see what modules are available to you, you will need to run modules avail:

[djgreen@godhand matlab]$ module avail

-------------------------------------------------------------- /usr/share/modulefiles ---------------------------------------------------------------

matlab/r2021a

------------------------------------------------------- /usr/share/lmod/lmod/modulefiles/Core -------------------------------------------------------

To add a module, you will need to run modules load [insert module here]:

[djgreen@godhand matlab]$ module load matlab/r2021a

To see which modules you currently have loaded, you will need to run modules list:

[djgreen@godhand matlab]$ module list

Currently Loaded Modules:

1) matlab/r2021a

Instead of typing exit to unload the module, you will need to run module unload [insert module here]:

[masumme2@godhand ~]$ module unload ansys/ansys2021r1

prepend / attach commands:

The old Linux environment also included the “prepend” and “attach” commands. These are no longer available. The first was just an alias,

Anyone using prepend in a script can add the following:

function prepend() {

export PATH=$2:$PATH

}

In tcsh it’s weirder:

alias prepend 'if (-d \!:2) if ("$\!:1" \!~ *"\!:2"*) setenv \!:1 "\!:2":${\!:1}'

The “new” add command has these builtin to allow these commands in older .environment files in our software lockers to continue to function as they are.

Rclone and Your Google Drive

The rclone client (https://rclone.org/docs/) is pushed to all ECE workstations. This software makes it very easy for you to access your NCSU Google Drive to copy files on or off your local Linux workstation -- and makes a great way for you to backup your data -- remember, you have unlimited space in your Google Drive.

[setup instructions]

[encrypting setup to avoid others using]

[sample commands]

References:

Using GitHub Repositories

If you’re not already, you need to start using the campus GitHub service to store and work on all of your code for both courses and your research:

https://github.ncsu.edu

Recommended (free) clients:

Using Singularity and Containers

As a department, our interest in machine learning and deep learning applications has increased dramatically over the past couple years, as has our usage of GPU driven applications. Many of these open source applications require very specific libraries or versions of libraries to be installed on the operating system -- these don't always match the needs of other applications, and are often newer than the default libraries provided by our RedHat Enterprise or Ubuntu LTS operating systems.

Trying to install these applications manually, and worse, trying to then keep them updated for some users but not for others, has proven to be impossible to maintain.

For this reason, we have started deploying application containers -- self contained applications which include all of the libraries needed to run them -- that we can run on either OS, and can be kept in place as long as needed without stopping us from simultaneously providing the newest versions of these applications to those working on the bleeding edge.

We will be using Nvidia's GPU Cloud as the core source of these packages to begin: https://ngc.nvidia.com/catalog/containers

We have deployed the "singularity" client to all ECE computers; we will use this to run these containers without requiring the user have sudo/admin rights on the box (one of the drawbacks and reasons we're not using docker instead). It should be noted that the campus HPC is also looking at deploying singularity to its systems, so a container you use on your workstation or the HYDRA farm, could later be used on a hundred nodes in the HPC, scaling up your research without needing to recode anything.

On the HYDRA and GRENDEL farms, you will now find a /containers directory with the initial batch of containers. Many of our initial containers expect a GPU card, so you won't find the same containers available on both server farms.

We are just starting to learn how best to use containers, but we can point out documentation for those who want to become advanced users (https://www.sylabs.io/guides/2.6/user-guide/) and have provided basic commands below.

(Note: all containers are kept in /containers on the HYDRA and GRENDEL servers. Just cd to that directory and look around to see what’s currently available.)

To inspect the metadata on a container, type

singularity inspect singularity-container-name.simg

This may be very limited information on some containers, on others, will provide version numbers for all applications within.

To start the Singularity image and then fire up a shell, type

singularity shell --nv singularity-container-name.simg

where

--nv gives your container GPU support

singularity-container-name is the container you wish to use

Type any commands you like at the prompt.

Alternately, you can create a bash shell script and run it inside of the container. To do so, once your interactive session has started, type

singularity exec --nv singularity-container-name.simg bash_script.sh

where:

--nv gives your container GPU support

singularity-container-name is the container you wish to use

bash_script.sh is your bash script

As all NGC containers are optimized for NVIDIA GPU acceleration we will always want to add the --nv flag to enable NVIDIA GPU support within the container when using any containers in /containers/ngc/. Please note that you must have a Pascal (https://en.wikipedia.org/wiki/GeForce_10_series) or Volta (https://en.wikipedia.org/wiki/Volta_(microarchitecture)) or Turing (https://en.wikipedia.org/wiki/Turing_(microarchitecture)) series of GPU to run these containers.

If there are additional applications which you'd like made available via a container, or if there's a newer version of a specific container that you'd like to use, please send a request to ecehelp@ncsu.edu (and specify if you need it on GRENDEL, HYDRA, or both). We can create a singularity container from any publicly available docker container repository.

Fixing SSH keys

Everyone once in a while you may come across the following when ssh’ing into an ECE computer:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

The fingerprint for the ECDSA key sent by the remote host is

SHA256:kBsL/Ibjw1PxwSZ5sdfdfsfsdfliN/NV5yO+QYXI/Er3XM0.

Please contact your system administrator.

Add correct host key in /Users/unityid/.ssh/known_hosts to get rid of this message.

Offending ECDSA key in /Users/unityid/.ssh/known_hosts:1

ECDSA host key for hostname.ece.ncsu.edu has changed and you have requested strict checking.

Host key verification failed.

Most often this is telling you that the computer has been reinstalled since the last time you logged into it. If that’s likely, then all you need to do is remove the reference to the computer in the file mentioned above and then try ssh’ing again. Or you can run the following command:

ssh-keygen -R hostname.ece.ncsu.edu

This will clear the old key out without you having to find it in the file.

Screen

Screen or GNU Screen is a terminal multiplexer. In other words, it means that you can start a screen session and then open any number of windows (virtual terminals) inside that session. Processes running in Screen will continue to run when their window is not visible even if you get disconnected.

You can use screen by running the following command:

$ screen

If you lose your connection to the server for whatever reason, you can regain the session by logging back into the server and using the following command:

$ screen -r

Anaconda 101

For those of you using machine learning, one of the critical applications you need to learn to use correctly is Anaconda. This will allow you to run a custom python installation within your user environment which is separate from the system installed python and often newer -- which you’ll find is important for the numerous Machine Learning (ML) and Deep Learning (DL) applications that you want to run (like TensorFlow, for example). Sometimes you just need something newer than the default python version that installed with the system; other times you’ll need a very specific version for what you’re running.

Plus anaconda includes the conda package management utility which will allow you to easily install many of the ML applications that you want and will automatically install all of their dependencies at the same time (within anaconda) so what would have been 3hrs of installing a dozen different pre-reqs becomes just one line of code.

(sidenote: avoid pip whenever possible -- you will find a ton of online ML documentation telling you how to install their software using the pip system… try using anaconda before you do)

Installation

You can download Anaconda here: https://www.anaconda.com/distribution/#download-section

Select your OS, then if you want the Python3 or Python2.7 version. Download to your home directory and install it there.

./Anaconda3-2019.03-Linux-x86_64.sh

If you cannot execute it, first run:

chmod +x Anaconda3-2019.03-Linux-x86_64.sh

(update with the correct name of the file)

Please note that a> you can install anaconda within your user home directory (which is what we want) and b> you don’t need administrative privileges to install it.

Your only constraint might be space -- so machines where your home directory is your AFS space (which NCSU only provides 10GB of) might have some issues with this as anaconda will want to use all of that 10GB of space. But outside of teaching lab systems or remote access servers, you should find that your research workstations all use local storage now for your home directories.

When installing, go ahead and have anaconda setup its initialization scripts (but see below).

Don’t Start in Anaconda by Default

Last login: Mon Jul 22 18:40:18 2019 from rampart.ece.ncsu.edu

(base) [djgreen@timeflip ~]$

The first thing you’ll notice after you install anaconda (and either logged out and back in OR ran “source ./.bashrc”) is that your prompt changes to the one above.

This indicates that you’re within the anaconda environment… but you don’t want this to be your default. This can break things -- access to your Gnome environment is a common one.

Run the following command:

conda config --set auto_activate_base false

Log back out / in and you’ll find your prompt back to normal. From now on, conda is in your path, but its not running by default.

To enter the conda env, run “conda activate” and to exit, run “conda deactivate”

User, not System Packages

[need docs]

Create Conda Environments

Need to install tensorflow?

conda create --name tf_gpu tensorflow-gpu

This is the same as running:

conda create --name tf_gpu

conda activate tf_gpu

conda install tensorflow-gpu

Updating Conda

In most cases what you want to do when you say that you want to update Anaconda is to execute the command:

conda update --all

If you are only interested in updating an individual package then from the command line:

conda update astroid astropy

However, Your root environment is probably not a good place to try and manage an exact set of packages—it is going to be a dynamic working space with new packages installed and packages randomly updated. If you need an exact set of packages, create a conda environment to hold them. Thanks to the conda package cache and the way file linking is used, doing this is typically fast and consumes very little additional disk space. For example:

conda create -n myspecialenv -c bioconda -c conda-forge python=3.5 pandas beautifulsoup seaborn nltk

Recommended Reading

Educational Videos

Uninstall

One of the nice things about installing anaconda in your home directory is that it's incredibly easy to uninstall it… just delete the directory. Open a terminal window, and then remove your entire Anaconda directory, which has a name such as anaconda2 or anaconda3, by entering:

rm -rf ~/anaconda3

Also, remove the conda initialize code from your .bashrc

# >>> conda initialize >>>

# !! Contents within this block are managed by 'conda init' !!

__conda_setup="$('/home/djgreen/anaconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"

if [ $? -eq 0 ]; then

eval "$__conda_setup"

else

if [ -f "/home/djgreen/anaconda3/etc/profile.d/conda.sh" ]; then

. "/home/djgreen/anaconda3/etc/profile.d/conda.sh"

else

export PATH="/home/djgreen/anaconda3/bin:$PATH"

fi

fi

unset __conda_setup

# <<< conda initialize <<<

add anaconda3

There is an installation of anaconda in AFS which you can add to your environment as an alternative to local installation -- “add anaconda3”

The advantage of this installation is that you can minimize the space needed -- for example, you could use this on our HYDRA or GRENDEL remote access systems where your AFS quota is quite small.

Courses are likely to be the largest user of this option.

The following steps, for example, would allow you to call the application into your environment, create a conda environment, activate it, and then add additional anaconda packages (qiskit) to your local storage that’s not provided through the “add” install:

add anaconda3

conda create -n ece792-046

(creates new env in ~/.conda/envs/ece792-046)

source activate ece792-046

#now install what you need

pip install qiskit --user

miniconda

We’ve found that anaconda versions can greatly impact your install, so sometimes the version in AFS isn’t new enough… this is where miniconda might be helpful. It’s the tiniest version of Anaconda and you can install it in your AFS home space.

First you need to download the latest version from https://docs.conda.io/en/latest/miniconda.html#linux-installers

I recommend heading there, copying the link, then using wget to grab it…

wget https://repo.anaconda.com/miniconda/Miniconda3-py39_4.10.3-Linux-x86_64.sh

bash Miniconda3-py39_4.10.3-Linux-x86_64.sh

Follow their instructions… go with the defaults. It’ll want to install to /afs/unity.ncsu.edu/users/d/djgreen/miniconda3 (replace d/djgreen w/ your path), which is fine.

I would recommend that unless you’ll be using it alot, to not add it to your environment by default. In which case, you can activate it with the following command:

eval "$(/afs/unity.ncsu.edu/users/d/djgreen/miniconda3/bin/conda shell.bash hook)"

(yes, its a mouthful and be sure to fix that path for yours)

Alternatively, have it add it, but then immediately run the following command to have it present but disabled by default

conda config --set auto_activate_base false

(ok, the alternative option is probably going to be saner in the long run)

GPU Resources

If you need access to GPU resources for your work, you have multiple options to explore:

HYDRA

See our section above for details on this farm of servers.

VCL

Starting in the 2019 fall semester, VCL now offers a pilot program with some limited access to VMs with GPUs attached. Currently, VCL only supports having a single GPU attached to a VM. There are 2 Tesla P100 GPUs and 4 Grid K2 GPUs available. Reservation durations may be more strictly time limited than other reservations due to the limited number of GPUs available.

To obtain access to the GPU enabled VMs, use the help support form to request access and explain your use case. Also, if use is for a project or course, please include the professor and/or course number.

See https://vcl.ncsu.edu/get-help/documentation/gpu-enabled-vms-in-vcl/ for more information.

HPC

Here is the Quick Start Tutorial

https://projects.ncsu.edu/hpc/Guide/

HPC Learning / Training Materials:

https://projects.ncsu.edu/hpc/Documents/hpc_links.php

And HPC Office hours are here:

https://projects.ncsu.edu/hpc/Documents/UserTraining.php#hours

Details on Anaconda usage on the HPC:

https://projects.ncsu.edu/hpc/Software/Apps.php?app=Conda

New HPC Video Series:

Research Servers

Check with your advisor to see if they have purchased a server that includes GPUs within them for their research team. These systems will be limited to a particular research group and might be more useful to you than one of these other options.

AWS

As an NC State student, you can make use of free credits that are provided to our students. All of our students are eligible for the AWS Educate program. By default, this program provides $40 in free AWS credits to students across the globe, but because NC State has enrolled as a member of the AWS Educate program. Because of this, our ECE students will actually get $100 per year in free credits.

$100 in credits should be more than enough for most course projects (provided you turn the systems off when not needed). And the credits only come into play should the students be doing something that exceeds the free tier at AWS (for folks using AWS for the first time).

How do you sign up?

  1. Create an AWS account using your unityID@ncsu.edu email address. This is required.
  2. Once created, visit the AWS Educate site and register under the student role: https://www.awseducate.com/registration

You’ll get an email within 24-36hrs with a voucher for the free credits. You’ll need to monitor your usage to make sure you don't spend beyond that or it comes out of your pockets.

---

Now, if you think that you'll have a need beyond this where you'd want to cover the costs on a researcher’s NC State account, then we can create a special AWS account for the professor, then register it through the campus Internet2 contract for AWS services. Any fees charged to that account can then be automatically charged to a departmental account each month. Our contract also waives all in/out data transfer fees into AWS.

FYI: Amazon's Machine Learning University is making its online courses available to the public -- classes previously only available to Amazon employees will now be available to the community:

Software Collections

In order to provide ECE staff and students with the latest industry standards, we’ve installed three packages that provide updated versions of gcc, Python and other development tools on our RHEL systems. The packages installed include devtoolset-8, python27 and python36. These packages allow for development with newer compilers and code versions without interfering with the existing system installations.

scl -l will list all collections installed on your system.

As an example, you can use Python3.6 in a Bash shell with the following command:

scl enable rh-python36 bash

Or enable gcc 8.3.1 with the following command:

scl enable devtoolset-8 bash

If you need to use both, you can call both at the same time:

scl enable rh-python36 devtoolset-8 bash

For a full list of features and User Guides please see the links below:


Appendix A: No Tokens at Login (GSSAPI issue):

When connecting to a campus Linux machine from another campus Windows machine, you may find that the Linux machine doesn’t ask for a password, and automatically logs you in -- but that you don’t have valid AFS tokens.

(note, this will ONLY occur on campus machines joined to the WolfTech Active Directory domain -- this does not impact personal computers connecting to campus Linux machines)

Technical Background

Here's a KB article from MIT on the subject that explains Kerberos authentication vs delegation: http://kb.mit.edu/confluence/pages/viewpage.action?pageId=4981397

In short, you can use kerberos to authenticate to a machine using GSSAPI but NOT delegate your credentials cache to the remote machine.

When you do this, the remote server knows who you are, but does not create a credentials cache for your new session. As such, if you do not delegate your credentials, then you will have NO cache and since you have no cache, aklog will fail to retrieve AFS tokens.

Fixing your Clients

If using Putty, open the client and create a new session after enabling the following configurations:

Connection > SSH > Auth > GSSAPI -> "Attempt GSSAPI authentication (SSH-2 only)" (enabled, by default)

Connection > SSH > Auth > GSSAPI -> "Allow GSSAPI credential delegation" (*disabled*, by default)

If you’re using MobaXterm, click Settings > Configuration, and uncheck “GSSAPI Kerberos”:

Making these changes should force the ssh client to request your password as it has in the past. And once logged into the remote computer, you should find that you have valid AFS tokens.


Appendix B: Standard Dot Files

In new environment, no cmd to reset these to their defaults -- need to consider creating one.

Default .cshrc

[klmorr22@grendel2 ~]$ more .cshrc

################################################################################

# #

# .cshrc file (initial setup file for C-Shells) #

# #

# WARNING: PLEASE READ THE REST OF THIS FILE BEFORE MAKING ANY CHANGES !!! #

# #

################################################################################

if (-d /usr/athena/lib/skeleton) then

set skeleton=/usr/athena/lib/skeleton

else

set skeleton=/afs/bp.ncsu.edu/system/common/skeleton

endif

if (-r $skeleton/cshrc) then

source $skeleton/cshrc

else

if ($?prompt) then

echo "WARNING: System-wide initialization files were not found."

echo " C-Shell initialization has not been performed."

endif

set path = (/bin $HOME/bin /usr/local/bin /usr/bin/X11 /usr/athena/bin \

/usr/afsws/bin /usr/ucb /usr/bin .)

limit coredumpsize 0

set prompt="eos% "

set ignoreeof

umask 077

alias rm rm -i

endif

if ($?XSESSION) then

if (-r /usr/athena/bin/end_session) alias logout '/usr/athena/bin/end_session && exit '

if (-r /usr/bin/end_session) alias logout '/usr/bin/end_session && exit '

endif

################################################################################

Default .bashrc

[klmorr22@grendel2 ~]$ more .bashrc

# .bashrc

# Source global definitions

if [ -f /etc/bashrc ]; then

. /etc/bashrc

fi

# Uncomment the following line if you don't like systemctl's auto-paging feature:

# export SYSTEMD_PAGER=

# User specific aliases and functions

Default .bash_profile

[klmorr22@grendel2 ~]$ more .bash_profile

# .bash_profile

# Get the aliases and functions

if [ -f ~/.bashrc ]; then

. ~/.bashrc

fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH

Default .login

[klmorr22@grendel2 ~]$ more .login

################################################################################

# #

# .login file (terminal setup file) #

# #

# Note: This file is only read once after the .cshrc file when log in. #

# It will not be read again for subsequent shells. #

# #

# WARNING: PLEASE READ THE REST OF THIS FILE BEFORE MAKING ANY CHANGES !!! #

# #

################################################################################

if (-d /usr/athena/lib/skeleton) then

set skeleton=/usr/athena/lib/skeleton

else

set skeleton=/afs/bp.ncsu.edu/system/common/skeleton

endif

if (-r $skeleton/login) then

source $skeleton/login

else

if ($?prompt) then

echo "WARNING: System-wide initialization files were not found."

echo " Login initialization has not been performed."

endif

stty dec

switch ($term)

case xterm:

setenv DISPLAY unix:0

set noglob; unsetenv TERMCAP; eval resize; unset noglob

breaksw

default:

set term=vt100

setenv TERMCAP /etc/termcap

breaksw

endsw

setenv TERM $term

endif

################################################################################

# #

# If you would like to modify the login initialization sequence, please #

# make the changes in a file called .mylogin located in the top level #

# of your home directory. Your ~/.mylogin file is used only to set up #

# your terminal type. For other customizations, please refer to the #

# comments in your default ~/.cshrc. #

# #

# WARNING: Any changes in this file may disappear one day when the system #

# is updated! Make sure you know what you are doing!!! #

# #

################################################################################

Default .logout

[klmorr22@grendel2 ~]$ more .logout

clear

date