ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hari Sekhon (JIRA)" <>
Subject [jira] [Commented] (AMBARI-10494) Ambari 2.0 HDP Stack deployment broken due to yum repo assumptions trying to install krb5-server on all nodes
Date Fri, 17 Apr 2015 16:33:59 GMT


Hari Sekhon commented on AMBARI-10494:

Hi Jeff,

Yes this cluster has been kerberized for a while using Redhat IPA (basically MIT KDC + 389-ds
LDAP pre-integrated). I generated and auto-deployed the keytabs using a perl script I wrote
on github and documented in AMBARI-6432 that accepts the standard Ambari CSV export file listing
all principals.

That was around Ambari 1.5/1.6.1 and since then I've been going through Ambari upgrades as
they've become available but the latest version of Ambari 2.0.0 is a confused and doesn't
see the cluster as kerberized but in the upgrade stack procedure Ambari has still been triggering
kinits where necessary (sometimes incurring other issues eg. AMBARI-10519).

> Ambari 2.0 HDP Stack deployment broken due to yum repo assumptions trying to
install krb5-server on all nodes
> ---------------------------------------------------------------------------------------------------------------------
>                 Key: AMBARI-10494
>                 URL:
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-agent, ambari-server, stacks
>    Affects Versions: 2.0.0
>         Environment: HDP => HDP
>            Reporter: Hari Sekhon
>         Attachments: errors-5311.txt, output-5311.txt
> When trying to upgrade from HDP 2.2.0 to 2.2.4 Ambari tries to install krb5-server on
all nodes (why all nodes??) and but issues a yum command on RHEL6 that excludes nearly all
> {code}Fail: Execution of '/usr/bin/yum -d 0 -e 0 -y install '--disablerepo=*' --enablerepo=base,HDP-UTILS-,HDP-
krb5-server' returned 1. Error: Nothing to do{code}
> The reason this fails is because there is no "base" repo as packages are managed through
Redhat Satellite server with internal repo names. This is a common deployment style in corporations
that have strict border filtering so servers are not pulling packages directly from the internet
(this is a bank).
> The install of the new stack version actually did succeed on nodes where krb5-server
happened to already be installed, so a workaround is to pre-install krb5-server on all nodes
to allow it to simply skip this package. Well I would if Ambari didn't get stuck after failure
(see AMBARI-10495).
> I understand why the repo exclusions are done to try to force the right Hadoop rpms versions
to be installed but it might be better to not exclude any repos for this krb5-server package,
although I'm not sure why this package needs to be installed on all nodes anyway.
> Also, if using parcels as I recommended in AMBARI-8815, repo exclusions wouldn't be needed
at all and it would avoid this and other rpm/repo related problems, which is why Cloudera
engineers switched to parcel deployments.
> Hari Sekhon
> (ex-Cloudera)

This message was sent by Atlassian JIRA

View raw message