View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000142||apt-panopticon||Feature||public||2020-01-03 09:43||2022-10-14 01:09|
|Summary||0000142: Have it automatically drive decisions of what mirror is in or out of the DNS-RR including CC.|
|Description||<Evilham> anyway, if we delegate roundr.devuan.org to some devuany thing, which should be separated from the main DNS, I did a thing that is easily modifiable to fit the needs: https://weneeda.name/ |
<Evilham> so the general devuan.org zone: boring, static, manually managed
<Evilham> roundr.devuan.org: prone to automating, deb.devuan.org as a CNAME to deb.roundr.devuan.org gets both things in a way
<Evilham> so, for devuan, we'd have to do something that deals with info from apt-panopticon and the prometheus instance
<Evilham> what I'd ask you to add is RSA / SHA512 signing of a list of hosts you consider valid for the RR
<Evilham> with a timestamp :-)
<Evilham> and a random 32bit thing
<Evilham> basically, I think if we get the apt-panopticon data into the prometheus thing, we can send alerts to the DNS server and when that happens, have it trigger instantly an otherwise periodic check on your source file
<Evilham> and for that, we need to make sure that your source file is not tampered with
<Evilham> so, signing + timestamp + nonce are kinda a must
<onefang> I've already written a Nagios / Icinga plugin for alerts, though I'm happy to do your way to.
<Evilham> I don't mind either way tbh, as long as it's not noisy and robust
<onefang> Though that's more for running on the same computer, not sending to some other computer.
<Evilham> just a note that: if we do deploy something with this general line, it means that misbehaving / outdated mirrrors get removed from the pool automatically, that new mirrors get added after we update mirror-list.txt, ...
<onefang> Which is why I keep insisting we should discuss policy soon. B-)
<Evilham> policy about the RR? if it doesn't work it shouldn't be there :-)
<Evilham> I think that's all that matters
<onefang> Policy about "how many errors / warnings over how long a time qualifies / disqualifies for the RR". B-)
<Evilham> say, 60 seconds of being "bad" to go out and 300 of being "good" to go in and make it tunable, it's not an issue that we temporarily remove things from the RR if they are back in after they behave properly
<onefang> Oh, that's a different take on what I was thinking. B-)
<Evilham> :-p it's kind of simple really, everything on deb.devuan.org should work fine, if it doesn't it shouldn't be there
<Evilham> or there is a 1/N chance of hitting it and that's a bug
<onefang> Though now I have to get the tests to under 60 seconds, I've got it consistently just under one on mine, rrq's looks to be just over.
<Evilham> I just said 60 seconds, it doesn't have to be that :-D
<Evilham> it can be 2m of being bad, or 5, something that can be changed later
<onefang> I have tunable bandwidth arguments, the default is "medium", there's a "low" that's a lot quicker. 22 seconds on rrq's.
<Evilham> we'd have to check how it behaves since mirrors actually sync every 30m
<Evilham> so, worst case every once in a while pkgmaster would be alone in the RR for a few mins
<Evilham> this can be tested before deployment without delegating roundr.devuan.org
|Tags||No tags attached.|
In a nutshell -
Move the deb.roundr.devuan.org name server to something that can be automated, so apt-panopticon and Evilhams Prometheus instance can decide to add and remove IPs very quickly. It remains as a CNAME for deb.devuan.org.
Somehow alerts are sent to this thing that removes DNS records when mirrors drop below "good enough for the RR", or adds them when they rise above that limit. The alerts could be some new output module I write for apt-panopticon, Nagios / Icinga using the existing plugin, or some alert thingy from Evilhams Prometheus instance.
What "good enough" is can be tunable.
To avoid nasty people trying to screw with us, the alert has to be cryptographically secure if being sent between computers. (The VPS owned by rrq I just setup apt-panopticon on to avoid "server running it gets ludicrous speed" I doubt is secure enough for this.)
Think we will need to add a "DNS-RR" field to https://pkgmaster.devuan.org/mirror_list.txt, so we know which mirrors should be part of this automated to and fro.
[03:40:30] <bb|hcb> Next step (maybe) is to make that script to also generate more proper CC.deb.devuan.org resolvings, at least to keep the traffic at the same continent and spread the traffic on the mirrors instead on pkgmaster (where resources are quite limited at 250mbit/s)
[03:43:10] <onefang> Luckily I already added the CountryCode field.
[03:48:52] <bb|hcb> I was thinking about including the ipv4/ipv6 addresses in mirror_list.txt, so that resolving happens only at apt-panopticon, else with misconfigured resolvers both sides may use different views of the internet (not highly probable, though)
[03:52:18] <bb|hcb> Also some clarification on the semantics of Active and DNSRR fields - Active should mean that the mirror is good to use and DNSRR should mean that the mirror is configured and properly serving deb.devuan.org AND that the admin agrees to include it there
[03:52:23] <onefang> Then we would have to keep an eye on those and change them if needed.
[03:53:26] <onefang> That was already my idea for the DNSRR field.
[03:54:16] <onefang> So you are saying apt-panopticon updates https://pkgmaster.devuan.org/mirror_list.txt ?
[03:55:12] <bb|hcb> Isn't it? That was my undestanding
[03:56:41] <onefang> There's a master file on pkgmaster that I update manually, and a cron job that runs once an hour that does that currently.
[03:57:57] <onefang> /home/mirror-admin/mirror_list.txt
[04:39:11] <bb|hcb> Oops, I was thinking that this is auto updated...
[04:42:51] <bb|hcb> And about CC RR, one more field will be needed - DNSRRCC, because not all mirrors may want to be included or configured to serve the content...
[10:53:27] <bb|hcb> onefang: What are your thoughts about automatic update of the Active field in mirror_list.txt? Do you need help for that?
[10:55:10] <bb|hcb> Obviously maintaining some form of the mirror admin intent in DNSRR and/or DNSRRCC should happen manually
[14:38:35] <onefang> bb|hcb: That's one way to deal with things. I have long planned to automatically update the DNS-RR based on the three apt-panopticons voting on which mirrors are up.
[14:39:18] <onefang> If you are now using / planning on using mirror_list.txt to change DNS-RR, that'll work.
|2020-01-03 09:43||onefang||New Issue|
|2020-01-03 09:43||onefang||Status||new => assigned|
|2020-01-03 09:43||onefang||Assigned To||=> onefang|
|2020-01-03 10:04||onefang||Description Updated|
|2020-01-03 10:10||onefang||Description Updated|
|2020-01-03 10:21||onefang||Note Added: 0000262|
|2020-06-01 10:48||onefang||Note Added: 0000286|
|2020-07-16 17:01||onefang||Note Edited: 0000286|
|2020-07-16 21:50||onefang||Priority||normal => urgent|
|2021-06-15 11:32||onefang||Priority||urgent => high|
|2022-01-20 16:36||onefang||Note Added: 0000535|
|2022-10-14 00:50||onefang||Summary||Have it automatically drive decisions of what mirror is in or out of the DNS-RR. => Have it automatically drive decisions of what mirror is in or out of the DNS-RR including CC.|
|2022-10-14 01:08||onefang||Relationship added||parent of 0000446|
|2022-10-14 01:09||onefang||Priority||high => immediate|