From Wed Aug 12 11:24:14 2009 Date: Wed, 12 Aug 2009 11:24:14 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 95 Mime-Version: 1.0 Status: RO X-IMAP: 1250100658 4 Delete. This is a system message. --END+PSEUDO-- From jw137282@sac.sfbay.sun.com Fri Aug 7 19:38:59 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n782cwIK003049 for ; Fri, 7 Aug 2009 19:38:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n782cvwn001024; Sat, 8 Aug 2009 10:38:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO100A01E0W8M00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 Aug 2009 19:38:56 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO1002VKE0W5XD0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 Aug 2009 19:38:56 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n782cuBf033418; Fri, 07 Aug 2009 19:38:56 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n782csnc003044; Fri, 07 Aug 2009 19:38:54 -0700 (PDT) Received: (from jw137282@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n782csaf003040; Fri, 07 Aug 2009 19:38:54 -0700 (PDT) Date: Fri, 07 Aug 2009 19:38:54 -0700 (PDT) From: James Walker Subject: idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009] To: PSARC-ext@sun.com Cc: Andre.Molyneux@sun.com Message-id: <200908080238.n782csaf003040@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Content-Length: 3268 Status: RO X-Status: $$$$ X-UID: 0000000001 I'm sponsoring this familiarity case for Andre Molyneux. The requested release binding is minor. The man pages have been posted in the materials directory. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: idzebra 1.2. Name of Document Author/Supplier: Author: Andre Molyneux 1.3 Date of This Document: 07 August, 2009 4. Technical Description Summary ======= Zebra[1] is a high-performance, general-purpose structured text indexing and retrieval engine. It reads structured records in a variety of input formats (eg. email, XML, MARC) and allows access to them through exact boolean search expressions and relevance-ranked free-text queries. Zebra can be used standalone or by other applications. The Koha[2] Integrated Library System (ILS) uses the ID Zebra search engine to provide an open source ILS solution for many libraries. Koha will be ported to OpenSolaris to give more access to the Library of Congress catalog on OpenSolaris platforms used by libraries around the world. Zebra supports large databases (more than ten gigabytes of data, tens of millions of records). It supports incremental, safe database updates on live systems. You can access data stored in Zebra using a variety of Index Data tools (eg. YAZ and PHP/YAZ) as well as commercial and freeware Z39.50 clients and toolkits. Index Data Zebra 2.0.40 will be integrated into the SFW consolidation as part of this proposal, and will be installed as SUNWidzebra. This project requests a minor release binding. Dependencies ============ SUNWlibyaz Interfaces ========== Exported Interfaces Classification Comment ------------------- -------------- ------- SUNWidzebra Uncommitted Package /usr/bin/zebraidx Uncommitted Command /usr/bin/zebrasrv Uncommitted Command /usr/bin/idzebra-config Uncommitted Config Script /usr/include/idzebra-2.0/ Uncommitted Include Files /usr/share/aclocal/idzebra-2.0.m4 Uncommitted Autoconf macro /usr/lib/libidzebra-2.0.so Uncommitted Symlink /usr/lib/libidzebra-2.0.so.0 Uncommitted Symlink /usr/lib/libidzebra-2.0.so.0.0.1 Uncommitted 32bit Library /usr/lib/64/libidzebra-2.0.so Uncommitted Symlink /usr/lib/64/libidzebra-2.0.so.0 Uncommitted Symlink /usr/lib/64/libidzebra-2.0.so.0.0.1 Uncommitted 64bit Library *64 = amd64 | sparcv9 Imported Interfaces Classification Comment ------------------- -------------- --------------------------- SUNWlibyaz Uncommitted Z39.50/SRW/SRU programmer's toolkit Project Private =============== /usr/share/doc/idzebra-2.0/ Documenation /usr/share/idzebra-2.0/ Other Files /usr/share/idzebra-2.0/idzebra-2.0-examples Examples /usr/lib/idzebra-2.0/modules Plugin Modules Reference Documents =================== [1] http://www.indexdata.com/zebra [2] http://koha.org/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Mon Aug 10 02:05:26 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7A95PCP004865 for ; Mon, 10 Aug 2009 02:05:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7A95K3d021341 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 10 Aug 2009 10:05:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO500B0BL91BD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 02:05:25 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO5003JZL90R770@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 02:05:24 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7A95M4G025389 for ; Mon, 10 Aug 2009 09:05:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO500L00KYSCB00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 10:05:13 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO500LGZL8NSC90@fe-emea-10.sun.com>; Mon, 10 Aug 2009 10:05:12 +0100 (BST) Date: Mon, 10 Aug 2009 10:05:04 +0100 From: Darren J Moffat Subject: Re: idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009] In-reply-to: <200908080238.n782csaf003040@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: James Walker Cc: PSARC-ext@sun.com, Andre.Molyneux@sun.com Message-id: <4A7FE2C0.9060203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908080238.n782csaf003040@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Content-Length: 1003 Status: RO X-Status: $$$$ X-UID: 0000000002 James Walker wrote: > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > idzebra > 1.2. Name of Document Author/Supplier: > Author: Andre Molyneux > 1.3 Date of This Document: > 07 August, 2009 > 4. Technical Description > > Summary > ======= > Zebra[1] is a high-performance, general-purpose structured text indexing > and retrieval engine. It reads structured records in a variety of input > formats (eg. email, XML, MARC) and allows access to them through exact > boolean search expressions and relevance-ranked free-text queries. It is a little unfortunate that we already have usr/sbin/zebra that is nothing to do with this. However I don't beleive any changes to this case are required as a result of that since there is not path name conflicts even though there are similar ones /usr/sbin/zebra vs /usr/bin/zebrasrv. -- Darren J Moffat From James.Walker@sun.com Mon Aug 10 10:53:45 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7AHrim5021351 for ; Mon, 10 Aug 2009 10:53:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7AHrcoo029872 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Aug 2009 01:53:44 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO600M0J9PIDT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 10:53:42 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO600LA09PH3M10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 10:53:41 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7AHrfZW004485 for ; Mon, 10 Aug 2009 17:53:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO6002009L5D200@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 11:53:41 -0600 (MDT) Received: from [172.20.25.153] ([unknown] [172.20.25.153]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO600EYF9OZ1N40@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 10 Aug 2009 11:53:23 -0600 (MDT) Date: Mon, 10 Aug 2009 12:14:08 -0600 From: Jim Walker Subject: Re: idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009] In-reply-to: <4A7FE2C0.9060203@Sun.COM> Sender: James.Walker@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com, Andre.Molyneux@sun.com Reply-to: James.Walker@sun.com Message-id: <4A806370.5060402@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908080238.n782csaf003040@sac.sfbay.sun.com> <4A7FE2C0.9060203@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Content-Length: 498 Status: RO X-Status: $$$$ X-UID: 0000000003 Darren J Moffat wrote: > > It is a little unfortunate that we already have usr/sbin/zebra that is > nothing to do with this. However I don't beleive any changes to this case > are required as a result of that since there is not path name conflicts even > though there are similar ones /usr/sbin/zebra vs /usr/bin/zebrasrv. Right. We considered this. There aren't any namespace conflicts with the current zebra package and the names used in this case are still the "familiar" ones. Cheers, Jim From glenn.skinner@sun.com Wed Aug 12 11:23:57 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CINu4M013994 for ; Wed, 12 Aug 2009 11:23:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7CINos6025923 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Aug 2009 19:23:55 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA00C0D0FTDD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 11:23:53 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA00CS40FS8100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 11:23:52 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7CINqmU054296; Wed, 12 Aug 2009 11:23:52 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7CIGMfv003468; Wed, 12 Aug 2009 11:16:22 -0700 (PDT) Date: Wed, 12 Aug 2009 11:16:22 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/424 [idzebra] To: PSARC-ext@sun.com, jw137282@sac.sfbay.sun.com Cc: Andre.Molyneux@sun.com Reply-to: Glenn Skinner Message-id: <200908121816.n7CIGMfv003468@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: qMZkV/53uLzwg1cwEJw+6Q== X-PMX-Version: 5.4.1.325704 Content-Length: 1258 Status: RO X-Status: $$$$ X-UID: 0000000004 Following up on discussion during today's PSARC meeting... Date: Fri, 07 Aug 2009 19:38:54 -0700 (PDT) From: James Walker Subject: idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009] ... Interfaces ========== Exported Interfaces Classification Comment ------------------- -------------- ------- SUNWidzebra Uncommitted Package /usr/bin/zebraidx Uncommitted Command /usr/bin/zebrasrv Uncommitted Command /usr/bin/idzebra-config Uncommitted Config Script /usr/include/idzebra-2.0/ Uncommitted Include Files /usr/share/aclocal/idzebra-2.0.m4 Uncommitted Autoconf macro /usr/lib/libidzebra-2.0.so Uncommitted Symlink /usr/lib/libidzebra-2.0.so.0 Uncommitted Symlink /usr/lib/libidzebra-2.0.so.0.0.1 Uncommitted 32bit Library /usr/lib/64/libidzebra-2.0.so Uncommitted Symlink /usr/lib/64/libidzebra-2.0.so.0 Uncommitted Symlink /usr/lib/64/libidzebra-2.0.so.0.0.1 Uncommitted 64bit Library Is zebrasrv a daemon that idzebra users wouldn't ordinarily start by hand? If so, then it ought to live in /usr/lib rather than in /usr/bin. -- Glenn From Andre.Molyneux@sun.com Wed Aug 12 13:45:26 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CKjQnM021359 for ; Wed, 12 Aug 2009 13:45:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7CKjPqh065483 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Aug 2009 14:45:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA00A076ZPFP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 13:45:25 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA009QO6ZOO120@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 13:45:24 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7CKjNh2025106; Wed, 12 Aug 2009 20:45:23 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOA001006GXFR00@mail-amer.sun.com>; Wed, 12 Aug 2009 14:45:23 -0600 (MDT) Received: from [172.20.25.53] ([unknown] [172.20.25.53]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOA007AH6ZH9930@mail-amer.sun.com>; Wed, 12 Aug 2009 14:45:17 -0600 (MDT) Date: Wed, 12 Aug 2009 14:45:17 -0600 From: Andre Molyneux Subject: Re: 2009/424 [idzebra] In-reply-to: <200908121816.n7CIGMfv003468@ivrel.sfbay.sun.com> Sender: Andre.Molyneux@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, jw137282@sac.sfbay.sun.com Message-id: <4A8329DD.50203@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_0gHGocca340JlAS0KR0Fqg)" X-PMX-Version: 5.4.1.325704 References: <200908121816.n7CIGMfv003468@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 26632 This is a multi-part message in MIME format. --Boundary_(ID_0gHGocca340JlAS0KR0Fqg) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Glenn Skinner wrote: > > Is zebrasrv a daemon that idzebra users wouldn't ordinarily start by > hand? If so, then it ought to live in /usr/lib rather than in > /usr/bin. Apparently it can be either. The zebrasrv man page states: zebrasrv is the Z39.50 and SRU frontend server for the Zebra search engine and indexer. On Unix you can run the zebrasrv server from the command line - and put it in the background. It may also operate under the inet daemon. Full man page attached for context. Regards, Andre --Boundary_(ID_0gHGocca340JlAS0KR0Fqg) Content-type: text/plain; name=zebrasrv_man Content-transfer-encoding: 7BIT Content-disposition: inline; filename=zebrasrv_man Maintenance Procedures ZEBRASRV(8) NAME zebrasrv - Zebra Server SYNOPSIS zebrasrv [-install] [-installa] [-remove] [-a file] [-v level] [-l file] [-u uid] [-c config] [-f vconfig] [-C fname] [-t minutes] [-k kilobytes] [-d daemon] [-w dir] [-p pidfile] [-ziDST1] [listener-spec...] DESCRIPTION Zebra is a high-performance, general-purpose structured text indexing and retrieval engine. It reads structured records in a variety of input formats (eg. email, XML, MARC) and allows access to them through exact boolean search expressions and relevance-ranked free-text queries. zebrasrv is the Z39.50 and SRU frontend server for the Zebra search engine and indexer. On Unix you can run the zebrasrv server from the command line - and put it in the background. It may also operate under the inet daemon. On WIN32 you can run the server as a console application or as a WIN32 Service. OPTIONS The options for zebrasrv are the same as those for YAZ' yaz-ztest. Option -c specifies a Zebra configuration file - if omitted zebra.cfg is read. -a file Specify a file for dumping PDUs (for diagnostic purposes). The special name - (dash) sends output to stderr. -S Don't fork or make threads on connection requests. This is good for debugging, but not recommended for real operation: Although the server is asynchronous and non-blocking, it can be nice to keep a software malfunction (okay then, a crash) from affecting all current users. The server can only accept a single connection in this mode. -1 Like -S but after one session the server exits. This mode is for debugging only. -T Operate the server in threaded mode. The server creates a thread for each connection rather than a fork a process. Only available on UNIX systems that offers zebra 2.0.40 Last change: 07/13/2009 1 Maintenance Procedures ZEBRASRV(8) POSIX threads. -s Use the SR protocol (obsolete). -z Use the Z39.50 protocol (default). This option and -s complement each other. You can use both multiple times on the same command line, between listener-specifications (see below). This way, you can set up the server to listen for connections in both protocols concurrently, on different local ports. -l file Specify an output file for the diagnostic messages. The default is to write this information to stderr -c config-file Read configuration information from config-file. The default configuration is ./zebra.cfg -f vconfig This specifies an XML file that describes one or more YAZ frontend virtual servers. See section VIRTUAL HOSTS for details. -C fname Sets SSL certificate file name for server (PEM). -v level The log level. Use a comma-separated list of members of the set {fatal,debug,warn,log,malloc,all,none}. -u uid Set user ID. Sets the real UID of the server process to that of the given user. It's useful if you aren't comfortable with having the server run as root, but you need to start it as such to bind a privileged port. -w working-directory The server changes to this working directory during before listening on incoming connections. This option is useful when the server is operating from the inetd daemon (see -i). -p pidfile Specifies that the server should write its Process ID to file given by pidfile. A typical location would be /var/run/zebrasrv.pid. -i Use this to make the the server run from the inetd zebra 2.0.40 Last change: 07/13/2009 2 Maintenance Procedures ZEBRASRV(8) server (UNIX only). Make sure you use the logfile option -l in conjunction with this mode and specify the -l option before any other options. -D Use this to make the server put itself in the background and run as a daemon. If neither -i nor -D is given, the server starts in the foreground. -install Use this to install the server as an NT service (Windows NT/2000/XP only). Control the server by going to the Services in the Control Panel. -installa Use this to install and activate the server as an NT service (Windows NT/2000/XP only). Control the server by going to the Services in the Control Panel. -remove Use this to remove the server from the NT services (Windows NT/2000/XP only). -t minutes Idle session timeout, in minutes. Default is 60 minutes. -k size Maximum record size/message size, in kilobytes. Default is 1024 KB (1 MB). -d daemon Set name of daemon to be used in hosts access file. See hosts_access(5) and tcpd(8). A listener-address consists of an optional transport mode followed by a colon (:) followed by a listener address. The transport mode is either a file system socket unix, a SSL TCP/IP socket ssl, or a plain TCP/IP socket tcp (default). For TCP, an address has the form hostname | IP-number [: portnumber] The port number defaults to 210 (standard Z39.50 port) for privileged users (root), and 9999 for normal users. The special hostname "@" is mapped to the address INADDR_ANY, which causes the server to listen on any local interface. The default behavior for zebrasrv - if started as non-priviledged user - is to establish a single TCP/IP listener, for the Z39.50 protocol, on port 9999. zebra 2.0.40 Last change: 07/13/2009 3 Maintenance Procedures ZEBRASRV(8) zebrasrv @ zebrasrv tcp:some.server.name.org:1234 zebrasrv ssl:@:3000 To start the server listening on the registered port for Z39.50, or on a filesystem socket, and to drop root privileges once the ports are bound, execute the server like this from a root shell: zebrasrv -u daemon @ zebrasrv -u daemon tcp:@:210 zebrasrv -u daemon unix:/some/file/system/socket Here daemon is an existing user account, and the unix socket /some/file/system/socket is readable and writable for the daemon account. Z39.50 PROTOCOL SUPPORT AND BEHAVIOR Z39.50 Initialization During initialization, the server will negotiate to version 3 of the Z39.50 protocol, and the option bits for Search, Present, Scan, NamedResultSets, and concurrentOperations will be set, if requested by the client. The maximum PDU size is negotiated down to a maximum of 1 MB by default. Z39.50 Search The supported query type are 1 and 101. All operators are currently supported with the restriction that only proximity units of type "word" are supported for the proximity operator. Queries can be arbitrarily complex. Named result sets are supported, and result sets can be used as operands without limitations. Searches may span multiple databases. The server has full support for piggy-backed retrieval (see also the following section). Z39.50 Present The present facility is supported in a standard fashion. The requested record syntax is matched against the ones supported by the profile of each record retrieved. If no record syntax is given, SUTRS is the default. The requested element set name, again, is matched against any provided by the relevant record profiles. Z39.50 Scan The attribute combinations provided with the termListAndStartPoint are processed in the same way as operands in a query (see above). Currently, only the term and the globalOccurrences are returned with the termInfo structure. zebra 2.0.40 Last change: 07/13/2009 4 Maintenance Procedures ZEBRASRV(8) Z39.50 Sort Z39.50 specifies three different types of sort criteria. Of these Zebra supports the attribute specification type in which case the use attribute specifies the "Sort register". Sort registers are created for those fields that are of type "sort" in the default.idx file. The corresponding character mapping file in default.idx specifies the ordinal of each character used in the actual sort. Z39.50 allows the client to specify sorting on one or more input result sets and one output result set. Zebra supports sorting on one result set only which may or may not be the same as the output result set. Z39.50 Close If a Close PDU is received, the server will respond with a Close PDU with reason=FINISHED, no matter which protocol version was negotiated during initialization. If the protocol version is 3 or more, the server will generate a Close PDU under certain circumstances, including a session timeout (60 minutes by default), and certain kinds of protocol errors. Once a Close PDU has been sent, the protocol association is considered broken, and the transport connection will be closed immediately upon receipt of further data, or following a short timeout. Z39.50 Explain Zebra maintains a "classic" Z39.50 Explain[1] database on the side. This database is called IR-Explain-1 and can be searched using the attribute set exp-1. The records in the explain database are of type grs.sgml. The root element for the Explain grs.sgml records is explain, thus explain.abs is used for indexing. Note Zebra must be able to locate explain.abs in order to index the Explain records properly. Zebra will work without it but the information will not be searchable. THE SRU SERVER In addition to Z39.50, Zebra supports the more recent and web-friendly IR protocol SRU[2]. SRU can be carried over SOAP or a REST-like protocol that uses HTTP GET or POST to request search responses. The request itself is made of parameters such as query, startRecord, maximumRecords and recordSchema; the response is an XML document containing hit-count, result-set records, diagnostics, etc. SRU can be thought of as a re-casting of Z39.50 semantics in web-friendly terms; or as a standardisation of the ad-hoc query parameters used by search engines such as Google and zebra 2.0.40 Last change: 07/13/2009 5 Maintenance Procedures ZEBRASRV(8) AltaVista; or as a superset of A9's OpenSearch (which it predates). Zebra supports Z39.50, SRU GET, SRU POST, SRU SOAP (SRW) - on the same port, recognising what protocol is used by each incoming requests and handling them accordingly. This is a achieved through the use of Deep Magic; civilians are warned not to stand too close. Running zebrasrv as an SRU Server Because Zebra supports all protocols on one port, it would seem to follow that the SRU server is run in the same way as the Z39.50 server, as described above. This is true, but only in an uninterestingly vacuous way: a Zebra server run in this manner will indeed recognise and accept SRU requests; but since it doesn't know how to handle the CQL queries that these protocols use, all it can do is send failure responses. Note It is possible to cheat, by having SRU search Zebra with a PQF query instead of CQL, using the x-pquery parameter instead of query. This is a non-standard extension of CQL, and a very naughty thing to do, but it does give you a way to see Zebra serving SRU ``right out of the box''. If you start your favourite Zebra server in the usual way, on port 9999, then you can send your web browser to: http://localhost:9999/Default?version=1.1 &operation=searchRetrieve &x-pquery=mineral &startRecord=1 &maximumRecords=1 This will display the XML-formatted SRU response that includes the first record in the result-set found by the query mineral. (For clarity, the SRU URL is shown here broken across lines, but the lines should be joined to gether to make single-line URL for the browser to submit.) In order to turn on Zebra's support for CQL queries, it's necessary to have the YAZ generic front-end (which Zebra uses) translate them into the Z39.50 Type-1 query format that is used internally. And to do this, the generic front-end's own configuration file must be used. See the section called YAZ SERVER VIRTUAL HOSTS; the salient point for SRU support is that zebrasrv must be started with the -f frontendConfigFile option rather than the -c zebraConfigFile option, and that the front-end configuration file must include both a reference to the zebra 2.0.40 Last change: 07/13/2009 6 Maintenance Procedures ZEBRASRV(8) Zebra configuration file and the CQL-to-PQF translator configuration file. A minimal front-end configuration file that does this would read as follows: zebra.cfg ../../tab/pqf.properties The element contains the name of the Zebra configuration file that was previously specified by the -c command-line argument, and the element contains the name of the CQL properties file specifying how various CQL indexes, relations, etc. are translated into Type-1 queries. A zebra server running with such a configuration can then be queried using proper, conformant SRU URLs with CQL queries: http://localhost:9999/Default?version=1.1 &operation=searchRetrieve &query=title=utah and description=epicent* &startRecord=1 &maximumRecords=1 SRU PROTOCOL SUPPORT AND BEHAVIOR Zebra running as an SRU server supports SRU version 1.1, including CQL version 1.1. In particular, it provides support for the following elements of the protocol. SRU Search and Retrieval Zebra supports the SRU searchRetrieve[3] operation. One of the great strengths of SRU is that it mandates a standard query language, CQL, and that all conforming implementations can therefore be trusted to correctly interpret the same queries. It is with some shame, then, that we admit that Zebra also supports an additional query language, our own Prefix Query Format (PQF[4]). A PQF query is submitted by using the extension parameter x-pquery, in which case the query parameter must be omitted, which makes the request not valid SRU. Please feel free to use this facility within your own applications; but be aware that it is not only non-standard SRU but not even syntactically valid, since it omits the mandatory query parameter. zebra 2.0.40 Last change: 07/13/2009 7 Maintenance Procedures ZEBRASRV(8) SRU Scan Zebra supports SRU scan[5] operation. Scanning using CQL syntax is the default, where the standard scanClause parameter is used. In addition, a mutant form of SRU scan is supported, using the non-standard x-pScanClause parameter in place of the standard scanClause to scan on a PQF query clause. SRU Explain Zebra supports SRU explain[6]. The ZeeRex record explaining a database may be requested either with a fully fledged SRU request (with operation=explain and version-number specified) or with a simple HTTP GET at the server's basename. The ZeeRex record returned in response is the one embedded in the YAZ Frontend Server configuration file that is described in the the section called YAZ SERVER VIRTUAL HOSTS. Unfortunately, the data found in the CQL-to-PQF text file must be added by hand-craft into the explain section of the YAZ Frontend Server configuration file to be able to provide a suitable explain record. Too bad, but this is all extreme new alpha stuff, and a lot of work has yet to be done .. There is no linkeage whatsoever between the Z39.50 explain model and the SRU explain response (well, at least not implemented in Zebra, that is ..). Zebra does not provide a means using Z39.50 to obtain the ZeeRex record. Other SRU operations In the Z39.50 protocol, Initialization, Present, Sort and Close are separate operations. In SRU, however, these operations do not exist. o SRU has no explicit initialization handshake phase, but commences immediately with searching, scanning and explain operations. o Neither does SRU have a close operation, since the protocol is stateless and each request is self-contained. (It is true that multiple SRU request/response pairs may be implemented as multiple HTTP request/response pairs over a single persistent TCP/IP connection; but the closure of that connection is not a protocol-level operation.) o Retrieval in SRU is part of the searchRetrieve operation, in which a search is submitted and the response includes a subset of the records in the result set. There is no direct analogue of Z39.50's Present zebra 2.0.40 Last change: 07/13/2009 8 Maintenance Procedures ZEBRASRV(8) operation which requests records from an established result set. In SRU, this is achieved by sending a subsequent searchRetrieve request with the query cql.resultSetId=id where id is the identifier of the previously generated result-set. o Sorting in CQL is done within the searchRetrieve operation - in v1.1, by an explicit sort parameter, but the forthcoming v1.2 or v2.0 will most likely use an extension of the query language, CQL sorting[7]. It can be seen, then, that while Zebra operating as an SRU server does not provide the same set of operations as when operating as a Z39.50 server, it does provide equivalent functionality. SRU EXAMPLES Surf into http://localhost:9999 to get an explain response, or use http://localhost:9999/?version=1.1&operation=explain See number of hits for a query http://localhost:9999/?version=1.1&operation=searchRetrieve &query=text=(plant%20and%20soil) Fetch record 5-7 in Dublin Core format http://localhost:9999/?version=1.1&operation=searchRetrieve &query=text=(plant%20and%20soil) &startRecord=5&maximumRecords=2&recordSchema=dc Even search using PQF queries using the extended naughty parameter x-pquery http://localhost:9999/?version=1.1&operation=searchRetrieve &x-pquery=@attr%201=text%20@and%20plant%20soil Or scan indexes using the extended extremely naughty parameter x-pScanClause http://localhost:9999/?version=1.1&operation=scan &x-pScanClause=@attr%201=text%20something Don't do this in production code! But it's a great fast zebra 2.0.40 Last change: 07/13/2009 9 Maintenance Procedures ZEBRASRV(8) debugging aid. YAZ SERVER VIRTUAL HOSTS The Virtual hosts mechanism allows a YAZ frontend server to support multiple backends. A backend is selected on the basis of the TCP/IP binding (port+listening adddress) and/or the virtual host. A backend can be configured to execute in a particular working directory. Or the YAZ frontend may perform CQL[8] to RPN conversion, thus allowing traditional Z39.50 backends to be offered as a SRU[2] service. SRU Explain information for a particular backend may also be specified. For the HTTP protocol, the virtual host is specified in the Host header. For the Z39.50 protocol, the virtual host is specified as in the Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1. Note Not all Z39.50 clients allows the VHOST information to be set. For those the selection of the backend must rely on the TCP/IP information alone (port and address). The YAZ frontend server uses XML to describe the backend configurations. Command-line option -f specifies filename of the XML configuration. The configuration uses the root element yazgfs. This element includes a list of listen elements, followed by one or more server elements. The listen describes listener (transport end point), such as TCP/IP, Unix file socket or SSL server. Content for a listener: CDATA (required) The CDATA for the listen element holds the listener string, such as tcp:@:210, tcp:server1:2100, etc. attribute id (optional) identifier for this listener. This may be referred to from server sections. Note We expect more information to be added for the listen section in a future version, such as CERT file for SSL servers. zebra 2.0.40 Last change: 07/13/2009 10 Maintenance Procedures ZEBRASRV(8) The server describes a server and the parameters for this server type. Content for a server: attribute id (optional) Identifier for this server. Currently not used for anything, but it might be for logging purposes. attribute listenref (optional) Specifies listener for this server. If this attribute is not given, the server is accessible from all listener. In order for the server to be used for real, howeever, the virtual host must match (if specified in the configuration). element config (optional) Specifies the server configuration. This is equivalent to the config specified using command line option -c. element directory (optional) Specifies a working directory for this backend server. If specifid, the YAZ fronend changes current working directory to this directory whenever a backend of this type is started (backend handler bend_start), stopped (backend handler hand_stop) and initialized (bend_init). element host (optional) Specifies the virtual host for this server. If this is specified a client must specify this host string in order to use this backend. element cql2rpn (optional) Specifies a filename that includes CQL[8] to RPN conversion for this backend server. See CQL[8] section in YAZ manual. If given, the backend server will only "see" a Type-1/RPN query. element explain (optional) Specifies SRU[2] ZeeRex content for this server - copied verbatim to the client. As things are now, some of the Explain content seems redundant because host information, etc. is also stored elsewhere. The format of the Explain record is described in detail, with examples, on the file at the ZeeRex[9] web-site. The XML below configures a server that accepts connections from two ports, TCP/IP port 9900 and a local UNIX file socket. We name the TCP/IP server public and the other server internal. zebra 2.0.40 Last change: 07/13/2009 11 Maintenance Procedures ZEBRASRV(8) tcp:@:9900 unix:/var/tmp/socket server1.mydomain /var/www/s1 config.cfg server2.mydomain /var/www/s2 config.cfg ../etc/pqf.properties server2.mydomain 9900 a /var/www/s3 config.cfg There are three configured backend servers. The first two servers, "server1" and "server2", can be reached by both listener addresses - since no listenref attribute is specified. In order to distinguish between the two a virtual host has been specified for each of server in the host elements. For "server2" elements for CQL[8] to RPN conversion is supported and explain information has been added (a short one here to keep the example small). The third server, "server3" can only be reached via listener "internal". SEE ALSO zebraidx(1) NOTES 1. Z39.50 Explain http://www.loc.gov/z3950/agency/markup/07.html 2. SRU http://www.loc.gov/standards/sru/ zebra 2.0.40 Last change: 07/13/2009 12 Maintenance Procedures ZEBRASRV(8) 3. SRU searchRetrieve http://www.loc.gov/standards/sru/specs/search-retrieve.html 4. PQF http://www.indexdata.com/yaz/doc/tools.html#PQF 5. SRU scan http://www.loc.gov/standards/sru/specs/scan.html/ 6. SRU explain http://www.loc.gov/standards/sru/specs/explain.html 7. CQL sorting http://zing.z3950.org/cql/sorting.html 8. CQL http://www.loc.gov/standards/sru/specs/cql.html 9. ZeeRex http://explain.z3950.org/ ATTRIBUTES See attributes(5) for descriptions of the following attributes: _______________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE| |_______________________________________ | Availability | SUNWidzebra | |_______________________________________ | Interface Stability| Uncommitted | |____________________|_________________| NOTES Source for idzebra is available on http://opensolaris.org. zebra 2.0.40 Last change: 07/13/2009 13 --Boundary_(ID_0gHGocca340JlAS0KR0Fqg)-- From Nicolas.Williams@sun.com Wed Aug 12 14:43:21 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CLhLUe022785 for ; Wed, 12 Aug 2009 14:43:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7CLhJlY028208; Wed, 12 Aug 2009 15:43:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA002039O8LP00@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Aug 2009 14:43:20 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA00G9B9O7AP80@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Aug 2009 14:43:19 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7CLeARR013192; Wed, 12 Aug 2009 16:40:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CLeAaL013191; Wed, 12 Aug 2009 16:40:10 -0500 (CDT) Date: Wed, 12 Aug 2009 16:40:10 -0500 From: Nicolas Williams Subject: Re: 2009/424 [idzebra] In-reply-to: <4A8329DD.50203@sun.com> To: Andre Molyneux Cc: Glenn Skinner , PSARC-ext@sun.com, jw137282@sac.sfbay.sun.com Message-id: <20090812214010.GM10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908121816.n7CIGMfv003468@ivrel.sfbay.sun.com> <4A8329DD.50203@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 774 On Wed, Aug 12, 2009 at 02:45:17PM -0600, Andre Molyneux wrote: > Glenn Skinner wrote: > > > >Is zebrasrv a daemon that idzebra users wouldn't ordinarily start by > >hand? If so, then it ought to live in /usr/lib rather than in > >/usr/bin. > > Apparently it can be either. The zebrasrv man page states: > > zebrasrv is the Z39.50 and SRU frontend server for the Zebra > search engine and indexer. > > On Unix you can run the zebrasrv server from the command > line - and put it in the background. It may also operate > under the inet daemon. That's also true of sshd*, and many other daemons. What matters is whether users _would_ do that. To me it looks like that's not the case here. [*] Well, one shouldn't start login daemons by hand. From glenn.skinner@sun.com Wed Aug 12 14:49:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CLnFLS022802 for ; Wed, 12 Aug 2009 14:49:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7CLnFcM031746 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Aug 2009 15:49:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA002039Y2ZG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 14:49:14 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA00GWA9Y2AC70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 14:49:14 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7CLnEMr056637; Wed, 12 Aug 2009 14:49:14 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7CLfiOh003874; Wed, 12 Aug 2009 14:41:44 -0700 (PDT) Date: Wed, 12 Aug 2009 14:41:44 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/424 [idzebra] To: Andre.Molyneux@sun.com Cc: PSARC-ext@sun.com, jw137282@sac.sfbay.sun.com Reply-to: Glenn Skinner Message-id: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 79sc8HX01Q+u34Rq6wLdyg== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1498 Date: Wed, 12 Aug 2009 14:45:17 -0600 From: Andre Molyneux Subject: Re: 2009/424 [idzebra] Glenn Skinner wrote: > > Is zebrasrv a daemon that idzebra users wouldn't ordinarily start by > hand? If so, then it ought to live in /usr/lib rather than in > /usr/bin. Apparently it can be either. The zebrasrv man page states: zebrasrv is the Z39.50 SRU frontend server for the Zebra search engine and indexer. On Unix you can run the zebrasrv server from the command line - and put it in the background. It may also operate under the inet daemon. Full man page attached for context. After reading the man page, it looks like zebrasrv is a classic Unix daemon that offers the administrator lots of different ways to configure it and to get it going. If this project were being developed from scratch within {,Open}Solaris, we'd tell you to make the daemon into an SMF service and to use SMF to manage its configuration settings. (And the daemon's file system location would be somewhere within /usr/lib.) Depending on how well-integrated into Solaris you want idzebra to be, you could potentially do this (and offer the changes for Solaris to the upstream developers). But it may not merit this level of effort. (If I were working on this project, I'd at least put zebrasrv into /usr/lib. I won't insist that you do so, though. Other ARC members may have different opinions.) -- Glenn From gdamore@sun.com Wed Aug 12 15:09:28 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CM9SOg023335 for ; Wed, 12 Aug 2009 15:09:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7CM9R4q025978 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Aug 2009 15:09:28 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA00D01AVRHX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 16:09:27 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA00KYGAVR3D90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Aug 2009 16:09:27 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7CM9LN3013501; Wed, 12 Aug 2009 15:09:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOA00J00AVKR500@fe-sfbay-09.sun.com>; Wed, 12 Aug 2009 15:09:21 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOA00CV7AVLQF90@fe-sfbay-09.sun.com>; Wed, 12 Aug 2009 15:09:21 -0700 (PDT) Date: Wed, 12 Aug 2009 15:09:21 -0700 From: "Garrett D'Amore" Subject: Re: 2009/424 [idzebra] In-reply-to: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Glenn Skinner Cc: Andre.Molyneux@sun.com, PSARC-ext@sun.com, jw137282@sac.sfbay.sun.com Message-id: <4A833D91.2010903@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1730 I think that it makes sense to at least *try* to move zebrasrv out of /usr/bin. /usr/lib seems the right place for it. - Garrett Glenn Skinner wrote: > Date: Wed, 12 Aug 2009 14:45:17 -0600 > From: Andre Molyneux > Subject: Re: 2009/424 [idzebra] > Glenn Skinner wrote: > > > > Is zebrasrv a daemon that idzebra users wouldn't ordinarily start by > > hand? If so, then it ought to live in /usr/lib rather than in > > /usr/bin. > > Apparently it can be either. The zebrasrv man page states: > > zebrasrv is the Z39.50 SRU frontend server for the Zebra > search engine and indexer. > > On Unix you can run the zebrasrv server from the command > line - and put it in the background. It may also operate > under the inet daemon. > > Full man page attached for context. > > After reading the man page, it looks like zebrasrv is a classic Unix > daemon that offers the administrator lots of different ways to > configure it and to get it going. > > If this project were being developed from scratch within > {,Open}Solaris, we'd tell you to make the daemon into an SMF service > and to use SMF to manage its configuration settings. (And the > daemon's file system location would be somewhere within /usr/lib.) > > Depending on how well-integrated into Solaris you want idzebra to be, > you could potentially do this (and offer the changes for Solaris to > the upstream developers). > > But it may not merit this level of effort. (If I were working on this > project, I'd at least put zebrasrv into /usr/lib. I won't insist that > you do so, though. Other ARC members may have different opinions.) > > -- Glenn > > From James.Walker@sun.com Fri Aug 14 10:19:35 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EHJZQO022870 for ; Fri, 14 Aug 2009 10:19:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7EHJX5o021543 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 15 Aug 2009 01:19:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00D0HMSJR900@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:19:31 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00LXPMSJRZ90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:19:31 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7EHJVpr015439 for ; Fri, 14 Aug 2009 17:19:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOD00N00MPG4W00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:19:31 -0600 (MDT) Received: from c-67-177-238-245.hsd1.co.comcast.net ([unknown] [129.150.220.86]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOD008HWMSIILB0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:19:30 -0600 (MDT) Date: Fri, 14 Aug 2009 11:19:30 -0600 From: Jim Walker Subject: Re: 2009/424 [idzebra] In-reply-to: <4A833D91.2010903@sun.com> Sender: James.Walker@sun.com To: "Garrett D'Amore" Cc: Andre.Molyneux@sun.com, PSARC-ext@sun.com Reply-to: James.Walker@sun.com Message-id: <4A859CA2.50005@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> <4A833D91.2010903@sun.com> User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) Status: RO Content-Length: 343 Garrett D'Amore wrote: > I think that it makes sense to at least *try* to move zebrasrv out of > /usr/bin. /usr/lib seems the right place for it. Since zebrasrv has good command definition and /usr/bin is the familiar location (ie. I'm not seeing /usr/lib being used anywhere else). I think /usr/bin is the best place for now. Cheers, Jim From Andre.Molyneux@Sun.COM Fri Aug 14 10:24:23 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EHONgJ023163 for ; Fri, 14 Aug 2009 10:24:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EHOMcj021980 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Aug 2009 10:24:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00417N0MQH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 10:24:22 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00MW2N0LYD40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 10:24:21 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7EHOLUF026855 for ; Fri, 14 Aug 2009 17:24:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD00G00MRC5600@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:24:21 -0600 (MDT) Received: from [172.20.25.53] ([unknown] [172.20.25.53]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD00MWNN0LAED0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:24:21 -0600 (MDT) Date: Fri, 14 Aug 2009 11:24:21 -0600 From: Andre Molyneux Subject: Re: 2009/424 [idzebra] In-reply-to: <4A859CA2.50005@sun.com> Sender: Andre.Molyneux@Sun.COM To: James.Walker@Sun.COM Cc: PSARC-ext@Sun.COM Message-id: <4A859DC5.7060303@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> <4A833D91.2010903@sun.com> <4A859CA2.50005@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 551 Jim Walker wrote: > Garrett D'Amore wrote: >> I think that it makes sense to at least *try* to move zebrasrv out of >> /usr/bin. /usr/lib seems the right place for it. > > Since zebrasrv has good command definition and /usr/bin is the > familiar location (ie. I'm not seeing /usr/lib being used anywhere > else). I think /usr/bin is the best place for now. Some consensus here would be helpful. I've moved zebrasrv to /usr/lib in my latest webrev, but can easily put it back. How does it get decided if PSARC as a whole has a preference? Andre From Nicolas.Williams@sun.com Fri Aug 14 10:36:32 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EHaVje023218 for ; Fri, 14 Aug 2009 10:36:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7EHaN92029942; Sat, 15 Aug 2009 01:36:28 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00F19NKSKI00@brm-avmta-1.central.sun.com>; Fri, 14 Aug 2009 11:36:28 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00L9SNKRRUB0@brm-avmta-1.central.sun.com>; Fri, 14 Aug 2009 11:36:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7EHXHxU001601; Fri, 14 Aug 2009 12:33:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7EHXHJI001600; Fri, 14 Aug 2009 12:33:17 -0500 (CDT) Date: Fri, 14 Aug 2009 12:33:17 -0500 From: Nicolas Williams Subject: Re: 2009/424 [idzebra] In-reply-to: <4A859CA2.50005@sun.com> To: Jim Walker Cc: PSARC-ext@sun.com Message-id: <20090814173317.GF1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> <4A833D91.2010903@sun.com> <4A859CA2.50005@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1303 On Fri, Aug 14, 2009 at 11:19:30AM -0600, Jim Walker wrote: > Garrett D'Amore wrote: > >I think that it makes sense to at least *try* to move zebrasrv out of > >/usr/bin. /usr/lib seems the right place for it. > > Since zebrasrv has good command definition and /usr/bin is the > familiar location (ie. I'm not seeing /usr/lib being used anywhere > else). I think /usr/bin is the best place for now. You're not seeing /usr/lib being used anywhere else because putting daemons there is a Solaris-ism. I.e., that's not a good excuse. OTOH, not wanting to bother is a good excuse given that the ARC seems to be OK with that in this case :) Is it the case, perhaps, that moving such things around is difficult for tools like Jucr and roboporter? If so, then that would be a bug in those tools. But perhaps we need to give up on some of these Solaris-isms. I personally don't care for putting so much stuff in /usr/sbin -- most things in /usr/sbin wouldn't cause any problems if they were in /usr/bin instead (and some belong in /usr/lib, since they are daemons). I mean, ping(1M), in /usr/sbin ?! That's just silly, plus we now have fping(1M) in /usr/bin, so we're becoming less and less consistent. Right now we're letting these Solaris-isms rot. That strikes me as not a good idea. Nico -- From glenn.skinner@sun.com Fri Aug 14 10:47:25 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EHlPDE023458 for ; Fri, 14 Aug 2009 10:47:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EHlCUn025305 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Aug 2009 10:47:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00G03O30OW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:47:24 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00LZHO30RRB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 11:47:24 -0600 (MDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7EHlNLx032286; Fri, 14 Aug 2009 10:47:23 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n7EHdsIs005926; Fri, 14 Aug 2009 10:39:54 -0700 (PDT) Date: Fri, 14 Aug 2009 10:39:54 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/424 [idzebra] To: James.Walker@sun.com, Andre.Molyneux@sun.com Cc: PSARC-ext@sun.com Reply-to: Glenn Skinner Message-id: <200908141739.n7EHdsIs005926@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: YYsgkCEs6dzDxEc0lTqYzQ== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1424 Date: Fri, 14 Aug 2009 11:24:21 -0600 From: Andre Molyneux Subject: Re: 2009/424 [idzebra] Jim Walker wrote: > Garrett D'Amore wrote: >> I think that it makes sense to at least *try* to move zebrasrv out of >> /usr/bin. /usr/lib seems the right place for it. > > Since zebrasrv has good command definition and /usr/bin is the > familiar location (ie. I'm not seeing /usr/lib being used anywhere > else). I think /usr/bin is the best place for now. Some consensus here would be helpful. I've moved zebrasrv to /usr/lib in my latest webrev, but can easily put it back. How does it get decided if PSARC as a whole has a preference? The project team takes PSARC's comments into account and updates the project specification (if necessary) to state where it is proposed to place zebrasrv. Then if any committee member feels strongly enough that that proposed location is architecturally flawed, that member will derail the case. If that happens, then the committee, project team, and other interested parties will discuss the issue until resolution occurs (probably during a meeting, so that everybody's time is used as efficiently as possible). But having said all that, I think what you're hearing is advice from various committee members that doesn't reach the level of derailment. (That's certainly true of me, for one.) -- Glenn From carlsonj@workingcode.com Fri Aug 14 11:31:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EIVH7e024530 for ; Fri, 14 Aug 2009 11:31:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7EIV9LD007595; Fri, 14 Aug 2009 19:31:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00909Q41C900@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Aug 2009 11:31:13 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00M59Q40YAB0@nwk-avmta-2.sfbay.sun.com>; Fri, 14 Aug 2009 11:31:13 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7EIR7mK010725; Fri, 14 Aug 2009 18:31:12 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-175909; Fri, 14 Aug 2009 18:31:11 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-52451339; Fri, 14 Aug 2009 18:31:09 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-3140791; Fri, 14 Aug 2009 18:29:44 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n7EITOrd001959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 14:29:24 -0400 (EDT) Date: Fri, 14 Aug 2009 14:29:23 -0400 From: James Carlson Subject: Re: 2009/424 [idzebra] In-reply-to: <4A859DC5.7060303@sun.com> To: Andre Molyneux Cc: James.Walker@sun.com, PSARC-ext@sun.com Message-id: <4A85AD03.2060300@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-EATSERVER-Metrics: carlson 1166; Body=3 Fuz1=3 Fuz2=3 X-Antispam: No, score=-0.2/5.0, scanned in 0.536sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908122141.n7CLfiOh003874@ivrel.sfbay.sun.com> <4A833D91.2010903@sun.com> <4A859CA2.50005@sun.com> <4A859DC5.7060303@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1538 Andre Molyneux wrote: > Jim Walker wrote: >> Garrett D'Amore wrote: >>> I think that it makes sense to at least *try* to move zebrasrv out of >>> /usr/bin. /usr/lib seems the right place for it. >> >> Since zebrasrv has good command definition and /usr/bin is the >> familiar location (ie. I'm not seeing /usr/lib being used anywhere >> else). I think /usr/bin is the best place for now. > > Some consensus here would be helpful. I've moved zebrasrv to /usr/lib > in my latest webrev, but can easily put it back. /usr/lib is the right spot for daemons on Solaris that are not intended to be invoked directly by users of any sort. /usr/sbin would be right if it were intended to be invoked directly by an administrator from the command line. /usr/bin is for things invoked by "ordinary users." We use /usr/lib the way some other systems use /usr/libexec. (In case you're looking for precedent or "familiarity.") I think you're getting fairly clear advice on that. The only real problem is that it's not very strong advice. In other words, not many care too much. > How does it get > decided if PSARC as a whole has a preference? PSARC is inanimate. It doesn't have preferences. The members do, and you can ask them what they prefer. If you want to be formal about it, ask to have the case derailed so that the PSARC members can go on record with an explicit vote (rather than just letting the case time out, as fast-tracks are supposed to do). -- James Carlson 42.703N 71.076W From gdamore@sun.com Sun Aug 16 00:25:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7G7PXtv001191 for ; Sun, 16 Aug 2009 00:25:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7G7PX5k035812 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 16 Aug 2009 01:25:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOG00801KML0R00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 16 Aug 2009 00:25:33 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOG00MJOKMK1940@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 16 Aug 2009 00:25:33 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7G7PRbK005203; Sun, 16 Aug 2009 00:25:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOG00300KE8V500@fe-sfbay-10.sun.com>; Sun, 16 Aug 2009 00:25:27 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOG00B6PKMEE360@fe-sfbay-10.sun.com>; Sun, 16 Aug 2009 00:25:27 -0700 (PDT) Date: Sun, 16 Aug 2009 00:25:26 -0700 From: "Garrett D'Amore" Subject: Re: 2009/424 [idzebra] In-reply-to: <200908141739.n7EHdsIs005926@ivrel.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Glenn Skinner Cc: James.Walker@sun.com, Andre.Molyneux@sun.com, PSARC-ext@sun.com Message-id: <4A87B466.5@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908141739.n7EHdsIs005926@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2541 Glenn Skinner wrote: > Date: Fri, 14 Aug 2009 11:24:21 -0600 > From: Andre Molyneux > Subject: Re: 2009/424 [idzebra] > > Jim Walker wrote: > > Garrett D'Amore wrote: > >> I think that it makes sense to at least *try* to move zebrasrv out of > >> /usr/bin. /usr/lib seems the right place for it. > > > > Since zebrasrv has good command definition and /usr/bin is the > > familiar location (ie. I'm not seeing /usr/lib being used anywhere > > else). I think /usr/bin is the best place for now. > > Some consensus here would be helpful. I've moved zebrasrv to > /usr/lib in my latest webrev, but can easily put it back. How > does it get decided if PSARC as a whole has a preference? > > The project team takes PSARC's comments into account and updates the > project specification (if necessary) to state where it is proposed to > place zebrasrv. > > Then if any committee member feels strongly enough that that proposed > location is architecturally flawed, that member will derail the case. > If that happens, then the committee, project team, and other > interested parties will discuss the issue until resolution occurs > (probably during a meeting, so that everybody's time is used as > efficiently as possible). > > But having said all that, I think what you're hearing is advice from > various committee members that doesn't reach the level of derailment. > (That's certainly true of me, for one.) > Yes, I think that's true. The comments from Jim have been answered -- in general in Linux land there is /usr/libexec for things that are run by something other than normal users or normal administrators. (Network daemons are normally a good example of this -- for example /usr/lib/inet/in.dhcpd. An administrator might choose to run this command manually, but that would not be the norm, and would probably only be used for debugging.) In Solaris, we don't have /usr/libexec, we just put such things in /usr/lib. /usr/sbin/ is used for utilities that an administrator might be expected to run but which ordinary users shouldn't care about. Its kind of a gray area. My preference is that if the utility would only ever be run by an administrator to debug a service, or to start up something manually that should have been started by SMF, then /usr/lib is probably better. If it is a reasonable thing that administrators might need to run this command manually, then /usr/sbin or /usr/bin. - Garrett > -- Glenn > > From James.Walker@sun.com Tue Aug 18 09:17:36 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IGHaI0024709 for ; Tue, 18 Aug 2009 09:17:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7IGHX07012605 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Aug 2009 09:17:36 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOK0030XYLA3600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Aug 2009 10:17:34 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOK00GIBYLAZR90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Aug 2009 10:17:34 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IGHXpg022377 for ; Tue, 18 Aug 2009 16:17:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOK00800Y2XC500@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Aug 2009 10:17:33 -0600 (MDT) Received: from [172.20.25.153] ([unknown] [172.20.25.153]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOK003HXYKSA4D0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 18 Aug 2009 10:17:20 -0600 (MDT) Date: Tue, 18 Aug 2009 10:38:55 -0600 From: Jim Walker Subject: Re: 2009/424 [idzebra] In-reply-to: <4A87B466.5@sun.com> Sender: James.Walker@sun.com To: "Garrett D'Amore" Cc: Andre.Molyneux@sun.com, PSARC-ext@sun.com Reply-to: James.Walker@sun.com Message-id: <4A8AD91F.2060408@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908141739.n7EHdsIs005926@ivrel.sfbay.sun.com> <4A87B466.5@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 594 Garrett D'Amore wrote: > > My preference is that if the utility would only ever be run by an > administrator to debug a service, or to start up something manually that > should have been started by SMF, then /usr/lib is probably better. If > it is a reasonable thing that administrators might need to run this > command manually, then /usr/sbin or /usr/bin. Thanks to everyone providing input on this. When I get some time (ha) I may take a stab at improving the target directory mapping information. Based on this input. The project team will locate zebrasrv in /usr/bin. Cheers, Jim From James.Walker@sun.com Tue Aug 18 10:24:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IHOXMC028077 for ; Tue, 18 Aug 2009 10:24:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IHOOsv012920 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 18 Aug 2009 18:24:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL001051OUCM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 18 Aug 2009 10:24:30 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL005QA1OTH8B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 18 Aug 2009 10:24:29 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IHOTsX006906 for ; Tue, 18 Aug 2009 17:24:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00L000ZFNM00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 18 Aug 2009 11:24:29 -0600 (MDT) Received: from [172.20.25.153] ([unknown] [172.20.25.153]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL00KO21OANJE0@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 18 Aug 2009 11:24:16 -0600 (MDT) Date: Tue, 18 Aug 2009 11:45:49 -0600 From: Jim Walker Subject: Re: idzebra [PSARC/2009/424 FastTrack timeout 08/14/2009] In-reply-to: <200908080238.n782csaf003040@sac.sfbay.sun.com> Sender: James.Walker@sun.com To: PSARC-ext@sun.com Cc: Andre.Molyneux@sun.com Reply-to: James.Walker@sun.com Message-id: <4A8AE8CD.9000807@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908080238.n782csaf003040@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 130 The timeout for this case has been reached and all issues have been resolved. I'm marking this case closed approved. Cheers, Jim