Member since
09-11-2015
115
Posts
126
Kudos Received
15
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
3037 | 08-15-2016 05:48 PM | |
2851 | 05-31-2016 06:19 PM | |
2389 | 05-11-2016 03:10 PM | |
1850 | 05-10-2016 07:06 PM | |
4736 | 05-02-2016 06:25 PM |
04-04-2017
04:26 PM
The second link no longer works. It would be nice to have a comprehensive comparison, rather than "jupyter is good for running python locally, zeppelin is better for cluster workloads"
... View more
03-10-2017
06:11 AM
This is very helpful, thank you. Can you please advise on where to find the Jetty logs, in case of issues with the web application itself?
... View more
08-15-2016
05:48 PM
There could be a problem with the certificate itself. I recommend regenerating it and trying again. You can follow instructions in the Apache Knox Users Guide to generate a self-signed certificate: http://knox.apache.org/books/knox-0-6-0/user-guide.html#Generating+a+self-signed+cert+for+use+in+testing+or+development+environments If you want to use a more legitimate certificate you can generate and sign it yourself with OpenSSL or from a CA, and follow the steps in the next section of the guide, Using a CA Signed Key Pair.
... View more
08-12-2016
05:03 PM
Can you provide more details about how you're attempting to connect, and with which client? If you're using curl, specify the exact command (masking the user password if you want), and the exact version of curl + OS
... View more
07-11-2016
10:17 PM
The only way to reliably accomplish this is to prevent users from logging into cluster nodes at all, and force them to use beeline to access HS2 in HTTP mode through Knox. Every solution recommending changes to hive-env.sh or hive.distro can be overridden by using a modified copy of those files. Those files could even be copied from elsewhere, because this is all open source.
... View more
06-13-2016
06:29 PM
Running each topology on its own Gateway instance is fine, but it's not necessary. You can use a single Knox Gateway instance and simply create a separate topology per-AD. Say you have 2 topologies, ad1 and ad2, then you can connect using: https://knox-host:8443/gateway/ad1/<service>/. https://knox-host:8443/gateway/ad2/<service>/.
... View more
06-10-2016
06:18 PM
2 Kudos
This feature is tracked in YARN-2477 (DockerContainerExecutor must support secure mode). There is currently no fix version specified. Docker container support on YARN is still very new, so you might want to follow the umbrella JIRA, (YARN-2466) to gain an idea of when additional features might become available.
... View more
06-08-2016
06:19 PM
@Tim Veil you might find this post helpful as a reference, or to integrate into your project: https://community.hortonworks.com/articles/29203/automated-kerberos-installation-and-configuration.html
... View more
06-01-2016
03:04 PM
1 Kudo
Sagar's answer is the best solution if both clusters will use the same AD. If each cluster has its own AD with unique users and groups, then you should clarify what you are hoping to gain by duplicating the policies. Keeping in mind that you'll need to sync them on an ongoing basis, it seems like "updating" every policy for a new set of users/groups would be more work than manually adding the policies on each cluster.
... View more
06-01-2016
02:07 PM
It sounds like there are two conflicting goals you might want to achieve. Is the intention to migrate cluster-B/2 to use the same AD as cluster-A/1? Or do all users have accounts in both ADs, and you want to translate the policies from A to B but keep them on different ADs?
... View more