Time |
Nick |
Message |
01:29 |
|
Mark__T joined #evergreen |
06:05 |
|
tsbere joined #evergreen |
07:47 |
|
rjackson_isl joined #evergreen |
07:48 |
|
rlefaive joined #evergreen |
08:06 |
|
ericar joined #evergreen |
08:28 |
|
mrpeters joined #evergreen |
08:46 |
|
mmorgan joined #evergreen |
08:50 |
|
Dyrcona joined #evergreen |
09:09 |
|
Shae joined #evergreen |
09:17 |
kmlussier |
Good morning #evergreen |
09:19 |
mmorgan |
Good morning! |
09:23 |
Dyrcona |
Mornin'. |
09:31 |
|
yboston joined #evergreen |
09:35 |
dbs |
In case y'all have not yet upgraded to OpenSSH 7, note that DSA keys are no longer permitted by default on the client side. |
09:35 |
dbs |
You can work around this by adding "PubKeyAcceptedTypes +ssh-dss" to your .ssh/config file in the short term, but long term probably best to ensure you're using RSA |
09:37 |
dbs |
Only 21 ssh-dss keys in the Evergreen git keydir repo, so that's not bad for gitadmins in the future |
09:40 |
yboston |
dbs++ |
09:41 |
tsbere |
They also plan on making the minimum rsa key size larger in the future, so if you are making new rsa keys I would recommend going at least 1024 bits. |
09:43 |
jeff |
if you have a dsa key or an rsa key smaller than 2048 bits, it's probably past time for you to rotate keys. |
09:44 |
* tsbere |
has run into a couple of situations where he couldn't go above 1024 bits due to client limitations, though that was usually weird clients in the first placea |
09:44 |
tsbere |
and I don't know where the extra a came from. :/ |
09:45 |
|
RoganH joined #evergreen |
09:54 |
RoganH |
kmlussier gmcharlt - I added the 2016 conference to the menu on the front of the website but didn't take the 2015 off. I thought it would be nice to have the upcoming and the past one but I'll take 2015 off if that's the general opinion. |
09:54 |
gmcharlt |
RoganH: I'm all for keeping past conferences list on the website |
09:56 |
kmlussier |
RoganH: You're referring specifically to the menu, right? I have no objections to keeping the immediate past conference there. |
09:58 |
RoganH |
kmlussier: yes, the menu |
09:58 |
RoganH |
OK, I'll leave it be and move on to things of less immediate productivity. |
09:59 |
kmlussier |
RoganH++ |
10:07 |
kmlussier |
Happy National Coffee Day y'all! |
10:07 |
dbs |
24 1024-bit keys, 131 2048-bit keys |
10:07 |
kmlussier |
@coffee [someone] |
10:07 |
* pinesol_green |
brews and pours a cup of Sumatra Golden Mandheling, and sends it sliding down the bar to Bmagic |
10:07 |
dbs |
4 1023-bit keys(!) |
10:07 |
dbs |
5 4096-bit keys (bravo) |
10:08 |
dbs |
and a 3000-bit key, to be completely different |
10:19 |
Bmagic |
@pinesol_green thanks! |
10:19 |
pinesol_green |
Bmagic: MARC still isn't dead yet, alas |
10:28 |
|
RoganH joined #evergreen |
10:28 |
RoganH |
@hate acquisitions |
10:28 |
pinesol_green |
RoganH: But RoganH already hates acquisitions! |
10:29 |
RoganH |
@hate acquisitions_with_a_pervasive_enduring_hatred |
10:29 |
pinesol_green |
RoganH: The operation succeeded. RoganH hates acquisitions_with_a_pervasive_enduring_hatred. |
10:44 |
csharp |
is anyone on 2.9-ish able to test if Offline Transaction Management is busted for them as well? |
10:44 |
csharp |
in my case, I enter the interface and get a skull and crossbones error |
10:45 |
csharp |
http://pastebin.com/YUtuEBGj |
10:46 |
phasefx |
csharp: check your offline-config.pl file? |
10:46 |
csharp |
lemme look |
10:47 |
csharp |
phasefx: it looks right to me |
10:49 |
csharp |
OS-level ownership and perms look correct (this is an NFS share) |
10:49 |
phasefx |
csharp: try appending this to your hostname and putting in a valid authtoken: /cgi-bin/offline/offline.pl?ses=authtoken&action=status&org=4&status_type=sessions |
10:50 |
phasefx |
and a valid org id |
10:51 |
csharp |
phasefx: in my case, that downloaded offline.pl |
10:52 |
phasefx |
for comparison, http://phasefx.evergreencatalog.com/cgi-bin/offline/offline.pl?ses=3ee28713658d0c9ecbbfe1c9178abb42&action=status&org=4&status_type=sessions |
10:52 |
csharp |
huh |
10:52 |
csharp |
so CGI may be busted? |
10:52 |
phasefx |
seems like it |
10:53 |
phasefx |
a bad offline-config.pl would give you an internal server error |
10:53 |
csharp |
okay - thanks - thanks something to go on |
10:53 |
csharp |
yeah - I didn't expect it to download the pl file |
10:53 |
dbs |
yeah, check for <Directory "/openils/var/cgi-bin/offline"> in your apache config |
10:53 |
csharp |
this is our transition to Apache 2.4 - it's possible something didn't make it over |
10:53 |
jeff |
"expected json, received perl." |
10:54 |
Dyrcona |
csharp: We're using 2.4 with no problems. |
10:54 |
dbs |
ah, could be lingering 2.2-isms, that would make sense |
10:54 |
csharp |
Dyrcona: yeah, I think it's probably at the GenaSYS level (which copies apache config into place from templates managed outside the normal EG install) |
10:55 |
Dyrcona |
If it is downloading the .pl rather than executing it, that points to no execute bit or a bad configuration missing ExecCGI on the location or directory. |
11:00 |
csharp |
they're all mode 755, which matches our production setup, so I don't this it's that - gonna work on ruling out apache |
11:00 |
csharp |
thanks for everyone's suggestions ;-) |
11:03 |
csharp |
aha - mod_cgi isn't enabled |
11:03 |
csharp |
that would do it ;-) |
11:04 |
Dyrcona |
heh. |
11:10 |
jeff |
i'm surprised that you didn't throw syntax errors having a config that uses directives from a module that isn't loaded. |
11:11 |
csharp |
me too, actually |
11:12 |
csharp |
funnily enough, we're getting a warning of overlapping alias declarations now that it is enabled |
11:22 |
|
Christineb joined #evergreen |
11:39 |
csharp |
well, even after I enable cgi, it's still failing to work, because it's looking in /usr/lib/cgi-bin rather than /openils/var/cgi-bin |
11:40 |
csharp |
and it's because of the new conf-available feature's cgi configuration, which aliases cgi-bin to /usr/lib/cgi-bin |
11:40 |
csharp |
so now I'm surprised no one else has hit this issue |
11:40 |
Dyrcona |
csharp: Debian? |
11:41 |
csharp |
Ubuntu 14.04 |
11:41 |
csharp |
here's the opensrf log message: script not found or unable to stat: /usr/lib/cgi-bin/offline |
11:41 |
Dyrcona |
We're on 14.04 and don't have that problem. |
11:41 |
csharp |
weird |
11:41 |
Dyrcona |
Never did as far as I know. |
11:42 |
csharp |
The Alias directive in /etc/apache2/sites-enabled/eg.conf at line 55 will probably never match because it overlaps an earlier ScriptAlias. |
11:43 |
Dyrcona |
Oh, that. Kill the earlier one. |
11:43 |
csharp |
the earlier ScriptAlias is in /etc/apache2/conf-available/serve-cgi-bin.conf |
11:44 |
Dyrcona |
We didn't enable that conf. |
11:44 |
csharp |
all I did was "a2enmod cgi" |
11:44 |
csharp |
and that came along with it as far as I can tell |
11:44 |
Dyrcona |
yeah. that enables it. |
11:45 |
csharp |
isn't that what Makefile.install does? |
11:45 |
Dyrcona |
I don't think so. |
11:46 |
csharp |
for m in $(DEB_APACHE_MODS); do a2enmod $$m; done; |
11:47 |
Dyrcona |
export DEB_APACHE_DISCONF = \ |
11:47 |
Dyrcona |
serve-cgi-bin |
11:47 |
csharp |
oh.... |
11:48 |
csharp |
I see that now |
11:48 |
Dyrcona |
Makefile.install enables cgi, then disables the conf on Trusty. |
11:48 |
csharp |
okay - thanks - that's exactly what I needed to know |
11:48 |
Dyrcona |
a2disconf |
11:48 |
Dyrcona |
cool. |
11:50 |
Dyrcona |
For those following along: a2disconf serve-cgi-bin |
11:50 |
csharp |
Dyrcona++ |
11:51 |
csharp |
that was all it needed |
11:51 |
Dyrcona |
Cool. |
12:01 |
|
kitteh_ joined #evergreen |
12:08 |
|
jihpringle joined #evergreen |
12:29 |
|
bmills joined #evergreen |
12:49 |
|
gdunbar joined #evergreen |
13:36 |
|
Shae joined #evergreen |
13:52 |
|
ericar_ joined #evergreen |
14:19 |
berick |
i'm doing some research for bug #838525. anyone else seeing lots of DoB's with the hour set to 23 in their databases? select count(*), date_part('hour', dob) from actor.usr group by 2; |
14:19 |
pinesol_green |
Launchpad bug 838525 in Evergreen "Timestamp on dob can make date appear off by a day" [Medium,Confirmed] https://launchpad.net/bugs/838525 |
14:24 |
jeff |
in order of frequency, we have: {12,0,4,NULL,23,3,1,2,5} |
14:27 |
jeff |
if i add max(create_date) i see that so far this month we've only had 23, 0, and 1 (and null, of course) |
14:28 |
jeff |
if i had to guess why we had a 23 yesterday and a 0 today i'd say that it might be a quick of how we stage users. have to dig further. |
14:28 |
jeff |
sure would be swell if we didn't store a timestamp or timezone for dob... ;-) |
14:28 |
jeff |
(which i realize is one of the possibilities suggested in that bug) |
14:30 |
berick |
ok, glad it's not just us :) i think this happens when you set a dob to a date on the other side of the daylight savinngs boundry, using an EDT timezone. |
14:30 |
jeff |
hrm. might not be anything specific to us, there. staging.user_stage.dob is text. |
14:31 |
jeff |
and in our environment, contains a YYYY-MM-DD formatted value |
14:36 |
Bmagic |
Has anyone put work into software to reveal a list of bibs that do not have an image in memcache? |
14:37 |
|
DPearl1 joined #evergreen |
14:37 |
jeff |
Bmagic: what are you attempting to accomplish? |
14:37 |
|
rlefaive joined #evergreen |
14:38 |
Bmagic |
I have often thought about book jacket images and how to get better coverage in the catalog. It seems like a quick rearrangment of marc 020 or 024's could get the jacket to show. We are using syndetics |
14:40 |
jeff |
Bmagic: we use a bit of javascript in the catalog to report the record IDs that don't load an image at display time. Based on that, we generally add a local image rather than try to edit the MARC. |
14:41 |
Dyrcona |
berick: We have an of magnitude less for 23 than for 0 and NULL, but still significant. |
14:42 |
jeff |
Syndetics doesn't support passing multiple values for a given key (last I looked), which would be great. Are you trying to gather data to determine if being more persistent would help, or are you already pretty sure based on some preliminary data that it would help? |
14:54 |
Bmagic |
jeff: We have lots of bibs without images. In some cases, I can rearrange the 020's in the marc and the images show up because of the key situation that you mentioned |
14:55 |
Bmagic |
so, I was thinking there could be software to spider the bibs and find those without a memcached image, then attempt to query syndetics for the image with a different key, and change the marc when another key has a positive result |
15:15 |
|
ericar_ joined #evergreen |
15:16 |
|
jboyer-isl joined #evergreen |
15:18 |
tsbere |
berick: https://bugs.launchpad.net/evergreen/+bug/838525/comments/13 |
15:18 |
pinesol_green |
Launchpad bug 838525 in Evergreen "Timestamp on dob can make date appear off by a day" [Medium,Confirmed] |
15:25 |
berick |
tsbere: i like the simplicity of it. '12 hours' would push patrons whose hour is already set to twelve into the next day, though. jeff seems to have a lot of those. we have a few too. (no idea how). |
15:25 |
berick |
maybe just + '1 hour' ? |
15:27 |
tsbere |
berick: I just went with 12 hours because I have done similar tricks for reports in the past and I basically copied one of them. Perhaps for a wider buffer 3 or 6 hours would be better, though? |
15:27 |
jeff |
Bmagic: we went with our approach because it prioritized those images which were actively being NOT displayed to patrons. :-) |
15:30 |
jeff |
Bmagic: If you wanted to enumerate all bibs with 020/024 values, I'd suggest skipping the memcached step and just request the image and determine if you get a 404 or a 1x1 payload. |
15:31 |
jeff |
And use those records as your hit list. Doesn't give you any idea of how often they're (not) appearing in results, but it meets your original desire of getting them all. |
15:33 |
Bmagic |
I see, that sounds like a good plan. I take it no body has worked in this area? I'm not reinventing a wheel |
15:34 |
tsbere |
We moved to Content Cafe instead, and I re-wrote that module to send all the supported identifiers at once instead (as they support doing so) |
15:35 |
jeff |
Depending on your bibs and memory allocated to memcached and your current memcached instance's slab allocation, you might push non-expired data from memcached before its usual TTL. Potentially things like sessions. Be aware. :-) |
15:37 |
berick |
tsbere: yeah, 3 or 6 is probably sane. i'd lean toward 3. |
15:41 |
csharp |
so do most sites go live after an upgrade before bib reingests are done, or do you wait? |
15:41 |
csharp |
I'm considering shooting for an overnight upgrade and being up and running while the reingest runs |
15:41 |
tsbere |
csharp: Depends on the reason for the reingest |
15:42 |
tsbere |
The more broken I expect things to be without it the more likely I am to want it to finish first |
15:42 |
* csharp |
has not investigated why we need a reingest for 2.8 |
15:43 |
jeff |
i believe we've gone 'live' post-upgrade with a partial (just what MUST be reingested) while the full runs in the background. the ability to do this may vary between what you're upgrading from/to, but with the newer support for selective/partial reingest will likely help there. |
15:43 |
csharp |
our test server is currently in an "upgraded from 2.7 to 2.9 but not yet reingested" state and I'm asking our staff to experiment with searching |
15:43 |
csharp |
pretty sure it's just a partial reingest that's required |
15:46 |
csharp |
actually it's 2.7.2-2.7.3 that requires the reingest |
15:48 |
csharp |
apparently 0904.schema.allow_spaces_as_ff_attr_values.sql |
15:49 |
csharp |
bug 1414112 |
15:49 |
pinesol_green |
Launchpad bug 1414112 in Evergreen 2.7 "Audience filter no longer searching blank spaces" [Medium,Fix released] https://launchpad.net/bugs/1414112 |
15:54 |
csharp |
hmm - miker's comments on the bug report make it seem that a reingest is not required... |
15:54 |
csharp |
gmcharlt: any thoughts on this?^^ |
16:01 |
csharp |
it actually appears that we applied that improvement with miker's reingest-free approach earlier this year |
16:01 |
csharp |
I don't see any other upgrade script in 2.7.2-2.7.3 that would require a reingest |
16:08 |
* csharp |
listens to the lovely crickets ;-) |
16:08 |
gmcharlt |
*chirp* |
16:09 |
Dyrcona |
csharp: There appear to be no reingests required for 2.9. |
16:09 |
jeff |
csharp: just clone your db, reingest the clone, and diff the pg_dump output! ;-) |
16:09 |
jeffdavis |
csharp: We didn't reingest when we upgraded 2.6->2.8. No reingest-related issues reported so far. |
16:10 |
csharp |
thanks to all for your responses - that helps! |
16:10 |
csharp |
jeff: that's a thought |
16:10 |
jeff |
csharp: please do not take it as a serious suggestion. :-) |
16:11 |
gmcharlt |
csharp: there would be a strictly optional attribute reingest one could do for 0938 |
16:11 |
csharp |
gmcharlt: thanks |
16:12 |
gmcharlt |
but emphasis is very much on the optional, as the experimental stuff is of no practical import at the moment unless one of your users has a hankier to report on the RDA content, carrier, and media code usage without having to query mfr |
16:12 |
gmcharlt |
*hankering |
16:13 |
csharp |
I think we'll wait on that then ;-) |
16:13 |
gmcharlt |
your WAL archive thanks you! ;) |
16:13 |
csharp |
wow - then this might be the briefest upgrade window we've had in a while! |
16:13 |
csharp |
gmcharlt: ha! |
16:13 |
csharp |
jeff: :-D |
16:14 |
Dyrcona |
csharp: 0905 and 0942 can run a long time. |
16:14 |
gmcharlt |
csharp: well, "select pg_sleep(3600);" is always an optional if it's running too quickly for you ;) |
16:14 |
Dyrcona |
but not as long as a reingest. |
16:20 |
|
jlitrell joined #evergreen |
16:20 |
jeff |
perhaps select pg_sleep(2 * (select count(*) from biblio.record_entry)); |
16:26 |
miker |
or if you have SSD, select pg_sleep(0.5 * (select count(*) from biblio.record_entry)); |
16:26 |
miker |
;) |
16:28 |
jeff |
heh |
17:25 |
|
mmorgan left #evergreen |
17:31 |
|
kitteh_ joined #evergreen |
17:36 |
kmlussier |
I like the "new decade takes flight" bit on the logo for the 2016 conference. |
19:32 |
|
eady joined #evergreen |
19:32 |
|
ldw_ joined #evergreen |
19:51 |
|
jihpringle joined #evergreen |
20:49 |
|
pmurray_away joined #evergreen |
20:49 |
|
pmurray joined #evergreen |
20:49 |
|
pmurray left #evergreen |