more markdown conversion from Docuwiki

If you run a machine that is frequently disconnected from the network, like a laptop, or don't want to set up an NFS-shared software installation, it is possible to install the software to the hard disk on your local machine.

There are two scripts in the programs tree that can be used to create a copy of the software on your local hard disk. The ''sbgrid-laptop'' script allows you to select individual applications from the software distribution for installation on your laptop. By default only the latest version of the selected applications will be installed. The ''localsync'' script allows you to copy an entire operating system software branch to your local machine. This script can be used on laptops, but each branch is quite large in terms of disk space usage.

You can create a customized local installation of the software using the ''sbgrid-laptop'' script located at ''/programs/share/bin/sbgrid-laptop''. This script requires you to have an SSH login to a computer that has access to an SBGrid software installation and will let you specify which packages you want to install.

Copy the script the machine you want to install the software on, and then run it in install mode: ''./sbgrid-laptop -i''. Follow the prompts on the screen to create your configuration file, your software installation list and to enable logins using an SSH key for authentication.

There is a script in the programs tree that can be used to copy the appropriate branch from a shared installation to your laptop or workstation.

Copy /programs/share/bin/localsync from the machine that has the software to your home directory on the standalone machine:

Then run the script like this:

The script will prompt you for your sudo (admin) password in order to create the programs directory, and then it will prompt you for your login password to the server that hosts your programs installation.

Here is an example run on my workstation:

This will copy the entire branch for your architecture to your local hard drive. For the OS X branch, this will use approximately 100 GB of disk space.

You should use a network cable for the initial download, since the download is fairly large. Subsequent runs of the 'localsync' script are differential; they will only copy new or changed files, so they can be run over a wireless connection. The script can be run at any time to make your local installation match the installation on your local server.

While we recommend that sites export their software installation via NFS to their workstations, it is possible to use rsync to copy the master installation to each workstation. This method has the drawback that it requires manual intervention on the part of the local sysadmin, and updates will not be instantaneous or simultaneous for all machines.

On each client machine, you'll need an 'sbgrid' user. That user will have a passphraseless ssh key that lets it log into the machine that hosts your primary installation. Each client machine will have a cron job for that sbgrid user that runs at 2 AM that will sync the programs from the master installation to the client machine.

* Create the 'sbgrid' user on client1

* Check the free space on /.

* If there's enough free space, set up the programs directory:

* If there is not enough free space on the root volume, you'll need to find space on a local volume.

* Login as 'sbgrid' on client1.

* Create the passphraseless ssh key:

(hit enter to confirm default file location, no passphrase, etc)

* Copy the ssh key to server1:

* Copy the localsync script from server1 to client1. From client1:

(May prompt to accept the host key. If you can't login without a password, the ssh key stuff above has failed, and you'll need to troubleshoot that.)

(This will take a while depending on the speed of the machines/network.)

* Test the installation:

tcsh

bash

(You should get a message like this: )

Welcome to SBGrid!

********************************************************************************

Your use of the applications contained in the /programs directory constitutes

acceptance of the terms of the SBGrid License Agreement included in the file

exclusively to member laboratories of the SBGrid Consortium.

To hush this license message, run 'touch ~/.agree2sbgrid'.

********************************************************************************

This installation last updated: 20110411

********************************************************************************

Total time to initialize: 1 second(s)

* Add a cronjob for the updates. As the 'sbgrid' user on client1:

* Check the cronjob:

The SBGrid Software Suite is designed to be installed on a single computer at your site, which will then share that installation with all the workstations on your network via NFS.

We refer to this computer as the site "master" server.

{{howtos:site_diagram.png?250}}

* Lab Name

* Types of computers on site: Linux, OS X Intel, OS X PowerPC, IRIX

* The names and email addresses of lab members that will use the software. One user may be designated to receive the majority of our correspondence if you would prefer not to hear from us too often.

Once the email has been received and your information has been entered into our system, we will email you a script you will run that will begin the remote installation process. Instructions for running the script will be included in that email, and are reproduced below for reference.

\\

We build and test software under 64-bit Red Hat 6. The majority of our Linux users are using the Red Hat/CentOS/Scientific Linux or Fedora distributions, but we also have labs using the software with Ubuntu, Debian and OpenSuSE. We don't explicitly test the software on these distributions, but it is known to work, and we will work to resolve problems reported by users of these Linux distributions.

We officially support the two most recent releases of Red Hat/CentOS/Scientific Linux (currently 6 and 7) and the two most recent releases of Fedora Linux. At this time, only 64-bit versions of linux are fully supported. As of January 2015, we are no longer updating the 32-bit software branch, though we will work to resolve reported problems.

Currently Supported:

* Red Hat Enterprise Linux 6.x and 7.x and the community supported versions: CentOS and Scientific Linux.

* Fedora releases actively supported by the Fedora community. Check https://fedoraproject.org/wiki/Releases for the current list.

We build and test the programs under the most four most recent OS X releases.

Currently Supported:

* OS X Intel 10.7 - 10.10

The OS X PowerPC branch is currently frozen. The applications are stable and work well on our PowerPC hardware, but they are not being updated.

Currently Supported:

* OS X PowerPC 10.4 - 10.5

The IRIX programs branch is currently frozen. The applications are stable and work well on our SGI hardware, but they are not being updated.

Currently Supported:

Most of the software titles installed in the SBGrid software collection have several versions available. We try to provide at least three versions of each software package, although very old or very new applications may have fewer versions.

To override the default version of a software title, you need to create an override file. The shell configuration scripts will read this file and override the default version.

The override file is named .sbgrid.conf and should be placed in your $HOME directory. The syntax for overrides is a simple key=value pair. E.g. it should look like this:

APPLICATION_X is the name of the application followed by an underscore and the shorthand initial for the architecture. The last field on the line is the software version number you want to use. The initials for each software branch are:

When you open a new shell, you will see a message about the overridden version. Note that a site administrator can create sitewide or machine-specific overrides as well.

The example output below shows CCP4 on linux being changed from the default version:

The basic account is a UNIX shell account accessible via SSH. This network account will let you access designated machines in the developer network. Along with the shell account you also get up to 10 GB of data storage, access to high performance compilers, basic development tools like version control systems (svn, git, etc) and shell text editors.

Once you have an account, you can access the developer network by connecting via SSH to:

This machine (internally named sbgrid-dev-architect) is the only external facing host on the network, and it hosts your home directory and acts as the SSH bastion host for the network. From this machine you can SSH to any of the build and test hosts via their hostname in the table below in order to compile software, run tests, etc.

The following are the always-on operating system/hardware combinations. They are generally kept at the latest point release:

We have the latest versions of the Intel, Portland and Absoft (PPC) compilers:

There is a configuration file for sh-compatible shells that will enable the compilers and their environmental settings:

Additionally, there are other operating systems available as virtual machines that can be enabled (OpenSuSE, Ubuntu, Fedora, etc), and some additional hardware that can be made available (Sun SPARC, IRIX MIPS, etc) on request.

Thanks for your interest in participating in the SBGrid Developer Network.

In order to be eligible for an account, you must have software in the SBGrid software suite or be planning to make your software available through SBGrid. This requirement limits accounts to developers of scientific software used in structural biology and related disciplines.

That's the only requirement for new accounts. In return for access to these resources, you must agree to not abuse the resources for:

And you agree to take reasonable precautions to maintain the security of your password and account by not sharing this information with other people.

On our end, we will:

We reserve the right to close accounts at any time for any reason.

Packages for RHEL 6, and 7 and compatible machines:

Nvidia 3D stereo typically requires disabling the Composite extension in X.org. Unfortunately, this extension is required to run Gnome 3 and the gdm login mangager supplied as the default desktop in CentOS and many other linux distributions.

The MATE Desktop Environment is the continuation of GNOME 2 which is the default desktop in CentOS 5 and 6.

To change to MATE on CentOS7 systems, first, install the Extra Packages for Enterprise Linux (EPEL) repo:

Then install the nvidia drivers from epel

You may find you need these packages as well

Next, install lightdm which doesn't require the composite extension.

From there we do a couple of groupinstalls

You may have these rpms installed already, but just for good measure

And then this will reload you changes, similar to changing runlevels with sysinitV

Make sure to select MATE from the drop menu as your graphical before you login.