PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : svn gibt nichts aus, wenns in einem Script gestartet wird



GabbbaGandalf
30.11.09, 01:12
Hallo,

ich habe ein kleines Script geschrieben, das vom Svn Server nach jedem Commit ausgeführt wird und prüfen soll, ob ein neues Tag mit einem bestimmten Namensmuster (site_YYYYMMDDHHMM) erstellt wurde. Wenn ja soll ein Verzeichnis auf dem Webserver mittels svn switch auf diesen neuen Stand gebracht werden. Führt man das Script per SSH ganz normal auf dem Terminal aus, geht alles wunderbar. Hängt man es aber an das post-commit Script an, oder lässt es per Cron laufen, scheint der "svn list"-Befehl nichts auszugeben. Meine Tests haben ergeben, das auch ein umleiten von "svn list URL" in eine Datei, diese nicht füllen. Die Variable svnVersion ist nachher leer. Irgendjemand eine Idee warum das so ist, oder nen workaround?




#!/bin/bash


# Neuestes Tag herausbekommen (arbeitet nur interaktiv richtig):
svnVersion=$(/usr/bin/svn list https://xxxxx.de/svn/yyyyy/tags | grep "^site\_[0-9]\{12\}/$" | /usr/bin/sort -r | /usr/bin/head -n 1)


svnVersionPath=https://xxxxx.de/svn/yyyyy/tags/$svnVersion\site

# URL der aktuellen Onlineversion herausbekommen (arbeitet korrekt):
webVersionPath=$(/usr/bin/svn info /var/www/websites/site | grep URL | cut -f2 -d" ")


echo $webVersionPath >> /var/log/dailymail
echo $svnVersionPath >> /var/log/dailymail

if [ $webVersionPath != $svnVersionPath ]; then
date >> /var/log/dailymail
echo "New Version in Repository, updating ..." >> /var/log/dailymail
/usr/bin/svn switch https://xxx.de/svn/yyyyy/tags/$svnVersion\site/ /var/www/websites/union >> /var/log/dailymail
echo "Correcting Folder Permissions" >> /var/log/dailymail
chown -R www-data /var/www/websites/site/home/*/files
chown -R www-data /var/www/websites/site/home/*/gallery
echo "DONE" >> /var/log/dailymail
fi

GabbbaGandalf
30.11.09, 01:36
Nachdem ichs nochmal im Terminal ausgeführt habe, wollte er, das ich das SSL Zertifikat nochmal akzeptiere. Seitdem geht es als root Cronjob. Im commit Script aber immer noch nicht, obwohl der www-data das script per sudo ausführt. Oder gibt es da noch einen Unterschied, wenn ich sudo mache und wenn ich wirklich root bin (Umgebungsvariablen oder so)?

gropiuskalle
30.11.09, 01:52
Oder gibt es da noch einen Unterschied, wenn ich sudo mache und wenn ich wirklich root bin (Umgebungsvariablen oder so)?

Die Umgebungsvariablen bleiben meines Wissens nach unter sudo gleich, d.h. Du führst zwar etwas mit root-Rechten aus, aber bist dennoch user.

Ohne Gewähr... kannst das ganze ja mal mit Hilfe des Kommandos 'env' vergleichen.

GabbbaGandalf
30.11.09, 11:22
OK, es scheint echt nen unterschied zu machen, ich werd mal eben testen, ob er einfach den .subversion Ordner nicht im richtigen Homeverzeichnis gesucht hat

undefined
30.11.09, 13:12
Natürlich macht das einen Unterschied. Der Cert-Cache von Benutzer wird nicht von root gelesen. Dafür kann er aber unter /etc/ssl/certs das fehlende Zertifikat in sein bundle.crt oder ca-certificates.crt aufnehmen. Siehe die OpenSSL Dokumentationen zum Thema c_rehash (http://www.annodex.net/cgi-bin/man/man2html?c_rehash+1) und cert cache (http://www.openssl.org/docs/)

GabbbaGandalf
01.12.09, 01:10
Ich habs nun hinbekommen! Es war letztendlich eine Verkettugng vom unglüklichen Umständen. Also zum einen natürlich das Zertifikat, das musste noch irgendwie akzeptiert werden. Es war im /root/.subversion zwar akzeptiert, aber das hat das aus dem Script aufgerufene nicht benutzt. Es hat stattdessen in /var/www gesucht., was mir aber nicht gefiel, weil da ja jeder dran kann. Nachdem ein Ändern der HOME-Variable im Script auch nix änderte, habe ich dann die svn Option "--config-dir" gefunden, mit der es dann die nötigen dateien gefnden hat. Dann hat mir "nur" noch eine kleine Datei mit Umlauten im Namen einen Strich durch die Rechnung gemacht, die svn als root scheinbar anders interpretiert hatte. -> Datei gelöscht und verhindert, das an der Stelle weitere Umlautdateien erstellt werden können.