Interactive AutoYaST Rules

This article describes a new feature of AutoYaST in openSUSE 11.3 (a backport for 11.2 is available too).

The rules.xml file describes how AutoYaST creates the complete XML profile out of single XML snippet files. Like for example "if the main memory is more than 2GB, use kde.xml, else use windowmaker.xml", "if you find more than one harddisk, use lvm.xml, else use simple_partitioning.xml" ... and so on ...
That's available since ages in AutoYaST what's new now is, that you can present all XML snippets you have to the users so they can select which ones to use on their own.
Confused but curious? Then read on ....

A while ago I read a feature request on the AutoYaST mailinglist that it would be cool to have the <rules> visible and selectable during installation and I was thinking: "Sounds like a good idea. So why not?". So here it is.
People love pictures so lets start with a screenshot:

On the screenshot you can see a dialog where you can choose between two rules where the first one is pre-selected and the second one is greyed out because it conflicts with the first one (I'll explain later what that conflict means).
Lets take a look at the interesting part of the rules.xml file now to see how to create such a dialog.

<rules config:type="list">
...
<rule>
  <custom1>
      <script>
<![CDATA[
echo -n 100
]]>
    </script>
    <match>100</match>
    <match_type>exact</match_type>
  </custom1>
  <result>
    <profile>rules/kde.xml</profile>
    <continue config:type="boolean">true</continue>
  </result>
  <dialog>
    <element config:type="integer">0</element>
    <question>KDE Desktop</question>
    <title>Desktop Selection</title>
    <conflicts config:type="list">
      <element config:type="integer">1</element>
    </conflicts>
    <dialog_nr config:type="integer">0</dialog_nr>
    <timeout config:type="integer">30</timeout>
  </dialog>
</rule>
<rule>
  <custom1>
      <script>
<![CDATA[
echo -n 100
]]>
      </script>
     <match>101</match>
     <match_type>exact</match_type>
  </custom1>
  <result>
    <profile>rules/gnome.xml</profile>
    <continue config:type="boolean">true</continue>
  </result>
  <dialog>
    <element config:type="integer">1</element>
    <dialog_nr config:type="integer">0</dialog_nr>
    <question>Gnome Desktop</question>
    <conflicts config:type="list">
      <element config:type="integer">0</element>
    </conflicts>
  </dialog>
</rule>
<rule>
...
</rule>
...
</rules>

That's not a complete rules.xml but only the interesting part with the two rules that created the dialog you see in the screenshot.
Here comes the description of the single XML elements:

• <dialog_nr config:type="integer">0</dialog_nr>
  
  That's a uniq id for the a popup dialog. All rules with the same dialog_nr are presented on the same popup dialog. This element is optional and the default for a missing dialog_nr is always "0". If you have one popup only anyway, you don't need to specify the dialog_nr.
  


• <element config:type="integer">0</element>
  
  element needs to be a uniq id. Even if you have more than one dialog, you must not use the same id twice like an element-id "1" on dialog 1 and and element-id "1" on dialog 2 too. That's different than with <ask> dialogs, where you can have the same <element> id on multiple dialogs. I'll explain later why this is.
  


• <title>Software Selection</title>
  
  that's a text string at the top of the dialog. A caption for that dialog if you want so and it's optional. If you configure multiple titles for one dialog, the last one is used.
  


• <question>KDE Software Selection</question>
  
  That's the text string behind the checkbox. If you don't configure a question, the name of the XML file that is triggered by this rule will be shown instead (in our example above, that would be "rules/kde.xml" and "rules/gnome.xml"). If you know what's in kde.xml and gnome.xml you maybe don't need the <question> but I'd prefer a short explaining text over just a filename.
  


• <timeout config:type=""integer">30</timeout>
  
  if you don't answer the dialog in "timeout" seconds, AutoYaST will continue.
  As soon as you touch one checkbox or button, the timeout stops for this popup and you have to press "okay" to continue. The next dialog can have a new timeout then.
  


• <conflicts config:type="list">
  
  here you can specify a list of element id's that conflict with this XML file. If you select this XML file, the conflicting one(s) will be deselected and disabled. Be careful what you configure here, you can create deadlocks. An element can conflict with another element on a different dialog and that's the reason why element id's have to be uniq.
  

Whether a question is pre-selected or not is defined by the result of the rule. In my example above, I configured a rule that matches always (100 = 100) and a rule that matches never (101 = 100). Without dialogs, such a rule file would not make a lot of sense because gnome.xml would never be used but here I use them to do the default pre-selection.
So again, if a rule matches, the file (kde.xml in our example) is pre-selected.
That means, if you add dialogs to your already existing rules.xml that has no dialogs yet and you set a timeout, your autoinstallation process will be the same like before, except that you'll see a popup dialog for "timeout" seconds. The rules work like before and you can see which ones have matched in the popups.

To sum things up:

All dialog configuration is done in the rules.xml file. Each <rule> can have one <dialog> which represents one checkbox on a dialog popup. You can have multiple dialog popups and you can have multiple rules (checkboxes) on one dialog popup.


This feature is officially implemented for openSUSE 11.3 but since openSUSE 11.2 is brand new and out for just a few days now, I made a driverupdate_11.2.tar.bz2 to make the feature available for openSUSE 11.2 too. If you want to try it, download and extract the file and copy the "driverupdate" file to the root of your installation source to get that feature on openSUSE 11.2.
Feedback is appreciated.

Thanx to Stacey Murphy and Martin Vogt for the idea.


have fun creating your own rules ;)
Uwe

Meet and Greet with AutoYaST

Bubli said that it might be a good idea to write an article of a very basic step by step instruction for AutoYaST and I had to agree with that. So this is more for people who don't ask questions like "can I use the 'ask' feature for 'rules' in AutoYaST?" ;)

So if you answer those questions with YES, then this article is for you:

• you have never used AutoYaST
• you just have a vague idea of what it is
• you always thought it's too complicated and too much work for "just taking a quick look at it"

if you nodded three times, read on, I wrote this especially for you

What do we need for this tutorial?

• an openSUSE boot CD/DVD like the openSUSE 11.2 DVD
• a USB stick and a way to read/write to that stick (like an installed Windows or Linux system)
• a physical machine for the test run (needs a DVD/CD drive and a USB port). The machine CAN be installed but you'll have the chance to abort the process before anything happened, so nothing will have changed then except that you'll know more about AutoYaST :-)

First of all you have to save the small AutoYaST XML snippet below in a file onto the USB stick. It doesn't matter which filesystem you have on the USB stick. It can be a Linux filesystem like for example ext4 but it can also be fat32 too, as long as openSUSE can mount the stick for reading.
Here is the file we want to use:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns"·
         xmlns:config="http://www.suse.com/1.0/configns">
 <users config:type="list">
   <user>
     <encrypted config:type="boolean">false</encrypted>
     <user_password>s3cr3t</user_password>
     <username>root</username>
   </user>
 </users>
</profile>

copy that file to the USB stick and name it for example "my.xml". You can name it like you want but I'll refer to it by "my.xml". Later we will take a closer look to the XML file but for now we just want to see AutoYaST in action.
Put the SUSE DVD into the machine and plug the USB stick in too. Now boot from that DVD until you see the bootmenu:

Move the cursor to "Installation" and then type "autoyast=usb:///my.xml" to the prompt, like I did on the screenshot. That "autoyast=...." parameter triggers the automatic installation instead of the manual installation. Of course "usb:///..." is just an example and tells AutoYaST to look for the XML file on all USB devices.

After a while, yast will show up and will present you the so called "proposal screen" that you have to confirm if you are happy with the settings. That screen can be seen during the manual installation too, so it'll be familiar to you. You can do all kind of changes now.

To get a real "free-hand" installation you can turn that confirmation screen off in the AutoYaST XML file but the default is to show it and for this tutorial it's a good idea to take that break to see what AutoYaST will do. Nothing has happened so far to your machine. We could turn off the computer now and your system would be the same like before you booted AutoYaST.

Since we did not specify any partitioning in the AutoYaST XML file, AutoYaST will calculate a reasonable partition plan that you can see on the proposal screen now. It might look different on your hardware than on mine in the screenshot because it depends on your hardware and what kind of partitions you already have on the harddisk.

If you look at the software proposal on the screen, you can see that it's quite minimalist. It will only install 526 MB of software, which is just the base pattern and does not even include a X Window system. We can change that in our my.xml file of course but lets click "Install" for now on the bottom right, to start the installation (or turn off the machine if you don't want to apply any changes).

AutoYaST will partition the harddisk now and will install the software, which looks like during a manual installation.
While AutoYaST is doing it's job, we can take a look at the XML file again.
Every AutoYaST profile starts with the same header:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns"
         xmlns:config="http://www.suse.com/1.0/configns">

and ends with the same footer:

</profile>

Everything between the <profile> elements is your configuration.
In our my.xml file it's only the configuration of the root user with the password "s3cr3t". Actually not even that would be needed for an installation but without a root user, you can not login at the end.
You probably want to configure an own software selection too because we already saw that the system which is installing right now is very small.
The partitioning is something many people want to customize too, to have control on how exactly it looks like in the end and to be able to configure more complex setups like LVM or RAID.

So that would add a <software> and <partitioning config:type="list"> section to the profile like this:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns"
         xmlns:config="http://www.suse.com/1.0/configns">
 <users config:type="list">
   <user>
     <encrypted config:type="boolean">false</encrypted>
     <user_password>s3cr3t</user_password>
     <username>root</username>
   </user>
 </users>
 <software>
 ...
 </software>
 <partitioning config:type="list">
 ...
 </partitioning>
</profile>

Since this text is for unexperienced AutoYaST users, I want to recommend to use the AutoYaST UI to configure a profile instead of a texteditor. You need to install the autoyast2 package for that and then you can start the UI by typing "yast2 autoyast" on the command line or by clicking on "Miscellaneous" and then on "Autoinstallation" in the YaST2 control center.

In the meantime our automatic installation should have rebooted and AutoYaST has finished the so called "2nd stage installation" where some post configuration happens. There is not so much to see there and AutoYaST will terminate without user interaction when it's finished. At the end you'll see the login prompt where you can login with username "root" and password "s3cr3t". I think you deserved a delicious piece of cheesecake now ;-)

That's it. The very basic steps of using AutoYaST to install a system. Maybe there will be more articles like this in the future, making the installation more and more complex because this were really just the basics.

Some important links:
AutoYaST Homepage
Archive of the AutoYaST mailinglist
Subscription to the AutoYaST mailinglist

thanks for flying AutoYaST - have fun ;)

P.S.: if you want to skip the confirmation screen, add this to your XML file between the <profile> tags:

<general>
 <mode>
   <confirm config:type="boolean">false</confirm>
 </mode>
</general>

More Timeouts for AutoYaST

Run, Lola, Run!
a famous german movie

Today I want to introduce you some new timeouts you can configure in AutoYaST.
On openSUSE 11,2 you can use timeouts in two new places.

• The feedback popups of your scripts can timeout now if you want


• The ask-dialogs can timeout now too

So even with feedback and ask-questions, you can now have a non-stop installation.
How does it work? Lets start with the feedback dialogs:

<script>
 <source>
<![CDATA[
echo "this feedback will timeout"
]]>
 </source>
 <feedback config:type="boolean">true</feedback>
 <feedback_type>message</feedback_type>
 <debug config:type="boolean">false</debug>
</script>
...
<report>
  <messages>
    <log config:type="boolean">false</log>
    <show config:type="boolean">true</show>
    <timeout config:type="integer">5</timeout>
  </messages>
</report>

This is an ordinary AutoYaST script which makes use of the feedback mechanism and there is nothing special with it except for the new feedback_type. This type can be "message", "warning" or "error" and if you are experienced with AutoYaST, you might notice that these are the same values that you can configure timeouts for in the <report> section.
Your scripts will timeout like you configure it in the report section if you specify a feedback_type for them.
Without that feedback_type, the old behaviour of a blocking popup is used.

On ask dialogs it works a bit different:

<ask>
  <title>Password: root</title>
  <path>users,0,user_password</path>
  <question>Password for root</question>
  <password config:type="boolean">true</password>
  <default>lousypassword</default>
  <timeout config:type="integer">20</timeout>
</ask>

You can configure the timeout in seconds for each dialog and if the user does not answer the dialog in time, it will continue with the assumption that the default value is wanted.
Without that <timeout ...>, the old behaviour of a blocking ask-dialog is used.

Run, AutoYaST, Run!

au revoir, Uwe

One string to rule them all ...

... one string to find them
Lord of the Rings (almost)

On openSUSE 11.2 I did a little change with the handling of how AutoYaST looks for the profile on devices. Currently you have to do it this way:

autoyast=device://sde2/mydir/myprofile.xml

to find the profile on /dev/sde2 in the path /mydir/myprofile.xml.
On openSUSE 11.2 you can use one string to find a profile on every device AutoYaST can find. So with:

autoyast=device:///mydir/myprofile.xml

AutoYaST will look for the profile on every device it can mount and will stop looking when the profile is found. Take care that you use three slashes if you want to use that feature. The old syntax with naming the device still works of course.
Actually that can even make the autoyast=usb://myprofile.xml superfluously because USB devices are found and mounted too with the new feature. I'll still keep the old USB syntax for a while but I might change the code underneath the veil to use the new "devices://" code.

Ciao! - Uwe

Two AutoYaST Features by One Char

and the star char is - The Slash!

Feature 1:
On openSUSE 11.2, if you add a "/" at the end of a filename in the <files> section, AutoYaST will create a directory:

<files config:type="list">
  <config_file>
    <file_path>/myData/</file_path>
    <file_permissions>644</file_permissions>
  </config_file>
...
</files>

Maybe nothing which makes the crowd go wild but might be useful from time to time and saves you from writing a script just for that.

Feature 2:
That's a bit more impressive than the first. If you use a "/" at the beginning of a <package> or <pattern>, you tell AutoYaST to interpret it as a regular expression like this:

<software>
  <patterns config:type="list">
    <pattern>/.*_server</pattern>
  </patterns>
  <packages config:type="list">
    <pattern>/kde4.*</pattern>·
  </packages>
</software>

Beware of using <package>/.*</package> because that will select every package and some of them conflict.

happy slashing ;) - Uwe

AutoYaST and LVM striping

A less known fact of the AutoYaST LVM configuration is, that it can do striping too. The reason for that being less known might be, that I just documented it a few weeks ago, even though that feature was available since ages.
If you now say "I want that!!! What is it good for?" you can read this article. In a nutshell, with striping you spread the harddisk IO across multiple physical devices which increases the IO performance but also the risk of data loss, so never use that without a RAID system below.

How to use that in AutoYaST? Just configure the number of physical devices and the blocksize in KB like this:

<drive>
 <device>/dev/data_vg</device>
 <is_lvm_vg config:type="boolean">true</is_lvm_vg>
 <type config:type="symbol">CT_LVM</type>
 <partitions config:type="list">
  <partition>
   <filesystem config:type="symbol">ext3</filesystem>
   <lv_name>my_data_lv</lv_name>
   <mount>/data</mount>
   <stripes config:type="integer">2</stripes>
   <stripesize config:type="integer">4</stripesize>
   <size>10G</size>
  </partition>
 </partitions>
 <pesize>4M</pesize>
 <use>all</use>
</drive>

That's the same like you would do without striping, except for those two keys:

<stripes config:type="integer">2</stripes>

which is the number of physical devices you use. And:

<stripesize config:type="integer">4</stripesize>

which is the size of a block in KB. So after writing 4kb the physical device will be switched.
That's all you need to activate striping on a logical volume.


happy striping - Uwe

Keep what you got

Let's say the docs present a simplified view of reality...
Larry Wall

Recently I got a bugreport against SLES11 by a customer who uses an undocumented a secret feature of AutoYaST that is quite fancy. It's hidden in the <networking> section and that option can not be configured with the UI. It's called:

<keep_install_network config:type="boolean">false</keep_install_network>

unfortunately that feature is broken on openSUSE 11.1 and SLES11 (that's why there was a bugreport) but will be fixed for openSUSE 11.2 and maybe on SP1 for SLES11.
What does it do? Well, actually you can take it literally. A networking section like this ...

<networking>
  <keep_install_network config:type="boolean">true</keep_install_network>
</networking>

... will keep the network configuration that was created by linuxrc by doing an installation of the system over a network. linuxrc will raise the network then to connect the installation source and with that boolean set to true in the XML file, AutoYaST will copy that network configuration into the installed system. So if the network configuration during the installation is the same you want in the running system, you don't have to configure it in the XML file. Just set that boolean to true and you'll keep your installation network in the running system.

Thanx to Bubli and Michal for supporting me with that bug.

au revoir - Uwe

A new kind of Script

I love flying. I've been to almost as many places as my luggage.
Bob Hope

Since openSUSE 11.2 (not in SLES11) you can use a new kind of script called "postpartitioning-script". That script runs between the pre-scripts and the chroot-scripts after the partitioning is done by autoyast and the system is mounted to /mnt. The fstab is written too but nothing is installed yet, so the system is quite empty currently (and can not be called "system" actually at that stage).
You can mount something into the system for example that was not specified in the XML file but is required during the installation.
The script definition in the XML file is very similar to the other scripts:

<postpartitioning-scripts config:type="list">
    <script>
        <filename>postpart.sh</filename>
        <interpreter>shell</interpreter>
        <debug config:type="boolean">false</debug>
        <feedback config:type="boolean">true</feedback>
        <source><![CDATA[
touch /mnt/a_test
echo Hi
]]>
        </source>
    </script>
</postpartitioning-scripts>

have a nice weekend, Uwe

imag(in)e AutoYaST

"Come to the edge.
We might fall.
Come to the edge.
It’s too high!
COME TO THE EDGE!
And they came,
and he pushed,
and they flew."
Christopher LOGUE

Since openSUSE 11.1 you can use the deploy_image element to use the pre-defined images of openSUSE. I have written an article about that a few weeks ago already. It's very easy to use and can speed up your installation remarkable but it's a bit inflexible.
Today I want to show you an experimental feature of AutoYaST that is available since a few releases and is a lot more flexible and a lot faster too. I did an installation of a kde4 system and measured the time from the proposal screen until the reboot happened and here are the numbers:

kde4 system with RPMs only	1051 RPMs	19 minutes
kde4 system with pre defined images	1051 RPMs	13 minutes
kde4 system with a kiwi image	1031 RPMs	3,5 minutes

All systems were about 2,8GB in size.

What you have to do for that is to create an image that AutoYaST dumps on the harddisk instead of installing RPMs. You specify it like
this in the AutoYaST XML file:

<software>
  <image>
    <script_location>http://10.10.0.162/image.sh</script_location>
    <run_kickoff config:type="boolean">true</run_kickoff>
  </image>
</software>

The kickoff is needed to configure the bootloader.

You can't configure any packages or patterns anymore, because all software has to be in your image. Here comes the image.sh I have used for my test:

#!/bin/sh
# if you don't want to deal with the fstab,
# you can also remove that file from your image
# so the one created by autoyast is not overwritten
# by your image extraction
mv /mnt/etc/fstab /tmp/
wget -O - http://10.10.0.162/kiwi_image.tgz 2>/dev/null| tar xfz - -C /mnt
mv /tmp/fstab /mnt/etc

as you can see, the script AutoYaST will run fetches an image from a HTTP server and pipes it into tar, which will extract it into the /mnt directory. The /mnt directory is the directory where your freshly partitioned and formated system is mounted to during the installation.
So the last question to answer is, how to create such an image? Well, the way you create an image is up to you because AutoYaST can do all kind of things in the script but in my case, I have used kiwi. Install the following packages:

kiwi-desc-usbboot
kiwi-desc-vmxboot
kiwi-pxeboot-prebuild
kiwi-instsource
kiwi-pxeboot
kiwi-tools
kiwi-desc-xenboot
kiwi-doc
kiwi-config-openSUSE-11.1
kiwi-desc-isoboot
kiwi
kiwi-instsource-plugins-openSUSE-11-1
kiwi-desc-oemboot
kiwi-desc-netboot

not all of them are needed but it can't hurt to install them all. Then do (as root):

cp -a /usr/share/doc/packages/kiwi/examples/suse-11.1/suse-oem-preload .

and edit the XML file in that directory. All I did was changing the location of my installation source, removed the example user (I let autoyast configure the users) and changed the patterns to install to "kde4". Then call:

kiwi --prepare ./suse-oem-preload --root /space/kiwi_image

This will take a while and kiwi will install the complete system into that directory. When it's done, all you have to do is to tar that directory into the kiwi_image.tgz tarball and put it on your webserver. Of course you can do all kind of changes to that before you tar it (like removing /etc/fstab, which is created by AutoYaST anyway)

Try it out, create yourself a nice image ;)
Keep in mind that this is still an experimental feature but a nice one to play with :)
Feedback is appreciated.

ahoj Uwe

The minimum profile

"All The Small Things" - Blink 182

On SLES9 the smallest AutoYaST profile had to contain a partitioning and a software section (well, and a user section with a root user if you wanted to login). On SLES10 the software section was no longer required because AutoYaST has chosen a very small system to install (only the base pattern) if no software section was there.
Now, on openSUSE 11.1/SLES11 not even the partitioning section is required anymore. If you don't provide the partitioning information, AutoYaST will ask the storage code of YaST2 what it would suggest in a manual installation to the user and that suggestion is used by AutoYaST too then. Those suggestions are often quite conservative and YaST tries to keep other Linux/Windows partitions intact.

So on openSUSE 11.1 / SLES11 the smallest profile looks like this:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
    <users config:type="list">
        <user>
            <encrypted config:type="boolean">false</encrypted>
            <user_password>myrootpassword</user_password>
            <username>root</username>
        </user>
    </users>
</profile>

well, actually it looks like this:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
</profile>

but you can not login then.

You might say, "that's nice but where is the sense in a totally unconfigured system?" and you are right. There is not so much use in it. All I wanted to show with this article is, that you can try out AutoYaST without configuring a full blown XML file. Now you can start to fill that XML file with flesh step by step, section by section. Put it on an USB stick for example and add autoyast=usb:///my.xml to the boot menu of an openSUSE 11.1/SLES11 DVD and that's it. You just fired up an autoinstallation.

bye bye, Uwe

P.S.: don't forget to buy the latest Diary of Dreams album that is released today ;)

DBus Interface of Amarok2

"Without music, life would be a mistake." - Friedrich Nietzsche

This time I want to write a short article about something completely different than AutoYaST or anything in that area.
Since I switched to KDE4 with amarok2, my little now-playing scripts for amarok and xchat did not work anymore. The interface to query amarok for the data was changed from dcop to dbus and so I had to google a bit and rewrite the eMail-signature script for kmail and write a new little script for xchat too.
So, how to squeeze the information out of the new amarok2? It's quite easy:

qdbus org.kde.amarok /Player GetMetadata

and that's it. qtbus is part of the libqt4 package and you'll get an output of everything that is interesting and that you can parse easily. Here is my little xchat2 script for example:

#!/usr/bin/perl

use strict;

Xchat::register("wumprock","1.0","Amarok xchat info");
IRC::print("Wumprock 1.0 for XChat \cB\cC3loaded\cC0 :)");
IRC::add_command_handler("curplay", "cmd_amacurplay");

sub cmd_amacurplay {
    my $META = `qdbus org.kde.amarok /Player GetMetadata`;

    my ($ARTIST) = ( $META =~ /artist: (.*)/  ? $1 : "-" );
    my ($TITLE)  = ( $META =~ /title: (.*)/   ? $1 : "not playing" );
    my ($ALBUM)  = ( $META =~ /album: (.*)/   ? $1 : "-" );
    IRC::command("/me is now playing '$TITLE' by '$ARTIST'");
}

You can use /cur_play then in xchat to let everyone who cares (and not) know what you are listening to.

I have a smilar script for kmail to, so I can add the "now playing:" line under my signature but it looks quite the same and so I'll not paste it here.·

happy listening - Uwe

Static Text in Ask dialogs with openSUSE 11.2

With openSUSE 11.2 you can use a new feature of the famous ask-dialogs in AutoYaST. You can add static text to a dialog that requires no user interaction.
That makes it possible for you to put some explanation between widgets or you can create a popup that contains only a text and has to be confirmed like "press okay to start the installation".

<ask>
   <question></question>
   <type>static_text</type>
   <dialog config:type="integer">1</dialog>
   <element config:type="integer">1</element>
   <default><![CDATA["I know a man who gave up smoking, drinking, sex,
and rich food. He was healthy right up to the time
he killed himself."

Johnny Carson
]]>
  </default>
</ask>

happy autoyasting - Uwe

AutoYaST and SLP on openSUSE 11.2

Tell it to me and I will forget.
Show it to me and I might remember.
Make me do it and I will know.
Konfucius

Since openSUSE 11.2 AutoYaST supports the SLP. With autoyast=slp you can tell AutoYaST to query via SLP where it can find the profile. So for example, you can burn a DVD with "autoyast=slp" in the isolinux.cfg file and you can use that DVD in different network topologys then because the location of the autoyast profile is configured on the SLP server in the network. Here is a little example section from my /etc/slp.reg file:

# autoyast
service:autoyast:http://192.168.0.1/my_autoyast.xml,en,65535

AutoYaST will fetch the my_autoyast.xml file then from 192.168.0.1 via http. Of course it's not necessary that the SLP server is running on 192.168.0.1 too.
Another cool feature you get when using SLP is that you can choose between different profiles. If AutoYaST gets more than one profile location from the SLP server it pops up a dialog box to let you choose the right profile:

# /etc/slp.reg
# simple
service:autoyast:http://10.10.0.162/part1.xml,en,65535

# lvm
service:autoyast:http://10.10.0.162/part3.xml,en,65535

have a nice week

bye, Uwe

Why to Confirm? (Part 2)

"Anyone who has never made a mistake has never tried anything new." - Albert Einstein

Last week I started with an article about debugging the autoinstallation process. This week I want to publish the second part of it.

Debug scripts
If something with your self written scripts seems to go wrong, you can turn on the debugging of that scripts with the

<script>
    <debug config:type="boolean">true</debug>
    <feedback config:type="boolean">true</feedback>
    ...
</script>

options. If you don't turn on the feedback option, you won't see a popup but you'll still find the logs of your scripts in the /var/adm/autoinstall/logs/ directory. With feedback turned on, you'll see the log in a popup too that has to be confirmed.

Debugging the ask-dialogs
When you use the ask-dialogs and you want to test it without booting into the installation system, you should extract the complete <ask> part from the profile and store it in an own XML file. You can test the dialogs now with:

yast2 ayast_setup setup filename=/tmp/my_ask.xml

That requires that all <stage> entries in an ask-question are set to "cont" (the default is "initial"). If the <stage> is missing or set to "initial", you won't see anything with the help of "ayast_setup" because those dialogs are only raised up in stage one.
Be aware of the fact that all second stage parts of this XML file are really executed. So if there are some post-scripts in your XML for example, those will be executed too and depending on what you do in your scripts, you might end up with a slightly rearranged system :-)
ayast_setup is a very cool part of AutoYaST that can not only be used to debug your ask-sections (or any other second stage section), but also to configure a complete system with an AutoYaST profile from inside the running system (here is a nice article about it).


Problems with rules
If you use the rules feature to create a profile dynamically, you have some options for debugging too. If you want to see the values of the pre-defined rules (like "memsize", "karch", "mac" ....) you can run the client:

/usr/lib/YaST2/bin/y2base ayast_probe ncurses

You can run it in the installation system (by switching to the console via CTRL+ALT+F2 for example) or in an already installed system too (yast2 ayast_probe).
If you are using custom rules based on a shell script written by you, you can run those scripts to see how they behave in the installation environment. They are stored in /tmp/YaST2-...../rule_.... files. You can grep for that tmp dir via

grep 'Writing rule script into' /var/log/YaST2/y2log

That requires that yast has started at least once and autoyast has fetched the XML profile.
If you don't have problems with the rules scripts, but with the merging, you can merge the XML files like AutoYaST would do it to view the result:

/usr/bin/xsltproc --novalid --param replace "'false'" \
    --param dontmerge1 "'package'" \
    --param with "'a.xml'" --output out.xml \
    /usr/share/autoinstall/xslt/merge.xslt base.xml

The dontmerge parameter can be specified in your rules.xml too (see also the merging documentation).

remote logging
if you want to transfer your logfiles (including y2log messages) to a loghost, you can simply pass the parameter "loghost=10.10.0.162" to your linuxrc parameter list. Of course you need network for that (netsetup=1) and your loghost has to accept log messages from the network (for syslog-ng that requires a udp(ip("0.0.0.0") port(514)); in the config file).

If you want to use a serial console for remote logging, pass the following to your linuxrc parameter list:

earlyprintk=ttyS0,115200 console=ttyS0,115200

115200 might be too much for your system so you might have to reduce it and ttyS0 is hardware dependent of course (might be ttyS1 or so on your system). On the remote system you might want to use screen like screen /dev/ttyS0 115200 then.

Still stuck?
If you are still stuck, you can always write a mail to the AutoYaST mailinglist (you have to subscribe to that list if you want to send mails to it).
It's always a good idea to read the FAQ too.

have fun debugging :-)

ciao, Uwe Gansert

Why to Confirm?

"To err is human, but to really foul things up requires a computer." - Paul Ehrlich

y2confirm - the proposal screen

Sometimes it happens that something in the autoyast process does not work like you expect it to work. Like an add-on product is not added or the partitioning looks different than you expected it to look like. What to do now? How to debug the autoinstallation process? That's something I want to shed some light onto now.

If you use a fully automatic installation, it's a good start to turn on the confirmation of the proposal screen like this:

<general>
    <mode>
        <confirm config:type="boolean">true</confirm>
        ...
    </mode>
    ...
</general>

if you don't want to change your profile (for example because it's on a read only media) you can use y2confirm on the kernel parameter command line. So before the kernel and initrd are loaded, add "y2confirm" (either in your PXE config or in the boot menu of the installation DVD). That will make autoyast stop too at the proposal screen before anything has happened (except for your pre-scripts which are already executed at that time) and you can take a look at what autoyast wants to do - you can even change values and if you press the "ok" button, the autoinstallation continues with your changed values.
y2confirm also changes the starting process of the services in the second stage - you can confirm/reject every single service in the second stage then
... anyway... back to stage 1 ...
Imagine you have problems with the software selection because of a failed resolver run, you'll see a red "Software" link in the proposal screen then. Click on that and confirm the software selection then again. A popup will raise up that'll show you the resolver error message.
You can see all added respositories on the Software screen too, so you can check if your add-on section works like expected. That's how the proposal screen might help you to get closer to the root of the problem - click on everything that is red ;)

Log Files
"The logs - the answers are all in the logs" (Wietse Venema - author of postfix)

If you can not get any further interesting information from the proposal screen that helps you to track down your problem, it's time to start to dig in the dirt now. Switch to the console via "CTRL+ALT+F2" and change to the /var/log/YaST2/ directory. There are multiple log files but the y2log file is the one with the most information about the autoinstallation process but there are special log files from the software resolver too. The y2log file might scare you and you need to know what you are looking for (like an url of an add-on) to find anything useful at all and it makes no sense to read the y2log from the beginning to the end.
When you are in stage2 (after the first reboot) you'll find the y2log from the first stage file in "/var/log/YaST2/y2log-1".

Installation via SSH
If I want to repeat first stage tests without rebooting after each test, I add:

usessh=1 nosshkey sshpassword=a

to the linuxrc parameter list (the same place that I mentioned above where you have to add "y2confirm"). Yast will not start then but I can login via "ssh -X" and start it on my own by entering "yast". I can terminate yast as often as I want via"CTRL+c". Keep in mind that when you terminate yast after the partitioning is done, and you want to restart it, you have to umount and "swapoff" the used partitions. The ssh way requires network of course and you can find a list of linuxrc parameters here.

I have splitted this blog post into two parts because it got too large. Read the second part next week.

Happy bug squashing now! :) See you next week ...

au revoir, Uwe Gansert

openSUSE 11.1 / SLES11 and add-ons

Today I want to take you on a little journey into the world of add-on repositories on openSUSE 11.1 and SLES11.
If you want to add an extra repository to your autoinstallation process, like a repository containing all updates or some self created RPMs, you have two options to do so. You can specify it in your autoyast XML file like this:

<add-on>
 <add_on_products config:type="list">
   <listentry>
     <media_url>http://192.168.66.1/11.1_install/updates</media_url>
     <product>SuSE-Linux-Updates</product>
     <product_dir>/</product_dir>
     <name>MyUpdates</name>
   </listentry>
 </add_on_products>
</add-on>

"Buddy, that's nothing new" you might say and you are right, because it's possible that way since SLES10 / openSUSE 10.1 and it's the easiest way to add an add-on.
The other option is something that has changed now and is a bit more complex but you don't have to specify the add-on in your autoyast XML file then.
In the past you could add a file called "add_on_products" to the root of the installation source. The format of that file was pretty simple - too simple for such a complex world maybe because it has changed to a way more complex XML format now. Look:

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
   xmlns:config="http://www.suse.com/1.0/configns">
   <product_items config:type="list">
       <product_item>
           <name>11.1 updates</name>
           <url>http://10.10.0.162/11.1_install/DVD1/updates</url>
           <path>/</path>
           <ask_user config:type="boolean">false</ask_user>
           <selected config:type="boolean">true</selected>
       </product_item>
       <!-- Another product item -->
       <product_item />
   </product_items>
</add_on_products>

The complete format description can be found here.
When you created that file, it's not as easy like just adding it to the root of the installation source to make things fly, because in SLES11 and openSUSE 11.1 every file on the installation source needs a checksum in the "content" or the "SHA1SUMS" file and those files have to be signed. Update for SLES11 SP1 and openSUSE 11.2: the checksum for add_on_products.xml and the add_on_products file is optional now. So if you use openSUSE 11.2 or newer or SLES11 SP1, you can skip the following steps!
I'll guide you through the process of using and signing an add_on_products.xml file now.

Step one is to create the XML file like described above and to copy it to the root of your installation source with the name "add_on_products.xml". Then you have to calculate the sha1sum of that file and store it in a file called SHA1SUMS like this:

sha1sum add_on_products.xml > SHA1SUMS

The file should look like this then (with a different sum of course)

taylor:/space/11.1_install/DVD1 # cat SHA1SUMS
a3813f6a5d64459b3727389bcf632c2038abc627  add_on_products.xml

okay, that was easy right? Now the SHA1SUMS file needs to be signed by your gpg key. I assume you already have a gpg key but if not, you can easily create one like described here. When you have your gpg key, you can sign the file by the following command with your private gpg key:

gpg -b --sign --armor SHA1SUMS

a file SHA1SUMS.asc will be created which contains the signature for the SHA1SUMS file. That means, if you change the SHA1SUMS file from now on, you have to recreate the SHA1SUMS.asc file too.
The installer needs to know your public gpg key now, so it can check the signature of that file. You need to add your public gpg key to the initrd AND you have to store it in a file called SHA1SUMS.key (yes, two places - I'd call that a bug). First of all you need to export your public gpg key like this:

cd /inst/source/openSUSE-11.1/DVD1/
gpg --export --armor $KEYID > SHA1SUMS.key
ls > directory.yast
cp SHA1SUMS.key my-key.gpg

$KEYID has to be replaced by your keyid. Mine is "30FC5F6B" for example and you can see all keys in your keyring by "gpg --list-public-keys". Your key will be in that list too and the id is in a line starting with "pub".

pub   1024D/30FC5F6B 2001-06-13
uid                  Uwe Gansert <ug@suse.de>
sub   1024g/55DBC73E 2001-06-13

now you have to add that key to the initrd in /boot/i386/loader/initrd on the DVD or on your tftp server for PXE booting. Add the key like this:

mv initrd initrd.gz
gunzip initrd.gz
find my-key.gpg | cpio -o -A -F initrd -H newc
gzip initrd
mv initrd.gz initrd

You can take a breath now because you are nearly done :-). You can remove my-key.gpg if you want. The SHA1SUMS file is signed and the key is known to the installation system in the initrd and by the SHA1SUMS.key file. You can verify the content of the initrd by "cpio -it <>
gpg -b --sign --armor content

ATTENTION: don't accidentally overwrite the content.asc file in the root of your 11.1/SLES11 installation source or the conent.key file will not match anymore with the signature.

Congratulation! You made it!


bye, Uwe Gansert