oem-prepare cannot cope if oem creates user (?)

[Ian Jackson]

Binary package hint: oem-config

I installed gutsy 20071016.1 i386 d-i in oem mode in English (with auto-resize of another gutsy test install):

During the oem boot I:
 * Fiddled a bit with the Software Sources to remove the CD entry
 * Installed libadns1-bin using Synaptic
 * Created a user called "guest" using System / Administration / Users and Groups, in the most obvious way

Then I double-clicked on "prepare for shipping to end-user" which appeared to work, and rebooted.

When I rebooted the usual "enter your details" dialogue appeared as expected. I provided my language (Dutch), keyboard (British English) and timezone (Language) and was asked for my name and username and password.

When I confirmed my entering the password for the second time, the X server died immediately (black screen) and I was presented with a gdm prompt. The user and password I had provided during user firstboot did not work (I didn't try the guest user). I rebooted into the other install for forensics and found that the main admin user did not exist.

I presume that this problem was caused by the fact that I created a user during the OEM preparation. I think this ought to be supported.

[Ian Jackson (ijackson)]

I have filed another bug about these events, regarding the poor error handling. That other bug is bug 153311.

[Dragomir Minkovski (dejuren)]

Confirming. When user is created during OEM-user session, it is not possible to create another user during OEM end-user customization, the script ends, and the system is only accessible with credentials of the first user account.

[Loye Young (loyeyoung)]

I've run across this too. What I wanted was to set up every user's desktop to be like the 'oem' model, but I also wanted another user already installed by default. (In my particular case, I needed to have yours truly be able to access the box for customer support issues, so I wanted an "administrator" user who had sudo power.)

Here's how I worked around it:

After the "oem" user desktop was exactly like I wanted it,
[code]
# cp -R /home/oem /home/oem2
[/code]

Search-and-replace through /home/oem2, replacing every instance of '/home/oem' with '$HOME'. (There are half a dozen or so techniques for the forgoing: pick the one you like the most.)

[code]
# cp -R /home/oem2/* /home/skel
# rm -R /home/oem2
[/code]

Then made an ugly hack towards the end of the oem-firstboot script. I told oem-firstboot to run a tiny little bash script ("another-user.sh") I wrote and saved in /temp directory. another-user.sh was extremely simple: a one-line "adduser" command, using the command-line options to give the user name, what groups the user belongs to, password, etc. After another-user.sh runs (exit 0), processing goes back to oem-firstboot. The next line of oem-firstboot deleted another-user.sh. In the case I had, I knew the user wasn't going to be poking around in the scripts, so I wasn't worried about the security implications of having a password in a text file. (I told you it was an ugly hack.)

That's what worked for me, but the problem should of course be fixed the right way.

Happy Trails,

Loye Young

[Torsten Spindler (tspindler)]

I took a look at the code and in lib/components/user.py I see that self.preseed is called or rather set (my guess). preseed is defined in FilteredCommand and calls self.db.set(name,value). I suspect the problem lies here, but I do not know how to debug this further...

[Torsten Spindler (tspindler)]

I tried to isolate the problem in the below script, reusing debconfcommunicator.py and debconffilter.py. Here's the result of a run with debugging of debconf enabled. No user is added to the system, though all debconf calls seem to succeed. Open question is if this script will add any user at all?

# DEBCONF_DEBUG=developer ./toast.py
debconf (developer): <-- VERSION 2
debconf (developer): --> 0 2.0
debconf (developer): <-- CAPB
debconf (developer): --> 0 multiselect escape
debconf (developer): <-- SET passwd/user-fullname Hugo Herrlich
debconf (developer): --> 0 value set
passwd/user-fullname, Hugo Herrlich
debconf (developer): <-- FSET passwd/user-fullname seen true
debconf (developer): --> 0 true
debconf (developer): <-- SET passwd/username hugo
debconf (developer): --> 0 value set
passwd/username, hugo
debconf (developer): <-- FSET passwd/username seen true
debconf (developer): --> 0 true
debconf (developer): <-- SET passwd/user-password herrlich
debconf (developer): --> 0 value set
passwd/user-password, herrlich
debconf (developer): <-- FSET passwd/user-password seen true
debconf (developer): --> 0 true
debconf (developer): <-- SET passwd/user-password-again herrlich
debconf (developer): --> 0 value set
passwd/user-password-again, herrlich
debconf (developer): <-- FSET passwd/user-password-again seen true
debconf (developer): --> 0 true
debconf (developer): <-- SET passwd/user-uid 4444
debconf (developer): --> 0 value set
passwd/user-uid, 4444
debconf (developer): <-- FSET passwd/user-uid seen true
debconf (developer): --> 0 true

[Torsten Spindler (tspindler)]

Some more debugging information. If no non-system user exits, frontend/gtk_ui.py blocks at gtk.main() and waits for the forward to be pressed. If there is a user it continues right away to if self.backup and starts running the scripts (*_apply in scripts directory).

These are the lines the above comment refers to:

            self.allow_change_step(False)
            self.dbfilter.start(auto_process=True)
            gtk.main()

            if self.backup:
                pass

[Torsten Spindler (tspindler)]

After some more debugging it seems to me that the user/user-setup-wrapper script is causing the problem. It is called from components/user.py as command of a filteredCommand object.

I run the script from the command line:
$ DEBUG_DEBCONF developer debconf /usr/lib/oem-config/user/user-setup-wrapper
with and without a user on the system. The diff between the two commands output is attached, I will attach the complete output next.

[Torsten Spindler (tspindler)]

If a non system user already exists user-setup-ask does terminate immediately. This is caused by is_system_user in functions.sh in /usr/lib/oem-config/user

Overriding is_system_user like this will allow to generate a second user during oem-config-firstboot:

# Workaround when there is a user between 1000-29999
is_system_user() {
 return 1
}

[Torsten Spindler (tspindler)]

As user-setup-ask is part of the user-setup package, which is included in oem-config, where would a patch that enables creation of additional users during oem-config-firstboot best reside? As patch of the scripts included in oem-config, or directly in user-setup?

A patch could look like this for oem-config:

user-setup:
export ALLOWMULTIPLEUSERS=yes

user-setup-ask:
change
 if [ "$RET" = true ] && ! is_system_user; then
to
 if [ "$RET" = true ]; then
   if [ ! is_system_user || $ALLOWMULTIPLEUSERS ]; then

This can be combined into one line, though not sure on the bash syntax.

[Colin Watson (cjwatson)]

Patching anything in oem-config is a definite no-no. It would have to go directly into user-setup.

I'd like to think about this a little bit, but some kind of environment variable override for is_system_user sounds reasonable. Rather than checking it every time is_system_user is called, it should just be checked in the function definition.

[Torsten Spindler (tspindler)]

The following patch adds a check for OEMCONFIGUSER in the is_system_user function and will always return true if the variable is set.

[Torsten Spindler (tspindler)]

This patch adds the OEMCONFIGUSER variable to the user setup script in oem-config and will cause is_system_user to always return true, combined with the patch above for user-setup.

[Colin Watson (cjwatson)]

For user-setup's purposes, a more generic name would be appropriate. No need to send another patch, though; I'll change it to OVERRIDE_SYSTEM_USER by analogy with the existing OVERRIDE_BASE_INSTALLABLE elsewhere.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package user-setup - 1.16ubuntu5

---------------
user-setup (1.16ubuntu5) hardy; urgency=low

  * Make is_system_user always return false if OVERRIDE_SYSTEM_USER is set
    (LP: #153310).

 -- Colin Watson <email address hidden> Tue, 04 Mar 2008 10:16:14 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package oem-config - 1.31

---------------
oem-config (1.31) hardy; urgency=low

  [ Colin Watson ]
  * Remove /etc/udev/rules.d/70-persistent-cd.rules and
    /etc/udev/rules.d/70-persistent-net.rules in oem-config-prepare, in case
    the system is going to be cloned.
  * Remove /home/oem/.ssh/known_hosts in oem-config-prepare. If ssh was used
    then this might be slightly sensitive.
  * Allow user creation even if a non-system user already exists (thanks,
    Torsten Spindler; LP: #153310).

  [ Evan Dandrea ]
  * Port zoommap fixes from ubiquity.
  * Automatic update of included source packages: console-setup
    1.21ubuntu4, user-setup 1.16ubuntu5.

 -- Evan Dandrea <email address hidden> Tue, 04 Mar 2008 11:51:16 -0500