Üdv!
Adott egy gép, amin eddig a backup gyakorlatilag a fontos könyvtárak "össze tar-olása"(tar.bz2) volt. Szeretném a backupolást a jövőben az rsync-re bízni, mivel ez a sávszélesség tekintetében gazdaságosabb lenne. Egyedüli problémám a jogosultságok megőrzésénél adódik. Arra gondoltam, hogy valahogy így fogom használni:
rsync -az /minden/ami/fontos/ backup@tavoli-gep.hu:/home/backup/
Ez szép és jó is, de a jogosultságokat és tulajdonosokat így képtelenség megőrizni, mivel nem root-ként csatlakozok a remote géphez. A fordított felállás, tehát, hogy a tavoli-gep.hu csatlakozzon a menteni kívánt géphez megint nem jó, mert root nélkül jó néhány dologhoz nem fér hozzá.
A kérdésem tehát: Hogyan szokás ezt a problémát áthidalni biztonságosan? (root-ként nem szívesen loginolnék a tavoli-gep.hu-ra)
u.i.: Nem ragaszkodok az SFTP-hez, vevő vagyok bármi másra is...
- 3595 megtekintés
Hozzászólások
root-nál amúgy megőrzi?
- A hozzászóláshoz be kell jelentkezni
Meg kell őriznie, mivel az -a opció magába foglalja a p o és g opciókat is, amik pont erre hivatottak. A probléma, hogy userként(mivel nem root jogokkal megy az SFTP login) nem tud chown-olni más felhasználókra.
- A hozzászóláshoz be kell jelentkezni
-a vagy -p kapcsolóval megőrzi a jogosultságokat, nem?
- A hozzászóláshoz be kell jelentkezni
Én lementem a fájljogokat külön, így ez nem gond. http://www.unix.com/shell-programming-scripting/42750-shell-script-save…
- A hozzászóláshoz be kell jelentkezni
Valami ilyesmiben gondolkodtam én is, köszi. Egyelőre ez lesz a befutó. Proci, köszi a tippet neked is, lehet megúsztam ezzel egy kis szívást.. :)
- A hozzászóláshoz be kell jelentkezni
Sima -a nálam néha összekavarta az UID/GID-et az adott rendszer passwd/group fájlja alapján, ezért évek óta --numeric-ids opcióval mentek.
Természetesen ehhez is root jog kell, de garantáltan nem kutyolódik össze semmi.
Pl. mysql egyik rendszeren 60, másikon 80-as uid. A célrendszeren is mysql-nek adja a fájlt, nem számít, hogy az 80-as uid. Na ere jó a --numeric-ids
- A hozzászóláshoz be kell jelentkezni
Csak egy ötletet mondanék, szerintem nem túl nehéz megoldani.
Mi van akkor ha a mentendő gépen rsync-el ellenőrzöd a változásokat, ezt betarolod, átküldöd a cél gépre, ott kitarolod és rsyn-cel áttöltöd a cél dir-be?? :)
- A hozzászóláshoz be kell jelentkezni
ha a másik gépen nincs root-joga, akkor igy se tudna tulajt állítani ott.
- A hozzászóláshoz be kell jelentkezni
Az rsyncd nem segíthet? Úgy tudom ilyesmikre is jó.
- A hozzászóláshoz be kell jelentkezni
mivel nincs root joga a gépre, valszeg nem is tud feltenni és futtatni, ilyesmit, gondolom én.
Amúgy az rsyncd csak kiajánl egy mappát, rsync protokollon keresztül, amit az rsyncel letölthetsz.
Valamint a probléma alapja, hogy tulajt csak root-ként állíthatsz.
- A hozzászóláshoz be kell jelentkezni
En azt mondom, egy without-password -os root nagy kart nem tud okozni, hacsak nem hagyod el a privat ssh kulcsodat - ez esetben meg hulyeseg ellen nem ved semmi.
Illetve kevesse ismert funkcio az sshd-ben, hogy az allowusers-ben meg lehet adni, hogy az adott user honnet csatlakozhat. Tehat ha azt mondom, hogy root@10.0.0.11 akkor az azt jelenti, hogy a 10.0.0.11-rol fogadjuk csak el a root usert.
En egyebkent duplicity-t hasznalok, ez megorzi a jogokat, mert tar fajlba csomagol, viszont lehet vele sftp-re menteni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
A without-password -os root azért jó ebben az esetben, mert ha véletlen megtörik azt a szervert amit backupolsz, akkor buktad vele együtt a backup szerveredet is teljes egészében.
Viszont ha backupolandó szerverenként van egy külön user a backup szerveren megfelelő opciókkal az authorized_keys-ben, akkor csak az ahhoz szerverhez tartozó backuphoz férnek hozzá jó esetben.
Nyilván, ha backup scripthez tartozó bejegyzés az authorized_keys-ben megfelelően van paraméterezve az enyhíthet a dolgon, de ha nem muszáj akkor minek.
Ja és ezen az allowusers-nél a host megadása sem sokat javít.
♲♻♲
- A hozzászóláshoz be kell jelentkezni
Ha megtorik a szervert es eljutnak a rootig, az csak az egyik problemad lesz, hogy a backup szerver is megy vele. Megy ott tobb minden mas is.
Egyebkent pedig nyilvan, ahol ilyen jellegu megfontolasok vannak, ott nem szabad engedni a root-ot loginolni - de el is lehet felejteni minden rsync alapu backupot, es valami tomoritett formatumuba lehet gondolkodni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Köszönöm a tippeket mindenkinek! A végső megoldás az lett, hogy rsync előtt a backupolni kívánt gépen csinálok egy sql dumpot és egy listát a fájlok jogosultságairól, tulajdonosairól. A fentebb ajánlott perl szkripteket átírtam sh-ra, de lényegében ugyan az. Utána megy a passwordless SFTP rsync-elés.
A célgépre is van egyébként root-om, de így a legegyszerűbb a dolog talán. Később még biztosan reszelek rajta, de egynek már jó! :)
- A hozzászóláshoz be kell jelentkezni
Backup előtt ls -lR > ls-lR. Ez elterjedt volt 2 évtizede az FTP szervereken. Aztán jól elfelejtettük.
- A hozzászóláshoz be kell jelentkezni
Hasznos, köszi!
- A hozzászóláshoz be kell jelentkezni
Mondjuk ennél egy
find . -lsvagy egy
find . -print0 -ls-nek egy fokkal feldolgozhatóbb kimenete van.
Feltéve persze ha vissza is akarjuk még állítani azokat a jogosultságokat.
Szerk.:
Talán itt még vannak korrektebb megoldások is:
http://stackoverflow.com/questions/3450250/is-it-possible-to-create-a-s…
http://www.unix.com/shell-programming-scripting/42750-shell-script-save…
♲♻♲
- A hozzászóláshoz be kell jelentkezni
man rsync:
--fake-super store/recover privileged attrs using xattrs
Van benne egy bővebb leírás is lentebb...
♲♻♲
- A hozzászóláshoz be kell jelentkezni
Hat ha a szerveren van xattr tamogatas. Kerdes, hogy van-e.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
sub
--
"'The time has come,' the Walrus said"
- A hozzászóláshoz be kell jelentkezni