Bug 204707
| Summary: | libuser (and system-config-users) do not support useradd or libuser.conf home directory definitions | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John E. Koontz <koontz> | ||||
| Component: | system-config-users | Assignee: | Nils Philippsen <nphilipp> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | mitr, nphilipp | ||||
| Target Milestone: | --- | Keywords: | FutureFeature | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-08-14 15:36:03 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. |
FutureFeature applies? 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? How reproducible: 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. Actual results: The new home directory is always in /home, which is perfectly consistent with the code snippet above, and not surprising given that snippet, etc. Expected results: The new home directory will be in /local/home. Additional info: 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 string.