On Wed, Nov 12, 2025 at 01:44:33PM +0100, Mark Wielaard wrote: > Preparation for Sourceware services upgrades, migration and isolation > are in full swing! Come and learn about the setup of the future! > [...] > If you care about Sourceware infrastructure providing a worry-free, > friendly and secure software development environment for community run > core toolchain and developer tools projects then this day is for you!
For those that couldn't attend here is a summary: OSUOSL offered to replace our two smaller x86_64 container builder machines for builder.sourceware.org with one larger 2x28 cores (2x56 threads), 768GB RAM machine when osuosl migrates to their new data center later this year. The Sourceware Project Leadership Committee will decide on whether to provide a couple of fast SSD disks for it. OSL offered the same for some smaller GCC Compile Farm machines. Please do support OSUOSL if you can https://osuosl.org/donate/ Red Hat IT helps us by doing scans of our servers and services. We discuss findings and update public service crypto settings based on their recommendations. Sam proposed (and sent a patch) to always use ftpmirror and check gpg signatures against gnu-keyring.gpg for our container builders when building from source. We pulled in Yuri who was working on a variant of the build-many-glibcs.py script for ARM's autobuilders to do something similar. Several FSF tech admins joined to help investigate issues with ftp and ftpmirror blocks and URLs. Next we looked at the new server1 VM-first setup. The OS on the bare metal doesn't provide any services (or allow direct access). It is just there to host VMs, three already setup. debuginfod.elfutils.org, already in production, forge-stage.sourceware.org, ansible managed and a new sourceware VM, hosting everything from server2 which isn't already in a separate VM. All libvirt based. Then we specced out various other services that should go into their own VM, inbox, patchwork, buildbot, forge and bunsen. With possible service version upgrades. For network setup we have a /24 with 8 public addresses that can be staticly assigned to each VM (if we need more, we can get more). Backups are done through lvm snapshots. There was some debate on how to handle databases, should they be put in "backup mode", dumped regularly as .sql files? Full discussion notes at https://sourceware.org/sourceware-wiki/OpenHouse2025/ > Keep Sourceware worry-free, friendly and independent by donating > https://sourceware.org/donate.html support our fiscal sponser SFC > https://sfconservancy.org/sustainer and/or support OSUOSL for > hosting Free Software projects https://osuosl.org/donate/ > > Do you or your company want to sponsor Sourceware plans financially > https://sourceware.org/sourceware-security-vision.html#plans > donate hardware or services then contact us at [email protected]
