[opensuse-autoinstall] Adding packages to profile triggers error message
Hi, I try to install sles 11 via autoyast. I did an installation from dvd, and pulled an autoyast profile. This profile works, and can be installed via pxe. Now I want to add the following packages: findutils-locate, dhcp-server, bind, apache2, vsftpd, nfs-kernel-server I do this via the gui. I have also tried to do it with an editor, as the gui messed up profiles in sles10sp2. In both cases, after the first reboot, I get the errormessage: "The package resolver run failed. Please check your software section in the aut" [oyast profile] (last part invisible, I guess it should be the software section in my autoyast profile :-)) This a real problem, as I have to confirm this message, thus it stops the autoinstall process. After confirming, the autoinstall process continues. Right bevor 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)" I confirm, and can log in. Theses messages are presistend after reboot. Its annoying, but not a stopper like the first problem. Why is this? Can I avoid this? Isaac -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org
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
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-
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
participants (3)
-
Isaac Hailperin
-
Patrick J. LoPresti
-
Scott R. Corzine