Last week, Check Point released the first major update to the Gaia-introducing R75.40 version. The release of R75.45 mainly brings enhancements and fixes for the new Gaia platform:
R75.45 Release Notes
R75.45 Resolved Issues
R75.45 Known Limitations
R75.45 includes this R75.40 hotfix.
Among the new features provided, support for 6in4 tunneling, policy-based routing appear to be the most intriguing (at least to me).
The long list of fixes addresses important issues such as long policy install time, kernel memory leaks or IPS not exiting bypass mode again after returning to normal CPU utilization.
Only direct upgrades from R75.40 are supported, no earlier versions.
I haven’t tried this new release yet, but given the list of fixes and potential first prematureness of the still young Gaia platform, I’ll check it out rather sooner than later.
You may not always have the convenient option to install vendor-specific hardware management agents/extension on ESXi hosts or physical servers, for example with appliance-ish OSes like the Check Point SPLAT/Gaia platform (which is just a custom RHEL descendant), or you may run into a server without these tools installed. So how can you still query firmware information on such systems directly from the command line? I will outline a couple of ways here which make it possible to obtain that information.
The example information captured here is from HP Proliant Servers (since G5), but most of it should work in similar ways with other hardware platforms too. Unless noted otherwise, the example commands here should work regardless of whether you have CIM providers or hardware management agents installed or not.
When trying to set the Trusted Management Servers certificate in the HP Systems Management Homepage via pasting the base64 string or getting the certificate directly from the SIM server, I was greeted by one pretty generic error message:
Error: Certificate failed validation and was not imported.
This happened on physical GNU/Linux (RHEL) systems as well as Windows Server 2008 R2 machines .
Is it impossible to properly import a SIM certificate either by pasting the base64 encoded certificate string or by letting the SMH fetch the certificate by itself from the server?
Instead I had to manually copy the .pem certificate file to the server and restart the SMH. On Windows, it goes in C:\hp\hpsmh\certs\ (if you installed the server via SmartStart) and on GNU/Linux in /opt/hp/hpsmh/certs/.
I also noticed that the displayed certificate raw data you can see under Details (https://192.168.1.1:2381/proxy/smhui/getcertdata?certname_goes_here.pem) after having imported one actually cuts off a the last 2 or so lines of the base64 string, so don’t rely on copying this to create a file on your servers.
An ESXi host has a number of important logfiles located in /var/log (or /scratch/log) for each of it’s components. Reviewing those logs the standard way can be quite cumbersome: Some logs can be viewed through the DCUI (if you like to torture yourself) or you have to enable SSH each time on each host to browse through the logs. Compared to that, having your host-local logs in one central place can be very useful for things like audits or troubleshooting. VMware also noticed that back in vSphere 4 an included the vilogger component directly into the vMA. Unfortunately vilogger was removed with vSphere5 for reasons completely beyond me.
Instead VMware included the ESXi Syslog collector for vCenter, but it’s quite basic and not really the greatest way to centralize your hosts logs, especially in larger environments. I’m also missing my bash and *nix tools to properly filter and navigate through the volume of information contained in the logs.
So as the vMA 5.x Linux OS already comes with the default syslog-ng daemon, why not take advantage of that and let your hosts log there? The steps outlined here were done with the vMA 5.0 but should work without a hitch on the 5.1 release too.