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.

Failed to get repomd/repodata.xml; Reason: 530 – Access denied

So my fellow co-worker turned on the debug-logging and we quickly found out why: rug isn’t using the command line credentials I was passing.

Now I only need to find out, why rug isn’t using them, and how I’m able to pass username and password to rug .. Or not, after looking through the Novell community, I found bug 204741 in Novell’s bugzilla. Guess, what .. It’s marked WONTFIX (or whatever, I can’t view the duplicate bug).

Though the problem seems to be not limited to virtual systems alone, I just browsed through this Novell Forum thread which pretty much describes my problem. I found the same error in the VM’s I tried to mount a CD image.

kernel: ide-cd: weird block size 524288
kernel: ide-cd: default to 2kb block size

Only difference between my behaviour and the one described, is that the virtual maschine is switched off immediately after you try to mount a CD image.

Now, this guy is saying Novell is working on it … But you’re gonna have to ask the question, why in gods name did such an update get through QA ? Or ain’t there no QA for updates ? *shrug*

In the afternoon, when my co-worker decided to go home (that was ~1500), I decided to revert back to the old patch level. But that isn’t as easy as you think (at least on SLES). The only thing I wanted to do, was something like this:

$ emerge '
Looks like SuSE (or Novell who bought SuSE sometime 3 or 4 years ago) doesn't consider reverting to an older patch level. Which means I would have to remove apache2, apache2-prefork, apache2-mod_php4; fetch the basic RPMS from our FTP server (which sadly forbids directory listing, so I can't exactly look for the original RPMS) and I tried to blindly to fetch them.
Foooked. Didn't work .. now I cron'ed the POS to restart every half an hour, so at least we have *some* solution. Will see about reverting the the last patch tomorrow again, hopefully I'll find the original RPMS.
]]>
			http://blog.barfoo.org/2007/03/08/sles-9-once-again/feed/
		1
		
		
		
		http://blog.barfoo.org/2006/03/10/bitching/
		http://blog.barfoo.org/2006/03/10/bitching/#comments
		Fri, 10 Mar 2006 19:57:11 +0000
		Christian
				
		
		
		
		

		http://blogs.barfoo.org/phreak/?p=63
		
			Once again, I’m compelled to play (other call it administering  ) with our TYPO3 cluster (which is sadly running SLES).

One thing I just learned about SLES (for the ones curious, its Novell’s SuSE Linux Enterprise Server and yes, it suffers the same pain as SuSE/openSuSE). They split one single config file (at least the apache2 one) into 9 (or more) different files.
Another thing is, for what the hell does a simple LAMP need a full blown Xorg w/ KDE installed ?
Good lord! Praise the USE-flags (f.e. -X or -kde)
]]>
			http://blog.barfoo.org/2006/03/10/bitching/feed/
		0