Bug 40183 - updated security RPMS require rpm v4
Summary: updated security RPMS require rpm v4
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-11 01:54 UTC by Steven Roberts
Modified: 2007-03-27 03:44 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-06 02:47:37 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 Steven Roberts 2001-05-11 01:54:25 UTC
Description of Problem:
the latest couple of rounds of updates (including security ones like the xntp3 one) require the rpmv4 updates.  this puts a lot of sites (including 
mine) betweena rock and a hard place.  Do I A) install an untested random variable that is rpm4 or B) live without the security updates.  I 
understand having rpm4 required in RH 7, but a forced upgrade (especially considering the huge mess going from rpm2 to rpm3) in RH 6.x 
systems is not a good thing.

Comment 1 Jeff Johnson 2001-05-11 02:18:16 UTC
rpm-4.0.2 is released as an errata for all Red Hat platforms, and we
build packages against the latest released errata.

FWIW, rpm-4.0 has survived two Red Hat distro's already, it's
not exactly an "untested random variable". YMMV.

Comment 2 Steven Roberts 2001-05-11 02:40:36 UTC
which two?

RH7.0 shipped with it, but RH7.1 was released AFTER rpm4 started being shoved down the update throat.  plus, rpm3 has had a lot of time out in the 
field.  rpm4 won't get that for a few years.  how big were the changes in rpm4?  the errate update wasn't exactly verbose on that...

Also, on the changeover, is rpm4 actually going to be documented? that is one of the things that greatly hurt on thr rpm3 change, rpm2 had great docs, 
ncluding Maximum RPM, rpm3 still doesn't have that level of docs.

Comment 3 Jeff Johnson 2001-05-11 03:46:38 UTC
Where have you been for the last several years? :-)

You might take a gander at www.rpm.org, as the rpmlib API is fairly
well documented using doxygen, something "Maximum RPM" never
did well ...

Comment 4 Steven Roberts 2001-05-25 19:11:53 UTC
Okay, so I decided to take the plunge and so with the rpm's requiring rpmv4.  One REALLY big problem.  is there an instimage compatible with both 
rpmv4 and RH6.2?  Unless there is then I can't use the security updates that require rpmv4.

and in case you are wondering I tried using the RH6.2 one, and it doesn't work.

Comment 5 Jeff Johnson 2001-05-25 19:25:51 UTC
BTW, it shouldn't have been a security errata for rpm, the errata text
was released, but there's no way to undo what was originally done.

rpm-3.0.7 (unreleased, but on the rpm-3_0_5 branch in CVS) is the easiest
pathway for a 6.2 compatible installer. That version will install rpmv4
and do everything you need. Otherwise, you will have to backport changes
from the Red Hat 7.0 anaconda to use rpmdb iterators, a bit of a pain.

The only problem I'm awars of is a bit of  name space pollution with the

int cpioFileMapCmp(const void * a, const void * b)
    const char * afn = ((const struct cpioFileMapping *)a)->archivePath;
    const char * bfn = ((const struct cpioFileMapping *)b)->archivePath;

    /* Match payloads with ./ prefixes as well. */
    if (afn[0] == '.' && afn[1] == '/')        afn += 2;
    if (bfn[0] == '.' && bfn[1] == '/')        bfn += 2;

    return strcmp(afn, bfn);

Make sure that the function of the same name in the installer
is exactly the same. Bonus points if you also rename the
function within the installer.

Comment 6 Steven Roberts 2001-05-25 19:48:46 UTC
Are there docs anywhere on how to toss new rpm binaries into the installer? (or can you give me a quick summary?)

I have been meaning to pick apart the internals of how the installer works, but haven't had time yet beyond diving into lots of kickstart usage...

Comment 7 Steven Roberts 2001-05-25 20:24:16 UTC
did a quick peak and it looks like anaconca might just use under instimage:
/usr/bin/rpm and
(and other misc stuff)

so, am I correct in thinking I can just do a source build of rpm, and then copy the results in?

just asking because some of the installer stuff (like mount) is built in.


Comment 8 Jeff Johnson 2001-05-25 20:42:03 UTC
If you have the stomach for it, porting the 7.0 anaconda back to 6.2 is
a great learning mechanism. No (or very little) doco, but I suspect the
source is pretty informative.

Meanwhile, the 7.x anaconda interfaces to rpm *only* through python
bindings AFAIK. The killer is in other details, such as wide chars, mount
labels, kernel driver quirks and such that need some thought.

rpmlib-4.0.2 is *easy* compared to some of the other 6.2 -> 7.0 changes

Comment 9 Jeff Johnson 2001-05-31 14:08:06 UTC
Can't see any further problem here.

Comment 10 Steven Roberts 2001-08-06 02:47:33 UTC
Well, the bad news the solution mentioned above didn't work out.

don't worry there is good news.

Comment 11 Steven Roberts 2001-08-06 02:59:26 UTC
The good news is that RedHat support responded with a solution to Service request #180058 that did work well for me.

The basic idea is instead of merging the updates into the base RPMS set, leave the stock RPMS set unchanged, and do the updates as a part of the 
kickstart post section.  What this does is you don't have to get the install program up to rpm v4, you just upgrade the machine in %post to rpmv4 and then 
install the updates.

Which for others that have this problem, a quick look at what I did:

I through everything under a /intall/tl63 (tl63 meaning TrueLink and is RH 6.2 with changes)
RedHat - the normal RH6.2 image (including the RPMS sub-dir)
updates/rpm4 - the rpm v4 rpm and the db3 rpm (basically what is need to first update to rpm v4)
updates/i386 - the updates form RH minus the rpm4 ones and the kernel rpm's
updates/kernel - contains kernel updates seperately (so that same tree can support installs to i586's and i686's)
extras - some extra RPMS we have grabbed/built in house -- openssh, apache with mod_ssl support, sudo, etc.

snippets from the kickstart script:
# mount install tree again -- will allow us to grab sub scripts and patches, etc
mount <install IP>:/install /mnt

# update to rpm4
rpm -ivh /mnt/tl63/updates/rpm4/db3-3*.rpm
rpm -Fvh /mnt/tl63/updates/rpm4/rpm-4*.rpm

# grab updates to current packages
rpm -Fvh /mnt/tl63/updates/i386/*.rpm

# grab updated kernel for this arch
rpm -Fvh /mnt/tl63/updates/kernel/*.rpm
rpm -Fvh /mnt/tl63/updates/kernel/i686/*.rpm

# fix kernel lilo setup
perl -pi -e 's/14-5\.0/19-6.2.7/' /etc/lilo.conf


# ALL DONE, umount
umount /mnt
Which as a final note, I just wanted to express my thanks to everyone at RedHat for the great support I have gotten on this and other issues.  Compared 
to the lack of support we get from other vendors the level of support from RedHat is quite refreshing.

Comment 12 Steven Roberts 2001-08-16 05:36:24 UTC
FYI, we found an issue with rpm v4 today.  the relocatable package we are building internally don't work under rpm v4.  we haven't looked into why yet.  We did the 
quick workaround of using the static rpm v3 binary for our installs or the relocatable package (we use a seperate rpmdb for them already so wasn't a big problem).  
basically looks like a '/' is getting clipped out of the path (our rpm's have a prefix of /db  and when we tell it to install to foo/db it makes it foodb)

Comment 13 Jeff Johnson 2001-08-16 15:10:56 UTC
Relocations are broken in rpm-4.0.2, fixed in rpm-4.0.3. FWIW, you should
be trying to use rpm-4.0.3-0.92 or later, bits are cooked, release is imminent.

Comment 14 Steven Roberts 2001-08-17 00:15:14 UTC
thanks for the heads up.  we will be anxiously awaiting 4.0.3 :)

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