deployment.keys.*.user/group need to be sent after activation #232
Comments
|
@rbvermaa is this what is causing my deployment to end with: ? |
|
@aaronlevin did you find a work-around for this? EC2 deployments work fine for me, but container deployments fail with this error. |
|
The mentioned error is not the error that would show up with this issue. |
|
@rened I am not 100% sure, but it might be the ssh connection (as root) to the server where the containers are running. |
|
Thanks a lot @rbvermaa, that fixed it! I was not aware that also for deployments to a container on localhost a ssh login to I would like to add instructions for this for newcomers like me, would And thanks a lot for all your work on nixops - it is one of the coolest things I have ever seen. |
|
I don't think the container backend is described yet in the manual, which would be the best place to put any documentation. We should probably also improve the error message in this particular situation. |
|
Ok, I'll draft a little section for the manual then, just walking thought the trivial-container.nix example. |
|
@rened Awesome! Very much appreciated! |
|
I have an issue where if I set deployment.keys."foo".user, and a nixos module is responsible for creating this user in a users.extraUsers expression, then the deployment fails because it tries to |
|
This should be related to #362. |
Instead of chowning keys to their user/group every time they are sent, only attempt the chown during send-keys if the user and group both exist, and again do a chown during activation after the users and groups have been created. One result is that if a key and its user and/or group are to be created in the same `nixops deploy`, the key will first be uploaded and owned by root:root, then chmod'd, then late in activation the key will be chowned to the newly created user/group. This includes a node's first deploy, when it has neither keys nor users/groups. Another result is that between send-keys and the next deploy (often, but not necessarily, in the same `nixops deploy`), a key may have its permissions set as configured, but _not_ be owned by the configured user/group (instead root:root), which is presumed safe. fixes NixOS#362, fixes NixOS#232
Instead of chowning keys to their user/group every time they are sent, only attempt the chown during send-keys if the user and group both exist, and again do a chown during activation after the users and groups have been created. One result is that if a key and its user and/or group are to be created in the same `nixops deploy`, the key will first be uploaded and owned by root:root, then chmod'd, then late in activation the key will be chowned to the newly created user/group. This includes a node's first deploy, when it has neither keys nor users/groups. Another result is that between send-keys and the next deploy (often, but not necessarily, in the same `nixops deploy`), a key may have its permissions set as configured, but _not_ be owned by the configured user/group (instead root:root), which is presumed safe. fixes NixOS#362, fixes NixOS#232
|
See #400 |
Instead of chowning keys to their user/group every time they are sent, only attempt the chown during send-keys if the user and group both exist, and again do a chown during activation after the users and groups have been created. One result is that if a key and its user and/or group are to be created in the same `nixops deploy`, the key will first be uploaded and owned by root:root, then chmod'd, then late in activation the key will be chowned to the newly created user/group. This includes a node's first deploy, when it has neither keys nor users/groups. Another result is that between send-keys and the next deploy (often, but not necessarily, in the same `nixops deploy`), a key may have its permissions set as configured, but _not_ be owned by the configured user/group (instead root:root), which is presumed safe. fixes NixOS#362, fixes NixOS#232
Otherwise deployments fail on initial deployments.
The text was updated successfully, but these errors were encountered: