- Koha-devel - lists.koha-community.org

Re: [Koha-devel] Bug 8641
by Paul 23 Jan '13

23 Jan '13

At 06:48 PM 1/22/2013 -0500, Jared Camins-Esakov wrote: >Paul, >This bug was signed off a few weeks ago, and is designed to produce a >"warning" in the "About" page covering staff use of Koha (not sure if this >covers all flag settings down from superlibrarian or if it applies to 3.8. >as well as 3.10?) logging in as either "root", "admin (mysql) account" or >"database administrative user." >I seem to remember (but could be wrong) that after a new 3.8 install, Koha >created a "new user", number 0, which was problematic and as far as I can >tell exhibited the signs that the warning covers (I have tried to read all >details in bugs 8641, 8262 and 9008 plus some references to IRC.) >You are. User "0" is the database administrative user. Do not use it for >anything other than initial installation and upgrades. Ever. Thanks Jared. I'm glad that my memory didn't fail me :) and that I never use it. But I'm still interested in the "warning" - particularly as you mention that it should be used for upgrades. As far as I can see (using getent passwd | cut -d : -f 1 | xargs groups) there is no problem with *system* security. Also, User "0" does not appear in the MySql 'borrowers' table. So why is it possible to log in with the "warned against" credentials? How should it be used during upgrades? It also is possible to create a superlibrarian with User "koha" credentials; limited testing in my sandbox has not [yet!] shown any side effects, except that User "0" can no longer log in (demonstrated by the fact that "Library" is set.) Best - Paul _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ --- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>

1 0

RM vacation
by Jared Camins-Esakov 23 Jan '13

23 Jan '13

Good morning. I just wanted to let folks know that the RM will be on vacation starting this Friday, January 25, until Monday, February 4. I anticipate no crises in my absence, and will probably check my e-mail, but the amount of time I spend on testing and pushing will be greatly curtailed. Also, I'll be in California, so if I'm around, it will be four hours later than is my wont. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins(a)cpbibliography.com (web) http://www.cpbibliography.com/

1 0

Bug 8641
by Paul 23 Jan '13

23 Jan '13

This bug was signed off a few weeks ago, and is designed to produce a "warning" in the "About" page covering staff use of Koha (not sure if this covers all flag settings down from superlibrarian or if it applies to 3.8. as well as 3.10?) logging in as either "root", "admin (mysql) account" or "database administrative user." I seem to remember (but could be wrong) that after a new 3.8 install, Koha created a "new user", number 0, which was problematic and as far as I can tell exhibited the signs that the warning covers (I have tried to read all details in bugs 8641, 8262 and 9008 plus some references to IRC.) Maybe I'm paranoid, but could someone please clarify how far any problems might extend. If someone sets up a *new* Koha superlibrarian account using the same name/password as system (sudo) user and/or with all MySql privileges, permission tables should not interfere with one another, or overlap, even when identical user/pw combinations are used. Surely this would only apply if staff-user is "koha" or whatever other name was explicitly granted MySql privileges during/immediately after Koha installation. Am I mistaken? Thanks and best regards, Paul

2 1

Old bugs to check
by MJ Ray 22 Jan '13

22 Jan '13

Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5672 Search History Should have RSS Feeds http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2960 Cyrillic Z39-50 servers (bad encoding results) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5169 name/rename label batches http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2645 Put Total Due at top of Fines page/seperate paid from unpaid http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5472 Build script needs updating for 3.2.1 release http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3200 missing quotes in rebuild_unimarc_100.pl http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5789 Fines don't work when items have null homebranch http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 why is there a 'do not notify' option? http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4125 Bulkmarcimport.pl script has changed a lot without beeing documented http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4874 debian/scripts/koha-* should use Koha instance DB credentials http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3343 duplicate subfields in authority http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5024 Debian packages don't include YUI plugins http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4855 Tools/Export does not tell browser file size http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3147 call to ModZebra in DelAuthority fails (fatal error) if record previously deleted but still exists in index http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5340 bulk subscription renewal http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5721 marc import summary should be filtered or customizable http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5270 007 variable control builder/Specific Material Designation http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3111 Opac lists all ITYPES as same, when database lists different. Other OPAC issues. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5538 would be nice to search both collection code and item type -- Email robot driven by MJ Ray (slef), member of www.software.coop, http://koha-community.org supporter, web and library systems developer. Available for hire (including development) at http://www.software.coop/

1 0

Contents of more_subfields_xml
by Paul 22 Jan '13

22 Jan '13

I have recently done some "house-keeping" looking for consistency in the MySQL db (5.5.24 in 3.8.5), and while some tidying up has been straight-forward I am having problems with more_subfields_xml in items. Only about 90% of 'items' have any xml attached to them. Within those that do have an xml entry, only the following subfields appear: <subfield code="f"> entries < 1% <subfield code="i"> entries ~ 20% <subfield code="k"> entries ~ 1.5% <subfield code="x"> entries ~ 95% and they are mostly filled with random values from 2xx, 6xx and 9xx, although the 'code="x"' values appear to be valid from the 952$x. code="f" contains values from 952$v; code="i" has some 952$i valid entries but mostly 650$a,x,y,z; code="k" has random authors, titles, etc - and I can't find where we might use 952$k in our frameworks. Can someone please tell me how these blobs are mapped/created and used by koha? Our odd-ball results/entries don't appear to be having much, if any, influence on cataloguing and search functions. Also, if there is any way to "rebuild" more_subfields_xml -- it's way too big a problem to manage manually. Many thanks - Paul P.S. For completeness, after de-duping all the entries obtained from " SELECT more_subfields_xml FROM items; " (249,636 text lines), the only data left (apart from the subfields above) are "empty containers" using: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.loc.gov/MARC21/slim"> xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd" <?xml version="1.0" encoding="UTF-8"?> <collection </collection> <datafield tag="999" ind1=" " ind2=" "> </datafield> <leader> a </leader> <record> </record>

2 1

About installation in OpenSuse 12.x
by John Herz 22 Jan '13

22 Jan '13

Hello: I am looking for instalation instruction in OpenSuse 12.x if any have some experience, in the wiki only show without zebra configuring :( thank you

2 1

(no subject)
by Mohamed zalabany 22 Jan '13

22 Jan '13

hi all i want to know if i have libraries consortium and i need every library see her records only from opac or stuff is their any configuration available from administration to do that or the data will be searchable for all branches the second could we change the opac interface for every library in the consortium when the user of this library enter with his user name and password Mohamed El Zalabany Integrated library systems consultant LibroTech for library systems and information technology http://www.librotech.net mh_zalabany(a)hotmail.com Mobile: 0111291444

2 2

XSLT and superfluous "xmlns" attributes
by Magnus Enger 21 Jan '13

21 Jan '13

Dear Community! I'm having some XSLT trouble... I have some OAI-PMH records available here: http://sksk.bibkat.no/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=m… The National Library of Norway wants to harvest these records, but they have some very specific requirements, namely that the code for the owning library should be in 850 and that 001 should match the record identifier used in the OAI records identifier. To achieve this, I'm taking advantage of the OAI-PMH:ConfFile syspref, to specify an XSLT stylesheet to transform the records on the fly. Here is the relevant part of the ConfFile: format: biblioteksok: metadataPrefix: biblioteksok metadataNamespace: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim schema: http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd xsl_file: /home/magnus/koha/biblioteksok.xslt and here is the stylesheet in /home/magnus/koha/biblioteksok.xslt: <xsl:stylesheet version="1.0" xmlns:marc="http://www.loc.gov/MARC21/slim" xmlns:items="http://www.koha-community.org/items" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:package="info:srw/extension/13/package-v1.0" > <xsl:output omit-xml-declaration="yes" indent="yes"/> <xsl:template match="node()|@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:template> <xsl:template match="marc:controlfield[@tag=001]"/> <xsl:template match="marc:datafield[@tag=850]"/> <xsl:template match="marc:leader"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy>  <xsl:if test="not(marc:controlfield[@tag=001])"> <xsl:text> </xsl:text><xsl:element name="controlfield"> <xsl:attribute name="tag">001</xsl:attribute> <xsl:value-of select="//marc:datafield[@tag=999]/marc:subfield[@code='c']/text()"/> </xsl:element> </xsl:if> </xsl:template> <xsl:template match="marc:datafield[@tag=999]"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy>  <xsl:if test="not(marc:controlfield[@tag=850])"> <xsl:text> </xsl:text> <xsl:element name="datafield"> <xsl:attribute name="ind1"><xsl:text> </xsl:text></xsl:attribute> <xsl:attribute name="ind2"><xsl:text> </xsl:text></xsl:attribute> <xsl:attribute name="tag">850</xsl:attribute> <xsl:element name="subfield"> <xsl:attribute name="code">a</xsl:attribute> <xsl:text>NO-1120127</xsl:text> </xsl:element> </xsl:element> </xsl:if> </xsl:template> </xsl:stylesheet> And here is the result of applying the stylesheet: http://sksk.bibkat.no/cgi-bin/koha/oai.pl?verb=ListRecords&metadataPrefix=b… I was quite pleased with the result myself, but now the National library is complaining that the transformed records do not validate against http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd and that the empty "xmlns" attribute should be removed from the following elements: <controlfield xmlns="" tag="001">93</controlfield> <datafield xmlns="" ind1=" " ind2=" " tag="850"> I have no idea how to achieve that. Does anyone else have a clue? Best regards, Magnus Enger libriotech.no

2 2

sql query / number of items
by Samuel Desseaux 18 Jan '13

18 Jan '13

Hi, I need to write a sql query to count the number of 995 field in the records which i 've imported. An idea? Best, samuel

2 1

reindexing with zebra
by Samuel desseaux 17 Jan '13

17 Jan '13

Hi, While reindexing zebra, i've this message and some warns i don't understand. Zebra configuration information ================================ Zebra biblio directory = /var/lib/koha/zebradb/biblios Zebra authorities directory = /var/lib/koha/zebradb/authorities Koha directory = /usr/share/koha/intranet/cgi-bin BIBLIONUMBER in : 090$9 BIBLIOITEMNUMBER in : 090$a ================================ ==================== exporting authority ==================== 701.................................................................................................... Records exported: 758 ==================== REINDEXING zebra ==================== 15:41:06-17/01 zebraidx(10724) [warn] /etc/koha/zebradb/authorities/etc/dom-config-marc.xml: stylesheet authority-zebra-indexdefs.xsl not found in path /etc/koha/zebradb/authorities/etc:/etc/koha/zebradb/etc:/etc/koha/zebradb/marc_defs/unimarc/authorities:/etc/koha/zebradb/lang_defs/fr:/etc/koha/zebradb/xsl 15:41:06-17/01 zebraidx(10724) [warn] /etc/koha/zebradb/authorities/etc/dom-config-marc.xml: stylesheet authority-zebra-indexdefs.xsl not found in path /etc/koha/zebradb/authorities/etc:/etc/koha/zebradb/etc:/etc/koha/zebradb/marc_defs/unimarc/authorities:/etc/koha/zebradb/lang_defs/fr:/etc/koha/zebradb/xsl ==================== exporting biblio ==================== 41801.................................................................................................... Records exported: 41805 ==================== REINDEXING zebra ==================== 15:49:11-17/01 zebraidx(10729) [warn] Unknown register type: Best, samuel

1 0