This really applies to both libuser and the overlying system-config-users.
Description of problem:
As implemented libuser code (and system-config-users code using it) do not
forward information on the default location of user home directories from
useradd's /etc/default/useradd (HOME=) or libuser's /etc/libuser.conf
(LU_HOMEDIRECTORY=). Useradd does take note of /etc/default/useradd.
The code in system-config-users module userWindow.py uses a constant string:
def on_newUserNameEntry_focus_out_event(self, *args):
name = self.userWinUserName.get_text()
self.userWinHomeDir.set_text("/home/%s" % name)
The code in libuser's config.c, etc., simply indicates that HOME-related
features are unimplented.
Version-Release number of selected component (if applicable):
All from Red Hat Linux 7.3 to Fedora Core 5, to the extent I have checked.
Probably all since code was written?
Set HOME in /etc/defaults/useradd or LU_HOMEDIRECTORY in /etc/libuser.conf and
open system-user-config. Assume the setting is appropriate for /local/home.
The new home directory is always in /home, which is perfectly consistent with
the code snippet above, and not surprising given that snippet, etc.
The new home directory will be in /local/home.
Because of the explicitness of the coding, and the references to
"unimplemented," there may be some unstated external interaction issue or
planning consideration. The actual implementation does not look like it would
be particularly involved. It could be cloned from the code present for other
parameters, with some modifications to remove "%n" etc. from the end of the
As far as I remember it is unimplemented simply because the variables have sligtly
different semantics (the necessary /%n at the end).
s-c-users should get the default value of userWinHomeDir by creating a temporary
user entity with the desired login name and reading its HOMEDIRECTORY attribute.
I'm getting way out of my depth here, and so my apologies to the knowledgeable
and experienced. Still, wouldn't it be easier (and less prone to awkward
states in the event of a crash) to read adduser's HOME string and trim off the
%n? It's true that this assumes knowledge of the internal semantics of
adduser, but I'm not clear that the process sketched above relies on adduser
to explain them. Perhaps the adduser HOME-access could be encapsulated
somehow to document the fact that it is reaching into adduser? Most
convenient would be to modify adduser to provide the root of HOME in some
fashion. I imagine it's impractical to change HOME itself.
Creating a temporary user entity does not really create an user in the system
databases; it only creates an in-memory object.
I think this is the most natural way to get the default value, because it ensures
the default value will be exactly the same as when really creating the user.
Adding a separate interface increases the risk that the two implementations
will eventually diverge due to some oversight.
Created attachment 140059 [details]
Use libuser's default for home directory
default/useradd:HOME importing added in libuser-0.54.8.
The attached patch adds the s-c-u part.
Mirek, I've applied your patch in the upstream repo. As FC5 is dead, I'll change
the product version to devel.
This should be long fixed.