Unix domain socket support #12450
Comments
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
|
the line you mentioned should just verify the host part not the scheme part. for that part, it probably need to differentiate unix socket which does not need a port. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
|
This issue has an open PR, I propose we reopen it. /reopen |
When restoring a backup for both etcd and etcd-events, I observed a port-conflict on port 8002/8003. Switching to unixs:// endpoints (unix domain sockets) is a little more secure, and avoids the port conflict. Due to etcd-io/etcd#12450 the syntax is slightly awkward - we have to make it look like a host and port.
When restoring a backup for both etcd and etcd-events, I observed a port-conflict on port 8002/8003. Switching to unixs:// endpoints (unix domain sockets) is a little more secure, and avoids the port conflict. Due to etcd-io/etcd#12450 the syntax is slightly awkward - we have to make it look like a host and port.
|
Hi I was wondering will this feature be supported on feature release of etcd 3.5? Creating an embedded etcd cluster using unix socket would be very convenient for test purposes😀 |
|
Looks like #12469 was merged into main but not backported to 3.5, any chance it could be backported? |
Resolves etcd-io#12450 This commits adds support to unix/unixs socket URLs, which currently fail with the message "URL address does not have the form "host:port". It also replaces the work started in etcd-io#11747.
Resolves etcd-io#12450 This commits adds support to unix/unixs socket URLs, which currently fail with the message "URL address does not have the form "host:port". It also replaces the work started in etcd-io#11747. (cherry picked from commit d93b7c8) Signed-off-by: Hubert Zhang <hubert.zyk@gmail.com>
Resolves etcd-io#12450 This commits adds support to unix/unixs socket URLs, which currently fail with the message "URL address does not have the form "host:port". It also replaces the work started in etcd-io#11747. (cherry picked from commit d93b7c8) Signed-off-by: Hubert Zhang <hubert.zyk@gmail.com>
When restoring a backup for both etcd and etcd-events, I observed a port-conflict on port 8002/8003. Switching to unixs:// endpoints (unix domain sockets) is a little more secure, and avoids the port conflict. Due to etcd-io/etcd#12450 the syntax is slightly awkward - we have to make it look like a host and port.
Hi. In the documentation for --listen-client-urls, the docs say that a unix path like
unix://<file-path>can be used.However, due to this validation code, unix domain sockets cannot actually be used. We get an error like the following:
Is my use of the flag correct?
--listen-client-urls=unix:///var/etcd/data/datafileHas anyone had success using unix sockets with etcd?
The text was updated successfully, but these errors were encountered: