Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 May 2009 17:30:11 -0400
From:      "martes" <>
To:        Neil Neely <>
Cc:, "Tonix \(Antonio Nati\)" <>
Subject:   Re: Avoiding source code on production servers
Message-ID:  <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Greetings All.

I have just begun to have time to fully investigate this type of topic. =20=

Have you not seen it worth the time to apply a patch in a custom package,=
creation of such packages in general to resolve these type of issues?

I may be off the target however, I just wanted to know what type of milag=
anyone may have gotten from using a test system for kernel builds ,etc as=
been suggested, and is most likely the case for many, including me, howev=
to use the builds to generate your own customized pkgs to install on inci=
systems to facilitate patches, etc....


How does that solution sound?  I have not had a chance to test this howev=
I thought I saw such a solution on a very old archive when researching
automation of kernel builds/installs, and automating system installation
using packages.


Any thouhgts?=20
>Sat May 23 2009 10:36:18 EDT from Neil Neely to "Tonix (Antonio Nati)" =20=

>Subject: Re: Avoiding source code on production servers
>Tonix (Antonio Nati) wrote:
>>> I'm in the phase of planning my new generation of FreeBSD servers, an=
>>> I would love to make them more easy to upgrade.
>>> Main problem I have currently is I do not want any source code on
>>> production server, so freebsd-update is welcome, but... what about
>>> packages?
>>> I would use packages, but they are not easy to upgrade, while ports
>>> can be easy to upgrade, but need to have sources an servers.

>The weakness of FreeBSD here is very unfortunate and IMO goes far beyond=

>just source vs binary distribution.  Working in a mixed environment
>where we have begun heavily using CentOS and utilizing yum it's obvious
>how far behind FreeBSD has fallen in this space.  Ports lack any kind of=

>concept of  "Long Term Stable", so if you are running anything in ports
>(like say perl...) then when a security issue comes out you end up
>having to install new versions - the default is not to patch the older
>versions.  For non-production environments that is likely fine, but for
>major production services it is a painful scenario.  So you aren't just
>fixing security you are mixing in the concept of adjusting functionality=

>as well.
>(A recent perl "security" upgrade moved perl to a new version which
>broke compatibility with the Crypt::CBC module requiring a reinstall -
>the new version of that from ports forced salting when it hadn't
>previously and now applications were needing to be recoded to get it all=

>working again.)
>At the end of the day FreeBSD of course lets you have all the power to
>just apply the patches yourself to the source and you would be fine.  At=

>the cost that you need to be doing all of this work yourself and can't
>rely on nice management tools to help you.  Every problem I've ever
>encountered with FreeBSD can be easily handled by a FreeBSD expert - but=

>when I bring in a new green admin they have a heck of a time making any
>sense of it and I'm drug back into the trenches of managing all this.
>Why the contrast is extra frustrating is that it takes considerable
>skill and understanding of the details of an environment to safely
>update a production FreeBSD server.  Contrast this with CentOS where an
>extremely green admin can easily manage it with minimal instruction.
>Unlike with the FreeBSD process this has no risk that it will cause
>cascading complex issues that require application modification to
>restore them to operation.
>I've been using FreeBSD since the 2.x days in '96 or so, and I love it -=

>my tone is critical because I'm sad to see the state of things and
>doubly sad that I don't have the time to volunteer with the project to
>help do something about it.  In most ways I consider FreeBSD superior to=

>any linux, however this core issue of maintenance over time has been
>driving our shift to using CentOS over the last few years.  If a "Long
>Term Stable Port Tree" concept were to come along I think that would
>plug the hole here.  While I lack the time to lead such a charge, I
>would be happy to assist if such an effort were to get launched.
>Neil Neely
> mailing list
>To unsubscribe, send any mail to ""

Want to link to this message? Use this URL: <>