IDL 8.8 and older being retired at SSL

[jameswilburlewis]

IDL versions prior to and including IDL 8.8 are considered at "end of life" and no longer supported by NV5. Accordingly, by campus policy, SSL will no longer be supporting those versions, effective May 1.

That could mean that the labwide installations will be removed.

We recently migrated many of our SOC processes (cron jobs, ksh scripts) from IDL 8.5.1 to IDL 9. We need to check for any stragglers that haven't been updated yet. The tmtools distribution, used to process telemetry, ephemeris files, eclipses, etc. is still on IDL 8.5.1 and will need to be updated.

Edit: It looks like only a few ksh scripts were updated, so there are plenty of references to old IDL versions that need to be fixed.

[jameswilburlewis]

We have some prep work to do before upgrading our cron jobs and other processing scripts to IDL 9.2.

Ophion is missing some shared libraries:

$ idl
/disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/idl: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/libidl.so)
/disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/idl: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/libidl.so)
/disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/idl: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/libalan.so)
/disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/idl: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /disks/apollo/export/idl_9.2/idl92/bin/bin.linux.x86_64/libalan.so)
$ alias idl
idl=/disks/apollo/export/idl_9.2/idl/bin/idl

ambrosia, python2, thailo, and gaia2 are still on Centos 7, which doesn't support IDL 8.9 or later:

gaia2-~ [41] source /usr/local/setup/setup_idl8.9
IDL 8.9 is not supported on this platform [ CentOS 7, RHEL 7 ] - exit
gaia2-~ [42] 

See related task: #64. We'll have to wrap that one up before we can switch to IDL 9.2.

[nickssl]

Are all of them physical servers or some of them are VMs?

[jameswilburlewis]

thailo is a physical server....I think ambrosia, python2, and gaia2 are all VMs.

[nickssl]

Do we need all these VM servers? Perhaps it is time to retire python2 and gaia2? We now have ophion and talos (in addition to cronus, thailo, ambrosia).

[jameswilburlewis]

Yeah, this does seem like a good time to consolidate! Anything that runs on python2 or gaia2 probably doesn't need a lot of resources, so I don't think cronus or talos will impacted by moving some cron jobs over.

Nick, if you can start moving gaia2 jobs over to talos, I'll start migrating the python2 jobs to cronus. (But let's leave the cronwatch jobs in place on python2 and gaia2....we'll disable those last, once we're sure everything works in the Red Hat environment.)

[DCarSunDr]

Just a thought, but apparently some GMAG downloads in the past required the generation of SSH key pairs to authorize the download of data, like gaia2 had one for the AARI group when we were still retrieving those data. I don't know if it would affect anything current, but is there anything we'd need to do to prevent errors, say if talos was attempting to access the ssh key that gaia2 was using?

[jameswilburlewis]

@DCarSunDr The SSH keys for things like rsync access aren't tied to the machines originating the connections, and should work from anywhere. But there is a caveat: if a data provider has firewall rules to allow access only from specific IP addresses, moving a cron job from one machine to another could result in failed connections or permission problems. I think we usually try to get them to whitelist our entire network, instead of just specific hosts, for exactly this scenario. It's something we should definitely keep an eye on, though!