| Time |
Nick |
Message |
| 00:04 |
|
dbwells_ joined #evergreen |
| 06:58 |
|
TARA joined #evergreen |
| 07:15 |
|
agoben joined #evergreen |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:26 |
|
TARA joined #evergreen |
| 08:52 |
|
bos20k joined #evergreen |
| 08:58 |
|
mmorgan joined #evergreen |
| 09:15 |
|
maryj joined #evergreen |
| 09:24 |
|
jvwoolf1 joined #evergreen |
| 09:35 |
|
gmcharlt joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 09:45 |
|
kmlussier joined #evergreen |
| 10:10 |
dbs |
Hey so for those who upgraded from 2.7 -> 2.10 or any of the steps in between, did you notice an increased demand for open-ils.cstore / other processes that resulted in more tweaking of max_children in opensrf.xml etc? |
| 10:12 |
bshum |
dbs: How much higher? |
| 10:13 |
bshum |
I only ask cause we always ran it with more than stock ever since https://bugs.launchpad.net/evergreen/+bug/701208 happened back in 2.0 |
| 10:13 |
dbs |
bshum: I bumped max children for cstore back up to 45, which is what we had on 2.7 before to deal with spikes; inadvertently reset it to 15 when we went to 2.10 and I saw evidence of starvation |
| 10:14 |
bshum |
And yeah in that bug it says 45 too for Dyrcona and that's likely what we set ours to ever since |
| 10:14 |
dbs |
bshum++ # thanks for the pointer, I'll check our max_requests because that's probably back to stock |
| 10:15 |
dbs |
ah, no, we were at 1000. hmm |
| 10:16 |
dbs |
I'm just in the post-upgrade "why do we have network timeouts and slow connectivity" detective work phase, which we seem to have to do after every upgrade. |
| 10:16 |
dbs |
Hoping for a silver bullet :) |
| 10:19 |
dbs |
was super-happy to figure out that our MARC record ingest wide-character failure in Encode.pm problem turned out to be having an old copy of maintain_control_numbers() db function in the public. schema that was getting called instead of the shiny evergreen.maintain_control_numbers() |
| 10:21 |
csharp |
dbs: did you also upgrade ubuntu in the process (assuming that's your platform from something you said before...) |
| 10:21 |
dbs |
Although there are bug reports about the effect of backup/restore on the search path, I'm not sure we have a clearly documented "Here's how to restore your database and deal with the now public schema functions" best practices tip |
| 10:21 |
dbs |
csharp: we upgraded the evergreen server from 12.04 to 14.04, yeah |
| 10:22 |
csharp |
dbs: iirc, both we and JBoyer saw increase cstore needs with that upgrade |
| 10:22 |
dbs |
our hosts upgraded the database servers to xenial back in June, turns out they had run into the problem on their databases but forgot that we might need a fix too :) |
| 10:22 |
csharp |
but we were never able to pin it down to EG/PG/Ububuntu |
| 10:22 |
csharp |
or Ubuntu, even :-) |
| 10:23 |
csharp |
we upgraded Evergreen, PostgreSQL and Ubuntu in one go back in January] |
| 10:23 |
* csharp |
won't be doing that again |
| 10:24 |
* bshum |
ain't afraid of no upgrade |
| 10:25 |
* csharp |
posts bshum's email address to PINES-L email list, drops mic, walks away |
| 10:25 |
bshum |
:D |
| 10:28 |
csharp |
dbs: in case you weren't tuned in during our upgrade in January, we had some issues - see this thread if you missed it: http://www.mail-archive.com/open-ils-general@list.georgialibraries.org/msg12066.html |
| 10:28 |
StomproJ |
dbs, are the bug reports about backup/restore for evergreen? Or just for postgresql in general... I was just searching launchpad for eg related bugs so I could read up on that, but I'm not finding anything. |
| 10:34 |
dbs |
csharp++ # thanks, we're still on Postgresql 9.1 on xenial; I'm entirely hands-off when it comes to the postgresql server these days |
| 10:35 |
bshum |
9.1? *shudders* |
| 10:35 |
bshum |
:D |
| 10:35 |
dbs |
StomproJ: postgresql in general, and in combination with restoring evergreen databases, there are fragments of conversation in IRC and in various mailing lists |
| 10:36 |
dbs |
bshum: yeah, our hosts are on 9.4 but I figured upgrading Ubuntu + Evergreen (3 major releases) in one day was enough. *That much* I learned from csharp :) |
| 10:37 |
|
_adb joined #evergreen |
| 10:38 |
dbs |
StomproJ: and yeah, not official bug reports I guess--more just "hey is anybody else seeing what I'm seeing" comms |
| 10:38 |
bshum |
Speaking of which, we should probably update the documentation for the README in master/2.11 to say PG 9.3 minimum |
| 10:39 |
dbs |
https://www.google.ca/search?q=evergreen+search+path for example :) |
| 10:39 |
bshum |
If pinesol_green were around a ~search_path would say something too |
| 10:40 |
dbs |
oh, and for anyone who isn't on 2.10 yet, maybe we should backport dbwells' reingest speed-up so that it gets rolled in prior to the required attr reingest, because holy hell that would have taken forever for us |
| 10:40 |
dbs |
dbwells++ |
| 10:42 |
|
kmlussier joined #evergreen |
| 10:42 |
|
rhamby joined #evergreen |
| 10:42 |
|
pinesol_green joined #evergreen |
| 10:42 |
|
dkyle joined #evergreen |
| 10:42 |
|
phasefx joined #evergreen |
| 10:47 |
dbs |
that, plus pingest.pl, basically made our upgrade feasible over a half day of downtime instead of over a three-day weekend of downtime |
| 10:47 |
csharp |
dbwells_++ Dyrcona++ |
| 10:48 |
dbs |
indeed, Dyrcona++ |
| 10:49 |
dbs |
and dbwells++ # more karma can't hurt |
| 10:51 |
* dbs |
wonders if some of the staff client slowdowns might be due to the increased HTTPS measures we added in Apache 2.4 (OCSP stapling and other arcane things) |
| 10:51 |
dbs |
So many wonderful possibilities to explore :) |
| 10:55 |
StomproJ |
dbs, thanks for not using lmgtfy.com :-) |
| 10:59 |
bshum |
dbs: That wouldn't surprise me actually. |
| 11:00 |
Bmagic |
We just upgraded from 9.3 to 9.5 on 14.04. I had to recreate some metabib functions after the dump and restore process |
| 11:00 |
Bmagic |
and the permission schema had that bug that required function replacements bug 1568046 |
| 11:00 |
pinesol_green |
Launchpad bug 1568046 in Evergreen "Concerto won't load because of problem with permission.grp_ancestors on PostgreSQL 9.5" [Undecided,Fix committed] https://launchpad.net/bugs/1568046 |
| 11:01 |
|
Bmagic joined #evergreen |
| 11:03 |
Bmagic |
"time pg_dump -i -Fd -Z 9 -f /path/data_dump --serializable-deferrable evergreen" |
| 11:05 |
Bmagic |
after creating the database on 9.5. I also needed to run ALTER DATABASE evergreen SET search_path TO evergreen,public; |
| 11:10 |
|
hopkinsju_ left #evergreen |
| 11:33 |
|
brahmina joined #evergreen |
| 12:18 |
|
jwoodard joined #evergreen |
| 12:23 |
|
plux joined #evergreen |
| 12:38 |
|
jihpringle joined #evergreen |
| 12:42 |
|
bmills joined #evergreen |
| 12:46 |
plux |
Have a 2.10.6 install running on pg 9.4 which is on an ubuntu 14.04 LTS server…..hitting the no active tranactions error from opensrf and ‘there is no transaction in progress’ on the db logs but don’t see the diff in configs from 2.9x and pg 9.2. Read some of the past posts on this but not getting on top of it yet. Any thoughts? |
| 12:47 |
jeff |
plux: what action are you trying to perform that isn't working? |
| 12:48 |
jeff |
a postgres log entry containing "WARNING: there is no transaction in progress" is not itself a sign of something broken. |
| 12:49 |
plux |
right….things are working…but I had two unexplained crashes and some lag in checkin from the client and I didn’t have these errors before |
| 12:50 |
plux |
tried to eliminate them with setting autocommit to off but doesn’t seemed to have worked or helped the situation |
| 12:50 |
plux |
as you say, it’s not clear that it’s actually breaking anything however but there is some unstable behaviour |
| 12:54 |
jeff |
i wouldn't recommend adjusting something like autocommit. |
| 12:54 |
miker |
plux: a spurious rollback in the code will cause that log message. that can happen when shared code that might run inside a transaction is called without one. that's not particularly uncommon |
| 12:54 |
jeff |
(in this case) |
| 12:55 |
miker |
also, what jeff says about autocommit. though, we protect against writes outside transactions |
| 12:56 |
jeff |
plux: what kind of unexplained crashes did you encounter? were there other log entries around those times, aside from the not-uncommon "no transaction in progress" / "No active transaction to roll back" ones? |
| 12:57 |
Bmagic |
plux: have you dumped the database and restored it recently? |
| 12:57 |
plux |
yes |
| 12:58 |
Bmagic |
I had these exact same issues after I did that |
| 12:58 |
plux |
this is post upgrade from 2.9 to 2.10.6 last week |
| 12:58 |
jeff |
it can be easy to focus on one particular thing in the logs. sometimes helpful to step back and look at the problem from the start again. :-) |
| 12:58 |
Bmagic |
You probably have a search path issue |
| 12:58 |
plux |
:) indeed |
| 12:58 |
Bmagic |
Try running this on the database: ALTER DATABASE evergreen SET search_path TO evergreen,public; |
| 12:59 |
bshum |
Maybe start with SHOW search_path; |
| 12:59 |
bshum |
To see what it is |
| 12:59 |
Bmagic |
bshum++ |
| 12:59 |
bshum |
Before you alter it |
| 12:59 |
plux |
will do …good place to start |
| 13:00 |
bshum |
Bmagic++ # good suggestion |
| 13:01 |
bshum |
I guess I'm more cautious after eating lunch. This morning I was much more adventurous. :) |
| 13:01 |
Bmagic |
It's very timely. I just did this last week, and had the same exact errors in my logs |
| 13:01 |
plux |
comes back as "$user",public which would seem to be correct (db user is evergreen) |
| 13:02 |
Bmagic |
bummer, I guess that wasn't it. I believe we need more information from your log. "No transaction in progress" happens later. I found that the real error was more like "Function oils_xpath does not exist" |
| 13:04 |
Bmagic |
The error message might be in /openils/var/log/osrfsys.log |
| 13:06 |
Bmagic |
I have a question while we are here. Do copy level holds "Beat" title level holds when it comes to "who gets it first" ? We have patrons who are "butting in line" beating patrons who have older holds for the same thing |
| 13:08 |
csharp |
Bmagic: yeah, they can. Basically copy and volume holds subvert the entire holds process and shouldn't be used except when they are actually needed (as in, a cataloger needs a specific copy, for example) |
| 13:08 |
Bmagic |
Ah! that explains it |
| 13:08 |
csharp |
they also have the downside of restricting the hold to only being filled by that specific copy, which could (and does) end up screwing the patron |
| 13:09 |
csharp |
but staff in our libraries still try to outgame the holds system with copy level holds, I'm sure |
| 13:10 |
plux |
so…no transaction in progress is from the db server logs ….osrfsys.log is fine open-ils.circ_stderr.log has Caught error from 'run' method: Exception: OpenSRF::DomainObject::oilsMethodException 2016-09-06T08:52:43 OpenSRF::Application /usr/local/share/perl/5.18.2/OpenSRF/Application.pm:231 <500> No active transaction to roll back |
| 13:11 |
csharp |
Bmagic: if you or your staff are *really* curious, here is the white paper my colleagues wrote a few years ago about how EG holds work in PINES: http://pines.georgialibraries.org/holds-white-paper |
| 13:11 |
Bmagic |
csharp++ |
| 13:12 |
Bmagic |
plux: keep looking - I believe you are missing the real error in there somewhere, scroll up? |
| 13:13 |
plux |
open-ils.vandelay_stderr.log is throwing Invalid indicator "\" forced to blankInvalid indicator "\" forced to blank |
| 13:13 |
plux |
Caught error from 'run' method: Exception: OpenSRF::DomainObject::oilsMethodException 2016-09-07T12:39:33 OpenSRF::Application /usr/local/share/perl/5.18.2/OpenSRF/Application.pm:231 <500> Error committing transaction as well |
| 13:14 |
Bmagic |
hrm. Post the log to pastebin? (remove sensitive data) |
| 13:15 |
mmorgan |
csharp: Bmagic: I thought copy and volume holds were still interfiled with title holds, unless they are forced - I'll have a look at the white paper. |
| 13:15 |
plux |
k…will do |
| 13:26 |
dbs |
plux: we're just recently on 2.10.6 and getting "No active transaction to commit" on open-ils.circ open-ils.circ.checkin |
| 13:27 |
dbs |
I filed https://bugs.launchpad.net/evergreen/+bug/1620750 to fix the warning about uninit var but that shouldn't cause the transaction to roll back |
| 13:27 |
pinesol_green |
Launchpad bug 1620750 in Evergreen 2.10 "open-ils.circ.checkin generates a WARN log message in checkin_retarget()" [Undecided,New] |
| 13:27 |
|
bos20k_ joined #evergreen |
| 13:28 |
plux |
right….I may be fine actually as those don’t seem to be be actually breaking anything although staff have had to checkin twice on occasion |
| 13:29 |
plux |
we had a crash over labor day so I’m wondering if that is more related to closing dates and due dates as it’s actually been working since…I just noticed the db errors and was trying to resolve them |
| 13:30 |
plux |
on another note…we have a working mac client for 2.10.6 if anyone is interested |
| 13:32 |
plux |
still on the transaction errors…we’re getting more on open-ils.vandelay.stderr.log just as a point of interest |
| 13:32 |
plux |
Invalid indicator "\" forced to blankInvalid indicator "\" forced to blank |
| 13:32 |
plux |
Caught error from 'run' method: Exception: OpenSRF::DomainObject::oilsMethodException 2016-09-07T12:39:33 OpenSRF::Application /usr/local/share/perl/5.18.2/OpenSRF/Application.pm:231 <500> Error committing transaction |
| 13:33 |
plux |
that may be on our end….I haven’t dug into that yet |
| 13:33 |
plux |
OpenSRF::DomainObject::oilsMethodException 2016-09-07T12:39:33 OpenSRF::Application /usr/local/share/perl/5.18.2/OpenSRF/Application.pm:231 <500> Error committing transaction |
| 13:39 |
dbs |
That may just be the nature of the records you're importing causing MARC::Record to emit a warning message? |
| 13:41 |
dbs |
Is there a list of the indexes that go missing after a restore? I'd like to double-check our system :) |
| 13:43 |
plux |
good point….I should double check our indexes |
| 13:45 |
csharp |
plux: have you done a VACUUM ANALYZE since you restored your DB? |
| 13:47 |
csharp |
(technically, ANALYZE is all you need on a freshly pg_restore-d DB, but VACUUM doesn't hurt) |
| 13:47 |
jeff |
dbs: the two common indexes that have historically failed due to search path issues are mentioned in that irc conversation you linked the other day. |
| 13:47 |
jeff |
dbs: authority.by_heading_and_thesaurus and authority.by_heading |
| 13:48 |
csharp |
oh yeah - I remember those |
| 13:49 |
plux |
I didn’t but that’s another good point (VACUUM ANALYZE) and I’ll check those indexes. I’ll run the vacuum at night as I hate the noise |
| 13:51 |
csharp |
heh |
| 13:52 |
jeffdavis |
:) |
| 13:52 |
dbs |
jeff++ # thanks! sorry, so many quasi-random IRC conversations, some of which have questionable ramblings by the likes of me that turn out to be red herrings a day or two later |
| 13:53 |
dbs |
I hope to dump some of my upgrade experiences & (re)discovery into a blog entry, maybe into docs, if I have time... |
| 13:54 |
* jeff |
nods |
| 13:59 |
csharp |
for those with range-protected items (age-protected and A/V in PINES), how do you deal with copy/hold ratios? |
| 14:00 |
csharp |
we've found that people can no longer renew range protected items because there are holds *elsewhere* but not at the owning library (i.e. there are no holds that could be filled with the copy in hand because of range-protection) |
| 14:01 |
dbs |
hmm, just over six seconds between 17:16:58 open-ils.circ.checkin call and 17:17:05 No active transaction to commit -- plux, is that the rough difference you're seeing in the logs too |
| 14:02 |
dbs |
because the keepalive for cstore is six seconds. hrm. |
| 14:02 |
* dbs |
will get on that vacuum horse |
| 14:03 |
jeff |
csharp: while we have some libraries using age hold protection, we do not make use of copy/hold ratios. i fear that "prevent renewal when copy needed for hold" suffers from similar, though. |
| 14:03 |
jeff |
imo, if the item you are attempting to renew isn't going to be captured at checkin, you should be able to renew. :-) |
| 14:03 |
csharp |
I'm about to dig into the code |
| 14:04 |
csharp |
jeff: yeah, that's a sane standard |
| 14:04 |
JBoyer |
jeff, is that not how that setting works? We have that on here and I'd imagine there would be riots if it prevented renewals because there were holds elsewhere. |
| 14:04 |
csharp |
it must be different than the "prevent when copy needed for hold" setting because we're getting tickets on it (we moved from the YAOUS approach to hold/copy ratios) |
| 14:05 |
JBoyer |
(unless it's checking to see if the holds can *actually be filled*, which isn't likely during age protection when holds tend to be hot and heavy.) |
| 14:05 |
* jeff |
reads code as a first step to confirming/debunking his stated fear |
| 14:06 |
* dbs |
guesses "SELECT last_vacuum, COUNT(*) FROM pg_stat_user_tables GROUP BY last_vacuum;" show should something other than NULL for last_vacuum... |
| 14:07 |
csharp |
dbs: ours is null too |
| 14:07 |
csharp |
<null> | 601 |
| 14:07 |
dbs |
And only 16 tables for SELECT schemaname, relname, last_autovacuum FROM pg_stat_user_tables WHERE last_autovacuum IS NOT NULL; |
| 14:08 |
jeff |
last_vacuum is ``Last time at which this table was manually vacuumed (not counting VACUUM FULL)'' |
| 14:08 |
jeff |
per 9.4 docs |
| 14:08 |
dbs |
csharp: well that's weird |
| 14:08 |
dbs |
oh, thanks jeff |
| 14:08 |
csharp |
jeff++ |
| 14:13 |
dbs |
happily there are some recent entries for last_autoanalyze, but I'll focus on analyzing for now |
| 14:13 |
dbs |
gotta get good plans! |
| 14:15 |
jeff |
dbs: https://youtu.be/FPQlXNH36mI |
| 14:15 |
|
Dyrcona joined #evergreen |
| 14:33 |
csharp |
my investigation has yielded the following: if the "Block Renewal of Items Needed for Holds" setting is set, the perl layer checks for the nearest *permitted* hold, and if it finds any at all, it returns COPY_NEEDED_FOR_HOLD and drops dead |
| 14:34 |
csharp |
so if the in-db circ rules knew/cared about *permitted* holds, that would solve our problem |
| 14:34 |
jeff |
so that probably means that until just recently some of those renewals might fail because the permit hold checks timed out. ;-) |
| 14:35 |
jeff |
(since fixed, I believe) |
| 14:35 |
csharp |
ooh - I never considered that |
| 14:37 |
dbs |
tell me more about this "since fixed" :) |
| 14:45 |
miker |
csharp: one way of looking at the problem is that the input to the circ ratio check comes from ahm, which contains copies that may be "too far away" today, but won't be tomorrow (to support running the retargetter less often). if we increase the cost of hold targetting by checking transit distance restrictions per copy (not necessarily a bad thing -- targetting's set to get much faster in the future), and accept the "slush" of retargetting interval in |
| 14:45 |
miker |
the time-based distance restrictions, then the ratio would be able to act how you are wanting |
| 14:49 |
csharp |
miker: thanks - I'll think on that |
| 14:50 |
csharp |
Terran's working up a bug report, I think |
| 14:53 |
* dbs |
holds head in hands as staff clients start timing out when just trying to log in |
| 14:53 |
csharp |
that's what happened to us |
| 14:53 |
csharp |
on 2.9 |
| 14:54 |
Dyrcona |
Well, that's nice. I'm rebasing a branch. I resolved conflicts. I did git add . then git rebase --continue and git says nothing to commit do git rebase --continue.... |
| 14:55 |
csharp |
dbs: we installed pg_badger, which helped us identify long queries (though when everything gets slow, it's near impossible to tell symptoms from causes) :-/ |
| 14:55 |
* dbs |
greedily awaits the details on how csharp overcame that particular issue |
| 14:55 |
dbs |
aha |
| 14:55 |
csharp |
tuning postgres helped too |
| 14:55 |
dbs |
open-ils.actor.user.has_work_perm_at.batch this time around. |
| 14:56 |
Dyrcona |
Ok. and after git rebase --abort I get a lovely message about my branch having diverged from the source branch. |
| 14:56 |
csharp |
but as miker said in the thread I linked to earlier, it's very site-dependent about what needs tuning |
| 14:56 |
csharp |
I wonder if 9.1 might be "too old" |
| 14:57 |
csharp |
(which would be the opposite problem that we faced - 9.4 was "too new") |
| 15:01 |
dbs |
yeah, I spent way too much time over the years doing postgresql tuning, our hosts have been the tuners for the past couple of years and that's worked fine |
| 15:01 |
dbs |
but now? heh. |
| 15:01 |
dbs |
we'll see |
| 15:02 |
csharp |
ah |
| 15:03 |
Dyrcona |
hmm.. a merge seemed to work.... |
| 15:04 |
|
maryj joined #evergreen |
| 15:05 |
csharp |
dbs: you might look at kernel memory settings along with PG settings - in the end, I think the most important factor for us was disabling transparent huge pages and reducing shared buffers |
| 15:05 |
csharp |
but that was 9.4 |
| 15:06 |
dbs |
csharp: I have no access to that now. Definitely did those in the old days. |
| 15:07 |
csharp |
gotcha |
| 15:08 |
dbs |
(Our hosts also host Sitka, so we're in very good hands) |
| 15:08 |
csharp |
oh good |
| 15:09 |
dbwells |
dbs: I haven't followed along very carefully, but for performance issues after an Ubuntu 14.04 upgrade, I'd look at this thread: https://www.mail-archive.com/open-ils-general@list.georgialibraries.org/msg12066.html Part of that thread is a bug I posted (#1527731) about how we had to up our join_collapse_limit to get decent performance. The rest is more steps miker took to help with PINES. |
| 15:10 |
dbs |
thanks dbwells |
| 15:10 |
dbwells |
Well, not necessary Ubuntu 14.04, but anything with newish Perl. |
| 15:20 |
dbs |
hmm, no "No active transaction to commit" messages since running ANALYZE one hour ago |
| 15:36 |
* dbs |
wonders how many other sites run with HTTPS for everything |
| 15:36 |
jeffdavis |
define "everything" :) |
| 15:37 |
jeffdavis |
Sitka forces HTTPS on all Evergreen traffic except for one or two places where doing so breaks stuff, like a piece of offline transaction upload |
| 15:37 |
dbs |
heh, okay. Start with the commented out lines at the bottom of eg_vhost.conf that redirects any HTTP request to HTTPS |
| 15:38 |
dbs |
And then stuff like Header always set Strict-Transport-Security "max-age=15768000" ? |
| 15:39 |
Dyrcona |
Asciidoc makes cleaning up conflicts just a little bit harder. |
| 15:39 |
pinesol_green |
[evergreen|Bill Erickson] LP#1413352 Brief record price sets lineitem price - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=58e107f> |
| 15:39 |
jeffdavis |
looks like the other exception we make is not forcing HTTPS on /opac/extras/sru since yaz/simple2zoom can't handle it (which probably sounds familiar to you, dbs :) |
| 15:40 |
jeffdavis |
I found this info by grepping for "stupid crap" in our puppet config :D |
| 15:40 |
jeffdavis |
our old sysadmin was not happy to have to make exceptions |
| 15:41 |
pinesol_green |
[evergreen|Galen Charlton] LP#1436987: webstaff - fix patron search form - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ee71196> |
| 15:41 |
dbs |
and SSLUseStapling on? |
| 15:42 |
dbs |
jeff: yaz4 can't handle HTTPS on Ubuntu14.04, yeah |
| 15:42 |
dbs |
*real* familiar :) |
| 15:42 |
dbs |
he was a good sysadmin too! |
| 15:45 |
jeffdavis |
yep, as is our current one - we've been lucky |
| 15:46 |
jeffdavis |
we also require SNI, which IIRC was our excuse to officially stop supporting some old browsers |
| 15:48 |
jeffdavis |
not sure about Strict-Transport-Security, SSLUseStapling etc |
| 15:52 |
dbs |
I think we're basically using the Intermediate Apache 2.4.18 version generated at https://mozilla.github.io/server-side-tls/ssl-config-generator/ |
| 15:53 |
dbs |
Hey weren't we supposed to have a developer meeting at 3:00 PM Eastern? |
| 15:58 |
miker |
dbs: heh ... I /just/ noticed that, too... |
| 15:59 |
dbs |
well there's been lots of sysadmin /developer talk so that's good |
| 15:59 |
* tsbere |
thinks his watch was bugging him about that when he was away from his desk, but then he forgot about it |
| 15:59 |
* JBoyer |
keeps not having it on his calendar. :( |
| 16:00 |
JBoyer |
Not that I' |
| 16:00 |
JBoyer |
d be a good one to run it, so more people remembering would be ideal. ;) |
| 16:00 |
tsbere |
JBoyer: My watch told me because my google account knows about a community calendar that shows it |
| 16:01 |
JBoyer |
Oh, yeah. I suppose I could subscribe to that. |
| 16:02 |
* dbs |
does that |
| 16:02 |
Dyrcona |
I have the calendar in Thunderbird. |
| 16:02 |
Dyrcona |
I didn't pay attention to it today. |
| 16:04 |
jeff |
so nice that both links to the NCIP v 1.01 schema on ncip.info are 404 |
| 16:05 |
jeff |
woo. guessed a working url. |
| 16:05 |
Dyrcona |
I was about to say that I might have copies of the PDFs hanging around. |
| 16:06 |
Dyrcona |
I think I have 1.01 and 2.01. |
| 16:06 |
kmlussier |
Maybe we should follow the DIG model and have somebody who takes on the responsibility of sending out advance meeting notices like yboston does for DIG. |
| 16:06 |
dbs |
With a link to the agenda and everything!?! |
| 16:07 |
kmlussier |
dbs: Wow! Let's not get too crazy with these ideas! ;) |
| 16:11 |
rhamby |
kmlussier: are you volunteering? |
| 16:11 |
* rhamby |
exists stage left |
| 16:12 |
kmlussier |
rhamby: I think I've already done that job. |
| 16:13 |
rhamby |
kmlussier: so you're saying you're qualified? |
| 16:13 |
Dyrcona |
heh |
| 16:24 |
* dbs |
also wonders if anyone is using webby in 2.10 - I've mentioned it as a "pure beta, YMMV" thing to a few people here who seem to be suffering XUL-related sluggishness |
| 16:25 |
kmlussier |
dbs: I think the MOBIUS folks have been using webby in production - I don't know what release they're on. |
| 16:26 |
kmlussier |
JBoyer: Are some of your libraries using the web client in production? |
| 16:29 |
* jeff |
uses csplit to turn a few hundred megabyte file into a few hundred thousand files worth of sometimes-xml |
| 16:32 |
jeff |
(deprecated -- for current [information], see the [link to new thing]) -- where said link to new thing is a page that is empty save for a "powered by" graphic/link. |
| 16:33 |
jeff |
alas, not the first time i've run into this specific deadend. |
| 16:33 |
dbs |
"Powered by a Professional Organization of Heritage Preservation Institutions" |
| 16:33 |
jeff |
the other, "deprecated" link is of course 404 (with a different powered by ad) |
| 16:35 |
jeff |
broken link, broken link, document management system with spam from 2010... |
| 16:42 |
bshum |
For fun, I just noticed that we haven't updated the version statement in the README that goes "Evergreen 2.8 has been tested on ...." (insert various Linux flavors). I'm thinking either to toss out some commits to fix that in all the rel_2_x branches and give master the coming 2.11 (so that future branching and updates get a better number) or that we remove the version entirely. Thoughts? |
| 16:43 |
bshum |
I think it could work too with just plain "Evergreen has been tested on ..." various OS |
| 16:47 |
dbs |
yeah, looks like it escaped the version numbers to bump part of https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
| 16:47 |
* dbs |
looks at the short-lived https://wiki.evergreen-ils.org/doku.php?id=dev:evergreen:release_checklist |
| 16:48 |
dbs |
but I agree with dropping the version entirely there |
| 16:49 |
dbs |
huh, "relation "browse_entry" page 54392 is uninitialized --- fixing", not seen that before during a VACUUM |
| 16:49 |
* bshum |
guesses we use the version for both the README and upgrade instructions too |
| 16:52 |
jeff |
dbs: db server crash recently? |
| 16:52 |
jeff |
(since your last vacuum of similar type?) |
| 16:53 |
dbs |
might have been a 'service postgresql reload' during the vacuum |
| 16:53 |
dbs |
not aware of any db server crashes though |
| 17:00 |
dbs |
What's the suggested approach to dealing with functions that are duplicated across public and evergreen schemas? |
| 17:01 |
* dbs |
is staring glumly at the results of 'SELECT proname, proargmodes, proargnames, COUNT(*) FROM pg_proc GROUP BY proname, proargmodes, proargnames HAVING COUNT(*) = 2;' |
| 17:06 |
dbs |
actually, swapping proargtypes instead of proargmodes, just down to 8 duped functions |
| 17:06 |
jeff |
8 here also. |
| 17:07 |
jeff |
{flatten_marc,oils_xpath_table,maintain_control_numbers,regexp_split_to_array,indexing_ingest_or_delete,stat_cat_check,xml_is_well_formed,lowercase} |
| 17:09 |
jeff |
still only 8 when i expand the criteria to HAVING COUNT(*) > 1 |
| 17:09 |
jeff |
:-) |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
jeff |
some of those appear to be acceptable. |
| 17:11 |
jeff |
actor.stat_cat_check and asset.stat_cat_check seem normal. |
| 17:13 |
dbs |
good good |
| 17:35 |
* csharp |
has 7 of jeff's 8 (missing oils_xpath_table) |
| 17:36 |
csharp |
(from the list of dupes, not from the DB) |
| 17:38 |
jeffdavis |
we have 45 dupe functions according to that query, so I think we win |
| 18:09 |
|
jvwoolf left #evergreen |
| 23:35 |
jeff |
again, some of those are not problematic. |
| 23:35 |
jeff |
...but i think jeffdavis does win. :-) |
| 23:38 |
|
bmills joined #evergreen |
