I got a new server for my home, more to come on that later. Right now I want to talk about my worthless account management practices. You see, a long time ago (4 years) in a land far far away (2 counties), I was a system administrator. I knew all the best practices. I could plan a server migration with zero downtime or if some DT was required could minimize it. I could keep my servers up with 3-4 9’s (99.99?%).
I think I’ll compare my situation to that of the super clean janitor who invites you into their home only to reveal that they live in squalor. My home server works, but it is a mess. So it is wholly appropriate that when it came time to replace my aging server with 3-4 years of Linux cruft (initially installed with Breezy Badger and then upgraded) that I throw caution to the wind and just install Linux and see what kind of problems I run into.
Well, the first problem I run into is that my baby cannot watch her Baby Signing Time DVD rips from the server — I know ripping DVDs is a violation of the DMCA, but Jeff Atwood says it is OK, so if you are an MPAA lawyer, please see Jeff, he is a top-10 blogger and must have way more money than I do — the XBMC wouldn’t work. Well DUH! The only account on the new system is mine. I hadn’t created any XBMC account for the samba share, nor had I set its samba password.
Since I’m sure many other people might reinstall and not upgrade, but would like to not have to reconfigure everything, this is my little migration guide. I’ll assume that you have a backup or your old hard disk lying around and that you are capable of getting at the needed files in some way. In my case, my old root file system is mounted /mnt, so when you see /mnt paths in these commands, just remember that is my old disk.
Jay’s Stupid Guide to Account Migration
First, it is important to keep in mind that Ubuntu, Debian and AFAIK every Linux distribution these days creates necessary system user accounts for you on demand. e.g. I didn’t have a bind account and group on my system until I installed the bind9 package. This means the the uid/username map will most certainly be different between your old system and your new system. I’m OK with this. I want a new system. I just want some old user accounts.
Visual Inspection
$ cat /etc/passwd
….
jrwren:x:1000:1000:Jay R. Wren,,,:/home/jrwren:/bin/bash
janice:x:1001:1001::/home/janice:/bin/bash
sbak:x:1003:1003::/home/sbak:/bin/bash
….
Cool, so there is my account, and there are a few others. One for my wife, one for a great friend, and I left out a few more. But there aren’t too many, so if I had to manually do this, I could do that. If I really had to copy and paste lines in passwd and shadow I could. But I won’t.
Let Them Login
Use your eyes and know your regex. In my case the uids for all of the accounts I wanted moved were 1001-1007, so I confirmed that my regex was correct and then just appended via pipe using tee.
$ grep x:100[1234567] /mnt/etc/passwd | sudo tee -a /etc/passwd
I could now run the “id” command for these new users and it would work! Neato.
But I’d like them to be able to login with their old password in case they were at some place without their ssh public key, so I set out to do the same thing with shadow. Shadow is keyed by username, not uid, so we just have to map back to that.
$ grep x:100[1234567] /mnt/etc/passwd | awk -F: ‘{print $1}’ | sudo grep -f - /mnt/etc/shadow | sudo tee -a /etc/shadow
Cool, now people can login.
Power In Numbers and Groups
If we look at the stat(3) of a file from the old system as owned by one of these migrated users now, then the uid maps to the correct name but the group is incorrect. We need to do the same thing for groups.
$ grep x:100[1234567] /mnt/etc/passwd | awk -F: ‘{print “x:”$4}’ | grep -f - /mnt/etc/group | sudo tee -a /etc/group
So we map a little differently and we construct our fgrep regex using awk, but its mostly similar to the shadow case.
Samba
Regular user accounts are all neat and good, but the whole point was XBMC which connects via samba share. This is where my sysadmin knowledge is starting to show its age. The last time I migrated samba accounts the accounts were in an smbpasswd file and could be moved very much like the shadow case above. These days samba stores this information in a trivial database known as a tdb. http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/msdfs.html (No idea why an html file named msdfs actually contains tdb information instead of DFS information.)
I had to search the docs and google a bit before I found this post: http://fixunix.com/samba/246816-samba-where-samba-store-users-passwords.html which lead me to the pdbedit command. Samba has changed since I last used it. http://us3.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html
Unfortunately, I didn’t have tdb password entries for all these user accounts, actually I had ‘em only for two. No big deal since the easiest path is to go through the old smbpasswd file format to get here.
First thing, I found that pdbedit doesn’t like read only file systems, so copy your pdb local (did I mention my old disk is mounted read only at /mnt?)
$ cp /mnt/var/lib/samba/passwd.tdb oldpasswd.tdb
Now we need that old smbpasswd file format
$ sudo pdbedit -Lw -b tdbsam:oldpasswd.tdb > smbpasswd
Then I want to filter it for only the accounts I care about.
$ grep x:100[1234567] /mnt/etc/passwd | awk -F: ‘{print $1}’| grep -f - smbpasswd > smbpasswd.stripped
Then (thanks to abartlet #samba on freenode for guiding me) merge these into the new systems passwd.tdb
$ sudo pdbedit -i smbpasswd:smbpasswd.stripped
Now you should have functioning samba passwords.
If someone reading this is thinking, oh this is WAY easier in windows, could you please link me to the step by step process like this? I’ve always wanted to use it and I could never get it done.
