Greetings, Apologies if this is not the appropriate list, but my questions are about best practices in maintaining production servers (so I believe I can justify a post in -stable, short of a -release list :) I maintain a modest installation of 6 FreeBSD servers. They're CVSUP'd to RELENG_4_8 (I make buildworld on each individually) and I portupgrade ports as necessary. In an attempt to mature and harden this installation, I'm wondering what is the best approach for keeping production servers patched and with the latest ports. I know that compiling everything on each box is poor security practice and a unnecessary drain on resources. But I'm confused as to how to go about compiling world and the ports on a separate machine and how to then distribute to the production servers. Should I compile ports as packages? Which directories are appropriate for NFS export? Each machine is i386, so there should be any architecture issues, but each has its own hardware configuration, so how would I building a custom kernel work? My selfish goal is to reduce maintenance time and effort by centralizing patches and updates, and my overall goal is to enhance security and reliability on the production servers by removing compiling tools. Thanks in advance for any advice on this matter. Cheers, Paul -- Paul Smith <paul@cnt.org> Webmaster/Systems Administrator Center for Neighborhood Technology Chicago, Illinois USA
Paul Smith wrote:> Apologies if this is not the appropriate list, but my questions are about > best practices in maintaining production servers (so I believe I can justify > a post in -stable, short of a -release list :)You ask good questions, regardless of where they were directed to. [ -questions or maybe -isp might have been a better choice. ]> I maintain a modest installation of 6 FreeBSD servers. They're CVSUP'd to > RELENG_4_8 (I make buildworld on each individually) and I portupgrade ports > as necessary. In an attempt to mature and harden this installation, I'm > wondering what is the best approach for keeping production servers patched > and with the latest ports. I know that compiling everything on each box is > poor security practice and a unnecessary drain on resources. But I'm confused > as to how to go about compiling world and the ports on a separate machine and > how to then distribute to the production servers. Should I compile ports as > packages? Which directories are appropriate for NFS export? Each machine is > i386, so there should be any architecture issues, but each has its own > hardware configuration, so how would I building a custom kernel work?If you do a "make package" for each port that you install, you can copy of using network filesharing (NFS, Samba, etc) to distribute the /usr/ports/packages directory. Create that directory if it doesn't exist, and "make package" will save the .tgz there rather than under each individual port directory. Beyond that, you should consider sharing /usr/src and /usr/obj from your buildserver onto the other machines for performing upgrades. You can copy all of your kernel config files to the build server, and do: make buildkernel KERNCONF=machine1 make buildkernel KERNCONF=machine2 ...etc, for each distinct kernel config file you have. You then "make installkernel" with the right KERNCONF as appropriate for the machine you're upgrading. While you're there, you can compare and possibly merge several individual config files into one that appropriate for most or all of your hardware. -- -Chuck
Here's what we do:
For the system:
- A separate build box, spec'd no higher than the lowest production machine
- keep a CVS repository on the build box
- buildbox /etc/make.conf has KERNCONF="SERVER CLIENT1 CLIENT2..."
- run make update / make buildworld / make buildkernel on the build box
- Install kernel & world on the build box, run mergemaster, etc as
documented
- run the build box for a couple of days (rebuilding ports etc) to check it
out
- NFS mount /usr/src and /usr/obj readonly on each client
- client /etc/make.conf has KERNCONF=CLIENTn
- installkernel / installworld / mergemaster on the client in the normal way
For the ports:
- use portupgrade on build box and clients
- build box has the union of all the client package sets installed on it
- build box does "portupgrade -p" to build packages
- client boxes NFS mount /usr/ports/ (including /usr/ports/packages)
(can also do it with a local CVSup'd /usr/ports and using FTP to
the build box to get the packages, but that's harder to get right.)
- clients run portupgrade -PP to use the packages only
This works well enough for us with a similar number of servers.
paul@cnt.org said:> Say a system like this were put into place to support existing > production servers. What's the cleanest/most elegant/least > destablizing way to remove the compiler tools on those machines?It's not supported out of the box as far as I can see. One approach is like this: - Add new variable NO_COMPILERS to /etc/make.conf on all the client machines - Go through the Makefiles and add code to drop the compiler tools if this variable is defined. Look for example at how NO_CVS is implemented in src/gnu/ usr.bin/Makefile and work from that. - You'll have to manually rm the tools from the existing client machines as this change won't delete old ones, it'll just not install new ones. - You might like to also define NOINSTALLLIB and NOPROFILE on the client make.conf to not install all the .a and _p.a libraries (see /usr/share/mk/ bsd.lib.mk). Even easier might be to maintain a list of files you don't want on the client machines and then rm them after every installworld (you could automate this in the /usr/src/Makefile).
Chuck Swiger <cswiger@mac.com> writes:> Paul Smith wrote: > [ ... ] > > Is there a way to take advantage of the portupgrade suite when it comes to > > building packages? I.e., is there a "make package" equivalent in portupgrade? > > I would imagine portupgrade would make packages of any dependicies as well, > > no? > > Exactly; use the "-p" option to portupgrade: > > -p > --package Build a package when each specified port is > installed or upgraded. If a package is upgraded > and its dependent packages are given from the com- > mand line (including the case where -r is speci- > fied), build packages for them as well....and on the installing side, use -PP. -- Dan Pelleg