x/build: add doas package on NetBSD systems

[ianlancetaylor]

Go version

devel

Output of go env in your module/workspace:

N/A

What did you do?

#70702 reports that su asks for a password on some FreeBSD systems, causing the runtime test TestSUID to fail and leaving the terminal in a broken state. Using the doas command with the -n option avoids this problem. doas is available as a separate package on FreeBSD and perhaps also NetBSD. Let's add it to the builders, and switch the test to use it. It's OK to run the test on systems where there is no doas command; the test will be skipped.

What did you see happen?

/bin/sh: doas: not found

What did you expect to see?

A passing test.

CC @golang/release

[dmitshur]

Now that #61095 is nearly done, at least for the freebsd-amd64 builder, I think this should be a matter of adding the right package to this line and rebuilding the image.

CC @mknyszek.

[mknyszek]

I don't mind doing this but I'd like to get the LUCI builder out the door first and in a stable state before updating the image yet again.

[mknyszek]

I rebuilt the image with doas installed and redeployed it.

[gopherbot]

Change https://go.dev/cl/634336 mentions this issue: env/freebsd-amd64: install doas

[ianlancetaylor]

Thanks!

[mknyszek]

Ah, perhaps I closed it prematurely. I didn't do anything for NetBSD, but it's also not ported to LUCI. Might be similarly easy to update. Updating the title, reopening, and leaving for the next release rotation person.

[gabyhelp]

Related Code Changes

• runtime: in TestSUID use doas on FreeBSD

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dmitshur]

There are LUCI builders for netbsd/arm and netbsd/arm64 ports (#63698 and #63614). They're remote, so this change is something their builder owner can consider applying (CC @bsiegert).

[bsiegert]

The NetBSD LUCI builders (arm and arm64) now have doas installed. But at the moment, there is no config file, so it is disabled. I am hesitant to open full root access to the swarming user.

On the other hand, these systems also have sudo installed already, since the LUCI infrastructure uses it to run reboot after a failed test. So perhaps having NetBSD use the sudo branch that's already there for Darwin would be useful. What do you think?

[ianlancetaylor]

@bsiegert See the discussion on #70702, which suggests that doas is better because it can be told to not ask for a password.