Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Dec 2007 16:54:16 +0000
From:      David Wood <david@wood2.org.uk>
To:        Eugene Grosbein <eugen@grosbein.pp.ru>
Cc:        stable@freebsd.org
Subject:   Re: SOLVED: qemu: freebsd6_mmap -1 errno 12 Cannot allocate memory
Message-ID:  <bMaNtGF4wsWHFAlD@wood2.org.uk>
In-Reply-To: <20071208154341.GA90973@svzserv.kemerovo.su>
References:  <20071207154852.GA22166@grosbein.pp.ru> <20860185@bb.ipt.ru> <Pine.GSO.4.64.0712071140240.11654@sea.ntplx.net> <20071208042252.GA30019@svzserv.kemerovo.su> <20071208054552.GP83121@deviant.kiev.zoral.com.ua> <20071208055537.GA38551@svzserv.kemerovo.su> <20071208060206.GQ83121@deviant.kiev.zoral.com.ua> <20071208060947.GB38551@svzserv.kemerovo.su> <20071208064703.GA40347@svzserv.kemerovo.su> <Pine.GSO.4.64.0712080935570.16331@sea.ntplx.net> <20071208154341.GA90973@svzserv.kemerovo.su>

next in thread | previous in thread | raw e-mail | index | archive | help
[cc line trimmed]

In message <20071208154341.GA90973@svzserv.kemerovo.su>, Eugene Grosbein 
<eugen@grosbein.pp.ru> writes
>I know. I will never 'rebuild all ports', I don't think that's Right Thing.
>
>I've upgraded once from 4.11-STABLE to 6.0-RELEASE (binary upgrade
>over existing system) and all ports worked nice, including X, brousers etc.
>The only problem was a change of locale on-disk format that had simple 
>workaround.
>
>I still have a.out binaries built under 2.2.8 running
>under production 4.11-STABLE, they run just fine.
>Modern operating system just have to offer binary backwards
>compatibility for user-level, IMHO.
>
>I have backups and when 'the same thing' happen again for a library
>I forgot to move to lib/compat, I'll restore it there and continue
>to use it.

It's your choice, but from a security perspective, this worries me.


You will have applications you are using linked against FreeBSD 
libraries that no longer have any FreeBSD security team support.

misc/compat3x is marked as Forbidden / Ignore in the ports tree due to 
an unfixed security bug that isn't going to be fixed (the effort isn't 
felt to be worth it). I would expect misc/compat4x to land up that way 
sooner or later as there's no longer any security team support for 4.x.

 From a security point of view, this suggests that all 3.x and earlier 
binaries should be rebuilt. I would be wanting to rebuild any binaries I 
could that weren't built on relatively modern 5.x and upwards. By 
relatively modern, I mean no more than one point release away from the 
current one, and ideally no release that doesn't have current security 
team support.


Security issues with ports are fixed by upgrading them - to a higher 
PORTREVISION if not a later version. Some of the ports that have got 
security related updates are fairly key libraries such as OpenSSL (I 
tend to use ports OpenSSL on my machines as it's more up to date than 
base system OpenSSL).

Indeed, whether you're using base OpenSSL or ports OpenSSL, how are you 
going to rebuild libraries for binaries built on old releases? You could 
fire up an old release to do so, maybe taking advantage of 
virtualisation to do so, but that rapidly becomes a lot of work. As soon 
as you need to upgrade one dependency based on an older release, you 
have a potentially complex problem on your hands, especially as the 
ports tree no longer supports 4.x or earlier.



Even running as you are now gives you some overhead. One slip and you're 
reaching for a backup to restore libraries to fix whatever is broken.


portupgrade -af can be somewhat painful on systems with plenty of ports 
installed. However, if you are not tracking -CURRENT and you don't 
upgrade to a new major release at anything earlier than -RC stage (7.0 
had an ABI change between -BETA3 and -BETA4), that should be needed just 
once per major version.

By not rebuilding ports and other applications after a major version 
upgrade, you throw away any advantages of building with new libraries 
and toolchain components on the new releases if you continue to use old 
binaries.

If you build ports with default options and knobs, you can use the 
packages that are available, at least as a starting point. I use a fair 
amount of customisation, so I compile the lot on my boxes. I keep the 
number of installed ports down fairly aggressively, which helps.



Before too long:

7.x will be the mainstream release

6.x the legacy release for those who need more time before jumping to 
7.x

and 8-CURRENT the bleeding edge.


5.5 is the last planned release from the 5.x line; it has an estimated 
End of Life (from a security team point of view) of 31 May 2008. That 
may slip by a bit depending on when 7.0-RELEASE ships, but I suspect the 
entire 5.x branch will go EoL in mid 2008 and the ports tree will drop 
5.x support shortly afterwards.


My main use for FreeBSD is as a server OS. My policy for the OS is to 
track the current -RELEASE in my chosen major version fairly closely and 
track the security fixes immediately. I'm currently on 6.2-RELEASE-p9 - 
I'll evaluate 7.0-RELEASE after it is released, and intend to jump to 
that rather than 6.3-RELEASE, even though the more conservative option 
is 6.3-RELEASE.

I track the ports tree fairly closely, not least because I'm a ports 
maintainer.


I am currently tracking RELENG_6_3 and RELENG_7 (I'll switch to 
RELENG_7_0 when that's created) on non critical and virtual machines for 
ports testing purposes. I won't use those machines in production as a 
matter of policy - even though I'm considering new Dell Poweredge 2950 
III hardware. My reading of the CVS logs suggests that the Mark III 2950 
would require 6.3, 7.0 or backporting driver changes to 6.2 because 
mfi(4) in 6.2 doesn't support the new PERC6/iR RAID controller on the 
version III boards.

More than likely, I'll defer the hardware purchase until 7.0-RELEASE is 
available. I know the mfi changes I'll need are in RELENG_7, and I'd 
hope there's no problem with Harpertown processors (the new Penryn based 
E54xx Xeons).


You may well have different priorities to mine in terms of what you 
upgrade to and when - but I believe that you should consider the 
security implications of your actions.



Best wishes,




David
-- 
David Wood
david@wood2.org.uk



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bMaNtGF4wsWHFAlD>