Thank you guys for reviewing the draft design and providing
useful and helpful feedback and comments.
I have reflected all received feedback in updated draft design
below. Updated draft design will be incorporated into
System Configuration SMF Service design specification [b]
along with additional comments received from Gary.
Please let me know if you notice that I missed or misunderstood anything.
Also, I have filed following CRs to capture different issues
pointed out during this fruitful discussion, :
7029410 Make 'Users' configuration screen compliant with PSARC/2010/165
opinion
7030192 'userdel(1m) -r' does not remove ZFS dataset unless that dataset
is mounted
7030216 Installers should consume pam(3PAM) for dealing with password
configuration
7030232 svc:/system/config should take advantage of new useradd(1m)
features when creating user account
Thank you,
Jan
1 Motivation
============
New System Configuration framework [a] currently provides
for post-install configuration of root and user account [b].
While this addresses requirements in area of fresh installation
of Solaris instance, it is not sufficient in scenarios where already
configured Solaris instance has to be reconfigured.
For instance in case of p2v migration or when non-global
zone is created by cloning of existing one.
In these cases, old configuration has to be removed and replaced
with new one applicable for new environment Solaris instance
is running in.
2 Scope
=======
The unconfiguration mechanism will provide for removal of user account
previously created by New System Configuration framework.
User accounts created by other mechanisms will remain untouched.
That will prevent from accidental removal of user accounts which
are not to be a subject of unconfiguration.
3 Problem statement
===================
Provide mechanism for removal of initial user account
and reverting configuration of root account previously
carried out by New System Configuration framework.
4 Requirements
==============
* remove initial user account from the system
* revert configuration of root account
5 Assumptions
=============
It is assumed that the mechanism will always run within target
environment and thus it will not be designed to work on alternate
root.
It allows to take advantage of mechanisms and tools which are
not alternate root aware - smf(5), userdel(1m), usermod(1m).
6 Solution
==========
Start method of svc:/system/config smf service currently takes
care of post-install configuration of user and root account.
For purposes of unconfiguration, this smf service will be enhanced,
so that it could be plugged into smf unconfiguration framework -
see [c] for information about how smf unconfiguration framework
is supposed to work in general.
In particular, new smf 'unconfigure' method of svc:/system/config
smf service will be delivered.
That method will be responsible for removing user account previously
created by this service as well as it will clean up configuration
of root account.
- In order to assure that only initial user account is removed,
- new smf property 'configured_users' of type 'astring' will be
- defined for svc:/system/config smf service.
+ New smf properties will be defined for svc:/system/config smf service
+ to control process of user unconfiguration:
+
+ * 'application' property group 'configured_user' will be created.
+ It will serve as a container for following properties.
+
+ * 'astring' property 'configured_user/login'. It will contain login
+ of initially created user. It will default to empty string.
During configuration, smf start method will store login
of created user account into that property.
During subsequent unconfiguration, smf unconfigure method will
obtain user account to be removed from that property.
If that property is empty or does not contain valid login,
removal of user account will be skipped and a warning
will be logged.
That property will be set to empty string after that.
+
+ * 'boolean' property 'configured_user/remove_home_dir'.
+ If set to true, unconfigure smf method will remove home directory
+ (along with underlying ZFS dataset). It will default to 'false'.
+
+ It will be goal of 'sysconfig' tool to set that property when user
+ explicitly expresses desire to wipe out home directory for
+ to-be-unconfigured user account.
Following chapters specify what in particular would be
covered by unconfiguration.
6.1 user account
----------------
For user account, smf unconfigure method will
* remove user from local databases:
passwd(4), shadow(4), group(4), user_attr(4)
* remove user entry from /etc/auto_home file
* remove home directory along with underlying ZFS dataset
* remove user entry from sudoers(4) file
smf method will consume userdel(1m) utility to accomplish
all tasks above except of the last one.
+ Risk of removal of user account from other than local
+ databases (e.g. LDAP)
+ will be eliminated by limiting userdel to operate
+ only on local databases by specifying '-S files' option.
smf method will manually take care of removing user entry
from sudoers(4) file.
6.2 root account
----------------
For root account, smf unconfigure method will
* remove password hash from shadow(4) file
- (replace it with empty string)
+ (by calling 'passwd -r files -d root')
* change root to normal account if it was configured
as a role.
+ 'userattr type root' will be used to determine if root is a role.
+ It prints role to stdout if root is of type role and exit 0, nothing
+ and exit 1 if type is not an attribute of root.
+ 'rolemod -K type=normal root' will be used to change root to a normal
+ login account. In that case, message will be logged into smf log file
+ to let admin know that switch happened. Existing accounts with assigned
+ root role will be left unmodified.
+ root account itself will be never removed from the system and content
+ of root home directory will be preserved during unconfiguration.
7 Error handling
================
In case of success, smf unconfigure method will exit
with $SMF_EXIT_OK.
In case of fatal error, smf unconfigure method will exit
with $EXIT_ERR_FATAL error code. Following conditions will be
considered as fatal errors:
* CLI tools consumed for manipulating user and root account
(usermod(1M), userdel(1M)) fail.
+ * smf unconfigure method fails to remove entry from sudoers(4) file
+ (assuming one existed).
* Failure when modifying SMF properties.
Reason of failure will be logged in smf log file
of svc:/system/config smf service.
8 Dependences
=============
* smf unconfigure framework
* userdel(1m)
9 Deliverables
==============
* unconfigure smf method for svc:/system/config smf service
* configured_user smf property for svc:/system/config smf service
10 Related documents
====================
[a]
http://hub.opensolaris.org/bin/view/Project+caiman/System+Configuration+Project
[b]
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/scsmfdesignlatest.pdf
[c]
http://src.opensolaris.org/source/xref/caiman/caiman-docs/sysconfig/sys-unconfig-design.odt
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
