Author Archives: alex

Debian GNU/kFreeBSD in Xen HVM DomU mit Verschlüsselung und ZFS

1 Reply

Ich will Backup und ich will ZFS, da brauch ich glaube ich in beiden Fällen nicht drauf eingehen warum. Auf dem Server läuft ein Debian Wheezy (amd64) und mit Xen werden diverse virtuelle Maschinen ausgeführt. Für’s Backup sind vier Platten vorgesehen und da soll ZFS drauf und die Daten sollen verschlüsselt werden.

Wie ich jetzt darauf gekommen bin das ganze mit Debian GNU/kFreeBSD zu realisieren, sei mal nicht in Frage gestellt, ist jetzt so und es gibt eine VM, die mittels Hardware-Virtualisierung der CPU installiert wurde, hatte ich ja hier schon erwähnt wie. Probleme mit der I/O-Performance hab ich dank der passenden Mailingliste auch beheben können.

Bevor wir jetzt ZFS installieren, soll noch Crypto drunter. Das könnte man auch anders schichten, aber so rum scheint empfohlen zu sein. Ebenfalls empfohlen ist es Crypto nicht auf die nackte Platte zu tun (auch wenn das ginge) sondern die Platten noch zu partitionieren. Bei BSD scheint da mittlerweile GPT der Standard zu sein und das passende Tool bei FreeBSD wäre gpart. Beim Debian GNU/kFreeBSD haben wir aber Debian Userland und da gibt’s dieses Tool nicht. Partitioniere ich also mit gdisk, dachte ich mir, aber das ist dann auch wieder nicht so einfach, weil gdisk sich beschwert, dass /dev/da0 ein character device sei. Ist es auch, scheint bei BSD so zu sein, bedeutet aber, dass ich die Platten nicht in der VM partitionieren kann, sondern das bereits im Wirt tun muss. Mit gdisk war das kein Problem und als Partitionstyp hab ich mal FreeBSD ZFS benutzt aka 0xA504.

Nächster Schritt: Verschlüsselung. Da benutzt man bei FreeBSD das Tool geli und das ist dann wieder Kernel Space genug, dass es auch verfügbar ist. Befehle hier:

% sudo geli init -s 4096 -l 256 /dev/da0p1
Enter new passphrase:
Reenter new passphrase: 

Metadata backup can be found in /var/backups/da0p1.eli and
can be restored with the following command:

        # geli restore /var/backups/da0p1.eli /dev/da0p1

Und dann:

% sudo geli attach /dev/da0p1
Enter passphrase:

Beim Initialisieren kann man auch noch Keydateien angeben und alle möglichen Optionen setzen. Details dazu hat das FreeBSD-Handbuch. Analog wird mit den anderen Platten verfahren und es stehen einem dann die aufgeschlossenen Devices zur Verfügung, für die erste verschlüsselte Partition der ersten Platte hier /dev/da0p1.eli welches dann gleich einem zpool hinzugefügt wird.

Den zpool namens tank erzeugte ich dann so:

sudo zpool create tank raidz2 da0p1.eli da1p1.eli da2p1.eli da3p1.eli

Das entspricht de facto einem RAID-6 und ist auch bereits unter /storage gemountet. Für den nächsten Systemstart fehlt also nur noch ein Skript, was mir die Crypto-Devices aufmacht. Bei Debian GNU/kFreeBSD kann man da mal in /etc/default/geom schauen. Das darauf liegende ZFS wird dann automatisch gefunden und eingebunden.

Alles weitere ist dann Anwendung von ZFS, das wäre thematisch aber was für einen anderen Artikel. ;-)

ksplash’d

Leave a reply

Auf dem neuen Rechner im Büro ist (natürlich) Debian installiert, mit KDE, so wie auf allen meinen Rechnern. Flotte Kiste und ich hab mir nichts weiter dabei gedacht, dass nach dem Einloggen kein Splash Screen erschien, schnell halt die Mühle. Durch einen Zufall bin ich aber heute nochmal bei den Einstellungen der Splash-Screens gelandet und stellte fest, dass »Default« zwar funktionierte, das von mir bevorzugte »joy« des aktuellen Debian-Release Wheezy jedoch nicht. Warum? Gar nicht so leicht rauszufinden, aber was aufgerufen wird, ist wohl sowas wie das hier:

adahl@ada ~ % ksplashx joy --test     
libpng error: Read Error
Failed to load: background.png

Huch, was ist da denn das Problem? Mein Monitor läuft in keiner der Auflösungen, wo im Paket desktop-base Bilder mitgeliefert werden, also mal mit strace geschaut, was er da öffnen will:

open("/home/adahl/.kde/cache-ada/ksplashx/joy-1680x1050-background.png", O_RDONLY) = 5

Hmm, da hat wohl wer umgerechnet und abgelegt, und …

 
adahl@ada ~ % ls -l ~/.kde/cache-ada/ksplashx/
insgesamt 2028
-rw-r--r-- 1 adahl adahl 2076229 Jun  1  2012 Default-1680x1050-background.png
-rw-r--r-- 1 adahl adahl       0 Aug 23  2012 joy-1680x1050-background.png

Na sowas?! Also kurzerhand die leere Datei gelöscht und schon geht das! :-)

Link

Wunderbarer Beitrag von Lena:

“Non-coders” in Open Source projects or: On aliens – Confessions of a “non-coder” (1).

Gut geschrieben und amüsant illustriert. Eine Freude zu lesen, auch für Coder. ;-)

(via Twitter)

Wireshark als normaler Nutzer ausführen

Leave a reply

Mit jedem neuen Rechner und damit jeder neuen Installation kommen jedesmal die gleichen Probleme auf einen zu. Aktuell hab ich hier im Büro eine neue Maschine mit Debian Wheezy und ich will Wireshark als normaler Nutzer ausführen. Laut /usr/share/doc/wireshark/README.Debian muss dumpcap installiert sein und richtig eingerichtet und man muss selbst der Gruppe wireshark angehören. Das genannte Tool ist Teil des Pakets wireshark-common und das lässt sich wie folgt umkonfigurieren:

sudo dpkg-reconfigure wireshark-common

Es öffnet sich ein Menü, man stellt das gewünschte ein. Nutzer zur passenden Gruppe hinzufügen mit Debian-Mitteln sieht dann so aus:

sudo addgroup adahl wireshark

Ausloggen und neu wieder einloggen, damit die Gruppenberechtigungen wirksam werden und dann tut das.

Problemchen mit approx beheben

Leave a reply

In Zeiten vieler Rechner und dennoch langsamer Internetverbindungen1 kann ein Paketproxy ein wahrer Segen sein. Updates und Pakete für Debian und auf Debian basierenden Betriebssystem werden dann im lokalen Netz zwischengespeichert und es muss nicht jeder einzelne Rechner immer alles von einem Debian-Spiegel aus dem Netz holen. Ich setze dazu approx ein. D.h. ich betreibe keinen eigenen Mirror, sondern halte nur die nötigen Pakete lokal nochmal vor. Ein spezialisierter Proxy wie approx, der über die Struktur des Paketservers bescheid weiß, kann hier meiner Meinung nach bessere Dienste leisten, als ein generischer Proxy.

Während die Idee an sich gut ist, gibt es im Detail ein paar Problemchen. Sowohl approx vermurkst sich manchmal seine Daten als auch clientseitig das apt auf dem Rechner. Auf beiden Seiten kann man das wieder bereinigen und ich zeige kurz wie.

approx

Ein häufiges Problem, das ich bei approx festgestellt habe, sind 0 Byte große Dateien. Sind solche unter /var/cache/approx solche vorhanden, kommt es auf Clientseite zu allerlei komischen Fehlern, heute hatte ich da beispielsweise HTTP 404 für Dateien, die auf dem Mirror vorhanden sind. Auf dem Server, wo approx läuft, habe ich dann zwei Sachen ausgeführt:

sudo find -L /var/cache/approx -empty -exec rm -rf {} +
sudo approx-gc

apt

Die Probleme hier entstehen vermutlich ähnlich wie serverseitig durch unterbrochene Updatevorgänge, nutzer- oder netzwerkseitig, egal, es ist halt was kaputt. Es gibt natürlich aptitude clean und dergleichen und manchmal scheint das aber nicht zu helfen. Zuletzt behalf ich mir dann damit:

sudo rm -rf /var/lib/apt/lists
sudo mkdir -p /var/lib/apt/lists/partial

So sind Updates jetzt wieder möglich. Ich weiß zwar nicht, was genau und warum das ab und zu kracht, aber so kann man’s wenigstens in einen funktionierenden Zustand zurücksetzen.

  1. Breitbandausbau am Arsch! [↩]

Git unter Windows

3 Replies

Ganz ehrlich, ich hab die Schnauze voll von Windows. Es begann damit, dass ich mehrere Tage gebraucht habe, um Qt 4.8.x selbst zu kompilieren, weil die pre-built Binaries mit einem alten MinGW mit GCC 4.4.x gebaut wurden, dieses aber nicht mit Qt mitgeliefert wird. MinGW selbst stellt aber keine älteren Releases bereit und wegen ABI-Änderungen bei GCC lässt sich Qt (GCC 4.4) nicht mit aktuellem MinGW (GCC 4.8) zusammen nutzen. Das allein schon war frustrierend genug, aber es tauchen dann ja noch so Schwierigkeiten auf, wie dass der Snakeoil Virenscanner selbst kompilierte Software hart löscht. Jetzt habe ich endlich ein Qt und dann beschwert sich CMake noch lange vor dem Build der Anwendung, dass es ein “sh” im PATH gefunden hat. Git für Windows bringt das mit, wozu auch immer. Dachte ich, schauste mal, ob das unbedingt nötig ist, aber die Git-GUIs für Windows brauchen das und auch sonst ist das mit den GUIs für Git unter Windows höchst schmerzhaft. Eine Liste gibt es zwar, aber das ist alles unbrauchbar:

GitHub for Windows
Verbirgt große Teile der Komplexität von Git, ist damit für gewisse Workflows unbrauchbar und arbeitet, oh Wunder, nur mit GitHub.
Git Extensions
Ist nicht plattformunabhängig und installiert mir Dinge mit, die ich schon habe.
git-cola
Braucht erstmal noch Python und PyQt und letzteres wiederum bringt im Binary-Installer gleich wieder ein ganzes Qt mit. Was hatte ich noch gleich selbst kompiliert?
GitEye
Ist ein komplettes Eclipse, für Git, also riesengroß, nur für ein Versionsverwaltungssystem. Irre.
SmartGit
Nicht frei.
SourceTree
Braucht mindestens Windows 7.

Dann wäre da noch TortoiseGit, aber das ist nur ein Fork von dem für Subversion super geeigneten TortoiseSVN und dementsprechend ungeeignet für einen Git-Workflow. Git ist halt kein zentralisiertes Versionsverwaltungssystem wie CVS, wie soll ich dafür dann das selbe Interface gebrauchen können?

Bei Mercurial hat man wenigstens ein schönes plattformunabhängiges GUI in Qt geschrieben. Das heißt zwar auch TortoiseHg, hat aber von der Bedienung her kaum was mit den zuvor genannten gemein und spült mir auch keine zusätzliche kaputte Shell auf meinen Rechner.

Hölle, ist das alles broken. Ich will mein Linux zurück. :-/

Ach so ja, das Problem mit CMake lässt sich übrigens lösen, indem man das CMake-GUI mit einem sauberen PATH startet, bspw. mit einer Batch-Datei cmake-gui.bat:

cd "C:\Programme\CMake 2.8"
PATH=C:\MinGW\bin;C:\Qt\Qt4.8.5-x86\bin
"C:\Programme\CMake 2.8\bin\cmake-gui.exe"

HowTo: GnuPG mit unbegrenztem Signing-Key und ablaufendem Encryption-Key

3 Replies

Sperrig, die Überschrift, also worum geht’s? Ich zitiere mal aus dem GnuPG-Handbuch:

Wenn Sie ein neues Schlüsselpaar erzeugen, werden standardmäßig ein DSA-Hauptschlüssel zum Unterschreiben und ein ElGamal-Unterschlüssel zum Entschlüsseln erzeugt. Dies ist von Vorteil, weil die Aufgaben der beiden Schlüssel verschieden sind und es sinnvoll sein könnte, den beiden Schlüsseln verschiedene Verfallsdaten zu geben. Der DSA-Hauptschlüssel wird benutzt, um digitale Unterschriften zu leisten, und er bestätigt Ihre Identität dadurch, daß andere ihn signiert haben. Der ElGamal-Unterschlüssel wird nur benutzt, um an Sie geschickte verschlüsselte Daten zu entschlüsseln. Typischerweise sollte eine digitale Signatur eine lange oder unbegrenzte Gültigkeitsdauer haben; Sie wollen ja auch die Unterschriften auf Ihrem Schlüssel, die Sie mühsam zusammengetragen haben, nicht verlieren. Andererseits sollte der ElGamal-Unterschlüssel in gewissen Zeitabständen gewechselt werden, um Ihre Datensicherheit zu erhöhen, da ein Angreifer, wenn der ElGamal-Unterschlüssel geknackt ist, alle Dokumente lesen kann, die für diesen Schlüssel verschlüsselt worden sind oder es noch werden.

Darauf folgt noch ein kurzer Hinweis, dass das etwas umständlich ist, aber wie genau man das anstellt, ist quasi als Hausaufgabe überlassen und deswegen1 zeige ich das jetzt hier.

Zunächst erstellt man sich einen Schlüssel ohne Ablaufdatum, der Wizard packt sonst auf beide Unterschlüssel ein Ablaufdatum und das wollen wir ja eigentlich nicht:

gpg --gen-key

Heutzutage ist das kein DSA/ElGamal-Paar, sondern beides sind RSA-Schlüssel, aber Details kann man in einem beliebigen HowTo zur Schlüsselerstellung nachlesen. In meinem Fall hab ich zu Testzwecken das hier erhalten:

pub   4096R/8C5DE4C1 2013-09-27
  Schl.-Fingerabdruck = 1EDD 0AF2 9CA3 A110 A30F  D404 3C63 79A9 8C5D E4C1
uid                  Alice (Testschlüssel) 
sub   4096R/79C6C593 2013-09-27

Als nächstes bearbeite ich diesen Schlüssel:

gpg --edit-key 0x8C5DE4C1

Hier gibt es jetzt eine Reihe von Befehlen, die man sich mit help anzeigen lassen kann. Zunächst ist list ganz hilfreich. Die Ausgabe davon:

gpg> list

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/79C6C593  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel)

Den Unterschlüsseln ist ein »sub« vorangestellt, allerdings nicht nummeriert. Man wählt nun den Encryption-Key aus mit key 1 oder wenn man bereits mehrere Unterschlüssel hat, muss man durchzählen, die sind freundlicherweise geordnet. GnuPG markiert den soeben ausgewählten Unterschlüssel mit einem Sternchen:

gpg> key 1

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel)

Der nächste Befehl ist expire. Zuvor kann man sich mit list nochmal überzeugen, dass auch nur der Unterschlüssel ausgewählt ist. GnuPG ist an der Stelle aber so freundlich bei der Nachfrage nochmal klar zu stellen, dass man nur das Ablaufdatum des Unterschlüssels ändert. Sieht dann so aus:

gpg> expire
Ändern des Verfallsdatums des Unterschlüssels.
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
        = Schlüssel verfällt nach n Tagen
      w = Schlüssel verfällt nach n Wochen
      m = Schlüssel verfällt nach n Monaten
      y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 2
Key verfällt am So 29 Sep 2013 12:47:52 CEST
Ist dies richtig? (j/N) j

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Alice (Testschlüssel) "
4096-Bit RSA Schlüssel, ID 8C5DE4C1, erzeugt 2013-09-27

                              
pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: 2013-09-29  Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel)

Hier sieht man jetzt, dass der Key, dem das »pub« vorangestellt ist und bei dem es sich um den Signing-Key (SC) handelt, immernoch kein Verfallsdatum hat, der Encryption-Key (E) hingegen schon.

Bis hier hin wäre das das Vorgehen, wenn man sich einen neuen Schlüssel erstellt oder bereits einen hat, der bisher kein Ablaufdatum hat. Hat man seinen Schlüssel bereits auf einen Keyserver geladen, empfehle ich nicht am Ablaufdatum rumzufummeln. Solche Änderungen kommen womöglich nie beim Gegenüber an. Dann lieber neuen Schlüssel machen.

Was nun, wenn der Encryption-Key droht abzulaufen? Man fügt mit addkey einen neuen hinzu. GnuPG fragt dann nach allerlei Details, u.a. wie lange der neue Unterschlüssel gültig sein soll. Bei der Frage, was für ein Unterschlüssel es werden soll, wählt man einen für »nur verschlüsseln« und dort sinnvollerweise die Variante RSA mit der vorgebenen oder einer größeren Schlüssellänge:

gpg> addkey
Schlüssel ist geschützt.

Sie benötigen eine Passphrase, um den geheimen Schlüssel zu entsperren.
Benutzer: "Alice (Testschlüssel) "
4096-Bit RSA Schlüssel, ID 8C5DE4C1, erzeugt 2013-09-27

Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
   (3) DSA (nur unterschreiben/beglaubigen)
   (4) RSA (nur signieren/beglaubigen)
   (5) Elgamal (nur verschlüsseln)
   (6) RSA (nur verschlüsseln)
Ihre Auswahl? 6
RSA-Schlüssel können zwischen 1024 und 4096 Bit lang sein.
Welche Schlüssellänge wünschen Sie? (2048) 
Die verlangte Schlüssellänge beträgt 2048 Bit
Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll.
         0 = Schlüssel verfällt nie
        = Schlüssel verfällt nach n Tagen
      w = Schlüssel verfällt nach n Wochen
      m = Schlüssel verfällt nach n Monaten
      y = Schlüssel verfällt nach n Jahren
Wie lange bleibt der Schlüssel gültig? (0) 1m
Key verfällt am So 27 Okt 2013 11:57:50 CET
Ist dies richtig? (j/N) j
Wirklich erzeugen? (j/N) j
Wir müssen eine ganze Menge Zufallswerte erzeugen.  Sie können dies
unterstützen, indem Sie z.B. in einem anderen Fenster/Konsole irgendetwas
tippen, die Maus verwenden oder irgendwelche anderen Programme benutzen.
.............+++++
..........+++++

pub  4096R/8C5DE4C1  erzeugt: 2013-09-27  verfällt: niemals     Aufruf: SC  
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub* 4096R/79C6C593  erzeugt: 2013-09-27  verfällt: 2013-09-29  Aufruf: E   
sub  2048R/C82D05DE  erzeugt: 2013-09-27  verfällt: 2013-10-27  Aufruf: E   
[ uneing.] (1). Alice (Testschlüssel)

Hier hab ich jetzt gleichzeitig zwei gültige Encryption-Keys, aber das diente ja nur zum Zeigen und Ihr werdet den Key auch auf keinem Keyserver finden.

Mit save verlässt man den Editiermodus und dann lädt man den mit neuem Encryption-Key versehenen Schlüssel wie gewohnt auf den Keyserver hoch.

Übrigens habe ich meinem eigenen PGP-Schlüssel mit dieser Methode auch gerade einen frischen Encryption-Key spendiert. Falls sich Euer Mailprogramm beschwert, dass Ihr mir keine verschlüsselten Mails mehr schicken könnt, ladet Euch mal meinen aktuellen Public-Key! ;-)

  1. und weil ich Frank Lanitz das mal auf einer Keysigningparty bei den Chemnitzer Linux-Tagen versprochen hatte, ach und wegen der im Netz39 bevorstehenden Keysigningparty, na und natürlich, weil der Encryption-Key bei mir bald abläuft … [↩]

Sessionname in Statuszeile von GNU screen

Leave a reply

Grml ist das Live-Linux meiner Wahl für allerlei Zwecke. Das coole ist die Config, die dort für Zsh, Vim und GNU screen mitgeliefert wird und da ich wenig Lust hab, mir sowas selbst zusammenzubasteln und ich ebenso gern ein vertrautes Nutzerinterface habe, nutze ich die Configs auch auf anderen Rechnern, indem ich dort einmal grml-config.sh ausführe und dann nur noch kleine Anpassungen machen muss.

Screen benutze ich ausgiebig und meistens mit mehreren sessions und ab und zu kommt man da mal durcheinander. Deswegen habe ich die .screenrc jetzt doch mal ein bisschen angepasst und statt

  caption always "%{+b rk}$USER@%{wk}%H | %{yk}(load: %l)  %-21=%{wk}%D %d.%m.%Y %0c"

steht da jetzt bei mir

  caption always "%{+b rk}$USER@%{wk}%H | %S | %{yk}(load: %l)  %-21=%{wk}%D %d.%m.%Y %0c"

und dank des zusätzlichen Parameters %S hab ich die aktuelle Session direkt im Blick. :-)

HowTo: FreeBSD als HVM-DomU in Xen auf Debian Wheezy

3 Replies

Zu Hause und im Netz39 e.V. läuft je ein Server mit Debian Wheezy auf amd64 und als Virtualisierungssystem wird Xen benutzt. Linux-Gäste werden paravirtualisiert und das läuft schon seit Jahren fluffig. Für bestimmte Zwecke muss es aber auch mal ein anderes System sein und das ist im Hackerspace ein aktuelles FreeBSD 9.1 und zu Hause ein Debian GNU/kFreeBSD, also kein Debian GNU/Linux, sondern eben das Debian mit dem ganzen GNU Userland und einem FreeBSD-Kernel. In beiden Fällen ist auch die VM die 64-Bit-Variante und die Hardwarevirtualisierung der jeweiligen Prozessoren soll genutzt werden. Was fehlt: die initiale Config für die VM und da hab ich gesucht, recherchiert und probiert und präsentiere jetzt, was bei mir funktioniert hat. Zu Hause sieht’s so aus:

vcpus = 2
memory = 1024
name = 'kleopatra'
builder = 'hvm'
kernel = 'hvmloader'
disk =  [
                'phy:/dev/mapper/heaven-kleopatra,hda,w',
                'file:/home/alex/debian-7.1.0-kfreebsd-amd64-netinst.iso,hdc:cdrom,r',
        ]
boot = 'dc'
vif = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

Und im Space:

vcpus       = 1
memory      = 512
name        = 'hydrogen'
builder     = 'hvm'
kernel      = 'hvmloader'
disk        = [
            'phy:/dev/mapper/vgmarx-wasserstoff,hda,w',
            'file:/media/images/FreeBSD-9.1-RELEASE-amd64-disc1.iso,hdc:cdrom,r',
          ]   
boot        = 'dc'
vif     = [ 'mac=00:16:3E:XX:XX:XX,bridge=xenbr0' ]
vfb     = [ 'type=vnc' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

In beiden Fällen hatte ich zuvor Xen nach der Anleitung im Debian-Wiki aufgesetzt. Die XX in den Mac-Adressen sind durch zufällige Werte zwischen 00h und FFh zu ersetzen. Die Erzeugung von Zufallszahlen und die Umrechnung ins Hexadezimalsystem überlasse ich als Hausaufgabe.

Nach dem Start der DomU macht man einen SSH-Tunnel auf für den VNC-Port und verbindet sich mit seinem bevorzugten VNC-Client1 auf localhost:

ssh -L 5900:localhost:5900 yourxenhost

Nach der Installation in der Config die Bootreihenfolge anpassen bzw. das CD-Image rausnehmen, fertig.

  1. unter KDE benutze ich krdc, auch wenn ich den Namen grauslig finde [↩]

echo echo echo

1 Reply

Der Netzwerkdienst echo ist laut allwissender Müllhalde im inetd implementiert. Muss man wissen. Und dann muss man noch wissen, wie der aktiviert wird, ist er per default logischerweise nicht. Unter Debian Wheezy mit dem inetd aus dem Paket openbsd-inetd fügt man an geeigneter Stelle folgende Zeile zu /etc/inetd.conf hinzu:

echo    stream  tcp     nowait  root    internal