Einheiten (Entitäten) und Standorte wirken in GLPI wie derselbe „Baum“, lösen aber gegensätzliche Probleme: Eine Einheit segmentiert Daten und Berechtigungen; ein Standort ist nur eine physische Referenz. Beides zu verwechseln – oder die Hierarchie der Einheiten erst zu entwerfen, wenn die Daten schon erfasst sind – ist die Ursache von Nacharbeit, die Tage kostet. Dieser Leitfaden zeigt, wie GLPI diese Bäume in der Datenbank speichert, eine Schritt-für-Schritt-Anleitung zur Planung der Struktur und die Fallen, die erst im Betrieb von Umgebungen mit mehreren Einheiten auftreten.
Einheit, Standort und Gruppe: Wer macht was
Legen Sie vor dem Anlegen eines Knotens die Grenze fest. Alle drei Mechanismen organisieren GLPI, aber entlang unterschiedlicher Achsen – und eine falsche Wahl führt zu Datenlecks oder zu Bürokratie ohne Funktion.
| Mechanismus | Segmentiert Berechtigungen? | Hierarchisch? | Was ein Benutzer dann sieht | Typische Verwendung |
|---|---|---|---|---|
| Einheit | Ja (Daten und Zugriff) | Ja | Nur die Daten seiner Einheit | Niederlassung, MSP-Kunde, isolierte Abteilung |
| Standort | Nein | Ja | Nichts ändert sich – nur ein physisches Etikett | Gebäude, Etage, Raum, Rack, Rechenzentrum |
| Gruppe | Teilweise (Tickets) | Ja | Tickets, die seiner Gruppe zugewiesen sind | Support-Team, Squad, Bereitschaft |
Praxisregel: Eine Einheit ist eine Vertraulichkeitsgrenze, ein Standort ist die physische Karte eines Assets, eine Gruppe ist die Arbeitswarteschlange. Lautet die Frage „wer darf dies sehen“, ist die Antwort fast immer: Einheit – ein Standort verbirgt nie etwas vor irgendjemandem.
Wie GLPI den Baum der Einheiten speichert
Die Ansicht Verwaltung > Einheiten ist eine Hülle über der Tabelle glpi_entities. Jede Zeile verweist über die Spalte entities_id auf ihr übergeordnetes Element, speichert den vollständigen Pfad in completename und die Tiefe in level. Zwei stille Spalten – sons_cache und ancestors_cache – speichern den vorberechneten Baum in serialisierter Form; aus ihnen lesen die Sichtbarkeitsfilter, nicht aus einem rekursiven JOIN zur Abfragezeit.
-- Arvore de entidades: pai, nivel e caminho completo
SELECT e.id,
e.name AS entidade,
e.completename AS caminho,
e.level AS nivel,
pai.name AS entidade_pai
FROM glpi_entities e
LEFT JOIN glpi_entities pai ON pai.id = e.entities_id
ORDER BY e.completename;
Der Wert completename („Matriz > TI > Suporte“) erscheint in Auswahlfeldern und Berichten; level beschleunigt die Sichtbarkeitsabfragen. Merken Sie sich diese beiden Namen: Über completename prüfen Sie den Baum, und über level bestimmt GLPI den Geltungsbereich, ohne die ganze Tabelle zu durchsuchen.
Vererbung: Was an untergeordnete Einheiten weitergegeben wird (und was nicht)
Eine untergeordnete Einheit erbt nicht automatisch Daten der übergeordneten – sie erbt als rekursiv markierte Konfiguration. Kategorien, SLAs, Geschäftsregeln, Benachrichtigungsvorlagen und Standorte tragen ein Paar (entities_id, is_recursive): Um im ganzen Baum zu gelten, muss ein Element in der Stammeinheit liegen (entities_id = 0), mit is_recursive = 1. Wird eine Kategorie innerhalb einer untergeordneten Einheit angelegt, ist sie dort gebunden, und Geschwistereinheiten sehen sie nicht.
-- Categorias ITIL que NAO estao compartilhadas para toda a arvore
-- (um item global correto tem entities_id = 0 e is_recursive = 1)
SELECT id, name, entities_id, is_recursive
FROM glpi_itilcategories
WHERE NOT (entities_id = 0 AND is_recursive = 1);
Der häufige Fehler ist, eine ITIL-Kategorie „nur für diesen Kunden“ anzulegen und dann festzustellen, dass die Hälfte der Organisation sie nicht sieht. Im Betrieb führen wir diese Prüfung vor jedem Go-live mit mehreren Einheiten durch: Ein Element, welches global sein sollte und nicht in (0, rekursiv) liegt, ist ein Fehler, der auf sein erstes Ticket wartet.
Schritt für Schritt: Struktur vor den Daten entwerfen
- Listen Sie die echten Vertraulichkeitsgrenzen auf (wer was NICHT sehen darf). Jede harte Grenze wird zu einer Einheit; der Rest ist Standort oder Gruppe.
- Zeichnen Sie den Baum auf Papier mit höchstens drei Ebenen. Tiefe kostet in jedem Auswahlfeld und jedem Bericht.
- Legen Sie Einheiten über die Oberfläche an, von oben nach unten – nie per SQL (siehe Fallen).
- Konfigurieren Sie in der Stammeinheit, was gemeinsam ist (Kategorien, SLAs, Benachrichtigungen), und markieren Sie dabei
is_recursive; geben Sie nur an untergeordnete Einheiten weiter, was exklusiv für sie ist. - Erst dann erfassen Sie Benutzer, Assets und Tickets. Daten später zwischen Einheiten zu verschieben ist teuer und zieht Anhänge mit.
Standorte: physische Hierarchie und ein Feld, welches alle vergessen
Die Tabelle glpi_locations ist über ihr eigenes locations_id (übergeordnetes Element) hierarchisch, aber jeder Standort gehört auch zu einer Einheit (entities_id) und hat is_recursive. Ein in einer untergeordneten Einheit angelegter Standort erscheint in anderen Einheiten nicht, sofern er nicht rekursiv ist – derselbe Mechanismus wie bei Kategorien. Und der Wert 0 in locations_id ist nicht null: Er ist der Sentinel „kein Standort“.
-- Computadores sem localizacao definida, por entidade
SELECT e.completename AS entidade,
COUNT(*) AS sem_localizacao
FROM glpi_computers c
JOIN glpi_entities e ON e.id = c.entities_id
WHERE c.locations_id = 0 -- 0 = nenhuma (sentinela), nao NULL
AND c.is_deleted = 0
GROUP BY e.completename
ORDER BY sem_localizacao DESC;
Inventar ohne Standort ist ein stilles Muster, welches beim ersten physischen Vorfall auffliegt („in welchem Rack steht es?“). Die obige Abfrage wird zu einem Hygiene-Indikator für die CMDB, den wir pro Einheit verfolgen, statt zu einer Überraschung mitten in der Nacht.
Fallen aus der Praxis
Die schlimmste von allen: eine Einheit direkt per SQL in der Datenbank anlegen. Die Zeile wird eingefügt, aber sons_cache und ancestors_cache der übergeordneten Einheit werden nicht neu berechnet – und da Sichtbarkeitsfilter aus diesen Caches lesen, bleibt die Einheit für getSonsOf() unsichtbar. Ein grausames Symptom: Die Einheit existiert in der Tabelle, erscheint in einem SELECT, verschwindet aber aus Auswahlfeldern und aus dem Baum der Oberfläche. Wir haben auf die harte Tour gelernt, nie eine Einheit per INSERT anzulegen: Erst eine Erstellung über die Oberfläche berechnet die Caches neu. Ist ein Legacy-Import bereits per SQL erfolgt, besteht die Korrektur darin, jede Einheit über die Oberfläche erneut zu öffnen und zu speichern, um eine Neuberechnung des Baums zu erzwingen.
- Einheit 0 als leer behandeln – die Stammeinheit hat
id = 0, eine GÜLTIGE ID. Code und Integrationen, dieif (!entities_id)prüfen, verwerfen die Stammeinheit unbeabsichtigt; in select2-Komponenten ist der Wert der Stammeinheit""(leerer String), nie"0". - Dokument verschwindet beim Verschieben eines Tickets – ein Anhang (
Document_Item) erfordert, dass sich ein Dokument in derselben Einheit befindet wie sein Ticket. Wird ein Ticket in eine andere Einheit verschoben, ohne sein Dokument mitzunehmen, ist kein Zugriff auf den Anhang mehr möglich. - Gemeinsamer Standort ohne Rekursion – ein Rack oder einen Raum in einer untergeordneten Einheit anlegen und erwarten, dass die Zentrale ihn sieht: Ohne
is_recursivesieht jede Einheit nur ihre eigenen Standorte. - Zu viele Einheiten – jede Einheit vervielfacht Konfiguration (Kategorien, SLAs, Benachrichtigungen, Profilzuweisung pro Einheit). Zehn fast gleiche Einheiten kosten zehnmal so viel Wartung. Ist ein Bericht der einzige Unterschied zwischen zwei Bereichen, verwenden Sie Gruppe oder Standort, keine Einheit.
Checkliste für die Organisationsstruktur
- Erfassen Sie die Vertraulichkeitsgrenzen, bevor Sie GLPI anfassen; nur sie werden zu Einheiten.
- Begrenzen Sie den Baum der Einheiten auf drei Ebenen Tiefe.
- Legen Sie Einheiten über die Oberfläche an, nie per SQL.
- Konfigurieren Sie Gemeinsames in der Stammeinheit mit
is_recursive = 1; geben Sie nur Exklusives nach unten weiter. - Behandeln Sie
idundlocations_idmit dem Wert0als gültigen Wert, nicht als leer. - Führen Sie vor jedem Go-live die Prüfungen auf nicht geteilte globale Elemente und auf Assets ohne Standort aus.
Müssen Sie eine Struktur mit mehreren Einheiten ohne Nacharbeit entwerfen (oder retten) oder Ihre Standorte auf einer Karte georeferenzieren? NexTool führt GLPI-Umgebungen mit mehreren Einheiten ein und betreibt sie, mit einem von Anfang bis Ende geprüften Baum, und Modul Geolocation bringt Ihre Standorte auf die Karte. Sprechen Sie mit unserem Team für Einführung und Betrieb.
Geprüft vom Team der NexTool Solutions.