<snip>
> >
> > 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 .+:)",
> > > + )
> > > + [1]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).
> >
> > [Honnappa] One of the feedback we collected asks to deprecate the use
> > of clear text passwords in config files and root user. It suggests to
> > use keys and sudo. It is a ‘Must Have’ item.
> >
> >
> > I agree it should be documented. I honestly didn't consider that anyone
> > would try running DTS as a non-root user.
> >
> > [Honnappa] +1 for supporting root users for now and documenting.
> >
> >
> > 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.
> >
> > [Honnappa] +1 for using just bash, we can document this as well.
> >
>
> I would agree overall. Just supporting one shell is fine - certainly for now.
> Also
> completely agree that we need to remove hard-coded passwords and ideally
> non-root. However, I think for the initial versions the main thing should be
> removing the passwords so I would be ok for keeping the "root"
> login requirement, so long as we support using ssh keys for login rather than
> hard-coded passwords.
I would be for dropping support for the hard-coded passwords completely.
Setting up the password-less SSH is straightforward (not sure if you meant the
same).
>
> /Bruce
