[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cdn.debian.net not working in Germany

ISHIKAWA Mutsumi (ishikawa@debian.org) wrote on 31 July 2010 12:47:
 >>>>>> In <19538.55557.46736.318089@fisica.ufpr.br> 
 >>>>>>	Carlos Carvalho <carlos@fisica.ufpr.br> wrote:
 >>> ISHIKAWA Mutsumi (ishikawa@debian.org) wrote on 30 July 2010 15:48:
 >>>  >>>>>> In <19537.59866.871270.311169@fisica.ufpr.br> 
 >>>  >>>>>>	Carlos Carvalho <carlos@fisica.ufpr.br> wrote:
 >>>  >>> Another cdn problem: In
 >>>  >>> http://lists.debian.org/debian-devel/2008/02/msg00700.html Araki says
 >>>  >
 >>>  >>> This CDN checks your hosts DNS query to retrive your national location.
 >>>  >>> [removed]
 >>>  >>> - This CDN checks debian rsync mirror process. If mirror site is mirroring, CDN hides this site. 
 >>>  >
 >>>  >>> This is not appropriate. Debian mirrors are required to update in a
 >>>  >>> way that guarantees coherence between packages and indices.
 >>>  >
 >>>  > I think you misunderstand.
 >>>  >
 >>>  > Yes, coherence between packages and indices on single site is
 >>>  >guaranteed, but coherence the debian tree between a mirror site and
 >>>  >another mirror site is not guaranted.
 >>> Yes but why is this relevant in this case? A client will only go to
 >>> one mirror.
 >  It is not true. You forget user need to run apt-get `update' and
 >  `upgrade (or install or so)'
 > For example,
 >  Site A and Site B is CDN member, user query for cdn.debian.net
 >  will be returned both Site A and B's IP (the query answer includes
 >  two IN A entries)
 >  When Site A's debian tree is newer than Site B's debian tree,
 >   * It is OK, both apt-get update and upgrade (or install or so)
 >     access to same IP, e.g apt-get update fetch from Site A and
 >     apt-get upgrade fetch from Site A)
 >   * It is not OK, when apt-get update and upgrade
 >     access to deffernt IPs, e.g apt-get update fetch from Site A
 >     and apt-get upgrade fetch from Site B. In this example stuation,
 >     Site A's Packages file is newer than Site B, some packages
 >     will not be able to download from Site B.

I agree that sending the client mirrors that are in different versions
is bad. My point is that this is unrelated to a mirror being in the
middle of an update.

I think cdn should only send mirrors that are up-to-date in relation
to the master, or at least in relation to the official country or
continent mirror (which are pushed by the master). This is checked by
the files in project/trace.

Reply to: