Date: Sat, 23 May 2009 17:30:11 -0400 From: "martes" <martes@mgwigglesworth.com> To: Neil Neely <neil@neely.cx> Cc: freebsd-isp@freebsd.org, "Tonix \(Antonio Nati\)" <tonix@interazioni.it> Subject: Re: Avoiding source code on production servers Message-ID: <0000071356@mail.mgwigglesworth.com> References: <4A166B29.1070202@interazioni.it> <4A1809E2.8020608@neely.cx>
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,= 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 milag= e 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, howev= er to use the builds to generate your own customized pkgs to install on inci= dent systems to facilitate patches, etc.... =20 How does that solution sound? I have not had a chance to test this howev= er, 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. =20 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= d >>> 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@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-isp >To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0000071356>