Fórum Root.cz
Hlavní témata => Server => Téma založeno: Pavouk106 14. 04. 2014, 09:37:45
-
Zdravím,
potřeboval bych udělat (v Linuxu) adresář, do kterého budou moct přistupovat konkrétní/všichni uživtelé systmu včetně zápisu. Ideálně bych to měl tak, že by adresář byl např. na umístění /home/sdileny, data by byla přímo v něm a uživatelé by měli ve svých domovských adresářích pouze odkazy/symlinky.
Zároveň tenhle sdílený adresář budu chtít skriptem rsyncovat jednou za čas jinam a tím pádem mne zajímají mimo jiné také práva všech podadresářů a souborů. Chtěl bych je (nejspíš) všehcny vlastnit jako pavouk:pavouk.
Poraďte, jak (třeba) vysvětlit adresáři, že vše v něm bude mít vlastníka pavouk:pavouk a práva ugo+rw. Nebo to jde i jinak a lépe?
Předem díky
-
data by byla přímo v něm a uživatelé by měli ve svých domovských adresářích pouze odkazy/symlinky.
Obávám se, že myšlenka zůstala nepochopena... Symlinky na co?
-
sudo chown pavouk.pavouk /home/sdilene a chmod ugo+rw /home/sdilene
Aj keď by som dal radšej skuponu users, a v podadresári /home/sdilene/ by som vytvoril každému jeho pieskovisko ktoré si nastaví podľa potreby, a tom mu nalinkoval cez ln -s aj s parametrami.
-
Poraďte, jak (třeba) vysvětlit adresáři, že vše v něm bude mít vlastníka pavouk:pavouk a práva ugo+rw. Nebo to jde i jinak a lépe?
V Linuxu je vlastníkem vždy ten, kdo soubor (adresář, ...) vytvořil, oprávnění se naopak dědí. Za předpokladu, že nikdo z uživatelů nebude s oprávněními manipulovat (?!), stačí nastavit výchozí oprávnění pro adresář /home/sdileny. Pokud trváte na tom, že budete vlastníkem celého obsahu, musíte čas od času použít chown.
Jinak (netvrdím že lépe) to jde udělat tak, že do /home/sdileny namontujete FS, který přístupová práva neumí, např. FAT32.
PS: ugo+rw lze nahradit a+rw (all).
-
A k cemu vlastne potrebujes vlastnit vsechny ty adresare? Co je ucelem toho?
-
Ad. symlinky: to netreba resit, jde o prkotinu, ne o podstatnou cast veci.
Ad. vlastneni adresare a vseho v nem: budu delat rsync jinam, hodilo by se mit vsechno pod jednim uzivatelem.
Peter: To prave nechci. Chtel bych jedno velky piskoviste bez rozdilu.
Olaf: Takze to vypada, ze jinak to ani nepujde.
Mel jsem puvodne na mysli, zda nejde mit adresar tak, ze by vse v nem natvrdo delilo jeho nastaveni nehlede na to, kdo by to tam vkladal... Tzn. vlastnika, skupinu, prava.
-
Nabizi se pouzit ACL http://www.root.cz/clanky/acl-rozsirena-nastaveni-prav-v-linuxu/
-
Kompletní dědění práv Posixová práva ani ACL neumí. Základní požadavek – aby k datům mohlo přistupovat a zapisovat je víc lidí – by se klasicky řešil tak, že vytvoříte skupinu, všechny požadované uživatele do ní zařadíte a pak nastavíte právo rw- na společném adresáři téhle skupině. Problém pak ale je, že se uživatelé musejí starat o práva souborů a adresářů, které tam vytvářejí – pokud tam vytvoří soubor a neurčí mu nějaká práva, bude mít přiraženu výchozí skupinu uživatele, takže ostatní jej už nebudou moci přepsat (pokud bude mít typická práva rw-rw-r--). Tohle se dá obejít SGID bitem na společném adresáři – pak všechny nově vytvářené soubory adresáře zdědí skupinu z nadřazeného adresáře, ne skupinu uživatele. SGID příznak se pak rekurzivně nastavuje i pro adresáře vytvořené v tomto adresáři. Ale pokud uživatel do adresáře soubor nebo jiný adresář nakopíruje i se zachováním práv, dojde ke stejnému problému, tj. budete tam mít soubory nebo adresáře, které nemají nastavenou správnou skupinu nebo SGIDbit.
rsync bych neřešil tím, že budou mít všechny soubory stejného vlastníka. Buď bych jej také zařadil do nové skupiny (tím pádem by mohl soubory číst i zapisovat). Pokud byste chtěl, aby rsync mohl jen číst, přidal bych speciálnímu uživateli pro rsync právo přes ACL. Opět, když to nastavíte jako dědičné, bude se propisovat i do vytvořených podadresářů, ale vlastník souboru nebo adresáře to právo může odebrat.
-
BTW, kdyz ten rsync pobezi trebas z cronu pod rootem, tak jemu snad jedno, kdo ma na co jaka prava.
-
BTW, kdyz ten rsync pobezi trebas z cronu pod rootem, tak jemu snad jedno, kdo ma na co jaka prava.
To ano, ale je otázka, zda je to správně, že ten rsync běží pod rootem.
-
V Linuxu je vlastníkem vždy ten, kdo soubor (adresář, ...) vytvořil, oprávnění se naopak dědí. ...
Kompletní dědění práv Posixová práva ani ACL neumí. ...
Omlouvám se za chybnou informaci. Pravdu má samozřejmě kolega Jirsák.
Dovolím si doplnit, že v Mac OS X (BSD) se ACL nastavují přímo pomocí chmod a umožňují nastavit i dědění oprávnění. Naopak vlasníka obsahu adresáře lze vnutit nastavením atributu SUID příslušného adresáře. Oprávnění včetně ACL se pak ověří pomocí ls (ls -le). Nějak se mi ty OS v hlavě prohodily :).
PS: Když už jsem u těch oprav :), u zmíněného FS FAT32 samozřejmě záleží, jak se namontuje (to ostatně platí u všech FS).
-
No, situace se má tak, že jednou za čas budu dělat ručně rsync. Rsync pojede přes SSHFS na jiný stroj. SSHFS běží přes FUSE a tím pádem závisí na uživateli. Takže rootem nespouštět. Ve finále by se dalo říct, že stačí při rsync nebrat v potaz původního vlastníka a nahradit je vlastní sadou (pavouk:pavouk). Otázka ale je, když pak budu dělat zpětný rsync (pro případ, že se změní data na tom vzdáleném stroji), jestli rsync nevezme vlastníka v potaz při řešení duplicity... Tzn. jestli si rsync bude myslet, že už data existují, i když budou mít jiné vlastníky.
Snad je to srozumitelný.
Jednoduše jde o následující: Jde o desktop, ne server nebo kritickou věc. Mám jeden FS (EXT4) mountovaný jako /home. Je na něm víc uživatelů. Chci aby uživatelé mohli navzájem do jednoho adresáře, kde bude hudba, fotky, filmy, ... (odtud si to taky vezme miniDLNA, to ale jen na okraj, to neřeším). Klidně ať si každej uživatel tvoří co chce, ale jde mi o to, abych to pod jedním užiatelem mohl celé rsyncovat jinam a to i naopak - odjinud do toho adresáře - a to bez problémů.
(Že já blbec se nedokážu nikdy vyžvejknout napoprvý)
-
BTW, kdyz ten rsync pobezi trebas z cronu pod rootem, tak jemu snad jedno, kdo ma na co jaka prava.
To ano, ale je otázka, zda je to správně, že ten rsync běží pod rootem.
Proc ne? Zalezi na tom, jestli mate cilove zarizeni pod kontrolou. Krome toho mate moznost pustit si tam na localhostu rsyncd a tlacit to na nej skrz ssh tunel.
Ve finále by se dalo říct, že stačí při rsync nebrat v potaz původního vlastníka a nahradit je vlastní sadou (pavouk:pavouk). Otázka ale je, když pak budu dělat zpětný rsync (pro případ, že se změní data na tom vzdáleném stroji), jestli rsync nevezme vlastníka v potaz při řešení duplicity...
Rsyncu se da hodit parametr --no-owner. Krome toho by bylo dobre vedet, kdy byste eventuelne rsyncoval zpet. Ma to byt pouze pro pripad havarie, tedy jako zaloha? Pokud ano, tak asi neni nutne nejake vlastniky resit. Proste se to tam jednou za havarii disku nejak narve rucne a prava a vlastnici se upravi, pokud to bude potreba.
-
To bych řešil úplně jinak. rsync pod rootem přímo na vzdálený stroj (bez sshfs, ať tam ten rsync vůbec k něčemu je). Seznam adresářů, které se mají synchronizovat, předáte jako parametry. Nemusíte pak řešit žádná práva na soubory, žádné odkazy, zálohuje se přesně to, co je na disku (včetně vlastníků a práv). A jako bonus se nebude pokaždé kopírovat všechno, ale využijete vlastnosti rsyncu a po síti budete přenášet jen změněná data a kontrolní součty.
-
To bych řešil úplně jinak. rsync pod rootem přímo na vzdálený stroj (bez sshfs, ať tam ten rsync vůbec k něčemu je). Seznam adresářů, které se mají synchronizovat, předáte jako parametry. Nemusíte pak řešit žádná práva na soubory, žádné odkazy, zálohuje se přesně to, co je na disku (včetně vlastníků a práv). A jako bonus se nebude pokaždé kopírovat všechno, ale využijete vlastnosti rsyncu a po síti budete přenášet jen změněná data a kontrolní součty.
Může být. Nicméně stále potřebuju hnout s tím obřím pískovištěm, kde si může každý plácat svoje bábovičky + každý může plácat kohokoliv jiného bábovičky. A to bez ručních zásahů.
-
Může být. Nicméně stále potřebuju hnout s tím obřím pískovištěm, kde si může každý plácat svoje bábovičky + každý může plácat kohokoliv jiného bábovičky. A to bez ručních zásahů.
Založit pro to skupinu, uživatele přidat do té skupiny, skupinu adresáře „obří pískoviště“ nastavit na tuto skupinu a nastavit mu SGID bit. Obvykle tam asi uživatelé nevyrobí takové nastavení práv, aby to něčemu vadilo. Pokud chcete i tomuhle předejít, pak skript spouštěný z intofy nebo cronu, který bude nově vzniklým souborům a adresářům nastavovat určenou skupinu a práva rw- pro skupinu. Bez toho to v linuxu nepůjde, není por něj žádná rozšířená implementace hiearchických přístupových práv, jako měl třeba Novell Netware nebo mají Windows. Možná to bude umět NFSv4 ACL, ale nejsem si jist, nečetl jsem podrobnější popis.
-
Hehe - shodou okolností bude obří pískoviště na NFSv4 :-) Ale SGID a společná skupina bude stačit. Vzhledem k tomu, že adresář ale bude ležet na 24/7 stroji, tak nebude problém dělat jednou za den CRONem nějaké úpravy nad celý adresářem včetně obsahu. Ok, jsem poučen :-)
Díky moc.
Pokud je ještě čas a chuť, přeptal bych se tu na ten rsync pod rootem bez SSHFS -> Použití přímo rsyncu. Jak na to? Ideálně příklad ze života rozebraný na kusy a popsaný... Abych to pochopil :-)
-
Pokud je ještě čas a chuť, přeptal bych se tu na ten rsync pod rootem bez SSHFS -> Použití přímo rsyncu. Jak na to? Ideálně příklad ze života rozebraný na kusy a popsaný... Abych to pochopil :-)
Mate zdrojovy stroj a cilovy stroj. Na zdroji je minimalne rsync a ssh, na cili je minimalne sshd a rsync. Pustite rsync ze zdroje na cil, rsync se na cil prolame po ssh, tam si pusti take rsync a ty dva rsyncy si pak budou povidat a sdelovat si, ktery kus ktereho souboru ma jiny kontrolni soucet a musi se znovu prenest.
Delat rsync pres sshfs by byl totalni nesmysl. To to muzete rovnou kopirovat a vyjde to v podstate nastejno nebo, podle toho, jak to maji v rsyncu implementovane, by to mohlo byt jeste horsi. Pres sshfs by se to asi chovalo jako by se delal rsync dvou lokalnich kopii. Ale snad rsync neni tak blby, aby si v lokale posilal delty souboru, kdyz by se to muselo stejne vsechno z obou kopii precist, porovnat a pak prepsat rozdily, kdyz by asi vyslo efektivneji skouknout velikost, datum a pri neshode to preplacnout novou kopii.
Rsync ma cenu, kdyz bezi jedna kopie na kazdem konci, cimz se usetri sitovy provoz a sype se to rychleji. Zejmena, pokud to jede po nejake hrozne lince.
-
Pokud je ještě čas a chuť, přeptal bych se tu na ten rsync pod rootem bez SSHFS -> Použití přímo rsyncu. Jak na to? Ideálně příklad ze života rozebraný na kusy a popsaný... Abych to pochopil :-)
Příklady ze života tu zrovna mám jenom s rdiff-backup nebo rsync, kde je ale na druhé straně rsync server. Tak si zkusím nějaký příklad ze života, kde je na druhé straně jenom ssh, vymyslet :-)
rsync /home/uzivatel backup@vzdaleny.server.example.com::/var/data/backup/uzivatel/
Připojuje se na vzdálený počítač přes ssh pod uživatelem backup, na lokálním počítači mám pod uživatelem, pod kterým rsync spouštím (root) uložený ssh klíč pro toho uživatele backup. Na tom vzdáleném stroji stačí jen SSH server a uživatel backup, který má nějaký příčetný shell. Jo a ty dvě dvojtečky v příkazu nejsou chyba.
Dá se to udělat i tak, že na vzdáleném serveru běží speciální rsync server, ale to mi připadá pro zálohování zbytečné. To se hodí třeba v případě, kdy chcete rsync zpřístupnit více uživatelům a nechcete je pouště do shellu.
Další parametry rsyncu (co a jak se má nebo nemá synchronizovat) si určitě doplníte sám :-)
Koukám, že JardaP to zatím popsal dobře i s vysvětlením, tak ten svůj komentář zachovám aspoň kvůli tomu příkazu.
-
Dá se to udělat i tak, že na vzdáleném serveru běží speciální rsync server, ale to mi připadá pro zálohování zbytečné. To se hodí třeba v případě, kdy chcete rsync zpřístupnit více uživatelům a nechcete je pouště do shellu.
Rsyncd ma vyznam i jindy. Napriklad kdyz potrebuji zalohovat vzdaleny stroj na lokalni a nemam tam povoleny root login. To byl kdysi pripad meho routeru, kde root login nebyl, protoze to bylo rovnou na Internetu a furt se tam stejne nekdo dobyval. Samozrejme, dalo by se rsync iniciovat i ze strany routeru, jenze to by bylo moc prace, protoze bych se tam musel napred zalogovat nebo bych to musel dat do cronu a pak si naridit budika, abych zapnul USB disk. Navic by to byl jediny stroj, ktery by byl zalohovan jinak, nez ty ostatni, tedy vsechno z jedne plecky.
Ovsem pozor, pokud se na tom neco nezmenilo, tak komunikace s rsyncd neni sifrovana, cili se musi nechat poslouchat na localhostu a na to se protunelovat pres ssh. Cele je to ponekud pakarna na rozchozeni. Musi se konfigurovat rsyncd a udelat tunel. V tomhle pripade nevidim, k cemu by to bylo, tak bych si nepridelaval praci.
-
rsync /home/uzivatel backup@vzdaleny.server.example.com::/var/data/backup/uzivatel/
.... Jo a ty dvě dvojtečky v příkazu nejsou chyba.
Předem se omlouvám za možná špatně pochopenou manuálovou stránku, ale mám za to, že '::' se použijí pro připojení k rsyncd ??
There are two different ways for rsync to contact a remote system:
using a remote-shell program as the transport (such as ssh or rsh) or
contacting an rsync daemon directly via TCP. The remote-shell trans-
port is used whenever the source or destination path contains a single
colon (:) separator after a host specification. Contacting an rsync
daemon directly happens when the source or destination path contains a
double colon (::) separator after a host specification, OR when an
rsync:// URL is specified (see also the "USING RSYNC-DAEMON FEATURES
VIA A REMOTE-SHELL CONNECTION" section for an exception to this latter
rule).
-
Lidi (nebo bych měl říct Linuxáci? :-) ), díky moc. Je vidět, že i když si myslím, že něco umím nebo znám, pořád jsem začátečník jak sviňa :-)
Dneska večer s tím budu experimentovat a doufám, že přes noc už zálohovat ;-)
-
Lidi (nebo bych měl říct Linuxáci? :-) ), díky moc. Je vidět, že i když si myslím, že něco umím nebo znám, pořád jsem začátečník jak sviňa :-)
Spis se priznej, ze je pohodlnejsi, kdyz ty manualy a Google cte nekdo jiny. ;-) BTW, konkretne k rsyncu lze vygooglovat priklady skoro na vsechno, i kdyz je to nekdy ponekud na hlavu to zkombinovat tak, aby vypadlo, co chci. Kdyz jsem si hral s rsyncd a ssh tunelem, tak mi to docela trvalo, nez to delalo, co jsem chtel.
-
JardaP: Původně zněl dotaz jinak (na adresář), ale když jsem se rozpovídal, tak jsem "využil" dobroty lidí a ptal se dál :-) Jde spíš o to, že než laborovat sám, je nejjednodušší zeptat se někoho, kdo ví a zná - pak se srozumitelně dozvím co potřebuju. Ve zkratce: Ano, je to pohodlnější. A díky za vysvětlení ;-) Bejt vy z Plzně, vzít vás já na pivo :-)
-
Psst, kdovi, kolik zde pritomnych je z Plzne a kdovi, kolik toho vychlastaji. Aby se ten rsync sakra neprodrazil!
-
Předem se omlouvám za možná špatně pochopenou manuálovou stránku, ale mám za to, že '::' se použijí pro připojení k rsyncd ??
Dotaz je to dobrý, ale odpověď neznám :-) Podle manuálové stránky to tak je. Podle Wikipedie tato syntaxe není dobře popsaná nepoužívá se snadno, s čímž souhlasím. Při pokusu to hlásí, že vzdálená cesta musí začínat jménem modulu a ne lomítkem, a když cestu upravím, hlásí odmítnuté spojení (na druhé straně rsyncd neběží). Takže je to asi jak píšete.
Já jsem tu syntaxi se dvěma dvojtečkama měl u rdiff-backup, kde to fungovalo. Myslel jsem, že se to takhle přímo předá rsyncu, ale asi ne. Takže pro použití přes ssh má být asi jen jedna dvojtečka.
-
Dík za odpověď.