Bugzilla – Bug 4215
AI doesn't set 'root' role and 'Primary Administrator' profile
Last modified: 2009-03-30 14:37:42 UTC
You need to log in before you can comment on or make changes to this bug.
When looking at the system installed using AI, user is not assigned Primary Administrator profile and role is not set to root. Following line is missing in /etc/user_attr file: jack::::profiles=Primary Administrator;roles=root Also 'root' is not set to role, since 'type=root' is missing in that file. For LiveCD case, this is taken care by Distribution Constructor (DC) and ICT. 'slimcd_bootroot_configure' script takes care of those tasks for DC: # Give jack administrator profile and convert root to a role $SED -e's/^root::::/root::::type=role;/' ${BR_BUILD}/etc/user_attr \ >${TMP_DIR}/user_attr echo "jack::::profiles=Primary Administrator;roles=root" >>${TMP_DIR}/user_attr $CP ${TMP_DIR}/user_attr ${BR_BUILD}/etc $RM ${TMP_DIR}/user_attr Then ict_set_user_role() ICT modifies /etc/user_attr file for newly created user account: /* * If a user login has not been specified then clear out user jack, * and switch root out of being a role since no other user has * been created. * * If a user login has been specified make that user * a primary administrator. * */ if ((login == NULL) || (strlen(login) == 0)) { (void) snprintf(cmd, sizeof (cmd), "/bin/sed -e '/^jack/d' -e 's/type=role;//' %s >%s%s", USER_ATTR_FILE, target, USER_ATTR_FILE); } else { (void) snprintf(cmd, sizeof (cmd), "/bin/sed -e 's/^jack/%s/' %s > %s%s", login, USER_ATTR_FILE, target, USER_ATTR_FILE); } For AI, it seems that the implementation should be slightly different. We should be applying the same set of rules. However, we should not rely on content of /etc/user_attr in AI image, but /a/etc/user_attr should be directly modified instead, since the intent for AI is to isolate Automated Installer environment from final installation as much as possible.
Long-term this needs to be configured by the manifest (set roles associated with a username, specify whether root is a role) but for an interim fix, behaving similarly to slim as Jan suggests would be OK.
Since it is already past the codefreeze for 2008.11 release, we are only putting back fixes for stoppers. Moving this bug's Target Milestone to 2009.04.
I think of AI as an Enterprise tool for network installation. However, this bug also occurs on single workstation upgrades. It was present after I did a snv-86 to 100a to 101a upgrade done over three days; 101a was not released at the time of the 100a upgrade. The Release notes document this as an AI bug, but this classification might mislead upgraders and cause them to miss the documented fix. For upgraders the time frame for a fix may be more pressing.
(In reply to comment #3) > I think of AI as an Enterprise tool for network installation. However, this > bug also occurs on single workstation upgrades. > > It was present after I did a snv-86 to 100a to 101a upgrade done over three > days; 101a was not released at the time of the 100a upgrade. > > The Release notes document this as an AI bug, but this classification might > mislead upgraders and cause them to miss the documented fix. > > For upgraders the time frame for a fix may be more pressing. Please be specific about the problem you encountered; the problem described here is in fact completely specific to the automated installer, so if you saw something on updates, then it's a different problem and should be filed as such.
(In reply to comment #4) > (In reply to comment #3) > > I think of AI as an Enterprise tool for network installation. However, this > > bug also occurs on single workstation upgrades. > > > > It was present after I did a snv-86 to 100a to 101a upgrade done over three > > days; 101a was not released at the time of the 100a upgrade. > > > > The Release notes document this as an AI bug, but this classification might > > mislead upgraders and cause them to miss the documented fix. > > > > For upgraders the time frame for a fix may be more pressing. > > Please be specific about the problem you encountered; the problem described > here is in fact completely specific to the automated installer, so if you saw > something on updates, then it's a different problem and should be filed as > such. I've submitted this as a new bug related to upgrade.
See also bug 4885. We'd really rather set up sudo and not the Primary Administrator profile.
*** Bug 7274 has been marked as a duplicate of this bug. ***
Added Commit to fix: 2009.06-02 in Whiteboard field
ict_set_user_role() will be modified to take the transfer mode as an argument. For IPS mode transfers, the target /etc/user_attr file will be directly modified with the configuration.
Fixed in changeset d18198e6514f93f064ee74eecbb852f78f3888dc
This fix appears to break the installed image. After the initial install and upon first reboot the following messages are seen on the console for each service being started: Mar 30 07:13:13 svc.startd[7]: Could not set reconfiguration property: Not ownerup' swVersion='latest' Mar 30 07:13:13 svc.startd[7]: Could not initialize state for svc:/system/boot-archive:default: Not owner. Mar 30 07:13:13 svc.startd[7]: Could not commit state change for svc:/system/boot-archive:default to repository: Not owner. Ultimately the system drops into maintenance mode. The problem appears to be an incorrect entry in /etc/user_attr. The modified entry, in /etc/user_attr, being generated by this piece of code is missing a colon (:): + /* Change root entry to be of type 'role' */ + (void) snprintf(cmd, sizeof (cmd), + "/bin/sed -e 's/^root::::/root:::type=role;/' " + "%s%s > %s", target, USER_ATTR_FILE, tmp_ua); The sed command should be: /bin/sed -e 's/^root::::/root::::type=role;/'