> To: Mike Long <mike.long@analog.com>
> cc: kenh@cmf.nrl.navy.mil, current-users@NetBSD.ORG
> Subject: Re: sup-server brokenness...
> From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@HeadCandy.com>
>
> As far as I know, *official* mirrors have always had unrestricted
> access through a different (confidential) sup port. They don't
> compete with users for connections. We certainly did at
> ftp.iastate.edu (but we only mirrored, we didn't serve sup
> connections). Sup mirrors should be up to date by now if they were
> configured correctly to begin with.
Some things:
1) could someone post a list of official mirrors which offer sup
access, preferrably with indication of whether they currently
are up-to-date.
2) that in addition to the collections we already have, these be
added: bin, sbin, usr.bin, usr.sbin, lib, libexec, share,
covering these directories under src, and miscsrc covering the
rest (distrib, etc, regress). That way I wouldn't have to
sup down the 'src' collection, which is near-impossible to get
without something crashing midway. I have had this type
of problem almost every time I had to get the full src package
(now it was SUP: Invalid message count -1 midway through),
also before the current rush of problems.
3) That after the 1.1 release is out, that 'core' take a brain-
storming about replacing sup with something else. These are
the problems I see with sup:
a) When sup'ing from the master, there is no indication of
when the database was completely updated last, or what
sub-collections exist, or what their configuration files are.
b) When sup'ing from a mirror, there is no indication of
when the slave was updated. Really we want to get the
latest timestamp from the master (the one that doesn't exist in
paragraph a) above) which was last successfully transferred to
the slave.
c) There's no easy way to maintain the same collections on
mirrors as on the master (well it could be done, by ftp-ing
the configuration files and running some script on them).
I do this manually for the moment.
SUP has worked mostly OK for me, so don't take this as a flame,
just suggestions.
If the master sup site is fast and reliable, these issues
aren't so pressing, but once it is down for a while things
get ugly, with lots of people wanting to sup at the same time
from the master.
For those who are in Scandinavia (or for that sake elsewhere)
and need a sup mirror you are free to use ours, but - alas - it is
yet not updated with the src package.
Here's a supfile sample for sup'ing from our mirror:
current-mirror release=ksrc-common host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=ksrc-i386 host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=src host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=doc host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=othersrc host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=games host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
current-mirror release=gnu host=skarven.itea.unit.no use-rel-suffix backup delete base=/usr prefix=/usr hostbase=/supmirror
This should have the same release= possibilites as sup.netbsd.org
except for domestic, and is maintained via cron.
Your friendly Norwegian NetBSD fan,
- Arne H. J.