Bug 210603 - add RHN Satellite config option to disable activation key Universal default possibility
Summary: add RHN Satellite config option to disable activation key Universal default p...
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
(Show other bugs)
Version: 500
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jesus M. Rodriguez
QA Contact: Brandon Perkins
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-13 04:19 UTC by Matt Domsch
Modified: 2008-10-29 14:21 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-29 14:21:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Matt Domsch 2006-10-13 04:19:49 UTC
Description of problem:
A system admin using Dell's internal RHN Satellite Server created a new
activation key, and set it with "Universal default: yes", but shouldn't have. 
This caused all sorts of problems with new registrations of course.

To disable this possibility, I had to edit Sniglets/ActivationKeys.pm to remove
the drop-down option for "Yes" there, and force it to always be "no".

I'd like to see a high-level configuration file option which accomplishes the
same function - disable the ability to set "Universal default: yes" on a key.

Version-Release number of selected component (if applicable):
3.4, though 4.1 appears to have the same behavior.

Comment 1 Red Hat Bugzilla 2007-04-12 01:25:15 UTC
User bnackash@redhat.com's account has been closed

Comment 2 Matt Domsch 2008-10-29 14:21:44 UTC
These have been open for years with no investigation or resolution.  Since then the code base has moved on significantly, such that many of these no longer would apply to the current spacewalk code.  I'm closing these requests in the hope they're no longer necessary, or if they are, they'll get discovered anew.


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