The usual IT babble
Posts tagged SLES11
SMT: Disable unmirrorable catalogs
Oct 24th
Today I got this report from my SMT:
WARNING: The following repositories cannot be mirrored.
Maybe you have not enough permissions to download these repositories?
* SLES10-SP2-Pool sles-10-x86_64
* SLES10-SP2-Pool sles-10-i586However, if you try and disable that repository with smt-catalogs -d, SMT is gonna quit your action with “0 repositories disabled“. Since I didn’t want the error to show up again, here’s a quick way on how to disable it.
Open up a mysql shell (mysql -u root -p preferably) and enter those queries:
USE smt; UPDATE Catalogs SET domirror='N' WHERE DOMIRROR='Y' AND MIRRORABLE='N';
Afterwards, if you rerun smt-mirror the warning message should be gone.
Creating a custom RPM repository for SMT
Oct 22nd
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.
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:
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:
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.