Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Hello, I'm sort of a novice Linux user and was running into an issue with user migration. I'm trying to migrate users and groups from a RHEL 5.11 install to a CentOS 6.6 install, both systems are 64 bit. Initially I tried to do an rsync of the passwd, shadow, group and gshadow files with no luck. When trying to login with an existing account on the new server I get access denied. I tried to change the password on the new server, but even then it doesn't seem to change the password and I still get access denied. I then tried to tar up the four above files and then extracted them on the new server, but the same issue existed. I also created a new account on the old server, copied all the necessary files over to the new server and still have the same issues. Any ideas what I may be doing wrong or what I can try next? This is getting frustrating!
Distribution: Debian Wheezy/Jessie/Sid, Linux Mint DE
There are a few pitfalls in copying the complete password and groups files. Not for the users, but mainly for system accounts. Since service UIDs might be different on the different machines it is likely that services will fail half or complete because of permissions issues.
The same goes for ordinary users. Permissions were set on a numeric UID (like 1001), but the home directory was set on name (like /home/jlinkels). So if jlinkels has a UID of 1005 in the copies password file, he can't access his directory (which was 1001).
I know, because I did the same as you, and at the instant I pressed the <enter> button I realized my mistake.
Thanks for the response and the additional info. That link is the second way I tried to copy everything over, but maybe I did something wrong the first time so I can give it another shot and see if maybe the second time is the charm?
One thing I forgot about when I used this process initially is that on the old system there isn't a /etc/shadow file, but a /etc/shadow- so I copied that over instead. Could that possibly be causing me some issues too?
Well, still no luck even with this go around. The one user account still won't login with it's original password, or if I change it's password on the new server. However, there is another account that I used as a test account and I was able to change the password on the new server and login with that. So that's strange that the primary (critical) account is possibly the only one that can't login on the new system. Any ideas on what I can try next?
Try manually copying the passwd, shadow, and group entries for just that one account (usually Red Hat will create a group for each user account by default). Once you've done so, please run:
on each machine (replace <username> with the name of the user). Make sure they give identical results. Also, be sure that the shadow file is readable only by root (permissions 0400 or -r-------). Then try to login as the new user *from the console*, and if that works then try remote login (e.g. via ssh). If the "id" command returns the same values but login fails, carefully check the password hash (second column in the shadow file). If they're the same, check /var/log/secure for errors during the login, and post them here if you need help interpreting them.
One of the problems you may be seeing is caused by SELinux. The security labels on files are a binary number - and the two systems do have some differences, as the security labels get regenerated (new labels added, old ones modified...) and the numbers do not have to match.
In addition to the UID/GID usage changing (they change again with RHEL 7/CentOS 7).
One issue that can happen is that UID assignements to system services usually expand. Just replacing the /etc/passwd, /etc/shadow, and /etc/group files is not enough - the system UIDs/GIDs of the target must be preserved.
In RHEL 7, there are a fair number of new ones - things assigned for saslauth (UID 499, GID 76 in RHEL 6) become UID 499, GID 76. New services exist (such as gnome-initial-setup: uid 982, gid 973; sanlock: uid 179, gid 179; dockerroot: uid 979, gid 979) have to be maintained or the system will not be able to update itself properly.
In the case of SELinux a "restorecon /etc/passwd /etc/group /etc/shadow" should do.
But to properly migrate users is a bit more work:
1. ensure the users existing UID/GID and name does not conflict with the new system (user names tend not to conflict, but sometimes test accounts might). Also verify that the security flags used in the /etc/shadow file have not changed definitions...
2. extract the user account entries from the old passed/shadow/group files, update any necessary UID/GID/security entries.
3. append the extracted entries to the new system /etc/passwd /etc/shadow /etc/group files.
Now to the issue of the users files .... The security labels HAVE changed... And the UID/GID values sometimes need to be changed (RHEL 7 starts users uid/gid values at 1000).
4. Users will not have access to their home directory until the UID/GID match the /etc/passwd files, and the SELinux security labels need to be updated too. Using find to replace UID/GID values over the entire home filesystem works... Doing a restorecon -R /home works for the security labels, even if it is a bit slow. And be careful if you have a lot of users. I have had to deal with things like the old UID being changed to a new UID, but the new UID happened to also be used by the old system for a different user. This isn't usually a problem if you are just adding 500 to the uid/gid though... but it depends on HOW you add that 500 and how many users you are dealing with.
Oh, and you DID make backups first, right?
PS, I did leave something out... Sometimes (not in your case though) the password encryption form changes... and you have to manually reset the passwords before a user can login.
Last edited by jpollard; 05-30-2015 at 06:55 AM.
Reason: added PS