Bug 68408 - rhn_package_manager only executable by root and packageDir changed?
Summary: rhn_package_manager only executable by root and packageDir changed?
Alias: None
Product: Red Hat Network
Classification: Red Hat
Component: RHN/Channels   
(Show other bugs)
Version: RHN Stable
Hardware: All Linux
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: jkomendar
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-09 22:49 UTC by Isaiah Weiner
Modified: 2007-04-18 16:44 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-07-30 17:50:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Isaiah Weiner 2002-07-09 22:49:19 UTC
Description of problem:
Prior to rhns-proxy-package-manager-1.2.4-3 (when rhn_package_manager was still 
in the rhn_package_manager package) users could execute rhn_package_manager 
independant of having root access.  This was fantastic and much more secure 
when you have channel administrators you don't want having the root password to 
your RHN proxy.  It also meant each users's $HOME/.rhn_package_manager would be 
obeyed, and the new version does not appear to honor the packageDir directive 
in /etc/rhn/default/rhn_proxy_package_manager.conf.  When will you be changing 
the program to let people other than root execute it, and what's the right 
directive for the old packageDir?  The default /var/up2date path is not going 
to work for us.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. execute rhn_package_manager

Additional info:

Comment 1 Mihai Ibanescu 2002-07-22 22:54:43 UTC
We tried to unify the configurations for rhn_package_manager and the proxy;
rhn_package_manager should use the same configuration options as the proxy.
The old packageDir directive should be pkg_dir in /etc/rhn/rhn.conf. Please do
file a bug if this does not happen(against RHN/Proxy, and/or feel free to assign
it to me directly. This bug got into RHN/Channels, and I'm not the owner of this

We felt that the simplicity of one configuration file would be a better
approach, rather than having multiple config files, one for proxy and one for
the package manager, doing pretty much the same thing. 

At that point we also enforced the root check. Again, if this is too
inconvenient for people at large, we'll find an intermediate solution (i.e. any
user can upload, and look for a  ~/.rhn.conf file before reading /etc/rhn/rhn.conf).

Comment 2 Isaiah Weiner 2002-07-26 20:08:45 UTC
Hindsight is 20/20, but maybe there could be some solicitation of input on
things like check-root.

Please consider this a request to change it back.  It's awfully frustrating in a
multi-admin and NIS+ environment.

Thanks for the information about pkgdir!

Comment 3 Isaiah Weiner 2002-07-26 20:09:37 UTC
er, pkg_dir.

Comment 4 Isaiah Weiner 2002-07-30 03:22:39 UTC
I copied /etc/rhn/default/rhn_proxy_package_manager.conf to
/etc/rhn/rhn_proxy_package_manager.conf and made the pkg_dir addition, which
didn't appear to work - rhn_package_manager is still copying the headers to the
default '/var/up2date/...' path.  Why might this be happening?

Comment 5 Mihai Ibanescu 2002-07-30 17:36:51 UTC
Short answer: don't do that.
All the settings, for everything proxy side, are in /etc/rhn/rhn.conf.
rhn_package_manager reads that file to get pkg_dir. Under normal circumstances,
pkg_dir should be already set for the proxy, so rhn_package_manager piggybacks
on the proxy's configuration.
rhn_package_manager also has a -p (or --printconf) option to print the
configuration it's gonna use.

Comment 6 Isaiah Weiner 2002-07-30 17:49:55 UTC
It works, and looking back reading your instructions seems clean, but at the
time seemed ambiguous. (There's already a setting in rhn.conf for _a_ "pkg_dir",
but not _the_ "pkg_dir".)

Note You need to log in before you can comment on or make changes to this bug.