SafeQ integration
Integracija podataka o korisnicima iz sustava za kopiranje, Koha knjižničnog sustava i AAI sustava uz pomoć LDAP protokola

Podaci na korisničkim karticama
Opis procesa pripreme podataka na karticama za korištenje u 3M RFID sustavu i u sustavu za fotokopiranje

Printanje i programiranje kartica
Opis trenutne procedure printanja i programiranja kartica. Bilješke o razvoju nove procedure.

Iskaznice za kopiranje za grupu korisnika

Upute za otklanjanje problema

RFID čitači na kopirkama javljaju "Zabranjen pristup", i stroj nije pripremljen (tako nešto...)

Pobrisati jobove na kopirci

Ne radi printanje

Da bi radilo printanje sa studentskih računala, korisnik mora imati AAIedu korisnički račun (za logiranje u računala, oblika login@ffzg.hr) i mora imati isti login u Kohi pod OPAC login.

AAIedu login i zaporka se mogu provjeriti logiranjem na https://ldap.ffzg.hr/

Ova stranica opisuje postupak koji prolaze podaci da bi novootvoreni korisnici preko Koha sučelja
a) dobili članski broj (broj kartice)
b) pojavili se u SafeQ sustavu.

SafeQ sustav povlači podatke o korisnicima iz Kohe preko LDAP-a. LDAP je implementiran direktno na podacima u Kohi (vidi SafeQ integration), ali SafeQ ne može pročitati broj korisnika sa kartice, nego samo serijski broj kartice koji koristi RFID protokol (SID).

Taj broj postoji jedino u log datotekama 3M sustava, a kako računalo na kojem se programiraju čipovi za sad nije spojeno na mrežu, cijela procedura ipak ovisi o povremenom presnimavanju podataka na server.

U razvoju je zamjena za cijelu ovu proceduru koja bi omogućila printanje novih isprogramiranih kartica odmah nakon što se korisnik prvi puta ulogira u Kohu (tj. odmah čim aktivira članstvo u knjižnici).

trenutno stanje

Generiranje brojeva kartica

Prvi korak je dodjeljivanje brojeva kartica u obliku 200908240042 gdje su prve znamenke datum a zadnje četiri redni broj korisnika u tom danu. To je jedinstveni broj korisnika koji koriste svi ostali servisi (npr. 3M Selfcheck) ali ne i SafeQ-a!

Generiranje brojeva kartica

ovaj korak radi se na produkcijskoj bazi

dpavlin@koha:/srv/koha-rfid$ ./generate-cardnumber.pl --commit

provjeriti ispis i pokrenuti ponovo sa --commit da bi se promjene zapisale u bazu

generira također backup borrowers tablice

Ispisuje na kraju generirato ime log datoteke:

backup for borrowers table: backup/borrowers.2010-09-02T15:05:09.sql 3838484 bytes
generated print.2010-09-02T15:05:09.txt 41879 bytes

Format loga: cardnumber <tab> login <tab> ime <tab> prezime

dpavlin@klin:~/klin/Biblio-RFID$ head -1 print.2010-09-02T15\:05\:09.txt 
201007140004    kohatest@ffzg.hr        Koha    Testičić Probišić Đž

Printanje iskaznica

ovaj korak se radi na mašini sa koje se printaju iskaznice

Podaci za pritanje

dpavlin@klin:~/klin/Biblio-RFID$ rsync -v koha:/srv/koha-rfid/print*.*.txt .

Pokretanje printanja

Printanje čeka da se kartica makne na RFID čitača da bi nastavilo!

dpavlin@klin:~/klin/Biblio-RFID$ ./scripts/print.pl print.2010-09-02T15\:05\:09.txt

...

QUEUE EMPTY - printing finished
log.print/2010-08-17T16:36:27.txt 100 bytes created

Kopiranje SID-ova za Kohu

dpavlin@klin:~/klin/Biblio-RFID$ rsync -rav log.print/ koha.ffzg.hr:/srv/koha-rfid/log.print/

Import SID-ova u Kohu

dpavlin@koha-dev:/srv/koha-rfid$ ./rfid2koha-borrower-attribute.pl log.print/2010-08-17T16\:36\:27.txt

Import 3M log datoteka

ovaj korak je stara procedura i ne koristi se više

kopiranje novih logova na koha-dev

*.LOG datoteke iz 3M softwarera se kopiraju u /srv/koha-rfid/log

dpavlin@koha:~$ sudo mount /mnt/koncar/
dpavlin@koha:~$ cp -v /mnt/koncar/* /srv/koha-rfid/log/
dpavlin@koha:~$ sudo umount /mnt/koncar/

preimenovanje u intervale koje pokrivaju

dpavlin@koha:/srv/koha-rfid$ make rename
find log/ -name "*.LOG" | xargs -i ./rename-log.sh {}
chmod 644 log/*.log

dpavlin@koha:/srv/koha-rfid$ ls -al log | head
total 27860
drwxr-xr-x 4 dpavlin dpavlin   4096 2010-03-01 16:33 .
drwxrwxr-x 6 dpavlin dpavlin   4096 2010-02-25 15:18 ..
-rw-r--r-- 1 dpavlin dpavlin 524488 2010-02-21 02:10 20080922-20081111.log
-rw-r--r-- 1 dpavlin dpavlin 524334 2010-02-21 02:10 20081015-20081024.log
-rw-r--r-- 1 dpavlin dpavlin 524606 2010-02-21 02:10 20081024-20081103.log
-rw-r--r-- 1 dpavlin dpavlin 524322 2010-02-21 02:10 20081027-20081027.log
-rw-r--r-- 1 dpavlin dpavlin 524510 2010-02-21 02:10 20081027-20081029.log
-rw-r--r-- 1 dpavlin dpavlin 524296 2010-02-21 02:10 20081029-20081103.log
-rw-r--r-- 1 dpavlin dpavlin 524366 2010-02-21 02:10 20081103-20081106.log

provjera novih podataka

cd log
git status
git add *.log
git commit -m 'new data'

parse log

dpavlin@koha-dev:/srv/koha-rfid$ make rfid

...

wc -l rfid.txt
12196 rfid.txt
echo "`cat rfid.txt | cut -d, -f2 | sort -u | wc -l` different tags"
11243 different tags
echo "`cat rfid.txt | cut -d, -f2- | grep ',20' | sort -u | wc -l` card tags"
4151 card tags

Kopiranje borrowers tablice s produkcije na development

dpavlin@koha-dev:/srv/koha-rfid$ ./update-borrowers.sh

Ovo će stvoriti borrowers2 tablicu na developmentu i prekopirati sve nove korisnike u borrowers tablicu, a postojećim korisnicima upisati cardnumber ako je on u međuvremenu generiran na produkciji.

update kohe

(pokreće sam i parsanje log dataoteka)

dpavlin@koha-dev:/srv/koha-rfid$ make rfid2koha

Integration of SafeQ and Koha

We are trying to integrate users in SafeQ and our users in Koha. Koha is library system which stores it's users into relational database. To allow SafeQ system access to users we decided to implement LDAP protocol on top of our data scheme in Koha.

This is described in little more details at: http://blog.rot13.org/2009/03/integrating_systems_using_netldapserver_and_rdbms.html

Mapping configuration

Users

Examining UMgr-LDAP.conf configuration we came up with following mapping from our RDBMS to LDAP schema: http://svn.rot13.org/index.cgi/virtual-ldap/view/sql/hreduperson.sql

we are creating objectGUID with primary key in our database and rest of the fields should be self-explanatory.

This produce following result for LDAP search query:

dpavlin@koha-dev:/srv/virtual-ldap$ ldapsearch -h 10.60.0.13 -p 2389 -b dc=ffzg,dc=hr -x 'pager=E00401001F77965C'
# extended LDIF
#
# LDAPv3
# base <dc=ffzg,dc=hr> with scope subtree
# filter: pager=E00401001F77965C
# requesting: ALL
#

# dpavlin@ffzg.hr, SURAD, ffzg.hr
dn: uid=dpavlin@ffzg.hr,ou=SURAD,dc=ffzg,dc=hr
ou: SURAD
uid: dpavlin@ffzg.hr
objectGUID: 606
cn:: RG9icmljYSBQYXZsaW51xaFpxIc=
homeDirectory: /home/606
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: hrEduPerson
memberOf: SURAD
sn:: UGF2bGludcWhacSH
mail: dpavlin@rot13.org
pager: E00401001F77965C
givenName: Dobrica
displayName:: UGF2bGludcWhacSH

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

This works quite well, and I can see users with their's cards in SafeQ system.

Roles

Roles are mapped into groups using following mapping: http://svn.rot13.org/index.cgi/virtual-ldap/view/sql/group.sql

Which generate LDAP groups like this:

dn:cn=SURAD,ou=SURAD,dc=ffzg,dc=hr

    members: uid=vivainfo,ou=SURAD,dc=ffzg,dc=hr
             uid=dpavlin,ou=SURAD,dc=ffzg,dc=hr
         ou: SURAD
         cn: SURAD
description: Suradnici
objectClass: group

which produce groups in Role drop down:

Some more information about defining groups in ldap can be found at: http://blog.rot13.org/2009/04/ldap_haters_guide_to_groups.html

Const centre

Groups which we have defined in Koha are really only useful for reporting, so it seems that cost centres in SafeQ are the right place to import our groups.

We are trying to use following mapping: http://svn.rot13.org/index.cgi/virtual-ldap/view/sql/organizationalunit.sql

Idea is to expose same group data as organizationalUnits in SafeQ so we can get accounting by those groups. We would also like to have different prices for each group of users and ability to report using groups from Koha.

Changing configration to:

# Mapping of LDAP containers to SafeQ cost centres (departments)
# If enabled, all organisational units containers will be displayed in SafeQ as cost centres
# If disabled (no, false), attribute mapping is used - see ldap_ou
ldap_map_ou = yes

We get const centers mapped from our organizational units:

but all const centres have same number (0)

How can we supply SafeQ with correct cost center number so users can end up in correct one?

Possible bugs in SafeQ

LDAP search

I also found out something which seems like a bug in the way SafeQ search LDAP server: when you search for 'dpavlin' as login/alias I get following queries:

## filter and [

 { equalityMatch => { assertionValue => "HrEduPerson", attributeDesc => "objectclass" }, },
 { equalityMatch => { assertionValue => "dpavlin%", attributeDesc => "uid" }, },
]

objectclass is o.k., but uid looks like uid=dpavlin% which I think it should be uid=dpavlin* to be correct LDAP syntax.

This query doesn't return anything, but next one is o.k.:

## filter and [

 { equalityMatch => { assertionValue => "HrEduPerson", attributeDesc => "objectclass" }, },
 { substrings => { substrings => [{ any => "dpavlin" }], type => "uid" }, },
]

which is uid=*dpavlin* and it finds user.

Role/Cost Centere drop-down

Selecting role of const center doesn't change filtered output of users. I don't see any difference in LDAP search query when changing selected role and/or cost centar. Is that normal?