Nach dem Upgrade auf Ruby 1.9.1 und Rails 3.0 unter Mac OS X Snow Leopard hatte ich einigen Ärger mit RubyGem Warnungen. Insbesondere, wenn ich den Server innerhalb des Rails-3-Projektes mit dem folgenden Kommando starten wollte:

rails server

Zu Beginn, als ich noch mit dem bundler Gem Version 0.9.3 arbeitete, waren es zwei Arten von Fehlern bzw. Warnungen: Die erste Warnung hat das Termial mit hunderten Zeilen Code gefüllt, wie …

WARNING:  # NoMethodError: undefined method ` ' for nil:NilClass 
# -*- encoding: utf-8 -*-
...
WARNING:  Invalid .gemspec format in \
'.rvm/gems/ruby-1.9.1-p378/specifications/spec.gemspec'

Das Bundler-Team rund um Carlhuda hat den Fehler mit der Bundler Version 0.9.4 behoben … das Problem sollte nach einem Update des Gems also nicht mehr auftauchen.

Das andere Problem war allerdings etwas hartnäckiger. Beim Start des Servers via

rails server

oder beim Durchführen eines Tests via

rake

innerhalb eines Rails-3-Projektes kamen die folgenden Warnungen:

/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:14: \
warning: already initialized constant VERSION
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:14: \
warning: already initialized constant RubyGemsVersion
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:194: \
warning: already initialized constant MUTEX
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:196: \
warning: already initialized constant RubyGemsPackageVersion
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:202: \
warning: already initialized constant WIN_PATTERNS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1079:\
 warning: already initialized constant MARSHAL_SPEC_DIR
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1084: \
warning: already initialized constant YAML_SPEC_DIR
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/version.rb:72: \
warning: already initialized constant VERSION_PATTERN
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/requirement.rb:20: \
warning: already initialized constant OPS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/requirement.rb:30: \
warning: already initialized constant OP_RE
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/version.rb:246: \
warning: already initialized constant Requirement
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:18: \
warning: already initialized constant TYPES
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/platform.rb:171: \
warning: already initialized constant RUBY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/platform.rb:177: \
warning: already initialized constant CURRENT
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:39: \
warning: already initialized constant NONEXISTENT_SPECIFICATION_VERSION
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:50: \
warning: already initialized constant CURRENT_SPECIFICATION_VERSION
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:56: \
warning: already initialized constant SPECIFICATION_VERSION_HISTORY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:72: \
warning: already initialized constant MARSHAL_FIELDS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:75: \
warning: already initialized constant TODAY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:593: \
warning: already initialized constant Cache
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:14: \
warning: already initialized constant DEFAULT_BACKTRACE
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:15: \
warning: already initialized constant DEFAULT_BENCHMARK
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:16: \
warning: already initialized constant DEFAULT_BULK_THRESHOLD
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:17: \
warning: already initialized constant DEFAULT_VERBOSITY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:18: \
warning: already initialized constant DEFAULT_UPDATE_SOURCES
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:24: \
warning: already initialized constant OPERATING_SYSTEM_DEFAULTS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:30: \
warning: already initialized constant PLATFORM_DEFAULTS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:53: \
warning: already initialized constant SYSTEM_WIDE_CONFIG_FILE

Jeremy Kemper vom Rails-Core-Team hat klar gemacht, dass diese Warnungen kein Rails- sondern ein RubyGem-Bug sind. Ruby 1.9 wird mit einer veralteten RubyGems-Version ausgeliefert … Ruby Version 1.9.1p378 beinhaltet RubyGems 1.3.1. Ich habe natürlich die RubyGems auf Version 1.3.5 aktualisiert mit

sudo gem update --system

aber diese Aktualisierung führte zu zwei RubyGem-Installationen die die Warnungen verursachen.

So, wie kann man das Problem lösen? Ein Löschen von Ruby 1.9.1 und die Neuinstallation haben leider keinerlei Effekt … die Lösung ist im Grunde recht simpel:

Ist Ruby 1.9.1 und Rails 3.0 beta schon installiert …

1. Wichtig: Nach der Installation von Ruby 1.9.1 darf auf KEINEN FALL RubyGems 1.3.5 separat manuell installiert werden – das wäre eine Doppelinstalltion. Das sollte man unbedingt beherigen, wenn man die wunderbare Beschreibung von Dan Benjamin, wie man Ruby, RubyGems, und Rails auf Snow Leopard installiert nutzt.

2. Wenn man also Ruby 1.9.1 installiert hat, RubyGems auf 1.3.5 und Bundler auf 0.9.4 upgedated und Rails 3.0 installiert hat, ist das einzige was man tun muss folgendes:

sudo gem uninstall rubygems-update

Das wars. Keine Fehler mehr!

Falls Ruby 1.9.1 und Rails 3.0 noch nicht installiert ist …

1. Man kann mit Dan Benjamins Rezept starten und modifiziert die Befehle für download, make und install von ruby-1.9.1-p378.tar.gz. Wichtig ist natürlich, dass man rubygems-1.3.5.tgz NICHT wie angegeben installiert.

2. Dann wird das veraltete RubyGems mit folgendem Kommando aktualisiert:

sudo gem update --system

3. Jetzt sollten die Gems rake und sqlite3-ruby installiert werden.

4. Schließlich werden noch die weiteren Gems und rails –pre installiert, wie in den Rails 3.0 beta Release Notes beschrieben.

5. Nach der erfolgreichen Installation von Rails 3.0 beta fehlt noch der entscheidende Schritt:

sudo gem uninstall rubygems-update

6. Am Ende gilt es nur noch zu prüfen, ob einige Gems noch aktualisiert werden können bevor man sich in Rails 3.0 stürzen kann …

sudo gem update

Hope this helps … und hoffentlich spart es etwas Zeit Thx Andy für den Hinweis

MAMP, eine lokale Webserver-Umgebung auf dem Mac, eignet sich immer wieder wunderbar für das Testen, Entwickeln und Gestalten mit WordPress. MAMP bringt Apache, MySQL und PHP fertig konfiguriert in einem eigenen Verzeichnis mit. Leider kann die Installation und Konfiguration eines WordPress-Blogs den Zugriff auf die MAMP-Startseite verhindern:

Forbidden
You don’t have permission to access /MAMP/ on this server.
Apache/2.0.63 (Unix) PHP/5.2.11 DAV/2 Server at localhost Port XXXX

Das ist natürlich mehr als ärgerlich, da von der Startseite aus beispielsweise die Konfigurationseite phpMyAdmin, zur Administrierung der MySQL-Datenbank, nicht mehr erreichbar ist.
Bei mir lag es an einer falsch platzierten Datei: Beim Konfigurieren der WordPress-Installation über das Web-Interface wurde eine .htaccess-Datei fälschlicherweise im Root-Verzeichnis meiner Festplatte abgelegt. Etwas beunruhigend – aber ein lösbares Problem

Wie immer: Die Lösung ist wie immer auf eigene Gefahr … insbesondere das Terminal ist ein wunderbares Werkzeug … mit dem man aber auch viel kaputt machen kann!

Die Datei fällt im Finder nicht auf, das sie wie alle Punk-Dateien in UNIX normalerweise nicht angezeigt werden. Also bemüht man das Terminal und sieht sich das Root-Verzeichnis der Festplatte mal genauer an:

cd /

dann

ls -la

Findet sich dort die Datei .htaccess, sollte man sich vor dem Löschen bzw. Umbenennen nochmal den Inhalt genauer ansehen:

cat .htaccess

Am Einfachsten ändert man ihren Namen und macht die Datei sichtbar:

mv .htaccess htaccess-backup

So erscheint die Datei wieder im Finder und richtetet kein Unheil mehr an … wenn man sich sicher ist, dass man die Datei auch nicht mehr braucht, kann man sie natürlich jetzt auch im Finder einfach in den Papierkorb ziehen

webmail.google.com hijacked by t-online

• Ein unbedarfter T-Online-Kunde gibt webmail.google.com in seinen Browser ein.
• Er bekommt keine Fehlermeldung, sonder eine Seite von T-Online unter der URL “http://webmail.google.com/” zu sehen.
• Auf der von T-Online übermittelten Seite wird einerseits darüber informiert, dass die eingegebene Internet-Adresse nicht gefunden werden konnte. Darüber hinaus hat sich T-Online erlaubt, die eingegebene URL zu analysieren und nach Schlagworten zu durchsuchen. Passend zu diesen Schlagwörtern werden vom Yahoo-Werbeservice Overture.com Werbeanzeigen bzw. Suchergebnisse präsentiert und die Klicks der Nutzer auf Suchergebnisse und Werbeanzeigen getrackt.
• Hätte der Nutzer nur mail.google.com eingegeben, dann wäre er beim gewünschten Service von Google und nicht bei T-Online gelandet …

Das Verfahren, das T-Online für die Realisierung ihrer so genannten “Navigationshilfe” verwendet, wird auch als DNS-Hijacking bezeichnet: Statt eine korrekte Fehlermeldung bei einem vertippten Domain-Namen zurückzugeben, leitet T-Online diese Anfrage einfach auf ihre Server um und analysiert die Anfrage zu Werbezwecken. Das Verfahren von T-Online ist in vielerlei Hinsicht mehr als bedenklich:

• Der Service zeigt, dass die T-Online nicht als neutraler Internet-Service-Provider agiert und den Nutzer mit dem gewünschten Server verbindet – oder eben auch nicht verbindet, wenn der Server nicht verfügbar ist.
• T-Online bemächtigt sich in den Augen der Nutzer gegebenenfalls der Domains und präsentiert unter der Vorspiegelung des angeforderten Domain-Names andere Inhalte: Der Nutzer muss ja davon ausgehen, dass die Infos, die ihm unter “webmail.google.com” (Screenshot via T-Online) gezeigt werden auch von Google.com kommen. Das Vorgehen von T-Online deckt sich dabei auf perfide Weise mit Phishing-Angriffen auf Banken zum Identitätsdiebstahl – nicht umsonst verwenden die Phishing-Angreifer mit Rogue-DNS-Servern ein ähnliches Prinzip wie die T-Online mit ihrer “Navigationshilfe”.
• Interessant ist die “Navigationshilfe” natürlich besonders für die Konkurrenten von besucherstarken Webseiten: Microsoft freut sich sicher über die Platzierung ihres Links auf http://webmail.google.com – und auch die Direktbank Comdirekt ist sicher nicht unglücklich über die prominente Platzierung ihrer Werbung für ein kostenloses Girokonto unter http://online.deutschebank.com (Screenshot via T-Online). T-Online kapert also mit der Navigationshilfe bestehende Domains falls ein Nutzer sich bei der Subdomain verschreibt und schaltet darauf Suchergebnisse und ggf. Werbung von Konkurrenten – über die Schadensersatzforderungen an die Deutsche Telekom AG machen sich hoffentlich bald die Rechtsabteilungen von Google, Deutsche Bank und anderen Gedanken. Auch die Wettbewerbshüter der EU könnten sich zu dem Thema so ihre Gedanken machen.
• Auch ein Teil der falsch geschriebene oder nicht registrierte Domains werden von T-Online abgefangen und kommerziell verwertet. Das ist natürlich weitaus weniger mühsam als interessante Domains für teures Geld zu registrieren und dann, wie z.B. über Sedo.com zu parken und darauf Werbung zu schalten. Auch diese Vorteilsnahme von T-Online ist sicher voll im Sinne der Wettbewerbshüter.
• Wie in den FAQs der “Navigationshilfe” beschrieben, behält sich die Deutsche Telekom AG alle Abfragen mit falscher Subdomain oder nicht vorhandener Domain zu speichern. Großzügigerweise verzichtet die Telekom auf eine personenbezogene Speicherung. Allerdings frag man sich schon, wofür T-Online dann trotzdem ein Cookie mit einer Verfallszeit von einem Jahr auf dem Rechner der Nutzer speichert. Übrigens werden auch die Klicks auf die präsentierten Suchergebnisse und Werbeanzeigen von der Yahoo-Tochter Overture.com getrackt. Sicher eine Goldgrube für Data-Mining-Experten … und ein Alptraum für Datenschützer.
• Als T-Online-Kunde ist es besonders verwunderlich, dass dieser “Service” einem ungefragt untergeschoben wird. Kein Double-Opt-In-Verfahren, sondern eine komplizierte Abmeldeprozedur. Die T-Online hätte ihre Kunden ja auch fragen können, ob sie einen manipulierten DNS-Server haben wollen, der ihre Anfragen gegebenenfalls zu Werbezwecken weiterverarbeitet. Dann hätte sich der Service aber sicher nicht so schnell durchgesetzt.
• Die T-Online verstößt mit dem DNS-Hijacking möglicherweise auch gegen die RFC-Standards zur Implementierung von DNS-Servern der Internet Engeneering Task Force – IETF die Grundlage für eine reibungslos funktionierende Internet-Infrastruktur sind. Spamfilter und andere Webservices sind ggf. auf standardkonforme Antworten des DNS-Servers angewiesen um beispielsweise zu erkennen, dass es eine Domain überhaupt nicht gibt. All diese Services funktionieren nicht mehr, wenn sie über T-Online und deren Navigationshilfe mit dem Internet verbunden sind. Vielleicht sollte die ICANN auch die T-Online in die Schranken weisen, wie sie es mit VeriSign 2003 erfolgreich gemacht hatten.
• Mit dem Anzeigen von Werbung und Suchergebnisses auf gekaperten Domains ergeben sich auch eine Reihe von Sicherheitsrisiken – Ryan Singel’s Artikel in der Wired finden sich dazu noch mehr Hintergrundinformationen. Auch im Bericht der ICANN zum VeriSigh Site-Finder-Projekt finden sich weitere Informationen über mögliche Sicherheitsrisiken durch den Navigationshilfe-Service der T-Online.
• Möglicherweise verstößt die Deutsche Telekom AG mit der Einführung der Navigationshilfe auch gegen das Grundrechte der Informationsfreiheit (Art. 5 Abs. 1 GG) und gegen das Fernmeldegeheimnis (Art. 10 Abs. 1 GG). Dazu könnte die DNS-Manipulation durchaus auch den Straftatbestand der Datenveränderung (§ 303a StGB) erfüllen – dann wäre die Staatsanwaltschaft gefordert. Doch darüber sollten die Rechtsanwälte unter euch diskutieren.

Hintergrund: VeriSign musste auf Druck der ICANN 2003 seinen Site-Finder-Projekt einstellen
VeriSign hatte als Registrierungsstelle aller .com und .net Domains im Jahr 2003 mit dem “Site Finder” Projekt einen ähnlichen Service wie die T-Online Navigationshilfe aufgesetzt. Nach heftigsten Protesten stellte VeriSign unter dem Druck der ICANN den Service nach wenigen Wochen wieder ein. Die ICANN hat über diesen Fall einen Bericht verfasst, der die Gefahren und Problem einer solchen Lösung nochmals klar und deutlich machen. Weitere Hintergründe zu VeriSign Site Finder und zu ähnlichen DNS-Mißbräuchen finden sich in Ryan Singel’s Artikel in der Wired.

Hintergrund: DNS-Server
Das WWW funktioniert nach dem einfachen Prinzip, dass jeder Domain-Name in einer URL wie “http://webmail.google.com” erstmal in einem dicken “Telefonbuch” nachgeschalgen werden muss – im sogenannten Domain Name System, kurz DNS. Auf den DNS-Servern ist zu jeder registrierten Domain – und gegebenenfalls auch zu den registrierten Subdomains – eine IP-Adresse hinterlegt, unter der der Server erreicht werden kann. Ist für die gewünschte Domain oder Subdomain kein Eintrag vorhanden, so muss der DNS-Server eine Fehlernachricht zurückschicken (für die Nerds unter Euch: eine NXDOMAIN-Response).

Microsofts Windows Life Hotmail Service hatte bisher auf dem iPhone (und auch auf anderen Mobiltelefonen) keinen Spass gemacht: Die E-Mails waren nur über die Web-Seite abrufbar. Mit den modernen Smartphone-Browsern funktionierte das zwar – die Usability blieb allerdings völlig auf der Strecke.
Jetzt hat sich Microsoft wohl dem Druck der Massen gebeugt und bietet nun auch den Abruf der E-Mails per POP3-Server an. Die meisten anderen Free-Mail-Provider bieten diesen Service schon seit langem. Mit diesem Schritt gibt endlich auch M$ ihren Kunden die Möglichkeit die Hotmail-E-Mails direkt in den Mail-Client zu übertragen und dort anzusehen und zu bearbeiten.
So lassen sich diese auf dem iPhone mit der nativen Mails-Applikation bearbeiten. Auch mit anderen Smartphones wie dem T-Mobile Google G1 oder dem Blackberry ist damit endlich Hotmail mobil nutzbar. Auf dem Mac und PC funktioniert der Abruf der Mails über POP3 natürlich auch – auf dem Mac beispielsweise mit Apple Mail, Mozilla Thunderbird oder M$ Entourage.

Folgende Account-Einstellungen sind notwendig:

• POP-Server: pop3.live.com (Port 995)
• SMTP-Server: smtp.live.com (Port 25)
• SSL-Verschlüsselung für die POP3- und SMTP-Verbindung müssen aktiviert sein.
• SMTP-Authentifizierung durch Kennwort muss eingeschaltet sein.

Neue E-Mail-Accounts lassen sich auf dem iPhone unter “Einstellungen” > “Mail, Kontakte, Kalender” hinzufügen. Vielleicht wird Hotmail durch diesen Schritt wieder etwas attraktiver …

Quelle: news.softpedia.com

Seit heute ist die Registierung zur – wohl wieder größten – Ruby-on-Rails-Konferenz in den USA möglich: RailsConf 2009. Wie in den vorigen Jahren organisiert O’Reilly wieder das Event. Dieses Mal findet die Konferenz allerdings nicht in Portland sondern in Las Vegas statt – nicht nur das Glücksspiel- und Vergnügungszentrum der USA sondern auch ein begehrter Konferenzstandort
Für die Schnellentschlossenen bis zum 16. März winkt ein Early-Bird-Bonus mit dem sich 200 USD sparen lassen.
Für alle die auf der Konferenz einen Vortrag halten wollen, wurde das Abgabedatum für einen Call for Participation bis zum 17. Februar 2009 verlängert. Da heißt es also schnell sein!
Die Konferenz selbst findet dann vom 4. bis 7. Mai 2009 im Las Vegas Hilton statt.

Viva Las Vegas!

Quellen: rubyonrails.com, RailsConf.com