Я работаю над проектом, где несколько Пи Малины собирают данные датчика и регистрируют их в несколько файлов, несколько раз в день. Я хотел записать маленький сценарий для загрузки всех тех файлов на FTP-сервер в конце дня с crontab. Таким образом, я записал сценарий с помощью lftp, который работал сначала, но позже начал показывать ошибку.
Ниже сценарий и подробный вывод. Как я могу зафиксировать его?
#!/bin/bash
HOST='ftp://xyz.com'
USER='xxxxxx'
PASS='xxxxxx'
TARGETFOLDER='/home/xxxx'
SOURCEFOLDER='/home/pi/yyyy'
lftp -f "
open $HOST
user $USER $PASS
debug -o lftp_debug.txt
lcd $SOURCEFOLDER
mirror --reverse --delete --verbose $SOURCEFOLDER $TARGETFOLDER
bye
"
вывод:
---- Connecting to xyz.com (xx.xx.xx.xx) port 21
<--- 220 (vsFTPd 3.0.3)
---> FEAT
<--- 211-Features:
<--- EPRT
<--- EPSV
<--- MDTM
<--- PASV
<--- REST STREAM
<--- SIZE
<--- TVFS
<--- 211 End
---> USER XXXX
<--- 331 Please specify the password.
---> PASS XXXX
<--- 230 Login successful.
---> PWD
<--- 257 "/home/XXXX" is the current directory
---> MKD /home
<--- 550 Create directory operation failed.
---> MKD /home/XXXX
<--- 550 Create directory operation failed.
---- CWD path to be sent is `/home/XXXX'
---> CWD /home/XXXX
<--- 250 Directory successfully changed.
---> PASV
**** control-socket: Connection reset by peer
---- Closing data socket
---- Closing control socket
Забавная вещь состоит в том, когда я вхожу в тот же FTP-сервер посредством команды 'FTP' с тем же пользователем и передаю ее работы как очарование, но когда я вхожу в систему через lftp
с тем же пользователем и передачей я смог войти в сервер, но как только я даю ls
управляйте, чтобы это показало следующий вывод.
lftp user@xyz.com:~> ls
`ls' at 0 [Delaying before reconnect: 24]
Не используйте ftp. Вероятно, проблема, с которой вы столкнулись, связана с общим путаницей направления соединения в FTP. FTP использует два порта: одно командное соединение и одно соединение для передачи данных. Традиционно командное соединение было от клиента к серверу, а соединение для передачи данных от сервера к клиенту!
PASV - противоположность; он указывает серверу прослушивать соединение для передачи данных от клиента и сообщать клиенту, что это номер порта. Похоже, это (неожиданное для многих) поведение - это то, что вас кусает.
Однако, на мой взгляд, продолжение использования FTP сегодня не является хорошей альтернативой. Это просто устарело, с точки зрения безопасности и протокола.
У вас есть несколько альтернатив FTP. Если вы используете аутентификацию, хорошая альтернатива - scp / sftp. Требуется ровно один порт, он аутентифицирован и зашифрован.
Если вам требуются анонимные предложения, http (s) - хорошая альтернатива. Либо через POST-запрос, либо с помощью WebDAV. Http может также быть настроен на использование аутентификации и может быть зашифрован с помощью TLS (https). Он также открывает только один канал для данных и команд.
FTP - это 40-летний протокол. Он выходит из употребления, и, как следствие, этому программному обеспечению не уделяется столько внимания, как более популярным веб-серверам и ssh-серверам, и, таким образом, существует большая вероятность выживания серьезных уязвимостей в исходном коде.
Кроме того, команда для SCP'а будет намного проще: scp * $user@$host:$targetfolder
- и вы можете использовать аутентификацию на основе ключей, чтобы избежать паролей в скрипте!