Control: reopen 914852 Hallo, * Osamu Aoki [Fri, Apr 23 2021, 02:35:08PM]: > control: unmerge 986356 > control: merge 986356 954904 > control: retitle 954904 Support SRV record > control: retitle 986356 Support SRV record > control: clone 986356 -1 -2 > control: retitle -1 Add cdn-fastly.deb.debian.org to debvol_mirrors.gz > control: tags -1 patch > control: retitle -2 Truncated InRElease file > control: severity -2 normal > thanks
I am loosing track of this mess and I think I have closed on of this issue with the latest experimental release by mistake. > Although > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914852 > is likely caused by the same root cause, let me not get too agressive. > So I am unmerging it. But merging keep 2 bugs together. Okay. Still, wrong issue was hit, sorry. > As I grep the source for "SRV", I do not see it in apt-cacher-ng > source. So I am faily sure apt-cacher-ng doesn't support SRV record. > > https://en.wikipedia.org/wiki/SRV_record > > APT is also written in C++ and it has: > apt/apt-pkg/contrib/srvrec.cc > apt/apt-pkg/contrib/srvrec.h > to support SRV record from 2015. > > It explains as: > DNS SRV record support in apt > ============================= > > Apt supports a subset of the DNS SRV server records protocol as > described in [RFC 2782](https://tools.ietf.org/html/rfc2782) for > service discovery. > > Before connecting to the requested server APT will send a SRV > record request of the form `_$protocol._tcp._$host`, e.g. > `_http._tcp.ftp.debian.org` or `_http._tcp.security.debian.org`. This is ongoing implementation. I switched the code to libc-ares which has SRV support too. However it's not happening automatically (I need to implement a bit of code which does similar considerations as APT) so it is currently not utilized, also because I don't have a good test base to implement it. For deb.debian.org it seems to be pointless because CNAME does the job ATM, or am seing things wrong here? $ host -t SRV deb.debian.org deb.debian.org is an alias for debian.map.fastlydns.net. $ host -t CNAME deb.debian.org deb.debian.org is an alias for debian.map.fastlydns.net. > If the server sends SRV records > as a reply APT will use those to connect to the server(s) in > this reply. It will honor the `priority` field in the reply. > > However it does not implement the `weight` algorithm as described > in RFC 2782. It will use an equal weight for each server of the > same priority. > > If connecting to a server fails APT will retry with the next one > and remove the server from the list of valid servers for this > session. > > Merging this part of code from apt to apt-cacher-ng should fix issues > from the root cause. I am afraid some repos such as one from Ubuntu > may be using the similar configuration. So other bugs may be solved > too. > > Fixing this may fix truncated file problem too. (I don't know) File truncation is likely to be a bug somewhere deep in the downloading code. I tried to find a workaround for the low hanging fruits in 3.6.3 but I am not sure whether it was doing it right. Another issue I have found is with the connection closing code which was not done right and could potentially kill open filehandles or even causing unrelated activities to reuse the ID, therefore maybe even damaging data. This should explains all that "bad file descriptor" issues. I am going to prepare a backport of the changes from the experimental release into stable-proposed-updates but the timing is very unfortunate. > I also cloned this bug to make different issues separate. > > Since without adding cdn-fastly.deb.debian.org as attached file, it > waste cache space if the user uses it in chroot etc.. Since it is > small gz file I atach fixed file itselg here and mark this bug as > patch. This goes to -1 cloned bug. First, the file you sent is generated, so patching it is not okay. Second, I am not sure whether I can reproduce the original issue. Means: for me, using deb.debian.org as source simply works and the last time I checked it was transparently going to fastly service, no extra hops there. Best regards, Eduard.
