From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 49F3FA0032; Tue, 13 Sep 2022 19:24:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D364D4021D; Tue, 13 Sep 2022 19:24:30 +0200 (CEST) Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by mails.dpdk.org (Postfix) with ESMTP id F304940151 for ; Tue, 13 Sep 2022 19:24:29 +0200 (CEST) Received: by mail-pj1-f46.google.com with SMTP id o70-20020a17090a0a4c00b00202f898fa86so2574447pjo.2 for ; Tue, 13 Sep 2022 10:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Nndsn9D6FsazFCVZK8V7z0xB4RK2Jw5XaShez97WVCU=; b=M2xD1ZEC4+ZzFrFJJcK6i2bRRpJQNS+K+vBJTci5aKjP+eP5N9HUh6K3lb5ctIa+Eq uggvC2kMEsCgnzHNoXGoEoo3h4UTwZdKdjL6tIHhBZobMFGHrsqzqR8Pp3MU+tpxDIX2 ueMBTH3SeodbBy02XKz7p3Kpn6ivDaUrAKGKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Nndsn9D6FsazFCVZK8V7z0xB4RK2Jw5XaShez97WVCU=; b=f8VZ2RxfpAxGbd8lgK9xigCdUmuCSXhB/ivwvPoim+r+si77AfpkN2Jim+ktZYyfMR fdVvqJH7XfNbCgdl7Mw7D5iAUow50hlubhmPD16SlqMA6UeabxJTpAzH71ad1VDmnCVl WvYiPfPwiERaD+49iccsKcVISnO1cYU9VApdptQMJAqWKJxk+eHjUSTY6nJvuuzOGAi1 +CSJ39X6tUZtrfn8teEnwF35QBFnQMe7XsT6elrwTZz+yOTGhrsHhxiMrM3GfxqBwQIg V1uVVvzr9AzAJy3cxi2eTTejvOgN7Ina0qCxCTgi2woE8BHMTxav/gRToX1zKNqcIZ3G Nxlw== X-Gm-Message-State: ACgBeo1/79c61PCeSVCRbV9WzlKd/3T6CIiYDxvBmbdt7dJwO4JGilnh jgiDIk1zAGzdzF7uUQ71JOteaMeChgmdiScc7wCaNQ== X-Google-Smtp-Source: AA6agR6po04vfMbJu5m3YwhTkBgiVPWKjSBjeWWvUc+bq6kxqaBSrNXZ8BYrtRuLCQhUYvm8pgQQVvBJFLqFw/qPLeE= X-Received: by 2002:a17:902:c104:b0:176:e2fa:2154 with SMTP id 4-20020a170902c10400b00176e2fa2154mr32789635pli.98.1663089869112; Tue, 13 Sep 2022 10:24:29 -0700 (PDT) MIME-Version: 1.0 References: <20220728100044.1318484-1-juraj.linkes@pantheon.tech> <20220729105550.1382664-1-juraj.linkes@pantheon.tech> <20220729105550.1382664-5-juraj.linkes@pantheon.tech> <20220913144149.xbtomt2pzwywnodn@toster> In-Reply-To: <20220913144149.xbtomt2pzwywnodn@toster> From: Owen Hilyard Date: Tue, 13 Sep 2022 13:23:53 -0400 Message-ID: Subject: Re: [PATCH v4 4/9] dts: add ssh pexpect library To: Stanislaw Kardach Cc: =?UTF-8?Q?Juraj_Linke=C5=A1?= , Thomas Monjalon , David Marchand , ronan.randles@intel.com, Honnappa Nagarahalli , "Tu, Lijuan" , dev Content-Type: multipart/alternative; boundary="000000000000e0e6e505e892487d" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000e0e6e505e892487d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > On Fri, Jul 29, 2022 at 10:55:45AM +0000, Juraj Linke=C5=A1 wrote: > > > + self.session =3D pxssh.pxssh(encoding=3D"utf-8") > > + self.session.login( > > + self.node, > > + self.username, > > + self.password, > > + original_prompt=3D"[$#>]", > > + password_regex=3Dr"(?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. --000000000000e0e6e505e892487d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 29, 2022 at 10:55:45AM +0000, Juraj = Linke=C5=A1 wrote:
<snip>= ;
> +=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.session =3D pxssh.pxssh(encoding=3D= "utf-8")
> +=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.session.login(> +=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.node,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.username,
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 self.password,
&= gt; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = original_prompt=3D"[$#>]",
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 password_regex=3Dr"(?i)(?:password:)|(?:passphrase for key)= |(?i)(password for .+:)",
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 )
= > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0=C2=A0self.logger.info(f"Connection to {self.n= ode} succeeded")
> += =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.send_expect("stty -echo= ", "#")
> += =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.send_expect("stty colum= ns 1000", "#")
First of all, thanks for those chan= ges! Having DTS inside DPDK makes
test synchronization a lot easier. I&#= 39;m happy to say (unsurprisingly)
that it works with my RISC-V HiFive U= nmatched board like a charm.

Though there is a small issue with the lines above. They assume &qu= ot;#" as
the prompt sign, even though original_prompt was set to &q= uot;[$#>]". This
touches on two problems:
1. # is usually a r= oot prompt - is DTS assumed to be run with root
=C2=A0 =C2=A0privileges?= DPDK may (in theory) run without them with some permission
=C2=A0 =C2= =A0adjustment (hugetlb, VFIO container, etc.). If we assume DTS needs
= =C2=A0 =C2=A0root access, this has to be both documented and validated befo= re
=C2=A0 =C2=A0running the whole suite. Otherwise it'll be hard to = debug.

Around a year ago there were som= e attempts to get DTS to not require root. This ended up running into issue= s 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 cu= rrent version of DTS can probably run without root, but it will probably st= op working as soon as DTS starts interacting with PCI devices. Elevating pr= ivileges using pkexec or sudo is less portable and would require supporting= a lot more forms of authentication (kerberos/ldap for enterprise deploymen= ts, passwords, 2fa, etc). It is much easier to say that the default SSH age= nt must provide root access to the SUT and Traffic Generator either with a = password or pre-configured passwordless authentication (ssh keys, kerberos,= etc).=C2=A0

I agree it should be documented. = I honestly didn't consider that anyone would try running DTS as a non-r= oot user.=C2=A0
=C2=A0
2. Different shells use different prompts on different distros= . Hence
=C2=A0 =C2=A0perhaps there should be a regex here (same as with = original_prompt)
=C2=A0 =C2=A0and there could be a conf.yaml option to m= odify it on a per-host
=C2=A0 =C2=A0basis?

As far as customizing the prompts, I think that is doable via a configur= ation option.=C2=A0

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 ea= se 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 issue= s, which in my opinion are resources better spent on more in-depth testing = of DTS and DPDK.=C2=A0
--000000000000e0e6e505e892487d--