View | Details | Raw Unified | Return to bug 18107
Collapse All | Expand All

(-)a/en/build/README (-16 lines)
Lines 1-16 Link Here
1
Placeholder for the build dir
2
3
To build
4
5
sudo apt-get install python3-sphinx
6
make html
7
8
to make a single html 
9
10
make singlehtml
11
12
to generate the po files
13
14
make gettext
15
16
(-)a/en/source/18_miscellaneous.rst (+641 lines)
Lines 2351-2356 Run TalkingTech\_itiva\_outbound.pl --help for more information Link Here
2351
2351
2352
Run TalkingTech\_itiva\_inbound.pl --help for more information
2352
Run TalkingTech\_itiva\_inbound.pl --help for more information
2353
2353
2354
Integrating SIP2 with Koha
2355
=============================
2356
2357
SIP2 (Session Initiation Protocol) is a protocol for communication between devices.
2358
2359
In the context of Koha SIP2 is used for communication between Self Check (SC) machines i.e. self checkout machines, and the Automated Circulation System (also known as ACS which in this case is the server running Koha).
2360
2361
SIP2 communications consist of requests and responses.
2362
2363
The self checkout machines are ‘dumb’ and so they send requests to the Koha server which runs logic which determines a particular outcome which is sent as a response message back to the client self checkout machine, and this is then conveyed to the user.
2364
2365
.. warning:: Security notice regarding using SIP2 service
2366
	     			 To ensure that your SIP2 traffic is secure as it passes over the internet you need to make sure that you are using a VPN or   stunnel.
2367
2368
Setting up SIP2
2369
----------------------
2370
2371
If you installed Koha using Debian packages then SIP2 setup is easy, simply follow these steps:
2372
2373
2374
1. In your terminal (in the root Koha directory) write in:
2375
*sudo koha-enable-sip <instancename>*
2376
2377
2378
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.
2379
You will need to edit this file as root because it contains passwords (to do so write ‘sudo’  at the start of your command).
2380
2381
e.g.
2382
*sudo vi /etc/koha/sites/<instancename>/SIPconfig.xml*
2383
2384
.. note:: Important note: There are three areas of interest in the SIPconfig.xml file that you need to change. These are: service, account and institution.
2385
2386
2387
**Service**
2388
2389
2390
	2.1 Change the port value near the top of the SIPconfig.xml file (identified by the number 1 in the below screen shot), so it has the same IP address as set further down the SIPconfig.xml file identified by 2.
2391
2392
	.. note:: Make sure the two port values don’t have the same port number as you cannot have the same port being listened to by two different services. When deciding upon the port number make sure it is a high number (i.e. above 1000) because all ports below 1000 require root permissions.
2393
2394
|image1122|
2395
2396
2397
2398
**Account**
2399
2400
The account(s) you define in the SIPconfig.xml file are simply account(s) permitted to use the SIP2 service i.e. your defining who can send and receive SIP2 commands.
2401
2402
	.. warning:: 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 circulate permissions) as the user account you write into the SIPconfig.xml file.
2403
2404
	.. note:: It is highly recommended that you only write in Koha user accounts with circulate permissions.
2405
2406
				The reason we want SIP2 users to only have circulate permissions rather than superlibrarian permissions is to reduce the access SIP2 users have to confidential patron data in case the system was compromised.
2407
2408
	  			If the ACS or the SC were compromised then having all SIP2 users only having circulation permissions 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 	   superlibrarian permissions). So it is simply a matter of protecting your users.
2409
2410
|image1119|
2411
2412
2413
**Account value definitions:**
2414
2415
2416
1. Login id: This is the account username. - Modify this accordingly
2417
2. Password: Account password - Modify this accordingly
2418
3. Delimiter: The type of delimiter for account information - Leave as default
2419
4. error-detect -  Leave as default
2420
5. Institution: This is the branchcode for the library that the user belongs to. NOTE: This institution needs to be defined further down in the institution area of the SIPconfig.xml file and it must also exist in the Koha database. i.e. you need to create a library with the same branchcode in Koha staff interface.
2421
6. encoding: This is the standard used to encode the account data
2422
7.  Terminator: This needs to match the terminator value of the SIP2 server. - Modify this if you know the terminator value of the SIP2 server.
2423
2424
**Institution**
2425
2426
2427
	The institution information you define here must match a library created in the Koha staff interface.
2428
2429
	.. warning:: You need to make sure all the institutions that accounts are assigned to further up in the SIPconfig.xml file are also defined in the institution area of the same file.
2430
2431
|image1120|
2432
2433
**Institution value definitions:**
2434
2435
2436
	1. Institution id: The branchcode of the library. - Modify this accordingly.
2437
	Must be the same as created in Koha and the account area.
2438
2439
2. Implementation: Defines the code that will be run. - Leave as default
2440
2441
 3. Policy: Policy defines the permitted SIP2 commands allowed from SC’s in this institution.
2442
 For example: renewal=”true” means that SC’s at that institution have permission to send renewal item SIP2 commands.
2443
2444
 4. Starting SIP2
2445
 Simply write in the command:
2446
 *sudo koha-start-sip <instancename>*
2447
2448
.. note:: Now you have a running SIP2 server.
2449
2450
Using SIP2
2451
~~~~~~~~~~~~~~~~~~~
2452
2453
SIP2 is a communication protocol. The messages sent in SIP2 are either requests or responses. The SC’s send request messages to the ACS which will run some logic and send back the resulting value to the SC as a response message.
2454
2455
The request messages contain arguments, which are data values used by the ACS in its functions to perform the required task such as renewing items.
2456
2457
**SIP2 commands**
2458
2459
If you want to manually use/test SIP2 then you will be writing and receiving messages via the Linux terminal.
2460
2461
To be able to send and receive messages with the SIP2 server you need to use telnet to open a SIP2 connection. You need to specify the port number you want telnet to use.
2462
2463
To find this information look at the service area at the top of the SIPconfig.xml file (look for the port number as pointed out by the arrow in the below screenshot).
2464
2465
|image1121|
2466
2467
2468
1. Write into the terminal
2469
2470
   *telnet localhost <portnumber>*
2471
2472
   e.g. *telnet localhost 8023*
2473
2474
2. Now write in the username and password set in one of the accounts in the     SIPconfig.xml file.
2475
2476
3. Now you are connected to the SIP2 server you can start writing and sending request commands. The connection to the SIP2 server does time out fast so if haven’t finished writing and receiving commands simply write in:
2477
2478
   *telnet localhost <portnumber>*
2479
2480
   to restart the SIP2 connection.
2481
2482
**SIP2 command syntax**
2483
2484
Every SIP2 command has a 2 digit numerical prefix which defines what the command is doing.
2485
2486
e.g. To get information about a patron you start your command with the prefix: 63. The response from the server also has a corresponding numerical prefix.
2487
2488
Below is an example of a SIP2 request message to request patron information (in this example a Koha patron account with the user name ‘joe’, password ‘joes’, and card number ‘y76t5r43’ has been created in the Koha staff interface).
2489
2490
Additionally a library with the branchcode of ‘WEL’ has been created in the Koha staff interface and is also defined in the institution area of the SIPconfig.xml file):
2491
2492
|image1123|
2493
2494
So the format of this SIP2 request message is:
2495
2496
|image1124|
2497
2498
.. note:: The summary value is a 10 character value. If a Y is written in for the summary value then you will be able to get both a summary and more detailed informational output.
2499
2500
The value in the <YYYYMMDD>       <HHMMSS> is the current datetime, by leaving a 4 space gap between the YYYYMMDD and HHMMSS this indicates you want to use local time rather than UTC.
2501
2502
.. note:: In this manual letter codes for the various fields are used where possible in describing the SIP2 message fields e.g. AO<institutionid>.
2503
2504
					These letter codes can be written in the SIP2 commands into the Linux terminal, but make sure when substituting values in for the fields (values inside the <>) that you do not write in the <> brackets.
2505
2506
2507
**SIP2 messages:**
2508
2509
2510
**Block patron**
2511
2512
This uses the prefix 01 for request messages and 24 for response messages.
2513
2514
Request message:
2515
2516
|image1125|
2517
2518
2519
.. note:: Card retained is a single character field of either ‘Y’ or ‘N’  which tells the ACS that a card has been retained by the self checkout machine.
2520
2521
Response message:
2522
2523
|image1126|
2524
2525
.. note:: <patronstatus> is a 14 character long value. The value Y in the string means true. Each position in this string (starting at 0) has a single corresponding value (Y or N) in the string.
2526
2527
					e.g. a Y at position 1 (the second value in the string) means that the patrons renewal privileges are denied.
2528
2529
2530
**Check-in items**
2531
2532
2533
This uses the request message (messages sent to the ACS) prefix of 09 and the response prefix of 10 (sent to the SC).
2534
2535
Request message:
2536
2537
|image1127|
2538
2539
.. note:: * <no block (Offline)> is a single character field of either ‘Y’ or ‘N’ which indicates if the transaction is being performed offline. As offline transactions are not supported you need to write ‘N’ if you are testing this message out manually.
2540
2541
					* <transactiondate> this is a 18 character field with the date is the format: YYYYMMDDZZZZHHMMSS.
2542
2543
					ZZZZ is the timezone, if you want to set it to local you need to leave 4 blank spaces, but if you want to set it to the UTC (Coordinated Universal Time) then you need to write in 3 blank spaces and a Z.
2544
2545
Response message:
2546
2547
|image1128|
2548
2549
.. note:: Alert type could have one of several values:
2550
	00 : Unknown
2551
	01: local hold
2552
	02: remote hold
2553
	03: ILL Transfer
2554
	04: transfer
2555
	99: Other
2556
2557
If an item is resensitized then the value of <resentitize> should be Y otherwise it should be N. Rensensitizing items is done to ensure that if someone tries to steal the item they are detected.
2558
2559
**Checkout items**
2560
2561
This uses the request message prefix of 11 and the response message prefix of 12.
2562
It has similar syntax to the check-in command, outlined above except the prefixes are different.
2563
2564
**Hold** – May not yet be supported on some systems. This has a request message numerical prefix of 15 and a response message prefix of 16.
2565
2566
Request message:
2567
2568
|image1129|
2569
2570
.. note:: <holdmode> is a single character value. + means add a hold, - means delete a hold and * means change a hold.
2571
2572
Response message:
2573
2574
|image1130|
2575
2576
.. note:: * <ok> is a single length value which is either 0 (for hold is not permitted or was not successful) or 1 (for hold is permitted and was successful).
2577
2578
					* <available> is a single length value which is either Y or N. Y means the item is currently in the library, whilst N means the item is currently on loan/someone else has created a hold on the item.
2579
2580
2581
**Item information: This uses the request command prefix of 17, and the response command prefix of 18**
2582
2583
Request message:
2584
2585
|image1131|
2586
2587
.. note:: See the check-in items command (described above) to find out what the <xact_date> value is.
2588
2589
					The terminal password is optional.
2590
2591
Response message:
2592
2593
|image1132|
2594
2595
**Item status update  This uses the request message prefix of 19 and the response message prefix of 20**
2596
2597
Request message:
2598
2599
|image1133|
2600
2601
.. note:: <itemproperties> is not a fixed length value, and you can optionally write in values such as item size and these values will be stored in the Koha database for the item.
2602
2603
Response message:
2604
2605
|image1134|
2606
2607
.. note:: <itempropertiesok> is a single length character value which is either 0 or 1. 1 identifies that the <itemproperties> value defined in the item status update request message was successfully stored in the Koha database.
2608
2609
**Patron status**
2610
2611
This uses the request message prefix 23 and the response message prefix of 24.
2612
2613
Request message:
2614
2615
|image1135|
2616
2617
Response message:
2618
2619
|image1136|
2620
2621
.. note:: The value displayed for <patronvalidity> is Y (valid) and N (invalid)
2622
					The value in the <YYYYMMDD>    < HHMMSS> is the current date/time.
2623
2624
					The reason for the gap between the two values is to define that you want to use localtime rather than UTC.
2625
2626
2627
**Patron enable - This is not yet supported. This uses the request message prefix of 25 and the response message prefix of 26**
2628
2629
.. note:: This command undoes the block patron command.
2630
2631
Request message:
2632
2633
|image1137|
2634
2635
Response message:
2636
2637
|image1138|
2638
2639
**Renew This uses the request message prefix of 29 and the response message prefix of 30**
2640
2641
Request message:
2642
2643
|image1139|
2644
2645
.. note:: * <thirdpartyallowed> is  a single character value which is either Y or N. If it is Y then third parties can renew items.
2646
2647
					* <noblock> is a single character value which is either Y or N. If it is Y then this means that the item was checkin/out when the ACS was offline.
2648
2649
 					* <nbduedate> is the transaction date of checkin/checkout when the ACS was offline.
2650
2651
					* <feeacknowledged> is a single character value which is either Y or N. This indicates if the user accepts the fee associated with the item they are renewing.
2652
2653
Response message:
2654
2655
|image1140|
2656
2657
.. note:: * <ok> is a single character value which is either 0 or 1. A value of 1 means the item was successfully renewed, 0 means item was not successfully renewed.
2658
2659
					* <renewalok> is a single character value which is either Y or N. The logic for the setting of the value of <renewalok> is Y is set when the item is already checkout by the user and so it should be desensitized thereby renewing it, whereas N is set if the item is not already checkout to the patron and so it should not be renewed.
2660
2661
					In other words don’t let patrons renew books when they are not currently checked out to them.
2662
2663
					* <magneticmedia> is a single character value which is either Y (for yes), N ( for no), or U (for unknown).
2664
2665
					* <mediatype> is a three numerical character long value. For a list of the values go to: http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
2666
2667
2668
**End session**
2669
2670
This uses the request message prefix of 35 and the response message prefix of 36
2671
2672
Request message:
2673
2674
|image1141|
2675
2676
Response message:
2677
2678
|image1142|
2679
2680
.. note:: <success_or_failure> is either Y for success or N for failure.
2681
2682
**Fee Paid – May not be implemented yet. This uses a request message prefix of 37 and a response message prefix of 38**
2683
2684
Request message:
2685
2686
|image1143|
2687
2688
.. note:: * <feetype> is a two numerical character value which is between 01 and 99. To see a list of fee type values go to http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
2689
2690
					* <paymenttype> is a two character numerical value between 00 and 99. 00 is cash, 01 is Visa, and 02 is credit card.
2691
2692
					* <currencytype> is a 3 alphanumeric character long value identifying the currency the fee paid was in.
2693
2694
Response message:
2695
2696
|image1144|
2697
2698
.. note:: <paymentaccepted> is a single alphanumeric character long value which is either Y (payment has been accepted) or N (payment has not been accepted).
2699
2700
2701
**Patron information**
2702
2703
This uses the request message prefix of 63 and the response message prefix of 64
2704
2705
Request message:
2706
2707
|image1145|
2708
2709
Response message:
2710
2711
|image1146|
2712
2713
.. note::  <valid patron> is Y for valid and N for not valid.
2714
2715
.. note::  <hold itemcount><overdueitemcount><chargeditemscount><fienitemscount><recallitemscount><unavaliableholdscount> are all 4 numerical character long values.
2716
2717
**Renew all**
2718
2719
This uses the request message prefix of 65 and the  response message prefix of 66.
2720
2721
Request message:
2722
2723
|image1147|
2724
2725
Response message:
2726
2727
|image1148|
2728
2729
.. note:: * <renewedcount> is a 4 numerical character long value denoting the number of items that were renewed.
2730
2731
					* <unrenewedcount>, has the same format as the <renewedcount> but it denotes the number of items not renewed.
2732
2733
**Login**
2734
2735
This uses the request message prefix of 93, and the response message prefix of 94.
2736
2737
Request message:
2738
2739
|image1149|
2740
2741
.. note:: <UIDalgorithm> and <PWDalgorithm> are one character long values indicating the type of algorithm to use to encrypt the loginuserid and loginpassword respectively.
2742
2743
					Writing in the value of 0 means these values will not be encrypted.
2744
2745
Response message:
2746
*941* is a successful login.
2747
*940* is an unsuccessful login
2748
*[connection closed by foreign host.]* is a unsuccessful login
2749
2750
2751
**Resend**
2752
2753
This requests the receiving device to resend its last message.
2754
2755
SC -> ACS resend request is *97*
2756
2757
ACS -> SC resend request is *96*
2758
2759
2760
**Status of the ACS and SC**
2761
2762
This has the request message prefix of 99 and the response message prefix of 98.
2763
2764
Request message:
2765
2766
|image1150|
2767
2768
2769
.. note:: The status code is one of 3 values.
2770
 					* 0: SC is ok
2771
					* 1: SC is out of paper
2772
					* 2: SC is shutting down
2773
					max print width is a 3 character long value which is the integer number of characters the client can print
2774
					Protocol version is a 4 character value in the format x.xx
2775
2776
Response message:
2777
2778
|image1151|
2779
2780
.. note:: If you get the response message ‘96’ this means that the request message is not valid/understood.
2781
2782
2783
**Troubleshooting SIP2**
2784
2785
Can’t connect to remote host when writing in the command telnet localhost <portnumber>
2786
2787
3 solutions for this issue to try are:
2788
2789
	1. Check the portnumber your writing in the above command is the port number written in the SIPconfig.xml file at the location indicated by the number 1.
2790
	i.e. in the below example because the portnumber is 6001 the correct command would be:
2791
	telnet localhost 6001
2792
2793
	2. Check if any userid is written more than once in the SIPconfig.xml file.
2794
	The userid (which is simply the username of the Koha user)  needs to be unique within the SIPconfig.xml file. If you have the same userid multiple times in your SIPconfig.xml file this will cause the connection to SIP2 to fail before you get a chance to authenticate.
2795
2796
	3. Check the account defined in the SIPconfig.xml file also exists in the Koha database with the same username, password and has circulate permissions.
2797
	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.
2798
2799
2800
2801
Further troubleshooting
2802
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2803
To access the SIP2 logs in your Koha home directory navigate to the following directory:
2804
/var/log/koha/<instancename>
2805
2806
Then view the output of the sip-error.log and the sip-output.log files which give more detailed information about the SIP2 error.
2807
2808
* cat sip-error.log
2809
* cat sip-output.log
2810
2811
2812
**Useful links on SIP2 commands:**
2813
2814
http://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
2815
2816
2817
2818
Integrating LDAP with Koha
2819
==============================
2820
Setting up LDAP (Lightweight Directory Access Protocol) for Koha allows you to store all user information in a central database which is accessed both by your organisations Koha instance and for users to authenticate on other existing systems.
2821
2822
LDAP is a protocol used for file discovery over networks and network authentication.
2823
2824
LDAP configurations are powerful allowing you to customise how Koha and LDAP interact. LDAP  can be configured so that new accounts created in LDAP can be synced down into the Koha database, additionally updates to the LDAP user account are synced down to the Koha database.
2825
2826
However Koha cannot sync data up to the LDAP server, thus the data traffic when using LDAP is only one directional.
2827
2828
Auth_By_Bind is set to 1 where a Microsoft Windows Active Directory system is in use in the LDAP database.
2829
2830
**Before going through the steps to configure LDAP you will need the following
2831
information/actions from the organisation**
2832
2833
* The organisation will need to open a port to allow access to their AD from the server.
2834
2835
* Information on the access to the AD server (IP address/hostname, port, SSL info)
2836
2837
* Information on the configuration of the AD server (relevant OUs, DCs, CN formats relative to usernames)
2838
2839
* Mapping between AD fields and Koha fields, including defaults
2840
2841
* Default values for things not provided by AD (categorycode, branchcode for example)
2842
2843
* To authenticate a user do we bind as them (seems to be common for AD) or do we use an account and login with that and then check? If the latter, we'll need details of how to log in
2844
2845
* Do the existing usernames in Koha match the usernames that we'll be using to look them up in AD? If so, good. If not, how will we deal with duplicate users?
2846
2847
**Steps to set up LDAP with your Koha instance**
2848
2849
2850
1 In Linux terminal navigate to the directory containing the koha-conf.xml file which will either be in:
2851
* /etc/koha/sites/<instance-name>/
2852
OR
2853
*  /etc/koha/
2854
2855
2 Open the koha-conf.xml file with root permissions:
2856
sudo vi koha-conf.xml
2857
2858
3 Scroll down to the line containing ‘<useldapserver>0</useldapserver>’ and change it to:
2859
<useldapserver>1</useldapserver>
2860
2861
4 Then in the next line below write in the LDAP configurations below: Note all fields highlighted in yellow need to be replaced with the appropriate values for your organisations LDAP server.
2862
2863
	<ldapserver id="<ldapserverid>">
2864
2865
	<hostname><hostname></hostname>
2866
2867
	<base>dc=<domaincontroller>,dc=<domaincontroller></base>
2868
2869
	<user>cn=<nameofuser>, dc=<domaincontroller>,dc=<domaincontroller></user> <!--This is the username of user account with permissions to query the LDAP server -->
2870
2871
	<pass><password></pass> <!-- This is password of the user account with permissions  to query the LDAP server-->
2872
2873
	<replicate><either0or1></replicate> <!-- add new users from LDAP to Koha database -->
2874
2875
	<update><either0or1></update> <!-- update existing users in Koha database -->
2876
2877
	<auth_by_bind><either0or1></auth_by_bind> <!-- set to 1 to authenticate by binding instead of password comparison, e.g., to use Active Directory -->
2878
2879
	<principal_name><principalname></principal_name> <!-- optional, for 	auth_by_bind: a printf format to make userPrincipalName from koha userid 	-->
2880
2881
	<mapping> <!-- match koha SQL field names to your LDAP record field names-->
2882
2883
	<firstname is="givenname"></firstname>
2884
2885
	<surname is="sn"></surname>
2886
2887
	<address is="postaladdress"></address>
2888
2889
	<city is="l">Athens, OH</city>    <!-- Athens,OH is the default value for
2890
	city of all users logging into Koha -->
2891
2892
	<zipcode is="postalcode"></zipcode>
2893
2894
	<branchcode is="branch">Central</branchcode>
2895
2896
	<userid is="uid"></userid>
2897
2898
	<password is="userpassword"></password>
2899
2900
	<email is="mail"></email>
2901
2902
	<categorycode is="employeetype">EM</categorycode>
2903
2904
	<phone is="telephonenumber"></phone>
2905
2906
	</mapping>
2907
2908
	</ldapserver>
2909
2910
5 Save and exit the koha-conf.xml file
2911
2912
6 Check the LDAP connection works by writing in:
2913
2914
ldapsearch -H ldaps://host.name  -s base -x  -w "" -d 1
2915
2916
2917
.. note:: Note about hostname
2918
					Hostname can either be a alphanumerical name or it can be the LDAP server IP address (its optional to write port number). By default the ldaps default port number is 636, whilst ldap default port number is 389
2919
2920
2921
.. note:: Note about the replicate and update fields
2922
					The replicate  LDAP config field for LDAP in the koha-conf.xml file allow the Koha database to be added to with a new borrower account whenever a user logs into Koha (either the staff client or OPAC) with their LDAP username and password (assuming the same username and password does not already exist in the Koha database).
2923
2924
					Whereas the update LDAP config field (in the same file allows) allows for user information in the LDAP database to be synced down to the Koha database.
2925
					e.g. if someone gets married and their surname changes then the new surname only needs to 	be updated in the existing LDAP database and that will be synced down to the Koha 	database automatically if the update configuration is set to 1.
2926
2927
2928
About the mapping fields (the fields highlighted green)
2929
<city is="l">Athens, OH</city>
2930
2931
The left hand column name (highlighted yellow) is the name of the column in the LDAP database.
2932
2933
The column name inside quote marks (highlighted pink) is the name of the column in the Koha database. NOTE: This can be filled with any value if there is no equivalent column name in the Koha database as exists in the LDAP database.
2934
2935
The value highlighted cyan is the default value for the specified Koha and LDAP columns. So in the above example all user records in the Koha and LDAP databases  will by default have the city value of ‘Athens, OH’.
2936
2937
Example of the LDAP configurations:
2938
2939
 <useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
2940
2941
 <ldapserver id="ldapserver" listenref="ldapserver">
2942
2943
 <hostname>ldaps://example.co.au</hostname>
2944
2945
 <base>ou=employees,dc=companya,dc=com,dc=au</base>
2946
2947
 <user></user> <!-- DN, if not anonymous -->
2948
2949
 <pass></pass> <!-- password, if not anonymous -->
2950
2951
 <auth_by_bind>1</auth_by_bind>
2952
2953
 <replicate>1</replicate> <!-- add new users from LDAP to Koha database -->
2954
2955
 <update>0</update> <!-- update existing users in Koha database -->
2956
2957
 <principal_name>ou=employees,dc=companya,dc=com,dc=au</principal_name>
2958
2959
 <mapping>
2960
2961
 <userid       is="uid"            ></userid>
2962
2963
 <cardnumber   is="uid"            ></cardnumber>
2964
2965
 <email        is="mail"           ></email>
2966
2967
 <surname      is="sn"             ></surname>
2968
2969
 <firstname    is="givenname"      ></firstname>
2970
2971
 <categorycode is="1">EM</categorycode>
2972
2973
 <branchcode   is="1">SYD</branchcode>
2974
2975
 </mapping>
2976
2977
 </ldapserver>
2978
2979
2980
2981
The values in the mapping area are not always the same, and it depends on what is in your organisations LDAP database. For example some organisations do not use <userid> instead each user is only identified by the <email> field and so no <userid> is written.
2982
2983
2984
2985
**Troubleshooting LDAP**
2986
2987
The log that LDAP errors are printed to depends on several factors:
2988
2989
If plack is not disabled then LDAP errors are displayed in the plack-error.log file
2990
If plack is disabled then the location that LDAP errors are printed to is either the opac-error.log file (if the user is logging into the OPAC) or the intranet-error.log file (if the user is logging into the staff client)
2991
All of these three log files are accessible in the following directory:
2992
2993
/var/log/koha/<instance>/
2994
2354
OCLC Connexion Gateway
2995
OCLC Connexion Gateway
2355
======================
2996
======================
2356
2997
(-)a/en/source/images.rst (+33 lines)
Lines 1117-1119 Link Here
1117
.. |image1116| image:: images/reports/datepicker.png
1117
.. |image1116| image:: images/reports/datepicker.png
1118
.. |image1117| image:: images/reports/branchpulldown.png
1118
.. |image1117| image:: images/reports/branchpulldown.png
1119
.. |image1118| image:: images/appendix-extending/colorccode.png
1119
.. |image1118| image:: images/appendix-extending/colorccode.png
1120
.. |image1119| image:: images/appendix-services/accounts.png
1121
.. |image1120| image:: images/appendix-services/institution.png
1122
.. |image1121| image:: images/appendix-services/portnumbersmall.png
1123
.. |image1122| image:: images/appendix-services/portnumberbig.png
1124
.. |image1123| image:: images/appendix-services/sipcommand1.png
1125
.. |image1124| image:: images/appendix-services/sipcommand2.png
1126
.. |image1125| image:: images/appendix-services/sipcommand3.png
1127
.. |image1126| image:: images/appendix-services/sipcommand4.png
1128
.. |image1127| image:: images/appendix-services/sipcommand5.png
1129
.. |image1128| image:: images/appendix-services/sipcommand6.png
1130
.. |image1129| image:: images/appendix-services/sipcommand7.png
1131
.. |image1130| image:: images/appendix-services/sipcommand8.png
1132
.. |image1131| image:: images/appendix-services/sipcommand9.png
1133
.. |image1132| image:: images/appendix-services/sipcommand10.png
1134
.. |image1133| image:: images/appendix-services/sipcommand11.png
1135
.. |image1134| image:: images/appendix-services/sipcommand12.png
1136
.. |image1135| image:: images/appendix-services/sipcommand13.png
1137
.. |image1136| image:: images/appendix-services/sipcommand14.png
1138
.. |image1137| image:: images/appendix-services/sipcommand15.png
1139
.. |image1138| image:: images/appendix-services/sipcommand16.png
1140
.. |image1139| image:: images/appendix-services/sipcommand17.png
1141
.. |image1140| image:: images/appendix-services/sipcommand18.png
1142
.. |image1141| image:: images/appendix-services/sipcommand19.png
1143
.. |image1142| image:: images/appendix-services/sipcommand20.png
1144
.. |image1143| image:: images/appendix-services/sipcommand21.png
1145
.. |image1144| image:: images/appendix-services/sipcommand22.png
1146
.. |image1145| image:: images/appendix-services/sipcommand23.png
1147
.. |image1146| image:: images/appendix-services/sipcommand24.png
1148
.. |image1147| image:: images/appendix-services/sipcommand25.png
1149
.. |image1148| image:: images/appendix-services/sipcommand26.png
1150
.. |image1149| image:: images/appendix-services/sipcommand27.png
1151
.. |image1150| image:: images/appendix-services/sipcommand28.png
1152
.. |image1151| image:: images/appendix-services/sipcommand29.png

Return to bug 18107