Hallo,
wir benutzen die Standalone Version 1.8.1 und haben Anpassungen in den Dateien SNCA.xml vorgenommen.
Was passiert mit meinen Anpassungen, wenn ich auf die Version 1.19 aktualisiere?
Hallo Ralblo,
bisher wurde die SNCA bei keinem Update überschrieben, stattdessen wird eine neue SNCA mit der Endung .rpmnew angelegt. Der Abgleich muss dann manuell erfolgen; wenn neue Elemente in der SNCA vorhanden sind fehlen kann es sonst zu Anzeige- und Funktionsfehlern kommen.
Diese Information findest Du auch hier: https://verinice.com/support/pro-update/
Viele Grüße
Stefanie Langer
1 „Gefällt mir“
Hallo @RalBlo,
wie Stefanie bereit erwähnt hat, werden .rpmnew bzw. .rpmold Dateien angelegt. Das sind im Endeffekt Diffs.
Mit einem Diff-Tool deiner Wahl kannst Du angenehm die Unterschiede einsehen und ggf. teilautomatisiert übernehmen.
Ubuntu stellt hier das Tool diff der diffutils (per default vorhanden),
aber es geht auch vim mit der -d Option.
Unter Windows kann der Notepad++ sehr gut die Unterschiede anzeigen.
Als Empfehlung kann ich jedem nur wieder die Verwendung von Git für die Konfigurationsdateien ans Herz legen. Versioniert man die Dateien, können eigene Änderungen/Anpassungen sauber getrackt werden, schnell wieder rückgängig ( 
) gemacht werden und kommt eine neue Version von Sernet, so kann diese in einer Minute (über sogenannte Drei-Wege-Merges) in die eigenen Änderungen integriert werden. In dem Fall bietet sich für Windows ein Git-Tool wie https://gitforwindows.org/ an.
Auch hier können rpmnew- und rpmold-Files in der Diff-Ansicht bequem gegenübergestellt werden.
Mit besten Grüßen
2 „Gefällt mir“
Vielen Dank für eure Hilfe.
Viele Grüße
Hallo @Member123,
das Thema Git ist höchst interessant, aber auch nicht trivial. Könntest Du eine kleine Anleitung zur Verfügung stellen oder auf eine gute Anleitung verweisen?
Vielen Dank, Stefanie Langer
Hallo,
@StefanieLanger
ich kann zumindest mal eine kurze Anleitung für Git und Centos 7 schreiben. Für Verinice nutze ich git (noch) nicht, habe es aber für diverse andere conf Dateien im Einsatz.
GIT installieren
sudo yum install git
Namen und Email konfigurieren (Ansonsten kommt es später zu einem Fehler)
git config --global user.name “Max Mustermann"
git config --global user.email “Max.Mustermann@muster.de”
Hiermit nochmal die eingetragenen Daten überprüfen
git config --list
Anschließend in das Verzeichnis von verinice wechseln und das GIT Projekt erstellen.
cd /usr/share/tomcat6/webapps/veriniceserver/WEB-INF/
git init
Jetzt wird ein unsichtbarer Ordner namens ./git erstellt. Standardmäßig sieht git sämtliche Dateien in dem ordner ( /usr/share/tomcat6/webapps/veriniceserver/WEB-INF/ ).
Das sieht man auch ganz gut mit dem Befehl
git status
Wichtig: Noch wird nichts gesichert, git sieht lediglich die Dateien! (Die Dateien stehen auch unter „untracked“ )
Wie gesagt kann die Liste der „untracked“ Files ziemlich lang werden, daher empfehle ich git erstmal „blind“ zu machen und git dann lediglich zu zeigen, die gesichert/versioniert werden sollen.
echo „*“ > .gitignore
Wenn du anschließend nochmal den Befehl
git status
eingibst, dürfte die lange Liste nach „untracked“ leer sein.
Anschließend müssen nur noch die zu versionierende Dateien angegeben werden.
git add -f veriniceserver-plain.properties
git add -f verinice-ldap.properties
git add -f SNCA.xml
git add -f web.xml
Alle Dateien, die man eben gesichert haben will! Das „-f“ ist nur dann wichtig, wenn du git vorher „blind“ gemacht hast ( echo „*“ > .gitignore ).
Wenn alle Dateien hinzugefügt wurden, muss man das ganze noch „comitten“.
git commit -m „Das ist ein Kommentar z.b. Grundkonfiguration“
Jetzt sind die Dateien gesichert/versioniert.
Wenn jetzt eine Datei verändert wird, kann man mit dem Befehl
git diff
feststellen in wie weit sich die lokalen Dateien von den gesicherten git Dateien unterscheiden. (Einfach mal testen)
Bei jeder Änderung der lokalen Dateien muss man den Befehl
git commit -m „Das ist ein Kommentar z.b. Grundkonfiguration“
absetzen, um die Dateien auch in den „GIT“ Ordner zu laden.
Noch ein paar interessante Befehle:
Um zum Beispiel die Historie für eine spezielle Datei zu sehen kann man auch
git log Filename
eingeben und man sieht sämtliche Versionen dieser Datei mit Timestamp, so kann man auf eine funktionierende Version zurückspringen.
Um einen commit rückgängig zu machen, benötigt man den HASH des commits. Diesen erhält man wie folgt:
git log
Jetzt sucht man sich den Hash eines vorherigen commits (der noch funktionierte). Und man kann diesen wie folgt wiederherstellen:
git checkout CommitHash
Das war jetzt aber echt nur eine kleine Einführung! Es sollte alles mit den angegebenen Befehlen funktionieren. Falls nicht einfach mal googlen. Manche Tutorials sind zwar älter, aber funktionieren trotzdem 
Ich hoffe das hat für den Einstieg geholfen!
Viele Grüße
Alex
2 „Gefällt mir“
