+++ This bug was initially created as a clone of Bug #21333 +++ Description of problem: When creating a user using drakconf, a fatal error occurs if the home directory already exists and "Create home directory" is activated. When running from Konsole I get the following output: Error creating `/home/test': Error creating `/home/test': File already exists at /usr/libexec/drakuser line 588. libuser fatal error: lu_mail_spool_create() called with non-NULL *error How reproducible: Always Steps to Reproduce: 1. Open drakconf -> System -> Manage users 2. Create a user "testuser" and activate the option "Create home directory" 3. Remove "testuser" but do not remove home directory 4. Create "testuser" again activating the option "Create home directory" 5. Fatal error occurs.
Cloned from #21333 to implement the suggestions made by Thomas in #21333:C7 to Mageia 6. Updated packages pushed for Mageia 6. Advisory: ======================== Updated libuser and userdrake packages fixes bugs. When creating a new user with userdrake, if a directory matching the name supplied for the new user already exists userdrake will segfault leaving the new user created but without a home directory or mail spool. This patch fixes that by preserving the existing directory by re-naming it (appending text identifying it as a duplicate along with a date and time) if the user chooses to do so, and then proceeding to create the new home directory in the usual manner and avoiding the segfault. Ownership on the duplicate directory is also changed to root.root thus reserving the handling of security implications for an admin. This allows the new user to log in with a new, clean home directory while preserving the contents of the old directory in case data needs to be migrated. The user is also allowed to choose to not do anything with the existing directory and make different choices in how the new user account is created if they desire. ======================== Updated packages in core/updates_testing: ======================== lib64user1-0.62-8.2.mga6 lib64user-devel-0.62-8.2.mga6 libuser-0.62-8.2.mga6 libuser-ldap-0.62-8.2.mga6 libuser-python-0.62-8.2.mga6 libuser-python3-0.62-8.2.mga6 from libuser-0.62-8.2.mga6.src.rpm perl-USER-2.17-1.mga6 userdrake-2.17-1.mga6 from userdrake-2.17-1.mga6.src.rpm
Keywords: advisory, validated_update => (none)Assignee: bugsquad => qa-bugs
If you added new strings... please update translation catalog and ask for translations on i18n
I'm guessing here that I've done something that is not as simple as I had thought and was not addressed in packager school. I'm not unwilling, but I don't know how to address this. Neoclust noted something wrong on the dev list too. I'm guessing I built the new version tarball in the wrong way???
(In reply to Mike Rambo from comment #3) > I'm guessing here that I've done something that is not as simple as I had > thought and was not addressed in packager school. I'm not unwilling, but I > don't know how to address this. Neoclust noted something wrong on the dev > list too. I'm guessing I built the new version tarball in the wrong way??? i can commit for you in the git if you want ( i just created the distro/mga6 branch ).
CC: (none) => mageia
That would be great. I don't know if I have rights anyway. I found three files to change. NEWS, Makefile (version), and userdrake itself with the four added lines. The change applies to both cauldron and mga6. Do you need anything more?
Assignee: qa-bugs => mrambo
Yuri just replied on the i18n list that he had taken care of the translations. But I think there has to be a version problem. I had assumed that this would become 2.17 and pushed the updates that way for cauldron and mga6. But it looks like userdrake is still 2.16 in git.
You are expecting things to happend too fast :) What Yuri did wat to update translation catalog: http://gitweb.mageia.org/software/userdrake/commit/?id=a49068de12675b30832e46113a2ad922ddbedc58 So that the new lines shows up as lines to be translated. Then he committed the ukrainian translation: http://gitweb.mageia.org/software/userdrake/commit/?id=12971ef508d9aa1cbd3580e178e25d780a7d3661 So now please wait some days so other translators can catch up and get their translations done... after that, update version in git, commit it, tag it and use "make dist" to roll a new tarball... after that upload that tarball and resubmit the package with a bumped rel/subrel...
Ping. The libuser update candidate is still sitting in core/updates_testing unattended to.
AFAIK we're still waiting for translations.
CC: lewyssmith => (none)
(In reply to Rémi Verschelde from comment #8) > Ping. The libuser update candidate is still sitting in core/updates_testing > unattended to. Because it is not in the MADB list of updates to test; possibly because it is not yet assigned to QA - correctly. I tested it previously, and have: lib64user1-0.62-8.1.mga6 libuser-0.62-8.1.mga6 perl-USER-2.16-1.mga6 userdrake-2.16-1.mga6 but see that the versions have been bumped (comment 1), and may be bumped again (c7). Once that is finalised, and it appears as an update to re-test, that will be done.
(In reply to Mike Rambo from comment #9) > AFAIK we're still waiting for translations. Looking here: http://gitweb.mageia.org/software/userdrake/log/ seems many have already updated.. And I think you have waited long enough so you can roll out a new tarball for and get this moving...
I'm pretty sure the tarball is now generated correctly so I'm finally reassigning back to QA. Only the files list at the bottom of this advisory is different from before. Advisory: ======================== Updated libuser and userdrake packages fix bugs. When creating a new user with userdrake, if a directory matching the name supplied for the new user already exists userdrake will segfault leaving the new user created but without a home directory or mail spool. This patch fixes that by preserving the existing directory by re-naming it (appending text identifying it as a duplicate along with a date and time) if the user chooses to do so, and then proceeding to create the new home directory in the usual manner and avoiding the segfault. Ownership on the duplicate directory is also changed to root.root thus reserving the handling of security implications for an admin. This allows the new user to log in with a new, clean home directory while preserving the contents of the old directory in case data needs to be migrated. The user is also allowed to choose to not do anything with the existing directory and make different choices in how the new user account is created if they desire. ======================== Updated packages in core/updates_testing: ======================== lib64user1-0.62-8.2.mga6 lib64user-devel-0.62-8.2.mga6 libuser-0.62-8.2.mga6 libuser-ldap-0.62-8.2.mga6 libuser-python-0.62-8.2.mga6 libuser-python3-0.62-8.2.mga6 from libuser-0.62-8.2.mga6.src.rpm perl-USER-2.17-1.1.mga6 userdrake-2.17-1.1.mga6 from userdrake-2.17-1.1.mga6.src.rpm Thomas, I tried to properly fix up git too but as this is my first experience with git I don't really know if it is correct. Feel free to contact me (IRC, email) if it is found otherwise.
Assignee: mrambo => qa-bugs
Oops, queries added to linked bug 21333
MGA6-32 on Dell Latitude D600 Mate No installation issues (Dutch install) I could not replicate the initial error as I tested already the first update in bug 21333 But tried this one again in MCC: create a new user, delete that one again preserving its home, create it again: a numbered home is newly created without warning. After this update: now when recreating the user a dialogue asks to preserve the existing home. Choosing yes creates a xxxxrenamed-duplicate home. The original home is the default home of the user. All OK for me.
Whiteboard: (none) => MGA6-32-OK
Advisory uploaded
Keywords: (none) => advisory, has_procedure
Testing complete mga6 64 Confirmed the desired behaviour. Validating.
Keywords: (none) => validated_updateWhiteboard: MGA6-32-OK => MGA6-32-OK mga6-64-ok
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2018-0049.html
Status: NEW => RESOLVEDResolution: (none) => FIXED