[WBEL-devel] I'm not dead yet. :)

[John Morris]

Sorry about dropping out for a bit, been on a deployment deadline death
march followed up by a Thanksgiving roadtrip with <24 hour notice of the
change of plans. Ended up staying with folks who only had a cellphone so
no net for six days. (Yes I am still twitching spasmodically from
withdrawal.)

All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has
caused I'm going to hold on hatching that pending a bit more inspection
later tonight.

[John Morris]

Sorry about dropping out for a bit, been on a deployment deadline death
march followed up by a Thanksgiving roadtrip with <24 hour notice of the
change of plans. Ended up staying with folks who only had a cellphone so
no net for six days. (Yes I am still twitching spasmodically from
withdrawal.)

All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has
caused I'm going to hold on hatching that pending a bit more inspection
later tonight.

[John Morris]

Sorry about dropping out for a bit, been on a deployment deadline death
march followed up by a Thanksgiving roadtrip with <24 hour notice of the
change of plans. Ended up staying with folks who only had a cellphone so
no net for six days. (Yes I am still twitching spasmodically from
withdrawal.)

All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has
caused I'm going to hold on hatching that pending a bit more inspection
later tonight.

[Jon Lewis]

Post by John Morris
All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has

What is the "primary site"?...or is that a closely guarded secret to keep
it (the library?) from being overrun by mobs of WBEL users who should be
using the mirrors?

I'd really like to setup a public mirror of WBEL, but I'd rather not
mirror from a 3rd party mirror (like NCSU). Is NCSU the only mirror that
talks to the primary site?...making them the tier 1 mirror that all other
mirrors have to mirror if they want the most authoratative source they can
get?

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

[Karanbir Singh]

Post by John Morris
Sorry about dropping out for a bit, been on a deployment deadline death
march followed up by a Thanksgiving roadtrip with <24 hour notice of the
change of plans. Ended up staying with folks who only had a cellphone so
no net for six days. (Yes I am still twitching spasmodically from
withdrawal.)

Phew! welcome back to the living world.

Is there anyway that a sort-of-status update might be passed onto the
mail list + website in such situations ? Is there anyone else you can
call on the phone and ask them to post msgs to indicate that John is
still in circulation ?

I would be happy to offer my phone number to be used in such situations...

Post by John Morris
All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has
caused I'm going to hold on hatching that pending a bit more inspection
later tonight.

What exactly is the issue with the httpd package ? Is it just the Redhat
logo / report ?

[Ben Mohilef]

Content-type: Multipart/Alternative; boundary="Alt-Boundary-23456.17183221"

--Alt-Boundary-23456.17183221

Post by Karanbir Singh
What exactly is the issue with the httpd package ? Is it just the
Redhat logo / report ?

I built httpd-2.0.46-44.ent from the RH source and installed the
resulting rpms. The only customization I did after install was to put
in our own /var/www/error and /var/www/icons files. The RH logo
doesn't seem to appear anywhere. Of course, I didn't do a very
exhaustive check, so I may have missed a RH logo somewhere. In
any case, the updated web server works quite well.


--Alt-Boundary-23456.17183221 <?xml version="1.0" ?><html> <head> <title></title> </head> <body> <div align="left"><font face="Arial"><span style="font-size:10pt">On 2 Dec 2004 at 15:52, Karanbir Singh wrote:</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">&gt; What exactly is the issue with the httpd package ? Is it just the</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">&gt; Redhat logo / report ?</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">I built httpd-2.0.46-44.ent from the RH source and installed the
resulting rpms. The only customization I did after install was to put
in our own /var/www/error and /var/www/icons files. The RH logo
doesn't seem to appear anywhere. Of course, I didn't do a very
exhaustive check, so I may have missed a RH logo somewhere. In
any case, the updated web server works quite well.</span></font></div>
<div align="left"></div>
</body>
</html>

--Alt-Boundary-23456.17183221--

[Karanbir Singh]

Post by Ben Mohilef
Content-type: Multipart/Alternative; boundary="Alt-Boundary-23456.17183221"
--Alt-Boundary-23456.17183221

Post by Karanbir Singh
What exactly is the issue with the httpd package ? Is it just the
Redhat logo / report ?

I built httpd-2.0.46-44.ent from the RH source and installed the
resulting rpms. The only customization I did after install was to put
in our own /var/www/error and /var/www/icons files. The RH logo
doesn't seem to appear anywhere. Of course, I didn't do a very
exhaustive check, so I may have missed a RH logo somewhere. In
any case, the updated web server works quite well.

What does the server report itself as / Version info from the server

- KB

[Ben Mohilef]

White Box fixes - Fixed for WB's different buildroot (not /usr/src)

The redhat src rpm for 2.0.46-44.ent installed normally in
/usr/src/redhat when we built it in mid November. Didn't build 46-40
so I don't know about that revision.

this .spec, index.html, powered_by*, renaming - and twiddling
httpd-*redhat.patch, certwatch.c and certwatch.xml.

Yes, these are RH identifiers which need to be pulled in public
distributions such as WB. However, for private distributions (such
as I am using) they seem to work jest' fine.

I'll try to drop this one and the most recent kernel & openmotif
packages soon.

Thanx from all of us WB users.

BTW, the new kernel builds nicely and has no untoward effects at
least in the athlon, smp-athlon and i686 flavour. [Unfortunately, a
new kernel means rebuilding nvnet.o and slusb/slmdm drivers
which are never included in unsupported. I am no longer a fan of
nvidia.]

regards,

ben

[John Morris]

Post by Jon Lewis

Post by John Morris
All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has

What is the "primary site"?...or is that a closely guarded secret to keep
it (the library?) from being overrun by mobs of WBEL users who should be
using the mirrors?

Well since I suspect anyone who is reading -devel could figure it out,
http://www.whiteboxlinux.org/pub will get you to it via http. But
remember that it is at the end of a single T-1 so don't expect a lot of
throughput.

Post by Jon Lewis
I'd really like to setup a public mirror of WBEL, but I'd rather not
mirror from a 3rd party mirror (like NCSU). Is NCSU the only mirror that
talks to the primary site?...making them the tier 1 mirror that all other
mirrors have to mirror if they want the most authoratative source they can
get?

That is the current situation. Clearly, after catching up email and
seeing the chaos that erupted while I was away, something more redundant
is needed. Shortterm it is clear a second mirror needs to pull directly
from here and the rest of the mirrors need to be divided between those, so
a failure on one will still leave half of the mirror sites with valid
data.

Idea #1 would be to have a reliable european site begin to update via
rsync from here and have the other european mirrors pull from them. That
means less traffic on longhaul links when things are working but will
throw a LOT of transatlantic traffic when something goes wrong.

Idea #2 of course is to randomize who pulls from who with the obvious
advantages and disadvantages.

Is there a consensus as to which way would be best?

Longer term I see a need for some sort of cron job that checks the mirrors
and rewrites the up2date mirror lists in
http://whiteboxlinux.org/up2date-mirrors with only ones that have the most
complete packages. I can see a fair amount of thought going into that
little puppy to handle as many of the pathological cases as possible. And
considering how often Fedora's mirror system still falls down, perhaps it
can be made general purpose enough they could benefit from it?

A few ideas to get things started....

It should pull a file list from each mirror and compare them to the prime.
Some sort of metric needs to be calculated for each mirror. Then taking
into account the average bandwidth of each mirror and a guess of the
current WBEL traffic a list gets built starting with the best site and
adding in less complete ones until enough are included to cover the
expected load or just add all of them if they are complete.

Some obvious problems with that scheme are:

1. There is currently NO feedback from mirrors as to how much traffic
they have served.

2. This means there is no practical way to even guestimate average
aggregate bandwidth needed even if up2date traffic could be seperated from
.iso pulls, etc.

3. Calculating a completeness metric would be tricky. A site with a .hdr
file and no .rpm doesn't have the goods, but what if they are only missing
the .src.rpm? What if they are only missing the very latest updates but
have a boatload of bandwidth? What if files in the base distro are
missing for some reason? Once I get around to populating the extras
directory are they as important as updates?

Of course in a perfect world the files would get regenerated on the fly as
a .cgi and lookup the source IP and prefer mirror sites close to it but
that is just a dream since I doubt our server would handle that load and
those sort of detailed IP maps are probably too expensive.

[Jon Lewis]

Post by John Morris
Well since I suspect anyone who is reading -devel could figure it out,
http://www.whiteboxlinux.org/pub will get you to it via http. But
remember that it is at the end of a single T-1 so don't expect a lot of
throughput.

Funny thing is, when I got this message, I was already in the process of
setting up our mirror (whitebox.atlantic.net). When I finished and
started comparing things to the NCSU one, I noticed some minor issues.

Both the 'home site' (www.whiteboxlinux.org) and NCSU seem to have their
3.0/en/os/i386 directories based on the original release. Before noticing
this, I chose to base mine on the liberation-respin1 iso files. I don't
know if thats going to cause problems for anyone. I don't expect it
would, but AFAIK, all my installs were done from respin1, so I don't have
a good/easy way to test this.

A related problem is the system I used for the mirror is running an older
Red Hat release that didn't have yum and apparently can't have the latest
yum without some major work being done (upgrading rpm and a bunch of
related apps and libs). Using yum-1.0.3, I was able to generate the
headers directory (since the isos don't include those files), but that
version of yum won't generate headers for srpms, so my
/3.0/en/os/i386/headers dir lacks srpm headers, which I assume only breaks
installation of srpms via yum. Probably not a huge deal.

For some reason both the home site and NCSU lack pretty much all the files
from the first iso which would normally be in 3.0/en/os/i386/dosutils. I
copied those files from the iso into my mirror.

At the moment, I have it setup to rsync updates from NCSU every 2 hours.
I see no reason to run rsync against the distribution files, since it
appears they never change.

It would probably make sense to locate a handful of high-bandwidth (for
some definition of HB) mirrors that would be willing to pull directly from
the home site and make anyone else mirror from one of them, thus creating
two tiers of mirrors. There's been talk of this a few times on the
redhat-mirror list, but Red Hat just keeps buying more bandwidth and
servers. That's not really an option for the library.

Post by John Morris
Idea #2 of course is to randomize who pulls from who with the obvious
advantages and disadvantages.

If by randomize, you mean using something like multiple A record DNS to
make mirrors rsync against a different site each time, that can get messy
since not all servers are guaranteed to be in sync at all times or even
use the same paths, so it's generally best to pick a mirror and stick with
it.

Post by John Morris
Is there a consensus as to which way would be best?

Does consensus matter? Isn't this your show? :)

Is this sort of mirror talk more appropriate on the devel list? Should
there be a mirror list?

BTW, my plan for whitebox.atlantic.net is to use it internally for our
growing number of WBEL servers, and to make it publicly available,
probably rate-limited to some small multiple of 10mbit/s, which may vary
according to how full our transit pipes are at any given time.

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

[William Hooper]

Jon Lewis said:
[snip]

Post by Jon Lewis
Both the 'home site' (www.whiteboxlinux.org) and NCSU seem to have their
3.0/en/os/i386 directories based on the original release. Before noticing
this, I chose to base mine on the liberation-respin1 iso files. I don't
know if thats going to cause problems for anyone. I don't expect it
would, but AFAIK, all my installs were done from respin1, so I don't have
a good/easy way to test this.

If someone were to attempt a network install they would have to use a
liberation-respin1 boot disk with your mirror Vs. using an original
liberation disk with all the other mirrors. Perhaps you can put your
respin1 tree in a different directory and hard-link the files that are the
same so you can have both trees with minimum of space lost. For that
matter the newer RPMs in respin1 are probably already in your updates
directory and could also be hardlinked.

[snip]

Post by Jon Lewis
...so my
/3.0/en/os/i386/headers dir lacks srpm headers, which I assume only
breaks installation of srpms via yum. Probably not a huge deal.

But if you fix the above this can be fixed also by mirroring the headers.

Post by Jon Lewis
At the moment, I have it setup to rsync updates from NCSU every 2 hours.
I see no reason to run rsync against the distribution files, since it
appears they never change.

True.

Post by Jon Lewis
It would probably make sense to locate a handful of high-bandwidth (for
some definition of HB) mirrors that would be willing to pull directly from
the home site and make anyone else mirror from one of them, thus
creating two tiers of mirrors.

You need step one (more mirrors fetching from the home site) first.
[snip]

[William Hooper]

Post by Jon Lewis
Using yum-1.0.3, I was able to generate the
headers directory (since the isos don't include those files), but that
version of yum won't generate headers for srpms, so my
/3.0/en/os/i386/headers dir lacks srpm headers, which I assume only
breaks installation of srpms via yum. Probably not a huge deal.

1) If possible, NFS mount the directory on a machine with the newer
version of yum.

2) Copy the files locally, create the headers, then update the server.

Though for consistencies sake, if you are planning on making it a public
mirror, I would still suggest it match the other servers with your respin1
tree in a different place.

[Jon Lewis]

Post by William Hooper
1) If possible, NFS mount the directory on a machine with the newer
version of yum.
2) Copy the files locally, create the headers, then update the server.

I suppose I could do either of those if the srpm headers are that
important.

Post by William Hooper
Though for consistencies sake, if you are planning on making it a public
mirror, I would still suggest it match the other servers with your respin1
tree in a different place.

I simply figured I might as well use the latest "version" of 3.0. I
personally frequently do FTP installs as not all the old parts boxes I
throw together have a CD drive, and it can save time by not requiring me
to babysit and play "swap the CD" during the install. Why install 3.0
when you can install 3.0-respin1?

----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

[William Hooper]

Post by Jon Lewis
I simply figured I might as well use the latest "version" of 3.0. I
personally frequently do FTP installs as not all the old parts boxes I
throw together have a CD drive, and it can save time by not requiring me
to babysit and play "swap the CD" during the install. Why install 3.0
when you can install 3.0-respin1?

No disagreement with that at all. As I tried to convey, having the
respin1 tree around is a good thing, just not what is expected at that
location. If it is your personal server it is no big deal, but if it is a
public mirror it might cause some confusion.

Without looking too hard at it, I would guess that hardlinking would give
you both trees with very little increase in used space. Somewhere Red Hat
used to have a script that would go through the two trees and make the
hardlinks for you...

[John Morris]

Post by Karanbir Singh
What exactly is the issue with the httpd package ? Is it just the
Redhat logo / report ?

This is what I documented in the changelog for the currently released
verison:

* Sun Oct 10 2004 John Morris <***@beau.org> 2.0.46-40.ent.WB1
- White Box fixes
- Fixed for WB's different buildroot (not /usr/src) thanks to hint
- from Pasi Pirhonen over at Tao.
- WB fixups include this .spec, index.html, powered_by*, renaming
- and twiddling httpd-*redhat.patch, certwatch.c and certwatch.xml.


I'll try to drop this one and the most recent kernel & openmotif packages
soon.

[John Morris]

Post by Ben Mohilef

White Box fixes - Fixed for WB's different buildroot (not /usr/src)

The redhat src rpm for 2.0.46-44.ent installed normally in
/usr/src/redhat when we built it in mid November. Didn't build 46-40
so I don't know about that revision.

Then you should not have problems. But by default I build as a
unprivledged user and there are some hardcoded references to /usr/src in
the .spec that get passed to libtool which caused some folks a heap of
trouble building apache add ons until it got sorted out thanks to a hint
from one of the Tao folk.

Post by Ben Mohilef
Yes, these are RH identifiers which need to be pulled in public
distributions such as WB. However, for private distributions (such
as I am using) they seem to work jest' fine.

Yup.

Post by Ben Mohilef
BTW, the new kernel builds nicely and has no untoward effects at
least in the athlon, smp-athlon and i686 flavour. [Unfortunately, a
new kernel means rebuilding nvnet.o and slusb/slmdm drivers
which are never included in unsupported. I am no longer a fan of
nvidia.]

I feel your pain about the driver rebuild nightmares. Not sure what I
will do when the Radeon 9200 chipset goes out of production since it is
the most recent with OS drivers built into XFree86/X.org. But even
without worrying about X failing to load, there always seem to be drivers
to futz with doesn't there. Grr.

[Kirby C. Bohling]

Post by John Morris
Sorry about dropping out for a bit, been on a deployment deadline death
march followed up by a Thanksgiving roadtrip with <24 hour notice of the
change of plans. Ended up staying with folks who only had a cellphone so
no net for six days. (Yes I am still twitching spasmodically from
withdrawal.)
All but one update is now on the primary site awaiting the mirrors to
catch them. The missing one is httpd and considering the problems it has
caused I'm going to hold on hatching that pending a bit more inspection
later tonight.

I don't see it on any of the mirrors until now (dec-06), not even on NCSU .
Did you change the location of the updates directory, so that the mirrors
mirror the wrong site/directory?

Nope, the NCSU mirror site just periodically has issues. (As far as
I can tell from what I've seen, it's very rarely whiteboxlinux.org
that has problems). Of the 5-6 times I've seen problems with the
mirrors, it's been fixed on the NCSU time all but once (the one time
I believe it was the headers were out of sync because John Morris
was trying to save time/bandwidth, his local copy worked, but the
copy people mirroed from didn't).

I've filed a ticket with them and the sync is going on right now (if
you rsync, and then rsync again, you'll get more files). As I'm
writting this, they are pulling the SRPMS, hopefully they'll get to
i386 soon.

They pulled the e-mail address from the rsync and ftp MOTD. I got
in contact with David Mir, the last person I saw who had
successfully contacted the mirror admin, in private. He gave me a
URL that you can submit trouble tickets to.

http://help.ncsu.edu/services/passon.pl?basedoc=newprob.html

Thanks to David Mir for forwarding that info to me. To cover
myself, I'm going to point out, until it's been 48 hours on the
updates are out of sync you probably shouldn't file a trouble
ticket. If you do file one, please e-mail the list so we don't
carpet bomb them with requests to get the mirrors in sync. The
people at NCSU doing us a huge favor, we should be nice to them. I
wish they'd give me a direct e-mail contact, as I'd e-mail the guy
and the CC: the whitebox list so everyone was in the loop.

Thanks,
Kirby

[John Morris]

Post by Jon Lewis
Both the 'home site' (www.whiteboxlinux.org) and NCSU seem to have their
3.0/en/os/i386 directories based on the original release. Before noticing
this, I chose to base mine on the liberation-respin1 iso files. I don't
know if thats going to cause problems for anyone. I don't expect it
would, but AFAIK, all my installs were done from respin1, so I don't have
a good/easy way to test this.

So long as you have no original 3.0 installs and don't plan to make it a
public mirror there won't be any problems. I didn't update the tree
because I wasn't sure what would happen if someone installed from a set of
3.0 media and tried to get current. In theory any dependencies should be
satisfied by newer packages but didn't want to find out. Since any
package that differs from 3.0 is in the errata directory it isn't all that
important either way.

Post by Jon Lewis
For some reason both the home site and NCSU lack pretty much all the files
from the first iso which would normally be in 3.0/en/os/i386/dosutils. I
copied those files from the iso into my mirror.

Known issue, the 3.0 CD set had them missing, they were lost somewhere
between RC2 and the 3.0 release and are back for the respin. Really
should go drop them back into the online tree though.

Post by Jon Lewis
At the moment, I have it setup to rsync updates from NCSU every 2 hours.
I see no reason to run rsync against the distribution files, since it
appears they never change.

Which is a good argument for keeping the updates out of the original tree,
all that comparing during rsync is expensive, better to just do what you
did and ignore it after the first pull.

Post by Jon Lewis

Post by John Morris
Is there a consensus as to which way would be best?

Does consensus matter? Isn't this your show? :)

To an extent, but the first step to wisdom is to realize how much ya don't
know. Many has been the time I have been educated by the collected wisdom
hanging out on this list in the last year.

Post by Jon Lewis
Is this sort of mirror talk more appropriate on the devel list? Should
there be a mirror list?

I can see a need for that.

Post by Jon Lewis
BTW, my plan for whitebox.atlantic.net is to use it internally for our
growing number of WBEL servers, and to make it publicly available,
probably rate-limited to some small multiple of 10mbit/s, which may vary
according to how full our transit pipes are at any given time.

When you are ready for outside traffic, drop a note.