After an update of nodes, such as the May 2018 upgrade to CentOS 7, the SSH key fingerprint of a node may change. This will, in turn, cause an error when you next try to log into that node as your locally stored key will no longer match. SSH uses this as a way to spot man-in-the-middle attacks or DNS spoofing. However, when a key changes for a valid reason, this does mean you need to clear out the one on your computer in order to be able to re-connect.
See this FAQ page for further instructions: SSH key error, DNS spoofing message

Modules in your .bashrc no longer work or give errors on login
If you have edited your .bashrc file to include module loads at login, you may find that some CentOS 6 modules will not be found or may not work on CentOS 7. You will need to edit your .bashrc and comment out or remove any such lines going forward. If you can no longer log in because of something in your .bashrc, contact us and we can rename your .bashrc and copy in a default version for you.
If you'd like to start from scratch, a default .bashrc contains the following:

# .bashrc

# Source global definitionsif [ -f /etc/bashrc ]; then. /etc/bashrcfi

# User specific aliases and functions below

Can I removesource new-modules.shfrom my .bashrc ?
Yes. It no longer serves a purpose and can be removed. It's not absolutely necessary for you to remove it, but it's recommended if you're comfortable with editing your .bashrc file as it makes for a cleaner login.

CentOS 7 modules and searching
The Portal is the best place to search for modules, and provides far more information that module spider will. By default, the portal will now search for CentOS 7 modules (an option to switch to search old modules is also available): Portal Module Search

As always, you have the ability to install your own software in many cases (especially true for R, Python, Anaconda).
Please see our Installing Software Yourself page.

For more information and information on legacy CentOS 6 modules, see the Running Jobs page.

Singularity
New to Odyssey3 is the concept and implementation of containerized environments for jobs. We have standardized on Singularity for this and it is available now on Odyssey3. For more detailed information and instructions, see:

Please Note: You cannot run Singularity on a login node (much like you should not run jobs or heavy software there). You will need to run it from an interactive session. More details in Singularity on Odyssey

If using NX/NoMachine or a CentOS 6 node, don't cross-submit jobs to CentOS 7 partitions/queuesDue to some environmental differences between CentOS 6 and CentOS 7, if you are using an NX/NoMachine node or your lab has access to any nodes running CentOS 6 [which we are happy to upgrade for you], do not launch jobs for partitions/queues running CentOS 7 directly from that node or you may experience odd job failures (e.g. - failures from basic commands which have moved to a different location on 7). And vice-versa, if you use ATLAS or another partition which still has CentOS 6 nodes, don't launch jobs from CentOS 7 nodes; Use that partition's dedicated nodes.

After you log in to the CentOS 6 node, or establish an NX session on a CentOS 6 NX server (holynx01, rcnx01, etc.), start an interactive session on the test partition. Once you are in the interactive session run source centos7-modules.sh, that will enable the CentOS7 specific modules and rectify any lingering issues with your run environment. Once that is complete you can submit jobs as per normal. Users should not submit jobs directly from the NX nodes or CentOS 6 nodes to Slurm as Slurm will map the current CentOS 6 environment into the job they submit, this can create problems for the job. Instead jobs should always be submitted from interactive sessions.

Alternately, you can, from a terminal in your NoMachine session, ssh -CY login.rc.fas.harvard.edu (with X11 forwarding) to a login node. This will have largely the same effect.

What about old modules?
While it is true that some older modules will work on CentOS 7 without recompiling or rebuilding, we do not offer any guarantees on that front. You are free to try, but we have no plans to try to go back and make changes to old modules or to support their use. Use at your own risk.

My alternate shell (csh, tcsh, etc.) doesn't work right
Having a non-standard default shell will cause problems and does not allow us to set global environmental defaults for everyone. We will no longer change the default shell on any account or support the use of alternate shells as default login shell. Users who do not have bash as their default login shell will need to change back to bash. Users can, of course, still launch an alternate shell once logged in.

Still need help transitioning to CentOS 7?

You can always visit our regular Office Hours which run from roughly late August until the end of May/start of June.
See our Office Hours calendar.

Or send us a help ticket via our Portal (preferred) or by emailing rchelp@rc.fas.harvard.edu