Outras APIs e protocolos
SIP2
SIP2 (Protocolo de Iniciação de Sessão) é um protocolo de comunicação entre dispositivos.
No contexto do Koha, o SIP2 é usado para a comunicação entre máquinas de autoatendimento (SC), isto é, máquinas de autoempréstimo, e o Sistema Automatizado de Circulação (também conhecido como ACS, que neste caso é o servidor que executa o Koha).
As comunicações SIP2 consistem em solicitações e respostas.
As máquinas de autoempréstimo são “simples” e enviam solicitações ao servidor Koha, que executa a lógica para determinar um resultado específico. Esse resultado é enviado como mensagem de resposta à máquina cliente de autoempréstimo e então apresentado ao usuário.
Aviso
Aviso de segurança sobre o uso do serviço SIP2: para garantir a segurança do tráfego SIP2 durante sua transmissão pela internet, certifique-se de usar uma VPN ou o stunnel.
Configurar o SIP2
Dica
Dicas úteis podem ser encontradas na wiki do Koha:
Configuração do servidor SIP2 do Koha e Configuração do SIP2.
Se você instalou o Koha usando pacotes Debian, a configuração do SIP2 é simples; basta seguir estas etapas:
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).
Por exemplo: sudo vi /etc/koha/sites/<instancename>/SIPconfig.xml
Nota
Observação importante: há três áreas relevantes no arquivo SIPconfig.xml que precisam ser alteradas: service, account e institution.
Serviço
2.1 Altere o valor da porta próximo ao início do arquivo SIPconfig.xml (identificado pelo número 1 na captura de tela abaixo) para que tenha o mesmo endereço IP definido mais abaixo no arquivo SIPconfig.xml, identificado pelo número 2.
Nota
Certifique-se de que os dois valores de porta não tenham o mesmo número, pois dois serviços diferentes não podem escutar a mesma porta. Ao escolher o número da porta, use um número alto (isto é, acima de 1000), pois todas as portas abaixo de 1000 exigem permissões de root.
Conta
As contas definidas no arquivo SIPconfig.xml são simplesmente as contas autorizadas a usar o serviço SIP2; isto é, você define quem pode enviar e receber comandos SIP2.
Aviso
As informações de conta inseridas aqui também devem existir no banco de dados do Koha; isto é, você precisa criar um usuário na interface administrativa do Koha com o mesmo nome de usuário e senha (certificando-se de atribuir a permissão circulate) da conta informada no arquivo SIPconfig.xml.
Nota
É altamente recomendável inserir somente contas de usuários do Koha que tenham a permissão circulate.
Recomenda-se que os usuários SIP2 tenham somente a permissão circulate, e não a permissão superlibrarian, para reduzir o acesso deles a dados confidenciais dos usuários caso o sistema seja comprometido.
Se o ACS ou o SC for comprometido, permitir que todos os usuários SIP2 tenham apenas a permissão circulate significa que um invasor só poderá acessar dados de usuários pelo terminal, e não também pela interface web (que estaria disponível com a permissão superlibrarian). Trata-se, portanto, de proteger seus usuários.
Definições dos valores da conta:
ID de login: nome de usuário da conta. — Altere conforme necessário
Senha: senha da conta — Altere conforme necessário
Delimitador: tipo de delimitador das informações da conta — Mantenha o padrão
error-detect — Mantenha o padrão
Instituição: é o branchcode da biblioteca à qual o usuário pertence. OBSERVAÇÃO: essa instituição precisa ser definida mais abaixo, na área institution do arquivo SIPconfig.xml, e também deve existir no banco de dados do Koha. Isto é, você precisa criar uma biblioteca com o mesmo branchcode na interface administrativa do Koha.
encoding: padrão usado para codificar os dados da conta
Terminador: deve corresponder ao valor do terminador do servidor SIP2. — Altere se você souber qual é o valor do terminador do servidor SIP2.
Também é possível adicionar atributos personalizados de usuários aos perfis SIP2 usando um formato como:
<patron_attribute field=”XX” code=”CODE1” /> <patron_attribute field=”XY” code=”CODE2” /> <patron_attribute field=”XZ” code=”CODE3” />
Instituição
As informações de instituição definidas aqui devem corresponder a uma biblioteca criada na interface administrativa do Koha.
Aviso
Certifique-se de que todas as instituições às quais as contas foram atribuídas anteriormente no arquivo SIPconfig.xml também estejam definidas na área institution do mesmo arquivo.
Definições dos valores da instituição:
- ID da instituição: o branchcode da biblioteca. — Altere conforme necessário.
Deve ser igual ao criado no Koha e na área account.
Implementação: define o código que será executado. — Mantenha o padrão
Política: define os comandos SIP2 permitidos aos SCs desta instituição. Por exemplo: renewal=”true” significa que os SCs dessa instituição têm permissão para enviar comandos SIP2 de renovação de exemplares.
Iniciar o SIP2
- Basta digitar o comando:
sudo koha-start-sip <instancename>
Nota
Agora você tem um servidor SIP2 em execução.
Nota
Opcionalmente, você pode configurar o comportamento dos compartimentos de triagem usando as preferências do sistema UseLocationAsAQInSIP e SIP2SortBinMapping.
Usar o SIP2
SIP2 é um protocolo de comunicação. As mensagens enviadas por SIP2 são solicitações ou respostas. Os SCs enviam mensagens de solicitação ao ACS, que executa uma lógica e devolve o valor resultante ao SC como mensagem de resposta.
As mensagens de solicitação contêm argumentos, que são valores de dados usados pelo ACS em suas funções para executar a tarefa necessária, como renovar exemplares.
Comandos SIP2
Se quiser usar ou testar o SIP2 manualmente, você escreverá e receberá mensagens pelo terminal do Linux.
Para enviar e receber mensagens do servidor SIP2, use o telnet para abrir uma conexão SIP2. É necessário especificar o número da porta que o telnet deve usar.
Para localizar essa informação, consulte a área service no início do arquivo SIPconfig.xml (procure o número da porta indicado pela seta na captura de tela abaixo).
Digite no terminal
telnet localhost <portnumber>
Por exemplo: telnet localhost 8023
Agora digite o nome de usuário e a senha definidos em uma das contas do arquivo SIPconfig.xml.
Agora que você está conectado ao servidor SIP2, pode começar a escrever e enviar comandos de solicitação. A conexão com o servidor SIP2 expira rapidamente; portanto, se você ainda não tiver terminado de escrever e receber comandos, basta digitar telnet localhost <portnumber> para reiniciar a conexão SIP2.
Sintaxe dos comandos SIP2
Todo comando SIP2 possui um prefixo numérico de dois dígitos que define o que o comando faz.
Por exemplo, para obter informações sobre um usuário, inicie o comando com o prefixo 63. A resposta do servidor também possui um prefixo numérico correspondente.
Abaixo há um exemplo de mensagem de solicitação SIP2 para obter informações de um usuário (neste exemplo, uma conta de usuário do Koha com nome de usuário ‘joe’, senha ‘joes’ e número de carteirinha ‘y76t5r43’ foi criada na interface administrativa do Koha).
Além disso, uma biblioteca com o branchcode ‘WEL’ foi criada na interface administrativa do Koha e também está definida na área institution do arquivo SIPconfig.xml:
Portanto, o formato desta mensagem de solicitação SIP2 é:
Nota
O valor de resumo tem 10 caracteres. Se Y for informado nesse valor, você poderá obter tanto um resumo quanto uma saída informativa mais detalhada.
O valor em <YYYYMMDD> <HHMMSS> é a data e hora atuais; deixar um intervalo de quatro espaços entre YYYYMMDD e HHMMSS indica que você deseja usar o horário local, e não UTC.
Nota
Neste manual, sempre que possível, são usados códigos de letras para os vários campos ao descrever os campos das mensagens SIP2, por exemplo, AO<institutionid>.
Esses códigos de letras podem ser usados nos comandos SIP2 no terminal do Linux, mas, ao substituir os campos pelos valores (os valores dentro de <>), não inclua os sinais <>.
Mensagens SIP2:
Bloquear usuário
Usa o prefixo 01 para mensagens de solicitação e 24 para mensagens de resposta.
Mensagem de solicitação:
Nota
Cartão retido é um campo de um único caractere, ‘Y’ ou ‘N’, que informa ao ACS que um cartão foi retido pela máquina de autoempréstimo.
Mensagem de resposta:
Nota
<patronstatus> é um valor de 14 caracteres. O valor Y na sequência significa verdadeiro. Cada posição dessa sequência (começando em 0) possui um único valor correspondente (Y ou N).
Por exemplo, um Y na posição 1 (o segundo valor da sequência) significa que os privilégios de renovação do usuário foram negados.
Devolver exemplares
Usa o prefixo 09 para a mensagem de solicitação (mensagens enviadas ao ACS) e o prefixo 10 para a resposta (enviada ao SC).
Mensagem de solicitação:
Nota
<no block (Offline)> é um campo de um único caractere, ‘Y’ ou ‘N’, que indica se a transação está sendo realizada offline. Como transações offline não são compatíveis, você deve informar ‘N’ ao testar esta mensagem manualmente.
<transactiondate> é um campo de 18 caracteres com a data no formato YYYYMMDDZZZZHHMMSS.
ZZZZ é o fuso horário. Para defini-lo como horário local, deixe quatro espaços em branco; para usar UTC (Tempo Universal Coordenado), insira três espaços em branco e um Z.
Mensagem de resposta:
Nota
O tipo de alerta pode ter um destes valores: 00: Desconhecido
01: reserva local
02: reserva remota
03: transferência de EEB
04: transferência
99: Outro
Se um exemplar for reativado, o valor de <resensitize> deverá ser Y; caso contrário, deverá ser N. A reativação de exemplares garante que uma tentativa de furto seja detectada.
Emprestar exemplares
Usa o prefixo 11 para a mensagem de solicitação e o prefixo 12 para a resposta. A sintaxe é semelhante à do comando de devolução descrito acima, exceto pelos prefixos.
Reserva — Pode ainda não ser compatível com alguns sistemas. Possui o prefixo numérico 15 para mensagens de solicitação e 16 para mensagens de resposta.
Mensagem de solicitação:
Nota
<holdmode> é um valor de um único caractere. + significa adicionar uma reserva, - significa excluir uma reserva e * significa alterar uma reserva.
Mensagem de resposta:
Nota
<ok> é um valor de um único caractere, 0 (a reserva não é permitida ou não foi bem-sucedida) ou 1 (a reserva é permitida e foi bem-sucedida).
<available> é um valor de um único caractere, Y ou N. Y significa que o exemplar está atualmente na biblioteca, enquanto N significa que está emprestado ou que outra pessoa fez uma reserva para ele.
Informações do exemplar: usa o prefixo 17 para o comando de solicitação e o prefixo 18 para o comando de resposta
Mensagem de solicitação:
Nota
Consulte o comando de devolução de exemplares (descrito acima) para saber qual é o valor de <xact_date>.
A senha do terminal é opcional.
Mensagem de resposta:
Atualização do status do exemplar: usa o prefixo 19 para a mensagem de solicitação e o prefixo 20 para a mensagem de resposta
Mensagem de solicitação:
Nota
<itemproperties> não é um valor de comprimento fixo; opcionalmente, você pode informar valores como o tamanho do exemplar, que serão armazenados no banco de dados do Koha para o exemplar.
Mensagem de resposta:
Nota
<itempropertiesok> é um valor de um único caractere, 0 ou 1. O valor 1 indica que o valor de <itemproperties> definido na mensagem de solicitação de atualização do status do exemplar foi armazenado com sucesso no banco de dados do Koha.
Status do usuário
Usa o prefixo 23 para a mensagem de solicitação e o prefixo 24 para a mensagem de resposta.
Mensagem de solicitação:
Mensagem de resposta:
Nota
O valor exibido para <patronvalidity> é Y (válido) ou N (inválido). O valor em <YYYYMMDD> < HHMMSS> é a data e hora atuais.
O espaço entre os dois valores indica que você deseja usar o horário local em vez de UTC.
Ativar usuário — Ainda não é compatível. Usa o prefixo 25 para a mensagem de solicitação e o prefixo 26 para a mensagem de resposta
Nota
Este comando desfaz o comando de bloqueio do usuário.
Mensagem de solicitação:
Mensagem de resposta:
Renovar: usa o prefixo 29 para a mensagem de solicitação e o prefixo 30 para a mensagem de resposta
Mensagem de solicitação:
Nota
<thirdpartyallowed> é um valor de um único caractere, Y ou N. Se for Y, terceiros poderão renovar exemplares.
<noblock> é um valor de um único caractere, Y ou N. Se for Y, significa que o exemplar foi devolvido ou emprestado enquanto o ACS estava offline.
<nbduedate> é a data da transação de devolução ou empréstimo realizada enquanto o ACS estava offline.
<feeacknowledged> é um valor de um único caractere, Y ou N. Indica se o usuário aceita a cobrança associada ao exemplar que está renovando.
Mensagem de resposta:
Nota
<ok> é um valor de um único caractere, 0 ou 1. O valor 1 significa que o exemplar foi renovado com sucesso; 0 significa que a renovação não foi bem-sucedida.
<renewalok> é um valor de um único caractere, Y ou N. A lógica para definir <renewalok> é: Y quando o exemplar já está emprestado ao usuário e, portanto, deve ser dessensibilizado e renovado; N quando o exemplar não está emprestado ao usuário e, portanto, não deve ser renovado.
Em outras palavras, não permita que usuários renovem livros que não estejam emprestados a eles no momento.
<magneticmedia> é um valor de um único caractere: Y (sim), N (não) ou U (desconhecido).
<mediatype> é um valor numérico de três caracteres. Para consultar a lista de valores, acesse: https://web.archive.org/web/20190712041755/https://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
Encerrar sessão
Usa o prefixo 35 para a mensagem de solicitação e o prefixo 36 para a mensagem de resposta
Mensagem de solicitação:
Mensagem de resposta:
Nota
<success_or_failure> é Y para sucesso ou N para falha.
Taxa paga — Talvez ainda não esteja implementado. Usa o prefixo 37 para a mensagem de solicitação e o prefixo 38 para a mensagem de resposta
Mensagem de solicitação:
Nota
<feetype> é um valor numérico de dois caracteres entre 01 e 99. Para consultar a lista de tipos de taxa, acesse https://web.archive.org/web/20190712041755/https://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
<paymenttype> é um valor numérico de dois caracteres entre 00 e 99. 00 corresponde a dinheiro, 01 a Visa e 02 a cartão de crédito.
<currencytype> é um valor alfanumérico de três caracteres que identifica a moeda em que a taxa foi paga.
Mensagem de resposta:
Nota
<paymentaccepted> é um valor alfanumérico de um único caractere: Y (pagamento aceito) ou N (pagamento não aceito).
Informações do usuário
Usa o prefixo 63 para a mensagem de solicitação e o prefixo 64 para a mensagem de resposta
Mensagem de solicitação:
Mensagem de resposta:
Nota
<valid patron> é Y para válido e N para inválido.
Nota
<hold itemcount><overdueitemcount><chargeditemscount><fienitemscount><recallitemscount><unavaliableholdscount> são todos valores numéricos de quatro caracteres.
Renovar todos
Usa o prefixo 65 para a mensagem de solicitação e o prefixo 66 para a mensagem de resposta.
Mensagem de solicitação:
Mensagem de resposta:
Nota
<renewedcount> é um valor numérico de quatro caracteres que indica a quantidade de exemplares renovados.
<unrenewedcount> tem o mesmo formato que <renewedcount>, mas indica a quantidade de exemplares não renovados.
Login
Usa o prefixo 93 para a mensagem de solicitação e o prefixo 94 para a mensagem de resposta.
Mensagem de solicitação:
Nota
<UIDalgorithm> e <PWDalgorithm> são valores de um caractere que indicam, respectivamente, o tipo de algoritmo usado para criptografar loginuserid e loginpassword.
Informar o valor 0 significa que esses valores não serão criptografados.
Mensagem de resposta: 941 indica um login bem-sucedido
940 indica um login malsucedido
[connection closed by foreign host.] indica um login malsucedido
Reenviar
Solicita que o dispositivo receptor reenvie sua última mensagem.
A solicitação de reenvio do SC para o ACS é 97
A solicitação de reenvio do ACS para o SC é 96
Status do ACS e do SC
Possui o prefixo 99 para a mensagem de solicitação e o prefixo 98 para a mensagem de resposta.
Mensagem de solicitação:
Nota
O código de status tem um destes três valores. — 0: o SC está funcionando normalmente
1: o SC está sem papel
2: o SC está sendo desligado
A largura máxima de impressão é um valor de três caracteres que corresponde ao número inteiro de caracteres que o cliente pode imprimir
A versão do protocolo é um valor de quatro caracteres no formato x.xx
Mensagem de resposta:
Nota
Se você receber a mensagem de resposta ‘96’, isso significa que a mensagem de solicitação não é válida ou não foi compreendida.
Solução de problemas do SIP2
Não é possível conectar-se ao host remoto ao digitar o comando telnet localhost <portnumber>
Há três soluções possíveis para tentar corrigir esse problema:
Verifique se o número da porta digitado no comando acima é o mesmo informado no arquivo SIPconfig.xml no local indicado pelo número 1. Por exemplo, como o número da porta abaixo é 6001, o comando correto seria: telnet localhost 6001.
Verifique se algum userid aparece mais de uma vez no arquivo SIPconfig.xml. O userid (que é simplesmente o nome de usuário do usuário do Koha) deve ser exclusivo dentro do arquivo SIPconfig.xml. Se o mesmo userid aparecer várias vezes no arquivo, a conexão com o SIP2 falhará antes que você tenha a oportunidade de se autenticar.
Verifique se a conta definida no arquivo SIPconfig.xml também existe no banco de dados do Koha com o mesmo nome de usuário e senha e se possui a permissão circulate. Se você excluiu e recriou o banco de dados do Koha depois de criar a conta do usuário na interface administrativa e no arquivo SIPconfig.xml, essa conta não existirá no banco de dados e precisará ser recriada na interface administrativa.
Para acessar os logs do SIP2 no diretório inicial do Koha, navegue até o seguinte diretório: /var/log/koha/<instancename>
Em seguida, consulte a saída dos arquivos sip-error.log e sip-output.log, que fornecem informações mais detalhadas sobre o erro do SIP2.
cat sip-error.log
cat sip-output.log
Links úteis sobre comandos SIP2:
LDAP
Configurar o LDAP (Lightweight Directory Access Protocol) para o Koha permite armazenar todas as informações dos usuários em um banco de dados central, acessado tanto pela instância do Koha da organização quanto pelos usuários para se autenticarem em outros sistemas existentes.
LDAP é um protocolo usado para localização de arquivos em redes e autenticação de rede.
As configurações do LDAP são flexíveis e permitem personalizar a interação entre o Koha e o LDAP. O LDAP pode ser configurado para que novas contas criadas nele sejam sincronizadas com o banco de dados do Koha e para que as atualizações das contas de usuários do LDAP também sejam sincronizadas com o banco de dados do Koha.
No entanto, o Koha não consegue sincronizar dados com o servidor LDAP; assim, o tráfego de dados ao usar LDAP é unidirecional.
Auth_By_Bind é definido como 1 quando um sistema Microsoft Windows Active Directory é usado no banco de dados LDAP.
Antes de seguir as etapas para configurar o LDAP, você precisará obter da organização as seguintes informações ou providências
A organização precisará abrir uma porta para permitir o acesso ao AD a partir do servidor.
Informações de acesso ao servidor AD (endereço IP/nome do host, porta e informações de SSL)
Informações sobre a configuração do servidor AD (OUs, DCs e formatos de CN relevantes em relação aos nomes de usuário)
Mapeamento entre os campos do AD e os campos do Koha, incluindo os valores padrão
Valores padrão para informações não fornecidas pelo AD (categorycode e branchcode, por exemplo)
Para autenticar um usuário, fazemos o bind como esse usuário (o que parece ser comum no AD) ou usamos uma conta, entramos com ela e depois fazemos a verificação? Se for a segunda opção, precisaremos dos detalhes para entrar
Os nomes de usuário existentes no Koha correspondem aos nomes que usaremos para pesquisá-los no AD? Se sim, ótimo. Caso contrário, como lidaremos com usuários duplicados?
Etapas para configurar o LDAP em sua instância do Koha
- 1 No terminal do Linux, acesse o diretório que contém o arquivo koha-conf.xml, que estará em um destes locais:
/etc/koha/sites/<instance-name>/
ou
/etc/koha/
2 Abra o arquivo koha-conf.xml com permissões de root: sudo vi koha-conf.xml
3 Role até a linha que contém ‘<useldapserver>0</useldapserver>’ e altere-a para: <useldapserver>1</useldapserver>
4 Em seguida, na linha seguinte, insira as configurações LDAP abaixo:
<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 Salve e feche o arquivo koha-conf.xml
6 Verifique se a conexão LDAP funciona digitando:
ldapsearch -H ldaps://host.name -s base -x -w “” -d 1
Nota
Observação sobre o nome do host:
O nome do host pode ser um nome alfanumérico ou o endereço IP do servidor LDAP (informar o número da porta é opcional).
Por padrão, a porta padrão do ldaps é 636, enquanto a porta padrão do ldap é 389.
Nota
Observação sobre os campos replicate e update:
O campo de configuração replicate do LDAP no arquivo koha-conf.xml permite adicionar ao banco de dados do Koha uma nova conta de usuário sempre que alguém entra no Koha (na interface administrativa ou no OPAC) com seu nome de usuário e senha do LDAP, desde que o mesmo nome de usuário e senha ainda não existam no banco de dados do Koha.
Já o campo de configuração update do LDAP (no mesmo arquivo) permite sincronizar as informações dos usuários do banco de dados LDAP com o banco de dados do Koha.
Por exemplo, se uma pessoa se casar e seu sobrenome mudar, o novo sobrenome só precisará ser atualizado no banco de dados LDAP existente; ele será sincronizado automaticamente com o banco de dados do Koha se a configuração update estiver definida como 1.
Sobre os campos de mapeamento (os campos destacados em verde) <city is=”l”>Athens, OH</city>
O nome da coluna à esquerda (destacado em amarelo) é o nome da coluna no banco de dados LDAP.
O nome da coluna entre aspas (destacado em rosa) é o nome da coluna no banco de dados do Koha. OBSERVAÇÃO: ele pode ser preenchido com qualquer valor quando não houver no banco de dados do Koha uma coluna equivalente à existente no banco de dados LDAP.
O valor destacado em ciano é o valor padrão das colunas especificadas do Koha e do LDAP. Portanto, no exemplo acima, todos os registros de usuários nos bancos de dados do Koha e do LDAP terão, por padrão, o valor de cidade ‘Athens, OH’.
Exemplo das configurações LDAP:
<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>
Os valores na área de mapeamento nem sempre são os mesmos e dependem do conteúdo do banco de dados LDAP de sua organização. Por exemplo, algumas organizações não usam <userid>; cada usuário é identificado somente pelo campo <email> e, portanto, nenhum <userid> é informado.
Solução de problemas do LDAP
O log no qual os erros de LDAP são registrados depende de vários fatores:
Se o Plack não estiver desativado, os erros de LDAP serão exibidos no arquivo plack-error.log. Se o Plack estiver desativado, os erros serão registrados no arquivo opac-error.log (quando o usuário entra no OPAC) ou no arquivo intranet-error.log (quando o usuário entra na interface administrativa). Esses três arquivos de log podem ser acessados no seguinte diretório:
/var/log/koha/<instance>/