Comment 10 for bug 666555

Le dimanche 02 janvier 2011 à 22:58 +0000, RnSC a écrit :
> Following up, new system. Gave up on getting 10.04 video to work on my
> system (another story), switched to 10.10.
>
> Created a user named "bugta", user 1001, group 1001.
>
> Tried to use System / Administration / Users and Groups to change the
> home directory of bugta from /home to /lhome. lhome pre-existed, but
> did NOT have a directory in it called bugta.
>
> After prompting me, it created /lhome/bugta and copied the contents of
> /home/bugta into it. However it did not update /etc/passwd. To be
> explicit, the bugta line in /etc/passwd still had /home/bugta as the
> user's home directory.
>
> Repeated the test described in my 2010-11-14 post exactly, except for
> changing the user. The line below was copy pasted from what I typed:
>
> /usr/sbin/usermod -d /lhome/bugta -g 1001 -l bugta -s /bin/bash -u 1001
> bugta >2011.01.02-1709.log 2>&1
>
> /etc/passwd was modified to make the home directory /lhome/bugta.
>
> I believe that this represents a bug in 10.10. The System / Administration / users and groups dialog does not modify /etc/passwd even when the user being changed is not logged on.
So please follow instructions from
https://wiki.ubuntu.com/DebuggingGnomeSystemTools so that we can check
if/why the correct commands are successfully run.

> ---
>
> With regard to modifying the user who is logged on, I believe that
> *somehow* this should work. My need for it *is* driven by how I build
> my systems, which will explain below, but that is immaterial and I do
> not want to cloud my message. It suggest the following:
>
> The issue would arise any time userid, groupid, home directory is
> changed for an active user. If the user is *not* in the user trying to
> make the change, I suggest that the program refuse to make the change,
> and specify that the user must log off and all processes running under
> that user ID must exit before the change can be made. Note that in
> obscure cases that this may still not be sufficient, as any process
> could have information about the target user ID in private memory. The
> only 100% safe thing to do is to reboot. The user could be warned and
> given a choice - log off or reboot.
>
> If the user is the one running "Users and Groups", I suggest that a
> dialog offer the choices of aborting the change, or continuing with a
> unavoidable and immediate system restart without further warning
> afterward to ensure consistency for running processes related to that
> user ID (To avoid giving the user the opportunity to ctrl-alt-backspace
> for example out of the reboot).
>
> I do not like the idea of having to reboot the system for a change, but
> this is a very unusual situation.
Upstream users-admin now prevents changing home dir for active users. I don't
think we should require a reboot because that's not likely to be useful. usermod
currently fails because it checks whether the user is logged in - if
only a few processes are still running, they are not likely to block
changing the home dir. And killing them would be a mess given how the
gnome-system-tools are designed.

> ---
> Why I need this (And a little bit of a soap box):
>
> In general, my user home directories are on a file server. This is
> /home, created by an auto mount map or direct nfs mount. I create the
> accounts on each machine to avoid the complexity of LDAP at the cost of
> 15 minutes work when I rebuild.
>
> The account created during installation I use as a local administrator
> account (naming it administ), which is functional and whole even if my
> network or the file server with the home directories is non-functional.
> But Ubuntu gives me no choice but to create it in /home! So I let it
> create it, then need to move it to *somewhere else* before I can make
> /home refer to my server and activate my other accounts. I choose
> /lhome (local home).
>
> I use the Ubuntu System / administration / users and groups dialog to
> change the home directory (This *is* the mainstream Ubuntu mechanism).
> I guess I *could* create another administrator account, then change it
> from there, then delete the second account. But I feel that somehow the
> system should deal with this situation, not block out a valid change.
usermod refuses to change the home dir of active users, based on the rationale
you suggested above. If you think there should be an override option, file
a bug against usermod. But we should make sure this would theoretically
work. And anyway doing so brings the risk of being locked out of the
only admin account in case something goes wrong - so that's not
something to recommend.

> Regarding using the dialog vs. the command line stuff, I "grew up"
> editing UNIX configuration files such as /etc/passwd and /etc/group,
> creating home directories with mkdir. "man" explained the actions of
> each command, and each configuration file. Life was simple and
> transparent. Today a plethora of dialog boxes provide magical access to
> who-knows-what underlying mechanisms, and maintaining coherence of who-
> knows-what interdependencies. I am afraid to change anything the easy
> way, and instead use the provided dialogs. I fear that Linux is moving
> toward Windows, where everything is opaque and based on hidden magic,
> vs. UNIX where everything was transparent and intuitive to the most
> casual observer. Because the dialogs are not well documented as to what
> they do, one cannot manage the system the old way because you have no
> way of knowing what to do any more.
>
> Hiding the underlying mechanisms is a good architectural principle, but
> I would prefer the simple transparent system with those clearly
> identified as the system interfaces, perhaps with nice helpful graphical
> applications whose stated role is to manipulate those system interfaces
> in well defined and documented (transparent) ways to make the system
> nice for those who cannot type. I like to be in control and secure that
> I can make the system work. Otherwise I might as well buy Windows,
> where everything is easy, confusing, seems to encounter unanticipated
> situations and malfunctions or doesn't work on a regular basis, and you
> can't figure out why or fix it! Please don't take offense, notice the
> direction we are going and think about it! Making it clear what you are
> doing is just as important as doing it. It would only take a page or
> two of text to outline what the "Users and Groups" dialog is doing!
If you know how to use commandline tools and you prefer them, please use them!
users-admin is made to ease the life of people that don't know or like command
line. It wouldn't make sense to expose all the details of the commands
that are run to people that don't want to use them (even if we should
have a nicer error reporting, obviously). And users-admin isn't even
intended for administrators: it's more of a tool for desktop users,
which supports advanced settings as a bonus (and because we lack a
proper tool for admins).

But I don't think dialogs are really obscure about what they do: if you
know how users and groups work on Unix, most settings are transparent.
It's just that the failure of the commands isn't reported correctly.
Sadly, it's nearly impossible to report errors with the current
architecture of the gnome-system-tools, so the best I can do is prevent
common errors from happening.