Блог о технологиях, технократии и методиках борьбы с граблями
Периодически возникает необходимость снять архив напрямую с FTP. К примеру, я сейчас строю сателлитную сетку под один из проектов и верстальщик выкладывает у себя на постоянке восстановленные из веб-архива сайты.
Переносил тут клиенту сайтеги с хостинга под управлением DirectAdmin и что то резко обломался резвости FTP соединения, т.к параллельно устанавливалось только 3 сессии, а при попытке открыть 4ю, все сразу подвисало и уходило в повторные попытки.
Возникла необходимость поставить ftp сервер, так что в этой связи появился стимул наконец то разродиться статьей по настройке ftp сервера. Для этого я буду использовать сервер ProFTPD, позволяющий хранить аккаунты пользователей в базе данных, а также дающий возможность использования различных удобных фич как в безопасности, так и для подключения дополнительных модулей.
Хранение пользователей в базе данных крайне удобно, так как позволяет использовать ftp не заводя в системе штатные аккаунты, пусть и с ограниченными правами (по этой же причине мне нравится связка dbmail + mysql). Также эти базы можно удобно резервировать, тем более что все пути и чируты прописываются именно в них. Также при желании можно подключить проверку загружаемых файлов через clamav путем патча пакета pfoFTPD, но думаю что это отнесу к какой нить другой статье.
За последний годы, объемы данных возросли многократно, и если в 96 году файловый сервер стоявший в здании М9 имел RAID-массив аж на целых 500 мегабайт, что вызывало благоговейный трепет, то сейчас, покупая флешку, даже не рассматриваешь модели менее 8Гб. Соответственно в разы возросли и скорости передачи данных, но с приходом новых поколений пользователей, появляется новая проблема, когда люди начинают недоумевать отчего они не могут переслать 2-3Гб по почте.
Максимум что мне приходило на почту- это была первая версия Дыбалы, которую мне в свое время переслали ребята из РТКОММа и я тогда конечно намучился, получая по почте около 150 мегов. Так что когда 5-6 лет спустя я обнаружил у пользователя в почтовом ящике письмо с вложенным роликом на полгига, которые он пытался отправить по почте, я даже не удивился.
Вообще пользователей стоит приучать к тому, что максимальное вложение письма должно составлять 20-25 мегов, но и даже таких объемов идеально избегать, пользуясь архиваторами и не забывая о том, что почтовые программы (больше всего конечно мелкомягкие) любят дописывать от себя 10-15%. И если твой админ позволяет отправлять 30+ метров почты, то это не значит что на принимающей стороне работает такой же добряк. Вообще большие сообщения это головняк для админа, так как они загружают почтарь который вынужден держать сессию на получение такого письма, да к тому же забивают почту. Поэтому пользователей стоит приучать использовать другие механизмы передачи файлов через интернет. Естественно, что админ может предложить юзверям пользовать общедоступные веб-ресурсы, вроде депозита или рапидшары, но более корректно в моем понимании- это иметь собственный FTP сервер, позволяющий выкладывать и скачивать с него файлы.
Собственно о планировании такой схемы я уже как то писал, но так и не сподобился развернуть все более подробно, так как в тот раз как обычно никому было ничего нужно, а вот буквально на днях оказалось, что надо было вчера, так что видимо в ближайшее время выложу факу настроек ftp-сервера.
А к вышесказанному остается только добавить немного слов по разграничению прав: либо на уровне пользователей, либо на уровне отделов, если пользователей катастрофически много. Но в любом случае на каждую папку надо давать два типа прав: на чтение и на полный доступ, причем полный доступ следует выдавать только проверенным людям, и менять логин на полный доступ хотя бы раз в месяц, поскольку как я уже как то писал- если контора ведет активный файлообмен, то логины довольно быстро сливаются в паблик, ибо вы даете сотруднику, тот дает проверенному клиенту, тот дает дизайнеру или одмину васе, вася дает подружке маше, а поскольку маша дает всем, то через пару недель ваш логин публикуют на каком нить форуме. То есть, если возможно, то логины на запись следует вообще активировать по запросу, поскольку изнутри конторы пользователи работают через smb.
Доступ же к аккаунтам изнутри как раз организуется с полными правами, либо к рутовой папке для гостя, где торчат все акки, либо же персонализировано по логину. Для особо не спокойных можно естественно прикрутить к AD, но в случае разграничения на уровне отделов, видимо придется повозиться.
На счет подключения к веб-серверу- тут все просто- просто прописываем либо субдомены для каждой папки, либо паролим каждую папку и даем адреса вида: наш_сайт/папка1
Сегодня пришлось поехать к клиенту как раз по поводу многострадального шарика с видяхами, и пока суть да дело- нарисовался планчик для локального ftp-сервера, который необходимо поставить в конторе. Рисовать не охота, да и Visio я себе так и не поставил, поэтому опишу на пальцах куда рыть.
Собственно принципиальная схема работы следующая: FTP-сервер работающий под ProFTPd с хранением учеток в базе MySQL. К нему есессно подрублен контроль файлов и clamav. Сам сервак находится в DMZ за фаерволом, где на него подключены собственно порты 20, 21 и все выше 1024, для отработки пассива. Также ставим apache и открываем 80 порт на фаерволе, так как некоторым тупым бургам понадобится скачивать из локалок, а по своему опыту работы я неоднократно сталкивался с ситуацией когда у таких “васяток” банально нет чела который им мог бы объяснить как переключить ftp-клиента в пассивный режим, а факи которые им шлешь на почту, почему то не вспомогают. Вот для таких граждан необходимо также иметь web-сервер на котором завести некоторое количество папочек, запароленных на основе .htaccess.
Остальные пакеты это samba сервер, через который внутренние клиенты раскидывают файлы по папкам, с аутентификацией на уровне пользователей. Тут собственно можно сделать два варианта: либо разрешить прохождение smb пакетов из сетки через фаервол, либо засунуть сервак вторым интерфейсом в локалку, но это не особо хорошая идея, ибо хотя шансов что нам сломают ftp крайне мало, но все равно это получается лишний вход. В принципе можно его вывести вторым шнутом во внутренний DMZ, куда уже фильтровать пакетики от внутренних сетей. Такой ход более гиморный, но зато и наиболее спокойный.
Каждому юзверю, или отделу создается папка- желательно конечно с квотированием, иначе ftp-сервер превращается в неконтролируемую файлопойку похуже файл-сервера. В этой связи есть смысл подрубить еженедельную отправку на почту статистики вывода:
df -ah
du -ch -d 1 /ftphome
Теперь по защите всего это хозяйства, как я и сказал: на фаерволе делаем маппинг по портам, или же безусловную трансляцию, закрывая все порты ниже 1024 порта, кроме 20, 21 и 80 вовне, а внутрь от сервера пропускаем все или же только smb протоколы.
После чего все это дело настраиваем и радуемся жизни.
Столкнулся в самом начале своей работы в инет агентстве с тем, что пришлось переносить один через-жопу-сделанный-сайт™ (далее ЧЖСС), который еще до моего прихода в контору, ваяли некие омские умельцы, о которых я уже упоминал как то, и видимо еще буду неоднократно их вспоминать. Собственно при переносе всплыла некая особенность реализации, что люди не удосужились озадачиться юзерфрендли алгоритмом переименовывания русскоязычных картинок, при загрузке на сайт, в англоязычные. Поэтому они грузились на сайт в таком же виде что и были на компе, с той лишь разницей- поскольку все это проходило через Drupal, что русские названия сохранялись в кодировке utf-8.
И вот собственно при попытке их вытащить с многострадального хостинга, выяснилось что сделать это не представляется возможным, так как при трансфере стандартным leechftp которым я пользовался стопяцот лет, русские названия превращаются в нечитабельную крокозябру, так что трансфер по ftp на русском превратился в серьезный головняк, так как выяснять какие файлы какие и потом их переименовывать (как мне посоветовали веселые разработчики) было реально сизифовым трудом. Опять же загоном сайта в архив эта проблема не решалась, так как файлы в архиве тоже были со сбитой кодировкой. Поэтому пришлось задуматься в чем проблема того что скачать ftp на русском не представляется возможным.
А оказалось что проблема в том, что кодировку utf-8 поддерживает весьма небольшое количество ftp-клиентов, так что следующим этапом стал поиск удобоваримого клиента, в резьтате чего сформировался следующий список:
SmartFTP
FileZilla (вроде как в варианте патченной версии)
плагин к FireFox- Fireftp
Lftp
FTPRush
Из них я попробовал несколько штук, и остановился на SmartFTP- правда к сожалению данный клиент является коммерческим, что подразумевает что за него надо бы платить денег. Так как с FileZilla у меня возникли таки траблы с переносом файлов, Fireftp эпизодически задумывалось о судьбах рунета, в вот SmartFTP работал отлично, так что в данный момент я использую исключительно его, в том числе и для работы с файлами по ftp на русском, поскольку решать проблему русскоязычных файлов никто не захотел. SmartFTP оказался отличным ftp-клиентом, который помимо возможности скачать ftp на русском позволяет выполнять все необходимые для ftp-клиента функции: качать, переносить директории и файлы без трансфера на удаленную машину, редактировать удаленные файлы, менять права и многое-многое другое. Единственный вскрывшийся глюк оказался в том, что при редактировании файла на локальной машине- следует убирать выделение с файла, так как он, при попытке сохранения изменений, будет удален.
