KVM, video virtio, Debian 8 guest, host with Intel HD 4000 – install a 4.9 kernel on the guest for optimal 2D graphics performance !

Posted on by

Some time ago I wrote a post about the use of new virtio video driver for a KVM guest with a Debian 8 operative system. See:
KVM, video QXL und video virtio – Video-Auflösung des Gnome-Desktops eines Debian 8-Gastystems einstellen
The KVM host at that time was a PC with a native Nvidia graphics card. In my post I was very positive about the 2D-performance results of the spice/virtio combination for the KVM guest graphics.

Two days ago I had to perform the installation of a Debian 8 KVM guest – this time, however, the host was a laptop with an Optimus system: The internal graphics card of the i7-3632QM CPU was/is an Intel HD Graphics 4000. (The laptop has an additional Nvidia GT645 M, which can be used via Bumblebee.) Under normal conditions the Intel HD graphics (with the i915 kernel module) has sufficient power to support 2D and 3D accelerated GUIs. In my case the laptop ran on Opensuse Leap 42.2, qemu-kvm was of version 2.9, libvirt of version 3.3 (installed from the “virtualization”-repository: http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.2/). But this time I got a bit disappointed.

Disappointing 2D-graphics performance of the Debian8 KVM guest with kernel 3.6, with spice/QXL and spice/virtio

I experienced two problematic points with the Debian 8 guest and its original 3.6 kernel:

  • The performance with the Spice/QXL-graphics of the KVM guest was not at all convincing – especially not with GTK-applications (neither on a KDE or Gnome 3 GUI of the guest) at and above guest graphics resolutions 1400×900. I saw tearing of windows during fast movements across the spice terminal screen. Especially disappointing was the performance of Firefox ESR: Sluggish reactions of all kinds of window contents and slow reactions to scrolling of complicated web site contents – especially of running videos. But the QXL driver at least gave me the choice of many, many guest resolutions up to the maximum resolution of the host.
  • The performance was only slightly better with the new “virtio” driver. But the choice of guest resolutions was very limited with a maximum of 1280x768px.

Update to the latest kernel on the Debian 8 guest

I then read on some Internet websites that the virtio graphics driver on qemu/kvm requires a kernel later than version 4.x on the guest system, too. So why not try? The installation of newer kernels on Debian 8 is possible by adding the “backports” repository to apt’s configuration. We have to a add a line

deb http://mirror.one.com/debian/ jessie-backports main contrib non-free

to /etc/apt/sources.list on the Debian system. The we execute

apt-get update

and

apt-get install -t jessie-backports linux-image-amd64

to get the latest kernel installed. In my case this is a SMP kernel of version 4.9.18. Up to now this kernel lead to no conflicts or problems with any of the installed software on the Debian 8 guest.

Results of the updated guest with kernel 4.9

The graphical performance of the Debian guest with spice/virtio combination, however, changed dramatically to the better! Actually, the overall 2D-performance is now really convincing – even on the relatively weak Intel HD 4000. The tear free moving of window frames of all kinds of Qt- or Gtk3-applications across the spice terminal is just one point. The other is that the performance impression of e.g. Firefox ESR on the virtualized guest is almost not distinguishable from Firefox on the host’s
KDE interface. Below you see 2 FF windows on the Gnome GUI of the Debian 8 KVM guest plus a QGit window. One FF window plays a video.

And in addition I now get all resolutions I could wish for:

I love KVM! Even on laptops!

Eternal Blue – und die vermeintliche Sicherheit nach MS Windows Updates

Posted on by

Wannacry und EternalBlue sind gerade in aller Munde. Zu Recht; der bereits eingetretene (wirtschaftliche) Schaden ist immens. Auf der Linux-Seite braucht man sich hier übrigens nicht auf ein hohes Ross zu setzen: Heart Bleed, Shell-Shock, massive Probleme mit SSH und TLS und KEX-Algorithmen seien nur als Beispiele dafür genannt, welche Schwachstellen auch Linux-Systeme lange Zeit unerkannt aufwiesen. Niemand weiß, wie lange die vor ihrer Behebung von wem ausgenutzt wurden … Ich finde, in einem solchen Fall ist klammheimliche Schadenfreude völlig unangebracht. Zumal auch viele Admins in einer heterogenen Welt leben müssen – und mit Samba Brücken zu Windows-Servern oder PCs hergestellt haben. [Es stellt sich nebenbei die Frage, ob eigentlich Samba schwachstellenfrei ist ….]

Was ist eigentlich mit Angriffen ohne Ransomware?

Diskussionswürdig erscheint mir ferner ein Punkt, der mir im Moment in der hektischen Berichterstattung etwas unterzugehen scheint; viele der in deutschen Tageszeitungen erschienen Artikel zu Wannacry hoben vor allem auf Angriffsvektoren ab, die bösartige E-Mail-Anhänge voraussetzen. Die SMB-Schwachpunkte betroffener Windows-Systeme wurden von vielen “fachkundigen” Journalisten lediglich als Hebel für die schnelle Verbreitung der Malware begriffen. Die Aufregung in den Zeitungsartikeln konzentrierte sich deshalb vor allem auf das Thema “Erpressung” und natürlich den Funktionsausfall der betroffenen Systeme.

Dabei hatten Experten und u.a. auch die Fa. Cisco frühzeitig und völlig zu Recht auf folgenden Punkt aufmerksam gemacht:

Eternal Blue ist ein Exploit, den Angreifer gezielt und direkt gegen Systeme, die die SMB-Schwächen aufweisen und verwundbar sind, in einem LAN oder auch aus dem Internet heraus einsetzen können. Voraussetzung ist nur, dass auf den Zielsystemen bestimmte SMB-Ports zugänglich sind. Und natürlich kann im Rahmen des Angriffs auch eine ganz andere und weniger offensichtliche Payload (Schadware) als eine Ransomware zum Einsatz kommen.

Eigene Experimente mit Kali

Ich bewahre nicht ganz zufällig ältere Sicherungsimages von Win7/8/10-Images für VMware auf. Eine solche Kopie konnte ich gestern benutzen, um ein paar Experimente mit EternalBlue und dem Angriffs-Framework “Fuzzbunch” von einem Kali-System aus durchzuführen. Natürlich abgeschirmt von der Umwelt. Ergebnis war die praktische Bestätigung dreier plausibler Vermutungen:

  • Der Einsatz der im April publizierten Angriffswerkzeuge Fuzzbunch (Python-basiert; läuft auf Linux-Systemen unter Wine) und Eternal Blue ist bei ein wenig Erfahrung relativ einfach. Ein aktueller Umlauf von Modifikationen und neuen Angriffsvarianten ist deshalb als wahrscheinlich anzusehen.
  • Ein Angriff gegenüber Windows-Systemen, die die für Eternal Blue notwendigen Schachstellen im SMB-Protokoll aufweisen und von außen über SMB-Ports zugänglich sind, kann direkt und ohne Umwege (über Fake-Webseiten oder bösartige E-Mail-Anhänge) über das Internet geführt werden. Scan-Verfahren zur Identifizierung angreifbarer Systeme lassen sich von bösen Zeitgenossen jederzeit anfertigen. (Nachtrag 27.05.: Für Netzwerk-Admins steht nun z.B. ein NSE-Script für NMAP bereit).
  • Welche Payload (Schadware, Backdoor etc.) ein Angreifer nach Kompromittierung in das Windows-System einschleust, ist relativ beliebig. In Frage kommen u.a. Meterpreter Reverse Shells.

Nachtrag 27.05.2017:
Da ich inzwischen per Mail zwei Anfragen bekommen habe, ob ich die durchgeführten Experimente nicht im Detail beschreiben möchte, Folgendes: Nein, ich möchte nicht ins Detail gehen. Grund: Die deutsche Gesetzgebung (Hacker-Paragraph). Außerdem sind im Internet bereits genügend präzise Beiträge und Filme zum konkreten Einsatz
von EternalBlue erschienen.

Reicht ein Update?

Das Problem hat aufgrund der beträchtlichen Zeitspanne, die seit der Veröffentlichung der Eternal-Tools vergangenen ist, eine weitaus größere Dimension, als so mancher Windows-Nutzer und Konsument von einschlägigen Zeitungsartikeln zur aktuellen Ransomeware-Welle meinen möchte. Bereits im April wurde der Einsatz des Exploits im Detail diskutiert; Hacker hatten also frühzeitig die Möglichkeit, sich tiefer einzuarbeiten.

Dass es viele direkt aus dem Internet angreifbare Windows-Systeme gab und gibt, muss nach den Ereignissen der letzten Tage nicht mehr großartig bewiesen werden. Ich selbst kenne einige kleinere Firmen, die Windows einsetzen und die über das Internet Filesharing per SMB nutzen. Worüber nun alle Verantwortlichen, die bislang anfällige Windows-Systeme betreuen, intensiv nachdenken sollten, ist also das Folgende:

EternalBlue ermöglicht einem Angreifer vor allem den Zugang zu einem kompromittierbaren Windows-System. Der Angriff muss aber keineswegs mit der Implementierung von Ransomware verbunden sein – auch wenn sich die Presse hierauf kapriziert.

Gerade geschickte (und wirklich böse) Angreifer, die perfidere Ziele als eine begrenzte Gelderpressung im Sinne haben, werden nach einem erfolgreichen EternalBlue-Angriff auf den gehackten Systemen problematischer Tools als eine offen nach außen sichtbare Ransomware implantieren. Gerade die wirklich ernst zu nehmenden Angreifer werden sich auf dem kompromittierten System still verhalten, Spuren verwischen, im Hintergrund ihre Privilegien erhöhen, Daten abziehen und sich – wiederum mit Hilfe von Eternal Blue auf andere Systeme im (Firmen-) LAN ausbreiten. Alles ohne, dass man das nach außen hin im Alltagsbetrieb merken müsste. Das war ja gerade das, was die NSA vermutlich mit Eternal Blue und dem Exploit Kit “Fuzzbunch” bezweckte.

Es genügt deshalb keinesfalls, jetzt auf den Systemen, die die SMB-Schwachstellen aufweisen, mal schnell die bislang versäumten Updates einzuspielen und wegen nicht zu Tage getretener Ransomware zu meinen, dass die Welt dann wieder in bester Ordnung sei. Ist sie mitnichten …. denn die wirklich gefährlichen Angreifer haben sich ggf. bereits unerkannt eingenistet.

Diejenigen Windows-Nutzer und Admins, bei denen die Ransomware den Angriff offensichtlich machte, sind in gewisser Weise besser dran als diejenigen, die auch Systeme mit den SMB-Schwachstellen hatten, exponiert waren und mittels Eternal Blue von intelligenten Hackern oder Organisationen angegriffen wurden – die aber davon bislang gar nichts merkten, merken oder merken werden. Man könnte ja auf Virenscanner hoffen – aber das Thema einer Maskierung von Schad-SW gegenüber Scannern ist ja nun wirklich kein Neues; das ist und bleibt ein ewiges Katz und Maus-Spiel ….

Im Bereich der Wirtschaft steht deshalb mal wieder die Bewertung der Auswirkungen unerkannter Wirtschaftsspionage im Vergleich zu den Kosten einer umfassenden Bereinigung potentiell betroffener Systeme an. Als verantwortlicher Admin würde ich jedenfalls kritische Windows-Systeme, die die SMB-Schwachstellen aufwiesen, nach den Vorgängen der letzten Tage neu aufsetzen oder aber zumindest ihren ausgehenden Datenverkehrs feinmaschig überwachen – auch und gerade dann, wenn keine Ransomware erscheint.

Denjenigen Administratoren, die die Gefahr besser ausloten wollen, lege ich zudem einige kürzlich erschienene Veröffentlichungen im Internet zum konkreten Einsatz von EternalBlue, Fuzzbunch etc. ans Herz. Damit sind bereits ein paar Schlagworte für die Suche genannt; weitere Stichworte wären Kali, Wine, msfconsole und Empire.

Nachtrag 26.05.2017:
Meine lieben Linux-Kollegen, die sich bislang ggf. sicher wähnten und Samba im Einsatz haben, seien auf folgende Artikel zu SambaCry hingewiesen:
http://thehackernews.com/2017/
05/samba-rce-exploit.html
https://www.heise.de/security/meldung/Jetzt-patchen-Gefaehrliche-Luecke-in-Samba-3725672.html
https://www.heise.de/security/meldung/SambaCry-Gefaehrliche-Sicherheitsluecke-in-Samba-finden-und-patchen-3726053.html

Interessant zu lesen sind auch die zugehörigen Diskussionen im zugehörigen Heise-Forum – u.a. wegen eines in diesem Falle überflüssigen Lagerkampfes zwischen Linux- und Windows-Anhängern.

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – III

Posted on by

Wir machen weiter mit unserer Einführung von Git – genauer EGit – unter Eclipse. Im ersten Post dieser Serie
Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – I
hatten ich ein einfaches Szenario vorgegeben und zugehörige Aufgaben für die Arbeit mit Git unter Eclipse definiert. Im zweiten Post
Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – II
hatte ich gezeigt, wie man unter Eclipse ein vorhandenes Projekt mit einem Git-Repository versieht.

Ich fasse nochmal die dort geleisteten Schritte unter EGit für Eclipse zusammen:

  • Vorhandenes Projekt unter Eclipse vorbereiten und von SVN-Resten befreien.
  • Target-Verzeichnis für das Git-Repository anlegen.
  • Git-Repository im Target-Verzeichnis initialisieren und EGit den Transfer aller Projekt-Dateien in den “Working Tree” im Target-Verzeichnis vornehmen lassen. Dazu ein dortiges Verzeichnis angeben.
  • Alle Projekt-Verzeichnisse/-Dateien für eine Indizierung/Behandlung in der Git-Versionsverwaltung vormerken. Dabei eclipse- und projektspezifische Dateien/Verzeichnisse gezielt außen vor lassen.
  • Alle Projekt-Verzeichnisse/-Dateien erstmalig “committen”. Im Staging View den Commit mit Informationen zum Autor und Committer sowie mit hinreichenden Kommentaren versehen.

Das führte zu folgendem Bild im Eclipse-View “Git-Repositories”:

Die Anzeige dieses Views erhält man übrigens über den Menüpunkt “Window=> Show View => Other => GIT => Git Repositories”. Es lohnt sich übrigens gleich auch noch prophylaktisch den View “Git Staging” zu laden.

Wir wenden uns nun der Aufgabe 4 unseres Aufgabenkataloges zu:

  • Aufgabe 4: Durchführung von Änderungen im Verzeichnisbaum des Projekts und Testen nachfolgender “Commits”. Blick auf die Git-Versionshistorie auf dem PC. Identifizierung des HEAD-Commmits bzw. -Knotens.

Wer das EGit-Interface nach diesem Artikel genauer studieren will, nutze bitte das Handbuch unter: http://wiki.eclipse.org/EGit/User_Guide

Testverzeichnis und Testdatei

Um die Inhalte des Working Tree nicht zu zerstören, lege ich ein Testverzeichnis “gittest” mit zwei Dateien an : “test.php5” und “basic.css”. Deren Inhalt ist sehr simpel; s.u. Nach der Anlage sieht das im PHP-Explorer so aus:

Man beachte die kleinen symbolischen Fragezeichen; sie deuten an, dass der Git-Status noch undefiniert ist.

Zu diesem Zeitpunkt sind die neuen Dateien noch nicht ohne ein “Refresh” (F5) im Working Tree des Views “Git-Repositories” zu sehen:

obwohl sie dort natürlich vorhanden
sind. Also F5 drücken.

Um das neue Verzeichnis samt Dateien der Versionsverwaltung zu unterwerfen, müssen wir das neue Verzeichnis in PHP-Explorer auswählen und zunächst in den Index des Repositories aufnehmen. Hierzu benutzen wir, wie im letzten Artikel beschrieben, den Button mit dem grünen “+”-Zeichen in der Git-Bedienleiste unter Eclipse:

Im “Git Staging View” erhalten wir dann automatisch die Möglichkeit, einen Kommentar einzugeben:

Danach drücken wir rechts unten auf den “Commit”-Button. Anschließend sind die Fragezeichen-Symbole verschwunden:

Der Master-Branch hat sich entsprechend verändert:

Man beachte die Anzeige des verkürzten Hashes für den Commit, der zur HEAD-Version des aktuellen Branches (im Moment der Master-Branch) führte!

Nun können wir uns mal die sog. “Historie” für “test.php5” ansehen. Dazu rufen wir im Kontext-Menü dieser Datei den Menüpunkt “Team=>Show in History” auf. Im sich öffnenden Historie-View erhalten wir dann:

Es wird der Originaltext der committeten Datei angezeigt. Im Zusammenhang mit dieser Datei gibt es bislang nur einen Knoten, der dem letzten Knoten des Masterbranches entspricht (Man vergleiche die Hashnummern!). Siehe auch, dass im unteren Bereich des Views der aktuelle Stand der Datei “test.php5” mit “/dev/null” verglichen wird!

Dateiänderungen, Commits und Anzeige der Dateiinhalte für verschiedene Knoten

Wir ändern nun den Inhalt der PHP-Datei; wir setzen einen Variablen-Wert um (aus var $a=100; wird var $a=200;) und speichern dann die Datei:

Eclipse zeigt uns (ähnlich wie bei SVN auch) an, dass die Datei zwar geändert wurde, aber die Änderung noch nicht “committed” worden ist. Man erkennt das z.B. am “>”-Symbol an der Datei im Datei- bzw. PHP-Explorer. Um die Änderung im Repository zu erfassen, müssen wir den “Commit”-Button in der Git-Bedienleiste (gelber Zylinder mit rotem Pfeil nach rechts) betätigen. Wie erwartet öffnet sich wieder der “Staging View”, in dem wir die Änderung kommentieren können. Danach drücken wir wieder den Button “Commit”. Ergebnis im Repository-View:

Interessanter ist nun ein Blick in den
View “History”; dort wird die Historie auch in Form eines Graphen angezeigt; die Knoten sind dabei streng gemäß der zeitlichen Historie angeordnet:

Ggf. nochmal F5 drücken, falls im unteren Bereich die Differenzen nicht angezeigt werden sollten. Wir erkennen nun zwei Knoten (mit unterschiedlichen Hashes), die die Historie dieser Datei betreffen. Netterweise wird uns auch die Änderung zur Vorgängerversion angezeigt. Das ist komfortabel!

Ein Doppelklick auf einen Knoten oder aber auf einen der mit einem Knoten verbundenen Dateinamen rechts unten im History-View öffnet übrigens die durch die Versionsänderung betroffene Datei im jeweiligen Zustand des Knotens im Editorbereich – dort wird hinter dem Namen dann auch der Hash des Commits angezeigt. Sind mehrere Dateien betroffen, wird die erste ausgewählte geöffnet.

Klickt man allerdings in der Icon-Leiste, die sich im History View rechts oben befindet, das Icon für den “Compare Mode” (links neben dem Branch-Icon), so öffnet sich die Datei im “Compare-Modus”; die Inhalte der Version des früheren Knotens werden mit der aktuell vorhandenen Version des momentan gewählten Branches verglichen.

Ein Markieren zweier Knoten des Graphen und ein “rechter Mausklick” öffnet ein Kontextmenü; auch hierüber erhalten wir die Option (Menüpunkt “Compare with each other”), ein Vergleichsfenster für diese Versionen im Editorbereich von Eclipse zu öffnen:

Das ist in unserem Fall trivial, da bislang ja nur zwei Knoten existieren. Die genannten Möglichkeiten des History-Views entfalten ihren vollen Nutzen natürlich aber vor allem bei längeren und komplexeren Historien.

Eine längere Änderungshistorie

EGit liefert noch sehr viel Möglichkeiten und Views mehr als oben beschrieben. Der Leser kann ja nun selbst mal eine Kette von Änderungen an verschiedenen Testdateien vornehmen und jede dieser Änderung committen. Natürlich ist das nicht die normale Situation in einem ernsthaften Entwicklungsprozess; wir spielen im Moment ja aber nur, um uns an EGit zu gewöhnen.

Die nachfolgende Darstellung zeigt dann das Ergebnis nach 5 bzw. 4 weiteren Änderungen an unseren beiden Testdateien “test.php” und “basic.css” im View “History“. Den History View erreicht man übrigens auch durch einen “rechte-Maus”-Klick auf den Branch im View “Git Repositories”; dort ist “Show In => History” zu wählen:

Wir bekommen nun eine etwas umfangreichere Darstellung der erstellten Knoten in unserem Master-Branch. Ein “Rechte-Maus-Klick” auf einen Knoten führt übrigens zu einem Kontextmenü, über dessen Punkt “Open in Commit Viewer” man auch eine Ansicht der zugehörigen Commit-Einträge (Kommentare etc.)
öffnen kann.

Unser lineare Graph ist im Moment allerdings immer noch etwas langweilig, da wir bislang kein Branching vorgenommen haben.

Testweises Branching

Branching gehört zwar nicht zum Umfang dieser Serie von Posts zu Git. Damit die Graphen jedoch nicht ganz so langweilig aussehen, müssen wir aber unseren Master-Branch durch weitere Entwicklungszweige ergänzen. Dort sind neue Knoten zu erzeugen und auch ein Zusammenführen von Entwicklungszweigen (Mergen) ist natürlich interessant. Ich gehe hier allerdings nur kurz auf diese Thematik ein. Das gewählte Beispiel ist entspricht dabei nur einer wenig sinnvollen, praxisfernen Spielerei; wer einen schnellen und realitätsnahen Überblick darüber gewinnen will, wie man Branching für verschiedene Situationen eines Entwicklungsprozesses effektiv nutzt, möge sich z.B. das Buch “Git” von Rene Preißel und Bjørn Stachmann (dpunkt.verlag) zu Gemüte führen.

Einen neuen Branch legt man im View “Git Repositories” z.B. über das Kontextmenü des Zweiges “Branches => Local” an.

Danach gibt man in einem Popup-Formular den Namen des neuen Branches an; die Option “Checkout” zum Wechseln in den Branch ist bereits vorbelegt:

Man erkennt danach im View “Git Repositories”, dass der neue erzeugte Branch “Consolidation” auch der aktuelle (Arbeits-) Branch geworden ist (kleiner schwarzer Haken). Alle kommenden Änderungen finden auf den vorhandenen Dateiständen dieses Branches statt, bis man ggf. den Branch des Repositorys wieder gezielt wechselt.

Man erkennt an der Abbildung, dass ich auf diese Weise bereits insgesamt 4 Branches zu meinem Repository angelegt habe – neben dem “master” die Brances “bugfix”, “consolidation” und “php-extensions”. Nun kann man in diesen Branches testweise die gleiche Datei (test.php5) in unterschiedlicher, aber konflikterzeugender Weise editieren und dann im jeweiligen Branch durch Commit einen neuen Knoten erzeugen. Die jeweiligen Dateiversionen in den jeweiligen Branches sollen danach einander widersprechende Inhalte besitzen.

Ich ändere beispielsweise im Branch “bugfix” den Wert von $a auf “$a=10” ab. Dazu muss ich zuerst in den Branch “bugfix” wechseln. Dies geht wieder im Kontextmenü von “Local”:

Ist die Datei “test.php5” schon im Editor-Bereich geöffnet, ändert sich der Editor-Inhalt automatisch auf den des aktuellen Branches. Nach dem Branch-Wechsel führen wir die Änderung “$a=10;” durch und committen die neue Version. Dann machen wir eine entsprechende unabhängige Änderung “$a=20” in der gleichen Datei des Branches “php-extensions” und committen auch dort. Abschließend nehmen wir eine Änderung “$a=30” im Branch “master” vor. Schließlich wechseln wir in den Branch “consolidation”. Dort setzen wir “$a=40” und committen.

Wir “mergen” nun in einem weiteren Schritt den Branch “bugfix” in den Branch “consolidation”. Wir lösen den Merge-
Vorgang über das Kontextmenü des Branches “consolidation” aus:

In unserem speziellen Fall muss das zu einem Konflikt führen. Grund ist, dass in den zu mergenden Dateien unterschiedliche Vorgaben in demselben betroffenen Zeilenbereich stehen und die logische Historie nicht eindeutig ist. Git kann nicht wissen oder erschließen, welche Änderung in welchem Branch die gewünschte sein soll. Beide Änderungen sind ja nach dem Zeitpunkt der Verzweigung in gleichen Codebereichen erfolgt. (In manchen Git-Tools kann man übrigens einstellen, ob man rein der zeitlichen Abfolge vertrauen soll. Ich nutze ein solche Option aber aus guten Gründen nie).

Der Konflikt wird auch an anderer Stelle deutlich markiert; im geöffneten Editor einer betroffenen Datei u.a. durch gezielt vorgenommene Einschübe:

Man beachte die Markierung der verschiedenen Varianten im Editor durch “>>>” und “<<<” Zeilen. Im PHP Explorer View “Git Staging” ist der Konflikt dagegen durch eine deutliche rote Markierung am jeweiligen Dateieintrag hervorgehoben.

Rechts sieht man übrigens das sog. “merge tool”, dass man etwa über das Kontext Menü der Datei im unteren Bereich “Unstaged Changes” öffnen kann. Es geht aber immer auch über Unterfunktionen des Punktes “Team” im Kontext-Menü der Datei im PHP-Explorer.

Wir lösen den Konflikt im Editor auf; d.h. wir entscheiden uns dabei für eine der angedeuteten Varianten, z.B. die Variante vom Branch “bugfix” (a=10). Die nicht gewünschten Zeilen und die Markierungszeilen aus dem Merge-Prozess löschen wir.

Wir speichern die geänderte Datei dann ab; diese ist dadurch aber noch nicht in den Index des Branches aufgenommen. Aus Sicht des Views “Git Staging” ist der Konflikt somit noch nicht behoben; eine Aktualisierung F5 hilft nichts und auch ein “Commit” ist nicht möglich. Hier muss man vielmehr eine explizite Entscheidung zur Aufnahme der eben als künftiges Soll gespeicherten Version in den Index wählen; dies geschieht im Kontextmenü des Git-Staging-Views durch Auswahl des Punktes “Add to index“:

Danach ist ein Commit unserer neuen Dateiversion möglich:

Hinweis:
Alternativ zu einer direkten Arbeit im Editor ist auch das Arbeiten über das “Merge Tool”, das im wesentlichen einer Diff-Azeige mit Zusatzfunktionen entspricht, möglich. Das mag jeder mal selber ausprobieren.

Wir committen und mergen danach in ähnlicher Weise den Branch “php-extension” in den Branch “consolidation”. Dabei entscheiden wir uns für den Wert von “$a=20” aus “php-extensions”.

Zwischenzeitlich können wir immer mal den Zustand des jeweils aktiven Branches im
View “History” begutachten (zur Sicherheit dort F5 drücken):

Bei mir sieht das so kompliziert aus, weil ich in den anderen Branches bereits früher Änderungen durchgeführt hatte. Der “consolidation”-Branch wurde ja aus dem Master-Branch im Zustand “a54a2b7” erzeugt; seine “Vergangenheit” davor ist mit der des Master-Branches identisch.

Durch Klicken des rechten Branch-Symbols oben rechts in der Icon-Leiste dieses Views erhält man übrigens eine graphische Ansicht aller vorhandenen Branches. Es gibt in dieser Icon-Leiste noch weitere interessante Möglichkeiten, deren Studieren sich lohnt. Interessant ist ferner das Markieren zweier Versionen aus dieser Ansicht, die man dann per Kontext-Menü direkt in einer “Compare”-Ansicht öffnen und vergleichen kann.

Schließlich mergen wir noch den “consolidation”-Branch in den Master-Branch und übernehmen dabei den Wert des “consolidation”-Branches. Wir erhalten am Ende eine recht komplex wirkende Branch-Historie; im oberen Bereich sind die hier angesprochenen Änderungen mit den Hash-Nummern “fc53e0e, d3995ff, a262600, b999a78, df23e87, fb258ff, f48c829” zu sehen:

Hinweis zu sog. “Fast Forward Branches”:

In unserem Beispiel zu Branching haben wir gezielt Konflikte provoziert, die bei den verschiedenen Merges manuell beseitigt werden mussten. In vielen Fällen erfolgen aber Code-Änderungen z.B. durch Hinzufügen von Code-Fragmenten oder durch Code-Änderungen, die nicht in Konflikt mit der letzten gemeinsamen Version von zwei Branches stehen, wenn im Zielbranch an dem betroffenen Codesegment seit der Verzweigung nichts geändert wurde. Entsprechende Änderungen haben eine eindeutige logische Historie und können in Form sog. einfacher “Fast Forward Merges” [FFM] abgewickelt werden: EGit übernimmt die Änderungen dann einfach automatisch in die Target-Datei; ein manuelles Eingreifen ist nicht nötig. Ein “FFM” wird in einem Zwischendialog nach dem Mergeversuch angekündigt; das Merge-Popup (s.o.) erlaubt spezielle Einstellungen für FFMs.
Da Git aber nicht die Semantik der Änderungen überprüfen kann, muss man auf der Basis vorhergehender Codevergleiche natürlich auch im Fall von FFMs sicher sein, dass man mit der direkten Übernahme der Änderungen keinen Unsinn anrichtet. Das Denken nimmt einem Git nicht ab.

Andere Tools

Später werden wir zur Überwachung und ggf. Manipulation zentraler (!) Repositories auf den jeweiligen Servern (grafische) Tools installieren müssen, die unabhängig von Eclipse und EGit funktionieren. In Frage kommen aus dem Opensource Umfeld etwa:

GitGui (wird mit dem Git-Paket ausgeliefert; wirkt wegen Tcl/Tk etwas hausbacken, Graphen; umfangreicher Satz von Werkzeugen zur Repository-Pflege), Git Cola (Graphen; nützliche Funktionen zur Manipulation des Repositories), QGit (Graphen und einige einfache Manipulationsbefehle), GitG (web-ähnliche Oberfläche) sowie Giggle (Graph und Klon-Funktion). Die zugehörigen Pakete lassen sich für die jeweilige Linux-Distribution relativ einfach finden und installieren; ich gehe hier nicht darauf ein.

Alle genannten Tools erlauben eine Anzeige der vorhandenen Branches, ihrer Knoten und zumindest von Versions-Differenzen eines ausgewählten Knotens zur Vorgängerversion. Der Umfang an Funktionalitäten zur Pflege/Manipulation des Repositories ist unterschiedlich; hervorzuheben sind hier “Git
GUI” und “Cola Git”. Für eine einfache Graphenanzeige genügen GitG, QGit und Giggle.
Ich zeige abschließend den oberen Teil der Graphen in GitGui (gitk-Ansicht), QGit, Giggle, Cola-Git (DAG). Das ist alles recht ähnlich; die DAG-Ansicht finde ich eher verwirrend – hier wird die Logik zu stark komprimiert. Cola-Git bietet alternativ aber auch die gitk-Ansichten von GitGui.

GitGUI

QGit

Giggle

Cola-Git (DAG-Ansicht)

In GitG, GitGui, Cola Git (gitk) kann man zwischen einer rein chronologischen und einer topologisch-logischen Graphendarstellung wählen. Eine rein chronologische Darstellung hilft in einen komplizierten Situationen die Historie zu rekonstruieren.

Fazit

Das EGit-Plugin für Eclipse bietet einige hübsche Features an, um die Historie von Änderungen zu verfolgen. Wir haben in diesem Artikel allerdings nur an der Oberfläche gekratzt. Der Leser ist aufgerufen, weitere Möglichkeiten zu erkunden. Zumindest für ein lokales Repository werden dabei kaum Wünsche offen gelassen. Auch die Graphendarstellung für einzelne Branches im History-View braucht sich nicht zu verstecken. Die Knoten sind chronologisch geordnet – und neben jedem Knoten wird in einer separaten Spalte der zugehörige verkürzte Hash angezeigt. Das bietet komischerweise keines der anderen Tools an.

Die Funktionalitäten von EGit kann man übrigens auch in einer von Eclipse unabhängigen Form genießen. Hierzu lädt man sich die entsprechende Anwendung “GitEye” der Fa. CollabNet (s. https://www.collab.net/downloads/giteye) für Linux herunter. Das Archiv einfach expandieren und GitEye starten.

Im Vorgriff auf ein Monitoring und eine direkte Verfolgung von Änderungen eines zentralen Git-Repositories auf einem entfernten Host haben wir einen kurzen Blick auf andere Tools geworfen, die sich ebenfalls leicht installieren lassen und wie EGit eine grafische Aufbereitung bieten. Auch hier gilt es, sich mit den Möglichkeiten und Grenzen der Tools vertraut zu machen.

Im nächsten Artikel dieser Serie
Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – IV
verfolgen wir allerdings die im ersten Artikel gesetzten Ziele weiter. U.a. werden wir ein zentrales Repository auf einem Host im LAN anlegen und auch dieses Repository mit Push-Befehlen auf einen aktuellen Stand bringen. Parallel werden wir uns die durchgeführten Änderungen auf dem zentralen Tool über QGit ansehen. Das entspricht den Aufgaben 5 -7 des ersten Artikels.

Remote Desktop für Debian 8 mit X2Go auf Strato-V-Servern

Posted on by

In unserer Firma fallen z.Z. mehrere technische Schritte an, die wir parallel abwickeln müssen:

So stellen wir einerseits zwei Opensuse-Leap-Server für einen Kunden auf Debian-8-basierte vServer beim Hoster Strato um. Zeitgleich ersetzen wir das von uns unter Eclipse genutzte Versionsverwaltungssystem SVN durch Git und binden u.a. auch dabei einen der gehosteten vServer ein.

Damit wir und unser Kunde auf dem vServer

  • das dortige Git-Server-Repository besser kontrollieren und verfolgen können,
  • gelegentlich Branches anlegen und Merge-Aktionen durchführen können,

sollen auf dem vServer auch graphische GIT-Frontends zum Einsatz kommen. Z.B. “cola-git”, “qgit”, “giggle”. Ziel ist u.a. die Ansicht solcher Graphen wie in der nachfolgenden Abbildung:

Obwohl die Anwendung am Server läuft, wollen wir den Output natürlich auf dem Desktop unserer Arbeitsplatz-PCs oder denen des Kunden ansehen können.

So stellte sich uns also die Frage, wie man am schnellsten zu einem performanten graphischen Remote-Desktop für ein gehostetes “headless” System, also für ein System ohne echte eigene Grafik-Ressourcen, kommt. In unserem Fall zeigte sich, dass X2GO die richtige Wahl war und ist.

Nomenklatur – Remote Hosts, X-Server, X-Clients

Wir verwenden im weiteren Text die nachfolgende Nomenklatur, um Missverständnisse zu vermeiden. Bekanntermaßen ist ja beim X11-Protokoll die laufende Grafik-Anwendung ein “X-Client”. Das Umsetzungsprogramm, das aus den Grafik-Befehlen des Clients schließlich Fenster und grafische Inhalte auf den Bildschirm eines Linux-Desktops oder oder die Grafikstation eines Thin Client zaubert, ist hingegen der “X-Server”.

Die zuständigen Protokolle für den Datenaustausch zwischen X-Client und X-Server funktionieren auch über Netzwerke hinweg:

  • Als “Remote-Host” bezeichne ich den vServer bei Strato. Dort laufen dann Linux-Anwendungen, die grafischen Output im Rahmen ihres Benutzerinterfaces anbieten (in unserem Beispiel GIT-Anwendungen mit GUI).
  • Das Linux-System, von dem aus wir auf den vServer zugreifen, nenne ich “Arbeitsplatz-PC” oder kurz “PC”. Auf ihm läuft unter Linux selbstverständlich auch ein lokaler X-Server. Dieser dient wiederum einem Linux-Desktop – in meinem Fall KDE 5 – als technische Basis für die Integration grafischer Benutzerschnittstellen zu lokalen und entfernten Anwendungen.
  • Die graphischen Programme wie “qgit”, die auf dem vServer (=Remote-Host) laufen und ihren Output wie grafische Anweisungen einem lokalen oder über das Internet auch einem entfernten X-Server zuweisen, nennen wir “Remote X-Clients”.

Bzgl. möglicher Lösungen für Remote-Desktop-Darstellungen auf einem Arbeitsplatz-PC ist es nicht von vornherein klar, wo und in welcher Form ein X-Server zum Einsatz kommt. Natürlich läuft auf einem normalen Linux-PC ein X-Server für eine grafische Oberfläche; das schließt aber nicht aus, dass auch auf dem Remote-System ein X-Server aktiv ist.

Ein Remote-X-Client-Programm könnte also einerseits mit einem (headless) X-Server auf dem Remote-Host zusammenarbeiten. Er könnte andererseits aber auch direkt mit dem X-Server am Arbeitsplatz-PC über das Internet interagieren (z.B. über ssh -X oder die explizite Vorgabe eines entfernten X-Servers samt Screen über die Umgebungsvariable “DISPLAY”).

Funktionsweise von VNC vs. X2Go

Der Vollständigkeit halber werfen wir deshalb auch einen kurzen Blick auf Unterschiede in der typischen Funktionsweise von VNC und X2Go. Man beachte, dass in beiden Fällen “Server”-Komponenten auf dem Remote-Host und “Client”-Komponenten auf dem Arbeitsplatz-PC zum Einsatz kommen; das ist gerade umgekehrt wie bei den X11-Komponenten:

  • VNC: Auf dem Remote-Host kann theoretisch ein headless X-Server laufen, für dessen Implementierung ggf. die zu installierende Remote-Desktop-Umgebung (wie etwa ein VNC-Server-Modul) sorgen muss. Dessen Bilddaten-Output könnten dann über ein VNC-Programm abgegriffen und über das Internet an einen Arbeitsplatz-PC bei uns übertragen werden. Dort greift dann ein VNC-Client-Programm die Daten auf und blendet sie als lokaler X-Client über ein passendes Fenster in den grafischen Linux-Desktops des PCs ein.
  • X2Go: Unter X2Go läuft auf dem Remote-Host der sog. “X2Go-Server”. Der nutzt essentielle Teile des X11-Protokolls um Daten und Grafikanweisungen an den X-Server eines Arbeitsplatz-PCs zu übertragen. Dort koppelt allerdings ein zwischengeschalteter “X2Go-Client” an den X11-Server des Arbeitsplatz-PCs an. (Unter Windows Clients ist ein geeigneter X11-Server bereitzustellen!). Im Unterschied zu ” ssh -X” oder einem direkten Remote Zugriff auf einen X11-Server werden von den zwischengeschalteten X2Go-Komponenten zusätzlich Kompressionsalgorithmen und Caches exzessiv genutzt und der Statusabgleich zwischen X11-Server und X11-Client auf das notwendige Minimum reduziert.

In beiden Fällen müssen die VNC- oder X2Go-Client-Komponenten natürlich die Keyboard- und Mausinteraktionen mit den relevanten Fenstern am Arbeitsplatz-PC abfangen und an die X-Clients auf dem Remote-Host übertragen.

Ich gehe nachfolgend von klassischen X-Servern (und nicht Wayland) aus. Wayland ist meines Wissens nicht mit X2Go kompatibel.

SSH -X als Alternative ?

Natürlich habe ich auf unserem Strato-vServer erstmal eine direkte grafische Datenübertragung zwischen den X-Clients der vServer und meinem Arbeitsplatz-PC mittels “ssh -X” ausprobiert. Dabei wird der Grafik-Output der X-Remote-Clients (über das zwischengeschaltete Internet) direkt vom X-Server am Arbeitsplatz-PC behandelt. Aber Qgit, Giggle und Co. sind doch schon recht komplexe Anwendungen, die mit einem X-Server relativ häufig relativ viele Informationen austauschen müssen.

Ich war mit der Performance überhaupt nicht zufrieden. Das Arbeiten an sich erwies sich zwar nicht als unmöglich; aber bei verschiedenen Schritten treten doch spürbare Wartezeiten auf – u.a. beim Aufbau von Verzeichnis- und Strukturbäumen. Die Durchführung von Änderungen war dann nicht wirklich bequem, sprich nicht flüssig möglich. Mein Eindruck war: Es wird eine deutlich bessere Kompression und Pufferung der Daten benötigt.

Probleme mit VNC – und Einschränkungen bzgl. der Desktop-Umgebung

Ich dachte als Nächstes natürlich an klassische VNC-Anwendungen (https://de.wikipedia.org/ wiki/ Virtual_Network_Computing), mit deren Hilfe man einen echten Remote-Desktop realisiert.

In LANs hatte ich früher schon mal TurboVNC eingesetzt. Ich hatte das damals als recht performant empfunden. Sogar der Einsatz von VirtualGL für Remote-Hosts, die mit einer 3D-Grafik-Karte ausgestattet waren, war möglich. Nun braucht man für einen Strato vServer und GIT-Frontends natürlich kein VirtualGL. Aber TurboVNC war ja auch sonst ganz OK – zumindest unter älteren Opensuse-Systemen.

Dennoch habe ich den Einsatz von TurboVNC auf einem Strato-vServer mit Debian nach ein paar Experimenten abgebrochen. Unter Debian 8 gab es (fast erwartungsgemäß) Probleme mit Gnome 3 (trotz vorhandener Mesa-Bibliotheken). Gnome 3 ist (wie KDE 5 auch) von Haus aus für VNC problematisch, da 3D-Fähigkeiten der Umgebung vorausgesetzt werden. Bei mir klappte der Start des Desktops trotz vorhandener Mesa-Bibliotheken und des lokalen VMware-Grafiktreibers des Virtuozzo-Containers für den Strato-vServer nicht.

Auch eine kurze Recherche im Internet zeigte: Der Einsatz von Gnome erfordert unter klassischen VNC-Servern (und auch unter TurboVNC) einfach viel zu viele Klimmzüge. Wie funktionabel und performant dagegen der in Gnome integrierte VNC-Server “vino” ist, habe ich in meinem Frust dann nicht mehr ausprobiert.

KDE 4 unter Debian 8 ging zwar unter TurboVNC; ich bekam aber keine Veränderung der Auflösung jenseits 1024x768px am TurboVNC-Client auf dem Arbeitsplatz-System hin. Der Zeitaufwand für das Rumprobieren wurde mir dann irgendwann zu groß. Das hatte zwei Konsequenzen:

  • Als erstes reduzierte ich meine Anforderungen an eine Desktop-Umgebung kurzentschlossen auf LXDE und KDE4. Mit letzterem kennt sich auch unser Kunde in hinreichendem Maße aus.
  • Als zweites konzentrierte ich mich auf die von Debian im Standardumfang mitgelieferten VNC-Pakete: “tightvnc” und “vnc4server”.

Ein Kurztest der beiden VNC-Varianten überzeugte mich aber hinsichtlich der Performance mit KDE 4 nicht; besonders nicht der vnc4server. Mit LXDE konnte ich dagegen ganz gut arbeiten.

KDE 4 ist halt ein Desktop-Schwergewicht, das den X11-Server je nach Desktop-Gestaltung laufend belastet. Dabei ist zu bedenken, dass die meisten VNC-Systeme auf dem Remote-Linux-System einen laufenden (headless) X11-Server brauchen, dessen Bilddaten dann abgegriffen und an einen VNC-Client auf einem lokalen PC übertragen werden. Das ist vom logischen Prozess-Ablauf her gesehen ein Umweg, weil neben dem X11-Server noch eine Zwischenschicht auf dem Remote-System ausgeführt werden muss. Die Bilddaten auf dem lokalen PC müssen zudem wieder in einem Fenster auf dem lokalen X11-Server dargestellt werden.

X2Go als Alternative ?

Wenn es denn hinreichend schnell funktionieren würde, würde man deshalb als Linuxer eigentlich immer gerne direkt Remote-X11 über SSH einsetzen. Auf dem Remote-System – hier also dem vServer – liefen dann Anwendungen, die als X-Window-Client-Programme ihre Daten und graphischen Steuerbefehle (über einen SSH-Tunnel) direkt an den aktuell laufenden X11-Server auf meinem Arbeitsplatz-PC übertragen. In unserem LAN klappt das auch wunderbar – sogar mit der Übertragung von 3D-Grafik-Daten. Da reicht die Bandbreite schon in einem Gigabit-Netz zur schnellen Datenübertragung völlig aus. Das gilt aber leider nicht unbedingt für Remote-Systeme im Internet zu denen die Bandbreite in beide Richtungen begrenzt ist. (Zumindest bei mir).

Dann fiel mir ein: Eine hinsichtlich Kompression, Caching und X11-Server/Client-Abgleich optimierte Variante des X11-Protokolls über ein Netzwerkverbindungen lieferte doch das NX3-Nomachine-Protokoll; es bildet die Grundlage des Opensource Forks X2Go (siehe hierzu die Links weiter unten).

Ergebnis eines kurzen X2Go-Tests

Am Ostersamstag habe ich mir dann nach ein wenig Internet-Recherche (und zum Leidwesen meiner Frau) auch den X2Go-Server und X2Go-Client angesehen. Ergebnis: Ich bin nach wie vor begeistert! Stichpunkte sind:

  • Denkbar einfache Installation und Konfiguration. Einfache Integration von SSH-Schlüsseln. Einfache Einstellung unterschiedlicher Auflösungen.
  • Sehr gute, wirklich überzeugende Performanz!
  • Der Datenaustausch zwischen Remote-System und dem Arbeitsplatz-PC erfolgt von vornherein auf SSH-Basis.

Weitere erwähnenswerte Features, die die praktische Nutzung erleichtern, sind:

  • Copy/Paste zwischen nativen lokalen Fenstern des Arbeitsplatz-PCs und Fenstern des Remote-Desktops ist nahtlos möglich.
  • Freigabe lokaler Verzeichnisse: X2Go erlaubt vom Remote-Desktop aus auch einen Zugriff auf (dafür freigegebene) lokale Verzeichnispfade des Arbeitsplatz-PCs. Damit können Files auf dem Remote-Host z.B. in einem graphischen File-Manager zwischen den dortigen Verzeichnissen (des Hosts) und dem lokalen Verzeichnis des Arbeitsplatz-PCs verschoben/kopiert werden. Zur Wahrung der Sicherheit bei solchen Transaktionen gibt es die Option, den Datenaustausch über SSH getunnelt durchzuführen.
  • Mehrere Sitzungen gleichzeitig: Will man mehrere Sitzungen zu verschiedenen Servern gleichzeitig öffnen, so startet man auf dem lokalen PC mit “x2goclient &” einfach einen neuen Client. Auch zwei Sitzungen unter unterschiedlichen Benutzernamen zum gleichen Server sind möglich. Ebenso zwei Sitzungen mit derselben Remote-UID für verschiedene Desktops/Window-Manager – z.B. eine Sitzung mit LXDE und eine mit KDE für ein und denselben User auf demselben Remote-Host. X2Go-Client zeigt einem eine Liste laufender Sitzungen und fragt, was mit den laufenden Sitzungen passieren soll. Die lässt man weiterlaufen und wählt für die neue Sitzung die Option “Neu”. Die verschiedenen Remote-Sitzungen zum gleichen Remote-Host teilen sich dann aber natürlich dessen Netzwerk-Ressourcen. Die sind bei Stratos vServern durchaus begrenzt.
  • Seamless Mode: X2Go erlaubt anstelle der Anzeige eines kompletten Remote-Desktops theoretisch auch das Remote-Starten einer einzelnen Anwendung und deren Anzeige auf dem lokalen Desktop des Arbeitsplatz-PCs. (Seamless Mode; das Ganze entspricht dann in der klassischen SSH-Welt in etwa dem vorkonfigurierten Aufruf einer grafischen Remote-Applikation nach einem ssh -X.). Leider klappt das aber auf einem KDE5-Plasma-Desktop (s.u.) nicht wie erwartet.
  • Desktop-Sharing: X2Go bietet auch die Möglichkeit des Desktop-Sharings zwischen verschiedenen Nutzern an – das habe ich aber unter den Bedingungen eines vServers aber noch nicht ausprobiert. Ich gehe darauf in diesem Artikel auch nicht weiter ein.

Mit jedem dieser Punkte kann ja jeder mal selber herumexperimentieren. Siehe zur Thematik paralleler Sitzungen auch
https://gist.github.com/ ledeuns/ f0612fb43b967c129c88)

Bzgl. des Desktop-Sharings:
http://wiki.x2go.org/ doku.php/ doc:usage:desktop-sharing

Arbeitet man gleichzeitig unter derselben UID mit 2 getrennten Sessions – z.B. einer LXDE- und einer KDE-Sitzung – auf demselben Arbeitsplatz-PC, so können dabei interessante Effekte z.B. unter Libreoffice auftreten: Ist Libreoffice bereits auf einem der (Remote-)Desktops (z.B. dem KDE-Desktop) geöffnet, so wird ein nachfolgendes Libreoffice-Programm, das in einer parallel laufenden LXDE-Sitzung gestartet wird, trotzdem im KDE-Desktop angezeigt. Ansonsten läuft das Meiste aber normal und erwartungsgemäß.

Für mich war wirklich überraschend, dass neben meinen Git-GUIs auch stark grafiklastige Anwendungen wie Libre-Office Draw, Impress, Inkscape etc. gleichzeitig und sehr, sehr flüssig nutzbar waren. Aus meiner Sicht ist hier die Performance eines Terminal-Servers gegeben, die im wesentlichen nur durch die Netzanbindung des vServers ans Internet limitiert wird und im getesteten Umfang (4 parallele 1920×1200 Sitzungen) überhaupt nicht durch CPU/RAM des Virtuozzo Containers für unseren vServer [V30 bzw. V40, HP3PAR] begrenzt wurde.

Weil es so schön ist, nun eine Zusammenstellung der wichtigsten Hinweise zur Installation und Inbetriebnahme von X2Go, die ich bei dieser Gelegenheit im Internet aufgesammelt habe.

X2Go-Installation: Passende Repositories ziehen

Unter folgendem Link ist beschrieben, wo man die aktuellen Repositories mit X2Go-Komponenten für Debian 8 (64Bit) findet: http://wiki.x2go.org/ doku.php/ wiki:repositories:debian.

Man trägt dann die Repositories über folgende Zusatzzeilen in die Datei “/etc/apt/sources.list” ein: 

root@myremotedebian:~# cat /etc/apt/sources.list
# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.
deb ftp://ftp.stratoserver.net/pub/linux/debian/ jessie main contrib non-free
deb ftp://ftp.stratoserver.net/pub/linux/debian-security/ jessie/updates main contrib non-free

#ICH - 15.04.2017 - Repos for X2Go:
# -----------------------------------
#X2Go Repo
deb http://packages.x2go.org/debian jessie main
# X2Go Repository (sources of release builds)
deb-src http://packages.x2go.org/debian jessie main

Zur Sicherheit machen wir den zugehörigen Key verfügbar; als root: 

root@myremotedebian:~ # apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E

Dann Update der Paket-Datenbank durchführen: 

root@myremotedebian:~ # apt-get update

Nun – als Test – Installieren des Schlüssels über ein Paket aus dem X2Go-Repository: 

root@myremotedebian:~ #  apt-get install x2go-keyring && apt-get update

Dann die Pakete x2goserver und x2goserver-xsession installieren: 

root@myremotedebian:~ #  apt-get install x2goserver

Bei mir wurde x2goserver-xsession automatisch mit installiert. Falls das nicht der Fall sein sollte: 

root@myremotedebian:~ #  apt-get install x2goserver-xsession

Man glaubt es vielleicht nicht – aber das war es im Prinzip serverseitig schon. Zumindest was X2Go anbelangt. Der Grund hierfür ist, dass der X2GO-Client (s.u.) eine SSH-Sitzung nutzt und im Zuge des SSH-Logins die nötigen Umgebungsvariablen setzt und erforderliche Programme auf dem Server für eine Remote-X-Sitzung startet.

LXDE und KDE 4 installieren

Sollte man LXDE oder KDE 4 unter Debian 8 noch nicht installiert haben, so ist dies über 

root@myremotedebian:~ #  apt-get install lxde

bzw.

root@myremotedebian:~ #  apt-get install kde-standard

möglich.

Will man Remote-Audio nutzen, sollte man ggf. auf dem Remote-Host und auch auf dem Arbeitsplatz-PC Pulseaudio installieren. Für mich ist Sound irrelevant – und Pulseaudio kommt bei mir aus Prinzip nicht auf einen PC-Desktop. Aber das mag ja bei anderen anders sein … 🙂

Natürlich muss auf beiden Systemen SSH bereitstehen ..

Auf dem Debian 8 Remote-Host muss zwingend das Paket “openssh-server” installiert sein. Zudem sollte der Server aus Sicherheitsgründen so konfiguriert sein, dass der SSH-Port verlagert ist, sichere Kex-Algorithmen genutzt und eine Authentifizierung über asymmetrische Keys (hinreichender Länge) durchgeführt wird. Der Zugang sollte ferner durch eine Firewall und weitere Maßnahmen auf bestimmte Clients beschränkt werden. Ich gehe auf die SSH-Server-Konfiguration hier nicht weiter ein. Da wir es hier mit gehosteten Remote-Systemen zu tun haben, gehe ich davon aus, dass der zuständige Admin dieses Metier beherrscht.

Jedenfalls muss auf dem Server ein SSHD-Dämon laufen und bereit sein, Logins über einen in der Firewall für bestimmte Clients geöffneten Port entgegen zu nehmen. X2Go tunnelt später die gesamte Kommunikation zwischen Client und Server durch die SSH-Verbindung. Darum muss man sich nicht mehr selber kümmern; s.u.. Es ist übrigens nicht notwendig, für verschiedene Sitzungen auf ein und demselben Remote-Host mehrere unterschiedliche SSH-Ports zu öffnen.

Installation und Nutzung auf dem Arbeitsplatz-PC (X2Go-Client)

Bzgl. der Client-Installation gilt: Es sind passende Pakete für die Distribution zu finden, die man auf seinem Arbeitsplatz-PC einsetzt. Siehe für Hinweise
http://wiki.x2go.org/ doku.php/ doc:installation: x2goclient.

Ich beschreibe die Clientseite hier nur für einen Opensuse Leap 42.2 Client. Für Opensuse liegen die erforderlichen RPMs unter folgendem Repository:
repositories/X11:/RemoteDesktop:/ x2go/openSUSE_Leap_42.2/
Von dort installiert man mittels YaST etwa “x2goclient”, “pyhoca-gui”. Der Rest der benötigten Pakete wird dann über Abhängigkeiten nachgezogen:

Nun öffnet man auf seinem Client-PC den Client am Terminal etwa über: 

ich@mytux:~> x2goclient &

Es öffnet sich initial eine Oberfläche, die die Anlage von sog. “Sitzungen” zu Remote-Hosts erlaubt; diese “Sitzungsvarianten” werden später im X2Go-Client-Fenster zur Auswahl angeboten.

Ich zeige nachfolgende die verschiedenen Konfigurationsdialoge für eine Sitzung (die ich “Dummy” genannt habe). Natürlich muss man die Eingabefelder mit den für seine eigene Situation passenden Daten ausfüllen.
Siehe für eine ausführliche Beschreibung des X2Go-Client-Setups zudem:
http://wiki.x2go.org/ doku.php/ doc:usage:x2goclient

Zunächst – und das ist das Wichtigste – müssen wir die Serververbindung einstellen:

Dann steht eine Konfiguration der Bandbreite der Verbindung an:

Wir wenden uns anschließend einer Konfiguration der Auflösung der Desktop-Darstellung zu:

Für erste Tests deaktivieren mal die Sound-Unterstützung:

Als letztes kann man konfigurieren, ob man bestimmte Verzeichnisse auf dem Arbeitsplatz-PCs für einen direkten Zugriff durch Remote_X-Client-Programme freigeben will. Tut man das, so sollte man in jedem Fall die zugehörige Option zur SSH-Port-Weiterleitung aktivieren.

Man kann all diese Konfigurationseinstellungen später über den Menüpunkt “Sitzung => Sitzungsverwaltung” nachbessern.

Resultate

Hat man seine “Sitzung” konfiguriert, so steht diese im rechten Bereich des X2Go-Client-Fensters zur Aktivierung bereit.

Nach einem Doppelklick rückt die aktivierte Verbindung ins Zentrum der Anzeige; in unserem Fall öfnnet sich zudem ein kleines Dialogfenster, in dem wir die Passphrase für unseren SSH-Key eingeben müssen. Und nach wenigen Augenblicken/Sekunden öffnet sich schließlich das Fenster für unseren Remote-Desktop – hier mit LXDE :

Der aufmerksame Betrachter wird Qgit im linken Bildbereich entdeckt haben – hier für ein noch sehr langweiliges Test-Repository. Ich habe fast alle mir unter Linux bekannten Git-Clients ausprobiert – jeder läuft flüssig; fast wie lokal.

Das Ganze nun auch nochmal für einen Remote-KDE-Desktop:

Für 2 parallele Sitzungen zum gleichen Server muss man einfach zwei x2go-Clients öffnen und in einer zwischenzeitlichen Anzeige bereits geöffneter Sessions die Optionen so wählen, dass die bereits geöffnete Sitzung nicht unterbrochen werden soll, sondern dass eine neue Sitzung geöffnet werden soll.

Die nachfolgende Abbildung zeigt zwei parallel zu einem vServer unter Debian 8 geöffnete Sitzungen – eine unter LXDE, die andere unter KDE4:

Getestet habe ich das Ganze mit einer vDSL-Leitung, aber auch einer ADSL-16MBit-Leitung – auch bei letzterer sind mehrere gleichzeitige Sitzungen kein Problem !

Wo so viel Licht ist, gibt es aber auch Schatten. Daher sei abschließend noch auf 2 Punkte hingewiesen, die in der Praxis relevant werden können.

Problematischer Punkt bzgl. der Soundunterstützung und Firefox unter X2Go

Im Prinzip kann X2Go (angeblich) Audio-Daten übertragen. Allerdings über einen Pulseaudio-Server. Den habe ich bei mir allerdings wegen vieler Probleme mit einer Xonar D2X und einer X-Fi nicht am Laufen. Ich benutze ausschließlich plain Alsa – das funktioniert zuverlässig und erlaubt das Umschiffen vieler Pulseaudio-Probleme. Fakt ist jedenfalls, dass es mit einer aktivierten Sound-Unterstützung für Pulseaudio unter X2Go und einem remote gestarteten Firefox ESR erhebliche Probleme gibt:

Alle Menüpunkte der Firefox-Oberfläche reagieren nicht mehr bzw. mit erheblicher (!) Zeitverzögerung auf Maus-Klicks im X2GO-Client. Firefox wirkt wie eingefroren; das stimmt aber nicht – die Reaktion kommt nur mit Minuten Verzögerung. Das ist u.a. hier beschrieben:
http://thescriptingadmin.blogspot.de/ 2015/09/ firefox-freezing-on-linux-x2go.html
https://debianforum.de/ forum/ viewtopic.php?t=164257

Wer immer daran Schuld hat. Da das mit anderen GTK-Anwendungen als FF nicht passiert, tippe ich darauf, dass FF bei installiertem PA auch erwartet, dass PA reagiert. Was remote evtl. ein Problem darstellt, wenn dort PA ggf. gar nicht installiert ist.

Ich habe mangels Interesse nicht getestet, ob dieser Fehler u.U. daran liegt, dass auf meinem Arbeitsplatz PA nicht aktiv ist. Lasst mir gerne eine Email zukommen, wenn ihr dazu was wisst. Ich persönlich verzichte aber lieber auf Sound von einer Remote-X2Go-Quelle, als mich mit PA herumzuschlagen. Vielleicht probiere ich das später mal auf einem Laptop. Falls ihr auch auf dieses Problem mit FF stoßen solltet und bereit seid, auf Sound vom X2go-Server zu verzichten, gilt Folgendes:

Wichtiger Hinweis zu einem Problem mit Firefox und dem X2Go-Client unter Linux:

Soundunterstützung im X2Go-Client abschalten (Reiter “Medien” unter den Einstellungen) oder aber auf einen anderen Soundserver umschalten. Bei mir funktionierte ein Remote-Firefox FF im X2Go-Desktop-Fenster nach einer Abschaltung der Soundunterstützung durch Pulseaudio problemfrei.

X2Go Seamless Mode funktioniert nicht unter KDE5

X2Go bietet zwar im Prinzip die Möglichkeit an, Remote X-Anwendungen auch als singuläre Applikationen zu starten, die direkt als Fenster (also ohne umgebenden Remote-Desktop) in den Desktop des Arbeitsplatz-PCs eingeblendet werden.

Hierzu konfiguriert man eine entsprechende Sitzung, z.B. nur für “qgit”, wie folgt:

Danach startet die angegebene Applikation im seamless Fenstermode. Das klappt auch mit einem Terminal wie etwa “lxterminal” (“/usr/bin/lxterminal”). Von der Kommandozeile aus, kann man dann weitere Anwendungen wie “qgit” starten, die dann wiederum als Einzelapplikation auf dem lokalen Desktop angezeigt werden.

Leider täuscht aber der erste positive Eindruck; unter KDE5 sind die zugehörigen Fenster für komplexere Anwendungen als ein Terminal in ihrer Größe leider nicht veränderbar. Das macht den Einsatz des “Seamless Mode” für KDE5 am Arbeitsplatz-PC in der Praxis unbrauchbar. Der seamless Mode funktioniert aber sehr wohl unter einem LXDE-Desktop am Arbeitsplatz-PC.

Fazit

X2Go bietet eine einfache zu handhabende Möglichkeit, performant von einem Linux-Arbeitsplatz-PC auf grafische Anwendungen eines Remote-Strato-vServers zuzugreifen. Die Linux-Installation des vServers muss lediglich einen LXDE- oder KDE4-Desktop unterstützen. (Desktops unter XFCE, Mate, LXQT habe ich nicht getestet; das sollte aber auch alles funktionieren).

Als einzige Wermutstropfen bleiben, dass der Seamless Mode auf einem KDE5-Target-Desktop des Arbeitsplatz-PCs nicht richtig funktioniert und dass im Moment weder native KDE5- noch Gnome3-Desktops des vServers unterstützt werden. Angeblich wird daran aber bereits von den X2Go-Entwicklern gearbeitet; wir freuen uns auf entsprechende neue X2Go-Versionen.

Links

Was ist X2GO?
http://www.mn.uio.no/geo/ english/services/it/help/ using-linux/x2go.html
https://de.wikipedia.org/ wiki/ NX_NoMachine
http://xmodulo.com/x2go-remote-desktop-linux.html
https://serverfault.com/ questions/227542/ what-alternatives-to-vnc-are-there-for-linux

Details zum Server
http://wiki.x2go.org/doku.php/wiki: advanced: x2goserver-in-detail

Installation von X2Go
http://wiki.x2go.org/doku.php/ wiki:repositories:debian
https://www.sugar-camp.com/x2go-vorstellung-und-installationsanleitung/
http://wiki.x2go.org/ doku.php/ doc:installation:x2goserver
http://www.linux-community.de/Internal/Artikel/ Print-Artikel/LinuxUser/2011/07/X2go-Terminalserver-auch-fuer-den-Hausgebrauch
http://xmodulo.com/x2go-remote-desktop-linux.html
https://mun-steiner.de/ wordpress/ index.php/ linux/ x2go-mit-ssh/
https://wiki.archlinux.de/title/X2go

Installation und Übersicht über ein paar Bugs
http://www.mn.uio.no/geo/english/ services/it/help/ using-linux/x2go.html

VNC : Benötigt VNC einen X-Server?
https://unix.stackexchange.com/ questions/ 129432/vnc-server-without-x-window-system

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – II

Posted on by

Im letzten Blog-Post

Erste Schritte mit Git für lokale und zentrale Repositories unter Eclipse – I

hatte ich ein einfaches Szenario beschrieben, das regelmäßige Wechsel zwischen mobiler und ortsgebundener Entwicklungsarbeit beinhaltet und gerade im Leben von Freiberuflern immer wieder auftritt. Versionskontrolle erfordert im Zuge solcher Wechsel das Arbeiten mit lokalen und zentralen Repositories sowie systematische Abgleichoperationen zwischen solchen Repositories. Git ist für derartige Szenarien gut geeignet. Um entsprechende Experimente durchführen zu können, haben wir im letzten Post unser einfaches Wunschszenario in durchzuführende logische Schritten untergliedert.

Unser Ziel ist nun eine Abbildung der identifizierten Schritte in eine Git-Versionsverwaltung unter der IDE Eclipse. Daraus ergaben sich konkrete Aufgabenstellungen für Tests. In diesem Post befassen wir uns mit den ersten drei der identifizierten Aufgaben:

  • Aufgabe 1: Erstellen eines lokalen Git-Repositories auf dem PC.
  • Aufgabe 2: Klärung: Wo liegt der “Working Tree”? Welchen Verzeichnisbaum zeigt Eclipse?
  • Aufgabe 3: Einbringen des Inhalts des Projektverzeichnisbaums in den Master-Branch des lokalen Repositories. Initiales Commit.

Ich setze für das Verständnis der nachfolgenden Ausführungen einige Begrifflichkeiten voraus, die ich im letzten Blog-Post dieser Serie erläutert habe. Da es sich hier um einen Linux-Blog handelt beschreibe ich alle Schritte zur Lösung der Aufgaben für eine Linux/Eclipse-Umgebung, Linux-Verzeichnisbäume und, soweit erforderlich, Linux-Shell-Kommandos. Vermutlich lässt sich das Meiste aber auch direkt auf eine MS-Umgebung übertragen.

Abgrenzung “Eclipse Workspace” versus “Git Workspace”

In deutschsprachigen Büchern zu Git ist oft die Rede von einem (Git-) “Workspace”. Andererseits gibt es aber auch unter Eclipse “Workspaces”. Diese sollten wir im Folgenden begrifflich auseinanderhalten:

  • Eclipse Workspace: Ein Eclipse Workspace verwaltet eine Ansammlung von mehreren Projekten und zugehörige Dateien in projektspezifischen Verzeichnissen. Für den gesamten Eclipse Workspace können verschiedene grundlegende Eclipse-Eigenschaften (Settings) projektübergeordnet eingestellt werden. Ich kürze einen Eclipse-Workspace nachfolgend mit EWS ab. Ein EWS ist regelmäßig mit einem zugehörigen Verzeichnis verbunden. Das schließt aber definierte Links in weitere zugeordnete Verzeichnisse nicht aus. Im Besonderen müssen die Projektdateien nicht zwingend in einem Verzeichnis unterhalb des Workspace-Verzeichnisses beheimatet sein. Die EWS-spezifischen Eclipse-Einstellungen werden jedoch in versteckten Dateien/Unterverzeichnissen des EWS-Verzeichnisses hinterlegt. Solche speziellen Dateien/Verzeichnisse eines EWS wird man später nicht unbedingt in einem GIT-Repository erfassen wollen, da sie typischerweise Anweisungen beinhalten, die für eine Eclipse-Version spezifisch sind; ein abgleichender Transfer auf ein anderes System mit einer älteren Eclipse-Version könnte dann zu Problenmen auf der Eclipse-Ebene führen.
  • Git-Workspace: Ein Git-Workspace bezieht sich auf Dateien einer Verzeichnisstruktur, deren Änderungshistorie in einem Git-Repository im Sinne einer Versionierung aufgezeichnet und verwaltet wird. Ich kürze nachfolgend einen Git-Workspace mit GWS ab. Ein GWS besteht typischerweise aus einem reinen Repository-Bereich unterhalb eines speziellen Verzeichnisses “.git” und einem sog. “Working
    Tree    “, dessen Dateien eine definierte Code-Version auf einem Entwicklungs-“Branch” (-Zweig) beinhalten. Auf der Eclipse-Ebene entspricht der Working-Tree typischerweise der Verzeichnis-Struktur eines Projektes mit den dazu gehörigen aktuellen Code-Dateien.

Vorbereitende Schritte

Bevor wir uns an die Lösung unserer Aufgaben machen, müssen wir je nach Ausgangssituation ein paar vorbereitende Schritte treffen. Für diese und auch für nachfolgende Aktionen gilt:

Wir legen uns vorab immer eine Sicherheitskopie des gesamten EWS und ggf. auf Datei- oder Ordnerebene verlinkter anderer Eclipse Workspaces an. Ferner sichern wir vor Experimenten mit Dateien eines realen Projekts evtl. existierende SVN-Repositories, die mit diesem Projekt verbunden sein mögen.

Vorbereitender Schritt 0 – Git und das Eclipse EGit-Plugin installieren

Auf unserem Linux-PC installieren wir zunächst das für die jeweilige Distribution verfügbare Git-Paket. Wir erhalten damit u.a. auch Zugriff auf CLI-Kommandos, die im Zuge der Repository-Verwaltung eingesetzt werden können. Die Kenntnis solcher Kommandos ist übrigens nützlich, auch wenn man – wie ich – grafisch Bedien-Elemente einer IDE verwenden will. (Man kann unter Linux eine Git-basierte Versionsverwaltung von Projekten auch ausschließlich auf der Kommandozeile betreiben.) Wer Lust hat, kann neben Git selbst gleich auch noch die Pakete “gitg”, “Qgit”, “Giggle” und ggf. auch “git-cola” oder “cola-git” installieren. Jedes dieser Pakete bietet eine eigene unabhängig von Eclipse nutzbare GUI für Git mit mehr oder weniger Komfort und Funktionalität an.

Für Eclipse selbst gibt es ein Git-Plugin namens EGit (welches wiederum JGit benötigt). EGit sollte im Haupt- oder Update-Repository der jeweiligen Eclipse-Installation (hier Neon 3) in einer passenden Version verfügbar sein. Für den aktuellsten Stand greift man auf folgendes Eclipse-Repository zu: 

http://download.eclipse.org/egit/updates.

Von dort können wir EGit genauso wie andere Eclipse Plugins auch installieren. Je nachdem, ob man vor hat, später auch externe GitHub-Dienste zu nutzen und/oder Mylyn einzusetzen, kann die Installation weiterer Plugins von Interesse sein. Das folgende Bild zeigt, welche Git-bezogenen Pakete ich selbst unter einem aktuellen Eclipse Neon 3 installiert habe:

Ich gehe auf die relativ trivialen Installationsschritte unter Linux/Eclipse nicht näher ein. Siehe bei Bedarf aber:
http://www.vogella.com/ tutorials/ EclipseGit /article.html #installation-of-git-support-into-eclipse
https://www.eclipse.org/ forums/ index.php/ t/273443/

Vorbereitender Schritt 1 – Lösen eines PHP-Projektes von seiner SVN-Anbindung

Das nachfolgende Bild zeigt die relativ simple Verzeichnis und Projektstruktur eines EWS namens “ecl_alienx”; das zugehörige Verzeichnis auf dem Linux-PC ist “/projekte/ecl_alienx”.

Das dortige Test-Projekt “alien1” und seine Verzeichnisse/Dateien sind unterhalb des Ordners “/projekte/ecl_alienx/alien1” beheimatet. Eclipse-Puristen würden diese Ortswahl für die Programmdateien mit einiger Berechtigung kritisieren. Das ist uns hier aber egal; es wird sich sowieso gleich ändern.

Den Bildinformationen entnehmen wir: Das Projekt ist offenbar noch mit einem Subversion-SVN-Repository verbunden. Wir lösen diese SVN-Verbindung nun über den Disconnect-Befehl, den wir unter dem Kontexmenüs des Projektes finden: => “Team => Disconnect”.

Dabei löschen wir auch die SVN-Metainformation in den “.svn”-Dateien jedes Projekt-Verzeichnisses. Das ist zwar nicht zwingend erforderlich; ich möchte bei den nachfolgenden Git-Experimenten aber keinen SVN-Ballast mit mir rumschleppen. (Das SVN-Repository selbst wird bei dieser Aktion übrigens nicht gelöscht).

Unser Projekt ist jetzt unbelastet von jeglicher Versionsverwaltung.

Für die weiteren Schritte lohnt es sich, den View “Git Repositories” (z.B. im unteren Bereich des Eclipse Desktops) permanent geöffnet zu halten. Dieser View ist anfänglich natürlich noch leer; bei späteren Git-Aktionen ist ein kontrollierender Blick in diesen View immer informativ und hilfreich. Öffnen kann man den View über den Eclipse Menüpunkt “Window => Show View => Others => Git => Git Repositories”.

Lösung der Aufgabe 1 – Erstellen eines lokalen Repositories

Als erstes erstellen wir mittels einer Shell oder einem Dateimanager außerhalb des EWS ein Verzeichnis für unseren künftigen GWS inkl. eines lokalen GIT-Repositories. In meinem Testfall etwa unter “/projekte/GIT/alien1“. Dann öffnen wir das Kontext-Menü unseres Projektes erneut und wählen den Punkt “Team => Share Project“:

Im nächsten Dialogfenster klicken wir auf den “Create“-Button und geben im nachfolgenden Subdialog den vorgesehenen Zielort des Repositories an:

Achtung:
Das Bild deutet bereits an, dass EGit deutlich mehr vor hat, als nur ein Git-Repository anzulegen. Vielmehr sollen alle Unterverzeichnisse unseres Projektes in eine Verzeichnisstruktur im Targetverzeichnis “/projekte/GIT/alien1” umgezogen werden. Wir werden gleich sehen, dass dadurch der sog. “Working Tree” unter dem Directory “/projekte/GIT/alien1/alien1/” im Workspace angelegt wird; der Working Tree besteht initial also aus den ursprünglichen Projekt-Verzeichnissen und -Dateien des EWS.

Im Targetverzeichnis “/projekte/GIT/alien1” wird parallel auch das eigentliche Git-Repository als Teil des GWS angelegt. Die erforderlichen Repository-Strukturen (Unter-Verzeichnisse für verschiedene Informationen, Object-Datenbanken mit Blobs, Indices, …) findet man anschließend in einem Verzeichnis “/projekte/GIT/alien1/.git“.

Hinweis: Ich würde an dieser Struktur des GWS nichts ändern!

  • Git erlaubt zwar grundsätzlich eine Trennung des Dachverzeichnisses
    für das “.git”-Repository-Verzeichnis vom Dachverzeichnisses für den “Working Tree”. Man kann dies etwa über CLI-Kommandos erzwingen. Nach meiner Erfahrung bringt eine solche separate Lagerung des Repositories und des Working-Trees an unterschiedlichen Orten EGit aber bei weiteren Aktionen außer Tritt. Also den Umzug der Verzeichnisstruktur an die angezeigten Position bitte zulassen!
  • Bitte achtet auch darauf, dass der Pfad zum künftigen “.git”-Verzeichnisses in eurem Dialog wirklich so ähnlich aussieht wie dargestellt. Man gerät durch Unachtsamkeit relativ schnell in eine Situation, in der man “.git” nachher unterhalb des Hauptverzeichnisses des Working Trees wiederfindet. Auch das ist technisch zwar zulässig, hätte später aber mehrere unangenehme Seiteneffekte, auf die ich an dieser Stelle nicht eingehen will. Also: Bitte darauf achten, dass das “.git”-Verzeichnis auf derselben Ebene der Verzeichnisstruktur platziert wird wie der zu erzeugende Working Tree. !

Jetzt klicken wir endlich auf den Button “Finish”; je nach Größe des bereits vorhandenen Projektverzeichnisses dauert das Verlagern der Dateien ggf. ein wenig. Schließlich sind aber sowohl das Repository unter dem Directory “.git” wie auch der Working Tree am vorgesehenen Bestimmungsort vorhanden.

>Lösung der Aufgabe 2 – Working Tree und Verzeichnisstruktur

Das Ergebnis sollte sich im PHP-Explorer bzw. im View “Git Reposiories” wie folgt darstellen:

Im unteren Teil sehen wir einen Ausschnitt des “Git Repository”-Views. Bereits hier erkennen wir deutlich den Aufbau unseres neuen GWS. Der Working Tree ist dort als solcher bezeichnet und sein Pfad ist angegeben. Ein Dateimanager bestätigt die gewünschte Verzeichnishierarchie:

Glückwunsch! Wir haben unser erstes Git-Repository samt Working Tree erstellt. Durch die Parametrierung bei der Erstellung des Repositorys und durch die beiden obigen Abbildungen haben wir neben Aufgabe 1 auch schon Aufgabe 2 gelöst.

Das Repository ist in diesem Zustand aber erst vorbereitet. Noch sind dort keine Inhalte oder Verionsobjekte angelegt ….

Git-Smart-Icon-Leiste aktivieren

Um nachfolgend etwas einfacher mit dem Repository und dem Commit neuer Dateien arbeiten zu können, beschaffen wir uns eine Smart-Icon-Leiste für Git-Operationen im Kopfbereich von Eclipse. Das erreichen wir in zwei Schritten:

  • Klick auf den Eclipse-Menüpunkt “Window => Perspective => Customize Perspective … “. Dort unter dem Reiter “Action Set Availability” die Punkte “Git” und “Git Navigation Actions” aktivieren.
     
  • Danach aktivieren wir unter dem Tab “Menu Visibility” den Punkt “Git”:
     

Als Ergebnis erhalten wir folgende Leiste:

>Lösung der Aufgabe 3 – Master-Branch und initiales Commit

Der weiter oben dargestellte View “Git-Repositories” weist uns neben dem Repository-Symbol im Moment explizit darauf hin, dass noch keine HEAD-Version existiert. Wie auch? Im “Branches”-Bereich ist unter dem Punkt “Local” ja noch nicht mal ein (Master-) Branch zu finden (s. den vorhergehenden Blog-Post). Es gibt im Moment noch überhaupt keinen Branch!

Unter Git muss man Verzeichnisse und Dateien explizit für die Berücksichtigung in der Versionsverwaltung markieren. Die kleinen Fragezeichen in den Verzeichnis-Icons im PHP-Explorer deuten an, dass dies bislang noch für keines der vier Hauptverzeichnisse unseres Test-Projektes geschehen ist. Ein “gt;”-Symbol nach den Verzeichnis- bzw. auch nach einem Datei-Namen deutet ferner an, dass es eine Änderung gibt, die noch nicht per Commit im Repository erfasst wurde: Der aktuelle Inhalt jeder Datei stellt aus Sicht von Git offenbar eine Art erste (initiale) Änderung dar. Wir würden das Symbol bei jeder Datei unterhalb der Verzeichnisse sehen.

Später werden wir das “>”-Symbol natürlich genau an denjenigen Dateien/Verzeichnissen entdecken, die jemand seit dem letzten Commit modifiziert hat. Das ist beim Einsatz von Subversion ganz genauso. Einen kleinen Unterschied zu SVN gibt es allerdings doch, und der macht sich dadurch bemerkbar, dass das Verzeichnis “uploads” kein “>”-Symbol aufweist: Der Grund dafür ist, dass das Verzeichnis leer ist. Das ist ein Hinweis darauf, dass Git keine separate Versionsverwaltung für Verzeichnisse als Repository-Objekte vornimmt. Verzeichnisse sind lediglich ein Art Attribut der nach Versionen verwalteten Datei-Objekte!

Den aktuellen Repository-Zustand könnte man im Git-Sprachgebrauch also etwa so zusammenfassen: Es ist bislang weder ein “Commit” zu den vorhandenen Dateien erfolgt, noch wurden die in Verzeichnissen organisierten Dateien überhaupt für eine Indizierung und Verwaltung in einem Branch und damit auch der Git-Objektdatenbank vorgesehen. Wir ändern das nun in zwei separaten Schritten:

Schritt 1 – Einbeziehen der Verzeichnisse und ihrer Dateien in die Versionsverwaltung: Wir markieren unsere 4 Projektverzeichnisse des Beispiels “alien”, “includes”, “interpreters”, “uploads” im PHP- oder Projekt-Explorer. Dann klicken wir in der Git-Icon-Leiste auf das grüne Kreuz. Danach müssen warten, bis sich das Dialogfenster zu “Operation in Progress …” wieder schließt.

Die nächste Abbildung zeigt, dass sich die Mikro-Symbole an den Verzeichnissen nun geändert haben:

Der weiße Stern auf schwarzem Grund weist allerdings darauf hin, dass die Dateien in den Verzeichnissen immer noch keinen “Commit” erfahren haben.

Schritt 2 – Initialer Commit für alle erfassten Dateien:
Um für alle Dateien einen “Commit” einzuleiten, markieren wir unsere Verzeichnisse erneut und klicken dann auf das orange Repository-Symbol mit dem Pfeil von links nach rechts in der Git-Icon-Leiste; dieses Symbol befindet sich neben dem grünen Kreuz und symbolisiert einen Commit-Vorgang – unseren ersten im erstellten Repository.

Nach wenigen Augenblicken bietet sich uns dann folgendes Bild im sogenannten “Git Staging View“. Dieser View öffnet sich automatisch und listet Dateien/Verzeichnisse auf, die modifiziert wurden und für die endgültige Ausführung des Commits “vorgemerkt” sind. Man nennt das auch “Staging“.

Im linken Bereich sehen wir im Bereich “Unstaged Changes” Dateien (nur 2 von 5 sind sichtbar), die bislang nicht für Commits vorgemerkt wurden. Es handelt sich in unserem Fall um Eclipse-Konfigurationsdateien für das spezielle Projekt. Darunter sehen wir im Bereich “Staged Changes” allerdings die für das Commit vorgemerkten Dateien. In unserem Fall alle Projektdateien. (Es handelt sich offenbar um eine größeres Projekt, zu dem über 3000 einzelne Dateien beitragen.)

Im rechten Bereich des “Staging View” können (besser müssen) wir unseren Commit noch mit einem Kommentar verzieren. Unterhalb sollten auch Author und Committer angegeben werden; dabei sind bestimmte Formatanforderungen zu erfüllen, die wir nach einem Klick in das jeweilige Feld gefolgt von einem “Ctrl-Space” angezeigt bekommen. Die entsprechenden Werte lassen sich auch in den Eclipse-Preferences für Git hinterlegen. Man findet Git-Preferenzen wie üblich unter dem Menüpunkt “Window => Preferences => Team => Git”.

Wir klicken nun auf den Button “Commit“. Es wird jetzt eine erste Komplettversion im sog. “master”-Branch unseres Repositories erzeugt. Genauer: Zuerst wird der Master-Branch generiert; dann wird n einer ersten Projektversion auf diesem Branch der aktuelle Inhalt aller ausgewählten Projektdateien erfasst. Das Erzeugen der zugehörigen initialen Objekte des Repositories und deren Komprimierung dauert in meinem Fall wegen der großen Menge der Dateien ein paar Augenblicke.

Jeder Commit führt zu einem neuen Versionsstatus des gesamten Branches (sozusagen über alle modifizierten Dateien hinweg). Auf der Branch-Ebene entspricht ein Commit in seiner Gesamtheit somit einem eindeutigen Knoten (s. hierzu den letzten Post). Die Identität des Knotens wird durch einen eindeutigen Hash gekennzeichnet, dessen erste Buchstaben wir im Git-Repository-View auch angezeigt bekommen. Diesem Hash sind wiederum Hashes für die einzelnen erfassten Objekte (Dateien bzw. komprimierte Blobs zu deren Änderungen) zugeordnet. Auch die Änderungen selbst (bzw. zugehörige Objekte in einem Binärformat) werden also über Hashes identifiziert.

Im Git-Repository-View ergibt sich nach der Durchführung des Commits folgendes Bild :

Nun existiert offenbar der ersehnte lokale Master-Branch. Daneben erkennen wir die ersten alphanumerischen Zeichen seines Hashes (hier: 3659950) und die Anfänge unseres eben erstellten Kommentars.

Unsere Verzeichnis-Symbole im PHP-Explorer weisen nun zudem das kleine orangefarbene zylinderartige Repository-Symbol auf – damit wird angezeigt, dass die Dateien in den betroffenen Verzeichnissen ordnungsgemäß versioniert wurden. Das Fehlen von “>”-Symbolen an den Verzeichnissen, die Dateien enthalten, zeigt an, dass im Repository auch alles auf dem aktuellsten Stand ist.

Neben dem Verzeichnissymbol zum Haupt-Directory “alien1” unseres Projekts wird freundlicherweise dargestellt, welchem Branch der Inhalt des “Working Trees” gerade zugeordnet ist. (In realen Projekten wird es ja ggf. mehrere Branches geben). Der geneigte Leser wird nun sicher auch selbst beantworten können, warum das “>”-Symbol neben dem Hauptverzeichnis “alien1” nicht verschwunden ist.

Der interessierte Leser mag in einem eigenen Beispiel zudem mal einen Blick in das Verzeichnis “/…./.git/objects” werfen; man wird feststellen, dass auch dieses Verzeichnis nach dem initialen Commit mit vielen Dateien in einem Binärformat gefüllt wurde.
Nach unserem initialen Commit ist die komplette Information über den Inhalt der Projekt-Dateien also redundant vorhanden – einmal im “Working Tree” und auch in der Objektdatenbank des Repositories.

Nach weiteren Commits enthält das Repository aber deutlich mehr Informationen als der Working Tree: Der Working Tree spiegelt dann nur den Zustand wider, der zum geöffneten letzten Knoten des aktiven Branches gehört – plus ggf. zwischenzeitlich vorgenommene Änderungen, die noch nicht committed wurden. Das Repository hingegen enthält dann die gesamte bisherige Änderungshistorie. Dank Komprimierungstechnologie und der Speicherung inkrementeller Änderungen ist der Platzbedarf des Workings Trees über lange Zeit hinweg dennoch meist deutlich geringer als der Platzbedarf des Working Trees.

Zusammenfassung und Ausblick

Wir haben im Zuge dieses Artikels zu einem vorhandenen Projekt eine voll funktionsfähige lokale Versionsverwaltung unter Git eingerichtet, mit der wir nun weitere Experimente durchführen können. Wir haben dabei gesehen, dass ein Repository nach seiner Anlage auch gefüllt werden muss. Dazu sind Dateien für die Erfassung und Verfolgung in der Versionsverwaltung zu markieren. Ein Commit besteht im Grunde aus drei Phasen :

  • Phase 1: Auswahl und Staging der geänderten Dateien für die Durchführung des Commits.
  • Phase 2: Eingeben eines Kommentars zum Commit. Benennung des Autors und des Committers.
  • Phase 3: Technische Durchführung des Commits.

Ein Commit erzeugt einen eindeutig identifizierbaren Knoten in einem Branch. In einem initialen Commit werden der Master-Branch des Repositories und dessen erster Knoten erzeugt. Der Commit bzw. der korrespondierende Knoten im Branch sind durch einen eindeutigen Hash gekennzeichnet. Einem Commit sind ferner bestimmte (neu) angelegte Objekte im Verzeichnis “.git/objects” zugeordnet.

Im nächsten Blog-Post führen wir testweise einige Änderungen und zugehörige Commits durch. Wir betrachten dabei auch die Darstellung der Historie unter Eclipse. Zudem werfen wir einen ersten vergleichenden Blick auf die GUIs “GitG” bzw. “QGit”.