- Koha - lists.katipo.co.nz

Re: [Koha] Backing up 3.0
by Frederic Demians 18 Dec '08

18 Dec '08

> Any thoughts on what files are essential to restore in the event of a > complete system crash? I second Joe Atzberger analysis. Your backup policy must be adjusted on data update periodicity. A good practice is to document backup AND restore. You must know and test by advance what you will have to do in case a restore is required. You may need a partial or a complete restore depending of situation: complete disk failure or just DB data corruption. Don't forget that with Koha 3 indexes are built outside MySQL DB: in Zebra. You can't save Zebra indexes synchronically with MySQL DB. Hopefully, Zebra indexes can be rebuilt easily and almost quickly. You must know how to do it in a recover after crash scenario. Other systems are also possible involving disk partitioning and mirroring. -- Frédéric

1 0

Re: [Koha] Backing up 3.0
by Doug Dearden 18 Dec '08

18 Dec '08

Hi Joe, I agree with your analysis. Rereading my post I realize I gave the impression that ll of the scripts run every day, when only the database related scripts run daily. I am not backing up the file system and config every day, I just want a backup so I can restore quickly if I need to. I do have several scripts to deal with the various pieces separately (database, configs, koha files with customizations). As I had quite the task getting all of the Koha prerequisites in place, in particular all the perl modules I would like to get a good backup of those that I can restore if needed to a new server. My thoughts on a restore would be to install the basic Debian system from the CD, then install MySQL and Apache2 using apt-get or aptitude. With that base system in place I could then copy the rest of the files needed including all of the Perl modules and the koha files, copy in my custom config files and then restore the database. As I write this I think the piece I am missing, is where all of the Perl modules that are prerequisites for Koha are installed. On a regular Debian install would these all be in /usr/share/perl, /usr/share/perl5, /usr/lib/perl, and /usr/lib/perl5? Am I missing another directory with prerequisites that I haven't thought of? Thanks, Doug >>> "Joe Atzberger" <ohiocore(a)gmail.com> 12/18/2008 11:16:33 AM >>> Doug -- Your process sounds pretty good. I would leave out the perl directories or at least treat them separately from your daily data backup. We should differentiate between different kinds of backups: - data: mysqldump, the most important part to backup from a production system - application/configuration: koha directories and conf files, including any customization - system: everything else. The goals of these are different. Data is the most volatile and is exclusively internal to the application. Everybody should backup their data and mysqldump is the plainest way to do it. The application itself and configuration shouldn't change between installations or upgrades. The premise is that if you have the data, you can rebuild Koha by repeating installation steps on any system and loading in the data. Backing these up every day when they are expected to be unchanged is overkill. For disaster recovery purposes or shorter recovery windows, or where you can't be trusted to complete a second installation, you start getting into the other two types of backups. These are files on the filesystem and not data from a database. Note that the koha directories may be in different places depending on the type of installation performed, so the backup will not necessarily be useful (and could be harmful) if applied on a different system. This makes it hard to script explicit steps that are still generic enough to satisfy everybody. IMHO, the koha manual shouldn't get involved with anything beyond data backups. The rest is for the sysadmin of a given system to decide. --Joe Atzberger On Thu, Dec 18, 2008 at 11:49 AM, Doug Dearden <dearden(a)sarsf.org> wrote: > Hello all, > > I want to check to make sure I am backing up Koha correctly. I looked > at this reference: > > http://www.kohadocs.org/Backups_and_Restoring.html > > It refers to the file structure for an earlier version. I couldn't > find anything in the doc at > https://sites.google.com/a/liblime.com/koha-manual/ , but maybe I am > missing something there. Here is what I came up with: > > Backup the database using: > > mysqldump --add-drop-table -u<dbusername> -p<dbpassword> koha > > koha.sql > > I am running multiple databases, and am repeating the above for each > unique database name. > > Backup all of the files in /usr/share/koha . > > Backup the extra config files in: > > /etc/koha > /etc/apache2 > /etc/mysql/my.cnf > > I am also backing up these as I made changes to them - perhaps unique > to my install: > > /etc/vsftpd.conf > /etc/network > /etc/hosts > > I am using cron to run several scripts that do the above, using tar > -czf to create compressed files and the copying them to a remote > location that also gets backed up to tape every day. > > As I write this, I am thinking I should add /usr/share/perl5 and > /usr/share/perl to the list. > > Is there anything else needed that won't easily install from a Debian > install? My approach on this is to have a backup of all the unique > items needed for Koha, so I can do a clean install of Debian with > Apache2 and MySQL, then restore from the backups and go. As there will > be core items that change depending on the hardware config, I don't > think I can just backup the entire debian file system and transfer it to > a new machine. > > Thanks, > > > > Doug Dearden > Director, Information Technology > School for Advanced Research > (formerly School of American Research) > (505)954-7220 > www.sarweb.org > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

Re: [Koha] Backing up 3.0
by Doug Dearden 18 Dec '08

18 Dec '08

Thanks Frederic, I will add that to my script. Any thoughts on what files are essential to restore in the event of a complete system crash? Best, Doug >>> Frederic Demians <frederic(a)tamil.fr> 12/18/2008 11:11:01 AM >>> > mysqldump --add-drop-table -u<dbusername> -p<dbpassword> koha >koha.sql You must add --single-transaction option to dump a consistent state of Koha DB. You may want to add compression on the fly rather than after dump to spare disk space: mysqldump --add-drop-table --single-transaction \ -u<dbusername> -p<dbpassword koha | gzip >koha.sql -- Frédéric

1 0

Re: [Koha] Backing up 3.0
by Doug Dearden 18 Dec '08

18 Dec '08

Thanks for the link, I'll check that out. Are you backing up the file system as well? Any thought to restoring on a different server in the event of a total system crash? Doug >>> "Chadwick, John, DCA" <john.chadwick(a)state.nm.us> 12/18/2008 11:11:15 AM >>> I am doing something similar. I use a file from sourceforge.net call AutoMySQLBackup. Very easy to edit and make it executable. http://sourceforge.net/projects/automysqlbackup I run backups on a regular basis and have even done a restore from one box to another with no problems. John +-------------------------------------------+ John Chadwick, Ed.D. Information Technology Manager New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 505-476-9740 505-476-9761 (FAX) John.Chadwick(a)state.nm.us -----Original Message----- From: koha-bounces(a)lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Doug Dearden Sent: Thursday, December 18, 2008 9:50 AM To: koha(a)lists.katipo.co.nz Subject: [Koha] Backing up 3.0 Hello all, I want to check to make sure I am backing up Koha correctly. I looked at this reference: http://www.kohadocs.org/Backups_and_Restoring.html It refers to the file structure for an earlier version. I couldn't find anything in the doc at https://sites.google.com/a/liblime.com/koha-manual/ , but maybe I am missing something there. Here is what I came up with: Backup the database using: mysqldump --add-drop-table -u<dbusername> -p<dbpassword> koha > koha.sql I am running multiple databases, and am repeating the above for each unique database name. Backup all of the files in /usr/share/koha . Backup the extra config files in: /etc/koha /etc/apache2 /etc/mysql/my.cnf I am also backing up these as I made changes to them - perhaps unique to my install: /etc/vsftpd.conf /etc/network /etc/hosts I am using cron to run several scripts that do the above, using tar -czf to create compressed files and the copying them to a remote location that also gets backed up to tape every day. As I write this, I am thinking I should add /usr/share/perl5 and /usr/share/perl to the list. Is there anything else needed that won't easily install from a Debian install? My approach on this is to have a backup of all the unique items needed for Koha, so I can do a clean install of Debian with Apache2 and MySQL, then restore from the backups and go. As there will be core items that change depending on the hardware config, I don't think I can just backup the entire debian file system and transfer it to a new machine. Thanks, Doug Dearden Director, Information Technology School for Advanced Research (formerly School of American Research) (505)954-7220 www.sarweb.org _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

1 0

Searching by MARC tag
by Lenora Oftedahl 18 Dec '08

18 Dec '08

Ok. I'm looking for the search by MARC tag that was in 2.2.9 and I can't find in 3.0. Did this option go away for the cataloger interface? Thanx. Lenora

1 0

Re: [Koha] Koha Digest, Vol 38, Issue 63
by Jim Minges 18 Dec '08

18 Dec '08

1. Re: SIP-2 support? (anand(a)webodesk.com) There is at least one library using RFID in Koha: the Basehor Community Library in our NExpress group. The basic SIP2 functionality worked fine, but we needed our friends at Liblime to write an enhancement to correctly handle RFID self-check on items on which a hold had been placed. Jim Minges Northeast Kansas Library System koha-request(a)lists.katipo.co.nz wrote: > Send Koha mailing list submissions to > koha(a)lists.katipo.co.nz > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.katipo.co.nz/mailman/listinfo/koha > or, via email, send a message with subject or body 'help' to > koha-request(a)lists.katipo.co.nz > > You can reach the person managing the list at > koha-owner(a)lists.katipo.co.nz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Koha digest..." > > > Today's Topics: > > 1. Re: SIP-2 support? (anand(a)webodesk.com) > 2. Re: GST and discount not calculating correctly when placing > an order in 3.0 acquisitions. (Chris Cormack) > 3. Re: Freight in aquistions? (Joshua Ferraro) > 4. Re: GST and discount not calculating correctly when placing > an order in 3.0 acquisitions. (Joshua Ferraro) > 5. Re: GST and discount not calculating correctly when placing > an order in 3.0 acquisitions. (Chris Cormack) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Dec 2008 02:09:18 -0700 > From: anand(a)webodesk.com > Subject: Re: [Koha] SIP-2 support? > To: Oliver.Bernuetz(a)canadabusiness.ca > Cc: koha(a)lists.katipo.co.nz, Joshua Ferraro <jmf(a)liblime.com> > Message-ID: <20081217020918.vbkluyjpss8kk804(a)webodesk.com> > Content-Type: text/plain; charset="iso-8859-1" > > > > Quoting Joshua Ferraro <jmf(a)liblime.com>: > > >> Hi Oliver >> >> On Tue, Dec 16, 2008 at 11:10 AM,? <Oliver.Bernuetz(a)canadabusiness.ca> wrote: >> >>> Hi there, >>> >>> Does Koha feature SIP 2 support?? We're looking at RFID so I need to >>> know this. >>> >> Yes, Koha 3.0 supports SIP2 via the OpenNCIP libraries >> (http://openncip.org) and has been successfully connected to >> Self-Checkout systems like those by 3M, Authentication with search >> services like VDX(tm), as well as other SIP2 applications. I'm not >> aware of any Koha libraries using RFID, but I don't anticipate any >> major barriers to that provided the implementation relies on the SIP2 >> 3M spec. >> >> Cheers, >> >> -- >> Joshua Ferraro? ? ? ? ? ? ? ? ? ? ? ?SUPPORT FOR OPEN-SOURCE SOFTWARE >> CEO? ? ? ? ? ? ? ? ? ? ? ? ?migration, training, maintenance, support >> LibLime? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Featuring Koha Open-Source ILS >> > > Yes koha 3.0 supports SIP2, we have successfully integrated 3M SIP2 > with Koha 3.0 and Live Working Demonstration of 3M Selfcheck System[1] > with Koha 3.0 was given at 'ILA-TISS International Conference 2008'. > which was held between 12-15 November 2008 at TISS, Mumbai, India. > > (ILA - Indian Library Association, TISS - Tata Institute of Social > Science)-- > Anand Sharma > RDG Library Services > Mumbai, India. > > > > Links: > ------ > [1] > http://solutions.3m.com/wps/portal/3M/en_US/library/home/products/selfcheck… > >

1 0

Re: [Koha] RDA, was: Re: Simple MARC or Simple Acquisitions?
by BWS Johnson 18 Dec '08

18 Dec '08

Salvete! >I'd suggest reading a paper by Martha Yee wrote for IFLA posted at >http://slc.bc.ca/yee.pdf entitled PRINCIPLES FOR THE DISPLAY OF >CATALOGER CREATED METADATA. I think how a system displays the MARC >record is critical. As a cataloger I am shocked at the mess so many >catalogs make of displaying our work to the public. That was about contemporary to when I was in Library school. I'm not sure if I read it as part of Cataloguing and Classification or whether I stumbled across it on my own, I think it was the former. I agree with your mess observation. The OPAC to me is a different bird than the Cataloguing tools that the Librarian works with, even though they are two sides of the same record. One of the things that I think this project beat others on was the introduction of the 856u into the search results. It doesn't seem when I think back on it like anyone else was doing this at that point, but it was natural to our lads. Cheers, Brooke

1 0

Re: [Koha] RDA, was: Re: Simple MARC or Simple Acquisitions?
by BWS Johnson 18 Dec '08

18 Dec '08

Salvete! >Well... I'm doubtful about the chances of RDA being a runaway hit: I'm doubtful for different reasons, but it's still worth thinking about the concepts as we think about the cataloguing module. >* it's not easily accessible (they're trying to actually sell the >recommandation rather than freely distribute it) Don't get me started, Wilbur. For whatever reason, a lot of the professional literature is like this, which I think is intensely hypocritical in a field that believes in open access. I nag about this constantly. Recently, American Libraries became available for free online, which is a tiny start, although they've done it with a dumb reader. But, more to the point, unfortunately, that's how they've done it for years. http://www.aacr2.org/us/products_aacr2.html >* it's not easily accessible (the mere ToC runs to 75 pages : who's >going to actually read this, let alone implement it?) Again, AACR2R is at least 750 pages, and that doesn't necessarily include the extra looseleaf that comes out. (I'd argue that very few people actually read it. When I explain cataloguing, I tell people it's like an elementary school class. The kids in the front of the class have read everything and actually know what's going on. The kids in each subsequent row are copying over the shoulder of the student in front of them. Thus the disparity in the quality of records. ;) >* it's not easily accessible (with 251 different "entities") I'd say that original cataloguing as it currently stands isn't easily accessible either. >* if you want to make it accessible, you can do "profiles" to use only >subsets of those 251 entities; but wait: a recommandation with >different profiles to manage... sounds a lot like Z3950 to me, and is >in danger of reverting to the mess we have with UNIMARC / MARC21 / >NORMARC / WHATEVERMARC *nod* That is one of my big reasons that I don't think it will catch on too quickly. It seems to contain enough MARC like throwbacks that some folks will be turned off that it's too similar. I think (and this is wild rumour) that this was done to appease folks that wanted some sort of skeletal structure to the thing. If it is eventually adopted, I do think you'd have much less of a MARC mess in terms of flavour, just as it's very appealing in linking what would normally be many different records. (Les Misérables in print, on CD, on VHS, on DVD, et cetera...) They really wanted this to be international, which is why they took the AACR part out. >* it looks a lot like marc too, with entities like "title proper", >"title uniform", etc > It was initially meant as a replacement to AACR2R. Then thinking and committee work happened. Kathy Glennan has what I would call an English translation of all this evolutionary stuff here: http://www.musiclibraryassoc.org/BCC/Descriptive/RDA_Evolution.pdf >I don't know, I'm not a cataloger either : maybe RDA is the way to go, >I don't claim I'm competent to pass judgment on the recommandation >from a cataloguer's point of view, but I don't envision Ex Libris, >SirsiDynix or, for that matter, the Koha community investing what it >would take to just try to implement this thing. I'd love to be proved >wrong though. It's still fluid. And I'd say very sketchy, since initially as I was going through the site I spotted that subjects basically were ducked. So I shot off emails to a few cataloguing geniuses that basically enquired whether I had read the draft properly and viola, subjects were in fact just not there yet. So even if we wanted to implement it right this second, we couldn't. However, I think it would behoove us greatly to think about some of the very positive overarching premises as we design things, which is why I thought the slideshow was useful. If we expend a little effort learning and thinking now, it might partially mitigate the need for a large overhaul to be compliant in the murky future, since part of the work is essentially done in advance. Keep our options open, so to speak. I had to have a few meaningful hand holding discussions with actual cataloguers before I could begin to get my head around what they're trying to do. If this makes any sense, it's simpler, but the explaining of it is more lengthy and complex. Cheers, Brooke

1 0

RDA, was: Re: Simple MARC or Simple Acquisitions?
by Nicolas Morin 18 Dec '08

18 Dec '08

On Thu, Dec 18, 2008 at 2:22 PM, BWS Johnson <mhelman(a)illinoisalumni.org> wrote: > Salve! > > Big warning: I'm not properly a cataloguer, but gosh over the years my > cataloguing disguise seems to be getting very good. > > The time to think about a major overhaul is *now* since the RDA proposal is > on the table. Well... I'm doubtful about the chances of RDA being a runaway hit: * it's not easily accessible (they're trying to actually sell the recommandation rather than freely distribute it) * it's not easily accessible (the mere ToC runs to 75 pages : who's going to actually read this, let alone implement it?) * it's not easily accessible (with 251 different "entities") * if you want to make it accessible, you can do "profiles" to use only subsets of those 251 entities; but wait: a recommandation with different profiles to manage... sounds a lot like Z3950 to me, and is in danger of reverting to the mess we have with UNIMARC / MARC21 / NORMARC / WHATEVERMARC * it looks a lot like marc too, with entities like "title proper", "title uniform", etc I don't know, I'm not a cataloger either : maybe RDA is the way to go, I don't claim I'm competent to pass judgment on the recommandation from a cataloguer's point of view, but I don't envision Ex Libris, SirsiDynix or, for that matter, the Koha community investing what it would take to just try to implement this thing. I'd love to be proved wrong though. Cheers, Nicolas

2 1

Simple MARC or Simple Acquisitions?
by Rachel Hamilton-Williams 18 Dec '08

18 Dec '08

Hi ya, Hopefully starting on a new thread. Just in the last few weeks we've had a couple of clients who would really benefit from an easier way to do their own cataloging. They don't (Sadly) find their specialist materials being well serviced via the various z39.50 servers etc, often because they are doing cataloging of materials they are producing themselves, or from other government departmens/private publishers essentially. As alluded to we (Katipo) did have an interface to do this in the very early versions of Koha, and I still have essentially the spec for it in the form of a working version, and screen shots/manual type stuff - we called it simple acquisitions, and in the current version of Koha you can see that there is a preference for either simple or normal acquisitions - of which only normal is really there. I've been toying with the idea of seeing what's involved in essentially adding a simple acquisitions module back in again - but saw that Galen I think is planning something similar sounding as a simple MARC module. So I'm wondering if the two ideas are close enough to be the same thing? I'd anticipate still doing some "money stuff" as part of a simpler acquisitions process - it's just you wouldn't order & recieve, it'd be all one action - for libraries that basically pop down to their local book shop twice a year to get some new materials in, but who still want to keep a record of what they cost. So I'm not sure if that takes it out of the realm of a simple MARC catalogue system. Anyways, if anyone has strong views one way or the other let me know. I'm a bit biased against the current MARC interface - we get people being intimidated by it (me included :-) but I'm prepared to work through it. Cheers Rachel

2 1