Skip to content

Enhances provisioning for sudo-only hosts#4242

Open
alexstewartja wants to merge 2 commits into
deployphp:masterfrom
alexstewartja:sudo-only-polyfills
Open

Enhances provisioning for sudo-only hosts#4242
alexstewartja wants to merge 2 commits into
deployphp:masterfrom
alexstewartja:sudo-only-polyfills

Conversation

@alexstewartja

Copy link
Copy Markdown

Improves the provisioning process to support VPS environments that do not provide direct root access, relying instead on a user with sudo privileges.

  • Provision User Setup:

    • Dynamically locates the authorized_keys file for the provision_user if the root user's key isn't available.
    • Adds robust sudo fallbacks for copying public keys and generating SSH keys for the deployer user, allowing these operations to succeed even without direct write permissions by leveraging sudo.
    • Ensures the deploy_path is created and owned by the deployer user during the initial user provisioning, making it ready for deployment.
  • Website Provisioning:

    • Sets the remote_user to the provision_user for the initial stages of website provisioning, enabling sudo operations where necessary before switching to the deployer user.
    • Correctly sets group ownership (deployer:caddy) and makes the log directory group-writable (chmod 775) to ensure the Caddy web server can successfully write access logs, preventing reload failures.

Shared-hosting VPS offerings (e.g. GoDaddy) grant sudo access but no
direct root login, which breaks multiple assumptions in the provision
recipes. All changes are guarded so the default root-login path is
unaffected.

provision:user:
- /root/.ssh/authorized_keys may not exist when you connect as a
  non-root provision_user. Fall back to that user's authorized_keys
  (resolved via getent) so the deployer user still gets a login key.
- Create {{deploy_path}} and chown it to deployer while still running
  as the privileged host user, since a non-root user cannot chown.

provision:website:
- Set remote_user to provision_user (every other provision task does)
  so commands connect as that user and elevate via the host's
  become:root; otherwise a standalone run never establishes root and
  the mkdir/chown run unprivileged -> Permission denied.
- Create the log dir and assign owner deployer / group caddy in the
  root context. The deployer user's supplementary caddy group is not
  reliably active in the non-login 'sudo -H -u deployer' shell, so a
  later 'chgrp caddy' as deployer fails with Operation not permitted.
Ensures the caddy daemon (which runs as group `caddy`) can create `access.log`
within `{{deploy_path}}/log`. Without `775` permissions, `service caddy reload`
fails to open the log writer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant