FAQ
Hi all,

I'm not sure whether to consider this a bug or a feature request... It's
certainly just a minor fix at any rate...

If using a RHEL base with Satellite/Spacewalk for repository management the
yum install to a host that SCM does failes if using sudo (non-root) rather
than root.

The specific reason for this is that requesting any package information via
yum-rhn-plugin requires privileged access whereas regular users are allowed
to carry out yum search etc against regular repositories.

The SCM installation does the check to see if the packages exist without
using sudo on the yum command (and only uses sudo on the package install
itself) and consequently can't find the packages and then fails....

If the SCM code is adjusted on the sudo route to include sudo on the
package search as well as the package install this would then work - and
would eliminate the root ssh requirement and allow for proper auditing of
packages via satellite/spacewalk - without any side effect overall.

I recognise this is no longer required when using the CM package support
for rolling upgrades but suspect that RPM/yum managed instances will still
be a valid use case for some time to come.

Kind regards,

James

Search Discussions

  • Harsh J at Jan 31, 2013 at 10:56 am
    Hey James,

    What version of CM are you reporting this for? I believe we've
    addressed this in CM 4.1.1+. Please let us know!
    On Thu, Jan 31, 2013 at 3:54 PM, James Hogarth wrote:
    Hi all,

    I'm not sure whether to consider this a bug or a feature request... It's
    certainly just a minor fix at any rate...

    If using a RHEL base with Satellite/Spacewalk for repository management the
    yum install to a host that SCM does failes if using sudo (non-root) rather
    than root.

    The specific reason for this is that requesting any package information via
    yum-rhn-plugin requires privileged access whereas regular users are allowed
    to carry out yum search etc against regular repositories.

    The SCM installation does the check to see if the packages exist without
    using sudo on the yum command (and only uses sudo on the package install
    itself) and consequently can't find the packages and then fails....

    If the SCM code is adjusted on the sudo route to include sudo on the package
    search as well as the package install this would then work - and would
    eliminate the root ssh requirement and allow for proper auditing of packages
    via satellite/spacewalk - without any side effect overall.

    I recognise this is no longer required when using the CM package support for
    rolling upgrades but suspect that RPM/yum managed instances will still be a
    valid use case for some time to come.

    Kind regards,

    James


    --
    Harsh J
  • James Hogarth at Jan 31, 2013 at 12:16 pm

    On Thursday, 31 January 2013 10:56:12 UTC, Harsh J wrote:
    Hey James,

    What version of CM are you reporting this for? I believe we've
    addressed this in CM 4.1.1+. Please let us know!

    My apologies...

    Last time I tested this was prior to 4.1 CM and it was listed in my todo
    list to report ...

    I looked at the release notes and saw no mention of something like this in
    the 4.1.X series:

    https://ccp.cloudera.com/display/ENT41DOC/Known+Issues+and+Work+Arounds+in+Cloudera+Manager+4#KnownIssuesandWorkAroundsinClouderaManager4-KnownIssuesFixedinClouderaManager4.1.1

    I made the assumption it wasn't actually fixed yet then...

    Just tested it on my current (CM 4.1.3 plus CDH 4.1.2 plus impala 0.4 beta)
    install and it worked fine...

    Great stuff - but is there any more details of cloudera specific fixes
    (rather than stuff that is upstream) that I should be looking at or was
    this just a slip up in not including the fix was put in place?

    Cheers,

    James
  • Harsh J at Jan 31, 2013 at 12:32 pm
    Hi James,

    Good to know and thanks very much for taking the time to report your
    feedback, it is immeasurably valuable to us! :)

    I think it may not have made it to the release notes, being a smaller
    improvement. We discovered this out of another oddity, that of some
    yum conf files being 400 instead of readable by all, and thereby
    requiring root to execute even for info commands (which usually
    shouldn't require root privs to run). We did run install as root
    always, so its just during the pre-install info lookup this would
    fail.
    On Thu, Jan 31, 2013 at 5:46 PM, James Hogarth wrote:

    On Thursday, 31 January 2013 10:56:12 UTC, Harsh J wrote:

    Hey James,

    What version of CM are you reporting this for? I believe we've
    addressed this in CM 4.1.1+. Please let us know!
    My apologies...

    Last time I tested this was prior to 4.1 CM and it was listed in my todo
    list to report ...

    I looked at the release notes and saw no mention of something like this in
    the 4.1.X series:

    https://ccp.cloudera.com/display/ENT41DOC/Known+Issues+and+Work+Arounds+in+Cloudera+Manager+4#KnownIssuesandWorkAroundsinClouderaManager4-KnownIssuesFixedinClouderaManager4.1.1

    I made the assumption it wasn't actually fixed yet then...

    Just tested it on my current (CM 4.1.3 plus CDH 4.1.2 plus impala 0.4 beta)
    install and it worked fine...

    Great stuff - but is there any more details of cloudera specific fixes
    (rather than stuff that is upstream) that I should be looking at or was this
    just a slip up in not including the fix was put in place?

    Cheers,

    James


    --
    Harsh J

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupscm-users @
categorieshadoop
postedJan 31, '13 at 10:24a
activeJan 31, '13 at 12:32p
posts4
users2
websitecloudera.com
irc#hadoop

2 users in discussion

James Hogarth: 2 posts Harsh J: 2 posts

People

Translate

site design / logo © 2022 Grokbase