Created attachment 1163505 [details] success
Created attachment 1163506 [details] manually
Weird. The log transfer goes fine when I set dual_log_enable=YES on the vsftpd server.
https://github.com/ManageIQ/manageiq/pull/9127
Ok, so it turned out that server logging has nothing to do with this bug. There seems to be subtle differences between ftp servers. It would be great if QE could verify this bug with vsftpd and at least one other ftp server.
version: 5.7.0.16.20161213213754_1ad3545 MS IIS and FileZilla on Win works as defined even with subfolders(with empty folder and with some files in it) vsftpd: As Kyrylo said, if incoming folder is empty - error occur (Error '550 Permission denied.', writing to FTP: [ftp://10.36.4.30], Username: []). If at least one file present in this folder - logs collected successfully. vsftpd config: listen=NO listen_ipv6=YES anonymous_enable=YES anon_root=/srv/ftp/ local_enable=NO no_anon_password=YES write_enable=YES dual_log_enable=YES anon_upload_enable=YES anon_mkdir_write_enable=YES allow_writeable_chroot=YES In "/srv/ftp" present folder "pub" with 777 access rights. So if you set log collection to 10.36.4.30/pub and "pub" folder is empty - error will occur. But if you create at least one file - you will be able to collect the logs.
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/f87471adff09ee5316165ae906fc8e3705796868 commit f87471adff09ee5316165ae906fc8e3705796868 Author: Šimon Lukašík <isimluk> AuthorDate: Fri Jun 3 14:53:43 2016 +0200 Commit: Šimon Lukašík <isimluk> CommitDate: Tue Jun 7 17:48:19 2016 +0200 Start mocking specific behavior of remote ftp servers I feel we need some better mocking then just rspec's double. There are differences between various ftp servers and we keep touching FileDepotFtp code as we see saw these differences comming. The tests based on rspec's double are not the useful in this case as they need to be rewritten each time we change the code logic. At that point we may re-introduce bugs for certain ftp servers. Let's build the knowledge about specific servers behavior in the spec. https://bugzilla.redhat.com/show_bug.cgi?id=1341502 spec/models/file_depot_ftp_spec.rb | 76 +++++++++++++++++++++++++++++++++----- 1 file changed, 67 insertions(+), 9 deletions(-)
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/f40f36a53e78e1bb2afa5baa76c1bd1d35d97c5b commit f40f36a53e78e1bb2afa5baa76c1bd1d35d97c5b Author: Šimon Lukašík <isimluk> AuthorDate: Fri Jun 3 11:02:50 2016 +0200 Commit: Šimon Lukašík <isimluk> CommitDate: Tue Jun 7 17:48:19 2016 +0200 AnonFTP: Create directory structure by descending down https://bugzilla.redhat.com/show_bug.cgi?id=1341502 The problem is that we cannot rely on fpt.nlst to give exception when file is not available. With vsftpd 3.0.2-14.fc23 and Ruby-2.2.0 Net::FTP I get behaviour like the following ftp.nlst('/') => ["/incoming", "/pub"] ftp.nlst('/incomming') => [] ftp.nlst('/non-existent') => [] app/models/file_depot_ftp.rb | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
This should be now fixed. If possible, could you please test with both MS ftp server and vsftpd? Thanks!
verified in 5.9.0.4.20171024163837_ef71ea6 with both vsftpd and MS ftp
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0380