On 03/17/11 08:41 PM, Gary Winiger wrote:
On 03/17/11 11:08, FRANK LUDOLPH wrote:
Jan,
Removing existing user home directories can cause critical data loss so
it should require a specific manual option to remove user accounts and
data and not automatic and implicit in the command. The same could be
said for the root account.
So I would suggest that the base unconfig not touch either the root or
user accounts and that specific options be provided/required to remove
them.
Isn't the point of sys-unconfig to set the system back to the
initial "factory" conditions, i.e., no user data? Particularly
if you do group:users.
Hi Frank, Gary,
thinking about this, I can see there might be scenarios where we
might want to unconfigure user account without removing its
home directory.
In particular, since home directory resides on shared ZFS dataset,
it is shared across all BEs created as clone of master BE. So in this case,
if we removed home ZFS dataset, it would affect not only BE
to be unconfigured, but all its 'siblings'.
Based on that, I think design could be changed/enhanced
in following way:
* define new 'application' property group 'configured_user'
for svc:/system/config smf service.
* define new 'astring' property 'configured_user/login'.
That will contain login of initially created user.
* define new '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. E.g. one could do something like
sysconfig unconfigure -g system -r
where -r would trigger setting configured_user/remove_home_dir
to true.
root account is never removed from the system and content of root
home directory is left untouched during unconfiguration.
Frank, might that address your concern ?
Thank you,
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss