The usual IT babble
Posts tagged SLES10
AutoYAST and custom swap partitioning
Jun 3rd
Well, we’ve been discussing our swap partitioning the last few days at work, and I finally got around to implementing it. Again, it proved to be kinda hard, basically because AutoYAST decides to do things differently. More >
SLES10 not installing boot loader in MBR
Jun 3rd
Well, as I mentioned in my earlier post, I had some trouble during the week. I was having issues with SLES10 installations not finishing during the bootloader installation phase. After trying out different flavors (as in 10SP2 x64/x86, …), and not having any luck with this, I went searching on Google as a last effort try. Guess what, yet again Google helped me out!
It was pretty simple. Putting /dev/cciss/c0d0 into /boot/grub/device.map as (hd0) made the grub-installer finish. Now, figuring out how to transfer those information during the installation proved difficult. I was just about to give up, while reading through the AutoYAST documentation, when it struck me. There is even an extra chapter for this stuff, so simply putting the following into my profile solved my issues:
<bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/cciss/c0d0</linux> </device_map_entry> </device_map> </bootloader>
Configuring nagios-plugins-zypper
Nov 12th
Since I’m running check_zypper via nrpe (which in turn runs as nobody), I need to set up sudo. In order for the plugin to work, we need to add the following line to /etc/sudoers (by means of visudo):
nobody ALL = NOPASSWD: /usr/bin/zypper sl, /usr/bin/zypper --non-interactive --no-gpg-checks --terse list-updates
(Keep in mind this needs to be a single line …)
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.
Loooong time
Oct 10th
It’s been very quiet around here, I’ve been rather busy with my real life. During that busy time, a lot of things happened. I switched jobs starting on October 1st, I’m now working in Karlsruhe (as compared to the 870km northern Greifswald). It may sound far, but it’s actually quite pleasant. You know, I was born down here (well not exactly here — 70 kilometers afar) and I still had the feeling that this is my home.
My tasks haven’t changed that much, I’m still doing
- VMware Virtual Infrastructure (as compared to vSphere)
- IBM Storage / Brocade SAN (was IBM Storage / Cisco SAN)
- Storage Virtualisation Controller (we were just buying that before I left)
- SUSE Linux Enterprise Server 10/11 – Deployment and Management (is pretty much the same as before)
What I don’t do any longer is Windows. That is, per se not completely right, since Virtual Center only runs on Windows boxen, but pretty much my whole work focuses on Linux and Storage. It’s as I argumented in the the interview a step ahead, since I’m specializing myself into a certain direction (whether or not that works out — I can’t tell yet. Time is gonna tell me that).
In my first week I spent some time getting to know the co-workers, working my head into the SVC (I already had a somewhat theroretical — and practical — insight, but not deep enough to actually make do with it). Next on my list is the AutoYaST environment for SLES-boxen / Kickstart for ESX(i), which (hopefully) enables us to standardize server installations using common schemas and partitions layout.
Also on the list is building a two-node test environment for the SVC so we don’t break the live environment with some tests we might be doing. Next on the list is some accouting to bring the settlements for the resource utilization based on vCPU/vMem upon a solid, up to date foundation.