Agenda - NYULibraries/ILS-Tech GitHub Wiki
Present: Heidi Frank, Daniel Lovins, Nancy Lin, Rachel Pisciotta, Mike Haag, Ryan DiFrancesco, David Perry
Aleph Circulation
- Circulation print daemons - can they be set up to cycle through one computer and run hourly? (Rachel P)
- Rachel asked Jerry S directly about setting up a job for sending hold requests
- Can turn print daemon off altogether, then hold requests get sent to printing queue and can be processed per normal circ notices routines (set up by David)
- David will work with Rachel to build the script and test in Stage
- Need to change the setting in the AlephCom/alephcom.ini and Circulation/print.ini file so that print daemons are turned off automatically with the installation
- Decommissioning Aleph 20. Need to work with Ex Libris. (5 minutes)
- Need to have ExLibris do the official decommissioning of Aleph 20
- Seems the Aleph 20 Oracle instances are still starting up. After v.20 is decommissioned, need to test a restart of Aleph stage to make sure v.22 comes up clean
- Need to be clear with ExLibris whether we just want to deactivate v.20 on the application and the database server, or actually remove the files from disk - for both the Aleph configuration and the oracle data files
- ACTION: Nancy will write up inquiry about the usual process ExLibris takes to deactivate the older version
- z39.50 server - Need usage analysis and review large log files and set up nightly restarts. gzipping, archiving, deleting using chron? (5 minutes)
- The large log file is likely a result of the EZ Borrow rollout
- ACTION: Nancy will add a nightly job to the joblist to clean out this log file by restarting - Mike mentioned setting up something to monitor log file size and to save older log files to a separate server. Ryan's dept has been looking into a cloud service to store log entries for a 30-day period
- ACTION: Nancy will also work with Rachel to monitor EZ Borrow reports
- Cloning from Aleph Production to Stage Servers (start discussions). (15 minutes)
- Need to do extensive comp of tab directories and analyze other relevant directories of v.22 Stage versus Production
- Set up environmental variables, scripts to config for Stage and Prod environments.
- ACTION: Ryan will send [email protected] the list of files needing changes to environmental variables
- Coordinate gitHub workflow.
- Service Pack 3 - All rep changes have been reviewed and approved. Should we install on Stage server? Need to refresh data from Prod? Wait for consultant? (5 minutes)
- Yes, we want to refresh Stage data with Production data before installing the Service Pack on Stage (David and Ryan would do the refresh)
- Create automated vendor loads from NYU submitted files (not from vendor FTP) - what's the best place to put files? Karms server? (5 minutes)
- KARMS staff will copy vendor files (using naming conventions) into a shared folder, then David's automated script will pull them onto Calista (?) and load to Aleph
- ACTION: Nancy will send Midwest script and vendor files to David to get the automation set up
- Copying files to/from alephe/scratch. Bill Jones often runs services requiring upload/download to alephe/scratch but Task Manager does not allow for access to alephe/scratch. Solutions? (5 minutes)
- ACTION: Nancy will create script to monitor alephe/scratch and copy any WJ files over to nyu01/scratch (or somewhere he can access them)
- Consultant work and Open Aleph Admin search (10 minutes)
- Meeting / Interview is on Wednesday, 10/22/14
- Open issues/discussion? (10 minutes)
- Setting up automated monitoring and testing of systems - e.g., getting notices if the number of records loaded to Primo is different from those added/updated in Aleph, etc. (Mike H)
- We could maybe leverage the weekly OCLC reports which is a record of any Aleph record that has been touched, in order to monitor Primo publishing
- Keep u-tree tables in sync, so periodic refreshes would be good idea
- Status of new Aleph Stage (Aleph Stage Beta)
- Ready as of today, licensing received yesterday;
- Taking clone (at SAN level) of Aleph Beta seemed to work, data current as of Dec. 20th. Old Aleh stage was refreshed early october. We have list form ExLib of ~ 40 config-related files that need to change.
- First test: Can we refresh from current production environment? Then full republish via shared mount with Primo Dev.
- What about Allen's question about 966 testing? Lives in current Aleph Stage. So hold off till Aleph Stage full refresh and then redo procedure for creating 966s in new environment.
- ACTION: Once David's here, push data from Prod to new Stage
- ACTION: DONE. Ryan to send out email about next steps on Stage Beta
- ACTION: Mike Haag to share plan for Git-based table management in new Aleph.
- ACTION: DONE. Daniel will review Ryan's attachments and reach out to primo.admin and aleph.admin on missing values
- ACTION: DONE. Daniel will revise sketch project plan to update dates and make more modular so that ExLibris piece can be swapped in and out as they update their own plans. Then distribute to migration project group.
- ACTION: DONE. Ryan will create email alias for combined P4 and A22 project teams.
- ACTION: DONE. Ryan will pull over u-tree from production into Stage Beta. Circ Tech is OK with abandoning changes in Old Aleph Stage.
- GitHub repo for table change management? Scot might be able to work with Mike on this. Beware hidden svn files cloned from Aleph Prod will be pointing to Prod SVN repo. Corey suggests we might want to use git to pull u-tree into new branch. Beware of using same Oracle instance to support two different git branches (e.g., dev and dev-0), since each will write changes to Oracle that may contradict one-another. 3 separate Aleph instances (stage, dev, prod) is best approach. But not currently supported at NYU Cabinet level.
- Beware complications using Git to generate u-tree.
- Updates on planning ahead to Aleph 22 and Primo 4. ExL tickets opened with target dates June 6 and July 12 respectively. See Cases 00055354 [1] and 00055348 [2]
- Sizing form submitted for both A22 and P4?
- "Request for Aleph Upgrade by Ex Libris" form submitted?
- Migration alias to include all new project members? Cf. [email protected]
- Aleph Disk Space issues
-
Service packhotfix to Aleph post-upgrade?
[2] https://exlibrisgroup--c.na4.visual.force.com/apex/VF_Case_WithoutJira?id=5006000000WsSQsAAN
- Review final steps of Aleph hardware migration. Cf. upgrade project plan and Ex Libris Case 00033734
- Review what's being tested. Cf. acceptance testing chart
- Aleph Stage seems to have an Oracle problem. Can we hold off on having a staging environment until David returns?
- Action: Daniel to send group info on when hotfix was applied to Stage.DONE
- Cf. notes from Nov. 15 expanded Primo Admins meeting
- Aleph Stage hardware migration: Oct.-Nov. 2013
- Implemented by Ex Libris; Overseen by Systems
- Database and software migration complete.
- Testing
- Client testing complete (Matthew, Mike Haag, other?)
- Server-side testing underway (including publishing of data into Primo Dev) (Primo Admins)
- Aleph Beta /primo_publishing directory now mounted on primodev3: alephapp1.bobst.nyu.edu:/primo_publishing_alephbeta. This was prerequisite for data publishing test.
- Search items that we know got published (e.g., by searching nyu_aleph* ; or search for key words used in logical base). Ensure interoperablilty links work. Hannan may be able to help with testing if we provide sample assertions ... e.g., can a PhD student request a periodical from off-site?
- Test interoperability with GetIt (Scot can point QA server to AlephBeta?)
- ACTION: David to set PrimoDev table auto-extend to 'on'.
- ACTION: Daniel check with Mike Haag on test of self-check out machines
- ACTION: Daniel to check with Allen Jones on test of RFID functionality and something about 'gates' at TNS.
- ACTION: Daniel ask Mike Haag about about issue of circ messages (?) via a-tree that get 'squashed'
- PDS: Does David need to configure for AlephBeta? Or just make sure able generate flat file?
- Not necessary, per David. Logging in as Aleph should have same results.
- Test bib record loading scripts (Bill Jones)
- ACTION: David will test CGI script for recalls and renews
- ACTION: Barnaby will test privileges guide (via new git branch)
- Aleph Prod hardware migration: January 5-8, 2014 (Beginning of work day Jan. 5 in Israel is Sat. night for us)
- Call scheduled for Wed. Dec. 4 with ExLib Matthew is implementations service manager and engineer will be on the line. Daniel, Ryan, Brooks, Marty, David, maybe Roddy.
- How does ExLib handle changing shifts of engineers
- Roles and responsibilities:
- Move Aleph Prod to new hardware and OS (Ex Libris)
- Communicate with ExLib
- Communicate across NYU departments about downtime (Nadaleen?)
- Coordinate with GNU and consortial partners on downtime; E.g., is Abu Dhabi open on Sundays? Do they have a J-Term? (Marty?)
- Track progress of implementation and testing (Daniel?)
- Coordinate upgrade implementation with regular ongoing processes and other projects like EZ-Borrow
- Coordinating client testing (Mike Haag and Matthew?)
- How to block Aleph client from general staff during testing? Similar to Fiscal Close blocking? Systems will need a list of allowed IP addresses.
- ACTION: Daniel to give list of tester IPs to Ryan and Brooks, to add to documentation
- Sys Admin; Network Admin (Ryan off campus. Brooks covering.)
- DB Admin (David off campus. No-one covering). Make sure we understand whats involved. E.g., system jobs to be stopped in SQL warehouse ... can this be automated?
- Vendor loads will be turned off in advance of upgrade.
- Report problems: contact Client Services?
- Part of message from Nadaleen and Marty
- If Brooks notices trouble, write to aleph.admin, include Daniel's number. If necessary, escalate to Roddy for decision on backing out or other actions.
- Call scheduled for Wed. Dec. 4 with ExLib Matthew is implementations service manager and engineer will be on the line. Daniel, Ryan, Brooks, Marty, David, maybe Roddy.
- Upgrade to Aleph 22: Late spring 2014
- Upgrade to Primo 4: Summer 2014
- Prepare for loss of P3 Dev and Prod environments when P4 is installed
- Prepare for loss of A20 Stage and Prod environments when A22 is installed.
- Question: what does initial Primo 4 implementation mean? Replication of current (P3) functionality, with schedule in place for switching on new features (index browse and generic FRBR displays)
- Factor in time needed to change custom jsps to accommodate changes, even without new features. Alternative, consider allowing more of the native UI. Does it need to look exactly same as p3? Probably not. (Long-term consideration that will effect scheduling in the future: possibility of de-coupling Primo front-end from indexing engine.)
- Add Marty and Nina to Aleph admin alias. Former because of reporting role across GNU and consortium; latter because Aleph-related newly-hired ERMM technologist is in her department.
- Ex Libris per recent support case (no. 00022233) for missing log files. Ping has written: "localhost_access_log* file was mistakenly removed since SP 3.1.4. However it was restored in Primo SP4.1.1". I don't know if we can live without that file till next summer, but that seems to be the suggestion/implication. Ping also suggested that the weird change in aliases may be connected with the JBOSS upgrade and filepath changes, though I don't quite get how that would have happened. [added]
- Corey suggests best path is to escalate with ExL if they don't respond adequately to Ryan's latest request. Another option, though, is to re-enable jboss' access logging ourselves, with reference to http://stackoverflow.com/questions/11531092/jboss-and-tomcat-access-log-parameter-setup http://www.mastertheboss.com/jboss-web-server/how-do-you-configure-jboss-to-enable-http-logging and Primo1 and primo2 file likely stored here: /exlibris/primo/p3_1/ng/primo/home/system/thirdparty/jbossas/server/publish/deploy/jbossweb.sar ... but note issue of whether config stored in Oracle somehow, and "deploying" will rewrite it. "The necessary "valve" exists, but is commented out."
- When there's a SP upgrade in Aleph, table headers may change in working code, meaning files get out of sync with SVN repo. This is already the case in Stage and Prod, and will be exacerbated when there's another SP applied this October. Need to do an full SVN update?
- There's also an issue with daemons re-starting after boot. Bill agreed to add a Util daemon status check to his documentation and let the rest of us know where to look (to find the documentation) for future reference [added]
- Sticky session problem, e.g., with EShelf, when load balancer switches away from graceful error pages, and there's an application that pings the Primo web server so frequently that it doesn't have a chance to time out and refresh. Need documentation on testing and fixing. And who's responsible. (Reported by Scot after Primo 3.1.4 SP upgrade on 8/20/13).
- JS comment on SI 16384-445115: "I see that your job_list does *not* have the following line shown in KB 5737: xx hh:mm:ss N server_monitor -tks WWW I strongly recommend that this be added. Following the pattern of your other entries, it should be the first one: W1 01:30:00 N server_monitor -tks WWW . Then do util e/15/1 to restart the job_daemon."
- Aleph Enhancement Requests due to ELUNA by 7/19 (this Friday)
- JBoss vulnerability and accelerating upgrade of Primo prod to 3.1.4 (Dev is already there).
- Fiscal close
- David to shut off vendor loads on evenings of 6/26 & 8/27
- Bill to turn off PC server evening of 26th.
- Ryan to do the IP-Blocking to only allow Client Connections from Corey's, Nina's, Ayse's & Greg's IPs on the mornings of 6/27 & 8/28 (Greg may need to let AD, Shanghai client users know that they won't have access after a certain hour, since Ryan will start blockage, ca. 11pm night before (6/26). Ryan will send notification email. Greg will send confirmation when his piece is finished. Expecting it to take 1/2 day for TNS and NYSID; 1 full day for NYU.
- Bill to reconfigure the vendor loads (i.e., update budget year in scripts) as soon as possible so they can be re-enabled by David
- Ex Libris switching to Salesforce for issue reporting: "A pilot project began in May that involved a small group of Alma and Primo customers, and we are planning to rollout Salesforce to all customers starting August 2013. Pivotal eService will remain available in read-only status to view cases that were not migrated to Salesforce."
- Taking advantage of the inter-session period this summer to implement the latest SP for Primo prod on the morning of Friday 8/23 with whoever cares to join me. (Daniel)
- Bill may implement the Aleph upgrade that same week, but dependency on Linux Oracle migration issues (see below). (Bill)
- Issues regarding HSL migration phase 2? (Corey)
- Issues regarding Shanghai implementation? (Heidi?)
- Aleph Oracle migration. Ryan cautiously optimistic. At least one file successfully transferred.
- Update on Metalib server hardware upgrade? (Ryan) Still no response after 3 months. In process of building server now so we can hit ground running when we do get a solution. Migrate to Metalib 4.5 from 4.3.
- Automated testing suggestions? (Carolina)
- Schedule service pack upgrades for Aleph and Primo this summer
- Create project plan for developing automated tests in advance of Aleph 22 and Primo 4 upgrades, now pushed back to 2014.
- Still waiting for word from Cabinet on Discovery Systems librarian JD approval (to take on Primo admin responsibilities, among others, in KADD)
- Coordinating Systems maintenance and upgrades in January
- SAN upgrade (list of services affected here). 2 hours of actual upgrade work but stopping and restarting various apps needs full work day.
- ILS-WG and E-Access will need to manage communications about gradual resumption of services as apps come back online after the SAN upgrade
- Primo 3 SPs
- Aleph SP 7 and 8
- Cf. Academic Calendar
- SAN upgrade (list of services affected here). 2 hours of actual upgrade work but stopping and restarting various apps needs full work day.
- Primo server questions
- Prod Back Office warning: "DB/FS/CPU: Not OK"
- Talk to David about monitoring tool
- Question following site visit to Princeton. Cf. list of Primo sites
- Prod Back Office warning: "DB/FS/CPU: Not OK"
-
OCLC Batchload TF Report
- Implications for OCLC record ID capture
- Implications for Aleph authority control processing
- Implications for system throughput capacity (e.g., "Reload all non-Roman-script records that were edited between July 1, 2011, and December 31, 2012.")
- Mysterious happenings in BobCat [1] …
- How is it that a record can be confirmed published and normalized in Primo but not indexed [2] SD Update: this is the same issue as search.do (Follow up on this issue)
- Why are certain Aleph-based URLs not appearing in Primo or GetIt? [3]
- Why is search.do not working in some cases?
- Update on findings of OCLC Batch Load Task Force: given the year-long-plus saga of Aleph’s authority module corrupting MARC record syntax and therefore breaking OCLC batch loads, should NYU consider outsourcing authority control [4]?
- Upgrading Primo 3 SPs first week of January. Should we start planning for Primo 4?
- Update on Application Admins initiative. Is it working OK? Need to fill in more names [5]. Ryan: Need to know who's already included in Admin aliases.
- "Three Conditions on EBSCO display logic"
- HSL Migration update?
- GitHub update?
- KARMS Linux update?
- GitHub as platfom/archive for ILS-Tech agendas?
- MARCit service Activation Req form
- ISAW location labels: How to modify?
- Aleph SP 20.7 and 20.8
[2] Eg.: ISAW Papers. Cf. SI 16384-392600
[3] E.g.: "Innocents abroad : American teachers in the American century" by Jonathan Zimmerman, BSN 003508127, Oxford bibliography of philosophy online
[4] e.g. http://www.bslw.com/authority_control/
[5] http://wiki.library.nyu.edu/display/ILSSC/Application+Administrators