Updates

Disclaimer:  On RHEL/CENTOS needed packages might be missing.

Ubuntu

The directions below cover installing FreeFem++ on Ubuntu machines.

http://www.freefem.org/ff++/linux.php

RHEL/CENTOS

For RHEL/CENTOS, the following packages are needed:

SuperLU-devel openmpi-devel mesa-libGL-devel freeglut-devel mesa-libGLU-devel,gsl-devel m4 bison patch cmake octave-devel libpng-devel libXt-devel freeglut-devel

OpenMPI module needs to be loaded before configure and compile.

module load mpi/openmpi-x86_64

Enable MPI when configure is run.

./configure –enable-download –with-mpi=mpic++

Missing packages at this point will have to be downloaded.

download/getall

To verify everything after make, use make check.  The output should be examined closely.

Below are the packages needed for Pandas, Numpy and matplotlib in Fedora, and presumably RHEL/CENTOS.

python3-matplotlib
python3-numpy
python3-pandas

In  Fedora 23, Libvirt is the default vagrant provider. When running vagrant, this can give the “The provider ‘libvirt’ could not be found” error. Below fixes the issue.

$ echo “export VAGRANT_DEFAULT_PROVIDER=virtualbox” >> ~/.bashrc
$ source ~/.bashrc

GitLab is now up and running within the department, initially for tech use only. It will be expanded out to the rest of the department later.

Importing Existing Bare repos

To import existing bare repos into GITLAB under a GROUP called TESTGROUP, transfer the files over to the server under the following directory:

Verify that the git user owns the files so that gitlab rake commands will work. Next run the following command to import the repos.

If successful, the repos will now appear in the TESTGROUP in Gitlab.

Backup

Gitlab provides backup functionality by creating a tar file that can be copied elsewhere.

The backup file is created in a directory listed in the gitlab.yml file. The file on the current install is located below.

To run the backup use the following gitlab-rake command.

Cisco AnyConnect works well with Fedora 22, once you install pangox-compat.   For Fedora 22, you have to use DNF, command is below.

dnf install pangox-compat

The AMD Catalyst driver is not supported for RHEL 7 and the FirePro V7800.

The Catalyst Linux drivers for Linux recommend building the RPM for CENTOS 7. Building the RPM succeeds along with installing the RPM. The driver will fail once the machine is restarted.

Running the Catalyst Linux drivers directly to do the install will fail almost immediately. Notification is given that the driver is not supported for this operating system.

SSM is the new storage management tool in RHEL 7. It does not have full support for MD currently. RAID1 via LVM is being used currently within the department.

Link below points to the RHEL 7 documentation.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-ssm.html

Driver updates have been completed on local hardware with Quadro Video Cards and Telsas.

NVIDIAs RPM Repo is used for the Tesla install on the RHEL 6 machines. Directions are available from the NVIDIA site below.

http://docs.nvidia.com/cuda/cuda-getting-started-guide-for-linux/index.html#axzz3bogL0IXa

Unfortunately, the above link does not provide a method of installing the Quadro Video driver from RPM.

The link below gives an overview, but unfortunatly refers to an an older driver, and does not use the RPM Repo from NVIDIA.

https://access.redhat.com/solutions/64300

The driver was downloaded from the NVIDIA page, and the install for the Quadro card done manually.

http://www.nvidia.com/Download/driverResults.aspx/80145

Zabbix is now the default monitoring tool for the department’s servers. Users using compute servers can request access to monitor machines resources via Zabbix. Access is recommended for all users of the research machines with large jobs.

The Ganglia and Nagios tools are being phased out now. The License server monitoring tool phase out will occur over the summer.

Yesterday the student sysadmin complained they were getting randomly kicked out of a server. Investigation lead to discovery of an older VM started on another server with the same MAC address. Two machines running with the same IP address was the root of our disconnect issues. Implementing a process where archived VMs have thier MAC addresses changed or removed.