The code for that is partially in the Windows launcher. The Windows side actually prompts for the user name:
https://github.com/microsoft/WSL-DistroLauncher/blob/master/DistroLauncher/DistroLauncher.cpp#L44

and passes it to ‘adduser’:
https://github.com/microsoft/WSL-DistroLauncher/blob/1f8551f7e2ea22bba2e6fb02f01e7a5f7fb757f3/DistroLauncher/DistributionInfo.cpp#L14

That seems to be a Debian specific tool that also prompts for a password. We don’t have it in openSUSE. When done, the Windows part actually calls into the Linux environment again with ‘id -u’ to get the uid of the added user:
https://github.com/microsoft/WSL-DistroLauncher/blob/1f8551f7e2ea22bba2e6fb02f01e7a5f7fb757f3/DistroLauncher/DistributionInfo.cpp#L44

So in order to also prompt for the password we’d have to write a wrapper like the Debian one or implement another prompt in the launcher. Implementing such a prompt in Windows code seems boring to me. When writing a wrapper, I’d do something dialog based to make it look more fancy. There’s already jeos-firstboot that does something similar already and more. But then the WSL image doesn’t have to be really minimal, which means we have YaST!

So even though WSL doesn’t really boot as it has no systemd it would be still possible to run the YaST firstboot wizard on first start. What modules it launches is configurable via xml file. So leaving out hardware/VM specific things like network configuration it works pretty well:

For the launcher to know the name of the created user a small YaST module was needed to write the name into /run/wsl_firstboot_uid. The launcher fetches it from there.

Using the YaST firstboot wizard also allows to use e.g. the existing registration dialogs on SLE or add other useful configuration steps. One feature I have in mind would be for example is the role selection screen to offer some pre defined package selections for WSL use cases.

Tumbleweed and Leap appx files to test this are available from download.opensuse.org. Keep in mind that one needs to import the certificates used by OBS for signing first.

In openSUSE developers do not perform manual builds on some specially crafted machine in their basement and then upload the result somewhere. Instead all sources are stored in a version control system inside the open build service (OBS) instance at build.opensuse.org. OBS then automatically builds the sources including all dependencies according to defined build instructions (eg spec files for rpms). OBS also automatically adds cryptographic signatures to files that support it to make sure nobody can tamper with those files.

The WSL appx files are basically zip files that contain a tarball of a Linux system (like a container) and a Windows exe file, the so called launcher. Building a container is something OBS can already do fully automatic by means of Kiwi. The launcher as well as the final appx however is typically built on a Windows machine using Visual Studio by the developer.

Since the goal of the openSUSE WSL offering is to have the appx files officially and automatically be produced along with other images such as the DVD installer, Live images or containers, the appx files have to be built from sources in OBS.

Fortunately there’s already a MinGW cross toolchain packaged as rpms OBS and a tool to generate appx files on Linux.

Combining that all together OBS can actually build the WSL appx from sources. The current state of development can be found in the Virtualization:WSL project in OBS. The generated appx files are published on download.opensuse.org.
The current images for Leap 15.2 Alpha and Tumbleweed there are good enough for some testing already so please go ahead and do so, feedback welcome!
Note that since the appx files are signed by OBS rather than Microsoft, there are a few steps required to install them.

Going forward there is still quite some work needed to polish this up. Kiwi for example can’t build the appx directly itself but rather the fb-util-for-appx is called by a spec file. That requires some hacks with the OBS project config to work. On Linux side there’s currently no password set for the root user, so we need a better “first boot” solution. More details on that in a later article. Meanwhile, remember to have a lot of fun…

Keep in mind that nested virtualization needs to be turned on to be able to run the openQA worker inside qemu (pass nested=1 to kvm_intel resp kvm_amd). To conveniently access the web interface, vnc and ssh I added “-net” “user,hostfwd=tcp::8888-:80,hostfwd=tcp::5091-:5091,hostfwd=tcp::2222-:22” to the qemu command line.

As soon as openQA is up and running the remaining steps are easy:

• add the sample Android test cases I created:

  # cd /var/lib/openqa/tests
  # git clone -b android-4.4 git://github.com/lnussel/os-autoinst-distri-android.git android-4.4
  # chown geekotest android-4.4/needles
  

• import the job templates so openQA learns what to do with Android iso images

  # android-4.4/templates
  

• Download android-x86-4.4-r2.iso and store it in /var/lib/openQA/factory/iso
• register the iso image with openQA:

  # /usr/share/openqa/script/client isos post \
      ISO=android-x86-4.4-r2.iso \
      DISTRI=android VERSION=4.4 ARCH=i586 \
      FLAVOR=live BUILD=0002
  

Voilà! If everything went right openQA should now have created a job and the worker should start processing it.

Here are some screenshots and a video of my test run:

Looks like the emulator in the Android SDK is also qemu based. So theoretically it shouldn’t be hard to integrate that one into openQA in order to actually test on emulated phones as well.

1. start the yast2 DSL module
2. follow the instructions of the wizard to set up a new PPPoE device. Enter your user name and password at the provider screen.
3. At the “Connection Parameters” screen uncheck “Automatically Retrieve DNS”. Enter an arbitrary IPv4 address as first DNS server (yast doesn’t accept IPv6 there yet, bug 665516).
4. finish the wizard and leave yast
5. open /etc/sysconfig/network/providers/provider0 (or whatever name was chosen by yast) in an editor
6. change DNS1 and DNS2 to the actual IPv6 addresses of your provider’s name servers
7. add the following line to the file:
   PPPD_OPTIONS="noip +ipv6 ipv6cp-accept-local"
8. save and quit
9. Done! You may now use cinternet or qinternet to dial in and enjoy the (rather empty) IPv6 internet.

There have been complaints that every SuSEconfig run also calls SuSEconfig.permissions which leads to changed file permissions at unexpected times. Therefore I’ve modified SuSEconfig.permissions to only actually set permissions when called explicitly (ie SuSEconfig –module permissions). When called by a generic SuSEconfig run SuSEconfig.permissions now only shows files with wrong permissions but doesn’t actually fix them anymore.

Since packages that have files with special permission handling do call SuSEconfig.permissions explicitly via %run_permissions in %post the change above alone isn’t sufficient to avoid surprises. Therefore I’ve introduced the new macro %set_permissions. This macro expects file names as arguments. Only permissions of those files are adjusted then. To notify packagers of that new method an rpmlint check now issues an informal message if %run_permissions is used.

Originally the script assumed an infinite number of build hosts ie
maximal parallelism. That’s a good method for visualizing the
bottlenecks. In reality the number of build hosts is limited though.
So I’ve added options to run the simulation with a fixed number of
build hosts and different algorithms to choose which package needs
to be built next. By using the script in a loop it’s even possible
to produce an animation:

The image shows the amount of blocked, scheduled and currently
building packages at each point in time

Source code is available at gitorious if you want to try it out yourself.
You need an account in the openSUSE build service as mkdiststats
uses osc to download dependency information.

Packages for openSUSE 11.1 are available from the openSUSE build service. You also need to update SuSEfirewall2 from that repo. Source code repo is available at gitorious.

Firewall Zone Switcher is *not* meant to be some kind of ‘Personal
Firewall’ that confuses the user with all kinds of low level stuff.
It’s neither a Firewall configuration tool. That job is still left
to Admin tools like YaST. Firewall Zone Switcher settings are
temporary and are reset to the system defaults on reboot.

Firewall Zone Switcher consist of a DBus service and a system
tray applet. Both are written in python currently to have proof of
concept program quickly. Packages are available from the openSUSE
build service. You also need to update SuSEfirewall2 from that
repo. Source code repo is available at gitorious.
Keep in mind that the app as well as the patch to SuSEfirewall2 are just proof
of concept ie experimental so there will be bugs. Feedback welcome nevertheless