[ENC]BladeXP's Blog

Was die Welt nicht alles braucht!

Torrents mit mktorrent erstellen

geschrieben von encbladexp am 19.05.2012 19:03:00.

Eine effektive Methode um eine große Datenmenge Ressourcenschonend an eine Gruppe von Personen zu verteilen ist nach wie vor Bittorrent, was u.a. daran liegt das kein einzelner Host sich um den ganzen Traffic kümmern muss sondern dies auf viele verteilt wird.

Ein Vorteil gegenüber Sharehostern ist auch das die Daten nicht bei einem mehr oder (meistens) weniger vertrauenswürdigen Provider rumliegen. Wer glaubt das ein Gewinnorientieres Unternehmen (Sharehoster sind das!!!) viel Wert auf die Sicherheit der Daten legt glaubt meiner Meinung nach auch das ein Zitronenfalter die Zitronen faltet ;-)

Ich empfehle für Torrents immer alles in 2-3 große Dateien zu packen, da meine Zielpersonen nach wie vor alle Linux oder ein anderes anständiges System verwenden packe ich die ganzen Dateien (Bilder, Videos, Dokumente) immer in ein Tar Archiv:

tar cf torrent-daten.tar torrent-daten/
Ob eine Kompression sinnvoll ist muss jeder selbst entscheiden, bei Bildern und Videos ist der Vorteil aber meistens zu vernachlässigen.

Nun benötigt man nur noch das schöne Tool mktorrent welches bei jeder brauchbaren Distribution in den Paketquellen zu finden sein sollte. Mit diesem kann man nun die benötigte .torrent Datei erzeugen:

mktorrent -p -a http://tracker.stefan-betz.net:6969/announce/ -c "Coole Bilder, P0rn und vieles mehr" torrent-daten.tar
Je nach Datenmenge kann dies eine ganze Zeit lang dauern, auf brauchbarer Hardware schafft man aber mehrere Gigabyte an Daten in wenigen Sekunden. Der Schalter -p sorgt dafür das für dieses Torrent nur dieser Tracker verwendet wird und auf andere Wege der Peer Discovery (dem Suchen nach Seedern/Leechern) verzichtet wird. Bei einem öffentlichem Torrent wie z.B. einer Linux Distribution kann und soll man dieses Flag weglassen.

Jetzt muss man dem Tracker (sofern es kein öffentlicher ist) noch erklären das dieser eben dieses Torrent verteilen soll, darauf gehe ich an dieser Stelle nicht ein, da sich dies von Dienst zu Dienst und von Tracker zu Tracker unterscheidet. Bei einem komplett offenen Tracker ist kein zusätzlicher Schritt erforderlich!

Hat man dies getan kann man loslegen, und zwar indem man seinem eigenen Torrent Client sowohl das Torrent als auch die Quelldaten unterschiebt. Ich selbst verwende immer gerne Transmission als Daemon auf meinen Servern und erkläre das daher mal mit eben diesem:

mv torrent-daten.tar /srv/transmission/download/
transmission-remote -a torrent-daten.tar.torrent
Dies wird von Transmission durch eine Meldung bestätigt, über die Weboberfläche sieht man nun das dieses Torrent vollständig vorhanden ist, der Status ist daher "Seeding".

Jetzt ist der Zeitpunkt an welchem man die .torrent Datei verteilen darf, wenn jeder seinen Torrent Client weiterlaufen lässt verteilt sich so die Bandbreite unter der ganzen Gruppe und niemand muss einen Spiegelserver oder ähnliches aufsetzen.

Goodbye Xencon

geschrieben von encbladexp am 19.05.2012 19:01:00.

Wie in einem anderen Artikel schon beschrieben habe ich ja die letzten Tage/Wochen/Monate meinen alten Hetzner Server abgelöst. Auf dem Weg dorthin konnte ich viele verschiedene Hoster von vServer Testen.

Einer von diesen war Xencon, welchen ich über das freiesMagazin kennenlernen durfte. Der Anbieter war damals nicht unbedingt der günstigste, hatte aber einen sehr guten Service und brauchbare Qualität. Als Basis wurde Xen eingesetzt was sehr vielversprechend ist.

Nachdem am Anfang alles lief, häuften sich jedoch mit der Zeit die Probleme, Downtimes wurden öfters und man merkte das der Support von den Problemen auch nur noch angenervt ist (die Server werden bei Hetzner gehostet, es handelt sich also um die gleichen Desktop Kisten welche auch Hetzner vermietet). Da ich relativ geduldig bin habe ich mir das eine ganze Zeit lang mit angesehen, parallel dazu habe ich neue Hostingmöglichkeiten gesucht, und bin somit durch einen guten Bekannten auf ServerWay aufmerksam geworden.

So langsam hoffe ich aber das meine Liste von Hostern wo ich nicht mehr hin will nicht noch länger wird, auf dieser Liste wären aktuell folgende Hoster:

  • Hetzner (Probleme durch Xencon, Berichte von einigen Bekannten, teils eigene Erfahrungen)
  • Xencon (wegen Hetzner)
  • Loomes (nehmen das mit der Werbung nicht so ganz genau, langer Streit im Kündigungsfall)
Das sind nur die Anbieter welche dedizierte oder vServer anbieten, und auch nur die bei denen ich schon selbst Kunde war.

Nicht aufgelistet habe ich die (unzähligen) Provider welche ich nur mal kurz für ein paar Wochen probiert habe oder welche OpenVZ als Basis verwenden.

Wer auch fehlt ist 1&1, da ich den ganzen Konzern so gut es geht meide (persönliche Erfahrungen mit verschiedenen Produkten von diesem Saftladen).

Goodbye Hetzner

geschrieben von encbladexp am 19.05.2012 19:00:00.

Viele Jahre habe ich (zufrieden) einen dedizierten Server (aus echtem Blech) bei Hetzner verwendet. Dieser diente als Arbeitstier für mein (ehemaliges) Nebengewerbe und natürlich auch um meinen ganzen privaten Krempel brauchbar zu hosten, dies wären:

  • E-Mail
  • Jabber
  • Blog
  • VPN
Also insgesamt nichts weltbewegendes für einen Server den sich jemand mietet.

Durch die Aufgabe meines Nebengewerbes ist mir aber natürlich ein 59€/Monat Server etwas zu Teuer, zumal ich privat werde 4GB RAM noch 500GB Plattenplatz sinnvoll ausnutzen würde.

Der erste Versuch diesen zu ersetzen waren übrigens auf 2 Hetzner vServer auf KVM Basis umzusteigen, das lief nicht sonderlich gut, es kann aber auch sein das dies dem damals noch recht neuem Produkt (Hetzner hat erst damit angefangen) geschuldet war.

Aktuell habe ich meine Dienste auf 2 vServer verteilt, bei 2 verschiedenen Anbietern um eine gewisse Ausfallsicherheit zu haben, und natürlich um Backups zwischen den 2 Systemen anfertigen zu können.

Projekt zu verschenken: pyNeighborhood

geschrieben von encbladexp am 08.05.2012 20:40:00.

Aktuell Räume ich meine ganzen Projekte, die ich mal vor Jahren angefangen habe etwas aus. Dazu zählt auch pyNeighborhood welches ich gerne an jemanden verschenken würde.

Hier die Anforderungen, d.h. Wissen über diese Punkte müsste man schon mitbringen:

  • Python
  • PyGTK & Glade
  • Samba / CIFS
  • Versionskontrollen wie bzr

Hauptgrund für die weniger gewordene Zeit ist das ich meiner Aufgabe als Administrator bei ubuntuusers.de und meiner Verantwortung als Mitglied der Piratenpartei nachkommen möchte ohne das mein Privatleben zu sehr darunter leidet.

Sollte sich für pyNeighborhood niemand finden würde ich das Projekt auf Launchpad stilllegen lassen und die entsprechenden Paketbetreuer darum bitten das Paket aus den Repositories zu entfernen, es hat keinen Sinn Pakete in den Quellen zu haben welche wohl nie mehr Updates erfahren werden.

Speedport W723V Typ A: Energieverbrauch

geschrieben von encbladexp am 06.05.2012 11:57:00.

Bei uns in der Gegend wird dieses Jahr etwas in Richtung Breitbandausbau unternommen, das bedeutet ich bekomme wohl im Laufe des Jahres eine Bandbreite von 6-8 MBit, was natürlich ein großer Fortschritt ist.

Da ich jemand bin der gerne schon vorab alles erledigt hat, habe ich mir bei meinem ISP (Deutsche Telekom) oben genannten Router besorgt.

Ich habe dabei nicht vor das Teil tatsächlich als Router zu verwenden, es dient mir lediglich als DSL Modem und wird daher nicht viel tun. Aus diesem Grund ist es mir natürlich wichtig wie viel Energie das Gerät für diese einfache Aufgabe benötigt.

Um es kurz zu machen benötigt man bei abgeschaltetem DECT und WLAN ca. 7 Watt, was ich gerade noch so OK finde. Schaltet man DECT + WLAN an ist man bei ca. 8.5 Watt.

Arch Linux procps Update

geschrieben von encbladexp am 05.05.2012 09:07:00.

Für Arch Linux gibt es seit gestern/heute ein Update von procps auf procps-ng welches folgenden Meldung generiert wenn man an der /etc/sysctl.conf etwas verändert hat:

warning: /etc/sysctl.conf saved as /etc/sysctl.conf.pacsave

Dies sollte man nicht einfach ignorieren, denn wenn man dort z.B. IP-Forwarding aktiviert hat wäre diese Einstellung nach dem Reboot weg da procps-ng eine "frische" Konfiguration anlegt bei welcher alle Einstellungen dem Standard entsprechen.

Als Lösung kann man einfach die Datei /etc/sysctl.conf durch die /etc/sysctl.conf.pacsave überschreiben, dann greift die vorherige Konfiguration wieder. Alternativ kann man auch alle Einstellungen in einer neuen Datei mit der .conf Endung im Verzeichnis /etc/sysctl.d anlegen, diese wird dann auch beim booten gelesen.

Wenn der Proxy jammert…

geschrieben von encbladexp am 05.05.2012 08:43:00.

Seit ein paar Tagen nervt mich auf der Arbeit Firefox alle 2-3 Minuten ich möge mich doch bitte am Proxy der Firma authentifizieren. Natürlich habe ich dies schon längst getan.

Mit einem meiner Lieblingsspielzeuge (Wireshark), konnte ich aber relativ schnell feststellen woher dieses nervige Problem kommt: Das Plugin HTTPS Everywhere versucht regelmäßig eine Verbindung zu einem Server der eff herzustellen, dies dient der SSL Observatory welche in den Optionen von diesem Plugin ausgeschaltet werden kann.

Bis dieser Bug im Plugin/Addon gefixt wurde sollte man dies tun, außer man hat Lust alle 2-3 Minuten seine Proxyauthentifizierung erneut durchzuführen ;-)

Wer einen Proxy ohne Authentifizierung verwendet merkt von diesem Problem natürlich nichts.

AES-NI Verfügbarkeit überprüfen mit TrueCrypt

geschrieben von encbladexp am 16.04.2012 15:44:00.

Häufig stellt sich bei vielen die Frage ob eine Verschlüsselung viel Performance kostet, eine Frage die ich gerne mit dieser Gegenfrage beantworte: Hast du AES-NI?

Hintergrund ist das ohne entsprechende Hardwareunterstützung der CPU die komplette Verschlüsselung relativ aufwändig durchführen muss, dies Kostet Zeit, Performance und gerade bei mobilen Geräten auch ordentlich Energie.

AES-NI ist eine dieser Hardwareerweiterungen welche in vielen modernen Intel Prozessoren zu finden ist (bei AMD ist man da leider im Moment noch recht verloren), aber leider von manchen BIOS / UEFI Implementierungen nicht aktiviert wird. Hier gibt es folgende Möglichkeiten:

  • AES-NI kann im BIOS einfach aktiviert werden (meistens dort wo auch VT, VT-d & Co zu finden sind)
  • Es gibt keine Option für AES-NI, jedoch bietet der Hersteller ein Update an um dies freizuschalten
  • Der Hersteller ist einfach nur unfähig und man hat keine Chance außer zu hoffen
Über die Konsole kann man recht einfach herausfinden ob AES-NI vorhanden ist, und zwar über diesen Befehl:
grep aes /proc/cpuinfo | wc -l
Wenn man hierbei einen Wert größer als 0 sieht ist der Support sowohl im CPU vorhanden als auch aktiviert.

Was AES-NI in der Praxis bringt kann man ganz einfach mit TrueCrypt testen. Und zwar gibt es dort im Menü unter Tools->Benchmark ein kleines Tool mit welchem man die Geschwindigkeit der installierten CPU in Sachen Verschlüsselung testen kann. AES-NI Support gibt es übrigens erst ab Version 7 von TrueCrypt, je nach Distribution ist also ein Backport oder PPA erforderlich um dies auf alten Systemen testen zu können.

In der Regel sollte man mit aktiviertem AES-NI locker Werte im Bereich > 1GB/s erreichen ;-)

Taskwarrior 2.0 in Arch

geschrieben von encbladexp am 01.04.2012 13:07:00.

Nach Fedora und Cygwin hat nun auch Arch Linux Version 2.0.0 von Taskwarrior in den Paketquellen.

Es wird natürlich noch einige Zeit dauern bis diese Änderung auch bei allen Mirrors angekommen ist, in der Zwischenzeit sollte man aber zumindest mal die Release Notes gelesen haben, da sich u.a. einiges an der Syntax geändert hat.

GNOME3 und der nVidia 295.20 Treiber

geschrieben von encbladexp am 18.03.2012 12:59:00.

Seit einiger Zeit gibt es ja den nVidia Treiber in Version 295.20, leider gibt es in eben dieser Version einen Bug: Die GNOME Shell stürzt beim verwenden der Suchfunktion ab.

Als Fehler findet man dann im Syslog etwas über die libnvidia-tls.so welche einen Speicherzugriffsfehler verursacht. Von dem Problem betroffen sind verschiedene Linux Distributionen, und in allen welche diesen neuen Treiber haben gibt es auch ein Ticket im Bugtracker:

Es gibt aber ein relativ einfaches Workaround für dieses Problem:

echo > ~/.local/share/recently-used.xbel
sudo chattr +i ~/.local/share/recently-used.xbel
Das ganze sorgt dafür das die Information über zuletzt verwendete Dateien verloren gehen, zusätzlich wird dafür gesorgt das die Datei nicht wieder mit neuen Informationen gefüllt werden kann. Hierzu kennen die meisten Linux/Unix Dateisysteme ein Attribut welches eine Datei unverwundbar macht. Auf einem NFS Server, also wenn /home auf einem NFS Share liegt muss dies natürlich am Server gemacht werden, da chattr nicht über NFS funktioniert.

Sollte es demnächst ein nVidia Update geben welches dieses Problem fixt genügt es dieses Attribut wieder zu entfernen:

sudo chattr -i ~/.local/share/recently-used.xbel
Sollte man kein sudo verwenden muss man auf eine andere Möglichkeit ausweichen um den nötigen Befehl als root auszuführen, normale Benutzer können dieses Attribut nicht setzen.