← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 11:09 | Elwell | Stupid Q - SIP2 in the koha sense isn't the same as SIP in the VoIP sense right? |
| 11:09 | '''''''''''''';;'' | |
| 11:10 | ah,found the 3M document | |
| 23:05 | SelfishMan | "my company emailaddresses on the Bayesian spam filter black list." |
| 23:05 | oops, wrong channel | |
| 23:17 | mason | for the NZ viewers -> http://wellingtonista.com/wait[…]kend-venn-diagram |
| 03:29 | Amit | hi good morning koha |
| 03:30 | hi mason good morning | |
| 05:15 | mason | hiya amit |
| 05:15 | Amit | hi mason |
| 05:15 | how is your weekend | |
| 05:16 | mason | very good thanks |
| 05:16 | Amit | enjoying cricket NZ vs Aus |
| 07:18 | Elwell | heh. Love the venn diagram |
| 07:18 | mc | hello world |
| 07:27 | chris | hi mc |
| 07:28 | Elwell | Stupid Q - is it possible to use zebra for log parsing? kinda like splunk? |
| 07:28 | (yes I know its not terribly koha related) | |
| 07:30 | chris | you could |
| 07:30 | there's a bunch of tools that would probably do a lot better job though | |
| 07:33 | with a lot less effort :) | |
| 07:35 | Elwell | :-) |
| 07:35 | wasnt sure how optimised zebra was | |
| 07:38 | chris | its very fast at searching |
| 07:40 | but you need to set up documents describing how your data is structured and what indices you want to build | |
| 07:41 | so you would need to set that up for you logfiles | |
| 07:42 | and querying your logfiles via Z39.50 or sru/sw just doesnt seem like a lot of fun :) | |
| 07:43 | SelfishMan | Although it is a rather geeky way to do it |
| 07:44 | Just don't Z39.50 enable a Furby to query your logfiles because that's just going too far | |
| 07:44 | chris | no one should use Z39.50 unless they have to ;) |
| 07:48 | HARE9 | good morning |
| 07:51 | chris | hi hare9 |
| 07:59 | Amit | hi hare9 |
| 07:59 | hi chirs have u check reading level in koha3 | |
| 07:59 | sory chris | |
| 08:02 | chris | what do you mean? |
| 08:03 | Amit | i mean to say http://lists.katipo.co.nz/publ[…]/2006/010884.html |
| 08:03 | this one for koha 3 | |
| 08:13 | chris | i havent done it, but it might work, you would have to edit the zebra config |
| 08:14 | hi paul | |
| 08:14 | paul_p | hi chris |
| 08:14 | Amit | k |
| 08:15 | paul_p | & hi amit (& anyone else on this channel) |
| 08:15 | Amit | hi paul |
| 08:16 | kf | amit: perhaps this is the way to do it in 3.0: http://lists.katipo.co.nz/publ[…]tober/015763.html |
| 08:17 | Amit | k |
| 08:18 | thanks hope it will help | |
| 08:20 | kf | did not try it yet, but i will need a new search option for our accession numbers |
| 08:20 | Amit | k |
| 09:42 | kf | hi there, i have a question: my colleague asked me, if its better to have a separate mysql-server. how do you handle that? |
| 09:42 | paul_p | is it better ? it just depends on your needs. |
| 09:43 | if you have a dedicated mySQL server (with specific DB-tuning & backups & ...), then it's a good idea. | |
| 09:43 | the easiest way to do that is : | |
| 09:43 | chris | and a fast network |
| 09:43 | paul_p | * install koha on a single server |
| 09:43 | chris | if your network is slow, then doing all the db work over the network is a big performance kill |
| 09:44 | paul_p | * modify the koha_conf.xml to link mysql from localhost to xxx.yyy.zzz.ttt |
| 09:44 | or, if you install koha for the 1st time, you can, during configure, specify the address of the mySQL server | |
| 09:44 | kf | util now, we have koha as vmware on one server, but we will probably host koha for more than one library |
| 09:45 | chris | you definitely wont want to run it under vmware in production |
| 09:45 | paul_p | chris: why ? |
| 09:45 | chris | emulation is always slower |
| 09:46 | kf | we do that for many applications atm, is the difference great? |
| 09:47 | our koha seems ok for me, but the only person using it is me of course | |
| 09:48 | paul: do you use a separate server for your installations? or just a single server? | |
| 09:48 | chris | paul: its also one more thing that can go wrong, and you end up supporting 2 OS's on the machine instead of one |
| 09:49 | i can understand it for local applications | |
| 09:50 | paul_p | chris: I agree with your ideas here. & we just use 1 server for our hosted koha |
| 09:50 | in fact, we have 1 server, with vserver & 2 "vserver" machines : one for production one for testing | |
| 09:51 | vserser is not full virtualization. | |
| 09:51 | chris | i usually do that with xen |
| 09:51 | yeah we use vservers a lot at work | |
| 09:51 | kf | ok, one more question. how to handle multiple koha installation? |
| 09:51 | ah | |
| 09:52 | paul_p | kf: we have developed some tools to help having multiple koha installations on the same server. |
| 09:52 | kf | vservers? |
| 09:52 | chris | you can do it the vserver, or xen etc |
| 09:52 | or you can do it with multiple dbs and config files | |
| 09:52 | paul_p | kf: we use vserver just for separating production & testing |
| 09:52 | chris | i currently have 6 koha's running on my server at home |
| 09:53 | paul_p | all our productions instances are on the same vserver. |
| 09:53 | chris | just with different databases and config files, but all using the same perl |
| 09:53 | paul_p | & the same Koha, chris is right |
| 09:53 | kf | i think i will need at least three - koha production, koha for training and one to test new versions |
| 09:53 | paul_p | then, it's different than what we have. |
| 09:53 | for that, I suggest to have different VM | |
| 09:54 | just an example : I did an update at SAN-OP, and got a problem due to perl Text::CVS_XS, that has changed ! | |
| 09:54 | (it use to encode files depending on locale, now it's latin1 if my investigations are correct) | |
| 09:55 | so, you need to have 2 or 3 completely differents environments | |
| 09:56 | kf | what about local changes in templates? i will try to avoid it... but we will at least need a special search option for inventory numbers |
| 09:57 | if you have just one koha for several installations its everywhere then, right? | |
| 09:58 | sorry, paul, i think i understand now | |
| 10:01 | chris | i normally have a development, a staging and a production server |
| 10:01 | paul_p | chris: yes, and that can be virtual machines imo |
| 10:02 | chris | the production server could do both training and live |
| 10:02 | (have 2 koha's on it) | |
| 10:02 | paul_p | chris: ++ |
| 10:02 | chris | staging is for testing |
| 10:02 | and development is where you make your new templates etc | |
| 10:03 | often my staging box is a separate machine, and i run replication from the production box to it | |
| 10:04 | kf | what about more than one production systems for different libraries? |
| 10:04 | chris | they would be on your production machine (or virtual machine) |
| 10:05 | and that would be the machine you backup obsessively :) | |
| 10:05 | nothing helps you sleep better than reliable backups :) | |
| 10:06 | another option | |
| 10:06 | is using amazon's ec2 | |
| 10:07 | where you just spark up another instance (from your koha image) for each production system | |
| 10:08 | http://aws.amazon.com/ec2/ | |
| 10:24 | kf | back, had a support emergency here - you always help chris |
| 10:24 | but im not sure if i understand it right | |
| 10:24 | ok, you dont recommend a separate mysql-server due to performance reasons, is this right? | |
| 10:25 | chris | it depends on your network |
| 10:25 | kf | and its possible to have more than one koha installation on one server, with different conf-files? |
| 10:25 | chris | if its 100 |
| 10:25 | Mbit (or better) | |
| 10:25 | kf | ok |
| 10:25 | chris | then a machine tuned just to be a database server can help with performance |
| 10:26 | it its slower, then the performance gain can be offset by network lag | |
| 10:27 | and yes you can have multiple koha's running on the same server | |
| 10:28 | kf | we just start thinking about the best infrastructure for the production system |
| 10:29 | chris | ive done it both ways before (separate mysql machine and with mysql on the same machine) |
| 10:30 | generally a webserver and a database server will compete for the same scarce resources (ram and cpu) | |
| 10:30 | paul_p | kf: how many items in your catalogue ? |
| 10:30 | chris | so if its high usage, seperating them can be a good idea |
| 10:30 | the nice thing is | |
| 10:30 | you can always start with them on the same server | |
| 10:31 | then shift it and change the config et voila ;) | |
| 10:31 | :) | |
| 10:31 | kf | about 50.000 for our first library |
| 10:32 | but some other libraries are also interested, so we have to think about more than one production system | |
| 10:33 | chris: your french is better than mine ;) | |
| 10:33 | paul_p | kf: with 50 000 items, you don't need to care of having 2 separate servers imo ! |
| 10:33 | chris | paul has heard me try to speak it, he may disagree :) |
| 10:33 | yes, with 50,000 one will be fine | |
| 10:35 | kf | but i think it would be easier to backup one db-server, instad of several mysql-instances in different vms? |
| 10:35 | the question is about performance then i think, but that should not be a big problem when the network is fast enough | |
| 10:36 | chris | ok, i should go to sleep |
| 10:37 | paul_p | sweet dreams chris |
| 10:39 | kf | sweet dreams chris |
| 10:39 | and thx | |
| 10:40 | and thx paul, i will have to discuss this with my colleague, wo is responsible for the servers | |
| 10:41 | perhaps i will send him here next time :) |
← Previous day | Today | Next day → | Search | Index