>
> On Fri, Jul 29, 2022 at 10:55:45AM +0000, Juraj Linkeš wrote:
> <snip>
> > + self.session = pxssh.pxssh(encoding="utf-8")
> > + self.session.login(
> > + self.node,
> > + self.username,
> > + self.password,
> > + original_prompt="[$#>]",
> > + password_regex=r"(?i)(?:password:)|(?:passphrase
> for key)|(?i)(password for .+:)",
> > + )
> > + self.logger.info(f"Connection to {self.node}
> succeeded")
> > + self.send_expect("stty -echo", "#")
> > + self.send_expect("stty columns 1000", "#")
> First of all, thanks for those changes! Having DTS inside DPDK makes
> test synchronization a lot easier. I'm happy to say (unsurprisingly)
> that it works with my RISC-V HiFive Unmatched board like a charm.
> Though there is a small issue with the lines above. They assume "#" as
> the prompt sign, even though original_prompt was set to "[$#>]". This
> touches on two problems:
> 1. # is usually a root prompt - is DTS assumed to be run with root
> privileges? DPDK may (in theory) run without them with some permission
> adjustment (hugetlb, VFIO container, etc.). If we assume DTS needs
> root access, this has to be both documented and validated before
> running the whole suite. Otherwise it'll be hard to debug.
>
Around a year ago there were some attempts to get DTS to not require root.
This ended up running into issues because DTS sets up drivers for you,
which requires root as far as I know, as well as setting up hugepages,
which I think also requires root. The current version of DTS can probably
run without root, but it will probably stop working as soon as DTS starts
interacting with PCI devices. Elevating privileges using pkexec or sudo is
less portable and would require supporting a lot more forms of
authentication (kerberos/ldap for enterprise deployments, passwords, 2fa,
etc). It is much easier to say that the default SSH agent must provide root
access to the SUT and Traffic Generator either with a password or
pre-configured passwordless authentication (ssh keys, kerberos, etc).
I agree it should be documented. I honestly didn't consider that anyone
would try running DTS as a non-root user.
> 2. Different shells use different prompts on different distros. Hence
> perhaps there should be a regex here (same as with original_prompt)
> and there could be a conf.yaml option to modify it on a per-host
> basis?
As far as customizing the prompts, I think that is doable via a
configuration option.
As far as different shells, I don't think we were planning to support
anything besides either bash or posix-compatible shells. At the moment all
of the community lab systems use bash, and for ease of test development it
will be easier to mandate that everyone uses one shell. Otherwise DTS CI
will need to run once for each shell to catch issues, which in my opinion
are resources better spent on more in-depth testing of DTS and DPDK.
