I was recently researching the latest guidance on securing OpenSSH and came across a web page on a popular site espousing that the easiest way to protect OpenSSH is to define a login banner. While a login banner is useful, especially in a enterprise setting, it’s useless for securing SSH. So, here is my recipe for securing OpenSSH. While testing these, ALWAYS keep a connection open. It’s very easy to break something and if you don’t already have an open connection, you will have successfully locked yourself out.
Last year I budgeted for 3 P740C model’s to replace 3 P6 550 models that were getting long in the tooth. Because of the long lead time in our budget process and the continued downward pressure from IBM on their pricing, I was able to purchase 4 P7+ 740D models. That is a big win for us.
After implementing new 7042-CR7 model HMCs (which I recommend everyone upgrade to) and powering on our first box, I noticed that the latest HMC code reports the server has a Power7 and not a Power7+. The Power7 chip has been out for nearly a year, and the HMC has been through several updates since then, so why does it not show Power7+ the way it did for Power6+? Here’s what the screen looks like:
I recently put up a test Splunk server to act as a central syslog repository, one of the issues in our security audits. There are some “open” projects to do this, but Splunk has a lot of features and is “pretty” compared to some of the open alternatives. Getting data from our Linux hosts was a snap, but data from our AIX hosts has a few minor annoyances. Fortunately, we were able to overcome them.
As usual, I’m late to the party. I was at the Power Systems Technical University in San Antonio several years ago (an awesome venue), and there was a session on the new AIXPert feature of AIX 6.1 (later back-ported to 5.3). At the time I though it was clunky and wasn’t too excited about it.
CODBL0004W Essential periodic calculations did not occur when expected. The last day processed is Apr 25, 2011 while it should be Apr 29, 2011.
Direct CREATETAB authority = YES Direct BINDADD authority = YES Direct CONNECT authority = YES
I’ve recently found some of our systems have corrupt smit screens when looking at printer queue characteristics. When looking at any options under “smit chpq” for some of the printers, we got:
1800-109 There are currently no additional SMIT screen entries available for this item. This item may require installation of additional software before it can be accessed.
The message clearly points to missing filesets. But printers.rte, bos.rte.printers, and the printer device filesets ( like printers.hplj-4si.rte) were all installed and up to date. The problem is that the ODM stanzas for the printers aren’t correct. The queue subsystem looks a files under /var/spool/lpd/pio/@local to do the printing, but smit looks in the ODM.
Here’s a simple thing that I ran across. I have a vendor that recommended that I set the Maximum memory in my LPARs to the system maximum. That way you never have to reboot to increase the maximum memory in that LPAR. I found out later that setting your LPARs memory to the system maximum makes the hypervisor allocate more memory for overhead.
In a recent post, Low-impact database clone with splitvg, Anthony English used the splitvg command to clone a database. I hadn’t thought of the splitvg command since playing with it when it was first announced in the Differences Guide for AIX 5.2 (?). As luck I was building a new LPAR that is a copy of an already existing LPAR. I don’t strictly NEED the files in the filesystems copied to the new LPAR, but I do need the filesystems. But getting the files might save the application analysts some time. So, I decided to break out the old splitvg command.
After upgrading to AIX 6.1, or a fresh install, you need to add a few filesets:
idsldap.cltbase61.rte idsldap.cltbase61.adt idsldap.cltbase61.rte idsldap.clt32bit61.rte idsldap.clt32bit61.rte
I recently had a AIX box send a 1.5 GB Email to our MS Exchange Email system, which brought Exchange to a screeching halt. Our Exchange admin was understandably unimpressed. So after a few seconds of research, I found sendmail has a setting to limit the maximum message size. Put this in your sendmail.cf file and restart sendmail:
That's in bytes, so that should be 50MB.