Posts made by yaa9k47

Hallo,

ich habe eine Frage zu den Zugriffsrechten auf Dateisystemebene für Installationen auf Linux. Im idoit-rights.sh-script werden, abweichend von den Empfehlungen in der Knowledgebase, zusätzl. rekursiv 777-Rechte für eine ganze Reihe von Ordnern und Dateien vergeben. Das sollte doch nicht nötig sein, wenn als Datei-Eigentümer der Apache-User gesetzt ist, oder? Mindestens die src/config.inc.php enthält bei uns das DB-Passwort im Klartext.

Übersehe ich etwas, oder sollte das Skript nicht lieber gefixed werden, um nicht configs world-readable zu haben?

Als Standard-Rechte sieht das skript 644 für Dateien und 775 für Ordner vor; gibt es bekannte Probleme, wenn ich restriktiver 600 für dateien und 700 für Ordner setze (mit Apache-user als Eigentümer)?

Auszug aus idoit-rights.sh:

  echo "[*] Setting up temp rights"
  $SU_CMD chmod -R 777	temp \
                        src/themes/default/smarty/templates_c \
                        src/themes/default/smarty/cache \
                        src/ \
                        updates/versions \
                        src/config.inc.php \
                        imports/ \
                        upload/files \
                        upload/images

Danke!

Sehr schön, danke für die Rückmeldung!

Ich konnte das Verhalten eben in der Demo-Installation von i-doit.org reproduzieren. Scheint also in der Tat mit der Verschachtelung der Räume ab der 3. Ebene zu tun zu haben.

Die Anpassung beider Einstellungen bringt leider keine Abhilfe. Ich habe jetzt aber festgestellt, daß das geschilderte Verhalten mit der Anzahl räumlich ineinander verschachtelter Gebäude-Objekte zusammenzuhängen scheint. Das Problem tritt auf bei Standort-Pfaden der Form:
root location > Gebäude-Objekt 1 > Gebäude-Objekt 2 > Gebäude-Objekt 3 > Raum-Objekt > Schrank-Objekt > Gerät

Das Problem tritt hingegen nicht auf, wenn ich aus obigem Schema entweder

• ein Gebäude-Objekt entferne:
  root location > Gebäude-Objekt 1 > Gebäude-Objekt 2 > Raum-Objekt > Schrank-Objekt > Gerät

• oder wenn ich das Schrank-Objekt entferne:
  root location > Gebäude-Objekt 1 > Gebäude-Objekt 2 > Gebäude-Objekt 3 > Raum-Objekt > Gerät

( Wir nutzen die mehrfache Gebäude-Verschachtelung dazu, um Standorte abzubilden in der Form: Stadt -> Gebäude -> Gebäudeteil Sollten wir dies besser anders abbilden? )

Danke für die schnelle Antwort, das trifft aber nicht ganz mein Problem. Die von mir geschilderten alternativen Standortpfade treten innerhalb der selben Objekt-Liste auf, beim gleichen Objekt-Typ. Konkretes Bsp. Objekttyp Switch: in der Objektliste wird unter Standort-Pfad jeweils der Pfad angezeigt, aber eben nur dann beginnend mit root location, wenn das Switch-Objekt nicht in einem Schrank positioniert ist (siehe screenshot).

Hallo,

bei uns tritt eine kleine Inkonsistenz bei der Anzeige der Standort-Pfade auf. Das fällt bislang nur optisch auf, es wäre trotzdem schön, wenn wer wüßte, wie ich das behebe:
In Objekt-Listen wird mir der Standort-Pfad in zwei Varianten angezeigt: einmal mit dem kleinen Haus-Piktogramm als Root (wie es auch in der KB zu sehen ist), das andere Mal ohne. Beide Varianten schlagen sich auch in csv-Exports nieder: Standort-Pfade enthalten im Export nur teilweise die "Root location" als erstes Element des Standort-Pfads.
Die Variante ohne Piktogramm/Root Location tritt immer dann auf, wenn das Objekt in einem Schrank-Objekt verortet wurde. Bei den Schrank-Objekten selbst wird der Standortpfad aber noch richtig angezeigt, also mit root location.

Kennt wer dafür eine Lösung? Schön wäre, wenn der Standort-Pfad einheitlich angezeigt werden würde, also immer mit oder immer ohne root location.

Für jeden Hinweis schon mal danke!

Bei uns treten die Exceptions unabhängig davon auf, als welcher user man eingeloggt ist, also auch als admin.

ok, bin schon erstmal beruhigt, daß das kein Fehler in unserem setup ist.

danke für die Rückmeldungen,

Grüße

Hallo Sven,

danke für den Tip mit open_basedir - das war auch bei uns der Fehler. Ein Kollege hatte den value wohl in zeitlicher Nähe zum i-doit-Upgrade gesetzt, deshalb hatte ich fälschlicherweise das Upgrade für ursächlich gehalten.

Grüße

Seit Upgrade auf 1.8 [EDIT: Fehler lag nicht am Upgrade] Es funktioniert bei unserer idoit pro Installation weder Ping noch nslookup bei Layer3-Netzen. Die entsprechenden Buttons sind ausgegraut und nicht klickbar. Sowohl nslookup als auch fping sind installiert und nutzbar (auch für den Apache-user). Fehlermeldung gibt es keine.

Hat jemand eine Idee, woran das liegen könnte, bzw. kann Tips zum Debuggen geben?

Hallo,

wenn wir in idoit pro 1.8 über Verwaltung -> Systemeinstellungen -> Mandanteneinstellungen -> Logging: Exception Log das Exception-Logging aktivieren, wird unter <idoit-installationspfad log="" datum_auth_exception.log="" massenweise="" ins="" geschrieben,="" und="" zwar="" bei="" jeder="" aktion="" über="" die="" webgui.="" dieses="" verhalten="" beobachten="" wir="" sowohl="" nach="" einem="" upgrade="" auf="" 1.8="" als="" auch="" einer="" kompletten="" neuinstallation="" debian="" 8.<br="">Die Logeinträge variieren, alle Messages beginnen mit "Rechtesystem Fehler: (…)".

Bsp.:

[2017-02-14 15:34:30 0.49411700] ERROR:  Exception Trace:

- File: /srv/i-doit/index.php (line: 260)
  include_once
- File: /srv/i-doit/src/hypergate.inc.php (line: 226)
  include_once
- File: /srv/i-doit/src/i-doit.inc.php (line: 121)
  include_once
- File: /srv/i-doit/src/application.inc.php (line: 56)
  isys_application::run
- File: /srv/i-doit/src/classes/core/isys_application.class.php (line: 141)
  idoit\Legacy\ModuleLoader->boot
- File: /srv/i-doit/src/idoit/Legacy/ModuleLoader.php (line: 53)
  isys_module_manager->load
- File: /srv/i-doit/src/classes/modules/manager/isys_module_manager.class.php (line: 1136)
  isys_module_cmdb->start
- File: /srv/i-doit/src/classes/modules/cmdb/isys_module_cmdb.class.php (line: 981)
  isys_cmdb_view_explorer->process
- File: /srv/i-doit/src/classes/modules/pro/cmdb/view/isys_cmdb_view_explorer.class.php (line: 76)
  isys_auth->check
- File: /srv/i-doit/src/classes/auth/isys_auth.class.php (line: 313)
  call_user_func
- File:  (line: )
  isys_auth_cmdb->explorer
- File: /srv/i-doit/src/classes/modules/cmdb/auth/isys_auth_cmdb.class.php (line: 145)
  Message: "Rechtesystem Fehler: Sie verfügen über unzureichende Rechte um den CMDB Explorer zu öffnen."

Wie gesagt, diese log-Einträge fluten unser exception-log, und das Verhalten ist auf Debian 8 reproduzierbar, selbst bei frischen Installation von idoit pro 1.8.2.
Zurücksetzen des Rechtesystems bringt nichts.

Kann vielleicht irgendwer anders dieses Verhalten bestätigen? Und / oder eine Lösung vorschlagen?</idoit-installationspfad>

Mittlerweile wird das Passwort für das Admin-Center ja verschlüsselt in der src/config.inc.php abgelegt. Damit funktioniert momentan (i-doit pro 1.8.2) aber nicht mehr das Zurücksetzen des Rechtesystems über Verwaltung -> Rechtesystem -> Rechtesystem zurücksetzen.

Mit Passwort im Klartext funktioniert es weiterhin.