Beim Paketieren der i-doit open 1.18 scheint etwas schiefgegangen zu sein - die Default-User werden nicht in der Datenbank angelegt.

Was bei mir funktioniert hat: i-doit open 1.17.2 von SourceForge herunterladen und installieren, und dann mit dem 1.18er Update-Paket aktualisieren.

HTH,
Martin

Da "Floor" und "Building" mit dem Standort zusammenhängt, wäre wohl die Methode cmdb.location_tree.read die richtige. Die funktioniert aber m.W. nur "abwärts" von der Location Root (Object-ID 1) aus. Eventuell kommt man auch mit cmdb.objects_by_relation.read weiter. Dafür müsste man aber die Konstante für den relation_type kennen (die m.W. nirgends richtig dokumentiert sind).

Try pressing the "Adjust" button.

So wie ich es sehe, ist "Status-Planung" Teil des Add-Ons "Wartung". Die Knowledgebase hat aber keine Informationen dazu Die finden sich in einem Blogeintrag von 2020.

Grüße
Martin

Das ist vermutlich analog dem Beispiel für den Command ldap-sync der Knowledgebase eingerichtet. Dort steht nämlich

attributes[personnel_number]=initials

Der Pfad zu dieser Konfig-Datei wird dem ldap-sync per --config übergeben (das i.d.R. per cron-Job ausgeführt wird).

Das liegt jetzt nicht direkt in meinem Kompetenzbereich, aber Tante Google findet diese Liste von AD-Attributen. Ob employeeID oder employeeNumber bei Ihnen genutzt wird, sollten Sie Ihren lokalen AD-Admin fragen.

Under "Attributes selected for display", the "Global" section, enter "General". There's your "CMDB status".

An /var/lib/dpkg würde ich nur mit dem dpkg- oder apt-Befehl indirekt rangehen.

Allerdings kannst Du /var/www/html/updates/versions komplett leermachen - das sind die ausgepackten Dateien für idoit-Updates. Da kommen - in der Anzeige verteilt auf die Unterordner - auch nicht wenige Inodes zusammen.

Was die Platte über Nacht voll macht, kann ich Dir aber auch nicht sagen (und wüßte auch nicht, wie man das herausfinden kann). Sorry.

@C.Geist said:

Danke @MartinV

Sieht aus als wären die Inodes das Problem:
Was kann ich jetzt tun?

Kurz gesagt: Du hast zuviele Dateien im System.

Tante Google verweist zum Thema "linux inodes full" auf Stackoverflow Link1 und Link2.

Es gibt mehrere Kommandos, welche die Verzeichnisse mit den meisten Dateien anzeigen, z.B.

for i in $(find / -type d); do echo $(ls -a $i 2>/dev/null | wc -l) $i; done | sort -n

Falls man entbehrliche Dateien findet (wie bei mir in /var/lib/php/sessions mit 17336 Dateien !), kann man durch Löschen Inodes freischaufeln.

@C.Geist said:

Wie gesagt ich bin kein Linux Profi, aber ich vermute das alles auf /dev/sda1 läuft.

Ja, der root-Mountpoint / ist /dev/sda1. Nur den musst Du Dir anschauen.

Ich verstehe deinen Punkt mit dem begrenzten Diskspace, aber warum kann die CMDB kein 4K log schreiben wenn noch 8,3G frei sind?

Bei Linux-Filesystemen können es auch immer die inodes sein, die knapp werden. Wie die Situation da aussieht, siehst Du mit df -i /

HTH,
Martin

Das liegt jetzt nicht direkt in meinem Kompetenzbereich, aber Tante Google findet diese Liste von AD-Attributen. Ob employeeID oder employeeNumber bei Ihnen genutzt wird, sollten Sie Ihren lokalen AD-Admin fragen.

Das ist vermutlich analog dem Beispiel für den Command ldap-sync der Knowledgebase eingerichtet. Dort steht nämlich

attributes[personnel_number]=initials

Der Pfad zu dieser Konfig-Datei wird dem ldap-sync per --config übergeben (das i.d.R. per cron-Job ausgeführt wird).

When encountering a 500 Internal Server Error, the place to look for error messages is the Apache server error log (by default /var/log/apache/error.log)

Die Fehlermeldung gab's kürzlich schon mal hier im Forum. Schau mal dort.

Bei einem "500 Internal Server Error" hilft i.d.R. ein Blick ins Errorlog des Webservers.

HTH,
Martin

I don't have a ready-made script for you. The APi call to create an object is described in the Knowledge Base. How this is called depends heavily on the programming/scripting language useed.