I'm astonished this never cropped up.
Or maybe it did, and we never connected the dots.
NEMS Migrator's "Restore" feature restored the user information.
Well, yeah. Duh. That's kind of the point, right?
Let me give you a scenario I thought up:
1) Bill gets his shiny new NEMS server and runs nems-init.
2) Bill decides a great username is "bill".
3) After a few months, Bill decides to upgrade to the latest, shiniest version of NEMS (maybe 1.4!).
4) Bill initializes his new NEMS deployment, but decides he'd rather not use his first name as the user, so he decides upon "necromancer" because he thinks it sounds like a hacker name.
5) Bill restores his NEMS backup from Migrator Off-Site Backup.
6) Migrator's "Restore" feature replaces Bill's configuration, as would be expected.
Okay, so there's the play-by-play, and I know at least one of you is named "Bill" - so congrats for being chosen. But here's the problem:
Bill's NEMS configs now reflect a username as: bill
Bill's NEMS user is: necromancer
Bill can no longer access half the features of NEMS, and if he does, he'll see strange permissions issues.
Now, during the NEMS Migrator Restore operation, it compares these two usernames and does a find-and-replace throughout the restored configs to change them to the new user... necromancer.
There are obviously scenarios where this will break things... like if a user called themselves user1, I'm guessing their resource.cfg file will turn $USER1$ into $necromancer$. Well, it won't, because I thought of that and made it case-sensitive. But you get the idea. So I also blocked usernames like "nems", "admin" and "nagios" because those will DEFINITELY break things in a find and replace.
I've pushed out this update to all versions of NEMS.