Finally time to start migration to Linux....

[Brian K. White]

On 9/20/2011 5:36 PM, Walter Vaughan wrote:
> Bill Campbell wrote:
>
>> I have python scripts that handle this pretty easily, and they
>> can handle things like moving $HOME directories from places like
>> /usr/$LOGNAME or /u/usr/... to /home where they belong.  It's
>> probably a good idea to assign new uid and gids that are in sync
>> with the Linux standards.  SCO tends to use low numeric uids
>> below the range considered standard in Linux.  Group gids are
>> also a bit different.  The standard CentOS user admin commands,
>> like Red Hats, like to assign unique groups for each user.
>>
> Danger Danger Will Robinson.
> EVERY stupid record in filePro will then have invalid @CB @UB info
>
> Most filePro installs should have user ids starting at 200 for the
> filePro user.
> RHEL/Centos seems to want to reserve up to 499.
> Don't have /etc/passwd at my fingertips for that OS to verify.
>
> What's most important is maintaining your data. I don't care if you get
> everyone to
> sign in blood that they don't care, eventually you will take the blame.
>
> Find a currently supported Linux OS that does not want to create system
> users that will interfere with your current user id's. Do not do
> anything till
> you solve that problem (me, I use freeBSD with filepro and the highest
> system user is 80, so this is not a problem).
>
> Your not installing filepro so you can run an OS, find the OS that
> supports filePro the best.
>
> The other solution will be to update the binary header info on all your
> data.
> If there was some sort of magical utility that would work that would be
> cool.
> You would think someone would have written a general utility to convert
> filepro user id's by now.

I have a klunky little script that duplicates users from sco to linux by 
reading a copy of passwd and shadow from the sco box and outputting 
useradd commands. You run it, decide the commands look ok, and then 
re-run it but piped into sh.

It preserves the old uid's as long as they are not already used on the 
current system, including the sub-1024 ones.

If a uid is already used, it displays that warning and issues an 
alternate useradd command that lets the system assign a new 
non-conflicting uid for that user.

If a user NAME is already used on the current system, that user is 
skipped. The existing user is not affected.

It also ignores id's less than 200 exactly because those are all special 
on sco.

It preserves the users old password.

It does not preserve the users shell or home directory, so on the new 
system the users home directory will be created fresh in /home, from the 
current system's skeleton files, and the passwd entry will say /home/foo 
and /bin/bash

Up to you to figure out how to deal with customized .profiles and other 
junk in users home directories. We never have that problem since I avoid 
ever doing that for exactly this reason except in the fewest possible 
necessary special cases. For us, we don't even worry about /home at all 
since all users just have the same skeleton .profile and home files. all 
the per-user stuff happens in a special login script which looks up the 
users name in a filepro file. the login script just gets added once to 
the system skeleton .profile before adding any users.
No permissions problems, no shell syntax compatibility problems, no 
broken assumptions...

But for cloning the user accounts, preserving uids and passwords where 
possible, do this:

Copy passwd and shadow from the sco box to a temp dir on the linux box.
Cd into the temp dir with them.
Manually look at the files to remove any lines that you know you either 
don't want to copy or that you will handle manually because of some 
conflict. You can ignore all the uid's below 200, the script already 
ignores those. Even above 200, some users are special ones you don't 
want to copy. Either they have already been created on the new box, or 
they will be created as part of software installs, or they don't apply 
to the new box, for instance the software they relate to won't be installed.
Examples:
filepro
vsifax
prngd
ssh

In all those cases you can just delete them from the old passwd file.

You only have to look at oe edit the passwd file. When you remove a line 
from passwd, the corresponding line in shadow is never looked at anyways.

Then just run "aap passwd shadow |less"

If you don't agree with any of the proposed useradd commands, then edit 
the passwd file and try again. For instance if you already created a 
user of the same name but you would rather restore the user with their 
old uid from the old passwd file, then "userdel username" then re-run 
aap. If the proposed commands includes junk users you don't want then 
edit passwd and re-run aap.

Once the commands all look ok, then run "aap passwd shadow |sh"

http://www.aljex.com/bkw/linux/aap

-- 
bkw