Dalai
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Hallo Leute, da ich nach mehrstündiger Internet-Suche nichts gefunden habe, habe ich mich heute im Forum angemeldet, um hier nachzufragen. Ich habe einen LDAP-Server aufgesetzt. Der läuft auch problemlos (als Datenbackend für einen Samba PDC). Nun - nach erfolgter und erfolgreicher Einrichtung des Servers - wollte ich das Daten(bank)verzeichnis des LDAPs verschieben. Standardmäßig ist das ja /var/lib/ldap was per default in der root-Partition liegt, wo es aber IMO nichts zu suchen hat. Folgendermaßen bin ich dafür vorgegangen: - LDAP angehalten mit /etc/init.d/slapd stop - Daten verschoben von /var/lib/ldap nach /media/daten/ldap - Zugriffs- und Besitzrechte von /media/daten/ldap nach 0755, Besitzer openldap/openldap geändert. - Pfad in /etc/ldap/slapd.conf angepasst, Einstellung directory von /var/lib/ldap nach /media/daten/ldap geändert. Nun das Problem: wenn ich den LDAP mit /etc/init.d/slapd start wieder starten will, funktioniert das nicht. Er gibt mir diesen Output zurück:
The operation failed but no output was produced. For hints on what went wrong please refer to the system's logfiles (e.g. /var/log/syslog) or try running the daemon in Debug mode like via "slapd -d 16383" (warning: this will create copious output).
Also habe ich den LDAP mit dem zusätzlichen Parameter -d 16383 gestartet und dann sehe ich ganz am Ende der Ausgabe dies: slapd -d 16383 -g openldap -u openldap -f /etc/ldap/slapd.conf hat geschrieben: line 68 (directory "/media/daten/ldap") /etc/ldap/slapd.conf: line 68: invalid path: Permission denied
Nochmal: die Rechte des Verzeichnisses stimmen! Besitzer/Gruppe ist openldap und Zugriffsrechte sind auf 0755 gesetzt. Kann mir irgendjemand verraten, wo das Problem liegt? Übrigens tritt dasselbe Problem auf, wenn ich das Verzeichnis /var/lib/ldap nur umbenenne und die Änderung in der /etc/ldap/slapd.conf vermerke! Ist da was hardcoded, oder wie? Ich danke im Voraus für Hilfe MfG Dalai PS: OS ist Ubuntu Server 8.04, die relevanten Partitionen (/ und /media/daten) sind alle ext3.
|
uname
Anmeldungsdatum: 28. März 2007
Beiträge: 6030
Wohnort: 127.0.0.1
|
was per default in der root-Partition liegt, wo es aber IMO nichts zu suchen hat.
Ich verstehe die Leute nicht, die immer an irgendwelchen Konfigurationen rumdrehen wollen. Es gibt viele Leute die sich damit beschäftigen und es bestimmt besser wissen. Und wenn es dir in der root-Partition nicht gefällt so nutze entweder einen symbolischen Link oder lege für /var/lib/ldap doch eine neue Partition an. Im übrigen liegen normale Benutzerdaten (/etc/passwd und /etc/shadow) auch auf der root-Partition, wie böse.
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Ich verstehe die Leute nicht, die immer an irgendwelchen Konfigurationen rumdrehen wollen. Es gibt viele Leute die sich damit beschäftigen und es bestimmt besser wissen.
Es geht hier um die LDAP-Datenbank. Genau dafür gibt's eine Datenpartition, wo man sowas ablegt. Davon abgesehen existiert natürlich ein Image von der root-Partition, aber das macht man eben nicht jeden Tag. Als Default-Einstellung ist /var/lib/ldap ja in Ordnung, aber es geht hier um einen Server, der extra für Daten (und dieses Verzeichnis enthält eben Daten des LDAP) ein separates RAID-1 hat.
Und wenn es dir in der root-Partition nicht gefällt so nutze entweder einen symbolischen Link
Auch das habe ich versucht und /var/lib/ldap nach /media/daten/ldap zeigen lassen, aber die Fehlermeldung des slapd bleibt dieselbe! Er löst offenbar den Symlink selbst auf und startet dann nicht.
oder lege für /var/lib/ldap doch eine neue Partition an.
Ich soll für jeden Furz (sorry für den Ausdruck) ne eigene Partition machen? Es kommt ja noch Samba, Postfix/Dovecot und diverse andere Dienste dazu. Ich habe schon darüber nachgedacht, das /var auf die Datenpartition umzulegen, aber darin liegen eben auch Daten, die zum System gehören (apt-cache) und ich auf der Datenpartition nicht gebrauchen kann.
Im übrigen liegen normale Benutzerdaten (/etc/passwd und /etc/shadow) auch auf der root-Partition, wie böse.
Das sind für's System wichtige Daten, aber keine Anwendungsdaten für die Domäne oder sonst was. Im Übrigen wird's schon einen Grund haben, warum diese Einstellung in der slapd.conf existiert. Ich will wissen, wieso sie nicht das macht, was sie soll; nicht mehr, aber auch nicht weniger. Es geht hier nicht darum, ob das gut oder sinnvoll ist, was ich versuche. Ich will es so haben, dass die DB auf der Datenpartition liegt und fertig. MfG Dalai
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Da mir das Problem keine Ruhe ließ, habe ich selbst ein bisschen rumprobiert und schließlich eine mehr oder weniger befriedigende Lösung gefunden. - LDAP anhalten - Verzeichnis /var/lib/ldap nach /media/daten/ldap kopieren oder verschieben - mount --bind /media/daten/ldap /var/lib/ldap - LDAP wieder starten Läuft wie gewünscht. Trotzdem wäre es interessant zu wissen, warum die Einstellung directory in der slapd.conf existiert und doch nicht funktioniert, wie sie soll. Wenn die Einstellung nicht funktioniert, dann wäre es sinnvoller gewesen, sie wegzulassen, um nicht falsche Hoffnungen zu wecken. Außerdem wäre es schön, wenn der slapd die Symlinks nicht selber auflösen würde, damit man die Verzeichnisse so verbiegen/verlinken kann, wie man will. Dazu gibt's die nämlich. Ja, ich weiß, dass es Open Source ist und ich selber Anpassungen machen könnte. Aber: nur wenige Leute verstehen Quellcode und können programmieren, im Vergleich zu denen gesehen, die Software nur benutzen. Dazu kommt noch das Risiko des (Nicht)Funktionierens des geänderten Pakets und die investierte Zeit. Nicht jeder hat Zeit, ein Paket zu ändern, nur weil bestimmte Eigenschaften nicht funktionieren, wie sie es laut Doku tun sollten. MfG Dalai
|
mindhaq
Anmeldungsdatum: 16. Juni 2005
Beiträge: Zähle...
Wohnort: Berlin
|
Ich bin über das selbe Problem gestolpert, als ich eine weitere Datenbank in einem ganz anderem Verzeichnis hinzufügen wollte (was also auch nichts mit Konfig-Geschraube zu tun hat 😛 ). Nach langem Suchen habe ich dann schließlich die Ursache gefunden: AppArmor ! Das AppArmor-Profil für slapd (/etc/apparmor.d/usr.bin.slapd ) schränkt Dateizugriffe auf einige wenige Verzeichnisse ein, weshalb ein Symlink da auch nichts hilft - das wäre ja auch schlimm, wenn man das so einfach umgehen könnte. Wenn man die Konfigurationen für "the databases and logs" und "lock file" entsprechend anpasst und apparmor neu startet, klappt das ganze auch ohne eigene Partition bzw. umständliche mount-hacks ☺ Verbesserungswürdig in diesem Zusammenhang wäre, dass apparmor bei Regelverstößen ruhig etwas in ein Logfile schreiben könnte. /var/log/apparmor/ ist aber leer, und im syslog steht auch nichts.
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Nach langem Suchen habe ich dann schließlich die Ursache gefunden: AppArmor!
Wie bist du denn darauf gekommen? Da hab ich ja im Leben nicht dran gedacht.
... schränkt Dateizugriffe auf einige wenige Verzeichnisse ein, weshalb ein Symlink da auch nichts hilft
Ah, dann löst also wahrscheinlich nicht der slapd die Symlinks auf sondern AppArmor.
Wenn man die Konfigurationen für „the databases and logs“ und „lock file“ entsprechend anpasst und apparmor neu startet, klappt das ganze auch ohne eigene Partition bzw. umständliche mount-hacks
Danke! So hab ich das jetzt auch gemacht und meinen "Mount-Hack" wieder entfernt.
Verbesserungswürdig in diesem Zusammenhang wäre, dass apparmor bei Regelverstößen ruhig etwas in ein Logfile schreiben könnte.
Das sehe ich allerdings auch so! In diesem Zusammenhang darf ich die englische Wikipedia zitieren: In addition to manually specifying profiles, AppArmor includes a learning mode, in which violations of the profile are logged, but not prevented.
Es wäre also gut, wenn diese Option per default für dieses AppArmor-Profil eingeschaltet wäre. Das macht es Admins leichter, die Ursache für solche Probleme zu finden und diese dann geziehlt zu beheben. MfG Dalai
|
mindhaq
Anmeldungsdatum: 16. Juni 2005
Beiträge: 12
Wohnort: Berlin
|
Dalai schrieb: Nach langem Suchen habe ich dann schließlich die Ursache gefunden: AppArmor!
Wie bist du denn darauf gekommen? Da hab ich ja im Leben nicht dran gedacht.
Irgendwann hatte ich wohl mit Glück die richtige keyword-Kombination bei Google eingegeben, und es erschien ein Beitrag bei ubuntuusers.org. Das Wort "AppArmor" ließ dann den Groschen fallen ☺
Verbesserungswürdig in diesem Zusammenhang wäre, dass apparmor bei Regelverstößen ruhig etwas in ein Logfile schreiben könnte.
Das sehe ich allerdings auch so! In diesem Zusammenhang darf ich die englische Wikipedia zitieren: In addition to manually specifying profiles, AppArmor includes a learning mode, in which violations of the profile are logged, but not prevented.
Es wäre also gut, wenn diese Option per default für dieses AppArmor-Profil eingeschaltet wäre. Das macht es Admins leichter, die Ursache für solche Probleme zu finden und diese dann geziehlt zu beheben.
Hm, das hieße ja, dass AppArmor im default gar nichts bewirkt. Ich fände "prevented and logged" als default sinnvoll. Denn wenn da was verhindert wird, ist es ja entweder ein Konfigurationsproblem (wie hier bei uns) oder ein übergeordnetes Sicherheitsproblem, was eigentlich gar nicht da sein sollte, was man aber ohne Logeintrag gar nicht mitbekommt. Wie man das allerdings einstellt, habe ich jetzt auf die Schnelle auch nicht herausgefunden.
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
In addition to manually specifying profiles, AppArmor includes a learning mode, in which violations of the profile are logged, but not prevented.
Es wäre also gut, wenn diese Option per default für dieses AppArmor-Profil eingeschaltet wäre. Das macht es Admins leichter, die Ursache für solche Probleme zu finden und diese dann geziehlt zu beheben.
Hm, das hieße ja, dass AppArmor im default gar nichts bewirkt. Ich fände „prevented and logged“ als default sinnvoll.
Ups, das wollte ich eigentlich auch schreiben, weil ich dachte, das wäre so gemeint. Da hab ich die Wikipedia zu schnell überflogen *schuldig guck*. MfG Dalai
|
traxanos
Anmeldungsdatum: 31. Dezember 2006
Beiträge: 656
|
Die Aussage das die Datenbank nichts auf Root zu suchen hat ist zwar richtig, aber dafür ist ja /var da. Normalerweise wird /var komplett als eine separate Partition betrieben. So können auch keine Logs das System zu Müllen. Das verschieben auf eine Partition die unter Media ist, sollte man zwar nicht machen, würde man aber dann mit einem "Symbolischen Link" lösen. In deinem Fall: ln -s /media/datenldap /var/lib/ldap Wenn der Server produktiv genutzt werden soll, solltest du darüber nachdenken ihn nochmals richtig aufzusetzen. Ebene 1: Platte Ebene 2: RAID (falls möglich) Ebene 3: Partitionen für LVM-PV und /boot Ebene 4: LVM-VG Ebene 5: LVs für swap. root, home, var (evtl nocht /usr, /opt)
Danach musst du auch nichts mehr verschieben. Und wichtig mach die LVs so klein wie möglich und so groß wie nötig, so dass die VG noch freien Speicherplatz hat. Somit kannst du jederzeit eine LV vergrößern bei Bedarf EDIT: AppArmor loggt alles in /var/log
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Das verschieben auf eine Partition die unter Media ist, sollte man zwar nicht machen, würde man aber dann mit einem „Symbolischen Link“ lösen. In deinem Fall:
Das habe ich doch versucht. Steht doch oben in einem meiner Posts. Der Symlink wird aufgelöst und der Zugriff verweigert.
Wenn der Server produktiv genutzt werden soll, solltest du darüber nachdenken ihn nochmals richtig aufzusetzen.
Na klar. Jetzt, wo das Problem gelöst wurde und auch sonst alles läuft, fang ich nochmal von vorne an? Davon abgesehen teste ich diverse Spielereien erst auf einem anderen System, bevor ich die Änderungen ins Produktivsystem gebe.
AppArmor loggt alles in /var/log
Tut er bei mir nicht. Weder im Syslog noch in /var/log/messages noch in /var/log/apparmor sind sinnvolle oder wichtige Einträge von AppArmor zu finden. MfG Dalai
|