--- Begin Message ---
On Sun, 21 Mar 2021 22:04:29 +0100
Harald Welte via tcpdump-workers <tcpdump-workers@lists.tcpdump.org>
wrote:
> My company sysmocom is running build and test infrastructure for
> osmocom.org, and we'd be more than happy to host those ARM build
> slaves in Germany. We also operate a number of rpi4 for jenkins
> build/test runs and as openbuildservice builders.
Hi Harald.
Thank you for the offer. For the operating systems specifics please see
below.
* linux-aarch64 — easy to install, tested with 64-bit Raspbian 10 and
64-bit Debian 11 snapshot. Tested on RPI3B and RPI4B, currently runs
on an RPI4B, can likely use other hardware and Linux distributions.
I've seen ARM servers with many CPU cores and SSDs, but so far on
paper only. Anyway, RPI4B performance is fine.
* linux-armv7l — same easy, tested with 32-bit Raspbian 10. Currently
runs on an RPI4B, but that's possibly not the right way to do 32-bit
ARM. Jan is looking if his spare 32-bit Pi can be set up for this.
* freebsd-aarch64 — easy to install on an RPI3B using FreeBSD 12.2,
since a few weeks ago easy to bootstrap on an RPI4B using FreeBSD
13.0-RC. Currently runs on an RPI4B.
* netbsd-aarch64 — possible to install using NetBSD 9.1 and RPI3B with
physical console (HDMI monitor + USB keyboard), as there is no SSH
access in the default image (AFAIR). No support for newer RPIs yet.
Currently runs on an RPI3B.
* openbsd-aarch64 — possible to install using OpenBSD 6.8 and RPI4B
with TTL serial console, RPI4-UEFI bootloader on the SD card and one
additional USB storage for the OS permanently plugged in. Currently
runs on an RPI4B.
As soon as the OS is up and I have the shell prompt, it does not take
long to configure the system (partly scripted) and to install the
worker (fully scripted). You can have a copy of a working SD card image
instead if that helps. On this note, most of the buildbot-worker
activity happens on a tmpfs mount.
One important thing to keep in mind is that the workers may end up
executing arbitrary commands when building a pull request
automatically. So it is best to keep them firewalled from internal
networks and not to keep any other important workload/data on the same
host. It might be possible to use some virtualisation means to isolate
the workers from the rest of the host, but please do not count on that
anytime soon unless you can do it yourself.
Let me know which ARM workers look feasible to you. If you can host
PowerPC workers instead or in addition to that, it would help too.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
