From the perspective of Chemistry IT, here is NMR Scheduler's background story, along with contextual and technical information.

Contextual and technical information, as far as Oliver understands it

  • The service runs on an Apache web server running on a Linux server, and depends on files and Perl scripts.
    • Q: What are the current versions of the software, and will any of them start to lag?
  • The Linux server is now hosted within Amazon Web Services (AWS), via Cornell's contract.
    • This incurs a monthly charge (amount?).
    • Move to AWS was conceived by Oliver, and he lined up free technical resources at CIT for Ivan.
  • The server is managed remotely by Ivan.

N.B. The AWS charges are currently going through CIT. CIT is processing the charge to their account as a favor to Chemistry so we did not have to create an account ourselves with AWS. (This can be changed, if desired.) CIT currently has no other persistent responsibilities or connections to this server.

Historical background, from Chemistry IT's perspective

Chemistry IT has served as trusted consultants to NMR regarding this server, including helping NMR get it migrated to (Amazon Web Services).

  • Following Chemistry IT's conception of  Amazon Web Services (AWS) as a hosting solution, Chemistry IT provided assistance and encouragement to have Ivan work with CIT staff. For free, CIT provided a generous amount of consulting technical expertise, and implementation work, and debugging to migrate the server from the extremely old hardware in 248 Baker Lab, and old software, into the Amazon Web Services (AWS) infrastructure. CIT ensured correctly configured networking. They also de-bugged the software to ensure it would run correctly on more contemporary software (Linux OS, Apache, and Perl). Migration occurred Tuesday, Oct. 11, 2016, from about 8:45 am to 10-ish.
  • Ivan signed off on migration's success on (date?).
    • Q: Was the last problem detected by NMR on 12/19/16? (With CIT's help, hopefully that was subsequently resolved to completion.) That incident inspired this write-up since Chemistry IT was contacted by NMR staff seeking assistance and we could not help. That's break/fix process is not good for NMR nor Chemistry IT.

Chemistry IT had hosted the hardware in 248 Baker Lab for many years, from before Oliver's arrival.

  • The server had been in B-71 ST Olin before being moved into 248 Baker Lab.
  • Shortly after Oliver's arrival in 2012, Oliver notified Ivan of our group's reluctance to continue hosting the server since we were concerned we would be inadvertently drawn into dealing with a preventable crisis. The risk of the crisis was high since the service was critical to NMR's service delivery and the server's hardware was so very old, as was the software it depended on.
    • When the server was finally migrated off the hardware (Oct. 2016, to AWS), that hardware was about 13 years old (or even older? From ~2000?).
    • Also, as a public-facing web server, we judged that it was unacceptably neglected in terms of best practices as well as practices defined by University policy and expectations. For example, it was not being patched or updated regularly or timely, if at all, against security vulnerabilities.
      • It had been running an OS version from about October 2005 (RHEL 4.2) (Is this correct OS and date?)).
  • Early in Oliver's tenure, Ivan hoped to re-write the scheduler. Those plans fell through over the following 4 years.
    • The continued neglect of the server, and its increased potential for a crisis, kept on growing as the years passed.
  • No labels