computing:proxmux
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
| computing:proxmux [2023/12/23 21:45] – oemb1905 | computing:proxmux [2023/12/24 11:18] – oemb1905 | ||
|---|---|---|---|
| Line 11: | Line 11: | ||
| ------------------------------------------- | ------------------------------------------- | ||
| - | Been testing proxmux on home back up server. The server | + | Most important thing about proxmox |
| qm importdisk 500 hub.jonathanhaack.com.qcow2 < | qm importdisk 500 hub.jonathanhaack.com.qcow2 < | ||
| - | qm set 500 --scsi0 vms: | + | qm set 500 --scsi0 vms: |
| | | ||
| - | These commands bring in the image block by block, and then re-assign the virtual disk that VM 500 uses to the image you just brought in, instead of the placeholder image you created | + | Alternately, if you just want to attach a raw image file, or VDD, to an existing proxmox VM, just do the following: |
| + | |||
| + | qm importdisk < | ||
| + | |||
| + | After that, you can add storage | ||
| vzdump < | vzdump < | ||
| Line 61: | Line 65: | ||
| auto vmbr0 | auto vmbr0 | ||
| iface vmbr0 inet static | iface vmbr0 inet static | ||
| - | address 10.18.18.2/24 | + | address 10.13.13.2/24 |
| - | gateway 10.18.18.1 | + | gateway 10.13.13.1 |
| bridge-ports enp0s31f6 | bridge-ports enp0s31f6 | ||
| bridge-stp off | bridge-stp off | ||
| Line 77: | Line 81: | ||
| sudo apt install nginx | sudo apt install nginx | ||
| - | sudo nano / | + | sudo nano / |
| | | ||
| Enter this in the file | Enter this in the file | ||
| server { | server { | ||
| - | server_name | + | server_name |
| location / { | location / { | ||
| - | proxy_pass http:// | + | proxy_pass http:// |
| - | # | + | # |
| } | } | ||
| } | } | ||
| - | Repeat this as needed for each VM within PVE. Once this is done, set up TLS on the PVE/RP instance as follows: | + | 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 apt install certbot letsencrypt python3-certbot-nginx | ||
| sudo certbot --authenticator standalone --installer nginx -d example.domain.com --pre-hook " | 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, | ||
| - | --- // | + | --- // |
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
