The whole point of our patching is so you don't need the satellite server...
What you want to do is setup the 'offline' repo type and point the patch repo at the channel directory on the satellite server that contains the rpms for your redhat version/arch. blade will have to generate it's own metadata, on the redhat server, and you'll need an agent, and possibly nsh installed on the satellite server.
The client needs to download the metadata and the patches upto a certain date, but I realized that we should be able to do this using the BL
method simple by creating multiple patch catalogs and also by ignoring all the patches past a certain date. This basically simulates their usecase.
Also, another reason was to get CentOS patching working with this method. right now they are using the satellite server to patch CentOS. They didn't want to use two different methods to do the patching, The BL RedHat way and the BL VPC for CentOS.
Bill - switching this discussion from the older thread (VPC) to this one (BBSA 8.x).
We are also trying to leverage RH Satellite in an isolated network. Client still wants to use RH Satellite for some of the devices they are responsible for, while BBSA is responsible for patching another set of devices (CLM-customer). We don't want to duplicate efforts re-importing RHN content from internet into this isolated network.
We got the RSCD agent installed in the RH Satellite server, but see that the /var/satellite directory structure is a bit more complicated than anticipated:
---> NULL (which contains ALL of RHN import)
-----> (and so on. Each directory at this level then contains another sub structure where RPMs reside)
---> 1 (ID of ORG setup in Satellite, which may contain subset of RHN content).
---> <same structure as above>
The challenge I see is that even if I point the Offline patch catalog to the directory above (such as /var/satellite/redhat/NULL), and it spyders the subdirectories for RPMs, it still is expecting the RHES5x86_64.xml file that is generated by the Offline Patch Downloader. I dont believe the Offline Patch Downloader will generate all of the metadata it needs by itself.
if you can get the RPMS for a particular 'channel' into a dir, you can use the 'createrepo' option w/ the downloader to generate the metadat. search in the 8.1 or 8.2 user guide for 'createrepo' and that will show you what to do.
Yeah I was thinking about that. Thanks.
would the createrepo option cycle through all the directories as explained above to create the metadata for all the rpm's availalbe or does it need to have all rppm's in one directory (without any subdirectories) to work?
Rpms in one directory per os/version tag.
thanks Bill Robinson, not what i wanted to hear but ok
so there is no way of making BSA checking the sattelite server where we do have all the patches and create the metadata BSA needs, instead it needs to "duplicate" all the patches on the BSA server (or fileserver location) to be able to use BSA for patching right?
It requires that you have a helper server (which can be the file server) that stores all of the rpms in a single directory per os/version tag and then metadata is generated w/ that directory structure. right now it’s not possible to point bsa at a satellite server.