I spent some time yesterday figuring out ways on how to assign custom (as in self-built) RPMs to a installation using SMT. First you obviously need a “external” repository, that can be integrated into the SMT.
So we need to create repository someplace, where the SMT can go and grab it. I ain’t gonna cover the sharing part, since that is your job! I’m just gonna cover the steps on how to create the custom repository and how to integrate it into the SMT.
|
1 2 3 4 5 6 7 |
mkdir -p /srv/www/htdocs/custom-rpms/sles10-addons/rpm/{i586,x86_64,src} # copy some RPMs into the respective arch directories cd /srv/www/htdocs/custom-rpms/sles10-addons/ createrepo -o $PWD . gpg --genkey gpg -a --detach-sign --default-key <keyid> repodata/repomd.xml gpg -a --export <keyid> > repodata/repomd.xml.key |
That’s it, you just created a RPM-repository which you could use with YaST/zypper … But since you already invested time into getting SMT up and running, you might want to assign this repository based on the product that is being installed.
Say we have RPMs for SLES10 SP1/SP2/SP3 in this repository for the architectures i586 and x86_64. First you would take a look at the output of smt-list-products and get the ID for the products/architecture you want to assign this to. But since we’re lazy, you could just use this:
|
1 2 3 4 5 6 |
smt-setup-custom-repos $( for i in $( smt-list-products -f csv | egrep "SUSE-Linux-Enterprise-Server.*(i(.*)86|x86_64)" | cut -d, -f1 | sed 's,",,g' ); do echo -n "--productid $i "; done ) --name 'SLE10-Addons' --description 'Additional RPMs not part of SLES10 (i586/x86_64)' --exturl 'http://smt.home.barfoo.org/custom-rpms/sle-10-addons' |
And likewise for SLES11:
|
1 2 3 4 5 6 |
smt-setup-custom-repos $( for i in $( smt-list-products -f csv | egrep "SUSE_SLES.*(i(.*)86|x86_64)" | cut -d, -f1 | sed 's,",,g' ); do echo -n "--productid $i "; done ) --name 'SLE11-Addons' --description 'Additional RPMs not part of SLES11 (i586/x86_64)' --exturl 'http://smt.home.barfoo.org/custom-rpms/sle-11-addons/' |
Now, after smt-mirror has been executed the next time (either by yourself or via the predefined crontab entry), SMT is able to assign this repository to clients. While this isn’t completely true — SMT is able to assign this custom catalog before running smt-mirror, but it just doesn’t make sense, since it doesn’t contain any data — it still works.
Now, once you install the next SLES10/SLES11 (hopefully you enabled suseRegister, that actually gathers the channels), SMT will assign this “update channel” (jesus, why does Novell use so many words for the same damn thing ?), on top of all the others, to your system.
The only trouble with this is, that if you want to install packages from this repository during setup, it’s not gonna work. That’s because YaST (or AutoYaST) first install packages, preps the environment and after prebooting the new system, then runs suseRegister/customer_center … Screwed. Again.
Guess the only way is to add the original repository (no need to automatically assign this, since we can’t install during setup) into the add-ons section of my AutoYaST file.