I like your second suggestion - let's cut an RC and give everyone the time
you are suggesting (2 weeks). That way folks can test and/or vote over the
period, rather than waiting the two weeks then starting the vote mechanics.
I know there are some people interested in getting access to 3.5.3-alpha
asap. Two birds.
Patrick
On Tue, Nov 29, 2016 at 3:11 PM, Flavio Junqueira <f...@apache.org> wrote:
> 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)
> >>>
> >>
> >>
>
>
