अन्य एपीआई और प्रोटोकॉल
SIP2
एसआईपी 2 (सत्र आरंभ प्रोटोकॉल) उपकरणों के बीच संचार के लिए एक प्रोटोकॉल है।
कोहा एसआईपी 2 के संदर्भ में सेल्फ चेक (एससी) मशीनों यानी स्वयं चेकआउट मशीनों के बीच संचार के लिए प्रयोग किया जाता है, और स्वचालित परिसंचरण प्रणाली (जिसे एसीएस भी कहा जाता है जो इस मामले में सर्वर कोहा चला रहा है)।
एसआईपी 2 संचार में अनुरोध और प्रतिक्रियाएं शामिल हैं।
स्वयं चेकआउट मशीन ‘गूंगा ‘ हैं और इसलिए वे कोहा सर्वर को अनुरोध भेजते हैं जो तर्क चलाता है जो एक विशेष परिणाम निर्धारित करता है जिसे क्लाइंट सेल्फ चेकआउट मशीन पर प्रतिक्रिया संदेश के रूप में भेजा जाता है, और फिर इसे उपयोगकर्ता को बताया जाता है।
चेतावनी
SIP2 सेवा का उपयोग करने के संबंध में सुरक्षा सूचना: यह सुनिश्चित करने के लिए कि आपका SIP2 ट्रैफ़िक सुरक्षित है क्योंकि यह इंटरनेट पर गुजरता है, आपको यह सुनिश्चित करने की आवश्यकता है कि आप वीपीएन या स्टनलाइन का उपयोग कर रहे हैं।
एसआईपी 2 स्थापित करना
यदि आपने डेबियन पैकेज का उपयोग करके कोहा स्थापित किया है तो एसआईपी 2 सेटअप आसान है, बस इन चरणों का पालन करें:
1. In your terminal (in the root Koha directory) write in: sudo koha-enable-sip <instancename>
2. Now you need to configure the SIP2 settings, to do this you need to edit the SIPconfig.xml file which exists in the /etc/koha/sites/<instancename>/ directory. You will need to edit this file as root because it contains passwords (to do so write ‘sudo’ at the start of your command).
e.g. sudo vi /etc/koha/sites/<instancename>/SIPconfig.xml
टिप्पणी
महत्वपूर्ण नोट: SIPconfig.xml फ़ाइल में रुचि के तीन क्षेत्र हैं जिन्हें आपको बदलने की आवश्यकता है। ये हैं: सेवा, खाता और संस्था।
सेवाएँ
2.1 SIPconfig.xml फ़ाइल के शीर्ष के पास पोर्ट मान बदलें (नीचे स्क्रीन शॉट में नंबर 1 द्वारा पहचाना गया), इसलिए इसमें एक ही आईपी पता है जो SIPconfig.xml फ़ाइल को 2 से नीचे सेट किया गया है।
टिप्पणी
सुनिश्चित करें कि दो पोर्ट मानों में एक ही पोर्ट नंबर नहीं है क्योंकि आपके पास दो अलग-अलग सेवाओं द्वारा समान पोर्ट नहीं सुना जा सकता है। पोर्ट नंबर पर निर्णय लेने पर सुनिश्चित करें कि यह एक उच्च संख्या है (यानी 1000 से ऊपर) क्योंकि 1000 से नीचे के सभी बंदरगाहों को रूट अनुमतियों की आवश्यकता होती है।
खाता
SIPconfig.xml फ़ाइल में परिभाषित खाता आप खाते हैं जिन्हें एसआईपी 2 सेवा का उपयोग करने की अनुमति है यानी आप परिभाषित कर रहे हैं कि एसआईपी 2 कमांड कौन भेज सकता है और प्राप्त कर सकता है।
चेतावनी
Account information that you write here must also exist in the Koha database i.e. you need to create a patron in the Koha staff interface with the same username, password (making sure to assign them the circulate permission) as the user account you write into the SIPconfig.xml file.
टिप्पणी
It is highly recommended that you only write in Koha user accounts with the circulate permission.
The reason we want SIP2 users to only have the circulate permission rather than the superlibrarian permission is to reduce the access SIP2 users have to confidential patron data in case the system was compromised.
If the ACS or the SC were compromised then having all SIP2 users only having the circulate permission means that an intruder would only be able to access patron data via the terminal rather than the web interface as well (which would be available with the superlibrarian permission). So it is simply a matter of protecting your users.
खाता मूल्य परिभाषाएं:
लॉगिन आईडी: यह खाता उपयोगकर्ता नाम है। - तदनुसार इसे संशोधित करें
पासवर्ड: खाता पासवर्ड - तदनुसार इसे संशोधित करें
Delimiter: खाता जानकारी के लिए delimiter के प्रकार - डिफ़ॉल्ट के रूप में छोड़ दें
त्रुटि -पता - डिफ़ॉल्ट के रूप में छोड़ दें
संस्थान: यह पुस्तकालय के लिए शाखा कोड है जिसे उपयोगकर्ता संबंधित है। नोट: इस संस्था को SIPconfig.xml फ़ाइल के संस्थान क्षेत्र में आगे परिभाषित करने की आवश्यकता है और यह कोहा डेटाबेस में भी मौजूद होना चाहिए। यानी आपको कोहा स्टाफ इंटरफ़ेस में एक ही शाखा कोड के साथ लाइब्रेरी बनाने की आवश्यकता है।
एन्कोडिंग: यह मानक डेटा खाता एन्कोड करने के लिए प्रयोग किया जाता है
टर्मिनेटर: इसे एसआईपी 2 सर्वर के टर्मिनेटर मान से मेल खाना चाहिए। - यदि आप SIP2 सर्वर के टर्मिनेटर मान को जानते हैं तो इसे संशोधित करें।
प्रारूप का उपयोग कर एसआईपी 2 प्रोफाइल में कस्टम संरक्षक विशेषताओं को जोड़ना भी संभव है जैसे कि:
<patron_attribute field="XX" code="CODE1" /> <patron_attribute field="XY" code="CODE2" /> <patron_attribute field="XZ" code="CODE3" />
इंस्टीट्यूशन
आपके द्वारा यहां परिभाषित संस्था की जानकारी कोहा स्टाफ इंटरफेस में बनाई गई लाइब्रेरी से मेल खाना चाहिए।
चेतावनी
आपको यह सुनिश्चित करने की ज़रूरत है कि SIPconfig.xml फ़ाइल में आगे बढ़ने वाले सभी संस्थानों को भी उसी फ़ाइल के संस्थान क्षेत्र में परिभाषित किया गया है।
संस्थान मूल्य परिभाषाएं:
1. Institution id: The branchcode of the library. - Modify this accordingly. Must be the same as created in Koha and the account area.
कार्यान्वयन: चलाए जाने वाले कोड को परिभाषित करता है। - डिफ़ॉल्ट के रूप में छोड़ दें
3. Policy: Policy defines the permitted SIP2 commands allowed from SC’s in this institution. For example: renewal=”true” means that SC’s at that institution have permission to send renewal item SIP2 commands.
4. Starting SIP2 Simply write in the command: sudo koha-start-sip <instancename>
टिप्पणी
अब आपके पास एक चल रहा SIP2 सर्वर है।
टिप्पणी
वैकल्पिक रूप से, आप सॉर्टिंग बिन व्यवहार को कॉन्फ़िगर कर सकते हैं, का उपयोग करके UseLocationAsAQInSIP और SIP2SortBinMapping सिस्टम प्राथमिकताएं।
एसआईपी 2 का उपयोग करना
एसआईपी 2 एक संचार प्रोटोकॉल है। एसआईपी 2 में भेजे गए संदेश या तो अनुरोध या प्रतिक्रिया हैं। अनुसूचित जाति एसीएस को अनुरोध संदेश भेजती है जो कुछ तर्क चलाएगी और परिणामी मूल्य को एससी को प्रतिक्रिया संदेश के रूप में वापस भेज देगा।
अनुरोध संदेशों में तर्क होते हैं, जो आइटम को नवीनीकृत करने जैसे आवश्यक कार्य करने के लिए एसीएस द्वारा अपने कार्यों में उपयोग किए जाने वाले डेटा मान होते हैं।
एसआईपी 2 आदेश
यदि आप मैन्युअल रूप से एसआईपी 2 का परीक्षण / परीक्षण करना चाहते हैं तो आप लिनक्स टर्मिनल के माध्यम से संदेश लिख और प्राप्त करेंगे।
एसआईपी 2 सर्वर के साथ संदेश भेजने और प्राप्त करने में सक्षम होने के लिए आपको एक एसआईपी 2 कनेक्शन खोलने के लिए टेलनेट का उपयोग करने की आवश्यकता है। आपको उस पोर्ट नंबर को निर्दिष्ट करने की आवश्यकता है जिसे आप टेलनेट का उपयोग करना चाहते हैं।
इस जानकारी को खोजने के लिए SIPconfig.xml फ़ाइल के शीर्ष पर सेवा क्षेत्र देखें (नीचे दिए गए स्क्रीनशॉट में तीर द्वारा इंगित पोर्ट नंबर देखें)।
टर्मिनल में लिखें
टेलनेट लोकलहोस्ट <portnumber>
e.g. टेलनेट लोकहोस्ट 8023
अब SIPconfig.xml फ़ाइल में एक खाते में उपयोगकर्ता नाम और पासवर्ड सेट में लिखें।।
अब आप एसआईपी 2 सर्वर से जुड़े हुए हैं, आप लिखना शुरू कर सकते हैं और अनुरोध कमांड भेज सकते हैं। एसआईपी 2 सर्वर से कनेक्शन तेजी से समाप्त हो जाता है, इसलिए यदि लेखन समाप्त नहीं हुआ है और कमांड प्राप्त करना है तो बस इसमें लिखें:
टेलनेट लोकलहोस्ट <portnumber>
एसआईपी 2 कनेक्शन को पुनरारंभ करने के लिए।
एसआईपी 2 कमांड सिंटैक्स
प्रत्येक SIP2 कमांड में 2 अंकीय संख्यात्मक उपसर्ग होता है जो परिभाषित करता है कि आदेश क्या कर रहा है।
जैसे संरक्षक के बारे में जानकारी प्राप्त करने के लिए आप उपसर्ग के साथ अपना आदेश शुरू करते हैं: 63. सर्वर से प्रतिक्रिया में भी इसी संख्यात्मक उपसर्ग है।
नीचे संरक्षक जानकारी का अनुरोध करने के लिए एक एसआईपी 2 अनुरोध संदेश का एक उदाहरण है (इस उदाहरण में कोहा स्टाफ इंटरफ़ेस में उपयोगकर्ता नाम 'जो', पासवर्ड 'जोस' और कार्ड नंबर 'y76t5r43' के साथ कोहा संरक्षक खाता बनाया गया है)।
इसके अतिरिक्त कोहा स्टाफ इंटरफ़ेस में 'वेल' के शाखा कोड वाला एक लाइब्रेरी बनाई गई है और इसे SIPconfig.xml फ़ाइल के संस्थान क्षेत्र में भी परिभाषित किया गया है):
तो इस एसआईपी 2 अनुरोध संदेश का प्रारूप है:
टिप्पणी
सारांश मान 10 वर्ण मान है। यदि कोई वाई सारांश मूल्य के लिए लिखा गया है तो आप दोनों सारांश और अधिक विस्तृत सूचनात्मक आउटपुट प्राप्त कर पाएंगे।
<YYYYMMDD> <HHMMSS> का मान वर्तमान डेटाटाइम है, YYYYMMDD और HHMMSS के बीच 4 स्थान का अंतर छोड़कर यह इंगित करता है कि आप समन्वित वैश्विक समय के बजाय स्थानीय समय का उपयोग करना चाहते हैं।
टिप्पणी
इस मैनुअल में विभिन्न फ़ील्ड के लिए अक्षर कोड का उपयोग किया जाता है जहां एसआईपी 2 संदेश फ़ील्ड का वर्णन करने में संभव हो जैसे AO<institutionid>.
ये पत्र कोड एसआईपी 2 कमांड में लिनक्स टर्मिनल में लिखे जा सकते हैं, लेकिन सुनिश्चित करें कि फ़ील्ड के लिए मूल्यों को प्रतिस्थापित करना (<> के अंदर मान जिन्हें आप <> ब्रैकेट में नहीं लिखते हैं।
एसआईपी 2 संदेश:
ब्लॉक संरक्षक
यह अनुरोध संदेशों के लिए उपसर्ग 01 और प्रतिक्रिया संदेशों के लिए 24 का उपयोग करता है.
अनुरोध संदेश:
टिप्पणी
कार्ड बनाए रखा या तो 'Y' या 'N' का एक एकल चरित्र क्षेत्र है जो एसीएस को बताता है कि एक कार्ड स्वयं चेकआउट मशीन द्वारा बनाए रखा गया है।।
प्रतिक्रिया संदेश:
टिप्पणी
<patronstatus> एक 14 वर्ण लंबा मूल्य है। स्ट्रिंग में मान वाई सही है। इस स्ट्रिंग (0 से शुरू) में प्रत्येक स्थिति स्ट्रिंग में एक एकल संबंधित मान (वाई या एन) है.
जैसे स्थिति 1 पर एक वाई (स्ट्रिंग में दूसरा मान) का अर्थ है कि संरक्षक नवीकरण विशेषाधिकारों से इनकार किया जाता है.
चेक-इन आइटम
यह अनुरोध संदेश (एसीएस को भेजे गए संदेश) 09 के उपसर्ग और 10 के प्रतिक्रिया उपसर्ग (एससी को भेजा गया) का उपयोग करता है।
अनुरोध संदेश:
टिप्पणी
<no block (Offline)> या तो 'वाई' या 'एन' का एक एकल चरित्र क्षेत्र है जो इंगित करता है कि लेनदेन ऑफ़लाइन किया जा रहा है या नहीं। ऑफ़लाइन लेन-देन समर्थित नहीं हैं, इसलिए यदि आप इस संदेश का मैन्युअल रूप से परीक्षण कर रहे हैं तो आपको 'एन' लिखने की आवश्यकता है.
<transactiondate> यह एक 18 वर्ण फ़ील्ड है जिसमें तिथि प्रारूप है: YYYYMMDDZZZZHHMMSS.
ZZZZ टाइमज़ोन है, यदि आप इसे स्थानीय पर सेट करना चाहते हैं तो आपको 4 खाली रिक्त स्थान छोड़ने की आवश्यकता है, लेकिन यदि आप इसे यूटीसी (कोऑर्डिनेटेड यूनिवर्सल टाइम) पर सेट करना चाहते हैं तो आपको 3 रिक्त स्थान और ज़ेड में लिखना होगा।
प्रतिक्रिया संदेश:
टिप्पणी
अलर्ट प्रकार में कई मानों में से एक हो सकता है:00 : Unknown 01: local hold 02: remote hold 03: ILL Transfer 04: transfer 99: Other
यदि किसी आइटम का पुनर्वितरण किया जाता है तो <resensitize> का मान वाई होना चाहिए अन्यथा यह होना चाहिए कि यह सुनिश्चित करने के लिए एन Rensensitizing आइटम किया जाता है कि अगर कोई आइटम चोरी करने का प्रयास करता है तो उन्हें पता चला है।
चेकआउट आइटम
यह 11 के अनुरोध संदेश उपसर्ग और 12 के प्रतिक्रिया संदेश उपसर्ग का उपयोग करता है। इसमें उप-उपसर्ग को छोड़कर ऊपर उल्लिखित चेक-इन कमांड के समान वाक्यविन्यास है।
** होल्ड ** - अभी तक कुछ सिस्टम पर समर्थित नहीं हो सकता है। इसमें 15 का अनुरोध संदेश संख्यात्मक उपसर्ग और 16 का एक प्रतिक्रिया संदेश उपसर्ग है।
अनुरोध संदेश:
टिप्पणी
<holdmode> एक एकल चरित्र मूल्य है। + का मतलब है एक होल्ड जोड़ें, - मतलब है कि एक होल्ड हटाएं और * मतलब है कि एक होल्ड बदलें.
प्रतिक्रिया संदेश:
टिप्पणी
<ok> एक लम्बाई मान है जो या तो 0 है (होल्ड के लिए अनुमति नहीं है या सफल नहीं हुआ है) या 1 (पकड़ के लिए अनुमति है और सफल था)।
<available> एक सिंगल लम्बाई मान है जो या तो वाई या एन वाई का मतलब है कि आइटम वर्तमान में लाइब्रेरी में है, जबकि एन का मतलब है कि आइटम वर्तमान में ऋण पर है / किसी और ने आइटम पर रोक लगाई है.
** आइटम जानकारी: यह 17 का अनुरोध कमांड उपसर्ग का उपयोग करता है, और प्रतिक्रिया कमांड उपसर्ग 18**
अनुरोध संदेश:
टिप्पणी
<xact_date> मान क्या है यह जानने के लिए चेक-इन आइटम कमांड (ऊपर वर्णित) देखें।
टर्मिनल पासवर्ड वैकल्पिक है।
प्रतिक्रिया संदेश:
आइटम स्थिति अपडेट यह 19 के अनुरोध संदेश उपसर्ग का उपयोग करता है और प्रतिक्रिया संदेश उपसर्ग 20
अनुरोध संदेश:
टिप्पणी
<itemproperties> निश्चित लंबाई मान नहीं है, और आप वैकल्पिक रूप से आइटम आकार जैसे मानों में लिख सकते हैं और ये मान आइटम के लिए कोहा डेटाबेस में संग्रहीत किए जाएंगे।
प्रतिक्रिया संदेश:
टिप्पणी
<itempropertiesok> एक लम्बाई वर्ण मान है जो या तो 0 या 1 है। 1 यह पहचानता है कि आइटम स्थिति अद्यतन अनुरोध संदेश में परिभाषित <itemproperties> मान कोहा डेटाबेस में सफलतापूर्वक संग्रहीत किया गया था।
संरक्षक स्थिति
यह अनुरोध संदेश उपसर्ग 23 और प्रतिक्रिया संदेश उपसर्ग 24 का उपयोग करता है।
अनुरोध संदेश:
प्रतिक्रिया संदेश:
टिप्पणी
प्रदर्शित मान वाई (मान्य) और एन (अमान्य) है <patronvalidity> के लिए <YYYYMMDD> < HHMMSS> में मान वर्तमान दिनांक / समय है।
दो मानों के बीच के अंतर का कारण यह परिभाषित करना है कि आप यूटीसी के बजाए लोकलटाइम का उपयोग करना चाहते हैं।
** संरक्षक सक्षम - यह अभी तक समर्थित नहीं है। यह 25 के अनुरोध संदेश उपसर्ग का उपयोग करता है और 26 के प्रतिक्रिया संदेश उपसर्ग का उपयोग करता है **
टिप्पणी
यह आदेश ब्लॉक संरक्षक कमांड को पूर्ववत करता है।
अनुरोध संदेश:
प्रतिक्रिया संदेश:
** नवीनीकरण यह 29 के अनुरोध संदेश उपसर्ग का उपयोग करता है और प्रतिक्रिया संदेश उपसर्ग 30 **
अनुरोध संदेश:
टिप्पणी
<thirdpartyallowed> is a एकल वर्ण मान जो या तो वाई या एन है। यदि यह वाई है तो तीसरे पक्ष आइटम नवीनीकृत कर सकते हैं।
<noblock> एक एकल वर्ण मान है जो या तो वाई या एन है। यदि यह वाई है तो इसका मतलब यह है कि जब एसीएस ऑफलाइन था तो आइटम चेकइन/आउट था।
<nbduedate> एसीएस ऑफ़लाइन होने पर चेकइन / चेकआउट की लेन-देन तिथि है।
<feeacknowledged> एक एकल वर्ण मान है जो या तो वाई या एन है। यह इंगित करता है कि उपयोगकर्ता उस आइटम से जुड़े शुल्क को स्वीकार करता है, जिसे वे नवीनीकृत कर रहे हैं।
प्रतिक्रिया संदेश:
टिप्पणी
<ok> एक एकल वर्ण मान है जो या तो 0 या 1 है। 1 का मान है कि आइटम सफलतापूर्वक नवीनीकृत किया गया था, 0 का मतलब है कि आइटम सफलतापूर्वक नवीनीकृत नहीं किया गया था।
<renewalok> एक एकल वर्ण मान है जो या तो वाई या एन है। <renewalok> के मान की सेटिंग के लिए तर्क वाई है जब आइटम पहले से उपयोगकर्ता द्वारा चेकआउट किया जाता है और इसलिए इसे नवीनीकृत किया जाना चाहिए जिससे इसे नवीनीकृत किया जा सके, जबकि एन सेट किया गया है यदि आइटम पहले से ही संरक्षक के लिए चेकआउट नहीं है और इसलिए इसे नवीनीकृत नहीं किया जाना चाहिए।
दूसरे शब्दों में जब संरक्षक वर्तमान में चेक आउट नहीं होते हैं तो संरक्षक पुस्तकें नवीनीकृत न करें।
<magneticmedia>एक एकल वर्ण मान है जो या तो वाई (हां के लिए), एन (नहीं के लिए), या यू (अज्ञात के लिए) है।
<mediatype> एक तीन संख्यात्मक चरित्र लंबा मूल्य है। मानों की एक सूची के लिए यहां जाएं:http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
अंत सत्र
यह 35 का अनुरोध संदेश उपसर्ग और 36 का प्रतिक्रिया संदेश उपसर्ग का उपयोग करता है
अनुरोध संदेश:
प्रतिक्रिया संदेश:
टिप्पणी
<success_or_failure> विफलता के लिए या तो सफलता के लिए वाई या एन है।
** शुल्क भुगतान - अभी तक लागू नहीं किया जा सकता है। यह 37 का अनुरोध संदेश उपसर्ग और 38 का एक प्रतिक्रिया संदेश उपसर्ग का उपयोग करता है **
अनुरोध संदेश:
टिप्पणी
<feetype>एक दो संख्यात्मक वर्ण मान है जो 01 और 99 के बीच है। फीस प्रकार मानों की एक सूची देखने के लिए यहां जाएं http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
<paymenttype> 00 और 99 के बीच दो वर्ण संख्यात्मक मान है। 00 नकद है, 01 वीज़ा है, और 02 क्रेडिट कार्ड है।
<currencytype> एक 3 अल्फान्यूमेरिक वर्ण लंबा मूल्य है जो भुगतान किए गए शुल्क की पहचान करता है।
प्रतिक्रिया संदेश:
टिप्पणी
<paymentaccepted> एक एकल अल्फान्यूमेरिक वर्ण लंबा मान है जो या तो वाई है (भुगतान स्वीकार कर लिया गया है) या एन (भुगतान स्वीकार नहीं किया गया है)।
संरक्षक जानकारी
यह 63 के अनुरोध संदेश उपसर्ग और 64 के प्रतिक्रिया संदेश उपसर्ग का उपयोग करता है
अनुरोध संदेश:
प्रतिक्रिया संदेश:
टिप्पणी
<valid patron> वाई वैध है और मान्य नहीं है।
टिप्पणी
<hold itemcount><overdueitemcount><chargeditemscount><fienitemscount><recallitemscount><unavaliableholdscount> सभी 4 संख्यात्मक चरित्र लंबे मूल्य हैं.
सभी को नवीनीकृत
यह 65 के अनुरोध संदेश उपसर्ग और 66 के प्रतिक्रिया संदेश उपसर्ग का उपयोग करता है।
अनुरोध संदेश:
प्रतिक्रिया संदेश:
टिप्पणी
<renewedcount> एक 4 संख्यात्मक वर्ण लंबा मान है जो नवीनीकृत वस्तुओं की संख्या को दर्शाता है।
<unrenewedcount>, <renewedcount> के समान प्रारूप है, लेकिन यह नवीनीकृत न किए गए आइटमों की संख्या को दर्शाता है।
लॉगइन
यह 93 के अनुरोध संदेश उपसर्ग का उपयोग करता है, और प्रतिक्रिया संदेश उपसर्ग 94 का उपयोग करता है।
अनुरोध संदेश:
टिप्पणी
<UIDalgorithm> और <PWDalgorithm> एक वर्ण लंबे मान हैं जो क्रमशः loginuserid और loginpassword एन्क्रिप्ट करने के लिए उपयोग करने के लिए एल्गोरिदम के प्रकार को इंगित करते हैं.
0 के मान में लिखने का अर्थ है कि ये मान एन्क्रिप्ट नहीं किए जाएंगे।
प्रतिक्रिया संदेश: 941 एक सफल लॉगिन है। 940 एक असफल लॉगिन [कनेक्शन विदेशी होस्ट द्वारा बंद है।] एक असफल लॉगिन है
पुन: भेजें
यह प्राप्तकर्ता डिवाइस को अपने अंतिम संदेश को फिर से भेजने का अनुरोध करता है।
SC -> एसीएस अनुरोध भेजना है 97
ACS -> SC अनुरोध भेजना है 96
**SC और ACS की स्थिति **
इसमें 99 का अनुरोध संदेश उपसर्ग और 98 का प्रतिक्रिया संदेश उपसर्ग है।
अनुरोध संदेश:
टिप्पणी
स्थिति कोड 3 मानों में से एक है। * 0: एससी ठीक है * 1: अनुसूचित जाति कागज से बाहर है * 2: अनुसूचित जाति अधिकतम प्रिंट चौड़ाई को बंद कर रही है एक 3 वर्ण लंबा मान है जो क्लाइंट प्रिंट कर सकते हैं अक्षरों की पूर्णांक संख्या प्रोटोकॉल संस्करण एक 4 वर्ण मान है प्रारूप x.xx
प्रतिक्रिया संदेश:
टिप्पणी
अगर आपको प्रतिक्रिया संदेश '96' मिलता है तो इसका मतलब है कि अनुरोध संदेश मान्य / समझा नहीं गया है।
समस्या निवारण एसआईपी 2
टेलनेट लोकलहोस्ट कमांड में लिखते समय रिमोट होस्ट से कनेक्ट नहीं हो सकता है<portnumber>
3 कोशिश करने के लिए इस मुद्दे के समाधान हैं:
पोर्टनंबर की जाँच करें उपरोक्त कमांड में आपका लेखन पोर्ट नंबर है जो SIPconfig.xml फ़ाइल में नंबर 1 द्वारा इंगित स्थान पर लिखा गया है। उदाहरण के लिए नीचे दिए गए उदाहरण में क्योंकि पोर्टनंबर 6001 सही कमांड होगा: telnet localhost 6001.
जांचें कि क्या कोई उपयोगकर्ता SIPconfig.xml फ़ाइल में एक से अधिक बार लिखा गया है। उपयोगकर्ता (जो कि आसानी से कोहा उपयोगकर्ता का उपयोगकर्ता नाम है) को SIPconfig.xml फ़ाइल में विशिष्ट होना चाहिए। यदि आपके SIPconfig.xml फ़ाइल में एक ही उपयोगकर्ता के पास कई बार है तो इससे आपको प्रमाणित करने का मौका मिलने से पहले SIP2 का कनेक्शन विफल हो जाएगा।
Check the account defined in the SIPconfig.xml file also exists in the Koha database with the same username, password and has the circulate permission. If you have dropped and recreated the Koha database after creating the patron account in the Koha staff interface and the SIPconfig.xml file then that patron account will not exist in the Koha database and so you will need to recreate them in the Koha staff interface.
अपने कोहा होम निर्देशिका में एसआईपी 2 लॉग तक पहुंचने के लिए निम्न निर्देशिका पर नेविगेट करें: /var/log/koha/<instancename>
फिर sip-error.log और sip-output.log फ़ाइलों के आउटपुट को देखें जो SIP2 त्रुटि के बारे में अधिक विस्तृत जानकारी देते हैं।
cat sip-error.log
cat sip-output.log
एसआईपी 2 आदेशों पर उपयोगी लिंक:
http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
एलडीएपी
कोहा के लिए एलडीएपी (लाइटवेट डायरेक्ट्री एक्सेस प्रोटोकॉल) की स्थापना आपको सभी उपयोगकर्ता जानकारी को केंद्रीय डेटाबेस में संग्रहीत करने की अनुमति देती है जिसे आपके संगठन के कोहा इंस्टेंस और उपयोगकर्ताओं के लिए अन्य मौजूदा सिस्टम पर प्रमाणित करने के लिए एक्सेस किया जाता है।
एलडीएपी एक प्रोटोकॉल है जो नेटवर्क और नेटवर्क प्रमाणीकरण पर फ़ाइल खोज के लिए उपयोग किया जाता है।
एलडीएपी कॉन्फ़िगरेशन शक्तिशाली हैं जिससे आप कोहा और एलडीएपी कैसे बातचीत कर सकते हैं। LDAP can को कॉन्फ़िगर किया जा सकता है ताकि एलडीएपी में बनाए गए नए खाते को कोहा डेटाबेस में सिंक किया जा सके, इसके अलावा एलडीएपी उपयोगकर्ता खाते के अपडेट को कोहा डेटाबेस में सिंक किया गया है।
हालांकि कोहा एलडीएपी सर्वर तक डेटा सिंक नहीं कर सकता है, इस प्रकार एलडीएपी का उपयोग करते समय डेटा यातायात केवल एक दिशात्मक है।
Auth_By_Bind 1 पर सेट है जहां एक Microsoft Windows सक्रिय निर्देशिका सिस्टम LDAP डेटाबेस में उपयोग में है।
एलडीएपी को कॉन्फ़िगर करने के चरणों के माध्यम से जाने से पहले आपको संगठन से निम्नलिखित जानकारी / कार्रवाइयों की आवश्यकता होगी
संगठन को सर्वर से अपने एडी तक पहुंच की अनुमति देने के लिए एक पोर्ट खोलने की आवश्यकता होगी।
एडी सर्वर (आईपी पता / होस्टनाम, पोर्ट, एसएसएल जानकारी) तक पहुंच के बारे में जानकारी
एडी सर्वर की कॉन्फ़िगरेशन पर जानकारी (प्रासंगिक ओयू, डीसी, उपयोगकर्ता नाम से संबंधित सीएन प्रारूप)
एडी फ़ील्ड और कोहा फ़ील्ड के बीच मैपिंग, डिफ़ॉल्ट सहित
एडी द्वारा प्रदान की जाने वाली चीज़ों के लिए डिफ़ॉल्ट मान (उदाहरण के लिए श्रेणी कोड, शाखा कोड)
किसी उपयोगकर्ता को प्रमाणीकृत करने के लिए हम उनके रूप में बाध्य करते हैं (एडी के लिए आम लगता है) या क्या हम एक खाते का उपयोग करते हैं और उसके साथ लॉगिन करते हैं और फिर जांचते हैं? यदि उत्तरार्द्ध, हमें लॉग इन करने के विवरण की आवश्यकता होगी
क्या कोहा में मौजूद मौजूदा उपयोगकर्ता नाम उपयोगकर्ता नाम से मेल खाते हैं जिनका उपयोग हम उन्हें एडी में देखने के लिए करेंगे? यदि हां, तो अच्छा। यदि नहीं, तो हम डुप्लिकेट उपयोगकर्ताओं से कैसे निपटेंगे?
अपने कोहा उदाहरण के साथ एलडीएपी स्थापित करने के लिए कदम
1 लिनक्स टर्मिनल में koha-conf.xml फ़ाइल वाली निर्देशिका में नेविगेट करें जो या तो निम्न में होगा: * /etc/koha/sites/<instance-name>/ OR * /etc/koha/
2 koha-conf.xml फ़ाइल को रूट अनुमतियों के साथ खोलें:sudo vi koha-conf.xml
3 लाइन में नीचे स्क्रॉल करें ‘<useldapserver>0</useldapserver>’ और इसे यहां बदलें: <useldapserver>1</useldapserver>
4 फिर नीचे की अगली पंक्ति में नीचे LDAP विन्यास में लिखें:
<ldapserver id="<ldapserverid>">
<hostname><hostname></hostname>
<base>dc=<domaincontroller>,dc=<domaincontroller></base>
<user>cn=<nameofuser>, dc=<domaincontroller>,dc=<domaincontroller></user> <!--This is the username of user account with permissions to query the LDAP server -->
<pass><password></pass> <!-- This is password of the user account with permissions to query the LDAP server-->
<replicate><either0or1></replicate> <!-- add new users from LDAP to Koha database -->
<welcome><either0or1></welcome> <!-- send new users the welcome email when added via replicate -->
<update><either0or1></update> <!-- update existing users in Koha database -->
<auth_by_bind><either0or1></auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory -->
<principal_name><principalname></principal_name> <!-- optional, for auth_by_bind: a printf format to make userPrincipalName from koha userid -->
<mapping> <!-- match koha SQL field names to your LDAP record field names-->
<firstname is="givenname"></firstname>
<surname is="sn"></surname>
<address is="postaladdress"></address>
<city is="l">Athens, OH</city> <!-- Athens,OH is the default value for
city of all users logging into Koha -->
<zipcode is="postalcode"></zipcode>
<branchcode is="branch">Central</branchcode>
<userid is="uid"></userid>
<password is="userpassword"></password>
<email is="mail"></email>
<categorycode is="employeetype">EM</categorycode>
<phone is="telephonenumber"></phone>
</mapping>
</ldapserver>
5 koha-conf.xml फ़ाइल सेव करें और बाहर निकलें
6 लिखकर एलडीएपी कनेक्शन काम की जांच करें:
ldapsearch -H ldaps://host.name -s base -x -w "" -d 1
टिप्पणी
होस्टनाम होस्टनाम के बारे में नोट या तो अल्फान्यूमेरिकल नाम हो सकता है या यह एलडीएपी सर्वर आईपी पता (पोर्ट नंबर लिखने के लिए वैकल्पिक) हो सकता है। डिफ़ॉल्ट रूप से ldaps डिफ़ॉल्ट पोर्ट संख्या 636 है, जबकि ldap डिफ़ॉल्ट पोर्ट संख्या 389 है
टिप्पणी
प्रतिलिपि और अद्यतन फ़ील्ड के बारे में नोट कोहा-conf.xml फ़ाइल में एलडीएपी के लिए replicate LDAP कॉन्फ़िगरेशन फ़ील्ड कोहा डेटाबेस को जब भी कोई उपयोगकर्ता कोहा में लॉग इन करता है (या तो कर्मचारी क्लाइंट या ओपेक ) उनके एलडीएपी उपयोगकर्ता नाम और पासवर्ड के साथ (मानते हैं कि वही उपयोगकर्ता नाम और पासवर्ड कोहा डेटाबेस में पहले से मौजूद नहीं है)।
जबकि अद्यतन एलडीएपी कॉन्फ़िगरेशन फ़ील्ड (उसी फ़ाइल में अनुमति देता है) एलडीएपी डेटाबेस में उपयोगकर्ता जानकारी को कोहा डेटाबेस में सिंक करने की अनुमति देता है। जैसे अगर कोई विवाहित हो जाता है और उनका उपनाम बदल जाता है तो नया उपनाम केवल मौजूदा एलडीएपी डेटाबेस में अपडेट किया जाना चाहिए और अपडेट होने पर कोहा डाटाबेस में स्वचालित रूप से समन्वयित किया जाएगा विन्यास 1 पर सेट है।
मैपिंग फ़ील्ड के बारे में (फ़ील्ड हरे रंग को हाइलाइट करते हैं) <city is="l">Athens, OH</city>
बाएं हाथ कॉलम नाम (पीला हाइलाइट) एलडीएपी डेटाबेस में कॉलम का नाम है।
कोट अंक के अंदर कॉलम नाम (हाइलाइट गुलाबी) कोहा डेटाबेस में कॉलम का नाम है। नोट: यदि एलडीएपी डेटाबेस में मौजूद कोहा डेटाबेस में समकक्ष कॉलम नाम नहीं है तो यह किसी भी मान से भरा जा सकता है।
मान को हाइलाइट किया गया मान निर्दिष्ट कोहा और एलडीएपी कॉलम के लिए डिफ़ॉल्ट मान है। तो उपर्युक्त उदाहरण में कोहा और एलडीएपी डेटाबेस में सभी उपयोगकर्ता रिकॉर्ड डिफ़ॉल्ट रूप से 'एथेंस, ओएच' का शहर मूल्य होगा।
एलडीएपी विन्यास का उदाहरण:
<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
<ldapserver id="ldapserver" listenref="ldapserver">
<hostname>ldaps://example.co.au</hostname>
<base>ou=employees,dc=companya,dc=com,dc=au</base>
<user></user> <!-- DN, if not anonymous -->
<pass></pass> <!-- password, if not anonymous -->
<auth_by_bind>1</auth_by_bind>
<replicate>1</replicate> <!-- add new users from LDAP to Koha database -->
<update>0</update> <!-- update existing users in Koha database -->
<principal_name>ou=employees,dc=companya,dc=com,dc=au</principal_name>
<mapping>
<userid is="uid" ></userid>
<cardnumber is="uid" ></cardnumber>
<email is="mail" ></email>
<surname is="sn" ></surname>
<firstname is="givenname" ></firstname>
<categorycode is="1">EM</categorycode>
<branchcode is="1">SYD</branchcode>
</mapping>
</ldapserver>
मैपिंग क्षेत्र में मान हमेशा समान नहीं होते हैं, और यह आपके संगठन एलडीएपी डेटाबेस में क्या है इस पर निर्भर करता है। उदाहरण के लिए कुछ संगठन <userid> का उपयोग नहीं करते हैं बल्कि प्रत्येक उपयोगकर्ता को केवल <email> फ़ील्ड द्वारा पहचाना जाता है और इसलिए कोई <userid>लिखा नहीं जाता है.
समस्या निवारण एलडीएपी
एलडीएपी त्रुटियों को मुद्रित करने के लिए लॉग इन कई कारकों पर निर्भर करता है:
यदि प्लेक अक्षम नहीं है तो plack-error.log फ़ाइल में एलडीएपी त्रुटियों को प्रदर्शित किया जाता है यदि प्लेक अक्षम है तो एलडीएपी त्रुटियों को मुद्रित करने वाला स्थान या तो opac-error.log फ़ाइल है (यदि उपयोगकर्ता OPAC में लॉग इन कर रहा है) या इंट्रानेट-error.log फ़ाइल (यदि उपयोगकर्ता कर्मचारी क्लाइंट में लॉग इन कर रहा है) इन तीनों में से सभी लॉग फ़ाइलें निम्न निर्देशिका में पहुंच योग्य हैं:
/var/log/koha/<instance>/