[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Next team meeting: 2022-10-12 20:00 UTC



Hello,

Here are my notes from today's meeting.

systemd-tmpfiles for /var
=========================

We discussed Bastian's proposal [1], to use systemd-tmpfiles to manage /var.
The eventual goal is to support trusted systems, where installed packages can
be meanigfully authenticated before execution.  Currently, secure boot does not
help validate userspace.  This goal was discussed at a recent meeting in Berlin
- Bastian said that more detail should be on the way.

[1] -  https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/58

changing how we build images
============================

We discussed Bastian's proposal [2], to replace FAI since we are only using a
small bit of it's functionality.  

The two main benefits discussed:
- eliminate pre-allocated storage: currently, we must pre-allocate a disk image
  ahead of time.  The bulid could be more flexible if it could ust build in a
  directory.
- unprivileged builds: loop mounts require root access, and are not namespaced,
  so unprivileged builds aren't currently possible.  Unprivileged builds would
  be safer for folks that might build on a non-dedicated system (e.g. their
  laptop), and could enable building in a container.


The two main costs:
- FAI is mature: if we replace FAI with something custom, we are likely to hit
  bugs in our reimplementation.
- FAI is documented: having documentation makes it easier for new developers to
  learn and modify our build process.  We'd need to spend time writing good docs.

[2] - https://salsa.debian.org/cloud-team/debian-cloud-images/-/issues/55

mirror team syncproxy for aws
=============================

The mirror team is looking for syncproxies in AWS.  We can provide this, but
we'd like to see if we can coordinate on this - our mirror plans will also
require syncproxy in AWS.  It'd be nice if we could share one set.  Noah is
going to reach out to the mirror team to discuss.


ec2 classic in legacy account
=============================

We received a warning from AWS that the legacy account will be losing EC2
classic, and there might be systems running that environment.  Noah took a
quick look around and was unable to identify any relevant VMs.

Also: the message was ambiguous, it may have meant that EC2 Classic had been
gone for some time.  So if you have a very old AWS system that you're missing,
this might be the cause of your issue.


Thanks for the time,
Ross


Reply to: