In my opinion the behavior you describe (packages autocreating users without consistent userids) is a defect in the package's install code and not in autoyast (nor should it be fixed in autoyast, kickstart, jumpstart, or any other installer).  Removing the user from the autoinst.xml fixes it for a single system but not some larger networks.  Under some circumstances it can even show up on a simple package upgrade. The real problem is that the package is always taking an action (creating a specific user) which should only occur ONCE in the lifetime of that system (complete rebuilds not included).  It's not checking to see whether or not the user already exists and has an assigned uid.  This can easily happen without autoyast:  A package could be (re-)installed at a later time or a network/site wide passwd file or naming service (NIS or LDAP) could already contain an administrator assigned uid (which could differ from the package default).  This is especially important in NFS environments. Any package adding a user SHOULD first check for the existence of the user and only add it if it does not already exist.  As long as "getent passwd $user" returns a useful $? status this can easily be done the following code:     if getent user $user; then         echo User $user already exists     else         useradd $user     fi Or even:     getent $user || useradd $user Note that unless the package has some sort of more globally assigned uid it SHOULD NOT specify one but should let useradd automatically assign one.  Even if the package normally supplies a standard uid (with useradd -u $uid $user) it is best to check first and optionally issue a warning if there is a conflict (sometimes the administrator is forced to change a standard uid/username to deal with conflicts or site policies).  That way people who were not specifically managing their uids get the account automatically created without colliding with a uid that might have already been in use by another user/package while keeping the others happy. All of this applies to groupadd (group and gid) and potentially other things managed by naming services (i.e. in nswitch.conf).  Also it applies to other unix/linux systems and package managers. I remember encountering this with one specific release of the "orarun" package during a SLES major upgrade/rebuild -- it's very bad to have different cooperating Oracle servers using conflicting uids when NFS or RAC is nearby (or just having files with the uids before the upgrade).  I ended up with the choice of: repackaging it, using a different orarun for a different SLES release, or writing a script to run in a later phase that changed the uid incorrectly assigned by the package back to the site-specific value & used something like find -user with chown to fix all of the files with the wrong uid. Please feel free to send this on to the maintainers of the gdm package (or any other package with this issue). -Scott R. Corzine- <scott@ties.org> On Wed, Nov 3, 2010 at 17:10, Patrick J. LoPresti <lopresti@gmail.com> wrote:

On Thu, 02 Apr 2009, Isaac Hailperin wrote:

...

After confirming, the autoinstall process continues. Right before I can log in, I get "Could not update ICEauthority file /var/lib/gdm/.ICEauthority" I confirm, and get: "There is a problem with the configuration server. (/usr/lib/GConf/2/gconf-sanity-check-2 exited with status 256)"

(Sorry to reply to an 18-month-old message, but I thought I would share the solution for the archives...)

I recently encountered the exactly same problem.  I also thought it was related to adding packages to my autoinst.xml.

The problem is described by this Novell KB article, although they do not mention adding/removing packages:

http://www.novell.com/support/search.do?cmd=displayKC&externalId=7006641

The "Could not update ICEauthority file /var/lib/gdm/.ICEauthority" happens because the ownership of the /var/lib/gdm directory is incorrect.  This in turn happens because the "gdm" user is explicitly created by autoinst.xml (as it will when you "clone" a system using "yast2 autoyast"), instead of being created dynamically by the gdm package itself.

My guess is that when you add or remove packages that themselves create users (in my case, it was vsfptd), it changes which UID is assigned to the gdm user when the gdm package itself is installed.  (Both packages call "useradd" without specifying a specific ID, so they will just grab consecutive UIDs on the system.)

Then when you have explicitly listed the gdm user in the <users> section of autoinst.xml, the UID gets changed to whatever it was on the system you cloned.

The solution is to remove the gdm user -- and any others that are created by package installed -- from the <users> section.

This is a very nasty failure mode, by the way.  Perhaps the "clone" functionality of autoyast could be made smarter?

 - Pat -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org

-- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org