To jest stara wersja strony!
Analiza warunków technicznych i implementacja prototypu modułu dostępu do danych Składu Osobowego AGH (SkOs) przy pomocy protokołu LDAP
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.:
projekt_konceptualny_16.pdf
projekt_logiczny_16.pdf
Raport końcowy
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.
Etapy realizacji projektu baz danych LDAP pracowników AGH
1. Utworzenie i modyfikacja bazy danych
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.
2. Konfiguracja ODBC – interfejsu pozwalającego połączyć się aplikacjom z systemem zarządzania bazą danych
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 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
[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
3. Konfiguracja serwera LDAP (wersja 2.4.19)
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
4. Konfiguracja Django w celu zarządzania bazą danych (python wersja 2.5.5, django wersja 1.1.1)
Wymagane pakiety:
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:
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.
Wygląd i opis interfejsów stron obsługujących bazy danych
1. Strona administracyjna relacyjnej bazy danych
2. Strony wykorzystane do wyszukiwania i prezentacji wyników
Inne opcje dostępu i wykorzystania bazy danych LDAP
Import danych z istniejącego systemu SKOS do bazy LDAP
Problemy jakie wystąpiły w trakcie realizacji projektu, proponowane rozwiązania i kierunki rozwoju