Hi, We have several forms of non-Koji internal builds: 1) COPR (the most visible) 2) http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/ (this could be a COPR) 3) rpm-ostree: http://rpm-ostree.cloud.fedoraproject.org/#/ Now, I recently was allocated a new atomic01.qa.fedoraproject.org server dedicated to rpm-ostree composes, and I'm happy to announce I now have it composing trees: fedora-atomic/rawhide/x86_64/server/docker-host => 175510ab77ef39ec6000db2745c70444d55957e38c5ff28f890237e1f012ea5e fedora-atomic/rawhide/x86_64/workstation/gnome/core => b6f3f3b53ef957c71e8d8bdc36c35519888d4177bf6a582ba37e33416ff84216 But it's on the QA network, and so I can't just serve the content directly from it. Nor would I want to have the compose server doing double duty as a static webserver anyways. I could just rsync this content to the current rpm-ostree.cloud.fedoraproject.org, but there are a few issues with that: 1) It's a one off instance in the fedora cloud with no backup/monitoring 2) No redundancy 3) No tuning for static webserving 4) Most critically, no TLS COPR only relatively recently gained TLS, which is fundamentally necessary for retrieving arbitrary executable code that runs as root. But COPR also (from what I understand from <puiterwijk>) is just one machine. What do you think about investing in having e.g. altcdn.fedoraproject.org be a load-balanced static webserver farm protected by TLS that could be written to by a trusted subset of non-Koji build/compose tooling? "altcdn" is the first thing that came to mind offhand for a name, feel free to pick others =) We'd need to determine the writing process; could be rsync-over-ssh access to specific subdirectories gated by ssh key? Something else? _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
