public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2] ftp01.sh: Add support for test lftp
Date: Wed, 16 Oct 2024 23:15:13 +0200	[thread overview]
Message-ID: <20241016211513.GA104519@pevik> (raw)
In-Reply-To: <66c4cb2a-14de-4967-9c86-843759087dc5@suse.cz>

> On 16. 10. 24 14:47, Cyril Hrubis wrote:
> > Hi!
> > > To be honest, I would rather to remove this FTP test because FTP protocol is
> > > legacy. I know it is supposed to be a smoke test, but maybe using modern tools
> > > would be better than keeping test working among various old FTP implementations.
> > > (Also nontrivial setup is required just for few FTP tests:
> > > https://github.com/linux-test-project/ltp/tree/master/testcases/network )
> > > But probably Cyril would be against. @Cyril @Martin WDYT?

> > So where is the ftp server setup code? Or do we expect ftp server to be
> > installed and configured prior to the test execution?

> > The actuall test does not look that complex to me.

> Hi,
> I've replied to patchset v1[1] that the server setup is better left to the
> user, like we do with NFS. In our case, it should be done in OpenQA during
> VM environment setup.

NFS case is kind of different from FTP. 1) There is the only nfsd implementation,
in kernel. But there are more FTP servers (userspace).

Also it's not just about starting the service (I agree with leaving services
enabled in tooling outside LTP, e.g. *not* using testcases/lib/daemonlib.sh),
but there is also service configuration which is required to be done in the test
(part of the testing). NFS tests just run exportfs. All FTP scripts but ftp01.sh
use vsftpd configuration. ftp01.sh could reuse this code (if it's working).

Besides this FTP server it also involves some additional setup [2] (adjust
/etc/ftpusers or /etc/vsftpd.ftpusers), but sure, this could be left for the
test runner.

> I agree that the test could be replaced by a socket test, either using
> improved netstress tool or some new syscall tests for send()/recv()/...

I was also thinking about using netstress.c (which is already used for
network many tests) for FTP download and upload tests.

There are also other tests in runtest/net_stress.appl:

* dns-stress.sh bind9 resolving test - IMHO not relevant for LTP (bind has nice
  CI testing done by ISC).
* ssh-stress.sh sshd stress test - IMHO not relevant for LTP even as a smoke
  test. Also touching ssh configuration can break some LTP users as LTP is often
  used as a connection to SUT.
* http-stress.sh http downloading stress test - IMHO redundant to FTP download
  (if we replace FTP tests with netstress / other C code, we can delete this as well).

Back to ftp01.sh (file modified in this patch). It tests downloading and
uploading with FTP protocol. It looks to me more as FTP client/server test than
anything else (it's not a stress test). IMHO not relevant for LTP.

Kind regards,
Petr

> [1] https://patchwork.ozlabs.org/project/ltp/patch/20240918100344.21316-1-wegao@suse.com/#3381493

[2] https://github.com/linux-test-project/ltp/tree/master/testcases/network#ftp-and-telnet-setup

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2024-10-16 21:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-18 10:03 [LTP] [PATCH v1] tst_test.sh: Add support for localhost ssh key setup Wei Gao via ltp
2024-09-18 11:46 ` Martin Doucha
2024-09-24 10:15   ` Wei Gao via ltp
2024-09-24 12:08     ` Martin Doucha
2024-09-25  3:57 ` [LTP] [PATCH v2] ftp01.sh: Add support for test lftp Wei Gao via ltp
2024-10-15 19:39   ` Petr Vorel
2024-10-16  3:13     ` Wei Gao via ltp
2024-10-16 13:41       ` Petr Vorel
2024-11-04 16:20       ` Petr Vorel
2024-10-16 12:47     ` Cyril Hrubis
2024-10-16 13:48       ` Petr Vorel
2024-10-16 15:32         ` Cyril Hrubis
2024-10-16 16:17       ` Martin Doucha
2024-10-16 21:15         ` Petr Vorel [this message]
2024-11-01 12:11           ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241016211513.GA104519@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=mdoucha@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox