Server should be immutable in some instances

[lasley]

This ticket details issues noticed while mutating a server that has already been created (or partially created & failed, but I'll generate another issue for that once I've tracked more down).

I'll keep adding to this ticket as I debug, but I am thinking the solution here is to just lock certain columns from changing & fix the handling on the ones that should. We'll need to determine ones that should and should not change strategically.

---

• [x] Permissions issues on user mutation

The isolation of tmp directory via the /tmp/key_${self.env.uid} does not account for a user change after initial server creation. The following steps will generate a filesystem permissions issue:

• Create server w/ login set to UserA
• Install server containers
• Change login to UserB
• Reinstall server, attempt to create container, or anything really
• Permissions issues due to UserA owning the /tmp/key_${self.env.uid} directory

---

• [X] SSH port does not update - #136

Pretty straightforward

• Create server w/ port set to 0
• Installation attempted, massive errors (obviously)
• Update port to 22
• Port remains at 0

[YannickB]

Hello,

I just fixed the error with ssh configuration, I had some of them myself because the configuration wasn't properly reloaded.

Regarding your error with user mutation, to me it's an error due to your installation itself (you changed the system user which run Odoo, this is not nothing) and not a Clouder error. But that said, the use of /tmp/key_uid can probably be improved, I had to do it like this because theses keys are generated by two computed field and it was quite tricky to set it up.

[lasley]

FYI I'm centralizing the tmp dir, which doesn't necessarily resolve the first issue, but does make it easier to refactor once an idea emerges: https://github.com/laslabs/clouder/blob/bugfix/9.0/centralize-tmp-dir/clouder/model.py#L232

I didn't change the system user running Odoo to cause the permissions issue, I changed the SSH user for the remote server. This should technically work assuming the remote user exists, has the proper SSH public in authorizedkeys, and permissions to access Docker. The only issue I was seeing was the tmp dir permissions, which I easily resolved with a `chown -r UserB: /tmp/key*` on the remote server.

Awesome on the SSH fix, I'll mark that off.

[YannickB]

Ok got it, I saw your branch I think you're doing a nice improvement of the key generation

[lasley]

This is complete for the most part. Lacking in the permissions of the tmp dir if changing users, but totally not an issue - especially now that things are centralized. Closing