Обмен файлами между Linux-машинами (отрезано)

[Davinel]

Ну сколько раз можно повторять: даже слабенькая машинка с полуторагигагерцевым процессором будет шифровать/дешифровывать данные быстрее, чем они способны будут считываться с диска и передаваться по сети. Для обычных компьютеров шифрование не является узким местом. Узкое место - крайне низкая скорость чтения/записи жестких дисков и передачи по сети. Вот если диски будут неколько гигабайт в секунду выдавать, а сеть будет оптоволоконной, то другое дело... Но, думаю, у такого компьютера и процессоры будут соответствующими - т.е. опять-таки, шифрование не будет являться узким местом.

Узким местом - нет. Но грузить процессор будет и довольно прилично, а компьютер таки довольно часто делает что то еще, кроме того, что просто копирует файлы.
К примеру при отсутствии аппаратного декодинга видео передача и просмотре его через ssh может означать неслабые тормоза.

"черный ящик" CIFS.

Почему это CIFS - черный ящик?..

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

Как я уже писал - nfs у меня уводил систему в кернел паник. Я НИКАК не могу назвать это "безопасным и стабильным" решением. И учитывая, что эта штуковина засунута в ядро - есть неплохой шанс что оно будет так делать при любой сколько нибудь серьезной ошибке.

С CIFS никакой глюков пока что не было вообще.

[Aviator]

Почему это CIFS - черный ящик?..

Потому, что хотя протокол частично и открыт, одна широко известная организация программирует реализацию за реализацией со значительными отклонениями от своих же документов. Поэтому, например, с PDC на самбе получается такое: то сетевые принтеры периодически "отваливаются" на XP/7 клиентах (угораздило же ж меня накатить на них хотфиксы, после них и началось, ладно, перебрался на IPP), то сетевые диски "вдруг" оказываются недоступны из-за того, что "невозможно считать права пользователя с контроллера домена", аналогично, перебрался на NFS. С клиентами на самбе, естественно, таких проблем не появляется. И вот получается, что самба используется только для авторизации пользователей, совмесно с OpenLDAP.

Как я уже писал - nfs у меня уводил систему в кернел паник. Я НИКАК не могу назвать это "безопасным и стабильным" решением. И учитывая, что эта штуковина засунута в ядро - есть неплохой шанс что оно будет так делать при любой сколько нибудь серьезной ошибке.
С CIFS никакой глюков пока что не было вообще.

Более 5 лет интенсивного использования NFS. Сейчас система на серверах - Debian Lenny, также Lenny и немного Squeeze на рабочих станциях.Kernel Panic за всё время использования, по вине NFS, не было ни разу.
Не осталось протокола паники? Хочется посмотреть.

[rm_]

Потому, что хотя протокол частично и открыт, одна широко известная организация программирует реализацию за реализацией со значительными отклонениями от своих же документов.

Забааавно, а не расскажете ли нам, что там с Керберос в этом плане, и сколько у него диалектов?)

[t.t]

Имеет смысл если необходимо безопасно передать информацию, в остальных случаях затраты на шифрование не оправданы.

Ну сколько раз можно повторять: даже слабенькая машинка с полуторагигагерцевым процессором будет шифровать/дешифровывать данные быстрее, чем они способны будут считываться с диска и передаваться по сети.

Я больше скажу: на кпк с arm 600 МГц при копировании по ssh через usb ни малейших тормозов ни разу замечено не было.

[Aviator]

Потому, что хотя протокол частично и открыт, одна широко известная организация программирует реализацию за реализацией со значительными отклонениями от своих же документов.

Забааавно, а не расскажете ли нам, что там с Керберос в этом плане, и сколько у него диалектов?)

Мимо тазика. Kerberos5 была принята в качестве стандарта IETF. Требования реализации протокола изложены в документах RFC1510 и RFC1964. Мало того, есть референсные дизайны Kerberos5, проблем с взаимодействием линуксовой и виндовой реализации не наблюдал, в отличие от самбы. До этого был Kerberos4, который и вышел на свет из недр MIT, т.е. началось широкое распространение. Результатом этого распространения стала 5-я версия стандарта.

[Bluetooth]

Как я уже писал - nfs у меня уводил систему в кернел паник. Я НИКАК не могу назвать это "безопасным и стабильным" решением. И учитывая, что эта штуковина засунута в ядро - есть неплохой шанс что оно будет так делать при любой сколько нибудь серьезной ошибке.

Честно говоря, частный баг возводить в степень правила - не очень, на мой взгляд.
Таким образом можно рассказать очень много страшных историй. Причем, для этих страшных историй не стоит в качестве основного предмета повествования брать что-то, что включено ядро. В качестве примера могу привести jack 2 ранней версии, запущенный в качестве демона от непривилегированного пользователя и при рестарте гарантировано приводящего к мгновенному ребуту машины

Потому, что хотя протокол частично и открыт, одна широко известная организация программирует реализацию за реализацией со значительными отклонениями от своих же документов. Поэтому, например, с PDC на самбе получается такое: то сетевые принтеры периодически "отваливаются" на XP/7 клиентах (угораздило же ж меня накатить на них хотфиксы, после них и началось, ладно, перебрался на IPP), то сетевые диски "вдруг" оказываются недоступны из-за того, что "невозможно считать права пользователя с контроллера домена",

Боюсь, вся проблема с закрытым быдлокодом в составе винды и с самбой никак не связано. На ум сразу приходят истории про "постучался вин хп сп2 на шару, к которой не было доступа на уровне ФС, вин ХП упала в БСОД".

[sash-kan]

Требования реализации протокола изложены в документах RFC1510 и RFC1964. Мало того, есть референсные дизайны Kerberos5, проблем с взаимодействием линуксовой и виндовой реализации не наблюдал, в отличие от самбы.

afaik, microsoft (как обычно) не придерживается стандартов и в этом случае — у неё имеется собственная реализация протокола kerberos, естественно, не полностью совместимая с rfc.