The YaST firstboot utility is a special kind of configuration workflow that can be run after the basic system is installed. It is started on the first boot of the system and guides a user through a series of steps that allow for easier configuration of their desktops. YaST firstboot does not run by default and has to be configured to run by the user or the system administrator. It is useful for image deployments where the system in the image is already configured (read: AutoYaST, SUSE_Studio, KIWI), and end-user should do only the last few steps, like setting the root password.

Enabling Firstboot

To enable running firstboot configuration sequence on the machine, it is necessary to:

• Have yast2-firstboot package installed. Depending on your installation method, this means adding the package to the list of packages to be installed (e.g. for AutoYaST) or that are part of installation image.

• Create the empty file /var/lib/YaST2/reconfig_system. If this file is present on system boot, firstboot configuration sequence is started. YaST Firstboot removes the file when the configuration is done.

Customizing YaST Firstboot

There are two files that control the behavior of Firstboot: the firstboot control file (firstboot.xml) and the sysconfig file /etc/sysconfig/firstboot. The control file defines the steps that should be part of your configuration sequence, in the sysconfig file it is possible to define custom messages and paths to various files.

Customized Messages

Most important texts configurable in sysconfig file is the text shown in the License Agreement screens. For license texts, there are sysconfig variables FIRSTBOOT_LICENSE_DIR and FIRSTBOOT_NOVELL_LICENSE_DIR.

The license text is read from the file ‘license.txt’ or from ‘license_<locale>.txt’. The license texts of the Novell base product are by default installed to the directory /etc/YaST2/licenses/base/ — you can set different value to FIRSTBOOT_NOVELL_LICENSE_DIR if they are elsewhere. Use FIRSTBOOT_LICENSE_DIR to indicate a path to directory containing vendor licence texts; it is preferred to put these license texts into another subdirectory of /etc/YaST2/licenses/.

To show two license texts in one dialog (typically the one from vendor and one from Novell), use ‘firstboot_license_novell’ step in your firstboot.xml file. This client will use the license texts specified by both FIRSTBOOT_LICENSE_DIR and FIRSTBOOT_NOVELL_LICENSE_DIR.

Customized Workflow

The default firstboot workflow can be controled using one single file which uses the same syntax as the control.xml file used to control the complete installation. The firstboot control file consists of workflow and proposal configurations and can be used to add or remove configuration screens depending on the end configuration of the system. The file firstboot.xml is installed with the yast2-firstboot package and can be found at the following location: /etc/YaST2/firstboot.xml.

This file can be modified to match the post installation requirements of the product in question. In addition to the default and pre-installed components, custom screens can be added to enable maximal flexiblity during post installation. Look into the example firstboot.xml file coming with your yast2-firstboot package for more available steps.

Custom Scripts

Not everything can be achieved with already prepared steps, and it is usually not necessary to write your own ycp dialogs.

You can add schell scripts to be executed at the end of the firstboot configuration. Scripts should be placed in /usr/share/firstboot/scripts or in a custom location that can be set using the variable SCRIPT_DIR of /etc/sysconfig/firstboot configuration file. The scripts are executed in alphabetical order of their names.

AutoYaST Support

It is possible to configure the firstboot process as a part of autoinstallation, so the system can be installed with most of the default values set via AutoYaST profile, leaving the rest to the end user during the firstboot sequence.

As a part of autoinstallation configuration, you need to provide all the changes mentioned above:

• Customize /etc/sysconfig/firstboot: it can be done e.g. via Sysconfig Editor in System section of AutoYaST configuration module.

• Provide customized firstboot.xml file and point to its location in FIRSTBOOT_CONTROL_FILE value of /etc/sysconfig/firstboot.

• Enable Firstboot: do it via GUI in Misc/Firstboot section of AutoYaST configuration module or manually by adding the section

<firstboot>
   <firstboot_enabled config:type="boolean">true</firstboot_enabled>
</firstboot>

to your AutoYaST profile.

This is the shortened version of the article published at http://en.opensuse.org/YaST_Firstboot

Martin and Stano created some concept and added new logging functions y2usernote and y2useritem. These log to the new log file, /var/log/YaST2/y2changes (or $HOME/.y2changes).

The question which is still not resolved is how should we use these functions? Which events our modules produce should provide description as “note” and which should provide “items”? What level of complexity should be presented to user? Should we log the real actions, just like commands passed to system agent or rather the explanations of the actions taken? Or both?

Let’s go to the example. The changes are already in FACTORY version of yast2-users packages (yast2-perl-bindings needed as well), so you may even try yourself.

At first, I started logging actions done in Write function. I deleted one user and renamed another. See:

2009-02-05 15:15:55 <item> rivendell User and Group Management module started
2009-02-05 15:16:12 <note> rivendell File written: ‘/etc/group’
2009-02-05 15:16:12 <note> rivendell User pre-deletion script called: ‘/usr/sbin/userdel-pre.local cc 1003 100 /local/home/cc’
2009-02-05 15:16:12 <note> rivendell File written: ‘/etc/passwd’
2009-02-05 15:16:12 <note> rivendell User ‘aa’ renamed to ‘bb’
2009-02-05 15:16:12 <note> rivendell Home directory moved: ‘/bin/mv /local/home/aa /local/home/bb’
2009-02-05 15:16:12 <note> rivendell File written: ‘/etc/shadow’
2009-02-05 15:16:12 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i passwd’
2009-02-05 15:16:12 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i group’
2009-02-05 15:16:12 <note> rivendell Group ‘dialout’ modified
2009-02-05 15:16:12 <note> rivendell Group ‘video’ modified
2009-02-05 15:16:12 <note> rivendell Home directory removed: ‘/bin/rm -rf /local/home/cc’
2009-02-05 15:16:12 <note> rivendell User post-deletion script called: ‘/usr/sbin/userdel-post.local cc 1003 100 /local/home/cc’
2009-02-05 15:16:13 <item> rivendell User and Group Management module finished

Now, it is not bad, but the item “File written: ‘/etc/group’” doesn’t give much detailed info about what was done to that file. Stano proposed printing the diffs of the original and modified one, it could look this way:

2009-02-09 10:05:50 <item> rivendell User and Group Management module started
2009-02-09 11:05:49 <note> rivendell Backup created: ‘/bin/cp /etc/group /etc/group.YaST2save’
2009-02-09 11:05:49 <note> rivendell File written: ‘/etc/group’
2009-02-09 11:05:49 <note> rivendell Comparing original and new version:
— /etc/group.YaST2save    2009-02-09 11:05:49.000000000 +0100
+++ /etc/group    2009-02-09 11:05:49.000000000 +0100
@@ -8,3 +8,3 @@
daemon:x:2:
-dialout:x:16:bb,hh,linux,zz
+dialout:x:16:aa,hh,linux
disk:x:6:
@@ -45,3 +45,3 @@
vboxusers:!:113:jsuchome
-video:x:33:bb,hh,linux,zz
+video:x:33:aa,hh,linux
wheel:x:10:
`
2009-02-09 11:05:49 <note> rivendell User pre-deletion script called: ‘/usr/sbin/userdel-pre.local zz 1003 100 /local/home/zz’
2009-02-09 11:05:49 <note> rivendell Backup created: ‘/bin/cp /etc/passwd /etc/passwd.YaST2save’
2009-02-09 11:05:49 <note> rivendell File written: ‘/etc/passwd’
2009-02-09 11:05:49 <note> rivendell Comparing original and new version:
— /etc/passwd.YaST2save    2009-02-09 11:05:49.000000000 +0100
+++ /etc/passwd    2009-02-09 11:05:49.000000000 +0100
@@ -28,6 +28,5 @@
wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
-bb:x:1002:100:AAA:/local/home/bb:/bin/bash
+aa:x:1002:100:AAA:/local/home/aa:/bin/bash
hh:x:1000:100:hhh:/local/home/hh:/bin/bash
linux:x:1001:100:linux:/local/home/linux:/bin/bash
-zz:x:1003:100:zz:/local/home/zz:/bin/bash
+::::::
`
2009-02-09 11:05:49 <note> rivendell User ‘bb’ renamed to ‘aa’
2009-02-09 11:05:49 <note> rivendell Home directory moved: ‘/bin/mv /local/home/bb /local/home/aa’
2009-02-09 11:05:49 <note> rivendell Backup created: ‘/bin/cp /etc/shadow /etc/shadow.YaST2save’
2009-02-09 11:05:49 <note> rivendell File written: ‘/etc/shadow’
2009-02-09 11:05:49 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i passwd’
2009-02-09 11:05:49 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i group’
2009-02-09 11:05:49 <note> rivendell Group ‘dialout’ modified
2009-02-09 11:05:49 <note> rivendell Group ‘video’ modified
2009-02-09 11:05:49 <note> rivendell Home directory removed: ‘/bin/rm -rf /local/home/zz’
2009-02-09 11:05:49 <note> rivendell User post-deletion script called: ‘/usr/sbin/userdel-post.local zz 1003 100 /local/home/zz’
2009-02-09 11:05:50 <item> rivendell User and Group Management module finished

Here, the user knows more about the real changes, but the log file is getting a bit less readable again… still I think I’d prefer it.

You could see on examples that I don’t really use the advantage of having 2 logging functions. AFAIK Martin’s original proposal was to use items to tell what actions are we going to perform and notes to log the details of such action. This is hardly achievable in yast2-users module (may be better with
others), since at the time of writing we don’t know the “user actions” taken, this is the info which is known when user is clicking in the UI (*). So another idea is to log directly when users is using UI and not at the time of write. See the last example (this is not a full log this time, just part of it):

2009-02-06 15:54:02 <item> rivendell User and Group Management module started
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘bb’ removed from group ‘dialout’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘aa’ added to group ‘dialout’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘bb’ removed from group ‘video’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘aa’ added to group ‘video’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘bb’ renamed to ‘aa’
2009-02-06 15:54:11 <item> rivendell (UI info) User modified: ‘aa’
2009-02-06 16:03:10 <item> rivendell User and Group Management module finished

I think the last method is getting more talkative and actually is not more helpful.

So – comments? Proposals?

(*) Actually it would need to be cached during the UI-clicking and logged at the time of writing only if user doesn’t cancel the actions.