Blog - Seite 2

Von Chrome OS direkt auf sFTP Dateisysteme zugreifen

Darauf habe bestimmt nicht nur ich seit langem gewartet: Seit gestern ist es möglich, vom Chrome OS Filemanager direkt auf Dateien zuzugreifen, die von einem Server per sFTP zur Verfügung gestellt werden. 

Erst im Januar wurde mit Chrome OS 40 die dafür notwendige API "fileSystemProvider" in den Chrome stable channel eingeführt. Diese API soll es Entwicklern ermöglichen, fremde Speicher-Systeme direkt in Chrome OS zu integrieren. Denkbar sind z.B. Webdav-Anbindungen oder Zugriffe auf Dropbox oder Amazon S3. 

SFTP FileSystem

Jetzt hat der Entwickler Yoichiro Tanaka die erste App veröffentlicht, die diese API im Einsatz zeigt: sFTP File System. Startet man diese App, öffnet sich ein Dialog zum Anmelden an einem SFTP-Server. Bemerkenswert ist, wie ich finde, dass bereits in dieser ersten Version die Verwendung der Public-Key Authentifizierung vorgesehen ist. 

Einmal angemeldet, findet sich das Wurzelverzeichnis des angebunden Servers in der "Dateien"-App. Von dort aus können Dateien dann kopiert oder z.B. direkt in einem lokalen Editor bearbeitet werden. Wenn das Dateisystem nicht mehr benötigt wird, wird es auf die selbe Art und Weise wie ein Wechseldatenträger ausgehängt.

Fazit

Die ersten Tests von SFTP Filesystem haben mich begeistert. Die Anbindung der getesteten SFTP-Server erfolgte problemlos. Dateien lassen sich wie gewohnt verwalten und z.B. nahtlos im Editor der Wahl - ich benutze dafür häufig Caret - bearbeiten. Ich denke, die App sFTP-Client, die ich bisher stattdessen verwendet habe, wird bald von meinen Systemen verschunden sein.

Durchlasskontrolle mit Googles reCAPTCHA

Einsatz von Captchas bereits auf dem ReverseProxy

Bei Kunden sehe ich immer wieder interne Webangebote, die im Internet veröffentlicht werden. Häufige Beispiele für solche Webseiten sind Web-basierte Email-Zugänge, wie z.B. Outlook Web Access (owa), oder die Veröffentlichung von Intranet-Anwendungen wie Sharepoint-Seiten oder Wiki-Systemen.

Damit die dahinterliegenden Informationen nur von den richtigen Personen eingesehen werden können, erfolgt eine Authentifizierung der Benutzer beim Aufruf der betreffenden Seite.

Das Problem: die öffentlich zugängliche Benutzerauthentifizierung

Wo liegt das Problem mit derart veröffentlichten Web-Inhalten? Das Problem ist die öffentlich zugängliche Benutzerauthentifizierung. Ein potentieller Angreifer könnte hier beispielsweise von außen durch Ausprobieren (Brute-Force) an gültige Benutzerkennungen gelangen. Dem kann der Administrator dadurch entgegentreten, indem er Benutzerkennungen nach einer festgelegten Anzahl falscher Anmeldeversuche sperren lässt. Wozu das wohl führt, wenn ein automatisiertes Skript trotzdem versucht, die Website mit allen möglichen Benutzer/Passwort-Kombinationen anzusprechen?

Mögliche Lösung: Captchas

Viele Webseiten setzen als Lösung für dieses Problem auf den Einsatz von sogenannten Captchas. Website-Benutzer müssen kryptische Zeichenketten entziffern oder Rechenaufgaben lösen, und zu demonstrieren, dass es sich um eine echte Person handelt, die da gerade die Anmeldemaske ausfüllt.

weiterlesen »

Amazon kann AWS jetzt direkt in Euro abrechnen

Traditionell stellt Amazon die AWS Leistungen in US-Dollars (USD) in Rechnung. Das bedeutet für die eigene Buchhaltung natürlich etwas Mehraufwand: Auf der ausgestellten Rechnung sind USD ausgewiesen, von der Kreditkarte werden dagegen die Beträge in Euro zum jeweils aktuellen Umtauschkurs abgebucht.

Außerdem fallen möglicherweise noch Gebühren für den Auslandseinsatz der Kreditkarte an (typisch sind im Moment ca. 1,5% bis 2%).

Abrechnung ab jetzt in Euro möglich

Seit Montag lässt sich jetzt für den eigenen AWS-Account unter den Account Settings die bevorzugte Währung für die Abrechnung auswählen. Die anfallenden Kosten werden dann in die gewünschte Währung umgewandelt und entsprechend in Rechnung gestellt. Einmalzahlungen werden tagesaktuell umgerechnet, für die nutzungsbezogenen Kosten (z.B. EC2-Instanz-Stunden) erfolgt die Umrechnung am Tag der Rechnungsstellung.

Folgende Währungen sind verfügbar:

  • Australian Dollars (AUD)
  • Swiss Francs (CHF)
  • Danish Kroner (DKK)
  • Euros (EUR)
  • British Pounds (GBP)
  • Hong Kong Dollars (HKD)
  • Japanese Yen (JPY)
  • Norwegian Kroner (NOK)
  • New Zealand Dollars (NZD)
  • Swedish Kronor (SEK)
  • South African Rand (ZAR)
Die Umrechnungskurse werden von Amazon Services LLC festgelegt und können deshalb geringfügig von den Kursen abweichen, die die eigene Kreditkartenbank in Rechnung stellen würde.

Die Nutzung der Währungsumrechnung durch Amazon ist im Moment nur möglich, wenn als Zahlungsmethode eine Visa oder MasterCard Kreditkarte hinterlegt ist.


Hier die offizielle Ankündigung von Jeff Barr im AWS-Blog: New - Set Preferred Payment Currency for your AWS Account

Wer schreiben darf, darf löschen? [update]

Implementierung eines Drop-Only Archiv-Verzeichnisses unter Linux

Wer schreiben darf, darf löschen! Diese Aussage ging mir durch den Kopf, als ein Kunde mir vor Kurzem am Telefon von seiner Idee erzählte: Für das interne Auftragsmanagement soll eine Ablagestruktur auf dem Samba-basierten Fileserver realisiert werden. Die Herausforderung: Die Ablagestruktur soll eine Art "Drop-only"-Ordner sein. Benutzer einer bestimmte Gruppe sollen beliebig Dateien in den Ablageordner schreiben dürfen, anschließend sollen die Dateien allerdings unveränderbar sein. Kein nachträgliches Bearbeiten, kein Umbenennen und schon gar kein Löschen - auch nicht für den Ersteller der Datei.

Problem: Wer schreiben darf, darf löschen

Mein erster Gedanke zu dieser Idee war der eingangs erwähnte: "Wer schreiben darf, darf löschen!" Wenn unter Linux einem Benutzer Schreibrechte auf einem Verzeichnis eingeräumt werden, kann dieser Benutzer in diesem Verzeichnis im Endeffekt alles: Dateien erzeugen, umbenennen und löschen. Dabei ist es total egal, wie die Rechte für die betroffenen Dateien gesetzt sind.

Weil ich bei solchen Problemfragen aber ungern "das geht nicht" sage, sagte ich am Telefon eher so etwas wie "Irgendwie geht das bestimmt - ich denke darüber nach".

Und tatsächlich - so ein Szenario lässt sich umsetzen, und der zugehörende Aufwand hält sich dabei in Grenzen.

weiterlesen »

Es wird Zeit, sich mit Docker zu beschäftigen

Quelle: docker.com
Bild: docker.com
Kurz nachdem Google die Alpha Version seines Management-Service für Docker-Container - die "Google Container Engine" - vorgestellt hat, bietet auch Amazon AWS mit dem "EC2 Container Service" eine Preview-Version für ein entsprechendes Werkzeug an. Gleichzeitig hat Microsoft in den letzten Monaten sehr viel Engagement in Richtung Docker gezeigt und eine Partnerschaft mit Docker Inc. bekannt gegeben. Und obwohl ich gestehen muss, dass ich die Entwicklung von Docker bis jetzt eher nur mit einem halben Auge und am Rande verfolgt habe, wird es jetzt höchste Zeit, das zu ändern.
weiterlesen »

Amazon nimmt neues Rechenzentrum in Frankfurt in Betrieb

Wie Jeff Barr im AWS-Blog schreibt, hat Amazon heute die neue Region "EU (Frankfurt)" in Betrieb genommen. Diese neue Region unterstützt - soweit ich das sehe - alle AWS Services.

Mit dieser Region können AWS-Nutzer jetzt also Ihre Daten und Services komplett in Deutschland hosten. Außerdem ist es zusammen mit den Rechenzentren in Irland möglich, multi-Regionale Anwendungen zu bauen, deren Daten Daten komplett in der EU bleiben.

Ein kurzer Test der Preisliste zeigt, dass die Preise für EC2 Instanzen und S3 Storage der neuen Region im Moment etwas über den Preisen der Region "EU (Ireland)" liegen.

Ich bin gespannt, wie das neue Angebot angenommen wird. Bis jetzt hatte ich jedenfalls immer den Eindruck, dass viele Unternehmen in Deutschland den AWS-Einstieg gescheut haben - aus Furcht vor der Datenhaltung im Ausland. Diese Hürde fällt jetzt ja weg :-)

Automatisierte Fehlerseiten mit Route53 und S3

Es darf nicht passieren - und dann es passiert doch. Selbst die am besten durchdachte Website ist irgendwann einmal offline. Mögliche Gründe dafür sind vielfältig: Ausfälle beim Hosting-Provider, Probleme mit der Internet-Anbindung bei selbst gehosteten Projekten, Software-Probleme mit Webserver oder Datenbank oder auch einfach nur menschliches Versagen.

Im besten Fall erhält der geneigte Website-Besucher in so einem Fehlerfall eine schön designte Fehlerseite, auf der man sich für die auftretenden Probleme aufrichtig entschuldigt und empfiehlt, doch später wieder vorbei zu schauen.

Mit etwas Logik und Programmieraufwand lassen sich solche Fehlerseiten natürlich innerhalb der eigenen Webumgebung realisieren. Aber was ist, wenn selbst diese nicht mehr ausgeliefert werden können? Dann erhält der Besucher vielleicht einfach eine kryptische Fehlermeldung des CMS oder er wartet frustiert auf die Timout-Meldung seines Browsers, der den Webserver nicht erreichen kann.

Mit einer Kombination aus Amazons Route53 und dem Amazon S3-Cloudspeicherservice lassen sich für solche Fehlerszenarien robuste Fehlerseiten zu sehr geringen Kosten realisieren.

weiterlesen »