FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
mar...@dc.cis.okstate.edu
as routers but send and receive all their out-of-network traffic
through a router?
If this is the lamest question that gets asked here, I am
sorry, but I want to make sure I am not missing some non-obvious
function that this memory leak involves. Thank you very much.
Martin McCormick
FreeBSD Security Advisories writes:
>Topic: routing table memory leak
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
nec...@freebsd.org
> Does this advisory apply to systems that do not function
> as routers
Yes. Hosts have routing tables, too.
> but send and receive all their out-of-network traffic
> through a router?
>
> If this is the lamest question that gets asked here, I am
> sorry, but I want to make sure I am not missing some non-obvious
> function that this memory leak involves. Thank you very much.
Better safe than sorry.
--
Jacques A. Vidrine <n...@nectar.cc> http://www.nectar.cc/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvid...@verio.net . nec...@FreeBSD.org . nec...@kth.se
bjoern...@mail.isis.de
> Does this advisory apply to systems that do not function
> as routers but send and receive all their out-of-network traffic
> through a router?
It affects every system described in the announcement that can be=20
pinged.
Bjoern
--=20
"The number of Unix installations has grown to ten, with more expected"
-- The Unix programmers handbook, 1972
br...@lariat.org
>V. Solution
>
>1) Upgrade your vulnerable system to 4.5-STABLE, 4.5-RELEASE-p3, or
>the RELENG_4_5 security branch dated after the respective correction
>dates.
On what server is 4.5-RELEASE-p3 located?
--Brett Glass
schulte...@nospam.schulte.org
>At 01:23 PM 4/17/2002, FreeBSD Security Advisories wrote:
>
>>V. Solution
>>
>>1) Upgrade your vulnerable system to 4.5-STABLE, 4.5-RELEASE-p3, or
>>the RELENG_4_5 security branch dated after the respective correction
>>dates.
>
>On what server is 4.5-RELEASE-p3 located?
You can synchronize your source tree and recompile. See:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
Direct any questions to freebsd-...@freebsd.org, please.
>--Brett Glass
--
Christopher Schulte
http://www.schulte.org/
Do not un-munge my @nospam.schulte.org
email address. This address is valid.
br...@lariat.org
>You can synchronize your source tree and recompile. See:
>
>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
Alas, this is not an acceptable solution.
I realize that many people use FreeBSD on non-mission-critical systems, or
to tinker with, and can afford downtime. But we need to create and maintain
production machines.
I hope that you can understand that doing a CVSup and then rebuilding the
world every night (slowing the system to a crawl in the process and
creating a system which might or might not be 100% stable) is not an
acceptable solution. Nor is downloading a random snapshot. (Which one
can't seem to do anyway these days; releng4.freebsd.org is refusing
What is needed is a known good "p3" (or "p-whatever") build that can be
installed quickly with minimum downtime. Yet, despite the fact that
people routinely refer to (for example) "4.5-RELEASE-p3", no such build
seems to actually exist. For those of us who create and manage production
servers, there should be.
--Brett Glass
da...@catwhisker.org
>From: Brett Glass <br...@lariat.org>
>At 11:11 PM 4/17/2002, Christopher Schulte wrote:
>>You can synchronize your source tree and recompile. See:
>>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
>Alas, this is not an acceptable solution.
>I realize that many people use FreeBSD on non-mission-critical systems, or
>to tinker with, and can afford downtime. But we need to create and maintain
>production machines.
>I hope that you can understand that doing a CVSup and then rebuilding the
>world every night (slowing the system to a crawl in the process and
>creating a system which might or might not be 100% stable) is not an
>acceptable solution. Nor is downloading a random snapshot. (Which one
>can't seem to do anyway these days; releng4.freebsd.org is refusing
That is irrelevant and specious.
If you have systems that are that important to you -- and I do, even
here at home -- then acquire a machine to do the builds, and then use
some method other than "build in place" to install the result. In some
cases, that could be NFS (perhaps over a special network dedicated to
such tasks); in others, it could be using such capabilities as provided
by atacontrol to insert a drive with a system image while the target
system remains up and running.
In neither case is the target system required to do the builds (and
consume the time and other resources necessary).
>What is needed is a known good "p3" (or "p-whatever") build that can be
>installed quickly with minimum downtime. Yet, despite the fact that
>people routinely refer to (for example) "4.5-RELEASE-p3", no such build
>seems to actually exist. For those of us who create and manage production
>servers, there should be.
Patches? Thanks....
Cheers,
david (links to my resume at http://www.catwhisker.org/~david)
--
David H. Wolfskill da...@catwhisker.org
Based on my experience as a computing professional, I consider the use of
Microsoft products as components of computing systems to be just as
advisable as using green wood to frame a house... and expect similar results.
na...@yogotech.com
> >You can synchronize your source tree and recompile. See:
> >
> >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
>
> Alas, this is not an acceptable solution.
>
> I realize that many people use FreeBSD on non-mission-critical systems, or
> to tinker with, and can afford downtime. But we need to create and maintain
> production machines.
>
> I hope that you can understand that doing a CVSup and then rebuilding the
> world every night (slowing the system to a crawl in the process and
> creating a system which might or might not be 100% stable) is not an
> acceptable solution.
Who said anything about building it every night?
> Nor is downloading a random snapshot. (Which one can't seem to do
> anyway these days; releng4.freebsd.org is refusing
Who said anything about a 'random' snapshot. Pick the snapshot that has
the fix applied (using the date), and build it. And, for what it's
worth, code that seem to claim is 'random' on the RELENG_4_X is
*exactly* the same code you would be getting if you download the patch
and apply it to your system, except that it's automated.
> What is needed is a known good "p3" (or "p-whatever") build that can be
> installed quickly with minimum downtime. Yet, despite the fact that
> people routinely refer to (for example) "4.5-RELEASE-p3", no such build
> seems to actually exist. For those of us who create and manage production
> servers, there should be.
There is. Download the 'random snapshot' using the RELENG_4_5 tag.
All I see from you is a lot of bitching about how the FreeBSD project
didn't hold your hand tight enough and have a developer show up on your
doorstop to install and verify every single version of FreeBSD you use.
This email is send from someone who is in *production use* a large
number of machines.
Nate
br...@lariat.org
>Who said anything about building it every night?
Many people are suggesting that one CVSup every night.
>> Nor is downloading a random snapshot. (Which one can't seem to do
>> anyway these days; releng4.freebsd.org is refusing
>
>Who said anything about a 'random' snapshot. Pick the snapshot that has
>the fix applied (using the date), and build it.
How does one know that there isn't a system-crashing bug in some other
part of the tree for the same date? What's needed is not just the
snapshot that happened to be available that day (or today) but one
that's known to be reasonably stable. Remember, a snapshot of -STABLE
taken on a random day is not guaranteed even to boot!
>There is. Download the 'random snapshot' using the RELENG_4_5 tag.
>All I see from you is a lot of bitching about how the FreeBSD project
>didn't hold your hand tight enough
Not true at all. What administrators using FreeBSD need is not
"hand-holding" but a way to upgrade to a known good snapshot.
Not necessarily the absolute latest, but one with the needed
patches which others have seen to work.
>and have a developer show up on your
>doorstop to install and verify every single version of FreeBSD you use.
I'm a developer myself, and therefore understand the value of testing.
It should be possible to get a snapshot ("patch level N," or whatever)
which one knows that others have tried and have found to work. As an
administrator, you should want this too.
--Brett Glass
na...@yogotech.com
> >If you have systems that are that important to you -- and I do, even
> >here at home -- then acquire a machine to do the builds, and then use
> >some method other than "build in place" to install the result.
>
> That's not sufficient to ensure that you didn't pick the wrong time
> to take a snapshot. Production machines must run a known good
> snapshot.
Pray tell who is going to very that a snapshot is both 'known and good'?
Simply applying security patches doesn't (necessarily) qualify as giving
you your requirement, so if you are truly concerned about your
production systems, you'll need to test *any* changes made to them
either on the system (and take the risk that it won't work), or setup a
system like David says and do your testing/verification process on a
scratch system.
This ain't rocket science here....
Nate
mist...@mushhaven.net
>
> How does one know that there isn't a system-crashing bug in some other
> part of the tree for the same date? What's needed is not just the
> snapshot that happened to be available that day (or today) but one
> that's known to be reasonably stable. Remember, a snapshot of -STABLE
> taken on a random day is not guaranteed even to boot!
It sounds like you want releng_4_5. This is -RELEASE with security
updates. It is pretty unchanging, and never gets feature updates, so
will always be the same as -RELEASE, only more secure.
> >There is. Download the 'random snapshot' using the RELENG_4_5 tag.
> >All I see from you is a lot of bitching about how the FreeBSD project
> >didn't hold your hand tight enough
>
> Not true at all. What administrators using FreeBSD need is not
> "hand-holding" but a way to upgrade to a known good snapshot.
> Not necessarily the absolute latest, but one with the needed
> patches which others have seen to work.
This is RELENG_4_5. What are you looking for that it does not
provide? Administrators HAVE 'a way to upgrade to a known good snapshot.'
> >and have a developer show up on your
> >doorstop to install and verify every single version of FreeBSD you use.
>
> I'm a developer myself, and therefore understand the value of testing.
> It should be possible to get a snapshot ("patch level N," or whatever)
> which one knows that others have tried and have found to work. As an
> administrator, you should want this too.
We do. And we have it. I fail to see what you want that is not already
provided.
Jamie
br...@lariat.org
>Pray tell who is going to very that a snapshot is both 'known and good'?
That's not "known and good" -- it's "known TO BE good."
>Simply applying security patches doesn't (necessarily) qualify as giving
>you your requirement,
Not if the version being used has also been altered in other ways.
>This ain't rocket science here....
No, it's not. Other open source projects issue periodic "patch level N"
snapshots between releases. If a significant security event occurs,
FreeBSD should as well. Pick a snapshot after the fixes have gone in,
test it, and post it as the next patch level... one that's a relatively
safe bet for an admin to upgrade to. In other words, you should be
able to go to the download site and actually find a build labeled
FreeBSD 4.5-RELEASE-p3.
--Brett
nec...@freebsd.org
> No, it's not. Other open source projects issue periodic "patch level N"
> snapshots between releases. If a significant security event occurs,
> FreeBSD should as well.
Clearly you are not paying attention. Please stop wasting everyone's
time (again).
--
Jacques A. Vidrine <n...@nectar.cc> http://www.nectar.cc/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvid...@verio.net . nec...@FreeBSD.org . nec...@kth.se
To Unsubscribe: send mail to majo...@FreeBSD.org
na...@yogotech.com
>
> That's not "known and good" -- it's "known TO BE good."
Same thing. If it's good, and you have no way of getting the same
snapshot it doesn't help you.
> >Simply applying security patches doesn't (necessarily) qualify as giving
> >you your requirement,
>
> Not if the version being used has also been altered in other ways.
Sure it does. The security patch could break your running system,
because it may not have been tested in your exact configuration, on your
exact hardware.
> >This ain't rocket science here....
>
> No, it's not. Other open source projects issue periodic "patch level N"
> snapshots between releases.
As does FreeBSD, if you'd get your head out of your butt and use it.
Nate
br...@lariat.org
>> Not true at all. What administrators using FreeBSD need is not
>> "hand-holding" but a way to upgrade to a known good snapshot.
>> Not necessarily the absolute latest, but one with the needed
>> patches which others have seen to work.
>
>This is RELENG_4_5. What are you looking for that it does not
>provide?
This is a CVS tag, not a build. Also, what you get when you
bring it in will change over time, so you can't easily answer
the question, "What patch level is this server running?"
What's needed is builds either from this or from -STABLE
(with testing to make sure nothing's broken) that one can
download and install without recompiling the world. With
numbers such that one can say, "This server is at -p3 and
a new security hole was found.... I'll upgrade to -p4 tonight."
Simple, convenient, and likely to work without fuss, so that
we can install the build and get back to more important things,
like developing code.
--Brett
br...@lariat.org
>> No, it's not. Other open source projects issue periodic "patch level N"
>> snapshots between releases.
>
>As does FreeBSD, if you'd get your head out of your butt and use it.
No, it doesn't. It only offers a CVS tag, not a build. You do understand
the difference?
--Brett
seta...@submonkey.net
> At 11:54 AM 4/18/2002, Jamie Norwood wrote:
>
> >> Not true at all. What administrators using FreeBSD need is not
> >> "hand-holding" but a way to upgrade to a known good snapshot.
> >> Not necessarily the absolute latest, but one with the needed
> >> patches which others have seen to work.
> >
> >This is RELENG_4_5. What are you looking for that it does not
> >provide?
>
> This is a CVS tag, not a build. Also, what you get when you
> bring it in will change over time, so you can't easily answer
> the question, "What patch level is this server running?"
That's not a bad point.
Any reason why newvers.sh can't be change to do this in RELENG_4 ?
Ceri
--
get the cool shoe shine
jber...@yahoo.com
you want a new way to upgrade, develop it yourself.
now stop trolling and let's move on.
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
jed...@fxp.org
--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 18, 2002 at 12:09:32PM -0600, Brett Glass wrote:
> At 12:02 PM 4/18/2002, Nate Williams wrote:
>=20
> >> No, it's not. Other open source projects issue periodic "patch level N"
> >> snapshots between releases.
> >
> >As does FreeBSD, if you'd get your head out of your butt and use it.
>=20
> No, it doesn't. It only offers a CVS tag, not a build. You do understand
> the difference?
>=20
ftp://snapshots.jp.freebsd.org/pub/FreeBSD/releases/i386/4.5-RELEASE-p3/
--=20
Chris D. Faulhaber - jed...@fxp.org - jed...@FreeBSD.org
--------------------------------------------------------
FreeBSD: The Power To Serve - http://www.FreeBSD.org
--45Z9DzgjV8m4Oswq
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: FreeBSD: The Power To Serve
iEYEARECAAYFAjy/DtoACgkQObaG4P6BelAPwACeIuZ9LvPzjRC5EMU5uW0phtaC
k0wAn3tpwnt0xhflwhBFsghENw9JxISi
=htMg
-----END PGP SIGNATURE-----
--45Z9DzgjV8m4Oswq--
seta...@submonkey.net
> On Thu, Apr 18, 2002 at 12:06:28PM -0600, Brett Glass wrote:
> > At 11:54 AM 4/18/2002, Jamie Norwood wrote:
> >
> > >> Not true at all. What administrators using FreeBSD need is not
> > >> "hand-holding" but a way to upgrade to a known good snapshot.
> > >> Not necessarily the absolute latest, but one with the needed
> > >> patches which others have seen to work.
> > >
> > >This is RELENG_4_5. What are you looking for that it does not
> > >provide?
> >
> > This is a CVS tag, not a build. Also, what you get when you
> > bring it in will change over time, so you can't easily answer
> > the question, "What patch level is this server running?"
>
> That's not a bad point.
> Any reason why newvers.sh can't be change to do this in RELENG_4 ?
I meant RELENG_4_[0-9].
dro...@rpi.edu
>At 12:02 PM 4/18/2002, Nate Williams wrote:
>
> >> No, it's not. Other open source projects issue periodic
> >> "patch level N" snapshots between releases.
> >
> > As does FreeBSD, if you'd get your head out of your butt
> > and use it.
>
>No, it doesn't. It only offers a CVS tag, not a build. You do
>understand the difference?
It is a cvs branch, not just a random tag. If you're saying you
want a pre-built ISO which will do a complete system install of
a given security-patch, then the answer is "we do not currently
have the resources to do that".
--
Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Institute or dro...@rpi.edu
beh...@zbzoom.net
> At 11:54 AM 4/18/2002, Jamie Norwood wrote:
>
> >> Not true at all. What administrators using FreeBSD need is not
> >> "hand-holding" but a way to upgrade to a known good snapshot.
> >> Not necessarily the absolute latest, but one with the needed
> >> patches which others have seen to work.
> >
> >This is RELENG_4_5. What are you looking for that it does not
> >provide?
>
> This is a CVS tag, not a build. Also, what you get when you
> bring it in will change over time, so you can't easily answer
> the question, "What patch level is this server running?"
uname -a
> What's needed is builds either from this or from -STABLE
> (with testing to make sure nothing's broken) that one can
> download and install without recompiling the world. With
With the number of custom kernels running out there, and the
number of different combinations of hardware out there, this is
not feasible. The best you could hope for is a page somewhere that
has submissions from people of "I'm running X here with Y kernel
config with Z hardware combination and it seems to be OK."
You might get a pre-built world somewhere with a GENERIC kernel
that you could download, but that's it. The snapshot server in Japan
has binaries that you can use to patch your system, but even it will
not have any of your local customizations.
> numbers such that one can say, "This server is at -p3 and
> a new security hole was found.... I'll upgrade to -p4 tonight."
> Simple, convenient, and likely to work without fuss, so that
> we can install the build and get back to more important things,
> like developing code.
That's exactly what RELENG_4_5 is for. If there's a hole in -p3,
then -p4 will have the fix for that hole, AND ONLY THAT FIX, in
addition to whatever was in -p3.
--
Chris BeHanna
http://www.pennasoft.com
jdici...@epylon.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Give me a break, he's not trolling, he's making a valid point. Perhaps some
of the current FTP mirrors could mirror the releng_4_[0-9] snapshots
currently on ftp://snapshots.jp.freebsd.org (as Chris Faulhaber posted).
The snapshots are being made none the less though so it looks like this
might be the answer to his problem/question.
Cheers,
- -JD-
- -----Original Message-----
From: Jon Bergfeld [mailto:jber...@yahoo.com]
Sent: Thursday, April 18, 2002 11:18 AM
To: secu...@FreeBSD.ORG
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
look, the existing process seems to work fine for everyone else, so if
you want a new way to upgrade, develop it yourself.
now stop trolling and let's move on.
- --- Brett Glass <br...@lariat.org> wrote:
> At 11:54 AM 4/18/2002, Jamie Norwood wrote:
>
> >> Not true at all. What administrators using FreeBSD need is not
> >> "hand-holding" but a way to upgrade to a known good snapshot.
> >> Not necessarily the absolute latest, but one with the needed
> >> patches which others have seen to work.
> >
> >This is RELENG_4_5. What are you looking for that it does not
> >provide?
>
> This is a CVS tag, not a build. Also, what you get when you
> bring it in will change over time, so you can't easily answer
> the question, "What patch level is this server running?"
> What's needed is builds either from this or from -STABLE
> (with testing to make sure nothing's broken) that one can
> download and install without recompiling the world. With
> numbers such that one can say, "This server is at -p3 and
> a new security hole was found.... I'll upgrade to -p4 tonight."
> Simple, convenient, and likely to work without fuss, so that
> we can install the build and get back to more important things,
> like developing code.
>
> --Brett
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPL8ULL8+wXo6G32BEQL91gCgutwDN743l4KlAhqALp0LfiRMu2IAn0rZ
I73vrq4B/M98XYVg3X09pC/M
=RBh4
-----END PGP SIGNATURE-----
seta...@submonkey.net
> On Thu, Apr 18, 2002 at 07:15:53PM +0100, Ceri Davies wrote:
> > On Thu, Apr 18, 2002 at 12:06:28PM -0600, Brett Glass wrote:
> > > At 11:54 AM 4/18/2002, Jamie Norwood wrote:
> > >
> > > >> Not true at all. What administrators using FreeBSD need is not
> > > >> "hand-holding" but a way to upgrade to a known good snapshot.
> > > >> Not necessarily the absolute latest, but one with the needed
> > > >> patches which others have seen to work.
> > > >
> > > >This is RELENG_4_5. What are you looking for that it does not
> > > >provide?
> > >
> > > This is a CVS tag, not a build. Also, what you get when you
> > > bring it in will change over time, so you can't easily answer
> > > the question, "What patch level is this server running?"
> >
> > That's not a bad point.
> > Any reason why newvers.sh can't be change to do this in RELENG_4 ?
>
> I meant RELENG_4_[0-9].
And it already does get changed.
/me considers unsubscribing ... :)
bm...@freebsd.org
> > Any reason why newvers.sh can't be change to do this in RELENG_4 ?
>
> I meant RELENG_4_[0-9].
The SO team *does* change it...go see the commits to src/sys/conf/
newvers.sh. The patch levels are annotated in src/UPDATING.
Bruce.
pe...@databits.net
| > > >This is RELENG_4_5. What are you looking for that it does not
| > > >provide?
| > >
| > > This is a CVS tag, not a build. Also, what you get when you
| > > bring it in will change over time, so you can't easily answer
| > > the question, "What patch level is this server running?"
| >
| > That's not a bad point.
| > Any reason why newvers.sh can't be change to do this in RELENG_4 ?
|
| I meant RELENG_4_[0-9].
It does. For example, here are the updates for RELENG_4_5:
We are now at 4.5-RELEASE-p3. Answering the "What patch level is this
server running?" question is as simple as running 'uname -r'.
--pete
--
Pete Fritchman [petef@(databits.net|freebsd.org|csh.rit.edu)]
finger pe...@databits.net for PGP key
Do...@freebsd.org
There is no way to end this discussion with Brett agreeing with
you. A cursory examination of the mail archives will show that this is one
of his favorite hobby horses. I would suggest not wasting any more time on
it.
Doug
mc...@artlogix.com
| Alas, this is not an acceptable solution.
|
| I realize that many people use FreeBSD on non-mission-critical systems, or to
| tinker with, and can afford downtime. But we need to create and maintain
| production machines.
|
| I hope that you can understand that doing a CVSup and then rebuilding the
| world every night (slowing the system to a crawl in the process and creating
| a system which might or might not be 100% stable) is not an acceptable
| solution.
Actually, it's not as bad as it might seem. I suspect what's got you upset is
the thought of having to do a make buildworld on every machine. I can tell you
how to avoid that.
What I've done in the past is to use NFS to export /usr from my fastest
machine. Let's assume you want to keep a Class C network at 192.168.3.0
updated.
/etc/exports:
/usr -alldirs -maproot=0:10 -network 192.168.3 -mask 255.255.255.0
Then, on the machines you want to keep updated, you'd mount /usr/src and
/usr/obj from that build machine.
Now, on the fast box, type
# cd /usr/src
# make buildworld
Churn, churn, churn. None of your production machines are impacted; only the
fast box handling the build.
I should also note that you may want to move *all* your kernel configuration
files over to the fast box, into /sys/i386/conf (if you're running x86/Pentium/
AMD boxes).
Once the build is done, pick a machine you want to update. Let's assume it's
called wibble, and it's kernel configuration file is called WIBBLE.
On the fast box, type
# make buildkernel KERNCONF=WIBBLE
Once that's done, go to Wibble, shut down the services on it (what you want to
do is essentially bring it down to single-user mode, but still keep NFS
running), and type the following:
# cd /usr/src
(Remember, that's the directory that actually resides on the
fast box)
# make installworld
(Which installs the new operating system.)
# make installkernel KERNCONF=WIBBLE
(Which installs the new kernel.)
# reboot
You should be done at this point with wibble. Next machine, wobble. Go to the
fastbox and type
# make buildkernel KERNCONF=WOBBLE
and when that's done, go to wobble and type
# cd /usr/src
# make installworld
# make installkernel KERNCONF=WOBBLE
# reboot
and so on.
You'll find that's a LOT faster than rebuilding the entire OS from source on
each and every machine.
Hope that helps. If you have any questions . . . well, you know where to
write. :)
mc...@artlogix.com
| I hope that you can understand that doing a CVSup and then rebuilding the
| world every night [...]
One thing I forgot to mention. A rebuild every night generally isn't
necessary. Some of those security advisories might not apply to you. Some of
them are things you might not consider a serious danger to your site given your
userbase. It's nice not to be forced to update on every advisory that comes
out.
But if something *does* affect you, having an efficient way to update all the
systems isn't such a bad thing.
br...@lariat.org
>look, the existing process seems to work fine for everyone else
Acutally, it doesn't. And it really hurts evangelism and new
adopters of FreeBSD.
For example, here's a rough transcript of a conversation I recently
had with an admin who wanted to put up a FreeBSD server.
Prospective user: FreeBSD sounds neat. How do I install it?
Me: Well, it's really easy. You just put in the first install floppy,
boot the system, insert the second floppy when asked, and away you
go. You can get the release floppies at ftp://www.freebsd.org/.
Prospective user: But I've heard that there were some security holes
and bugs discovered since then. How do I install a version with those
problems fixed?
[What I'd like to say: Oh, that's simple. In the same directory
you'll see 4.5-RELEASE, 4.5-RELEASE-p1, 4.5-RELEASE-p2, et
cetera. Just get the floppies for the most recent one, and it
will have all the critical fixes.
What I'd like to hear the prospective user say: This is great!
I'm glad that FreeBSD lives up to its reputation for being
easy to install.]
What I have to say now: That's not so simple. First, you have
to install the last ful release, bugs and all. Then, you have
to use CVSup...
Prospective user: What's that?
Me: Well, it updates your source tree to include the latest fixes.
Prospective user: Source tree? I'm not ready to play with the
source; I'm not familiar with the system yet, and I don't know
what this CVSup thing is.
Me: Unfortunately, there's no other way to do it. You have to
get the latest source, using the tag RELENG_4_5, and then
do a "make world."
Prospective user: What's a tag? How do I use it? And what's a
"make world?" And how do you find out the name "RELENG_4_5"
if you don't know it already?
Me: Do you have about half an hour? I can teach you the basics
of CVSup....
Prospective user: Naah, never mind. This is more complicated than
I thought, and it's a lot more complicated than installing
Red Hat and installing the latest RPMs to fix the bugs. I just
wanted to download a version of the OS that's secure, but I
don't have time to learn about all this stuff you're talking
about right this minute. I guess I'll stick with {Win2K/Linux}.
(End of dialogue)
As you can see from the above, FreeBSD doesn't have a simple answer
to a simple, reasonable question: "How can I *just install* FreeBSD
with all of the latest security fixes on a new machine, without
walking off of a conceptual cliff?"
We need to address this. Not only would it help newcomers; it would
also help admins who just want to do a quick, no-hassle upgrade that
includes the latest security fixes. We should NOT say, "the heck with
them if they're not willing to learn all sorts of developer stuff on
the spot." That's pointless elitism. And we shouldn't make it
unreasonably hard for admins to update... or they might not do it.
And then, when their systems are broken into, FreeBSD's reputation
as a secure OS suffers.
--Brett Glass
br...@lariat.org
>ftp://snapshots.jp.freebsd.org/pub/FreeBSD/releases/i386/4.5-RELEASE-p3/
I've looked at this. It looks like the right idea. But:
1) It's halfway around the world, in Japan. Downloads can be quite
slow. Why isn't it on the main FreeBSD FTP server and mirrors?
2) It's not documented anywhere -- not even on the Web page at
http://snapshots.jp.freebsd.org/.
3) Is it really a "p3" build? Or is it a snapshot of -STABLE? It looks
as if at least part of it (maybe all of it) is rebuilt every day.
--Brett
br...@lariat.org
>There is no way to end this discussion with Brett agreeing with
>you.
Not true. About the only thing I am sure to disagree with is an
assertion to the effect that the problem does not exist (it
plagues lots of folks!) that it does not need to be fixed.
>A cursory examination of the mail archives will show that this is one
>of his favorite hobby horses.
It's not a "favorite hobby horse" but rather a longstanding issue.
Why not work to solve the problem?
--Brett
br...@lariat.org
>Actually, it's not as bad as it might seem. I suspect what's got you upset is
>the thought of having to do a make buildworld on every machine. I can tell you
>how to avoid that....
[Snip]
Good tips here, assuming that you're willing to keep a build server around.
But what if you're doing a fresh install at a customer site (with Internet
feed), and want to get from floppies to a reasonably secure system without
headaches? Also, won't "make installworld" nuke some of the customization
you've done to each machine? And what if you're running with SECURELEVEL=2
on your production servers?
--Brett
mar...@roble.com
> look, the existing process seems to work fine for everyone else, so if
> you want a new way to upgrade, develop it yourself.
Actually the existing process does not work fine for everyone,
neither Brett, myself, nor many other sysadmins of mission-critical
production systems. If you would suppress the dirt-mouthed language
and stop shooting the messenger this might be more evident.
Different sites have different levels of risk tolerance. CVSup is
not the right tool for applying minimal deltas of fully tested code
to mission-critical servers. I've migrated several FreeBSD servers
to Solaris over the years for exactly this reason. Solaris' patch
and package subsystems are considerably better designed (i.e, anal)
and the patches are far more thoroughly tested than you'll find in
FreeBSD. This is a core difference between much free and commercial
software and it doesn't appear likely to change any time soon
(especially given the responses to Brett's wholly accurate
observations).
The development-oriented readers of -security, good as their coding
skills are (and they are the best), simply don't have the admin or
management experience necessary to understand a risk-analysis with
this level of distinction much less the time or inclination to
write the necessary code or implement supporting procedures.
FreeBSD is the finest OS for many, many applications. It's not,
however, the best at minimizing the risk of applying patches.
Trying not to be critical, just noting the facts as I see them,
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
David...@asu.edu
> Brett Glass <br...@lariat.org> writes:
> | I realize that many people use FreeBSD on non-mission-critical systems, or to
> | tinker with, and can afford downtime. But we need to create and maintain
> | production machines.
> how to avoid that.
THANKYOU. Here's a suggestion that helps. Seems like the topic for a
new HOWTO -- Keeping security updates across large numbers of production
servers ---
I'm very new to FreeBSD -- I chose FreeBSD because there was not a distro
dejour like in the linux world. Keeping security patching tractable
should be of great interest to the security group.
--
David Bear
College of Public Programs/ASU
480-965-8257
...the way is like water, going where nobody wants it to go
sco...@drkshdw.org
machine to test a cvsup, before going "live" in a production environment.
Most respectable companies with mission critical servers would do so.
It's also not our fault if cvsup is "not an acceptable solution" in your
curcumstances. It works for the rest of the world.
Get off your high horse, and mock up a server, cvsup test it, and then
upgrade your production servers. If this is still unacceptable, Please feel
free to code up your own patches, apply them, and quit bitching on the
mailing lists?
Jeff
----- Original Message -----
From: "Brett Glass" <br...@lariat.org>
To: "Christopher Schulte" <schulte...@nospam.schulte.org>;
<secu...@FreeBSD.ORG>
Sent: Thursday, April 18, 2002 12:10 PM
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
> At 11:11 PM 4/17/2002, Christopher Schulte wrote:
>
> >You can synchronize your source tree and recompile. See:
> >
> >http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
>
> Alas, this is not an acceptable solution.
>
> I realize that many people use FreeBSD on non-mission-critical systems, or
> to tinker with, and can afford downtime. But we need to create and
maintain
> production machines.
>
> I hope that you can understand that doing a CVSup and then rebuilding the
> world every night (slowing the system to a crawl in the process and
> creating a system which might or might not be 100% stable) is not an
> acceptable solution. Nor is downloading a random snapshot. (Which one
> can't seem to do anyway these days; releng4.freebsd.org is refusing
>
> What is needed is a known good "p3" (or "p-whatever") build that can be
> installed quickly with minimum downtime. Yet, despite the fact that
> people routinely refer to (for example) "4.5-RELEASE-p3", no such build
> seems to actually exist. For those of us who create and manage production
> servers, there should be.
>
> --Brett Glass
sfra...@expertcity.com
--------------060803020103020202070702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
I'd just like to second this.
I've managed unix systems for quite a few years, all solaris and AIX
until recently when I started moving one production class of servers
over to FreeBSD (performance is a lot better for this function.)
My biggest confusion in moving to FreeBSD was the CVSup process, and how
to get a currently patched stable image. (Not that it is that difficult,
but it is not intuitive, and there was no page in the FreeBSD handbook
saying "To ensure your system has the current patchset, and the most
stable code as of this date, do this... If you dont trust the latest
stable code, you can get patchlevel Y by doing this...")
Also, it is, in my opinion, unfortunate that I can install a system from
the CD"s without putting the source to everything on the box, but to go
to the -releng current patch set, I do need to first get the sources for
all on the system.
My .02c
Brett Glass wrote:
>At 12:17 PM 4/18/2002, Jon Bergfeld wrote:
>
>
>>look, the existing process seems to work fine for everyone else
>>
>
>Acutally, it doesn't. And it really hurts evangelism and new
>adopters of FreeBSD.
>
><snip>
>
>As you can see from the above, FreeBSD doesn't have a simple answer
>to a simple, reasonable question: "How can I *just install* FreeBSD
>with all of the latest security fixes on a new machine, without
>walking off of a conceptual cliff?"
>
>We need to address this. Not only would it help newcomers; it would
>also help admins who just want to do a quick, no-hassle upgrade that
>includes the latest security fixes. We should NOT say, "the heck with
>them if they're not willing to learn all sorts of developer stuff on
>the spot." That's pointless elitism. And we shouldn't make it
>unreasonably hard for admins to update... or they might not do it.
>And then, when their systems are broken into, FreeBSD's reputation
>as a secure OS suffers.
>
>--Brett Glass
>
>
>To Unsubscribe: send mail to majo...@FreeBSD.org
>with "unsubscribe freebsd-security" in the body of the message
>
--------------060803020103020202070702
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
I'd just like to second this.<br>
<br>
I've managed unix systems for quite a few years, all solaris and AIX until
recently when I started moving one production class of servers over to FreeBSD
(performance is a lot better for this function.)<br>
<br>
My biggest confusion in moving to FreeBSD was the CVSup process, and how
to get a currently patched stable image. (Not that it is that difficult,
but it is not intuitive, and there was no page in the FreeBSD handbook saying
"To ensure your system has the current patchset, and the most stable code
as of this date, do this... If you dont trust the latest stable code, you
can get patchlevel Y by doing this...")<br>
<br>
Also, it is, in my opinion, unfortunate that I can install a system from
the CD"s without putting the source to everything on the box, but to go to
the -releng current patch set, I do need to first get the sources for all
on the system.<br>
<br>
My .02c<br>
<br>
<br>
Brett Glass wrote:<br>
<blockquote type="cite" cite="mid:4.3.2.7.2.200204...@nospam.lariat.org">
<pre wrap="">At 12:17 PM 4/18/2002, Jon Bergfeld wrote:<br> <br></pre>
<blockquote type="cite">
<pre wrap="">look, the existing process seems to work fine for everyone else<br></pre>
</blockquote>
<pre wrap=""><!----><br>Acutally, it doesn't. And it really hurts evangelism and new<br>adopters of FreeBSD.<br><br><snip><br><br>As you can see from the above, FreeBSD doesn't have a simple answer<br>to a simple, reasonable question: "How can I *just install* FreeBSD<br>with all of the latest security fixes on a new machine, without<br>walking off of a conceptual cliff?"<br><br>We need to address this. Not only would it help newcomers; it would<br>also help admins who just want to do a quick, no-hassle upgrade that<br>includes the latest security fixes. We should NOT say, "the heck with <br>them if they're not willing to learn all sorts of developer stuff on <br>the spot." That's pointless elitism. And we shouldn't make it<br>unreasonably hard for admins to update... or they might not do it.<br>And then, when their systems are broken into, FreeBSD's reputation <br>as a secure OS suffers.<br><br>--Brett Glass<br><br><br>To Unsubscribe: send mail to <a class="moz-tx
t-link-abbreviated" href="mailto:majo...@FreeBSD.org">majo...@FreeBSD.org</a><br>with "unsubscribe freebsd-security" in the body of the message<br></pre>
</blockquote>
<br>
</body>
</html>
--------------060803020103020202070702--
mc...@artlogix.com
| Good tips here, assuming that you're willing to keep a build server around.
| But what if you're doing a fresh install at a customer site (with Internet
| feed), and want to get from floppies to a reasonably secure system without
| headaches?
I'd probably burn it onto a CD myself based on the latest -STABLE I was willing
to support.
| Also, won't "make installworld" nuke some of the customization you've done to
| each machine?
I try my hardest not to customize anything in /usr/src. If you do that, you're
on your own, bud.
| And what if you're running with SECURELEVEL=2 on your production servers?
You'll have run with a lower SECURELEVEL to install it. But then, you'd have
to anyway.
C'mon, Brett, these last two objections are really stretching things. Are you
looking for a solution, or are you just whinging?
mc...@artlogix.com
| Solaris' patch and package subsystems are considerably better designed (i.e,
| anal) and the patches are far more thoroughly tested than you'll find in
| FreeBSD.
Of course. Sun has much, much more control over the hardware. I don't know
that they're particularly better designed (things might have changed in the
last three years since I've been off Solaris, though), but they're certainly
better tested on the sort of hardware it's likely to run on.
But even it's not perfect. I remember a SunOS patch some years ago that had
the community up in arms. Sun was pretty embarrassed about that.
| This is a core difference between much free and commercial software and it
| doesn't appear likely to change any time soon (especially given the responses
| to Brett's wholly accurate observations).
Well, if you are willing to contribute monetarily, I'm sure someone in the
FreeBSD camp would be willing to write a better one. After all, you don't seem
very hesitant to contribute to Sun; perhaps if FreeBSD got some of your budget,
some of the tools most important to you would move up on the priority chain.
| The development-oriented readers of -security, good as their coding skills
| are (and they are the best), simply don't have the admin or management
| experience necessary to understand a risk-analysis with this level of
| distinction much less the time or inclination to write the necessary code or
| implement supporting procedures.
I completely disagree with this, save one item: it's a matter of time. The
effort is largely volunteer in nature. Many of us have been admins or coders
for years (nearly fifteen years Unix administration for me), and we're aware of
the problems and shortcomings of the open-source movement. Believe me, there
are definitely things I'd like to see improved as well---but *I* don't have the
time to code it, either. If someone were willing to pay me to swot up package-
and release-management code, I'd consider it.
If you're not comfortable with contributing to FreeBSD development on that
level, or its shortcomings are too great, you're probably better off with
Solaris.
benj...@macguire.net
* Jeff Palmer (sco...@drkshdw.org) [020418 15:08]:
> It's not the FreeBSD communities fault if you don't have a non-critical
> machine to test a cvsup, before going "live" in a production environment.
> Most respectable companies with mission critical servers would do so.
>
> It's also not our fault if cvsup is "not an acceptable solution" in your
> curcumstances. It works for the rest of the world.
>
> Get off your high horse, and mock up a server, cvsup test it, and then
> upgrade your production servers. If this is still unacceptable, Please feel
> free to code up your own patches, apply them, and quit bitching on the
> mailing lists?
>
> Jeff
There seems to be a lot of animosity among people, rather than constructive
discussion of the issue that has been raised. This can't be too productive.
Sometimes an improvement suggestion is just an improvement suggestion, and not
an accusation or hostile criticism. I think everyone here wants to see The
Project improve and benefit us all.
Like it or not, Brett has raised a concern which is entirely valid and echoed
by many system administrators. ( I have a feeling the number is not small )
FreeBSD currently does not enable easy maintainance between critical release
points for large server environments. Using cvsup to maintain source builds
for environments like these ( say 400 servers or more ) is not only
unacceptable without an on staff developer and release engineer, it is
infeasible.
For those of you who would be quick to note that "Corporations with 400
servers should be able to afford a developer and release engineer" please
note that 400 NT, Solaris, AIX, or HP-UX servers can be maintained by a small
team of administrators, and do not require these extra resources. If you can
still convince them to go with FreeBSD despite the extra salaries and
resources instead of the ease ( and insurance ) of buying a support contract
from the vendor, I commend you. Marketing is not my gig.
Nobody expects a new system to replace the current and trustworthy cvsup
method. By the same token, nobody expects The Project to support every
possible hardware/software configuration out there. On the flip side, FreeBSD
is not like NetBSD or Linux in that we don't support 40 architectures, and a
few household appliances.
Currently, we have 2 major architectures spanning 3 processors. Intel and
AMD processors on the PC, and Alpha. Sparc and IA64 may be considerations in
the future. For now, any patches or builds of this nature could very well be
limited to 3 supported base architectures. Typically, we have maybe 2 or 3
critical releases of this nature per month. That comes to 3 builds three
times a month, not a considerable strain, for the benefit of releasing
patches that folks will use.
I should like to note that this kind of system would be an excellent
opportunity for a FreeBSD support company to pick up some slack that perhaps
The Project doesn't have the resources to cover. It could potentially be a
valuable service for customers and users alike.
--
Benjamin Krueger
"Life is far too important a thing ever to talk seriously about."
- Oscar Wilde (1854 - 1900)
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
kar...@rohrbach.de
--wRokNccIwvMzawGl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Brett Glass(br...@lariat.org)@2002.04.18 14:34:47 +0000:
> >A cursory examination of the mail archives will show that this is one
> >of his favorite hobby horses.=20
>=20
> It's not a "favorite hobby horse" but rather a longstanding issue.
> Why not work to solve the problem?
if it is of major importance to you, please contact the jp.freebsd.org
people, talk about the open issues (docs, distribution,...) and then set
up a public ftp mirror that holds snapshots of RELENG_4_WHATEVER.
if you want to do it yourself, creating iso images and a properly set up
ftp-area for network installs read the docs listed at
http://www.freebsd.org/releng/index.html#docs
you just have to set up some midrange pc hardware that pulls the CVS
archive and runs a script around "make release". this _is_ a lot of
work, sure, and i stopped delivering my (past employer's) customers
custom -stable releases on iso (for obvious reasons). if you got more
than let's say 50 boxes running the same release with a site-specific
standard setup, it makes sense to invest the time. go ahead and try
building a release.
regards,
/k
--=20
> Obscenity is the crutch of inarticulate motherfuckers.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--wRokNccIwvMzawGl
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8v1CnM0BPTilkv0YRAngMAJ9e2DftxdqlK0uy19UdzCmD0KZUbQCcDSP2
N57d4sbEHwsl1kUCIskjURw=
=/gLB
-----END PGP SIGNATURE-----
--wRokNccIwvMzawGl--
kar...@rohrbach.de
--L/bWm/e7/ricERqM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Benjamin Krueger(benj...@macguire.net)@2002.04.18 15:43:38 +0000:
> Like it or not, Brett has raised a concern which is entirely valid and ec=
hoed
> by many system administrators. ( I have a feeling the number is not small=
)
but you are missing the point that _administrators_ have the option (and
the knowledge) to upgrade from source, using a builder system, just like
most freebsd admins with larger installations do.
> FreeBSD currently does not enable easy maintainance between critical rele=
ase
> points for large server environments. Using cvsup to maintain source buil=
ds
> for environments like these ( say 400 servers or more ) is not only=20
> unacceptable without an on staff developer and release engineer, it is=20
> infeasible.=20
take your favourite spreadsheet and create a TCO estimate of
administration and maintenance of
- freebsd 4.x
- linux (your "favourite" distro)
- win32
including the points
- system setup
- first time installation of services
- customer education (for them to be able to use the system)
- maintaining system stability (sec updates, subsystem upgrades)
and all that in an automatic or semi-automatic manner with maint
contracts running 1 or 2 years.
at my previous employer we had 1000+ customer boxes out there, some with
maintenance contracts, and freebsd turned out to be the most performant,
most stable and cheapest solution. i would be delighted to see the
numbers you get under the bottom line for TCO of the three platforms.
> For those of you who would be quick to note that "Corporations with 400=
=20
> servers should be able to afford a developer and release engineer" please=
=20
> note that 400 NT, Solaris, AIX, or HP-UX servers can be maintained by a s=
mall=20
^^^^^^ ^=
^^^^
> team of administrators, and do not require these extra resources. If you =
can=20
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
so, money is not a resource at your site? freebsd is an os, _freely
available_, running on _darn cheap_ hardware. your comparison lacks a
bit of realism here, at least from the european point of view of the
software/hardware prices of the vendors mentioned above.
btw, i'd also like to have some of the stuff you smoke over there ;-)
> still convince them to go with FreeBSD despite the extra salaries and
> resources instead of the ease ( and insurance ) of buying a support contr=
act
> from the vendor, I commend you. Marketing is not my gig.
>=20
> Nobody expects a new system to replace the current and trustworthy cvsup
> method. By the same token, nobody expects The Project to support every
> possible hardware/software configuration out there. On the flip side, Fre=
eBSD
> is not like NetBSD or Linux in that we don't support 40 architectures, an=
d a
> few household appliances.=20
nevertheless, release engineering for RELENG_4_X (X!=3D5) turned out to be
pretty perfect for an opensource os, from my point of view.
> Currently, we have 2 major architectures spanning 3 processors. Intel and=
=20
> AMD processors on the PC, and Alpha. Sparc and IA64 may be considerations=
in=20
> the future. For now, any patches or builds of this nature could very well=
be=20
> limited to 3 supported base architectures. Typically, we have maybe 2 or 3
> critical releases of this nature per month. That comes to 3 builds three
> times a month, not a considerable strain, for the benefit of releasing=20
> patches that folks will use.
>=20
> I should like to note that this kind of system would be an excellent
> opportunity for a FreeBSD support company to pick up some slack that perh=
aps
> The Project doesn't have the resources to cover. It could potentially be a
> valuable service for customers and users alike.
i agree partly. from my experience in the freebsd community there are
quite some folks who _do_ release builds for internal use at their site.
it would rather be a coordination effort to get one or more publicly
available update releases available out there, if their employers would
spend the resources on doing this.
regards,
/k
--=20
> UNiX *IS* user friendly. It's just selective about who it's friends are.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--L/bWm/e7/ricERqM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8v1o3M0BPTilkv0YRAkU3AKCpxnKRnte3UjZqm175TfGA/v1lkACcDE98
Oq6dhNWKw6e97+2M8G7AaFc=
=jocT
-----END PGP SIGNATURE-----
--L/bWm/e7/ricERqM--
na...@yogotech.com
> points for large server environments. Using cvsup to maintain source builds
> for environments like these ( say 400 servers or more ) is not only
> unacceptable without an on staff developer and release engineer, it is
> infeasible.
>
> For those of you who would be quick to note that "Corporations with
> 400 servers should be able to afford a developer and release engineer"
> please note that 400 NT, Solaris, AIX, or HP-UX servers can be
> maintained by a small team of administrators, and do not require these
> extra resources.
So, for 400 NT, Solaris, AIX, or HP-UX servers you allow a small team,
and for FreeBSD you don't even allow a single engineer? Seems kind of a
double standard.
And as a long-time administrator, I disagree that FreeBSD is more
difficult to maintain releases across systems. I've done Ultrix, SunOS,
Solaris, FreeBSD, and (ack!) Linux, and I find that FreeBSD is second to
Solaris, but barely so.
However, Solaris doesn't even provide anything remotely close to what
Brett is asking, and they're getting paid alot for the OS than FreeBSD
is getting paid.
Nate
Do...@freebsd.org
On Thu, 18 Apr 2002, Brett Glass wrote:
> At 12:54 PM 4/18/2002, Doug Barton wrote:
>
> >There is no way to end this discussion with Brett agreeing with
> >you.
>
> Not true. About the only thing I am sure to disagree with is an
> assertion to the effect that the problem does not exist (it
> plagues lots of folks!) that it does not need to be fixed.
I think everyone agrees that you have problems Brett. No argument
there. :) The question is, whether or not this problem of between-release
upgrades is ever going to be solved to your satisfation.
> >A cursory examination of the mail archives will show that this is one
> >of his favorite hobby horses.
>
> It's not a "favorite hobby horse" but rather a longstanding issue.
> Why not work to solve the problem?
The typical FreeBSD answer is, "Since YOU think it's a problem,
why don't YOU work to solve it?" However, since to my knowledge your
record of never actually contributing a line of code to the project
remains unblemished, I know you don't like that answer very much.
I also think that the new RELENG_N_N idea is a good one, and it
may do your heart good to know that I took your point about not being able
to easily ascertain how many patches have been applied to a particular
point in that branch up with the release engineers just now. I agree that
it's valid, and should be easy to fix with newvers.sh, if it's not already
fixed (I haven't been following developments on that stuff too closely).
As for other magical solutions to your (upgrade) problems...
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
benj...@macguire.net
I think you misunderstood. I meant you don't need release engineers for
any of the above, only FreeBSD. FreeBSD might be great, but it doesn't admin
itself yet. ;) Consider 4 sysadmins, and 2 release engineers for FreeBSD, as
opposed to just 4 sysadmins for NT / Solaris / AIX / HP-UX.
--
Benjamin Krueger
"Life is far too important a thing ever to talk seriously about."
- Oscar Wilde (1854 - 1900)
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
To Unsubscribe: send mail to majo...@FreeBSD.org
na...@yogotech.com
Call it what you like, but I consider preparing/testing a release for
our configuration part of the 'sysadmin' job. Certainly the IS staff at
my company does hardware/software verification as part of their job, on
*all* platforms (including Win98/NT/Win2K/WinME/XP, along with all of
the *nix variants).
If it makes you feel better, use the title 'release engineer', but the
staff of 4 people should be more than adequate to do all of the tasks
necessary to support your installations, regardless of whether FreeBSD
is used or not.
Nate
na...@yogotech.com
> > > by many system administrators. ( I have a feeling the number is not small )
> >
> > but you are missing the point that _administrators_ have the option (and
> > the knowledge) to upgrade from source, using a builder system, just like
> > most freebsd admins with larger installations do.
>
> Indeed they do. Doing this for 1000 individual servers, even when
> scripted, is an incredible task, and not very feasible.
Doing *anything* to 1000 individual servers running ANY OS is an
incredible tasks, regardless of what is being done. Why is FreeBSD
being singled out here?
> Quite a few shops do have the luxery of being able to maintain and release
> internal builds. Quite a few more do not. Either way, its still a good
> opportunity for someone who can. =)
Any shop that has a significant # of servers that I've worked with takes
the time to do internal builds using a standard set of hardware.
Otherwise, you spend more time chasing your tail than in solving
problems. (Again, this issue is orthogonal to the issue of which
hardware/software is being used).
benj...@macguire.net
That is very convenient, but I wouldn't call it realistic. We're talking about
more than just verification here. We're talking about building and testing an
entire OS from source, and then distributing it among a large number of
machines. While I'm sure most sysadmins would like to fancy themselves
superpeople (I would!), most of us aren't. ;) The point here is that release
engineering is very much a larger task than using release patches. With a
large server farm, you are going to have lots of reasons to have folks soley
dedicated to just this task.
--
Benjamin Krueger
"Life is far too important a thing ever to talk seriously about."
- Oscar Wilde (1854 - 1900)
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
To Unsubscribe: send mail to majo...@FreeBSD.org
va...@texoma.net
>However, Solaris doesn't even provide anything remotely close to what
>Brett is asking, and they're getting paid alot for the OS than FreeBSD
>is getting paid.
Perhaps there is reason for the FreeBSD project to *consider* providing the
requested enhanced service(s) in return for a subscription fee from those
who would benefit. It might [outsell | generate more revenue than]
T-Shirts or Daemons, perhaps even make evangelism easier, perhaps even
increase market share.
OTOH, perhaps a free T-Shirt should come with each subscription.
Make mine an XX-L, please `[8-))
rgds/ldv
7 year licensee of BSD/OS, now using FreeBSD
haw...@visi.com
br...@lariat.org writes:
> At 12:22 PM 4/18/2002, Chris Faulhaber wrote:
>
>>ftp://snapshots.jp.freebsd.org/pub/FreeBSD/releases/i386/4.5-RELEASE-p3/
>
> I've looked at this. It looks like the right idea. But:
>
> 1) It's halfway around the world, in Japan. Downloads can be quite
> slow. Why isn't it on the main FreeBSD FTP server and mirrors?
>
> 2) It's not documented anywhere -- not even on the Web page at
> http://snapshots.jp.freebsd.org/.
>
> 3) Is it really a "p3" build? Or is it a snapshot of -STABLE? It looks
> as if at least part of it (maybe all of it) is rebuilt every day.
OK, I believe it was mentioned already, but was rather glossed over:
For any one "snapshot", be it a major.minor-RELEASE, or -RELEASE-pN,
have you - or anyone - any idea just how many snapshots would be required?
Some systems are IDE/ATAPI, others are SCSI, some are both, and some are
RAID. You want a snapshot kernel supporting all that, if yours is just
an internet gateway? What're the possible permutations of supported DASD?
What are the possible permutations of NICs?
What of optimizations for particular CPUs?
So, how many kernels should be "snaphot"d? And who's to make that call?
My point is, if it isn't already obvious, is that this path will garner
nothing but disappointment to some group of people somewhere. There's no
way FreeBSD - or any OS that runs on "ubiquitous" or "off the shelf"
hardware - can make everyone happy. I daresay it'd actually satisfy but
a small number of users, of which you may or may not be included. Even
"snapshot"d GENERIC kernels wouldn't cut it, methinks (it wouldn't for
me, anyway).
---
I've tried to use Red Hat's RPMs for updates/upgrades, and it was more
hassle to keep that straight than to simply replace the OS altogether (and
I have to wonder if a majority of Linux sysadmins haven't came to the same
conclusion and practice?). Those were on "generic" systems, too; I shudder
to think what would break were they custom (in the FreeBSD sense). RPMs are
not the panacea they're purported to be, many's the time they've broken
more than they've fixed.
---
I have used NFS as a method of distributing builds from a "master" box,
and it is a viable solution, indeed. Clean, too, from the standpoint of
support. And the price of the "master" box? What, $600 or $700?
For the record: I cvsup'd from -RELEASE-p2 to -p3, rebuild the world,
and kernel, while doing all my day-to-day business, with only occasional
and brief hesitations in response times. It took about 2-1/2 hours. The
system was off-line for all of about ten minutes for the installation.
This on a 700Mhz Celeron. The overhead on other servers NFS-connected to
it would be that last ten minutes or so.
As to your "what if" about customer's systems? The build process is a
great time for an extended lunch to mull over others issues with that
client. Someone can page you on the off-chance it breaks, though that's
never happened to me.
---
And to a comment of yours that stuck in my mind: You can cvsup every night
if you want, but that doesn't necessarily mean a build every night.
> --Brett
Brett, FreeBSD's methodologies may not be the most convenient for you or
others that agree with you, but you've got to admit, it is comprehensive,
and pretty much bullet-proof, if not idiot-proof.
Just my more-than-two-cents' worth,
Dave
--
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
br...@lariat.org
>OK, I believe it was mentioned already, but was rather glossed over:
>
>For any one "snapshot", be it a major.minor-RELEASE, or -RELEASE-pN,
>have you - or anyone - any idea just how many snapshots would be required?
One.
>Some systems are IDE/ATAPI, others are SCSI, some are both, and some are
>RAID. You want a snapshot kernel supporting all that, if yours is just
>an internet gateway? What're the possible permutations of supported DASD?
I'm afraid I don't understand. What are you talking about?
>What are the possible permutations of NICs?
>
>What of optimizations for particular CPUs?
>
>So, how many kernels should be "snaphot"d? And who's to make that call?
You obviously misunderstand what we've been referring to when we use
the word "snapshot." A "snapshot," in this context, is a build of FreeBSD
from a particular day's sources.
--Brett
haw...@visi.com
>
> At 07:49 PM 4/18/2002, D J Hawkey Jr wrote:
>
> >OK, I believe it was mentioned already, but was rather glossed over:
> >
> >For any one "snapshot", be it a major.minor-RELEASE, or -RELEASE-pN,
> >have you - or anyone - any idea just how many snapshots would be required?
>
> One.
>
> >Some systems are IDE/ATAPI, others are SCSI, some are both, and some are
> >RAID. You want a snapshot kernel supporting all that, if yours is just
> >an internet gateway? What're the possible permutations of supported DASD?
>
> I'm afraid I don't understand. What are you talking about?
>
> >What are the possible permutations of NICs?
> >
> >What of optimizations for particular CPUs?
> >
> >So, how many kernels should be "snaphot"d? And who's to make that call?
>
> You obviously misunderstand what we've been referring to when we use
> the word "snapshot." A "snapshot," in this context, is a build of FreeBSD
> from a particular day's sources.
No, I think I do understand. Would not that "snapshot" include the kernel?
If so, what would you like that kernel to be configured as when the snapshot
is taken? Do you think it'd be the same requirements as that of the majority
of others? Even a large minority? How about a small majority?
The kernel not withstanding, what about CPU capabilities? What if the OS
was built with code that uses SSE, but your CPU doesn't support SSE? This
pro'lly isn't a reality [right now], but you get my drift, don't you?
Would you really want an OS built for the lowest common denominator as the
one you install on your production servers, much less your desktop?
> --Brett
Dave
--
______________________ ______________________
\__________________ \ D. J. HAWKEY JR. / __________________/
\________________/\ haw...@visi.com /\________________/
http://www.visi.com/~hawkeyd/
ja...@shalott.net
Hash: SHA1
> >For any one "snapshot", be it a major.minor-RELEASE, or -RELEASE-pN,
> >have you - or anyone - any idea just how many snapshots would be required?
>
> One.
>
> >Some systems are IDE/ATAPI, others are SCSI, some are both, and some are
> >RAID. You want a snapshot kernel supporting all that, if yours is just
> >an internet gateway? What're the possible permutations of supported DASD?
>
> I'm afraid I don't understand. What are you talking about?
I think that the implication is that no one ever uses a "snapshot" because
everyone always compiles their own custom kernel, because GENERIC is never
appropriate for a production system. Whether or not you agree is for you
to decide.
Can this discussion stop taking place on this list? While you may or may
not agree that this aspect of release engineering needs fixing, I hope
that you will agree that this is only tangentially a security issue, and
that cluttering a list which people count on to be mostly brief
clarifications of important and immediate security issues is undesirable.
Maybe take it to -hackers? Or create a new -relng list?
-Jason
-----------------------------------------------------------------------
I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry
that 10 or 15 years from now, she will come to me and say "Daddy, where
were you when they took freedom of the press away from the Internet?"
-- Mike Godwin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg
iD8DBQE8v4AXswXMWWtptckRAohdAKDycH8+ZTv8FSFfDjLgGy9CYgEI7wCgtTo8
6aXuG0FGVzMHvL9eA1/7nS4=
=om2H
-----END PGP SIGNATURE-----
br...@lariat.org
>C'mon, Brett, these last two objections are really stretching things.
I don't think so. They're real pitfalls for administrators.
As I've mentioned in other messages, what I think we need is the
equivalent of the Japanese FreeBSD X.Y-RELEASE-pZ builds, on the
main FTP server and on the mirrors, ready for installation both
by new users and by admins looking to do a sure, safe upgrade.
Having a local build server is a nice idea, especially if you're
a large shop, but doesn't get newcomers a safe version to install
(important; if they're hacked they'll sour on FreeBSD) or give
an admin a build to which she can just upgrade quickly and know
that the latest holes are closed.
--Brett
br...@lariat.org
>> You obviously misunderstand what we've been referring to when we use
>> the word "snapshot." A "snapshot," in this context, is a build of FreeBSD
>> from a particular day's sources.
>
>No, I think I do understand. Would not that "snapshot" include the kernel?
>If so, what would you like that kernel to be configured as when the snapshot
>is taken?
GENERIC.
>Would you really want an OS built for the lowest common denominator as the
>one you install on your production servers, much less your desktop?
Sure, to start with. And then I customize it. If my kernel config files are
preserved through the update, I can do that very quickly.
--Brett
haw...@visi.com
reply; this discussion doesn't really belong in this list.
On Apr 18, at 08:33 PM, Brett Glass wrote:
>
> At 08:24 PM 4/18/2002, D J Hawkey Jr wrote:
>
> >> You obviously misunderstand what we've been referring to when we use
> >> the word "snapshot." A "snapshot," in this context, is a build of FreeBSD
> >> from a particular day's sources.
> >
> >No, I think I do understand. Would not that "snapshot" include the kernel?
> >If so, what would you like that kernel to be configured as when the snapshot
> >is taken?
>
> GENERIC.
Wouldn't cut it for some of the boxes I am or have been responsible for.
It'd boot and run, mostly, but it wouldn't "communicate".
> >Would you really want an OS built for the lowest common denominator as the
> >one you install on your production servers, much less your desktop?
>
> Sure, to start with. And then I customize it. If my kernel config files are
> preserved through the update, I can do that very quickly.
Excepting servers that can't connect to a "master box" via NFS (as has been
detailed), you can't possibly build and install a kernel inside of the ten
to twenty (max?) minutes of downtime to install an already-built kernel from
that NFS server "master".
Even were it so, you'd end up with a tuned kernel running against it's
lowest common denominator OS; that's acceptable to you? Not for me, nope.
In my mind, it boils down to this: If you value FreeBSD enough to employ
it, is it such a stretch to have a "master" on the network to accomodate
FreeBSD's update/upgrade methodologies? My "master" just happens to be my
workstation; no additional costs incurred.
In closing, it seems to me you've got to consider the entire population
more, and your own conveniences a little less. Completely unfashionable
since, oh, the middle 80's or so, but it's the coda to much, isn't it?
> --Brett
Dave
--
______________________ ______________________
\__________________ \ D. J. HAWKEY JR. / __________________/
\________________/\ haw...@visi.com /\________________/
http://www.visi.com/~hawkeyd/
br...@lariat.org
>> GENERIC.
>
>Wouldn't cut it for some of the boxes I am or have been responsible for.
>It'd boot and run, mostly, but it wouldn't "communicate".
And at that point you'd quickly rebuild the kernel.
>Excepting servers that can't connect to a "master box" via NFS (as has been
>detailed), you can't possibly build and install a kernel inside of the ten
>to twenty (max?) minutes of downtime to install an already-built kernel from
>that NFS server "master".
If you've got that many to do, it *is* better to create a build
server.
>Even were it so, you'd end up with a tuned kernel running against it's
>lowest common denominator OS; that's acceptable to you?
Again, you're not making sense. It wouldn't be the "lowest common
denominator OS;" it'd be THE latest version of the OS.
--Brett
mc...@artlogix.com
| I don't think so. They're real pitfalls for administrators.
No, they're not. Most administrators don't modify stuff in /usr/src, and if
they do, most of them understand that they're on their own when they do this.
And if you want to modify the operating system (i.e., upgrade), you've got to
drop SECURELEVEL, in the classic can't-have-your-cake-and-eat-it-too dilemma.
I'm going to treat those as specious whines, and go back to the basic problem.
You want to be able to roll out security patches, as I understand it, without
doing buildworld/installworld/buildkernel/installkernel. Yes?
Y'know, even Solaris didn't have this until the last few years. I admit it:
in doing autoupdating, FreeBSD is a little behind the commercial curve.
Which isn't surprising, given its lack of funding.
Okay, so if I were administrating 1000 FreeBSD machines, and having to keep
them up to date, how would I do it?
I guess what I'd do is keep a reference machine around for starters. No matter
what, I'd want a reference machine tracking -STABLE, so that if I was hit with
a DoS attack that was already fixed in the sources, I would at least have
access to the source code.
The next thing I'd have to ask is how important it was that they were *all*
running the same operating system. If it was critical to the mission, what I'd
probably do is set up a rolling update system. I wouldn't use very many kernel
configuration files; instead of individualizing them too much, I'd probably
name them MAIL, WEB, or after whatever function they were fulfilling. Do the
buildworld and the first kernel, and roll it out to, say, ten vanguard boxes by
executing a command from the reference machine to tell the vanguard boxes (I
can think of several ways to do this off the top of my head) to go to
single-user mode and start the installworld and installkernel. When they
reboot, they let the next batch know (say, 50 machines) that it's time for them
to update. The vanguard machines would then serve as the second wave's
reference machines (five apiece), which would then do the installworld, and
then refer to the reference box for installkernel. And so on, until all the
machines were updated within the day. Rolling blackouts, as it were, but
wouldn't cut services entirely.
Of course, I'd have to put it together myself. And if it was sufficiently
clean and well-written, I might share it with the community. Might even become
a nice general-usage tool.
Of course, to me, that's sort of what sysadmins *do*. I don't see this as a
weakness of the operating system per se; it's just that there's no tool that's
going to help me run my particular shop quite as effectively as I'd like,
because I'm the guy who knows what the requirements are for the shop, and I
know how everything's put together. For example, on a server farm like the one
I've been talking about, you might not even want to bother taking things down
to single-user mode. Sure, it's safer that way, but when I know I'm the only
user on a system, the only one with a password, I might want to take a
shortcut. Again, test it on the reference box first, but if I felt it was safe
enough. . . .
On the other hand, if everything absolutely, positively had to be done NOW,
with as little impact as possible, I'd have redundant boxes all over the place,
doing distributed functions, so taking down a bunch of them would slow things
down, but not make services completely unavailable.
It goes without saying that downtime should be announced in advance.
Take a different BSD operating system: Mac OS X. The System Update tool is
quite nice. But the system still has to get bounced once in a while, and you
still have to go from box to box updating the system. Last I checked, that was
true of Solaris, too.
I guess I look at it like this: There's an inherent tradeoff between
flexibility and convenience, and another one between work and spending. I like
the flexibility, and I like saving money, so I use FreeBSD. If convenience and
not having as much work to do is more valuable to you, then Solaris or
something like it is probably a better solution. I admit that FreeBSD (or
Linux, or OpenBSD or NetBSD or HP/UX or AIX or whatever) isn't for everybody.
Each shop's requirements has a hand in tipping the balance towards what OS is a
preferable solution. If security and source auditing is your number one
concern, then use OpenBSD, for heaven's sakes. If you want your operating
system manufacturer to keep your systems updated for you conveniently and
easily, then use Solaris or something like that. If you have a boss with a
penguin fetish, then Linux may be what you want.
No OS is going to be the end-all and be-all of the entire population. I think
the FreeBSD core team knows that. I'm an agnostic on the issue of which is
"best"---I just have a strong preference for FreeBSD, because of my *own*
requirements. There are things I'd like to change about FreeBSD, and when I
have the time, I might try to help change those things, or when I win the
lottery, I might pay someone to help change those things. But I accept the
limitations of a volunteer project: they don't have the manpower or monetary
resources to do what Sun or Microsoft or IBM does. The FreeBSD core team is
*dwarfed* by the number of paid full-time Solaris team developers, and I'm not
even going to go *into* how many people Microsoft or IBM has banging away on
their respective OSes on respectable salaries.
FreeBSD might not be for your shop. It's okay. We can take it. But whinging
that it's not Solaris is only going to wear at the hardworking and competent
volunteers that have made FreeBSD as excellent as it is. The cardinal rule is,
don't fix it if it ain't broke, but closely following *that* rule is this one:
If you think it is, fix it. Do something to contribute---after all, none of us
are getting paid to work on FreeBSD (with a very few notable exceptions, and
nobody full-time to my knowledge).
mc...@artlogix.com
| Sure, to start with. And then I customize it. If my kernel config files are
| preserved through the update, I can do that very quickly.
Kernel config files have been preserved through the update since FreeBSD 3.x.
They're in /sys/i386/conf. GENERIC gets stomped on, as does LINT, but
everything else is preserved. And if you're feeling paranoid about it (which I
tend to be), there's always the floppy drive or some other backup mechanism.
Ml...@ear.com.br
E
exposition of the problem that Brett has been trying to show since the
beginning. To anyone that that thinks there is not really an issue here, t=
he
last paragraph applies.
Brett, you next step (if there is any next step) is to use apples and oran=
ges!!
Mario Lobo
> Acutally, it doesn't. And it really hurts evangelism and new
> adopters of FreeBSD.
>
> For example, here's a rough transcript of a conversation I recently
> had with an admin who wanted to put up a FreeBSD server.
>
> Prospective user: FreeBSD sounds neat. How do I install it?
>
> Me: Well, it's really easy. You just put in the first install floppy,
> boot the system, insert the second floppy when asked, and away you
> go. You can get the release floppies at ftp://www.freebsd.org/.
>
> Prospective user: But I've heard that there were some security holes
> and bugs discovered since then. How do I install a version with those
> problems fixed?
>
> [What I'd like to say: Oh, that's simple. In the same directory
> you'll see 4.5-RELEASE, 4.5-RELEASE-p1, 4.5-RELEASE-p2, et
> cetera. Just get the floppies for the most recent one, and it
> will have all the critical fixes.
>
> What I'd like to hear the prospective user say: This is great!
> I'm glad that FreeBSD lives up to its reputation for being
> easy to install.]
>
> What I have to say now: That's not so simple. First, you have
> to install the last ful release, bugs and all. Then, you have
> to use CVSup...
>
> Prospective user: What's that?
>
> Me: Well, it updates your source tree to include the latest fixes.
>
> Prospective user: Source tree? I'm not ready to play with the
> source; I'm not familiar with the system yet, and I don't know
> what this CVSup thing is.
>
> Me: Unfortunately, there's no other way to do it. You have to
> get the latest source, using the tag RELENG_4_5, and then
> do a "make world."
>
> Prospective user: What's a tag? How do I use it? And what's a
> "make world?" And how do you find out the name "RELENG_4_5"
> if you don't know it already?
>
> Me: Do you have about half an hour? I can teach you the basics
> of CVSup....
>
> Prospective user: Naah, never mind. This is more complicated than
> I thought, and it's a lot more complicated than installing
> Red Hat and installing the latest RPMs to fix the bugs. I just
> wanted to download a version of the OS that's secure, but I
> don't have time to learn about all this stuff you're talking
> about right this minute. I guess I'll stick with {Win2K/Linux}.
>
> (End of dialogue)
>
> As you can see from the above, FreeBSD doesn't have a simple answer
> to a simple, reasonable question: "How can I *just install* FreeBSD
> with all of the latest security fixes on a new machine, without
> walking off of a conceptual cliff?"
>
> We need to address this. Not only would it help newcomers; it would
> also help admins who just want to do a quick, no-hassle upgrade that
> includes the latest security fixes. We should NOT say, "the heck with
> them if they're not willing to learn all sorts of developer stuff on
> the spot." That's pointless elitism. And we shouldn't make it
> unreasonably hard for admins to update... or they might not do it.
> And then, when their systems are broken into, FreeBSD's reputation
> as a secure OS suffers.
>
> --Brett Glass
>
To Unsubscribe: send mail to majo...@FreeBSD.org
Stanley....@ipaustralia.gov.au
I am writing to say that this has been an admirable thread and sum up
by saying that it's unlikely the FreeBSD upgrade system is likely to
satisfy the characters depicted below.
However, they may be better off with other operating systems. Is this
argument really anything more than OS Y does X better ?
Granted that the upgrade system could be improved, I think that this is
an opportunity for others to step forward, since the projects resources
probably don't give it the priority the plaintiffs think it needs.
I think the project delivers well in areas such as=20
. stability
. applications
. device support
. performance
. security
These are more important to me than the upgrade path (which meets my
relatively low tech needs).
Surely not many are as impressed by upgradability - pain in anyones
language - as features.
BTW, it seems to me that the skills required to safely upgrade any OS
are not coding skills and are unlikely to be found among casual computer
users.
I am neither coder nor sys admin, yet the use of CVS and friends, once I
bit the bullet, wasn't all that daunting. Would it be as hard as
learning UML, J2EE, writing a parser ? I don't think so.
On Fri, Apr 19, 2002 at 08:04:01AM -0300, Mario Lobo wrote:
> I=B4ve been following this thread since it started and this is the DEFI=
NITE=20
> exposition of the problem that Brett has been trying to show since the=20
> beginning. To anyone that that thinks there is not really an issue here=
, the=20
> last paragraph applies.
>=20
> Brett, you next step (if there is any next step) is to use apples and o=
ranges!!
>=20
> Mario Lobo
>=20
> >=20
> > We need to address this. Not only would it help newcomers; it would
> > also help admins who just want to do a quick, no-hassle upgrade that
> > includes the latest security fixes. We should NOT say, "the heck with=
=20
> > them if they're not willing to learn all sorts of developer stuff on=20
> > the spot." That's pointless elitism. And we shouldn't make it
> > unreasonably hard for admins to update... or they might not do it.
> > And then, when their systems are broken into, FreeBSD's reputation=20
> > as a secure OS suffers.
Thank you,
Yours sincerely.
--=20
------------------------------------------------------------------------
Stanley Hopcroft Network Specialist
------------------------------------------------------------------------
'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'
from Meditation 17, J Donne.
sea...@unt.edu
I'm running two systems on 4.3-RELEASE-p28; I am guessing they are
vulnerable. If so, what steps do I follow to patch the system?
Upgrading is not an option since the fxp (QLogic fibre-channel HAB)
driver is very flaky since 4.4 and above.
The patches seem to make relavent changes; I just want to be sure.
Thanks!
--
____________________________________________________
Curry Searle | Postmaster
sea...@unt.edu | Unix Hosts
www.cas.unt.edu/~searle | Xiotech Support
College of Arts & Sciences | Win32 Desktop & Server
Computer Support Services | Network HW & Protocols
freeb...@hotmail.com
brett glass writes:
>Sure, to start with. And then I customize it. If my kernel config
>files are preserved through the update, I can do that very quickly.
i thought you were trying to avoid rebuilding the kernel??? if your gonna
build the kernel, just build world also! and use a dedicated build server
like other's have suggested.
he's aboviously changing his questions every other post just to get people
on this list riled up(mission accomplished.)
as other people have noted, he does this frequently, so let's just stop this
thread and get back to security. please!
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
haw...@visi.com
appropriate, this time.
In article <3CC02BB3.103...@ns.sol.net>,
sea...@unt.edu writes:
> The patch described in the advisory talks about 4.5-RELEASE.
> I'm running two systems on 4.3-RELEASE-p28; I am guessing they are
> vulnerable. If so, what steps do I follow to patch the system?
>
> Upgrading is not an option since the fxp (QLogic fibre-channel HAB)
> driver is very flaky since 4.4 and above.
>
> The patches seem to make relavent changes; I just want to be sure.
I was going to ask the same thing today, to try to provide backported
patches. I assume you're writing of source patches, not binary patches?
Let's stay in contact with one another on this. If 4.4 and earlier are
vulnerable and patchable (that is, no make world required), I'll create
patchfiles and make them available. It may take me a day or two, though.
Developers: Userland is affected here - /usr/lib/libz. Would a
"make && make install" (sic) in /usr/src/lib/libz before building the
kernel suffice for a solid upgrade?
> Thanks!
Ditto,
Dave
--
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
kar...@rohrbach.de
--s5/bjXLgkIwAv6Hi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Doug Barton(Do...@FreeBSD.org)@2002.04.18 18:07:54 +0000:
> The typical FreeBSD answer is, "Since YOU think it's a problem,
> why don't YOU work to solve it?" However, since to my knowledge your
> record of never actually contributing a line of code to the project
> remains unblemished, I know you don't like that answer very much.
doug, the "lines of code" argument does not apply to people supplying
ideas, or experience from operations. take me for example, i am not much
of a c coder, so i see it as a contribution to the world _not_ to put
my sources out, them being pretty crappy and likely to screw up things
badly. OTOH, i answer questions on the mailing lists and contribute my
ideas to the community, all originating from my work expeieence with
freebsd and other systems, you get the point.
> I also think that the new RELENG_N_N idea is a good one, and it
> may do your heart good to know that I took your point about not being able
> to easily ascertain how many patches have been applied to a particular
> point in that branch up with the release engineers just now. I agree that
> it's valid, and should be easy to fix with newvers.sh, if it's not already
> fixed (I haven't been following developments on that stuff too closely).
how about including the tag of the last applied patches' corresponding
security advisory for the RELENG_4_?
what i did in my internal releases was including a date tag relating to
a local changelog (including cvsup dates, local changes, and so on).
this additionally gives a compile-time independent timestamp for the
release.
or, how about the "official" patch naming? "4.5-STABLE-p3" and the like?
just a few ideas...
regards,
/k
--=20
> "Afghanistan proved that expensive precision weapons save innocent lives,=
=20
> and we need more of them." -- George W. Bush, 2002 State of the Union Add=
ress
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--s5/bjXLgkIwAv6Hi
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8wDMVM0BPTilkv0YRAnyTAJ0WuqyRgLYGRDunA60pFRA3AzKmxQCgogWE
fsuJtinVXV/ylH74PXzRetc=
=g5qg
-----END PGP SIGNATURE-----
--s5/bjXLgkIwAv6Hi--
br...@lariat.org
> I think everyone agrees that you have problems Brett.
Being insulting doesn't further the discussion.
>> It's not a "favorite hobby horse" but rather a longstanding issue.
>> Why not work to solve the problem?
>
> The typical FreeBSD answer is, "Since YOU think it's a problem,
>why don't YOU work to solve it?"
I am -- by putting up with invectives such as the ones you've
hurled at me in recent messages. Putting up a specific build on
the FTP server and mirrors is not something I can physically do,
but I can demonstrate the need and the benefits that will come
from it. As with the "High" security option in the current
FreeBSD install (which I was also flamed for suggesting on the
lists. It's amazing how any new idea, good or bad, is answered
with flames by some people).
>However, since to my knowledge your
>record of never actually contributing a line of code to the project
>remains unblemished,
I've actually had code in FreeBSD since 1995 or so. Mostly small
stuff, and all contributed through others because I'm not a
committer. But some of it is important.... Such as the recent changes
to syslogd that allow automatic monitoring. (These were featured in
my paper at the first Usenix BSDCon.)
> I also think that the new RELENG_N_N idea
I see; it's "the" new RELENG_N_N idea, not mine. Can't give me
credit for anything, can you? ;-)
>is a good one, and it
>may do your heart good to know that I took your point about not being able
>to easily ascertain how many patches have been applied to a particular
>point in that branch up with the release engineers just now. I agree that
>it's valid, and should be easy to fix with newvers.sh, if it's not already
>fixed (I haven't been following developments on that stuff too closely).
It's a start. But we also need to make the security branch the one that
new users get, by default, when they visit the FreeBSD Web site, get
floppy images, and download via the Net. It would also be exceedingly
useful to post -- prominently -- a patch that upgrades buyers of the
last release on CD to the same build, and to display a message at the end
of sysinstall directing users to the page where it's located. This way,
every new install will be as secure as we currently know how to make it.
This is not only good publicity; if you believe (as I do) that it's
unethical to knowingly give someone an insecure version to install when
a secure one can is readily available, it's just good ethics. Other
benefits, such as giving admins a verstion to which they can upgrade
quickly, would also arise from this. It's a total win.
--Brett
nec...@freebsd.org
> The patch described in the advisory talks about 4.5-RELEASE.
> I'm running two systems on 4.3-RELEASE-p28; I am guessing they are
> vulnerable. If so, what steps do I follow to patch the system?
For this PARTICULAR advisory, the bug was introduced after
4.4-RELEASE, so there is no need for you to patch your system.
The answer for other issues in general are:
You are officially on your own. The releases which are currently
supported by the Security Officer are 4.4 and 4.5 (as always, the
current release and the previous release).
> Upgrading is not an option since the fxp (QLogic fibre-channel HAB)
> driver is very flaky since 4.4 and above.
The `fxp' driver is not the `QLogic fibre-channel HAB' driver.
> The patches seem to make relavent changes; I just want to be sure.
You may certainly back port patches to 4.3. Maybe someone here will
be generous and backport the fix, test it, and post it to the list.
Cheers,
--
Jacques A. Vidrine <n...@nectar.cc> http://www.nectar.cc/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvid...@verio.net . nec...@FreeBSD.org . nec...@kth.se
nec...@freebsd.org
advisory was the topic of this thread.]
On Fri, Apr 19, 2002 at 09:29:13AM -0600, Brett Glass wrote:
> > I also think that the new RELENG_N_N idea
>
> I see; it's "the" new RELENG_N_N idea, not mine. Can't give me
> credit for anything, can you? ;-)
It is not new and it is not yours. We have been updating newvers.sh
on the security branches for 8 months now (since 4.3-RELEASE-p12).
> But we also need to make the security branch the one that
> new users get, by default, when they visit the FreeBSD Web site, get
> floppy images, and download via the Net.
Finally, a reasonable suggestion. It has come up many times, but the
issue is always the same: resources. Do you have some to contribute?
> It would also be exceedingly
> useful to post -- prominently -- a patch that upgrades buyers of the
> last release on CD to the same build, and to display a message at the end
> of sysinstall directing users to the page where it's located.
We have experimental binary patches for some time now, and we're not
ready quite yet to stop calling them `experimental'. When we do, you
can be sure that we will announce it.
Cheers,
--
Jacques A. Vidrine <n...@nectar.cc> http://www.nectar.cc/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvid...@verio.net . nec...@FreeBSD.org . nec...@kth.se
To Unsubscribe: send mail to majo...@FreeBSD.org
nec...@freebsd.org
> Developers: Userland is affected here - /usr/lib/libz. Would a
> "make && make install" (sic) in /usr/src/lib/libz before building the
> kernel suffice for a solid upgrade?
No, the src/lib/libz is --- as you note --- for userland. It is not
used by the kernel.
Note that the patch includes updates to the kernel source as well.
Also note that `savecore' statically links libz, so it must be
recompiled and reinstalled also. I don't believe there are any other
programs in the base system that statically link libz.
Cheers,
--
Jacques A. Vidrine <n...@nectar.cc> http://www.nectar.cc/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvid...@verio.net . nec...@FreeBSD.org . nec...@kth.se
To Unsubscribe: send mail to majo...@FreeBSD.org
Do...@freebsd.org
> Doug Barton(Do...@FreeBSD.org)@2002.04.18 18:07:54 +0000:
> > The typical FreeBSD answer is, "Since YOU think it's a problem,
> > why don't YOU work to solve it?" However, since to my knowledge your
> > record of never actually contributing a line of code to the project
> > remains unblemished, I know you don't like that answer very much.
>
> doug, the "lines of code" argument does not apply to people supplying
> ideas, or experience from operations. take me for example, i am not much
> of a c coder, so i see it as a contribution to the world _not_ to put
> my sources out, them being pretty crappy and likely to screw up things
> badly. OTOH, i answer questions on the mailing lists and contribute my
> ideas to the community, all originating from my work expeieence with
> freebsd and other systems, you get the point.
Oh, I agree completely. The problem is, at the end of the day,
this is a volunteer organization. If no one volunteers to make your idea a
reality, you're pretty well stuck in do it yourself mode.... unless your
idea of fun is to sit around and wait for the topic to come up and make a
nuisance of yourself over and over again.
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
Do...@freebsd.org
> At 07:07 PM 4/18/2002, Doug Barton wrote:
>
> > I think everyone agrees that you have problems Brett.
>
> Being insulting doesn't further the discussion.
I was trying to inject a little humor into the situation.... thus
the smiley which you seem to have deleted.
> >> It's not a "favorite hobby horse" but rather a longstanding issue.
> >> Why not work to solve the problem?
> >
> > The typical FreeBSD answer is, "Since YOU think it's a problem,
> >why don't YOU work to solve it?"
>
> I am -- by putting up with invectives such as the ones you've
> hurled at me in recent messages.
Ok, now I'm going to be insulting. You have officially sunk to a
new low. "They're being mean to me, therefore I'm contributing to the
project!"
(I new I should not have contributed to this thread...)
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
To Unsubscribe: send mail to majo...@FreeBSD.org
megat...@pacbell.net
--Boundary_(ID_DK/v9UVviBTmeeeLTnWvgA)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
At 08:30 PM 4/18/2002 -0600, Brett Glass wrote:
>Having a local build server is a nice idea, especially if you're
>a large shop, but doesn't get newcomers a safe version to install
>(important; if they're hacked they'll sour on FreeBSD) or give
>an admin a build to which she can just upgrade quickly and know
>that the latest holes are closed.
>
>--Brett
Brett,
I've been watching this thread quietly, as I am a "newcomer" to FreeBSD.
However your intimation that we'll run for the hills like children at the
first sign of difficult offends me.
First, anyone connected to the net who ever thinks that their box is ever
"safe" needs a reality check. Pretty good assumption for a newcomer, eh? I
came to FreeBSD because of its security and groups like this. If my site
gets hacked, I'm not going to "sour" on FreeBSD, I'm going to take
advantage of this group and all the other wonderful resources available to
this community and figure out what I need to learn to do better.
Just because we're new to FreeBSD doesn't mean we're sheep. We all know
where the sheep graze. Nobody ever told me that FreeBSD was easy. Nobody
ever told me it was secure "out of the box". What I heard was that if I was
willing to learn how to do it, FreeBSD has the potential to be one of the
most powerful and secure operating systems out there. I never thought that
all the work was going to be done for me, or that the process would be easy
of end. If technology was easy, sysadmins would get paid minimum wage and
have to wear polyester uniforms and funny little hats.
Anyone who runs from an OS due to their own inability to learn how to
properly configure/maintain it can go run Windows and contribute to
Microsoft's ongoing track record for security and stability.
You sound like you know exactly what you want. Why not put it together?
Hey, if you build it, it'll be done exactly the way you want it done, won't
it? Don't let this opportunity pass you up! Here's your chance to have a
piece of FreeBSD work perfectly for you! I'd code it, but my skills aren't
up to snuff (yet) and I don't figure that any of these kind people should
have to bear the burden of holding my hand. So I send my money to O'Reilly
and I spend my time learning how to do new things. One of these days I will
contribute to this body of work, but not until I've got the chops (I'd like
to fix bugs, not introduce them ;-) ).
If you aren't careful, one of these days you'll be griping about the update
mechanism I wrote, because I won't code it the way you want, I'll code it
the way I want.
Life is wonderful when you just deal with what IS. I read this list to
learn how to use the tools I currently have to do the best job I can, not
to watch theory wars via email. If you don't like things the way they are,
step up to the plate and do something about it. Otherwise, we all heard
what you said, so please remain in the audience and take your seat.
Personally, my hat's off to the fine folks who post the security
notices, analyze the bugs, write the code, debug the code, and maintain
the source tree, all for a FREE OS! Without the people who actually do all
the work that you're complaining about, you'd have to do all that work
yourself (or "sour" on FreeBSD, as you put it). Try applying THAT across
1000 servers sometime.
-Greg
P.S. If you really must respond to this, please email me directly. No need
to clutter the group with more witty banter or high drama.
Greg Fortune
Megaton Technologies
megat...@pacbell.net
------------------------------------------
"Those who say it can't be done should
get out of the way of those who are doing it."
--Boundary_(ID_DK/v9UVviBTmeeeLTnWvgA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT
<html>
At 08:30 PM 4/18/2002 -0600, Brett Glass wrote:<br><br>
<blockquote type=cite class=cite cite>Having a local build server is a
nice idea, especially if you're<br>
a large shop, but doesn't get newcomers a safe version to install<br>
(important; if they're hacked they'll sour on FreeBSD) or give<br>
an admin a build to which she can just upgrade quickly and know<br>
that the latest holes are closed.<br><br>
--Brett<br>
</blockquote><br>
Brett,<br><br>
I've been watching this thread quietly, as I am a "newcomer" to
FreeBSD. However your intimation that we'll run for the hills like
children at the first sign of difficult offends me.<br><br>
First, anyone connected to the net who ever thinks that their box is ever
"safe" needs a reality check. Pretty good assumption for a
newcomer, eh? I came to FreeBSD because of its security and groups like
this. If my site gets hacked, I'm not going to "sour" on
FreeBSD, I'm going to take advantage of this group and all the other
wonderful resources available to this community and figure out what I
need to learn to do better.<br><br>
Just because we're new to FreeBSD doesn't mean we're sheep. We all know
where the sheep graze. Nobody ever told me that FreeBSD was easy. Nobody
ever told me it was secure "out of the box". What I heard was
that if I was willing to learn how to do it, FreeBSD has the potential to
be one of the most powerful and secure operating systems out there. I
never thought that all the work was going to be done for me, or that the
process would be easy of end. If technology was easy, sysadmins would get
paid minimum wage and have to wear polyester uniforms and funny little
hats.<br><br>
Anyone who runs from an OS due to their own inability to learn how to
properly configure/maintain it can go run Windows and contribute to
Microsoft's ongoing track record for security and stability.<br><br>
You sound like you know exactly what you want. Why not put it together?
Hey, if you build it, it'll be done exactly the way you want it done,
won't it? Don't let this opportunity pass you up! Here's your chance to
have a piece of FreeBSD work perfectly for you! I'd code it, but my
skills aren't up to snuff (yet) and I don't figure that any of these kind
people should have to bear the burden of holding my hand. So I send my
money to O'Reilly and I spend my time learning how to do new things. One
of these days I will contribute to this body of work, but not until I've
got the chops (I'd like to fix bugs, not introduce them ;-) ).<br><br>
If you aren't careful, one of these days you'll be griping about the
update mechanism I wrote, because I won't code it the way you want, I'll
code it the way I want.<br><br>
Life is wonderful when you just deal with what IS. I read this list to
learn how to use the tools I currently have to do the best job I can, not
to watch theory wars via email. If you don't like things the way they
are, step up to the plate and do something about it. Otherwise, we all
heard what you said, so please remain in the audience and take your
seat.<br><br>
Personally, my hat's off to the fine folks who post the security
notices, analyze the bugs, write the code, debug the code, and
maintain the source tree, all for a FREE OS! Without the people who
actually do all the work that you're complaining about, you'd have to do
all that work yourself (or "sour" on FreeBSD, as you put it).
Try applying THAT across 1000 servers sometime.<br><br>
-Greg<br><br>
P.S. If you really must respond to this, please email me directly. No
need to clutter the group with more witty banter or high drama.<br>
<x-sigsep><p></x-sigsep>
<b><i>Greg Fortune<br>
</b>Megaton Technologies<br>
megat...@pacbell.net<br>
------------------------------------------<br>
</i>"Those who say it can't be done should<br>
get out of the way of those who are doing it."</html>
--Boundary_(ID_DK/v9UVviBTmeeeLTnWvgA)--
kar...@rohrbach.de
--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Doug Barton(Do...@FreeBSD.org)@2002.04.19 11:45:28 +0000:
[...]
> > doug, the "lines of code" argument does not apply to people supplying
> > ideas, or experience from operations. take me for example, i am not much
> > of a c coder, so i see it as a contribution to the world _not_ to put
> > my sources out, them being pretty crappy and likely to screw up things
> > badly. OTOH, i answer questions on the mailing lists and contribute my
> > ideas to the community, all originating from my work expeieence with
> > freebsd and other systems, you get the point.
>=20
> Oh, I agree completely. The problem is, at the end of the day,
> this is a volunteer organization. If no one volunteers to make your idea a
> reality, you're pretty well stuck in do it yourself mode.... unless your
> idea of fun is to sit around and wait for the topic to come up and make a
> nuisance of yourself over and over again.
i just wanted to point out that not everyone in the community is a coder
demigod, but a lot of people come up with good ideas. you're perfectly
right with that statement above, because code simply doesn't write
itself.=20
and, yes, in my spare time i am currently experiencing quite a steep
learning curve in understanding netbsd's/freebsd's make system, and
emacs, and some more minor fundamental things that have to do with
"hard" code. i did my cs studies in darmstadt, quite some 10 years ago,
and i do try very hard to acquire the knowledge to be able to play with
the build system, as a first step. the code i write for stuff i need, on
a daily basis, is mostly in python, just as a sidenote, so you hopefully
understand my deficiencies in reading and writing C code or makefiles.
as it comes to committing code to the project, you already read my
statement, on how i see my C proficiencies. i once made an apache module
to drive netscape 3.x remote configuration and isp service registration.
this was the only compiled language project in _years_ (and i was glad
when it ran in production and we were finished with it). another small
tool is /usr/ports/sysutils/timelimt, by peter pentchev, where i hacked
some docs and contributed some ideas, but i must admit that in this
little program, my language knowledge increased quite a bit, but not
sufficiently to modify os or userland code, or create new programs
(in C).
i guess the comparison of your perspective as a proficient (i hope
that's the right word) C coder to mine as a systems administrator is
like you would sit down read the handbook and translate it to a language
you do not speak (for example thai), chapter by chapter. it's simply a
steep learning curve keeping a lot of folks from being a guru, but
that's not really a bad thing.
when it comes to personal experience to share with the community - i
mean system administration questions, operations knowledge, etc. - you
know that i always shared and will share that openly. i also provide a
complete cvsup server in .de (which is not listed at the moment, btw.)=20
because i think that this is one way to give something back to the=20
community.
> Do YOU Yahoo!?
no, i google ;-)
regards,
/k
--=20
> Tragedy is when I cut my finger. Comedy is when you walk into an open
> sewer and die. --Mel Brooks
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--neYutvxvOLaeuPCA
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8wHq1M0BPTilkv0YRAjdRAJ9O5y/jAo2dq/x/0LR6o/GoYIEDogCfZpac
qJuhpNBtfKsVqsYXauLEWGs=
=nPeW
-----END PGP SIGNATURE-----
--neYutvxvOLaeuPCA--
mar...@roble.com
>First, anyone connected to the net who ever thinks that their box is ever
>"safe" needs a reality check.
Please try to keep the invective down. This thread has not been
about subjective measures of safety. All agree that applying large
amounts of new code cannot be as safe as applying specific patches
with a minimum of new code.
>Pretty good assumption for a newcomer, eh?
You're joking (and forgot the smiley) I hope.
>Just because we're new to FreeBSD doesn't mean we're sheep. We all know
>where the sheep graze. Nobody ever told me that FreeBSD was easy. Nobody
>ever told me it was secure "out of the box".
If you have something to say about CVSup or the current method of
applying patches or labeling releases then do contribute. Until
then we can all do without diatribes like Greg's. There certainly
are many ways to improve FreeBSD and we should not require the
submission of code or money in exchange for the privilege of pointing
them out.
If I knew how to get a better patch system implemented into FreeBSD
I would. What this thread makes clear, however, is that it's not
about submitting improvements, it's about legacy methodology. The
current majority of -security subscribers seem to be happy with
CVSup and buildworld and unhappy with the prospect of learning
anything different. As a result we're stuck with the status quo.
That and the resultant small market share which forces most of us
to use and support other operating systems in order to earn a
living. If you want a better FreeBSD just copy Solaris' patch
system wholesale. There's no need to reinvent the wheel. The real
problem, however, is cultural. Exactly how do you submit a new
patch system over the objections of legacy developers.
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
Do...@freebsd.org
> i just wanted to point out that not everyone in the community is a coder
> demigod, but a lot of people come up with good ideas. you're perfectly
> right with that statement above, because code simply doesn't write
> itself.
Personally, I fall cleanly into the non "coder demigod" camp. I'm
functional in C, but I doubt that I'll ever attain the heights that many
in the project have. But that never stopped me from contributing. I
contributed what skills I do have for a long time before I got a commit
bit. Nowadays, I maintain some ports, clean up PR stuff when I can,
twiddle /etc... submit mostly aesthetic 3 line patches to things I care
about... basically, a lot of the piddly stuff that has to happen in order
to keep things functional. I also keep threatening to write some
documentation, but never seem to find the time.
My point is that whatever your level of experience, you CAN
contribute to the project if you want to. Even if your only contribution
is ideas for improvements that are based on your level of experience,
because we need that too. I long ago forgot what it was like to be a new
FreeBSD user, even though I still focus on interface design because it's
something I have some skill/interest in. What you(pl.) CAN'T do, is sit on
the sidelines and log grenades in periodically about how the project is
not responsive to your needs. Both becase that's not how things work, and
because it's not true. We DO have a response. The response is, do it your
self and quit whining about it. :)
> and, yes, in my spare time i am currently experiencing quite a steep
> learning curve in understanding netbsd's/freebsd's make system, and
> emacs,
Eeekk.. stop learning emacs asap, before it corrupts your brain.
:)
> > Do YOU Yahoo!?
>
> no, i google ;-)
That's cool, they are one of our partners. :)
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
To Unsubscribe: send mail to majo...@FreeBSD.org
br...@lariat.org
>I long ago forgot what it was like to be a new
>FreeBSD user,
This is part of the problem here. We should care a lot about
newcomers' experience, and respect the fact that no matter
how bright they are they cannot learn everything at once.
Expecting a new user to master CVSup is unreasonable.
--Brett
sir...@cowbert.2y.net
It has been said (by various people, mostly those from the latter computing
age of PDP,VAX,and s/390) that a good sysadmin is one that should be able
to script (or otherwise automate/routin-ize) themselves out of a job.
Administration is just that. Read: management from the desk, planning,
communications, finding people and tasking them to deploy or implement.
Sysadmin-ship historically was maintaining system components that could not
maintain themselves. This included loading software from tape, backing up
to tape, providing user-requested features and fixing failures. With
modern systems, the OS is but one very small part of the whole equation.
It is supposed to provide a user-computer interface to load and run
programs. It ought to be as automated and easy to implement as possible,
with high reliability and security.
There really is no reason why UNIX or FreeBSD should be harder to
deploy or implement than WinNT or Solaris. A "solution" being the
buzzwords of these days, is exactly what it should mean.
You are supposed to tell your boss "we need this functionality,
this vendor supplies something with that. It costs this much compared
to this other thing, and the implementation time is 1 day"
Unless you are truly masochistic, I'm pretty sure you don't want to spend your
nights trying learning the nuances of an OS that you picked because
you lost an OS flamewar with your favorite security mailing list ;)
In effect, the old saying "Unix is userfriendly, it's just picky about its users"
should really ring less and less true as we develop more advanced
versions of it.
> Anyone who runs from an OS due to their own inability to learn how to
> properly configure/maintain it can go run Windows and contribute to
> Microsoft's ongoing track record for security and stability.
>
It isn't running away. see above :) At a company, you don't *learn*
how to properly configure an OS, you do it. Years ago, I used to work at a place
where the motivational poster was "This is not a University".
Companies who hire administrators expect that their people know what's going
on and enough knowledge to run the systems. I suppose if someone
wants to migrate software platforms they should be educated to some
extent about the target platform, but how do we use this as a
FreeBSD selling point instead of hindering potential users
to begin using FreeBSD? (see comment below)
If it's going to take additional human resources to implement FreeBSD over
some other OS, with the same sort of stability and reliability, then
maybe it's not such a good idea. Sysadmins have better things to do
than maintain build servers and worry if the next patch breaks the OS.
They should be figuring out improvements in efficiency, user training,
uptime, infrastructure growth and assessing the needs of users or clients.
> You sound like you know exactly what you want. Why not put it together?
> Hey, if you build it, it'll be done exactly the way you want it done, won't
> it? Don't let this opportunity pass you up! Here's your chance to have a
> piece of FreeBSD work perfectly for you! I'd code it, but my skills aren't
> up to snuff (yet) and I don't figure that any of these kind people should
> have to bear the burden of holding my hand. So I send my money to O'Reilly
> and I spend my time learning how to do new things. One of these days I will
> contribute to this body of work, but not until I've got the chops (I'd like
> to fix bugs, not introduce them ;-) ).
>
> If you aren't careful, one of these days you'll be griping about the update
> mechanism I wrote, because I won't code it the way you want, I'll code it
> the way I want.
>
> Life is wonderful when you just deal with what IS. I read this list to
> learn how to use the tools I currently have to do the best job I can, not
> to watch theory wars via email. If you don't like things the way they are,
> step up to the plate and do something about it. Otherwise, we all heard
> what you said, so please remain in the audience and take your seat.
>
> Personally, my hat's off to the fine folks who post the security
> notices, analyze the bugs, write the code, debug the code, and maintain
> the source tree, all for a FREE OS! Without the people who actually do all
> the work that you're complaining about, you'd have to do all that work
> yourself (or "sour" on FreeBSD, as you put it). Try applying THAT across
> 1000 servers sometime.
But then again, the objective of FreeBSD advocacy is to say that we
provide a suitable replacement enterprise level OS in a production
environment on mission critical systems. The main argument
would favor improved binary patch system with minimal downtime and
maximum stability. If more people are to expected to adopt open source
operating systems, then Brett's point is that a successful binary
patch system is also an important marketing feature.
Normally, with commercial vendors, the sysadmin will consult those
technicians to result in a working solution to a patch. That's the
price of a support contract. You are walked through the upgrade
process, and if something breaks, the vendor is responsible for fixing
it. (I'm talking about large implementations here, such as our S/390
support contracts. Downtime of over an hour is unacceptable, so
the protocols for microcode updates have been written by IBM
for our customized systems, and in the case they failed to forsee
an event, they have a tech on hand. Similarly, I've never seen
any particularly involved AIX patch because we needed to reinstall all
the core binaries for an update - we just install the binaries on
the patch CD, and half the time don't even need to reboot.)
With open source, mailing lists such as these are typically
your main source of support. However, utilities facilitating
easy system upgrades such as a reliable binary patch system
would again be beneficial not only to existing users, but
also to potential users.
As a sidenote, linux operators commonly exclaim why I have to spend
hours compiling all of my core software, and then take down the system
to patch a system when all they do to fix vulns is to download the latest
rpm or deb. Similarly, microsofties download the latest SP (even though
it's usually 5 months later :) and reboot.
>
> -Greg
>
> P.S. If you really must respond to this, please email me directly. No need
> to clutter the group with more witty banter or high drama.
>
> Greg Fortune
> Megaton Technologies
> megat...@pacbell.net
> ------------------------------------------
> "Those who say it can't be done should
> get out of the way of those who are doing it."
--
Peter C. Lai
University of Connecticut
Dept. of Residential Life | Programmer
Dept. of Molecular and Cell Biology | Undergraduate Research Assistant
http://cowbert.2y.net/
860.427.4542 (Room)
860.486.1899 (Lab)
203.206.3784 (Cellphone)
kar...@rohrbach.de
--jy6Sn24JjFx/iggw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Brett Glass(br...@lariat.org)@2002.04.19 16:12:33 +0000:
> At 04:07 PM 4/19/2002, Doug Barton wrote:
>=20
> >I long ago forgot what it was like to be a new
> >FreeBSD user,=20
>=20
> This is part of the problem here. We should care a lot about
> newcomers' experience, and respect the fact that no matter
> how bright they are they cannot learn everything at once.
> Expecting a new user to master CVSup is unreasonable.
brett,=20
i'm sorry, but reading this thread made me think about the days when i
started using freebsd and set up my first server. after being left alone
at a root user prompt "# " i learned how to configure the stuff in /etc,
that docs are in /usr/share/doc, how to install packages, and then how
to cvsup (for building upt to date versions out of the ports tree).
in my personal opinion, i find the RPM or binary-only distribution
mechanism very dangerous for users, because it is mainly the microsoft
approach to hide software complexity behind an interface the user has to
trust. i personally do not trust binary package systems (although i am
forced to use them sometimes), nor do i blindly trust the ports tree.
yes, i mean i _read_ the make files and view the output of the make
process before installing a port the first time on one box. then i make
a package out of it. that's all personal preference, yes.
IMVHO, what would be a good thing[tm] for the source dist (/usr/src) is
a Changelog file, containing the history of major fixes/enhancements to
the currently installed sources. it would be very easy to write a little
wrapper that saves /usr/src/Changelog (or maybe even a whole hierarchy
of subsystem Changelogs) to a backup and then diffs out the changes
after the update completed. this gives at least some overview about what
has changed and where to look for potential breakage.
it would be very good, if some of the committers could comment on that.
regards,
/k
--=20
> It's not that perl programmers are idiots, it's that the language rewards
> idiotic behavior in a way that no other language or tool has ever done.=
=20
> --Erik Naggum=20
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--jy6Sn24JjFx/iggw
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8wLW1M0BPTilkv0YRAl3jAJ9fJ5Sk8a6cspaWQ1zL999UK5amowCcD5G/
PyZoL5PZ2sIdiJDss/LJi1w=
=za7G
-----END PGP SIGNATURE-----
--jy6Sn24JjFx/iggw--
Hostm...@video2video.com
> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
{My lord! Is this thread still alive?! The secu...@freebsd.org list is
for legitimate, authoritative notices only is it not...}
> Brett Glass(br...@lariat.org)@2002.04.19 16:12:33 +0000:
> > At 04:07 PM 4/19/2002, Doug Barton wrote:
> > >I long ago forgot what it was like to be a new FreeBSD user,
> > This is part of the problem here. We should care a lot about newcomers' experience, and respect the fact that no matter how bright they are they cannot learn everything at once. Expecting a new user to master CVSup is unreasonable.
Hi Karsten. The FreeBSD (and most *nix OS folk) community *does* care tons
about newcomers. It's the newcomers that make demands, snap judgments, and
ask endless questions without RTFM or RTFMOTT (... once told to) that are
disliked and as such scolded, often somewhat harshly but -- well, you gadda
make an example. :)
Besides, nobody expects anyone to "master" any command (cvsup for example).
That is unreasonable and everyone would agree; Are you confusing goals with
inferences? For example, Jane J. wishes to master (or mistress) the grep
command, so she posts to a list "How do I use grep?" Someone replies "man
grep" and Jane J. gets all fussy because this cold-hearted posting person
is somehow impeding her from becoming "Grep Expert of the Planet." *lol*
> brett, i'm sorry, but reading this thread made me think about the days when i started using freebsd and set up my first server. after being left alone at a root user prompt "# " i learned how to configure the stuff in /etc, that docs are in /usr/share/doc, how to install packages, and then how to cvsup (for building upt to date versions out of the ports tree).
I always log in as root - The thinking is... rm doesn't scare me one bit! :)
> in my personal opinion, i find the RPM or binary-only distribution mechanism very dangerous for users, because it is mainly the microsoft approach to hide software complexity behind an interface the user has to trust. i personally do not trust binary package systems (although i am forced to use them sometimes), nor do i blindly trust the ports tree. yes, i mean i _read_ the make files and view the output of the make process before installing a port the first time on one box. then i make a package out of it. that's all personal preference, yes.
Don't know practically nuttin about RPM, but if you are concerned about
security and customizable control of pkg_add, remember the following: You
can *always* just ftp the package (a tarball, or somecommandhere_3.1.1.tgz)
to your box, gunzip and untar the contents... edit them in your favorite
editor and then "make" or "make clean" or "make install" manually (you can
tell beyond a certain point in this sentence I know not about what I speak)!
> IMVHO, what would be a good thing[tm] for the source dist (/usr/src) is a Changelog file, containing the history of major fixes/enhancements to the currently installed sources. it would be very easy to write a little wrapper that saves /usr/src/Changelog (or maybe even a whole hierarchy of subsystem Changelogs) to a backup and then diffs out the changes after the update completed. this gives at least some overview about what has changed and where to look for potential breakage. it would be very good, if some of the committers could comment on that.
> regards,
> /k
No comment. (Uninformed.)
> > It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. --Erik Naggum
What does this Chief Wiggum, er, Erik Naggum know about PERL anyways?!
_P_erl _E_eez _R_eallllly _L_ovable. :) By the way your quote brought to
the forward hanging, thin branch of thought on the tip of my cortical
cortex in the pink matter left of the grey matter, or something, this:
It's not that MACOS USERS are idiots, it's that the OS rewards idiotic
behavior in a way that no other OS or SOFTWARE [ever has]. --Peter Leftwich
(For the record, I think very highly of Apple *hardware*, it's the OS that
makes me feel very claustrophobic, and it's the software that, well, the
software that is nowhere to be found except in scant quantities across the
globe! *grins* So hurry up and write a FreeBSD for the G4 architecture!)
> KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
> http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/
> GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46
> My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
> Please do not remove my address from To: and Cc: fields in mailing lists. 10x
Hope this has been as fun for y'all as it hath fer me.
--
Peter Leftwich
President & Founder
Video2Video Services
Box 13692, La Jolla, CA, 92039 USA
+1-413-403-9555
kar...@rohrbach.de
--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Peter Leftwich(Hostm...@Video2Video.Com)@2002.04.19 20:50:16 +0000:
> On Sat, 20 Apr 2002, Karsten W. Rohrbach wrote:
[...]
> > Brett Glass(br...@lariat.org)@2002.04.19 16:12:33 +0000:
> > > At 04:07 PM 4/19/2002, Doug Barton wrote:
> > > >I long ago forgot what it was like to be a new FreeBSD user,
>=20
> ques...@freebsd.org
>=20
> > > This is part of the problem here. We should care a lot about newcomer=
s' experience, and respect the fact that no matter how bright they are they=
cannot learn everything at once. Expecting a new user to master CVSup is u=
nreasonable.
>=20
> Hi Karsten. The FreeBSD (and most *nix OS folk) community *does* care to=
ns
you are quote-quoting brett here ;-)
i /do/ know that _especially_ the freebsd folks /do/ care.
> > brett, i'm sorry, but reading this thread made me think about the
> > days when i started using freebsd and set up my first server. after
> > being left alone at a root user prompt "# " i learned how to
> > configure the stuff in /etc, that docs are in /usr/share/doc, how to
> > install packages, and then how to cvsup (for building upt to date
> > versions out of the ports tree).
>=20
> I always log in as root - The thinking is... rm doesn't scare me one bit!=
:)
sensing some amount of irony here, yes a new user logs in as root,
because he got a "blank" system, with (hopefully) limited userland.
i doesn't matter how many times you tell him "no do not log in as root",
he will understand it when he executed his first more complex shell
command containing "rm" ;-)
> > in my personal opinion, i find the RPM or binary-only distribution
> > mechanism very dangerous for users, because it is mainly the
> > microsoft approach to hide software complexity behind an interface
> > the user has to trust. i personally do not trust binary package
> > systems (although i am forced to use them sometimes), nor do i
> > blindly trust the ports tree. yes, i mean i _read_ the make files
> > and view the output of the make process before installing a port the
> > first time on one box. then i make a package out of it. that's all
> > personal preference, yes.
>=20
> Don't know practically nuttin about RPM, but if you are concerned about
> security and customizable control of pkg_add, remember the following: You
> can *always* just ftp the package (a tarball, or somecommandhere_3.1.1.tg=
z)
> to your box, gunzip and untar the contents... edit them in your favorite
> editor and then "make" or "make clean" or "make install" manually (you can
> tell beyond a certain point in this sentence I know not about what I spea=
k)!
yes, i know. but after the "USA_RESIDENT=3Dno vs. kerberos lib linkage in
packages" issue, i rather roll my own, thanks.
> Hope this has been as fun for y'all as it hath fer me.
your mua does terrible things to line breaks. please check and fix ;-)
regards,
/k
--=20
> Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
> Geniuses remove it.
> --Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982=20
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 B=
F46
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x
--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE8wMETM0BPTilkv0YRAtvkAKCk6l55y3weLMSqUFxQOwTTg4uTWQCeMU+x
OyHl4AnoIxji0gJauiWuY3Q=
=Smi2
-----END PGP SIGNATURE-----
--UugvWAfsgieZRqgk--
bne...@paypal.com
Let's apply this logic to other places in our lives....
Licenses for people with an inability to learn to drive should be
easier. Perhaps the DMV should start distributing chauffeurs for those
unable to learn to drive? This, of course, will be a free service.
People who do not know how to run their own businesses should be given a
staff, salary, idea, and business process, all for free. (!)
If you don't know how to do dentistry (golsh, that's tougher then
CVSup!), there should be an easy, free, "do it at home for free(!)" kit.
You simply plug this free device into your mouth and whammo, no dental
woes.
'Expecting a new user to master CVSup is unreasonable.' -- sounds liek
you're volountering to engineer a solution. Go do it and stfu.
Until then, I am adding a to/from/body filter that if it includes your
name, it goes right to the trash. When I see the "Super n00b FreeBSD
Install by Brett Glass", this filter will be removed.