Heute bin ich wagemutig mit meiner Freundin zur Eröffnung des Apple Store in Oberhausen gefahren! Ehrlich gesagt habe ich nicht mit diesem Volksfest ähnlichen Andrang gerechnet. Bisher waren wir noch nicht drin, wir beschäftigen uns noch etwas im Centro bis die Schlangen kürzer werden.
Ich habe auch ein paar Bilder gemacht:
Ich hatte nun schon etwas länger das Problem, dass ich mit meinem Macbook mit OS X 10.6.4 und meinem iPhone kein Tethering mehr per Bluetooth hinbekommen habe. Per USB ging das komischerweise. Auch mit meinem neuen iPhone hat es noch nicht geklappt. Der Verdacht lag also nahe dass es irgendwie mit OS X zusammen hängt.
Nach ein bisschen Recherche habe ich nun im Blog von Peter Pfläging die Lösung für das Problem gefunden.
Bei mir bestand das Problem darin, dass ich zwar verbinden konnte, das IPhone auch aktive Tethering angezeigt hat aber keine Verbindung zu bekommen war. Systemeinstellungen->Netzwerk auf dem Macbook hat dann auch “Keine IP Adresse” unter Bluetooth-PAN angezeigt.
Die Lösung von Peter Pfläging für das Problem sieht so aus, dass man unter OS X eine neue Umgebung fürs Netzwerk erstellt. Nach dem Auswählen der neuen Umgebung kann man dann alle Geräte/Schnittstellen außer Bluetooth PAN löschen und damit dann verbinden.
Bei mir hat danach allerdings dann auch eine Verbindung über die Umgebung automatisch funktioniert?! Ob das so bleibt (nachdem ich dann wieder zu einem anderen Netz verbunden habe) weiß ich allerdings nicht.
Falls nicht würde ich mal ausprobieren, ob man auch auf DHCP verzichten kann. Die Einstellungen würden dann (zumindest bei meinem iPhone) so gewählt werden:
IP: 172.10.20.4
Netmask: 255.255.255.240
GW: 172.10.20.1
Als DNS-Server kann man dann z.B. die DNS Server von Google verwenden. Das wäre dann 8.8.8.8 und 8.8.4.4.
Ob die manuelle Einstellung dann allerdings das Problem löst müsste ich mal ausprobieren wenn das Problem wieder auftritt.
Interessante Idee aus China: Busse fahren einfach über Autos drüber. So kommt es nicht zu Stau und der öffentliche Raum wird optimal genutzt.
Hier ein Video in dem das Konzept vorgestellt wird:
Siehe auch:
Bei der letzten Landtagswahl fand ich die Auflistung der Wahlergebnisse nach Stimmbezirk durchaus interessant. Ich behaupte, man kann an den Wahlergebnissen zum Teil schon ablesen wie sympathisch einem ein Stadtteil sein wird. Das wäre z.B. interessant wenn man neu in eine Stadt kommt und sich schon einmal grob orientieren möchte oder wenn man eine neue Wohnung sucht.
Meine Idee dazu ist nun, die Google Maps API und den CSV Export der Stadt für die Wahlergebnisse (Rohdaten, Infos zur Schnittstelle) zu nutzen. Damit könnte man dann anhand einer Vorauswahl (welche Partei(en) finde ich gut bzw. in welche Hochburg möchte ich auf keinen Fall) die Stadtkarte je nach Wahlergebnis (relativ zum Durchschnittswert der gesamten Stadt) unterschiedlich markieren. Mit der API habe ich vor einiger Zeit schon mal ein bisschen rumprobiert und im Grunde ist sowas nicht wirklich schwierig, das Ausprobieren kostet nur eben Zeit. Aber sobald mal wieder ein bisschen Zeit für solche Spielereien ist, werde ich das wohl mal ausprobieren. Für mich klingt es jedenfalls nach einem spannenden kleinen Projekt.
Von Facebook wird man ja bei jedem Update mit E-Mails versorgt. Heute habe ich aber eine E-Mail bekommen die mir etwas Bauchschmerzen bereitet. In der E-Mail mit Betreff “XY hat eine/n von dir vorgeschlagene/n FreundIn hinzugefügt”, findet sich im Antwort-An-Header (Reply-to) die richtige E-Mail Adresse von XY.
Ich finde es sehr befremdlich, dass Facebook so offen mit den richtigen E-Mail Adressen seiner Mitglieder umgeht. Unter Umständen möchte ja nicht jeder, dass seine E-Mail Adresse auf diesem Wege preis gegeben wird. Vielleicht ist einem ja auch seine E-Mail Adresse vor Geschäftspartnern, mit denen man via Facebook Kontakt hält peinlich (da irgendwann mit 14 Jahren registriert)?
Update: Die E-Mail heißt Facebook-Intern übrigens friend_suggestion_accepted (siehe X-Facebook-Notify-Header)
Mal schnell jemandem zeigen was man selbst sieht? Auf dem Mac kein Problem mit Skitch! Einfach einen Ausschnitt auf dem Bildschirm markieren, ggf. mit einem Marker noch Bereiche unkenntlich machen oder markieren. Mit einem Klick hochladen und direkt eine URL zum hochgeladenen Bild bekommen. Einfacher geht es nicht!
Wer kennt das Problem nicht? Mal schnell testen was die PHP-Funktion XY ausgibt, oder mal schnell einen md5-Hash sha1-Hash generieren? Reguläre Ausdrücke testen? Functions-Online von Jan Bogutzki ist da die Lösung!
Häufiger gebraucht habe ich das Tool z.B. schon um schnell mal HTML-Code für einen Blogbeitrag mit htmlentities so umzuwandeln, dass ich es in den HTML-Editor pasten konnte.
Gefunden habe ich die Seite übrigens über PHP hates me von Nils Langner, die Seite ist übrigens auf jeden Fall einen Stammplatz im RSS-Reader wert!
Leider habe ich schon öfters gesehen, dass ein Verzeichnisschutz in einer Apache .htaccess-Datei etwa so aussah:
AuthUserFile /path/to/htpasswd
AuthName "intern"
AuthType Basic
<Limit GET>
require valid-user
</Limit>
Das sollte man unbedingt NICHT so machen, sondern in das LIMIT nicht nur GET, sondern auch POST mit aufnehmen.
Korrekt ist also:
AuthUserFile /path/to/htpasswd
AuthName "intern"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>
Der Grund dafür ist einfach, auch mit POST kann man nämlich die Daten vom Server abrufen. Um das zu demonstrieren reicht ein einfaches curl -d irgendwelchedaten <url>. Im ersten Fall würde die Seite damit komplett angezeigt, im zweiten würde man den gewünschten Fehlercode bekommen.
Eine nette Seite mit vielen Beispielen zum Thema habe ich hier gefunden: http://home.golden.net/htaccess.html
Ich habe mich mal mit JiffyBox von domainFactory auseinandergesetzt.
Dafür, dass das Produkt erst seit wenigen Monaten am Markt ist, wirkt die Administration schon sehr gelungen und stabil. Das Admin-Panel sieht bis auf ein paar Detailfehler (die Texte in den Header-Leisten sind nicht sauber vertikal zentriert) im Design unter Safari auch sehr schön aus, unter Firefox tritt das Problem nicht auf. Außerdem sieht es in Safari so aus, als würde die Seite ewig laden, das wirkt erstmal etwas irritierend. Unter Firefox tritt aber auch dieses Problem nicht auf. Aber wie gesagt, das sind Detailfehler und die beeinträchtigen nun wirklich nicht die Benutzung, höchstens den perfektionistischen Anspruch von domainFactory.
Für meinen Test habe ich Ubuntu 10.04 LTS 64bit gewählt. Bei der Betriebssystemwahl wirkte der angegebene Speicher hinter dem Namen des Betriebssystems (1 GB oder 512 MB) für mich etwas befremdlich. Ich dachte zunächst, damit wäre gemeint wieviel Platz das Betriebssystem in Anspruch nimmt. Was tatsächlich gemeint war, war dann der Speicher für die SWAP-Partition. Der erste Start verlief dann absolut problemfrei, da gibt es absolut nichts zu meckern. Auch die Informationen während des Starts sind “cool”, man wird nämlich ziemlich live über ein “jQuery-Growl” (ich glaube die setzen keins der dort vorgestellten Plugins dafür ein) informiert was der Server gerade tut. Leider sind diese Informationen beim ersten Start teilweise so schnell wieder ausgeblendet, dass man garnicht alles lesen konnte. Gefühlt ist der Server außerdem sehr schnell.
Eine weitere Kinderkrankheit die mir aufgefallen ist: Unter Profile kann man das Profil des Servers verändern, das dürfte in etwa der Xen-Konfiguration eines Servers entsprechen. Dort kann man auch den Kernel auswählen, mit dem der Server gestartet werden soll. Dazu gibt es dann ein “Mehr Informationen”, das auf diese Seite im Wiki verweist. Dort steht dann, dass man die Xen-Kernel den PV-Kerneln aufgrund von höherer Geschwindigkeit vorziehen soll. Standardmäßig ausgewählt ist aber der PV Kernel und wenn man auf den Xen-Kernel wechselt bootet der Server nicht mehr (Fehler: General error mounting filesystems), merkwürdig. Vermutlich einfach nur ein kleiner Fehler im Wiki der aber den Eindruck etwas trübt. Sehr hilfreich ist in diesem Fall übrigens die Rettungskonsole gewesen, die einem Live die Konsole des Servers anzeigt, super Sache!
Nun ein weiterer Kritikpunkt, private IP Adressen… das ist fast eine Glaubensfrage!
Sicher ist es schön interne Adressen nutzen zu können und manchmal sicher auch sinnvoll. Allerdings finde ich das im Fall von JiffyBox etwas gefährlich. Als ahnungsloser Kunde könnte man ja vielleicht auf die Idee kommen, dass der Adressbereich “intern” in Bezug auf den einen Kunden ist und Dienste wie z.B. einen Proxy offen anbieten. Das ist aber offensichtlich nicht der Fall. Das zur Verfügung gestellte Netz ist nämlich offen für alle Kunden und jeder Kunde erhält eine IP Adresse aus diesem Netz. Im Grunde muss man also die IP Adressen genau so schützen wie die externe auch, damit führt man aber die internen Adressen ad absurdum und könnte direkt die externe IP nutzen und mittels iptables schützen. Da muss man dann allerdings mit dem Traffic aufpassen, so wie es aussieht wird der nämlich berechnet, sobald man die externe Adresse nutzt.
Dabei wäre es mit Sicherheit ein Leichtes das zu ändern (indem man den Traffic erst am Router erfasst oder eigene IP Adressen als Ziel bzw. Quelle vom Accouting ausschließt). Ein nmap über das Netz lieferte allerdings nur 11 erreichbare Server (inklusive meinem Testsystem), das Angebot wird wohl nicht so intensiv genutzt, ist auch nicht bei Auslieferung konfiguriert.
Grundsätzlich schlecht sind interne IP Adressen nun allerdings auch wieder nicht, aber vielleicht wären es auch machbar die Netze jeweils Kundenweise automatisiert abzuschotten (z.B. als Firewall auf dem Hostsystem) um die Netze wirklich wie ein geschlossenes LAN nutzbar zu machen?
Gut, die Backups und die Statistiken sind wirklich schön! Außerdem gefällt es mir, dass man komplette Backups auch als tarball runterladen kann und im Prinzip bei einem anderen Anbieter wieder nutzen kann. Für den professionellen Einsatz wäre es noch schön sowas auch via API machen zu können, damit könnte man dann auch externe Backups realisieren. Löblich ist übrigens, dass per Default tägliche und wöchentliche Backups konfiguriert sind! Die API habe ich mir bisher nur über die Dokumentation angesehen, das sieht allerdings sehr vielversprechend aus.
Interessant finde ich die Angabe des Hostsystems in der JiffyBox-Übersicht, das lässt auf Transparenz hoffen. Darüber könnte man bei mehreren JiffyBoxen erkennen, ob diese auf dem gleichen System liegen oder nicht.
Was da für den professionellen Einsatz vielleicht noch interessant wäre, wäre einsehen zu können, welche Infrastruktur meine verschiedenen JiffyBoxen nutzen. Möchte ich z.B. eine Art Hochverfügbarkeit über JiffyBox erreichen, ist durchaus interessant welche Strom- und Netzwerkfeeds von den Hostsystemen genutzt werden und ob diese unabhängig von einander sind. Das könnte man z.B. über eine nette Grafik darstellen und dem Kunden als Option anbieten als Allokationsziel die höchste Gesamtverfügbarkeit anzustreben.
Das Forum, die Statusseite und das Wiki dürfen natürlich hier nicht fehlen. Leider erlaubt das Wiki keinen Schreibzugriff und für das Forum muss man sich getrennt anmelden. Ein stärker in das Control-Panel integriertes Forum wäre sicher wünschenswert für ein noch direkteres Feedback. Nicht ganz klar ist mir allerdings, wieso gerade das Wiki beharrlich auf eine SSL-Verbindung besteht, schlimm ist das allerdings nicht, eher im Gegenteil.
Wenn man den Gedanken weiter spinnt, könnte domainFactory darauf aufbauend auch fertiges Setups für hochverfügbare Webserver anbieten, die per Klick über mehrere Server installierbar sind und am Ende Zugangsdaten zu fertig konfigurierter Datenbank und einen per SFTP nutzbaren Webserver anzeigen. Wenn man dann Abends zusätzliche Webserver haben möchte, kann man diese dann per Klick hinzubuchen.
Denkbar wäre auch, dass der Loadbalancer für den Spaß von domainFactory selbst zur Verfügung gestellt wird und auf Basis der aktuellen Anfragen dynamisch Webnodes hinzugebucht werden oder abgeschaltet werden. Das wäre dann ein super Cloud-Setup das die Möglichkeiten von JiffyBox meiner Meinung nach optimal nutzt. IP Adressen zwischen den virtuellen Instanzen hin und her verschieben zu können wäre dafür allerdings wohl auch nötig (z.B. für File- oder Datenbankserver). Ob das zur Zeit unterstützt wird kann ich nicht sagen. Damit würde JiffyBox aber meiner Meinung nach auch in den Himmel der “richtigen” Clouds aufsteigen.
Die JiffyBox wie einen gewöhnlichen virtuellen Server oder als Testbereich für irgendwas zu nutzen finde ich eigentlich etwas unwürdig, damit würde man nämlich diverse Möglichkeiten brachliegen lassen. Nichts desto trotz ist JiffyBox mit Xen eine gute Alternative zum gewöhnlichen Virtuozzo Server der Massenhoster, der durch die Hoster an allen Ecken und Enden beschnitten wird.
Die Kosten für Rechenleistung und Plattenplatz werden nicht nach Nutzung sondern nach Zeit abgerechnet und sind sehr günstig. Vermutlich um damit auch die Nutzer anzusprechen zu können, die sonst woanders einen virtuellen Server mieten würden.
Der Traffic ist in Zeiten der Flatrates für alles allerdings eher teurer und für Downloads, Videostreams oder ähnliches daher nur bedingt geeignet. Bei größeren Abnahmemengen dürfte domainFactory da allerdings eher verhandlungsbereit sein. Der Preis je TB Traffic dürfte im Einkauf für domainFactory vermutlich unter 10€ liegen, auf jeden Fall aber unter 20€. Der aktuelle Preis von 12ct je GB liegt hochgerechnet bei etwa 120€ je TB. Vielleicht bietet ja domainFactory demnächst mal Traffic-Pakete an, z.B. 100 GB für 5€, 500 GB für 20€ – damit wäre man dann wieder im Rennen.
Ich könnte mir durchaus vorstellen in Zukunft auch Projekte über eine Plattform wie JiffyBox abzuwickeln. Das Konzept überzeugt mich und die Möglichkeiten die das Produkt schon jetzt anbietet sind super.
Ich glaube JiffyBox hat gute Chancen sich am Markt zu etablieren, das setzt allerdings voraus, dass domainFactory weiter Entwickler dafür abstellt und stets neue Features reinpumpt, ansonsten stirbt das Produkt vermutlich bevor es richtig interessant wird.
Möglicherweise könnte domainFactory auch auf die Idee kommen, das bisherige Webhosting in JiffyBox umzuziehen und damit den eigenen Serverpark zu konsolidieren. Das wäre ein Vertrauensbeweis! Ein paar Web 2.0 Referenzen wären außerdem auch interessant, gerade für die wäre das Angebot nämlich interessant, da wird sich der Vertrieb wohl bemühen müssen 
.
Interessanter Weise findet sich im alt-Tag des Logos auch noch der Hinweis auf die Beta-Version:
<a href="/index.php">
<img src="/images/logo_jiffybox.png" id="jb_logo_top" alt="JiffyBox CloudServer On Demand [beta]">
</a>
Eigentlich schade, dass JiffyBox ganz im Web-2.0-Stil nicht immer noch Beta ist.
Update: Auf status.jiffybox.de wird als Logo auch noch das Bild mit dem Beta-Hinweis genutzt.
Als Systemadministrator möchte man häufig wissen, wie die eigenen Server so ausgelastet sind. Sei es um “beweisen” zu können, dass man mehr oder neuere Server braucht oder um rauszufinden wann Lastspitzen auf welchem Server auftreten. Klingt erst einmal nicht so einfach da ein geeignetes Tool zu finden, dass nicht für noch mehr Last auf den Produktivsystemen sorgt und dazu noch einfach zu handhaben ist (man möchte ja nicht seine Zeit damit verbringen, das Monitoring zu konfigurieren, sondern damit Ergebnisse auszuwerten und entsprechend darauf zu reagieren). Eine alles-inklusive Lösing ist da z.B. Zabbix. Zabbix macht zwar einen sehr professionellen Eindruck, ist für meine Einsatzzwecke aber bisher immer viel zu “aufgeblasen” gewesen. Außerdem gibt es da noch Ganglia, aber auch das finde ich nicht besonders intuitiv.
Einen guter Kompromiss stellt Munin für mich dar. Unter Debian ist Munin sehr schnell installiert und konfiguriert. Es reicht dazu auf den “nodes”, also den Rechnern die man überwachen möchte, das Paket munin-node via apt-get zu installieren. Auf dem Server, der die Daten sammeln soll, wird dann das Paket munin installiert.
Die Konfiguration gestalltet sich sehr einfach, in /etc/munin/munin-node.conf sollte man mit allow die IP spezifizieren, mit der der Sammel-Server verbinden wird. Wichtig ist darauf die etwas “komisch” erscheinende Regex-Notation zu benutzen. Aus 127.0.0.1 wird dadurch z.B. ^127\.0\.0\.1$. Alles andere kann erstmal auf den Standard-Einstellungen bleiben.
Auf dem zentralen Server muss dann noch /etc/munin/munin.conf angepasst werden. Wichtig ist, für jeden Server der überwacht werden soll kurz eine eigene Sektion einzufügen, hier am Beispiel von www.peterchen.net:
[www.peterchen.net]
address www.peterchen.net
use_node_name yes
Nach Veränderungen der Konfiguration sollte man Munin mit /etc/init.d/munin-node restart neustarten. Nach wenigen Minuten dürften die ersten Informationen in der Weboberfläche von Munin erscheinen. Wo Munin die Oberfläche erzeugt, wird auch in der munin.conf festgelegt. Standard ist (bei Debian) /var/www/munin.
Ein Munin in Aktion kann beispielweise hier betrachtet werden: http://munin.ping.uio.no/.
Wenn in den Graphen noch keine Daten erscheinen, sollte man folgende Dinge überprüfen:
