> On Feb. 26, 2015, 7:09 a.m., Andrew Onischuk wrote: > > ambari-common/src/main/python/resource_management/libraries/functions/get_klist_path.py, > > line 26 > > <https://reviews.apache.org/r/31483/diff/1/?file=878321#file878321line26> > > > > Can you create more generic function. > > Something like: > > > > get_binary_path(pathes_list, binary_name): > > > > and use it as: > > get_binary_path(..., "klist") > > get_binary_path(..., "kinit") > > > > I know we already use the same approach for kinit, and maybe in future > > need some more like this.
I was thinking about this as well and teetered back and forth on doing that. I decided to do the copy to try not to introduce a new bug. Also I know that we will be reworking the get_kinit_path and get_klist_path functions when we support alternate locations of kinit and klist. So I assumed we would do a similar fix then. > On Feb. 26, 2015, 7:09 a.m., Andrew Onischuk wrote: > > ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_webhcat_server.py, > > line 112 > > <https://reviews.apache.org/r/31483/diff/1/?file=878322#file878322line112> > > > > Can we evaluate klist path in params, to be able to do more usages in > > future is it's necessary As mentioned in the previous comment, this will be addressed when we take on alterante paths for kinit and klist. I don't think such a change is appropriate now, espically with the current time constraints. > On Feb. 26, 2015, 7:09 a.m., Andrew Onischuk wrote: > > ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py, line > > 58 > > <https://reviews.apache.org/r/31483/diff/1/?file=878327#file878327line58> > > > > Tests will fail if klist is present on system. In tests we also have to > > mock call function you used, to return always 0 or 1. > > Andrew Onischuk wrote: > just a small changes better I think better to do. Otherwise patch looks > good. I'm looking into this one... Python mocks are not my forte. Thanks for the review. - Robert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31483/#review74255 ----------------------------------------------------------- On Feb. 26, 2015, 7:02 a.m., Robert Levas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/31483/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2015, 7:02 a.m.) > > > Review request for Ambari, Andrew Onischuk, Emil Anca, Jonathan Hurley, and > Vitalyi Brodetskyi. > > > Bugs: AMBARI-9785 > https://issues.apache.org/jira/browse/AMBARI-9785 > > > Repository: ambari > > > Description > ------- > > After enabling Kerberos, the root user has the spnego user set for it > > ``` > [root@c6501 ~]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: HTTP/[email protected] > > Valid starting Expires Service principal > 02/18/15 22:14:51 02/19/15 22:14:51 krbtgt/[email protected] > renew until 02/18/15 22:14:51 > ``` > > It appears that the issue is related to the agent-side scheduler and/or some > job that is scheduled to run periodically. Apparently some job is kinit-ing > with the SPNEGO identity as the running user (root in this case) without > changing the ticket cache. Thus whenever the job runs the root user's ticket > cache gets changed to contain the SPNEGO identity's ticket. > > While investigating and solving the issue it was found that other credentials > were added to this cache, overwriting what was there, during backround > processing, as well. > > Most of the issues were releated to _alert_ checking on web-based UI > endpoints while configuring the environment for curl to use Kerberos > authentication. Another place (in Oozie) was a failure to run a command as > the `oozie` local user. > > Solving this includes using an alternate credential cache when kinit-ing. > While at it, the cached is checked to see if the tickets are expired (or even > there) before kinit-ing. > > > Diffs > ----- > > ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py 8ee6606 > > ambari-common/src/main/python/resource_management/libraries/functions/__init__.py > 44d235c > > ambari-common/src/main/python/resource_management/libraries/functions/get_klist_path.py > PRE-CREATION > > ambari-server/src/main/resources/common-services/HIVE/0.12.0.2.0/package/alerts/alert_webhcat_server.py > 970ddde > > ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/alerts/alert_check_oozie_server.py > a5a066b > > ambari-server/src/main/resources/common-services/OOZIE/4.0.0.2.0/package/scripts/oozie_service.py > 092149d > > ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/OOZIE/package/files/alert_check_oozie_server.py > a5a066b > > ambari-server/src/main/resources/stacks/BIGTOP/0.8/services/WEBHCAT/package/files/alert_webhcat_server.py > 970ddde > ambari-server/src/test/python/stacks/2.0.6/OOZIE/test_oozie_server.py > 45e9dc4 > > Diff: https://reviews.apache.org/r/31483/diff/ > > > Testing > ------- > > Manually tested all services in test cluster to see which might have this > issue. Found only OOZIE and HIVE issues and tests showed they are fixed and > working as they should. > > #Jenkins Test Results > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 01:12 h > [INFO] Finished at: 2015-02-26T06:35:45+00:00 > [INFO] Final Memory: 44M/457M > [INFO] > ------------------------------------------------------------------------ > > > Thanks, > > Robert Levas > >
