bigrig-scripts
A series of BASH scripts for setting up a bare-metal device as a \"large scale hypervisor\" with Proxmox
The task is to use Proxmox on a UM790 Pro with 96GiB of Ram, 1.82 TiB SSD, and a USB bay of five 3.64 TiB SATA drives. The end result will have scripts to manage the finalized installation of the OS (Proxmox is Debian based) and the hardware suitable to providing services with the simulated failure of one SATA drive to be reconstructed after notification, then register the reconstruction is complete.
Install PVE (the Proxmox Virtual Environment)
Install DNS (the DNS Server Appliance)
With reference to this howto, invoke the following:
pveum user add <user>@pam
pveum user list
pveum acl modify / --roles PVEAdmin --users <user>@pam
Lock down the server with the firewall[^3]. This is through the PVE Web, Datacenter:firewall/options, select "Firewall" on the right-side panel and the "edit" button above that. Select the "Firewall" checkbox on the pop-up and "ok."
Prepare for on-going maintenance
sudo apt update -y && sudo apt upgrade -y
command, of course.sudo apt install git -y
mkdir -p ~/projects && cd ~/projects && git clone git@github.com:Romaq/bigrig-scripts.git
cd ~/projects/bigrig-scripts/bigrig-scripts
Set domain name using https://www.dynu.com (optional if fixed IP)
sudo ./DynuSetup.sh
sudo journalctl -u ddclient
Set up email notifications per the howto.
Prepare the zfs storage tank.
Datacenter/<host>:Disks/ZFS
and click the "Create: ZFS" button./tank
at the root.Download .iso files to the storage tank.
[^1]: Proxmox Virtual Environment, usually but not necessarily the web page GUI control panel, but may also be a "PVE" command line. [^2]: A "sudo user" on both the shell and on PVE avoid exposing root privilages without a means to limit root privilage as conditions change. This also limits the need for exposing root in further stages of installation and development, such as with "git" identity on the server. [^3]: The PVE Firewall has a hard-coded exceptions: "WebGUI(8006) and ssh(22) from your local network." [^4]: While a GPG key isn't necessary, strictly speaking, it is a good practice and assumed as part of these instructions for the consistency of PVE rebuild events. If you have a GPG key within Github, it will be required here. [^5]: This selection avoids confusing your internal network interface from the external interface presented to the world.