Bernhard Häussner
Tags: Artikel mit dem Tag «Shell» durchstöbern

VNC mit openSUSE oder Debian Linux (Howto)

22.10.2009, 09:13

Die Verwendungsmöglichkeiten einer Remote-Desktop-Lösung reichen von Fernadministration bis Support. VNC erlaubt den Fernzugriff auf graphische Benutzeroberflächen. Eine Kurzanleitung zur Installation von VNC-Server und -Client unter openSUSE und/oder Debian:

Server

Zunächst benötigt man auf dem Server (der Computer dessen Bildschirm übertragen werden soll) einen VNC-Server, wie z.B. x11vnc:

sudo zypper install x11vnc
#oder Debian:
sudo aptitude install x11vnc

Als nächstes legt man eine Passwort-Datei an, in der das Passwort für den Fernzugriff gespeichert wird:

mkdir ~/.vnc
x11vnc -storepasswd ~/.vnc/passwd
#(fragt nach einem neuen Passowrt)
chmod 0600 ~/.vnc/passwd

Da die Firewall den benutzen Port 5900 blockieren sollte, wird das Passwort nur gebraucht, da sich nicht jeder Benutzer des Server-Computers in den Desktop einklinken können soll. Nun könnte auf dem Server schon der VNC-Server gestartet werden, doch das mache ich dann vom Client:

Client

Zunächst stellen wir sicher, dass es ein VNC-Client installiert ist:

sudo zypper install tightvnc
#oder Debian:
sudo aptitude install xtightvncviewer

Da die Verbindung sicher sein soll und Firewalls umgehen soll, wird das ganze über SSH getunnelt (Mehr zum SSH-Tunnel am Beispiel MySQL), und der Server gleich mit gestartet, durch dieses kleine Script: (Es setzt eine konfigurierte OpenSSH Public Key Authentication voraus)

#!/bin/bash
SSHLOGIN=user@vncserver
ssh -L 5900:localhost:5900 $SSHLOGIN "x11vnc -localhost -display :0 -rfbauth ~/.vnc/passwd" &
sleep 3
vncviewer localhost

Optional kann man auch die SSH-Option -C angeben, die bei Netzwerkverbindungen mit geringer Bandbreite (Internet) die Daten komprimiert und somit alles schneller läuft. Theoretisch.

Arbeitet man auf verschiedenen remote Desktops kann man $SSHLOGIN durch $1 ersetzen und dann das Script mit der passenden User/Server-Kombination für SSH starten.

Das Script verlangt die Eingabe des des oben gesetzten VNC-Passworts, dann müsste der Remote Desktop zu sehen sein.

Kommentare: 5 Einträge

Linux Backup Server

02.08.2009, 13:04
Backup Server

Backup Server

Da die Anzahl „wichtiger“ elektronischer Dokumente, hauptsächlich Rechnungen, wächst, und ich auch sonst nichts vermissen will, sichere ich meine Daten hin und wieder auf einem Backup-Server. Wie ich das mache und was man noch mit einem solchen Server anfangen kann:

Volldatensicherung

Für die komplette Sicherung des /home-Ordners erstelle ich tar-Archive.

Um einfach auf die Backuplaufwerke zugreifen zu können, kann man SMB-Freigaben mounten:

mount -t cifs -o username=bernhard //server/backup /mnt/backup/
#Beispielhafter-Aufruf:
tar -czvf /mnt/backup/pc1/`date +%Y-%m-%d`-amoebes.tar.gz\
 -X /home/amoebe/tarexclude\
 /home/amoebe >> /mnt/backup/pc1/last.log 2>&1

Es geht aber natürlich auch über eine Pipe zu SSH:

tar -czf - -X /home/amoebe/tarexclude /home/amoebe\
 | ssh server "cd /home/bernhard/backup/pc1/\
 && cat - > `date +%Y-%m-%d`-amoebes.tar.gz"

Weil ich der eigenen Samba-(nicht)-Konfiguration kaum vertraue, und ich auch nicht immer 100%ig weiß, was CIFS anrichtet, ist mir SSH lieber. Die Verschlüsselung von SSH kostet zumindest nicht zu viel Zeit - das Backup dauert ohnehin nur rund 7 Minuten bei den gut 2 GB. Und SSH ist fast immer verfügbar, während Samba nicht überall installiert ist.

Da man temporäre Dateien, wie den Mülleimer, nicht zu sichern braucht, kann man sie vom Backup ausschließen. Dazu hat tar eine eingebaute Filterfunktion, die aus einer Datei eine Liste von Mustern auslesen kann, welche Dateien nicht in das Archiv kommen. Für mein OpenSUSE/KDE habe ich mir folgende Excludes für tar zusammengestellt:

/home/amoebe/tarexclude:
.local/share/Trash/files/*
.thumbnails/*
.beagle
.gvfs
*~
*.swp

Inkrementelles Backup

Für größere Datenmengen ist das Vollbackup nicht mehr zu praktikabel, weshalb man nur noch die Änderungen seit dem letzten Backup überträgt. Dazu ist rsync das passende Tool und bedient sich so:

rsync -vaP --exclude=Backups/ -e ssh amoebe@192.168.1.36:/mnt/lib\
 /home/bernhard/backup/lib/
#Allgemein: rsync [Quelle] [Ziel]

rsync kann SSH gleich mit benutzen. Dieser Befehl läuft auf dem Backup-Server z.B. in einem Cron-Job. Er wird die Dateien vergleichen und neue Dateien bzw. veränderte Dateien übertragen. Es wird allerdings kein Archiv erstellt. Mit diesem Befehl halte ich eine Kopie meiner Datensammlung synchronisiert, was bei jedem Durchlauf ungefähr 2 Minuten braucht (bei 57 GB).

Sharing

Ein Vorteil von einem solchen NAS-ähnlichem Backup-Server ist, dass man auch gleich gut Dateien zwischen Computern im Netzwerk teilen kann. So habe ich auf den Server ein Software-Repository, in dem sich duzende von Windows-Installern, jQuery-Plugins und ähnlichem tummeln. Dazu bastelt man zunächst ein Ordner mit Setuid-Bit, welches beim Erstellen von Dateien die Gruppenzugehörigkeit auf die des Ordners setzt. Oder man ändert einen Ordner nachträglich:

chgrp -R sharer /srv/share
find /srv/share/* -type d -exec chmod g+srw {} \;

So kann dann eine ganze Benutzergruppe den Ordner teilen. Eigentlich bräuchte man dazu noch ein nettes Webinterface mit einer Datenbank im Hintergrund, sodass man die Dateien mit Meta-Infos versehen kann und schnell durchsuchen kann.

Freizeit

Leider kein echtes Wärmebild von meinem Computer

Leider kein echtes Wärmebild von meinem Computer

Da der Server die meiste Zeit mehr oder weniger nutzlos herumsteht, lasse ich ihn nebenbei potentielle Primzahlen faktorisieren. Dazu gibt es das Projekt GIMPS, wo auf Distributed Computing gesetzt wird, um riesige Primzahlen zu finden. Man läd sich das Programm mprime herunter und startet es, dann beantwortet man ein paar Fragen und das rechnen kann beginnen. Ungefähr so:

mkdir primes
cd primes/
wget http://mersenneforum.org/gimps/mprime259-linux64.tar.gz
tar xzvf mprime259-linux64.tar.gz
less readme.txt
#Wenn man screen nicht hat, debian:
sudo apt-get install screen
screen
./mprime
# strg+a strg+d lässt das Programm im Hintergrund weiterlaufen („detach“)
screen -r #holt es zurück. 

Etwas skeptisch bin ich damit allerdings noch, da es meine CPUs recht warm (50° C) hält (und damit die Lüfter laut) und auch etwas mehr Strom verbraucht.

http://www.mersenne.org/ - Website von GIMPS

Mehrere SSH-Verbindungen

Wenn man ein paar Computer gleichzeitig benutzt, und ein paar Terminals offen hat, kann es schnell passieren, dass man einen Befehl auf dem falschen Computer ausführt. „Ein Paar“ beginnt hier erfahrungsgemäß wirklich schon bei 2. Daher mache ich meine Remote-Prompts gerne türkis, mit dieser Zeile in der .bashrc:

PS1="\@ \[\033[0;36m\]\u@\\h\[\033[0m\]:\w> "

Da das immer noch nicht eindeutig genug ist, habe ich mir die Terminals auch noch mit unterschiedlichen Farben hinterlegt:

Das geht mit urxvt oder indem man in Konsole ein neues Farbschema anlegt und dann ein neues Profil, für das man bei Befehl den SSH-Befehl eingibt.

SCP und SHH Dateiübertragungsgeschwindigkeit

Irgendwie würde mich interessieren, wieviel SCP und SSH durch die Verschlüsselung langsamer werden. Darum habe ich paar Komponententests des Vollbackups gemacht.

  • Reines Übertragen der Backup-Datei mit scp: 1787MB in 00:50 bei 35.7MB/s
  • Erstellen des Archivs: 1787 MB in 4:51 also 6 MB/s
  • Lesegeschwindigkeit Quelle: 58,5 MB/s (arm)
  • Schreibgeschwindigkeit Ziel: 79,3 MB/s
  • Lesegeschwindigkeit Ziel: 371 MB/s (für Übertragungs-Tests verwendet)
  • Lesegeschwindigkeit über SMB: 48,9 MB/s
  • Netzwerkgeschwindigkeit rund 100MB/s

Es ist also kein Problem die Daten zu verschlüsseln, da das erstellen des Archivs nicht sonderlich schnell ist. Bei einer geringeren Netzwerkgeschwindigkeit, z.B. bei fast Ethernet oder über das Internet würde es sogar ohne archivieren nicht mehr auffallen.

Das sind also meine Tricks, was ich mit dem Server so anstelle.

Kommentare: keine

Javascript Library Builder

31.07.2009, 13:07
JS-Build

JS-Build

Es gibt einige Methoden Javascript auf HTML-Seiten einzubinden. Ein Block im <body>, in onclick-Attributen und ähnlichem, oder als Verknüpfungen im <head> aber am besten in einer externen Datei, die nach dem HTML-Dokument geladen wird. Nur will man beim Entwickeln die einzelnen Javascript-Teile meist in getrennte Dateien legen und auf der Seite dann möglichst viel in eine (am besten möglichst kleine) Datei packen, um Requests zu sparen. Dieses Problem kann der Javascript Library Builder lösen, ein recht kurzes Shell-Script, welches eine Sammlung von .js-Dateien in wenige Dateien minimiert.

Man nehme zum Beispiel eine solche Dateistruktur:

lib/
  php/...
  js_frontend/
    00_jQuery.js
    01_jQ_plugin.js
    02_effekte.js
    licence.txt
  js_backend/
    03_ajaxCalls.js

Der Scriptaufruf wäre so einfach wie:

jslibbuild.sh -o build lib/js* 

Ich habe auf dieser Seite 27 einzelne Dateien, die ich in zwei Javascript Dateien packe, nämlich für die Seite und für das CMS. Diese Beispiel-Dateistruktur würde jetzt in den zwei Dateien js_frontend.min.js und js_backend.min.js im Ordner build resultieren. Der Datei js_frontend.min.js würde zusätzlich nach dem minimieren mit jsmin die Datei licence.txt vorgehängt, sodass z.B. in Kommentaren (die von jsmin geschluckt werden) vermerkte Autorenhinweise erhalten bleiben, was unter anderem bei den CC-Lizenzen nötig ist.

Dazu akzeptiert das Script die optionale Option -l nach der der Name der Lizenz-Dateien angegeben wird. Eine weitere optionale Option ist -c, um das build-Verzeichnis vor dem Anlegen der neuen Dateien zu löschen. Das ist nötig, wenn ein ganzer source-Ordner gelöscht wird, aber dringend zu vermeiden, wenn weitere Dateien im build-Ordner liegen. Hier noch ein Beispiel:

jslibbuild.sh -c -l gpl.txt -o /srv/www/htdocs/js ~/web/lib/js/* 

Das Script benötigt jsmin, steht unter GPLv2+ und kann hier heruntergeladen werden:

Zum „installieren“ einfach in den Ordner ~/bin kopieren. Das Script ist eigentlich ziemlich einfach, kann aber doch einiges an Arbeit ersparen.

Kommentare: keine

MySQL von außen via SSH-Tunnel (und KDE GUI)

28.12.2008, 17:04
Lokaler MySQL-Client 
    |
    |
(verschlüsselte SSH-Verbindung)
    |
    v
MySQL-Server

Als Web-Administrator braucht man oft Zugang zu einem MySQL-Server. Das kann man mit phpMyAdmin machen, doch das ist kaum so sicher und weniger komfortabel wie remote-Zugriff über einen SSH-Tunnel.

Was kann der SSH-Tunnel und wie geht das?

En SSH-Tunnel macht, dass, wenn auf den eigenen Rechner von einem Port zugegriffen wird, dann die Packete über die verschlüsselte SSH-Verbindung von dem Verbundenen Rechner (Gateway) aus wieder an einen Rechner weitergeleitet werden. Der Befehl sieht so aus:

ssh -L lokalerport:zielrechner:zielport sshgatewaylogin@gateway

Siehe auch das Diagramm:

Irgendwer 
    |
    |
(Lokaler Port)
    |
    v
Mein Computer
    |
    |
(verschlüsselte SSH-Verbindung)
    |
    v
Gateway, eingeloggt als SSH-Gateway-Login
    |
    |
(Zielport)
    |
    v
Zielrechner

Im Fall MySQL greife nur ich über irgendeinen Port auf meinen Computer zu. Der Gateway-Rechner und Zielrechner sind der MySQL-Server und der greift auf sich selbst zu und zwar über den MySQL-Port (Standard: 3066). Dann sieht das ungefähr so aus:

ssh -L 7777:127.0.0.1:3306 me@mysqlserver -N -f

In Verbindung mit MySQL am besten immer 127.0.0.1 verwenden, das vermeidet Ärger. Das praktische ist nun, dass man MySQL-Clients auf den eigenen Rechner nun mit der Datenbank auf dem Server verwenden kann. Solche Clients sind z.B. der MySQL-Abfrage-Browser oder der MySQL-Administrator oder sogar ein PHP-Skript, das auf dem eigenen Rechner läuft. Man kann damit also nicht nur die Datenbank mit einem schönen GUI verwalten, sondern auch PHP-Skripte, Templates o.ä. auf dem eigenen Rechner testen, nur eben mit der Datenbank auf dem Server. Das ist besonders praktisch, wenn man in einem nicht-lokalen Team zusammenarbeitet, da dann alle auf eine zentrale (Development-)Datenbank zugreifen und nicht jeder ständig seine Datenbank synchronisieren muss. (Außerdem muss nicht jeder einen MySQL-Server installieren. )

Wie man das verwendet ist auf tsunamihost.ch sehr gut beschrieben, für Windows und unixoide Systeme. Es findet sich sogar ein kleines Script für init.d um den Tunnel bei jedem Systemstart zu aktivieren.

(Update 2010-11-21) Um zum Beispiel ein MySQL-Dump über den SSH-Tunnel auf einen entfernten Datenbankserver aufzuspielen genügt dann dieser Befehl:

cat local_path/to/dump.sql | \
   mysql -u db_user -p -P 7777 -h 127.0.0.1 db_schema

Es ist hier wichtig als Host 127.0.0.1 anzugeben, da sonst eine lokale Socket-Verbindung genutzt wird. Und natürlich den Port, über den der Tunnel läuft. (/Update)

Ich will mir keine Befehle und Ports merken und habe KDE

Dann habe ich noch ein kleines Script im Angebot: Es lässt sich z.B. im Startmenü verknüpfen und wenn man es anklickt öffnet sich ein Dialog, der fragt, ob der MySQL-Tunnel benötigt wird. Ein klick auf „Ja“ und der Tunnel wird gestartet bzw. läuft weiter oder ein Klick auf "Nein" und der Tunnel wird, sollte er laufen, gestoppt. Einfacher geht es nicht, oder? Das Sktipt braucht KDE, da es kdialog verwendet und steht hier zum Download bereit:

Kurz die Konfiguration bearbeiten und in den Ordner ~/bin verschieben und der Tunnel kann jederzeit gestartet werden.

Da das Tunnel Aufbauen von meiner Server Management Software YaSvenT erledigt wird, benutze ich inzischen das Sktipt allerdings fast nicht mehr

Kommentare: keine

Ramdisc - Maximum Performance

05.11.2008, 21:09

Wow, wow, wow. RAM wird diese Tage immer billiger, man bekommt die 8 GB schon für um die 80 Euro. Wer es wirklich übertreiben will kann natürlich auch auf die 32 GB kommen. Da fragt man sich dann auch langsam, wohin mit dem ganzen RAM. Wenn ich ehrlich bin, komme ich mir langsam ein bisschen seltsam vor mit meinen bescheidenen 2 GB. Aber auf der anderen Seite brauche ich meist nichtmal die zwei, und was soll man dann mit den übrigen 30 GB RAM machen? Da kommt dann z.B. die Ramdisk ins Spiel:

Anstatt die Dateien auf den langsamen Festplatten zu lassen, kann man sich natürlich eine flash-Festplatte kaufen. Aber wenn der RAM für heutige Anwendungen sowieso eher überdimensioniert ist, warum nicht gleich auf den RAM schreiben? Ein Nachteil: Man muss den Platz auf der Festplatte reservieren für Backups und Reboots. Denn sollte man seinen Rechner mal neu starten sind die Daten, da im RAM, eigentlich weg. Noch ärgerlicher, wenn der Saft weg beleibt. Doch mit ein paar kleinen Tricks kommt man da auch drum rum.

Doch erstmal zum Einrichten der Ramdisk (unter OpenSUSE). Da OpenSUSE anders als z.B. Debian standardmäßig keine Ramdisks zur Verfügung stellt, reicht uns für den Anfang eine kleine (1 GB) tmpfs-Partition. (Verzeichnisse natürlich angleichen)

mkdir ramd
cat /etc/fstab
cat /etc/fstab > fstab.txt
echo 'tmpfs /home/amoebe/Desktop/ramd tmpfs size=1g 0 0' >> /etc/fstab
mount /home/amoebe/Desktop/ramd/
df -T ramd/
# Ausgabe:
# Dateisystem   Typ    1K-Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
# tmpfs        tmpfs     1048576         0   1048576   0% /home/amoebe/Desktop/ramd

Na also. Kaum kopiere ich eine größere (~700 MB) Datei in das Verzeichnis, sehe ich im Systemmonitor, wie der ausgelastete RAM-Platz hoch geht... Nachdem ich nun 2 Kopien der Datei habe, eine auf der Festplatte und eine im RAM, lasse ich md5sum als Benchmark drüber laufen. Zuerst die Datei auf der Festplatte:

time md5sum groß.avi 
# 75dd50ae473ccba7e082aaa681853919  groß.avi 
# 
# real	0m29.759s
# user	0m1.956s
# sys	0m0.768s
time md5sum groß.avi 
# 75dd50ae473ccba7e082aaa681853919  groß.avi 
# 
# real	0m21.963s
# user	0m1.728s
# sys	0m0.584s

Wie man sieht, jedes Mal so um die 30 Sekunden. Doch ich musste leider mit ansehen, wie der Inhalt meiner schönen Ramdisk auf der Festplatte in den Swap geschrieben wurde, da die Datei sonst nicht mehr in den RAM gepasst hätte.

Jetzt wollte ich natürlich wissen, wie schnell die Ramdisk ist. Beim ersten Aufruf konnte ich schön den Swap zurück auf 0 gehen sehen, was natürlich auch einige Zeit in Anspruch genommen hat:

time md5sum vtemp/groß.avi 
# 75dd50ae473ccba7e082aaa681853919  ramd/groß.avi 
# real	0m35.570s
# user	0m2.128s
# sys	0m2.168s

Nicht sehr überzeugend. Doch die Ramdisk war ja nicht im RAM, konnte also nicht ihre ganze Stärke ausspielen. Doch jetzt, da wir die Datei wieder im RAM haben, sieht das Ganze schon besser aus:

time md5sum vtemp/groß.avi 
# 75dd50ae473ccba7e082aaa681853919  ramd/groß.avi 
# 
# real	0m2.536s
# user	0m2.040s
# sys	0m0.416s
time md5sum vtemp/groß.avi 
# 75dd50ae473ccba7e082aaa681853919  ramd/groß.avi 
# 
# real	0m2.444s
# user	0m1.984s
# sys	0m0.436s

Das bedeutet, wenn wir eine Ramdisk benutzen müssen wir noch mindestens so viel Platz im RAM lassen, wie unsere normale Arbeitsumgebung benötigt. Interessant, dass md5sum keine Kopie der Datei im RAM gemacht hat.

Jetzt könnte man natürlich noch mit einem Cronjob die Ramdisk regelmäßig mit der Festplatte abgleichen. Oder mit einem SVN-Repositry. Dann kann man sogar Änderungen verfolgen und rückgängig machen. Beim Herunterfahren kopiert man den Inhalt der Ramdisk auf die Felsplatte und lädt ihn beim hochfahren wieder. Das könnte natürlich bei größeren Datenmengen etwas lästig werden, aber wenn man einen Suspend-Hook bastelt, der den Inhalt kurz mit dem Repository abgleicht, dann kann man den Computer beruhigt in Suspend 2 RAM fahren ohne dass Datenverlust zu befürchten ist, falls doch mal jemand übers Kabel stolpert o.ä.

Interessant könnte es natürlich werden, wenn man beim Booten alle Programme in die Ramdisk speichert. Also mein gesamtes OS mit allen Programmen hat zurzeit 9,1 GB. Bei den 8 GB wird es also ein bisschen sehr knapp, aber bei 12 GB sollte es schon ganz gut klappen. Dann will ich gar nicht wissen, wie schnell sich die Programme laden.

Andrerseits ist das alles irgendwie noch ein bisschen sehr aufwändig, da lasse ich lieber alle Programme laufen und baue mir ein ordentliches RAID5 auf, dann kann (fast) nichts schief gehen, und schnell ist es auch noch. Wenn ich allerdings mal ein größeren RAM habe und dann an einer größeren Datei arbeite, vor allem mit unterschiedlichen Programmen, aber nicht gleichzeitig, könnte ich auch die Ramdisk zurückgreifen. Beim Filme schneiden könnte das äußerst nützlich sein.

Kommentare: keine
« Vorherige Seite [ Seite 1 2 ]
 
Χρόνογραφ
© 2008-2012 by Bernhard Häussner - Impressum - Login
Kurz-Link zur Homepage: http://1.co.de/