Yes, it should be possible , which version of BBSA are you using ?
in the config file, you can specify multiple os -arch filters, this is for 8.1 , 8.2 :-
Hope this helps
We tried this but get the following error.... It is being run on 8.1 sp3....
[root@centaur bladelogic_patch_downloader]# sh suse_downloader.sh -configFile configs/sles/suse-downloader-config-SLES11-SP1-Updates.new
Suse Downloader failed: Suse downloader configuration xml parsing faile. Error: Config file contains multiple entries of same OS-Arch [SLES11 - x86_64].
Downloader finished with return status - 1
The dowloader xml looks like this:<subscription><os-arch-filter><os>SLES11</os><arch>x86_64</arch><username>xxxxxx</username><password>xxxxx<password></os-arch-filter><os-arch-filter><os>SLES11</os><arch>x86_64</arch><username>xxxxxx</username><password>xxxxx<password></os-arch-filter></subscription>
This is the error
Error: Config file contains multiple entries of same OS-Arch [SLES11 - x86_64].
You have got duplicate tags, both of them are SLES11 and x86_64, these are duplicate! They fetch the same patches so are not allowed.
In this case you dont need two filters,
So how can we then pull down both the SLE11-SDK-SP1-Updates and SLE11-SP1-Updates in the same patch catalog?
Try using a different lable in <os> tag
It should be able to download patches using this.I have not myself used or tested this.
How do you plan to create the patch catalog based on this ? Which filter will you use for each of these ?
Unfortunatley I dont have a 8.1 setup ready to see available filters for SLES 11
Hi.... we tried that but no luck..... Error: Unknown OS
When creating the Patch Catalog we intend to the payload and repo to one Sles 11 dir on the File Server...... more than anything we don't want to have multiple Patch Catalogs covering Sles 11 - SP1 due to possible dependency failures...
Well, I am not sure whether you can specify mutiple URL's in the Os-arch filter or not, with mutiple tags or comma seperated list of URL's in a single tag ! Not sure, but worth a try
If that does not work
The only solution I see is for you to run mutiple instances of Suse downloader at the same time with different Configuration files. each configuration file xml having different URL's as required.
Contact BMC Support to check if this possible by any means, or raise an RFE if it is not.
The only way I could think to do this is run separate runs of the downloader, copy all the rpms you want in the repo into a single dir, and run the downloader w/ the createrepo option on that dir, then point the cuj to that dir.
1 of 1 people found this helpful
I know this thread is a bit old but would like to put my two cents.
This topic has been addressed to me many times when trying to add repositories for later SPs of SLES11 that are not included by default in the BSA product.
In case you need to patch later releases, the inclussion of additional channels, by means of the "SuSE Service Packs List File" under Configuration / Patch Global Configuration / SuSE Linux tab, as described in https://kb.bmc.com/infocenter/index?page=content&id=KA375015
But if you require to have in the same Patch Catalog patches comming from different channels (ie different releases together) or providers (ie adding patches stored in a custom repository), then the approach mentioned by Bill Robinson would be the one I would use.
There is a slight deviation I like to implement: to minimize the network traffic and the update time, what I do is to download the novell patches creating "dummy" repositories [SP specific] and then I invoke the offline downloader using the "createRepo" option just to take the patches and put them together into the same repository.
The reason to do this is that the Patch Update Jobs, will only retrieve the NEW patches in the provider repositories, whereas the Offline downloader is downloading the whole provider repository every time an Update is to be performed.
the target of the offline downloader and the repo location can be the same place. unless you have them separated in your env for some reason.
it would still be a good rfe though. there could be some way to track what was downloaded so as to not download again.