Comments 64
О, вот это круто. Но не тормозит ли?
Помнится мне, я на винде ставил прогу, которая делает мне диск, подключаясь к серверу по sftp. И ещё пробовал прогу, которая делает ровно то же самое, но только по ftp.
Так вот, версия с sftp работала не очень сильно медленнее.
Я вот для себя сразу подумал, что можно как-нить повесить скриптик не эвент соединения с вайфай сетью. Если соединено с домашней сетью, подрубаться к домашнему серверу и всем инетным. Если с офисной — к тамошнему серверу.
А автоматический коннект можно отключить в таком варианте.
Помнится мне, я на винде ставил прогу, которая делает мне диск, подключаясь к серверу по sftp. И ещё пробовал прогу, которая делает ровно то же самое, но только по ftp.
Так вот, версия с sftp работала не очень сильно медленнее.
Я вот для себя сразу подумал, что можно как-нить повесить скриптик не эвент соединения с вайфай сетью. Если соединено с домашней сетью, подрубаться к домашнему серверу и всем инетным. Если с офисной — к тамошнему серверу.
А автоматический коннект можно отключить в таком варианте.
А ещё можно так же сделать автомонтирование офисных samba-шар.
А когда потеряли сеть, можно отключаться от всего ненужного.
А когда потеряли сеть, можно отключаться от всего ненужного.
а можно по-подробнее с момента «когда потеряли сеть»?
Я, конечно, нуб в линуксе, но у меня во всех дистрибутивах самба жутко виснет на пару минут при потере коннекта. Приложение, которое пытается хотя бы отобразить каталог в миднайт-командере, в котором есть отвалившаяся шара (т.е. не саму шару, а каталог, в который она подключена), не реагирует ни на kill, ни на что вообще. umount тоже тупит пару минут, только потом срабатывает. Если повезет.
Я пытался найти способ уменьшить этот таймаут, но безуспешно.
Написал тебе скрипты, которые пытаются нмапом найти на самбовый порт, в случае удачи монтируют нужные шары, в случае неудачи пытаются размонтировать. Но, во-первых, лаги, во-вторых, размонтируется через раз. Какая-то гномовская прослойка иногад виснет, и пока ее руками не убьешь, размонтировать не получится. Проблема не настолько для меня актуальна, чтобы копать дальше, но крайне неприятно.
Обязательно попробую то, что приведено в статье.
Я пытался найти способ уменьшить этот таймаут, но безуспешно.
Написал тебе скрипты, которые пытаются нмапом найти на самбовый порт, в случае удачи монтируют нужные шары, в случае неудачи пытаются размонтировать. Но, во-первых, лаги, во-вторых, размонтируется через раз. Какая-то гномовская прослойка иногад виснет, и пока ее руками не убьешь, размонтировать не получится. Проблема не настолько для меня актуальна, чтобы копать дальше, но крайне неприятно.
Обязательно попробую то, что приведено в статье.
> Но не тормозит ли?
Ничуть. Небольшая задержка ощущается только при подключении — то есть первом обращении. А потом разница между удаленными и локальными файлами не ощущается.
Можно и скриптик сделать — это надо смотреть ifup / ifdown скрипты.
Автоконнект хорош тем, что ему не важно где вы — если вам нужны ваши рабочие файлы — вы их получите. Иногда надо залезть на сервер из дома.
Ничуть. Небольшая задержка ощущается только при подключении — то есть первом обращении. А потом разница между удаленными и локальными файлами не ощущается.
Можно и скриптик сделать — это надо смотреть ifup / ifdown скрипты.
Автоконнект хорош тем, что ему не важно где вы — если вам нужны ваши рабочие файлы — вы их получите. Иногда надо залезть на сервер из дома.
всё же это зависит от мощности процессора на обоих сторонах канала… данные шифруются, а значит на это тратится процессорное время.
представьте ситуацию когда есть 20 клиентов и все активно пользуются файлсервером… нагрузка на процессор будет весьма и всесьма…
ведь как правило на файлсерверы не ставят высокопроизводительные процессоры.
представьте ситуацию когда есть 20 клиентов и все активно пользуются файлсервером… нагрузка на процессор будет весьма и всесьма…
ведь как правило на файлсерверы не ставят высокопроизводительные процессоры.
Само собой.
Поэтому и пишут, что не надо использовать sshfs для бакапов :)
А для «точечной» работы с файлами — самое оно.
Поэтому и пишут, что не надо использовать sshfs для бакапов :)
А для «точечной» работы с файлами — самое оно.
Если я правильно догоню — там на шифрование какое-то ограничение стоит… или еще что. В результате скорость не так чтобы очень.
6 гигов около часа копируются по локальной сети через sshfs
6 гигов около часа копируются по локальной сети через sshfs
Я тоже под Win пользовался www.expandrive.com/sftpdrive, она?
Под Lin тоже sshfs пользуюсь, но если честно, пока не напрягает набрать
Под Lin тоже sshfs пользуюсь, но если честно, пока не напрягает набрать
mount -a или вообще любой алиас назначить, НО пару раз действительно забывал подмонтировать перед запуском Eclipse (workspace тоже на сервере) и он сразу создавал новый локальный ;), после чего монтирование в непустую папку работает только с sshfs -o noempty. Так что спасибо за afuse, буду попробоватьsftpdrive не пробовал. Он вроде как платный?
Можно и mount -a, но я опсал как вынести всю эту рутину, чтобы она сама делалась.
Можно и mount -a, но я опсал как вынести всю эту рутину, чтобы она сама делалась.
SftpDrive да платный… но работает like a charm ;) a по поводу автоматизации я уже спасибо сказал.
Вспомнилось: у нас в давние времена один хороший человек написал shell гуй к RCS, дружественный такой, с русскоязычными менюшками и проч… так выросло целое племя «программистов», которые вообще не знали, что такое система контроля версий, при этом постоянно ею пользуясь ;)…
Вспомнилось: у нас в давние времена один хороший человек написал shell гуй к RCS, дружественный такой, с русскоязычными менюшками и проч… так выросло целое племя «программистов», которые вообще не знали, что такое система контроля версий, при этом постоянно ею пользуясь ;)…
О, схожая ситуация, скажи, ты работаешь с SVN или CVS в Eclipse? Если да, поделись опытом как отлаживая удаленно код чекаутить его в SVN? кроме как подключать удаленные ресурсы как локальные диски вариантов нет?
Репозиторий находится на совсем другом сервере (обычно) и если делать чекаут и отлаживаться на локальной машине то описанное в топике монтирование не нужно. Другое дело с удаленной разработкой: Eclipse умеет интегрировать с CVS/SVN только локальные проекты (имхо), поэтому тут как раз здорово выручает sshfs, выдавая удаленные по-сути файлы как локальные.
Можно наверное придумать и без sshfs путем публикации по (s)ftp после коммита в репозиторий, т.е. сначала идет фиксация в CVS/SVN а потом те же файлы заливаются на удаленный сервер для отладки — но честно даже не пробовал ;)
поддержка CVS в Eclipse интегрирована изначально, для SVN же использую допольнительный плагин. В появившихся перспективах CVS/SVN Repository Explorer добавляешь репозитории, и Eclipse в навигаторе проектов сам определяет наличие связи с репозиторием; проставляет напротив файлов проекта номера версии; а через пункт «Team» в контекстном меню файлов/каталогов, можно проводить привчные манипуляции с репозиторием.
Можно наверное придумать и без sshfs путем публикации по (s)ftp после коммита в репозиторий, т.е. сначала идет фиксация в CVS/SVN а потом те же файлы заливаются на удаленный сервер для отладки — но честно даже не пробовал ;)
поддержка CVS в Eclipse интегрирована изначально, для SVN же использую допольнительный плагин. В появившихся перспективах CVS/SVN Repository Explorer добавляешь репозитории, и Eclipse в навигаторе проектов сам определяет наличие связи с репозиторием; проставляет напротив файлов проекта номера версии; а через пункт «Team» в контекстном меню файлов/каталогов, можно проводить привчные манипуляции с репозиторием.
не знаю может ты говорил про другую утилиту, но я пользуюсь вот этим www.expandrive.com/sftpdrive
Суть проста, по SSH(SFTP) коннектится к удаленной машине и создает на локальной машине что-то виде сетевого диска. Посмотрел по скорости работает быстрее чем самба да и безопаснее чем самба через интернет :)
Может оффтом (простите), хочется заодно спросить:
Обычно я использовал WinSCP но тут понадобилось работать SVN на удаленной машине, т.е. разработка ведется удаленно, когда код доводится до стабильного состояния чекаутится в SVN. Другого способа не нашел :( если выкачивать репозитарий себе на комп, но его нельзя отлаживать (проект UNIXовый, локальная машина Windows). Может кто знает способы как еще можно работая на удаленном сервере (повторюсь, скрипты исполняются на UNIX машине), а разработку вести локально (Windows, Zend for Eclipse)?
Суть проста, по SSH(SFTP) коннектится к удаленной машине и создает на локальной машине что-то виде сетевого диска. Посмотрел по скорости работает быстрее чем самба да и безопаснее чем самба через интернет :)
Может оффтом (простите), хочется заодно спросить:
Обычно я использовал WinSCP но тут понадобилось работать SVN на удаленной машине, т.е. разработка ведется удаленно, когда код доводится до стабильного состояния чекаутится в SVN. Другого способа не нашел :( если выкачивать репозитарий себе на комп, но его нельзя отлаживать (проект UNIXовый, локальная машина Windows). Может кто знает способы как еще можно работая на удаленном сервере (повторюсь, скрипты исполняются на UNIX машине), а разработку вести локально (Windows, Zend for Eclipse)?
А чем плох вариант открыть в Zend по SFTP, или подмонтить папку с помощью Dokan SSHFS и открыть как локальный файл?
так и пользовался в Zend через SFTP но коммитеть файлы в SVN не получается (или не знаю как сделать, умею только потом зайти по SSH и выполнить команду коммита). Сейчас работаю в связки SFTPDrive + TurtoiseSVN + Zend но мне кажется, что наверняка есть более удобное средство, о котором я не просто не знаю.
а по поводу SSHFS — не всегда есть возможность договориться с провайдером поднять все нужные тебе службы, к тому же если провайдеров много
а по поводу SSHFS — не всегда есть возможность договориться с провайдером поднять все нужные тебе службы, к тому же если провайдеров много
C SVN очень удобно работать как svn+ssh — и аутентификация по ключу, и секурность — всё настраивается.
А вот если надо иметь доступ к удалённой ФС от рута, а по ssh надо сначала залогиниться от кого-нить другого, и только потом можно подняться с помошью su. В этом варианте как быть?
На многих системах вход рутом просто запрещен.
Но если очень надо, то можно разрешить в /etc/ssh/sshd_config:
PermitRootLogon yes
Но если очень надо, то можно разрешить в /etc/ssh/sshd_config:
PermitRootLogon yes
Сисадмины проклинают этот комментарий.
И я с ними согласен! Так делать не надо! Хоть возможность имеется.
UFO just landed and posted this here
— Под рутом не надо работать вообще. Этот аккаунт только для административных задач — что-то установить, подкрутить в системе и тп. Для этого есть sudo.
— Страшно небезопасно заходить рутом. Поэтому такой вход везде блокируется.
— Что будет в случае опечатки, ошибки и т.п. — под рутом вы можете сломать всю систему.
— А в данном случае — если вы ненароком удалите лишнее, то вы можете удалить все с удаленной системы — у вас же подмонтирован /!
— Страшно небезопасно заходить рутом. Поэтому такой вход везде блокируется.
— Что будет в случае опечатки, ошибки и т.п. — под рутом вы можете сломать всю систему.
— А в данном случае — если вы ненароком удалите лишнее, то вы можете удалить все с удаленной системы — у вас же подмонтирован /!
UFO just landed and posted this here
Вы просили рациональное объяснение — я вам его дал. Мое личное мнение — рутом ходить можно, только если у вас достаточно хорошо обеспечена безопасность всего остального — доступ на сервер хорошо ограничен с левых адресов и т.п.
Вообще, мы немного ушли в оффтоп — разговор был про работу с удаленными файлами как с локальными. Если вы удаленные хосты только админите, но не ведете никакую разработку на них, то для вас это совершенно неактуально.
Вообще, мы немного ушли в оффтоп — разговор был про работу с удаленными файлами как с локальными. Если вы удаленные хосты только админите, но не ведете никакую разработку на них, то для вас это совершенно неактуально.
Это не рациональное объяснение. С точки безопасности лично я никогда не видел разницы между входом под юзером + sudo и входом сразу под root.
Насчёт «под root работать не надо» — в этом есть здравое зерно — для тех кто не в состоянии себя контролировать и не делать под root то, что можно сделать под юзером. (Я лично себя контролирую хорошо, и без проблем делаю su — username когда зашёл по ssh как root но вижу что часть работы можно сделать от юзера.) Но суть в том, что PermitRootLogon no к этому отношения вообще не имеет и ничего не меняет (на серверах с этой глупостью я просто делаю sudo bash сразу после входа).
«Страшно небезопасно заходить рутом.» — улыбнуло. В «страшно» я ещё могу поверить, а вот «небезопасно» было бы неплохо обосновать.
«под рутом вы можете сломать всю систему» — безусловно. Только вот как этому может помешать PermitRootLogon no? Если приходится админить машину, значит приходится выполнять команды от root, и делает это в root shell или через sudo — вероятность ошибиться в команде и нечаянно угробить систему всегда существует.
«у вас же подмонтирован /» — этот пассаж я просто не понял. Связь между доступностью / и PermitRootLogon no от меня странным образом ускользает.
В общем, давайте честно признаемся, что это миф. Безопасность это не повышает. Разве что чисто психологически помогает. :) А вот что безопасность действительно повышает — это запрет входа по паролю. Если вход разрешён только с помощью ключей, то все брутфорсеры дружно идут лесом.
Насчёт «под root работать не надо» — в этом есть здравое зерно — для тех кто не в состоянии себя контролировать и не делать под root то, что можно сделать под юзером. (Я лично себя контролирую хорошо, и без проблем делаю su — username когда зашёл по ssh как root но вижу что часть работы можно сделать от юзера.) Но суть в том, что PermitRootLogon no к этому отношения вообще не имеет и ничего не меняет (на серверах с этой глупостью я просто делаю sudo bash сразу после входа).
«Страшно небезопасно заходить рутом.» — улыбнуло. В «страшно» я ещё могу поверить, а вот «небезопасно» было бы неплохо обосновать.
«под рутом вы можете сломать всю систему» — безусловно. Только вот как этому может помешать PermitRootLogon no? Если приходится админить машину, значит приходится выполнять команды от root, и делает это в root shell или через sudo — вероятность ошибиться в команде и нечаянно угробить систему всегда существует.
«у вас же подмонтирован /» — этот пассаж я просто не понял. Связь между доступностью / и PermitRootLogon no от меня странным образом ускользает.
В общем, давайте честно признаемся, что это миф. Безопасность это не повышает. Разве что чисто психологически помогает. :) А вот что безопасность действительно повышает — это запрет входа по паролю. Если вход разрешён только с помощью ключей, то все брутфорсеры дружно идут лесом.
> Насчёт «под root работать не надо» — в этом есть здравое зерно…
Еще бывают опечатки, западают кнопки на клаве и тп. — таким образом может запуститься не совсем то, что нужно.
> «Страшно небезопасно заходить рутом.»
Толпа китайских брутфорсеров круглые сутки подбирает пароли на серваки, root — один из самых популярных логинов. Если он заблокирован — то о впринципе ничего пдобрать не смогут. Логны остальных юзеров еще надо узнать — это чуть сложнее.
> Только вот как этому может помешать PermitRootLogon no?
Если вы зашли как юзер и сдалали su — то один фиг. Если зашли как юзер, и все административные действия вы предваряете sudo то это безопаснее. Например вам нжуно собрать прогу, нужен ли вам root для скачивания сорцов и компиления?
> «у вас же подмонтирован /»
Вы подмонтили удаленную систему и удалили точку монтирования. Что будет?
Еще бывают опечатки, западают кнопки на клаве и тп. — таким образом может запуститься не совсем то, что нужно.
> «Страшно небезопасно заходить рутом.»
Толпа китайских брутфорсеров круглые сутки подбирает пароли на серваки, root — один из самых популярных логинов. Если он заблокирован — то о впринципе ничего пдобрать не смогут. Логны остальных юзеров еще надо узнать — это чуть сложнее.
> Только вот как этому может помешать PermitRootLogon no?
Если вы зашли как юзер и сдалали su — то один фиг. Если зашли как юзер, и все административные действия вы предваряете sudo то это безопаснее. Например вам нжуно собрать прогу, нужен ли вам root для скачивания сорцов и компиления?
> «у вас же подмонтирован /»
Вы подмонтили удаленную систему и удалили точку монтирования. Что будет?
может запуститься не совсем то, что нужноИ как от этого спасает PermitRootLogon no?
Логны остальных юзеров еще надо узнатьА Вам не кажется странным, что, допуская возможность подбора пароля root, Вы надеетесь что логин/пароль обычного юзера будет подобрать сложнее? Во-первых надо ставить длинный случайный пароль, символов 10 минимум — пусть подбирают. Во-вторых у юзеров как раз обычно пароли проще, чем у root. В-третьих, как уже писалось выше, нужно заблокировать вообще доступ по паролям и использовать ключи (хотя бы только для root — см. PermitRootLogin without-password). В общем, проблема брутфорса действительно есть, она довольно просто решается, но PermitRootLogon no не является решением этой проблемы.
нужен ли вам root для скачивания сорцов и компиленияВ большинстве дистрибутивов — нет. И в этом случае можно либо зайти под юзером, либо из root сделать su — username на время выкачки/компиляции — PermitRootLogon no здесь при чём. А в Gentoo root нужен для запуска emerge, а дальше уже сам emerge автоматически переключается на непривелигерованный аккаунт «portage» на время выкачки/компиляции.
подмонтили удаленную системуМонтировать удалённую FS как (удалённый) root?! Жесть. Мне такое просто в голову не пришло.
Я научился тому, что под рутом не надо сидеть, когда опечатался, и вместо kill %1 получился kill 1. Итого — не отвечающий сервер, находившийся в тот момент не в дата центре, а в месте, где вообще никого не было ещё два дня :) И ребутнуть его было некому…
И далеко не для всех действий на сервере, даже если вы зашли туда именн для этого нужен рут. Поднять бд — не нужен, что-то там поделать с файлами, восстановить из бэкапов, заархивировать, поработать с логами — для всего этого рут не нужен. Я уж не говорю про такие вещи как ls и cd.
И далеко не для всех действий на сервере, даже если вы зашли туда именн для этого нужен рут. Поднять бд — не нужен, что-то там поделать с файлами, восстановить из бэкапов, заархивировать, поработать с логами — для всего этого рут не нужен. Я уж не говорю про такие вещи как ls и cd.
PermitRootLogin without-password
а стоит ли что-то поднимать? sftp по умолчанию работает с любым хостом, на котором открыт ssh.
Открываю в наутилусе sftp://server/path (на server у меня лежит мой ключ) и создаю закладку в панели.
Когда мне надо — щелкаю по закладке и всё.
Только gvfs с ssh глючит, зараза. За год пару раз код программ терял при записи :(
Когда мне надо — щелкаю по закладке и всё.
Только gvfs с ssh глючит, зараза. За год пару раз код программ терял при записи :(
Поэтому мне и не нравится GnomeVFS, что он привязан к гному. Хорошо бы, чтобы такое же поведение можно было инициировать из любой программы. Хоть их того же Эклипса.
Кстати, в моем варианте так же можно использовать наутилус — просто сделать в нем закладку на нужный файл, тогда все будет открываться точно так же.
Кстати, в моем варианте так же можно использовать наутилус — просто сделать в нем закладку на нужный файл, тогда все будет открываться точно так же.
Нужно настроить fuse на своем компе. И все.
Спасибо, не знал за afuse.
вопрос не несколько по теме и от совсем неспециалиста — как лучше/безопаснее/удобнее обмениваться файлами в windows-сетях, кроме как через «сетевое окружение»?
*«несколько не по теме», сорри
Если честно, я не спец по виндоус-сетям.
Очень многое зависит что и как вы будете оббменивать — одно дело, если фильмы, и совсем другое если нужен точечный доступ к файлам. Надо рассмотреть какие требования к безопасности вы выдвигаете: то ли это в локалке, то ли через интернет.
Очень многое зависит что и как вы будете оббменивать — одно дело, если фильмы, и совсем другое если нужен точечный доступ к файлам. Надо рассмотреть какие требования к безопасности вы выдвигаете: то ли это в локалке, то ли через интернет.
в описанной ситуации svn/git/mercurial/bzr etc кажется более разумным выбором
Одно другому не мешает :)
Эта конфигурация хороша, если вам надо править файлы локально, а запускать/тестировать/и т.п. удаленно.
Эта конфигурация хороша, если вам надо править файлы локально, а запускать/тестировать/и т.п. удаленно.
простите, а SVN разве не для этого предназначен?
Нет, для хранения ревизий. :) Это можно делать как удалено, так и локально.
Я немного про другое, дело не только в SVN, но и в других программах.
Например, я редактирую файл на ноуте под виндой, а компилирую на сервере под линуксом. Мне удобнее подправить файл, скомпилить его, прогать тесты, если есть баги — подправить, снова собрать, проверить. Когда все готово — закоммитить.
Я немного про другое, дело не только в SVN, но и в других программах.
Например, я редактирую файл на ноуте под виндой, а компилирую на сервере под линуксом. Мне удобнее подправить файл, скомпилить его, прогать тесты, если есть баги — подправить, снова собрать, проверить. Когда все готово — закоммитить.
Если надо редактировать файлы в Windows и дублировать изменения на unix, правильней будет другой подход.
Есть такая программа WinSCP — морда для putty, похожая на TotalComander, поддерживающая сессии от putty. У неё есть режим зеркалирования удалённой папки. На стороне windows наблюдение за измененями в файловой системе делается встроенными малозатратными механизмами (хуки вешаются), поэтому изменения подхватываются быстро. Файлы, которые дублировать не надо, можно отфильтровать — например, служебные файлы от subversion, бэкапные копии, временные файлы.
Плюсы — при падении сети файлы никуда не исчезают на обоих концах, достаточно сделать реконнект, часто без повторной синхронизации. Не надо делать дополнительных настроек на обеих машинах. При разработке совершенно прозрачно всё копируется. Естественно, копирование одностороннее, то есть править руками удалённую директорию не стоит — исправления будут убиты.
Есть такая программа WinSCP — морда для putty, похожая на TotalComander, поддерживающая сессии от putty. У неё есть режим зеркалирования удалённой папки. На стороне windows наблюдение за измененями в файловой системе делается встроенными малозатратными механизмами (хуки вешаются), поэтому изменения подхватываются быстро. Файлы, которые дублировать не надо, можно отфильтровать — например, служебные файлы от subversion, бэкапные копии, временные файлы.
Плюсы — при падении сети файлы никуда не исчезают на обоих концах, достаточно сделать реконнект, часто без повторной синхронизации. Не надо делать дополнительных настроек на обеих машинах. При разработке совершенно прозрачно всё копируется. Естественно, копирование одностороннее, то есть править руками удалённую директорию не стоит — исправления будут убиты.
Спасибо за интересное решение, а сколько времени проходит с момента изменения файла до момента срабатывания что файл реально изменился? в робокопи и других утилитах типа AllwaySync там время срабатывания мимум раз в минуту что достаточно долговато, когда отлаживаешь скрипт и сражу хочешь увидеть результат.
Срабатывание практически мгновенно. Windows, в отличии от Unix, имеет механизм, позволяющий перехватить операции с файлами или узнать об этих операциях — например, так работают антивирусные мониторы. В Linux надо периодически (например раз в минуту, где-то это называется poll) опрашивать директорию с файлом и смотреть, не изменился ли он, в Windows это не нужно, операционная система сама сообщает приложению в момент изменения. Поэтому и возможно мгновенно вызывать обновление на удалённом сервере.
Вы немного отстали: в линухе довольно давно есть механизм inotify.
Интересно, я только слышал о работах над ним но не знал что они завершились успешно. А есть софт, который использует inotify для мирроренья?
Вы имеете в виду что-то типа:
(пример из офф.доки inotify-tools) или вам нужен большой, сложный, коммерческий коробочный глючный продукт с красивым гуём? ;-)
#!/bin/sh
# A slightly complex but actually useful example
inotifywait -mrq --timefmt '%d/%m/%y %H:%M' --format '%T %f' \
-e close_write /home/billy | while read date time file; do
rsync /home/billy/${file} rsync://billy@example.com/backup/${file} && \
echo "At ${time} on ${date}, file ${file} was backed up via rsync"
done
(пример из офф.доки inotify-tools) или вам нужен большой, сложный, коммерческий коробочный глючный продукт с красивым гуём? ;-)
Скажем прямо, Ваш пример как раз и есть глючный. Например представьте, что в течении минуты будут изменены файлы в сотне разных директорий (что, к примеру, бывает при SVN commit). Что произойдёт? Можно сразу сказать — беда будет :) для обеих машин. Значит надо предусмотреть опции, надо предусмотреть методику их хранения и изменения, надо вести логи копирования… Надо подумать как не закрывать соединение с сервером. Много чего нужно для комфортной работы. Поэтому и возник у меня вопрос — есть ли готовый софт с функциональностью WinSCP? Кстати, rsync на виндусовых машинахимеет кучу проблем, начиная с поддержки ключей от putty и кончая зависаниями, так что и он не сильно поможет.
Во-первых это был пример, о чём там есть соотв. disclaimer.
Во-вторых, давайте не будем придумывать себе проблемы заранее. Я пока не вижу причины, по которой svn заливающий один за другим сотню файлов проблем не вызывает, а rsync параллельно с ним заливающий эти же файлы на другую машину, сразу всё положит, причём на обоих машинах.
В-третьих, если Вы хотите «всё продумать», «постоянное соединение» — продумайте, организуйте соединение, и немного скорректируйте приведённый выше пример для своих условий. Получится простое, понятное и управляемое решение с требуемым уровнем надёжности.
Во-вторых, давайте не будем придумывать себе проблемы заранее. Я пока не вижу причины, по которой svn заливающий один за другим сотню файлов проблем не вызывает, а rsync параллельно с ним заливающий эти же файлы на другую машину, сразу всё положит, причём на обоих машинах.
В-третьих, если Вы хотите «всё продумать», «постоянное соединение» — продумайте, организуйте соединение, и немного скорректируйте приведённый выше пример для своих условий. Получится простое, понятное и управляемое решение с требуемым уровнем надёжности.
По второму пункту: принципиальный недостаток — на каждое изменение запуск rsync — отсюда и проблемы с производительностью. Установка соединения ssh часто бывает медленной, так что сам процесс соединения может быть самой долгой операцией. Идеалом было бы установка соединения и чтение потока событий, вот такую программу было бы здорово найти.
Я смотрел в другую сторону насчёт использования inotify — файловые системы пользовательского уровня. Вроде есть такие, google на «inotify mirror» выдаёт много вариантов — но некоторые я посмотрел — в анонсах inotify есть, в исходниках нет, а тестировать некогда.
Нашёл даже inotify.aiken.cz/?section=incron&page=about&lang=en — «This program is an „inotify cron“ system. It consists of a daemon and a table manipulator. You can use it a similar way as the regular cron. The difference is that the inotify cron handles filesystem events rather than time periods.», она Ваш пример хорошо перекрывает, но это не совсем то что хотелось бы. Но для организации передачи небольших файлов через hot-directory (так это обычно называется в похожих программах) хорошо подходит.
Я смотрел в другую сторону насчёт использования inotify — файловые системы пользовательского уровня. Вроде есть такие, google на «inotify mirror» выдаёт много вариантов — но некоторые я посмотрел — в анонсах inotify есть, в исходниках нет, а тестировать некогда.
Нашёл даже inotify.aiken.cz/?section=incron&page=about&lang=en — «This program is an „inotify cron“ system. It consists of a daemon and a table manipulator. You can use it a similar way as the regular cron. The difference is that the inotify cron handles filesystem events rather than time periods.», она Ваш пример хорошо перекрывает, но это не совсем то что хотелось бы. Но для организации передачи небольших файлов через hot-directory (так это обычно называется в похожих программах) хорошо подходит.
В KDE для доступа к файлам по ssh есть kio slave fish (fish:/).
>После чего достаточно его запустить с нужными парамтерами:
>afuse -o mount_template=«sshfs %r:/ %m» -o unmount_template=«fusermount -u -z %m» ~/sshfs/
извиняюсь за занудство, но не могли бы Вы, пожалуйста, пояснить пару моментов по этой команде — буду очень благодарен:
>После чего все обращения к файлам и папкам в папке ~/sshfs/ будут вызывать монтирование соответствующей папки в ~/sshfs/
Монтироваться будут данные с server.ru? А если нужно монтирование с otherserver.ru? откуда команда afuse узнаёт, с какого именно сервера и от имени какого юзера монтировать ssh?
%r, я так понимаю, означает удалённый сервер, но как именно и откуда это значение будет подставлено во время выполнения команды?
P.S. пробежался по man'ам sshfs и afuse, но про существование переменных %r и %m ничего не нашёл.
P.P.S. как бы то ни было, за сам совет большое спасибо — давно знал про sshfs, да настроить всё никак руки не доходили, а вручную ssh'ем ходить надоело :-)
>afuse -o mount_template=«sshfs %r:/ %m» -o unmount_template=«fusermount -u -z %m» ~/sshfs/
извиняюсь за занудство, но не могли бы Вы, пожалуйста, пояснить пару моментов по этой команде — буду очень благодарен:
>После чего все обращения к файлам и папкам в папке ~/sshfs/ будут вызывать монтирование соответствующей папки в ~/sshfs/
Монтироваться будут данные с server.ru? А если нужно монтирование с otherserver.ru? откуда команда afuse узнаёт, с какого именно сервера и от имени какого юзера монтировать ssh?
%r, я так понимаю, означает удалённый сервер, но как именно и откуда это значение будет подставлено во время выполнения команды?
P.S. пробежался по man'ам sshfs и afuse, но про существование переменных %r и %m ничего не нашёл.
P.P.S. как бы то ни было, за сам совет большое спасибо — давно знал про sshfs, да настроить всё никак руки не доходили, а вручную ssh'ем ходить надоело :-)
Ааа… разобрался. afuse.sourceforge.net/ — в секции «Example Usage» объяснено, как монтирование происходит — оно осуществляется не после обращения к ~/sshfs, а после обращения к ~/sshfs/server.ru; т.е. если нужно подключиться к хосту server.ru, делаем, к примеру
> ls ~/sshfs/server.ru/home/user
а если к otherserver.ru то
> ls ~/sshfs/otherserver.ru/home/user
> ls ~/sshfs/server.ru/home/user
а если к otherserver.ru то
> ls ~/sshfs/otherserver.ru/home/user
Совершенно верно!
Обращение к серверу идет примерно так же как в scp.
Вы пишете scp user1@host.com:/home/user1/file.txt.
А здесь по аналогии:
cp ~/sshfs/user1@host.com:/home/user1/file.txt.
Второй вариант удобнее тем, что у вас после захода на сервер будет работать автодополнение в консоли. КРоме того, соединение устанавливается 1 раз — пароль нужно ввести всего 1 раз, дальше просто работать. Очень удобно, если вам нужно перекинуть несколько файлов.
Но с серверами, с которыми работаешь постоянно, надоедать писать полную строку обращения. И тогда можно сделать короткое имя, а основные парамтеры спрятать в ~/.ss/_config
Обращение к серверу идет примерно так же как в scp.
Вы пишете scp user1@host.com:/home/user1/file.txt.
А здесь по аналогии:
cp ~/sshfs/user1@host.com:/home/user1/file.txt.
Второй вариант удобнее тем, что у вас после захода на сервер будет работать автодополнение в консоли. КРоме того, соединение устанавливается 1 раз — пароль нужно ввести всего 1 раз, дальше просто работать. Очень удобно, если вам нужно перекинуть несколько файлов.
Но с серверами, с которыми работаешь постоянно, надоедать писать полную строку обращения. И тогда можно сделать короткое имя, а основные парамтеры спрятать в ~/.ss/_config
> а после обращения к ~/sshfs/server.ru
Я бы даже сказал после обращения к ~/sshfs/server.ru/ когда известно полное имя.
Я бы даже сказал после обращения к ~/sshfs/server.ru/ когда известно полное имя.
Я так и не понял, а под виндой к этой шаре можно подключаться, или SSHFS ета Linux онли?
Можно, я даже дал ссылку на программу для подключения: dokan-dev.net/en/download/
Ставите ее, настраиваете и у подключаете удаленный хост как новый диск.
Ставите ее, настраиваете и у подключаете удаленный хост как новый диск.
Спасибо! Как раз пригодилось
Sign up to leave a comment.
Удобный доступ к файлам на удаленных хостах