Archive for the 'subversion' Category

SVN Commands

Published on Mai 25, 2008 in general and subversion. 0 Comments Tags: , , , , , , , .

Weil ich sie immer wieder suche, hier eine Liste von SVN Befehlen, einfach erklärt und mit schönen Beispielen. Besonders svn:ignore benutzt man immer wieder. Auch wenn ich gerade git installiere, der ein oder andere versteht SVN sicher besser mit diesem Dokument.

– SVN PROPERTIES –

ANZEIGEN

Properties des aktuellen Verzeichnisses anzeigen
svn pl

Zeige alle Änderungen für den nächsten commit, ignorierte Dateien sollen trotzdem angezeigt werden:
svn st –no-ignore

Alle Properties rekursiv anzeigen
svn pl -R
Merke: “Properties on ‘config’: svn:ignore” bedeutet nicht, dass “config” ignoriert wird, sondern dass im Verzeichnis config, gewisse Objekte ignoriert werden. “config” ist in gewisser Weise nur der Träger der Eigenschaft, die Werte widerrum sind die Inhalte in config, welche ignoriert werden.

Alle svn:ignore Properties rekursiv anzeigen
svn pg svn:ignore -R

Details über ein Property erhalten
svn pg PROPVAL PATH –strict
Beispiele:
Welche Objekte werden im aktuellen Verzeichnis ignoriert?
svn pg svn:ignore . –strict

SETZEN

Property des aktuellen Verzeichnisses setzen
svn ps PROPNAME PROPVAL PATH
Merke: Der aktuelle Wert des Properties wird dabei überschrieben! Möchte man ihn behalten, muss man ihn neu mit hinzufügen.
Merke: PROPVAL für z. B. svn:ignore ist ein Objekt je Zeile. Das wird mit z. b. “objekt1[RETURN]objekt2″ erreicht.
Merke: Ein mit “svn mkdir” erstelltes Verzeichnis kann nicht direkt ignoriert werden. Verzeichnisse die ignoriert werden sollen, müssen manuell erstellt werden und können anschließend ignoriert werden.
Beispiele:
Das Verzeichnis test im aktuellen Verzeichnis ignorieren
svn ps svn:ignore test .
Das Verzeichnis test im Unterverzeichnis public/images ignorieren
svn ps svn:ignore test public/images
Die Verzeichnisse test1 und test2 im aktuellen Verzeichnis ignorieren
svn ps svn:ignore “test1[RETURN]test2″ .
Alle *.log Dateien im Unterverzeichnis log ignorieren (Das hat keine Auswirkung auf das Verzeichnis log an sich, sondern nur die Dateien dort drin)
svn ps svn:ignore *.log log

LÖSCHEN

Property PROPNAME von PATH löschen
svn pd PROPNAME [PATH]
Merke: Wieder hat das keine Auswirkung auf das Verzeichnis PATH, nur auf dessen Inhalte! (Es sei denn natürlich PATH ist eine Datei)
Merke: Wird PATH weggelassen, wird das Property vom aktuellen Verzeichnis gelöscht
Beispiele:
Alle Objekte im aktuellen Verzeichnis sollen nicht mehr ignoriert werden
svn pd svn:ignore
Alle Objekte im Verzeichnis public/images sollen nicht mehr ignoriert werden
svn pd svn:ignore public/images

– LEGENDE –

PROPNAME ist ein Property
z. B. svn:ignore oder svn:executable

PROPVAL Wert eines Properties
Die Belegung des Properties mit z. B. dem Namen eines Unterverzeichnisses

PATH Verzeichnis zu einem Verzeichnis oder einer Datei usw.
z. B. dir/subdir oder .

[RETURN] Entertaste
Ist ein Zeilensprung mit der Returntaste

cap deploy “permission denied” nach upgrade auf capistrano 2.1

Published on Januar 9, 2008 in capistrano, gems, ruby on rails, server and subversion. 0 Comments Tags: , , .

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.

subversion auf debian aufgesetzt

Published on Dezember 21, 2007 in security, server and subversion. 0 Comments Tags: , , , .

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!

HowTo: MySQL 5, Mongrel, Capistrano + Subversion

Published on September 18, 2007 in capistrano, gems, introducing, ruby on rails, server and subversion. 5 Comments Tags: , , , , .

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.