Shoot. Make that 3.4.10. Urg.
Patrick
On Mon, Dec 5, 2016 at 3:03 PM, Patrick Hunt <ph...@apache.org> wrote:
> 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)
>> >>>
>> >>
>> >>
>>
>>
>
