The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз ftp-сервера ProFTPD 1.3.5

16.05.2014 11:55

После двух с половиной лет разработки увидел свет новый значительный выпуск ftp-сервера ProFTPD 1.3.5, сильными сторонами которого являются расширяемость и функциональность, а слабыми - недостаточное внимание к качеству и безопасности кода. Одновременно доступен корректирующий выпуск ProFTPD 1.3.4e, который станет последним в серии ProFTPD 1.3.4.

Основные новшества ProFTPD 1.3.5:

  • Новые модули:
    • mod_dnsbl для ограничения доступа по черным спискам, опрашиваемым через DNS (DNSBL);
    • mod_snmp для накопления различной статистики и предоставления доступа к ней через протокол SNMP (поддерживается SNMPv1 и SNMPv2);
    • mod_log_forensic для сбора данных о действиях пользователя в рамках установленного сеанса, но сброса данной информации в лог только при выявлении необычной активности;
    • mod_rlimit - в отдельный модуль вынесен код для задания лимитов через директивы RLimitCPU, RLimitMemory и RLimitOpenFiles;
    • mod_geoip для получения информации о местоположении пользователя по его IP-адресу. На основе полученных данных могут быть созданы фильтры (например, можно запретить доступ из отдельных стран) или просто добавлена информация в лог.
  • Новые директивы конфигурации
    • LDAPLog для сохранения лога работы mod_ldap в отдельном файле;
    • RLimitChroot для включения дополнительных ограничений на запись в директории /etc и /lib внутри chroot-окружения с целью защиты от атак по организации загрузки фиктивных библиотек.
    • SQLUserPrimaryKey и SQLGroupPrimaryKey (mod_sql) для определения первичных ключей для хранимых в SQL таблиц с пользователями и группами;
    • AllowChrootSymlinks для запрета следования символическим ссылкам при переходе в chroot;
    • CapabilitiesRootRevoke для выборочного сброса root-привилегий при использовании модуля mod_cap;
    • IfAuthenticated для задания набора директив, применяемых только к сеансам с аутентифицированным пользователем;
    • FactsOptions для тонкой настройки MLSD/MLST-вывода модуля mod_facts;
    • QuotaDefault для задания квоты по умолчанию, применяемой модулем mod_quotatab если квота для пользователя явно не определена;
    • RewriteMaxReplace для ограничения максимального числа замен в mod_rewrite;
    • TLSServerCipherPreference для расстановки приоритетов в выборе шифров при использовании mod_tls;
    • В директиве ExecOnEvent добавлена поддержка флага "~" при указании которого команда исполняется с правами вошедшего пользователя. ExecOnEvent также теперь допустимо использовать внутри блоков VirtualHost;
    • В директиву SFTPOptions добавлена опция IgnoreSCPUploadTimes для запрета изменения времени модификации и создания файлов;
    • В директиву SFTPOptions добавлена опция AllowInsecureLogin для принудительного включения поддержки небезопасных алгоритмов шифрования в mod_sftp, используемых в тестовых целях. Например, без использования "SFTPOptions AllowInsecureLogin" mod_sftp не работает при указании 'none' в SFTPCiphers и SFTPDigests;
    • В директивы AllowFilter и DenyFilter добавлена поддержка флагов "[NC]" и "[nocase]" для игнорирования регистра символов. Например: "AllowFilter \\.html [NC]";
    • Для директивы CreateHome представлена опция NoRootPrivs для создания домашних директорий без использования root-привилегий (например, для решения проблем с NFS);
    • В RewriteCondition и RewriteRule добавлена поддержка переменных, содержащих время;
    • В RootRevoke добавлена опция "UseNonCompliantActiveTransfers", позволяющая сбросить root-привилегии, но сохранить возможность прикрепления к привилегированному порту для обеспечения работы активного режима FTP;
    • В директиве SFTPDigests обеспечена поддержка хэшей SHA-256 и SHA-512;
    • В SocketOptions добавлен параметр "keepalive", позволяющий управлять включением TCP keepalive;
    • В директивах VirtualHost, MasqueradeAddress и DefaultAddress теперь можно указывать имя сетевого интерфейса, а не только имя хоста или IP-адрес;
  • Добавлена поддержка команды SSCN FTP для организации безопасной передачи данных между серверами (site-to-site, FXP);
  • Обеспечена корректная работа конфигураций с TLS 1.1/1.2;
  • Изменён формат вывода времени в логах, который теперь соответствует спецификации ISO-8601. Например, вместо "Jan 31 15:33:03" теперь указывается "2013-01-31 15:33:03,832";
  • В утилиту ftpasswd добавлена поддержка хэшей SHA-256 и SHA-512, обеспечена возможность блокирования аккаунтов (--lock/--unlock);
  • Изменён метод обработки команд PORT и EPRT, адреса в которых теперь проверяются на вхождение в список непубличных подсетей (10.x.x.x, 192.168.x.x и 172.16.x.x), определённый в RFC 1918. Запросы с такими адресами теперь игнорируются и вместо них используется IP с которого поступил запрос;
  • В модуле mod_sql_passwd добавлена поддержка алгоритма хэширования PBKDF2. Управление производится через директиву SQLPasswordPBKDF2;
  • В модули mod_sftp и mod_tls добавлена поддержка методов шифрования по эллиптическим кривым (Elliptic Curve, ECDSA, ECDH). Обеспечена возможность аутентификации отдельных пользователей по цифровым сертификатам без пароля (директива TLSUserName).
  • В mod_sftp добавлена поддержка SFTP-расширения "fsync@openssh" (включается через SFTPExtensions fsync) для обработки клиентских запросов на принудительный сброс буферов.


  1. Главная ссылка к новости (http://www.proftpd.org/...)
  2. OpenNews: Релиз ftp-сервера ProFTPD 1.3.4 и 1.3.3g с устранением критической уязвимости
  3. OpenNews: Взлом сервера проекта ProFTPD привел ко внедрению бэкдора
  4. OpenNews: Вышел ftp-сервер ProFTPD 1.3.3
  5. OpenNews: Протоколу FTP исполнилось 40 лет
  6. OpenNews: Релиз FTP сервера vsftpd 3.0.0 с поддержкой нового sandbox-режима
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/39785-proftpd
Ключевые слова: proftpd
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, rob pike (?), 12:04, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интресно, где сейчас массово востребован FTP?

    На всякий случай - кроме shared hosting-ов с PHP.

     
     
  • 2.5, Аноним (-), 12:18, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Многие конторы используют FTP-серверы в качестве инструмента для обмена файлами с внешними контрагентами.
     
     
  • 3.15, Труповращатель (?), 13:35, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Бюстгальтерия, одножопа, медок, клиентбанки, клиентбутылки и т.п.
     
     
  • 4.20, chupnik (ok), 14:29, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А расшифровать можно, что есть медок и клиентбутылки?
     
     
  • 5.23, Аноним (-), 15:28, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Видимо, клиент-банки с узким в^H горлышком.
     
  • 3.46, Аноним (-), 21:07, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > в качестве инструмента для обмена файлами с внешними контрагентами.

    А не проще HTTP? Он через любые фаеры пролазит, в отличие от.

     
  • 2.6, FSA (??), 12:28, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не поверишь, но много кто использует. Ибо проще всего объяснить планктону как что-то туда закачать/скачать оттуда. К тому же альтернативы не всегда хорошо работают. Я, например, файлы на php shared хостинг закачиваю обычно через ssh. Это заметно медленнее, чем по ftp. Но мне лень каждый месяц менять пароль, поэтому я просто использую ключ для ssh, который не нужно менять.
     
     
  • 3.13, angra (ok), 13:33, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А почему ssh медленнее? Помню еще лет восемь назад экспериментировали в локалке на офисных машинах и оверхед от шифрования был в пределах погрешности.
     
     
  • 4.26, vlikhachev (ok), 15:51, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > А почему ssh медленнее? Помню еще лет восемь назад экспериментировали в локалке
    > на офисных машинах и оверхед от шифрования был в пределах погрешности.

    Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.
    Впрочем, в виндовой офисной локалке (т.е. у безруких одминов) сеть обычно настолько нетороплива, что не позволит этого увидеть. То есть лимитирует скорость приема/записи (виндового) сервера, а не скорость ssh/ftp.
    У меня до 3 МБайт/с ssh и до 25-30 МБайт/с ftp по гигабитной локальной сетке.

     
     
  • 5.29, PnDx (ok), 16:45, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
      Сморозил. ssh pipe 40-50 MB/s по гигабиту, с упором в cpu (blowfish).
    Дай угадаю, "3 МБайт/с" - это винда + winscp?
     
     
  • 6.47, Аноним (-), 21:08, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Дай угадаю, "3 МБайт/с" - это винда + winscp?

    Да знаешь, шифровать гигабит может поднапрячься и не только винда. Какой-нибудь ноут на атоме поднапряжется гигабит шифровать и так и сяк.

     
  • 5.36, Аноним (-), 17:35, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.

    Ты этим больше не ширяйся! Не менее ваш, Ваш К.О.

     
  • 5.41, Аноним (-), 19:34, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.

    Совсем не капитан, ты что, данные перед шифрованием в Base64 перегоняешь, а после шифрования поток ещё раз в Base64 ? :)

    PS Лучшего объяснения не придумал, как траффик в 3 раза увеличить. :)

     
  • 5.43, angra (ok), 20:07, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну разве я виноват, что у вас руки из задницы растут? Две линуксовые машины, 100mb сетка, scp:

    100%   93MB  10.3MB/s   00:09

    real 0m8.604s
    user 0m2.309s
    sys 0m0.467s

    Чуть не забыл. Одной из машин уже семь лет, то есть даже древний атлончик не является проблемой. В качестве пробных данных было видео, то есть несжимаемый контент.

     
     
  • 6.48, Аноним (-), 21:09, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > 100%   93MB  10.3MB/s   00:09

    А теперь на гигабите, плиз :)

     
     
  • 7.53, Аноним (-), 03:29, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А у тебя есть гигабитные каналы хотябы до Германии?
     
     
  • 8.58, Аноним (-), 06:47, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    для гигабитных каналов ssh патчат hpn патчами ... текст свёрнут, показать
     
     
  • 9.71, Michael Shigorin (ok), 19:03, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Во, спасибо -- запамятовал уже имечко ... текст свёрнут, показать
     
  • 8.62, Аноним (-), 21:53, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    У меня есть гигабитная локалка ... текст свёрнут, показать
     
  • 7.59, Xaionaro (ok), 11:24, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Человек сказал, что трафик возрастает втрое. А следующий человек это опроверг. Причём тут гигабит вообще?
     
     
  • 8.63, Аноним (-), 21:54, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    При том что в гигабитной локалке шифрование очень все тормозит и сильно грузит м... текст свёрнут, показать
     
     
  • 9.74, Xaionaro (ok), 10:14, 19/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И кто мешает отключить это шифрование Более того, то не ответ Трафик втрое не ... текст свёрнут, показать
     
  • 7.76, Аноним (-), 17:56, 19/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> 100%   93MB  10.3MB/s   00:09
    > А теперь на гигабите, плиз :)

    А что вы лыбитесь, думает что-то другое будет?

    % time scp foo.MP4 xxx:/dev/null
    foo.MP4                   100%  957MB  50.4MB/s   00:19    
    scp foo.MP4 xxx:/dev/null  2.93s user 1.36s system 21% cpu 19.684 total

    Это древний core2duo, и канал, как вижно, забит чуть менее чем полностью.
    В домашней локалке под i7 scp работает со скоростью канала и не создаёт нагрузки на CPU вообще.

     
  • 5.56, dal (?), 03:38, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> А почему ssh медленнее? Помню еще лет восемь назад экспериментировали в локалке
    >> на офисных машинах и оверхед от шифрования был в пределах погрешности.
    > Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в
    > 3 раза... Ваш К.О.
    > Впрочем, в виндовой офисной локалке (т.е. у безруких одминов) сеть обычно настолько
    > нетороплива, что не позволит этого увидеть. То есть лимитирует скорость приема/записи
    > (виндового) сервера, а не скорость ssh/ftp.
    > У меня до 3 МБайт/с ssh и до 25-30 МБайт/с ftp по
    > гигабитной локальной сетке.

    Обычно скачиваю сжатые файлы со скоростью 9-10 MB/s по uplink 100Mb/s используя scp, без тюнинга, железо правда минимум E3-1230:)

     
  • 5.70, Michael Shigorin (ok), 18:59, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.

    Даже если Compression yes или это был вообще rsync?  Да и без них неочевидно, мягко говоря.

    > У меня до 3 МБайт/с ssh и до 25-30 МБайт/с ftp по гигабитной локальной сетке.

    Это процессоры/диски древние или локалка такая.  На хорошем процессоре пятилетней давности 50+ MB/s по гигабиту мне ssh даёт без каких-либо ухищрений.

     
  • 5.75, Аноним (-), 17:44, 19/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому, что трафик при передаче через ssh (scp, sftp) возрастает примерно в 3 раза... Ваш К.О.

    Капитан олигофрен, вы ли это? Гнусная ложь, ничего там не возрастает. Только CPU time на шифрование, которое на компьютерах выпущенных в этом веке заметить очень сложно, особенно с учётом aesni и друзей.

     
  • 4.30, rob pike (?), 17:02, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    http://www.psc.edu/index.php/hpn-ssh
    http://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers-fast/
     
  • 3.14, hshhhhh (ok), 13:34, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • –5 +/
    а почему вы не делаете это через git как все нормальные люди? :)
     
     
  • 4.21, angra (ok), 14:53, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Наверное потому, что git это всего лишь одна из многих систем контроля версий, а не протокол передачи файлов по сети. При этом решения на базе git умеют взаимодействовать с различными протоколами передачи, например с ssh, что вводит недалеких людей в заблуждение и они искренне считают, что передают файлы на сервер при помощи git.
     
     
  • 5.72, Michael Shigorin (ok), 19:05, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Наверное потому, что git это всего лишь одна из многих систем контроля
    > версий, а не протокол передачи файлов по сети.



    $ grep ^git /etc/services
    git             9418/tcp                        # git pack transfer service
    git             9418/udp                        # git pack transfer service


     
  • 4.42, Аноним (-), 19:37, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так и представляю: корпоративная сетка, офис предприятия, планктон и Git :))
     
     
  • 5.64, Аноним (-), 21:55, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > планктон и Git :))

    На гитхаб давно заглядывал? А то я видел как корпоративный манагер чертыхался, скрипел, но осваивал южеж git. Потому что партнеры выложили файло именно туда и иззъявили желание версионировать все через git. Бывает и вот так...

     
  • 3.27, XoRe (ok), 16:05, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Не поверишь, но много кто использует. Ибо проще всего объяснить планктону как
    > что-то туда закачать/скачать оттуда. К тому же альтернативы не всегда хорошо
    > работают. Я, например, файлы на php shared хостинг закачиваю обычно через
    > ssh. Это заметно медленнее, чем по ftp. Но мне лень каждый
    > месяц менять пароль, поэтому я просто использую ключ для ssh, который
    > не нужно менять.

    scp, sftp ?

     
     
  • 4.28, YetAnotherOnanym (ok), 16:35, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > scp, sftp ?

    УебДАВ?

     
     
  • 5.68, XoRe (ok), 14:20, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> scp, sftp ?
    > УебДАВ?

    Очень на любителя.

     
  • 3.55, dal (?), 03:33, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Не поверишь, но много кто использует. Ибо проще всего объяснить планктону как
    > что-то туда закачать/скачать оттуда. К тому же альтернативы не всегда хорошо
    > работают. Я, например, файлы на php shared хостинг закачиваю обычно через
    > ssh. Это заметно медленнее, чем по ftp. Но мне лень каждый
    > месяц менять пароль, поэтому я просто использую ключ для ssh, который
    > не нужно менять.

    Попробуйте отключить шифрование контента при передаче по scp. Ваш КО.

     
  • 2.12, angra (ok), 13:31, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    При всей моей нелюбви к этому протоколу мне не приходит в голову замена в пределах его ниши. Другое дело, что он зачастую применяется там, где есть более удачные решения.
     
  • 2.18, ALex_hha (ok), 14:06, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Интресно, где сейчас массово востребован FTP?
    > На всякий случай - кроме shared hosting-ов с PHP.

    сабж и sftp поддерживает, что очень удобно

     
     
  • 3.22, angra (ok), 14:55, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вы случаем не путаете sftp с ftps?
     
     
  • 4.24, Аноним (-), 15:31, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы случаем не путаете sftp с ftps?

    Нет.

     
     
  • 5.37, Аноним (-), 17:36, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вы случаем не путаете sftp с ftps?
    > Нет.

    да.

     
  • 4.67, ALex_hha (ok), 12:25, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы случаем не путаете sftp с ftps?

    случаем не путаю

    LoadModule mod_sftp.c
    LoadModule mod_sftp_pam.c

    SFTPEngine on
    SFTPLog /var/log/proftpd/sftp.log
    TransferLog /var/log/proftpd/xferlog-sftp.log

    Port 2121
    SFTPHostKey /etc/ssh/ssh_host_rsa_key
    SFTPHostKey /etc/ssh/ssh_host_dsa_key
    SFTPAuthorizedUserKeys file:~/.sftp/authorized_keys
    SFTPCompression delayed
    MaxLoginAttempts 3

     
  • 4.69, XoRe (ok), 14:24, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы случаем не путаете sftp с ftps?

    http://ru.wikipedia.org/wiki/SFTP - дополнение к SSH
    http://ru.wikipedia.org/wiki/FTPS - дополнение к FTP

     
  • 2.34, вы все ламеры (?), 17:29, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Интресно, где сейчас массово востребован FTP?
    > На всякий случай - кроме shared hosting-ов с PHP.

    в моем случае ftp - единственное что полностью утилизирует гигабитный канал. ни sftp, ни nfs, ни cifs даже половины скорости ftp не выдают.

     
     
  • 3.52, Ytch (ok), 01:27, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    в моем случае (внутри локалки) - основное достоинство, что поддерживается "искаропки" во всех используемых системах и не требует ничего ставить/настраивать. особенно актуально за пределами своего подразделения - уж "у себя"-то ЕСТЬ множество способов как обменяться файлами, в зависимости от назначения обмена, но для разового обмена временными и/или не очень служебными файлами используем тот же ftp. Да и через корпоративные политики и прибамбасы пролезает нормально.
     
     
  • 4.60, arisu (ok), 15:03, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > в моем случае (внутри локалки) - основное достоинство, что поддерживается "искаропки" во
    > всех используемых системах и не требует ничего ставить/настраивать. особенно актуально
    > за пределами своего подразделения - уж "у себя"-то ЕСТЬ множество способов
    > как обменяться файлами, в зависимости от назначения обмена, но для разового
    > обмена временными и/или не очень служебными файлами используем тот же ftp.
    > Да и через корпоративные политики и прибамбасы пролезает нормально.

    прочитал. возрыдал. жуть какая. хорошо, что я так не живу.

     
  • 4.61, Аноним (-), 20:51, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > в моем случае (внутри локалки) - основное достоинство, что поддерживается "искаропки" во
    > всех используемых системах и не требует ничего ставить/настраивать. особенно актуально
    > за пределами своего подразделения - уж "у себя"-то ЕСТЬ множество способов
    > как обменяться файлами, в зависимости от назначения обмена, но для разового
    > обмена временными и/или не очень служебными файлами используем тот же ftp.
    > Да и через корпоративные политики и прибамбасы пролезает нормально.

    Дропбоксы и прочие гугл-драйвы удобнее же.

     
     
  • 5.65, Аноним (-), 21:57, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Дропбоксы и прочие гугл-драйвы удобнее же.

    Да, конечно, упал канал в интернет - работа энтерпрайза полностью встала. За такие советы вам яйца однажды оторвут. И боссы и сотрудники.

     
  • 3.54, dal (?), 03:30, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А у меня есть проблема: NFS больше 650MB/s (около 6Gb/s) не понимается....  
     
  • 3.57, Аноним (-), 04:17, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Интресно, где сейчас массово востребован FTP?
    >> На всякий случай - кроме shared hosting-ов с PHP.
    > в моем случае ftp - единственное что полностью утилизирует гигабитный канал. ни
    > sftp, ни nfs, ни cifs даже половины скорости ftp не выдают.

    Слишком толсто


     
  • 3.73, Michael Shigorin (ok), 19:07, 18/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > ни nfs, ни cifs даже половины скорости ftp не выдают.

    Опять же странно, хотя и мнение "нет ничего быстрей двух tar через rsh" помню...

     

  • 1.2, Аноним (-), 12:06, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    для localhost'a весьма удобен pure-ftpd
     
  • 1.3, Аноним (-), 12:11, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    мы макеты в типографию сливаем по фтп
     
  • 1.4, Аноним (-), 12:14, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    PORT/EPRT
          When handling PORT and EPRT FTP commands from clients, proftpd now
          checks for RFC 1918 addresses in those commands; these are non-publicly
          routable IP addresses, and should NOT be being sent by clients.  When
          proftpd detects these RFC1918 addresses being used for a WAN server
          address, then proftpd will ignore the RFC1918 address, and instead
          use the IP address of the connecting client.  This change should help
          interoperability of data transfers for some FTP clients.

    А разработчики ProFTPD не догадываются, что их сервер может использоваться в интранет сетях ? Администраторы внутренней сети РЖД от такого изменения будут счастливы ;-)

     
     
  • 2.7, Аноним (-), 12:58, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Администраторам региональной СПД Газпрома фиолетово. Они не используют этот комбайн.
     
  • 2.9, Аноним (-), 13:20, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А что будет не так? Сервер возьмёт тот адрес, с которого соединение вместо указанного в команде (если у сервера внешний IP), но эти два адреса должны бы совпадать.

    Хотя в совсем сложной ситуации всё сломается, она требует не только внутренних адресов, но и хитрого роутинга.

     

  • 1.8, karapuz2 (ok), 13:03, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Никогда не мог понять, чем отличается сабж от, например, vsftpd?
     
     
  • 2.10, angra (ok), 13:24, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Дырками?
     
  • 2.11, Аноним (-), 13:24, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В первую очередь дырявостью.
     
     
  • 3.17, ALex_hha (ok), 14:05, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В первую очередь дырявостью.

    за фичи приходится платить

     
  • 2.16, Я (??), 14:05, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Незнаю как сейчас, но раньше у ProFTPD можно было хитро настраивать права доступа. Я его использую.
     
  • 2.33, Аноним (-), 17:28, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Никогда не мог понять, чем отличается сабж от, например, vsftpd?

    Вообще то всем отличается. Общего только протокол который они реализуют.

     
  • 2.49, Аноним (-), 21:11, 16/05/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Никогда не мог понять, чем отличается сабж от, например, vsftpd?

    Тем что умеет все, даже кофе в постель приносить. Правда, в комплекте с венерическими заболеваниями. Достаточно посмотреть на ченжлог, чтобы понять что это огромный энтерпрайзный мегамонстр. Чего для сетевого софта чревато кучами дыреней.

     

  • 1.19, Аноним (-), 14:17, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Мне больше нравится Pure-FTPd, только он давно уже не обновлялся, но  проект хороший Pure-FTPd. Что же касается ProFTPD то он скоро будет напоминать новогоднюю елку, а за фичи платить безопасностью можно разве что в локальной сети, но не в Интрнете.
     
  • 1.25, Shodan (ok), 15:44, 16/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    proftpd не елка, просто он модульный
     
  • 1.51, Аноним (-), 00:38, 17/05/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Встроенный в дистр OpenBSD вполне подходит для рядовых задач. Без лишнего рукоблудия.
     
     
  • 2.66, Аноним (-), 21:59, 17/05/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Встроенный в дистр OpenBSD вполне подходит для рядовых задач. Без лишнего рукоблудия.

    Правда, сам openbsd хрен запустишь на новом оборудовании, а если запустишь - обнаружишь что он там работает галимо. Например, многопроцессорные машины оно нормально использовать не умеет, а однопроцессорных серверов нынче просто не бывает уже.

     

  • 1.78, Аноним (-), 16:13, 08/11/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Где можно почитать как более правильно обновить proftpd 1.2 на новый 1.3.5?
    Все это на CentOS 6.5.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру