Script von einem anderen Rechner aufrufen
Ein Hoster bereitet mir gerade etwas Kopf zerbrechen. Ich probiere den erst seit kurzer Zeit aus und einige Dinge sind etwas seltsam. Anfangs war bei den meisten, aber nicht allen public_html-Verzeichnissen das Recht auf 750 gesetzt, wunderbar die Welt darf die Homepage nicht sehen ;-) Darauf hin habe ich die Rechte auf 755 geändert. Nun stelle ich heute zufällig fest, dass die Rechte wieder auf 750 gesetzt wurden. Man freut sich, zum Glück ist zur Zeit alles ein Test-Szenario. Ich möchte nun folgendes von einem Script aus machen, das lokal aufgerufen wird. Prüfung der Rechte des Verzeichnisses von public_html und der Dateien darin inkl. Unterverzeichnisse, wenn die Rechte nicht passen sollen die Rechte geändert werden. Ich habe einen Zugang vom lokalen Rechner mit Keys ohne PW, kann also per Script die Verbindung aufbauen. Wie erreiche ich, dass das Script die Rechte nicht lokal prüft, sondern am entfernten Host. Theoretisch könnte ich dort ein Script hinterlegen und einen Cronjob prüfen lassen, aber ich traue dem System dort nicht. Wenn das noch mal passiert, wird sowieso der Hoster gewechselt. Im Produktivbetrieb möchte ich aber nicht deswegen Probleme haben, weil die Rechte verändert wurden. Al
Wie erreiche ich, dass das Script die Rechte nicht lokal prüft, sondern am entfernten Host. Theoretisch könnte ich dort ein Script hinterlegen und einen Cronjob prüfen lassen, aber ich traue dem System dort nicht. Wenn das noch mal passiert, wird sowieso der Hoster gewechselt. Im Produktivbetrieb möchte ich aber nicht deswegen Probleme haben, weil die Rechte verändert wurden.
if [ `ssh user@$host "stat -c "%a" public_html"` -ne 755 ] then ssh user@host "chmod 755 public_html" fi
Hallo, Am Fre, 27 Okt 2006, Dominik Klein schrieb:
Wie erreiche ich, dass das Script die Rechte nicht lokal prüft, sondern am entfernten Host. Theoretisch könnte ich dort ein Script hinterlegen und einen Cronjob prüfen lassen, aber ich traue dem System dort nicht. Wenn das noch mal passiert, wird sowieso der Hoster gewechselt. Im Produktivbetrieb möchte ich aber nicht deswegen Probleme haben, weil die Rechte verändert wurden.
if [ `ssh user@$host "stat -c "%a" public_html"` -ne 755 ] then ssh user@host "chmod 755 public_html" fi
Aua. Wieso zwei mal ssh? Mal absehen davon, dass stat evtl. fehlt. ssh user@host "test `stat -c '%a' public_html` -ne 755 \ && chmod 755 public_html'" Alles eine Zeile. Andrerseits bezweifle ich, dass die Rechte auf 755 sein muessen. Es reicht ja, wenn der Webserver(!) die Dateien lesen bzw. in die Verzeichnisse wechseln kann. Al, passt die Gruppe denn? -dnh -- "Cynical" is a term invented by optimists to describe realists. -- Gregory Benford
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller:
Hallo,
Am Fre, 27 Okt 2006, Dominik Klein schrieb:
Wie erreiche ich, dass das Script die Rechte nicht lokal prüft, sondern am entfernten Host. Theoretisch könnte ich dort ein Script hinterlegen und einen Cronjob prüfen lassen, aber ich traue dem System dort nicht. Wenn das noch mal passiert, wird sowieso der Hoster gewechselt. Im Produktivbetrieb möchte ich aber nicht deswegen Probleme haben, weil die Rechte verändert wurden.
if [ `ssh user@$host "stat -c "%a" public_html"` -ne 755 ] then ssh user@host "chmod 755 public_html" fi
Aua. Wieso zwei mal ssh? Mal absehen davon, dass stat evtl. fehlt.
Das gibt es schon: which stat /usr/bin/stat
ssh user@host "test `stat -c '%a' public_html` -ne 755 \ && chmod 755 public_html'"
Alles eine Zeile.
Andrerseits bezweifle ich, dass die Rechte auf 755 sein muessen. Es reicht ja, wenn der Webserver(!) die Dateien lesen bzw. in die Verzeichnisse wechseln kann.
Al, passt die Gruppe denn?
Die Gruppe von public_html ist nobody. drwxr-xr-x 13 bogner nobody 4096 Oct 25 15:37 ./ drwx--x--x 9 bogner bogner 4096 Oct 27 12:35 ../ Darunter liegende Verzeichnis haben dann: drwxr-xr-x 3 bogner bogner Dateien haben -rw-r--r-- Wie sollten die Rechte sein? Ich sehe keine Grund die Gruppe einzuschränken, wenn "other" zugreifen kann. Die Rechte wurden automatisch von cpanel vergeben. Al
Hallo, Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller: Die Gruppe von public_html ist nobody.
drwxr-xr-x 13 bogner nobody 4096 Oct 25 15:37 ./
Also hier hat das *.nogroup. Die Frage ist: in welchen Gruppen laeuft der Apache? -dnh -- Eine Katze hat einen Schwanz mehr als keine Katze. Keine Katze hat zwei Schwänze, also hat eine Katze drei Schwänze. [Bernd Brodesser in suse-linux]
Am Samstag, 28. Oktober 2006 03:17 schrieb David Haller:
Hallo,
Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller: Die Gruppe von public_html ist nobody.
drwxr-xr-x 13 bogner nobody 4096 Oct 25 15:37 ./
Also hier hat das *.nogroup. Die Frage ist: in welchen Gruppen laeuft der Apache?
grep -i apache /etc/group apache:x:48: Damit bin ich aber auch nicht schlauer, oder? Al
Hallo, Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Samstag, 28. Oktober 2006 03:17 schrieb David Haller:
Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller: Die Gruppe von public_html ist nobody.
drwxr-xr-x 13 bogner nobody 4096 Oct 25 15:37 ./
Also hier hat das *.nogroup. Die Frage ist: in welchen Gruppen laeuft der Apache?
grep -i apache /etc/group apache:x:48:
Damit bin ich aber auch nicht schlauer, oder?
Schau mal in der /etc/apache2/httpd.conf (bzw. bei SUSE 10.1 in /etc/apache2/uid.conf) nach, was als User bzw. Group angegeben ist. # egrep '\<(User|Group)\>[^-]' /etc/apache2/* 2>/dev/null /etc/apache2/uid.conf:User wwwrun /etc/apache2/uid.conf:Group www Die public_html-Verzeichnisse sollten also hier die Rechte $USER.www haben und mit der Gruppe www erreichbar sein (Ausfuehrrechte der uebergeordneten Verzeichnisse). Oder "world readable" und erreichbar sein. -dnh -- Verstehe hier den Zusammenhang nicht. Oder meinst du, da du mehrere Platten hast, die sich nicht im Gehäuse in die Quere kommen, springen keine Pinguine auf die Windowsplatte und zertrümmern die Fenster mit ihren Watschelbeinchen. -- Thorsten von Plotho-Kettner in suse-linux
Am Samstag, 28. Oktober 2006 14:06 schrieb David Haller: Hallo David,
grep -i apache /etc/group apache:x:48:
Damit bin ich aber auch nicht schlauer, oder?
Schau mal in der /etc/apache2/httpd.conf (bzw. bei SUSE 10.1 in /etc/apache2/uid.conf) nach, was als User bzw. Group angegeben ist.
In /etc gibt es keine Apache.
# egrep '\<(User|Group)\>[^-]' /etc/apache2/* 2>/dev/null /etc/apache2/uid.conf:User wwwrun /etc/apache2/uid.conf:Group www
Das habe ich mir wegen oben gespart.
Die public_html-Verzeichnisse sollten also hier die Rechte $USER.www haben und mit der Gruppe www erreichbar sein (Ausfuehrrechte der uebergeordneten Verzeichnisse). Oder "world readable" und erreichbar sein.
Ich fand nur das raus: Apache/1.3.37 (Unix) PHP/5.1.2 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a Al
Hallo, Am Son, 29 Okt 2006, Al Bogner schrieb:
Am Samstag, 28. Oktober 2006 14:06 schrieb David Haller:
Schau mal in der /etc/apache2/httpd.conf (bzw. bei SUSE 10.1 in /etc/apache2/uid.conf) nach, was als User bzw. Group angegeben ist.
In /etc gibt es keine Apache.
Dann eben
# egrep '\<(User|Group)\>[^-]' /etc/apache2/* 2>/dev/null
egrep '\<(User|Group)\>[^-]' /etc/httpd/* 2>/dev/null -dnh -- 103: COBOL Ein Wort, unendliche Schmerzen. (Kristian Köhntopp)
Am Sonntag, 29. Oktober 2006 01:05 schrieb David Haller: Hallo David,
Am Son, 29 Okt 2006, Al Bogner schrieb:
Am Samstag, 28. Oktober 2006 14:06 schrieb David Haller:
Schau mal in der /etc/apache2/httpd.conf (bzw. bei SUSE 10.1 in /etc/apache2/uid.conf) nach, was als User bzw. Group angegeben ist.
In /etc gibt es keine Apache.
Dann eben
# egrep '\<(User|Group)\>[^-]' /etc/apache2/* 2>/dev/null
egrep '\<(User|Group)\>[^-]' /etc/httpd/* 2>/dev/null
Auch nicht, aber ich habe das gefunden (warte schon darauf, bis sich wer aufregt, dass ich außerhalb meines Home-Verzeichnisses rumsuche ;-) ) lrwxrwxrwx 1 root root 17 Aug 12 20:42 httpd -> /usr/local/apache/ drwxr-xr-x 4 root root 4096 Aug 12 16:24 httpd.old/ Al
Hallo David, Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller:
ssh user@host "test `stat -c '%a' public_html` -ne 755 \ && chmod 755 public_html'"
stat: Aufruf von stat für „public_html“ nicht möglich: Datei oder Verzeichnis nicht gefunden stdin: is not a tty bash: -c: line 0: unexpected EOF while looking for matching `'' bash: -c: line 1: syntax error: unexpected end of file Sind es Rechte an denen ich scheitere oder stimmt die Syntax nicht? Al
Hallo, Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller:
ssh user@host "test `stat -c '%a' public_html` -ne 755 \ && chmod 755 public_html'"
stat: Aufruf von stat für ???public_html??? nicht möglich: Datei oder Verzeichnis nicht gefunden
Das hab ich einfach nur so uebernommen. s.u.
stdin: is not a tty bash: -c: line 0: unexpected EOF while looking for matching `'' bash: -c: line 1: syntax error: unexpected end of file
Sind es Rechte an denen ich scheitere oder stimmt die Syntax nicht?
Da ist ein ' zuviel. Sowas muesstest du eigentlich inzwischen selber sehen ;) ssh user@host "test `stat -c '%a' ~/public_html` -ne 755 \ && chmod 755 ~/public_html" -dnh -- panic("ocfs2 is very sorry to be fencing this system by panicing\n"); -- /usr/src/linux/fs/ocfs2/cluster/quorum.c
Am Samstag, 28. Oktober 2006 03:14 schrieb David Haller:
Hallo,
Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller:
ssh user@host "test `stat -c '%a' public_html` -ne 755 \ && chmod 755 public_html'"
stat: Aufruf von stat für ???public_html??? nicht möglich: Datei oder Verzeichnis nicht gefunden
Das hab ich einfach nur so uebernommen. s.u.
stdin: is not a tty bash: -c: line 0: unexpected EOF while looking for matching `'' bash: -c: line 1: syntax error: unexpected end of file
Sind es Rechte an denen ich scheitere oder stimmt die Syntax nicht?
Da ist ein ' zuviel. Sowas muesstest du eigentlich inzwischen selber sehen ;)
Schon, aber andere Varianten (ohne ') funktionieren auch nciht.
ssh user@host "test `stat -c '%a' ~/public_html` -ne 755 \ && chmod 755 ~/public_html"
Leider passt das auch nicht Verwende ich ~/public_html wird kritisiert, dass das _lokale_ Homeverzeichnis nicht gefunden wird. Beim vollen Pfad gibt es diese Meldung: ssh user@domain.tld "test `stat -c '%a' /home/user/public_html` -ne 755 && chmod 755 /home/user/public_html" stat: Aufruf von stat für „/home/user/public_html“ nicht möglich: Datei oder Verzeichnis nicht gefunden stdin: is not a tty bash: line 0: test: -ne: unary operator expected Da ein ssh sowieso ins Home-Verzeichnis wechselt, würde auch relativ public_html reichen, klappt aber auch nicht. Ich denke, es wird nicht am entfernten Rechner nach public_html gesucht sondern am lokalen. Außerdem würde ich es gerne mit einem find kombinieren, etwa so: find /home/user/public_html -type d -print0 | xargs -r -0 chmod 755 find /home/user/public_html -type f -print0 | xargs -r -0 chmod 644 Al
Hallo, Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Samstag, 28. Oktober 2006 03:14 schrieb David Haller:
Am Sam, 28 Okt 2006, Al Bogner schrieb:
Am Freitag, 27. Oktober 2006 19:37 schrieb David Haller:
ssh user@host "test `stat -c '%a' public_html` -ne 755 \ && chmod 755 public_html'" [..] Schon, aber andere Varianten (ohne ') funktionieren auch nciht.
ssh user@host "test `stat -c '%a' ~/public_html` -ne 755 \ && chmod 755 ~/public_html"
Leider passt das auch nicht
*GNARF* Ich Depp! Falsche Quotes (bzw. fehlende Escapes). ssh user@domain.tld 'test `stat -c "%a" /home/user/public_html` -ne 755 && chmod 755 /home/user/public_html' [..]
Außerdem würde ich es gerne mit einem find kombinieren, etwa so:
find /home/user/public_html -type d -print0 | xargs -r -0 chmod 755 find /home/user/public_html -type f -print0 | xargs -r -0 chmod 644
ssh user@domain.tld 'test `stat -c "%a" ~/public_html` -ne 755 \ && find ~/public_html -type d -print0 | xargs -r -0 chmod 755' sollte eigentlich klappen. -dnh -- Nichts its gefährlicher als sich in Gefahr zu begeben. das merkst du spätestens dann, wenn du sein erstes Posting ins Usernetz losgelassen hast. [WoKo in dag°]
Am Samstag, 28. Oktober 2006 17:17 schrieb David Haller: Hallo David,
ssh user@domain.tld 'test `stat -c "%a" ~/public_html` -ne 755 \ && find ~/public_html -type d -print0 | xargs -r -0 chmod 755'
Danke das funktioniert nun ganz gut, Ich habe jetzt folgendes: ssh "$NUTZER"@"$DOMAIN" 'test `stat -c "%a" ~/public_html` -ne 755 && find ~/public_html -type d -print0 | xargs -r -0 chmod 755' ssh "$NUTZER"@"$DOMAIN" 'test `stat -c "%a" ~/public_html/index.html` -ne 644 && find ~/public_html -type f -print0 | xargs -r -0 chmod 644' Wenn ich aber das nach dem Oktalwert hinzufüge, dann wird kein Warnmail versandt: && echo "Problem mit den Rechten" | mail -s "Rechte falsch auf $DOMAIN' Al
Hallo, Am Son, 29 Okt 2006, Al Bogner schrieb:
Am Samstag, 28. Oktober 2006 17:17 schrieb David Haller:
ssh user@domain.tld 'test `stat -c "%a" ~/public_html` -ne 755 \ && find ~/public_html -type d -print0 | xargs -r -0 chmod 755'
Danke das funktioniert nun ganz gut,
Ich habe jetzt folgendes: ssh "$NUTZER"@"$DOMAIN" 'test `stat -c "%a" ~/public_html` -ne 755 && find ~/public_html -type d -print0 | xargs -r -0 chmod 755' ssh "$NUTZER"@"$DOMAIN" 'test `stat -c "%a" ~/public_html/index.html` -ne 644 && find ~/public_html -type f -print0 | xargs -r -0 chmod 644'
Kannst du auch noch zusammenfassen. ssh ist eine verschluesselte "remote shell", d.h. dass Shellbefehle auf einem "entfernten" Rechner ausgefuehrt werden. Ausserdem faellt mir noch ein: wozu der Test ob die Rechte stimmen? Oder willst du's nur mitbekommen, dass die Rechte neu gesetzt werden mussten? a) obiges zusammengefasst: ssh "${NUTZER}@${DOMAIN}" ' test `stat -c "%a" ~/public_html` -ne 755 \ && find ~/public_html -type d -print0 | xargs -r -0 chmod 755; \ test `stat -c "%a" ~/public_html/index.html` -ne 644 \ && find ~/public_html -type f -print0 | xargs -r -0 chmod 644' (wichtig ist AFAIK dabei das "; \" nach dem xargs .. chmod 755, das ganze wird an die remote shell so uebergeben, als ob das alles auf einer Zeile stuende). b) die pragmatische Loesung, einfach "drueberbuegeln": ssh "${NUTZER}@${DOMAIN}" ' find ~/public_html -type d -print0 | xargs -r -0 chmod 755; \ find ~/public_html -type f -print0 | xargs -r -0 chmod 644' c) die pragmatische, mitbekommenwoll Loesung: ssh "${NUTZER}@${DOMAIN}" ' find ~/public_html -type d -print0 | xargs -r -0 chmod -c 755; \ find ~/public_html -type f -print0 | xargs -r -0 chmod -c 644' d) koennte sein, das du auf die Befehle in ein Script auf dem entfernten Rechner packst und dann eben: ssh "${NUTZER}@${DOMAIN}" '~/bin/rechtesetzen.sh' oder so ausfuehrst. Und dann ist noch folgender Satz aus der manpage zu beachten: "The exit status of the remote program is returned as the exit status of ssh." D.h. bei mehreren Befehlen ist der exit-status der ssh der exit-status der (remote-)shell, und der ist der exit-status der letzten "Pipeline" (also meist der des letzten Befehls). Also z.B.: ssh "${NUTZER}@${DOMAIN}" \ 'test `stat -c "%a" ~/public_html` -ne 755' || mail ... ^^^^^^^^^^^^^^^^^^^ remote ^^^^^^^^^^^^^^^^ ^^^^^^^^ lokal ... wobei der lokale Teil den Exitstatus des ssh, der der Status des 'test' ist, auswertet.
Wenn ich aber das nach dem Oktalwert hinzufüge, dann wird kein Warnmail versandt:
&& echo "Problem mit den Rechten" | mail -s "Rechte falsch auf $DOMAIN' ^^ Was erwartest du, wenn du nur bei Erfolg mailst? ;) ^^?
Und das quoting ist auch etwas suspekt ;)
Siehe oben bzgl. evtl. guenstigerer Loesungen, was Meldungen angeht,
aber wenn du eine Mail willst, wenn die Rechte neu gesetzt werden
sollte folgendes gehen:
ssh "${NUTZER}@${DOMAIN}" '
if test `stat -c "%a" ~/public_html` -ne 755; then \
find ~/public_html -type d -print0 | xargs -r -0 chmod 755; \
echo "Verzeichnisrechte neu gesetzt"; \
fi; \
if test `stat -c "%a" ~/public_html/index.html` -ne 644; then \
find ~/public_html -type f -print0 | xargs -r -0 chmod 644; \
echo "Dateirechte neu gesetzt"; \
fi' | mail -s "Rechte auf $DOMAIN" `id -n`
# ^- ab hier lokal
Die Pipe zu 'mail' kann lokal sein, denn STDOUT der remote shell ist
stdout des ssh-Befehls. Wenn du die Mails remote senden willst:
ssh "${NUTZER}@${DOMAIN}" '
{
if test `stat -c "%a" ~/public_html` -ne 755; then \
[..]
fi; \
} 2>&1 | mail -s "Rechte auf '"${DOMAIN}"'"... empfaenger@bla.tld'
# ^ ^- Anf.z. ^^^^^|^^^^^ ^- Anfuehrungsz. remote zu
# | remote auf |
# | `- wird vor Uebergabe an ssh lokal
# | expandiert, in lokalen Anf.z.
# `- Ausgaben remote zusammenfassen
Ja, da muss man beim Quoten ziemlich aufpassen ;)
Aber was auch geht: ssh frisst das Shellscript auch von stdin, z.B.:
cat <
Am Sonntag, 29. Oktober 2006 02:00 schrieb David Haller: Hallo David,
b) die pragmatische Loesung, einfach "drueberbuegeln":
das habe ich mir anfangs auch gedacht, will ich aber nicht mehr. Auch muss man aufpassen, wenn frontpage installiert ist, dann gibt es zB -rw------- bei service.pwd 644 wäre also nicht so gut. Ich habe das Problem so gelöst, dass ich Frontpage völlig deinstalliert habe, brauche ich ja nicht, war nur vorinstalliert.
c) die pragmatische, mitbekommenwoll Loesung:
Ja, ich will da schon was mitbekommen. Ich glaube noch immer, dass da irgenein Script im Datacenter die Rechte mehr oder wenig zufällig versaut hat. Ich bin mir sicher, dass ich nicht die Rechte bei _allen_ betroffenen Accounts kaputt gemachte habe (1 Account lasse ich mir vielleicht einreden) und der Hoster "schwört", dass von seiner Seite keine Rechte geändert wurden. Ich suche also nach einer Lösung, wie ich so ein Problem möglichst schnell entdecke und automatisch korrigiere. Der Hoster wird dann sicher gewechselt, aber die Migration braucht ja auch Zeit.
d) koennte sein, das du auf die Befehle in ein Script auf dem entfernten Rechner packst und dann eben:
ssh "${NUTZER}@${DOMAIN}" '~/bin/rechtesetzen.sh'
Ich weis nicht, ob das klug ist, wenn man misstraurisch gegenüber dem Hoster ist.
Siehe oben bzgl. evtl. guenstigerer Loesungen, was Meldungen angeht, aber wenn du eine Mail willst, wenn die Rechte neu gesetzt werden sollte folgendes gehen:
ssh "${NUTZER}@${DOMAIN}" ' if test `stat -c "%a" ~/public_html` -ne 755; then \ find ~/public_html -type d -print0 | xargs -r -0 chmod 755; \ echo "Verzeichnisrechte neu gesetzt"; \ fi; \ if test `stat -c "%a" ~/public_html/index.html` -ne 644; then \ find ~/public_html -type f -print0 | xargs -r -0 chmod 644; \ echo "Dateirechte neu gesetzt"; \ fi' | mail -s "Rechte auf $DOMAIN" `id -n` # ^- ab hier lokal
Die Pipe zu 'mail' kann lokal sein, denn STDOUT der remote shell ist stdout des ssh-Befehls. Wenn du die Mails remote senden willst:
Das weis ich noch nicht, ob es für mich einen Unterschied macht. Ursprünglich ging ich davon aus, dass ich remote senden will. Letztlich ist es aber egal, ich will es nur dokumentiert haben.
ssh "${NUTZER}@${DOMAIN}" ' { if test `stat -c "%a" ~/public_html` -ne 755; then \ [..] fi; \ } 2>&1 | mail -s "Rechte auf '"${DOMAIN}"'"... empfaenger@bla.tld' # ^ ^- Anf.z. ^^^^^|^^^^^ ^- Anfuehrungsz. remote zu # | remote auf | # | `- wird vor Uebergabe an ssh lokal # | expandiert, in lokalen Anf.z. # `- Ausgaben remote zusammenfassen
Ja, da muss man beim Quoten ziemlich aufpassen ;)
Aber was auch geht: ssh frisst das Shellscript auch von stdin, z.B.:
cat <
&1 ## stdout auf stdin umbiegen if test \`stat -c '%a' ~/public_html\` -ne 755; then find ~/public_html -type d -print0 | xargs -r -0 chmod 755 echo "Verzeichnisrechte neu gesetzt" fi if test \$(stat -c '%a' ~/public_html/index.html) -ne 644; then find ~/public_html -type f -print0 | xargs -r -0 chmod 644 echo "Dateirechte neu gesetzt" fi EOF Bei dieser Form werden Variablen $FOO, `` und $() im Here-Dokument interpretiert, ein ~ aber erst remote. Wenn man
cat <<'EOF' | ...
verwendet nicht. '' und "" koennen in beiden Faellen als Quotezeichen verwendet werden (die so auch weitergegeben werden).
Umgehen kann man's durch escapen (s.o.), ich hab oben mal beide Varianten drin.
Ziemlich kompliziert. Ich werde mal testen. Vielen Dank! Al
Am Sonntag, 29. Oktober 2006 02:00 schrieb David Haller: Hallo David, Wie war! ich komme nicht weiter;-)
Ja, da muss man beim Quoten ziemlich aufpassen ;)
Das funktioniert: WARN="admin@domain.tld" NUTZER="user" DOMAIN="domain.tld" # eigene Variable für Prüfung und Rechtesetzung, sodass die richtig gesetzten Rechte immer als falsch betrachet werden, aber beim Test immer die richtigen Rechte gesetzt werden DEFAULTDIRCHK=757 DEFAULTDIR=755 DEFAULTFILECHK=643 DEFAULTFILE=644 Ich prüfe also auf 757, die sind falsch und setze dann die bereits vorhandenen Rechter von 755 auf 755 und löse ein Mail aus: # Einrückungen wegen Posting verändert ssh "${NUTZER}@${DOMAIN}" ' { if test `stat -c "%a" ~/public_html` -ne '"${DEFAULTDIRCHK}"'; then \ find ~/public_html -type d -print0 | xargs -r -0 chmod '"${DEFAULTDIR}"'; \ echo "Verzeichnisrechte neu gesetzt"; \ fi; \ } 2>&1 | mail -s "Rechte auf '"${DOMAIN}"'" '"${WARN}"'' So kommt ein Testmail an, verändere ich aber etwas, dann kommt es vermutlich wegen falschem Quoting, dazu, dass Worte oder Variablen im Subject als Mailuser betrachtet werden und and die Standardomäne versandt werden. Ich würde gerne etwas in der Art (ohne richitges Quoting) haben: } 2>&1 | mail -s "Rechte auf '"${DOMAIN}"'" auf $DEFAULTDIR gesetzt '"${WARN}"'' Bei den Varianten, die ich probiert haben, gibt es immer ein Mal an auf@, gesetzt@ usw. Wie erreiche ich im Testkörper des Mails eine Auflistung _vor_ Änderung der Rechte und _nach_? Vielleicht sollte man die Listung vor der Änderung in eine Variable schreiben Letztlich möchte ich es nicht mit mail, sondern mit mutt versenden. Wie soll ich am besten mehrere Domains mit dazugehörigem User abarbeiten? Al
Hallo, Am Son, 29 Okt 2006, Al Bogner schrieb:
Am Sonntag, 29. Oktober 2006 02:00 schrieb David Haller:
Ja, da muss man beim Quoten ziemlich aufpassen ;)
Das funktioniert:
WARN="admin@domain.tld" NUTZER="user" DOMAIN="domain.tld" [..] # Einrückungen wegen Posting verändert ssh "${NUTZER}@${DOMAIN}" ' { if test `stat -c "%a" ~/public_html` -ne '"${DEFAULTDIRCHK}"'; then \ find ~/public_html -type d -print0 | xargs -r -0 chmod '"${DEFAULTDIR}"'; \ echo "Verzeichnisrechte neu gesetzt"; \ fi; \ } 2>&1 | mail -s "Rechte auf '"${DOMAIN}"'" '"${WARN}"''
So kommt ein Testmail an, verändere ich aber etwas, dann kommt es vermutlich wegen falschem Quoting, dazu, dass Worte oder Variablen im Subject als Mailuser betrachtet werden und and die Standardomäne versandt werden.
Ich würde gerne etwas in der Art (ohne richitges Quoting) haben: } 2>&1 | mail -s "Rechte auf '"${DOMAIN}"'" auf $DEFAULTDIR ^ Mit dem " hier beendest du das Argument fuer -s "" gesetzt '"${WARN}"''
Genau im Quoting liegt das Problem, du musst darauf achten, was lokal
expandiert werden soll und was wie es uebergeben wird:
-s "Rechte auf '"${DOMAIN}"' auf '"$DEFAULTDIR"' gesetzt" '"${WARN}"
Hab's sogar getestet. Achte mal darauf, wie die shell das ganze an ssh
uebergibt:
$ H=dhaller.de; W=dh D="755"
$ set -x
$ ssh dh@localhost 'set -x; echo "body" | mail -s "Rechte auf '"${H}" auf '"$D"' gesetzt" '"${W}"
+ ssh dh@localhost 'set -x; echo "body" | mail -s "Rechte auf dhaller.de auf 755 gesetzt" dh'
dh@localhost's password:
+ echo body
+ mail -s 'Rechte auf dhaller.de auf 755 gesetzt' dh
$ ^ ^ die sind aus den
-s ".." entstanden!
Und die Mail wird passend erzeugt. Nochmal auseinandergepfriemelt:
wir sind im ersten offenen '' Paar: ssh u@host '...
| mail -s " ## remote " auf
Rechte auf ' ## lokal ' (ssh-Arg) zu
"${DOMAIN}" ## lokal geschuetzt Variable einsetzen
' ## lokal ' (ssh-Arg) wieder auf
auf ' ## lokal ' (ssh-Arg) wieder zu
"$DEFAULTDIR" ## lokal geschuetzt Variable einsetzen
' ## lokal ' (ssh-Arg) wieder auf
gesetzt" ## remote " zu
' ## lokal ' (ssh-Arg) wieder zu
"${WARN}" ## lokal geschuetzt Variable einsetzen
## hier darf kein Leerzeichen stehen, sonst
## macht die shell das zu einem weiteren
## lokalen Argument fuer die ssh.
## Weggelassen wird hier, weil das lokale '
## schon wieder zu ist der Abschluss:
' ## lokal ' (ssh-Arg) wieder auf
-- -fbla@blubb ## z.B. noch Argumente fuer das remote mail
' ## lokal ' (ssh-Arg) wieder zu
Wie geschrieben, ich wuerde lokal mailen und cat < Bei den Varianten, die ich probiert haben, gibt es immer ein Mal an auf@,
gesetzt@ usw. s.o. Wie erreiche ich im Testkörper des Mails eine Auflistung _vor_ Änderung der
Rechte und _nach_? Vielleicht sollte man die Listung vor der Änderung in eine
Variable schreiben Besser nicht. Letztlich möchte ich es nicht mit mail, sondern mit mutt versenden. Remote oder Lokal? Und welchen Grund haettest du, nicht lokal zu
mailen? Mutt laesst sich gut verwenden. Wie soll ich am besten mehrere Domains mit dazugehörigem User abarbeiten? for udom in user1@host1 user2@host2; do
cat <
Am Sonntag, 29. Oktober 2006 22:12 schrieb David Haller: Hallo David,
Genau im Quoting liegt das Problem, du musst darauf achten, was lokal expandiert werden soll und was wie es uebergeben wird:
Nicht so einfach ;-) Vielen Dank für die detaillierte Erklärung.
Wie erreiche ich im Testkörper des Mails eine Auflistung _vor_ Änderung der Rechte und _nach_? Vielleicht sollte man die Listung vor der Änderung in eine Variable schreiben
Besser nicht.
Dachte ich mir. Die Rechte nach der Änderung waren relativ einfach zu integrieren.. Interessant wäre natürlich schon zu protokollieren, was geändert wurde.
Letztlich möchte ich es nicht mit mail, sondern mit mutt versenden.
Remote oder Lokal? Und welchen Grund haettest du, nicht lokal zu mailen? Mutt laesst sich gut verwenden.
Ich habe schon auf Mutt umgestellt. Zur Frage lokal vs. remote gibt es keinen triftigen Grund. Der einzige Grund warum ich es remote machen will wäre, damit der Hoster das Mail im Log finden kann. Aber eigentlich will ich dann sowieso nicht mehr viel diskutieren. Mittlerweile wurde mir bei einer Domain die Shell gesperrt (-bash: fork: Resource temporarily unavailable) obwohl ich nichts besonderes getan habe, als _meine_ Textdateien in sehr kurzen Abständen wiederholt mit Kleinigkeiten zu editieren.
Wie soll ich am besten mehrere Domains mit dazugehörigem User abarbeiten?
for udom in user1@host1 user2@host2; do
for udom in user1@host1; do das sollte doch auch ok sein. Ich test mal nur mit einer Domain. Kann man die "user@domain" auch aus einer Liste übergeben, wie auch immer die Liste auszusehen hat?
cat <
if test \`stat ...\` -ne "$DIRMODE"; then
Ist das falsch? if test \`stat -c "%a" ~/public_html\` -ne "$DIRMODECHK"; then Ich erhalte keine konkrete Fehlermeldung, es sieht irgendwie nach Quotingproblem aus, (unexpected end of file)
find ~/public_html -ls echo -e "\n\n====\n\n" find ~/public_html -type d | xargs -r -0 chmod -c "$DIRMODE" find ~/public_html -type f | xargs -r -0 chmod -c "$FILEMODE" fi EOF done
Die Ausgaben des find -ls und der chmod -c landen im Body der Mail.
Ich hoffe ich habe da nichts falsch verstanden. Ich speichere die For-Schleife mit definierte Variablen lokal ab und führer es aus.
Oder die Variante mit dem lokal gespeicherten Script statt dem 'cat'.
Das sollte IMHO egal sein. Al
Hallo, Am Mon, 30 Okt 2006, Al Bogner schrieb:
Am Sonntag, 29. Oktober 2006 22:12 schrieb David Haller:
Genau im Quoting liegt das Problem, du musst darauf achten, was lokal expandiert werden soll und was wie es uebergeben wird:
Nicht so einfach ;-) Vielen Dank für die detaillierte Erklärung.
*g* [..]
Remote oder Lokal? Und welchen Grund haettest du, nicht lokal zu mailen? Mutt laesst sich gut verwenden.
Ich habe schon auf Mutt umgestellt. Zur Frage lokal vs. remote gibt es keinen triftigen Grund. Der einzige Grund warum ich es remote machen will wäre, damit der Hoster das Mail im Log finden kann. Aber eigentlich will ich dann sowieso nicht mehr viel diskutieren.
Dann mach's lokal. Macht auch die Uebergabe von Empfaenger usw. einfacher. s.u.
Mittlerweile wurde mir bei einer Domain die Shell gesperrt (-bash: fork: Resource temporarily unavailable) obwohl ich nichts besonderes getan habe, als _meine_ Textdateien in sehr kurzen Abständen wiederholt mit Kleinigkeiten zu editieren.
Gnarf.
Wie soll ich am besten mehrere Domains mit dazugehörigem User abarbeiten?
for udom in user1@host1 user2@host2; do
for udom in user1@host1; do das sollte doch auch ok sein. Ich test mal nur mit einer Domain.
Ja, geht.
Kann man die "user@domain" auch aus einer Liste übergeben, wie auch immer die Liste auszusehen hat?
Ja. Wenn du die bash o.ae. verwendest die Listen kann. declare -a CHECKHOSTS ### nicht wirklich noetig, mach ich aber gern ;) CHECKHOSTS=( "user1@host1" "user2@host2" ) CHECKHOSTS[${#CHECKHOSTS[@]}]="user3@host3" ### ${#VAR[@]} = Anzahl der Eintraege im Array for host in "${CHECKHOSTS[@]}"; do ... done
cat <
Das waere also das lokale mailen, das ich empfehlen wuerde.
if test \`stat ...\` -ne "$DIRMODE"; then
Ist das falsch? if test \`stat -c "%a" ~/public_html\` -ne "$DIRMODECHK"; then
Ich erhalte keine konkrete Fehlermeldung, es sieht irgendwie nach Quotingproblem aus, (unexpected end of file)
Sollte eigentlich gehen. Versuch's mal mit der anderen Variante: if test \$(stat -c "%a" ~/public_html) -ne "$DIRMODECHK"; then [..]
Die Ausgaben des find -ls und der chmod -c landen im Body der Mail.
Ich hoffe ich habe da nichts falsch verstanden. Ich speichere die For-Schleife mit definierte Variablen lokal ab und führer es aus.
Jep. Aber s.u.
Oder die Variante mit dem lokal gespeicherten Script statt dem 'cat'.
Das sollte IMHO egal sein.
Nicht ganz. Folgendes: ==== run_rechtecheck.sh ==== #!/bin/bash ADMIN=me@localost declare -a CHECKHOSTS ### nicht wirklich noetig, mach ich aber gern ;) CHECKHOSTS=( "user1@host1" "user2@host2" ) CHECKHOSTS[${#CHECKHOSTS[@]}]="user3@host3" ### ${#VAR[@]} = Anzahl der Eintraege im Array for host in "${CHECKHOSTS[@]}"; do ssh "$host" < rechtecheck.sh | mutt -s "Rechte auf $host" "$ADMIN" done ==== ==== rechtecheck.sh ==== #!/bin/bash exec 2>&1 ### alles auf stdout ausgeben DIRMODECHK=755 FILEMODECHK=644 if test `stat -c "%a" ~/public_html` -ne "$DIRMODECHK"; then find ~/public_html -ls find ~/public_html -type d -print0 | xargs -r -0 chmod -c "$DIRMODECHK" find ~/public_html -type f -print0 | xargs -r -0 chmod -c "$FILEMODECHK" fi ==== Wie du siehst entfaellt so komplett fast jegliches Problem beim Quoten. Zumindest wenn du keine Variablen von run_rechtecheck.sh uebergeben musst. Die Datei wird "unbehandelt" in die Pipe zu ssh zur remote-shell geschoben... -dnh --
<logic mode="patent office"> Validator error in line 1: Contradiction in terms. -- C. Faerber, A. Krey
Am Montag, 30. Oktober 2006 19:54 schrieb David Haller: Hallo David,
Am Mon, 30 Okt 2006, Al Bogner schrieb:
Am Sonntag, 29. Oktober 2006 22:12 schrieb David Haller:
Kann man die "user@domain" auch aus einer Liste übergeben, wie auch immer die Liste auszusehen hat?
Ja. Wenn du die bash o.ae. verwendest die Listen kann.
declare -a CHECKHOSTS ### nicht wirklich noetig, mach ich aber gern ;) CHECKHOSTS=( "user1@host1" "user2@host2" ) CHECKHOSTS[${#CHECKHOSTS[@]}]="user3@host3" ### ${#VAR[@]} = Anzahl der Eintraege im Array
for host in "${CHECKHOSTS[@]}"; do ... done
cat <
Das waere also das lokale mailen, das ich empfehlen wuerde.
if test \`stat ...\` -ne "$DIRMODE"; then
Ist das falsch? if test \`stat -c "%a" ~/public_html\` -ne "$DIRMODECHK"; then
Ich erhalte keine konkrete Fehlermeldung, es sieht irgendwie nach Quotingproblem aus, (unexpected end of file)
Sollte eigentlich gehen. Versuch's mal mit der anderen Variante:
if test \$(stat -c "%a" ~/public_html) -ne "$DIRMODECHK"; then
Auch wieder: unexpected end of file
Die Ausgaben des find -ls und der chmod -c landen im Body der Mail.
Funktioniert, aber mit der anderen Variante.
==== run_rechtecheck.sh ==== #!/bin/bash ADMIN=me@localost declare -a CHECKHOSTS ### nicht wirklich noetig, mach ich aber gern ;) CHECKHOSTS=( "user1@host1" "user2@host2" ) CHECKHOSTS[${#CHECKHOSTS[@]}]="user3@host3" ### ${#VAR[@]} = Anzahl der Eintraege im Array
Ich verstehe das mit den Arrays zu wenig. Ist nun das alternativ zu sehen:
CHECKHOSTS=( "user1@host1" "user2@host2" )
vs.
CHECKHOSTS[${#CHECKHOSTS[@]}]="user3@host3"
Ich habe eher an so was mit "here" gedacht, braucht natürlich nicht in eine Datei geschrieben werden. sort -u > "$CHECKHOSTS" << CHECKHOSTS user1@domain1.tld user2@domain2.tld etc. CHECKHOSTS
for host in "${CHECKHOSTS[@]}"; do ssh "$host" < rechtecheck.sh | mutt -s "Rechte auf $host" "$ADMIN" done ====
==== rechtecheck.sh ==== #!/bin/bash exec 2>&1 ### alles auf stdout ausgeben
DIRMODECHK=755 FILEMODECHK=644
if test `stat -c "%a" ~/public_html` -ne "$DIRMODECHK"; then find ~/public_html -ls find ~/public_html -type d -print0 | xargs -r -0 chmod -c "$DIRMODECHK" find ~/public_html -type f -print0 | xargs -r -0 chmod -c "$FILEMODECHK" fi ====
Wie du siehst entfaellt so komplett fast jegliches Problem beim Quoten. Zumindest wenn du keine Variablen von run_rechtecheck.sh uebergeben musst. Die Datei wird "unbehandelt" in die Pipe zu ssh zur remote-shell geschoben...
Eine Kleinigkeit musste ich korrigieren und zwar wurde der Pfad von rechtecheck.sh nicht gefunden, mit /usr/local/bin/rechtecheck.sh war es ok. Es gibt ein leeres Mail, wenn es keine Änderung gab. Wichtig ist mir auch noch, dass das Script _1_ Datei ist, kann man die beiden Scripts nicht in 1 Datei legen? Al
Hallo, Am Die, 31 Okt 2006, Al Bogner schrieb:
Am Montag, 30. Oktober 2006 19:54 schrieb David Haller:
Am Mon, 30 Okt 2006, Al Bogner schrieb: [..] Sollte eigentlich gehen. Versuch's mal mit der anderen Variante:
if test \$(stat -c "%a" ~/public_html) -ne "$DIRMODECHK"; then
Auch wieder: unexpected end of file
Hm. Dann hast du noch irgendwo ein Anfuehrungszeichen oder ein Here-Dokument offen... Das EOF muss am Zeilenanfang stehen! [..]
Ich verstehe das mit den Arrays zu wenig.
Ist nun das alternativ zu sehen:
CHECKHOSTS=( "user1@host1" "user2@host2" )
vs.
CHECKHOSTS[${#CHECKHOSTS[@]}]="user3@host3"
Ersteres ist die Variante, mehrere Werte einzutragen, letzteres fuegt als letztes Element ( Position = Bisherige Groesse des Array = ${#CHECKHOSTS[@]} ). Das Array ist indiziert von 0 .. $[ ${#CHECKHOSTS[@]} - 1 ]. Letzteres sollte also nur ein Beispiel sein, wie man "am Ende" noch anfuegen kann. Also z.B. wie in perl: @a = ( ... ); push(@A, nochwas); Du kannst z.B. auch sowas machen: CHECKHOSTS[0]="user1@host1" CHECKHOSTS[1]="user2@host2" CHECKHOSTS[2]="user3@host3" ... Da musst du halt die Indizes selber setzen.
Ich habe eher an so was mit "here" gedacht, braucht natürlich nicht in eine Datei geschrieben werden.
sort -u > "$CHECKHOSTS" << CHECKHOSTS user1@domain1.tld user2@domain2.tld etc. CHECKHOSTS
Das geht nicht. Nimm die Normale Variante: CHECKHOSTS=( "user1@host1" "user2@host2" ... "usern@hostN" ) [..]
Eine Kleinigkeit musste ich korrigieren und zwar wurde der Pfad von rechtecheck.sh nicht gefunden, mit /usr/local/bin/rechtecheck.sh war es ok.
Aeh, ja, du musst halt die Dateinamen anpassen.
Es gibt ein leeres Mail, wenn es keine Änderung gab.
Stoert das sehr?
Wichtig ist mir auch noch, dass das Script _1_ Datei ist, kann man die beiden Scripts nicht in 1 Datei legen?
Nein. Ausser halt wieder mit Here-Dokument, wo man dann eben eher Probleme mit dem Quoten bekommt. Andererseits finde ich es gar nicht schlecht, wenn man beide Scripte (das Lokale, mit den Hosts usw.) und das, das dann auf den remote-Rechnern ausgefuehrt wird, getrennt pflegen kann ;) -dnh -- Die Evolution ist das Vorbild der Konsumgesellschaft. "Schnell weg und neu!" -- Dieter Nuhr
Al Bogner wrote:
Ein Hoster bereitet mir gerade etwas Kopf zerbrechen. Ich probiere den erst seit kurzer Zeit aus und einige Dinge sind etwas seltsam. Anfangs war bei den meisten, aber nicht allen public_html-Verzeichnissen das Recht auf 750 gesetzt, wunderbar die Welt darf die Homepage nicht sehen ;-) Daraufhin habe ich die Rechte auf 755 geändert.
Nun stelle ich heute zufällig fest, dass die Rechte wieder auf 750 gesetzt wurden. Man freut sich, zum Glück ist zur Zeit alles ein Test-Szenario.
spätestens jetzt wäre schon die Kündigung auf dem Tisch des Hosters
Ich möchte nun folgendes von einem Script aus machen, das lokal aufgerufen wird.
Prüfung der Rechte des Verzeichnisses von public_html und der Dateien darin inkl. Unterverzeichnisse, wenn die Rechte nicht passen sollen die Rechte
geändert werden. Ich habe einen Zugang vom lokalen Rechner mit Keys ohne PW, kann also per Script die Verbindung aufbauen.
Wie erreiche ich, dass das Script die Rechte nicht lokal prüft, sondern am entfernten Host. Theoretisch könnte ich dort ein Script hinterlegen und einen Cronjob prüfen lassen, aber ich traue dem System dort nicht. Wenn das noch mal passiert, wird sowieso der Hoster gewechselt. Im Produktivbetrieb möchte ich aber nicht deswegen Probleme haben, weil die Rechte verändert wurden.
Ist es eigentlich ligitim, dass der Hoster in das System eingreift ?! Welchen Sinn hat es, dass er DEINE Rechte umsetzet ? Desweiteren schau doch einfach mal ob bereits ein Cronjob läuft der diese Rechte für den Hoster ändert. Vielleicht kannst du diesen ausstellen. Einen Ansatz für ein Script habe ich leider gerade nicht paprat. Sorry. Gruß Stefan
Al Bogner wrote:
Ein Hoster bereitet mir gerade etwas Kopf zerbrechen. Ich probiere den erst seit kurzer Zeit aus und einige Dinge sind etwas seltsam. Anfangs war bei den meisten, aber nicht allen public_html-Verzeichnissen das Recht auf 750 gesetzt, wunderbar die Welt darf die Homepage nicht sehen ;-) Darauf hin habe ich die Rechte auf 755 geändert.
Nun stelle ich heute zufällig fest, dass die Rechte wieder auf 750 gesetzt wurden. Man freut sich, zum Glück ist zur Zeit alles ein Test-Szenario.
Überprüfe die Einstellungen von /etc/permissions. Wenn das nicht hilft, setze die Rechte in /etc/permissions.local. Die Rechte werden jedesmal gesetzt, wenn Suseconfig aufgerufen wird. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Freitag, 27. Oktober 2006 17:31 schrieb Sandy Drobic: Hallo Sandy,
Überprüfe die Einstellungen von /etc/permissions.
Es geht um die Situation beim Hoster. Ich fand noch nichts zu "permissions". Das System dort dürfte Centos sein. Wir können gerne darüber diskutieren, aber ich will nicht wegen OT Prügel bekommen ;.-) Der eigentliche Thread handelt von einem lokalen Script, das die Rechte remote ändert. Al
participants (5)
-
Al Bogner -
David Haller -
Dominik Klein -
Sandy Drobic -
stefan.milani＠imperia.net