Python fptlib Mlsd генератор ошибка итерации - PullRequest
Новая
       119

Python fptlib Mlsd генератор ошибка итерации

0 голосов
/ 27 октября 2019

Я ищу файл index.html в каталоге ftp. согласно документам они рекомендуют mlsd. Я пытаюсь распечатать результаты и ищу файлы, но это не работает. Я пробовал через терминал, и он работает нормально. 

#!/usr/bin/python3

from ftplib import FTP
ftp = FTP("192.168.10.6")
ftp.login("username", 'password')
resp = ftp.mlsd()
print(resp)



for name, facts in resp:
    print(name)
#also tried for item in resp:

Ошибки 

<generator object FTP.mlsd at 0x7fee1870cd00>
Traceback (most recent call last):
  File "./test.py", line 9, in <module>
    for name, facts in resp:
  File "/usr/lib/python3.6/ftplib.py", line 596, in mlsd
    self.retrlines(cmd, lines.append)
  File "/usr/lib/python3.6/ftplib.py", line 468, in retrlines
    with self.transfercmd(cmd) as conn, \
  File "/usr/lib/python3.6/ftplib.py", line 399, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "/usr/lib/python3.6/ftplib.py", line 361, in ntransfercmd
    source_address=self.source_address)
  File "/usr/lib/python3.6/socket.py", line 724, in create_connection
    raise err
  File "/usr/lib/python3.6/socket.py", line 713, in create_connection
    sock.connect(sa)
TimeoutError: [Errno 110] Connection timed out

1 Ответ

0 голосов
/ 27 октября 2019

После установки ftp.set_debuglevel(2) и включения подробного входа в систему /etc/vsftpd.conf, добавив log_ftp_protocol=YES. Я заметил, что клиент не отправляет команду после команды pasv. просмотрев протокол ftp, я заметил, что после входа в систему ftp решает какой-то случайный порт, по которому они будут общаться. Исходя из этого я подумал, что может быть проблема с брандмауэром. несмотря на то, что я уже разрешил 20,21,22 и 960. поэтому я попытался отключить брандмауэр полностью sudo ufw disable. и запустил скрипт, и он работал без нареканий. Что меня смущало, так это то, что иногда сценарий работал, и в основном это просто тайм-аут. Исходя из текущего сценария, я предполагаю, что всякий раз, когда возникает проблема тайм-аута, это в основном связано с настройками брандмауэра или безопасности, например, когда мы подключаемся к серверам ec2 и т. Д.

Кроме того, включение уровня debuglevel и verbose помогло мне во многом другомработает в темноте.

Вот журнал, после которого связь зависла или не работает. 

*get* '227 Entering Passive Mode (192,168,10,6,200,66).\n'
*resp* '227 Entering Passive Mode (192,168,10,6,200,66).'
...