patch management for software compiled from source

I'm doing research into building a lamp server in ubuntu or debian for an intranet. Pretty much everything I have seen recommends building from source, chrooting all the components and such for security and the most up to date versions of everything. For the specific packages (apache,mysql,php) would I be better off to just stick with the debian/ubuntu packages instead? The client is pretty hardcore into microsoft products and this is the first attempt at using linux in a big way at this company so I want to be able to present something very solid to the management.

From serverfault controlfreak123

• I'd say just install the default packages from your distribution. If you want to chroot your apache installation, you can install the mod_chroot package. In Debian/Ubuntu, that would be libapache2-mod-chroot.

  As far as being up-to-date, just make sure to be using a supported version of the OS (e.g. Debian Lenny or Ubuntu Hardy LTS), to have the security repositories activated in your sources.list and to update your packages on a regular basis.

  If your client is a Microsoft fanboy, he's surely not used to building things from source and it shouldn't shock him to use already packaged products. If you build from source, just know that you will have to follow security advisories yourself, and patch and rebuild the software every time it happens, instead of just upgrading the packages.

  I know there's a lot of 'security' freaks around who say you should build everything from source, put everything in chroots and lock your computer in a bank safe. The main problem I see with this is that it won't necessarily increase your security, but it will certainly make it very hard to administrate (just explained why in the previous paragraph) and in the end it will end up less secure than using standard packages and keeping them up-to-date with a sound configuration.

  controlfreak123 : I'd be curious to hear why you don't think chrooting would make it more secure but good points in the second paragraph. The main obstacle to getting linux products into the system isn't so much that the management dislikes non-windows as much as the current sys-admin thinks that they are unsafe because he himself doesn't understand linux. If this is accepted by the company I would be the one in charge of administration anyways but I liked your response best so thats why I chose your answer over the other one! Thanks for the info.

  freiheit : If you can execute arbitrary code as root, you can escape from a chroot. Chroot can be used to help build security tools, but was never designed with that purpose and breaks when you try. Besides, most attackers are primarily interested in making outgoing network connections, which they can do from inside a chroot with or without root.

  Raphink : Automating package updates in a chroot is a harder thing than when you're not using one, although it is very doable. In a lot of situations I've seen, programs installed in chroot where hardly ever updated, thus resulting in a far worse security situation than if a non-chrooted program was used and kept up-to-date.

  Raphink : Chroots are good, but they often give a false sense of security, unless you really know what you're doing and why.
  From Raphink

• It's almost always better to use the packages from the distribution.

  1. They're easy to update with standard tools (apt, etc). Even possible to do automatically.
  2. The packages have been tested; less likely to break in some weird way.
  3. All the dependencies are handled automatically for you
  4. It's much easier to document so somebody else can take over when you move on. "Standard Ubuntu apache packages" vs. page after page of exactly which options you picked when compiling things, where everything is installed, etc...
  5. Something client can understand how to manage the basics of. "To update, run these two commands on a regular basis", vs. "to update the OS run these commands on a regular basis; to find out about updates to httpd sign up for this mailing list; to update httpd download the latest file from this site and run these commands".
  From freiheit