Ok, Feiertag, guter Anlass weiter an ldap rumzuspielen.
Kurzer Zwischenstand.
ldapsearch -x -W -D 'cn=admin,dc=chii,dc=homedns,dc=org' '*'
geht und zeigt mir den kompletten ldap tree. OK
ldapsearch -x -D 'uid=dominik,ou=People,dc=chii,dc=homedns,dc=org' -W
Zumindest die AUTH klappt mit dem Passwort für dominik das im ldap steht aber Result 0.
Hmmm keine Ahnung ob das ok :-D
Logging für slapd
olcLogLevel auf 256 in /etc/ldap/slapd.d/cn=config.ldif gesetzt und slapd restarted.
rsyslog geadded: Anscheined printed sonst slapd das auf LOCAL4
local4.* /var/log/ldap.log
rsyslog restart.
Soooo, logging klappt.
Noch spezifischer:
ldapsearch -h localhost -p 389 -x -D "uid=dominik,ou=People,dc=chii,dc=homedns,dc=org" -b "uid=dominik,ou=People,dc=chii,dc=homedns,dc=org" -W
AUTH klappt und result ist weiter 0.
Sollte ich nicht mindestens meinen eigenen Eintrag lesen können ? Ich glaube da stimmt was nicht an den ACLs.
ldapmodify will als cn=admin,dc=config mein Passwort nicht.
/etc/ldap/cn=config/olcDatabase={0}config.ldif RootPW fehlt.
Hinzugefügt.
ACLs anschauen:
ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase=hdb olcAccess
Enter LDAP Password:
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn
=admin,dc=chii,dc=homedns,dc=org " write by anonymous auth by self write by *
none
Ok, in deutsch: Admin darf userPassword schreiben, anonymous darf authen und der user selbst darf passwort schreiben.
Sonst gibts keine Regeln.
Bischen radikal find ich. Sowas wie nonanonymous dürfen zumindest ou=People uid, mail und anders nicht sicherheitskritisches lesen.
Puuuuh, schon scheisse wenn man keine Ahnung hat.
Alsooooo, ldap auth von drupal löppt. (daniel und thomas haben das verifiziert :-D)
ldapsearch geht nur per auth, sonst return 0. Genau so solls sein.
phpldapadmin und ldap-account-manager sind ebenfalls am laufen.
Das nächste Ziel wäre es Postfix / Dovecot (oder Cyrus wenn Dovecot doof ist) ldap beizubringen.
Wenn das mal läuft, soll postfix mails die unter der Mailadresse "chii.homedns.org" via Relay über chii.homedns.org@gmx.de verschickt werden.
Damit sich User bei Drupal, Fusionforge, Mailinglist usw. anmelden können, müssen diese Emails verschicken können.
Dank der SPAMer nimmt kein Mailserver mehr Mails aus dem dynamisches IP Bereich der Provider an.
Ok, Startpunkt:
Die Migration Tools von Debian haben mir die Alias Adressen wie logcheck usw unter ou=Aliases abgelegt.
Und unter rfc822blah (s.u.) liegt der Wert wohin die Mails wirklich soll.
Also mal sehen wie wir das postfix beibringen.

Uiii, das ging ja easy
/etc/postfix/ldap-aliases.cf
search_base = ou=Aliases,dc=chii,dc=homedns,dc=org
scope = sub
query_filter = (cn=%s)
result_attribute = rfc822MailMember
und fertig.
Gleiches Spiel für People :-D
search_base = ou=People,dc=chii,dc=homedns,dc=org
scope = sub
query_filter = (uid=%s)
result_attribute = mail
Ich kriege immer mehr Bauchschmerzen ob ich gosa am Schluss so angepasst kriege das es mit meinem Tree löppt, aber egal "vi *.ldif" geht immer, wer braucht schon GUI's :-D
Aber eigentlich sollte gosa an Debian anpassbar sein und nicht andersrum. Abwarten...
/etc/fetchmailrc
set postmaster "dominik"
set bouncemail
set no spambounce
set softbounce
set properties ""
set daemon 300
set invisible
poll pop.gmx.net with proto POP3
user 'chii.homedns.org@gmx.de' there with password 'X' is 'chii.homedns.org' here options ssl sslcertck
Sooo, funzt:
Mail von dominik an chii.homedns.org geht. (Alias chii.homedns.org wird wieder zurück auf dominik gemapped.
Mail von irgendwas@irgendwo.de an chii.homedns.org@gmx.de wird von fetchmail geholt und über den Alias chii.homedns zu dominik weitergeleitet.
Nächster Step wäre jetzt Mails mit Absender chii.homedns.org via RELAY über gmx versenden.
Für heute reichts mir erstmal :-D
| Anhang | Größe |
|---|---|
| 122.5 KB |