Follow-up Comment #11, sr #111374 (group administration): Thanks for shedding some light on the difficulties, Bob.
At 2026-02-05T18:37:55-0500, Bob Proulx wrote: > Follow-up Comment #10, sr #111374 (group administration): >> One of the cgit mirror sites was stale for groff by about two whole >> weeks! > > Anything I say here won't help my case. I know I should just stand up > and own up that the mirrors were stale. And I will do that because I > had one job and that was to keep the mirrors in sync and clearly that > failed. Somehow I get the feeling that you have several more jobs than just that one. :) > But the logs at the time only showed that the mirror was stale by > about 4 days not 2 weeks. Why might that be different? I think git > may have fooled things here because if one commits locally then that's > the date. Then a few days later that is pushed and the data the git > log shows is the date of the commit not the push. So sure the log may > show the last commit to be 2 weeks ago but that is not a direct > insight into how long the mirror has been since the last successful > mirror sync. But I had one job and when that broke down it is still a > fail. Sorry! Is rsync not a good solution for syncing Git repos for some reason? Or... > Fortunately git when fetching will do the right thing. And I counted > upon that in the design of things. If a mirror is behind and git is > asked to fetch from it then nothing happens. Later when git is asked > to fetch and it hits an updated mirror then of course it will fetch > the new bits. As the RR-DNS rotates around through the addresses > things will work out for the CI/CD automated systems. ...is this a matter of the cgit/Web front-end not looking in the right place to determine that the repository has been updated? I think you get into this issue below but I don't completely follow it. (This doesn't mean you have to explain it again/better.) > How does Round-Robin-DNS work? Yes as you surmise there are > completely independent mirror systems running in parallel. There are > currently 7 systems with two more in the queue to be added. It's > growing to be somewhat of a large collection to manage. The primary > is the upstream system that is used for git push. The mirrors shield > the primary from the load from the AI Scraper bots and DDOS attacks. > > RR-DNS is only somewhat randomly distributed. It depends upon client > implementation. Every DNS query will rotate through the list of > addresses. But clients such as web browsers will cache the DNS lookup > and therefore stick with one address rather than rotate through the > list. Oh, lovely. Goodbye, separation of concerns! One of the problems with the Web being a "platform" is that people start to believe it, and embark on NIH projects. Similar to when a new programming language comes down the pike, so everything has to be rewritten in Java/C#/JavaScript/Go/Rust. 'Cause that gets you way more cred than having a good FFI story or stable ABIs. Who needs stability when you can have "velocity" and 759 statically linked dependencies?[1] > There are other limitations. The technique is somewhat more > thoroughly described on Wikipedia. > > https://en.wikipedia.org/wiki/Round-robin_DNS > > The advantage is that it is a completely independently distributed > technique. There is no other fully independent distributed technique > available to us to use with standard servers, networking, and DNS. > Vendors such as CloudFlare and Akamai use stronger infrastructure > methods of distribution which are not readily available to us. So even > though RR-DNS is not without drawbacks it is the best system readily > available to us. I have no complaint about RR-DNS per se. It sounds like I have a beef with (a) my browser maintaining its own DNS cache and (b) whatever about TLS certification makes it hard/wrong/stupid to associate IP addresses with them. >> I'm not seeing any hostname at the top of any cgit pages, and don't >> remember having ever seen it. Also, I would expect such a hostname >> in the footer: > > There are only a few options available when using cgit and one of them > is the cgit root-desc string. So I embedded the hostname in that > string. It's not perfect but it is at least a clue. Here is an > automated way to print that string. This will show the mirror that is > being queried for each wget run. > > wget -O- -q https://cgit.git.savannah.gnu.org/cgit/ \ > | grep cgit.browser Thanks! > Since wget does not cache the DNS lookup it will perform a new DNS > query each time. It is operating as git itself will operate. It will > rotate through the RR-DNS address list. The web browser such as > Firefox, Chromium, others will cache result though and stick with one > until the cache expires in the browser. > >> ... this didn't work due to HTTPS default and inappropriate or >> missing SSL certificate matches > > When looking at git-daemon cloning that is the easiest way to probe > individual IP addresses. For example picking a single address from the > list can be cloned from a selected mirror like this. > > git clone --depth=1 git://15.204.9.231/test-project.git > git clone --depth=1 git://"[2604:2dc0:202:300::5d3]"/test-project.git > > Don't fixate on that IP address. It's dynamic. That one in particular > is going to be removed from the pool soon. But it should be online > today. That's okay. I perceive the nature of the technique, I think. [snip] > I don't know what else to add here so I am just going to post this and > keep working on things. I appreciate your efforts, and your elucidation of the challenges involved. When I post a notification of some kind of service outage, I typically intend it as a heads-up in case it's an issue that people haven't noticed yet or is somehow affecting only me. Of course I love it when problems are resolved quickly, but not all of them can be. The oldest Savannah tickets in the groff group sit there and mock me... _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/support/?111374> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
