Aleks ihm sein Blog home :: computers
[ Wir haben noch Hirn hinten im Haus ]

Das ist mein Blog.

Hier gibts, was ich tue, getan habe und vielleicht tun werde. Auch, wenn und weil das total unwichtig für den weiteren Verlauf der Geschichte ist. Viel Spaß damit.

Wer mich möglichst zeitnah erreichen und/oder beschimpfen will, versuche dies per Email (s.u.) oder im ircnet.

TMG §5 Kontaktdaten.

←Maerz→
Mo Di Mi Do Fr Sa So
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Einträge nach Kategorien

Einträge nach Datum

RSS-Feed
Startseite

auch lesenswert
Nils' blog
Lestighaniker
Das Nuf advanced
Schandmännchen
Extra3
Titanic
Dilbert
The Register
Boing Boing
Daily WTF

[ blosxom ]

[ creative commons ]

28.01.2010

14:28 Uhr  Facebook - Privacy Wahnsinn und Web2.0 Selbstmord


Da liest man nen RSS-Feed und klickert auf den Artikel, SPON poppt auf, und in der linken Spalte taucht meine Hackfresse auf. WTF?

Noch mal geguckt. Ja, its me. Mein Facebook-Account irrlichtert in einem Widget durch Spiegel Online, hat sich irgendwo ein Cookie aus meinem Browser gepuhlt und die richtigen Schlüsse gezogen.

Nach den anderen, gruseligen Erfahrungen mit FB reicht mir das jetzt, da ich sowieso keinen Mehrwert aus der FB-Community ersehen kann - ich spiele keine Browserspiele, trete auch keinen Gruppen bei, in denen man sich wünscht, anderen ihre virtuellen Bauernhöfe zu verbrennen, wenn es noch eine Farmville-Anfrage gibt, und der meiste inhaltslose Dreck, den meine 'Freunde' dort absondern, interessiert mich auch nicht sonderlich, für meine narzistischen Neigungen reichen mir Twitter und vorallem mein Blog komplett aus.

Facebook hat nach meiner Testphase von etwa drei Wochen genau ein gutes: Ich kann meine eigenen (ebenfalls inhaltsleeren) Ergüsse aus Twitter und meinem Blog automatisiert einer größeren Öffentlichkeit anbiedern, weil man Twitter und RSS-Feeds in FB anflanschen kann.

Das schlechte Gefühl, daß sich eine Facebook-App wohlmöglich automagisch auf dem mobilen Kommunikationsendgerät durch die dort abgelegten Telefonnummern frist und diese bei FB gegencheckt, ist ziemlich gruselig und den Grund (Avatarbilder für das eigene Adressbuch auf dem mobilen Telekommunikationsendgerät zu ziehen) glaube ich eh nicht.

Dann hab ich mich mal durch die Leute geklickert, die auf der gleichen Schule wie ich waren (naja, wohl eher sind), und z.B. im Slip und hautengen Oberteil auf einem Bett posieren - ohne einen Gedanken daran, diese Bilder nie wieder (nie nicht überhaupt gar nicht wieder) entfernt zu bekommen, oder Leute, die anscheinden den ganzen Tag während der normalen Büroarbeitszeiten Farmville spielen: Wollt Ihr Euch wirklich nie wieder irgendwo anders bewerben?

Ich nehm mir jetzt den Strick. Scheisse. Nicht mal das klappt, da sind gerade zu viele Selbstmorde am Laufen. Dann später, dann könnt Ihr Facebooker das hier wenigstens noch lesen, und versuchen, mich von meiner Tat abhalten!

Ja, mir ist klar, daß ich trotzdem Web2.0 Dinge tue und stelle hier im Blog oder per Twitter oder per Oerkswatch private Daten und Meinungen dar, aber da bestimme ich die Granularität einigermaßen selbst.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

07.12.2009

21:34 Uhr  Will it scale? Rechnen mit der Wolke - Amazon WebServices - Teil 2


Okay, nach den einführenden Worten zu den Amazon Webservices, nun mal etwas Butter bei die Fische - Arbeiten in der Cloud.

Der erste Schritt: Eine passende AMI finden und sich so hinfummeln, wie man es gerne hätte. Das geht mit ec2-describe-images, allerdings zeigt das folgende Kommando den Irrsin des Unterfangens an: 

$ ec2-describe-images -a | wc -l
     970

Dafür ist dann Elasticfox ganz gut, um ein genehmes Image zu finden - oder man muß entsprechend seinen Vorlieben filtern: 

$ ec2-describe-images -a|grep -i lenny|wc -l
      27

Ok, wenn man nach Debian AMIs sucht, kommt man schnell auf alestic, und kann sich das dort genauer ansehen. Ich hab mich dann erstmal für 

IMAGE   ami-b8446fcc alestic-32-eu-west-1/debian-5.0-lenny-base-20091011.manifest.xml \
063491364108    available       publii386     machine aki-02486376 ari-fa4d668e

entschieden, also die aktuellste Version eines i386 (im Gegensatz zu amd64, eine Kostenfrage) Minimalimages (die anderen haben schnell mal nen komplettes KDE/Gnome dabei) entschieden. AMIs gibts in drei unterschiedlichen Größen, wobei sich Größe auf CPU-Büms und Plattenplatz bezieht. Zum Spielen reicht die kleinste locker aus.

Dieses AMI startet man sich: 

$ ec2-run-instances ami-b8446fcc -k aleks-testkeypair 
RESERVATION     r-c8f104bf      737588137133    default
INSTANCE        i-0444b873      ami-b8446fcc    pending \
aleks-testkeypair       0               m1.small \
2009-11-28T20:36:14+0000      eu-west-1a      aki-02486376 \
ari-fa4d668e            monitoring-disabled

Damit wird eine Instanz dieser AMI in der eigenen Umgebung gestartet, und zwar mit der Security-Group default, und meinem passenden ssh-Key in die AMI gefrickelt (das erzeugen mit ec2-add-key ist nervig und untypisch für Leute, die ssh-keygen gewohnt sind).

Nach einer Minute (oder so, kann man mit ec2-describe-instances überprüfen, das pending muß durch running ersetzt sein) ist die Instanz gebootet, und man kann sich, nachdem man in der Default-Security-Group die eigene IP freigeschaltet hat 

$ ec2-authorize default -P tcp -p 22 -s 213.39.215.21/32
GROUP           default
PERMISSION              default ALLOWS  tcp     22      22 \
FROM CIDR    213.39.215.21/32

per ssh dort einloggen: 

$ ssh -i .ec2/id-aleks-testkeypair root@ec2-79-125-34-231.eu-west-1.compute.amazonaws.com 

Amazon EC2 Debian 5.0.3 lenny AMI built by Eric Hammond
http://alestic.com  http://ec2debian-group.notlong.com

ip-10-227-89-159:~#

Und etwas umschauen, und sich die Instanz so hinfummeln, wie man es möchte (z.B. erstmal die normalen authorized_keys hinterlegen), und die Packages installieren, die man so normalerweise braucht. Achtung, stirbt die Instanz durch Deine Dummheit, kannst Du von vorne anfangen, Änderungen werden nicht wirklich gesichert (reboot funktioniert aber ohne Gedächnisverlust).

Will man die eigene Vermackelungen für die Nachwelt oder sich selbst erhalten, muß man aus dieser Instanz wieder ein AMI machen, dafür braucht man ein S3-bucket, x509-Key und Zertifikat, dazu auch noch die AWS-ID und die passenden Keys. Die x509-pems legt man auf der Instance ab, am besten dort, wo das AMI ge'bundled' wird, weil sie damit nicht in der neu erstellten AMI auftauchen (zur Sicherheit sollte man die nicht in AMIs rumliegen lassen). Ich mache das in /mnt.

Genauer: Ich habe dafür ein Skript gebaut, daß das alles sehr exemplarisch automatisiert (und z.B. vorher Services runterfährt und ein EBS umounted (dazu später mehr))

Das Skript muß natürlich auf der laufenden Instanz ausgeführt werden, die nachfolgenden Kommandos stammen nicht aus den ec2-api-tools, sondern aus den ec2-ami-tools :)

Letzlich ist das dann auch nur ein Kommando (wenn alle Keys da sind und kein EBS mehr im Weg rumgammelt): 

$ ec2-bundle-vol -d ${bundledir} -k ${pkkey} -c ${pkcert} \
 -u $awsuserid -r i386 -p ${imgname}

Genauer ist das im Skript erkennbar. Das Bündel muß dann ins S3-Bucket geladen werden, dazu gibts das Kommando ec2-upload-bundle 

$ ec2-upload-bundle -b ${s3bucket} -m ${bundledir}/${imgname}.manifest.xml \
-a $awsaccesskey -s $awssecretkey

Mit S3Fox kann man dann sehen, wie es im entsprechenden bucket anschwillt (das Bucket wird automatisch angelegt, wenn es noch nicht vorhanden ist).

Als letzte Amtshandlung muß man das entsprechende AMI noch im AWS registrieren - das geht wieder durch einen ec-api-tool-Aufruf, also lokal am Arbeitsplatz. 

$ ec2-register ${s3bucket}/${imgname}.manifest.xml

Dieses Kommando gebiert wiederum einen AMI-Namen, den man wiederum wie oben als neue Instanz laufen lassen kann, und für die man nun seine normalen sshkeys verwenden kann (wenn man sie reingefummelt hat). Allerdings sucht man dann eben nach dem eigenen Imagenamen zur Auswahl.

Ein Problem hat so eine Instanz aber noch, sie ist ziemlich vergesslich und sie ist nicht unter einer vorher bekannten IP ansprechbar. Die Vergesslichkeit regelt man mit einem EBS - elastic block storage, die IP-Vorhersage über Elastic-IPs.

Ein EBS legt man sich einfach mit ec2-create-volume an: 

$ ec2-create-volume -s 10 -z eu-west-1a
VOLUME  vol-aa8a6ec3    10              eu-west-1a      creating \
2009-11-28T23:19:26+0000

Die passende Zone kann man sich aus der Ausgabe von ec2-describe-instances herausfischen. Danach muß das EBS-Volume an die Instanz gebunden werden: 

$ ec2-attach-volume vol-aa8a6ec3 -i i-3c3fc34b -d /dev/sdb
ATTACHMENT      vol-aa8a6ec3    i-3c3fc34b      /dev/sdb \
attaching       2009-11-28T23:21:41+0000

Ab diesem Moment steht die Platte sdb der Instanz ztur Verfügung und kann normal partitioniert und formatiert werden.

Ein Tipp (das hat mich Tage gekostet): Wenn man in einer ursprünglichen Alestic-Instanz mit XFS rummacht, muss man zwingend Logversion 1 (mkfs.xfs -l version=1 /dev/sdb1) verwenden, sonst gibts beim ersten Zugriff ne Kernelpanic, und wenn man das Image mit den bisherigen Änderungen nicht gesichert hat, fängt man von weiter vorne wieder neu an. Die Ursache dafür scheinen Inkompatibilitäten in den von EC2 verwendeten Fedora-Kerneln mit den entsprechenden Debian-XFS-Modulen zu sein. Es gibt dazu reichlich Fundstellen im Netz.

XFS ist gut, weil man mit xfs_freeze und S3 sehr nette Backupstunts hinlegen kann, z.B. mit der Hilfe von ec2-consistent-snapshot, das auch noch ein FLUSH in den mysqld peitscht.

Ich verwende das aber bisher noch nicht, weil ec2-consistent-snapshot ein (jedesmal neues) EBS-Volume erzeigt und nicht in ein S3-Bucket schreibt. Da man den Namen nicht vorher weiß, ist ein sinnvolles Haushalten mit verschiedenen Snapshots aufwendig und letztlich durch den verbrauchten Speicherplatz teuer. Ich verwende stattdessen ein selbstgeschriebenes Skript, das mit Hilfe von s3cmd (s.u.) in ein S3-Bucket schreibt und dort Versionen mit vorhersagbaren Namen erzeugt, die es auch nach einer definierten Zeit wieder löscht.

Generell kann man sich das partitionierte EBS mounten, wie man lustig ist - ich habe mir das der Einfachheithalber erstmal unter /mnt/persistent gemounted, und alle Verzeichnisse oder Dateien, von denen ich weiß, daß sie sich unabhängig von der Maschineninstanz ändern (Home-Verzeichnisse, Datenbankspool, andere Spools, die man nicht verlieren will, Anwendungen, die unabhängig vom System gepflegt und upgedated werden, Konfigurationsdateien von Webservern, /usr/local, ... dort hin verschoben und dann ins System hineingelinkt.

Das EBS wird immer erst nach dem Booten an die Instanz gebunden, man sollte es also tunlichst vermeiden, dort zum Booten notwendige Dinge abzulegen.

Genauso wie das EBS läßt sich auch eine Elastic IP mit ec2-allocate-address bereitstellen und dann mit ec2-associate-address an eine Instanz binden. Das geht auch schon während des Bootens, also direkt, nach dem ec2-run-instances den Instanznamen preisgegeben hat.

Ich habe dafür ein Skript, daß eine passende AMI auswählt, mit den passenden security-groups startet, die IP dranklatscht, und immer wieder überprüft, ob der Status pending in den Status running gewechselt ist - wenn ja, wird das EBS attached.

Services, die auf Informationen auf dem EBS zugreifen, starten also nicht automatisch, bzw. brechen mit einer Fehlermeldung weg, wenn man das vorher weiß, kann man sich das aber entsprechend hinfummeln.

Die eigene Instanz läuft also - wichtig ist, immer daran zu denken, daß man nach Umbauten am System, die nicht im EBS zu liegen kommen, ein neues AMI erzeugen muß, um diese Änderungen für die Zukunft zu erhalten.

Es gibt die Möglichkeit, eine laufende Instanz direkt aus den AWS heraus zu überwachen, und bei bestimmten Triggern weitere, gleiche Instanzen zu starten - da fängt das Wolken erst richtig an. Damit habe ich aber noch nicht viele Erfahrungen, das reiche ich in einem gesonderten Artikel nach.

Praxis

Naja, es verhält sich wie ne normale Maschine :-)

Zum Arbeiten mit S3 hab ich noch s3cmd gefunden, damit kann man von der Shell aus in einem (oder mehreren) S3-Buckets herumfuhrwerken, das läßt sich aus meiner Perspektive in Skripten besser handhaben als als die im S3-Guide vorgestellten php, java, ruby, python, c++ und sonstigen Programmierbeispielen, um mal eben ne Konfiguration im Backup zu sichern und ähnliches. s3cmd funktioniert auch gut aus ec2-Instanzen heraus.
Debianer sollten nicht die paketierte Version verwenden, die kann z.B. kein -r (recursive). 

$ s3cmd ls
2009-11-25 09:11  s3://s2-master-img
$ s3cmd put Desktop/jahrbuch2009_export.pdf s3://s2-master-img
Desktop/jahrbuch2009_export.pdf -> s3://s2-master-img/jahrbuch2009_export.pdf  [1 of 1]
 13526575 of 13526575   100% in  206s    64.01 kB/s  done

Zur Praxis schreibe ich später noch mal was, wenn ich mehr rausgefunden habe.

Was kostet der Spaß?

Kurz: ich weiß es noch nicht genau.

Lang: Das AWS-Bezahlsystem ist eigentlich simpel, aber kompliziert, weil jeder kleine Furz einzeln abgerechnet wird.

Eine kleine EC2 Unix Instanz kostet z.B. in Europa USD 0.095 pro Stunde, dazu kommt Datenverkehr (USD 0.10 per GB rein und USD 0.17 per GB raus (wird billiger mit mehr Traffic). Dazu kommt EBS mit USD 0.11 pro GB im Monat für die Größe des Devices und USD 0.11 für 1.000.000 I/Os...

Okay, ich kann mir darunter nicht so irre viel vorstellen, Du auch nicht? Dafür gibts den Simple Monthly Calculator - der nicht so ganz simpel ist, will er doch Daten haben, die ich aus der hohlen Hand nicht einfach so weiß. Einfach mal selbst probieren...

Der dritte Teil wird etwas auf sich warten lassen, probiert einfach mal selbst damit rum.


[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

28.11.2009

23:05 Uhr  Erfahrungen im Rechnen mit der Wolke - Amazon WebServices - Teil 1



Okay, wenn der pointy-haired boss das so will, dann machen wir das mal.
Seit ungefähr 4 Wochen vor dem passenden Dilbert beschäftige ich mich mit Cloud Computing, und versuche herauszufinden, ob das für unsere Firma eine brauchbare Möglichkeit ist. Genauer, ob es für uns interessant ist, entsprechende Resourcen zu nutzen, weil sie angeblich schnell und auf den Punkt verfügbar sind, sehr gut skalieren und erst genau im Moment der Nutzung Kosten verursachen.

Ziel der Untersuchung ist einer der ganz großen Cloud Computing Anbieter, Amzon. Genauer AWS - Amazon WebService. Das gute daran: Jeder, der einen 'normalen' Amazonk-Account hat, kann darüber eventuelle Experimente abrechnen.

Da das für die meisten Leser ein relativ neues Feld sein wird, gibts erstmal ein paar AWS-Konzepte erklärt. AWS bietet sehr viel mehr als ich hier darstelle - siehe die Produktseite, ich beschränke mich hier erstmal auf EC2 und S3.

Grob gesagt stellt Amazon EC2 (Elastic Compute Cloud) die eigentlichen virtuellen Maschinen-Resourcen zur Verfügung. EC2 ist auf gute Skalierbarkeit und pay-per-compute ausgerichtet. D.h., es ist sehr einfach, zusätzliche, identisch konfigurierte Instanzen auch kurzfristig zu den vorhandenen dazuzustarten. Abgerechnet wird streng nach Verbrauch (CPU, Traffic, Plattenplatz, genutzte IPs usw). Was man nicht nutzt (und deswegen abschaltet), zahlt man auch nicht. Eine gute Einführung in die Konzepte gibts im EC2 GettingStartedGuide und die eigentliche Bedienungsanleitung im EC2 UserGuide. Da, wo mein Geschreibsel ins Nebulöse abgleitet, ist man beim Nachspielen gut beraten, diese Dokus zu lesen (die gibts auch als html und auch diverse weitere, gute Doku).

Amazon S3 (Simple Storage Service) bietet eine einfache Mögllichkeit, beliebige Daten im Netz vorzuhalten. S3 wird über eine eigene API angesprochen und kann nicht direkt als Filesystem in eine EC2-Instanz gemounted werden. Auch S3 wird streng nach Verbrauch (verbrauchter Plattenplatz, Traffic) abgerechnet.

Alle AWS Komponenten laufen selbst auch in Clouds, die Amazon als Regions bezeichnet. Derzeit gibt es zwei Regionen, eine an der US-Ostküste, eine in Europa. Wichtig ist hier nur, daß in der Regel alle Services in der gleichen Region läufen müssen, wenn diese in einem Projekt gemeinsam genutzt werden sollen. Ein Umzug in die andere Region ist möglich, aber umständlich.

Die konkrete Anzahl von Rechenzentren hinter diesen Regionen ist erstmal verborgen und unwichtig.

Im EC2 gibt es ein paar tolle Marketingschwurbel-Begriffe, die ich trotzdem verwende, weil ich sonst andere, die ebenfalls EC2 verwenden, nicht verstehe.

  • Die wichtigste Resource ist dabei ein AMI - Amazon Machine Image.
    Amazon (und auch andere) hält eine große Anzahl von unterschiedlichen AMIs zur Benutzung bereit, darunter befinden sich unter anderem auch Linux- und Windows-Images. Diese Images kann man sich so anpassen, wie sie für den eigenen Einsatzzweck am besten geeignet sind, d.h., die entsprechenden Packages installieren, die man immer benötigt, User und Keys hinterlegen usw.
    Hat man sich aus einem Default-AMI ein entsprechendes laufendes System zusammengeschustert, kann man dies in ein neues AMI überführen und entsprechend im AWS (genauer im S3) ablegen. Je nach Wunsch kann man dieses Image öffentlich zur Nutzung bereitstellen oder es nur selbst nutzen.
    Ein AMI ist grundsätzlich vergesslich - wird eine laufende Instanz abgeschaltet, gehen ALLE Änderungen, die seit dem Starten vorgenommen wurden, verloren, ebenso gehen alle dyanmisch zugewiesenen Resourcen verloren, wie IP-Addresse, ssh-hostkeys, gemountete externe Filesysteme. Dies betrifft allerdings keine Reboots.
    Aus diesem Grund ist an einigen Stellen ein Umdenken erforderlich, um die nichtvorhandene Persistenz des Filesystems durch andere Konzepte zu ersetzen.
  • Elastic IP - AWS verwendet für neu gestartete AMIs eine interne, nicht routingfähige RfC1918 IP-Adresse, die nicht persistent ist. Auf diese interne IP wird von außen über eine ebenfalls nicht persistente routingfähige IP genattet.
    Damit ein Angebot auch bei wechselnden AMI immer unter der gleichen IP (und damit letztlich einem DNS-Namen) erreichbar ist, gibt es das Konzept der Elastic IP.
    Damit kann eine IP unabhängig von laufenden AMI definiert werden, diese IP hat einen festen, einigermaßen vorhersagbaren DNS-Namen, und diese IP kann an eine gerade laufende AMI gebunden werden.
    Da die Elastic IP auf eine beim Start eines AMI nicht vorhersagbare IP genattet wird, wird ein anderer Weg benötigt, ein AMI intern persistent ansprechen zu können (Klassiker: Datenbank-Verbindung auf einen anderen Host).
    AWS verwendet ein DNS-System, das intern in der AWS anders auflöst als bei einer Anfrage aus dem Internet. Fragt man von Intern nach dem PTR der Elastic IP, bekommt man die interne IP des AMI, auf das gerade die Elastic IP gemappt ist. D.h., man kann den PTR als Hostnamen in Konfigurationsdateien sicher verwenden.
  • EBS - Elastic Block Storage ist ein in ein AMI hineinmountbares Blockdevice, das unabhängig von einer AMI existiert und damit als Persistenzlayer dienen kann.
    Mit EBS ist es möglich, Daten über einen Neustart hinaus zu erhalten. Das Blockdevice kann frei konfiguriert und z.B. mit einem Dateisystem versehen werden.
    Es ist möglich, mehrere EBS an ein AMI zu binden, allerdings ist es nicht möglich, ein EBS an mehrere AMI gleichzeitig zu binden.
    EBS verfügt über die Möglichkeit, snapshots vom Device zu erstellen, um es zu sichern oder es zu klonen und anderen AMI zur Verfügung zu stellen.
    In meinem Test-Projekt ist in jede laufende AMI-Instanz ein EBS als Partition gemounted und alle erhaltenswerten Daten (z.B. Userhomes, Anwendungsdaten, Datenbank-Daten, per AMI individuelle Konfigurationsdaten, ... sind entsprechend in die vorgesehenen Stellen im Filesystem des AMI hineingelinkt.
    Dabei darf man es nicht übertreiben - ein Linux bootet z.B. logischerweise nicht ohne ein lokales /etc. :-)
  • Die Security Groups stellen die Firewallkonfiguration des EC2 dar. Um für unterschiedliche Instanzen unterschiedliche Zugriffsmöglichkeiten zu ermöglichen, gibt es ein entsprechendes Gruppenkonzept.
    Das ist pille palle, das einzige, auf das man achten muß: Eine AMI kann nur VOR DEM START einer oder mehrerer Security-Gruppen zugeordnet werden.

Eigentlich kommt man mit dem oben dargestellten Möglichkeiten gut zurecht, allerdings nur, wenn man keine selbst vergurkten AMIs verwendet :-)

Die sinnvollste Möglichkeit, größere Datenmengen (z.B. eben AMIs) unabhängig von einer laufenden Instanz in der Amazon Wolke abzulegen, bietet S3 - Simple Storage Service. Zum S3 gibts auch wieder diverse Dokumentationen, Einstieg ist wieder der entsprechende GettingStartedGuide.

S3 ist nicht direkt mit mount als klassisches Filesystem mountbar, sondern über eine REST- bzw SOAP-API, für die es in jeder aktuell gängigen Programmiersprache Beispiele zum Anflanschen eigener Software gibt. Aktuelle Software zum Handhaben von Dateien (z.B. cyberduck aufm Mac, S3fox für Firefox und eben EC2-AMIs) hat entsprechende Schnittstellen implementiert.
Informationen werden in sogenannten buckets organisiert und bieten eine relativ granulare Möglichkeit der Zugangsberechtigungssteuerung.

Die AWS nutzen eine mehrstufige Authentifizierung, die sich auch je nach Komponente unterscheidet.

  • Für den Login in die AWS-Management-Webseite wird als Userkennung eine Emailaddresse und ein Password benutzt (die Amazonk-Buchladenkennung).
  • Für die direkte Arbeit mit EC2 und S3 benötigt man wiederum unterschiedliche Credentials, diese werden im AWS-Account generiert bzw. können dort ausgelesen werden.
  • Um einen Service anzusprechen, benötigt man die Accesskeys
  • Um AMIs zu bauen, benötigt man zusätzlich x509-Keys
  • Um sich auf Amis einzuloggen noch zusätzlich ssh-keys.

Neben den oben genannten Tools für S3 gibt es noch ein paar weitere, mit denen man sich an die Möglichkeiten von EC2 rantasten kann:

  • Die AWS Management Console ist per Webbrowser erreichbar, damit kann vorallem EC2 administriert werden. Von der Bedienung eher unhandlich, Benutzer, die Firefox verwenden, sollten lieber Elasticfox und S3Fox verwenden.
  • Elasticfox ist ein Plugin für Firefox und ermöglicht alle üblichen Operationen an EC2 per Webinterface.
    Achtung, die in Elasticfox verwendeten Tags sind LOKAL (werden nicht in die Cloud geschrieben) für den User, dem Firefox gehört - aus diesem Grund taugen die Tags auch nicht zur Namensgebung, wenn man im Team arbeitet.

Seine ganze geballte Kraft entfaltetet sich aber erst, wenn man die ec2-api-tools einsetzt, die man einigermaßen vernünftig skripten kann. Die ec2-api-tools sind in java geschrieben, und durch clevere wrapper für so ziemlich jede Betriebssystemsumgebung geeignet, wo man ein java und eine shell draufgewämst bekommt. Meine Beispiele beziehen sich auf nen Unix, genauer nen Mac. Das geht aber auch gut unter Windows.

Wenn man sich an die traditionellen Regeln für shell-Betrieb hält, und alle einigermaßen konstanten Parameter als Umgebungsvariablen exportiert ( 

$ set|grep EC2
EC2_CERT=/Users/alesti/.ec2/cert-test.pem
EC2_HOME=/usr/local/ec2-api-tools
EC2_PRIVATE_KEY=/Users/alesti/.ec2/pk-test.pem
EC2_URL=https://eu-west-1.ec2.amazonaws.com

), sind die Tools angenehm zu nutzen, ansonsten hat man schnell ekelhafte Kommandowürmer: 

ec2-describe-instances -K ~/.ec2/pk-test.pem -C ~/.ec2/cert-test.pem \
	-U https://eu-west-1.ec2.amazonaws.com i-04f60b73

gegen 

ec2-describe-instances i-04f60b73

Das Ergebnis ist in beiden Fällen (auf zwei Zeilen): 

RESERVATION     r-b07398c7 \
		358240633166 \
		testgroup,default
INSTANCE        i-04f60b73 \
		ami-370e2543 \
		ec2-79-125-2-112.eu-west-1.compute.amazonaws.com \
		ip-10-224-99-79.eu-west-1.compute.internal \
		running \
		0 \
		m1.small \
		2009-11-24T16:56:00+0000 \
		eu-west-1a \
		aki-02486376 ari-fa4d668e \
		monitoring-disabled \
		79.125.2.112 \
		10.224.99.79

Das kann man gut mit shell-Mitteln auseinanderfummeln und weiter verwursten.

Soviel erstmal zu den Basics, im folgenden zweiten Teil folgt dann der praktische Umgang mit AWS EC2 und S3.


[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

30.10.2009

17:12 Uhr  OSMC - Öberwachong öber all!


Und ich meine diesmal nicht Kameras und Schleierrasterfahndung, sondern die Beobachtung von Netzen, Rechnern und darauf laufenden Diensten auf Funktion - ein (leider) wichtiger Teil meines Jobs.

Gestern und vorgestern gab es dazu eine Konferenz in Nürnberg, die Open Source Monitoring Conference. Dort bin ich mit einem zappeligen Kollegen hingefahren, auf dem Fußweg vom Bahnhof zum Hotel sind wir dann auch erstmal direkt durchs Rotlichtviertel gestolpert - im Hotel gabs dann lecker Abendessen und es war ziemlich voll - eine trotz Wirtschaftsdepression ausgebuchte Konferenz, schon mal nicht schlecht.

Nun aber eher zum Inhalt, und was ich mitgenommen habe.

Leider gibt es die meisten Folien noch nicht online, ich erweitere diesen Artikel entsprechend, wenn die Folien verfügbar sind.

Jetzt wirds technisch, nicht computeraffine Leser können also aufhören, es verstehen zu wollen oder gleich aufhören, es zu lesen.

Ich schreib auch noch am Wochenende was neues, ich hab nämlich ein neues Spielzeug bekommen.

Der international agierende Großheilige St. Isotopp eröffnete den einen Track (es gab zwei parallele) mit einem Vortrag zum Thema Monitoring MySQL (was sich dann gleichzeitig als MySQL-Tuning-Vortrag herausgestellt hat).

Kristian hat seinen Vortrag mit einer (für mich) Banalität eröffnet, und zwar mit der Feststellung, daß es unterschiedliche Gründe für 'Monitoring' gibt, und das meist jeder, den man fragt, was anderes darunter versteht. Und zwar mindestens

  • Operations (also Fehlererkennung und Handling),
  • Infrastruktur-Entwicklung (Sizing, zukünftige Entwicklungen abschätzen),
  • Entwicklung (Fehler in Software erkennen und in zukünftigen Versionen ausbauen, neue Features kontrollieren),
  • Verfügbarkeitsauswertung (SLA Compliance).

Jede dieser Monitoringarten hat unterschiedliche Anforderungen in Bezug auf Zweck, Messtechnik, abzulieferndes Ergebnis, mögliche Latenz und Verfügbarkeit - aus diesem Grunde solle man es eher vermeiden, die Daten für alle Monitoring-Typen gemeinsam zu erheben oder zu verarbeiten.
Das ist für mich banal, weil wir das sowieso so handhaben - wir erfassen mit unserem Operations-Monitoring (zum Vergleich: Wir setzen Nagios zur Überwachung von etwa 550 Hosts und 2400 Services ein) keine Performancedaten, sondern machen dies z.B. mit Munin. Natürlich erfasst unser Nagios auch Performancedaten (das machen viele Checks automatisch), aber wir werten diese nicht via Nagios aus.

Mir war nicht klar, daß andere das in extremer Weise tun, das stellte sich erst im Laufe der Konferenz heraus. Genauso war mir nicht klar, daß es sinnvoller ist, das bewußt zu trennen (wir machen das wohl auch, weil es bei der Einführung von Nagios (damals noch Netsaint) noch nicht vorgesehen war). Wenn man mittels Nagios auch Daten für die Performanceauswertung erfassen will, muß man natürlich auch entsprechende Checks einrichten, die dann dem Operating aber auch nicht mehr Informationen zur Fehlerbeseitigung liefern als die eh schon vorhanden Checks, dafür aber auf dem Nagiossystem ordentlich Last und vor allem gewaltige Datenmengen erzeugen.

Dieses für mich 'Nichtproblem' zog sich durch die ganze Konferenz, meist verbunden mit dem Wunsch, dem Webinterface von Nagios mehr Konfigurationsmöglichkeiten, Views und Personalisierung zu verpassen - was mir total wumpe ist. Das Webinterface von Nagios ist häßlich, aber es erfüllt seinen Zweck. Etwas, das mich nachts um 3:48 Uhr weckt, muß nicht schön sein, sondern ich muß erkennen können, was Phase ist und ich muß das Gebimmel zielgerichtet abschalten können. Das lösen wir durch sinnvolle Checks und Abhängigkeiten und nicht durch Web2.0-Grafik. Das sieht natürlich anders aus, wenn man schöne Grafiken über z.B. die Auslastung von Mailqueues direkt im gleichen Tool haben will.

Ebenso scheinen viele aus dem Grund der Weiterverwurstung von fürs Operating erzeugten Daten die Datenbankschnittstelle von Nagios zu verwenden - und dort alles hineinzuballern, was man zumindest fürs Operating nach drei Tagen gar nicht mehr braucht. Ein ähnliches Problem scheint es auch beim (kommerziellen) MySQL-Enterprisemanager zu geben, dies hat bei Kristian (als Ex-MySQLler) dazu geführt, noch während der Konferenz in das NDO-Schema hineinzukriechen und ein paar Ideen dazu zu veröffentlichen. Ich hoffe, das lesen mal die richtigen, z.B. die Jungs vom Icinga-Team.

Der Rest von Kristians Vortrag taugt dafür, ein Gefühl dafür zu bekommen, welche Parameter man für ein Operating-Monitoring gerne überwachen möchte und MySQL zu tunen, also grundsätzliche Performanceprobleme zu verstehen und dem Datnbanksystem dann auf die Sprünge zu helfen. Guckt Euch die Folien an, es ist für mich als Nicht-DBA ne Menge Stoff dabei, von dem man zumindest mal gehört haben sollte.

Als nächstes habe ich einen Vortrag über SNMP gehört (net-snmp: The forgotten classic) - allerdings hat das bei mir nicht so richtig gezündet, weil es um wirklich classic snmp generell ging und nicht so sehr eine sinnvolle Nagiosintegration. Ich finde SNMP zum Glück meist vermeidbar, und vorallem sollte man das meiner Meinung auch immer tun, wenn das zu monitorende Gerät die Möglichkeit bietet, anders an Informationen zu kommen. Inzwischen ist das bis auf bei wenigen Switchen und ähnlicher Hardware problemlos möglich.

Im Anschluß gab es einen Vortrag zu einer Migration von Tivoli auf Nagios in einer wirklich großen (>11.000 Hosts) und heterogenen Umgebung (bei Audi).

Interessant zu sehen, welche Prozeduren dort eine Rolle spielen, aber vorallem hat mir der lakonische, stark dialektgefärbte Sprachstil von Eric Pfaller gut gefallen.

Nicht verstehen kann ich allerdings, wieso man dort statt nrpe (damit kann man Testkommandos auf Remotesystemen absetzen) check_ssh einsetzt - der ssh-Verbindungsaufbau ist verschlüsselungstechnisch um Größenordnungen teurer als der von nrpe. Scheinbar haben die das auch schon bemerkt, deswegen wird mit selbstgefrickelten Cachingmechanismen gearbeitet (anscheindend werden mehrere Checkanfragen und deren Antworten gesammelt und dann gemeinsam übertragen - ... Latenzen...).

Daneben verwendet Audi zur Verwaltung und Erzeugnung der Nagioskonfiguration einen LDAP-Server, der die entsprechenden Templates vorhält. Das hat allerdings einen sinnvollen aber ebenso perversen Touch und ist damit interessant :-)

Audi öffnet übrigens automatisiert für jeden hard-status CRITICAL nen Ticket. Toller Spaß.

Allerdings fand ich die Ankündigung zum Vortrag Application monitoring - Bridging the gap, der parallel zur Vorstellung des LDAPs als Backend für die Objektkonfiguration laufen sollte, interessanter, so daß ich dann doch dahin gegangen bin - ich war auch nicht enttäuscht.

Michael Medin, der in seiner not-so-spare time für Oracle arbeitet, ist ein guter Redner und inhaltlich ging es am Beispiel der jmx-console um Anwendungsmonitoring. Wir setzen jmx-monitoring ein, allerdings nicht im Operating, sondern zum Debugging, Development und allgemeinen Beobachten von Java-Anwendungen.

Medins Kernforderung: Redet miteinander, redet mit den Entwicklern! Stellt den Entwicklern Möglichkeiten zur Beobachtung ihrer Anwendungen zur Verfügung, in der Regel wissen diese nämlich weder, wie sich Ihre Anwendungen unter dem Eindruck von echten Benutzern verhalten, noch, daß es diese (feine) Möglichkeit bei Java-VMs, .NET und anderen Sprachen gibt. Gerade, wenn wie bei Java eine komplette VM hochgerissen wird, ist es sehr interesaant zu sehen, wie die garbage collection (nicht) funktioniert, wie viele Sessions der Datenbankconnector hält und was sich so im Heapspace tummelt.

Dabei ist noch das für mich neue jmx4perl aufgetaucht, daß anders als unsere Lösung keine java-libs zieht und damit auch keine eigene java-vm bootet.

Als letzten Vortrag am Mittwoch habe ich mir die Präse vom Icinga-Team gegeben. Icinga ist ein Nagios-Fork (Gründe für den Fork), die Core Teammitglieder sind anscheinend alle aus der Gegend und im Dunstkreis des Veranstalters Netways angesiedelt. Der Vortrag war von der Darbietung her erfrischend unprofessionell (aber nicht vom Inhalt) - durch den ständig wechelnden Vortragenden (und den Kampf darum) wurde es nicht langweilig.

Auch hier ging es (wie in den von mir eher nicht besuchten Vorträgen) zum großen Teil um die Darstellung und den Umgang mit den Ergebnissen von checks. Icinga bietet dafür in Zukunft ein sehr frei konfigurierbares Webinterface an, so daß sich damit jeder Betrachter seine spezifischen Views zusammenbauen kann - das neue Webinterface ist in PHP, damit ergeben sich dann die im web2.0 üblichen Dinge wie Ajax-Suche usw..

Icinga versucht, abwärtskompatibel zu Nagios zu bleiben (so lange es geht), gleichzeitig benötigt Icinga auf jeden Fall die Datenbankanbindung. Die Entwickler arbeiten daran, diese auf standard SQL zu bekommen, um andere DBRMS (PostgreSQL und Oracle) anbinden zu können. Daneben sind die Jungs dabei, eine universelle Schnittstelle zu entwickeln.

Die Präsentation hat deutlich gemacht, daß das Icinga-Team mit Hand und Fuß plant und dann entwickelt, und nicht im allgemeinen Fork-Chaos irgendwo Funktionen dranfrickelt - das gibt ein gutes Gefühl auf die folgende Entwicklung. Seit der Konferenz ist 1.0RC1 verfügbar.

Der 'gesellige Abend' war ok, allerdings waren die Tische etwas zu groß und die Mukke etwas zu laut, um sich in Ruhe austauschen zu können. Ich bin von dort dann trotz der weiteren Strecke zum Hotel gelaufen (gestützt durch Kristians und mein Handy-GPS - wie haben wir das nur früher hinbekommen) - wenn der Konferenzort auch noch der Schlafort ist, ist das zwar morgens sehr bequem, und man kann in Schluffen zum Vortrag, aber man bewegt sich quasi gar nicht mehr.

Der nächste Morgen begann mit check_mk als Alternative zu NRPE der sich im Nachhinein als mein persönliches Highlight herausstellende Vortrag. Wieder ein komplettes Konzept, bei dem deutlich wurde, daß der Entwickler nicht hirnlos angefangen hat, herumzubasteln, sondern vorher über eine Art Architektur für ein Tool nachgedacht hat.

check_mk ermöglicht durch die Verlagerung der nrpe-Konfiguration auf den Nagioshost eine Nichtkonfiguration auf dem zu checkenden Client - mit dem Pferdefuß, daß dies nur für stark normalisierte Standardsystemparameter funktioniert.

Die Vorteile des Konzeptes: Irre schnelles Ausrollen auf einer großen Anzahl von sehr heterogenen Clients, sehr einfache Möglichkeit der Überprüfung, ob evtl. Dinge dazugekommen sind, die man auch überwachen möchte, automatische Erstellung von 0815-Nagios-Konfigurationsdateien, irre Performance - weil check_mk einfach nur den Daemon auf dem Client anpiekst, und der alles auskotzt, was er weiß. D.h., es gibt nicht für jeden einzelnen Check eine Kontaktaufnahme.

Die Nachteile des Konzeptes: Im wesentlichen funktioniert das nur für wellknown Standardsystemparameter, es ist also super, um Eisen zu überwachen. Es ist ungeeignet, um sehr individuelle Checks zu verarbeiten, also genau das, was Anwendungsüberwachung eigentlich ausmacht. Bei nrpe kann ich einfach alle individuellen Anwendungschecks in die nrpe_local.cfg schreiben, diese global verteilen und via Nagios-Konfiguration jeweils pro Host genau die ansprechen, die ich dort brauche - bei check_mk muß man das dann anscheinend doppelt konfigurieren, also auf dem Client ins Scriptsverzeichnis kippen und auf dem Server entsprechend nach konfigurieren.

Insgesamt aber eine interessante Sache, die ich auf jeden Fall ausprobieren werde. Bei kurzem Nachdenken fallen mir sofort noch einige andere mißbräuchlinge Dinge ein, die man mit der Inventarisierungsfunktion von check_mk tun kann - z.B. per nmap alle Hosts vom Typ X (sagen wir mal Xen-VM) finden und dann mit check_mk -L trübertackern und die Systemdaten wegschreiben, nachdem man ins Skriptverzeichnis für Debian-Kisten z.B ein 'dpkg -l'-Aufruf gesetzt hat...
Außerdem scheint es auch ein logwatch-Flansch zu geben, da kann man diese Daten auch schön weiterverarbeiten.

Über das Gespräch mit Mathias Kettner hab ich dann den nächsten Slot verpaßt, aber das war auf der einen Seite die übliche Stockebrandt-IPV6-kommt-jetzt-bald-wirklich-Gedächnisveranstaltung und auf der anderen was über NConf, ein grafisches Enterprisekonfigurationstool. Nach (sehr kurzem) Nachdenken kommt man eigentlich darauf, daß zumindest ich in einer Enterprise-Umgebung Nagios-Dateien lieber maschinell (aus LDAP, per python-Parser, klassischem Makefile oder sonstirgendwie) aus dem svn lutsche und generiere denn über ein GUI zusammenklicke, aber da sind die Geschmäcker anscheinend verschieden.

Im Anschluß gab es eine Vorstellung des Monitorings in einer Enterprise-Umgebung, und zwar der von LindenLabs 2nd Life (auch deutlich über >10.000 Hosts).

Dort ist man den sonst üblichen Weg, die mit Nagios erzeugten Daten in einen grafischen Aufbereiter zu kippen, genau umgekehrt gegangen - so werden dort die Daten aus Ganglia, einem freien Monitoringsystem speziell für große Grids und Clustersysteme, an Nagios weiterverfüttert, um den Performance-Problemen mit z.B. aktiven Checks aus dem Weg zu gehen. Interessanter Ansatz, für das OP-Monitoring braucht man ja in der Regel nur einen Teilsatz der im grafischen Verlaufsmonitoring eh vorhandenen Daten.

Leider findet man auf der Ganglia-Webseite im ersten Schritt keine brauchbare Doku, ich hab das erstmal nicht weiter verfolgt.

Ganz zum Schluss gab es dann noch einen Vortrag zum Nagios-Benachrichtigungssytem, der zwar meiner Meinung nach sehr gut war, aber aufgrund des Themas wohl eher als einführender Vortrag an den Beginn der Veranstaltung gehört hätte.

Für die meisten wohl eher nix neues dabei, trotzdem fundiert und vor allem didaktisch sauber aufbereitet.

Zusammenfassung

Das Hotel, Unterbringung und das ganze Drumherum war super. Der Service war so gut, daß er fast schon genervt hat - wenn man beim letzten Bissen seinen Teller nicht mit Messer und Gabel verteidigt hat, wurde er einem sofort weggerissen und man mußte sich nen neuen holen.

Die Themen der Konferenz haben mich etwa zur Hälfte interessiert, und es waren zwei parallele Tracks. Leider waren ab und zu Sachen, die mich interessierten parallel. Wahrscheinlich läßt sich das nicht vermeiden, wenn man Wert darauf legt, daß es immer einen deutschen und einen englischen Vortrag parallel gibt, um sowohl internationale Besucher als auch (ältere) deutsche Besucher entsprechend abzuholen.

Die Besucherstruktur fand ich für eine OpenSource-Konferenz eher ungewöhnlich, nur wenig bekannte Gesichter, die auch nur wenig auf die bekannten Gagstarter (... you are currently dying...) reagierten. Nach meinem Eindruck viele Leute, die ohne großen OSS-Hintergedanken Nagios einsetzen (weil es augenscheinlich am meisten bäng for the bugs gibt) oder beim Veranstalter Kunden sind und nur darüber auf OSS-Konferenzen auftauchen. Nichtsdestotrotz haben sich viele interessante Gespräche und einige Kontakte ergeben.

Aus den Gesprächen nebenbei hat sich immer wieder ergeben, daß viele Besucher Mehrfachtäter sind und sich oft als Community-Members aus den Nagiosbenutzer-Selbsthilfeforen (z.B. Nagios-Portal oder Monitoring Exchange) kennen.

  • Ich nehme mit, daß opensource monitoring in der Regel wie 'nagios' ausgesprochen wird. Hoffentlich ändert sich das bald auf 'icinga'.
  • Ich nehme mit, daß ich mich mit check_mk beschäftigen werde und wahrscheinlich auch mit jmx4perl.
  • Ich nehme mit, daß die Probleme, die die meisten Konferenzteilnehmer drücken (grafische Aufarbeitung, Konfiguration und Auswertung) für uns keine sind.
  • Ich habe den Eindruck, daß ich bei einem ernsthaften Problem mit Nagios die vorhandenen Foren und Boards vergessen kann, zumindest, wenn ich eine Antwort will.
  • Ich nehme einige Antworten auf Fragen mit, die ich nie gestellt hätte.

Insgesamt hat es sich auf jeden Fall gelohnt, an der OSMC teilzunehmen.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

11.07.2009

17:40 Uhr  Verbindungsteilung


Hä?
Ok, connectionsharing klingt noch bescheuerter.
Heute gehts um das Teilen von Internetzugangspunkten mit anderen.

In Firmen ist ja sowas durchaus üblich und praktisch - das gemeinsame interne Netz hat einen Ausgang, und dort wohnt das Internet.

Privat gibts das ebenfalls als default, wenn man sich eine wie auch immer technologisch umgesetzte Internetanbindung mietet.

Allerdings ist so eine private Leitung in der Regel nicht immer komplett ausgelastet, und so sind die Endpreise wohl auch kalkuliert. Das Unternehmen FON setzt mit seiner Geschäftsidee schon seit längerem genau an diesem Punkt an, und bietet preisgünstige (um nicht subventionierte zu schreiben) und technisch relativ hochwertige Wlan-Router an, die man sich als Mieter einer Internetverbindung anschaffen kann, um erstens zuhause kabellos zu surfen (das ist nix neues) und zweitens die vorhandene und meist pauschal bezahlte Leitung mit anderen gemeinsam zu nutzen.

Diese 'anderen' können dies tun, wenn sie entweder selber bei sich zuhause Bandbreite über einen FON-Router zur Verfügung stellen, oder entsprechende Vouchers bei FON kaufen.

Selber Fonero werden ist günstig - die einfachste Fonera (so nennen die ihre Router) kostet 20 Euro und ist ein ziemlich vollwertiger Wlan-Router.

Die Sache hat allerdings mehrere Haken:

  • Obwohl ich Fonero (Mitglied) bin, hab ich noch nie das Wlan eines anderen Mitglieds genutzt - es ist einfacher, einfach den UMTS-Stick zu zücken und inzwischen auch nicht mehr teuer. Das stellt das Geschäftsmodell von FON generell in Frage, obwohl ich auf meiner fonera schon ab und zu fremde Nutzer habe. Um FON-Spots zu finden, kann man die entsprechenden Karten benutzen.
  • Die Nutzungsbedingungen der meisten Internet-Zugangsanbieter schliessen diese Art der Nutzung aus (dazu unten mehr)
  • Es besteht die Gefahr (wie bei allen eher offenen Wlans), daß über die eigene Leitung im Netz scheisse gebaut wird, und das die Scheisse erstmal auf einen selbst zurück fällt - bis die Strafverfolgungsbehörden verstanden haben, daß die Scheisse von anderen (in diesem Fall einigermaßen ermittelbaren Personen) stammt, ist erstmal alles, was mit Strom funktioniert, in der Aservatenkammer.

Ein Zugangsanbieter in Deutschland hat gegen eine kommerzielle Mitnutzung des von ihm bereitgestellten Privat-Kunden-Internetanschlusses auf Unterlassung wegen unlauteren Wettbewerbs geklagt und gewonnen, die Berufung ist nun vom OLG Köln zurück gewiesen worden - das betrifft auch das Geschäftsmodell von FON.
Witzigerweise hat die neueste release candidate Firmware nun einen Schalter, mit der man das öffentliche FON-Signal abschalten kann - Zusammenhang?

Daneben ist es natürlich einfach möglich, undercover Internet mit Freunden, Nachbarn und Bekannten zu sharen, indem man einfach den entsprechenden Wlan-Schlüssel weitergibt. Dies ist - ebenso wie die Nutzung von FON - in den meisten Zugangsanbieter-AGB verboten, weil dies die Kalkulation des auflaufenden Traffics schwieriger macht und man dafür lieber auf Geschäftskundentarifbasis abrechnen möchte - nichts desto trotz macht das wohl jede WG so.

Neben dem Festnetz-DSL-Sharing wird es zumindest für mich immer wichtiger, auch unterwegs Internet zu haben und dieses auch mit anderen zu teilen. Typische Einsatzszenarien sind Treffen an Orten, an denen es kein Wlan gibt, dies aber für die Arbeitsgruppe zur Arbeit notwendig ist. Ich hatte dieses Problem zuletzt bei der Blackflag-Aktion auf der Kieler Woche und auch auf dem Bundesparteitag der Piratenpartei, bei dem ich mit in der Orga gesteckt habe.

Auf der Kieler Woche war unser Büro in einem Auto mit Drucker und allem, wir hatten sogar nen 12V-220V-Wandler - aber kein gemeinsames Netz. Auf dem BPT gab zwar Internet, aber kein für die Orga abgetrenntes, einigermaßen sauberes (Mitgliederdaten und so...).

Auch auf anderen, 'fliegenden' Treffen ist dies zunehmend ein Problem - immer mehr Arbeitsmaterial liegt im Netz und nicht lokal vor, und oft ist es nicht ausreichend, wenn dann einer Netz hat (via UMTS-Modem im Handy oder UMTS-USB-Stick oder oder).

Die einfachste Möglichkeit ist es natürlich, einen Rechner mit UMTS-Stick durchlaufen zu lassen und diese Verbindung über Wlan für andere freizugeben. Die aktuellen UMTS-Sticks bzw. die damit gebündelte Software behindert genau dies allerdings ziemlich eindrucksvoll - an dem Web'n'Walk-Manager aufm Mac bin ich nach 20 Minuten Gefrickel nicht mal eben so vorbeigekommen (der schaltet stumpf das Wlan ab bzw. in eine Umgebung, in der es kein Wlan gibt - clever).

Die zweite Möglichkeit ist es, ein Handy zu benutzen, über dessen Modem eine UMTS-Verbindung aufgebaut wird und diese dann zu teilen. Geht mitm Mac und z.B. einem Nokia 6233 ziemlich gut - allerdings muß man dann, wie oben auch, den Rechner und das Handy laufen lassen und kann das Handy nicht mehr mit sich rumtragen und beim Telefonieren ist die Chance hoch, daß die Verbindung abkackt.

Ich hab mich deshalb etwas umgetan in der Richtung wlan2umts-Router. Am Markt gibts so einiges, vom einfachen, vom Provider gebrandeten umts2wlan-Router (einschlägig: web'n'walk-Router in etwa 20 Bauformen, aber meist ohne Ethernet und von der Software eher unkonfortabel) bis zum schusssicheren Industrial-Design. Das meiste ist mir entweder zu fipsig oder viel zu teuer.

Dazwischen liegen z.B. die Router von Linksys / Cisco, die einen recht ordentlichen Eindruck machen und mit einem befummelbaren Betriebssystem ausgeliefert werden, und einer der Router von FON, und zwar die Fonera 2.0.

Da ich zufällig so ein Gerät habe, mußte ich das latürnich ausprobieren, das Feature tut nur mit bestimmten usb-Sticks (Kompatibilitäts-Liste), der hier rumliegende T-Bim-Stick (Option irgendwas) tat natürlich nicht, aber einer von fonic (wie passend der Name) tat nach etwas Gefrickel mit Firmware-Updates einwandfrei.

Die Fonera als wlan2umts-brigde zu nutzen, hat noch ein paar Vorteile, an die USB-Schnittstelle kann man einen USB-Stick (oder Platte) hängen, dieser ist per smb aus dem internen Netz mountbar - so hat man gleich noch einen Fileserver für die Arbeitsgruppe dabei und muß nicht immer das eigene Laptop laufen lassen; über den Ethernet-Port kann man weitere, nicht wlan-fähige Geräte anschliessen, Drucker und so Zeug.

Allerdings braucht man dafür zwingend Netzstrom und so ganz spontan ist das auch nicht mehr, schnell hat man wieder einen Haufen Geklöter mit dabei - Fonera, Netzteil, einen kleinen Switch, Netzteil, Kabel usw.

Für spontanes Internetsharing hab ich gerade JoikuSpot entdeckt - das macht aus einem Symbian-Mobiltelefon eine wlan2umts-Bridge. Funktioniert super, aber man sollte das Netzteil fürs Handy in der Nähe haben, das ist die erste Anwendung die ich kenne, bei der man konfigurieren kann, bei welchem Akkuladezustand die Anwendung abschaltet :-)

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

25.06.2009

18:43 Uhr  Silberfisch mit Licht


Mein tapferes Macbook (eins der ersten in schwarz, von Juni 2006) hat nun fertig, da es aus der Apple-Versicherung Care&Protection raus ist und nach drei Jahren wohl auch abgeschrieben ist.

Apple hat mit dem Care&Protection in diesem Fall wohl eher drauf gezahlt, neben dem dritten Akku hatte es auch schon das dritte Topcase (Oberschale mit Keyboard, Trackpad und drumherum), das Mainboard wurde einmal erneuert und das optische Laufwerk wurde auch getauscht.

Ok, ich schleppe das Teil auch immer (ich meine immer) mit mir rum, da gibt es schon mal die eine oder andere mechanische Belastung.

Dafür weiß unser Apple Händler aber auch meinen Namen und wie ich meinen Kaffee am liebsten trinke. Schon fast etwas zu devot.

Das neue Spielzeug hat nun Unibody (das Gehäuse ist aus einem Stück Alu genagt) und ist wie mein aller erstes Apple-Laptop (huhu eventmops!) wieder silbern.

Die Migration hat unglaublicherweise dank TimeMachine nur knapp zwei Stunden gedauert - Timemachine-Platte anschliessen, Backup auf den neuen Rechner spielen (das dauert etwas), Apple-Update-Service durchladen, rebooten, fertig.

Ok, fast.
Die Dinge, die nicht im Backup waren, mußte ich noch rüber-rsyncen, aber dann war es fertig. Ich bin wirklich begeistert, dachte schon, ich muß mich wieder tagelang durch das Neugerät fressen und UIDs anpassen, Ports neu bauen usw.

Das Neue ist spürbar schneller (ok, drei Jahre CPU- und Grafikentwicklung sind nicht umsonst), so schnell, daß nun GoogleEarth ruckelfrei auch auf dem externen 24"er läuft und unser (LaTeX)-OP-Handbuch (1200 Seiten, zwei Durchläufe, dann als pdf öffnen) in 20 Sekunden baut.

Ansonsten begeistert mich gerade die automatische Tastaturbeleuchtung. Das ist so ähnlich wie eine automatische Wischiwaschi-Schaltung im Auto. Wenn die zum falschen Moment losgeht (Waschanlage, z.B.) ist gleich der Arm ab. Bin gespannt, was das Equivalent dazu ist...

Das Trackpad ist größer und tastenlos, die Applefraggles haben es aber geschafft, einen echten, mechanischen Klick einzubauen, damit stimmt die Klickhaptik wieder.

Den Akku kann man nicht mehr tauschen, dafür hält er angeblich bis zu 7 (sieben!) Stunden. Wenn es sechs sind, wäre ich auch ziemlich zufrieden.


[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

27.03.2009

17:32 Uhr  SD Memory Card Recovery


Nach dem Keiner will Backup, alle wollen Restore Artikel neulich nun ein Restore aus der Praxis.

Wie Nils neulich auch schon hat ein Freund von mir seine SD-Karte in einer Kamera geshreddert.

Ohne bei obigen Artikel nachzusehen, bin ich bei einer Suche nach entsprechenden Recovery-Tools wohl zufällig auf das gleiche Werkzeug gestossen und habe es ausprobiert.

PhotoRec, weil es OSS ist und nicht wie viele andere (shareware-)Werkzeuge die Bilder nur anzeigen aber nicht speichern kann - dafür müßte man die Software erst registrieren. Obwohl man da dann wenigstens nicht die Katze im Sack kauft.

Außerdem arbeitet es auf der Komandozeile und unter so ziemlich jedem handslüblichen Betriebsystem und mit so ziemlich jedem handelsüblichen Dateisystem (auch HFS+, ext4 und andere, jenseits des Mainstreams).

Von der SD-Karte von Andy, die mit den typischen BSD-Unix-Dateisystemtools nichts mehr zu entlocken war, hat photorec noch 191 Bilder runtergekratzt - wesentlich mehr, als der aktuelle Besitzer darauf gespeichert hat :-)

Nach dem bewußten, mehrfachen Überschreiblöschen ist allerdings dann auch für photorec nix mehr zu holen.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

24.03.2009

22:43 Uhr  Netzwerkkarte für Gamer


Also so richtig schlimm kann ja die Wirtschaftskrise doch noch nicht sein. Solange es Meldungen wie diese hier gibt, und sich dann das Produkt auch verkauft, wird alles gut.

Eine Netzwerkkarte speziell für Gamer. Soso. Mit Display auf der Karte und einer verspielten Klingonenfingermesserapplikation daran.

Die Karte zeichnet sich dadurch aus, daß sie zeitkritische Datenpakete bevorzugt ausliefert. Verstehe. Drücke auf den Feuerknopf (und das unehrenhafte seitliche Wegducken) werden nicht mit GE, sondern mit c ausgeliefert - wie praktisch - zumindest bis zum DSL-Modem.

Und wie es sich für Gamer-Zubehör gehört, hat sie 256 MB RAM. Nochmal, es handelt sich um eine NETZWERKkarte, nicht um eine Grafikkarte.

Nebenbei kann die Karte selbst noch VoIP selbst verarzten. Nicht nur schnell schiessen, auch schnell sprechen. Würde sagen, damit ist die Zielgruppe eventuell überfordert. Achja, beim Thema Actionshooter-Gamerbashing: Titanic hat da so einen Verdacht.

Wenn man die Karte gamertypisch übertaktet, kann man bestimmt auch 1,2 Gigabit rauskitzeln.

Uns geht gar nicht schlecht, wir jammern nur auf hohem Nivea.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

21.02.2009

10:26 Uhr  Keiner will Backup, alle wollen Restore


Bei mir hat es nun das zweite Mal in unmittelbarer Nähe zur Wohnung gebrannt, und der Gedanke, bei einem Feuer einen Haufen Daten zu verlieren, weil ich meine artig und einigermaßen regelmäßig angelegten Backups zu Hause aufbewahre, nervt.

Aus diesem Grund hab ich mich noch mal mit dem Thema auseinandergesetzt - bisher benutze ich zur Sicherung meiner privaten Daten zu Hause mehrere Strategien gleichzeitig:

  • Texte, Skripte und anderes weitestgehend textbasisiertes Zeug liegt sowieso versioniert in SVN-Repositories.
  • Fotos (das sind aktuell so 70 GB) liegen auf derzeit drei externen Platten.
  • meine Linux-Rechner rsyncen sich gegenseitig, was die wichtigeren Dinge angeht, die nicht in meinem $HOME liegen (wenn sie denn mal gleichzeitig laufen).
  • auf dem Mac benutze ich iBackup, was für alle typischen Programme entsprechende Extentions bereithält, um auf einigermaßen vernünftige Art an die Konfigurationen, Lizenzen und so weiter zu kommen.
  • Wirklich richtig wichtige Dinge wie ssh- und gpg-Schlüssel hab ich auf einem verschlüsselten USB-Stick.

Das SVN-System ist für nichtbinäre Dateien mein Favorit, weil es eben neben Backup gleich eine feine Versionsverwaltung mitliefert, und man von überall aus an die Daten rankommt, weil die SVN-Repositories, die ich nutze, übers Internet erreichbar sind. Für die, denen svn (subversion version nagetier) unbekannt ist: Das ist ein einigermaßen modernes Versionkontrollsystem, um auf einigermaßen durchschaubare Art und Weise mit vielen Leuten gleichzeitig an einem Softwareprojekt zu arbeiten, ohne sich dabei ständig durch eigene, für andere unvorhersehbare Änderungen gegenseitig in den Fuß zu schiessen, weil es z.B. möglich ist, sich widersprechende Änderungen sinnvoll zu behandeln. Weiteres unter der o.g. URL.

Für Fotos und andere binäre Dateien (ich hab kaum Musik und keine Filme) ist svn eher unbrauchbar, weil svn versucht, den Unterschied in einer Datei zwischen der aktuellen und der letzten Revision wegzuschreiben - bei Dateien, die aus nichtlesbaren Zeichen bestehen, ist das schwierig und so wird dann die gesammte Datei immer wieder komplett in das Repository geschrieben, wenn sie verändert wurde (jaja, da gibt es Zwischenformen, ich weiß). Aus diesem Grund habe ich die Fotos, wenn sie von der Speicherkarte der Kamera auf den Rechner kommen, auf einer externen Platte liegen (auf dem Laptop ist nicht genug Platz). Wenn ich an den Bildern rumgemurkelt habe oder neue dazu kommen, synchronisiere ich diese Platte jeweils einzeln mit zwei weiteren externen Platten (einigermaßen regelmäßig, nicht täglich). Dafür benutze ich rsync mit --no-perms-Option, weil eine der externen Platten ein kleines NAS-System ist, daß leider komische Vorstellungen von Unix-Gruppenrechten und umasks hat. Damit nun nicht jedesmal aufgrund der unterschiedlichen Dateirechte an allen Dateien geschraubt wird, dieser Kniff.

Durch die drei Platten und unterschiedliche Technologien (Ethernet, usb, firewire) habe ich eine relativ hohe Chance, das mir nicht alle Daten gleichzeitig verloren gehen. Ich bin auch paranoid genug, die beiden Sicherungsplatten nicht gleichzeitig anzuklemmen und sie sind von unterschiedlichem Anschlußtyp und Hersteller.

Außer, ich bin nicht zu hause und habe (was nur sehr sehr selten passiert, wenn ich weiter als bis zum Bäcker gehe) meinen Laptop und die fragliche externe Platte nicht in der Tasche und die Hütte brennt ab/Flugzeug fällt ins Haus/Waschmaschine der Übermieteren platzt/lokal begrenzter EMC-Schlag/blablafaselrabarber/$DEFAULTKATASTROPHE.

Musik - also, ich meine bezahlte Musik - würde ich wohl ähnlich sichern. Mir ist Musik nicht wichtig genug, geraubte besorgt man sich im Fall des Falles eben neu.

Konfigurationsdateien und anderen Krempel, der sich nicht richtig fürs svn eignet, synchronisiere ich mittels eines von Ray übernommenen und aufgebohrten rsync-Backup-Skriptes, das in mehreren Generationen ebenfalls auf eine der oben genannten Platten schreibt. Der Trick zum Platzsparen dabei ist, sich seit dem letzten Backup nicht veränderte Dateien nicht erneut auf dem Backupmedium abzulegen, sondern einfach nur aus dem aktuellen Generationsverzeichnis einen Hardlink (gnu: cp -l) zu legen. Das Skript sichert auch automagisch mysql-Datenbanken, ldaps und was eben so anliegt an Daten, die man nicht unbedingt plain auf die Platte rotzen will.

Aufm Mac benutze ich eben iBackup, das hat ne nette GUI, auf der man sich zusammenklickern kann, was man gerne gebackupt haben möchte. Es kann Netzlaufwerke und lokale Platten bespielen, oder per ssh/rsync Daten remote einkippen - aber es kann nicht incrementell arbeiten (oder ich hab das nicht gefunden). Ich will aber nicht zweimal die Woche 40GB Daten wegschreiben, sondern höchstens einmal alle zwei Monate und in der Zwischenzeit eben immer nur den Diff aufheben. Dazu kommt, das iBackup unglaubliche Resourcen verschlingt - eigenlich kann man das nur nachts laufen lassen.

Toll an iBackup ist hingegen, daß es für fast alle Programme, die man so auf dem Mac benutzt, passende Plugins hat, um auch die Konfiguration vernünftig zu sichern.

Zu dem USB-Stick schreib ich jetzt mal nix, das ist wohl ein extra-Kapitel.

Was alle obigen Backups (mit Ausnahme von svn) als Problem haben: Man muß es auch regelmäßig machen. Bei Dateien aus dem SVN-Repository macht man ja sowieso reflexhaft ein svn commit hinterher.

Als ich den Mac von Tiger auf Leppat umgestellt habe, hab ich das vorallem getan, weil mich Timemachine interessiert hat (und ich wollte Java 1.6 - beides erstmal ne Pleite...). Timemachine ist die Applelösung fürs Desktop-Backup. Sie ist unauffällig und macht, was sie soll - so las man.

Also damit erwartungsfroh rumgespielt (ganze 15 Sekunden) und festgestellt, daß das Mistding nur auf lokal angeschlossene Platten schreiben kann, nicht aber auf Netzlaufwerke (auf Remotemacs hingegen geht - das Problem scheint zu sein, das Timemachine die Platte selbst richtig formatieren muß, evtl. mehr Inodes als üblich? Evtl. geht eine lokal erstmalig genutze Platte später auch übers Netz, ich werde das probieren). Anscheinend konnte Timemachine auch keine anderen, externen Laufwerke sichern. Mein Interesse war also sofort und weitgehend erlahmt, ich hatte auch gerade keine Platte zur Hand, die ich mal eben formatieren konnte (Timemachine will eine eigene Partition haben).

Nach dem zweiten Brand hab ich mich jetzt noch mal mit dem Thema auseinandergesetzt, und eigentlich ist Timemachine eine geile Möglichkeit, sehr regelmäßig und ohne großen persönlichen Einsatz Backups zu bekommen:

Ich habe durch Ausprobieren und Versuch und Irrtum herausgefunden (also erst hab ich meine Hangarounds gefragt - die benutzen es, wußten aber erstaunlich wenig darüber, was geht und nicht geht), das Timemachine neben den eigentlichen Daten auch sämtliche Verwaltungsinformationen zum Backup auf die angestöpselte Platte schreibt (macht ja auch Sinn für ein bare metal restore). Das bedeutet, man kann mehrere, komplett von einander unabhängige Backups auf unterschiedliche Platten an unterschiedlichen Orten machen.

Ich habe mir zwei einfache externe USB-Platten gekauft, und eine davon steht nun zuhause und die zweite in der Firma. Steckt man eine dieser Platten an, merkt Timemachine das ohne weiteres Zutun (wenn man eine Platte das allererste mal ansteckt, muß man 'Volume wechseln' klickern, um die Platte/Partition erstmalig zu initialisieren und das erste Vollbackup einzuleiten) und macht ein inkrementelles Backup zu dem letzten, was sich auf der Platte befindet, drauf.

Wenn man das oft macht, kostet das kaum Zeit und wenig neuen Platz - wenn man ein paar Spezialisten von Backup ausnimmt, z.B. die Entourage-Datenbank. Die hat anscheinend das gleiche Binärdaten-Problem wie oben svn mit Bildern - aber das ist mir wurscht, ich brauche das nur als Verbindung für Termine in der Firma, im Notfall kann sich Entourage diese Daten auch alle neu besorgen. Eventuell bessert Apple da ja auch noch nach.

ich habe so also zwei aktuelle Backups an unterschiedlichen Standorten - und es sichert meine externe Platte mit den Fotos auch noch gleich mit.

Im Filesystem der Timemachine-Partition sieht es ziemlich genau aus wie auf dem Filesystem der rsync-Konstruktion von oben. Anscheinend nutzt Apple da auch irgendein rsync auf Drogen, das z.B. auch die schrägen zusätzlichen Dateiattribute auf HFS sauber einfängt.

Da kann man sich dann auch mit dem Finder oder auf der Shell die Dateien rausklauben, die man mit einem älteren Stand benötigt, aber nun kommt Apple - Apple wäre nicht Apple, wenn es nicht ein grafisch überlegenes 3D-Restore-Frontend (nämlich eben die Zeitmaschine) gäbe, mit der man wie im modernen Finder in der Diaschauansicht durch die Zeit browsed und sich die Dateien rauspickt, die man braucht. Spaceig, siehe Teaser.

Bare metal restore geht auch: Platte anstecken, von DVD booten, Timemachine-Restore auswählen. Ich wollte das heute probieren, in der Firma war aber gerade kein gleiches Macbook frei, aber ich werde das die Tage nachholen.

Macweenies: Das wollt Ihr auch. Und vorallem probiert das Restore aus, bevor Ihr es braucht.

Alle anderen: Macht irgendwie Backups, auch von Euren privaten Arbeitsplätzen. Macht sie möglichst automatisch und kontrolliert diese paranoid und zwanghaft. Ich glaube, das ist das einzige, was vor karpotter Hardware schützt. Murphy guckt ja schon, wo er zuschlägt.

Und man möge mir die tonnenförmige Verzeichnung des Fotos (ja, es ist eins, Screenshot geht nicht, wenn sich der Mac zu 3D aufplustert) verzeihen. Besser kann meine Kompakte das nicht.


[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

05.02.2009

19:48 Uhr  Runderneuerung


Ich hab mal, weil ja bald der Frühling kommt, und ich den Nick shrek schon seit Jahren nicht mehr benutze, das Blog und auch die Webseite an sich behutsam an den aktuellen Stand der Welt angepasst.

Da ich von Grafik und Design ungefähr genauso viel Ahnung habe wie von Gehirnchirugie, habe ich mich dabei auf sehr wenige Stilelemente beschränkt:

  • einen fröhlichen, lebensbejahenden Grauton (Graukartengrau war leider zu dunkel).
  • ne andere Schrifttype
  • Gefummel in nicht im Ansatz verstandenen css-Styles und damit konkurrierenden table-Definitionen
  • shrek weg

fertig


[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

14.10.2008

23:54 Uhr  Standards entsprechend, die es noch gar nicht gibt...


hat Apple seit heute im Angebot.

Also, liebe Werbeabteilung - was habt Ihr Euch da gedacht? Oder habt Ihr überhaupt gedacht? Oder einfach nur was schlecht aus dem Englischen übersetzt, was Ihr nicht verstanden habt?

Dann mal zur Aufklärung: Ein Standard ist eine vergleichsweise einheitliche oder vereinheitlichte, weithin anerkannte und meist auch angewandte (oder zumindest angestrebte) Art und Weise, etwas herzustellen oder durchzuführen, die sich gegenüber anderen Arten und Weisen durchgesetzt hat - sagt Wikipedia (nicht der Duden).

Weithin anerkannt und die es noch gar nicht gibt stehen dabei schon ziemlich im Gegensatz, zumindest wenn man nicht ständig Ofendichtmasse kokst oder Mohnbrötchen raucht.

Ansonsten war die Präse der neuen Produkte des Apfel-Hohepriestertums ja wohl eher enttäuschend, die übliche Vorberichtsvermutungshysterie eher mau.

Und ich biete jetzt in den gängigen Mac-Foren ein Howto an, wie man aus einem Glossy-Display ein mattes Display macht.

470er Nassschmirgelleinen, Steinwasser, 'nen Korkschleifklotz und ab gehts....
Klar, das Steinwasser kann bei mir gekauft werden. Aus eigener Produktion, und entsprechend auf die Schwingungen des zu behandelnden Displays abgestimmt.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

21.08.2008

18:05 Uhr  1. Nachtrag Cocktailmaschine


Bin inzwischen aus meinem Urlaub zurück und wieder nüchtern (Bericht folgt).

Die Cocktailmaschine hat nachgewirbelt (nicht nur in meinem Kopf), sondern auch mit etwas unscharfen Bildern beim radical monday und mit bewegten Bildern bei YouTube - dort kommt der UserInterfaceteil etwas besser zur Geltung, von dem ich in meinem Bericht leider keine Fotos zur Hand hatte.

Unser Manager hat schon Auftritte für uns und die Maschine organisiert, allerdings müssen wir aus hyänischen Gründen erstmal alles neu und komplett aus amagnetischem, waffenfähigem Edelstahl (V4A, mindestens) bauen.

Das hier ist auch nett, aber zu verspielt.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

27.07.2008

16:51 Uhr  Es lebt! - Die Macht in der (Cocktail)Maschine


Gestern war, wie jeden letzten Freitag im Juli, Sysadmin Day - oder genauer: the 9th annual System Administrator Appreciation Day. Traditionell gibt das abends ne Fete, auch bei uns im Hause. Alkohol spielt dabei eine wichtige Rolle, auch, um zu vergessen.

Bei uns im Hause gibt es bei verschiedenen Gelegenheiten Cocktails, aber es dauert oft lange, einen zu bekommen, weil die Zubereitung zelebriert wird, anstatt einzugiesen, es schwimmt meist noch Obst oder andere untrinkbare und den eigentlichen Zweck eines Cocktails negativ beeinflussende Gegenstände mit im Glas, das Glas ist meist im Beisein einer Bezugsperson mundegeblasen und ohne Kinderarbeit erzeugt und so weiter. Also wollten wir das Problem selbst bearbeiten, und das so, wie wir das immer tun - mit einem hohen Maß an wildgewordenen, quasi unwartbaren SkriptenAutomation.

Eine Cocktailmaschine mußte her.

Das sollte es natürlich auch ein möglichst preiswertes Vergnügen werden, getreu unserem Motto Wir wären nicht so groß geworden, wenn wir immer gleich alles wegschmeissen würden, der zöllige Schieber ist noch gut, Werner. Da gehst du mit der Drahtbürste bei.Schrott wird flott.

Die eigentlich personell und zeitlich streng getrennten Phasen Kundengespräche, Konzeption, Umsetzung, GoLive und Garantieabwicklung haben wir der Einfachheit halber (und um ein reales, typisches Projekt abzubilden) einfach durch eine allgemeine Chaosphase ersetzt.


Es war schnell klar, daß man zum Steuern von irgendwelchen Ventilen, Pompen oder Druckluftschaltern Relais brauchen würde, also haben wir entsprechende Bausätze besorgt und zusammen gebraten (Doppel-Null-Admin - mit der Lizenz zum Löten).

Die Anlaufphase nach dem eigentlichen KickOff dauerte dann ziemlich lange, bis wir uns darüber klar waren, mit welcher Technologie der Ausfluß aus den Vorratsbehältern einigermaßen kontrolliert gesteuert werden kann, und wie man rausfindet, wann das Glas voll ist und noch ein paar andere Betriebsparameter.

Der größte Teil der Konzeptionsphase ist nicht schriftlich überliefert, aber das Chatprotokoll hier gibt evtl. einen Eindruck von der Art der Überlegungen: 

A: ich löte gerade
   http://www.ulrichradig.de/home/index.php/avr/usb-relaiskarte 
   zusammen.
A: Als Schalte für unsere Cocktailmaschine.
A: Das wird so eine tierische Sauerei werden.
A: wir haben schon eine 8port-Karte, die seriell
   arbeitet, aber die macht nur eine Schaltung pro sekunde.
A: damit kann man nicht gut dosieren.
A: beim testlauf heute hat die bei schnelleren
   Schaltvorgängen gerne mal welche vergessen. Wenn da gerade die
   Schnapspumpe läuft...
B: Ich muß dringend mal wieder mit was computermäßigem
   spielen, sonst verlerne ich das noch ganz.
B: Wann ist denn der geplante go-live für die
   Cocktail-Pompe?
B: Ich bring' auch 'ne Tüte bunte Schirmchen mit.
A: Sysadminday.
A: und wir haben uns gegen eine Füllstandsmessung
   entschieden, weil zu kompliziert. (Waage oder optisch). 
   Deswegen kommt da drunter so eine Blutwanne mit Kanister. 
   Das gibt dann Milde Bowle
A: wir streiten gerade noch ob wir als das Medium per
   Pompe, Druckluft oder Schwerkraft (Magnetventil) befördern.
A: Druckluft ist mein Favorit, weil im Fehlerfall am 
   spektakulärsten. Pompen gibts auf dem Autoschrott - 
   Scheibenwischerdings
B: Statt Druckluft könnte man auch diese CO_2-Patronen
   fürs Wassermax nehmen. Das kühlt durch den Druckabfall 
   dann auch gleich. Und wenn die Maschine explodiert kann 
   es das Feuer ersticken.
A: geile idee
B: .oO(wenn im Sinne von "zu dem Zeitpunkt", nicht im
	Sinne von "falls")
A: :-)

Auf Grund der hohen Kosten von Magnetventilen und auch aus praktischen Gründen zur Betriebssicherheit haben wir uns für Scheibenwischwasserförderpumpen entschieden - diese bekommt man für 5 Euro das Stück auf jedem guten Schrottplatz. Wir haben dabei voll auf die bekanntermaßen weltbesten Scheibenwischiwaschipumpen von VAG gesetzt, die bevorzugt in Polos verbaut werden.

Leider sind diese Pumpen nicht selbstansaugend, so daß wir eine hängende Konstrukion mit Vorratsgefäß wählen mußten - die Idee, gleich die Vorratstanks mit aus den Polos zu fummeln, war nach genauerer Betrachtung der Reinigungsmöglichkeiten dann doch zu eklig.

Wir haben bis zuletzt nicht kapiert, wie genau das Verhältnis zwischen den beiden sichtbaren Anschlußstücken ist - wenn man eins zuhält, arbeitet das andere auch nicht mehr richtig, egal wie rum man Strom dran macht. Deswegen haben wir uns für eine 50iger-Rückspüleinrichtung entschieden (siehe nebenstehendes Prototypenbild) - ein Ende geht einfach wieder in den Tank zurück.

Heisklebepistolen sind in der Lage, eine hervorragende Dichtigkeit gegen Flüssigkeiten herzustellen, ohne dabei spröde zu werden.

Durch die aus der Fahrzeugtechnik entliehenen Bauteile konnten wir auch die Betriebsspannung auf einem nicht sofort tödlichen Niveau halten.

Wie es sich für ein ordentliches Projekt gehört, sind wir erst auf den letzten Drücker mit dem Ding selbst, dessen Kalibrierung und Reinigung und der Steuerungssoftware fertig geworden - so daß wir auch erst am Einsatztag selbst die Rezepte und die Zutaten auswählen und besorgen konnten.

Die Kalibrierung war notwendig, weil die Pumpen eine ziemlich unterschiedliche Pumpleistung haben. Die Reinigung... - naja, die Reinigungsflüssigkeit (billiger Korn) es hat erstmal seifig geschmeckt, aber das gab sich dann mit steigender Laufzeit.

Die Steuerungssoftware ist - wie es sich im Unixbereich gehört - ein shellscript, und die Benutzerschnittstelle als CLI ausgeführt.

Wir haben uns dann für die Grundkomponenten Vodka, Rum, Tequila, Ersatzflüssigkeit, O-Saft und Cola entschieden, damit konnten wir

  • Cuba Libre
  • Grüne Wiese
  • Tequila O-Saft
  • Vodka O-Saft
  • Milde Bowle
  • noch mehr, was ich vergessen habe

erzeugen. Milde Bowle hat per Zufallsfunktion einfach selbst was nettes gemixt. Sah meist eher unappetitlich aus, geschmacklich auch eine neue Erfahrung.

Entgegen unserer Befürchtungen hat die Maschine den ganzen Abend über durchgehalten, es ist quasi nix außer den berühmten letzten Tropfen in die Blutwanne (in der Koloration links rot dargestellt) gelaufen, was man hätte wiederverwenden können. Selbst einen brutalen Umsturzversuch hat die Maschine überlebt (und die Küche verklebt). Das Userinterface ist in seiner Schlichtheit unübertroffen, aber wohl einigen nicht ganz web2.0ig genug.

Der Zuspruch der Gäste war gut, der gesamte, eher großzügig gekaufte Suff ist aufgebraucht worden, und inzwischen kann ich auch schon wieder an Alkohol denken, ohne bohrende Kopfschmerzen auszulösen.

Achja, wir haben das erst gemeinte Angebot von einem anwesenden professionellen Würstchengrillmann, die Maschine mal auf einer Messe vorzuführen.

Version 2 bekommt dann eine schöne V4A-Frontfläche, 10Liter-Vorratstänks und den Eiscrusher gibts auch gleich mit rein (Eis hatten wir extra, Füllhöhenproblem, wissen schon...). Ahja, und einen Münzeinwurf, latürnich.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

19.06.2008

22:13 Uhr  Zattoo - Bernd endlich als Nachtschleife


Gerade versägt die als von allen die sich auskennen als Luschen und Verlierer vorverurteilte Nationalmannschaft die Portugiesen, da fällt im irc die Frage, ob man nicht so schnell jubeln soll, weil ich (der Hauptleidtragende) ja nur dvb-t habe.

Mir doch egal.

Ich nehme Fussi-Ereignisse eh mehr durch Getrampel über mir war als durch auf die Glotze linsen - der Fussball und ich führen eine friedliche Koexistenz durch gegenseitige Nichtbeachtung.

Da herum entspann sich folgender Dialog: 

21:08 @     ct |  Aua.
21:09 @  aleks | einschläfern
21:09 @ dexter |  Schland.
21:10 @  aleks | geht ja schon wieder. 
21:10 @  aleks | Tunte
21:10 @     ct |  Warum kein Gelb?
21:11 @     ct |  aleks: hab gerade nicht geguckt. 
		  Kann der weiterspielen oder wie?`
21:11 @     ct |  TOOOOOAAAAAAAARRRR!!!!!!!11
21:11 @     ct |  YESYES°!
21:11 @  aleks | ct ja
21:11 @  aleks | okay, daswars
21:11 @     ct |  aleks: sorry, bist Du zeitlich hinterher?
21:11 @     ct |  Dann halte ich mich ein wenig zurück.
21:11 @  aleks | ct: was?
21:12 @     ct |  Wegen DVB-T oder so. TV-Lag halt.
21:12 @  aleks | das sind aber nur 5 Sekunden.
21:12 @     ct |  Nicht dass ich hier Tor schreie und es ist bei Dir noch nix.
21:12 @     ct |  OK.
21:12 @  aleks | ich gucke eh nur nebenbei
21:12 @  aleks | die über mir trampeln, bevor du enter drückst.
21:12 @  aleks | schon okay
21:12 @     ct |  Warum bleibt der nicht liegenß
21:13 @ dexter |  Schlandschland.
21:13 @ dexter |  ct: Ich bin zattoomäßig hinterher.
21:14 @     ct |  OK.
21:14 @  aleks | was ist zattoo?
21:14 @  aleks | okay, jetzt will ich einen großen deutschen Sieg.
21:15 @     ct |  dexter: das ist keine halbe Sekunde hinter dem Kabel hier.
21:15 @  aleks | einen vaterländischen, vernichtenden Sieg. 
21:15 @  aleks | 5:1 oder so
21:15 @     ct |  aleks: Du kennst Zattoo nicht?
21:15 @  aleks | nö
21:15 @     ct |  Wahnsinn.
21:15 @  aleks | sonst würde ich nicht fragen, oder?
21:15  *  aleks gugelt
21:15 @     ct |  Das ist IP-Fernsehen.
21:15 @     ct |  Öffentlich-rechtlich ist da drin.
21:15 @     ct |  Das ist sehr sehr großartig.
21:16 @  aleks | ah.
21:16 @  aleks | geil
21:16 @     ct |  aleks: mach ruhig einen Account, da muss man nur
	  	  eine Mailadresse eintragen. Die schicken aber nicht mal 
                  was hin.
21:17 @     ct |  Das war NIEMALS Abseits.
21:20 @  aleks | das ist ja geil
21:21 @  aleks | mir ist vor ein paar tagen das eyetv kaputt
	         gegangen, weiß noch nicht, ob hard oder soft.
21:21 @  aleks | aber so ist das egal
21:21 @  aleks | ct: danke
21:21 @     ct |  aleks: der Privatmurks ist halt nicht dabei.
21:21 @     ct |  Aber dafür gibt es einen Sumo- und einen
	  	  Tischtennis-Sender.
21:22 @  aleks | d.h., da kann ich auch immer die Nachtschleife
	         von Bernd sehen?
21:22 @  aleks | geil. das gibts hier nicht im dvbt
21:22 @     ct |  Glaube schon.

Um es kurz zu machen: Man kann. Ich tue es gerade. Zitat: Die hässliche (Milchglas-Lounge-)Lampe kostet soviel wie ein Kleinwagen und macht so viel Licht wie eine Taschenlampe aus dem Yps-Heft.. Okay, ohne die Betonung von Bernd nicht so witzig, aber die Lounge-Nummer ist grandios.

Die Bernd-freie Zeit ist vorbei! Hurra! Nebenbei gibts auch langvermisstes, richtiges Radio - radio1 - und zwar ohne Reconnect-Gebastel auf einem völlig überlaufenen Realmediaserver und neben allen anderen Öffi-Rechtlichen Sendern (ich glaube, wirklich allen) auch ein paar andere, DMAX, Viva, MTV, Al Jazeera, CNN, usw.

Also, was ist zu tun? guckst du hier. Allerdings schicken sie einem doch eine Mail. Ansonsten kann ich erstmal keine nachteiligen Dinge entdecken.

Noch ein Grund mehr, die öffentlich-rechtlichen weiter gebührenfinanziert im Internet zu zu lassen.

Hmm. Inzwischen steht es 3:1. Irgendwie haben sich da einige schwer verschätzt. Alle - wirklich alle - sind wohl davon ausgegangen, das die Bundeskicker ordentlich einen unter die Jacke bekommen und raus fliegen.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

14.05.2008

10:52 Uhr  Technologie heute - per Maus bedienbare Patchfelder


Internet ist ne wirklich robuste Sache. Da siehts ja fast aus, wie beim Häuptling unterm Sofa.

Aber allerneueste Technologie - per Maus steuerbare Patchfelder und Switche. Aaaaber der Ivan, der is nicht ohne!

Hmm. Gerade ist der Server down - wohl etwas viel Ansturm gerade. Später unbedingt noch mal probieren!

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]

this oerks!

Wegen der Spamseuche wird die angegebene Emailadresse sehr stark gefiltert (und es fehlt das at - sorry) - sie ist von typischen Spam-Domains wie yahoo,hotmail,excite usw. sowie mit syntaktisch und/oder semantisch falschen Emails nicht erreichbar.