Re: debian-volatile mirrors
-----BEGIN PGP SIGNED MESSAGE-----
On 23-10-2007 17:14, Josip Rodin wrote:
> On Tue, Oct 23, 2007 at 12:32:07PM -0200, Felipe Augusto van de Wiel (faw) wrote:
> I'm filing an RT ticket to assimil... er... add you :)
Is there anything that I should read (besides webwml CVS)?
Documentations? Historical archives? Best practices? DOs and DONTs?
>>> Right now the Mirrors-from field isn't really used, it's just there for our
>>> own accounting purposes - it's good for analysis when its state differs from
>>> the one discovered by the mirror checker. It would be fairly easy (and
>>> probably desirable) to convert it to fields like Archive-upstream,
>>> Volatile-upstream, ...
>> I don't really know how they work, as already explained by
>> zobel the Mirrors-from where used by the push infrastructure, the
>> other fields were unknown to me, what I was doing is just trying
>> to keep Volatile Mirrors.masterlist using "good practices" IMHO
>> considering the existing and presented file format. :-)
> (In the meantime I actually went ahead and implemented that change above.)
I saw some commit messages talking about related info. :)
> In the private discussion in the meantime I realized that you actually kept
> private data in those fields, and that they went in the other direction -
> they documented from where the push comes and where it goes, whereas our
> existing field documented from where the downstream mirror actually rsyncs.
> The private data should stay private, and the other data can be generated
> from the DMC results which should be available soonish (I was still tying up
> some loose ends and this morning's run failed, the next one should succeed).
Thanks for the info.
Indeed, and I would like to send an e-mail to all Volatile
Mirror owner to let them know about our changes.
>>>> We have a push-mirror infrastructure and I added a
>>>> patch to use a different SSH port to prod servers, not sure
>>>> if Debian mirrors carry this patch or support this, I will
>>>> be happy to provide it again.
>>> You mean, patch to the documentation or?
>> I mean that some of the clients of the push network use
>> non standard SSH ports to get pushed, I added support for that
>> in our script, but AIUI, volatile.d.o will push the changes from
>> verdi.d.o which will be maintained by Volatile Team, so it is
>> still a different script. :-)
>> I had the impression that we are going to merge the
>> push infrastructure, then I realized that the Volatile archive
>> is on a different machine, with a different another dak instance.
> Yes. But we can still have the same people look at and maybe edit both,
> because it's essentially the same matter.
Hmmm... I don't think it's necessary (I'm not opposed
to it, either), but the script basically downloads the Masterlist,
find the servers that needs Prod and then runs the push (it comes
down to a shell loop to ssh $host $port).
My understanding is that we will maintain the Masterlist
in the cvs webwml and the verdi.d.o will download (or checkout)
the necessary file, parse it and push the servers. Do you think
it is important that the mirror team have access to that?
Right now, the infrastructure is not even on verdi it is
still on farm.ftbfs.de network. So we will need to do a few
* Migrate the push infrastructure to verdi
Some of our mirrors use very strict firewall rules, so
we need to let them know that we are changing from on
push server to another.
* Change the push infrastructure to use webwml Masterlist
I'm not sure how it works for already existing mirrors,
in volatile.d.n we ran the prodding after dinstall.
Right now, at the end of dinstall, verdi executes an
ssh command in another machines that actually does the
Maybe I'm lacking the understanding of how we do Debian
(not Volatile) does the pushes. Sorry if it looks like I'm a
little bit lost with regards to some parts, I'm just trying to
avoid duplicated working while trying to learn how to do or
implement it in "The Right Way (tm)".
I will bother Zobel and Andi to get some things running
on Volatile, since there are some small glitches that need to
be fixed/changed, hopefully, we can do it all together. :-)
Thanks for the help.
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----