[LTP] [PATCH 1/6] ftp/ftp01: Use tst_net.sh

[Akihiko Odaki]

Hi Petr,

On 2022/10/21 15:22, Petr Vorel wrote:
> Hi Akihiko,
> 
> I'm sorry I overlooked your message at v1
> https://lore.kernel.org/ltp/9894db50-6319-a818-c995-3ba9ab102c4b@daynix.com/
> 
> I guess script expects $PASSWD to be set.
> Also trying to follow the instruction, none of them (allowing root in
> /etc/ftpusers or filling /root/.netrc with machine localhost) work for me:
> https://github.com/linux-test-project/ltp/tree/master/testcases/network#ftp-and-telnet-setup
> 
> I suppose any ftpd implementation must be run on the remote server (localhost,
> if tst_net.sh uses netns - the default or on remote host, if ssh is used).
> Otherwise ftp command "user $RUSER $PASSWD" cannot work, right?
> 
> Although it should behave the same regardless netns or ssh is used,
> how do you test v3, with ssh or with netns (the default)? Or both?

Thanks for sharing your fork. I tried it with SSH, and I had to make the 
following modifications to run it correctly:
- I had to restore commented out "cd $TST_NET_DATAROOT".
- I had to change the arguments of test_get and test_put back to 
"binary" and "ascii".
   It is used to set the transfer mode (search for "echo $1").

> 
> It'd be nice if there was connection detection in the setup and tst_brk TCONF if
> login does not work. The best would be to have configuration in the setup() +
> cleanup in the cleanup()).
> 
> There are tests, which do vsftpd configuration: ftp-download-stress.sh,
> ftp-upload-stress.sh.
> 
> BTW in the past we seriously considered to delete these highlevel smoke tests.
> LTP is concentrated to test kernel API and internals, thus we didn't see much
> value with smoke tests like this (that's why they haven't been rewritten to use
> new API), specially if they require complex setup and get false positives when
> SUT not configured properly. That's why it'd be nice to at least TCONF (if not
> doing whole setup).

I just modified this test because it is annoying to set up rsh just to 
fix this test so I would rather not put more effort for further 
improvement. Personally I don't object to remove this test either.

Regards,
Akihiko Odaki

> 
> Kind regards,
> Petr