From: SourceForge.net <no...@so...> - 2008-05-31 10:36:44
|
Patches item #1937084, was opened at 2008-04-07 23:23 Message generated for change (Comment added) made by fpj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937084&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: fpj (fpj) Summary: Incompatible client and server list detection Initial Comment: Bad things may happen if the lists of hosts that make up ZooKeeper at the client doesn't match the actual servers that make up ZooKeeper particularly when the client's list includes servers from different ZooKeeper instances. The ZooKeeper server should validate the clients list when the clients connect to ZooKeeper. ---------------------------------------------------------------------- >Comment By: fpj (fpj) Date: 2008-05-31 12:36 Message: Logged In: YES user_id=1926444 Originator: NO I have moved this request to the patches queue as I'm proposing a patch. The patch attached creates a new jute packet type, called ChkServersPacket, that clients send to servers and servers recognize as containing the list of ZK servers the client is aware of. The main files affected are ClientCnxn.java and NIOServerCnxn.java. This patch thus not implement a modification to the C interface. A modification to the C client is necessary with the modifications to the server in the current patch as the server drops the connection to the client if the list doesn't match, and it doesn't accept the client coonection if the client doesn't send a list of servers. It is a possibility (not implemented in this patch, though) to enable and disable the check through a configuration flag. -Flavio File Added: patch-chkservers.txt ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-05-29 20:45 Message: Logged In: YES user_id=1926444 Originator: NO File Added: patch-srv-chk.txt ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-05-28 19:20 Message: Logged In: YES user_id=1926444 Originator: NO My plan is to add a check on the server side to NIOServerCNXN.readRequest() similar to the one for OpCode.auth. I would then add a new OpCode "chkservers" and a new packet "ChkServersPacket". Another way would be to piggyback this information on some other message, but I find such things confusing when trying to understand the code later. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-20 04:03 Message: Logged In: YES user_id=154690 Originator: YES I think it should be IP address/port pairs that are compared. It is possible that there could be a backend network used by the servers for the quorum protocols and a frontend network used to talk to clients. In that case we should be able to specify those address/port pairs, but for now lets just assume they are the same. (It's a valid assumption in all our current deployments.) You get extra credit for supporting both IPV4 and V6 addresses :) ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 09:17 Message: Logged In: YES user_id=12853 Originator: NO Are you saying that the client should pass the list of addresses to the Server? and the server should verify this list against the quorum members? I don't see this in the current code - what would have to change, the protocol and client initialization (server connect)? Seems like comparing ip addresses could be an issue since the ip seen by the client could differ from the ips used by the servers. Comparing host names seems like it could also have issues... What happens if a quorum member is temporarily offline (not active member, say network went down temporarily) and a client connects? Also -- seems like the host:port would need to be compared, not just host, correct? (multiple zk clusters running on a single host). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937084&group_id=209147 |