Vlákno názorů k článku Nextcloud: instalace lokálního úložiště na vlastní server od Logik - Nextcloud jsem zkoušel a bohužel má jeden podstatnej...

Nextcloud jsem zkoušel a bohužel má jeden podstatnej problém. Nepodařilo se mi ho rozchoit spolu se sambou - tedy aby ta samá data byla dostupná přes sambu (s AD autentizací) a přes nextcloud. Nextcloud používá vlastní autentizaci a data jsou ve FS pod jedním uživatelem (alespoň tak si to pamatuju).

Skončil jsem u Syncthing, která sice funguje v detailech trochu jinak než cloud, ale ve výsledku zajistí totéž: stejná data na více místech, aniž by jakkoli vynucoval způsob uložení dat ve FS.

Jo, tohle je bohuzel neresitelny problem uz z logiky veci je nextcloud webova aplikace, ktere typicky bezi pod jednim uzivatelem, takze to nedava smysl, aby to tak fungovalo.

Misto samby muzete pouzivat webdav (se vsemi vyhodami a nevyhodami).

Pro nahravani se da pouzit trik, ktery je zminen na konci.

Riešiteľné to je - Synology to vo svojom Drive vyriešili - akurát je viac viditeľné pre userov, keď tam budú dávať chaty a videokonferencie, ako keď vyriešia základné problémy so storage a protokolmi.

Zjevne nepobezi pod webserverem apache/nginx - tady je problem imho architektonicky.

Používajú nginx iba pre ingress, inak je to node.js. aplikácia.

To by som však ako problém nevidel - to, že NC/OC používajú PHP ktoré beží v procese nginx/apache je ich voľba, kľudne by mohli upraviť svoju architektúru na takú, kde je možné použiť impersonation/de­legation. Už nie sme v dobe shared hostingov, kedy bolo dôležité aby všetko bežalo na náhodnom PHP náhodného hostingu.

Samozrejme, ze to resit jde. Apache podporuje ruzny authentizacni moduly vcetne treba Kerberosu

https://active-directory-wp.com/docs/Networking/Single_Sign_On/Kerberos_SSO_with_Apache_on_Linux.html

To je iná záležitosť; to čo linkujete rieši autentifikáciu (t.j. používateľ vie preukázať, kto naozaj je), ale tu ide o možnosť zmeniť UID procesu na UID používateľa, aby tento mal prístup k súborom a ich metadátam presne tak, ako to môže robiť daný používateľ na lokálnom systéme (t.j, použiť danú identitu a outsourcovať autorizáciu na lokálny systém).

Zo zjavných dôvodov do tejto hry ani apache, ani nginx nejdú a ostávajú bežať pod svojim httpd alebo apache2. Riešením by bolo rozdeliť aplikáciu do viacero procesov, z ktorých niektorí workery by mohli meniť uid, ale to by asi nešlo urobiť s existujúcou architektúrou httpd+php a predpokladajúcou, že to používateľ bude púšťať na shared hostingu.

Vyššie spomenutý Synology Drive beží ako root, takže spustiť worker proces s právami konkrétneho používateľa vie. Jeho proces nie je vystrčený priamo na sieť, ale sedí za reverse proxy, ktoré mu robí nginx. Nepotrebuje bežať na shared hostingoch, nie je napísaný v php, takže tieto veci nepotrebuje riešiť a ani ich nerieši.

Tak na shared hostingu moc ta samba nepripada v uvahu, tak tam to neni potreba resit. Jinak PHP nemusi bezet pod stejnym uzivatelem jako apache. V FPM si muze clovek nastavit jakyho uzivatele chce. Takze reseni tohohle je bud spoustet PHP jako root nebo proste mit na ukladani souboru zvlast sluzbu no.

Nevím, jak je to v NextCloud (používám OwnCloud), ale předpokládám, že to bude podobné.
Sdílení pomocí SMB + WebDAV + (OC) klienta jsem nastavil tak, že jsem přidal "Externí úložiště", tedy diskový prostor je "jinde" než přímo na lokálním FS. (On to sice je stejný stroj, ale prostě ty soubory leží jinde.) Uživatel má pak nastavený například adresář "dokumenty" na "server", kde je zároveň funkční i SMB share.
Funguje to celkem dobře - trochu klesla rychlost přístupu k souborům, ale stále je nad rychlostí sítě, takže uživatelé nic nepoznají. (Rescan souborů lze vhodit do cronu...)

1. 4. 2021, 10:36 editováno autorem komentáře