Outras APIs e protocolos
SIP2
O SIP2 (Session Initiation Protocol) é um protocolo de comunicação entre dispositivos.
No contexto do Koha, o SIP2 é utilizado para a comunicação entre 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.
Os terminais de autoatendimento não têm lógica de negócio e, portanto, enviam solicitações ao servidor Koha, que executa a lógica para determinar um resultado específico. Esse resultado é enviado como uma mensagem de resposta de volta ao terminal de autoatendimento e, em seguida, comunicado ao utilizador.
Aviso
Aviso de segurança sobre o uso do serviço SIP2: para garantir a segurança do seu tráfego SIP2 ao transitar pela internet, deve assegurar-se que utiliza uma VPN ou stunnel.
Configuração do SIP2
Dica
Dicas úteis podem ser encontradas na wiki do Koha:
Configuração do servidor SIP2 do Koha e Configuração do SIP2.
Se instalou o Koha usando pacotes Debian, a configuração do SIP2 é fácil, basta seguir estes passos:
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
Nota importante: existem três áreas de interesse no arquivo SIPconfig.xml que precisa alterar. São elas: serviço, conta e instituição.
Serviço
2.1 Altere o valor da porta no início do ficheiro SIPconfig.xml (identificado pelo número 1 na captura de tela abaixo), de modo que ele tenha o mesmo endereço IP definido mais adiante no arquivo SIPconfig.xml, identificado pelo número 2.
Nota
Certifique-se de que os dois valores de porta não são iguais, uma vez que dois serviços diferentes não conseguem escutar na mesma porta. Ao definir o número da porta, escolha um valor elevado (ou seja, acima de 1000), uma vez que todas as portas abaixo de 1000 requerem permissões de administrador.
Conta
As contas que define no ficheiro SIPconfig.xml são simplesmente contas com permissão para utilizar o serviço SIP2, ou seja, está a definir quem pode enviar e receber comandos SIP2.
Aviso
As informações da conta aqui inseridas também devem existir na base de dados do Koha, ou seja, precisa de criar um utilizador na interface administrativa do Koha com o mesmo nome de utilizador e palavra-passe da conta de utilizador que definir no ficheiro SIPconfig.xml, certificando-se de que lhe atribui a permissão de circulação.
Nota
É altamente recomendável que apenas insira contas de leitor no Koha com a permissão de circulação.
A razão pela qual queremos que os utilizadores SIP2 tenham apenas a permissão de circulação, em vez da permissão de superbibliotecário, é reduzir o acesso destes utilizadores a dados confidenciais dos leitores da biblioteca, caso o sistema seja comprometido.
Se o ACS ou o SC fossem comprometidos, o facto de todos os utilizadores SIP2 possuírem apenas a permissão de circulação significa que um atacante apenas conseguiria aceder aos dados dos leitores através do terminal, e não através da interface web (o que seria possível com a permissão de superbibliotecário). Portanto, trata-se simplesmente de proteger os seus leitores.
Definições de valor da conta:
Login id: Este é o nome de utilizador da conta. – Modifique-o conforme necessário
Password: Palavra-passe da conta – Modifique conforme necessário
Delimiter: O tipo de delimitador para as informações da conta - Mantenha o padrão
error-detect - Deixar como padrão
Institution: Este é o código da biblioteca à qual o utilizador pertence. NOTA: Esta instituição necessita de ser definida mais abaixo, na secção de instituições do ficheiro SIPconfig.xml, devendo também existir na base de dados do Koha, ou seja, é necessário criar uma biblioteca com o mesmo código na interface administrativa do Koha.
encoding: Este é o padrão utilizado para codificar os dados da conta
Terminator: Este deve corresponder ao valor do terminador do servidor SIP2. - Modifique isto se souber o valor do terminador do servidor SIP2.
Também é possível adicionar atributos personalizados de leitor aos perfis SIP2 utilizando 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 da instituição que aqui definir devem corresponder a uma biblioteca criada na interface administrativa do Koha.
Aviso
É necessário garantir que todas as instituições às quais as contas estão atribuídas, mais acima no ficheiro SIPconfig.xml, também estão definidas na secção de instituições do mesmo ficheiro.
Definições de valores de instituição:
- Institution id: O código da biblioteca. - Modifique conforme necessário.
Deve ser igual ao criado no Koha e na área da conta.
Implementation: Define o código que será executado. - Mantenha o padrão
Policy: A política define os comandos SIP2 permitidos para os SC nesta instituição. Por exemplo: renewal=”true” significa que os SC dessa instituição têm permissão para enviar comandos SIP2 de renovação de empréstimos.
Iniciar SIP2
- Basta digitar o comando:
sudo koha-start-sip <instancename>
Nota
Agora tem um servidor SIP2 em execução.
Nota
Opcionalmente, pode configurar o comportamento da caixa de classificação utilizando as preferências de sistema UseLocationAsAQInSIP e SIP2SortBinMapping.
Usar SIP2
O SIP2 é um protocolo de comunicação. As mensagens enviadas no SIP2 são pedidos ou respostas. Os SC enviam mensagens de pedido ao ACS, que executa uma determinada lógica e devolve o valor resultante ao SC como mensagem de resposta.
As mensagens de pedido contêm argumentos, que são valores de dados utilizados pelo ACS nas suas funções para realizar a tarefa necessária, como por exemplo a renovação de empréstimos.
Comandos SIP2
Se quiser utilizar ou testar o SIP2 manualmente, escreverá e receberá mensagens através do terminal Linux.
Para enviar e receber mensagens com o servidor SIP2, é necessário utilizar o telnet para abrir uma ligação SIP2. É necessário especificar o número da porta que pretende que o telnet utilize.
Para encontrar esta informação, verifique a secção de serviço na parte superior do ficheiro SIPconfig.xml (procure o número da porta indicado pela seta na captura de ecrã abaixo).
Escreva no terminal
telnet localhost <portnumber>
exemplo: telnet localhost 8023
Agora, introduza o nome de utilizador e a palavra-passe definidos para uma das contas no ficheiro SIPconfig.xml.
Agora que está ligado ao servidor SIP2, pode começar a escrever e a enviar comandos de pedido. A ligação ao servidor SIP2 expira rapidamente; assim, se ainda não tiver terminado de escrever e receber comandos, basta escrever telnet localhost <número_da_porta> para reiniciar a ligação SIP2.
Sintaxe de comando SIP2
Todo o comando SIP2 possui um prefixo numérico de dois dígitos que define a função do comando.
Por exemplo: para obter informações sobre um utilizador, inicia-se o comando com o prefixo 63. A resposta do servidor apresenta também um prefixo numérico correspondente.
Abaixo, apresenta-se um exemplo de uma mensagem de pedido SIP2 para obter informações de um leitor (neste exemplo, uma conta de leitor no Koha com o nome de utilizador “joe”, a palavra-passe “joes” e o número de cartão “y76t5r43” foi criada na interface administrativa do Koha).
Além disso, foi criada uma biblioteca com o código ‘WEL’ na interface do Koha e também está definida na secção da instituição do ficheiro SIPconfig.xml:
Assim, o formato desta mensagem de pedido SIP2 é:
Nota
O valor de resumo é um valor de 10 caracteres. Se for introduzido um “Y” como valor de resumo, pode obter tanto um resumo como uma informação de saída mais detalhada.
O valor em <YYYYMMDD> <HHMMSS> corresponde à data e hora atuais; se deixar um espaço de quatro caracteres entre YYYYMMDD e HHMMSS indica que pretende utilizar a hora local em vez da UTC.
Nota
Utilizam-se códigos de letras para os diversos campos sempre que possível ao descrever os campos da mensagem SIP2 (por exemplo, AO<institutionid>).
Estes códigos de letras podem ser introduzidos nos comandos SIP2 no terminal Linux, mas, ao substituir os valores dos campos (aqueles que estão entre parênteses angulares < >), certifique-se de que não inclui os próprios parênteses rectos.
Mensagens SIP2:
Bloquear leitor
Utiliza o prefixo 01 para as mensagens de pedido e 24 para as mensagens de resposta.
Mensagem de pedido:
Nota
Cartão retido é um campo de um único caractere, ‘Y’ ou ‘N’, que informa o ACS de que um cartão foi retido pelo terminal de auto-empréstimo.
Mensagem de resposta:
Nota
<patronstatus> é um valor com 14 caracteres de comprimento. O valor Y na string significa verdadeiro. Cada posição nesta string (a partir de 0) tem um único valor correspondente (Y ou N) na string.
Por exemplo, um Y na posição 1 (o segundo valor na string) significa que os privilégios de renovação do utilizador são negados.
Devolução de exemplares
Utiliza o prefixo 09 para a mensagem de pedido (mensagens enviadas para o ACS) e o prefixo 10 para a mensagem de resposta (enviada para o SC).
Mensagem de pedido:
Nota
<no block (Offline)> é um campo de um único caractere, ‘Y’ ou ‘N’, que indica se a transação está a ser realizada offline. Como as transações offline não são suportadas, deve introduzir ‘N’ se estiver a testar esta mensagem manualmente.
<transactiondate> este é um campo de 18 caracteres com a data no formato: YYYYMMDDZZZZHHMMSS.
ZZZZ representa o fuso horário; se quiser defini-lo como local, precisa de deixar 4 espaços em branco, mas se quiser defini-lo como UTC (Tempo Universal Coordenado), deve introduzir 3 espaços em branco e um Z.
Mensagem de resposta:
Nota
O tipo de alerta pode assumir um de vários valores: 00 : Desconhecido
01: reserva local
02: reserva remota
03: transferência ILL
04: transferência
99: outro
Se um exemplares for resensibilizado, o valor de <resensitize> deverá ser Y, caso contrário, deve ser N. A resensibilização de exemplares é realizada para garantir que, se alguém tentar roubar o exemplares, é detetado.
Emprestar exemplares
Utiliza o prefixo de mensagem de pedido 11 e o prefixo de mensagem de resposta 12. A sintaxe é semelhante à do comando de devolução descrito acima, exceto os prefixos, que são diferentes.
Reserva – Pode ainda não ser suportado em alguns sistemas. Possui um prefixo numérico de 15 para a mensagem de pedido e um prefixo de 16 para a mensagem de resposta.
Mensagem de pedido:
Nota
<holdmode> é um valor de caractere único. + significa adicionar uma reserva, - significa eliminar uma reserva e * significa alterar uma reserva.
Mensagem de resposta:
Nota
<ok> é um valor de comprimento único que é 0 (caso a reserva não seja permitida ou não tenha sido bem-sucedida) ou 1 (caso a reserva seja permitida e tenha sido 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 o exemplar está emprestado ou que outra pessoa solicitou a reserva do exemplar.
Informações do exemplar: Utiliza o prefixo de comando de pedido 17 e o prefixo de comando de resposta 18.
Mensagem de pedido:
Nota
Consulte o comando de devolução de exemplares (descrito acima) para saber qual é o valor de <xact_date>.
A palavra-passe do terminal é opcional.
Mensagem de resposta:
Atualização do estado do exemplar: utiliza o prefixo de mensagem de pedido 19 e o prefixo de mensagem de resposta 20
Mensagem de pedido:
Nota
<itemproperties> não é um campo de tamanho fixo e pode, opcionalmente, introduzir valores como o tamanho do exemplar, e estes valores serão armazenados na base de dados do Koha para o exemplar em questão.
Mensagem de resposta:
Nota
<itempropertiesok> é um valor de caractere de comprimento unitário, sendo 0 ou 1. O valor 1 indica que o valor de <itemproperties>, definido na mensagem de pedido de atualização do estado do exemplar, foi armazenado com sucesso na base de dados do Koha.
Estado do leitor
Utiliza o prefixo de mensagem de pedido 23 e o prefixo de mensagem de resposta 24.
Mensagem de pedido:
Mensagem de resposta:
Nota
O valor apresentado para <patronvalidity> é Y (válido) e N (inválido). O valor em <YYYYMMDD> < HHMMSS> corresponde à data/hora atual.
O motivo da diferença entre os dois valores é definir que pretende utilizar a hora local em vez do UTC.
Ativação do leitor - Isto ainda não é suportado. Esta funcionalidade utiliza o prefixo de mensagem de pedido 25 e o prefixo de mensagem de resposta 26.
Nota
Este comando anula o comando de bloqueio de leitor.
Mensagem de pedido:
Mensagem de resposta:
Renovar: Utiliza o prefixo de mensagem de pedido 29 e o prefixo de mensagem de resposta 30
Mensagem de pedido:
Nota
<thirdpartyallowed> é um valor de caractere único, podendo ser Y ou N. Se for Y, terceiros podem renovar exemplares.
<noblock> é um valor de caractere único, sendo Y ou N. Se for Y, isto significa que o exemplar foi objeto de devolução ou empréstimo enquanto o ACS estava offline.
<nbduedate> é a data da transação de devolução/empréstimo ocorrida enquanto o ACS estava offline.
<feeacknowledged> é um valor de caractere único, podendo ser Y ou N. Indica se o leitor aceita a taxa associada ao exemplar que está a renovar.
Mensagem de resposta:
Nota
<ok> é um valor de caractere único que pode ser 0 ou 1. Um valor de 1 significa que o exemplar foi renovado com sucesso; 0 significa que o exemplar não foi renovado com sucesso.
<renewalok> é um valor de caractere único, podendo ser Y ou N. A lógica para definir o valor de <renewalok> é a seguinte: define-se Y quando o exemplar já está emprestado ao utilizador e, portanto, deve ser desativado (realizando assim a renovação); por outro lado, define-se N se o exemplar não estiver emprestado ao utilizador e, por isso, não deve ser renovado.
Por outras palavras, não permita que os leitores renovem livros que não lhes estejam atualmente emprestados.
<magneticmedia> é um valor de caractere único que pode ser Y (para sim), N (para não) ou U (para desconhecido).
<mediatype> é um valor composto por três caracteres numéricos. Para obter uma lista dos valores, aceda a: https://web.archive.org/web/20190712041755/https://multimedia.3m.com/mws/media/355361O/sip2-protocol.pdf
Encerrar sessão
Utiliza o prefixo de mensagem de pedido 35 e o prefixo de mensagem de resposta 36
Mensagem de pedido:
Mensagem de resposta:
Nota
<success_or_failure> é Y para sucesso ou N para falha.
Taxa Paga – Pode ainda não estar implementado. Utiliza um prefixo de mensagem de pedido 37 e um prefixo de mensagem de resposta 38
Mensagem de pedido:
Nota
<feetype> é um valor numérico de dois dígitos entre 01 e 99. Para ver uma lista de valores de tipo de taxa, aceda a 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 é dinheiro, 01 é Visa e 02 é cartão de crédito.
<currencytype> é um valor de 3 caracteres alfanuméricos que identifica a moeda usado no pagamento.
Mensagem de resposta:
Nota
<paymentaccepted> é um valor de um único caractere alfanumérico, sendo Y (pagamento aceite) ou N (pagamento não aceite).
Informação do leitor
Utiliza o prefixo de mensagem de pedido 63 e o prefixo de mensagem de resposta 64
Mensagem de pedido:
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 com 4 caracteres numéricos.
Renovar todos
Utiliza o prefixo de mensagem de pedido 65 e o prefixo de mensagem de resposta 66.
Mensagem de pedido:
Mensagem de resposta:
Nota
<renewedcount> é um valor de 4 caracteres numéricos que indica o número de empréstimos renovados.
<unrenewedcount> tem o mesmo formato que <renewedcount>, mas indica o número de empréstimos não renovados.
Autenticação
Utiliza o prefixo de mensagem de pedido 93 e o prefixo de mensagem de resposta 94.
Mensagem de pedido:
Nota
<UIDalgorithm> e <PWDalgorithm> são valores de um único caractere que indicam o tipo de algoritmo a utilizar para encriptar o loginuserid e a loginpassword, respetivamente.
Definir o valor como 0 significa que estes valores não serão encriptados.
Mensagem de resposta: 941 indica um início de sessão bem-sucedido
940 é uma tentativa de autenticação mal sucedida
[connection closed by foreign host.] indica uma tentativa de autenticação mal sucedida
Reenviar
Solicita ao dispositivo recetor que reenvie a sua última mensagem.
O pedido de reenvio SC -> ACS é 97
O pedido de reenvio ACS -> SC é 96
Estado do ACS e do SC
Isto tem o prefixo de mensagem de pedido 99 e o prefixo de mensagem de resposta 98.
Mensagem de pedido:
Nota
O código de estado é um de três valores. - 0: SC está ok
1: O SC está sem papel
2: O SC está a ser encerrado
a largura máxima de impressão é um valor de 3 caracteres que representa o número inteiro de caracteres que o cliente pode imprimir
A versão do protocolo é um valor de 4 caracteres no formato x.xx
Mensagem de resposta:
Nota
Se receber a mensagem de resposta ‘96’, significa que a mensagem de pedido não é válida ou não foi compreendida.
Resolução de problemas SIP2
Não é possível ligar ao host remoto ao executar o comando telnet localhost <número_da_porta>
3 soluções a experimentar para este problema são:
Verifique se o número da porta que está a introduzir no comando acima corresponde ao número da porta especificado no ficheiro SIPconfig.xml, na localização indicada pelo número 1. Ou seja, no exemplo abaixo, como o número da porta é 6001, o comando correcto seria: telnet localhost 6001.
Verifique se algum userid aparece mais do que uma vez no ficheiro SIPconfig.xml. O userid (que é simplesmente o nome de utilizador do Koha) deve ser único dentro do ficheiro SIPconfig.xml. Se o mesmo userid constar várias vezes no ficheiro SIPconfig.xml, a ligação ao SIP2 falhará antes de ter a oportunidade de se autenticar.
Verifique se a conta definida no ficheiro SIPconfig.xml também existe na base de dados do Koha com o mesmo nome de utilizador e palavra-passe, e se possui a permissão de circulação. Se tiver eliminado e recriado a base de dados do Koha após criar a conta de utilizador na interface administrativa do Koha e o ficheiro SIPconfig.xml, essa conta de utilizador deixará de existir na base de dados e será necessário recriá-la na interface administrativa do Koha.
Para aceder aos registos do SIP2 no diretório inicial do Koha, navegue até ao seguinte diretório: /var/log/koha/<instancename>
Em seguida, visualize o conteúdo dos ficheiros sip-error. log e sip-output. log, que fornecem informações mais detalhadas sobre o erro SIP2.
cat sip-error.log
cat sip-output.log
Endereços úteis sobre os comandos SIP2:
LDAP
A configuração do LDAP (Lightweight Directory Access Protocol) para o Koha permite armazenar todas as informações dos utilizadores numa base de dados central, acedida tanto pela instância Koha da sua organização como pelos utilizadores para autenticação noutros sistemas existentes.
O LDAP é um protocolo utilizado para a descoberta de ficheiros em redes e para a autenticação de redes.
As configurações LDAP são poderosas, permitindo personalizar a forma como o Koha e o LDAP interagem. O LDAP pode ser configurado de modo a que as novas contas nele criadas sejam sincronizadas com a base de dados do Koha; além disso, as atualizações nas contas de utilizador LDAP também são sincronizadas com a base de dados Koha.
No entanto, o Koha não consegue sincronizar os dados com o servidor LDAP, ou seja, o tráfego de dados ao utilizar o LDAP é unidirecional.
O parâmetro auth_by_bind é definido como 1 quando é utilizado um sistema Microsoft Windows Active Directory na base de dados LDAP.
Antes de seguir os passos para configurar o LDAP, necessita das seguintes informações/ações da organização
A organização terá de abrir uma porta para permitir o acesso à AD a partir do servidor.
Informação sobre o acesso ao servidor AD (endereço IP/nome do host, porta, informação SSL)
Informação sobre a configuração do servidor AD (UOs relevantes, DCs, formatos CN em relação aos nomes de utilizador)
Mapeamento entre campos AD e campos Koha, incluindo valores por defeito
Valores por omissão para dados não fornecidos pela AD (por exemplo, categorycode e branchcode)
Para autenticar um utilizador, devemos realizar o bind com as credenciais do mesmo (o que parece ser comum na AD) ou utilizar uma conta específica para fazer a autenticação e, de seguida, realizar a verificação? Se for a segunda opção, necessitaremos de detalhes sobre como realizar essa autenticação
Os nomes de utilizador existentes no Koha correspondem aos nomes de utilizador que iremos utilizar para os localizar no AD? Se sim, ótimo. Caso contrário, como lidaremos com utilizadores duplicados?
Passos para configurar o LDAP com a sua instância Koha
- 1 No terminal Linux, navegue até à diretoria que contém o ficheiro koha-conf.xml, que estará em:
/etc/koha/sites/<instance-name>/
OU
/etc/koha/
2 Abra o ficheiro koha-conf.xml com permissões de root: sudo vi koha-conf.xml
3 Desça o ecrã até à linha que contém ‘<useldapserver>0</useldapserver>’ e altere-a para: <useldapserver>1</useldapserver>
4 De seguida, na linha logo abaixo, insira as definiçõ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 Guarde e saia do ficheiro koha-conf.xml
6 Verifique se a ligação LDAP funciona, introduzindo:
ldapsearch -H ldaps://host.name -s base -x -w “” -d 1
Nota
Nota sobre o hostname:
Pode ser um nome alfanumérico ou o endereço IP do servidor LDAP (a introdução do número da porta é opcional).
Por omissão, o número da porta do ldaps é 636, enquanto o número da porta do ldap é 389.
Nota
Nota sobre os campos de replicação e atualização:
O campo de configuração para a replicação LDAP no ficheiro koha-conf.xml permite que uma nova conta de utilizador seja adicionada à base de dados do Koha sempre que um utilizador inicie sessão no sistema (seja na interface administrativa ou no OPAC) utilizando o seu nome de utilizador e palavra-passe LDAP (desde que esse mesmo par de nome de utilizador e palavra-passe ainda não exista na base de dados do Koha).
Por sua vez, o campo de configuração de atualização LDAP (no mesmo ficheiro) permite que as informações de utilizador da base de dados LDAP sejam sincronizadas com a base de dados do Koha.
Por exemplo, se alguém se casar e o seu apelido mudar, o novo apelido apenas necessitará de ser atualizado na base de dados LDAP existente e esta alteração será sincronizada automaticamente com a base de dados do Koha, desde que a definição de atualização esteja definida para 1.
Sobre os campos de mapeamento (os campos destacados a verde) <city is=”l”>Athens, OH</city>
O nome na coluna da esquerda (destacado a amarelo) é o nome da coluna na base de dados LDAP.
O nome da coluna entre aspas (destacado a cor-de-rosa) é o nome da coluna na base de dados do Koha. NOTA: Este campo pode ser preenchido com qualquer valor caso não exista, na base de dados do Koha, um nome de coluna equivalente ao existente na base de dados LDAP.
O valor destacado a ciano é o valor predefinido para as colunas especificadas do Koha e do LDAP. Assim, no exemplo acima, todos os registos de utilizadores nas bases de dados do Koha e do LDAP terão, por defeito, o valor de cidade ‘Athens, OH’.
Exemplo de 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 porque depende do conteúdo da base de dados LDAP da sua organização. Por exemplo, algumas organizações não utilizam o <userid> e cada utilizador é identificado apenas pelo campo <email> e, portanto, não é registado nenhum <userid>.
Resolução de problemas LDAP
O registo no qual os erros LDAP são registados depende de vários fatores:
Se o Plack não estiver desativado, são apresentados erros LDAP no ficheiro plack-error. log. Se o Plack estiver desativado, o local onde são registados os erros LDAP é o ficheiro opac-error. log (caso o utilizador esteja a aceder ao OPAC) ou o ficheiro intranet-error. log (caso o utilizador esteja a aceder à interface administrativa). Todos estes três ficheiros de registo podem ser acedidos no seguinte diretório:
/var/log/koha/<instance>/