При запуске ProFTPD в отдельном режиме, он не виден в "ps". На это может быть много причин, это возможно из-за запуска ProFTPD не как корня (изначально он должен быть запущен как корень, но будет переключен на непривилегированного пользователя). Несмотря на это, ProFTPD записывает все ошибки через стандартный syslog механизм. Вам необходимо проверить свой системный журнал, чтобы определить проблему.
Не работает!
Очень часто бывает так, что появляются неразрешимые проблемы из-за совершенно случайно возникших неполадок. Лучше всего в таком случае обратиться за помощью к участникам списка рассылки (proftpd-l), но для эффективной отладки необходимо предоставить полную информацию.
Вы пробовали следующее?
Проверили ваши записи?
Проверили сервер в режиме debug?
Прочитали FAQ?
Просмотрели архив рассылки?
Вы пользуетесь последней версией?
При отправке вашего вопроса по почте, предоставьте достаточно полную информацию, включающую сведения о (и не только):
OS и версии сервера (proftpd -vv)
Список учтенных модулей (proftpd -l)
Необходимые отрывки из журнала регистрации
Выходные данные из режима debug
Фрагмент конфигурации
Вы не можете запустить ProFTPD с root привилегиями, или ваш inetd сконфигурирован под пользователя, отличного от root. ProFTPD должен запускаться с root'овыми привилегиями лишь для привязки к tcp портам с адресами меньше 1024, или чтобы иметь возможность открыть shadow файл паролей для авторизации пользователей. После запуска, для нормальной работы, демон ProFTPD обычно меняет uid/gid на те user и group, которые указаны в конфигурации директивами User/Group, поэтому команда "ps" будет показывать, что демон ProFTPD запущен от пользователя, указанного в перечисленных ранее директивах конфигурации.
0.0.0.0 - это INADDR_ANY, который может связаться с любым интерфейсом. "Адрес уже используется" ("address in use") означает, что с этим адресом уже кто-то связан.
В linux есть возможность запустить команду:
fuser -n tcp 21
для того, чтобы получить номер(PID) текущего процесса, связанного с портом, на который сконфигурирован ProFTPD (в данном примере, и обычно по умолчанию - это tcp/port=21).
Наиболее распространенная причина - то, что ProFTPD сконфигурирован отдельно, а inetd сконфигурирован под порт 21. Превратите в комментарий начало строки "ftp" в /etc/inetd.conf и перезагрузитесь (killall -HUP inetd или нечто подобное может в этом помочь). Попробуйте проделать все сначала.
Пользователю, пытающемуся залогиниться, была выдана оболочка (shell), которая ен указана в системном файле /etc/shells. По умолчанию, proftpd потребует, чтобы логинящиеся пользователи имели правильные оболочки (shells). Воспользуйтесь RequireValidShell директивой для того, чтобы отключить данное требование.
Вы сконфигурировали ProFTPD для работы в режиме inetd, а не в режиме standalone. В этом режиме ProFTPD необходимо запускать с inetd super-сервера, это значит, что stdin/stdout будут являться панелями, а не терминалами. В результате, операции на панеле будут безуспешными и на экран будет выводиться данная ошибка. Если вы хотите запускать ProFTPD из командного процессора (shell), в режиме standalone, вам понадобится смодифицировать ваш файл конфигурации proftpd.conf и добавить или отредактировать для чтения директиву Server Type:
ServerType standalone
На хостовой машине плохо сконфигурированы настройки hostname - до того места, где резольвентная библиотека не может определить IP по имени. Решением данной проблемы может быть наладка DNS для домена, настройка hostname, настройка /etc/hosts файла. Что из вышеперечисленного поможет вам справиться с проблемой, в основном, зависит от вашей ОС, а также от того, какая конкретно у вас неполадка.
Спецификация FTP подразумевает, что для всех коммуникаций должны быть использованы две панели. Первая запускается через порт 21 и является управляющим каналом, по которому посылаются все команды и коды ответа каждый раз, когда необходима передача данных, например, при загрузке файла, листинге директории и т.д. Второй канал создается по необходимости; эта панель может принимать одну-две формы.
non-Passive
Со своей стороны сервер для сокетов данных использует tcp порт с номером 20. С ним легко и удобно работать в firewall конфигурации.
Passive
На удаленной стороне для передачи данных адреса или номера портов будут назначаться динамически. В сущности, сделать это практически невозможно в firewall конфигурации, учитывая, что отображение в памяти (mapping) порта будет новым для каждого соединения.
Решить данную проблему можно, заставив пользователей использовать конфигурации для non-passive режима (т.е. порт 20)
Нет, по крайней мере не HTTP/1.1 через виртуальный хостинг. Это изначальное ограничение текущего FTP RFC., в отличие от HTTP/1.1 спецификации, не имеющее сравнимого с HTTP разделом "Host: foo.bar.com" механизма для указания информации, с какой машиной установлено соединение. Таким образом, единственный способ для того, чтобы определить, для какого VirtualHost предназначено соединение, это по IP пункта назначения.
Единственным исключением здесь является ситуация, в которой вы хостите многочисленные серверы на одном IP при помощи разных портов, однако здесь необходимо, чтобы клиент использовал non-standard порт, отсюда можно сделать вывод, что данное решение массового хостинга не самое лучшее.
Есть ли какая-нибудь возможность устранения данной неполадки?
Существует ориентировочный стандарт http://search.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-12.txt с IETF, который расширяется и обновляется информацией по спецификации FTP, включая поддержку для команды HOST. Однако, учитывая то, что проблема с IP происходит от вебсайтов, не от виртуальных ftp серверов, маловероятно, что в ближайшее время будут значительные продвижения в данном направлении.
Найдите строчку в /etc/inetd.conf, которая выглядит приблизительно следующим образом:
ftp stream tcp nowait root in.ftpd in.ftpd
Замените ее на:
ftp stream tcp nowait root in.proftpd in.proftpd
Затем найдите свой процесс inetd в списке процессов и перешлите ему SIGHUP сигнал, чтобы он мог быть переработан и переконфигурирован. Возможно, вам также понадобиться добавить in.ProFTPD к hosts.allow в вашей системе.
Да. Хотя ProFTPD имеет встроенный контроль IP доступа (смотрите директивы Deny и Allow), многие администраторы предпочитают концентрировать контроль IP доступа в одном месте через in.tcpd. Просто сконфигурируйте ProFTPD, чтобы возможно было запускать его из inetd как любой другой tcp-wrapper wrapped daemon и добавить необходимые строки к файлам hosts.allow/deny.
При запуске ProFTPD в режиме standalone, mod_wrap может быть использован для того, чтобы направлять сервер для использования обычных файлов hosts.allow/deny.
Да. Используйте <VirtualHost> блок с FQDN вашей машины (Fully Qualified Domain Name) или IP адресом, и директиву Port внутри блока <VirtualHost>. Например, если ваш хост имеет имя "myhost.mydomain.com" и вы хотите запустить дополнительный FTP сервер на порту 2001, вы наберете команду:
...<VirtualHost myhost.mydomain.com>Port 2001...</VirtualHost>
Да, модуль mod_ratio предусмотрен специально для этого.
Существует четыре коэффициента директив: файловый коэффициент, начальный кредит файлов и начальный byte кредит. Установка любого коэффициента на 0 отменяет данный контроль.
Директивы следующие: HostRatio (согласуется с FQDN, можно использовать wildcards), AnonRatio (согласуется с паролем, вводимым при логине), UserRatio (принимает "*" для "любой пользователь" ("any user"), и GroupRatio.
Коэффициенты
на # enable module
UserRatio ftp 0 0 0 0
HostRatio master.debian.org 0 0 0 0 # leech access (default)
GroupRatio proftpd 100 10 5 100000 # 100:1 files, 10 file cred 5:1 bytes, 100k byte cred
AnonRatio billg@microsoft.com 1 0 1 0 # 1:1 ratio, no credits
UserRatio * 5 5 5 50000 # special default case
Данный пример приведен для тех, кто (1) загрузил 1 файл размером 82k, (2) ничего не закачал, (3) имеет коэффициент файлов 5:1 и 5:1 байтов, (4) имеет 4 файла и остаток кредита в 17k, и (5) в настоящий момент меняет директорию на /art/nudes/young/carla. Начальный кредит, не указнный здесь, был 5 файлов и 100k (UserRatio * 5 5 5 100000).
Версия 2.0 и более современные версии этого модуля интегрируются с mod_sql.
Ограничения mod_ratio
Ограничения коэффициентов в mod_ratio поддерживаются только на посессионной основе и не наблюдается трекинга потребления.
Возможно, это вызвано наличием файрвола или тайм-аута DNS. По умолчанию, ProFTPD попытается как использовать DNS, так и идентифицировать просмотр входящего соединения. Если это невозможно или занимает слишком много времени, логин отнимет больше времени, чем обычно. Для того, чтобы выключить DNS и идентифицировать использование:
UseReverseDNS off IdentLookups off
IdentLookups and tcpwrappers ***
Oct 7 12:30:48 salvage2 proftpd[8874]: FTP сессия закрыта. Окт 7 12:30:48 salvage2 proftpd[8874]: FTP сессия закрыта. Окт 7 12:30:48 salvage2 proftpd[8874]: FTP сессия закрыта. Окт 7 12:30:48 salvage2 proftpd[8874]: FTP сессия закрыта.
Вышеуказанный отрывок журнала регистрационных записей возможен скорее всего из-за локальной системы мониторинга или особенно агрессивной атаки DoS. Большинство систем сервиса мониторинга пытаются открыть порт ftp на целевом сервере для определения того, что он активен и запускается. В большинстве случаев за этими тестами сразу же следует "QUIT" или прерывание соединения.
TCPdump/TCPshow на интересующем нас сервере должны указывать, какая машина в вашей сети создает эти соединиения.
При помощи команды ftpwho мы можем проследить состояние каждого соединения ftp с сервером и узнать, какова его настоящая деятельность. Однако, эта команда не дает возможности узнать подробную информацию по виртуальному соединению на виртуальной основе.
Sort, of it's not quite as clean as the socket binding under Apache but the principle works something like this.
Режим Standalone
Чтобы прослушивать основной IP хоста, используйте SocketBindTight директиву
Чтобы прослушивать при помощи интерфейсов, которые не являются основными интерфейсами хоста, используйте SocketBindTight директиву, поместите конфигурацию вашего сервера в <VirtualHost ftp.mydomain.com> блоке и используйте "Port 0" для конфигурации главного хоста и "Port 21" внутри блока VirtualHost.
inetd
Возможны два подхода, первый - использовать патч из Daniel Roesen <droesen@entire-systems.com> (проверьте архивы рассылок).
Второй способ - запустить ProFTPD из xinetd (http://synack.net/xinetd/), это более эффективный вид замены inetd. Данные об этом в xinetd.conf будут выглядить примерно так:
service ftp { disable = no flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/proftpd log_on_success += DURATION USERID log_on_failure += USERID nice = 10 #bind = [IP to bind to] }
Проверьте наличие /etc/shutmsg и удалите его.
ftpshut позволяет серверу закрывать соединения при помощи сообщения без собственно отмены услуги. Закрытие (shutdown) может быть запланировано на определенный момент позже или может быть осуществлено прямо сейчас, существующие соединения можно закончить или закрыть сейчас же. Повторное включение осуществляется путем удаления /etc/shutmsg файла.
Нет, файл закрытия работает на daemon уровне, не на уровне virtual host.
Это является общей ошибкой, означающей "что-то произошло".
Соединение завершено
Указанный DefaultRoot не существует
Родительский сервер закрыт
Проверьте /etc/services
Неверные разрешения на DefaultRoot
Вы понимаете...
Возможны две причины, первая - то, что он просто не запущен, в этом случае попробуйте набрать proftpd -n -d2, чтобы запустить его в режиме debug и посмотрите, что произойдет. Другая причина может заключаться в том, что он не запускается из inetd и не существует активных сессий в данный момент.
Это зависит от режима, в котором вы запускаете сервер.
inetd
Пока вы не внесете изменения в сам inetd, нет необходимости что-либо делать. Сервер перегружает конфигурацию каждый раз, когда осуществляется новое соединение.
Standalone
Либо остановите и запустите сервер заново (звучит немного грубовато для большинства администраторов), либо отошлите SIGHUP для master daemon процесса.
Ошибка появилась в 1.2.0rc2, из-за которой команда PORT не работает так, как это необходимо, а следовательно, панель данных в некоторых случаях ломается. Ошибка была занесена в документацию как bug 240 и была зафиксирована в CVS. Релиз rc3 должен появиться до конца января 2001.
Proftpd не может определить, какой IP ассоциируется с именем хоста в VirtualHost block. Обычно происходит из-за проблемы с разрешением DNS хоста, проверьте файл resolv.conf, а также убедитесь в том, что выбранные вами имена серверов функционируют.
AllowStoreRestart не работает по умолчанию, потому что из-за этого любой перезаписываемый файл сможет быть поврежден любым пользователем. Мы рекомендуем использовать эту опцию только с аутентифицированными пользователями и только в определенных директориях.
Как уже упоминалось в описании директивы конфигурации HiddenStor, использование этой директивы несовместимо с FTP командой REST. Либо откажитесь от использования REST с AllowRetrieveRestart и AllowStoreRestart директивами, либо не используйте HiddenStor.
Установленное правило для ProFTPD - демонстрировать любое время, имеющее отношение к GMT. Для того, чтобы использовать сет местного времени, воспользуйтесь "TimesGMT off" в секции сервера конфигурации. Также существует известная статья с Redhat 7, описывающая управление временем. http://www.redhat.com/support/rh7-errata-bugfixes.html
Если проблема осталась, попробуйте указать временную зону через SetEnv, например: "SetEnv TZ :/etc/localtime"
Убедитесь в том, что ReverseDNS отключен, выключите ident lookups. Также не забудьте проверить размер вашего /etc/passwd (или shadow) файла; если он слишком большой, единственным решением может быть перемещение в другую аутентификационную схему.
Появляются некоторые проблемы как с использованием sendfile() в ProFTPD, так и с имплементацией внутри определенных операционных систем.
Если ответить кратко, то нет. Если ответить длиннее, то нет, но вы можете минимизировать последствия. Самый правильный подход к серверам, траффик которых огромен, - использование ftpshut для блокирования новых соединений и завершение существующих соединений после заранее установленного периода времени, затем - апгрейд и запуск заново. Такой подход ограничивает количество скачиваний, которые завершаются на полпути.
Установленный файл конфигурации ProFTPD сообщает для пользователя "nouser" и для группы "nogroup", хотя некоторые системы / дистрибуции не имеют заданной группы "nogroup". Решением в данной ситуации будет либо добавление группы "nogroup" к /etc/groups, либо изменение записи "nogroup" в proftpd.conf на группу, которая существует.
Настройка привилегий группы для обработки данных использует системный вызов setgroups(2). Данный вызов не удастся совершить - при этом мы увидим вышеуказанное сообщение об ошибке. Это может произойти по двум причинам: для одной из групп значение GID отрицательно, либо максимальное количество групп для одного пользователя превысило допустимое значение.
В идеале, все IDs, как UID, так и GID, будут положительными. К сожалению, обычно в большинстве систем используется -1 или -2, особенно для таких пользователей, как 'nobody', или группы 'nogroup'. Использование данных значений применяет обращение C с разными видами данных для того, чтобы сделать текущее цифровое значение высоким; хотя некоторые функции, такие, как setgroups(), не воспринимают это. Вообще, всегда старайтесь использовать положительные ID цифры.
Другим ограничением является количество дополнительных групп для пользователя (например, второстепенные группы, те, которые были сконфигурированы в in /etc/group). Максимальное количество дополнительных групп, к которым может принадлежать пользователь, определяется константой оперативной системы NGROUPS_MAX. На некоторых оперативных системах, таких, как Solaris, это ограничение может быть настроено по собственному желанию.
Некоторые другие приложения могут не иметь данной ошибки, если они используют функцию initgroups(3), которая считывает файл /etc/group для членства в дополнительных группах пользователя, а также устанавливает все группы. Данная функция, однако, игнорирует любые дополнительные группы для пользователя, большие, чем NGROUPS_MAX, в отличие от setgroups(2).
Если в этом заключается ошибка, упоминающаяся в сообщении, в любом случае, скорее всего придется сократить количество групп, членами которых являются ваши пользователи, либо настроить значение NGROUPS_MAX, если ваша операционная система позволяет это.
PAM(exit): Permission denied open_module: stat(/usr/lib/security/pam_unix.so.1) failed: No such file or directory
load_modules: can not open module /usr/lib/security/pam_unix.so.1 PAM(exit): Dlopen failure.
Данные сообщения появляются, когда действует директива конфигурации DefaultRoot. По этой директиве пользователь будет ограничен при использовании системного звонка chroot(2). Однако, данный звонок влияет на все другие утилиты системы, такие, как PAM. В этом случае, конфигурация PAM заставляет библиотеку PAM пытаться открыть PAM модули, используя путь, больше не являющийся действующим, что соответственно приводит к ошибкам. Это происходит при выходе из системы, потому что chroot уже создан к этому моменту; на входе в систему, модули PAM успешно найдены и загружены еще до chroot, поэтому не возникает никаких ошибок. Это просто ошибки, сообщающие о внешних неполадках, не приводящие к сбою функциональной работы сервера или дырам в системе безопасности.