SFTP and the points where transfers may fail
August 31, 2018
Earlier in August a 3000 manager who relies on the Stromasys virtualized 3000 was searching for failures. Well, he was asking about the causes for failures. He wanted to know more about failures of SFTP transfers on his MPE/iX system. (We'd call it a 3000 but there's no more HP iron there at Ray Legault's shop). He gave the rundown on the problems with MPE/iX.
We send about 40 files each day most of these in the early morning. Sometimes we would have zero to fives connection failures each morning. I noticed that these failures seem to occur when two SFTP jobs ran at the same minute. I then added a "JOBQ=FINLOG" to the job card of every SFTP job I had and set the job limit to 1. This was two weeks ago and we have not had a failure yet.
Brian Edminster, who still hosts open source software for MPE/iX, checked in to offer an answer to why those SFTP jobs were failing.
I'd be willing to bet that Ray's issue at Boeing with SFTP connect failures is due to the Entropy Generator running dry. Connections take lots of entropy data — and the one that comes 'out of the box' with the SFTP client doesn't generate very much without some modifications.
If you need to make more than one connection a minute (job limit 1), this modification will likely become necessary. Let me know if you'd like some pointers on how to do this. It will require some revisions to the SFTP software. The Entropy Gathering Daemon which Mark Klein's SFTP port uses is written in Perl. It is not terribly difficult to modify to include new data sources to "stir into the pool" that is drawn from by the SFTP client.
Edminster's MPE-Opensource.org website has an SFTP quickstart bundle of all packages required to install OpenSSH on MPE/iX including SFTP, scp, and keygen.