Re: a few questions and concepts

2006-04-10 Thread Giorgos Keramidas
On 2006-04-07 19:11, Jonathan Horne [EMAIL PROTECTED] wrote:
 On Friday 07 April 2006 16:34, Giorgos Keramidas wrote:
   so, the past couple of days, i have learned to cvsup my /usr/src
   directories.  ive just been using the standard copy of the
   stable-supfile. i have learned that if i perform the sendmail recompile
   after the cvsup, that it sendmail seems to proclaim 8.13.6 in the banner.
on top of that, i have learned that if i recompile the kernel after
   cvsup, that it no longer says FreeBSD 6.0-RELEASE, but FreeBSD
   6.1-PRERELEASE.
 
  You are running RELENG_6 now, which is much more recent than
  RELENG_6_0_RELEASE.

 [...]
 ill grasp the method of the madness eventually.  i guess what confuses me, is
 that i read about those, and then try to find them on the ftp sites.  i
 assume, that only release is made into a .iso file?  and to move to a higher
 version (either the security RELENG_6_0 or stable RELENG_6), you do this thru
 the cvsup tool.

 so, by your descriptions and reply to my previous comments, my system that is
 running what says 6.1-PRERELEASE is really RELENG_6 (stable) ?

100% correct.

This is exactly what stable-supfile fetches for you :)

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: a few questions and concepts

2006-04-10 Thread RW
On Saturday 08 April 2006 05:16, Kevin Kinsey wrote:

 Leading source code committers are typically always working on the
 Next Big Thing(tm), which is known as -HEAD in CVS, and often called
 (and officially, even, called) -CURRENT in FreeBSD.  Most users, though,
 are using the Last Big Thing(tm), known as -STABLE.

That sounds a bit unlikely, I would have thought most people would use a 
security branch like  RELENG_6_0. Nothing else is rcommended for production 
use.



 
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: a few questions and concepts

2006-04-08 Thread bsd
 On Friday 07 April 2006 16:34, Giorgos Keramidas wrote:
 On 2006-04-07 15:54, Jonathan Horne [EMAIL PROTECTED] wrote:
  im still pretty new to freebsd.  ive been playing around with the
 cvsup
  tools, and they are quite fascinating.
 
  i changed my production server from Fedora to FreeBSD 6.0, about 1 day
  before the most recent sendmail exploit was published (well, published
 on
  freebsd.org anyway).

 Murphy at work, again, eh? :)

  i did download the patch and recompile it, but as some have also noted
  on this list, that it still banners as 8.13.4 when you telnet to it.
 
  so, the past couple of days, i have learned to cvsup my /usr/src
  directories.  ive just been using the standard copy of the
  stable-supfile. i have learned that if i perform the sendmail
 recompile
  after the cvsup, that it sendmail seems to proclaim 8.13.6 in the
 banner.
   on top of that, i have learned that if i recompile the kernel after
  cvsup, that it no longer says FreeBSD 6.0-RELEASE, but FreeBSD
  6.1-PRERELEASE.

 You are running RELENG_6 now, which is much more recent than
 RELENG_6_0_RELEASE.

 The first one is the top of the 6.X branch, which changes moderately
 slow, but it *does* change.  The 6.0-RELEASE source tree is frozen in
 time at the point the tag was placed on the source tree.

  my questions:
  1) after cvsup, i think i can assume that sendmail is now compiling
 from
  sourcecode that should definatly be free from the current exploit.  i
  would also assume that anything that i would need to recompile from
  /usr/src should also see the benefit of 'latest source code'?

 Yes, both true.

  2) on a production server, should i avoid recompiling a kernel that
 will
  be FreeBSD 6.1-PRERELEASE?  on the whole, how reliable is the bulk of
  these newer sources that were pulled down by cvsup?

 In general, if you a bit paranoid, you should avoid running RELENG_6 on
 a production system.  At least until you have thoroughly tested it on a
 test system and found everything working as expected.

  i can definatly see the benefits of using cvsup to take care of
  problem with some things (like sendmail), but allowing it to update
  everything under the /usr/src tree, im wondering if i could be setting
  myself up for issues (by not editing the stable-supfile and taking
  only what i need).

 This is why each FreeBSD release is associated with at least:

 * A frozen tag, like RELENG_6_0_RELEASE

 * A security branch, like RELENG_6_0

 * A stable branch, like RELENG_6

 Changes go very fast in the CURRENT FreeBSD branch.  After they settle
 in for a while, soem of them are backported to the RELENG_X branch.  The
 RELENG_X branch changes much slower than the experimental, CURRENT
 branch, but it does change every time a new feature is backported to
 RELENG_X.

 Then, when security fixes are made available, they are added both to the
 RELENG_X branch and the RELENG_X_Y security branches.

 If all you want is the frozen release sources plus changes that are
 really really necessary, because they fix a serious security bug, you
 probably want RELENG_X_Y (RELENG_6_0 in this case).

 Regards,
 Giorgos

 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to
 [EMAIL PROTECTED]

 thank you kindly for your reply, that was quite informative.  ive actually
 read the document on the differences between the stable, current, and
 release
 (or whatever), and find that system quite confusing for the moment.   im
 sure
 ill grasp the method of the madness eventually.  i guess what confuses me,
 is
 that i read about those, and then try to find them on the ftp sites.  i
 assume, that only release is made into a .iso file?  and to move to a
 higher
 version (either the security RELENG_6_0 or stable RELENG_6), you do this
 thru
 the cvsup tool.

Yes, as far as I can tell that is correct, it confused me at first. The
iso image is the latest release for each branch.


 so, by your descriptions and reply to my previous comments, my system that
 is
 running what says 6.1-PRERELEASE is really RELENG_6 (stable) ?


Again correct. Don't forget 'stable' is not that stable it is a snapshot
of 'current' that is stable enough to be released.

 thanks,
 Jonathan Horne

The other confusing this is that the tags only realy refer to the
'userland' ie the core system. The ports get updated as and when.

On the system I am currently working on which will be a production server,
I don't whant too much change when in prodction so I am following the 6.0
branch at present (RELENG_6_0). I have portaudit installed which tells me
what ports have been updated through security issues and I can decide if I
need to update them. Apart from that I will probably leave it alone.

Hope this helps

Rob


___
freebsd-questions@freebsd.org mailing list

Re: a few questions and concepts

2006-04-08 Thread Kevin Kinsey

Robert Huff wrote:


Kevin Kinsey writes:

 


It's somewhat interesting (to me) that the even numbered releases
seem to have had longer and perhaps more successful runs than the
odd numbered ones.  5.X, in particular, seemed short to me.
   



Two comments:
1) Sample size = 2.
 



You may need to explain the math for that.  6 code trees, divided
by either the number of odds or evens, equals 3.  Still a small
sample size, to be sure, (but I doubt FreeBSD will ever have a large
enough number of released branches to ever approach anything
like the number of samples that would be required for statistical
proof of such a casual observation), and 6.x isn't yet done (for
that matter, neither is 5.X, but it's close), but I'm pretty sure that
5.x will be shorter lived than 4, and probably shorter than 6.x,
though I imagine they'll try to get 7.X out faster than 5.x was


2) 4 has run long because it took forever to get 5 out the
door.  While appreciative of the advances made, way too many useful
things got delayed waiting for 5.0.


Robert Huff
 



Agreed.  But I still see, casually speaking, an alternating length
of life, with 1.x and 3.x and 5.x lasting notably shorter amounts of time
than their even-numbered successors.  I think that core/releng
or someone has expressed a desire to not delay 7.x as long as
5.x was delayed, so there's a chance that this trend could be broken.

However, I take comfort in the fact that whatever branch it is,
it's not gonna be -RELEASEd until it's ready.  (And, of course,
we could bat that one around all day, too, but it's really starting
to feel like overkill --- all I made was a side comment about the
relative lengths of the numbered code branches).

It's a generalization, and a speculation, and merely an observation;
and, I think it's interesting to generalize and observe nonetheless,
but it's not measurable nor quantifiable, and not worthy of such
effort to sustain a discussion.

KDK

P.S.  The real hole I see in my conjecture is that, in reality,
the 5.X branch has been around a long time, being tagged
at the time that 4.0 was -RELEASED; however, it lived most
of its life as -CURRENT 

--
An idealist is one who helps the other fellow to make a profit.
-- Henry Ford

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: a few questions and concepts

2006-04-08 Thread Robert Huff

Kevin Kinsey writes:

   It's somewhat interesting (to me) that the even numbered releases
   seem to have had longer and perhaps more successful runs than the
   odd numbered ones.  5.X, in particular, seemed short to me.

  Two comments:
  1) Sample size = 2.
  
  You may need to explain the math for that.  6 code trees, divided
  by either the number of odds or evens, equals 3.

I'm discarding 1.x as affected by outside events (the lawsuit)
and 6.x, as both a) uncompleted and b) done under a different formal
release structure.
That leaves [2-5] - 4 units, or two pairs for comparison.


Robert Huff

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


a few questions and concepts

2006-04-07 Thread Jonathan Horne
im still pretty new to freebsd.  ive been playing around with the cvsup
tools, and they are quite fascinating.

i changed my production server from Fedora to FreeBSD 6.0, about 1 day
before the most recent sendmail exploit was published (well, published on
freebsd.org anyway).  i did download the patch and recompile it, but as
some have also noted on this list, that it still banners as 8.13.4 when
you telnet to it.

so, the past couple of days, i have learned to cvsup my /usr/src
directories.  ive just been using the standard copy of the stable-supfile.
 i have learned that if i perform the sendmail recompile after the cvsup,
that it sendmail seems to proclaim 8.13.6 in the banner.  on top of that,
i have learned that if i recompile the kernel after cvsup, that it no
longer says FreeBSD 6.0-RELEASE, but FreeBSD 6.1-PRERELEASE.

my questions:
1) after cvsup, i think i can assume that sendmail is now compiling from
sourcecode that should definatly be free from the current exploit.  i
would also assume that anything that i would need to recompile from
/usr/src should also see the benefit of 'latest source code'?
2) on a production server, should i avoid recompiling a kernel that will
be FreeBSD 6.1-PRERELEASE?  on the whole, how reliable is the bulk of
these newer sources that were pulled down by cvsup?

i can definatly see the benefits of using cvsup to take care of problem
with some things (like sendmail), but allowing it to update everything
under the /usr/src tree, im wondering if i could be setting myself up for
issues (by not editing the stable-supfile and taking only what i need).

last, im also as well interested in hearing how some of my peers here
apply the cvsup concepts to your production servers.

thanks for reading,
Jonathan Horne

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: a few questions and concepts

2006-04-07 Thread Giorgos Keramidas
On 2006-04-07 15:54, Jonathan Horne [EMAIL PROTECTED] wrote:
 im still pretty new to freebsd.  ive been playing around with the cvsup
 tools, and they are quite fascinating.

 i changed my production server from Fedora to FreeBSD 6.0, about 1 day
 before the most recent sendmail exploit was published (well, published on
 freebsd.org anyway).

Murphy at work, again, eh? :)

 i did download the patch and recompile it, but as some have also noted
 on this list, that it still banners as 8.13.4 when you telnet to it.

 so, the past couple of days, i have learned to cvsup my /usr/src
 directories.  ive just been using the standard copy of the stable-supfile.
 i have learned that if i perform the sendmail recompile after the cvsup,
 that it sendmail seems to proclaim 8.13.6 in the banner.  on top of that,
 i have learned that if i recompile the kernel after cvsup, that it no
 longer says FreeBSD 6.0-RELEASE, but FreeBSD 6.1-PRERELEASE.

You are running RELENG_6 now, which is much more recent than
RELENG_6_0_RELEASE.

The first one is the top of the 6.X branch, which changes moderately
slow, but it *does* change.  The 6.0-RELEASE source tree is frozen in
time at the point the tag was placed on the source tree.

 my questions:
 1) after cvsup, i think i can assume that sendmail is now compiling from
 sourcecode that should definatly be free from the current exploit.  i
 would also assume that anything that i would need to recompile from
 /usr/src should also see the benefit of 'latest source code'?

Yes, both true.

 2) on a production server, should i avoid recompiling a kernel that will
 be FreeBSD 6.1-PRERELEASE?  on the whole, how reliable is the bulk of
 these newer sources that were pulled down by cvsup?

In general, if you a bit paranoid, you should avoid running RELENG_6 on
a production system.  At least until you have thoroughly tested it on a
test system and found everything working as expected.

 i can definatly see the benefits of using cvsup to take care of
 problem with some things (like sendmail), but allowing it to update
 everything under the /usr/src tree, im wondering if i could be setting
 myself up for issues (by not editing the stable-supfile and taking
 only what i need).

This is why each FreeBSD release is associated with at least:

* A frozen tag, like RELENG_6_0_RELEASE

* A security branch, like RELENG_6_0

* A stable branch, like RELENG_6

Changes go very fast in the CURRENT FreeBSD branch.  After they settle
in for a while, soem of them are backported to the RELENG_X branch.  The
RELENG_X branch changes much slower than the experimental, CURRENT
branch, but it does change every time a new feature is backported to
RELENG_X.

Then, when security fixes are made available, they are added both to the
RELENG_X branch and the RELENG_X_Y security branches.

If all you want is the frozen release sources plus changes that are
really really necessary, because they fix a serious security bug, you
probably want RELENG_X_Y (RELENG_6_0 in this case).

Regards,
Giorgos

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: a few questions and concepts

2006-04-07 Thread Jonathan Horne
On Friday 07 April 2006 16:34, Giorgos Keramidas wrote:
 On 2006-04-07 15:54, Jonathan Horne [EMAIL PROTECTED] wrote:
  im still pretty new to freebsd.  ive been playing around with the cvsup
  tools, and they are quite fascinating.
 
  i changed my production server from Fedora to FreeBSD 6.0, about 1 day
  before the most recent sendmail exploit was published (well, published on
  freebsd.org anyway).

 Murphy at work, again, eh? :)

  i did download the patch and recompile it, but as some have also noted
  on this list, that it still banners as 8.13.4 when you telnet to it.
 
  so, the past couple of days, i have learned to cvsup my /usr/src
  directories.  ive just been using the standard copy of the
  stable-supfile. i have learned that if i perform the sendmail recompile
  after the cvsup, that it sendmail seems to proclaim 8.13.6 in the banner.
   on top of that, i have learned that if i recompile the kernel after
  cvsup, that it no longer says FreeBSD 6.0-RELEASE, but FreeBSD
  6.1-PRERELEASE.

 You are running RELENG_6 now, which is much more recent than
 RELENG_6_0_RELEASE.

 The first one is the top of the 6.X branch, which changes moderately
 slow, but it *does* change.  The 6.0-RELEASE source tree is frozen in
 time at the point the tag was placed on the source tree.

  my questions:
  1) after cvsup, i think i can assume that sendmail is now compiling from
  sourcecode that should definatly be free from the current exploit.  i
  would also assume that anything that i would need to recompile from
  /usr/src should also see the benefit of 'latest source code'?

 Yes, both true.

  2) on a production server, should i avoid recompiling a kernel that will
  be FreeBSD 6.1-PRERELEASE?  on the whole, how reliable is the bulk of
  these newer sources that were pulled down by cvsup?

 In general, if you a bit paranoid, you should avoid running RELENG_6 on
 a production system.  At least until you have thoroughly tested it on a
 test system and found everything working as expected.

  i can definatly see the benefits of using cvsup to take care of
  problem with some things (like sendmail), but allowing it to update
  everything under the /usr/src tree, im wondering if i could be setting
  myself up for issues (by not editing the stable-supfile and taking
  only what i need).

 This is why each FreeBSD release is associated with at least:

 * A frozen tag, like RELENG_6_0_RELEASE

 * A security branch, like RELENG_6_0

 * A stable branch, like RELENG_6

 Changes go very fast in the CURRENT FreeBSD branch.  After they settle
 in for a while, soem of them are backported to the RELENG_X branch.  The
 RELENG_X branch changes much slower than the experimental, CURRENT
 branch, but it does change every time a new feature is backported to
 RELENG_X.

 Then, when security fixes are made available, they are added both to the
 RELENG_X branch and the RELENG_X_Y security branches.

 If all you want is the frozen release sources plus changes that are
 really really necessary, because they fix a serious security bug, you
 probably want RELENG_X_Y (RELENG_6_0 in this case).

 Regards,
 Giorgos

 ___
 freebsd-questions@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to
 [EMAIL PROTECTED]

thank you kindly for your reply, that was quite informative.  ive actually 
read the document on the differences between the stable, current, and release 
(or whatever), and find that system quite confusing for the moment.   im sure 
ill grasp the method of the madness eventually.  i guess what confuses me, is 
that i read about those, and then try to find them on the ftp sites.  i 
assume, that only release is made into a .iso file?  and to move to a higher 
version (either the security RELENG_6_0 or stable RELENG_6), you do this thru 
the cvsup tool.

so, by your descriptions and reply to my previous comments, my system that is 
running what says 6.1-PRERELEASE is really RELENG_6 (stable) ?

thanks,
Jonathan Horne
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: a few questions and concepts

2006-04-07 Thread Kevin Kinsey

Jonathan Horne wrote:


On Friday 07 April 2006 16:34, Giorgos Keramidas wrote:
 


i can definatly see the benefits of using cvsup to take care of
problem with some things (like sendmail), but allowing it to update
everything under the /usr/src tree, im wondering if i could be setting
myself up for issues (by not editing the stable-supfile and taking
only what i need).
 


This is why each FreeBSD release is associated with at least:

   * A frozen tag, like RELENG_6_0_RELEASE

   * A security branch, like RELENG_6_0

   * A stable branch, like RELENG_6

Changes go very fast in the CURRENT FreeBSD branch.  After they settle
in for a while, soem of them are backported to the RELENG_X branch.  The
RELENG_X branch changes much slower than the experimental, CURRENT
branch, but it does change every time a new feature is backported to
RELENG_X.

Then, when security fixes are made available, they are added both to the
RELENG_X branch and the RELENG_X_Y security branches.

If all you want is the frozen release sources plus changes that are
really really necessary, because they fix a serious security bug, you
probably want RELENG_X_Y (RELENG_6_0 in this case).

Regards,
Giorgos
   

thank you kindly for your reply, that was quite informative.  ive actually 
read the document on the differences between the stable, current, and release 
(or whatever), and find that system quite confusing for the moment.   im sure 
ill grasp the method of the madness eventually.  i guess what confuses me, is 
that i read about those, and then try to find them on the ftp sites.  i 
assume, that only release is made into a .iso file?  and to move to a higher 
version (either the security RELENG_6_0 or stable RELENG_6), you do this thru 
the cvsup tool.


so, by your descriptions and reply to my previous comments, my system that is 
running what says 6.1-PRERELEASE is really RELENG_6 (stable) ?


thanks,
Jonathan Horne
 



Yes, and furthermore it's a RELENG_6 dated at the exact time of your
last cvsup/build cycle.  The CVS system allows you to check out source
code from any time in the history of the Project's development (and it
would do this for any project that had started out using CVS and continued
to do so consistently, like FreeBSD has).

Leading source code committers are typically always working on the
Next Big Thing(tm), which is known as -HEAD in CVS, and often called
(and officially, even, called) -CURRENT in FreeBSD.  Most users, though,
are using the Last Big Thing(tm), known as -STABLE.

In -CURRENT, I assume, the committers are doing wacko stuff to try
and make FreeBSD into a new version of the Six Million Dollar Man,
so once in a while, -CURRENT won't compile, because someone was
typing whilst they should be sleeping, and made a mistake, or, something
else happens.  In -STABLE, they don't try much new stuff, just fixing
bugs, or, as Giorgos pointed out, taking things that have proven themselves
in CURRENT, things that users are clamoring for (sometimes) and back 
porting

them to the older branch.

1.X 
  2.X --
   3.X -
 4.X ---
5.X 
---
 
   6.X -
   
  7.X -


So, back in 1993, users were using 1.0, and the developers were
working furiously to prepare the next version, which came to
be 2.0.  During this time, 1.1, 1.1.5, and 1.1.5.1 were released
for general use, and, spurred on by daemons the likes of which
New Jersey has ever known, the developers readied 2.0.

Once 2.0 was released, these crazy developers moved immediately
to the ng, and 2.x became the STABLE branch, the maintenance
branch, the code that users were using to build the WWW, as 'twere;
somebody can remind me, I guess --- the world record FTP server
was a 2.X machine, right?  (Gee, am I too lazy to Google, now?)

So, at that time, 3.X became -CURRENT, and 2.X became -STABLE,
and 1.X began to go the way of the dinosaur.

This cycle repeats itself each time a really new or major release
occurs; ATM there are, actually, two elder STABLES hanging about,
besides 6-STABLE (5-STABLE and 4-STABLE are still supported,
to some extent).  At the present time the HEAD or CURRENT stream
is the 7 series; it's possible that some dreamer is envisioning
what 8 might look like, but I kinda doubt it, since there's
plenty of work to do on 7-CURRENT, and keeping 6-STABLE going,
and patching any security issues in 5.X, 4.X, etc

Incidentally, but perhaps of value: regarding the RELEASE tag,
these are simply cuts from the -STABLE line that are polished
up (by going into a code freeze during which only critical bug
fixes are committed to -STABLE) and then running the release(7)
tools to create the 

Re: a few questions and concepts

2006-04-07 Thread Robert Huff

Kevin Kinsey writes:

  It's somewhat interesting (to me) that the even numbered releases
  seem to have had longer and perhaps more successful runs than the
  odd numbered ones.  5.X, in particular, seemed short to me.

Two comments:
1) Sample size = 2.
2) 4 has run long because it took forever to get 5 out the
door.  While appreciative of the advances made, way too many useful
things got delayed waiting for 5.0.


Robert Huff

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]