¶ Snipe-IT: Struktur und Workflow erklärt
Exported: 3/1/2026 17:01:45
Link: https://gemini.google.com/app/fbed821228e45fb6
¶ Prompt:
Du hast gesagt
Hallo Gemini, in diesen Thread würde ich gerne mit dir weiter besprechen, wie es mit Snipe-IT auf meinen vServer weitergeht und wie es zu handhaben ist.
Vorab: Ich habe gemerkt, dass viele Sachen aufeinander aufbauen. Kannst du mir eine Übersicht erstellen, welche Schritte ich wann ausführen muss, damit ich nicht immer vor eine Wand laufe? zB benötigt ein Asset ein Modell, das Modell wiederum braucht eine Kategorie, etc.
¶ Response:
Hallo! Es ist eine sehr kluge Entscheidung, sich erst einmal die Struktur anzuschauen. Snipe-IT ist wie ein Baukasten: Wenn das Fundament nicht steht, lassen sich die oberen Etagen nicht stabil bauen.
Hier ist die logische Reihenfolge, in der du Snipe-IT am besten fütterst, damit du beim Anlegen eines Assets nicht plötzlich abbrechen musst, weil eine Pflichtangabe fehlt.
¶ 1. Das Grundgerüst (Infrastruktur)
Bevor du Hardware überhaupt anfasst, musst du definieren, wo sie ist und wer sie verwaltet.
-
Standorte (Locations): Wo befindet sich das Asset? (z.B. Hauptquartier, Home-Office, Serverraum).
-
Abteilungen (Departments): Wer nutzt es? (z.B. IT, Marketing).
-
Firmen (Companies): Falls du mehrere Unternehmen oder eigenständige Einheiten verwaltest.
¶ 2. Die Klassifizierung (Kategorien & Felder)
Hier legst du fest, was das Asset eigentlich ist und welche Daten dafür wichtig sind.
-
Kategorien (Categories): Das ist der wichtigste Filter. Hier entscheidest du, ob etwas ein Asset (Laptop), ein Zubehör (Maus) oder ein Verbrauchsmaterial (Toner) ist.
-
Benutzerdefinierte Feldsätze (Custom Fieldsets): Wenn du für Server andere Infos brauchst als für Laptops (z.B. RAM-Bänke vs. Monitorgröße), erstellst du hier die Masken.
¶ 3. Die Definition (Hersteller & Modelle)
Jedes Gerät gehört zu einer Familie. Ohne Modell kein Asset.
-
Hersteller (Manufacturers): Apple, Dell, HP, Logitech.
-
Asset-Modelle (Asset Models): Hier wird es konkret. Ein Modell verknüpft den Hersteller mit der Kategorie und dem Feldsatz.
- Beispiel: Hersteller (Dell) + Kategorie (Laptop) = Modell (Latitude 5420).
¶ 4. Die Inventarisierung (Assets)
Erst jetzt kommen die eigentlichen Geräte ins Spiel.
- Assets: Hier gibst du die Seriennummer und das Asset-Tag (Inventarnummer) ein. Du wählst einfach das vorbereitete Modell aus, und Snipe-IT weiß automatisch, welche Felder auszufüllen sind.
¶ Die Abhängigkeits-Kette im Überblick
In dieser Reihenfolge "erzwingt" Snipe-IT die Eingaben:
| Ebene | Benötigt zwingend... |
|---|---|
| Kategorie | - |
| Asset-Modell | Kategorie + Hersteller |
| Asset | Asset-Modell + Status (z.B. "Einsatzbereit") |
| Herausgeben (Checkout) | Asset + Nutzer (oder Standort/Asset) |
¶ Ein Tipp für den Workflow
Wenn du merkst, dass du viele ähnliche Geräte hast, erstelle erst eines perfekt als Vorlage. Snipe-IT erlaubt es dir auch, Assets zu duplizieren, was bei einer Lieferung von 20 identischen Monitoren lebensrettend ist.
Soll ich dir zeigen, wie du die Status-Labels am besten konfigurierst, damit du immer weißt, was kaputt, im Lager oder gerade im Versand ist?
¶ Prompt:
Du hast gesagt
ja bitte
¶ Response:
Gerne! Die Status-Labels sind das Herzstück deiner Übersicht. In Snipe-IT entscheiden sie darüber, ob ein Gerät als „verfügbar“, „defekt“ oder „ausgemustert“ gilt.
Es gibt vier grundlegende Status-Typen, denen du eigene Namen geben kannst:
¶ 1. Einsatzbereit (Deployable)
Dies sind Geräte, die im Lager liegen und sofort an einen Nutzer oder einen Standort herausgegeben werden können.
-
Beispiel-Labels: „Lager / Verfügbar“, „Neuware“, „Konfiguriert & Bereit“.
-
Wichtig: Nur Assets mit diesem Status-Typ können „ausgecheckt“ werden.
¶ 2. Nicht einsatzbereit (Undeployable)
Diese Geräte sind in deinem Besitz, können aber aktuell nicht benutzt werden. Sie tauchen in der Liste auf, lassen sich aber niemandem zuweisen.
- Beispiel-Labels: „Defekt (In Reparatur)“, „Wartet auf Entsorgung“, „Vermisst/Verloren“, „Teststellung (Intern)“.
¶ 3. Archiviert (Archived)
Diese Assets zählen nicht mehr zu deinem aktiven Inventar. Sie bleiben in der Datenbank für die Historie (z. B. für Audits), tauchen aber in den Standard-Listen nicht mehr auf.
- Beispiel-Labels: „Verkauft“, „Verschrottet“, „Geleast & Zurückgegeben“.
¶ 4. Ausstehend (Pending)
Das ist ein Zwischenstatus. Das Gerät ist zwar da, aber noch nicht bereit für den Nutzer.
- Beispiel-Labels: „In Vorbereitung (Image-Installation)“, „Zulauf (Bestellt)“.
¶ Mein Vorschlag für deine erste Einrichtung:
Erstelle dir unter Admin-Einstellungen > Status-Labels folgende Favoriten, um den Überblick zu behalten:
-
„Lager / Frei“ (Typ: Einsatzbereit) – Standard für alles, was im Regal liegt.
-
„In Reparatur“ (Typ: Nicht einsatzbereit) – So weißt du, dass das Gerät physisch da ist, aber nicht funktioniert.
-
„In Einrichtung“ (Typ: Ausstehend) – Wenn du gerade das Betriebssystem auf dem vServer oder einem Laptop installierst.
-
„E-Schrott“ (Typ: Archiviert) – Für alles, was du entsorgt hast, aber im System behalten willst.
¶ Ein kleiner "Pro-Tipp" für den Workflow:
Wenn du ein Asset anlegst, kannst du ein Standard-Status-Label wählen. Ich empfehle, neue Geräte erst einmal auf „Ausstehend“ oder „In Einrichtung“ zu setzen. Erst wenn alles fertig konfiguriert ist, änderst du den Status auf „Lager / Frei“ (Einsatzbereit).
Soll ich dir als Nächstes zeigen, wie du die Nutzer (Users) importierst oder anlegst, damit du die Assets auch tatsächlich jemandem zuweisen kannst?
¶ Prompt:
Du hast gesagt
Hallo, merke dir mal bitte fürs wochenende, dass wir glpi statt ocs unf snipe-it ausprobieren wollen
¶ Response:
Alles klar, ich habe dir für das kommende Wochenende eine Erinnerung erstellt, GLPI als Alternative zu OCS und Snipe-IT auszuprobieren.
GLPI ist tatsächlich ein sehr mächtiger Ansatz, da es ITAM (Asset Management) und ITSM (Helpdesk/Ticketing) in einer einzigen Lösung vereint. Während Snipe-IT sich fast ausschließlich auf die Inventarisierung konzentriert, bietet GLPI von Haus aus eine tiefere Integration für Service-Prozesse.
Soll ich dir zur Vorbereitung auf das Wochenende schon mal die grundlegenden Unterschiede in der Architektur von GLPI im Vergleich zu Snipe-IT heraussuchen?
Samsung Reminder
GLPI statt OCS und Snipe-IT ausprobieren
Sa, 21. Feb. 2026
¶ Prompt:
Du hast gesagt
Ja bitte
¶ Response:
Das ist eine gute Idee, da sich die Philosophie hinter den beiden Systemen deutlich unterscheidet. Während Snipe-IT sich darauf spezialisiert hat, eine moderne und benutzerfreundliche „Inventarliste“ zu sein, ist GLPI eher ein „Schweizer Taschenmesser“ für die gesamte IT-Abteilung.
Hier sind die wichtigsten strukturellen Unterschiede, die dir am Wochenende beim Testen auffallen werden:
¶ 1. Alles-in-einem vs. Spezialisierung
-
Snipe-IT: Konzentriert sich primär auf den Lebenszyklus von Assets (Kauf -> Zuweisung -> Entsorgung). Es ist schlank und intuitiv.
-
GLPI: Ist ein vollwertiges ITSM-Tool (IT Service Management). Neben der Inventarisierung hast du ein integriertes Ticketing-System, Wissensdatenbanken, Projektmanagement und Vertragsverwaltung.
¶ 2. Die Daten-Erfassung (Agenten vs. Manuell)
-
Snipe-IT: Hier gibst du Daten meist manuell ein oder importierst sie per CSV. Es gibt keinen eigenen „Agenten“, der die Hardware eines PCs automatisch ausliest.
-
GLPI: Nutzt oft den GLPI-Agent (oder früher FusionInventory). Dieser wird auf den Endgeräten installiert und überträgt automatisch alle technischen Details (RAM, CPU, installierte Software) direkt in die Datenbank. Das ersetzt quasi das, was du mit OCS geplant hattest.
¶ 3. Hierarchien und "Entities"
-
Snipe-IT: Nutzt Standorte und Firmen, bleibt aber eher flach in der Struktur.
-
GLPI: Arbeitet mit Entitäten. Das ist extrem mächtig, wenn du verschiedene Standorte oder Firmen strikt voneinander trennen willst (mit eigenen Nutzern, Regeln und Sichtbarkeiten), aber alles in einer Installation verwaltest.
¶ 4. Die Lernkurve
-
Snipe-IT: Man findet sich in 15 Minuten zurecht. Die Oberfläche ist modern („Web 2.0“).
-
GLPI: Die Oberfläche wirkt traditioneller und ist durch die enorme Funktionsvielfalt anfangs etwas erschlagend. Man muss sich erst durch die vielen Menüs arbeiten, um die Asset-Verwaltung zu finden.
¶ Ein kleiner Tipp für deinen vServer-Test:
GLPI benötigt (genau wie Snipe-IT) einen LAMP-Stack (Linux, Apache, MySQL, PHP). Da du Snipe-IT schon im Blick hattest, sollte die Installation auf dem vServer recht ähnlich verlaufen. Achte bei GLPI besonders auf das Verzeichnis files und config, da dort die Berechtigungen korrekt gesetzt sein müssen.
Soll ich dir zum Wochenende auch eine kleine Checkliste zusammenstellen, welche Plugins (wie z.B. für das SNMP-Scanning im Netzwerk) für GLPI am Anfang sinnvoll sind?
¶ Response:
Sehr gerne. Wenn du am Wochenende mit GLPI startest, wirst du feststellen, dass das System durch Plugins enorm erweitert werden kann. Da du ja auch OCS im Blick hattest, ist die Automatisierung für dich sicher ein wichtiger Punkt.
Hier ist eine kompakte Checkliste für deinen Start mit GLPI auf dem vServer:
¶ 1. Die "Pflicht-Plugins" für den Start
GLPI hat einen eigenen Marktplatz direkt in der Benutzeroberfläche. Suche nach diesen Erweiterungen:
-
GLPI Inventory (nativ ab Version 10): Früher war das ein extra Plugin (FusionInventory), jetzt ist es fest integriert. Damit kannst du Computer, Drucker und Netzwerkgeräte automatisch inventarisieren.
-
Databases: Wenn du auch deine Datenbankinstanzen auf dem vServer als Assets tracken willst.
-
Fields: Falls dir die Standardfelder in GLPI nicht ausreichen (ähnlich wie die Custom Fields in Snipe-IT).
¶ 2. Vorbereitung auf dem vServer (SNMP & Agent)
Damit GLPI dein Netzwerk "scannen" kann:
-
SNMP aktivieren: Wenn du Drucker oder Switches finden willst, stelle sicher, dass SNMP auf diesen Geräten aktiviert ist.
-
GLPI Agent: Installiere den Agenten testweise auf einem deiner Rechner. Er sendet die Hardware-Infos (CPU, RAM, Software) per HTTP/HTTPS direkt an deinen vServer.
¶ 3. Der "Erste Schritte" Workflow
Damit du nicht "vor die Wand läufst" (wie du bei Snipe-IT sagtest), empfehle ich diese Reihenfolge in GLPI:
-
Entitäten (Entities) anlegen: Definiere deine Hauptstruktur (z.B. "Privat" oder "Firma").
-
Standorte (Locations): Genau wie in Snipe-IT – wo steht die Hardware?
-
Netzwerke: Definiere deine IP-Bereiche, damit GLPI weiß, wo es suchen soll.
-
Agent-Verbindung: Verbinde den ersten Agenten, um zu sehen, wie die Daten automatisch einlaufen.
¶ Ein wichtiger Unterschied für dein Setup:
In GLPI werden Assets oft automatisch erstellt, sobald sich ein Agent meldet. In Snipe-IT musstest du das Modell und die Kategorie vorher manuell anlegen. GLPI versucht, diese Informationen (z.B. "Hersteller: Dell", "Modell: Latitude") selbstständig aus den Daten des Agenten zu generieren.
Soll ich dir für Samstag noch die passenden Konsolenbefehle für die Installation des GLPI-Agenten unter Linux oder Windows heraussuchen?
¶ Prompt:
Du hast gesagt
Wir werden aber glpi auf meinem heimserver installieren, damit er dort die assets managen kann. Auf dem vserver nützt er mich nichts. Oder kann ich ihn dann trotzdem verbinden?
¶ Response:
Das ist eine sehr wichtige architektonische Entscheidung. Die kurze Antwort lautet: Ja, du kannst beides verbinden, aber es kommt darauf an, was genau dein Ziel ist.
Hier sind die zwei gängigen Szenarien für dein Setup:
¶ Szenario A: GLPI auf dem Heimserver (Lokal)
Das ist die sicherste und einfachste Variante für die Inventarisierung deiner privaten Geräte.
-
Vorteil: Der GLPI-Server und die Assets (PCs, Drucker, Smart Home) befinden sich im selben Netzwerk. Der Agent auf deinen Geräten funkt einfach die lokale IP des Heimservers an.
-
Nachteil: Du kommst von unterwegs nicht ohne VPN oder Port-Freigabe an deine Daten heran. Wenn du Assets auf dem vServer (z.B. Webserver-Instanzen) erfassen willst, müssten diese über das Internet auf deinen Heimserver zugreifen können.
¶ Szenario B: GLPI auf dem vServer (Zentral)
Du kannst GLPI auf dem vServer lassen und trotzdem deinen Heimserver und die lokalen Geräte managen.
-
Wie das geht: Der GLPI-Agent, den du auf deinen Rechnern zu Hause installierst, bekommt als Ziel-URL die Adresse deines vServers (z.B.
https://dein-vserver.de/glpi). -
Vorteil: Du hast eine zentrale Konsole für alles – deine vServer-Instanzen und deine Heim-Hardware. Der Agent "pusht" die Daten aktiv von zu Hause zum vServer. Du musst zu Hause also keine Ports öffnen, da die Verbindung von innen nach außen aufgebaut wird.
-
Sicherheit: Die Verbindung sollte dann zwingend über HTTPS verschlüsselt sein.
¶ Was ich dir für das Wochenende empfehle:
Wenn du dich für die Installation auf dem Heimserver entscheidest, hier die Befehle für den GLPI-Agenten (unter Debian/Ubuntu), damit er die Daten an deinen Server sendet:
-
Installation des Agenten:
Bash
sudo apt update sudo apt install glpi-agent -
Konfiguration der Ziel-URL: In der Datei
/etc/glpi-agent/agent.cfgmusst du den Server eintragen:Bash
server=http://IP-DEINES-HEIMSERVERS/glpi/ -
Sofortiges Inventar senden:
Bash
sudo glpi-agent --force
Mein Rat: Wenn du ohnehin einen vServer hast, ist die Installation dort oft charmanter, weil du die "Zentrale" immer erreichbar hast. Die Agenten zu Hause schicken ihre Daten einfach dorthin, egal ob sie hinter einer FritzBox oder in einem anderen Netz hängen.
Soll ich dir für Samstag die Vor- und Nachteile von Docker vs. nativer Installation (Apache/PHP) für GLPI auf deinem Heimserver heraussuchen? Da du ja auch Pilze, Zwiebeln und Gurken magst – vielleicht hast du ja auch Lust auf ein "Rezept" für eine schnelle Docker-Installation?
¶ Response:
Gern! Da du deinen Heimserver (und vielleicht auch den vServer) sauber halten willst, ist Docker oft das "schnellere Rezept". Es ist wie beim Kochen mit vorbereiteten Zutaten: Du musst dich nicht um die genaue PHP-Version oder Apache-Module kümmern, weil alles schon im "Topf" (Container) ist.
Hier ist der Vergleich für deine Entscheidung am Wochenende:
¶ Docker vs. Native Installation
| Feature | Docker (Empfohlen) | Native Installation (LAMP) |
|---|---|---|
| Aufwand | Niedrig: Ein Befehl und es läuft. | Hoch: PHP-Module, Apache/Nginx & MySQL manuell konfigurieren. |
| Updates | Einfach: Image tauschen, fertig. | Komplex: Manuelles Backup & Überschreiben der Dateien. |
| Sauberkeit | Perfekt: Hinterlässt keine Reste im System. | Mäßig: Verstreut Dateien im ganzen Linux-System. |
| Performance | Minimaler Overhead. | Direkt auf der Hardware (kaum spürbar schneller). |
¶ Das "Rezept": GLPI mit Docker Compose
Falls du Docker auf deinem Heimserver hast, kannst du diese docker-compose.yml nutzen. Das ist quasi die Einkaufsliste und Kochanleitung in einem:
YAML
version: '3.8'
services:
db:
image: mariadb:10.11
container_name: glpi-db
volumes:
- ./mysql:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=dein_sicheres_passwort
- MYSQL_DATABASE=glpidb
- MYSQL_USER=glpiuser
- MYSQL_PASSWORD=glpipassword
restart: always
glpi:
image: diocedigital/glpi:latest
container_name: glpi-app
depends_on:
- db
ports:
- "8080:80"
volumes:
- ./glpi_data:/var/www/html
restart: always
¶ So gehst du vor:
-
Speichere den Text oben in einer Datei namens
docker-compose.yml. -
Starte den Container mit:
docker-compose up -d. -
Öffne im Browser:
http://deine-heim-ip:8080.
¶ Warum der Heimserver für lokale Assets besser ist (mit Trick)
Wenn GLPI zu Hause läuft, kann es per SNMP-Scan dein gesamtes Netzwerk "abgrasen". Es findet deinen Drucker, deine Smart-Home-Bridge und sogar deine Kaffeemaschine (falls sie im WLAN ist), ohne dass du überall einen Agenten installieren musst.
Der Clou für den vServer: Du kannst den GLPI-Agenten auf deinem vServer installieren und ihm einfach deine Heim-IP (oder eine DynDNS-Adresse) geben. So "meldet" sich der vServer brav bei dir zu Hause im GLPI an.
Soll ich dir zeigen, wie du eine Port-Weiterleitung oder einen Reverse Proxy einrichtest, damit dein vServer seinen Status sicher nach Hause funken kann?