[WBEL-devel] Security updates

[Milan Keršláger]

Hi,

as there are troubles with WBEL mirrors and with release delays, I
suggest to update all needed components by hand. This mean download from
http://whiteboxlinux.org/pub/3.0/en/updates already released updates:

kernel, ipsec-tools and initscripts (ipsec-tools needs latest version)

Always there are security updates for cvs, kdelibs, rsync, libpng and
libpng10. All of these are not yet at official WBEL site.

As I need latest updates I (as usually) build my own set. You may
download them from (the second is mirror so you may wait some time to
sync with master site):

ftp://ftp.vslib.cz/pub/local/milan.kerslager/RHEL-3/testing.updates/
ftp://ftp.linux.cz/pub/linux/people/milan_kerslager/RHEL-3/testing.updates/


I'm a little bit unsatisfied with persistent troubles with WBEL. So I
want to point you to CentOS because this community project are able to
cooperate and is not depended on one owerworked person (even has been
slower before final release). All updates are ready a short time after
release (with priority for security updates). Because binary (and
source) compatibilty, this seems to be easy to switch.

If you are wondering why I'm talkin about this here - there is an
answer: I want to WBEL be better and I want to point about cooperation
strength and I want to Morris think about this (ie about its own
weaknes).

And no - I want to steal nothing.

[Raimo Koski]

Post by Milan Keršláger
I'm a little bit unsatisfied with persistent troubles with WBEL. So I
want to point you to CentOS because this community project are able to
cooperate and is not depended on one owerworked person (even has been
slower before final release). All updates are ready a short time after
release (with priority for security updates). Because binary (and
source) compatibilty, this seems to be easy to switch.

I lost interest in cAos before they released CentOS. It seemed without
following it much that they had a common community problem, too much
enthusiasm and/or opinions and too little people who do the actual work.
It might be different now, but of the ones I currently follow, Tao
x86-64 and Lineox provide updates fastest. Update 2 for Lineox was ready
15.05.2004 10:05 GMT. Lineox has the advantage of automated generating
of binary packages. The system could be made faster, but I think
eliminating single point of failures like non-redundant Internet
connections would be more important improvements. Also waiting a while
to get error reports is sensible. Update 2 had a broken sendmail
package, which I had time to erase because compiling the whole batch
took so long.

The best way to increase compile times would be to use distcc
(http://distcc.samba.org/), but I would have to first compile at least
several packages with it and compare them to ones compiled without it. I
once tried Openmosix to speed up compile times and it didn't help at all.

[Ed]

Post by Raimo Koski

Post by Milan Keršláger
I'm a little bit unsatisfied with persistent troubles with WBEL. So I
want to point you to CentOS because this community project are able to
cooperate and is not depended on one owerworked person (even has been
slower before final release). All updates are ready a short time after
release (with priority for security updates). Because binary (and
source) compatibilty, this seems to be easy to switch.

I lost interest in cAos before they released CentOS. It seemed without
following it much that they had a common community problem, too much
enthusiasm and/or opinions and too little people who do the actual work.
It might be different now, but of the ones I currently follow, Tao
x86-64 and Lineox provide updates fastest. Update 2 for Lineox was ready
15.05.2004 10:05 GMT. Lineox has the advantage of automated generating
of binary packages. The system could be made faster, but I think
eliminating single point of failures like non-redundant Internet
connections would be more important improvements. Also waiting a while
to get error reports is sensible. Update 2 had a broken sendmail
package, which I had time to erase because compiling the whole batch
took so long.
The best way to increase compile times would be to use distcc
(http://distcc.samba.org/), but I would have to first compile at least
several packages with it and compare them to ones compiled without it. I
once tried Openmosix to speed up compile times and it didn't help at all.

DistCC is effective, it works well. Keep in mind that it is insecure,
equivalent to opening up a passwordless account called "distcc".

Ed

[Vicki Reeves]

Post by Milan Keršláger
I'm a little bit unsatisfied with persistent troubles with WBEL. So I
want to point you to CentOS because this community project are able to
cooperate and is not depended on one owerworked person (even has been
slower before final release). All updates are ready a short time after
release (with priority for security updates). Because binary (and
source) compatibilty, this seems to be easy to switch.

So, Milan, I guess this is 'goodbye' as you seem to be moving to the
CentOS project. Hope all goes well for you there.
--
========================================================================
This is me:
Vicki Reeves ***@beau.org http://www.beau.org/~vickir

This is where I work:
Beauregard Parish Library http://www.beau.org
205 South Washington Ave, DeRidder, LA 70634 [phone] x19
The Library does not necessarily agree with everything I write :-D

Geek code 3.1:GIT d? s-:++ a? C++ L++$ W++ w-- Y+ b+ G e r+++

<><

[Karanbir Singh]

Post by Vicki Reeves

Post by Milan Keršláger
I'm a little bit unsatisfied with persistent troubles with WBEL. So I

So, Milan, I guess this is 'goodbye' as you seem to be moving to the
CentOS project. Hope all goes well for you there.

I hope his leaving wont get in the way of someone trying to fix the
situation that he quite correctly pointed out.

[Vicki Reeves]

Post by Karanbir Singh
I hope his leaving wont get in the way of someone trying to fix the
situation that he quite correctly pointed out.

Sorry, I don't know which situation you are referring to. Milan seems
to be generally unhappy with everything about WhiteBox. I'm not sure
how that could be fixed.
--
========================================================================
This is me:
Vicki Reeves ***@beau.org http://www.beau.org/~vickir

This is where I work:
Beauregard Parish Library http://www.beau.org
205 South Washington Ave, DeRidder, LA 70634 [phone] x19
The Library does not necessarily agree with everything I write :-D

Geek code 3.1:GIT d? s-:++ a? C++ L++$ W++ w-- Y+ b+ G e r+++

<><

[Karanbir Singh]

Post by Vicki Reeves
Sorry, I don't know which situation you are referring to. Milan seems
to be generally unhappy with everything about WhiteBox. I'm not sure
how that could be fixed.

Lol! Me neither. I think Milan is going to have to live with that problem.

Situation I was refering to was the slow propogation of the updates...

And, how open is JohnM ( about 0% I think ) to outside help on the
situation ?

[Vicki Reeves]

Post by Karanbir Singh
Situation I was refering to was the slow propogation of the updates...
And, how open is JohnM ( about 0% I think ) to outside help on the
situation ?

Not meaning to speak for John -- he does that quite well on his own --
but figuring that he is very deep in sleep after a night of working on
WBEL issues, I'm going to give you my (reasonably close up) view of the
situation.

Slow propogation of updates is the #1 concern at the moment. While we
can't do much about our bandwidth here at the library, I think what John
is working on with the mirror sites will make things much better in the
very near future.

So far as outside help, I want to start with a personal story. When my
babies were newborn, I was the kind of mom who wanted to hide them under
the porch and growl at anyone who tried to touch them. In time, they
grew a little stronger and I grew more confident that I understood what
they needed to thrive. Before long, I reached a point where I was ready
for others to share in their care.

I've worked on many projects with John. He is not adverse to help. He
is, however, cautious and that serves us well. We've managed to escape
many disasters because John has said, 'wait, let me look at this a
little longer before we choose a direction'. I think that is where he
is on help with WBEL now...

no, not under the porch growling, that's where I said I would be :-)

... I think John is working on getting things correctly in place and
understanding where outside help will best fit into the WBEL project.
He reads every thing that is posted on all the lists and he carefully
considers the suggestions that are made.

Please everybody, keep suggesting and, yes, even complaining. It all
goes into the WBEL pot and what comes out is a better product for all of us.
--
========================================================================
This is me:
Vicki Reeves ***@beau.org http://www.beau.org/~vickir

This is where I work:
Beauregard Parish Library http://www.beau.org
205 South Washington Ave, DeRidder, LA 70634 [phone] x19
The Library does not necessarily agree with everything I write :-D

Geek code 3.1:GIT d? s-:++ a? C++ L++$ W++ w-- Y+ b+ G e r+++

<><

[John Morris]

Post by Milan Keršláger
as there are troubles with WBEL mirrors and with release delays, I
suggest to update all needed components by hand. This mean download from

The problem was too many people trying to download direct. Which is why I
have killed http access to the whole /pub tree as of this afternoon. And
why the rsync appears to have finished between here and NCSU. Really
didn't want to have to do that, but it was the only way. After I get the
latest batch of errata posted I'll switch it back on.

Longer term I'm really wondering how to get new versions out. The only
idea that seems to have the potential to really solve the problem is DVD's
via overnight delivery. Looking at this upcoming respin, assuming one set
of SRPM images for both arches, it will have nine .iso files without
considering the possibility of DVD images plus all of the x86_64 files
also appearing down /pub/3.0/en/os/x86_64.

The bandwidth of the postal service is potentially huge... but the latency
isn't all that good. :)

[Jesse]

Post by John Morris
Longer term I'm really wondering how to get new versions out. The only
idea that seems to have the potential to really solve the problem is DVD's
via overnight delivery. Looking at this upcoming respin, assuming one set

What kind of connectivity does beau.org have?

It seems pretty clear that it doesn't have the kind of connectivity
needed to be a primary download source for all users of the distribution.
There's nothing wrong with that as long as the limitations are realized.

But perhaps it's enough to transfer some ISOs worth of CDs to mirrors
periodically? It certainly has enough for minor rsync updates. All
assuming it's no longer being used for general downloads.

I don't see any reason that the general public needs to download WBEL
directly from whiteboxlinux.org, at any point.

---
Jesse <***@lumiere.net>

[William Warren]

as per beau.org's site they have only a t-1. transferring entire iso's
would tear up their bandwidth for over 30 minutes per iso. nOt pratical
when that t-1 has to handle dns, mail, http..etc etc etc

Post by Jesse

Post by John Morris
Longer term I'm really wondering how to get new versions out. The only
idea that seems to have the potential to really solve the problem is DVD's
via overnight delivery. Looking at this upcoming respin, assuming one set

What kind of connectivity does beau.org have?
It seems pretty clear that it doesn't have the kind of connectivity
needed to be a primary download source for all users of the distribution.
There's nothing wrong with that as long as the limitations are realized.
But perhaps it's enough to transfer some ISOs worth of CDs to mirrors
periodically? It certainly has enough for minor rsync updates. All
assuming it's no longer being used for general downloads.
I don't see any reason that the general public needs to download WBEL
directly from whiteboxlinux.org, at any point.
---
_______________________________________________
Whitebox-users mailing list
http://beau.org/mailman/listinfo/whitebox-users

[Jesse]

Post by William Warren
as per beau.org's site they have only a t-1. transferring entire iso's
would tear up their bandwidth for over 30 minutes per iso. nOt pratical
when that t-1 has to handle dns, mail, http..etc etc etc

Well, they don't seem to be very averse to doing that right now. I would
expect a little congestion (assuming they don't just rate limit their
upload, rsync --bwlimit) a couple times per year for a couple days
wouldn't be that big a deal. Most of the time they're just pushing out a
few packages.

Sounds to me like if beau avoided public access and was just used to seed
mirrors, it'd do fine.



---
Jesse <***@lumiere.net>

[Sean McAdam]

This is a multi-part message in MIME format.
--------------070208090907040801090801
Content-Type: multipart/alternative;
boundary="------------030303030709020407070800"


--------------030303030709020407070800
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Post by John Morris

Post by Milan Keršláger
as there are troubles with WBEL mirrors and with release delays, I
suggest to update all needed components by hand. This mean download from

The problem was too many people trying to download direct. Which is why I
have killed http access to the whole /pub tree as of this afternoon. And
why the rsync appears to have finished between here and NCSU. Really
didn't want to have to do that, but it was the only way. After I get the
latest batch of errata posted I'll switch it back on.
Longer term I'm really wondering how to get new versions out.

Would some sort of multi-tiered mirroring be appropriate? Perhaps you
can provide the official site, with a few high bandwidth primary
mirrors. From there the secondary mirrors can rsync the updates. (that
is what I do now for my own mirror server. It handles updates for about
40 boxes)

Then setup and distribute the default up2date and yum configuration
files to point to a round robin DNS entry such as:
update.us.mirror.whiteboxlinux.org. (replace "us" where appropriate)

I would not mind hosting such a secondary mirror. I have a total of 3
Mbits that does not do too much at night, and I can spare 1 Mbit during
the day. If we can get several people to host secondary mirrors for
updates that would remove your overworked T1 from getting pounded from
default installs updating.

Post by John Morris
The only
idea that seems to have the potential to really solve the problem is DVD's
via overnight delivery.

The DVD idea may still be a good idea for the primary mirrors.


~Sean

-----
"Don't count your weasels before they pop." -- The Tick




--------------030303030709020407070800
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
John Morris wrote:
<blockquote cite="midPine.LNX.4.44.0405201938490.5219-***@mjolnir"
type="cite">
<pre wrap="">On Thu, 20 May 2004, Milan [iso-8859-2] Ker&sup1;l&aacute;ger wrote:

</pre>
<blockquote type="cite">
<pre wrap="">as there are troubles with WBEL mirrors and with release delays, I
suggest to update all needed components by hand. This mean download from
<a class="moz-txt-link-freetext" href="http://whiteboxlinux.org/pub/3.0/en/updates">http://whiteboxlinux.org/pub/3.0/en/updates</a> already released updates:
</pre>
</blockquote>
<pre wrap=""><!---->
The problem was too many people trying to download direct. Which is why I
have killed http access to the whole /pub tree as of this afternoon. And
why the rsync appears to have finished between here and NCSU. Really
didn't want to have to do that, but it was the only way. After I get the
latest batch of errata posted I'll switch it back on.

Longer term I'm really wondering how to get new versions out. </pre>
</blockquote>
<br>
Would some sort of multi-tiered mirroring be appropriate?&nbsp; Perhaps you
can provide the official site, with a few high bandwidth primary
mirrors. From there the secondary mirrors can rsync the updates.&nbsp; (that
is what I do now for my own mirror server. It handles updates for about
40 boxes)<br>
<br>
Then setup and distribute the default up2date and yum configuration
files to point to a round robin DNS entry such as:
update.us.mirror.whiteboxlinux.org. (replace "us" where appropriate)<br>
<br>
I would not mind hosting such a secondary mirror.&nbsp; I have a total of 3
Mbits that does not do too much at night, and I can spare 1 Mbit during
the day.&nbsp; If we can get several people to host secondary mirrors for
updates that would remove your overworked T1 from getting pounded from
default installs updating.<br>
<br>
<blockquote cite="midPine.LNX.4.44.0405201938490.5219-***@mjolnir"
type="cite">
<pre wrap="">The only
idea that seems to have the potential to really solve the problem is DVD's
via overnight delivery. </pre>
</blockquote>
The DVD idea may still be a good idea for the primary mirrors.<br>
<br>
<br>
~Sean<br>
<pre class="moz-signature" cols="72">-----
"Don't count your weasels before they pop." -- The Tick


</pre>
</body>
</html>

--------------030303030709020407070800--

--------------070208090907040801090801
Content-Type: text/x-vcard; charset=utf8;
name="sean.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="sean.vcf"

begin:vcard
fn:Sean McAdam
n:McAdam;Sean
adr:PMB 293;;905 W. 7th St;Frederick;MD;21701;USA
email;internet:***@fredcom.com
tel;work:301.619.3744
tel;fax:[phone]
tel;pager:***@fredcom.com
tel;home:301.898.7130
tel;cell:301.325.4615
x-mozilla-html:FALSE
url:http://www.fredcom.com/
version:2.1
end:vcard


--------------070208090907040801090801--

[John Morris]

Post by Jesse
What kind of connectivity does beau.org have?

A T-1, giving us 1.544Mbps in both directions. After hours our official
business traffic drops down fairly low, just two dozen dialups, the
email/spam flow, etc. Then I have my traffic and whatever the guys at the
sheriff's office and city police are doing via their wireless links that
run through here. (Don't ask, don't tell time.) :)

Post by Jesse
But perhaps it's enough to transfer some ISOs worth of CDs to mirrors
periodically? It certainly has enough for minor rsync updates. All
assuming it's no longer being used for general downloads.

Assuming nothing goes wrong, nobody tries to do a direct download, etc.,
doing an rsync on a full release tree with two arches is going to take
almost as long as an overnight mail. Hopefully if the ia64 port takes off
it can be synced to the mirrors direct from it's eventual development
site. The question is which is more likely to attract a divine
intervention by St. Murphy.

[Bogdan Costescu]

Post by John Morris
The problem was too many people trying to download direct. Which is why I
have killed http access to the whole /pub tree as of this afternoon.

You don't need these drastic measures. And you don't need manual
intervention at all. I'm amazed that with all those people coming to
this list and saying "I converted X tens of servers to WBEL" nobody
heard at least of "traffic shaping" in Linux.

This works when you have to prioritize outbound traffic - this is
exactly the problem here. (The inbound traffic can't be directly
prioritized as it depends on the other side and routers in-between.)
So, point your browser at:

http://lartc.org/

and start reading. Having set up 3 different purpose shapers, I can
say that working with 'tc' (and sometimes with 'iptables' to mark
packets) is not exactly the most user-friendly experience, but the
result is well worth it.

As to what policy to impose... the server and link owners are the only
ones that can decide. But you have almost infinite possibilities :-)