Member since
04-22-2014
1218
Posts
341
Kudos Received
157
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
21162 | 03-03-2020 08:12 AM | |
12072 | 02-28-2020 10:43 AM | |
3509 | 12-16-2019 12:59 PM | |
3025 | 11-12-2019 03:28 PM | |
4831 | 11-01-2019 09:01 AM |
09-17-2018
04:22 PM
@Tomas79, That error isn't really an error I think. Since there is an HTTP 404 response, there is no use in doing mutual auth (kerberos). Can you take some scren shots of the failures or show how you know there are failures? Also, please include any logging (even INFO level) from the time when the error occurs (/var/log/hue/runcpserver.log) Cheers!
... View more
09-17-2018
04:20 PM
@bellvirus, Please share: - your your LDAP configuration - your runcpserver.log file that shows activity when you try to authenticate - output from the Test LDAP configuration That should get us started.
... View more
09-17-2018
04:15 PM
@snm1523, Since you are using install path A, the installation will attempt to install cloudera-manager-server-db-2 which requires postgres server. Note that you need postgres >= 8.4 (not equal to) yum will attempt to download and install a postgres server, but in your case it cannot find any. Can you install posgresql-server manually with "yum?" This thread may have some relevant info too: https://community.cloudera.com/t5/Cloudera-Manager-Installation/Not-able-to-install-cloudera-manager-databases/td-p/22747
... View more
09-17-2018
03:58 PM
@pollard, Thanks for inspiring me to use docker on my Mac for the first time :-). I ran the following to start things up: docker run --hostname=quickstart.cloudera --privileged=true -t -i -p 8888:8888 -p 80:80 -p 7180:7180 6d2b3c820712 /usr/bin/docker-quickstart Oddly, the first time I started without using "-p" options and found that I got connection refused messages when trying to use hdfs dfs -ls / in the container shell. The second time I ran it with the command above, I could not run "hdfs" commands without error and get my file listings back. Also, I can run Hive and Impala queries from Hue. I didn't enable Cloudera Manager. Honestly, all I did was - docker run - docker stop - docker run... I'm suspicious of the network in your container since it it seems (like in my first try) that process in the container cannot connect to "quickstart.cloudera"
... View more
09-17-2018
12:58 PM
@desind, The stack shows that whatever search was generated by spring framework didn't return any matches. You can get more information by enabling TRACE level logging for the springframework classes involved. (1) Edit /etc/cloudera-scm-server/log4j.properties Add the following lines: log4j.logger.org.springframework.ldap=TRACE log4j.logger.org.springframework.security.ldap=TRACE (2) Restart Cloudera Manager: # service cloudera-scm-server restart ------------------- In general, when encountering the problems you describe, I recommend using the "LDAP" External Authentication Type so you have better control over the search filters. I still note that it appears your LDAP User Search Filter is not going to return what you expect since the syntax requires "DN" rather than a username. The {0} will be replaced with your username, so I don't believe the search will return any users. The user search filter is only used if you are using the "LDAP" External Authentication so you won't see problems with it unless you do use LDAP (vs Active Directory). Please feel free to share the debug output from a failed login as it should shed light on the problem. Your UPN does look correct, so it is hard to say why the search is failing to return a result.
... View more
09-17-2018
11:24 AM
@desind, Hi... A couple of things I noticed: (1) Based on the stack trace, you have configured Cloudera Manager's External Authentication with External Authentication Type: Active Directory This means that the username specified in the login page will be concatenated with the Active Directory Domain value to form a userPrincipalName value. For example, if I use a login name of "user1" and my Active Directory Domain is "example.com" the result will be a search for an object that has userPrincipalName=user1@example.com The stack trace shows that the query did not find any such match for that search. If your users' userPrincipalName values do not contain the string they nornally use to log in as (commonly the sAMAccountName) then you will need to use the LDAP value for External Authentication Type in the Cloudera Manager configuration. (2) Based on your screen shot, it appears your LDAP User Search Filter may not be configured in a way that will return any search results. You have: (&(objectclass=user)(memberof:1.2.840.113556.1.4.1941:={0})) I don't think that search filter is doing what you want it to do (though I think the issue I mentioned above is causing the direct failure you are seeing now. When using the LDAP Matching Rule in chain, you would need the {0} to be a group Distinguished Name as mentioned on the following page: https://docs.microsoft.com/en-us/windows/desktop/adsi/search-filter-syntax For example, this may be more in line with what you were intending: (&(objectclass=user)(sAMAccountName={0})(memberof:1.2.840.113556.1.4.1941:=CN=hadoop_group,DC=Example,DC=COM)) In the above, only users who are a member of "hadoop_group" or any of the nested groups can auth.
... View more
09-17-2018
10:25 AM
@Paulina, When you say that you are using LDAP everywhere, does that include LDAP group mapping for HDFS. I wasn't clear on that. The reason I ask is that the issue described has nothing to do with Hue at all; rather, this is a matter of Hue attempting to map access based on a defined role that is mapped to a group that includes one or more users. (1) beeline attempts to create a table as user maslova (2) HiveServer2 verifies this action is allowed by evaluating the desired action via Sentry (3) Sentry will attempt to see if maslova is a member of an OS group that is a member of a role that is granted the necessary access. When you ran id -Gn we see the result was: maslova maslova wheel However, you granted access to the "admins" role, but maslova is not a member of "admins" group that is mapped to the admins role. RECOMMENDATION: Make sure that you have set maslova to be a member of a group that is mapped to the role granted all access to "server1". Also, verify your HDFS level group mapping by checking what value is set in your HDFS Hadoop User Group Mapping Implementation configuration. Sentry will use the OS mapping by default (ShellBasedUnixGroupsMapping).
... View more
09-17-2018
10:00 AM
@pollard, Would would assume that this would work out of the box, but it sounds like there are some problems starting certain services do to connectivity issues. I'm having trouble figuring out how Cloudera Manager would show services in good health if services cannot connect to HDFS. Can you share a screen shot of your Cloudera Manager Home screen? Is HDFS running and in good health. Can you run simple HDFS commands? If you restart the cluster, does it seem to work fine? Hue is a higher level service, so I sould start by taking a look at HDFS and make sure it is accessible. I haven't played with the Docker version, so I hope those who have may have some feedback here, too.
... View more
09-17-2018
09:54 AM
1 Kudo
@mSparamonti, There is no alert emitted specifically for transition to "good" health, but you can have an alert emitted when a transition is made from alerting to non-alerting status is made. Clusters --> Cloudera Management Service --> Configuration Search for: Alert On Transitions Out of Alerting Health By default the setting is off. You can check the box and save to turn this feature on to see if it meets your needs.
... View more
09-17-2018
09:40 AM
1 Kudo
@sid2707, This page has a pretty good summary of how this works: https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/RackAwareness.html
... View more