KMP: Define a new subpkg template

There might be reasons, you’d wish you could make the kernel module package do other things. Two already pop into my head: 1) The mpp-Image upgrades for the ibm-rdac kernel module packages and 2) the “adjustments” which need to be done post install for the VMware kernel module package in /etc/vmware-tools/locations.

What you basically do is this:

  1. Add the new subpkg template to your sources list
  2. Call the %suse_kernel_module_package macro with the option -s and then add your source number

For me this looks like this:

After that, you just need to copy over /usr/lib/rpm/rpm-suse-kernel-module-subpackage to /usr/src/packages/SOURCES/subpkg and make your adjustments to that copy.

For example the diff between those two could look like this:

This is my final version of the subpkg template and I hopefully demonstrated how powerful a customized subpkg template can be!

SMT: Disable unmirrorable catalogs

Today I got this report from my SMT:

However, 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:

Afterwards, if you rerun smt-mirror the warning message should be gone.

Creating a custom RPM repository for SMT

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.

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:

And likewise for SLES11:

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.

Active Directory authentification for Samba on SLES11

I recently “redesigned” the PXE-installation server, which comes with a Samba service to easily move files on/off the box. The old one had the restriction, you need to create local user accounts. Since I also did an distribution upgrade, I wanted to try the integration of SLES11 into Active Directory.

And as it turns out, it really is simple. Just follow the steps outlined in the handbook.

  1. Open the Windows Domain Membership module, yast samba-client (or yast, then Network Services -> Windows Domain Membership) and enter your Domain information
  2. Open the Samba Server Module, yast samba-server (or yast, then Network Services -> Samba Server) and also enter your Domain information

Just make sure, you also check the box labeled Also Use SMB Information for Linux Authentication, otherwise it won’t work — don’t ask me why …

3ware 9550SXU-8LP trouble

My home NAS, powered by a (used) 3ware 9550SXU-8LP, started behaving weird during the weekend. The box would boot one time, but if you’d reboot it again it wouldn’t come back up. Now, since I don’t have a monitor attached to it (I didn’t take the monitor with me when I moved), I needed to borrow one from work — I’m gonna buy a DVI-D to HDMI-adapter soon, since the 42″ LCD-TV is right besides the NAS.

After looking at it yesterday, the 3ware boots up the first time, but when I rebooted the system it would look like this:

After hitting the any key, the system would continue to boot just fine, but without the 2,6TB RAID5 array hosted on the 3ware.

I opened the box up, looked into the case but couldn’t find anything obvious … The controller card was sitting just fine in the PCI-X slot. After powering down the box, I removed the card out of suspicion, blew into the slot, and reseated the card again into that same slot .. guess what ?

It works … been running the system ever since that, without any troubles ❗

Using the integrated kickstart generator

VMware built an kickstart generator into ESX 3.5. You just need to enable it, simply by editing an XML configuration and restarting the webAccess service. Simply edit /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.26/webapps/ui/WEB-INF/struts-config.xml and look for the line saying:

This line needs to be commented out (<– and –>) and the lines following, having those comment marks around them needs to be removed.

After doing that, you should be able to restart the webAccess service, and after that access your ESX host.

If that worked, you should see the Login to Script Installer link on the Dashboard of the Web interface.

Autoinstalling VMware-Tools

As I wrote before, I have been working on our AutoYaST setup. That entitles determining whether or not we’re currently inside a VMware environment. AutoYaST rules wise, that’s pretty easy (even though the MAC-tag is empty :shock:):

The hard part is figuring out ways, to make the VMware Tools installation as pain free as possible. One thing I can’t do, is running vmware-config-tools.pl

Since I already install my VMware-Tools Kernel modules package, I really don’t need to. I just needed to find out, what exactly the configuration script does in order to enable the loading of the modules through the init-script.

Finding that out is rather easy, just copy /etc/vmware-tools/locations to locations.orig on a freshly installed system, run vmware-config-tools.pl and then run a diff of those two files.

There is a lot more within that diff, but the important part about those changes are the CONFED parts. Apparently it’s completely enough (at least for the VMware Tools of ESX 3.5u4) to add those to the locations file. *Tada*

Once you start /etc/init.d/vmware-tools the next time, it’ll load the modules.

IBM SVC: Copy VDisk Host-Mapping from one host to another

As I wrote a few days ago, I started a new job. One of my first (voluntary) tasks was writing a shell script which would copy a VDisk Host-Mapping from a given host to another. This is useful, if you do have a lot of ESX servers for example and a few roaming ones.

Now, if say, you need to do some ESX-Updates and you would like to add the roaming one to a given farm, you would be in a dark an deary place. You would be required to either click through the GUI a dozen times (in my case, it might have needed ~200 clicks) or type svcinfo lshostvdiskmap <examplehosthere> and svctask mkhostvdiskmap <newhosthere> -force (these are incomplete command references) a few times.

Both methods ain’t optimal nor fast. Since the SVCTools (Perl, jikes) don’t really came into consideration, and the SVC SSH interface really doesn’t provide any other method to do a simple cut -d: -f3 (as a hint: if anyone knows a nice method to emulate cut with bash patterns — yeah, I ain’t kidding — please drop me a note!), I ended up writing a simple shell script which is gonna do all the tasks from any Linux system (in possession of the SSH DSA private keys for the SVC of course).

The script looks like this:

SLES11 and AutoYaST

After the first week passed awfully quick, the last week I worked on refining the way on how we are doing openSuSE / SUSE Linux Enterprise Server installations. Up till now, they were done by hand (without a predefined schema) and were getting ugly to maintain. Working my way through the Novell documentation on AutoYaST was pretty straight forward, but the little details were getting hairy. So I decided to write them down, in case someone was gonna end up in the same situation like me.

1. Understanding the folder layout
This isn’t a debate about how you should organize your file system(s), this is a reminder on how to design the AutoYaST profile … If (and probably when) you’re using rules, the layout of the profile directory mentioned in your autoyast PXE line should look like this:

AutoYast folder structure

Keep in mind, that profiles mentioned in your rules.xml, need to be placed in the parent folder, not in the rules folder itself.

2. Rules might not work as you think (ie installed_product)
If you work your way through AutoYaST, you are gonna get to the point where you can’t get around rules. Rules match specific parameters of the target system to a (sub) set of configuration parameters. Now, say you want to create a rule for systems on which you are about to install SUSE Linux Enterprise Server 11. The documentation tells us, to use something along the lines like this:

You’re quickly gonna notice that you’re installation is gonna fail. Why ? Because Novell decided to drop the defined schema and use something else … The tag install_product, when performing an SLES11 installation doesn’t contain ‘SUSE Linux Enterprise Server‘ as you might think, but rather ‘SUSE Linux Enterprise Server 11‘ … notice the difference ? That and the default, that if no match-tag is given, it matches to the exact phrase. So the correct AutoYaST snippet should look likes this:

Another hint when trying to match for SUSE Linux Enterprise Server 10 — say you wanna deploy SLES10SP2. Make sure you make a regex match for that, since — as you might have guessed, I didn’t at first — the install_product tag seems to contain SUSE Linux Enterprise Server 10 SP2 ❗

3. Asking questions during the installation
If you’re in need of asking questions (like “Please enter the hostname” or “Please supply the root password”), you’re gonna need a bit of understanding as well as a few tricks:

4. Working with scripts
Once you get to the point, where you want to embed scripts into the AutoYaST profile, you might up in a situation where YaST literally shoots you in the foot. If you (like me) utilize different profile, and in each profile define a script, YaST is gonna overwrite the tags from the other profile. This sucks, and I ended up placing a dummy script into my master profile.

4. Debugging the rules merging process

Well this is quite troublesome. There is no easy way to do this, no GUI or script telling you what the resulting AutoYaST xml is gonna look like. There are a few helps (like the xsltproc call mentioned in the FAQ — or looking at the output of /var/log/YaST2/y2log concerning your rules.xml) but other than that there really is just fiddling with it.

Right now, I’m stuck working on the determination whether or not the system YaST is about to install happens to be inside a VMware virtual machine or not (simply looking at the MAC address should suffice).

But again, as mentioned in the second point, Novell apparently lacks some consistency. The handbook states the rules tag mac would contain the MAC address … apprently not, the mac-tag is empty … Which leads us to using a custom rules script fiddling with ip, a bit of grep and a simple echo, which works quite well. Just make sure, that you move the output of your script to /dev/null, otherwise you’re gonna sit there and end up trying to figure out why the hell the script works on the command line, but not within an AutoYaST installation …

Loooong time

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.