Container Creation, Custom Port Mapping, + Dnsmasq/Nginx configuration updates for HTTPS

[maxklema]

Updated June 30th, 2025

Fixes

1) User passwords are unset after the container creation script.

unset CONFIRM_PASSWORD
unset CONTAINER_PASSWORD
unset PUBLIC_KEY

2) Key Files are now stored only temporarily, not permanently. They are created when a user enters a key and are copied over to their respective container and placed in ~/.ssh/authorized_keys. After, the key files are deleted. A similar approach occurs with custom port mapping. Deleting these files is more efficient than storing them permanently when they are no longer needed.

3) Even number CTID's are placed on pve2, while odd numbers are placed on pve1 automatically.

if (( $NEXT_ID % 2 == 0 )); then
       pct stop $NEXT_ID
       pct migrate $NEXT_ID intern-phxdc-pve2 --target-storage containers-pve2 --online
       ssh root@10.15.0.5 "pct start $NEXT_ID"
fi

4) Port Mapping (including SSH, HTTP, and all custom protocols) is automatically updated to port_map.json and iptables. SSH and HTTP ports are automatically generated, but users can add custom protocols from a master list if they so choose.

# Run Contianer Provision Script to add container to port_map.json

if [ -f "/var/lib/vz/snippets/container-port-maps/$PROTOCOL_FILE" ]; then
	echo "CONTAINS PROTOCOL FILE"
	/var/lib/vz/snippets/register-container-test.sh $NEXT_ID $HTTP_PORT /var/lib/vz/snippets/container-port-maps/$PROTOCOL_FILE
	rm -rf /var/lib/vz/snippets/container-port-maps/$PROTOCOL_FILE
else
	/var/lib/vz/snippets/register-container-test.sh $NEXT_ID $HTTP_PORT
fi

5) Only authorized users can SSH to the container-creation script. They must know the password for the create-container user on the jump host and the container creation container. Additionally, they must provide Proxmox credentials. The command to SSH: ssh create-container@opensource.mieweb.org. The script runs as a force command, meaning they do not have shell access outside of the script. They can not inspect the bin/ or any other directories that may contain sensitive information.

6) Public Key Registration: Users have the option to add their rsa/ed215.. public key. This allows them to not only SSH into their container without entering their password, but also allows them to log in to the create-container script faster since the jump host and container creation store the public key.

7) HTTP Ports. Turns out, HTTP port mapping is a good thing, since not every container must/can listen on port 80. Users can now choose which HTTP port their container listens on, and the Nginx reverse proxy forwards all HTTP traffic to that port automatically.

8) Informative Results: After the container is created, users get a list of protocol port numbers for their containers, their domain name, and a simple SSH command to quickly SSH into their container. A container can now get up and running in less than 3 minutes without admin intervention.

Previous Changes

Changes to intern-phxdc-pve1/register-container.sh:

Allows an optional parameter for custom ports.

./register-container.sh <CITD> <PARAM FILE>

where PARAM FILE has the following format:

Protocol Underlying-Protocol Default-Protocol-Port, Example: MPP TCP 218. As many protocols can be added as needed. All protocols are mapped to a custom, unique port in the range of 10,000-29,999.

Iptables are updated accordingly for each custom protocol + SSH.

port_maps.json is structured a bit differently. All ports are included in a map under ports key:

"max-container": {
    "ip": "10.15.x.x",
    "ports": {
       "HTTP": 80,
       "ssh": 2256,
       "MPP": 10042,
       "LDAP": 10043
    }
}

Dnsmasq + Nginx config updates

Dnsmasq has an additional domain for *.opensource.mieweb.org, both .org and .com map to the Nginx server.

Reverse Nginx proxy supports an additional server block for HTTPS/SSL traffic. This part is commented for now until we acquire the private key for the Let's Encrypt DNS certificate for *.org, which is needed to serve HTTPS traffic.

[cmyers-mieweb]

Added a couple notes on some items I spotted. While we have create-a-container open on this PR, can we add the following logic if a container's CTID is an even value for hypervisor load balancing?
pct migrate <CTID> intern-proxmox-pve2 --targetstorage containers-pve2

[cmyers-mieweb]

For added security I would consider unsetting any password fields at the conclusion of the variables use.
While I doubt we will encounter these issues, it is good practice to make this as secure as possible. If a user runs env or export in the same shell session after the script, they might see the password values if the variables are still set. Or since this is technically a multi-user container, if a user can access the memory of another user’s processes (e.g., via /proc), they might be able to read environment variables, including passwords, if the script is still running and the variables are set.

# Use $CONTAINER_PASSWORD as needed here...

unset CONTAINER_PASSWORD
unset CONFIRM_PASSWORD

[maxklema]

Good suggestion, I will implement that.

[maxklema]

Added a couple notes on some items I spotted. While we have create-a-container open on this PR, can we add the following logic if a container's CTID is an even value for hypervisor load balancing? pct migrate <CTID> intern-proxmox-pve2 --targetstorage containers-pve2

Yes, I can implement this.

[cmyers-mieweb]

Reviewed with Max container creation process, tested multiple instances of container startups, shutdowns, however found an issue where if a container is pct destroyed, the script will lock and fail. Need to to perform an RCA before merge.

[maxklema]

Reviewed with Max container creation process, tested multiple instances of container startups, shutdowns, however found an issue where if a container is pct destroyed, the script will lock and fail. Need to to perform an RCA before merge.

I made one more commit since our meeting, which provides fixes to that disk CTID lock error. Essentially, when I was demoing the script, I forced quit (CTRL C) the script during the cloning process. During the cloning process, the template (CTID 114) is locked via the disk, which stops any operations that are happening in the background to ensure it is cloned correctly. If you force quit at the right time, the container you created and the template both remain in a locked state. Therefore, when you tried to create a container after, it failed because the template was still in that locked state. To fix this, I implemented a trap command that runs on certain termination signals (like CTRL-C) that will unlock the template and remove some other files. This seems to work. Try to run the container creation script again and let me know if it works this time on your end. I am going to merge my changes into the main branch. I am glad we discovered this during testing.

[cmyers-mieweb]

Tested again by creating an even number CTID to also check SSH capability on pve2, confirmed this fix works. Good to merge.