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 22:09] – 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 140: | Line 144: | ||
| 30 2 * * 1 / | 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. | + | 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. |
| + | 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
