Hallo,

hier liegen wohl zwei Probleme vor.

1. User haben nach Login keine Rechte
Normalerweise sind die User dann in der falschen Gruppe. Bei der Definition des LDAP-Servers gibt man einen Filter an. Z.B. "(memberof=CN=MEINEGRUPPE,OU=…)".
Der String MEINEGRUPPE muss dann bei einer i-doit Gruppe unter "LDAP-Gruppe (Mapping)" eingetragen werden. Der LDAP-sync spielt hier noch keine Rolle.

2. LDAP-Sync geht nicht.
Den Fehler in der exception.log kann ich nicht reproduzieren (gleiche i-doit Version). Sie ist aber eindeutig: Der User hat das Recht nicht zum Ausführen des Handlers Admin sollte immer die rechte haben. welcher USer auf Betriebssystemebene fürht den Sync durch? www-data?
Den LDAP-Bind Fehler bei der Ausführung des Handlers bekomme ich wirklich nur, wenn das Passwort falsch ist. Schon einmal mit ldapsearch auf der Kommandozeile die Parameter überprüft? Der GUI traue ich nicht so richtig.

Hallo,

bei der Definition der LDAP-Verbindung z.B. folgenden Filter nutzen:
(memberof=CN=XXX,OU=Gruppen,DC=hier,DC=das,DC=richtige,DC=de)

Die DCs bitte eurer AD-Struktur anpassen.
Man kann beliebige normale LDAP-Filter nutzen, diese sind nicht i-doit spezifisch.

Hallo,
ich hätte nach Schritt 3 noch die Erzeugung des Mysql idoit-Users (welcher bei der i-doit Installation im Webinterface angegeben wird) sowie das Setzen der DB-Rechte erwartet.  Also so etwas wie:
GRANT USAGE ON . TO 'idoit'@'localhost' IDENTIFIED BY PASSWORD 'xxx'
GRANT ALL PRIVILEGES ON idoit_system.* TO 'idoit'@'localhost'
GRANT ALL PRIVILEGES ON idoit_data.* TO 'idoit'@'localhost'

Weiterhin sollte man beachten, dass bei dem SLES12 PHP den Mysql-Socket standarmäßig unter /var/run/mysql erwartet. Wenn man aber Mysql 5.6 nutzt, liegt der Socket unter /var/lib/mysql.
Zum Test einfach mal einen Link setzen: ln -s /var/lib/mysql/mysql.sock /var/run/mysql/mysql.sock
Falls das der Fehler war, in einer php.ini die Zeile
mysql.default_socket = /var/lib/mysql/mysql.sock
einfügen, da der symbolische Link nach einem Reboot weg ist.

Viele Grüße
K. Hildebrandt

Hallo,

zu Punkt 1:
Dies habe ich auch schon durchgeführt. Die DB anlegen und die Rechte für den idoit-user setzen. Dann das i-doit Verzeichnis vom SLES11 auf den SLES12 in das gleiche Verzeichnis kopieren (nicht alles steht in der Datenbank z.B. Handbücher etc.) und den mysldump einspielen.
Ich konnte dann mit der Version 1.4.x länger arbeiten und bis zur Version 1.4.11 updaten. Probleme bereitete nur das Update auf i-doit 1.5.x. Dies konnte ich nicht auf einem SLES12 korrekt beenden. Es wurde immer der komplette Festplattenplatz durch Dateien im MariaDB-Verzeichnis aufgebraucht, so dass die Installationsroutine nicht zu Ende lief.
Das gleiche Verhalten (Vollschreiben der Platte) konnte ich unter SLES12 und i-doit 1.4.11 deterministisch nachvollziehen, wenn ich in der i-doit Verwaltung unter "Systemtools" => "Cache /
Datenbank" die Schaltfläche "Tabellen Defragmentierung" (oder den "One Support-Button") verwendete.

Unter SLES11 (noch mit "echter" Mysql-DB) oder OpenSuse 13.2 (welches die gleiche MariaDB-Version wie der SLES12 verwendet), habe ich keine Probleme gehabt.
Letztendlich habe ich auf dem SLES12 die Datenbank von MariaDB auf Mysql 5.6.25 gewechselt. Dort klappte das i-doit Update dann ohne Probleme. Das System läuft damit einige Monate stabil.

Hinweis zum Apache: Auf dem SLES 12 läuft ein Apache 2.4. Dieser behandelt Zugriffsregeln (allow, deny) anders. Deshalb „a2enmod access_compat“ ausführen, damit die alten Regeln erlaubt werden. In einigen .htaccess Dateien vom i-doit werden diese genutzt.

zu Punkt 2:
Dabei habe ich unter dem SLES12 noch nie Probleme gehabt. Wenn man wie unter Punkt 1 beschrieben verfährt, sollte sich dieser Schritt auch erübrigen.

Viel Erfolg