Member since
04-22-2014
1218
Posts
341
Kudos Received
157
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
22537 | 03-03-2020 08:12 AM | |
13034 | 02-28-2020 10:43 AM | |
3757 | 12-16-2019 12:59 PM | |
3342 | 11-12-2019 03:28 PM | |
5129 | 11-01-2019 09:01 AM |
07-22-2019
02:21 PM
@mmmunafo, Yay, I'm not going crazy... just thought this was a logout issue. based on what I've seen, then, I think we may be able to work with this. Perhaps we can do something special in unset KRB5CCNAME in pam.py... I'll take a quick peek As for the cron job, yeah, that will work. I get it now. Crafty!
... View more
07-22-2019
02:15 PM
@Roroka, We need to make sure that your Cloudera Manager configuration matches with the agent configuration. Based on the below configuration, your agent is configured to use TLS but will perfom no validation of the Cloudera Manager certificate. In order for a heartbeat to work, then, you would need to have this configured in Cloudera Manager: You will also need to have configured Cloudera Manager to listen via TLS. The 'sslv3 alert bad certificate' message indicates that CM did not receive the certificate it expected from the agent (for authentication). I believe this indicates you have Use TLS Authentication of Agents to Server enabled in CM so CM expects agents will present a certificate. If you are just installing, though, I would not expect TLS to be involved at all. Did you enable "Auto-TLS" during installation. If so, do you have Cloudera Express? We need more of an understanding of the steps you used to install and also the current configuration of CM. Also, we need to know what your goal is at this stage and if you were trying to enable TLS in some way... Thanks!
... View more
07-22-2019
12:58 PM
1 Kudo
@Tomas79, As @mender mentioned, the documentation includes location of the files. Here is a link to the specific information: https://www.cloudera.com/documentation/enterprise/latest/topics/auto_tls.html#auto_tls_agent_files
... View more
07-22-2019
12:44 PM
@mmmunafo Your Hue credentials cache needs to be updated by the Hue kt_renewer, so I don't think your solution will work past the time when the ticket expires. Without a way to update the cache, eventually, the TGT will expire and Hue won't be able to communicate with any other services. I think the workaround I proposed (decreasing the interval for renewal) will work best and give you the most service uptime without restarting. What really surprises me about all of this is that logging out of Hue is actually triggering anything related to PAM; there should be no need to let the PAM module know of the Hue session terminating. I checked, and the simple PAM backend does not have a "logout" function, so if a user logs out of Hue and the accounts/logout call is made, this skips any interaction with the backend. Essentially, PAM and the OS should have no knowledge of a Hue logout. the "pam.py" package also has no logout hooks. the "pam.py" file also doesn't load any modules, really. Rather, it makes calls to pam and returns success if login via pam is successful. After that, Hue and supporting code should have no session/state information relevant to pam. Everything is at the Hue / Django session level after that. The more I think about this, the less it seems possible that initiating a log out from Hue could trigger any calls to pam modules. I think we must be missing something in terms of understanding how the problem occurs. Not sure what though.
... View more
07-22-2019
09:35 AM
@dennisli, If you are using parcels, you need to start the server from Cloudera Manager's UI. In fact if you are using Cloudera Manager to manage your cluster, you need to use CM to start your services.
... View more
07-22-2019
09:10 AM
@HadoopHelp, Assuming you want to delete a directory that has no contents, you can use: hdfs dfs -rmdir /tmp/emptydir
... View more
07-19-2019
04:52 PM
@mmmunafo, Tough situation indeed. I don't think it is possible to unset KRB5CCNAME like that as it is an environment variable for all of Hue. If you unset it one place, it would impact the entire server. There may be something elegant here, but I'm not seeing it. I think we may be in for quite an aggrivating adventure trying to get that to work. Perhaps we can look to mitigation instead so that we can make sure the Hue kt_renwer runs kinit a lot. Assuming users are not logging out of Hue a great deal, this may be enough to work around the issue. Even if the file is deleted, it will be added back pretty quickly. In CM, go to the Hue configuration and search for Hue Keytab Renewal Interval - Set it to 10 seconds. - Save and restart Hue Service You could even really set it to 5 or less if need be as the kinit is not much load on the KDC at all. Happy weekend... hope the workaround makes it a better one 🙂
... View more
07-19-2019
04:23 PM
1 Kudo
@Kevin_Z, The trick is knowing which structure stores the values. In the case of mapreduce.job.split.metainfo.maxsize you can find it via the REST api like this: (assuming your cluster was named cluster and your YARN service wasnamed yarn) http://cm_host:7180/api/v32/clusters/cluster/services/yarn/roleConfigGroups/yarn-GATEWAY-BASE/config?view=full You can see the configuration: { "name" : "mapreduce_jobtracker_split_metainfo_maxsize", "required" : false, "default" : "10000000", "displayName" : "JobTracker MetaInfo Maxsize", "description" : "The maximum permissible size of the split metainfo file. The JobTracker won't attempt to read split metainfo files bigger than the configured value. No limits if set to -1.", "relatedName" : "mapreduce.job.split.metainfo.maxsize", "sensitive" : false, "validationState" : "OK" }, See the comparable command for the REST call above: https://archive.cloudera.com/cm6/6.2.0/generic/jar/cm_api/swagger-html-sdk-docs/python/docs/RoleConfigGroupsResourceApi.html#read_config Cloudera Manager the following: Service Configuration (configuration items apply to every role for that service) Role Configuration Groups (Each role will use a role configuration group which defines configuration for all roles belonging to that role config group Overrides (A configuration value can be set for a specific role (overriding other configurations) In the case of "mapreduce.job.split.metainfo.maxsize" it is defined in the default Role Configuration Group for the YARN Gateway Role type. The default value is: 10000000 Via Python, I used the following to ad a "value" that was not None: #!/usr/bin/env python
import cm_client
from cm_client.rest import ApiException
from pprint import pprint
# Configure HTTP basic authorization: basic
cm_client.configuration.username = 'admin'
cm_client.configuration.password = 'lizard'
cm_client.configuration.verify_ssl = True
# Path of truststore file in PEM
cm_client.configuration.ssl_ca_cert = '/opt/cloudera/security/cacerts/ClouderaSEC_combined.pem'
# Create an instance of the API class
api_host = 'https://host-10-17-100-224.coe.cloudera.com'
port = '7183'
api_version = 'v30'
# Construct base URL for API
# http://cmhost:7180/api/v30
api_url = api_host + ':' + port + '/api/' + api_version
api_client = cm_client.ApiClient(api_url)
cluster_api_instance = cm_client.ClustersResourceApi(api_client)
# This lists all clusters, so if you have more than one, set "cluster_name" to it. Otherwise, last one wins
api_response = cluster_api_instance.read_clusters(view='SUMMARY')
for cluster in api_response.items:
cluster_name = cluster.name
# Get a list of all services and set myserive if the service type is "YARN"
services_api_instance = cm_client.ServicesResourceApi(api_client)
services = services_api_instance.read_services(cluster.name, view='FULL')
for service in services.items:
if service.type == 'YARN':
myservice = service
# Get a list of roles and get the GATEWAY type
roles_api_instance = cm_client.RolesResourceApi(api_client)
roles = roles_api_instance.read_roles(cluster_name, myservice.name)
for role in roles.items:
if role.type == 'GATEWAY':
myrole = role
# default is summary... this is only relevant if printing out information since full shows all values
# regardless if they have a non-default value or not
view = 'full'
# Uses RoleConfigGroupsResourceApi to retrieve all YARN role config groups
# Sets yarnGatewayBase to be the name of the role config group we want to update
rcg_api_instance = cm_client.RoleConfigGroupsResourceApi(api_client)
rcg_api_response = rcg_api_instance.read_role_config_groups(cluster_name, myservice.name)
pprint(rcg_api_response)
for cfg in rcg_api_response.items:
if cfg.name == "yarn-GATEWAY-BASE":
yarnGatewayBase = cfg.name
# read the config and iterate over each config till we find the one we want
# print out the config before update
yarn_gateway_base = rcg_api_instance.read_config(cluster_name, yarnGatewayBase, myservice.name, view=view)
for config in yarn_gateway_base.items:
if config.related_name == 'mapreduce.job.split.metainfo.maxsize':
print "mapreduce.job.split.metainfo.maxsize before update:\n===================\n"
pprint(config)
print "mapreduce.job.split.metainfo.maxsize after update:\n====================\n"
config_to_update = config.name
# Set message and new config values where "value" is what we want the new value to be
# use update_config() to update the value
message = 'testing update of mapreduce.job.split.metainfo.maxsize' # str | Optional message describing the changes. (optional)
new_config = cm_client.ApiConfig(name=config_to_update, value="20000000")
new_config_list = cm_client.ApiConfigList([new_config])
try:
# Updates the config for the given role config group.
res = rcg_api_instance.update_config(cluster_name, yarnGatewayBase, myservice.name, message=message, body=new_config_list)
pprint(res)
except ApiException as e:
print("Exception when calling RoleConfigGroupsResourceApi->update_config: %s\n" % e) If you have questions about anything, let us know.
... View more
07-19-2019
02:06 PM
@viha, If that is the first time you have started Cloudera Manager, those tables should not exist. CM, when first started, will create the necessary tables and populate them accordingly. Maybe there was an error or problem during install previously that led to the tables being created but not populated with any data? Seems like we are in a strange state either way. I would recommend starting over with an empty database and then try starting CM. The exception you get indicates that the VERSION column (in CM_VERSION table) value is "null". That should not be possible, so startup fails.
... View more
07-19-2019
01:51 PM
@mmmunafo, Not looking good... workarounds may become complex. Hue uses requests-kerberos and its readme says: In order to use this library, there must already be a Kerberos Ticket-Granting
Ticket(TGT) cached in a Kerberos credential cache. Whether a TGT is available
pointing the $KRB5CCNAME to a credential cache with a valid TGT. That's why Hue sets KRB5CCNAME. I tried not setting it (commented out of settings.py) and kerberos functions looked for credentials cache in /tmp What is most surprising about this is that I don't think there were any changes in Hue that would influence PAM auth behavior. KRB5CCNAME has always been set by Hue for the hue process. Since you upgraded OS version too, I wonder if the pam module behavior has changed. Is there any chance you can use SPNEGO or LDAP auth directly?
... View more