[LINUX] LDAP progs compatible met elkaar ?

[BacardiBreezer]

Aangezien ik een beetje controlpanel minded ben en het leuk vind om te kijken wat er allemaal kan ben ik bezig met LDAP

Ik heb ISPman op een Fedora Core 2 Machine erg goed draaiend en zou graag de users wat willen laten doen met de info die ze hebben.

Dus je maakt een user aan.... deze heeft wat info en gegevens, waaronder mailboxen enzo, en ik wil dus iets maken of eigenlijk kijken of andere interfaces met de LDAP-tree van ISPman om kunnen gaan.

Nu lijkt dit een beetje op een helpdesktopic maar dat is het niet ISPman ben ik even een dag mee bezig geweest om dat op de goede manier aan het draaien te krijgen zonder rare fratsen en dat lukte.... nu zijn hier vast wel mensen die weten of je dus met een ander prog de LDAP-tree van ISPman in kan lezen en kan editten.

Ik ben nog druk bezig om LDAP verder door te spitten maar wellicht dat iemand wat meer info heeft over LDAP en dat op een goede manier even neer kan zetten (beknopt dus)

[Verwijderd]

Uhm, zover ik weet kan elk programma dat LDAP ondersteunt, overweg met elkaar.. of zit ik nu ergens fout?

/me moet zich maar eens gaan inlezen over LDAP

Wellicht ook een idee voor de TS?

[BacardiBreezer]

Verwijderd schreef op 06 september 2004 @ 18:48:

/me moet zich maar eens gaan inlezen over LDAP

Wellicht ook een idee voor de TS?

Ben er wel mee aan de gang geweest maar ik vraag me af hoe het synchroon zou moeten lopen...... iedere applicatie zou toch data op een andere manier moeten wegschrijven ? Daarom de vraag......

Lezen doe ik nog steeds

[JoetjeF]

BacardiBreezer schreef op 06 september 2004 @ 18:02:nu zijn hier vast wel mensen die weten of je dus met een ander prog de LDAP-tree van ISPman in kan lezen en kan editten.

Ik heb wel eens iemand gezien die met een LDAP Browser/Editor een tree uitlas. Ik heb het zelf nog niet geprobeerd maar ga dat deze week wel doen. Hier kan je het downloaden: http://www-unix.mcs.anl.gov/~gawor/ldap/download.html

[BacardiBreezer]

Ik heb ook aan zoiets zitten denken idd. Browsen moet zeker mogelijk zijn...... maar zou het ook mogelijk zijn om met 2 verschillende editors zaken aan te gaan passen ?

[Verwijderd]

Ik zou ook zeker phpLDAPadmin even checken, daar kun je echt alles mee doen. URI: http://phpldapadmin.sourceforge.net/

[BacardiBreezer]

Verwijderd schreef op 06 september 2004 @ 21:05:
Ik zou ook zeker phpLDAPadmin even checken, daar kun je echt alles mee doen. URI: http://phpldapadmin.sourceforge.net/

Ook al gesjecked..... was niet de bedoeling. Ik wil eens kijken of ik een user wat zaken aan kan laten passen als hij aangemaakt is in de admintool...... ik moet zelf wat gaan proggen denk ik maar vraag me af of ik de zaken van ISPman aan moet houden.....

[viper]

Ik heb alleen een beetje ervaring met openLDAP. En je kan dus aangeven wat de permissie is per tree in de config file. Het is dus puur afhankelijk van je configuratie toestaat per gebruiker/tree/whatever..

[BacardiBreezer]

viper schreef op 07 september 2004 @ 00:29:
Ik heb alleen een beetje ervaring met openLDAP. En je kan dus aangeven wat de permissie is per tree in de config file. Het is dus puur afhankelijk van je configuratie toestaat per gebruiker/tree/whatever..

Ik geloof dat ik dit nog maar eens na moet lezen dan

[Skinkie]

Compatible? Alleen als je server alle versies van de LDAP standaard ondersteund. Overigens vind ik het best knap dat je ISPman zo snel aan de praat hebt gekregen

[BacardiBreezer]

Skinkie schreef op 07 september 2004 @ 15:47:
Compatible? Alleen als je server alle versies van de LDAP standaard ondersteund. Overigens vind ik het best knap dat je ISPman zo snel aan de praat hebt gekregen

Ik moet zeggen........ Peanuts eigenlijk Nu de aanpassingen nog Zoals je wel zal weten moet je qua mail enz nog wat zaken aanpassen wil je er iets meer mee kunnen...... verder wil ik gaan bekijken wat er nog meer mogelijk is.

Alles werk.... kan alleen geen reseller toevoegen merkte ik en de homedir wordt niet aangemaakt........ voor de rest draait het prima

[Verwijderd]

Het is zeker mogelijk. Zie het als een 'update' statement in een database. Misschien er voor ISP man wel special tools zijn die de integriteit van je LDAP database in de gaten houden

[Skinkie]

BacardiBreezer schreef op 07 september 2004 @ 15:58:
Ik moet zeggen........ Peanuts eigenlijk Nu de aanpassingen nog Zoals je wel zal weten moet je qua mail enz nog wat zaken aanpassen wil je er iets meer mee kunnen...... verder wil ik gaan bekijken wat er nog meer mogelijk is.

Alles werk.... kan alleen geen reseller toevoegen merkte ik en de homedir wordt niet aangemaakt........ voor de rest draait het prima

Ik begon al te denken... dat pakket werkte dus echt niet direct uit de doos En er zaten nog wat uiterst vervelende bugs in (oa. bij Commit Session) waardoor het hele systeem ghost procesjes ging maken.

[BacardiBreezer]

Skinkie schreef op 07 september 2004 @ 16:02:
[...]

Ik begon al te denken... dat pakket werkte dus echt niet direct uit de doos En er zaten nog wat uiterst vervelende bugs in (oa. bij Commit Session) waardoor het hele systeem ghost procesjes ging maken.

Wat dat betreft is er niets zo 1,2,3 uit de doos helaas Maar LDAP lijkt me DE oplossing, of zit ik er naast ?

Iig...... ISPman is een goede oplossing om vanuit te gaan

[Skinkie]

BacardiBreezer schreef op 07 september 2004 @ 16:33:
Wat dat betreft is er niets zo 1,2,3 uit de doos helaas Maar LDAP lijkt me DE oplossing, of zit ik er naast ?

Kijk bij Microsoft werkt het LDAP verhaal ook, Active Directory, probleem is wel dat (Open)LDAP zelf om te querien GRUWELIJK traag is. En dat is precies de reden waarom ISPman slecht is. ISPman pretendeert je problemen op te lossen, echter, toen ik het de laatste keer bekeek, was het niets anders dan een systeem wat statische configuraties maakte vanuit LDAP.
Maar waarom laat je een applicatie dat zelf niet uit LDAP halen? Omdat dat gruwelijk traag is. Waarom gebruikte je dan LDAP... om je configuraties centraal te houden... misschien is het dan beter om je configuraties in SQL op te slaan, er een LDAP laag overheen te leggen en je applicaties SQL laten vreten.

Uiteindelijk kom je op het punt dat dat ook niet de oplossing is omdat SQL ook gruwelijk traag is voor 1 request, en dan ga je denken aan BerkeleyDB voor je applicaties die door een messaging systeem vanuit SQL wordt gevoerd.

Van ISPman zijn we naar PostfixAdmin gegaan, hebben we dat uitgebreid met Domain management en virtual hosts. Om met een aangepaste mod_vhost_pgsql voor Apache2 ook die data live uit de database te halen. En PowerDNS om domein data te doen.

Overigens houd ik mijzelf ook nog vast aan het idee van LDAP, om later wat aan de performance te gaan doen. Het idee van een tree is zo mooi

[Verwijderd]

Is zijn opties om LDAP wat te versnellen d.m.v caching. Veel gevraagde gegevens komen dan niet altijd meer uit je LDAP

[Tomaat]

OpenLDAP maakt toch gebruik van BerkleyDB om zijn gegevens weg te schrijven naar de schijf?

En zijn LDAP en SQL echt zo traag? Of bedoel je _trager_ dan bijvoorbeeld het uitlezen van een flat file configuratie..file?

Ik ben zelf ook bezig 2 servers gebruik te laten maken van een LDAP tree om users tussen beide servers synchroon te houden. Wil nog niet helemaal lukken..maar daar hebben 't nu niet over

[Skinkie]

Tomaat schreef op 07 september 2004 @ 17:31:
OpenLDAP maakt toch gebruik van BerkleyDB om zijn gegevens weg te schrijven naar de schijf?

De 'defacto'-backend is BerkeleyDB, maar LDAP zelf is te traag. LDAP kan ook draaien op SQL echter dan heeft de betreffende DBD wel stored procedures nodig. (PostgreSQL voldoet, ik denk dat de nieuwe MySQL dat ook wel doet.)
Voordelen: grote LDAP queries zijn sneller...
Nadelen: kleine LDAP queries zijn gruwelijk langszaam

En zijn LDAP en SQL echt zo traag? Of bedoel je _trager_ dan bijvoorbeeld het uitlezen van een flat file configuratie..file?

Trager als een flat file (statisch), en trager als een Dynamische Backend die direct dynamische data uit BDB haald. Eigenlijk heeft het voornamelijk te maken met de sockets die er niet tussen zitten. Uit m'n hoofd: Bind 100%, Bind+LDAP 0,004%, Bind+SQL 7%, Bind+BDB (ideale geval) 75%.

Ik ben zelf ook bezig 2 servers gebruik te laten maken van een LDAP tree om users tussen beide servers synchroon te houden. Wil nog niet helemaal lukken..maar daar hebben 't nu niet over

Met NIS? Misschien kun je beter kijken als het voor Linux is naar *iets* met een PAM implementatie als het maar voor twee servers is.

Verwijderd schreef op 07 september 2004 @ 17:19:
Is zijn opties om LDAP wat te versnellen d.m.v caching. Veel gevraagde gegevens komen dan niet altijd meer uit je LDAP

Vergeet Caching als je iets totaal dynamisch doet doe het dan ook dynamisch anders heeft het totaal geen zin en moet je niets met LDAP doen.

[ Voor 14% gewijzigd door Skinkie op 07-09-2004 17:45 ]

[JoetjeF]

Skinkie schreef op 07 september 2004 @ 17:03:
[...]

Kijk bij Microsoft werkt het LDAP verhaal ook, Active Directory, probleem is wel dat (Open)LDAP zelf om te querien GRUWELIJK traag is.

Maar waarom laat je een applicatie dat zelf niet uit LDAP halen? Omdat dat gruwelijk traag is.

Overigens houd ik mijzelf ook nog vast aan het idee van LDAP, om later wat aan de performance te gaan doen. Het idee van een tree is zo mooi

Wij gebruiken ook een LDAP database, maar nog nooit last van performance problemen gehad. Ik weet ook niet hoe je aan die ervaringen komt. We gebruiken zelf eDirectory van Novell op een Pentium Xeon 2.8. Kan makkelijk een paar duizend requests per seconde aan in een tree van 750.000 objecten. Sterker nog, een test heeft uitgewezen dat 2 miljard objecten geen probleem is, maar dan heb je wel wat steviger hardware nodig

Nu staat OpenLDAP niet zo bekend om de features en snelheid (zie Gartner Magic Quadrant en METAspectrum reports), maar voor een normale omgeveing moet dit ook voldoende zijn.

Maar om terug te komen op de TS, LDAP is toch wel, min of meer, gestandaardiseerd. Er is een certificering process van The Open Group waar je meer informatie kan vinden. Er zouden dus zat tools moeten zijn om een LDAP database te managen.

[Skinkie]

JoetjeF schreef op 07 september 2004 @ 17:42:
Nu staat OpenLDAP niet zo bekend om de features en snelheid (zie Gartner Magic Quadrant en METAspectrum reports), maar voor een normale omgeveing moet dit ook voldoende zijn.

ik denk dat 99% van de Linux LDAP gebruikers OpenLDAP draait... en daar gaat het ook fout. ik ben het met je eens dat Novell beter spul heeft

[Verwijderd]

Maar waarom laat je een applicatie dat zelf niet uit LDAP halen? Omdat dat gruwelijk traag is. Waarom gebruikte je dan LDAP... om je configuraties centraal te houden... misschien is het dan beter om je configuraties in SQL op te slaan, er een LDAP laag overheen te leggen en je applicaties SQL laten vreten.

Ik gebruik OpenLDAP in een productie omgeving op me werk. Wij hebben totaal geen last van performance problemen. Bovendien kan je zoals je zelf al aangeeft heel makkelijk een SQL backend zoals postgresql aan openldap koppelen.

[BacardiBreezer]

OpenLDAP is gewoon lekker snel. Ik denk eerder dat de mensen die er NIET mee om kunnen gaan daar anders over denken

De reden van een SQL-backend aan LDAP hangen zou alleen zijn om in een dynamische omgeving variabelen weer te geven of ze juist in LDAP te plaatsen ?

Ik zie het nut van iets dubbels namelijk niet zo 1,2,3 in.

Iig..... ik weet wel dat LDAP rules..... Open ook zeker in een domein

[Verwijderd]

Skinkie schreef op 07 september 2004 @ 17:46:
[...]

ik denk dat 99% van de Linux LDAP gebruikers OpenLDAP draait... en daar gaat het ook fout. ik ben het met je eens dat Novell beter spul heeft

Misschien de volgende keer toch maar eens goed indexen en configuraties zetten. Ik draai meerdere OpenLDAP servers in productie en die zijn absoluut niet traag kan ik je vermelden.

[Skinkie]

Verwijderd schreef op 07 september 2004 @ 18:49:
Misschien de volgende keer toch maar eens goed indexen en configuraties zetten. Ik draai meerdere OpenLDAP servers in productie en die zijn absoluut niet traag kan ik je vermelden.

Ik baseer mij op de volgende benches:
http://bind-dlz.sourceforge.net/perf_tests.html

Mijn eigen systemen hebben last van een startup latency, van twee seconden verdere benches heb ik zelf nog niet gedraaid.

[BacardiBreezer]

Zo ik ben bezig met een andere custom-made tool. Dit is 100% een succes en kan aangepast worden naar mijn eigen wens

Hoezo uit de doos