From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Serge Petrenko <sergepetrenko@tarantool.org> Cc: tarantool-patches@freelists.org Subject: Re: [tarantool-patches] [PATCH v2] iproto: introduce a proxy module. Date: Mon, 8 Oct 2018 19:48:07 +0300 [thread overview] Message-ID: <20181008164807.ewiv7lwfh4e4decg@esperanza> (raw) In-Reply-To: <20181002180554.1142-1-sergepetrenko@tarantool.org> On Tue, Oct 02, 2018 at 09:05:54PM +0300, Serge Petrenko wrote: > Since salt proxy sends to a client differs from the salt it recieves > from a remote instance, forwarding auth requests to establish non-guest > connections is a little bit tricky: > let hash1 = sha1(password), > hash2 = sha1(hash1) > then upon auth proxy recieves such a string from the client: > reply = xor(hash1, sha1(proxy_salt, hash2)) > proxy has to send an auth request of such form to an instance: > request = xor(hash1, sha1(instance_salt, hash2)) > proxy fetches hash2 via a special message to tx thread (again, it is > accessible, since proxy is run on one of the cluster instances). > Then proxy computes hash1 = xor(reply, sha1(proxy_salt, hash2)) and > computes the request using hash1, hash2 and instance_salt. So unless the user is fine with guest access (which is rather unlikely AFAIU), it doesn't make sense to run a proxy on a standalone instance, does it? If so, may be we could simplify both configuration and the code by requiring a proxy to be a part of the replica set? I mean instead of netbox.listen(), we could add a knob to box.cfg, say box.cfg.proxy_enable = true|false. If this knob was set, the instance would automatically forward all incoming iproto requests to members of the replica set (including self). What do you think? > Proxy may be configured like this: > ``` > netbox = require("net.box") > netbox.listen(uri_to_listen, {cluster={ > {uri=uri1, is_master=false}, > {uri=uri2, is_master=true}, > ... > }}) > ``` I don't like that the user has to explicitly configure which participant is rw and which is ro. How will it work when box.ctl.promote is finally implemented?
next prev parent reply other threads:[~2018-10-08 16:48 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-02 18:05 Serge Petrenko 2018-10-03 8:49 ` Vladimir Davydov 2018-10-04 11:54 ` [tarantool-patches] " Georgy Kirichenko 2018-10-08 10:44 ` [tarantool-patches] " Vladimir Davydov 2018-10-16 18:35 ` [tarantool-patches] " Konstantin Osipov 2018-10-08 16:48 ` Vladimir Davydov [this message] 2018-10-16 18:39 ` Konstantin Osipov 2018-10-17 8:35 ` Vladimir Davydov 2018-10-17 15:31 ` Konstantin Osipov 2018-10-08 19:45 ` [tarantool-patches] " Vladimir Davydov 2018-10-16 18:42 ` [tarantool-patches] " Konstantin Osipov 2018-10-23 17:26 ` Konstantin Osipov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181008164807.ewiv7lwfh4e4decg@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=sergepetrenko@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [tarantool-patches] [PATCH v2] iproto: introduce a proxy module.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox