LINUX.ORG.RU
ФорумTalks

[NIH][Бред]Удаленное управление

 ,


0

0

В порядке бреда - а почему не написали демоны удаленного управления и удаленного доступа к файлам?

Вторая задача совсем простая - демон вроде SSH, но заточенный под доступ к файлам, ничего лишнего. И к нему клиентскую библиотеку, главная фича которой - совместимость по вызовам с функциями stdio и fcntl, но чтобы еще можно было написать fopen(«server://path/file»,«r»); opendir(«server://path/dir»); cwd(«server://path/dir») и даже cp server://path/dir/file/* /localpath/dir и т.п.? Можно даже исходить из предположения, что mmap необязателен... В принципе, вроде ничего невозможного нет - получится софтинка типа виндового редиректора, но более умный... И тогда можно будет даже без fuse обойтись.

Ну а демон управления чтобы работал по принципу snmp, gconf и интерфейса IOS - клиент цепляется к серверу, и запрашивает список доступных действий в данном контексте, для каждого действия сервер может выдать его описание и список параметров, если они есть. Клиент это визуализирует в гуе, и все щасливы. Для каждого дистрибутива можно написать плагин для демона, который будет управлять дистрибутивом по его правилам... Хотя, вот это то как раз можно сделать через DBus, наверное, только надо написать DBus-ный «сервер».

★★★★★

GVFS умеет такое. Общеиспользуемого универсального нет и не будет, потому что опенсорс - это вечный бардак и отсутствие стандартов.

anotheranonymous
()
Ответ на: комментарий от anotheranonymous

опенсорс - это вечный бардак и отсутствие стандартов

Душу согревает то, что в мире проприетарного софта бардак ещё страшнее =).

Deleted
()
Ответ на: комментарий от anotheranonymous

Почему? sftp в крусадере/конке очень даже хорошо организует доступ к файлам на любом ssh-сервере так, как будто это локальный каталог (то, что с этим может работать только kde-программы конечно напрягает, но по теме топика все это дело тоже каким-то образом внедрять в клиентов). Ну или fuse+ssh (наверняка есть и такое) тогда чем не подходит?

bender ★★★★★
()
Ответ на: комментарий от bender

>то, что с этим может работать только kde-программы конечно напрягает
Это не то что напрягает, это бредовая затея с самого начала, такие поделия надо давить в зародыше. GVFS прозрачно дает доступ через FUSE любой проге, хоть консольной, которая про этот самый GVFS и не слышала не разу.

anotheranonymous
()
Ответ на: комментарий от anotheranonymous

Только в твоих мечтах.

Да нет, в реальности.

Deleted
()

> клиентскую библиотеку, главная фича которой - совместимость по вызовам с функциями stdio и fcnt

Вообще таких велосипедов, перехватывавших иызовы libc, в древнелохматые времена было несколько.

получится софтинка типа виндового редиректора, но более умный...

Это вряд ли.

А кому и зачем это нужно, если уже есть sshfs?

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

>А cp, mv и ls тоже будем под GVFS переписывать? :-)
FUSE же. В ~/.gvfs все ресурсы сетевые видны прозрачно. А так, если что, у gvfs есть gvfs-copy, gvfs-move и gvfs-ls.

anotheranonymous
()
Ответ на: комментарий от tailgunner

>Вообще таких велосипедов, перехватывавших иызовы libc, в древнелохматые времена было несколько.
И ни один не стал стандартом. Fuck this shit.

А кому и зачем это нужно, если уже есть sshfs?

И как ты через него полезешь на cifs или nfs? И как его интегрировать в гуй? Каждой проге дергать sshfs?

anotheranonymous
()
Ответ на: комментарий от anotheranonymous

>>А кому и зачем это нужно, если уже есть sshfs?

И как ты через него полезешь на cifs или nfs?

Всегда подозревал, что толстые тролли тупы.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

anotheranonymous
()

Я конечно ничего не понимаю, но чем nfs не устраивает?

sin_a ★★★★★
()

ZFS имеет web-интерфейс управления, поддерживаемый специально запускаемым демоном.

iZEN ★★★★★
()

Мне тоже не понятно зачем обучать удаленному доступу каждую программу, если есть банальный mount

sdio ★★★★★
()
Ответ на: комментарий от iZEN

ZFS имеет ... когда в него встроят emacs новость напиши, ладно?

sdio ★★★★★
()
Ответ на: комментарий от sdio

>Мне тоже не понятно зачем обучать удаленному доступу каждую программу, если есть банальный mount
Ради уменьшения покраснения глаз.

anotheranonymous
()
Ответ на: комментарий от anotheranonymous

> велосипеды реализующие частности вроде подключения к ssh не нужны.

Бугага. Ты даже тупее, чем я думал. Не освоить понятие «монтирования ФС» - это не всякий сумеет.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Бугага. Ты даже тупее, чем я думал. Не освоить понятие «монтирования ФС» - это не всякий сумеет.
Школоло, такое школоло. Не смог ответить на простейшие вопросы, зато сопли пузырем.

anotheranonymous
()
Ответ на: комментарий от sdio

> Мне тоже не понятно зачем обучать удаленному доступу каждую программу

А не надо будет «учить каждую программу» - можно будет сделать ls -l ftp://servername://home/user и cp ftp://sitename/pub/images/pron.iso smb://dcserver/sharename/directory/dist.arj, и даже bash будет добивать табуляцией пути виа proto://host/path/file.ext

если есть банальный mount

Который может вызвать только банальный root, ага?

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от iZEN

> ZFS имеет web-интерфейс управления, поддерживаемый специально запускаемым демоном

Как мне через демон управления ZFS завести пользователя на убунте когда я сижу на федоре?

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

Если только файл с паролями переправить.

iZEN ★★★★★
()
Ответ на: комментарий от anotheranonymous

С этим полностью согласен; все усугубляется еще тем, что разработчики не собираются фиксить это в принципе. Кому интересно - бага висит еще с 2004го года: https://bugs.kde.org/show_bug.cgi?id=75324

Правда когда последний раз пробовал открыть odt-файл в OO.org из гномовского сетевого окружения по smb тоже ничего не получилось (в одной из бет 5го альта полгода назад примерно) - хотя очень сильно надеялся, что получится, т.к. как раз слышал, что гномовские виртуальные файловые системы как раз работают через fuse.

bender ★★★★★
()
Ответ на: комментарий от no-dashi

> Который может вызвать только банальный root, ага?

Не-а.

tailgunner ★★★★★
()
Ответ на: комментарий от anotheranonymous

> Не смог ответить на простейшие вопросы

Отвечать? Тебе? :D

зато сопли пузырем.

Ты так прикольно сердишься, дяденька... прямо как школьничег.

tailgunner ★★★★★
()
Ответ на: комментарий от no-dashi

>А не надо будет «учить каждую программу» - можно будет сделать ls -l ftp://servername://home/user и cp ftp://sitename/pub/images/pron.iso smb://dcserver/sharename/directory/dist.arj, и даже bash будет добивать табуляцией пути виа proto://host/path/file.ext

Похоже, что разработчики kde на что-то такое и надеются - внедрить url'ли в ядро системы. Интересно, сколько всего придется перепесать и поломать, чтобы это все заработало со всеми программами.

С другой стороны, почему бы не реализовать все тоже самое через fuse вида:
/universe/smb/servername1/path/to/file
/universe/smb/servername2/path/to/file
/universe/ssh/servername1/path/to/file
/universe/ssh/servername2/path/to/file

Каталог 2го уровня будет обозначать протокол, 3го - имя сервера, дальше файловая система. Подозреваю, что gvfs делает примерно тоже самое. Проблема только в том, чтобы автомонтирование пути происходило не только при обращении к gvfs из гуевой программы, а также при попытке набрать «ls /universe/smb/servername1» из консоли.

bender ★★★★★
()

>демон вроде SSH, но заточенный под доступ к файлам
Может, лучше слегка дописать autofs? Можно реализовать автомонтирование какой-нибудь /net/<proto>/<host>, при особом желании даже с опциями.

x3al ★★★★★
()
Ответ на: комментарий от bender

> С другой стороны, почему бы не реализовать все тоже самое через fuse вида:

/universe/smb/servername1/path/to/file

Ты не слышал ни об AFS, ни о Plan9? :)

Проблема только в том, чтобы автомонтирование пути происходило не только при обращении к gvfs из гуевой программы, а также при попытке набрать «ls /universe/smb/servername1» из консоли.

Разве у FUSE проблемы с автомнотированием?

tailgunner ★★★★★
()
Ответ на: комментарий от bender

>а также при попытке набрать «ls /universe/smb/servername1» из консоли.
Кстати вполне возможно такое провернуть. fusesmb что-то наподобие этого делает. Пишешь что нибудь cd ~/fusesmb/WORKGROUP/share и он лезет на этот сервер, даже если реально каталога этого нет. Но кроме этого нужна стандартизация всей этой ботвы, путей и прочего.

anotheranonymous
()
Ответ на: комментарий от no-dashi

>> если есть банальный mount

Который может вызвать только банальный root, ага?

У тебя на ту машину ssh есть? Для подключения sshfs банальный рут нужен? Интернет подсказывает что не нужен.

PS: кто нибудь знает, почему я от слова банальный на этом форуме вздрагиваю?

sin_a ★★★★★
()
Ответ на: комментарий от no-dashi

Если ты в системе настраиваешь автомонтирование то у тебя есть рут. А если есть рут, то зачем фузе?

sin_a ★★★★★
()
Ответ на: комментарий от x3al

> Можно реализовать автомонтирование какой-нибудь /net/<proto>/<host>

И с какой учетной записью ЭТО монтировать? А если у меня три юзера, и каждый из них хочет зайти на этот ресурс со своими правами? Так что ни одна system-wide технология не катит.

FUSE - попытка приплести ненужное здесь «монтирование», отсутствие кэша подключений и реквизитов для подключения; GVFS также не то - они строят свой новый юзерлэнд вокруг себя, что есть неправильно IMHO

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от sin_a

> Для подключения sshfs

Вы все русского языка не понимаете? Цель - избавиться от операции _монтирования_ удаленных ресурсов в дерево файловой системы. Вообще.

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

а зачем от нее избавляться, когда в ее абстракцию и так все эти сущности удаленных файловых систем прекрасно вписываются? С fuse я могу вообще не думать где находится файл и по какому протоколу к нему осуществляется доступ, могу сделать симлинк с локальной файловой системы на удаленную, могу иметь нужный мне удаленный каталог в любой точке файловой системы. После виндовых C:, D: и E: глобальная файловая система с одним корнем - верх логичности, простоты и гибкости - я не хочу все это видеть здесь обратно.

bender ★★★★★
()
Ответ на: комментарий от no-dashi

>> Можно реализовать автомонтирование какой-нибудь /net/<proto>/<host>

И с какой учетной записью ЭТО монтировать?

/net, благодаря поддержке namespaces, может относиться к разным сущностям для каждого пользователя. Это не говоря о том, что при желании можно монтировать в ~/fuse (не с текущим автомонтировщиком, но технически - вполне возможно).

GVFS также не то - они строят свой новый юзерлэнд вокруг себя, что есть неправильно IMHO

Тем не менее ты его строишь.

tailgunner ★★★★★
()
Ответ на: комментарий от anotheranonymous

>fusesmb что-то наподобие этого делает

Если не путаю с другой имплементаций самбы через fuse, то она монтирует в отдельный каталог сразу всю локальную сеть, а не каждую шару отдельно. Т.е. если мы натравливаем ее на каталог /mnt/smbfuse, то в этом /mnt/smbfuse она сама перечислит все рабочие группы и компьютеры в виде каталогов без необходимости прописывать в список монтирования каждый из них. По этой аналогии для текущей ситуации можно было бы написать модуль fuse, который бы рулил каталогом /universe, строил бы в нем подкаталоги второго уровня smb/ssh/http в зависимости от установленных в системе протоколов, а при обращении к ним уже бы вызывал соответствующий другой модуль fuse для монитрования шары по конкретному протоколу. Ну или выше упоминали уже какой-то autofs, который походу дела делает примерно тоже самое, не в курсе деталей.

bender ★★★★★
()
Ответ на: комментарий от bender

А если fusesmb не увидит шару (в подсети она другой, например). То можно ввести несушествуюший путь в точке монтирования fusesmb и он по ней полезет.

anotheranonymous
()
Ответ на: комментарий от no-dashi

> Цель - избавиться от операции _монтирования_ удаленных ресурсов в дерево файловой системы. Вообще.

Цель - обращаться с файлами на удалённой машине без затруднений. Так правильно?

Для этого можно:

А: обучить все программы работе с фалами по особенному, например через ftp, fish или придумать какой нибудь новый протокол.

Б: смонтировать удалённую ФС и просто обращаться к файлам.

Первое очевидно утопично

Во втором случае нам не нравится следующее:

1: необходимость иметь права root

2: необходимость совершать дополнительные действия.

Первое каким то образом обходится в современном гноме при подключении сетевой ФС, если не ошибаюсь это и называется fuse

Второе совсем обойти невозможно, как минимум нужно один раз внести запись в fstab. К минимуму второе сведено в autofs, там нужно только обратиться в нужному каталогу и если это возможно он будет смонтирован.

В связи с тем что nfs не всегда применимо, не все и не всегда раздают корень по nfs, можно подумать о сведении autofs и ssh.

И как оказалось, такое действительно существует:

http://wiki.archlinux.org/index.php/Autofs_(Русский)#.D0.A3.D0.B4.D0.B0.D0.BB...

Разве у FUSE проблемы с автомнотированием?

А ты попробуй. Пока что - да, проблемы

Так в чём именно?

sin_a ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.