ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hari Sekhon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-10823) Existing LDAP users break Ambari service deployment which expects local users
Date Fri, 05 Jun 2015 12:45:00 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-10823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574433#comment-14574433
] 

Hari Sekhon commented on AMBARI-10823:
--------------------------------------

Bitten again and again by this as enlarging clusters. One workaround is to simply add the
ldap user/groups that it complains about locally making sure to keep the UID/GIDs consistent.

> Existing LDAP users break Ambari service deployment which expects local users
> -----------------------------------------------------------------------------
>
>                 Key: AMBARI-10823
>                 URL: https://issues.apache.org/jira/browse/AMBARI-10823
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.0.0
>         Environment: HDP 2.2.4.2
>            Reporter: Hari Sekhon
>            Priority: Blocker
>
> New service deployment breaks if there is an existing matching LDAP user as Ambari tries
to usermod which only works on local users (it does not find the LDAP user in local /etc/passwd):
> {code}usermod: user 'blah' does not exist in /etc/passwd{code}
> There needs to be some provision for re-using existing LDAP users (needed for a non-trivial
Kerberos deployment with many end users), but what to do about user/group modifications in
such an environment is not clear. Perhaps Ambari should have a tick box for LDAP and export
a CSV that we can script to ensure the users and group service accounts are set up correctly
in the LDAP directory before proceeding, similar to the Kerberos principals CSV?
> Alternatively Ambari could just go ahead and create and modify local users and groups
but set their UIDs/GIDs to be the same as the LDAP counterparts so everything lines up (although
if adjusting existing local users/groups this could orphan files). This is probably not a
technically pristine thing to do although we've all made it work properly before on various
clusters so I know it does work if you're careful to find and re-own any orphaned files. I'm
not sure I can recommend this for an automated solution just due to the search time for orphaned
files.
> Here is an example of a service deployment error that seems to be too common:
> {code}stderr: 
> 2015-04-29 10:25:48,402 - Error while executing command 'any':
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 214, in execute
>     method(env)
>   File "/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY/scripts/hook.py",
line 30, in hook
>     setup_users()
>   File "/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY/scripts/shared_initialization.py",
line 75, in setup_users
>     ignore_failures = params.ignore_groupsusers_create
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 148,
in __init__
>     self.env.run()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", line
152, in run
>     self.run_action(resource, action)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", line
118, in run_action
>     provider_action()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/providers/accounts.py",
line 72, in action_create
>     shell.checked_call(command, sudo=True)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 70,
in inner
>     return function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 82,
in checked_call
>     return _call(command, logoutput, True, cwd, env, preexec_fn, user, wait_for_finish,
timeout, path, sudo, on_new_line)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 199,
in _call
>     raise Fail(err_msg)
> Fail: Execution of 'usermod -G hadoop -g hadoop spark' returned 6. usermod: user 'spark'
does not exist in /etc/passwd
> Error: Error: Unable to run the custom hook script ['/usr/bin/python2.6', '/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY/scripts/hook.py',
'ANY', '/var/lib/ambari-agent/data/command-5998.json', '/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY',
'/var/lib/ambari-agent/data/structured-out-5998.json', 'INFO', '/var/lib/ambari-agent/data/tmp']
>  stdout:
> 2015-04-29 10:25:47,721 - u"Group['hadoop']" {'ignore_failures': False}
> 2015-04-29 10:25:47,732 - Modifying group hadoop
> 2015-04-29 10:25:47,844 - u"Group['users']" {'ignore_failures': False}
> 2015-04-29 10:25:47,854 - Modifying group users
> 2015-04-29 10:25:47,900 - u"Group['spark']" {'ignore_failures': False}
> 2015-04-29 10:25:47,923 - Adding group u"Group['spark']"
> 2015-04-29 10:25:48,010 - u"User['hive']" {'gid': 'hadoop', 'ignore_failures': False,
'groups': [u'hadoop']}
> 2015-04-29 10:25:48,010 - Modifying user hive
> 2015-04-29 10:25:48,067 - u"User['oozie']" {'gid': 'hadoop', 'ignore_failures': False,
'groups': [u'users']}
> 2015-04-29 10:25:48,069 - Modifying user oozie
> 2015-04-29 10:25:48,128 - u"User['ambari-qa']" {'gid': 'hadoop', 'ignore_failures': False,
'groups': [u'users']}
> 2015-04-29 10:25:48,128 - Modifying user ambari-qa
> 2015-04-29 10:25:48,184 - u"User['hdfs']" {'gid': 'hadoop', 'ignore_failures': False,
'groups': [u'hadoop']}
> 2015-04-29 10:25:48,184 - Modifying user hdfs
> 2015-04-29 10:25:48,321 - u"User['spark']" {'gid': 'hadoop', 'ignore_failures': False,
'groups': [u'hadoop']}
> 2015-04-29 10:25:48,329 - Modifying user spark
> 2015-04-29 10:25:48,402 - Error while executing command 'any':
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/site-packages/resource_management/libraries/script/script.py",
line 214, in execute
>     method(env)
>   File "/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY/scripts/hook.py",
line 30, in hook
>     setup_users()
>   File "/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY/scripts/shared_initialization.py",
line 75, in setup_users
>     ignore_failures = params.ignore_groupsusers_create
>   File "/usr/lib/python2.6/site-packages/resource_management/core/base.py", line 148,
in __init__
>     self.env.run()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", line
152, in run
>     self.run_action(resource, action)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/environment.py", line
118, in run_action
>     provider_action()
>   File "/usr/lib/python2.6/site-packages/resource_management/core/providers/accounts.py",
line 72, in action_create
>     shell.checked_call(command, sudo=True)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 70,
in inner
>     return function(command, **kwargs)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 82,
in checked_call
>     return _call(command, logoutput, True, cwd, env, preexec_fn, user, wait_for_finish,
timeout, path, sudo, on_new_line)
>   File "/usr/lib/python2.6/site-packages/resource_management/core/shell.py", line 199,
in _call
>     raise Fail(err_msg)
> Fail: Execution of 'usermod -G hadoop -g hadoop spark' returned 6. usermod: user 'spark'
does not exist in /etc/passwd
> Error: Error: Unable to run the custom hook script ['/usr/bin/python2.6', '/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY/scripts/hook.py',
'ANY', '/var/lib/ambari-agent/data/command-5998.json', '/var/lib/ambari-agent/cache/stacks/HDP/2.0.6/hooks/before-ANY',
'/var/lib/ambari-agent/data/structured-out-5998.json', 'INFO', '/var/lib/ambari-agent/data/tmp']
> {code}
> Hari Sekhon
> http://www.linkedin.com/in/harisekhon



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message