Eben grade bin ich fröhlich auf einem System rumgeturnt und sogar auch noch mit nano in den Config dateien rumhantiert.
Was mich immer genervt hatte war dass backspace und delete die gleiche Belegung hatten. Beide haben nach Rechts gelöscht und nicht abwechselnd nach links und nach rechts, wie es eigentlich sein sollte.
Aufjedenfall hat mich das ganze so genervt dass ich da echt schon in den Wahnsinn getrieben wurde.
Wie man das ganze dann ziemlich halb elegant löst in dem man in der /etc/nanorc die Zeile
# set rebinddelete
Auskommentiert. Und schon hat man endlich es wieder auf normal gestellt. Supi!
Related posts
Eine neue kleine Reihe. Tools ohne die man eigentlich nicht mehr Leben kann. Heute: Dropbox.
Dropbox ist ein Dienst mit dem man Dateien in einer Cloud ablegen kann. Einem Serververbund. Das ganze wäre relativ uninteressant wenn man nicht einen unglaublich coolen Client für wirklich jede(!) Plattform hat. Man hat die Möglichkeit auf die Dropbox entweder per Webinterface oder aber einen Linux, Windows, Mac OS Client zu benutzen. Das ganze wäre auch nicht der totale Wahnsinn wenn diese Dropbox sich nicht auf allen Systemen synchronisieren würde. Die Daten werden letzendlich auf einer "Amazon S3" Cloud abgelegt. Finde ich toll und nutze das ganze bestimmt schon über 1 Jahr.
Wichtige Dateien und wo man ein bisschen Paranoider ist kann man in einem Truecrypt Container ablegen.
Insgesamt sicherleich einer meiner wichtigsten Tools.
Benutzt doch auch bitte meinen Ref-Link dahin. Damit bekomme ich zumindest 250MB mehr Speicherplatz.
Was sind euren wichtigsten Tools? Vorschläge? Alternativen?
Related posts
Meine Abschlussprüfung dreht sich um das Thema "Hochverfügbarkeitssysteme". Ich baue dort ein Hochverfügbarkeitssystem für die Firmenwebsite auf mit Hilfe von DRBD und Hearbeat auf Linuxbasis.
Das Thema ist hoch interessant weil es damit möglich ist Kostengünstig ein System aufzubauen was eine hohe Erreichbarkeit hat. In meinem Fall waren es zwei Dell Poweredge 850 Server die in getrennten Lokationen aufgestellt waren um einen Ausfall durch Netzwerkequipment auszuschließen. Die Verfügbarkeit des Systems sollte sich also auf ca. 99% belaufen.
Die Server sind über ein Crossoverkabel verbunden. Über dieses replizieren sie sich und Heartbeat checkt ob der andere Host erreichbar ist.
Aber was passiert wenn das Crossover Kabel defekt ist?
Jeder Host würde also denken dass der andere nicht erreichbar sei, beide würden in den "Master" Modus gehen und fröhlich in die Dateien schreiben. Schliesslich sind sie Master.
Wie kann man das beheben?
Am elegantesten mit dem STONITH Verfahren, also Shoot the other node in the head dies kann über ein weiteres serielles Kabel geschehen oder aber über eine IP gesteuerte Steckdosenleiste an diese der Slave ein "Shutdown" Signal sendet. Man lässt also den Slave, den Ersatzserver, übernehmen weil man davon ausgeht dass mit dem Master was nicht stimmen kann. Dieses Shutdown-Signal sagt dann der Steckdosenleiste dass die Stromzufuhr vom Masterserver unterbrochen werden soll. Dieses Verfahren kostet aber Geld und es wird in meinem Fall nicht davon ausgegangen dass das Crossover Kabel beschädigt werden kann.
Wie löst man das ganze also kostengünstig?
Ich habe es damit gelöst dass Heartbeat erst die Interne IP kontrolliert und sollte diese nicht erreichbar sein wird über das Externe Netz kontrolliert ob der Host darüber erreichbar ist.
Wenn erst beide Wege zu einem negativen Ergebnis führen wird eingeschritten und der Slave übernimmt seinen Dienst.
Das ist natürlich mehr ein Workaround aber immerhin führt es zu einem brauchbaren Ergebnis. Die 99,9% pro Jahr sollte man damit ohne Probleme erreichen.
Hat man das halbwegs verstanden was ich versucht habe zu erklären? 
Related posts
Ich musste mich am Ende tatsächlich nochmal mit Virtualisierung auseinandersetzen. Also mehrere Systeme auf einer Hardware. Ich finde das Thema Virtualisierung äußerst ansprechend und denke dass ich damit auch in der Zukunft noch mehr zu tun habe.
Xen ist ein Hypervisior System. Das heisst dass es damit möglich ist mehrere Systeme auf einer Hardware zu installieren. Diese Systeme, oder wie Xen sie bezeichnet, Domänen sehen weder die anderen Domänen noch den Wirt. Sie denken von sich dass sie selbst auch physikalische Hardware wären.
Vorteile von Xen sind ganze klar die Performance gegenüber VMware. Ein paar Werte von Golem:
Insbesondere HDD Write/Read sowie Netzwerkperformance.
VMWARE: Write: 30-40 MB/s
XenServer: Write 80-100 MB/s
VMWARE: Read 140-160 MB/s
XenServer: Read 100-140 MB/s
Netzwerkperformance bei Xen/VMWARE DOWNLOAD vom IIS/APACHE:
XenServer über 100 MB/s
VMWARE nur 40-60 MB/s
Teilweise doppelt so schnell! Das kommt daher dass die Xen Architektur direkt auf die Hardware zugreifen kann. VMware emuliert die Hardware und hat daher natürlich seine Perfomance einbussen.
Natürlich leidet darunter die Skalierbarkeit aber hey, dafür hat man ein performantes System!
Korrigiert mich wenn ich falsch liege, aber irgendwie musste ich die Zeit nutzen wo der Xen Server mir mein Filesystem baut. Vielleicht schreibe ich wieder eine Anleitung wenn ich damit fertig bin 
Related posts
Nach vielem hin und her habe ich es endlich geschafft einen Teamspeak3 Server zu installieren. Anfangs lief es irgendwie nicht mit SQLLite. Das ganze läuft jetzt auf einem Debian Lenny 32bit
Hier schilder ich einfach mal kurz wie es denn funktioniert:
Zuerst legen wir einen teamspeak User an dem aber der login verboten wird:
adduser --disabled-login teamspeak
dann holen wir uns das Paket mit wget und entpacken es mit tar xzf
Danach verschieben wir den ganzen Ordner nach /opt
mv teamspeak3-server_linux-x86 /opt/ts3
Jetzt geben wir dem User "teamspeak" den gesamten Ordner
chown -R teamspeak /opt/ts3
Jetzt haben wir gott-sei-dank endlich ein Start Stop Script was keine Screen Session mehr benötigt. das Verschieben wir einfach nach /etc/init.d/ oder aber wir machen einen Symlink oder wir legen dort einfach eine neue Datei an. Hauptsache es ist folgender Inhalt vorhanden:
#! /bin/sh
### BEGIN INIT INFO
# Provides: teamspeak
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: S 0 1 6
# Short-Description: TeamSpeak Server Daemon
# Description: Starts/Stops/Restarts the TeamSpeak Server Daemon
### END INIT INFO
set -e
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="TeamSpeak Server"
NAME=teamspeak
USER=teamspeak
DIR=/opt/ts3
DAEMON=$DIR/ts3server_startscript.sh
#PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
cd $DIR
sudo -u teamspeak ./ts3server_startscript.sh $1
Wichtig ist dass man "sudo" installiert hat weil der ganze Spaß dann nicht läuft und er es wohlmöglich als root ausführt. So wechselt er den User auf "Teamspeak" und führt dann den Spaß aus.
Jetzt natürlich noch die Rechte richtig setzen mit:
chmod 755 /etc/init.d/teamspeak
Jetzt ist die Installation eigentlich schon abgeschlossen und wir können einen ersten Test wagen:
/etc/init.d/teamspeak start
Jetzt probieren wir das ganze einfach mal und beim ersten Start bekommt man noch einen Token und serveradmin und Passwort genannt. Diese sollte man aufjedenfall sich notieren und rauskopieren. Den Token benötigt man für die Serveradministration, die nicht mehr über ein Webinterface sondern schlicht über den Client selbst erfolgt.
Related posts