Перекодировка в Proftpd

[moonug]

Слушаем-с Samm.
Мастер-класс. (Если он таки не откажется)

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Samm]

1) Никакого мастер класса не будет. Патч я сделал, исключительно для тех, кто считает что чарсет в фтп нужен (зачем??) и кто при этом хоть немного вежливее админа этого сайта.
2) Патч был написан на коленке, тестровался минут 5, вроде работает. Никаких гарантий. По идее его можно допилить и отправить автору proftpd, я этим заниматься не хочу и не буду, так как считаю, что данное решение - кривое и неправильное. Есть множество протоколов с нормальной поддержкой кодировки в стандарте, юзайте их и будет вам счастье. Лицензия - BSD, т.е. делайте что хотите и не е..те мозг.
3) Протокол ftp говно.

Теперь об использовании - наложите патч, пересоберите proftpd, после чего добавляем в конфиг:

LocalCharset koi8-r
ClientCharset windows-1251

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

Ах, да, сам говнопатч: http://samm.kiev.ua/proftpd-iconv.diff

[moonug]

1) Никакого мастер класса не будет. Патч я сделал, исключительно для тех, кто считает что чарсет в фтп нужен (зачем??) и кто при этом хоть немного вежливее админа этого сайта.
2) Патч был написан на коленке, тестровался минут 5, вроде работает. Никаких гарантий. По идее его можно допилить и отправить автору proftpd, я этим заниматься не хочу и не буду, так как считаю, что данное решение - кривое и неправильное. Есть множество протоколов с нормальной поддержкой кодировки в стандарте, юзайте их и будет вам счастье. Лицензия - BSD, т.е. делайте что хотите и не е..те мозг.
3) Протокол ftp говно.

Теперь об использовании - наложите патч, пересоберите proftpd, после чего добавляем в конфиг:

LocalCharset koi8-r
ClientCharset windows-1251

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

Ах, да, сам говнопатч: http://samm.kiev.ua/proftpd-iconv.diff

Ты бы сам повежливей был. А так чему удивляешься?
За патч спасибо, проверим, допилим, отправим.
По поводу других протоколов: попробуй держать файлопомойку на http, или раздавать фильмы на нормальной скорости. У всего есть своя ниша. а проблема кодировок встречается не только у нас в стране.

[Samm]

Держу файлопомойку на http. nginx, причём по скорости и функционалу - в 100 раз лучше чем ftp.

На прошлой работе держал хранилище файлов на вебдав + apache + worker_mpm (в джейле) и тоже прекрасно работало. Там правда тоже есть проблемы с чарсетом, но там на 100% виновата винда, нарушающая стандарт. Лечится заменой на более умного клиента, я выбрал вебдрайв.

[Samm]

Кстати, скорость у nginx была выше, за счёт sendfile(). На гигабите при тестах было заметно.

[moonug]

Кстати, скорость у nginx была выше, за счёт sendfile(). На гигабите при тестах было заметно.

Дай сцылку почитать, я не слышал про такой тест .

[Samm]

тест я проводил, результаты не выкладывал

http://www.opennet.ru/base/net/tune_freebsd.txt.html - вот про sendfile и не только.

[moonug]

тест я проводил, результаты не выкладывал

http://www.opennet.ru/base/net/tune_freebsd.txt.html - вот про sendfile и не только.

Это я смотрел и читал.

[hizel]

ftp конечно говно, но замены в своем классе задач нет
вы еще вспомните, что и smtp тоже гавно
да и жезнь собстно - дерьмо

[Alex Keda]

у когонить пашет?
привернул к своему ftp - нифига - в кои8 выдаёт, хотя в конфиге задано

Код: Выделить всё

LocalCharset                    koi8-r
ClientCharset                   cp1251

вот патч для порта - мож чё не так сделал...
http://lissyara.su/patch/proftpd/proftp ... .utf8.diff
добавил в конце опцию ICONV...

[Samm]

2 lissyara
аська или жаббер есть?

[Samm]

А, ну да, нифига при configure не подцепилось. Щас поправим патч.

UPD: патч для порта @ http://samm.kiev.ua/proftpd.patch

[moonug]

А, ну да, нифига при configure не подцепилось. Щас поправим патч.

UPD: патч для порта @ http://samm.kiev.ua/proftpd.patch

Пасиб, щас срач на серваке разгребу, snort настрою и буду тестить.

[Alex Keda]

ещё не всё.
там баг про анонимоусов.
для регистреред пашет для анонимов - нет ))
========
;l`v

[Alex Keda]

http://lissyara.su/patch/proftpd/proftp ... .work.diff
релиз.
патч для порта.

[Alex Keda]

просьба установивших последнюю сссссылку отписаться о работе.
работает или нет ))

[Samm]

Зашибись!
Столько было воплей и соплей о том, какой нужный функционал, и при этом - ни одного репорта, кроме как от lissyara. Впрочем, учитывая что я и так убил на ненужную мне вещь достаточно много своего времени, я всёже решил довести работу до конца, попутно пофиксив 2 бага в proftpd. Подробности в http://bugs.proftpd.org/show_bug.cgi?id=3056 и http://sourceforge.net/mailarchive/foru ... oftp-devel . Кстати, если вам эта фича реально нужна - напишите это в комментах к багзилле, будет больше шансов увидеть в след. версии. PR пока отправлять не буду, во первых влом, во вторых хочу подождать реакции девелоперов. В связи с тем, что архив sf.net часто недоступен, делаю репост тут:

Hello.

First of all i want to thank all of the developers for the great work - as for me proftpd is one of the best ftp servers. I`m using it on most of my servers and very happy with it.

Latest version of the proftp includes some basic UTF-8 support. Unicode support is a very important for any countries with non-latin alphabets, but also in some countries non-unicode characters are still widely used. Also i found a bugs in the current implementation, so i decided to extend recoding support in the proftpd webserver. Now the patch is ready and tested, and I hope that it is possible to integrate it in the baseline, because this is a "must have" feature for countries like Japan, Russia or Ukraine. Here is a brief description of the patch:

1) It will fix current recoding (wrong arguments order in the iconv_open)
2) 2 new optional configuration settings added LocalCharset and ClientCharset.
LocalCharset allow us to override server charset (nl_langinfo is not reliable way in many cases)
ClientCharset allow us to use other than Unicode charset in the server output.

If ClientCharset is used and is not UTF-8, UTF8 will be removed from the FEAT output to avoid problems with RFC2460 compatible clients.

Also patch will fix some minor issues with utf8_init() trace, which was broken because this function was used before configuration file was processed.

More details and the patch itself are at http://bugs.proftpd.org/show_bug.cgi?id=3056 . I am ready to support this patch and i hope that it will be included in the feature releases of the ProFTPD.

With best regards,
Alex Samorukov

[Andy]

И все равно, спасибо большое за проделанную работу. Оставайтесь, пожалуйста, на сайте/форуме!

[Alex Keda]

нацарапал на кривом инглише, чё смог ))
правда, как-то не очень вышло...

[Samm]

Кстати, автор отозвался, и маленькая часть репорта (багфикс) уже в CVS. Также я думаю попытаться включить в baseline фикс для русской "я" в CP1251.
Чтобы понять суть проблемы я полез для начала в код proftpd и патч для исправления этой проблемы. Оказалось, что дело в том, что "я", имеет код 0xFF, который в свою очередь используется в протоколе TELNET (RFC854) как символ IAC

All TELNET commands consist of at least a two byte sequence: the
"Interpret as Command" (IAC) escape character followed by the code
for the command. The commands dealing with option negotiation are
three byte sequences, the third byte being the code for the option
referenced. This format was chosen so that as more comprehensive use
of the "data space" is made -- by negotiations from the basic NVT, of
course -- collisions of data bytes with reserved command values will
be minimized, all such collisions requiring the inconvenience, and
inefficiency, of "escaping" the data bytes into the stream. With the
current set-up, only the IAC need be doubled to be sent as data, and
the other 255 codes may be passed transparently.

При чём тут телнет, если мы говорим о FTP, спросите вы? А очень просто. RFC959 (FTP) чётко говорит о том, что

The File Transfer Protocol follows the specifications of the Telnet
protocol for all communications over the control connection. Since
the language used for Telnet communication may be a negotiated
option, all references in the next two sections will be to the
"Telnet language" and the corresponding "Telnet end-of-line code".
Currently, one may take these to mean NVT-ASCII and <CRLF>. No other
specifications of the Telnet protocol will be cited.

и там же

The Relationship between FTP and Telnet:

The FTP uses the Telnet protocol on the control connection.
This can be achieved in two ways: first, the user-PI or the
server-PI may implement the rules of the Telnet Protocol
directly in their own procedures; or, second, the user-PI or
the server-PI may make use of the existing Telnet module in the
system.
Ease of implementaion, sharing code, and modular programming
argue for the second approach. Efficiency and independence
argue for the first approach. In practice, FTP relies on very
little of the Telnet Protocol, so the first approach does not
necessarily involve a large amount of code.

Теперь, зачем же proftpd потребовался код IAC? Он его использует очень забавно - для того, чтобы сообщить что его имплементация телнета - ничего не умеет и ничего делать не будет, т.е. максимально тупой терминал. А именно - на все запросы типа WILL/WONT отвечает DONT и на DO/DONT - WONT. Ни 1 из известных мне ftp клиентов не пытается делать escape для 0xff и таким образом мы имеем то, что следующий за "я" символ воспринимается как как команда и благополучно глотается. Думаю, что этот кусок кода с WILL/WONT был сделан для каких-то очень старых и глючных терминалов или ftp клиентов. По крайне мере я таких не видел. Полагаю, что будет вполне уместно сделать setting вроде TelnetEmuDisable или как-то так, который позволит вырубать кусок кода связанного с IAC.

Впрочем, есть мнение, что отключение обработки IAC приведит к нарушению RFC:

4.1.2.12 Connections: RFC-959 Section 5.2

The words "and the port used" in the second paragraph of
this section of RFC-959 are erroneous (historical), and they
should be ignored.

On a multihomed server host, the default data transfer port
(L-1) MUST be associated with the same local IP address as
the corresponding control connection to port L.

A user-FTP MUST NOT send any Telnet controls other than
SYNCH and IP on an FTP control connection. In particular, it
MUST NOT attempt to negotiate Telnet options on the control
connection. However, a server-FTP MUST be capable of
accepting and refusing Telnet negotiations (i.e., sending
DONT/WONT).

DISCUSSION:
Although the RFC says: "Server- and User- processes
should follow the conventions for the Telnet
protocol...[on the control connection]", it is not the
intent that Telnet option negotiation is to be
employed.

Теперь перейдём от теории к практике. Я испытал 2 клиента для того на предмет обработки злосчастного символа 0xFF. Первым был FileZilla. Есть мнение, что всем известным ftp клиентам вообще наплевать на обработку IAC. По крайне мере ни FileZilla ни mc не посылают 0xFF два раза вместо одного. Более того, получая 1 0xFF они честно отрисовывают его как "я", а вовсе не переходят в режим control, как того требует telnet rfc. Причём в профтпд без cyrfix патча обработка символа 0xff соотв. RFC, т.е. два символа воспринимаются как 1. Хотя в отдаваемой им информации он тоже не ескейпит этот символ, таким образом также нарушая станарт.

Резюме: если сделать минификс к proftpd, заменяющий в control output 0xff на 0xff 0xff - не изменится ровным счётом ничего, так как клиенты всё равно эту часть стандарта не реализовали. А патч, отключающий процессинг IAC приведёт к нарушению сервером RFC. Наглядный пример к чему приводит игнорирование стандартов, а также добавление в RFC нафиг там ненужных вещей, вроде IAC процессинга.

[Alex Keda]

=========
багфиксы эт харашо...
Кстати народ - а чё никто не пишет в филезилле профтпд?
Всем действительно покласть на то - есть пеекодировка в нём или нет?
Когад у меня на фтп не было - много народу кричало, а как напсиать пару строк в поддержку этого - никого нет?

[schizoid]

я есть, но я еще маленький писать такие вещи... много чего не знаю и не умею

[Alex Keda]

ты накорябая как сожешь - что штука нужная, что реально нужна...

[Samm]

Патчи в CVS. Обращаю внимание, итоговая реализация отличается от моего патча. Вот выдержки из документации:

UseEncoding
Syntax: UseEncoding on|off|local-charset client-charset
Default: None
Context: "server config", <VirtualHost>, <Global>
Module: mod_lang
Compatibility: 1.3.2rc1

The UseEncoding directive is used to explicit configure which character sets should be used for encoding. By default, the mod_lang will automatically discover the local character set, and will use UTF8 for the client character set. The module will also allow the use of UTF8 encoding to be changed by clients using the OPTS UTF8 command (as per RFC2640). However, if the UseEncoding directive is explicitly used to indicate the character sets to use (or not use), then any OPTS UTF8 commands used by clients will be refused.

For example, to disable all use of encoding, use the following in your proftpd.conf:

UseEncoding off

Similarly, to enable use of UTF8 encoding and to not allow clients to change the use of UTF8, you would use:

UseEncoding on

In addition to the on|off parameters, the UseEncoding directive allows administrators to specify exactly which character sets to use locally (i.e. for paths on local disks) and for dealing with clients. One such usage this way might look like:

UseEncoding koi8-r cp1251

For a full list of the character sets which are supported, use:

$ iconv --list

Также была решена проблем с некорректной обработкой файлов содержащих русскую букву "я" в кодовой странице cp1251.
Подробнее о причинах и следствиях проблемы можно почитать выше, в этом треде. Для решение проблемы был сделан патч, отключающий процессинг символа IAC при использовании страницы cp1251.

- Bug 3064 - Better handling of 0xFF character for Cyrillic, non-UTF8 charsets.
These character sets use the same value as the Telnet IAC character in
the alphabet. RFC959 states that FTP control messages must support Telnet
characters; this requirement causes problems for the character sets.
This the RFC959 requirement is relaxed if --enable-nls is used, and if
one of the problematic character sets is configured.

P.S. От начала работы (2008-03-23) до сегодняшнего дня прошло куча времени и изначальный багрепорт превратился в 4
http://bugs.proftpd.org/show_bug.cgi?id=3056 (Support non-UTF8 encoding and character sets)
http://bugs.proftpd.org/show_bug.cgi?id=3059 (Wrong handling of UTF8 conversions)
http://bugs.proftpd.org/show_bug.cgi?id=3063 (proftpd fails to start if LC_ALL environment variable is wrong)
http://bugs.proftpd.org/show_bug.cgi?id=3064 (Better handling of 0xFF character for Cyrillic, non-UTF8 charsets)

[Alex Keda]

вах
значит скоро в портах будет.
туда кстати включили каку-то версию старого патча...