My suggestion is that we get this in and let it sit for a couple of weeks before cutting an RC. Alternatively, we could cut an RC and just give more time than the typical 2 weeks for people to test.
-Flavio > On 29 Nov 2016, at 17:23, Patrick Hunt <ph...@apache.org> wrote: > > I did a bunch of manual testing last week. I tried running multiple cluster > sizes, tried running new server against old server, also went through the > rolling upgrade testing part of the document and that worked fine. afaict > at this point we're ready to commit. If there are any concerns please speak > up now as I intend to commit this soon. > > Patrick > > On Fri, Nov 18, 2016 at 12:15 PM, Patrick Hunt <ph...@apache.org> wrote: > >> As Flavio said originally on this thread this is a big change. Based on >> the current status of the patch and the testing feedback it seems like >> we've done significant work to ensure the quality of the change. Do folks >> feel that there has been sufficient review/testing that we can commit this >> and cut a 3.5.10 release? If not what specifically is left? >> >> Patrick >> >> On Wed, Nov 2, 2016 at 8:51 AM, Andrew Purtell <apurt...@apache.org> >> wrote: >> >>>> My view on this-> Since ZK server >>>> already has "jaas.config" in place for client-server auth, IMHO to >>> continue >>> >>> Right, also build the client-server authentication context >>> programatically. >>> >>>> How about pushing the current >>>> approach as a first step and based on the community interests later we >>>> could enhance this feature by programmatically builds the JAAS context. >>> >>> Yes, this is what I was suggesting. >>> >>> Thanks for considering the idea. >>> >>>> 1) A bad host or bad Kerb principal is keep on trying to establish >>>> connection with the Quorum. >>> >>>> 2) Trigger FLE several times. >>> >>> Let me get back to you. >>> >>> I think it would also not be difficult to create a new unit test that >>> extends QuorumHammerTest (like ObserverQuorumHammerTest), sets up a >>> secure >>> configuration using the minikdc, and then uses QuorumBase methods to start >>> and stop quorum peers at random while the generated load is hitting the >>> quorum. >>> >>> >>> On Wed, Nov 2, 2016 at 7:15 AM, Rakesh Radhakrishnan <rake...@apache.org> >>> wrote: >>> >>>> Thanks a lot Andrew Purtell for your time and comments. >>>> >>>>>>>>> I like how Hadoop programmatically builds the JAAS context from its >>>>>>>>> configuration such that the JAAS configuration file and definition >>> of >>>>>>>>> system property pointing to same are not needed. Would be nice if >>> ZK >>>> could >>>>>>>>> optionally do the same, that would be one fewer config file to get >>>>>>>>> precisely right. >>>> >>>> Its really an interesting thought. My view on this-> Since ZK server >>>> already has "jaas.config" in place for client-server auth, IMHO to >>> continue >>>> with this jaas config and allows to configure the 'QuorumServer' & >>>> 'QuorumLearner' quorum auth sections. How about pushing the current >>>> approach as a first step and based on the community interests later we >>>> could enhance this feature by programmatically builds the JAAS context. >>>> Does this makes sense to you? >>>> >>>> >>>>>>>> Any suggestions on some kind of hammer test to apply now ? >>>> 1) A bad host or bad Kerb principal is keep on trying to establish >>>> connection with the Quorum. Mostly this will increase the load on >>> Leader ZK >>>> server and observe how the system behaves. >>>> 2) Trigger FLE several times. This can be done by finding out newly >>> elected >>>> Leader and kill it. Probably can do this many times. >>>> >>>> >>>> Dear Committers, >>>> >>>> Could you please help me pushing ZOOKEEPER-2479 this in. This would >>> help to >>>> evaluate the time taken for FLE(enable or disable auth) and used to >>> compare >>>> time taken in several runs programatically in scripts or so. Thanks! >>>> >>>> Thanks, >>>> Rakesh >>>> >>>> On Wed, Nov 2, 2016 at 6:59 AM, Andrew Purtell <apurt...@apache.org> >>>> wrote: >>>> >>>>> I would like to relay a working example of a patched 3.4.9 ZK cluster >>>>> running on one host (without containers). I can confirm mutual SASL >>> auth >>>>> among the quorum is required and enforced because when instances were >>>>> slightly misconfigured with incorrect principal strings they couldn't >>>>> participate in the quorum. >>>>> >>>>> 1. Assign extra loopback addresses. Example below is what you need to >>> do >>>>> for FreeBSD: >>>>> >>>>> $ sudo ifconfig lo0 127.0.1.1 netmask 255.255.255.0 alias >>>>> $ sudo ifconfig lo0 127.0.2.1 netmask 255.255.255.0 alias >>>>> $ sudo ifconfig lo0 127.0.3.1 netmask 255.255.255.0 alias >>>>> >>>>> 2. Create Kerberos principals. Example below is for Heimdal, MIT will >>> be >>>>> similar: >>>>> >>>>> $ sudo kadmin -l >>>>>> add --random-key zookeeper >>>>>> add --random-key zookeeper/127.0.1.1 >>>>>> add --random-key zookeeper/127.0.2.1 >>>>>> add --random-key zookeeper/127.0.3.1 >>>>>> ext_keytab --keytab /var/tmp/test/zookeeper.keytab zookeeper >>>>>> ext_keytab --keytab /var/tmp/test/zookeeper.keytab zookeeper/ >>> 127.0.1.1 >>>>>> ext_keytab --keytab /var/tmp/test/zookeeper.keytab zookeeper/ >>> 127.0.2.1 >>>>>> ext_keytab --keytab /var/tmp/test/zookeeper.keytab zookeeper/ >>> 127.0.3.1 >>>>>> exit >>>>> >>>>> 3. Patch ZK with 1045, build a tarball, then unpack it into three >>> install >>>>> directories. Mine are /var/tmp/test/{1,2,3}. >>>>> >>>>> 4. Initialize 'myid' files: >>>>> >>>>> $ mkdir /var/tmp/test/1/data >>>>> $ echo 1 > /var/tmp/test/1/data/myid >>>>> $ mkdir /var/tmp/test/2/data >>>>> $ echo 2 > /var/tmp/test/2/data/myid >>>>> $ mkdir /var/tmp/test/3/data >>>>> $ echo 3 > /var/tmp/test/3/data/myid >>>>> >>>>> 5. Create configuration files for each instance. Below are examples >>> for >>>>> instance 1. You will need to make substitutions for your Kerberos >>> realm >>>>> (mine is LOCAL), and for instances 2 and 3 change the path to the JAAS >>>>> configuration file, path to data directory, and bind address for >>>>> clientPortAddress as appropriate. >>>>> >>>>> conf/java.env: >>>>> >>>>> export >>>>> JVMFLAGS="-Djava.security.auth.login.config=/var/tmp/ >>>> test/1/conf/jaas.conf >>>>> -Djavax.security.auth.useSubjectCredsOnly=false" >>>>> >>>>> conf/jaas.conf: >>>>> >>>>> QuorumServer { >>>>> com.sun.security.auth.module.Krb5LoginModule required >>>>> useKeyTab=true >>>>> keyTab="/var/tmp/test/zookeeper.keytab" >>>>> storeKey=true >>>>> useTicketCache=false >>>>> debug=false >>>>> principal="zookeeper/127.0.1.1@LOCAL"; >>>>> }; >>>>> >>>>> QuorumLearner { >>>>> com.sun.security.auth.module.Krb5LoginModule required >>>>> useKeyTab=true >>>>> keyTab="/var/tmp/test/zookeeper.keytab" >>>>> storeKey=true >>>>> useTicketCache=false >>>>> debug=false >>>>> principal="zookeeper/127.0.1.1@LOCAL"; >>>>> }; >>>>> >>>>> conf/zoo.cfg: >>>>> >>>>> tickTime=2000 >>>>> initLimit=10 >>>>> syncLimit=5 >>>>> dataDir=/var/tmp/test/zk/1/data >>>>> clientPort=2181 >>>>> clientPortAddress=127.0.1.1 >>>>> >>>>> quorum.auth.enableSasl=true >>>>> quorum.auth.learnerRequireSasl=true >>>>> quorum.auth.serverRequireSasl=true >>>>> quorum.auth.learner.loginContext=QuorumLearner >>>>> quorum.auth.server.loginContext=QuorumServer >>>>> quorum.auth.kerberos.servicePrincipal=zookeeper/_HOST >>>>> >>>>> server.1=127.0.1.1:2888:3888 >>>>> server.2=127.0.2.1:2888:3888 >>>>> server.3=127.0.3.1:2888:3888 >>>>> >>>>> 5. Launch the three instances in the foreground in separate terminals. >>>>> Example for instance 1: >>>>> >>>>> $ cd /var/tmp/test/1 >>>>> $ bash ./bin/zkServer.sh start-foreground >>>>> >>>>> Having done all this, I can see successful authentication and >>> bootstrap >>>> of >>>>> a quorum. >>>>> >>>>> This example shares a keytab. No need to do that if you'd like to be >>>>> pedantic. Clone the keytab file into the separate conf directories and >>>>> update the jaas.conf files. >>>>> >>>>> I like how Hadoop programmatically builds the JAAS context from its >>>>> configuration such that the JAAS configuration file and definition of >>>>> system property pointing to same are not needed. Would be nice if ZK >>>> could >>>>> optionally do the same, that would be one fewer config file to get >>>>> precisely right. >>>>> >>>>> Any suggestions on some kind of hammer test to apply now ? >>>>> >>>>> >>>>> On Fri, Oct 21, 2016 at 7:34 AM, Flavio Junqueira <f...@apache.org> >>>> wrote: >>>>> >>>>>> Michael Han posted an update to the test plan to the jira and I >>> want to >>>>>> call the attention of the community to it. It is a big change that >>> we >>>>> need >>>>>> to be extra careful about because it is supposed to go to the 3.4 >>>> branch. >>>>>> It'd be great to have more folks in the community involved with the >>>>>> testing. If you have cycles and interest, please help with testing. >>>>>> >>>>>> -Flavio >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> >>>>> - Andy >>>>> >>>>> Problems worthy of attack prove their worth by hitting back. - Piet >>> Hein >>>>> (via Tom White) >>>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> >>> - Andy >>> >>> Problems worthy of attack prove their worth by hitting back. - Piet Hein >>> (via Tom White) >>> >> >>