Nameserver einer Domain herausfinden
nslookup funkensturm.de

MX Record einer Domain herausfinden
nslookup -query=mx funkensturm.de

DNS Cache flushen
dscacheutil -flushcache

Prozesse (zu einem Command) mit PID’s herausfinden
ps aux | grep -i ruby
| grep -i command nur wenn man die Prozesse zu einem Command haben will

Prozesse beenden
kill -9 PID
killall command

mit den zwei fang ich mal an. Wird aber immer schön erweitert. Wenn ihr welche habt einfach in die Comments!

** [err] Permission denied, please try again.
** [err] Permission denied, please try again.
** [err] Permission denied (publickey,password).
** [err] svn: Netzwerkverbindung wurde unerwartet geschlossen

In die /config/deploy.rb muss folgende Option mit aufgenommen werden:

default_run_options[:pty] = true

Wenn ihr wissen wollt wieso, müsst ihr im original Beitrag nachschauen. Es hat mit den Rechten bei der shell zu tun und jetzt werden auch die user profile auf dem server vorher geladen.

Hier lag des Rätsels Lösung:

aptitude install libmysqlclient15-dev

Und erst dann hat man die mysql_config wie folgt zur Hand:

gem1.8 install mysql — –with-mysql-config=/usr/bin/mysql_config

Wie gesagt, “aptitude” muss für den ein oder anderen “apt get” sein und wenn man nicht als root eingeloggt ist, kommt noch ein “sudo” vor jeden Befehl.

Hinweis: Welches Paket man sich mit apt installieren muss (dieser Post muss ja nicht der aktuellste sein ;), kann man mit diesem Befehl herausfinden. Dann nimmt man einfach die neuste Version von dem oben genannten.

aptitude show libmysql

Eine einfach Lösung für dieses Problem ist ein Cron Job der das Verzeichnis regelmäßig aufräumt und alle alten (stale) Sessions löscht.

Hierfür habe ich ein Shell Script geschrieben, was ich in den Script Ordner meines Rails Projektes abgelegt habe. So sieht es aus:
script/remove_stale_sessions.sh

#!/bin/sh
find ../tmp/sessions/ruby_sess.* -mtime +1 -print | xargs rm -rf

Das Script löscht alle Sessions die seit 1 Tag nicht mehr benutzt wurden. Jetzt fehlt noch der Cron Job, der das Script alle paar Minuten aufruft. Ich hab ihn mal auf alle 10 Minuten gestellt. Mit crontab -e ruft man den Cron Job Manager auf. Jetzt i drücken, damit man in den INSERT Mode kommt und in die letzte Zeile folgenden Code schreiben:

*/10 * * * * sh /pfad/zur/app/script/remove_stale_sessions.sh

esc drücken um den INSERT Mode zu verlassen und :wq zum speichern und schon sollte der neue Cron installiert sein.

Update:
Ach so… vielleicht sollte man dafür gleich nen Deployment Task oder so was schreiben… irgendwas, damit man halt nicht bei jedem Projekt dran denken muss… wenn jemand Vorschläge hat…

“meinprojekt” ist im Folgenden das Verzeichnis auf dem Server, wohin deployed wurde. Standardmäßig ist das glaube ich /u/apps/meinprojekt.

Also zum Beispiel meinprojekt/public/uploads wird nach dem deploy einfach gelöscht und alle Dateien sind weg (nicht wirklich weg, man muss nur im Verzeichnis meinprojekt/releases danach suchen ;).

Um das zu verhindern (hier gefunden) muss man im meinprojekt/shared Verzeichnis auf dem Server wo man es deployed hat die Verzeichnisse erstellen, die solche wichtigen Sachen enthalten.

Also z. B. mkdir meinprojekt/shared/public/uploads. Anschließend passt man seine deploy.rb wie folgt an:

task :after_update_code, :roles => :app do
run “ln -nfs #{deploy_to}/shared/public/uploads #{release_path}/public/uploads”
end

Dadurch wird nachdem der Code deployed (also hochgeladen) wurde, ein Hardlink von dem deployten uploads-Verzeichnis auf /u/apps/meinprojekt/shared/public/uploads gemacht. Also sozusagen ein weiterverweisen auf das shared Verzeichnis.

Immer wenn jetzt jemand was hochläd, wird es in shared gespeichert, anstatt in current. Beim nächsten Deploy wird der Link wieder auf shared gesetzt und keine Daten gehen verloren.

Hier mal ein Beispiel für meine Gallery:

namespace :deploy do
[task :start...]
after “deploy:update_code”, :link_to_shared
end

# Create hard links to data in shared
desc “Link in critical data”
task :link_to_shared do
run “ln -nfs #{deploy_to}/shared/config/database.yml #{release_path}/config/database.yml”
run “ln -nfs #{deploy_to}/shared/backup #{release_path}/backup”
run “ln -nfs #{deploy_to}/shared/private #{release_path}/private”
run “ln -nfs #{deploy_to}/shared/public/images/gallery #{release_path}/public/images/gallery”
run “ln -nfs #{deploy_to}/shared/public/images/pending #{release_path}/public/images/pending”
end

Super. Danke Capistrano 2, dass du das kannst :)

wenn du sowas hast:

client denied by server configuration: proxy:balancer://mongrel_cluster/

dann musst du in deine httpd.conf das hier reinschreiben, (weil in der /etc/apache2/mods-available/proxy.conf alles auf “deny from all” steht):

und wenn du danach das hier hast:

proxy: No protocol handler was valid for the URL /. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

dann musst du den mod_proxy_http hinzufügen:

ln /etc/apache2/mods-available/proxy_http.load /etc/apache2/mods-enabled/proxy_http.load
/etc/init.d/apache2 restart

Hat mich ‘ne Stunde gekostet ;)

Zuerst habe ich meinen Useraccount auf dem Server namens “future” in den gleichen Usernamen geändert, den ich lokal auf meinem PowerBook benutze. Nämlich “futurec”. Das Passwort habe ich ebenfalls so angepasst, dass es auf dem Server jetzt das selbe ist wie auf meinem lokalen Rechner. Zuletzt noch das Homeverzeichnis umbenannt:

usermod -l futurec future
passwd futurec
mv /home/future /home/futurec

Dann habe ich auf meinem PowerBook (nach dieser Anleitung) folgendes eingegeben und mehrmals Return für die Abfragen eingegeben (also Standardeinstellungen):

ssh-keygen -t dsa

Anschließend habe ich mit Cyberduck und SFTP die Datei ~/.ssh/id_dsa.pub auf den Server geladen. Dort habe ich dann (in dem Verzeichnis wo ich die Datei hochgeladen habe) folgendes eingegeben. So wurde mein SSH-Public-Key in die vom Server authorisierten Keys aufgenommen und die hochgeladene wieder Datei gelöscht:

cat id_dsa.pub >> /.ssh/authorized_keys
rm id_dsa.pub

Dann musste ich in der Datei /etc/ssh/sshd_config sicherstellen, dass man sich per SSH überhaupt mit Keys einloggen darf:

PubkeyAuthentication yes
AuthorizedKeysFile /.ssh/authorized_keys

SSH neu starten:

/etc/init.d/ssh restart

Ab dann war es mir möglich, mich ohne Passwort, aber mit dem private Key ~/.ssh/id_dsa in z. B. Cyberduck einzuloggen.

Lokal auf dem Laptop habe ich dann die Datei ~/.ssh/config angelegt:

Host = fs
HostName = 123.123.123.123
User = futurec
Port = 4444

Und schon kann ich mich jederzeit ganz einfach mit diesem Befehl per SSH auf dem Server einloggen ohne jegliches Passwort eingeben zu müssen:

ssh fs

:)

Verzeichnis für Repositories auf dem Server erstellen:

mkdir /var/svn

Jetzt wird aus diesem Verzeichnis ein subversion repository gemacht:

svnadmin create /var/svn

Da der Server bisher nur über einen root Zugang verfügte, erstmal Benutzer anlegen, die subversion später nutzen werden:

useradd future
useradd manuel

Diese bekommen dann noch schöne Passwörter verpasst. Bei Eingabe wird ein gewünschtes Passwort für den jeweiligen user abgefragt.

passwd future
passwd manuel

Jetzt noch die home-verzeichnisse anlegen:

mkdir /home/future
mkdir /home/manuel
chown future:users /home/future
chown manuel:users /home/manuel

Damit wir uns später Arbeit sparen, legen wir eine Gruppe an, und setzen die neuen User in diese Gruppe. So ist es später leichter, Rechte für die Nutzung von SVN zu vergeben.

adduser future subversion
adduser manuel subversion

Jetzt bekommt die Gruppe (und somit future und manuel) Zugriff auf das vorhin erstellte svn repository. Der -R Parameter steht für rekursive, also alle Unterverzeichnisse inbegriffen (auf o. a. Artikel gibt es etwas mehr Details hierzu).

chgrp -R subversion /var/svn
chmod -R o-rwx /var/svn
chmod -R g+rw /var/svn
chmod g+s /var/svn/db

Jetzt wird es nochmal etwas tricky. Wenn oben genannte User Dateien erstellen und so weiter, dann werden diesen Dateien bestimmte Rechte gegeben. Nun wollen wir aber sicher stellen, dass niemand aus Versehen nur Rechte für sich selbst einräumt.

Dafür verwenden wir den UNIX Befehl umask. Wenn wir “umask 002″ aufrufen, heißt dass, dass von jetzt an bei Dateierstellung volle Rechte für die eigene Gruppe und lese und execute Rechte für alle andere gesetzt werden soll.

Da nicht jeder ständig diesen Befehl eingeben wird und möchte, “automatisieren” wir das ganz schlau. Nutzt jemand unser SVN repository, wird die Datei “svnserve” aufgerufen. Wir wechseln in das Verzeichnis, wo diese Datei sich befindet (“which svnserve” verrät uns wo das ist) und bennennen die Datei um! und zwar nehmen wir das letzte “e” weg:

cd /usr/bin
mv svnserve svnserv

Anschließend legen wir eine bash-Datei an, die genau so heißt wie unser svnserve vorher. In diese Datei schreiben wir folgendes:
Inhalt von /usr/bin/svnserve

#!/bin/bash
umask 002
/usr/bin/svnserv $*

Das bewirkt, dass jedes Mal wenn jemand svnserve (mit oder ohne Parameter) startet, er unser kleines Progrämmchen startet, dadurch automatisch “umask 002″ ausführt und dann erst das original svnserv. Schlau oder? (Den Trick habe ich übrigens hier gefunden.)

Jetzt befassen wir uns mit der Datei /var/svn/conf/svnserve.conf. Es handelt sich um die Konfiguration unseres svn repositories. In ihr passen wir ein paar Einstellungen wie folgt an:

[general]
anon-access = none
auth-access = write
realm = funkensturm

Damit geben wir anonymen usern “none” Rechte, future und manuel “write” rechte und noch einen Namen für unser Repository.

Auf dieser Seite habe ich ein paar Einstellungen gefunden, wie man den SSH Login usw. sicherer macht. Außerdem müssen wir ja noch unserer Gruppe subversion den Login per SSH erlauben!
Also ran an die Datei /etc/ssh/sshd_config (vorher backup machen!).
Die Datei ist ziemlich lang. Worauf es ankommt sind letzten Endes diese Werte:

Port 4444
AllowGroups subversion
LoginGraceTime 30
PermitRootLogin no

Damit haben wir den SSH Port von 22 (Standard) auf (z. B.) 4444 erhöht, damit nicht jeder Depp direkt den Port scannen kann. AllowGroups ist neu hinzugekommen, damit alle user in der Gruppe “subversion” SSH benutzen können. Die LoginGraceTime wurde auf 30 Sekunden gesetzt (Zeit zum Passwort eingeben). Da manuel und future sich jetzt einloggen können, können wir den login als root via SSH verbieten mit PermitRootLogin no.

Jetzt noch schnell SSH neu starten und die Änderungen sind aktiv:

/etc/init.d/ssh restart

FERTIG!

Ab jetzt kann man sich per SSH so auf dem Server (natürlich mit der richtigen IP und nicht 123…) einloggen:

ssh future@123.123.123.123 -p 4444

ABER!

Leider kapiert dein lokales svn nicht, dass er bei svn+ssh nicht den Port 22 nehmen soll, sondern unseren 4444. Dafür müssen wir LOKAL (also auf DEINEM MacBook oder PowerBook ;) folgende Datei anpassen: ~/.subversion/config

[tunnels]
fs = /usr/bin/ssh -p 4444

Damit sagen wir, dass ab jetzt svn+fs:// mit Port 4444 aufgerufen wird. (Man könnte auch anstelle “fs” auch “ssh” in die config Datei schreiben, dann würde bei svn+ssh:// immer Port 5777 verwendet werden. Aber das will man mit an Sicherheit grenzender Wahrscheinlichkeit nicht.)

Wenn man sein Projekt auschecken möchte, wird für unseren Server also ab jetzt das hier benutzt:

svn co svn+fs://future@123.123.123.123/var/svn/projekt

Zum hochladen eines neuen Projektes:

svn import projektname svn+fs://future@123.123.123.123/var/svn/projektname -m "Beschreibung der Änderung"

YEAH BABY!

Das ganze ist aber eigentlich recht einfach. Jetzt steht der BasicAuth Code im vhost drin und das sieht dann so aus:

<proxy *>
AuthName “Nur mit Passwort”
AuthType Basic
AuthUserFile /pfad/zur/.htpasswd
require valid-user
</proxy>

ProxyRequests Off
ProxyPreserveHost On

ProxyPass / http://0.0.0.0:3000/
ProxyPassReverse / http://0.0.0.0:3000/
ErrorLog /pfad/zum/server.log

wichtig war die Direktive <proxy *> in der der BasicAuth Code stehen muss. Sonst wird es einfach ignoriert!

Update:
Und so wird es dann in Rails 2.0 gemacht: HTTP Basic Authentication

Damit wir Ruby on Rails auch wirklich nutzen können, sollten wir noch ein paar Programme, Tools und Gems installieren.

Als erstes wäre da MySQL, denn wie wollen wir Datenbankgestütze Webentwicklung betreiben, wenn wir nicht mal einen Datenbank-Server und damit eine Datenbank haben…

MySQL5
Da wir ja MacPorts installiert haben ist das ganze recht einfach. Um auf Nummer Sicher zu gehen, machen wir jedoch erst mal ein selfupdate für MacPorts und installieren erst dann MySQL5

$ sudo port selfupdate
$ sudo port install mysql5 +server
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
$ sudo chown -R mysql:mysql /usr/local/macports/var/db/mysql5
$ sudo -u mysql mysql_install_db5


Jetzt am besten den Mac neu starten, dann kann man gleich sehen ob das LauchItem funktioniert.

MySQL Native Bindings Gem
Jetzt kommt der Teil, der mich die meiste Zeit gekostet hat (dabei sollte er doch die Geschwindigkeit der MySQL Abfragen beschleunigen) und der Grund war, warum ich bis her ohne die Nativen Bindings auskommen musste.
Das MySQL Gem ist irgendwie sehr unflexible, was die Pfade angeht und dazu kommt, dass MacPorts die MySQL Installation im MacPorts Verzeichnis nicht gebündelt ablegt sondern etwas zerfledert… anstelle eines einfachen gem install mysql war hier etwas mehr Finetuning nötig. Mittels der build-flags gelang mir dann aber auch das. Hier das Ergebnis:

sudo gem install mysql -- \
--with-mysql-dir=/usr/local/macports/lib/mysql5 \
--with-mysql-lib=/usr/local/macports/lib/mysql5/mysql \
--with-mysql-include=/usr/local/macports/include/mysql5/mysql


NACHTRAG, ab November 2008 so:

sudo env ARCHFLAGS="-arch ppc" gem install mysql -- --with-mysql-lib=/opt/local/lib/mysql5/mysql --with-mysql-include=/opt/local/include/mysql5/mysql


jetzt wird man gefragt, welche Version man für die Installation wählen will. Nehmen wir also die neuste, zum jetzigen Zeitpunkt mysql 2.7 (ruby), also drücken wir die 3 (da wir uns ja auf einem Mac befinden fallen die mswin32 Versionen für uns raus)

Select which gem to install for your platform (i686-darwin8.10.3)
1. mysql 2.7.3 (mswin32)
2. mysql 2.7.1 (mswin32)
3. mysql 2.7 (ruby)
4. mysql 2.6 (ruby)
5. Skip this gem
6. Cancel installation


Wenn man die build-flags nicht richtig setzt bekommt man solche Fehler:

ERROR: Failed to build gem native extension.
ruby extconf.rb install mysql
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no

und kann damit nicht so wirklich was anfangen… wie gesagt hat mich einiges an Zeit gekostet, weil auch Google dazu nicht richtig was sagt.

So nun sind auch die Bindings fertig und wir können uns anderen Dingen zuwenden.

Mongrel
Mongrel ist der Webserver. Rails liefert zwar schon einen Webserver mit (Webrick) aber Mongrel hat für mich bis her einen sehr sehr großen Vorteil, man sieht im Development Mode alle Requests. Damit fällt das Debugging viel leichter, da man sogar die MySQL Requests mit allen Werten sieht. Also installieren wir das Mongrel Gem einfach.

sudo gem install mongrel --include-dependencies

es kommen wieder die von oben bekannten Abfragen zur Version und weil es Abhängigkeiten gibt, die erfüllt werden müssen, wird gleich noch fastthread installiert. Meine Versionen sind mongrel 1.0.1 (2 drücken) und fastthread 1.0 (1 drücken).

Select which gem to install for your platform (i686-darwin8.10.3)
1. mongrel 1.0.1 (mswin32)
2. mongrel 1.0.1 (ruby)
3. mongrel 1.0 (mswin32)
4. mongrel 1.0 (ruby)
5. Skip this gem
6. Cancel installation
> 2
Select which gem to install for your platform (i686-darwin8.10.3)
1. fastthread 1.0 (ruby)
2. fastthread 1.0 (mswin32)
3. fastthread 0.6.4.1 (mswin32)
4. fastthread 0.6.4.1 (ruby)
5. Skip this gem
6. Cancel installation
> 1


Gut damit haben wir neben dem MySQL-Server nun auch unseren Webserver. Was jetzt kommt ist erst mal nicht so wichtig aber wir installieren es mal, damit wir uns später keine Gedanken mehr drum machen müssen.

Capistrano
Capistrano ist ein Deployment Tool, was einem die Arbeit des live gehens erheblich erleichtern soll. Ich hab es noch nicht benutzt und genau deshalb installiere ich es jetzt mit um es in den nächsten Tagen zu testen. Darüber wird es dann auch einen Post geben.
Neben dem hoch laden der Dateien mittels SSH, kann man noch eigene Rake Tasks in Ruby schreiben, die dann z.B. einen Dump der alten Datenbank erstellen, bevor die neue eingespielt wird. Naja wie gesagt, bei mehr Erfahrungen gibt es auch dazu einen Post, jetzt erst mal die Installation:

sudo gem install capistrano --include-dependencies

Jetzt noch Termios, dass dafür sorgen soll, dass die Passwörter, die man in Capistrano eintippt, nicht von allen gelesen werden können. Ich weiß nicht, ob das notwendig ist aber weh tun tut es ja auch nicht also:

sudo gem install termios --include-dependencies


Subversion
Subversion ist auch so nen Ding, worüber alle reden, was ich aber bis zum jetzigen Zeitpunkt, außer für Plugin Installationen, nicht genutzt habe. Capistrano nutzt es auch, also installieren wir auch noch dieses Tool. Eigentlich ist es einfach eine Versionskontrolle und wird meistens eingesetzt, wenn man in einem Team programmiert (es zeigt einem Konflikte an, d.h. zwei Leute haben zur gleichen Zeit an einer Datei, den selben Teil verändert, jeder natürlich anders und die Änderungen würden verlohren gehen. Hier springt dann eben SVN ein und man kann den Konflikt auflösen.)

sudo port install subversion


So damit haben wir eigentlich erst mal alles, was wir für die Entwicklung mit Ruby on Rails brauchen. Wenn es noch irgendwelche Sachen gibt, die man unbedingt braucht ab in die Kommentare damit.

Wie immer sind Verbesserungsvorschläge (Kommentare) erwünscht. Aus pragmatischen Gründen wird dann der folgende Code jedes Mal entsprechend erneuert:

class ApplicationController < ApplicationController::Base
  def untar
    result = ''
    Dir.open(PATH_TO_DIR).each do |file|
      next if file !~ /tar$/
      result += 'Extracting ' + file + '... '
      if system('cd ' + PATH_TO_DIR + '; tar -xf ' + file)
        result += 'done!<br/>Deleting ' + file + '... '
        if FileUtils::rm_r(PATH_TO_DIR + file)
          result += 'done!<br />'
        else
          result += 'error!<br />'
        end
      else
        result += 'error!<br />'
      end
      processed = true
    end
    result += '<br />Extraction completed!'
    result = 'No compressed files found.' if processed.nil?
    render(:text => result)
  end
end

PS: Manuel, vielen Dank für dieses WP! Sehr sehr schön. Viele Plugins, schöne Bilder und einfach schön! Wie wär’s, wenn du jetzt noch GANZ SCHNELL ein Ruby-Syntax-Highlight installierst :) DANKE!