Re: [Sarlug] проблема с proftpd

["Nikolay Baranoff" <nicko4ever@gmail.com>]

2008/4/28 Evgeny Sinelnikov <sin@info.sgu.ru>:
>  #>  >  Отдавать в utf8 - наименее плохой вариант, но поскольку в стандарте
> #>  >  это не описано, лучше http.
>  #>  да, именно... но как тогда писать? как права на чтение ограничить?
>  И что получилось? Письмо из Простоквашино?
>  Ну, не очень-то корректно выдирать фразы из контекста...
Я ответил на вопрос "как права на чтение [с ftp] ограничить?":
>  >  Многие ftp-серверы имеют настройки т.н. upload folder, туда можно
>  >  записывать но читать оттуда нельзя. Используется для защиты от
>  >  китайских порно-ботов.
Видимо, актуально если выбрана схема ftp(прием файлов)+http(отдача).

>  >  >  с ftp они трудноустранимы? Не стоит кривить душой ради того, чтобы
>  >  >  поддержать любимую платформу...
>  >  Не стоит проецировать.
>  Провоцировать? Не стоит кричать, что всё круто, пока не удостоверился,
>  что предлагаемое подходит.
ПроЕцировать. В данном случае означает применять свою схему мышления
на других людей. Я не кривлю душой.
Насчет "подходит" - применение этого всего так толком описано не было.
Это к примеру может быть архив с варезами - тогда кириллица вообще не
нужна. Или хранилище персональных данных юзеров - тогда кодировку
можно на совести юзера оставить, в какой положил - в такой и читает.
Или средство для обмена файлами вида "один выложил - многие скачали.

>  >  >  В этом есть доля правды... вот только mount для sshfs не работает, по
>  >  >  умолчанию, есть некий fuse-
>  >  fuse-версия вполне хорошо работает. В ядре оно не нужно, я считаю.
>  Это кому как оно хорошо работает... Если для вас это хорошо, то я за
>  вас рад, но несколько сочувствую тем, кому вы попытаетесь такое вот
>  удобство предложить... Я про код этого чуда программной мысли вообще
>  молчу - вы его сами-то видели? Оно, по определению, работать хорошо не
>  умеет... Ну, файлики по сети в консоли между двумя линуксами, да -
>  передаст... Но мне тогда проще обычный scp или даже mc... Смысл в
>  такой файловой системе?
Ну я как бы через sshfs-mount смотрю HDTV. Никаких проблем при этом не
испытываю. Что я неправильно делаю?

>  Зато мнение имеете обо всём университете...
Вы, как я понял, имеете мнение обо всем Интернете...

>  >  Не нужно размахивать жупелом красноглазия.
>  Вы, я полагаю существенно отклонились от темы... Вопрос был в том, что
>  русские имена на ftp не работают... Кроме того, что не стоит для этого
Были предложены работающие варианты:
1) есть самба где они работают.
1.1) если самба не подходит, есть http
2) есть 2 способа их починить - кривой и некривой
2.1)криво - прибить гвоздями любую однобайтную кодировку. теряем все
что в нее не влезет
2.1.1)менее криво - прибить гвоздями юникод
2.2)не криво - поддерживаем rfc2640

>  вообще использовать ftp (это понятно, что ssh лучше). Но для клиентов
ssh лучше для не подготовленных дополнительно двух *nix машин, читайте
внимательнее.

>
>  Так вот... Сначала вы призываете использовать utf8, предлагая
utf8 - не моя прихоть, а стандарт.
>  повсеместно переходить на кучу непонятных софтин и известную
Непонятных, простите, кому? Мне вот все понятно.
>  filezilla. Потом заявляете, что на виндовых пользователей вам вообще
>  плевать... И кто из нас теперь троль?
А вот этого я не заявлял. Я лишь сказал, что не проводил большого
исследования виндовых ftp-клиентов потому что во-первых нашел как
минимум один удовлетворяющий моим нуждам и успокоился, а во-вторых -
для меня уже перестал быть актуальным поиск виндовых клиентов, просто
потому что негде стало их запускать.

>  А в итоге получается так, что вариантов на самом деле три + один (о
>  последнем ниже)...
>  1) найти патч для proftpd-1.3 и забыть про проблемы
>  Например, в ALT Linux уже давно готова сборка 1.3.0 с поддержкой iconv:
>  http://lists.altlinux.org/pipermail/sysadmins/2008-January/013143.html
Никто не спорит что это будет работать. Только нужно быть заранее
увереным, что никому не понадобятся символы, не являющиеся
подмножеством cp1251. А также что не появятся посетители, использующие
другую кодировку.

>  2) сделать маргинальный ресурс на utf8 и рассказывать всем, что юникод
>  рулит, а все удобные проги кривые...
А желания под браузер mosaic сайты затачивать не возникает?
Если софт не отвечает современным стандартам, от него избавляются.

>  3) забить на ftp и юзать sshfs или ещё что... Что предложите на винде?
SMB, очевидно.

>  Ну, вам-то вот теперь с Романом всё ясно, а люди по прежнему пытаются
>  понять, что же делать... Но это не важно, вам ведь на большинство из
Ну нет однозначного ответа, у каждого из них свои недостатки.
>  них плевать, поскольку у них винда... С другой стороны, будь у них
>  Linux, вам бы на них было также плевать, просто отговорки вы бы
>  находили другие...
Да чего уж мелочиться, я тот самый Bastard Operator From Hell и я
ненавижу юзеров лютой ненавистью. Так-то.

>  Теперь о плюс первом варианте... Начиная с версии 1.3.1 в proftpd
>  добавлена поддержка пресловутого rfc2640
>  http://www.proftpd.org/docs/modules/mod_lang.html
Слава б-гу.

>  Сборка с поддержкой этого решения (опция --enable-nls) отсутствует
>  даже в Fedora. Да и толку в нём пока не много. Ни один клиент, даже
>  lftp, не знает команды LANG, глубокий сакральный смысл которой для
>  меня пока остаётся загадкой ибо поддержки динамического
Оно скорее для выбора языка. A new command "LANG" is added to the FTP
command set to allow
   server-FTP process to determine in which language to present server
   greetings and the textual part of command responses.
>  перекодирования в этом релизе всё равно нет...
Динамическое перекодирование на сервере с поддержкой rfc2640 на обоих
концах не нужно. Ну а без rfc2640 валидны только 7-bit ASCII имена
файлов.
>
>  Я не знаю кому там, что стало теперь понятно, а мне стало ясно, что
>  использовать на практике rfc2640 довольно не просто. И уж конечно не
Дело клиента - сказать FEAT, услышать в ответ UTF8 и принимать имена в
соответствующей кодировке. Перекодировка, если нужна, проивзодится на
стороне клиента. Смысла при этом передавать данные в 1-байтной
кодировке - никакого.

>  Есть надежда, что более адекватным решением окажется proftpd-1.3.2,
>  где для модуля mod_lang заявлена поддержка опции UseEncoding... Вобще
>  этот тотже вариант 1, только узаконенный в виде модуля... Ибо клиентов
>  не быстро исправишь, а работать нужно прямо сейчас...
Я понимаю желание поддержать зоопарк клиентов, но многие из них
банально не поддерживаются и их невозможно поддерживать вечно.