Archiv für August, 2009

Umlaute im Irssi

Thursday, 27. August 2009

Chatten ist ja für viele (auch für mich) das halbe Leben. Im Kontakt bleiben, koordinieren, wunderbar :)  Ich nutze dazu meine Shell und Irssi. Immer wenn ein Webserverwechsel ansteht, vergesse ich, wie ich im neuen Irssi nochmals die Umlaute unterstützt bekomme. Lösung: die eigene .bashrc :) Einfach in der .bashrc des Users, der Irssi betreibt die folgenden Zeilen anhängen, neu einloggen, fertig.

LANG=de_DE@euro
LC_ALL=de_DE@euro

Rails > 2.2 und MySQL support

Sunday, 23. August 2009

Lustigerweise ist seit Rails 2.2 die Standard-DB Sqlite 3. Gut, an sich ja nicht schlimm, da MySQL nach wie vor genutzt werden kann. Dementsprechend habe ich einfach

$ gem install mysql

getippt und dachte das war es dann. Pustekuchen ;) Rails fand daraufhin meine MySQL-Instanz nicht und meinte:

!!! The bundled mysql.rb driver has been removed from Rails 2.2. Please install the mysql gem and try again: gem install mysql.

Lösung: einfach die aktuelle libmysql.dll aus eurem Mysql bin-Verzeichnis (bei mir “C:\Programme\MySQL\MySQL Server 5.1\bin kopieren und in das bin-Verzeichnis von Ruby verwfen (bei mir “C:\Programme\Ruby\bin”). Netbeans neustarten, fertig :D

Eins zu kurz gedacht…

Wednesday, 19. August 2009

So ab und an übersieht man schon lustige Fehler :) Gut, mag auch an der Hitze liegen. Wenn man einen Apachen aufsetzt empfiehlt es sich ja, irgendwo recht weit oben in der Konfiguration (ich nehme hier auf debian die apache2.conf) alle Verzeichnisse erstmal von allen Optionen zu befreien, also z.B. so:

<Directory />
# Per default ist auf allen Verzeichnissen erstmal nichts erlaubt
Options None
# Auch .htaccess Dateien duerfen erstmal nichts ueberschreiben
AllowOverride None
</Directory>

Tjo. Soweit die Theorie. Mit Capistrano zusammen ergibt sich dank geschickter Deploymentstrategie allerdings das hier:


<Directory /var/projects/irenia/current/public>
Order allow,deny
Allow from all
</Directory>

wobei current bereits ein Symlink ist. Erst hier also Symlinks zu erlauben macht keinen Sinn, demnach habe ich oben wieder FollowSymLinks hineingeworfen:


<Directory />
# SymLinks brauchen wir dann doch :-)
Options FollowSymLinks
# Auch .htaccess Dateien duerfen erstmal nichts ueberschreiben
AllowOverride None
</Directory>

Wieder was gelernt ;-)

Sicher, sicher Rails!

Monday, 17. August 2009

Selbst in der Browserspielszene (oder gerade da?) hat sich inzwischen herumgesprochen, dass das Surfen ohne Verschlüsselung wenig hip ist. Gerade auf Lan-Partys oder im Rechneraum der Uni / Schule wird sonst jedes nochso schicke Passwort schnell zum offenen Geheimnis. Um nun unsere Rails-Applikation die auf einem Mongrel-Cluster mit einem Apachen als Balancer davor läuft auch über https:// anbieten zu können, müssen wir Rails mitteilen, wann der Benutzer https genutzt hat.  Das wird insbesondere dann kritisch, wenn wir intern redirects benötigten, also so etwas wie

redirect_to :action => 'myList'

Ohne Rails mitzuteilen, dass die ursprüngliche Anfrage per https kam, wirft uns Rails auf http zurück und das bringt nicht nur mich sondern auch den IE (Stichwort: unsicherer Inhalt) durcheinander. Eine schöne Lösung für dieses Problem findet sich im BlogFish von Jonathan Weiss, danke Jonathan! Nachtrag: denkt daran, dass für Jonathans Lösung das Apachemodul headers aktiviert sein muss:

$ a2enmode headers

Die Qual der Wahl

Monday, 17. August 2009

Wer im Leben viel Optionen hat, hat oft die Qual der Wahl. Gerade beim Apachen und dessen Verzeichnis-Direktiven komme ich jedes Mal durcheinander bzw. kann mir nicht merken, was nun was ist. Gott sei Dank gibt es Google und schöne Doku hierzu, wie beispielsweise das Buch Apache 2 aus dem Galileo Verlag, in welchem diese Optionen nochmals fein säuberlich zum Nachlesen aufbereitet sind :)

Auch ein Punkt, bei dem ich immer wieder ins Straucheln komme sind die virtuellen Hosts bzw. genauer deren Abarbeitungsreihenfolge. Nehmen wir einmal an, wir hätten zwei:

<VirtualHost irenia.de:80>
<VirtualHost *:80>

Und es käme eine Anfrage: www.irenia.de. Welcher virtuelle Host wird dann ausgewählt? Richtig! Zuerst der zweite! Grund: der Apache unterteilt bei den Congifs in zwei Abteilungen: einmal Virtual Hosts und einmal Wildcards und default. Innerhalb von mehreren Wildcard (*) Definitionen sucht der Apache übrigens (logischweise) immer allgemeinste Definition heraus. * ist allgemeiner als *:80. Überprüfen könnt ihr die Aufrufreihenfolge jederzeit mit

apache2ctl -S

Was dann bei mir zu dem folgenden Ergebnis führt:

VirtualHost configuration:
91.121.165.229:80 ns361216.ovh.net (/etc/apache2/sites-enabled/001-server-status:3)
wildcard NameVirtualHosts and _default_ servers:
*:80 ns361216.ovh.net (/etc/apache2/sites-enabled/000-default:6)

Capistrano to the rescue!

Saturday, 15. August 2009

Ok, heute war ein Tag, an dem ich viel über das Deployment von Rails gelernt habe. Dank Capistrano ist das Deployment eigentlich super einfach, nur gehöre ich zu der Sorte Mensch die gerne verstehen, was unter der Haube vor sich geht und da muss ich sagen ist das schon sehr elegant was Monseigneur Capistrano tut. Dran interessiert?

Hier gibt es im Openbook von Galileo schöne Hinweise.

In anderen Tutorials (siehe unten) hatte ich beispielsweise nie gelesen, dass ein

$ cap deploy:setup

notwendig ist bevor überhaupt irgendwas deployed wird. Logischerweise flogen mir dann immer die Fehlermeldungen um die Ohren, dass es eben die Verzeichnisse wie shared etc. einfach nicht gab :( Aber gut, man lernt ja nie aus, nach setup dann also

$ cap deploy:cold

Dabei legt Capi auch die Datenbanken an! Ihr solltet also den libmysqlclient-dev installiert haben und danach den mysql gem istallieren, gewohnt einfach mit:

$ gem install mysql

Danach geht es dann ohne Migrations direkt in den Betrieb:

$ cap deploy

Das schöne an Capistrano ist, dass man sowohl den vhost des Apachen als auch die mongrel_cluster.yml nur einmal auf den Symlink “current” umbiegen muss. Ab dann geht alles schön von alleine. Ein klein wenig nervig ist, dass man den Mongrel-Cluster vorher noch von Hand herunterfahren muss, aber gut, das wird sich auch noch irgendwie automatisieren lassen ;) Hier noch rasch die aktuellen Settings:

mongrel_cluster.yml
---
cwd: /var/projects/irenia/current
log_file: log/mongrel.log
port: 3000
environment: production
pid_file: log/mongrel.pid
servers: 3
address: 127.0.0.1

Und mein virtueller Host dementsprechend, auf die wesentlichen Zeilen reduziert:

TBD!

Heute war ein guter Tag :)

Rails und Mysql

Saturday, 15. August 2009

MySQL erfreut sich ja schon seit Jahren großer Beliebtheit, da kostenfrei und aus meiner Sicht auch funktional super. Daher setze ich MySQL gerne ein, auch jetzt mit meinen Rails-Projekten. Dabei muss man eine Kleinigkeit beachten. Beim Erstellen eines Railsprojectes wie etwa

Rails MyApp

erstellt Rails per default die connectoren zu einer Sqlite3 DB. Wollt ihr hier gleich bekanntgeben, dass ihr MySQL nutzen wollt:

Rails MyApp -d mysql

Leider war es das noch nicht ganz, da Rails per default annimmt, dass eure mysqld.sock in /tmp liegt. Je nach eurer Installation ist sie genau da aber nicht, bei mir ist sie beispielsweise unter debian / etch in /var/run/mysqld. Dementsprechend müsst ihr eure database.yml (im Config-Ordner) noch anpassen und Rails mitteilen, wo das socket zu finden ist:

development:
adapter: mysql
encoding: utf8
reconnect: false
database: MyApp_development
pool: 5
username: myUsername
password: myPassword
host: localhost
socket: /var/run/mysqld/mysqld.sock

Rails deployment einfach gemacht

Saturday, 15. August 2009

Bis vor Kurzem habe ich mich noch damit herumgeplagt, wie man Rails Applikationen am besten deployed. Irgendwie sollte man sich bei Rails daran gewöhnen, dass es in der Regel immer jemanden gibt, der sich diese Gedanken längst gemacht hat und eine gute Lösung parat hat. Findet man allerdings keine Lösung, dann sollte man genauestens über das Ziel nachdenken, das man gerade anvisiert ;)

Zum Thema Deployment mit Rails:  https://support.railsmachine.com/index.php?pg=kb.page&id=12

Hier findet ihr die sogenannte Railsmachine. Achtet darauf, dass das Gem Railsmachine mit den Standardinstallationen von Debian / Etch (aktuell 0.9.4) nicht gefunden wird. Dazu einfach auf Gem 1.3.5 updaten (siehe letzter Post). Die Railsmachine hilft euch – so wie es der Name schon sagt – beimAufsetzen einer Railsmaschine auf eurem Rootserver.

Als Erweiterung zum Tutorial musste ich feststellen, dass

railsmachine --apply-to . --name MyApp --domain my.cool.domain

einen Standarduser “deploy” anlegt, mit welchem Capi sich dann per ssh und auf die Datenbank verbinden möchte. Dementsprechend solltet ihr entweder einen deploy-user anlegen oder eben die deploy.rb (in config) auf einen passenden User anpassen.

Zusätzlich hat bei mir die railsmachine den mongrel-Server nicht installiert. Ob das immer so ist, weiß ich nicht genau. Aber was soll’s, dann installieren wir ihn halt nach :) Dazu braucht es allerdings eine Ruby-Entwickungsumgebung. Da wir später auch noch clustern wollen, nehmen wir mongrel_cluster auch noch gleich mit. Und bitte:

$ apt-get install ruby1.8-dev build-essential
$ gem install mongrel
$ gem install mongrel_cluster

Als nächstes müssen wir unseren Mongrel-Cluster erst einmal konfigurieren und die init-Skripte anlegen etc. Hierzu gibt es zwei schöne Tutorials:

1. Ubuntu Gutsy – Mongrel Clusters

und ein zweites, das allerdigs stärker den Capistrano einbindet:

2. Time for a grown up server

Beachtet bitte, dass beim Konfigurieren eurer cluster.yml auf jeden Fall die Zeile cwd: /var/projects/PROJEKTNAME vorhanden sein muss, da mongrel von hier aus relativ euer log sucht.

Die Sache mit den Versionen…

Friday, 14. August 2009

Kennt ihr das auch? Lokal nutzt ihr eine schöne Entwicklungsumgebung und dann kommt der moment, wo ihr euer Projekt endlich online stellen wollt.  Ratz-fatz apt-get heruntergenudelt, rauf die Sourcen und ab die fahrt. Mööööp. Warum hat etch zum Kuckuck nur Gems 0.9.4 und Rails 2.0.2 in der Standarddistri, wenn ich doch schon längst bei 1.3.5 und 2.3.2 bin? Meine Nerven! Gott sei Dank gibt es immer nette Kollegen, die einem die manuellen Updateschritte freundlich und häppchenweise zur Verfügung stellen ;)

http://wiki.rubyonrails.org/getting-started/installation/linux-ubuntu

Rails 2.3.x integriert nun available_locales

Tuesday, 11. August 2009

Seit Rails 2.3 ist es nun endlich soweit, die Rails Internationalization API (I18n) kennt nun die Variable “available_locales”. Dadurch kann das Laden von lokalen Sprachdateien deutlich vereinfacht werden. Ein schönes Tutorial zur Lokalisierung mit I18n findet sich hier http://guides.rubyonrails.org/i18n.html. Um damit auch lokal die Lokalisierung mit Subdomains testen zu können, muss man zunächst seine hosts-Datei anpassen

127.0.0.1 localhost
# virtual hosts
127.0.0.1 de.server.test
127.0.0.1 en.server.test

Im Anschluss daran muss man den ApplicationController der Anwendung entsprechend erweitern:

class ApplicationController < ActionController::Base
# set the locale
before_filter :set_locale
def set_locale
I18n.locale = extract_locale_from_subdomain
end

# de.server.test shold implicate locale "de"
def extract_locale_from_subdomain
parsed_locale = request.subdomains.first
# Genau hier kann nun die neue Variable AVAILABLE_LOCALES genutzt werden
(I18n.available_locales.include? parsed_locale) ? parsed_locale : nil
end
...
end

Rails wird mir immer sympathischer :)