About ewalk

ewalk · ‎07-26-2016

@ARUN Cloudbreak is the tool that will allow you to automate this using Ambari Blueprint.

ewalk · ‎07-05-2016

That sounds right given the error message.

ewalk · ‎07-01-2016

LDAP 49 errors can mean a lot of different things. Can you please check the logs from the LDAP server for the specific error cause? This is very likely a bad password error... Atlassian has a good explanation of the different error codes: https://confluence.atlassian.com/kb/common-user-management-errors-820119309.html

ewalk · ‎06-23-2016

To explain why you use different commands for the two nodes: The idea here is that you don't want both nodes to attempt the rollback and risk becoming inconsistent. In a perfect world you could probably do the rollback on both, but the world isn't perfect. The best way to guarantee consistency is to have one node do the rollback and then rebootstrap the second node to the first (i.e. overwrite node 2's state information with that from the rolled back node 1).

ewalk · ‎06-21-2016

AD is most definitely the easiest answer, unless you're morally opposed to it ;). You get integrated LDAP and KRB with nice user management tools. IPA does have some nice ootb features, though, around self service, etc.

ewalk · ‎06-21-2016

I generally recommend letting DNS handle this. The latest versions of the KRB client will default to resolving the KDC from SRV records in the DNS for the realm. This should be configured by default if you use Microsoft Active Directory (or AWS Simple AD). If you want it explicit in your krb5.conf file, you can use DNS round robin with the A/AAA/CNAME and reference that name in krb5.conf. Further, you could have multiple "kdc" entries for a realm in krb5.conf and a master_kdc entry which is only used when there are certain kinds of issues. You can always manage the krb5.conf from Ambari inside the Kerberos component configs.

ewalk · ‎06-20-2016

@Shishir Saxena In approach a, lack of involvement from enterprise security teams is not a positive thing. When dealing with a large enterprise, security is paramount and we should never be recommending that HDP administrators be permitted to manage authentication systems. Separation of duties is a core security principle and should not be taken lightly.

ewalk · ‎06-20-2016

For a general enterprise scenario I'd recommend approaches b and c. Depending on the security administrators, they will agree to one of these. In general it is preferable to reduce the number of sources of identity within an organization to allow for easily managed, secure control. I would very strongly advise against the stand-alone KDC approach in any real production environment.

ewalk · ‎05-11-2016

@Chris McGuire, that is probably the case, I'm not very familiar with the way spark is configured. I do know that, generally speaking, unless you explicitly say insert or use hive streaming you don't have deltas and don't need to worry about compaction. The partition append merging is a whole different story...

ewalk · ‎05-11-2016

@mbalakrishnan, do you think it might be missing it because they are originating from spark, not map, mapred or tez?

Online	Offline
Last Visited	‎09-06-2016 06:29 PM

Member Since	‎12-08-2015 06:44 PM
Last Visited	‎09-06-2016 06:29 PM
Posts	34
Kudos received	19

Cloudera Community

Cloudera Community

Re: HDP on AWS

Re: Kerberos KDC secondary

Re: Hive compactions on External table

Re: HDP on AWS

Re: issue with openldap/kerberos

Re: issue with openldap/kerberos

Re: What's the difference of -bootstrapstandby and...

Re: Looking for an automated integration of HDP/Am...

Re: Kerberos KDC secondary

Re: Choosing Kerberos approach for Hadoop cluster ...

Re: Keberos Implementation Approach: is it recomme...

Re: Hive compactions on External table

Re: Hive compactions on External table