ıgnıs: Struktur für jeden Einsatz

Das Ziel von ıgnıs (vormals intraRP) ist es eine Allround-Lösung für die Fraktionsverwaltung fiktiver Feuerwehren & Rettungsdienste vor allem für FiveM und andere ähnliche Settings anzubieten. Das System ist grundsätzlich zur Verwaltung eines deutschen Systems ausgelegt, kann aber mit eigenen Veränderungen durchaus auch an ein amerikanisches oder anderes Setting angepasst werden. Es handelt sich hierbei um eine Weiterentwicklung bzw. den Nachfolger von intra.stettbeck.de. Das System befindet sich in aktuell in Entwicklung und wird stetig verändert.

Installation

Wie du ignis auf einem Webspace, einem eigenen Server mit Apache oder nginx oder mit Docker installierst, steht Schritt für Schritt in der INSTALL.md.

Der Vorteil: immer kostenlos und immer Open Source!

Das Projekt wird hobbymäßig weiterentwickelt und ist für jegliche Unterstützung, Anpassungen, Wünsche & Ideen offen. Einen Vorteil kann man jedoch dauerhaft genießen: Das Projekt ist vollkommen Open Source und kann von jedem angewandt, umgesetzt und verändert/angepasst werden.

Plugins können über die Systemverwaltung installiert und entwickelt werden. Struktur, Sicherheitsmodell, Assets, Cron-Pattern und der versionierte Event-Vertrag stehen in PLUGINS.md.

Benutzte Assets

• Font Awesome 7 (Free)
• Tailwind Plus als lizenzierte Designreferenz; Original-Komponenten und Pakete sind nicht Bestandteil des Repositories. Details und Mitwirkenden-Regeln stehen in THIRD_PARTY_NOTICES.md.
• Tiptap (MIT, Tiptap GmbH) und tiptap-php (MIT) im Editor
• Beinhaltete Schriftarten von Google Fonts
• Chart.js
• SortableJS
• Taktische Zeichen
• Leaflet

Caution

Es handelte sich hierbei um ein kontinuierliches Entwicklungsprojekt! Es kommt zu stetigen Anpassungen. Wir garantieren nicht für Fehlerfreiheit und Datensicherheit!

Hosting und URL-Rewriting

Der Document-Root muss auf das Verzeichnis public/ zeigen. Dort liegen nur der Front-Controller index.php, cron.php und die gebauten Assets; Quellcode, Plugins, storage/ und die .env bleiben außerhalb und sind vom Webserver aus nicht erreichbar. Plugin-Dateien und Uploads liefert die Anwendung über eigene Routen aus.

Apache braucht mod_rewrite und für public/ mindestens AllowOverride FileInfo Options (oder AllowOverride All), damit die mitgelieferte public/.htaccess greift. Bei einer Installation in einem Unterverzeichnis muss BASE_PATH einschließlich abschließendem Slash gesetzt sein, zum Beispiel /ignis/.

Lässt sich der Document-Root auf dem Webspace nicht umstellen, kann er auf das Projektverzeichnis zeigen: Die .htaccess im Projekt-Root reicht dann jede Anfrage nach public/ durch und sperrt die internen Verzeichnisse. Das funktioniert, ist aber die zweite Wahl, weil der Schutz des Quellcodes dann allein an dieser Datei hängt. Das Dashboard weist auf diese Konfiguration hin.

Nach der Anmeldung ruft das Dashboard /api/health auf. Erscheint die Warnung „URL-Rewriting funktioniert nicht“, prüfe zuerst:

1. Zeigt der Document-Root auf public/ (oder ersatzweise auf das Projekt)?
2. Ist mod_rewrite aktiviert?
3. Darf der Webserver die mitgelieferte .htaccess lesen und anwenden?

Für nginx gibt es keine Durchreichung: root muss auf public/ zeigen. nginx.conf.example enthält die passenden try_files-Regeln. /api/health meldet außerdem fehlende PHP-Erweiterungen, HTTP-Transport, eingeschränkte Prozessfunktionen und unter rewrite, ob der Document-Root auf public/ zeigt.

Docker

Für den Betrieb im Container gibt es das Image ghcr.io/emergencyforge/ignis und docker-compose.prod.yml mit MariaDB. Die Vorlage docker/.env.example als .env neben die Compose-Datei kopieren, ausfüllen und starten:

docker compose -f docker-compose.prod.yml up -d

Die Instanz lauscht auf 127.0.0.1:8080 und gehört hinter einen Reverse Proxy, der X-Forwarded-Proto und X-Forwarded-Host setzt (Beispiel am Ende von nginx.conf.example). Updates kommen als neues Image: IMAGE_TAG in der .env anheben, dann docker compose -f docker-compose.prod.yml pull und up -d. Der Updater in den Einstellungen installiert im Container nichts. docker-compose.yml ist das Entwicklungs-Setup.

Anmeldung über ef_bridge

Discord-OAuth funktioniert im Browser von FiveM nicht. Für die FiveM-Ressource ef_bridge (vormals ignisTab) gibt es deshalb eine eigene Anmeldung, die unter Einstellungen › System-Konfiguration › Funktionen mit TABLET_LOGIN_ENABLED eingeschaltet wird (ab Werk aus). Der FiveM-Server schickt POST /api/tablet/login-token mit dem API-Schlüssel im Header X-API-Key und {"discord_id": "…"} und bekommt einen Token, der 60 Sekunden und genau einmal gilt. Das Tablet öffnet damit /auth/tablet?token=… und ist angemeldet wie nach dem Discord-Login. Die vollständige Adresse steht als login_url in der Antwort; sie folgt der System-URL (SYSTEM_URL), nicht der Adresse, über die der FiveM-Server ignis anspricht.

Es funktioniert nur für bestehende, aktive Benutzer, deren Discord-ID in ignis hinterlegt ist; ein Konto entsteht dabei nie. Teilen sich zwei aktive Konten dieselbe Discord-ID, gibt es keinen Token (409, ambiguous_user). Pro Discord-ID gibt es höchstens zehn Token pro Minute. Die Discord-ID stammt vom FiveM-Server, sie ist also nur so verlässlich wie dessen Discord-Pflicht.

Entwicklung: gemeinsame Pakete

Einige Bausteine (UI, Editor, Cron, Mail und weitere) liegen im Paket-Repo WebPackages. Composer bindet sie über Pfad-Repositories aus dem Nachbar-Checkout ../WebPackages ein, Vite baut UI und Editor von dort aus dem Quelltext.

Die CI (php.yml, build-release.yml, image.yml) checkt WebPackages nicht von main aus, sondern den Tag aus .github/webpackages-ref. Ein ignis-Commit baut damit immer gegen denselben Paketstand, und ein Bruch auf WebPackages-main färbt ignis nicht rot. Braucht ignis neuere Pakete, kommt der neue Tag in diese Datei, im selben Commit wie composer.lock und das neu gebaute Dist. Die Schritte stehen in der Datei selbst. Lokal gilt der Ref nicht: gebaut wird aus dem Nachbar-Checkout, wie er gerade ausgecheckt ist.