fuse: есть ли fuse FS которые ...

самому набомбить не проблема, например, на питоне. Только рабочих примеров не так много, увы.

А зачем это понадобилось?

самому набомбить не проблема, например, на питоне. Только рабочих примеров не так много, увы.

Если чтото бомбить, то уж сразу бомбить что-то более стоящее. Я подумал, вдруг ктото уже набомбил отдельный кусок.

А зачем это понадобилось?

Для тру мультиюзерной системы.... заметьте , если ранее(во времена оные) nfs уже был рассчитан на то что с одним /nfs/host1_disk1 работали все сотни юзеров, то сейчас линукс скатывается в режим реально однопользовательской системы. Когда один юзер - один компутер и никак иначе.

да, вроде, reiserfs такое поддерживает. Или в планах было. Раздельные неймспейсы.

Для тру мультиюзерной системы....

как это связано? Ты имеешь в виду чтобы юзеры не видели друг друга?

Для тру мультиюзерной системы....

как это связано? Ты имеешь в виду чтобы юзеры не видели друг друга?

Я имею в виду что два одновременно залогиненых юзера не должны ощущать неудобства от того что их в системе два *одновременно*.

Ну сам подумай - вот есть юзер. Пусть он лезет на какой то удаленный диск который для него сконфигурил админ тем или иным способом. В случае нормального мультиюзера он просто лезет в некую папку /mnt/disk а система сама решает спрашивать его пароль или нет, и потом на этом диске он под своим uid, это все отражается в логах, etc, любая программа которую он запустил может забирать/принимать данные с этого диска просто если ей укажут /mnt/disk в качестве места куда/откуда.

В текущем случае юзер лезет в проводник, который подключает для него в какую то невнянятую папку эту сетевую шару, при чем это сейчас. А чуть раньше он вообще лез на эту удаленную папку безо всякого mount. Ни скрипт запустить, ни программу какую использовать.

При чем и тогда и сейчас программа которая не знает от gvfs/kio не найдет где эти данные, которые она должна обработать. А если примонтировать вручную - не будут работать процессы с другим uid.

В результате ситуация когда снаружи, на десктопе, иллюзия того что сетевые и прочие диски подключаются «в один клик», внутри банальная невозможность с этими дисками работать без гуя.

То есть вместо систем действительно многопользовательской система расчитанная на то что к компутеру присобачен один монитор с клавой. И такая же ситуация например с флешками/сидиромами.

То есть логика работы в принципе не рассчитана на то что в системе одновременно могут быть залогинены два пользователя.

пардон, у меня щас моск не работает на такие длинные посты

~/mnt/mystorage - imho правильный unix-way для ФС монтируемых под конкретного пользователя и только для него. А монтироваться оне должны в логин-скриптах, и не факт что через fuse :)

~/mnt/mystorage - imho правильный unix-way для ФС монтируемых под
конкретного пользователя и только для него.

Ага. Ключевое слово «для ФС монтируемых для конкретного пользователя». Это не юниксвей. Это толпа десктоп-школьников и желание разрабов выпилить fs не как оно должно быть в юниксе, а как получится. Потому что ФС монтируемые только для конкретного юзера - это недоработка разработчиков сетевых fs в линуксе. которую к сожалению очень трудозатратно исправить по уму.

Я прекрасно помню времена когда не надо было ничего монтировать «для конкретного пользователя» а достаточно было смонтировать для системы. И конкретные пользователи прекрасно ходили через один mount-point

А монтироваться оне должны в логин-скриптах, и не факт что через fuse :)

Почему именно в логин скриптах. А если отвалится маунтпойнт? А если новые появятся диски?

Правильно монтировать в автомаунте... и нужно правильный код fs писать, что бы оно еще на отваливание точки нормально реагировало :D.

Почему именно в логин скриптах. А если отвалится маунтпойнт? А если новые появятся диски?

потому-что логин-скрипты и настройки конкретного юзера сидят в его каталоге (либо в LDAP), и логиниться юзер может на разные машины получая при этом свой любимый хомяк с привычно смонтированными внешними ресурсами.

потому-что логин-скрипты и настройки конкретного юзера сидят в его каталоге

Керберосу это не мешает. Как это собственно мешает брать их системным процессом, например сфоркнутым под этого юзера? Или можно класть необходимую часть настроек в какую то другую папку.

(либо в LDAP), и логиниться юзер может на разные машины получая при этом
свой любимый хомяк с привычно смонтированными внешними ресурсами.

А так он логинясь на любую машину получает /net где вся сеть уже привычно примонтирована. И все пути для всех скриптов и кастом-софта одинаковые. Грубо говоря /net/diskxxx/blender_render_spool/ одинаковый на любой машине для любого юзера.

А так он логинясь на любую машину получает /net где вся сеть уже привычно примонтирована. И все пути для всех скриптов и кастом-софта одинаковые. Грубо говоря /net/diskxxx/blender_render_spool/ одинаковый на любой машине для любого юзера.

и нафуя тогда изврат обозначенный в топике ?

...которые делают демультиплексинг по uid.

То есть пусть есть

/mnt/xxxfusefs

тогда юзер с uid 1 автоматически лезет на

/var/xxxfusefs/uid_1

а юзер с uid 2 попадает

/var/xxxfusefs/uid_2

и нафуя тогда изврат обозначенный в топике ?

Для того что бы хотя бы на скриптах можно было сделать хотя бы для одного диска «И все пути для всех скриптов и кастом-софта одинаковые. Грубо говоря /net/diskxxx/blender_render_spool/ одинаковый на любой машине для любого юзера. ».

Конечно хотелось бы описаный изврат, плюс автомаунтер который корректно с этим всем работает да еще и все это быстро как ххх, и настраивалось что бы просто и понятно, да еще всякого разного ... но я решил начать с более простого варианта :D

чот я не понял. А почему юзеры за /home/user вылазят? Зомби?

Грубо говоря /net/diskxxx/blender_render_spool/ одинаковый на любой машине для любого юзера. ".

~/XYZ_disk

~/XYZ_disk

Раскрытие тильды и $HOME вам гарантирует только шелл. Фейл.

чот я не понял. А почему юзеры за /home/user вылазят? Зомби?

У вас в /media например тоже только зомби лазают? ... понемаю.

плюс автомаунтер

автомаунтера который при системном вызове open(«/home/pupkin/x/y/z»..) разберётся что при необходимости надо прицепить к /home/pupkin/x внешнюю фс ftp://ftp.pupkin-vasya.ru/pub и только потом открывать файл, возможно кому-то нехватает. Но сомневаюсь, что в ядре linux такое вообще реализуемо. Это надо остановить вызывающий процесс, дать по шине команду некоему демону по стандартизованному протоколу, дождаться от него ответа, завершить-таки системый вызов и попутно отработать все ошибки, таймауты и отказы.

автомаунтера который при системном вызове open(«/home/pupkin/x/y/z»..)
разберётся что при необходимости надо прицепить к /home/pupkin/x внешнюю фс

Ээээ.... Вы описали функционал стандартного автомаунтера... :D

Это делает и amd и autofs - два стандартных автомаунтера в линуксе, amd вообще еще с юникс времен у Немет описан. У него только конфиг уж больно суровый - а так, неувядающая классика. Он емнип и демультиплексинг юзеров может... но я могу ошибаться.

Это надо остановить вызывающий процесс, дать по шине команду некоему
демону по стандартизованному протоколу, дождаться от него ответа,
завершить-таки системый вызов и попутно отработать все ошибки, таймауты и
отказы.

вово. вы описали autofs ... уже написан :D

amd работает выставляя локальный nfs сервер в качестве интерфеса к ядру.

Так как у нас сейчас есть fuse, эту часть, интерфейс к ядру, может делать она. Тогда правда это все будет тормозить, если гонять read/write через fuse ... что не очень удобно.

Раскрытие тильды и $HOME вам гарантирует только шелл

дык надо унифицировать путь до хомяка.

я вот так и не понял почему нельзя себе в хомяк монтировать папочки.

А то что это может не отвечать lsb... Да ну его нахер, там стока порожняка понавключали что я бы не стал по этому поводу заморачиваться.

дык надо унифицировать путь до хомяка.

У вас username меняется. Что $HOME/disk что /home/$USER/disk это в общемто побарабану: унифицируй - неунифицируй.

Тем не менее есть проблема которую так не решить принципиально - другие uid на этот эксклюзивный диск никто не пустит.

Грубо говоря банальный sudo make install уже с этйо шары не пройдет.

тебе надо чтобы все юзеры к одному диску получали доступ или что?

или разделить неймспейсы?

я вот так и не понял почему нельзя себе в хомяк монтировать папочки.

Что значит нельзя - можно конечно. Можно вообще виндовс использовать :D

Я про другое - фактически единственная сетевая FS в линуксе которая поддерживает описанный юзкейс (и не является чемто приделанным сбоку) сейчас это nfsv4 а она редкостный геморой в настройке. И далее ситуация будет усугублятся. Потому что явно проще написать код который монтирует fs для одного юзера эксклюзивно. Но это типичная багофича.

Так что ответом тут могут быть только всякие костыли. И лучше надежные, годные, крепкие костыли, чем их отсутствие :D

тебе надо чтобы все юзеры к одному диску получали доступ или что?

К одному mount point но со своими credentials.

Мне надо что бы, условно, для юзера и всех его программ (включая и запущенных из под su / sudo) директория /home/vasya/xxx/ ничем не отличалась бы от директории /home/vasya/exotic_network_share/ .

А еще лучше было бы иметь /net/ где директории ничем не отличаются от локальных, только являются сетевыми дисками подключенными с применением любых поддерживаемых сетевых протоколов и прозрачно для пользователя. С удобными настройками конкретики. Вплоть до того что по пути /n/ftp.server.ru/
для юзера без логина были видны только /n/ftp.server.ru/home/ftp/ , для юзера с логином появлялись /n/ftp.server.ru/home/* и все остальное, а для юзера у которого на этот сервер есть доступ через ssh или smb подключался именно он, вместо ftp. И это можно было бы динамически менять , ну и тп :D

Много хочу, да. :D

Собственно для этого есть не то что бы все, но почти все элементы - осталось их правильно увязать вместе, желательно без ядерных патчей и добится их надежной работы.

фактически единственная сетевая FS в линуксе которая поддерживает описанный юзкейс (и не является чемто приделанным сбоку) сейчас это nfsv4

так и непонятно зачем нужен описанный юзкейс. Как вы его описываете - это просто персональное пространство имён. Но оно уже есть и это нелюбимая вами тильда - воспринимайте её так.

так и непонятно зачем нужен описанный юзкейс.

Это не юзкейс, это так должны работать любые fs в юникс, есличо.

Как вы его описываете - это просто персональное пространство имён.
Но оно уже есть и это нелюбимая вами тильда - воспринимайте её так.

Если описать «как надо», так надо что бы mount и код в ядре подключали диски так, что бы сетевая FS сама проверяла можно ли пускать таких то юзеров на эту шару с этой mountpount, в зависимости от того ввел он правильно пароль или нет. И пускала тех юзеров что *свой* пароль к этйо шаре ввели правильно.

А я его описываю «не как надо» потому что понимаю, что пофиксить все сетевые fs так что бы они работали как надо, а не через одно место - нереально. Юзерская программа не должна ни в коем разе думать на тему того что «васе пишем через /home/vasya/pezdets_shara_xxx, а пете в /home/peotr/pezdets_shara_yyy но это на самом деле один диск». Это должна система думать об этом.

что бы сетевая FS сама проверяла можно ли пускать таких то юзеров на эту шару с этой mountpount, в зависимости от того ввел он правильно пароль или нет. И пускала тех юзеров что *свой* пароль к этйо шаре ввели правильно

вообще-то сетевым FS глубоко пофиг на расположение локального mountpoint (что правильно). А все прочие хотелки - исключительно вопросы авторизации. И все сетевые ФС так и работают, то есть пускают только тех у кого правильные credentials. Другой вопрос что местный юзер на удалённой системе может быть известен под другими(несколькими) именами и тогда без libastral последней сборки ни ядро ни автомонтёр не разберутся