I personally wouldn't advise using a single bare-metal machine just for dhcp, a separate one for dns, a separate one for sendmail etc. Seems like a huge waste of resources to me. My opinion is that you would fare better, as was suggested earlier, to use some of the other bare-metal machines for more intensive tasks like Apache. And, I always like to have a spare box or two to experiment with different things on, so I would keep one just for that if it were me. Virtualizing is great for testing and experimenting, but sometimes you can't beat a real machine for that.
On Tue, Jan 14, 2014 at 12:50 AM, Christopher Ahrens <n...@leviacomm.net>wrote: > Matthew Weigel wrote: > >> On 1/13/2014 9:11 PM, Christopher Ahrens wrote: >> >>> Jack Woehr wrote: >>> >>>> Christopher Ahrens wrote: >>>> >>>>> >>>>> Wish I could split everything off to physical, but all I have for >>>>> space for is a mini-rack that fits under my desk in my apartment >>>>> >>>> >>>> Sounds like you have answered your own question! >>>> >>>> >>> What I meant by bare-metal was if I should run a bunch of services on >>> the same >>> installation of OpenBSD. >>> >> >> Well, hardware failures on a small pool of machines are still hardware >> failures on a small pool of machines, whether you have virtual servers or >> not. >> >> For security, chroot (especially with privilege separation) accomplishes >> a lot >> of what virtualization claims to offer, with a much longer history of >> auditing >> and better understood weaknesses. >> >> It is usually easier, in my experience, to manage one system running many >> services in individual chroot environments than to manage many (virtual) >> systems. Files in chroot environments will sometimes need to be updated >> when >> you change the main system, but in my experience this is a much easier >> task to >> identify and manage than applying those changes en masse to a collection >> of >> virtual hosts. Plus, there will be plenty of system updates to the main >> system that don't need to trickle down to the chroot environments, but >> will >> almost always need to be applied individually to each virtual host. >> >> You may still want to physically separate some concerns if you have enough >> machines (e.g., build machines vs. service machines, spreading out >> disk-intensive services, etc.), but in general I don't think >> virtualization >> will particularly help you. >> >> > > OK, I think I'll try loading multiple services onto single machines, I'm > thinking that I could always just attach a bunch of carp interfaces (one > for each service) to the machine then if I want to move that service to > another machine (Virtual or physical) I just destroy the carp interface and > recreate it on the new one. > > At this point my plan is to use a pair of machines for a specific category > (to allow for a machine failure or allow for update cycles with no > downtime), each pair would handle one of Public internet services > (external-facing DNS, Public Web server, SMTP filtering), internal services > (Internal DNS, LDAP, CA), or business applications (Wiki, Mail Store / IMAP > access, source code control). The last two boxes used as spare and to test > virtualization options. > > I am just not using a single machine for multiple roles (I cut my teeth on > Windows 2000/2003 and picked up some bad habits and obsolete advice)
