CentOS - Nov 2013 - Most efficient way to create a CentOS 3 test VM

I'm about to create a new CentOS 3 VM for testing, since we still have a 
bunch of deployed machines running that OS.

(Don't yell at me about using old OSes.  These machines won't get 
"un-deployed" until they fall over dead of natural causes.  Until the 
last one dies, we need test and build VMs around to service them.)

I have the CentOS 3.9 *.iso files plus a local cache of RPMs against 3.9 
that is probably incomplete relative to the vault[*].

It seems wasteful to install the last published version of the OS, then 
scp over my local update RPMs, freshen from those, *then* check with the 
vault for yet more updates.

What I'm hoping for is some way to get a "CentOS 3.10", being 3.9
with
the vault updates directory contents merged in.

Is there a straightforward way to do that, or is schlepping around 
folders full of RPMs actually the best way to go?


[*] http://vault.centos.org/3.9/updates/i386/RPMS/

Warren Young wrote:
> I'm about to create a new CentOS 3 VM for testing, since we still have
a
> bunch of deployed machines running that OS.
>
> (Don't yell at me about using old OSes.  These machines won't get
> "un-deployed" until they fall over dead of natural causes.  Until
the
> last one dies, we need test and build VMs around to service them.)
>
I, at least, understand. We have one of our researchers who builds stuff
against that, because he's got collaborators around the world, and they
*can't* get newer, at least yet....
<snip>
       mark

On 11/26/2013 12:00 PM, Warren Young wrote:
> It seems wasteful to install the last published version of the OS, then
> scp over my local update RPMs, freshen from those,*then*  check with the
> vault for yet more updates.
>
> What I'm hoping for is some way to get a "CentOS 3.10", being
3.9 with
> the vault updates directory contents merged in.
>
> Is there a straightforward way to do that, or is schlepping around
> folders full of RPMs actually the best way to go?
I'd mirror the vault repository on a local http server, and edit the 
CentOS-Base.repo file to point to it, then you can just run yum update...



-- 
john r pierce                                      37N 122W
somewhere on the middle of the left coast

> What I'm hoping for is some way to get a "CentOS 3.10", being
3.9 with
> the vault updates directory contents merged in.
> 
> Is there a straightforward way to do that, or is schlepping around 
> folders full of RPMs actually the best way to go?
 
 Yes, it can be done. I did it a while back, but don't remember all the
details.

 I merged the updates into the distribution, plus a few yum-related packages
 from centosplus. I *think* I hacked up a comps.xml to create the yum metadata
 with createrepo, but that's only half the story. You also need to update
the
 hdlist and hdlist2 files with /usr/lib/anaconda-runtime/pkgorder and
 genhdlist. There are pitfalls. Best thing is to build a 3.9 vm from just
 the base package and then create all the metadata files on it from the
 combined repo.

On 11/26/2013 02:00 PM, Warren Young wrote:
> I'm about to create a new CentOS 3 VM for testing, since we still have
a
> bunch of deployed machines running that OS.
>
> (Don't yell at me about using old OSes.  These machines won't get 
> "un-deployed" until they fall over dead of natural causes.  Until
the
> last one dies, we need test and build VMs around to service them.)
>
> I have the CentOS 3.9 *.iso files plus a local cache of RPMs against 3.9 
> that is probably incomplete relative to the vault[*].
>
> It seems wasteful to install the last published version of the OS, then 
> scp over my local update RPMs, freshen from those, *then* check with the 
> vault for yet more updates.
>
> What I'm hoping for is some way to get a "CentOS 3.10", being
3.9 with
> the vault updates directory contents merged in.
>
> Is there a straightforward way to do that, or is schlepping around 
> folders full of RPMs actually the best way to go?
>
>
> [*] http://vault.centos.org/3.9/updates/i386/RPMS/
If I needed to do this, I would mirror the 3.9/os/ and 3.9/updates/
directory (and others if you need them)

Then I would create my directory as well in the same tree or even put my
files in 3.9/updates/ as we are no longer putting files there anyway.

Then I would rerun createrepo on the updates/i386 and updates/x86_64
directories and do network installs and run updates.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20131126/580bede1/attachment-0003.sig>

On 11/26/2013 4:38 PM, Johnny Hughes wrote:
> On 11/26/2013 02:00 PM, Warren Young wrote:
>> I'm about to create a new CentOS 3 VM for testing, since we still
have a
>> bunch of deployed machines running that OS.
>>
>> (Don't yell at me about using old OSes.  These machines won't
get
>> "un-deployed" until they fall over dead of natural causes. 
Until the
>> last one dies, we need test and build VMs around to service them.)
>>
>> I have the CentOS 3.9 *.iso files plus a local cache of RPMs against
3.9
>> that is probably incomplete relative to the vault[*].
>>
>> It seems wasteful to install the last published version of the OS, then
>> scp over my local update RPMs, freshen from those, *then* check with
the
>> vault for yet more updates.
>>
>> What I'm hoping for is some way to get a "CentOS 3.10",
being 3.9 with
>> the vault updates directory contents merged in.
>>
>> Is there a straightforward way to do that, or is schlepping around
>> folders full of RPMs actually the best way to go?
>>
>>
>> [*] http://vault.centos.org/3.9/updates/i386/RPMS/
> If I needed to do this, I would mirror the 3.9/os/ and 3.9/updates/
> directory (and others if you need them)
>
> Then I would create my directory as well in the same tree or even put my
> files in 3.9/updates/ as we are no longer putting files there anyway.
>
> Then I would rerun createrepo on the updates/i386 and updates/x86_64
> directories and do network installs and run updates.
I used to do something similar to this, except that in this case I'd 
assume "3.9/os/" and "3.9/updates/" are static, so I'd
probably combine
the RPMS from these 2 trees together (in a subdirectory called "RPMS" 
for instance), and then run:

repomanage -o RPMS | xargs rm -f

so that the outdated/superseded packages would be removed from the 
collection before running createrepo.

-Greg