This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
computing:proxmux [2023/06/18 18:43] – oemb1905 | computing:proxmux [2023/12/23 22:24] – oemb1905 | ||
---|---|---|---|
Line 19: | Line 19: | ||
vzdump < | vzdump < | ||
+ | vzdump < | ||
| | ||
- | This will create a VM in .vma format. | + | This will create a VM in .vma format. |
+ | |||
+ | vma extract / | ||
+ | |||
+ | Optionallly, you can use the python tool [[https:// | ||
python3 vma.py vzdump-qemu-101-2023_06_18-12_17_40.vma / | python3 vma.py vzdump-qemu-101-2023_06_18-12_17_40.vma / | ||
+ | |||
+ | In order to see where the virtual machine' | ||
+ | |||
+ | zfs list | ||
| | ||
- | You can also use vma extract as follows: | + | To delete one (be careful), |
+ | zfs destroy pool/ | ||
+ | |||
+ | I've migrated my Windows VM here for testing to avoid cumbersome EFI/TPM setup on virt-manager. Here's a page from ProxMux wiki on best practices for [[https:// | ||
+ | |||
+ | vms/ | ||
+ | vms/ | ||
+ | vms/ | ||
| | ||
+ | Be careful not to delete those thinking wrongly that they are extraneous - those are obviously required for booting, but it might not be clear upon first look. Also, I chose to install those on the '' | ||
+ | |||
+ | To verify sockets and cores | ||
+ | |||
+ | grep " | ||
+ | | ||
+ | Had to switch to postfix with my relay, so used satellite and: | ||
+ | |||
+ | [relay.haacksnetworking.org]: | ||
+ | |||
+ | Created bridge on pve instance with this recipe: | ||
+ | |||
+ | source / | ||
+ | auto lo | ||
+ | iface lo inet loopback | ||
+ | iface enp0s31f6 inet manual | ||
+ | auto vmbr0 | ||
+ | iface vmbr0 inet static | ||
+ | address 10.13.13.2/ | ||
+ | gateway 10.13.13.1 | ||
+ | bridge-ports enp0s31f6 | ||
+ | bridge-stp off | ||
+ | bridge-fd 0 | ||
+ | | ||
+ | Make sure the PVE instance, which is also our reverse proxy has the FQDN set up in ''/ | ||
+ | |||
+ | sudo nano /etc/hosts | ||
+ | < | ||
+ | sudo nano / | ||
+ | < | ||
+ | |||
+ | Set up configurations for each website on nginx as follows: | ||
+ | |||
+ | sudo apt install nginx | ||
+ | sudo nano / | ||
+ | | ||
+ | Enter this in the file | ||
+ | |||
+ | server { | ||
+ | server_name | ||
+ | location / { | ||
+ | proxy_pass http:// | ||
+ | # | ||
+ | } | ||
+ | } | ||
+ | |||
+ | Repeat this as needed for each VM within PVE. For example, here's another entry for an instance doing nextcloud instead of music: | ||
+ | |||
+ | sudo nano / | ||
+ | | ||
+ | Enter this in the file | ||
+ | |||
+ | server { | ||
+ | server_name | ||
+ | location / { | ||
+ | proxy_pass http:// | ||
+ | # | ||
+ | } | ||
+ | } | ||
+ | |||
+ | Once this is done, set up TLS on the PVE/RP instance as follows: | ||
+ | |||
+ | sudo apt install certbot letsencrypt python3-certbot-nginx | ||
+ | sudo certbot --authenticator standalone --installer nginx -d example.domain.com --pre-hook " | ||
+ | |||
+ | Remember, it the reverse proxy web server does not need to match the upstream web server on the LAN at the two different clients '' | ||
+ | |||
+ | sudo nano /etc/hosts [inside VM1] | ||
+ | < | ||
+ | sudo nano / | ||
+ | < | ||
+ | <Header add myheader " | ||
+ | < | ||
+ | |||
+ | That takes care of VM1, now let's do VM2: | ||
+ | |||
+ | sudo nano /etc/hosts [inside VM2] | ||
+ | < | ||
+ | sudo nano / | ||
+ | < | ||
+ | <Header add myheader " | ||
+ | < | ||
+ | | ||
+ | Once this id done, restart your web server. In my case, the VMs are using apache and only the PVE / reverse proxy server is using nginx. After restarting the web servers inside each VM, you now can create the matching certs inside each VM. Here's the commands for VM1: | ||
+ | |||
+ | sudo apt install certbot letsencrypt python3-certbot-apache | ||
+ | sudo certbot --authenticator standalone --installer apache -d music.example.com --pre-hook " | ||
+ | | ||
+ | Here are the commands inside VM2: | ||
+ | |||
+ | sudo apt install certbot letsencrypt python3-certbot-apache | ||
+ | sudo certbot --authenticator standalone --installer apache -d nextcloud.example.com --pre-hook " | ||
+ | | ||
+ | Once that's done, make sure that you have cron jobs set for both VMs and for the reverse proxy server / PVE instance. Just enter the following in crontab for all three: | ||
+ | |||
+ | 30 2 * * 1 / | ||
+ | |||
+ | This should now make Chrome happy since the VM cert will match the cert of the reverse proxy. Why does this work you might ask? Well, when you run certbot inside the VM, it merely cares whether it can be reached externally where you've declared it to be and since it can, it creates the cert without issue. The reverse proxy / PVE instance itself is also able to handle requests for these domains so certbot likewise has no problems issuing the cert there either. This not only makes the Chrome happy, but it addresses what the Chrome developers and rfc 6844 is concerned about, namely, that without this ... connections inside the LAN could potentially be non-TLS or non-header matching. So, this is a best of both worlds. Once this was done and I confirmed that some simple static websites were up and running and accessible externally and internally with no TLS errors on multiple browsers, etc., I then set up a WordPress instance on music.domain.com to ensure that there were no errors using some form of CMS. There were no errors. I am now migrating to this stack because it allows me to segregate services on different VMs in my home network without having to use one massive VM that has vhosts for everything. | ||
+ | |||
+ | One consideration to bear in mind is the following. My example uses one domain.com and other subdomains on that, like music.domain.com and nextcloud.domain.com. That makes it very easy to do. If you want to do this but want to do two different domains, it is certainly possible, but involves more NAT and setup on the reverse proxy and PVE instance than I a) need or b) care to do. It adds no value. I simply want separate VMs that are publicly accessible, internally accessible, TLS-secured, | ||
- | Dreamhost - prepare haacknet for home router. | ||
- | --- // | + | --- // |