Copy That: A Quick Cautionary Tale About Data Transfers
Rob McNelly also shares some IBM Support docs and a scary story of a cyberattack that didn't happen
We had a fun exercise recently. A customer sent a large amount of data from one data center to another. It was enough data that moving it via the network wasn’t a realistic option. Instead, they copied the data to a USB drive and shipped it overnight to the target data center.
I was asked how to use the VIO server to let the target partition read the data from the USB drive.
This is a pretty good write up of what we can do to use USB drives.
My first question was, is the drive supported on AIX? Was it formatted correctly?
IBM AIX documentation notes that AIX supports numerous IBM and third-party USB devices, everything from USB mass storage and flash and disk drives down to a keyboard and mouse. Of course there are exceptions, since AIX may not recognize some third-party USB devices.
We ran cfgmgr, and the USB mass storage device appeared on the VIO server. We were able to do a mkvdev -vdev usbms0 -vadapter vhost5, and we could see it in lsmap -all output, but the client LPAR could not see it.
At this point, the guy that actually copied the data chimed in, helpfully acknowledging that rather than copy the data directly from the Power Systems machine to the USB drive in the source data center, he’d copied it over the network from the LPAR to the USB drive connected to his laptop. The USB drive is formatted NTFS, so when the technician in the data center unplugged it from the Power system and plugged it into his laptop, he could see it and then copy it to the target LPAR over the LAN. This method works great, it’s faster than using the WAN, but if you’re in a similar situation just make sure you notify the folks who need to know how you formatted the drive/copied the data.
Catastrophe Averted
How often do you think about the security of open-source packages that you install on your production servers? Do you typically examine the source code yourself before you install packages? I doubt it. With the widespread adoption of open-source tools that are easily installed on AIX using RPM, YUM and dnf, I assume many of you are happily installing packages, and making your lives easier in the process.
But here’s a reminder that, from a security standpoint, nothing is foolproof:
“…Microsoft software developer Andres Freund was trying to optimize the performance of his computer when he noticed that one program was using an unexpected amount of processing power. Freund dove in to troubleshoot and “got suspicious.”
“Eventually, Freund found the source of the problem, which he subsequently posted to a security mailing list: He had discovered a backdoor in XZ Utils, a data compression utility used by a wide array of various Linux-based computer applications — a constellation of open-source software that, while often not consumer-facing, undergirds key computing and internet functions like secure communications between machines…”
As noted in the piece, a similar exposure nearly led to a major cyberattack in April, “a catastrophe that didn’t happen.”
The article closes with this quote: “While the possibility of socially engineering backdoors in critical software seems like an indictment of open-source projects, it’s not exclusive to open source and could happen anywhere. In fact, the ability for the engineer to discover this backdoor before it was shipped was only possible due to the open nature of the project.”
At the very least, I think it’s essential that we continue to proactively patch our systems and remove packages and anything else that we don’t need. It’s also important to read vendor security bulletins and take action as directed. But definitely give this a read. It’s quite the story.
IBM Support Docs
* This IBM Support doc covers TCP tuning recommendations that can improve the performance of WAN connections between AIX virtual machines.
“The following basic TCP tunings are recommended on AIX VM:
tcp_sendspace=1048576 tcp_recvspace=1048576The tcp_sendspace and tcp_recvspace need to be set to a higher value than LAN setup to keep long pipe populated due to high RTT. These options can be set per interface by using chdev command or system wide using no command or by application by using setsockopt() subroutine.
sb_max=2097152sb_max sets an upper limit for tcp_sendspace and tcp_recvspace. It is generally 2 or 4 times of tcp_sendspace and tcp_recvspace. This option can be set system-wide only.
Use the following command to set system-wide:
no -p -o sb_max=2097152There’s much more, including setting rfc1323, mtu_bypass=on, etc., so be sure to read the rest.
* This doc explains why the rpm command failed during a migration to AIX 7.3 TL2:
“Cause: The rpm installer is an open-source tool. IBM only packages it for AIX. The conversions from Berkely database to sqlite were forced by the RPM community.
“Some packages that were old, or from other builds, have had issues in conversion. AIX cannot control this. The conversions sometimes fail because of how the packages were built. Sometimes, the old packages have to get rebuilt first so the format can get converted to 4.18 sqlite. The “Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend” errors have been common across platforms. Sometimes the failure is due to a particular service that needed to be restarted, or a library that was replaced, or just general compatibility issues due to older packages.”
Read on to learn the procedure for backing up the directories, rebuilding the database and converting to sqlite. There’s also support information at the end.