IRC log for #koha, 2013-02-16

All times shown according to UTC.

Time S Nick Message
00:02 edveal left #koha
00:04 rambutan left #koha
00:21 asaurat left #koha
01:59 fredericd joined #koha
01:59 qu-bit_ joined #koha
01:59 tsbere joined #koha
01:59 clrh joined #koha
01:59 alohalog` joined #koha
01:59 phasefx joined #koha
01:59 dracoling joined #koha
01:59 magnuse joined #koha
01:59 mtj joined #koha
01:59 janPasi joined #koha
01:59 jcamins joined #koha
01:59 chris_n joined #koha
01:59 Callender joined #koha
01:59 bshum joined #koha
01:59 matts_away joined #koha
01:59 pastebot joined #koha
01:59 alohabot joined #koha
01:59 huginn joined #koha
05:13 rangi evening
05:34 appu1984 joined #koha
05:36 appu1984 message displayed when checkout 'Local Use Recorded'. cant check out . how to clear this, please
05:37 rangi what version of koha appu1984 ?
05:37 rangi ok then
05:38 appu1984 joined #koha
05:51 jenkins_koha Starting build #65 for job Koha_3.10.x (previous build: SUCCESS)
05:52 appu1984 joined #koha
06:06 mtj hey chrissa ->[…]-Tour-video-diary
06:07 mtj this is seriously funny!
06:31 jenkins_koha Project Koha_3.10.x build #65: SUCCESS in 40 min: http://jenkins.koha-community.[…]b/Koha_3.10.x/65/
06:31 jenkins_koha * Colin Campbell: Bug 9454: Use placeholders when adding basket
06:31 jenkins_koha * Jared Camins-Esakov: Bug 7608: Manual history should not always be enabled
06:31 jenkins_koha * Robin Sheat: Bug 9592 - update dependencies, allow blacklisting
06:31 huginn Bug[…]w_bug.cgi?id=9454 major, P5 - low, ---, colin.campbell, Pushed to Stable , NewBasket does not use placeholders in sql
06:31 huginn Bug[…]w_bug.cgi?id=7608 normal, P5 - low, ---, jcamins, Pushed to Stable , Manual history is always 'enabled'
06:31 huginn Bug[…]w_bug.cgi?id=9592 minor, P3, ---, robin, Pushed to Master , Package dependency updates for master
06:53 qu-bit joined #koha
07:06 jenkins_koha Starting build #66 for job Koha_3.10.x (previous build: SUCCESS)
07:11 rangi lol i had registered koha with openhatch 2 years ago and forgot about it
07:18 rangi or mtj set it up and i updated it then we both forgot :)
07:19 cait joined #koha
07:20 koyauni joined #koha
07:36 sophie_m joined #koha
07:46 jenkins_koha Project Koha_3.10.x build #66: SUCCESS in 40 min: http://jenkins.koha-community.[…]b/Koha_3.10.x/66/
07:46 jenkins_koha Fridolyn SOMERS: Bug 9226: Wrong branch filter after suggestion creation
07:46 huginn Bug[…]w_bug.cgi?id=9226 minor, P5 - low, ---, fridolyn.somers, Pushed to Stable , Wrong branch filter after suggestion creation
07:46 jenkins_koha Starting build #274 for job Koha_3.8.x (previous build: SUCCESS)
08:17 drojf joined #koha
08:21 drojf joined #koha
08:21 drojf good morning #koha
08:22 rangi hi drojf
08:22 drojf hey rangi
08:23 drojf +1°C, birds are going crazy on my balcony :D
08:23 cait hi rangi and drojf :)
08:23 drojf hi cait
08:24 jenkins_koha Project Koha_3.8.x build #274: SUCCESS in 37 min: http://jenkins.koha-community.[…]b/Koha_3.8.x/274/
08:24 jenkins_koha Fridolyn SOMERS: Bug 9226: Wrong branch filter after suggestion creation
08:24 huginn Bug[…]w_bug.cgi?id=9226 minor, P5 - low, ---, fridolyn.somers, Pushed to Stable , Wrong branch filter after suggestion creation
08:54 rangi if they dont haee bibnumbers in the marc, you cant just add the tags back and expect it to fix itself, they are gonna have to do a bunch of stuff
08:54 rangi it sounds like a total mess
08:55 drojf a bunch of stuff as in "set up a new instance"
08:55 rangi hmm given how long it took to do the first one
08:55 rangi i cant see that happening
08:56 rangi they'd have to write a script to run through every biblioitem row
08:56 rangi and fix the marcxml and marc
09:10 cait left #koha
09:15 cait joined #koha
09:36 amb joined #koha
09:36 amb greetings
09:37 amb i've just setup koha, and am playing around with it
09:37 amb one of the people accessing the staff site is experiencing this error: "IP address has changed, please log in again"
09:39 amb i guess it's because she is on a flaky network connection
09:40 amb but can i disable the ip address check somehow?
09:47 francharb joined #koha
09:47 francharb hi
09:48 cait amb: sorry no, it's a security thing
09:49 amb i'm looking at /usr/share/koha/lib/C4/lib/
09:49 cait hm yeah maybe in the code you can, but not sure how or where
09:49 amb there are a couple of lines with " # IP address changed"
09:50 amb i guess this is where i could change the behavior
09:53 drojf amb: i think i would rather look into the connection problem first and see if that can be fixed
09:53 amb drojf: i agree, i wish i could solve the problem at the client side, but they are an NGO with poor Internet connectivity
09:54 amb I don't think there' much I can do to change that
09:54 amb I need to be able to support flaky or rapidly-changing DHCP addresses at koha-side
09:55 drojf maybe you could make them go through a vpn and assign fixed ip addresses to them
09:55 drojf don't know if that would work, just a thought
09:56 amb hmmm
09:57 amb If they go through a VPN, will that guarantee a fixed public IP address?
09:59 drojf i think you can do that in openvpn configuration, on a per client basis
09:59 amb cool, I'll give that a shot
10:00 drojf good luck :)
10:00 amb sorry for the n00b question, but does restarting Apache2 also restart Koha?
10:01 amb I mean, I've changed /usr/share/koha/lib/C4/lib/ will restarting Apache2 bring these changes into effect?
10:01 cait I think it should take effect immediately
10:01 cait you can't really restart koha
10:01 cait maybe need to clear your cache/cookie
10:01 cait s
10:02 amb okay... zebrasrv is running as a separate demon... that has nothing to do with my changes, right?
10:02 amb *daemon
10:07 drojf it shouldn't, zebra is just for indexing the records
10:07 TJGom joined #koha
10:07 amb great
10:08 amb btw, i'm new to open source and licensing and GPLv3 etc... so if I'm running a modified version of /usr/share/koha/lib/C4/lib/ is that permitted?
10:08 drojf sure
10:09 amb oh ok :)
10:09 * amb breathes a sigh of relief
10:09 drojf :)
10:09 drojf the problem is
10:09 drojf you will have trouble with upgrades
10:09 drojf if you do local changes
10:11 amb i understand... it may break on upgrade, and then it's basically my responsibility to fix it
10:11 cait you got it :)
10:11 drojf in the long run, the easiest way to maintain changes is to generalize your change so others might be able to use it, make it optional (with a syspref) and submit a patch to bugzilla
10:11 amb since i made the unsupported change in the first place
10:12 drojf not sure if that is applicable here if it opens a security problem. i'm not sure of the implications of disableing the ip check
10:13 * amb nods
10:14 drojf if you consider doing a patch it would probably be best in this case to ask about it on the developer mailing list first to see what people think about it
10:17 amb cool
10:18 drojf are you running koha froma package installation?
10:21 amb yes, from the ubuntu packages
10:29 qu-bit_ joined #koha
10:29 drojf what some people do to maintain local changes is create their own packages. if you have not worked with git before it will take some time to learn how to do that though
10:46 amb i see
10:47 amb well, my changes to don't seem to have helped... the client is still having the same problem
10:47 amb its weird... my apache logs show connections over two ip addresses from her computer:
10:52 amb just spoke to the network admin... he says this is deliberate
10:52 drojf amb: have you done a whois on the ips? those are two different provider's address ranges. it seems unlikely that a bad connection would switch between ISPs?!
10:52 amb they have two ISPs and the public IP can unpredictably change from one to the other depending upon load
10:52 drojf ah!
10:52 drojf interesting
10:52 wahanui i heard interesting was sometimes good and sometimes bad
10:53 amb so this is definitely a use-case that I (and perhaps Koha too) should support
10:53 rangi no
10:53 rangi because there is no way to tell its the same person, or if someone has stolen their cookie
10:53 drojf i still think you should look into the vpn option
10:54 amb rangi: true, but there should be a way to whitelist certain "good" or trusted IP addresses
10:54 amb because i think the client's network setup is perfectly valid
10:55 rangi if it switches continuosly there is something wrong
10:55 rangi if it only switches occassionally, they just have to relogin occassionally
10:55 amb rangi, it's currently being a bit too erratic, it usually isn't... the public IP is usually much "stickier" to one ISP
10:56 rangi yep so theres the problem then
10:56 amb true, but i think there's still a good use-case for white-listing trusted IP addresses
10:57 drojf do they have reserved ip ranges at the two ISPs? if you have to list all addresses of two ISPs that seems not very practical
10:57 amb so that the client never encounters a perplexing "Your IP address has changed." message on some unfortunate days when the load is erratic
10:57 amb in my case, i just need to white-list two IP addresses
10:58 rangi i still think a vpn would be better
10:58 amb right now the client can't get any work done
10:58 rangi well asynchronous routing is gonna cause a whole pile of problems
10:58 rangi not just with koha
10:59 rangi if its erratic enough that the person cant get anything done, its gonna be throwing packets all over the floor
11:00 rangi but you are welcome to submit a patch for whitelisting ips .. as long as it comes with a huge warning - potential security hole
11:01 amb cool... i have to get a working fix first :)
11:01 amb my current attempt at changing didn't seem to have the least effect
11:03 rangi its unlikely to be pushed upstream is what i was hinting
11:03 rangi what i would do, is put a reverse proxy out in front of your koha, do that yourself, so that all connections appear to koha as from that ip
11:03 rangi and make that proxy only accept connections from the 2 ip numbers
11:04 amb rangi: excellent suggestion, thank you!
11:04 amb i'll put an nginx in front of apache
11:08 rangi cool
11:10 amb are all the koha logs at /var/log/koha/library ?
11:11 rangi if you called your instance library
11:11 rangi then ye
11:11 rangi s
11:11 amb ok
11:12 amb uh, how can i change the loglevel for these logs?
11:13 rangi just edit the apache config
11:13 rangi you want more detail in the access log?
11:13 amb in the koha lohs
11:13 amb *logs
11:13 amb they're all [error] right now
11:16 amb to be more specific, where will:  warn "Checking Auth";  appear?
11:16 rangi if you switched debug on
11:17 * rangi goes to sleep
11:17 drojf night rangi
11:17 bgkriegel joined #koha
11:18 amb sleep well, rangi... thanks
11:18 cait night rangi
11:18 * drojf goes to the books
11:18 * amb goes off to setup nginx
11:21 drojf cait has to watch the channel so nobody steals anything :)
11:21 cait huh?
11:31 francharb joined #koha
11:51 bgkriegel joined #koha
12:22 tcohen joined #koha
12:36 * cait waves
12:39 amb ??
12:39 cait don't think this is about you
12:39 cait don' worry
12:40 drojf no, it is not of course
12:40 amb ok :)
12:40 amb btw, i've setup nginx in front of apache2, and it's working great... i have yet to confim that it works for the client
12:40 drojf cool
12:40 amb but an excellent idea that i'm sure will solve my problem
12:40 cait good job :)
12:41 amb yeah, you guys rock :)
12:41 drojf bgkriegel is on a signoff spree
12:41 drojf bgkriegel++
12:41 amb thx, cait
12:41 jcamins_away amb: there is a gotcha here to keep in mind... is your OPAC publicly accessible?
12:41 cait amb++ :)
12:41 bgkriegel :)
12:42 amb jcamins, yes it is
12:42 cait bgkriegel++ too :)
12:42 amb what's the catch, jcamins_away?
12:44 jcamins_away amb: public users are not going to have their sessions localized to IP either.
12:45 amb i don't quite understand
12:45 amb yes, koha/apache only sees incoming requests from 'localhost' all the time now
12:45 jcamins_away Right.
12:45 drojf jcamins_away: and by »not« you mean »now«?
12:45 amb so?
12:45 wahanui i heard so was a long road.
12:46 jcamins_away amb: if a malicious user intercepts the HTTP cookie, it's very easy to impersonate someone elese.
12:47 jcamins_away And there is a much larger number of potential interceptors since the OPAC traffic could come from anywhere and be quite high.
12:47 jcamins_away drojf: no, the IP will _not_ be user-specific.
12:47 jcamins_away You may simply not care.
12:48 jcamins_away Which would be good. :)
12:48 amb oh crap, right... so one way could be to force everything over ssl... so hopefully less chance of MITM
12:48 drojf jcamins_away: i think i misunderstood your sentence then but we mean the same
12:49 jcamins amb: right. With SSL you still have higher risk, but at least you don't make it easier for MITM.
12:50 amb i know understand why the "Error: IP address has changed." logout was introduced as a security measure in the first place :)
12:51 amb *i now understand
12:51 cait :)
12:51 amb And the fix should have been for the client to not toggle their public IP every alternate request... but I can't really influence their network setup that much :(
12:52 jcamins Yeah, that sounds like IT screwing something up. Load balancers generally have the option for "sticky" sessions.
12:52 * amb nods
12:53 amb I guess it makes sense to have the nginx as a reverse proxy in front of the staff site... and white-list the 2/3 valid IP addresses
12:54 drojf pardon my ignorance but can't you have the opac side connections done to apache directly and the staff client cia nginx reverse proxy for only your two ip addresses?
12:54 amb And for the rest, well... how can I pass that on to Apache directly? I can't right?
12:54 amb drojf: exactly my point :)
12:55 amb but i need to see how i could accomplish that configuration
12:56 jcamins drojf: I don't think so.
12:56 jcamins Well... you could if you were running Koha under nginx.
12:57 amb hmmm
12:57 jcamins Oh. Or if you had two IPs.
12:58 amb Right! 2 IPs works great... Apache listening on OPAC on one IP and nginx as a reverse proxy for Staff Site on the other
12:59 amb I think that would work.
12:59 jcamins You could even have everyone except your problematic site access the staff client directly.
13:03 bgkriegel amb: do your patrons need to log-in in OPAC?
13:03 amb Right, I just need to open up another random port like 8888 in my EC2 firewall for the problematic site... have nginx listen on 8888 and proxy_pass onto Apache
13:04 amb Apache continues to listen on 80 as usual for OPAC and also for staff site
13:04 jcamins Yes, that makes sense.
13:05 amb bgkriegel: yes
13:05 amb bgkriegel: or rather, i don't know right now, but they probably will
13:05 bgkriegel you could face the same problems
13:06 amb ?
13:06 bgkriegel if they access from teh same place
13:07 bgkriegel or is a problem only for the staff?
13:07 amb it's a problem only for staff right now...
13:07 bgkriegel ok
13:32 amb joined #koha
13:41 amb joined #koha
13:56 amb joined #koha
15:00 amb joined #koha
15:36 Oak joined #koha
15:36 * Oak waves
15:52 * jcamins learns how to mess with the web browser's history.
15:54 jcamins It's fun.
15:54 cait bgkriegel++
15:55 cait hi Oak
15:55 cait :)
16:22 Oak he cait :)
16:23 Oak bgkriegel++
17:12 NateC joined #koha
17:54 Oak joined #koha
19:02 wajasu joined #koha
19:16 rangi joined #koha
19:28 craig_ joined #koha
19:34 * wajasu slow kohaclone for me
20:02 drojf joined #koha
20:54 drojf return of the button replacer :)
20:54 cait heh
20:55 jcamins Heh.
22:22 qu-bit joined #koha
22:39 bgkriegel joined #koha
23:14 qu-bit joined #koha

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary