[EMAIL PROTECTED] - Digest Saturday, May 26 2001 Volume 01 : Number 360
----------------------------------------------------------------------
Date: Sat, 26 May 2001 09:19:40 +0200
From: Jochen Hein <[EMAIL PROTECTED]>
Subject: [PUG] Re: isdn und adsl gleichzeit
>>>>> "DS" == Denny-Schierz@home <[EMAIL PROTECTED]> writes:
DS> Wenn ich mein ISDN starte (ADSL l�uft
DS> bereits) dann ist mein Restliches Internet tot, ich gehe davon
DS> aus, das das mit dem Routing zusammenh�ngt. Wie l��t sich das am
DS> gescheitestes unter einem Hut bringen.
Was willst Du haben?
- - Default route auf ADSL,
- - Host und Netz-Routen via ISDN?
Dann kein defaultroute in der ISDN-Konfiguration, und darauf achten,
dass keines der Skripte auf die Idee kommt das dennoch zu tun.
Macht aber hier eher �rger, da dann die Name-Server unterschiedlich
sein m�ssen...
Jochen
- --
Nicht weil die Dinge schwierig sind, wagen wir sie nicht,
sondern weil wir sie nicht wagen, sind sie schwierig.
------------------------------
Date: Sat, 26 May 2001 23:04:07 +0200
From: Martin Schmitt <[EMAIL PROTECTED]>
Subject: [PUG] Backups mit rsync und ssh als Root
Hi!
Nach langem, langem Suchen habe ich jetzt den Weg erfunden, wie man per
Rsync mit SSH als Transportmedium Datensicherungen (-replikationen) machen
kann, bei denen sowohl Eigentumsverh�ltnisse als auch Permissions der
replizierten Dateien erhalten bleiben, und bei dem die Sicherheit der
beteiligten Systeme einigerma�en gewahrt bleibt.
In der Beschreibung setze ich mal voraus, da� der Leser sowohl SSH als auch
Rsync bereits benutzt hat und leidlich im Griff hat. Wer sich nicht
angesprochen f�hlt, sollte AUF GAR KEINEN FALL die beschriebenen Sachen
einfach nachvollziehen/abtippen und ausprobieren!!! Wenn rsync hohldreht,
ist noch bevor man auf Ctrl-C dr�ckt, die Maschine im Zweifelsfall
vollst�ndig platt!!!
Das ist mein Ernst.
Noch da? Okay. :-)
Mir fiel in der Manpage des sshd(8) der zweite Absatz der folgenden
Beschreibung auf:
PermitRootLogin
Specifies whether the root can log in using ssh(1). The argument
must be ``yes'', ``without-password'' or ``no''. The default is
``yes''. If this options is set to ``without-password'' only
password authentication is disabled for root.
Root login with RSA authentication when the command option has
been specified will be allowed regardless of the value of this
setting (which may be useful for taking remote backups even if
root login is normally not allowed).
Auf Deutsch: Selbst wenn "PermitRootLogin" auf "No" steht, kann Root in
seinen authorized_keys die Option "command" setzen, um genau den dort
eingetragenen Befehl auszuf�hren.
Das Ziel war danach klar: Rsync startet �blicherweise "on the fly" einen
Serverproze� auf der Gegenstelle. Der Aufruf dieses Serverproze� mu� also
als "command" eingetragen werden.
Auf der "empfangenden" Maschine wird zuerst ein Verzeichnis "/backup"
vorbereitet. chown root, chmod 700.
Anschlie�end wird auf der "sendenden" Maschine ein RSA-Schl�ssel f�r Root
generiert, ohne Mantra, denn das wollen wir nachher ja nicht eingeben
m�ssen.
Jetzt wird der Public Key auf dem "empfangenden" System in
/root/.ssh/authorized_keys reingeschrieben. Vorne wird die ganze So�e mit
dem "command" und noch einigen weiteren selbsterkl�renden Nettigkeiten
davorgesetzt.
Als "command" wird die Kommandozeile genommen, die rsync ausf�hren w�rde,
wenn "dr�ben" eine Shell vorhanden w�re. Das scheint nicht von Hause aus
dokumentiert zu sein, daher habe ich die Parametrisierung bei einigen
wenigen halbwegs gescheiten Fundstellen im WWW abgeschaut:
from="sendesystem.domain.com",command="/usr/bin/rsync --server --delete -RlogDtpr .
/backup/sendesystem.domain.com",no-port-forwarding,no-pty,no-agent-forwarding 1024 35
17037560268...<Restlicher Key>
"--server" taucht in der Manpage leider nicht auf. Das mu�te ich einfach so
�bernehmen.
"--delete" ist **gef�hrlich** - Es l�scht Dateien vom Empfangssystem, die auf
dem Sendesystem nicht mehr existieren. Wenn das im falschen Kontext
ausgef�hrt wird, tut's den Knall. Die Auswirkungen sind wirklich grauenhaft.
"-RlogDtpr" will ich mal nicht erkl�ren, einfach in die Manpage von
Rsync schauen.
Zu den Pfadangaben: Der "." funktioniert irgendwie, und der Zielpfad
ist der Pfad, wo die Datensicherung landen soll.
Jetzt zum Aufruf von rsync auf dem "sendenden" System:
rsync --delete -e "ssh -C" -Ravv /etc /usr/local /home
empfaenger.domain.com:/backup/sendesystem.domain.com
Es gilt das vorher gesagte. "-a" ist gr��tenteils synonym zu den
Hieroglyphen aus dem Empf�ngerseitigen Aufruf. "-e" gibt das
Transportprotokoll (den rsh-Ersatz) an, in diesem Fall ist das ssh mit
Kompression.
Man _kann_ beim Empf�nger den Pfad durch "/" ersetzen und sich darauf
verlassen, da� der --server-Aufruf, der richtig parametrisiert ist, das
ganze richtet. Mir war das allerdings nicht allzu sympathisch. Wer will
schon ein /etc vermeintlich nach / replizieren? Keine besonders nette
Vorstellung.
Nochwas: Wenn die Aufrufe von rsync auf dem Sendesystem und rsync --server
auf dem Empf�nger nicht zueinander passen, gibt es absolut seltsame und
unpassende Fehlermeldungen. Hier kann man mit mehreren "-v" das Loglevel
erh�hen um zu sehen, was genau passiert. Ich habe zwischendurch mit -vvvvv
gearbeitet.
Tja, und das wars auch schon. Viel Erfolg damit. :-)
Falls jemand eine Beschreibung der Parameter von Rsync in diesem omin�sen
Gegenstellen-Modus hat, w�re ich �bergl�cklich.
Ciao,
- -martin
P.S.: Die Fundstellen, wo diese Technik erw�hnt wurde, sind:
http://www-co.ch.cam.ac.uk/internal/theory/backup-setup.html
http://www.geocrawler.com/archives/3/216/1999/6/0/2386755/
- --
"The day they take Linux away from us
is the day they pry it from our cold, dead fingers!"
------------------------------
End of [EMAIL PROTECTED] - Digest V1 #360
************************************
--------------------------------------------------------------------------
Digest von "[EMAIL PROTECTED]" - http://www.pug.org
