These scripts make my Debian LXC-based homelab that powers my home network. Over the past few years the goal has been

• Have a nice, customizable, powerful network
• Be 100% automated and reproducible on any machine
• Services instead of "super-installs", single systems that have so many critical programs and moving parts built up over years your afraid to upgrade or change.
• Simple to use

Breakdown of each script

• 0_init_host.sh - Configures the network bridge that all containers will attach to
• 1_make_package_mirror.sh - Sets up a simple nginx cache proxy container as the same packages are downloaded over and over during testing or updates, caching is faster and easier on upstream servers.
• make_nas.sh - Sets up a samba and nfs container for other machines on the network.
• make_netman.sh - Sets up a dnsmasq container. DNS and DHCP are critical services which should be quick to restore. This container can be quickly spun up on another machines for system upgrades or when things break.

= History =

Hardware wise this has evolved from

• ~7 physical ancient desktops - Nice when someone else is paying the power bill and when bitcoin/litecoin mining was viable, but neither happens now.
• 4 moderately powerful desktops, 2 which are Xen-based - Xen is nice but since each box only had 4 GB of RAM I was very limited. Also virtualizing many Linux kernel instances (a majority of the VMs) is wasteful and overkill.
• 1 Proxmox desktop, 2 Xen desktops - Proxmox is a nice introduction to Linux containers. However its OpenVZ-based which slowly being obsoleted and can sometimes get in the way since it's so automated. I'd still recommend Proxmox to someone who wanted containers but didn't want to hand-configure everything. The Xen desktop was still powered on to run a OpenVPN ES instance and other Windows VMs.
• 1 LXC-based desktop, 1 (usually off) Xen desktop - Since I almost entirely run Linux, LXC made sense. It's very lightweight, simple to configure, officially kernel supported, and low level enough that you understand what all the moving parts do. The Xen box still holds my Windows MDT server, but is usually turned off now.

Configuration wise this has evolved from

• Manually editing (then forgetting) config files on live machines - The easiest and where everybody starts, but then the machine dies or your upgrade or you get a new box and then your scratching your head wondering what you changed at 1 AM 9 months ago. It's also live, breaking dnsmasq means your roommate's XBox just dropped off the network.
• Puppet - Powerful and gets the job done. "Eventually consistant" config model was very annoying when doing changes. Custom language took some time to learn. Anything more than basic plugins requires knowing ruby, and I don't know ruby. Always running dameon was memory hungry on my memory-constrained machines. Probably very useful when you have hundreds of machines across several datacenters, but overkill for a homelab
• Puppet + PXE-booted Ubuntu automated installs - Used because Xen requires full installs. It gets the job done but PXE is annoying to work with. Automated Ubuntu installs however are neat (see [ubuntu d?? config file])
• Ansible - Easy yaml config, no always running dameon, logical model. My favorite config managment system out of all the ones I looked at.
• Bash scripts + lightweight containers - Ultimately all configuration managment boils down to "install X, put these files here". Doing this in puppet-lang or yaml is annoying when you know its a simple apt-get or cp in the end. Several times I had to have the config system call a bash script to do something non-standard. If you move to enirely hand-written bash scripts combined with lightweight LXC containers, honestly you have the best understandable, single-language, customizable, and segregated setup possible. And long term, config managment programs may come and go, but bash is going to be around forever. In some situations it makes more sense than a enterprise-size system .