ich habe hier ein selbstkompilierte Verinice-Server-App, kompiliert mit Openjdk 11.
Diese möchte ich nun auf einem CentOS 7-System installieren. Den Systemvoraussetzungen folgend habe ich dort Tomcat 7 installiert sowie java-11-openjdk.
Leider scheint die Default-Java-Version von Tomcat 7 aber Java 8 zu sein, denn die Verinice-App wirft Exception beim Start und kann nicht von Tomcat initialisiert werden.
Welches ist der richtige Weg, das Problem zu heben?
muss Tomcat 7 mit Java 11 betrieben werden?
muss die Verinice-App doch unter Java 8 laufen?
andere Vorschläge?
Vielen Dank für Ihre Hilfe!
Mit freundlichen Grüßen
T. Nieberg
verinice benötigt seit Version 1.23 Java 11. Dementsprechend muss der Tomcat Service auch mit dieser Java Version betrieben werden, da Version 8 nicht mehr funktioniert.
Vielen Dank für Ihre Antwort.
Allerdings kann basiert tomcat 7 unter CentOS 7.x auf Java 8. Hier ist die Dokumentation unter Systemvoraussetzungen | verinice. vermutlich nicht auf dem aktuellen Stand.
Mittlerweile konnte ich die Applikation mit tomcat 8 und Java 11 zum Laufen bewegen. Da allerdings das Datenbank-Layout fehlt und nicht frei verfügbar ist, scheint mir das Vorhaben eh zum Scheitern verurteilt zu sein.
Ein Betrieb des Servers ohne Produktkauf ist nicht möglich, nehme ich an?
Weiterhin - im Moment wuerde ich davon ausgehen, dass nichts weiter notwendig ist, als wie die DB connection richtig aufzusetzen. Das teste ich am Wochenende danach wird es dann fertig ver’docker’t.
Es waere fairer gewesen, wenn Dir jemand geantwortet haette, ob das Schema wirklich nicht dabei ist. Mit gutem Gewissen kann man es so nur einsetzen, wenn man es kauft, und dann lokal per CI parallel baut. Dafuer muesste man halt den Support bezahlen, aber das ist ja ok, und mehr als einige wenige Stunden sind dann sicher nicht notwendig. Da bleibt genug fuer echte Produktfragen danach.
Mehr stoert mich aber das SELinux Thema, und ich haette lieber da etwas contributed als wie reverse engineering zu machen und dokumentieren.
Habe aber nur 1x ich zur Verfuegung, und bis ich es am laufen habe, ist die Zeit fuer echte OSS Arbeit halt verbraten.
FYI @t.nieberg ich hab es nun erfolgreich getestet.
Du kannst den pgdump SQL dump bei bedarf mit $ pg_restore -f ziel.sql schemadump.sql konvertieren und damit auch exportieren.
Erstmal: Es gibt keine fehlenden Komponenten
das verinice.PRO Handbuch ist nicht Teil der OSS und liegt nicht bei
die Dokumentation ist - ich glaube das ist allen klar, die es versuchen - unzureichend
Grauzonen auf der .PRO Seite sind Bereiche wie z.b. wie man die Handbuecher mit in die .PRO Web GUI bekommt („bitte wenden Sie sich an Ihren Admin“), wird man nur mit intensivem Debugging rausfinden
Man muss die wichtigsten Settings in der veriniceserver-plain.properties.local anpassen. Dies sind die Kernparameter wie z.B. die JDBC URL oder der Name der Organisation
mit docker-compose habe ich da noch einige Probleme zu loesen, damit es 100% automatisch laeuft
die automatischen Builds der Handbuecher und das Packaging der JRE/JDK Files ist ein elend fieser Teil fuer nicht Java Devs. Generell muesste ein Profi aber auch Clients mit Amazon Corretto oder einem anderen freien JDK bauen koennen.
Ich werde es bei mir oder beim Kunden regelmaessig in ner CI bauen lassen, um sicherzustellen, dass der Stand der Reproduzierbarkeit jederzeit bekannt ist.
Hintergrund ist hier, es generell via mehreren docker Services laufen lassen zu koennen.
Wenn jemand zufaellig jemand die Kosten uebernimmt, kann ich vermutlich auch die SELinux und GreenSQL Integration anschauen. Erstmal muss ein einigermassen gehaertetes Containersetup reichen.
Dem, der als CISO diese Hardeningthemen nicht auf dem Radar und die Defizite nicht dokumentiert hat: wenn er sein Verinice mit AD Auth und ohne 2FA oder vorgeschaltetes „lokales“ VPN im Corp Net betreibt, gehoert ihm gewaltig der Marsch geblasen.
Ich vermute mal, dass es einige Leute gibt, die ihr Verinice nicht im Verinice dokumentiert haben, sonst wuerde es einige der Themen nicht geben.
Bei Verinice.veo wird es dank Web Interface sicher leichter, diese Sachen einfach selbst nachzuruesten, aber es sind ja auch bei Java nicht gerade „ungeloeste“ Probleme
