New issue
Advanced search Search tips

Issue 737192 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Jan 10
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

autotest uses three different SSH binaries

Project Member Reported by grundler@chromium.org, Jun 27 2017

Issue description

We get inconsistent performance, variation in features supported, and it's just bad practice to use three different SSH binaries by autotest infrastructure:
  1) goobuntu (OpenSSH_7.2p2, OpenSSL 1.0.1f 6 Jan 2014)
  2) ubuntu (on some servers)
  3) chromium OS chroot (OpenSSH_7.3p1-hpn14v12, OpenSSL 1.0.2k  26 Jan 2017)

Can we force autotest to use the chromium OS chroot in all cases?

Mike Frysinger has made some good observations around running a "chroot" openssh binary outside the chroot:
   https://bugs.chromium.org/p/chromium/issues/detail?id=736151

If this isn't feasible, it might be useful to "step back" and consider how we might be able to align autotest server runtime with chromium OS chroot.
 
No, we can't use the chroot version everywhere. Autotest production servers don't have a copy of the chroot.

I expect a mixture of goobuntu (from drones, shards, etc that live on ganeti) and ubuntu (from devservers, which do use ssh for cros_flash purposes).
Goobuntu is going away in 2017 or early 2018. Goobuntu will be replaced with a "rolling release" model as implemented by "Debian testing" release.  Would trying to migrate everything to the same linux distribution be a better long term strategy?

Because of Goobuntu change, I see less incentive for using Ubuntu on devservers. Even if Ubuntu continued to be used, why couldn't the ssh binary be specified by Autotest?
Goobuntu is not currently available outside of corp, and some of our servers (like the devservers and builders) are outside of corp. We use Goobuntu for machines inside corp (drones and some other lab servers). This seems weird, but makes sense given the network architecture and security requirements.

The Goobuntu replacement will probably have similar restrictions.

Given that, the only realistic way to have the same SSH version everywhere is via the chroot, or via some other container mechanism. That's a real architectural change that would need a lot of thought, discussion, and deployment time.
Status: Archived (was: Untriaged)
Archiving P3s older than 1 year with no owner or component.

Sign in to add a comment