> On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > core/src/main/java/org/apache/accumulo/core/client/security/tokens/KerberosToken.java, > > lines 71-79 > > <https://reviews.apache.org/r/29386/diff/4/?file=803145#file803145line71> > > > > Why is this unsupported? > > Josh Elser wrote: > Again, see earlier discussion. I have no idea what this is actually > supposed to destroy (we have zero documentation on the matter that I found) > and it's already been changed to be a noop. I am just as confident that a > noop is correct as an unsupported operation is correct (I have no confidence). > > As far as destroying a UGI, I haven't found any parallel to the > Destroyable interface. I'm not sure if something exists that we should be > calling.
It's a way for objects to remove their internal state (preferably by securely overwriting memory) so any credentials can be removed from memory, to give the user control over their credentials. It is expected to be called by the user. In the earlier implementation, setting the ugi to null would have been appropriate. In the latest version, you can nullify the principal. It's not terribly important, since the principal alone is not sensitive, but it would be helpful to have reasonable behavior when the user calls these methods to avoid things like "I called destroy, but it won't destroy!" or "My application verifies the token isn't destroyed before using it, but it seems to always be destroyed!". Even if it was a truly no-op, we could add an internal "destroyed" flag to give users reasonable behavior. Since we do have the principal, we can just make that null instead of adding a new flag, and use that to check the state of its destruction. Also, I think the other methods which assume it is not destroyed should throw IllegalStateException explicitly if it is, in fact, destroyed. But, I'm not even sure we do that in the other tokens, so it's probably fine to leave that behavior undefined. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > core/src/main/java/org/apache/accumulo/core/client/security/tokens/KerberosToken.java, > > lines 52-69 > > <https://reviews.apache.org/r/29386/diff/4/?file=803145#file803145line52> > > > > The no-arg constructor is used for Writable, and is used to serialize > > credentials to a file. This is useful for MapReduce. > > > > As is, this *should* work, as long as the user wishes to use the > > UserGroupInformation.getLoginUser(). However, that basically forces the > > MapReduce task to use the MapReduce task's own credentials, to talk to > > Accumulo, and not the user's. This could be a cumbersome pitfall. > > > > Is there a way to serialize the user's ugi, so that it can be > > de-serialized, falling back on the UserGroupInformation.getLoginUser() if > > the user's ugi cannot be deserialized? > > > > At the very least, the serialization should store *something* (magic > > bytes which refer to "nothing here"), so we can distinguish between that > > and future serialized options, if we add any later. > > Josh Elser wrote: > MapReduce is something I need to investigate and test. I have no idea how > token delegation works with MapReduce (if it's anything more than "use a > keytab"). If it's that, this approach should be fine. Otherwise, it'll be > problematic. > > I've also switched this from loginUser to currentUser (I think in the > most recent patch) as I think loginUser was incorrect. > > I'll add some magic bytes to the serialization. Saw the latest version with the magic bytes. Might be easier to use `private int ver = 1;` and `out.writeInt(ver);`. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > core/src/main/java/org/apache/accumulo/core/conf/Property.java, lines > > 165-167 > > <https://reviews.apache.org/r/29386/diff/4/?file=803146#file803146line165> > > > > I don't think we want to expose this. It's high risk. What is the > > reason and how is it related to this change? > > Josh Elser wrote: > Again, see the previous discussion on this subject. This is necessary to > actually perform an apples to apples comparison of the impact of Kerberos on > Accumulo. Comparing KRB/SASL with TThreadPoolServer against no KRB/SASL and > THsHaServer is an invalid benchmark to determine the overhead of KRB. > > Like I said earlier, `Experimental` is not really the appropriate > annotation here (Internal use would be more accurate), but it's what we have. > Do you have a recommendation on some other change in wording/annotation to > convey the intent? > > I'd like to not have to change the codebase any time I want to verify no > performance regressions in future versions (having to change code would > preclude any non-devs from running their own benchmarks too). My main concern is that I'm not entirely confident we're not exposing these to users in some way, still: see ACCUMULO-2460 and ACCUMULO-2401. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > core/src/main/java/org/apache/accumulo/core/rpc/UGIAssumingTransport.java, > > lines 61-64 > > <https://reviews.apache.org/r/29386/diff/4/?file=803151#file803151line61> > > > > This is what AssertionError is for. > > Josh Elser wrote: > No, they should throw RuntimeException. The comment is meant that those > exceptions weren't thrown from the doAs block. They should just wrap the > exceptions in a RuntimeException and let thrift do the correct thing. Ah, I misunderstood the message as "impossible to occur" when it now appears to be a "wasn't me" situation. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java, > > lines 285-293 > > <https://reviews.apache.org/r/29386/diff/4/?file=803157#file803157line285> > > > > It was discussed in the context of ACCUMULO-259 that the root user > > would be a built-in, password-based user, even if other auth mechanisms > > were available (like Linux root user). Some proposals were made to make > > this easier to work with and more intuitive for users, but the > > initialization of the root user should really just be the > > > > See ACCUMULO-1300 and related issues, for more details. > > > > What are the risks of making the root user rely on Kerberos? > > Josh Elser wrote: > Thanks for the background; I didn't remember this discussion. > > Hadoop does have a similar approach that we could adopt but I'm extremely > hesitant to recommend we do it (because I think it's some of the ugliest > configuration in Hadoop). Look up hadoop.security.auth_to_local: (first > result from google for me > http://hortonworks.com/blog/fine-tune-your-apache-hadoop-security-settings/). > Essentially, we could introduce this very convoluted user mapping into the > "root" user. Personally, I think this is much more confusing. > > I regret not being a part of the previous discussion, but I don't > understand why we should rely on always having a password based user. It > seems like forcing us into edge-case-city. Do you have more information on > this discussion? I didn't find anything on ACCUMULO-259 on it and I want to > make sure I'm up to speed. Comparing our "root" user is the Linux root user > is a bit of a fallacy in my opinion because they're not equivalent. In a > properly configured system, root should never be used by anyone but an > administrator to delegate permissions or perform one-time tasks (to avoid > permission delegation). > > In my opinion, avoid some "magical" user helps with the auditing and > authentication Accumulo uses as a whole. Each client that comes into Accumulo > is a user. They have a Kerberos identity and we treat them as the "Accumulo > user" based on that Kerberos identity. The internal "!SYSTEM" user is the > only other user; however it is still identified by a specific Kerberos > identity (the ones we know the servers use to log in). > > Also, this may benefit from non-reviewboard discussion, please feel free > to pop this over to the ML. As far as I know, all the conversation happened in the comments on ACCUMULO-259 and it's linked issues, as well as on the mailing list, but I don't have direct references, other than the issues I linked. The root user as compared to the Linux root user is analogous, not equivalent. I agree that a root user should never be used except to delegate and perform one time tasks. The problem is that, like the Linux root user, it is sometimes needed to do these tasks when other components of the system (such as the pluggable authentication service) are unavailable. The same permissions could be delegated to an admin in that service, so the built-in root would be even less frequently used, but it still might be needed. This is the same reasoning as setting a BIOS password, or Linux root user, or MySQL root user, or Hadoop SuperUser, or ZK's "super" user. The point may be moot, though, if the system is completely unusable if Kerberos is down (because the system token relies on Kerberos). Though... I can see a use case for restarting the system with Kerberos disabled to do maintenance and to have root available for that. As for the system user being a Kerberos identity, see my other concerns regarding that. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java, > > lines 62-63 > > <https://reviews.apache.org/r/29386/diff/4/?file=803163#file803163line62> > > > > What is the reason for making SystemCredentials able to use Kerberos? > > SystemCredentials are how the system identifies itself to itself. It's all > > internal. It shouldn't rely on external components, in my opinion. > > Josh Elser wrote: > The point is that the same identity that we use to authenticate clients > should be used to authenticate servers. In the same vein that the > SystemCredentials precludes rogue server processes from participating in the > instance, relying on a specific principal to identify "valid" servers for > this instance guarantees the same thing. > > Josh Elser wrote: > Going back through this, your comment bothers me still and I don't think > I did it justice as succinctly as I could the first time. Kerberos provides > *strong authentication* -- clients or servers use it. Just as we want to be > assured that clients are who they say they are, we want the same guarantee > for servers. We also *need* strong authentication for both to even talk to > HDFS, so it makes no sense to me to try to say that our servers shouldn't be > using kerberos. In short, I'm okay with this, assuming we can distinguish between the server component and a user using Kerberos on that same system (maybe a configuration item to define the system Kerberos principal [instance.kerberos.principal]? essentially, a less sensitive instance.secret.), and we retain all the sanity checks / hashing of the required common configuration / instance ID. I'm not arguing against the strong authentication or against using Kerberos for the servers. Just that all the goodness that the system credentials have right now needs to be checked also. We can do that by using the strongly authenticated transport, and just using the current SystemToken to verify the rest. The SystemToken, after all, is providing validation that it is a system component, with all the correct configuration to properly act as one, and not that it is who it says it is. I'd also like to have a plan moving forward with ACCUMULO-1300 (I don't think that plan would be very complicated... just a special authenticator for system credentials which works with and without Kerberos enabled, and does the proper validation checks that we have now). > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java, > > line 106 > > <https://reviews.apache.org/r/29386/diff/4/?file=803163#file803163line106> > > > > The SystemToken should be a separate type. it is not a password token. > > It is a token type that is exclusive to the system (it's even final, so it > > cannot be sub-class'd). It should not be swapped out with Kerberos tokens, > > or any other kind of token. > > > > It should also not be considered a password token. That just happens to > > be the closest analogy to the current implementation. It's really it's own > > special type. > > > > However, there is a proposal to make individual components > > authenticate, but I don't think this achieves that: ACCUMULO-1165 > > Josh Elser wrote: > bq. it is not a password token > > Really? It generates a secret and uses it to authenticate with a server. > That sounds like a password to me :). > > Seriously though, I respect that you have concerns here, but I don't have > the foggiest idea of what you think this should be changed to do. > > Kerberos gives each server a unique token (authenticated against the KDC) > via their keytab. We ensure rogue servers cannot participate in the instance > by requiring the primary in the principal ('accumulo' in > '`accumulo/_h...@example.com`'). SASL is also ensuring that an RPC cannot > even establish a connection to Accumulo servers. What piece of the puzzle are > we missing and how do you think this should operate? I don't think it needs to be renamed. It's a misleading rename. It's only a "password" in the same sense that all authentication tokens are essentially passwords, but not in the narrow scope that we think of passwords that people remember and use to log in. It's not even human-readable, except for the fact that we encode the hash with a printable character set. I think it'd be better to make the existing SystemToken be made Kerberos-aware, rather than create two separate token types which are swapped out. I think that achieves the existing goals, as well as the new Kerberos features. This also makes it easier to move forward with ACCUMULO-1300, solidifying the idea that the system token is checked by the system authenticator. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java, > > lines 153-168 > > <https://reviews.apache.org/r/29386/diff/4/?file=803163#file803163line153> > > > > This should not be here. Using Kerberos for the SystemToken removes an > > important check against rogue servers from other instances communicating > > with the current instance. > > > > It also removes all the other mandatory checks in the SystemToken which > > protect against incompatible variations in the "instance.*" properties, > > which are encapsulated in the SystemToken's hash. > > Josh Elser wrote: > bq. from other instances communicating with the current instance > > Not true. It, along with the KerberosAuthenticator/SecurityOperation, > guarantees that only servers with a primary component of their principal > matching the `general.kerberos.principal` value in accumulo-site.xml can > communicate with the instance. One would assume that separate realms or > primaries are used for Accumulo instances sharing the same KDC, but we could > try to make this stronger by (somehow) incorporating the rest of the > `instance.` properties. I don't know how to approach this, however, and am > open to suggestions. Making the existing SystemToken Kerberos-aware, and doing the validation of the existing hash after authenticating with Kerberos would work. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > server/base/src/main/java/org/apache/accumulo/server/security/handler/KerberosAuthenticator.java, > > line 41 > > <https://reviews.apache.org/r/29386/diff/4/?file=803164#file803164line41> > > > > I don't think this should be so tightly coupled with the > > ZKAuthenticator. It doesn't seem that this coupling is necessary to provide > > authentication functionality. > > > > Have a different implementation of an Authenticator that hijacks the > > data storage of another implementation, could be quite confusing to > > administrators, especially if they need to swap out the implementation. > > > > See ACCUMULO-1300 and related issues for other options. > > Josh Elser wrote: > I understand the intentions for ACCUMULO-1300; however, that's not > implemented. Being able to leverage the existing ZKAuthorizor was wonderful > so I really don't want to move away from how this fundamentally works. > > Shouldn't the Authenticator and Authorizor be fixed per instance > (allowing reset via `accumulo init --reset-security` or w/e)? What do you > actually want changed aside from documentation to make it clear to > administrators (I haven't written any documentation yet). So, I pointed out in the conversation around ACCUMULO-259, that I would prefer a pluggable security module that integrated all the security-related functions, because they are so dependent on each other. However, they were implemented as 3 separately configurable pluggable components. I would still like to see them merged (which doesn't preclude making one from modular components themselves). For now, I'm not really sure what it means for somebody to "create a user" when the authenticator already validates them. That's why it's confusing. Are we essentially making ZKAuthenticator Kerberos-aware, or are we providing a separate Kerberos Authenticator? That's really what it boils down to for me. It seems like we're doing a hybrid... but I think we should solidify on one or the other. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > server/base/src/main/java/org/apache/accumulo/server/security/handler/KerberosAuthenticator.java, > > line 46 > > <https://reviews.apache.org/r/29386/diff/4/?file=803164#file803164line46> > > > > Why is this seed fixed? > > Josh Elser wrote: > To keep using ZKAuthenticator as a "delegate", I need to put some > password into ZK. I don't think it's required that these random strings > actually be secure, it's mostly intended as obfuscation. Thoughts? If it's not intended to be secure, why use SecureRandom in the first place? And, because ZK is being used as a delegate, and because these are being used in place of a password, I think they should be secure. If somebody changed from the KerberosAuthenticator back to the default (which is easy to do, if one accidentally clobbers the configuration file when upgrading a system), non-secure passwords could actually be used to authenticate. If you really want to store something which cannot be used to authenticate, you need to replace it with something that cannot parse as a hashed password. This is what happens in /etc/shadow when you disable an account. In any case, I still don't see the need to do anything with the seed. SecureRandom does special stuff with the seed, and I'm not sure it is needed to set it. setSeed doesn't even behave the same way as regular Random does with a fixed seed. It doesn't seem "wrong". It just seems like unnecessary code. > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java, lines > > 176-180 > > <https://reviews.apache.org/r/29386/diff/4/?file=803175#file803175line176> > > > > Descriptions are not consistent with capitalization. ("Use" vs. "use") > > Josh Elser wrote: > Obligatory, it bothers me that they're all lowercase :) Make them all upper-case :) > On Dec. 30, 2014, 5:46 p.m., Christopher Tubbs wrote: > > shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java, line 210 > > <https://reviews.apache.org/r/29386/diff/4/?file=803175#file803175line210> > > > > Why is username the "short" user name? Is that unique in Kerberos? If > > not, the long version should be used everywhere instead. Otherwise, one > > user can appear to be another in logs, etc. > > > > If "getShortUserName" is not unique, it should avoided everywhere. > > Josh Elser wrote: > Check out: > http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-user/What-is-a-Kerberos-Principal_003f.html > > Kerberos principals are of the form: primary/instance@realm. Kerberos > principals are typically categorized as users and services. A user is not > qualified to a single instance (a host) and represent authentication across > the realm. For example, els...@example.com means that I can "roam". > Conversely, a service is typically "fixed" to a specific host. For example, > accumulo/node1.example....@example.com means that there is a process, logged > in as 'accumulo' on the host 'node1.example.com'. That service can't be run > on any other host. Now, an important note if someone actually creates a > principal "accum...@example.com" this is unique with respect to any other > "accumulo/`host`@EXAMPLE.COM" principal. I'm not sure if we need to do > anything else other than convention of kerberos principals, or if we should > be including the instance in "our" username when present. > > This kind of ties back into the SystemCredentials discussion again. Okay, so a smart configuration would make shortnames unique. However, UserGroupInformation returns only the `primary` for the short name. This means that user names will have to be unique across realms and instances. Right now, you are storing permissions using the short name. So, any user with the same primary, will be able to masquerade as any other user with the same primary from a different instance and/or realm, and be able to user their permissions and authorizations. That's the problem with the shortname here. That's very unexpected. - Christopher ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/29386/#review66382 ----------------------------------------------------------- On Dec. 31, 2014, 4:24 p.m., Josh Elser wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/29386/ > ----------------------------------------------------------- > > (Updated Dec. 31, 2014, 4:24 p.m.) > > > Review request for accumulo. > > > Bugs: ACCUMULO-2815 > https://issues.apache.org/jira/browse/ACCUMULO-2815 > > > Repository: accumulo > > > Description > ------- > > ACCUMULO-2815 Initial support for Kerberos client authentication. > > Leverage SASL transport provided by Thrift which can speak GSSAPI, which > Kerberos implements. Introduced... > > * An Accumulo KerberosToken which is an AuthenticationToken to validate users. > * Custom thrift processor and invocation handler to ensure server RPCs have a > valid KRB identity and Accumulo authentication. > * A KerberosAuthenticator which extends ZKAuthenticator to support Kerberos > identities seamlessly. > * New ClientConf variables to use SASL transport and pass Kerberos server > principal > * Updated ClientOpts and Shell opts to transparently use a KerberosToken when > SASL is enabled (no extra client work). > > I believe this is the "bare minimum" for Kerberos support. They are also > grossly lacking in unit and integration tests. I believe that I might have > somehow broken the client address string in the server (I saw log messages > with client: null, but I'm not sure if it's due to these changes or not). A > necessary limitation in the Thrift server used is that, like the SSL > transport, the SASL transport cannot presently be used with the > TFramedTransport, which means none of the [half]async thrift servers will > function with this -- we're stuck with the TThreadPoolServer. > > Performed some contrived benchmarks on my laptop (while still using it > myself) to get at big-picture view of the performance impact against "normal" > operation and Kerberos alone. Each "run" was the duration to ingest 100M > records using continuous-ingest, timed with `time`, using 'real'. > > THsHaServer (our default), 6 runs: > > Avg: 10m7.273s (607.273s) > Min: 9m43.395s > Max: 10m52.715s > > TThreadPoolServer (no SASL), 5 runs: > > Avg: 11m16.254s (676.254s) > Min: 10m30.987s > Max: 12m24.192s > > TThreadPoolServer+SASL/GSSAPI (these changes), 6 runs: > > Avg: 13m17.187s (797.187s) > Min: 10m52.997s > Max: 16m0.975s > > The general takeway is that there's about 15% performance degredation in its > initial state which is in the realm of what I expected (~10%). > > > Diffs > ----- > > core/src/main/java/org/apache/accumulo/core/cli/ClientOpts.java f6ea934 > core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java > 6fe61a5 > core/src/main/java/org/apache/accumulo/core/client/impl/ClientContext.java > e75bec6 > core/src/main/java/org/apache/accumulo/core/client/impl/ConnectorImpl.java > f481cc3 > > core/src/main/java/org/apache/accumulo/core/client/impl/ThriftTransportKey.java > 6dc846f > > core/src/main/java/org/apache/accumulo/core/client/impl/ThriftTransportPool.java > 5da803b > > core/src/main/java/org/apache/accumulo/core/client/security/tokens/KerberosToken.java > PRE-CREATION > core/src/main/java/org/apache/accumulo/core/conf/Property.java e054a5f > core/src/main/java/org/apache/accumulo/core/rpc/FilterTransport.java > PRE-CREATION > core/src/main/java/org/apache/accumulo/core/rpc/SaslConnectionParams.java > PRE-CREATION > core/src/main/java/org/apache/accumulo/core/rpc/TTimeoutTransport.java > 6eace77 > core/src/main/java/org/apache/accumulo/core/rpc/ThriftUtil.java 09bd6c4 > core/src/main/java/org/apache/accumulo/core/rpc/UGIAssumingTransport.java > PRE-CREATION > > core/src/main/java/org/apache/accumulo/core/rpc/UGIAssumingTransportFactory.java > PRE-CREATION > core/src/main/java/org/apache/accumulo/core/security/Credentials.java > 525a958 > core/src/test/java/org/apache/accumulo/core/cli/TestClientOpts.java ff49bc0 > > core/src/test/java/org/apache/accumulo/core/client/ClientConfigurationTest.java > PRE-CREATION > > core/src/test/java/org/apache/accumulo/core/conf/ClientConfigurationTest.java > 40be70f > > core/src/test/java/org/apache/accumulo/core/rpc/SaslConnectionParamsTest.java > PRE-CREATION > proxy/src/main/java/org/apache/accumulo/proxy/Proxy.java 4b048eb > > server/base/src/main/java/org/apache/accumulo/server/AccumuloServerContext.java > 09ae4f4 > server/base/src/main/java/org/apache/accumulo/server/init/Initialize.java > 046cfb5 > > server/base/src/main/java/org/apache/accumulo/server/rpc/TCredentialsUpdatingInvocationHandler.java > PRE-CREATION > > server/base/src/main/java/org/apache/accumulo/server/rpc/TCredentialsUpdatingWrapper.java > PRE-CREATION > server/base/src/main/java/org/apache/accumulo/server/rpc/TServerUtils.java > 641c0bf > > server/base/src/main/java/org/apache/accumulo/server/rpc/ThriftServerType.java > PRE-CREATION > > server/base/src/main/java/org/apache/accumulo/server/security/SecurityOperation.java > 5e81018 > > server/base/src/main/java/org/apache/accumulo/server/security/SecurityUtil.java > 29e4939 > > server/base/src/main/java/org/apache/accumulo/server/security/SystemCredentials.java > a59d57c > > server/base/src/main/java/org/apache/accumulo/server/security/handler/KerberosAuthenticator.java > PRE-CREATION > > server/base/src/main/java/org/apache/accumulo/server/thrift/UGIAssumingProcessor.java > PRE-CREATION > > server/base/src/test/java/org/apache/accumulo/server/AccumuloServerContextTest.java > PRE-CREATION > > server/base/src/test/java/org/apache/accumulo/server/rpc/TCredentialsUpdatingInvocationHandlerTest.java > PRE-CREATION > > server/base/src/test/java/org/apache/accumulo/server/security/SystemCredentialsTest.java > 4202a7e > server/gc/src/main/java/org/apache/accumulo/gc/SimpleGarbageCollector.java > 93a9a49 > > server/gc/src/test/java/org/apache/accumulo/gc/GarbageCollectWriteAheadLogsTest.java > f98721f > > server/gc/src/test/java/org/apache/accumulo/gc/SimpleGarbageCollectorTest.java > 99558b8 > > server/gc/src/test/java/org/apache/accumulo/gc/replication/CloseWriteAheadLogReferencesTest.java > cad1e01 > server/master/src/main/java/org/apache/accumulo/master/Master.java 12195fa > server/tracer/src/main/java/org/apache/accumulo/tracer/TraceServer.java > 7e33300 > server/tserver/src/main/java/org/apache/accumulo/tserver/TabletServer.java > d5c1d2f > shell/src/main/java/org/apache/accumulo/shell/Shell.java 58308ff > shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java 8167ef8 > shell/src/test/java/org/apache/accumulo/shell/ShellConfigTest.java 0e72c8c > shell/src/test/java/org/apache/accumulo/shell/ShellOptionsJCTest.java > PRE-CREATION > test/src/main/java/org/apache/accumulo/test/functional/ZombieTServer.java > eb84533 > > test/src/main/java/org/apache/accumulo/test/performance/thrift/NullTserver.java > 2ebc2e3 > > test/src/test/java/org/apache/accumulo/server/security/SystemCredentialsIT.java > fb71f5f > > Diff: https://reviews.apache.org/r/29386/diff/ > > > Testing > ------- > > Ensure existing unit tests still function. Accumulo is functional and ran > continuous ingest multiple times using a client with only a Kerberos identity > (no user/password provided). Used MIT Kerberos with Apache Hadoop 2.6.0 and > Apache ZooKeeper 3.4.5. > > > Thanks, > > Josh Elser > >
