Update und Customizing

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 Like

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 ( :wink: ) 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 Likes

Vielen Dank fĂĽr eure Hilfe.:clap:
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 :slight_smile:

Ich hoffe das hat fĂĽr den Einstieg geholfen!

Viele GrĂĽĂźe
Alex

2 Likes