Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rfe: enhance geo-replication to consume a separate ssh key to call ssh. #362

Closed
amarts opened this issue Nov 24, 2017 · 8 comments
Closed
Assignees
Labels
CB: geo-replication wontfix Managed by stale[bot]
Milestone

Comments

@amarts
Copy link
Member

amarts commented Nov 24, 2017

For 2 reasons:

  • Mainly for the automated tests: It is very hard to have passwordless ssh in a machine with default key for root, but a separate key is much easier to provide.
  • Also, it makes sense as a feature, because admins can identify the connections with different keys, and some better control can be given with this approach of having separate keys.
@aravindavk
Copy link
Member

+1

Geo-replication already uses seperate key (/var/lib/glusterd/geo-replication/secret.pem), for all its command. Currently Passwordless SSH is required between one master node to one slave node till the session is created. This can be revoked once Geo-rep create is successful. (Required again while running geo-rep create force command after adding new node)

Alternate setup tools are not using passwordless SSH

  • gluster-georep-setup tool will not require passwordless SSH but it accepts one slave nodes root password during setup.
  • Gdeploy integration will not use this passwordless SSH during geo-rep session setup

The enhancement required only for Geo-rep create command. It should accept custom pem key path.
(Note: Change also required in hook scripts and gverify script)

gluster volume geo-replication <mastervol> <slavehost>::<slavevol> create push-pem ssh-key <georep_setup_key.pem>

Note: Even this pem key can be removed/revoked once session is created.

@kotreshhr
Copy link
Contributor

With patch https://review.gluster.org/#/c/18024/ , this is supported in a different way.
The user has to export the path of ssh-key as GR_SSH_IDENTITY_KEY environment variable and it will work.

I think we should close this issue ?

@amarts
Copy link
Member Author

amarts commented Jan 5, 2018

Please document this (for version 4.0) and then close this.

I would like it to be a mention in 4.0 Release notes as well.

@ShyamsundarR (mention for the tracker).

@aravindavk
Copy link
Member

I prefer documenting like below instead of adding that env var in bashrc

GR_SSH_IDENTITY_KEY=/root/georep-key.pem gluster volume geo-replication <master> slavehost>::<slavevol> create push-pem

@kotreshhr kotreshhr self-assigned this Feb 26, 2018
@kotreshhr
Copy link
Contributor

The infra to support this is in place via environment variable as mentioned in above comment. But this is not feasible as a running glusterd wouldn't get the updated environment variable. So we need to provide a cli hook for this. Moving this out of 4.0

@ShyamsundarR ShyamsundarR removed this from the Release 4.1 (LTM) milestone Mar 20, 2018
@amarts
Copy link
Member Author

amarts commented Dec 3, 2019

A good candidate for release-8 / GlusterX ?

@amarts amarts added this to the GlusterX milestone Dec 3, 2019
@stale
Copy link

stale bot commented Jun 30, 2020

Thank you for your contributions.
Noticed that this issue is not having any activity in last ~6 months! We are marking this issue as stale because it has not had recent activity.
It will be closed in 2 weeks if no one responds with a comment here.

@stale stale bot added the wontfix Managed by stale[bot] label Jun 30, 2020
@stale
Copy link

stale bot commented Jul 15, 2020

Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it.

@stale stale bot closed this as completed Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CB: geo-replication wontfix Managed by stale[bot]
Projects
None yet
Development

No branches or pull requests

4 participants