Base Roll
In specific configurations, when you run "rocks sync users", you could see the error message:
411-alert: error while loading shared libraries: librocks.so: cannot open shared object file: No such file or directory
This occurs when 'ldconfig' is not run during the post installation. The fix is to ensure ldconfig is run at the end of an installation for all nodes.
Fixes to the Rocks Command Line and 411-master program to fully support channel bonding on the frontend.
When only one alias was specified for a host (with the command: rocks add host alias), the entry in /var/named/private.domain would have the format similar to compute-1-0 CNAME ('c1-0',).
The fix to the Rocks Command Line now properly outputs compute-1-0 CNAME c1-0.
Clients were unable to use the Rocks Command Line. This was because a file in /etc/ld.so.conf.d was not installed on the clients that allowed mysql client code to find its libraries.
Clients can now run Rocks Command Line commands.
The ability to build a "login appliance" was only available when the SGE Roll was supplied.
The login appliance configuration logic has been moved into the Base Roll, so now one can build login appliances on any Rocks clusters.
Memory leak fixed for gmond.
Properly report disk partitions into the database for software RAID file systems.
Prior to this fix, software RAID file systems on client nodes would be reformatted on subsequent installations.
Increase installation speeds for clients with software RAID file systems.
Prior to this fix, if one of the partitions is a software RAID and if the raid is in a "dirty" state, mdadm will try to 'resync' the disks to ensure all the data is protected. On a running system, this is a great thing to do. On an installing system, it slows the install down considerably.
We didn't find a way to disable the 'resync' action for mdadm, but we can extremely throttle back the top rebuild speed by executing:
echo 1 > /proc/sys/dev/raid/speed_limit_min echo 2 > /proc/sys/dev/raid/speed_limit_max |
Kernel Roll
There was a code in rocks-tracker that wasn't properly reconstructing the 'peers' circular list when that list was expanded. This could cause several MD5 checksum errors on installing nodes because an installing node would ask for a peer and the tracker would send stale peer data to the installing node.
In the case where one had a 64-bit frontend and 32-bit compute nodes, the messages exchanged between the tracker-server and the tracker-clients on installing nodes would be misaligned and installing nodes were incapable of finding (and thus, incapaable of downloading) their packages.
All tracker messages are now properly aligned between 32-bit and 64-bit machines.