Bug 131261 - Removal of COE rpms broke
Removal of COE rpms broke
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: coe (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Graner
Depends On:
  Show dependency treegraph
Reported: 2004-08-30 12:16 EDT by Pete Graner
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-01 11:31:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pete Graner 2004-08-30 12:16:48 EDT
When I uninstall using the rpm command not all files are deleted. 

There are registry files in /h/COE/data/CDS that include hostname
information. This can be a problem in the following scenario:

- Install COE- Uninstall COE using rpm command
- Change the hostname
- Reinstall COE and the installation fails due to Ambiguous hostname
and authentication issues because the hostname is now different then
the registry files.

i.e. rpm -e coe
Comment 1 Pete Graner 2004-09-08 11:25:10 EDT
This one is a not easy to fix due to how COE gets installed with the
inst.dii script.

I have 2 choices, right now #1 would be my long term choice:

1. Migrate the inst.dii script into a %post sciptlet, and then create
a script to create all of the password, key bits, that the user can be
instructed to run after the rpm installs (or use default password and
keys and they can change after installation)

2. Make all of the coe files that are included in the tar ball, and
any files created by inst.dii as ghost entries in the %files section
that way during the rpm -e process it will gleep them as part of the
removal process. 

I'd like to hear John's thoughts on how they plan on handling the
install in the future, like do you see inst.dii as the main installer
for COE long term or do you plan on letting the package mgt. utils
(rpm & pkg* on Solaris) handle these issues.

I don't mind doing the work if thats the direction that DISA/JPL wants
to go, if not, I'll bugger up somehting to completly remove it. If we
got this route keep in mind it will break RHN, and they will have a
holy *&^@^%# fit when they see the spec file hack, because this will
not allow of a automatic upgrade (same with Solaris if you packged up
the bits just like we did for rpm).

My reccomendation is to fix it right get rid of inst.dii and let the
package mgt tools do the dirty work, this way you can upgrade cleanly
etc... just my .02 worth.


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