Posted by & filed under AWS/Linux/Unix/Devops stuff.

If you are interested in switching from FreeBSD to Linux, you will need to come up with a plan for migrating your user accounts to Linux. Here are some tips, some things to consider, and a tutorial outlining one way to go about this.

If you are interested in switching from FreeBSD to Linux, you will need to come up with a plan for migrating your user accounts to Linux. If your account info is already stored on an LDAP server you won’t have to do much but ensure that the path to your user’s bash shell is /bin/bash rather than /usr/local/bin/bash (if you have installed bash from FreeBSD’s ports system), but you may still want to migrate a few accounts to have around as a backup in case there are problems with accessing your LDAP server. If your accounts are not stored on LDAP, now actually might be a good time to look into doing this (although the details of doing so are obviously outside of the scope of this document), however you might find it easiest to import accounts to your LDAP server using the provided scripts for doing this, and using these scripts requires that you have local Linux based accounts, unless you can find a script that will work with FreeBSD/BSD based accounts. So, one way or another, learning how to migrate your local accounts is probably going to be useful to you. Here is how to do so…

Local accounts created by various services/packages you have installed

Keep in mind that you probably do not want to migrate the accounts created by packages such as Apache or MySQL, as it is probably easiest to allow the packages you use to install these services to do this for you since the UID/GIDs will be different and the names may mismatch what is supplied in the included config files. Ditto for special accounts that were created by the OS itself. With the following instructions, it will be assumed that you will skip migrating these accounts.

Reading /etc/master.passwd

In FreeBSD the account info and passwords reside in this file, whereas in Linux there are separate files for account info and passwords. There are probably a number of superior ways to do the following, this method is admittedly rather crude, but it will work in a pinch. Using awk you can read your /etc/master.passwd and come up with some commands you can use to help to generate both the /etc/passwd (for accounts) and /etc/shadow (for passwords) files.

For generating /etc/passwd:

awk -F: ‘$2 ~/^$/ {print “useradd ” $1 ” -d ” $9 ” -c “” $8 “” -s /bin/bash”}’ /etc/master.passwd

You will then need to copy and paste this output to your shell to create these accounts one-by-one.

For generating /etc/shadow:

awk -F: ‘$2 ~/^$/ {print $1″:”$2″:15282:0:99999:7:::”}’ /etc/master.passwd

This output can be pasted directly into your /etc/shadow file

Notes

  • If you wish you can of course redirect output for both of these to a file (by appending “> /path/to/your/file” to the end of these commands)
  • Again, be sure to weed out accounts that should not be migrated, be careful!

If there is a better way to do any of this, please comment below!

  • Sven

    Thanks, I’ve been meaning to do exactly this because I’m migrating my NAS/ssh server for friends from FreeBSD to linux.

    “If you wish you can of course redirect output for both of these to a file (by appending “> /path/to/your/file” to the end of these commands)”

    That should be >> instead of >. Using > would replace the contents of the file with the output, instead of appending it.

    Anyway, thanks a lot!

  • Dennis Zhang

    Thanks for the info.

    However, if I were about to migrate the whole server (this server is currently used as backup and system logging activities) from the BSD to Linux (CentOS), this user account migration would be part of it. Do you have any idea about this? Thanks a lot

    Dennis

    • NetMusician Support

      I’m not sure what you are asking Dennis, but the above instructions should help with this migration. It might be a good idea to look into moving the accounts to OpenLDAP, since this is OS agnostic. This is what I did, and it works well not just for system logins, but consolidating passwords across all services.