See previous post.
I use lftp in a launchctl script to transfer and delete files from an Axway/Tumbleweed secure server, but after upgrading to macos Sierra, the connection failed (and looped forever retrying) with a brief flash of a “DH GEX group out of range” message.
Searching for the message reveals that it’s an ssh issue (DH is diffie-hellman): Apple apparently changed ssh to use a shorter keys by default in order to encourage use of TLS. At least I think that’s what happened. Could be that the secure server changed its key negotiation requirements the same day I upgraded to Sierra. The explanation of the error message (and solution to the problem) showed up in a Linux server forum.
First I mistakenly tried to rebuild lftp, which I could not do because ./configure died saying it couldn’t find the readline headers even though they were there (brew link –force readline). The second dead end was to try to change the fish:connect-program setting for lftp, but that had no effect. Finally, I scrolled through the lftp man page far enough to realize that the proper configuration setting is sftp:connect-program.
So I created ~/.lftprc and put this line in it:
set sftp:connect-program "ssh -a -x -o KexAlgorithms=diffie-hellman-group14-sha1"
I upgraded my office workstation from El Capitan to Sierra last week after waiting a while to make sure there were no problems with the new version of the operating system: my office workstation is used for some campus-wide services, and I go into panic mode when upgrades break things. So after a decent interval it seemed safe to let the upgrade go forward.
It’s a little embarrassing in hindsight how long it took me to recover from the upgrade, but there were no indications whatsoever what had gone wrong: just a cryptic HTTP 500 error code for part of one of the two virtual hosts on the system. Lots of time looking at mail configuration; PHP include_path, etc. Finally: “pg_connect() not found.” I wasn’t getting my “unable to connect to database” error because … postgres wasn’t available at all. The connection couldn’t fail because the code to make the connection couldn’t even be executed.
I’m not the only one to have the problem, of course, and I finally was able to google the correct problem. The solution was simple, just add these two lines to php.ini:
Since I don’t use the PDO interface to Postgres, I probably need only the second line, but I didn’t do the experiment to make sure.
So now I’m back to the old problem: when Apple updates the OS, the path to pgsql.so will undoubtedly change without documentation (that I know of) to alert me to the new path, just as the demotion of Postgres being included in the PHP installation by default was discontinued without documentation (that I know of).
Anyone buying a new Tesla can get free supercharging and a $1000 credit towards a new Model S or Model X by using this referral code. This code is valid for orders placed between May 19, 2017 and the end of 2017. Tesla updates their referral offers quite regularly. The referral code here seems to work for all of them. As of this update (February 2018), the first person to use my code gets a $500 credit, and the first five people get unlimited free supercharging.
And, yes, I think my Model S is terrific!
Google Forms is terrific for gathering information, but it sucks as a workflow tool. Today I received a Word document that instructed people to fill it out, print it, collect three signatures on the paper copy, scan that, and return it by email. No way to track progress; no record of what’s happening, but partial and unsynchronized records in both paper and email trails.
With Google Forms, we can be sure the entire chain from initiator to final approval is handled by authenticated individuals who are signed into the organization’s Google account. And we can collect form responses in a spreadsheet.
But we can’t populate the form with information from a database that provides, for example, the identities of the people who have to approve or review the user’s request. No drop-down lists generated from a table or no-sql document list somewhere.
And there will have to be code to trigger notifications to alert reviewers that they need to look at / approve a request.
For now it looks like we have to use Google Sheets for our “CMS” and HtmlService to generate the form(s) and GoogleScript code to interact with the users.
I’ve done most of this before for our “Assessment Document Repository.” It’s a bit slow, but at least the capability is there.
My first TODO is to update a Google Sheet when someone clicks a link that says “approve” in an email message.
Yea! DreamHost’s upgrade to WP 4.6 was automatic and uneventful.
Notes mostly to myself. Migrating from a Drupal site because keeping Drupal up to date was a bother. DreamHost will update WordPress automatically. At least the minor ones.