On Tue, Sep 20, 2022 at 11:25 PM Honnappa Nagarahalli
<honnappa.nagaraha...@arm.com> wrote:
>
> <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
>
>
> I think the question is whether there are any platforms/devices that should
> be tested by DTS that do not support passwordless SSH. Right now, the
> community lab is using SSH keys for everything. If Intel also doesn't need
> passwords, then it's up to the community whether to support them at all. It
> does make it a lot easier on DTS if we can just require that the active
> OpenSSH agent can log into all of the systems involved without a password.
> This would also make it easier to enable AD authentication for Windows.
>
> [Honnappa] Jerin, Hemant do you have any concerns for your platforms
> regarding this?
No. We are using passwordless SSH in our CI testing framework.
