zastosowanie LDAP

[Jacek Konieczny]

On Sat, Sep 11, 1999 at 09:58:26PM +0200, Tomasz Kłoczko wrote:
> On Sat, 11 Sep 1999, Jacek Konieczny wrote:
> > Np. w /etc/sysconfig/network można by było wybrać, czy konfiguracja
> > interfejsów ma być ładowana z plików, czy z LDAP, czy z obu.
> 
> Istnieje tu tylko problem jajka i kury (chyba). Sldap pracujacy lokalnie
> chyba wymaga już podniesionego interfejsu lo. Tzrebaby to jakoś sprytnie
> wpleść co nie musi wyglądać juz za elegancko. Jezli informacje o
> interfejsach miałyby być pobierane z zewnętrznego sldapa to nie da sie z
> nim skomunikować zanim nie podniesie się interfejsów sieciowych.

Lo może być traktowany specjalnie (chyba już nawet jest). A zresztą
jeśli się włączy kożystanie i z plików i z LDAP, to interfejsy, do
których będą pliki ifcfg-* podniosą się przy użyciu tych plików,
pozostałe przez ldap. Więc na przykład będą pliki:
ifcfg-lo
ifcfg-eth0
A na przykład ifcfg-ppp, z konfiguracją łączy wdzwanianych i
ifcfg-eth0:? z konfiguracją aliasów będą w LDAP.
Problem byłby tylko (ale raczej niewielki z odpowiednią kolejnością
startowania interfejsów.


> > rc-scripts, by zostały prawie bez zmian, poza tym, że przy wyborze LDAP,
> > i gdy odpowiednie narzędzia istnieją w systemie (ldapsearch)
> > source_config() ładowałoby odpowiednie zmienne z LDAP.
> > 
> > A czemu wogóle coś takiego robić? A no temu, że można by wtedy trzymać 
> > konfigurację aliasów wraz z resztą konfiguracji wirtualnych serwerów
> > (konfiguracja serwera WWW, poczty) w jednym miejscu.
> 
> Rozumiem, że masz juz jakąś koncepcje szczegółów bo jak na razie pomysł
> wydaje się dobry tylko jakoś nie mogę sobie włąśnie wyobrazić kilku
> szczegółów .. ale to nie jest najważneijsze jezeli taką koncepcję juz
> masz.

Powiedzmy takie drzewko:

			dc=com                                  dc=pl
			  |                                       |
		       dc=domena                                dc=d2
			  |                                       |
		   /             \                                |
	      dc=serwer	     ou=DomenyWirtualne                   |
		 | 		/          \                      |
       ou=People-|        domain=d1.com   domain=d2.pl  <---------+
       ou=Group -|	       |              |
          ...    |   ou=People-|    ou=People-|
   ou=Interfaces-|	  ....          ....

(domain=associatedDomain)

wszystko (może oprócz ou=Interfaces) pod: dc=serwer,dc=domena,dc=com
jest znane (taką strukturę otrzymujemy używając MigrationTools)

pod domain=d1.com, ou=DomenyWirtualne,dc=domena,dc=com ( i analogicznie
dla innych domen wirtualnych) mamy podobną strukturę.

Niech wpis ten będzie wyglądał jakoś tak: 
dn: associatedDomain=d1.com, ou=DomenyWirtualne,dc=domena,dc=com
objectClass: top
objectClass: domainRelatedObject
objectClass: ipHost
objectClass: pldInterface
objectClass: pldwwwsite
associatedDomain: d1.com
cn: www.d1.com
ipHostNumber: 123.45.67.89
interfacenam: eth0:0
...

Wystarczy, że rc-scripts będą szukały interfejsów zaczynając od dc=domena,dc=com
to wezmą pod uwagę 
 i Interfaces,serwer,domena,com 
 i d1.com,DomenyWirtualne,domena,com
.

Więc, żeby dodać kolejną domenę wirtualną wystarczy dodać konar do
"DomenyWirtualne", a nie zmieniać osobno konfigurację WWW, mail, 
interfejsów itp.

Cały dowcip w LDAP polega na tym, że żadnej hierarhi nikt nie narzuca (i
my też nie powinniśmy) - więc można sobie to poustawiać według potrzeb.
Ale hierarchia jaką pokazałem daje dodatkowe zalety:
Można prawa do zmieniania konfiguracji danej domeny wirtualnej oddać
komu innemu. Np. dać klientowi możliwość dodawania adresów email.
Gdy jakiś serwer przestanie być wirtualny, wystarczy "oderwać" jeden
konar. Dane konfiguracyjne, które się nie zmienią już są w odpowiedniej
hierarhi.

Oczywiście mogłem zapomnieć o jakiś "szczegółach"....

> > Można by postawić komuś serwer oparty o PLD, a podstawową administrację
> > nim oddać komuś mniej się na tym znającemu. 
> > 
> > Plik z konfiguracją wirtualnych serwerów dla apacha, można było by robić
> > z danych z LDAP przy pomocy prościutkiego skryptu. Podobnie z innymi
> > rzeczami.
> > 
> > Pomysł może rzeczywiście trochę zwariowany, ale czemu nie?
> 
> Jasne. Mi od jakiegoś czasu łazi po głowie zarządzanie zasobami drukarek
> poprzez LDAP na potrzeby grupy jednostek i kilku szczegółów mi jeszcze
> brak :)
Jakich (na priva), może razem coś wymyślimy - dobrze żeby to było wmiarę 
spójne z moimi pomysłami, jeśli chcemy to wykożystać w PLD.

> > Jeszcze tylko przydałby się jakiś dobry program do edycji bazy LDAP. 
> > Ja oglądałem kldap i gq i widzę, że wymagają jeszcze trochę pracy. Ale
> > może jest coś fajnego konsolowego?
> 
> Ja widziałem tylko gq.
Pisałem do autora tegoż z zapytaniem, czy będzie możliwa edycja haseł 
inne triki, które uzanałem za przydatne.
Odpowiedział, że owszem, niestety część z tych funkcji będzie wymagać
LDAP v3 (openldap 1.x supportuje tylko v2).
Jest gdzieś jakiś inny open-source serwer LDAP dla linuksa?

Pozdrowienia,
       Jacek
-- 
+---------+--------------------------------------------------------+
!      ,  !            Jacek Konieczny, Gliwice, Poland            !      
! Jajcus  !   email: jajcus w zeus.polsl.gliwice.pl, jacek w kde.org   !
!         ! ICQ# 7149127                           WWW: none (yet) !
+---------+--------------------------------------powered-by-Linux--+