Archive for the 'server' Category

Nützliche Terminal Befehle

Hier soll eine Liste mit nützlichen Terminal Befehlen entstehen, da man so manche einfach jedes mal vergisst und dann suchen muss.

Nameserver einer Domain herausfinden
nslookup funkensturm.de

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

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!

Ähnliche Posts:
» Musik vom Apple TV zurück in iTunes retten
» PGP mit Mac OS X und Thunderbird 2 (Enigmail Add-on)
» Mysql on Leopard: Startupitem, Prefpane, LaunchDemon
» Mit Mac und Imagemagick: Tiff Bild reparieren

cap deploy “permission denied” nach upgrade auf capistrano 2.1

Hier habe ich endlich gefunden wieso aus heiterem Himmel bei einem cap deploy mit ssh und svn (und public key authentication) immer folgender Fehler auftrat:

** [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.

Ähnliche Posts:
» Capistrano 2 hinter den Vorhang gucken
» “Capistrano überschreibt meine Dateien immer!”
» apache und mongrel_balancer errors
» HowTo: MySQL 5, Mongrel, Capistrano + Subversion

gem1.8 install mysql (MySql Ruby C bindings) in debian

Hier habe ich endlich gefunden, wieso genau die C Bindings für mysql nicht geklappt haben. Es fehlte noch ein apt Paket vorher (bzw. ich benutze aptitude).

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

Ähnliche Posts:
» Ruby on Rails with Leopard (localhost, sites, mysql, rmagick)
» ÜÄÖß Umlaute kaputt in Ruby on Rails und MySQL [broken umlauts]
» HowTo: MySQL 5, Mongrel, Capistrano + Subversion
» Mysql on Leopard: Startupitem, Prefpane, LaunchDemon

Sessions aufräumen – Stale Sessions Clean Up

Wenn man den ganz normalen Session Handler von Rails benutzt, dann werden die Sessions unter tmp/sessions/ abgelegt. Rails räumt dieses Session Verzeichnis aber nicht selber auf. Das kann zu einem Problem werden, wenn man plötzlich tausende von Sessionfiles in diesem Verzeichnis findet. Erst einmal wird die Application dadurch langsamer und zum Zweiten kann es auch das File System des Servers belasten, wenn der nämlich plötzlich keine Nodes mehr machen kann.

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…

Ähnliche Posts:
» No related posts

“Capistrano überschreibt meine Dateien immer!”

Wer seit Neuestem mit Capistrano seine rails app deployed, der kam vielleicht auch schon dahinter, dass dann alle Dateien weg sind, die man in ein bestimmtes Verzeichnis geschrieben oder hochgeladen 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 :)

Ähnliche Posts:
» Capistrano 2 hinter den Vorhang gucken
» cap deploy “permission denied” nach upgrade auf capistrano 2.1
» Rails 2.2: NoMethodError von create_time_zone_conversion_attribute?
» HowTo: MySQL 5, Mongrel, Capistrano + Subversion

apache und mongrel_balancer errors

Hi,

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):

Order allow,deny
Allow from all

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 ;)

Ähnliche Posts:
» BasicAuth + ProxyPath (Apache + Mongrel)
» Apache2 auf dem Mac macht nur 401 wegen FileVault
» Ruby on Rails with Leopard (localhost, sites, mysql, rmagick)

subversion auf debian aufgesetzt

Hi, endlich geschafft. SVN läuft und es war (im Rückblick gesehen) gar nicht so schwer. Dieser Artikel hat mir gut weitergeholfen. Nach der Installation von subversion mit aptitude hat folgende Einrichtung auf einem unserer debian server funktioniert:

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!

Ähnliche Posts:
» debian ssh key login und ~/./ssh/config
» gem1.8 install mysql (MySql Ruby C bindings) in debian
» HowTo: MySQL 5, Mongrel, Capistrano + Subversion

BasicAuth + ProxyPath (Apache + Mongrel)

Ich bin gerade dabei ein Rails Projekt mit Apache und Mongrel zum laufen zu bringen.
Das ganze soll aber erst mal hinter nem htaccess Passwort Schutz sein. Ich hab nun Ewigkeiten gesucht um das hin zu bekommen, denn wenn ich es einfach in die .htaccess im public Verzeichnis meines Rails Projektes ablege, geht es natürlich nicht, da die BasicAuth ja vom Apache gemacht wird und der hat die Anfrage ja schon an Mongrel übergeben…

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

Ähnliche Posts:
» Apache2 auf dem Mac macht nur 401 wegen FileVault
» HowTo: MySQL 5, Mongrel, Capistrano + Subversion
» Ruby on Rails with Leopard (localhost, sites, mysql, rmagick)
» apache und mongrel_balancer errors

HowTo: MySQL 5, Mongrel, Capistrano + Subversion

Update: Bis her war ein Fehler in diesem HowTo. MySQL muss natürlich als Server Version installiert werden ($ sudo port install mysql5 +server). Das Update betrifft nur den MySQL5 Bereich.

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.

Ähnliche Posts:
» Capistrano 2 hinter den Vorhang gucken
» cap deploy “permission denied” nach upgrade auf capistrano 2.1
» Ruby on Rails with Leopard (localhost, sites, mysql, rmagick)
» gem1.8 install mysql (MySql Ruby C bindings) in debian