search

enowars / eno-landing-page

ENOWARS Landing Page
MIT License
0 stars 1 forks source link

Block VMs shutdown/restarts in the first few minutes #11

Open ldruschk opened 4 years ago

ldruschk commented 4 years ago

Stopping/restarting the VM while the provisioning is still running causes the VM to end up in a broken state.

Trolldemorted commented 4 years ago

What exactly do you mean with broken? Can the VM not be turned on again? Should we raise this at hetzner?

ldruschk commented 4 years ago

It can be turned on, it just won't run the cloud-init provisioning that should happen during the first boot again.

Trolldemorted commented 4 years ago

Ok, that sounds intentional from hetzner's point of view. We used that to generate the openvpn certs, right?

ldruschk commented 4 years ago

Yes, although that won't be needed in the future anymore. It is however still used for deploying the Wireguard configuration, changing the password and starting services (and doing any team-specific service provisioning if required)

Trolldemorted commented 4 years ago

What is the plan for the future? Have a setup.sh which asks for a password and then does everything the cloud-init foo did?

ldruschk commented 4 years ago

Simply preventing the teams from restarting/stopping the VM before the provisioning is done by disabling these options in the web interface.

Trolldemorted commented 4 years ago

So no curl https://enowars.com/setup.sh | sh 😥

ldruschk commented 4 years ago

Imo that is a somewhat independent issue. The setup script for self-hosted vulnboxes would still be different from that used by teams self-hosting their vulnbox.

Given how simple self-hosting the vulnbox was for ENOWARS4 (if you exclude the 2gather keys), I find it easier to tell the teams to just install Wireguard, Docker and docker-compose and give them the Wireguard config. The service could then be distributed via GitHub again.

Simply replacing the provisioning of the vulnbox with curl https://enowars.com/setup.sh | sh would still not prevent people from stopping the VM during the provisioning.

Trolldemorted commented 4 years ago

The setup script for self-hosted vulnboxes would still be different from that used by teams self-hosting their vulnbox.

Why is that? It can ask whether it should deploy the wireguard stuff and whether it should deploy the services stuff. Selfhosting doesn't always mean having a complex setup like we do now, we have hosted vulnboxes on our laptops "back in the days".

Given how simple self-hosting the vulnbox was for ENOWARS4 (if you exclude the 2gather keys), I find it easier to tell the teams to just install Wireguard, Docker and docker-compose and give them the Wireguard config. The service could then be distributed via GitHub again.

Point taken, if we say team-specific is the exception and not the norm this works well. How did we solve 2gather?

Simply replacing the provisioning of the vulnbox with curl https://enowars.com/setup.sh | sh would still not prevent people from stopping the VM during the provisioning.

No, but they would know that they stopped the VM while provisioning and they could restart the provisioning process (and they know they have to provision it themselves).