kotovalexarian-likes-github/capistrano
1
0
Fork 0
mirror of https://github.com/capistrano/capistrano synced 2023-03-27 23:21:18 -04:00
Code Releases Activity

Expanding on the docs

Browse source
This commit is contained in:
Lee Hambley 2013-06-24 21:02:01 +02:00
parent 94b8564296
commit 2446004686
2 changed files with 105 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

70
_site/documentation/getting-started/authentication-and-authorisation/index.html
View file

@ -412,6 +412,41 @@ this carefully, and ideally architect your systems so that non-privlidged
users can restart services, or that services restart <em>themselves</em> when they
notice change.</p>
<p>To configure this heirarchy, ignoring for the moment the passwordless <code>sudo</code>
access that you may or may not need depending how well your servers are setup:</p>
<div>
<pre data-line=''><code class='language-bash'>me@localhost $ ssh root@remote
# Capistrano will use /var/www/....... where ... is the value set in
# :application, you can override this by setting the &#39;:deploy_to&#39; variable
root@remote $ deploy_to=/var/www/rails3-bootstrap-devise-cancan-demo
root@remote $ mkdir ${deploy_to}
root@remote $ chown deploy:deploy ${deploy_to}
root@remote £ umask 0002
root@remote $ chmod g+s ${deploy_to}
root@remote $ mkdir ${deploy_to}/{releases,shared}</code></pre>
</div>
<p><strong>Note:</strong> The <code>chmod g+s</code> is a really handy, and little known Unix feature, it
means that at the operating system level, without having to pay much attention
to the permissions at runtime, all files an directories created inside the
<code>${deploy_to}</code> directoy will inherit the group ownership, that means in this
case even though we are root, the files will be created being owned by <code>root</code>
with the group <code>deploy</code>, the <code>umask 0002</code> ensures that the files created
<em>during this session</em> are created with the permissions <em>owner read/write,
group: read/write, other: none</em>. This means that we&#39;ll be able to read these
files from Apache, or our web server by running the web server in the <code>deploy</code>
group namespace.</p>
<div>
<pre data-line=''><code class='language-bash'>root@remote # stat -c &quot;%A (%a) %n&quot; ${deploy_to}/
drwx--S--- (2700) /var/www/rails3-bootstrap-devise-cancan-demo
root@remote # stat -c &quot;%A (%a) %n&quot; ${deploy_to}/*
drwxrwsr-x (2775) /var/www/rails3-bootstrap-devise-cancan-demo/releases
drwxrwsr-x (2775) /var/www/rails3-bootstrap-devise-cancan-demo/shared</code></pre>
</div>
</div>
</div>
</div>
@ -736,6 +771,41 @@ as root, they can easily edit it to do anything they want that is evil. Use
this carefully, and ideally architect your systems so that non-privlidged
users can restart services, or that services restart <em>themselves</em> when they
notice change.</p>
<p>To configure this heirarchy, ignoring for the moment the passwordless <code>sudo</code>
access that you may or may not need depending how well your servers are setup:</p>
<div>
<pre data-line=''><code class='language-bash'>me@localhost $ ssh root@remote
# Capistrano will use /var/www/....... where ... is the value set in
# :application, you can override this by setting the &#39;:deploy_to&#39; variable
root@remote $ deploy_to=/var/www/rails3-bootstrap-devise-cancan-demo
root@remote $ mkdir ${deploy_to}
root@remote $ chown deploy:deploy ${deploy_to}
root@remote £ umask 0002
root@remote $ chmod g+s ${deploy_to}
root@remote $ mkdir ${deploy_to}/{releases,shared}</code></pre>
</div>
<p><strong>Note:</strong> The <code>chmod g+s</code> is a really handy, and little known Unix feature, it
means that at the operating system level, without having to pay much attention
to the permissions at runtime, all files an directories created inside the
<code>${deploy_to}</code> directoy will inherit the group ownership, that means in this
case even though we are root, the files will be created being owned by <code>root</code>
with the group <code>deploy</code>, the <code>umask 0002</code> ensures that the files created
<em>during this session</em> are created with the permissions <em>owner read/write,
group: read/write, other: none</em>. This means that we&#39;ll be able to read these
files from Apache, or our web server by running the web server in the <code>deploy</code>
group namespace.</p>
<div>
<pre data-line=''><code class='language-bash'>root@remote # stat -c &quot;%A (%a) %n&quot; ${deploy_to}/
drwx--S--- (2700) /var/www/rails3-bootstrap-devise-cancan-demo
root@remote # stat -c &quot;%A (%a) %n&quot; ${deploy_to}/*
drwxrwsr-x (2775) /var/www/rails3-bootstrap-devise-cancan-demo/releases
drwxrwsr-x (2775) /var/www/rails3-bootstrap-devise-cancan-demo/shared</code></pre>
</div>
-->
<!--</div> [> /container <] -->

35
documentation/getting-started/authentication-and-authorisation/index.markdown
View file

@ -312,3 +312,38 @@ this carefully, and ideally architect your systems so that non-privlidged
users can restart services, or that services restart *themselves* when they
notice change.
To configure this heirarchy, ignoring for the moment the passwordless `sudo`
access that you may or may not need depending how well your servers are setup:
{% prism bash %}
me@localhost $ ssh root@remote
# Capistrano will use /var/www/....... where ... is the value set in
# :application, you can override this by setting the ':deploy_to' variable
root@remote $ deploy_to=/var/www/rails3-bootstrap-devise-cancan-demo
root@remote $ mkdir ${deploy_to}
root@remote $ chown deploy:deploy ${deploy_to}
root@remote £ umask 0002
root@remote $ chmod g+s ${deploy_to}
root@remote $ mkdir ${deploy_to}/{releases,shared}
{% endprism %}
**Note:** The `chmod g+s` is a really handy, and little known Unix feature, it
means that at the operating system level, without having to pay much attention
to the permissions at runtime, all files an directories created inside the
`${deploy_to}` directoy will inherit the group ownership, that means in this
case even though we are root, the files will be created being owned by `root`
with the group `deploy`, the `umask 0002` ensures that the files created
*during this session* are created with the permissions *owner read/write,
group: read/write, other: none*. This means that we'll be able to read these
files from Apache, or our web server by running the web server in the `deploy`
group namespace.
{% prism bash %}
root@remote # stat -c "%A (%a) %n" ${deploy_to}/
drwx--S--- (2700) /var/www/rails3-bootstrap-devise-cancan-demo
root@remote # stat -c "%A (%a) %n" ${deploy_to}/*
drwxrwsr-x (2775) /var/www/rails3-bootstrap-devise-cancan-demo/releases
drwxrwsr-x (2775) /var/www/rails3-bootstrap-devise-cancan-demo/shared
{% endprism %}