Hi.
Ich habe auf einer VM in der DMZ ein Verzeichnis, das per .htaccess nur für Lehrer zugänglich ist. Die Auth. funktioniert meistens – aber leider nicht immer.
Es geschieht regelmäßig, dass der Browser
500 Internal Server Error
meldet. Im Apache-Errorlog steht dann:
Fri Mar 29 07:53:06.218226 2019] [authnz_ldap:info] [pid 5420] [client 83.129.129.110:37128] AH01695: auth_ldap authenticate: user blabla authentication failed; URI /videos/ [LDAP: ldap_simple_bind() failed][Can't contact LDAP server]
Für mich sieht das wie ein timeout-Problem aus, da es ja meistens klappt?!
Hat einer eine Idee, wo man da schrauben kann? Der “Workaround” im Moment ist: So oft “Reload” im Browser klicken, bis die Seite kommt.
(ldapsearch kommt übrigens sofort durch – von Verzögerungen merkt man da nichts)
Hat jemand eine Idee?
Noch ein Gedanke: Es ist die gleiche VM, auf der auch unsere NextCloud läuft. Mir kommt es so vor, als wenn das Problem vor allem dann auftaucht, wenn es parallel Zugriff von mehreren Clients gibt. Allerdings ist die VM sehr großzügig ausgestattet und hat mehr als genug Power. Die sollte das eigentlich locker ziehen…
Schöne Grüße,
Michael
Hallo Michael,
schick doch mal deine .htaccess Datei
LG
Holger
Hallo Holger,
hier ist sie…
AuthName "Lehrer"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPURL "ldaps://meine-dyn-adresse.de/ou=accounts,dc=linuxmuster,dc=local?uid"
Require ldap-attribute gidNumber=10000
Options +Indexes +MultiViews
IndexOptions FancyIndexing FoldersFirst NameWidth=* DescriptionWidth=*
DirectoryIndex index.html index.htm
Ich habe natürlich bereits ein paar Möglichkeiten gesucht und schon einige Parametern bei der Freigabe des Verzeichnisses ausprobiert. Momentan sieht die Freigabe (ssl) so aus:
<Directory /var/www/html/videos>
Options Indexes FollowSymLinks Includes MultiViews
AllowOverride All
Order allow,deny
Allow from all
# Require all granted
</Directory>
Es ändert aber nichts … Evtl könnte man die LDAP-Auth. direkt an die 10.16.1.1 durchreichen anstatt erst raus und dann wieder rein zu gehen?
Schöne Grüße,
Michael
Hallo Michael,
könnte auch ein Problem mit der Datenbank sein.
Lässt Du sie auf dem gleichen Server laufen? Falls ja, zieh die mal auf einen anderen Server um.
Viele Grüße
Thomas
Noch eine Idee: Partition voll? Und zwar nicht der Speicher, sondern keine Inodes mehr frei? Kommt bei MySQL/MariaDB des öfteren vor…
Hallo Thomas,
ja, die Seite ist dort untergebracht; es handelt sich aber nur um eine winzige, statische html-Seite, unter der die Kollegen ein paar Schulungsvideos finden können. Da wird also nicht besonders viel vom Apache gefordert. Dass daneben parallel die Nextcloud läuft, dürfte die VM eigentlich nicht im geringsten überfordern?!? Ich wollte eigentlich keinen weiteren Apachen aufziehen, um diese Seite bereit zu stellen.
df -h und df -i habe ich geprüft. Beides absolut im grünen Bereich (alles unter 20%).
Mir kommt das wie gesagt so vor, als wenn die Rückmeldung über die dyn-Adresse -> IPFire -> VM zu lange dauert und der Fehler 500 eigentlich nur ein Timeout ist??
Neue Ideen?
Michael
Könnte auch ein Zertifikatsfehler sein. Die Verbindung unverschlüsselt funktioniert?
Mit freundlichen Grüßen
Thomas Jordan
Hallo Michael,
da es mal geht und mal nicht sollte die Konfiguration in Ordnung sein. Die Meldung Can't contact LDAP server ist ja auch recht eindeutig.
Das könnte auf temporäre Probleme mit der Namensauflösung hindeuten, da wäre es in der Tat ein Ansatzpunkt, nicht den Umweg über extern zu gehen. Du müsstest dazu in der /etc/hosts den Host meine-dyn-adresse.de auf die 10.16.1.1 umbiegen (in der .htaccess kann man nicht die 10.16.1.1 eintragen, sonst gibt es einen Zertifikatsfehler).
Auch denkbar ist natürlich, dass es wegen zu hoher Last zu Timeouts kommt. Hier wäre ein Ansatzpunkt, den Apache von mpm_prefork auf mpm_worker umzustellen (ist sowieso eine gute Idee, wenn man Nextcloud mit vielen Usern laufen hat).
Beste Grüße
Jörg
Hi.
Ok, dazu müsste aber ein Loch in die Firewall auf Port 636.
Ich habe mir gerade nochmal htop auf der VM angesehen: 4 Kerne, 10 GB RAM, reichlich Platz, fast immer idle. Der sollte locker in der Lage sein, mehrere Verbindungen zu bedienen. Nextcloud wird bei uns zwar genutzt - aber nicht sooooo exzessiv 
Habe etwas über mpm_worker gelesen … damit kann man sich in Sachen PHP aber auch ein paar Probleme an Bord holen, oder?
Ich habe es gerade mit http:// … versucht … da gibt’s eine automatische Weiterleitung nach https://
Schöne Grüße,
Michael
Hallo Michael,
das meine ich nicht. Wenn du ldaps verwendest, braucht dein LDAP Server auch ein gültiges SSL Zertifikat. Hier schlägt die Authentisierung fehl. D.h. aus irgendeinem Grund kann der Webserver deinen LDAP Server nicht abfragen. Entweder erreicht er ihn nicht, oder kann wegen eines ungültigen SSL Zertifikats keine Verbindung aufbauen.
Du sagst, es ist der gleiche Server auf dem auch Nextcloud läuft. Die hast du doch auch per LDAP angebunden. Dann muss das auch genauso für deine Webseite gehen.
Beim Thema erreichen: Wohin löst denn dein Webserver per DNS meine-dyn-adresse.de auf? Auf die externe oder auf 10.16.1.1?
Liebe Grüße
Thomas
Hi Thomas,
also der lml Server hatte noch nie ein gültiges Zertifikat. Da wir LDAPS aber bei NextCloud, Wordpress, moodle und was weiß ich noch wo überall nutzen, hätte ich bisher nicht gedacht, dass das ein Problem ist?? Ich tippe daher weiterhin auf die Erreichbarkeit.
Ich habe die Adresse “schuladresse.schule.de” auf einem vServer als CNAME-Record auf einen DynDNS-Anbieter gelegt. Der löst dann also immer auf die richtige Dyn-IP auf. Der Rückweg läuft dann über die Fritzbox (Portweiterleitung) --> IPFire --> VM.
Ist schon möglich, dass das nicht schnell genug geht, oder?
Schöne Grüße,
Michael
Hallo Michael,
dann schau Mal in den Logs auf dem LDAPServer nach, ob da Anfragen ankommen und warum die ggf. abgelehnt werden.
Das wäre meine nächste Idee. Falls der nix empfängt ,die Firewall-Logs prüfen, ob und wo die Anfrage hängen bleibt.
Viele Grüße
Thomas