Re: [OPEN-ILS-GENERAL] Testing Staff client on new staging server, can't login - websockets error
Oh wow, sometimes you just need a second set of eyes to catch something. Fixed the typos and testing the staff client is functioning as it should. Thank you! Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jeff Davis Sent: Wednesday, May 01, 2019 12:01 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Testing Staff client on new staging server, can't login - websockets error Hi Jesse, It looks like your browser is trying to establish a websocket connection on port 433, not 443. Maybe there is a typo somewhere, perhaps in opensrf_ws.js or opensrf_ws_shared.js? Jeff On 2019-05-01 11:31 a.m., Jesse McCarty wrote: > HI All, > > I am preparing to migrate our Evergreen install (3.2.5) to a new Server > (Ubuntu 16.04) and have everything up and running but am having trouble > with the websockets to test the web staff client before moving the > current database over. The new server is configured like the production > server with websocketsd and nginx to proxy everything and has the > database imported from the production server's backup. I can search > catalog, login to account, just cannot get into the staff client. I get > the following error in the web console using Firefox: > > As another test, I created a test server (complete clone of the > production server, with configuration files and IP changes for internal > testing) and was able to run the staff client just fine. I can see that > the websocket is running on the new server. Not sure if/what I missed in > setup or not, any help is greatly appreciated. > > Thanks! > > Jesse McCarty > > City of Burlington > > Information Systems Technician >
[OPEN-ILS-GENERAL] Testing Staff client on new staging server, can't login - websockets error
HI All, I am preparing to migrate our Evergreen install (3.2.5) to a new Server (Ubuntu 16.04) and have everything up and running but am having trouble with the websockets to test the web staff client before moving the current database over. The new server is configured like the production server with websocketsd and nginx to proxy everything and has the database imported from the production server's backup. I can search catalog, login to account, just cannot get into the staff client. I get the following error in the web console using Firefox: [cid:image001.png@01D50010.84B37D90] As another test, I created a test server (complete clone of the production server, with configuration files and IP changes for internal testing) and was able to run the staff client just fine. I can see that the websocket is running on the new server. Not sure if/what I missed in setup or not, any help is greatly appreciated. Thanks! Jesse McCarty City of Burlington Information Systems Technician
Re: [OPEN-ILS-GENERAL] Apache install question
As Jason said, there is some name changing to do. When I copy the apache files I have them copied as follows: cp Open-ILS/examples/apache_24/eg_24.conf /etc/apache2/sites-available/eg.conf cp Open-ILS/examples/apache_24/eg_vhost_24.conf /etc/apache2/eg_vhost.conf cp Open-ILS/examples/apache/eg_startup /etc/apache2/ All run as root from within the Evergreen-ILS-3.1.X/ directory. Jesse McCarty City of Burlington Information Systems Technician From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of JonGeorg SageLibrary Sent: Monday, August 20, 2018 12:42 PM To: Evergreen Discussion Group Subject: [OPEN-ILS-GENERAL] Apache install question So on Step 11 of http://docs.evergreen-ils.org/3.1/_upgrade_the_evergreen_code.html - it wants me to copy as root the example eg_start, eg_vhost and eg.conf files to the /etc/apache2 and /etc/apache2/sites-available locations overriding the existing files. Yes, I got backup copies of the files. Apache 2.4.18 is installed so per the instructions I should be adjusting the copy commands to look at the Open-ILS/examples/apache_24 directory. However when I look in that directory I only have eg_24.conf, eg.conf.in<http://eg.conf.in>, eg_vhost_24.conf and eg_vhost.conf.in<http://eg_vhost.conf.in> - so of course if I were to run the cp command as listed it would error out because there are no matching files to be copied. Do I change the names or am I missing something and need to reinstall Apache or something else entirely? -Jon
Re: [OPEN-ILS-GENERAL] Web Staff Client Won't Login
Thanks Jason, that gave me the information I needed to get it working. The websockets configuration file (/etc/apache2-websockets/apache2.conf) didn't have the appropriate SSL information, it was still set to the default values and websockets would not start as a result. Edited that file with the correct .crt and .key entries and websockets stars and the Web staff client is allowing login. Thanks again! Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Wednesday, May 09, 2018 11:53 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Web Staff Client Won't Login On 05/09/2018 01:37 PM, Jesse McCarty wrote: > Netstat doesn't even show anything listening on the default websockets port. That sounds like the websockets instance of Apache is not running. What does # apache2ctl-websockets start output? Note: the # means you should run it as root or via sudo. Jason
Re: [OPEN-ILS-GENERAL] Web Staff Client Won't Login
Thanks for the information everyone. It appears I have everything in place on the firewall configurations but still no go. Netstat doesn't even show anything listening on the default websockets port. I also tried setting up the NGINX proxy in the OpenSRF instructions and with that in place the web staff client goes into offline mode. Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Tuesday, May 08, 2018 5:22 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Web Staff Client Won't Login On 05/07/2018 10:12 PM, Blake Henderson wrote: > That behavior usually means that the browser cannot connect to the > server on port 7682. Check to make sure that your browser can talk to > the server on that port by using this special URL: > > https://yourservername.org:7682 I am going to add that the above is necessary with Firefox if you use a self-signed certificate. Firefox seems to track certificates by server name and port number. So, you'll have to go to that URL and make the security exception for its certificate, too. You will also have to do this every time you change certificates on the server as well. I have not had to do the above with Chromium, and I hear it is not necessary with Chrome, either. You can also avoid the whole mess by setting up a proxy server, which may be overkill for a test installation, but is a good idea for production. Jason
[OPEN-ILS-GENERAL] Web Staff Client Won't Login
Hello Everyone, We recently upgraded to the 3.0 series of Evergreen (3.0.6) and are looking at testing out the web client, but it won't login. I went through the OpenSRF install instructions with the websockets extras and can get to the /eg/staff login page, but clicking on sign in or pressing enter does nothing. Did I miss a step in the install/upgrade somewhere along the line? It also doesn't show any of the custom color schemes of each library, instead staying green - not sure if this is by design or if I have something missing. Thanks in advance, Jesse McCarty City of Burlington Information Systems Technician
Re: [OPEN-ILS-GENERAL] Over 20GB in /openils/var/web/reporter is this normal/safe to clean up?
That’s great, thank you Ben! Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum Sent: Thursday, May 03, 2018 10:46 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Over 20GB in /openils/var/web/reporter is this normal/safe to clean up? Hi Jesse, Those folders contain the generated report contents from the reporter in Evergreen. Most email notifications and reports in the client will point back to those folders / files. In the past, we'd implemented a process to delete old reports from our server. This is a link to the Evergreen Magic spells page on the Evergreen wiki. https://wiki.evergreen-ils.org/doku.php?id=scratchpad:random_magic_spells#regularly_scheduled_report_output_purging You can adapt the scheduled report purging process outlined there to fit your needs. -- Ben On Thu, May 3, 2018 at 10:31 AM, Jesse McCarty wrote: > Hello Everyone, > > > > Checking over disk space on our Evergreen server I noticed the > /openils/var/web/reporter is over 25GB in space, and one of the numbered > subfolders within is 22GB. Looking in that folder, one of the subfolders has > over 100,000 additional subfolders. Is this normal behavior and can those > 100k folders be deleted without any issues? > > > > Thanks in advance. > > > > Jesse McCarty > > City of Burlington > > Information Systems Technician > > -- Benjamin Shum Evergreener
[OPEN-ILS-GENERAL] Over 20GB in /openils/var/web/reporter is this normal/safe to clean up?
Hello Everyone, Checking over disk space on our Evergreen server I noticed the /openils/var/web/reporter is over 25GB in space, and one of the numbered subfolders within is 22GB. Looking in that folder, one of the subfolders has over 100,000 additional subfolders. Is this normal behavior and can those 100k folders be deleted without any issues? Thanks in advance. Jesse McCarty City of Burlington Information Systems Technician
Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish
Jason, If the authority reingest is the one that runs in the 2.12.0-2.12.1 script, it looks like between an hour/hour and a half on our test system this morning. I don't know how many bib records we have, but our Database sits about 24GB if that helps for comparison. Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Wednesday, April 04, 2018 11:58 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish On 04/04/2018 02:46 PM, Jesse McCarty wrote: > Thank you Kathy, > > Those changes seemed to work great. What seemed to never end completed > in about a minute, and I was able to start up Evergreen and > search/renew and otherwise interact with the test system as expected > (in my limited IT testing role not being a library staff member that > fully utilizes the system). Is this to be expected to complete that > fast or should I be wondering if something didn't go as needed? Jesse, I think you're OK. That update went from never finishing on my test system to running in just 12 minutes. (We have several million bib records.) By never finishing, I mean I let it run for a few days before stopping it. If there were any problems, you should see error messages in the console where the script was running. I like to pipe the output to "tee" so it also goes to a file: psql -f upgrade_script.sql |& tee ~/upgrade_script.log The "|&" is a shortcut to send both standard output and errors to the file. Do you know how long the authority ingest part of the updrade scripts runs for you? That runs for over 30 hours on my test system, and it is already about as optimized as it can be. Cheers, Jason
Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish
Thank you Kathy, Those changes seemed to work great. What seemed to never end completed in about a minute, and I was able to start up Evergreen and search/renew and otherwise interact with the test system as expected (in my limited IT testing role not being a library staff member that fully utilizes the system). Is this to be expected to complete that fast or should I be wondering if something didn't go as needed? I'll have a staff member able to test more in depth next week when she returns from vacation. The only thing I didn't let complete from the various update scripts (that started at 2.10.3) was the UPDATE biblio.record_entry SET id = id WHERE source IS NOT NULL; line that was updating the 901 fields (none of our libraries use these apparently) and the consensus from the list here was that if the field isn't used there was no issue not completing this particular field update (one that took more than overnight to run). Thanks again for all the information and help, looks like our upgrade time is very manageable now with this fix. Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Kathy Lussier Sent: Thursday, March 29, 2018 3:20 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish Hi Jesse, After I responded to your e-mail, I submitted a bug with some code to make this change to the 3.0.2-3.0.3 upgrade script. If you look at the submitted code, you'll see exactly how you would add the lines to that particular script. You could copy and paste the code the additions that were made to the script. If you use git, you could also cherry-pick this patch to apply the changes. Please note: this patch has not been reviewed by anyone yet, so it might not be a bad idea for somebody to take a look at it and verify that it looks okay. http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/src/sql/Pg/version-upgrade/3.0.2-3.0.3-upgrade-db.sql;h=6ca665dad31f9e34b39b04fecc9f84ea44745ce1;hp=74a7c0117003a9db2b0d69cde85337216bdab467;hb=d1918fdd3627332a06b9d7a214544d2e46302a1a;hpb=5a6636f53ad07c718c6ba207d3f9d543deec72db If you make those changes as is, there is a section at the end that reenables the triggers before it finishes up. Kathy On 03/29/2018 06:10 PM, Jesse McCarty wrote: > Thanks again for the info. We are on 2.10.3 now and upgrading to 3.0.3. How > would I go about re-enabling the triggers mentioned and is disabling them as > simple as copy/paste the code snipped Kathy sent into the upgrade script? For > combing the scripts, would it just be copy/paste the contents of each one > sequentially into a single file? Do you have a workable single file upgrade > script that you can share? Modifying these files is new to me. > > Thanks again. > > Jesse McCarty > City of Burlington > Information Systems Technician > > -Original Message- > From: Open-ils-general > [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf > Of Jason Stephenson > Sent: Wednesday, March 28, 2018 4:34 PM > To: open-ils-general@list.georgialibraries.org > Subject: Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes > over a week to finish > > On 03/28/2018 06:52 PM, Jesse McCarty wrote: >> Not sure how to proceed to test getting the upgrade more manageable >> prior to upgrading production. Obviously cannot have production down >> or having issues for several business days. > If you add the code to disable triggers, etc., from the 2.12.6 to 3.0 upgrade > script, then it runs it much less time. It ran in about half an hour on my > test system. > > BTW, are you upgrading from 2.10 to 3.0? If so, it sometimes helps to make a > single upgrade script because some steps are occasionally repeated. In this > particular case, the 2.12.6 to 3.0.0 upgrade script does this calculation. It > would be wise to bundle everything up and put that update at the end so you > only have to do it once, rather than twice. > > There's an authority ingest in that 2.12.6 to 3.0 upgrade that takes a lot > longer on my test system. > > Jason -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish
Thanks again for the info. We are on 2.10.3 now and upgrading to 3.0.3. How would I go about re-enabling the triggers mentioned and is disabling them as simple as copy/paste the code snipped Kathy sent into the upgrade script? For combing the scripts, would it just be copy/paste the contents of each one sequentially into a single file? Do you have a workable single file upgrade script that you can share? Modifying these files is new to me. Thanks again. Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Wednesday, March 28, 2018 4:34 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish On 03/28/2018 06:52 PM, Jesse McCarty wrote: > > Not sure how to proceed to test getting the upgrade more manageable > prior to upgrading production. Obviously cannot have production down > or having issues for several business days. If you add the code to disable triggers, etc., from the 2.12.6 to 3.0 upgrade script, then it runs it much less time. It ran in about half an hour on my test system. BTW, are you upgrading from 2.10 to 3.0? If so, it sometimes helps to make a single upgrade script because some steps are occasionally repeated. In this particular case, the 2.12.6 to 3.0.0 upgrade script does this calculation. It would be wise to bundle everything up and put that update at the end so you only have to do it once, rather than twice. There's an authority ingest in that 2.12.6 to 3.0 upgrade that takes a lot longer on my test system. Jason
[OPEN-ILS-GENERAL] 3.0.2-3.0.3 Upgrade DB script takes over a week to finish
Hello Everyone, During my last test cycle we ran into an issue upgrading from 2.10 to a newer version with an update script that was setting the 901$sfor bib records. This took an extended amount of time to complete. Well now, in testing our upgrade to the 3.0 series part of the 3.0.2-3.0.3 version upgrade script took over a week to finish in testing, which is a big issue for updating production. Is it possible to comment out/remove the offending part of the upgrade script and not have any issues with the new system after the upgrade? Could it be the last part of the script in lines 277-291 of the upgrade script taking this long (line 290 perhaps)? 277 UPDATE biblio.record_entry 278 SET vis_attr_vector = biblio.calculate_bib_visibility_attribute_set(id) 279 WHERE id IN ( 280 SELECT DISTINCT cn.record 281 FROM asset.call_number cn 282 WHERE NOT cn.deleted 283 AND cn.label = '##URI##' 284 AND EXISTS ( 285 SELECT 1 286 FROM asset.uri_call_number_map m 287 WHERE m.call_number = cn.id 288 ) 289 UNION 290 SELECT id FROM biblio.record_entry WHERE source IS NOT NULL 291 ); Wondering if others have met something similar and how they dealt with it so as not to cause issues upgrading a production system and minimizing down time. We typically run our upgrades on a Sunday morning and all Evergreen related services are only down for about half a day and usually back up before 10am Monday worst case. Thanks in advance, Jesse McCarty City of Burlington Information Systems Technician
[OPEN-ILS-GENERAL] Check out history CSV download contains less information than displayed within a browser?
Hello everyone, Was curious if anyone had any insight into configuring the check-out history download and what gets included in the download? For our consortium, when a patron has check out history enabled and is viewing in the browser, there are columns for checkout date, due date and returned date. However, when you download the CSV none of these are present in the download. Is there a way to configure Evergreen to include these in the checkout history download? Thanks in advance. Jesse McCarty City of Burlington Information Systems Technician
Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions
Jason, Thanks for the feedback. All of our testing is done on a test system that was created from a backup of the production system and we work through the upgrades on it to work out any issues prior to upgrading the production system. With the 901 field, I am unsure how/if it is utilized within our Library or the three other libraries that are part of our system, awaiting feedback/information from the Catalogers on that one. If any of them utilize it, we'll have to figure out something that can process over a few days without causing any headaches during business hours. Thanks again, Jesse McCarty City of Burlington Information Systems Technician -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason Stephenson Sent: Wednesday, November 15, 2017 8:55 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions Jesse, You can skip the update to the 901 unless you plan to use the new subfield right away. Upgrades are never as simple as one would like, particularly on a system where patches have been applied before they're released, etc. I highly recommend having another machine where you run PostgreSQL with a copy of your production data so that you can test the upgrade scripts before doing it for real. I also recommend becoming familiar with the build/tools/make_release script. It's used by release managers and build masters to make the release tarballs. However, with the correct options, it can be used to generate a custom DB upgrade script from any version of Evergreen to any other. I use it as a first step for our upgrades at C/W MARS. HTH, Jason On 11/15/2017 11:15 AM, Jesse McCarty wrote: > Dan, > > > > Any assistance with creating a file that will break up the update task > would be greatly appreciated. We ended up deciding to hold off on > upgrading until 3.0 was released and we have a running test server > with semi current data in it. But, after doing all the re-ingests and > other associated DB upgrades throughout the various DB scripts, > running the update biblio.record command took something like 4 days. > I’m not sure how the 901 field is used within our library, but I would > like to ensure the upgrade is done completely so there are no > surprises as well as get everything ironed out in the testing > environment so I know exactly what to expect when we upgrade the production > system to the 3.0 series. > > > > Thank you again, > > > > Jesse McCarty > > City of Burlington > > Information Systems Technician > > > > *From:*Open-ils-general > [mailto:open-ils-general-boun...@list.georgialibraries.org] *On Behalf > Of *Daniel Wells > *Sent:* Wednesday, April 19, 2017 7:38 PM > *To:* Evergreen Discussion Group > *Subject:* Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error > questions > > > > Hello Jesse, > > > > For your first issue, it appears you have some kind of encoding > problem in some of records. This is very common for any record with > foreign characters. Without getting into too much detail, MARC > records are generally supposed to use UTF8 encoding (a modern, > universal encoding) or MARC8 encoding (an older, library-centric > standard). Records will commonly say they use one encoding but have > characters from the other, or use characters from an entirely different, > unsupported encoding (e.g. > Latin 1). I would recommend you try to sort these out eventually, but > I don't think you are doing any additional harm here. > > > > For the 901s update, this update is kinda brute-force, so there is a > chance you will run into table lock problems if anyone else tries to > update the biblio.record_entry table while this is running. The > biblio.record_entry table doesn't get updated during normal OPAC and > circ operations, so if you can avoid saving records, you should be > able to run it while live. A safer option (which we typically take) > in situations like this is to actually generate a file where every > update is a separate command (UPDATE biblio.record_entry SET marc = > marc where id = 123; UPDATE biblio.record_entry SET marc = marc where id = > 124; ... > etc.). Such a setup lets it plod along without holding onto multiple > rows as the work is done. Let me know if you need more guidance in > creating such a file. > > > > Also, that upgrade step comes from this feature > addition: https://bugs.launchpad.net/evergreen/+bug/1307553 . Unless > you actively plan to take advantage of this new source subfield $s, > you can delay this entire command until a more convenient time. It &
Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions
Dan, Any assistance with creating a file that will break up the update task would be greatly appreciated. We ended up deciding to hold off on upgrading until 3.0 was released and we have a running test server with semi current data in it. But, after doing all the re-ingests and other associated DB upgrades throughout the various DB scripts, running the update biblio.record command took something like 4 days. I’m not sure how the 901 field is used within our library, but I would like to ensure the upgrade is done completely so there are no surprises as well as get everything ironed out in the testing environment so I know exactly what to expect when we upgrade the production system to the 3.0 series. Thank you again, Jesse McCarty City of Burlington Information Systems Technician From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Daniel Wells Sent: Wednesday, April 19, 2017 7:38 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions Hello Jesse, For your first issue, it appears you have some kind of encoding problem in some of records. This is very common for any record with foreign characters. Without getting into too much detail, MARC records are generally supposed to use UTF8 encoding (a modern, universal encoding) or MARC8 encoding (an older, library-centric standard). Records will commonly say they use one encoding but have characters from the other, or use characters from an entirely different, unsupported encoding (e.g. Latin 1). I would recommend you try to sort these out eventually, but I don't think you are doing any additional harm here. For the 901s update, this update is kinda brute-force, so there is a chance you will run into table lock problems if anyone else tries to update the biblio.record_entry table while this is running. The biblio.record_entry table doesn't get updated during normal OPAC and circ operations, so if you can avoid saving records, you should be able to run it while live. A safer option (which we typically take) in situations like this is to actually generate a file where every update is a separate command (UPDATE biblio.record_entry SET marc = marc where id = 123; UPDATE biblio.record_entry SET marc = marc where id = 124; ... etc.). Such a setup lets it plod along without holding onto multiple rows as the work is done. Let me know if you need more guidance in creating such a file. Also, that upgrade step comes from this feature addition: https://bugs.launchpad.net/evergreen/+bug/1307553 . Unless you actively plan to take advantage of this new source subfield $s, you can delay this entire command until a more convenient time. It won't affect any normal operations to not have that subfield populated. Sincerely, Dan On Wed, Apr 19, 2017 at 4:22 PM, Jesse McCarty mailto:jes...@burlingtonwa.gov>> wrote: Hello Everyone, We are preparing for our spring upgrade to Evergreen, moving from 2.10.3 to 2.11.3 and ran into one little bump. As part of the DB upgrade, there is an update setting the 901$s for bib records. First question, as seen in the attached screen shot, this threw a bunch of ‘no mapping found for….’ Errors. Can this be safely ignored and proceed with running the system after upgrading with no issues (we haven’t seen any issue in our testing)? The second, this update seem to take longer than 24 hours. With that in mind would we be able to process the entire upgrade, then use Evergreen in daily production while this DB update finishes in the background? Or does this need to be 100% complete before allowing library’s connection to the system? Thanks in advance, Jesse McCarty City of Burlington IT Technical Assistant
[OPEN-ILS-GENERAL] Evergreen Self-Check and locking media cases
Hello Everyone, Currently we are running an ITG self-check system that utilizes magnetic locking cases for DVDs and CDs. I know the documentation references no security mechanisms in Evergreen self-check, but I was wondering if there is a way for the Evergreen self-check to interact/activate the magnetic unlockers for security cases? Is this a sought after feature/planned possibility? Or is the built in self-check designed to be nothing more than its current basic form? Thanks in advance, Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Notifying faculty about new books in their discipline
Jane, We would definitely be interested in more details in getting this up and running. I downloaded the code and started working though implementation on a test server based on what is shown online, but there looks to be more configuration information needed that isn't shown at this time (such as location of the conf directory, one of the config files has a reference to a JSON file in your home folder etc...). How the python files are eventually executed, I have a viewable location on the test server, but obviously there is much to configure before it populates correctly. Thanks! Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jane Sandberg Sent: Friday, May 26, 2017 7:01 AM To: Evergreen Discussion Group Subject: [OPEN-ILS-GENERAL] Notifying faculty about new books in their discipline Hi Evergreeners, Our Library sends monthly emails to our faculty that feature recently acquired books that might be of interest to them. This is a nice, automated process that pulls data from Evergreen and then uses call number ranges that we've defined to match books with departments. The emails include cover images and links to place holds, and we're pretty proud of this system. We've got our code up on GitHub: https://github.com/sandbergja/faculty_notifier I'm very happy to share more details if you're interested. -Jane -- Jane Sandberg Electronic Resources Librarian Linn-Benton Community College sand...@linnbenton.edu / 541-917-4655 Pronouns: she/her/hers or they/them/theirs
[OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions
Hello Everyone, We are preparing for our spring upgrade to Evergreen, moving from 2.10.3 to 2.11.3 and ran into one little bump. As part of the DB upgrade, there is an update setting the 901$s for bib records. First question, as seen in the attached screen shot, this threw a bunch of 'no mapping found for' Errors. Can this be safely ignored and proceed with running the system after upgrading with no issues (we haven't seen any issue in our testing)? The second, this update seem to take longer than 24 hours. With that in mind would we be able to process the entire upgrade, then use Evergreen in daily production while this DB update finishes in the background? Or does this need to be 100% complete before allowing library's connection to the system? Thanks in advance, Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Limiting search options for a consortium?
Thanks for the information, I have implemented this in a test server and it seems to have no effect. I can still search the entire Consortium and see records for other libraries. Did I miss something, or have the config in the wrong place? I edited the /etc/apache2/sites-available/eg.conf file and added the SetEnv physical_loc variable to each library as shown below (added it to the *.80 virtualhost as well), and have also made the staff client configuration change (value 1 or 2 made no difference). [cid:image001.png@01D27E02.72DBD690] Thanks again, Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jeff Davis Sent: Wednesday, February 01, 2017 2:26 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Limiting search options for a consortium? Hi Jesse, I believe there are two steps you need to take: (1) Set the physical_loc environment variable in the Apache config for each of your subdomains, using a directive like this: SetEnv physical_loc 4 (2) In your library settings, set "Org Unit Hiding Depth" to the appropriate value for each library. Here's the description for that setting: This will hide certain org units in the public OPAC if the Physical Location (url param "physical_loc") for the OPAC inherits this setting. This setting specifies an org unit depth, that together with the OPAC Physical Location determines which section of the Org Hierarchy should be visible in the OPAC. For example, a stock Evergreen installation will have a 3-tier hierarchy (Consortium/System/Branch), where System has a depth of 1 and Branch has a depth of 2. If this setting contains a depth of 1 in such an installation, then every library in the System in which the Physical Location belongs will be visible, and everything else will be hidden. A depth of 0 will effectively make every org visible. The embedded OPAC in the staff client ignores this setting. Hope that helps! Jeff On 2017-02-01 09:24 AM, Jesse McCarty wrote: > Hello Everyone, > > > > I was wondering if there are any configurations to restrict searches > to a single library in a consortium setup? We have four libraries in > our Evergreen system, all setup for access in sub-domains > (Burlington.skagitcat.org, laconner.skagitcat.org etc...). Occasionally > the search drop down gets switched/changed to search all the libraries > instead of the local library, which causes some confusion for patrons > looking for a book in our library when they don't realize the search > result is showing them a book in a different library. There any > configuration to eliminate the other options from the drop down box in > the web OPAC? Screenshot for reference attached, we would like to keep > the searches on the Burlington Public Library, but sometimes the box > gets set to Skagit Evergreen Libraries. > > > > Thanks in advance > > > > Jesse McCarty > > City of Burlington > > IT Technical Assistant > > >
[OPEN-ILS-GENERAL] Limiting search options for a consortium?
Hello Everyone, I was wondering if there are any configurations to restrict searches to a single library in a consortium setup? We have four libraries in our Evergreen system, all setup for access in sub-domains (Burlington.skagitcat.org, laconner.skagitcat.org etc...). Occasionally the search drop down gets switched/changed to search all the libraries instead of the local library, which causes some confusion for patrons looking for a book in our library when they don't realize the search result is showing them a book in a different library. There any configuration to eliminate the other options from the drop down box in the web OPAC? Screenshot for reference attached, we would like to keep the searches on the Burlington Public Library, but sometimes the box gets set to Skagit Evergreen Libraries. Thanks in advance Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Changing Novelist link in the OPAC
Thank you everyone, the summary.tt2 file Kathy and Brent mentioned was the file I needed. I initially looked at the eg_vhost file when the change was first brought to my attention, but when working with our Novelist rep, that particular code is for another Novelist feature in Evergreen and not this particular customization. Thanks again everyone! Jesse McCarty City of Burlington IT Technical Assistant From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Linda Jansova Sent: Wednesday, January 04, 2017 11:44 PM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Changing Novelist link in the OPAC Hi Jesse, In case you are using the standard way of including external added content to Evergreen catalog (as your interface is apparently customized, I'm not entirely sure it is the case, indeed), the link should be changed in Apache config file /etc/apache2/eg_vhost.conf (line #SetEnv OILS_NOVELIST_URL) as described in Evergreen documentation: http://docs.evergreen-ils.org/2.11/_including_external_content_in_your_public_interface.html. Linda On 4.1.2017 21:43, Brent Mills wrote: Hi Jesse, My best bet would be somewhere in summary.tt2 or copy_table.tt2 as Kathy mentioned. You could also recursively grep your templates for something like the “novelist_button” div class or part of the novelist URL to see where it’s being placed in your templates. That could help give some more clues: example: cd /openils grep -rn ’novelist_button' . Good luck! -Brent - Brent Mills Systems Librarian | Sage Library System email: br...@hoodriverlibrary.org<mailto:br...@hoodriverlibrary.org> tickets: https://sagelib.org/support On Jan 4, 2017, at 12:26 PM, Kathy Lussier mailto:kluss...@masslnc.org>> wrote: Hi Jessy, That link appears to be a customization. Based on its location, I would guess it's either in your opac/parts/record/summary.tt2 file or in opac/parts/record/copy_table.tt2. I hope this helps! Kathy On 01/04/2017 02:47 PM, Jesse McCarty wrote: Hello Everyone, Currently in our catalog, when a book is brought up there is a Novelist link displayed that leads to additional information (highlighted in the screen shot). We have updated our subscription and now need to update this link to reflect the new content. Can anyone point me in the direction of the proper file to edit to update this link? Thanks in advance. Jesse McCarty City of Burlington IT Technical Assistant -- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 343-0128 kluss...@masslnc.org<mailto:kluss...@masslnc.org> Twitter: http://www.twitter.com/kmlussier
Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues
Thanks for the information Ben, The server in the old conversation (thanks for link!) was a 2.4.4 test server that was eventually scrapped and I did not perform the upgrade from 2.4.4. Using the old thread, as well as Galen's information, I was able to apply the fix and then the DB upgrade scripts functioned properly and I now have an upgraded and functional test server. Thank you all again! The interesting part of this process is the two-step process in the 2.9.3-2.10.0 upgrade script where there is intervention needed to exit one screen and continue, and then the fact that part of the script takes all night and then some to finish (The server is a VM with 8 VCPUs, 18GB RAM and resides on SSD storage so it's no slouch). Even on slower hardware of previous upgrades, the records reingest process only took around 4 hours. Thanks again everyone! Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum Sent: Thursday, June 02, 2016 4:57 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues Hi Jesse, That error for missing metabib_field key 30 means that you do not have an entry in the table with ID of 30 (which is supposed to be LCCN in the stock installation). Looking back in the history, I see you've mentioned some issues with this metabib_field entry before (see http://markmail.org/message/wrdyhmaeenavxk2y) Perhaps it would be a good idea to audit your table's entries and compare it with a stock setup to see the differences (and make adjustments). I would start by checking to see if LCCN is already in the metabib_field table. Something like: SELECT id FROM config.metabib_field WHERE name = 'lccn'; If that gives you the ID for your missing LCCN field, that'll tell you what it is, instead of 30. -- Ben On Thu, Jun 2, 2016 at 7:18 PM, Jesse McCarty wrote: > Thank you Galen, > > Looks like I have something else missing, running the > 0795.schema.z39-batch-fetch-overlay.sql script came up with another error and > did a ROLLBACK: > > ERROR: insert or update on table "z3950_index_field_map" violates foreign > key constraint "z3950_index_field_map_metabib_field_fkey" DETAIL: Key > (metabib_field)=(30) is not present in table "metabib_field". > > Jesse McCarty > City of Burlington > IT Technical Assistant > > > -Original Message- > From: Open-ils-general > [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf > Of Galen Charlton > Sent: Thursday, June 02, 2016 10:03 AM > To: Evergreen Discussion Group > > Subject: Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade > issues > > Hi, > > On Thu, Jun 2, 2016 at 12:28 PM, Jesse McCarty > wrote: >> Could simply running the 2.4.3-2.5.0-upgrade-db.sql prior to the >> current DB scripts work, or would only certain portions of that file >> need to be run? My test server is a VM with snapshots, so reverting >> and re-testing anything is trivial. > > No, a subset should suffice. Specifically, the following steps before > running the main upgrade SQL: > > [1] running the SQL in upgrade/0795.schema.z39-batch-fetch-overlay.sql > (taken from the 2.10.x tarball) > > For example: > > psql> \set eg_version NULL > psql> \i upgrade/0795.schema.z39-batch-fetch-overlay.sql > > [2] following up with just this bit from the 0843 upgrade: > > ALTER TABLE config.z3950_index_field_map DROP CONSTRAINT > z3950_index_field_map_metabib_field_fkey; > ALTER TABLE config.z3950_index_field_map ADD CONSTRAINT > z3950_index_field_map_metabib_field_fkey FOREIGN KEY (metabib_field) > REFERENCES config.metabib_field(id) ON UPDATE CASCADE DEFERRABLE > INITIALLY DEFERRED; > > Apropos of a conversation during the development meeting yesterday, DB > revisions 0841/0842/0843 are a good example of where backporting schema > updates can be tricky. > > Regards, > > Galen > -- > Galen Charlton > Infrastructure and Added Services Manager Equinox Software, Inc. / > Open Your Library > email: g...@esilibrary.com > direct: +1 770-709-5581 > cell: +1 404-984-4366 > skype: gmcharlt > web:http://www.esilibrary.com/ > Supporting Koha and Evergreen: http://koha-community.org & > http://evergreen-ils.org
Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues
Thank you Galen, Looks like I have something else missing, running the 0795.schema.z39-batch-fetch-overlay.sql script came up with another error and did a ROLLBACK: ERROR: insert or update on table "z3950_index_field_map" violates foreign key constraint "z3950_index_field_map_metabib_field_fkey" DETAIL: Key (metabib_field)=(30) is not present in table "metabib_field". Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Galen Charlton Sent: Thursday, June 02, 2016 10:03 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues Hi, On Thu, Jun 2, 2016 at 12:28 PM, Jesse McCarty wrote: > Could simply running the 2.4.3-2.5.0-upgrade-db.sql prior to the > current DB scripts work, or would only certain portions of that file > need to be run? My test server is a VM with snapshots, so reverting > and re-testing anything is trivial. No, a subset should suffice. Specifically, the following steps before running the main upgrade SQL: [1] running the SQL in upgrade/0795.schema.z39-batch-fetch-overlay.sql (taken from the 2.10.x tarball) For example: psql> \set eg_version NULL psql> \i upgrade/0795.schema.z39-batch-fetch-overlay.sql [2] following up with just this bit from the 0843 upgrade: ALTER TABLE config.z3950_index_field_map DROP CONSTRAINT z3950_index_field_map_metabib_field_fkey; ALTER TABLE config.z3950_index_field_map ADD CONSTRAINT z3950_index_field_map_metabib_field_fkey FOREIGN KEY (metabib_field) REFERENCES config.metabib_field(id) ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED; Apropos of a conversation during the development meeting yesterday, DB revisions 0841/0842/0843 are a good example of where backporting schema updates can be tricky. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / Open Your Library email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues
Thanks for the information Josh. We had been running 2.4.4 in the past and skipped over the 2.5 series, upgrading directly to 2.6.3 from 2.4.4 (Our support company performed this upgrade). From 2.6.3 we went to 2.7.3, 2.8.3 and now we are running 2.9.3. Could simply running the 2.4.3-2.5.0-upgrade-db.sql prior to the current DB scripts work, or would only certain portions of that file need to be run? My test server is a VM with snapshots, so reverting and re-testing anything is trivial. Thanks again. Jesse McCarty City of Burlington IT Technical Assistant From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Josh Stompro Sent: Thursday, June 02, 2016 8:13 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues Hello Jesse, it might help to know the history of your system. What version you started with and how often you have upgraded? The 2.9.3-2.10.0_DBError02.jpg issue is because the config.z3950_index_field_map table doesn't exist. So you probably missed a schema update in the past. Maybe something in the 2.5 upgrade? Looks like the 2.4.3-2.5.0-upgrade-db.sql includes adding that table. Maybe you were on 2.4.4 or greater and missed some updates when you moved to 2.5? Josh Stompro - LARL IT Director From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jesse McCarty Sent: Wednesday, June 01, 2016 6:07 PM To: open-ils-general@list.georgialibraries.org<mailto:open-ils-general@list.georgialibraries.org> Subject: [OPEN-ILS-GENERAL] Evergreen 2.9.3 - 2.10.3 upgrade issues Hello Everyone, I am working on testing our next upgrade of Evergreen (2.9.3 to 2.10.3) and am running into issues with the database upgrade scripts and was wondering if anyone had similar issues or insight into what might be happening. I have attached screen shots of the errors I have been running into for reference. The first error occurs when running the 2.9.3-2.10.0 db upgrade script (2.9.3-2.10.0_DBError01.jpg) and appears to be informational with no impact on the script. The next issue shows up at the end of the 2.9.3-2.10.0 script (2.9.3-2.10.0_DBError02.jpg and 2.9.3-2.10.0_DBError02B.jpg) which appears to undo some of the changes it had made/attempted to make, but still appears to finish some changes. The next issue happens when trying to run the 2.01.0-2.10.1 db upgrade script and this is as far as I got, since it indicates a rollback and no changes made (I did try for kicks to run the 2.10.1-2.10.2 script, which failed as well). I also noticed that the Reingest that is part of the 2.9.3-2.10.0 script gets to a point that requires intervention before conintinueing. The screen hangs with a : at the bottom waiting for some input. I typed in q (like quitting vim) and it then seemed to continue on as normal and I'm not sure if typing q just exited the screen or canceled the work it was going to do. Any help is greatly appreciated, Thanks, Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Upgraded to 2.8.3 - Book covers no longer loading
Thanks Galen, That was the clue I needed. I commented out all the other added content modules (which were only default place holders from the standard config file) and left only our Syndetics added content information and the book covers show up again. The Novelist information was in an Apache configuration file and I was apparently looking in the wrong spot when I composed my original e-mail. Thanks again Everyone! Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Galen Charlton Sent: Tuesday, August 25, 2015 8:39 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Upgraded to 2.8.3 - Book covers no longer loading Hi, On Tue, Aug 25, 2015 at 11:19 AM, Bill Erickson wrote: > If you have Novelist set as your added content provider in opensrf.xml > it could produce the kind of error you are seeing. In particular, I was able to get a similar error with a configuration that has more than one active element in the section of opensrf.xml. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: g...@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web:http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
[OPEN-ILS-GENERAL] Upgraded to 2.8.3 - Book covers no longer loading
Hello Everyone, I just recently upgraded our test server (slated for promotion to Production once the kinks are worked out) from 2.8.1 to 2.8.3 and now none of the book cover images are loading. Has anyone run into this or know what I need to change to get them back? I copied over our Novelist SetEnv information from the old configuration file and this appears to be the only thing that broke with the 2.8.3 upgrade. Only clue I can see so far in the logs is the following line: Evergreen gateway: [perl:error] [pid 30041] [172.xx.xx.xxx:54675] Can't call method "use" on unblessed reference at /usr/local/share/perl/5.18.2/OpenILS/WWW/AddedContent.pm line 67 Thanks in advance. Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Marc Export Script Error
Dan, The Marc records are exported and then supplied to Boopsie for inclusion in the mobile app (runs weekly to provide updates). The export is independent of data migration activities, and is one of the functions I am trying to ensure is in working order prior to a planned fall deployment. Currently library staff are reviewing the records in question to see if they can figure out what is broken in them. Jesse McCarty City of Burlington IT Technical Assistant From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Dan Wells Sent: Tuesday, July 28, 2015 1:35 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Marc Export Script Error Jesse, Getting back to what you are trying to accomplish, is there a particular reason you are exporting your MARC records? If you're just migrating the whole database to a new server, I'd say exporting and reimporting the MARC isn't something you'd need (or want) to do. It's also possible you're actually talking about a data dump and restore, and I am just misunderstanding. It might still be worth looking over those records to see if you can spot the problem, but honestly, a database with only three records with shoddy MARC isn't bad at all :) Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133 From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jesse McCarty Sent: Tuesday, July 28, 2015 12:30 PM To: open-ils-general@list.georgialibraries.org<mailto:open-ils-general@list.georgialibraries.org> Subject: [OPEN-ILS-GENERAL] Marc Export Script Error Hi Everyone, I am working on a new Evergreen Server to deploy in the fall (Ubuntu 14.04, Postgres 9.3 - Current system is Ubuntu 12.04, Postgres 9.2) and am running into an error with the marc_extract script. The script works with no issue on the production system running Postgres 9.2, but after I import the current production data into a test server (identical to the current production server, with older DB data) and upgrade Postgres to 9.3 it stops working with the following error: Error in bibliographic record 168171 Substr outside of string at /usr/share/perl5/MARC/Record.pm line 573 There are two other bibliographic records that have the error as well (168498 & 172482). The new database seems to be working otherwise (attached is a screen shot of the output of the pg_upgradecluster results) even though the upgrade showed some errors. Any help is greatly appreciated. Thanks! Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Marc Export Script Error
Thanks for the information Ben. We are running Evergreen 2.7.3 in production & our test server. Our newly built server is running Evergreen 2.8.1 (plan to upgrade to 2.8.3 prior to deployment). The script ran, but produced no final .gz file (just the errors mentioned originally). Would our library staff be able to take the ID's and locate the record in question? I couldn't figure out how to take the ID given and find the record to see what was going on (tried searching in the staff client, but nothing came up). Of course, I wouldn't know what to look for once I found the MARC record so hopefully the library staff would recognize a bad MARC record... Thanks again. Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum Sent: Tuesday, July 28, 2015 10:50 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Marc Export Script Error For more details and history in IRC logs - http://irc.evergreen-ils.org/evergreen/2014-07-30#i_114153 -- csharp encountered malformed MARC in his tests with marc_export post Evergreen 2.6 era. Dyrcona created a patch and this was applied with Launchpad -- https://bugs.launchpad.net/evergreen/+bug/1350345 -- to avoid having marc_export die from bad records. From the LP, the maintenance releases that contained those fixes were 2.7.0 and 2.6.4. So yeah, my guess is that there's something wrong with those MARC records on your system Jesse. Since you have the IDs from the export attempt, you can try to determine what is in those records that cause them to fail to export cleanly. -- Ben On Tue, Jul 28, 2015 at 1:34 PM, Ben Shum wrote: > Hi Jesse, > > Some questions for you... what version of Evergreen are you using with > that PostgreSQL 9.3 system? > > That error you're seeing from the upgrade log sounds like maybe you > might not have your search_path set appropriately after the database > was copied over. For example: "After restoring a database, make sure > to reset the search_path accordingly with something like: alter > database unpredicable_haxxors_go_away set search_path = evergreen, > public, pg_catalog;" > > As for that other error, Substr outside of string at > /usr/share/perl5/MARC/Record.pm line 573 ; my guess is that you have > some bad MARC records in your database. This is likely unrelated to > your change in PostgreSQL, or maybe the version of MARC::Record that > you're now using is less tolerant? Or maybe you were using the older > marc_export script before it was changed around 2.6 or so and it > somehow tolerated the bad MARC better. > > In any case, I would check those bibs out on your system to determine > if there's any red flags in the way the MARC was created. Maybe > there's something that doesn't conform to the "standard" and that's > making things unhappy. > > -- Ben > > On Tue, Jul 28, 2015 at 12:30 PM, Jesse McCarty > wrote: >> Hi Everyone, >> >> >> >> I am working on a new Evergreen Server to deploy in the fall (Ubuntu >> 14.04, Postgres 9.3 – Current system is Ubuntu 12.04, Postgres 9.2) >> and am running into an error with the marc_extract script. The script >> works with no issue on the production system running Postgres 9.2, >> but after I import the current production data into a test server >> (identical to the current production server, with older DB data) and >> upgrade Postgres to 9.3 it stops working with the following error: >> >> >> >> Error in bibliographic record 168171 >> >> Substr outside of string at /usr/share/perl5/MARC/Record.pm line 573 >> >> >> >> There are two other bibliographic records that have the error as well >> (168498 & 172482). >> >> >> >> The new database seems to be working otherwise (attached is a screen >> shot of the output of the pg_upgradecluster results) even though the >> upgrade showed some errors. >> >> >> >> Any help is greatly appreciated. Thanks! >> >> >> >> Jesse McCarty >> >> City of Burlington >> >> IT Technical Assistant >> >> > > > > -- > Benjamin Shum > Evergreen Systems Manager > Bibliomation, Inc. > 24 Wooster Ave. > Waterbury, CT 06708 > 203-577-4070, ext. 113 -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
Re: [OPEN-ILS-GENERAL] Mobius Book Carousel Demoed at the EG Conference this year
Blake, Thanks for the information. Yes, I did get the code from Github and had placed all the files in the default location. After copying the .tt2 files to our /openils/var/templates_burlington/opac/parts/ folder (and editing to add the book bag #s) the three book bag titles are now appearing. Now, the only issue is nothing is propagating into the three book bags (ones I created shown below). I created the lists with our circulation account from a web browser and all three are shared, should they be created with an admin account? Since this is not our production server, (running on slightly older data) I checked in/renewed books from my patron account via the staff client to try and get information into them, but still nothing has filled the lists. Do these book bags depend on any cron jobs to propagate? [cid:image001.png@01D0B263.258BF4E0] Thanks again! Jesse McCarty City of Burlington IT Technical Assistant From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Blake Henderson Sent: Monday, June 29, 2015 11:20 AM To: open-ils-general@list.georgialibraries.org Subject: Re: [OPEN-ILS-GENERAL] Mobius Book Carousel Demoed at the EG Conference this year Jesse, Did you happen to get the code from Github? https://github.com/mcoia/mobius_evergreen/tree/master/bookbag_update There is a folder structure there intended to match the folder structure in /openilstemplat /openils/var/web/opac/skin/default/js/carousel and /openils/var/web/templates/opac/parts The various files belong to various places. If you are using a template override, book_carousel.tt2 needs to be in the base template folder otherwise the template toolkit breaks. Be sure and edit book_carousel.tt2 and replace the numbers with your bookbag id numbers. If you are getting nothing, then you might need to inspect the resulting html page and look for Check to see if that div has any content. If not, the javascript stuff isn't working. If it does, then take a careful look at your CSS. The jquery plugin jcarousel is picky about the CSS. If you just use the CSS example from Github, it should work but it never hurts to double check. I would be happy to take a look at what you have. -Blake- Conducting Magic MOBIUS 573-234-4513 877-312-3517 On 6/29/2015 11:56 AM, Jesse McCarty wrote: Hello All, Has anyone implemented the Book Carousel that Mobius demoed at the conference this year? (http://slides.mobiusconsortium.org/blake/bookcarousel/#/1). I have been going over the slides trying to implement this on our test server with no luck so far. I have placed the appropriate .tt2 files in their locations and created lists with our circulation account, but nothing is showing up either in the lists or on our OPAC. Are there additional instructions online somewhere that I am missing? Extra details: we have four libraries running on our system and at this point we are only looking to implement it for one. Thanks! Jesse McCarty City of Burlington IT Technical Assistant
[OPEN-ILS-GENERAL] Mobius Book Carousel Demoed at the EG Conference this year
Hello All, Has anyone implemented the Book Carousel that Mobius demoed at the conference this year? (http://slides.mobiusconsortium.org/blake/bookcarousel/#/1). I have been going over the slides trying to implement this on our test server with no luck so far. I have placed the appropriate .tt2 files in their locations and created lists with our circulation account, but nothing is showing up either in the lists or on our OPAC. Are there additional instructions online somewhere that I am missing? Extra details: we have four libraries running on our system and at this point we are only looking to implement it for one. Thanks! Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Securing an Evergreen Server
Thanks for the feedback Ben. I have actually been running unattended upgrades on all our Ubuntu servers for a while now (probably close to a year, including our current Evergreen production and test server). I have the automatic-reboot option set to false and then run a script via cron every Thursday (our planned maintenance day for system restarts if necessary) that checks if a system restart is required and reboots if necessary. This setup has been trouble free so far, but I will keep in mind the possible PostgresSQL issue mentioned and monitor the new server (which will be run in a test environment to see if there are any issues before taking over the production work). I upgraded PostgresSQL to version 9.2 (from 9.1) via the Postgres apt repository on our current production server and since then some versioning has gotten off kilter and now there are broken dependencies on the production server with Postgres 9.1. This has prompted me to move my server upgrade instead of staying on 12.04. Should be a nice upgrade though, moving to an SSD based server. We are small enough that our Evergreen setup is one server for everything, its running behind the hardware firewall with a virtual IP on said firewall (which also has additional rules/security to keep things locked down as much as possible - but more security doesn't hurt). Jesse McCarty City of Burlington IT Technical Assistant -Original Message- From: Open-ils-general [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum Sent: Wednesday, June 03, 2015 9:52 AM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Securing an Evergreen Server Hi Jesse, I might actually recommend against doing any unattended upgrades on your servers. I've seen this occur before where a security fix for PostgreSQL (which is normally a good thing) caused the server to restart spontaneously and disrupt Evergreen services, which didn't reconnect appropriately after the restart. In my experiences, it's been more effective to plan for and apply updates as necessary manually, rather than automatically. It does require more constant vigilance on the part of staff, but it leaves less surprises. I'll ponder the rest of your questions and will reply if others don't get there first, but I just wanted to mention that opinion first. -- Ben On Wed, Jun 3, 2015 at 11:38 AM, Jesse McCarty wrote: > Hello Everyone, > > > > I am in the process of building a new host server (Ubuntu 14.04) for > our Evergreen system, with a planned deployment in the fall running > the 2.8 series of Evergreen. I was wondering what steps fellow Sys > Admins take to secure the host OS for the best possible security? We > obviously have a good hardware firewall on our network and I was > planning on installing fail2ban and mod_security in Apache. I also > plan on blocking unused ports with the system firewall. For SSH > connections we have deny all in our hosts.deny file with only the > needed IP addresses in our hosts.allow file. The host system also runs > unattended upgrades in the middle of the night so any important security > fixes are applied without delay. > > > > Any other steps to take to ensure a secure environment? > > > > Thanks! > > > > Jesse McCarty > > City of Burlington > > IT Technical Assistant > > -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
[OPEN-ILS-GENERAL] Securing an Evergreen Server
Hello Everyone, I am in the process of building a new host server (Ubuntu 14.04) for our Evergreen system, with a planned deployment in the fall running the 2.8 series of Evergreen. I was wondering what steps fellow Sys Admins take to secure the host OS for the best possible security? We obviously have a good hardware firewall on our network and I was planning on installing fail2ban and mod_security in Apache. I also plan on blocking unused ports with the system firewall. For SSH connections we have deny all in our hosts.deny file with only the needed IP addresses in our hosts.allow file. The host system also runs unattended upgrades in the middle of the night so any important security fixes are applied without delay. Any other steps to take to ensure a secure environment? Thanks! Jesse McCarty City of Burlington IT Technical Assistant
Re: [OPEN-ILS-GENERAL] Evergreen 2.6.1 and 2.5.5 Uploaded
Here is a question: What is the official supported upgrade path from one version (2.4.x - 2.5.x, 2.5.x-2.6.x etc..) to the next? Looking through the DB upgrade scripts I see 2.4.3-2.5.0 upgrade script and a 2.5.3-2.6.0 upgrade script. Will any upgrade past a 2.x.3 (such as the 2.4.4-2.5.4 upgrade I have been trying to complete) run into headaches and issues? If we are looking to jump into a newer version (versus staying on a particular branch for an extended period of time) would we be wise to avoid going higher than a 2.x.3 release (say, upgrade to 2.5.3 with the plans to upgrade to either 2.6.x or 2.7.x at a later date and again going no higher than a 2.x.3 release)? Currently with our Evergreen system we have scheduled 3 in house upgrades per year, with the initial plan being two point release upgrades and one major version upgrade per year (though, with the improvements to Acquisitions in 2.5.x we are re-evaluating the only one major release upgrade plan). I am trying to plan out the upgrade path to eliminate as many issues as possible when upgrading. Thanks, Jesse McCarty City of Burlington IT Technical Assistant From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Dan Wells Sent: Thursday, May 29, 2014 9:08 AM To: 'open-ils-general' Subject: [OPEN-ILS-GENERAL] Evergreen 2.6.1 and 2.5.5 Uploaded Hello all, Maintenance releases 2.6.1 and 2.5.5 are now available for preview testing: http://evergreen-ils.org/downloads/previews/Evergreen-ILS-2.6.1.tar.gz http://evergreen-ils.org/downloads/previews/Evergreen-ILS-2.6.1.tar.gz.md5 http://evergreen-ils.org/downloads/previews/evergreen-client-2.6.1_i686.tar.bz2 http://evergreen-ils.org/downloads/previews/evergreen-client-2.6.1_i686.tar.bz2.md5 http://evergreen-ils.org/downloads/previews/evergreen-client-2.6.1_x86_64.tar.bz2 http://evergreen-ils.org/downloads/previews/evergreen-client-2.6.1_x86_64.tar.bz2.md5 http://evergreen-ils.org/downloads/previews/evergreen-setup-2.6.1.exe http://evergreen-ils.org/downloads/previews/evergreen-setup-2.6.1.exe.md5 http://evergreen-ils.org/downloads/previews/ChangeLog-2.6.0-2.6.1 http://evergreen-ils.org/downloads/previews/Evergreen-ILS-2.5.5.tar.gz http://evergreen-ils.org/downloads/previews/Evergreen-ILS-2.5.5.tar.gz.md5 http://evergreen-ils.org/downloads/previews/evergreen-client-2.5.5_i686.tar.bz2 http://evergreen-ils.org/downloads/previews/evergreen-client-2.5.5_i686.tar.bz2.md5 http://evergreen-ils.org/downloads/previews/evergreen-client-2.5.5_x86_64.tar.bz2 http://evergreen-ils.org/downloads/previews/evergreen-client-2.5.5_x86_64.tar.bz2.md5 http://evergreen-ils.org/downloads/previews/evergreen-setup-2.5.5.exe http://evergreen-ils.org/downloads/previews/evergreen-setup-2.5.5.exe.md5 http://evergreen-ils.org/downloads/previews/ChangeLog-2.5.4-2.5.5 As always, feedback is appreciated. Thanks, Dan Daniel Wells Library Programmer/Analyst Hekman Library, Calvin College 616.526.7133
