SVC: Migrate VDisks off a MDisk Group onto another

Out of necessity, another SVC shell script was just born. If you ever need to migrate a whole MDisk group onto another, you quickly discover the limited application of the SVC GUI. Now, you could query the VDisks using your original MDisk Group and then copy and paste the VDisk’s name (or the VDisk ID) into a command line and simply reuse that svctask migratevdisk command over and over.

Luckily IBM blessed the SVC with an SSH interface. So again, we can write a (kinda) simple shell script which may look like this:

And the execution would look like this:

Or maybe:

ESX: Query CDP information from the command line

I’m just tracing some troubles I’m having with a backup server and two (independent) network adapter ports (as in two ports on two different dual-port nics). If I enable the port and set it to auto configuration, it’ll get 100MBit/Half-Duplex, but the Portgroup becomes unavailable.

In order to get the connection back, I need to logon on the console (thank god even the backup server got an iLO2), and manually (as in esxcfg-nics -s 1000 -d full vmnic1) configure the adapter to 1GBit/s and full-duplex.

Since I didn’t want to go downstairs and trace the damn cables, I figured I could use the CDP features included in ESX. Turn the NICs on as 100MBit/Half-Duplex and run:

That’s all the networking guys should need. Switch’s IP-address and the Switch Port where the card is connected to. *Tada*.

Update: with ESXi 5.1, it’s just vim-cmd …

RPM: Query a specific rpm-file for information

Since I end up googling it each time I need this, it’s about time I write it down … If you want to query a specific RPM for information (Requires/Information/…) you’ll need to use the –package/-p option.

-p <file> — Query a Specific RPM Package File

Up to now, every means of specifying a package to an RPM query focused on packages that had already been installed. While it’s certainly very useful to be able to dredge up information about packages that are already on your system, what about packages that haven’t yet been installed? The -p option can do that for you.

So, if I wanted to show the Requires of my vmware-tools-kmp:

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 …

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: