#5886: need method for distributing urgent fixes... urgently ------------------------------+------------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 23 Alpha | Component: mash Resolution: | Keywords: meeting planning Blocked By: | Blocking: ------------------------------+------------------------------
Comment (by pfrields):
We had a meeting to kick this issue back into gear. Here are the notes from the public pad we used:
{{{ Requirements for quick fixes, 2016-Feb-24 Attending: dgilmore mattdm admiller pfrields dgregor
Imagine a quick fix needed for a Heartbleed/Shellshock type exploit -- q.v. https://fedorahosted.org/rel-eng/ticket/5886 Determine requirements for a solution and get the ball rolling toward implementing
Requirements: -- Barring utter breakdown of the internet, used once or twice a year. Not used frequently (so should be designed for infrequent, unfamiliar use.) -- Available to mere mortal users in the order of minutes rather than hours (meaning available on the user side?) Yes — after it's through QA, it should be basically immediately available for dnf install / update blinky in GNOME -- Seamless with normal updates processes for users (doesn't require extra steps before or after on end user systems) -- As few human bottllenecks as pragmatically and securely possible -- Need IPv6 connectivity to repository -- SOP for process (once figured out) -- include communication change
How do we make these fixes available for everyone? dgilmore: can't just mash a repo for this dgilmore: Need a tag in koji, an extra target in Bodhi, and we need to define a repo in our -repo RPM that will usually be empty but gets critical updates out by default admiller: Why not just have a special Bodhi marking for critical security updates? the new improved Bodhi *still* requires many more hours than reasonable to get content out to users When MirrorManager picks something up, it still has to be sync'd out -- hours or more pfrields: Can we do this with a primary location that is *not* mirrored, but also adds mirrored metalink if that fails under high load? dgilmore: Probably a location in kojipkgs mattdm: (does this risk killing kojipkgs?) pfrields: +1, needs to be aggressively cached and not too contentious dgilmore: Need IPv6 only connection, which we don't have in PHX2? mattdm: what about having 3-4 high bandwidth partners participate, and sync via push rather than pull? front end proxies are there, so having them front the repo would probably work Need lmacken input on how this would work in Bodhi, what's the size of that effort May need a separate product -- Bodhi only lets you do one F24 push at a time, so we might need one for e.g. F24-Security Need to restrict access somewhat for the *push* side -- the builds should be open to maintainer + provenpackager as usual Perhaps https://admin.fedoraproject.org/accounts/group/view/security-team + a few other trusted? Not sure if we want security team folks to have to interact with Bodhi twice a year and not know the process Cloud and other image rebuilds mattdm: important but a different scope admiller: the piece that's not fast is generating new two week atomic images (which are built nightly), which follows on the compose process. Generating the updates rpm-ostree is actually pretty quick so that people who already have Atomic Host installed will get updates quickly, but getting new install and cloud (AWS/qcow2) images would be slower (handful of hours vs handful of minutes). pfrields: need a document that describes decision tree for making new deliverables when required should include escalation points dnf: if cache is not old enough, you have to manually refresh What is GNOME limitation? dgregor: Don't see a need for this process to be dovetailed with Red Hat internally, different set of needs and constraints there AGREED: not a problem in this case; the approach is more or less dictated by the rest of the toolchain
ACTION: Paul - Set up meeting w/ dgilmore, lmacken to discuss Bodhi effort needed here and figure out any implementation problems might combine this with kfenzi to figure out hosting partner/b'width side Dennis -Talk with kevin to get concrete plan on hosting (see above?) Mattdm - Talk to Eric Christensen (sparks) about security team and other access to this process Paul -- find out how GNOME treats aging of repo metadata, hopefully same as dnf?
empty repodata du -hs /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/* 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/401dc19bda88c82c403423fb835844d64345f7e95f5b9835888189c03834cc93-filelists.xml.gz 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/6bf9672d0862e8ef8b8ff05a2fd0208a922b1f5978e6589d87944c88259cb670-other.xml.gz 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/77a287c136f4ff47df506229b9ba67d57273aa525f06ddf41a3fef39908d61a7-other.sqlite.bz2 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/8596812757300b1d87f2682aff7d323fdeb5dd8ee28c11009e5980cb5cd4be14-primary.sqlite.bz2 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/dabe2ce5481d23de1f4f52bdcfee0f9af98316c9e0de2ce8123adeefa0dd08b9-primary.xml.gz 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/f8606d9f21d61a8bf405af7144e16f6d7cb1202becb78ba5fea7d0f1cd06a0b2-filelists.sqlite.bz2 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/prestodelta.xml.xz 4.0K /mnt/koji/mash/updates/f23-updates- blank/f23-updates/x86_64/repodata/repomd.xml
Downloads on client should be 8-12k (good news is the "du" is misleading because that's just the minimum block size adding up) }}}
rel-eng@lists.fedoraproject.org
-
Fedora Release Engineering