3 ms·

Naive question: what's the correct way of doing this when you need to cp your content to a dir like /var/www/html that your user doesn't own (when logging in as

Naive question: what's the correct way of doing this when you need to cp your content to a dir like /var/www/html that your user doesn't own (when logging in as root is prohibited)? My "spooky" (and probably very stupid) method is an Expect script that lets me supply a password to sudo.

quells 5y ago
Usually these directories are owned by another group (www or www-data) so that your web server program (nginx, apache, etc) can access them without running as root. If you add your user to that group, you should be able to manage files in your web root without sudo. Be careful with permissions, though - you may need to chown to set the group after copying so that the files are readable by your web server.
darkr 5y ago
Ideally you want some atomic deployment strategy, rather than having to deal with whatever crap might have been in the directory previously. Something like - extract your deployment artefact to a new, unique directory - and then read-only bind-mount that directory as /var/www/html. > and probably very stupid) method is an Expect script that lets me supply a password to sudo. The old school sysadmin way of doing this would be to have a dedicated deployment user (ssh pubkey auth only - possibly restricting only specific commands), with a sudoers[.d] configuration to allow that user to run an explicit group commands without a password (NOPASSWD)
alfonsodev 5y ago
a pattern I have seen before is to clone the branch commit of each release to a folder /var/releases/{release_commit} and then html is not a folder but a soft link so /var/www/html -> /var/releases/latest_release_commit this is useful if you need to revert back quickly. But then releases folder needs to be cleaned up, or you can run out of space.
- Sohcahtoa82 5y ago
  That's dangerous unless you've properly configured your web server to block access to your .git directory.
  - handrous 5y ago
    Safer/easier to keep the .git somewhere else entirely, rather than in the working directory. Git's got arguments that let you do that. Then you can check out to a dir that doesn't have the .git dir in it at all. Alternatively, it's pretty easy to use git-archive (optionally, with an exclusions list to keep out files you don't want to serve publicly) to do something similar without ever cloning the remote repo. You can fetch a zip or tar.gz with a given commit's files, straight from a remote repo.
dangerface 5y ago
Login as the user that owns that dir, don't try to hack around the user permissions. Also you probably don't want your web under /var if its a partition and you fill it with lets say user content then you will lock up your server.
nightfly 5y ago
Ansible can do this (you tell it the user to initially log in, and that you need to "become" another user for a task)

quells 5y ago

Usually these directories are owned by another group (www or www-data) so that your web server program (nginx, apache, etc) can access them without running as root. If you add your user to that group, you should be able to manage files in your web root without sudo. Be careful with permissions, though - you may need to chown to set the group after copying so that the files are readable by your web server.

darkr 5y ago

Ideally you want some atomic deployment strategy, rather than having to deal with whatever crap might have been in the directory previously. Something like - extract your deployment artefact to a new, unique directory - and then read-only bind-mount that directory as /var/www/html. > and probably very stupid) method is an Expect script that lets me supply a password to sudo. The old school sysadmin way of doing this would be to have a dedicated deployment user (ssh pubkey auth only - possibly restricting only specific commands), with a sudoers[.d] configuration to allow that user to run an explicit group commands without a password (NOPASSWD)

alfonsodev 5y ago

a pattern I have seen before is to clone the branch commit of each release to a folder /var/releases/{release_commit} and then html is not a folder but a soft link so /var/www/html -> /var/releases/latest_release_commit this is useful if you need to revert back quickly. But then releases folder needs to be cleaned up, or you can run out of space.

Sohcahtoa82 5y ago
That's dangerous unless you've properly configured your web server to block access to your .git directory.
- handrous 5y ago
  Safer/easier to keep the .git somewhere else entirely, rather than in the working directory. Git's got arguments that let you do that. Then you can check out to a dir that doesn't have the .git dir in it at all. Alternatively, it's pretty easy to use git-archive (optionally, with an exclusions list to keep out files you don't want to serve publicly) to do something similar without ever cloning the remote repo. You can fetch a zip or tar.gz with a given commit's files, straight from a remote repo.

dangerface 5y ago

Login as the user that owns that dir, don't try to hack around the user permissions. Also you probably don't want your web under /var if its a partition and you fill it with lets say user content then you will lock up your server.

nightfly 5y ago

Ansible can do this (you tell it the user to initially log in, and that you need to "become" another user for a task)