Checkups will increase chance of good service in case we need crisis help. To-do's are not time-critical but doing them gets Brightworks/ Singlebrook additional experience in our system when it's working.
See also (mostly restricted access)
Highlights
Every 6 months, Brightworks (with Singlebrook) to spend 1-3 hours in our systems to do a checkup. This will accomplish:
- Confirming ability to connect and that test and production systems are interacting as expected.
- Explicitly checkup on certain things (list them!)
- And since already spending time there, determine if there is one, small "to do" which can be accomplished mostly on the margin..
1) Verify access to things by Brightworks AND Singlebrook.
- Both for test and production systems, and that all are interacting as expected.
2) Check up on:
- Backups: Check on them and think about them to ensure they meet needs.
- Review corpus of retained versions, and clean up as appropriate.
- Restore from backup: How often to test this? And how test this?
- Updates: Review software versions. Are any versions getting to represent a liability?
- Catch any updates ChemIT should have done (OS/ Apache level).
- Logs: What logs to activate and monitor? Any errors?
- Passords: Rotate passwords periodically (routine TBD)
- Other?
3) Potentially knock out small to-do items from CU priority list. Since already spending time in the systems, determine if there is a small "to do" which can be accomplished mostly on the margin. Take into account existing "stories" Singlebrook has (link to our protected page with a link to their PivitalTracker page for us) and from the list below:
To do ideas
| Task | Notes |
|---|---|
| (Addressed already: The Windows server seems big, coming up to almost 80GB exported.) | 10/25/16: Michael addressed this issue. He writes, "I have already compacted your WinQBDev down to 56GB and I will do the same thing to the WinQBProd when Alan closes at 4:30pm tonight. 15 minutes wait and a simple command." 10/24/16: Michael noticed this. What OS services can be removed? What logs or other accumulated data is large and not of value? What can be done to compress at the container level, especially once items within OS have been deleted? We want to avoid unnecessary large files in our VMs since it makes storing, copying, exporting, and backing up our VMs that much more difficult and time-consuming. |
Within the Linux OS, there is a very large log file, over 16GB as of 10/2016):
| 10/24/16: Lulu noticed this. She notes that this file appears to be increasing by about 3GB a year. Current size: 16,264,966,124. Seems that if only recording textual info, there should not be a persistent file growing this fast. If needed for debugging, delete older data so file never grows beyond a certain size? We want to avoid unnecessary large files in our VMs since it makes storing, copying, exporting, and backing up our VMs that much more difficult and time-consuming. |
| On Web server, the Admin web interface takes a long time to render, and state's "Error" during operation on page. Can take tens-of seconds to single minutes. It used to be fast. | 10/24/16: Oliver noticed this. This long delay is true of the initial page, which does not have any records. And it's true for any query of records. During that time, says "error", which eventually goes away. Could it be the amount of data in the logs (which logs?) is getting too large? Seems that if only recording textual info, should not be taking so long to process for the page. |
In end-user web kiosk interface, remove confirmation dialog when user has clicked "Logout". | 11/25/2015, per Josh, to Oliver. Approved by David Neish, 11/30/15. N.B. Josh confirmed that the non-NetID option not being visible on the 2 monitors in the stockroom is NOT a problem. (Shows fine on monitor outside stockroom.) |
| Prevent unicode entries by users of the web kiosks. | 10/5/16: Patch applied. Confirmed fixed. ================= 10/23/15: QB webconnect (3rd party; won't likely change) rejects any transactions with unicode characters such as an "ñ". Failed transaction keeps trying to succeed and thus get continually rejected forever. And that's a sad state for anyone, even a lowly transaction. Results in a loss of revenue, but has only happened once so far. Proposed solution: Convert (via library look-up) or strip out (if not found in library) all unicode characters within the the web app before transaction is sent to QuickBooks. Example: Oct 3, 2014, 3:22pm, $31.99: ñ in Abruña http://www.spanishdict.com/answers/100808/how-to-type-spanish-letters-and-accents Whatever is done, correct the above offending entry so it can go through. (Don't simply remove it!) Presumably correct it by hand, simply replacing the "ñ" with an "n". |
| Determine how and why email to GORGES being sent by the system. | 10/2015 (exact date?) Only detected because CU email was temporarily being blocked by GORGES. Otherwise function is not noticable by Chemistry. Next step, if approved: Singlebrook: 1 "story" (1-3 hours) to find and characterize purpose and change options. With that info in hand, then decide if it's worth paying to make any changes. |