Detailed instructions for rsync deployment method #3848

Merged
merged 1 commit into from Jul 31, 2015

Conversation

Projects
None yet
6 participants
@vitalyrepin
Contributor

vitalyrepin commented Jul 13, 2015

Suggest to provide more extended documentation on rsync-approach. It also mentions rrsync wrapper script which restricts access for rsync to the server. Based on my blog post here: http://vrepin.org/vr/JekyllDeploy/

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 13, 2015

Contributor

Why exactly did the old method need to be removed?

Contributor

envygeeks commented Jul 13, 2015

Why exactly did the old method need to be removed?

@gynter

This comment has been minimized.

Show comment
Hide comment
@gynter

gynter Jul 13, 2015

Contributor

The old method does not describe the process using rsync, but using scp.

Contributor

gynter commented Jul 13, 2015

The old method does not describe the process using rsync, but using scp.

@vitalyrepin

This comment has been minimized.

Show comment
Hide comment
@vitalyrepin

vitalyrepin Jul 13, 2015

Contributor

Rsync based method also suggests to limit write access only to the site directory (using rrsync wrapper) which is more secure than enabling certificate-based ssh access to the hosting account.

Contributor

vitalyrepin commented Jul 13, 2015

Rsync based method also suggests to limit write access only to the site directory (using rrsync wrapper) which is more secure than enabling certificate-based ssh access to the hosting account.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 13, 2015

Contributor

Your method uses SSH all over the place so what does your last statement mean? I personally think the old way could have been retagged instead of removed... your method is not necessarily better (in the way you do it) for the reasons you state but for the reasons you don't state that are obvious to the end-user. I'm not against this, I just think the old way didn't need to be removed, people work in different ways with different tools that they have at the time.

Contributor

envygeeks commented Jul 13, 2015

Your method uses SSH all over the place so what does your last statement mean? I personally think the old way could have been retagged instead of removed... your method is not necessarily better (in the way you do it) for the reasons you state but for the reasons you don't state that are obvious to the end-user. I'm not against this, I just think the old way didn't need to be removed, people work in different ways with different tools that they have at the time.

@vitalyrepin

This comment has been minimized.

Show comment
Hide comment
@vitalyrepin

vitalyrepin Jul 14, 2015

Contributor

Changed my commit per your feedback - put back old method and retagged it to 'scp'.

My last statement was about usage of rrsync wrapper and the restriction to certificate-based authorization (in .ssh/authorized_keys):

command="$HOME/bin/rrsync <folder>",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa <cert>

In this configuration, if the user is authorized with certificate he/she is allowed to execute only rrsync command (restricted rsync).

Contributor

vitalyrepin commented Jul 14, 2015

Changed my commit per your feedback - put back old method and retagged it to 'scp'.

My last statement was about usage of rrsync wrapper and the restriction to certificate-based authorization (in .ssh/authorized_keys):

command="$HOME/bin/rrsync <folder>",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa <cert>

In this configuration, if the user is authorized with certificate he/she is allowed to execute only rrsync command (restricted rsync).

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 16, 2015

Contributor

:shipit: /cc @jekyll/core

Contributor

envygeeks commented Jul 16, 2015

:shipit: /cc @jekyll/core

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jul 16, 2015

Member

Sure, feel free to merge and push out.

Member

parkr commented Jul 16, 2015

Sure, feel free to merge and push out.

@vitalyrepin

This comment has been minimized.

Show comment
Hide comment
@vitalyrepin

vitalyrepin Jul 29, 2015

Contributor

Any update on this? I see "All checks have failed" - is it something caused by my changes? I suspect, this is something else.

Contributor

vitalyrepin commented Jul 29, 2015

Any update on this? I see "All checks have failed" - is it something caused by my changes? I suspect, this is something else.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jul 29, 2015

Member

@vitalyrepin Would you mind rebasing on latest master?

Member

parkr commented Jul 29, 2015

@vitalyrepin Would you mind rebasing on latest master?

Detailed instructions for rsync deployment method
Extended documentation on rsync-approach. It also mentions rrsync wrapper script which restricts access for rsync to the server. Based on my blog post here: http://vrepin.org/vr/JekyllDeploy/

Restored previous version of 'Rsync' section and renamed it to 'scp' to reflect the content

Misspelling corrected: authorized_keys, not auhorized_key
@vitalyrepin

This comment has been minimized.

Show comment
Hide comment
@vitalyrepin

vitalyrepin Jul 31, 2015

Contributor

Rebased. Now checks are passed.

Contributor

vitalyrepin commented Jul 31, 2015

Rebased. Now checks are passed.

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Jul 31, 2015

Contributor

:shipit:

Contributor

envygeeks commented Jul 31, 2015

:shipit:

parkr added a commit that referenced this pull request Jul 31, 2015

@parkr parkr merged commit 1eba509 into jekyll:master Jul 31, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

parkr added a commit that referenced this pull request Jul 31, 2015

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Oct 23, 2015

Contributor

@vitalyrepin See comments in #4048. I'm not familiar with this approach...can you prefix the install location as usr/local?

Contributor

chrisfinazzo commented Oct 23, 2015

@vitalyrepin See comments in #4048. I'm not familiar with this approach...can you prefix the install location as usr/local?

@envygeeks

This comment has been minimized.

Show comment
Hide comment
@envygeeks

envygeeks Oct 25, 2015

Contributor

He used the Linux approach, not the single-user Mac approach. On Linux ~/bin is a common directory (even if a lot of us move it to ~/.local/bin acutally, bin is such a common directory that a lot of distros have a default .profile that checks if it exists so it can place it in the path.

Contributor

envygeeks commented Oct 25, 2015

He used the Linux approach, not the single-user Mac approach. On Linux ~/bin is a common directory (even if a lot of us move it to ~/.local/bin acutally, bin is such a common directory that a lot of distros have a default .profile that checks if it exists so it can place it in the path.

@vitalyrepin

This comment has been minimized.

Show comment
Hide comment
@vitalyrepin

vitalyrepin Oct 25, 2015

Contributor

Just for the reference:

It is not "/bin" but it is "~/bin".

"~" is expanded by the shell to the home directory of the user. Works in OS X as well.

Instruction is written with assumption that the user does not have root access (hence, can not put anything to the system-wide directories, including /usr/local/bin). That's why "~" (home dir) is used.

And this assumption is very realistic - this part of instructions describes server-side setup. E.g., it can be hosting's shell. User is usually granted chrooted environment there.

Contributor

vitalyrepin commented Oct 25, 2015

Just for the reference:

It is not "/bin" but it is "~/bin".

"~" is expanded by the shell to the home directory of the user. Works in OS X as well.

Instruction is written with assumption that the user does not have root access (hence, can not put anything to the system-wide directories, including /usr/local/bin). That's why "~" (home dir) is used.

And this assumption is very realistic - this part of instructions describes server-side setup. E.g., it can be hosting's shell. User is usually granted chrooted environment there.

@chrisfinazzo

This comment has been minimized.

Show comment
Hide comment
@chrisfinazzo

chrisfinazzo Nov 11, 2015

Contributor

Ah, I see. I've updated #4048 with the proper path. cc/ @vitalyrepin

Contributor

chrisfinazzo commented Nov 11, 2015

Ah, I see. I've updated #4048 with the proper path. cc/ @vitalyrepin

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.