Kowalczyk, Curzytek

• Do zrobienia:
  • analiza struktury danych przechowywanych w SkOs,
  • wykonanie projektu bazy danych,
  • rozpoznanie możliwości pobierania danych z SkOs (uzyskanie dostępu do bazy, parsowanie HTML) i przygotowanie procedur importu,
  • wykonanie prostego interfejsu webowego dostępu do nowej bazy,
  • analiza protokołu LDAP i istniejących serwerów; określenie wymagań (serwer, itd.) i wybór rozwiązania,
  • udostępnienie danych z bazy przy pomocy protokołu LDAP.
• Linki, itd.:
  • Administrator Danych Systemu SkOs - Sekretariat Uczelnianego Centrum Informatyki AGH (pawilon C1, pok.401)
  • http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
  • przykładowy link: http://regent2.uci.agh.edu.pl/skos/search/osoba_opis.php?osoba_id=3401

projekt_konceptualny_16.pdf

projekt_logiczny_16.pdf

Baza została stworzona w DBMS (Database Management System) PostgreSQL 8.4.2 na podstawie zaprojektowanego diagramu ERD. System operacyjny, na którym był realizowany projekt to Linux Debian, wersja testowa – squeeze. Pakiety były instalowane przy pomocą dostępnych repozytoriów systemu operacyjnego. Nazwa katalogu domowego: wojcieh.

Nazwa bazy danych przechowującej tabele LDAP: ldap.

Podczas testów okazało się, że do poprawnego odczytywania danych z bazy SQL do bazy hierarchicznej niezbędne jest ustawienie zmiennej client_encoding na latin1.

ldap => SET client_encoding TO latin1; 
SET

Po ustawieniu client_encoding na wartość utf-8 większość danych była gubiona. Nie wiemy jaka jest tego dokładna przyczyna i czy jest to tylko fenomen związany z Debianem, czy też na innych systemach operacyjnych dzieje się podobnie. Dokumentacja OpenLDAP mówi z kolei, że do przechowywania wszystkich tekstowych wartości atrybutów oraz nazw wyróżnionych używany jest zbiór znaków UTF-8.
Problem ten pociąga za sobą kilka istotnych konsekwencji. W celu administrowania bazą danych została wykorzystana strona administracyjna, jaką dostarcza framework DJANGO. Django wymaga kodowania znaków w formacie UTF-8. Dochodzi więc do konfliktu pomiędzy administrowaniem relacyjnej bazy danych, a poprawnym działaniem bazy hierarchicznej. Problem ten został rozwiązany w sposób prowizoryczny, poprzez utworzenie jeszcze jednej bazy danych przechowującej całą strukturę relacyjnej bazy danych. W tym celu został stworzony odpowiedni skrypt basha. Rozwiązanie takie nie jest najlepsze, ponieważ aby uwzględnić zmiany w bazie LDAP trzeba skopiować dane z jednej do drugiej bazy.

Mamy więc dwie bazy danych:

• aghldap z tabelami diagramu ERD, protokołu LDAP oraz tabelami utworzonymi przez framework Django, client_encoding = utf8
• ldap z tabelami i widokami protokołu LDAP, client_encoding = latin1, utworzona na podstawie bazy aghldap przy pomocy skryptu basha

Bazy są dostępne bez konieczności podawania hasła. Należy zmienić jedynie użytkownika i nadać mu odpowiednie prawa do modyfikacji struktury baz.

Wymagane pakiety:

• unixodbc, libiodbc2 – niezbędne biblioteki i narzędzia
• odbc-postgresql – sterownik ODBC dla DBMS PostgreSQL

Po zainstalowaniu pakietów w shellu sprawdzamy lokalizację plików konfiguracyjnych:

$ odbcinst -j
unixODBC 2.2.11
DRIVERS............: / etc/odbcinst.ini
SYSTEM DATA SOURCES: / etc/odbc.ini
USER DATA SOURCES..: /home/wojcieh/.odbc.ini

Wprowadzamy zmiany w plikach konfiguracyjnych:

• odbc.ini
  

;
;  odbc.ini
;
[ODBC Data Sources]
PgSQL=PostgreSQL

[PgSQL]
Driver          = /usr/lib/odbc/psqlodbc.so             # pełna ścieżka do drivera
Description     = Connection to LDAP/POSTGRESQL
Servername      = localhost 			
Port            = 5432 					# domyślnie 5432
Protocol        = 6.4 							
FetchBufferSize = 99
Username        = wojcieh				# nazwa użytkownika bazy danych
Password        = wojcieh9
Database        = ldap 					# nazwa bazy danych z tabelami LDAPa
ReadOnly        = no
Debug           = 1
CommLog         = 1

[ODBC]
InstallDir      = /usr/lib/odbc 			# ścieżka do katalogu ze sterownikami

• odbcinst.ini
  

[ODBC]
Trace           = 1
Debug           = 1
Pooling         = No

[PostgreSQL]
Description     = ODBC for PostgreSQL
Driver          = /usr/lib/odbc/psqlodbc.so 		# pełne ścieżki do driverów
Setup           = /usr/lib/odbc/libodbcpsqlS.so
UsageCount      = 2

Sprawdzamy, czy konfiguracja przebiegła pomyślnie (ostatni argument to nazwa użytkownika):

$ isql -v PgSQL wojcieh
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL>

Sprawdzić poprawność konfiguracji ODBC możemy również uruchamiając OpenOffice.org Base.
Wybieramy opcję Połącz z istniejącą bazą danych → ODBC, Nazwa źródła danych ODBC obecnego w systemie → PgSQL. Następnie należy podać nazwę użytkownika bazy i jego hasło. Po wykonaniu wszystkich tych czynności możemy pracować z bazą danych PostgreSQL w Base, należącym do pakietu OpenOffice.
Pełny opis konfiguracji na stronie www.easysoft.com

Wymagane pakiety:

• slapd – serwer OpenLDAP
• ldap-utils – narzędzia do obsługi bazy, komendy LDAP
• libldap2 – biblioteki OpenLDAP
• python-ldap – moduł pythona będący interfejsem LDAPa

Pliki serwera OpenLDAP znajdują się w katalogu / etc/ldap.
Wprowadzamy zmiany w pliku slapd.conf (ścieżki do poszczególnych plików mogą być inne, w zależności od systemu ):

# Schema and objectClass definitions
include         / etc/ldap/schema/core.schema
include         / etc/ldap/schema/cosine.schema
include         / etc/ldap/schema/nis.schema
include         / etc/ldap/schema/inetorgperson.schema
include         / etc/ldap/schema/eduperson.schema
include         / etc/ldap/schema/pledu.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile        /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel        296
#none

# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap                     # ścieżka do modułów OpenLDAPa
moduleload      back_sql 	                  # załadowanie modułu pozwalającego na integrację bazy LDAP z bazą SQL

# The maximum number of entries that is returned for a search operation
sizelimit       1000 				  # limit wyników wyszukiwania dla polecenia ldapsearch

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads    1

# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         sql					

# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        sql 				  # typ bazy – sql

# The base of your directory in database #1
suffix          "dc=agh,dc=edu,c=PL"
#URL            ldap://192.168.7.12/
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn          "cn=root,dc=agh,dc=edu,c=PL" 	  # dn administratora systemu
rootpw          secret		                  # secret oznacza brak hasła, hasło można wygenerować przy pomocy polecenia ldappasswd i wkleić w to miejsce zakodowany ciąg znaków
dbname          PgSQL 			          # nazwa określająca DBMS użyta w konfiguracji ODBC
dbuser          wojcieh 			
dbpasswd        aghldap
insentry_query  "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)"
upper_func      "upper"
strcast_func    "text"
concat_pattern  "?||?"
has_ldapinfo_dn_ru      no

lastmod off

access to *
        by * read

Plik slapd.conf jest najważniejszym plikiem i jego poprawna konfiguracja umożliwi poprawne działanie serwera. Należy tutaj omówić najważniejsze fragmenty tego pliku:

include         / etc/ldap/schema/core.schema

Linia powoduje dodanie schematu, tak iż możemy później korzystać z klas dostępnych w tym schemacie. Cztery pierwsze schematy są schematami podstawowymi, dostępnymi w ramach instalacji pakietu OpenLDAP. Schematy eduPerson.schema oraz pledu.schema są schematami opracowanymi przez niezależne instytucje i należy je dodać do katalogu schematów. Zostały one załączone w archiwum.

Parametr pidfile specyfikuje ścieżkę absolutną do pliku zawierającego ID procesu aktualnie działającego procesu serwera slapd.

Parametr argsfile specyfikuje ścieżkę absolutną do pliku zawierającego parametry podawane z linii poleceń dla aktualnie działającego serwer slapd.

Parametr loglevel 296 (=256+32+8) specyfikuje jakiego typu informacje mają zostać zapisane do logów systemowych. 8 oznacza zarządzanie połączeniem (connection management), 32 oznacza sposób przetwarzania wyników polecenia SEARCH, 256 oznacza statystki połączeń, operacji i wyników przeprowadzonych operacji.

Parametr backend sql jest niezwykle istotny. Pozwala on na dostęp do bazy hierarchicznej w sposób pośredni – za pośrednictwem PostgreSQL.

Parametr suffix pozwala na określenie dn (distinguish name / analogia do ścieżki dostępu) do bazy danych. Użycie suffixa w tym miejscu wymusza użycie tego samego suffixa w tabelach LDAP.

Bardzo ważna jest linia:

access to * by * read

Za pomocą polecenia access to określa się Access Control List (ACL), a więc prawa i poziom dostępu do bazy dla poszczególnych użytkowników. Powyższe polecenie pozwala na odczyt danych przez wszystkich.

Ponieważ dane systemu mają być dostępne dla wszystkich autentykacja jest zbędna.

Podczas konfiguracji pliku oraz pracy z danymi umieszczonymi w tabelach OpenLDAPa należy uważać, by nie popełnić najdrobniejszych błędów, ponieważ nie będziemy wtedy mogli uruchomić serwera slapd. Ze względu na brak debuggera należy samemu znaleźć i poprawić popełnione błędy, co może niestety pochłonąć mnóstwo czasu i nerwów. ( z doświadczenia )

Aby sprawdzić, czy konfiguracja przebiegła pomyślnie uruchamiamy serwer:

$ / etc/init.d/slapd start
Starting OpenLDAP: slapd

Brak błędów oznacza poprawną konfigurację.

Teraz możemy, za pomocą polecenia ldapsearch wyszukać dane z linii poleceń, na przykład:

$ ldapsearch -x -b "dc=agh,dc=edu,c=PL" "(&{givenName=*toni}(sn=*za)(title=*dr*))"
# extended LDIF
#
# LDAPv3
# base <dc=agh,dc=edu,c=PL> with scope subtree
# filter: (&{givenName=*toni}(sn=*za)(title=*dr*))
# requesting: ALL
#
# Antoni Lig\C4\99za + 2076, people, agh, edu, PL
dn:: Y249QW50b25pIExpZ8SZemErdWlkPTIwNzYsb3U9cGVvcGxlLGRjPWFnaCxkYz1lZHUsYz1QT
 A==
objectClass: inetOrgPerson
objectClass: eduPerson
objectClass: eduPerson
objectClass: pleduPerson
objectClass: pleduPerson
l: C-3, II p., pok. 204
cn:: QW50b25pIExpZ8SZemE=
ou:: UmFkYSBXeWR6aWHFgnUgRWxla3Ryb3RlY2huaWtpLCBBdXRvbWF0eWtpLCBJbmZvcm1hdHlra
 SBpIEVsZWt0cm9uaWtp
sn:: TGlnxJl6YQ==
uid: 2076
mail: ali@ia.agh.edu.pl
mail: ligeza@agh.edu.pl
title:: cHJvZi4gZHIgaGFiLiBpbsW8Lg==
givenName: Antoni
homePhone: (48) 12-267-44-67
labeledURI: http://galaxy.uci.agh.edu.pl/~ligeza
plposition: profesor nadzwyczajny
roomNumber: II p., pok. 204
description:: R8WCw7N3bmUgbWllanNjZSBwcmFjeQ==
displayName:: QW50b25pIExpZ8SZemE=
employeeNumber: 2076
telephoneNumber: (48) 12-617-28-49
departmentNumber:: S2F0ZWRyYSBBdXRvbWF0eWtpOyBXeWR6aWHFgiBFbGVrdHJvdGVjaG5pa2k
 sIEF1dG9tYXR5a2ksIEluZm9ybWF0eWtpIGkgRWxla3Ryb25pa2k=
homePostalAddress:: dWwuIFphY2hvZG5pYSA1JDMwLTM1MCBLcmFrw7N3
eduPersonAffiliation: profesorowie nadzwyczajni

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Jak widać w przypadku przeszukiwania bazy danych z linii poleceń wyświetlane dane są źle kodowane. Znacznie prostszym w obsłudze i zwracającym poprawnie kodowane znaki jest edytor graficzny GQ.

Opis konfiguracji na stronie darold.net

Wymagane pakiety:

• python-django,
• python-psycopg2 – moduł pythona dla PostgreSQLa

Sprawdzamy instalację Django:

$ python
>>> import django
>>> django.VERSION
(1, 1, 1, 'final', 0)

Po instalacji należy rozpakować archiwum zawierające pliki Django. Następnie zmieniamy niektóre linie plików:

• settings.py

DEBUG = True 		# ważne, by przed dopuszczeniem strony do użytku publicznego zmienić na False, by uniemożliwić niepowołanym obserwację błędów i informacji o systemie, które dostarcza debugger
TEMPLATE_DEBUG = DEBUG

ADMINS = (
    # ('Your Name', 'your_email@domain.com'),
)
MANAGERS = ADMINS

DATABASE_ENGINE   = 'postgresql_psycopg2'   # nazwa modułu do obsługi bazy danych
DATABASE_NAME     = 'aghldap'               # nazwa bazy danych z formatowaniem utf-8
DATABASE_USER     = 'wojcieh'               # nazwa użytkownika bazy danych
DATABASE_PASSWORD = ''         
DATABASE_HOST     = ''                      # Set to empty string for localhost.
DATABASE_PORT     = ''                      # Set to empty string for default.

# Absolute path to the directory that holds media.
# Example: "/home/media/media.lawrence.com/"
MEDIA_ROOT = '/home/wojcieh/PostgreSQL/Projekt/LDAP/django_ldap/static'
# ścieżka absolutna do plików css, js, grafiki
# jeśli nazwa katalogu nie będzie zmieniana część ścieżki /django_ldap/static pozostanie identyczna

# URL prefix for admin media -- CSS, JavaScript and images. Make sure to use a
# trailing slash.
# Examples: "http://foo.com/media/", "/media/".
ADMIN_MEDIA_PREFIX = '/media/static/'
# ścieżka względna do plików css, js, dla strony administracyjnej

TEMPLATE_DIRS = ( '/home/wojcieh/PostgreSQL/Projekt/LDAP/django_ldap/templates',
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.
)
# ścieżka absolutna do wzorców stron

• urls.py

from django.conf.urls.defaults import *
from django.conf import settings
from django_ldap.views import search_form,simple_search,advanced_search,advanced_search_form,index,contact

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',(r'^search-form/$',search_form),(r'^simple-search/$',simple_search),(r'^advanced-search/$',advanced_search),(r'^advanced-search-form/$',advanced_search_form),(r'^main/$',index),(r'^contact/$',contact),(r'^media/(?P<path>.*)$', 'django.views.static.serve',{'document_root': settings.MEDIA_ROOT}),
    # Example:
    # (r'^django_ldap/', include('django_ldap.foo.urls')),

    # Uncomment the admin/doc line below and add 'django.contrib.admindocs'
    # to INSTALLED_APPS to enable admin documentation:
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),

    # Uncomment the next line to enable the admin:
    (r'^admin/', include(admin.site.urls)),
)

W tym pliku określa się adresy stron, dla których wywoływane są określone w pliku views.py operacje.

By zrozumieć zasady tworzenia stron przy pomocy Django należy posiadać podstawowe informacje na temat tego frameworka dostępne na stronie www.djangobook.com
W plikach umieszczono komentarze w miejscach szczególnie istotnych, gdzie wprowadziliśmy pewne metody i funkcje ułatwiające pracę z danymi.

Warto w tym miejscu zauważyć, że framework Django został wykorzystany w dwojaki sposób tj. strona administracyjna posłużyła jako system zarządzania i administrowania bazą danych PostgreSQLa. Z kolei widoki i wzorce stron współpracują z modułem python-ldap, co pozwala na przeszukiwanie bazy LDAPa i wyświetlanie rezultatów na stronach.

Strony obsługiwane są na porcie 8000, który jest defaultowym portem Django. W przypadku zmiany portu należy zmienić również numery portów w plikach katalogu template.

Przed uruchomieniem serwera pamiętać o synchronizacji Django z bazą danych !!!

$ python manage.py syncdb

Serwer uruchamiany jest za pomocą polecenia:

$ python manage.py runserver (port)

Ze względu na fakt, iż Django dostarcza bardzo dobrą, prostą w użyciu i intuicyjną stronę administracji danymi została ona przez nas wykorzystana w celu zarządzania bazą PostgreSQLa.

Wygląd strony głównej:

Pliki odpowiedzialne za wygląd poszczególnych stron reprezentujących tabele i relacje między nimi znajdują się w katalogu postgresql_data. Za pomocą polecenia list_display dokonujemy wyboru listy atrybutów wyświetlanych na stronie, polecenie search_fields pozwala na wybór pól, które mogą zostać przeszukane według zadanego terminu, polecenie ordering wprowadza alfabetyczny porządek. Istnieje możliwość dodania, usunięcia, modyfikacji danych, ustalenia praw dostępu i wiele innych udogodnień pozwalających na proste i intuicyjne zarządzanie bazą danych.

Wygląd strony głównej:

W projekcie wykorzystane są pliki .css i .js odpowiadające za wygląd i animacje niektórych elementów. Istnieją dwie możliwości przeszukiwania stron: wyszukiwanie podstawowe i zaawansowane.

Wyszukiwanie podstawowe polega na znajdowaniu danych wg takich atrybutów jak imię lub nazwisko, zawierających dany ciąg znaków.

Wyszukiwanie zaawansowane wprowadza kolejne pola, za pomocą których zadajemy kryteria wyszukiwania oraz mamy możliwość wyboru dodatkowych opcji wg których dany atrybut zawiera, równa się, bądź zaczyna się od zadanego ciągu znaków.

Bardzo dużym atutem bazy hierarchicznej LDAP jest możliwość uzyskania dostępu do danych na wiele sposobów.
Bardzo popularne jest użycie książki adresowej klienta poczty elektronicznej w celu wyświetlenia podstawowych informacji dostępnych w danej bazie serwera LDAP. Lista wyświetlanych atrybutów jest jednak bardzo ograniczona, dlatego też nie ujrzymy wszystkich dostępnych informacji, lecz jedynie podstawowe, które w 90 % przypadków stanowią dla nas wystarczające źródło informacji.
Przejrzysty opis konfiguracji dla klienta Mozilla Thunderbird i pochodnych jest dostępny na stronie hep.ucsb.edu

W przypadku naszej bazy danych pola zakładki Ogólne wyglądałyby następująco:
Nazwa: dowolna_nazwa1
Nazwa hosta: localhost (tymczasowo)
Bazowy DN: dc=people,dc=agh,dc=edu,c=PL
Numer portu: 389

Przykładowy wynik wyszukiwania:

Możemy również przeszukiwać bazę danych bezpośrednio za pomocą jednego z edytorów graficznych jak GQ, Java LDAP Browser, czy też Softerra LDAP browser. Mamy wtedy możliwość odczytu wszystkich atrybutów, także tych, które są dostępne w ramach danej klasy, ale nie zostały im przypisane żadne wartości.

Przykład użycia edytora GQ:

Ze względu na brak bezpośredniego dostępu do bazy danych systemu SKOS niezbędne okazało się sparsowanie danych umieszczonych bezpośrednio na stronach tego systemu. W tym celu zostały wykorzystane następujące moduły pythona:

• urllib – pozwalający na skopiowanie zawartości źródła strony internetowej o zadanym adresie do obiektu lub do pliku
• BeautifulSoup – rozpoznający polecenia html i wycinający tekst znajdujący się między nimi

Ze względu na brak wcześniejszych doświadczeń z parsowaniem stron internetowych dane były pobierane w kolejnych krokach i ładowane do bazy. Dlatego też nie ma jeszcze opracowanych jednolitych procedur, jednak jeśli zajdzie taka potrzeba jesteśmy gotowi do stworzenia skryptu, który zintegruje kolejne etapy importu danych.

1. W punkcie pierwszym został już przedstawiony problem kodowania danych. Nie wiemy, czy jest to pewnego rodzaju anomalia związana bezpośrednio z dystrybucją linuxa, na której implementowany był serwer, czy problem ten jest powszechny. Na sieci brak jest informacji na ten temat, ze względu na fakt, iż użycie backendu umożliwiającego dostęp do bazy LDAP za pośrednictwem PostgreSQLa jest rzeczą niezwykle rzadką. Jakkolwiek stworzenie dwóch baz danych wydaje się kłopotliwe uważamy, że mamy całkiem przyzwoite rozwiązanie tego problemu. Nasz pomysł wynika z faktu, iż baza danych pracowników nie notuje dynamicznych, częstych zmian. Również wprowadzone zmiany nie muszą mieć natychmiastowego skutku. Należałoby stworzyć skrypt, którego zadaniem jest aktualizacji tabeli ldap_persons w bazie aghldap, przechowującej przetworzone na podstawie widoku dane, tak by nie dochodziło do duplikowania informacji. Aktualizacja polegałaby na całkowitym wyczyszczeniu tabeli i ponownym jej uzupełnieniu. Operacja ta zajmuje około 20 – 30 sekund. Następnie skrypt usuwałby zawartość tabeli o tej samej nazwie w bazie ldap i kopiował dane z jednej tabeli do drugiej. Operacja aktualizacji bazy danych, na której oparty jest serwer LDAP trwałaby więc bardzo krótko. Skrypt byłby wykonywany nad ranem, każdego dnia za pomocą crona.
2. Podczas prac nie udało się wyeliminować powtórzeń stanowiących o przynależności obiektu do klas eduPerson oraz pleduPerson. Niektórzy pracownicy, po usunięciu powtarzających się informacji mają przeznaczonych nawet kilka wierszy w tabeli ldap_persons. Z niewiadomych nam przyczyn powoduje to nadmierne powtarzanie informacji.
   
3. Numery ID pracowników w tabeli ldap_person, a co za tym idzie i w widoku ldap_entries zaczynają się od wartości 1000. Powodem takiego rozwiązania jest fakt, iż ID < 1000 pozostawiliśmy dla obiektów klasy organizationlUnit – tj. jednostki AGH, które można by w przyszłości również scharakteryzować za pomocą atrybutów klas protokołu LDAP i udostępnić dane z nimi związane.
4. Dobrym posunięciem byłoby stworzenie nowego schematu z klasami specjalnie dla jednostki jaką jest AGH. W projekcie, przecierając nowe szlaki korzystaliśmy jedynie z powszechnie dostępnych schematów.
5. Wyniki wyszukiwania pojawiają się na stronie dopiero po przeszukaniu całej bazy. W przypadku zapytań, których wynikiem jest duży zbiór gromadzenie danych trwa stosunkowo długo. Dobrym pomysłem byłoby wyświetlanie wyników na bieżąco, wykonując przeszukanie fragmentów bazy za każdym razem. Rozwiązałoby to również problem przekroczenia maksymalnego limitu znalezionych rekordów.
6. Należałoby również sprawdzić poprawność sparsowanych danych, czy gdzieś nie doszło do poważnych błędów i przekłamań.
7. Najpoważniejszy problem pojawił się w przypadku pracowników posiadających dwa miejsca pracy, tzw. główne i dodatkowe miejsce pracy. W systemie SKOS mamy 30 takich pracowników. Powoduje to przypisanie atrybutom związanym z miejscem pracy, a więc description, l, departmentNumber, roomNumber, eduPersonAffiliation, plPosition dwóch wartości.
   Przykład pokazuje tabela:
   
   Podczas testów okazało się, że dodana kolejno wartość atrybutu nie jest wstawiana na koniec listy, ale według porządku alfabetycznego. Sytuacja ta powoduje przemieszanie się ze sobą miejsc pracy, tak że nie można ich odróżnić. Nie udało nam się znaleźć nigdzie, czy można zmienić sposób, w jaki dodawane wartości atrybutów są porządkowane. Jedynym rozwiązaniem byłoby otagowanie wartości związanych z dodatkowym miejscem pracy. Aczkolwiek znacznie zmniejszyłoby to czytelność w przypadku przeglądania bazy za pomocą edytora graficznego, czy też książki adresowej.

1. www.python.org
2. www.easysoft.com
3. darold.net
4. www.djangobook.com
5. www.oav.net
6. projektldap.uci.umk.pl
7. middleware.internet2.edu
8. Adrian Holovaty, Jacob Kaplan-Moss „The definitive guide to django web development done right”, 2nd edition, July 2009
9. Gerald Carter „LDAP system administration”, O'Reilly, March 2003