Моя звать Борат. Я вас люблю. Я люблю АйТи. Нраица! Любит автоматизацию FTP Эта история расскажет о том, как наша компания автоматизировала передачу файлов по FTPS в условиях, когда не подходят стандартные решения и у разработчиков появляются мысли сделать fork ftplib, что, вообще-то, более похоже на депрессию из-за этой задачи. Компания, в которой я работаю, занимается бизнесом в сфере DaaS. На одном из этапов нашего пайплайна мы столкнулись с проблемой автоматизации передачи файлов клиенту по FTP. Мы не могли решить проблему, поэтому появилась идея автоматизировать нажатия кнопок у FileZilla. Мы использовали: wmctrl и xte. wmctrl – помогал управлять окном FileZilla; xte – нажимал на кнопки и горячие клавиши. Это разработанный макрос для GUI - насильник местный. Не хороший! Возмущён макросами для GUI Потому что это не гарантировало доставку файлов до клиента. Работая с автоматизацией GUI мы не можем точно отследить ошибки, проверить параметры, условия, посмотреть подробности какой-нибудь части. Кроме ведения логов, конечно. FileZilla предоставляет нам такую возможность, но это “доказательство от обратного”. Гораздо важнее начинать с перехвата ошибок на первом этапе - подключения к серверу. Чтобы можно было, хотя бы, переподключиться к FTP-серверу. Итак. Сервер клиента использует FTPS, нужно явно указать порт, IP, данные для авторизации. FileZilla имеет возможность сохранить параметры входа, и мы даже можем использовать параметр в командной строке, чтобы запустить клиент с подключением по реквизитам, указав название сохранённых данных из менеджера сессий. Но и это не имеет смысла, так как отследить, в какой директории сейчас находится FileZilla, нельзя. В ходе использования клиента мы обнаружили, что, если в локальной директории находится всего две папки: [‘..’, ‘some-dir’], то, при выделении через CTRL + A и по нажатию Enter, нас перенесёт в директорию выше, так как FileZilla имеет такой баг и нажимает именно на папку “..”, что является переходом на уровень вверх (спасибо, кэп). Задача: по FTPS переслать файлы на сервер клиента. При условии, что роутер клиента в качестве ответа при подключении по FTPS выдаёт внутренний IP. Не смотря на множество модулей Python, у нас случилась экстраординарная ситуация, которая вряд ли могла быть предусмотрена разработчиками таких известных библиотек, как pyftp, sftpy, ftplib. В строго регламентированных документами компаниях (наш заказчик таким и является) – сетевики клиента порой не в праве менять что-то под исполнителя, поэтому на этом пути нам встретился ТАКОЙ неудачный вариант. И это надо было как-то решать. Все ftp-клиенты для Пайтона при подключении просто зависали. Там ни ответа, ни привета. Было прочитано с сотню статей, куча документации и огромный стейк видео был пересмотрен. В итоге мы потом поняли, что сервер возвращает нам вообще неподходящий IP-адрес после подключения. Все эти библиотеки берут этот IP и используют в дальнейших операциях. Например, при авторизации туда посылают запрос. Зачем это сделано? Мы же и так задали вручную нужный нам IP. Вот такие приколы от разработчиков этих модулей мы получили. Кстати, стандартный FTP в терминале Linux тоже нам не подходил. Он не умел FTPS-передачи делать. Оказалось, что при запросе в Гугле, типа “cli ftp clients” часто упоминается lftp и другие. Разработал LFTP в 1996 году Так выпал день, что всё-таки мы попробовали LFTP, и ответ уже был другой! Хотя бы не зависает запрос. Но и что-то не то выдаёт. А проблема была в том, что SSL-сертификат не проходил верификацию. Наверное, он просто самоподписанный. К большому счастью это можно отключить. Потому что у LFTP мощные настройки. Здесь: и логи, и путь к логам, и SSL-настройки, и многое-многое другое. LFTP может передавать кучу файлов на сервер и логировать процесс работы: LFTP может зеркалировать две директории, то есть передавать файлы на сервер, но не перезаписывать имеющиеся, да ещё и в 10 потоков: Нраица! Автоматизировал FTPS Автор решения, кода и статьи: Денис Ковтуненко DaaS software engineer, web-developer