A-Team Systems is proud to announce the availability of Release 3 of it’s FreeBSD Cluster system which is now ready on our imaging servers for client deployment. We have also upgraded all client Release 2 clusters to take advantage of the new features which include:

ATPC / A-Team Physical Console

After much testing we’ve deployed our ATPC (A-Team Physical Console) application standard on all clusters. This tool runs on the console (on VTTY #1) and presents critical information in an easy to understand format. It is designed to give data center staff and remote hands at-a-glance details of a server and to aid in the following situations:

  • Avoiding non-graceful reboots or shutdowns: This is common when the technician does not have UNIX specific experience and opts to just ‘hard power’ or ‘reset’ a server or Virtual Machine. ATPC has a clearly displayed menu allowing the technician to gracefully reboot or power down the server. For security this can be disabled however in most situations if the physical environment cannot be trusted there are easier ways to attack it.
  • Performing maintenance on the wrong server. The server name and owner are clearly shown at the top of the display to avoid confusion between servers at the data center.
  • Not knowing who to contact: A-Team’s support information and client contact details are displayed at the top of the screen in the event that someone needs to be contacted about a server but the technician doesn’t know who.
  • Communicating during maintenance: Data centers are isolated and noisy environments, making phone calls almost impossible. ATPC includes the ability for A-Team to open a remote chat window with the technician on the console so we can coordinate and chat while maintenance is being performed on the server (or an adjacent server).

FreeBSD 9.1-RELEASE Patch Level 10

This FreeBSD 9.1 patch level includes numerous improvements and fixes, but the main significance is that it addresses the security concerns raised about trusting hardware random number generation in the wake of the NSA scandal as exposed by Edward Snowden. Specifically that it is highly likely that the NSA paid hardware manufacturers to include weaknesses in their random number generators. These weaknesses could in turn drastically reduce the security of the resulting cryptography when used (ie; HTTPS, SSL, SSH, etc).

It is worth noting that for most of FreeBSD’s history the Yarrow tool has been used to add further entropy to random sources and will do so for these hardware generators now by default.

LDAP Based Sudo Permissions

Sudo’s permissions and command mappings have been moved away from the local ‘sudoers’ files and into LDAP. This allows easy central management of Sudo permissions via the LDAP GUI without the need to run visudo(8) manually on each server.

LDAP Based SSH Public Keys

The OpenSSH LPK schema has been deployed to support ‘sshPublicKey’ attributes which allows users to centrally upload their SSH public key(s) via the user portal and have them automatically propagate to all servers.

This also prompted us to switch from FreeBSD’s built in version of OpenSSH portable to the newer one in the ports tree that supports the AuthorizedKeysCommand directive. This lets OpenSSH call an external script which we’ve developed to retrieve a user’s public SSH keys from LDAP. Traditional authorized_key files are still honored as well, but this is much more convenient and centrally manageable both for administrators and users.

MySQL Replication Monitoring

We’ve added built in monitoring support to ensure that both MySQL GTID and legacy MySQL replication pairs are correctly replicating between each other. For GTID (multi-master) setups this means that both masters are cross replicating to each other. For legacy (master-slave) setups this means that the slave is connected and processing updates from the master.