Avoiding source code on production servers

[martes]

Greetings All.

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

Have you not seen it worth the time to apply a patch in a custom package, or
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 milage
anyone may have gotten from using a test system for kernel builds ,etc as has
been suggested, and is most likely the case for many, including me, however
to use the builds to generate your own customized pkgs to install on incident
systems to facilitate patches, etc....

 

How does that solution sound?  I have not had a chance to test this however,
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? 
>Sat May 23 2009 10:36:18 EDT from Neil Neely to "Tonix (Antonio Nati)"  
>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, and
>>> 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
>http://neil-neely.blogspot.com/
>
>_______________________________________________
>freebsd-isp at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-isp
>To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>
>