Posts tagged SLES11

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:

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:

<rule>
   <install_product>
        <match>SUSE Linux Enterprise Server</match>
   </install_product>
   <install_product_version>
        <match>11</match>
   </install_product_version>
   <result>
        <profile>sles11.xml</profile>
   </result>
</rule>

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:

    <!-- Installing SLES11 -->
    <rule>
      <installed_product>
        <match>SUSE Linux Enterprise Server 11</match>
        <match_type>regex</match_type>
      </installed_product>
      <result>
        <profile>sles11.xml</profile>
        <continue config:type="boolean">true</continue>
      </result>
    </rule>

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

    <!-- Installing SLES10 -->
    <rule>
      <installed_product>
        <match>^SUSE Linux Enterprise Server 10</match>
        <match_type>regex</match_type>
      </installed_product>
      <result>
        <profile>sles10.xml</profile>
        <continue config:type="boolean">true</continue>
      </result>
    </rule>

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:

  <general>
    <ask-list config:type="list">
      <listentry>
        <default>xxx.home.barfoo.org</default>
        <pathlist config:type="list">
          <path>networking,dns,hostname</path>
        </pathlist>
        <question>Enter Hostname</question>
      </listentry>
      <listentry>
        <help>Enter the password for the superuser "root".</help>
        <password config:type="boolean">true</password>
        <path>users,0,user_password</path>
        <question>Enter root password</question>
        <stage>initial</stage>
        <title>Password for Root</title>
      </listentry>
    </ask-list>
  </general>
  ...
  <users config:type="list">
    <user>
      <fullname>root</fullname>
      <gid>0</gid>
      <home>/root</home>
      <shell>/bin/bash</shell>
      <uid>0</uid>
      <username>root</username>
    </user>
  </users>

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 …