Use and rules of debian.cloud
Hi folks
I propose the following initial use and associated policies for the
domain debian.cloud.
## deb.debian.cloud
Provides Debian mirrors, possibly limited, similar to deb.debian.org.
Each provider gets a subdomain, which should be used in the apt config.
Currently assigned are:
- azure
- aws
Vendors are only eligible if the mirrors and images are somewhat
controlled by Debian.
>From Bookworm, vendors will be able to provide default mirrors directly
via vendor data to cloud-init.
Only one level is allowed, aka "vendor" and "vendor-special", not
"special.vendor". So in theory one certificate "*.deb.debian.cloud"
will support all names.
We need to look how we can use deb.debian.org as last resort fallback.
Fastly requires explicit config of the domains, which is quite possible,
as they support wildcards. But supporting HTTPS for this case will be
not nice at all.
## deb-backend.debian.cloud
Records pointing to the HTTP access to the backend resources at the
given provider. Can be either CNAME or address records.
Currently assigned are:
- azure -> CNAME debian-archive.trafficmanager.net
- aws -> CNAME something.cloudfront.net
## infra.debian.cloud
Internal infrastructure services. For services the base name is usualy
the HTTPS ingress point (a load balancer/ssl offloader), if such thing
exists. Subdomains are used for other ingress points.
Currently assigned are:
- vault (ssh.vault)
- mirror-azure (ssh.mirror-azure, push.mirror-azure)
Those services need to be maintained at least in conjuction with the
cloed team and either for internal or Debian use.
Regards,
Bastian
--
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown
Reply to: