SEO

Hello,

I have a production SCO server that contains hundreds of users. We are
creating a backup server for disaster recovery. We have been able to
transfer all the data and code over no problem. This happens on a
nightly script.

The programmer says we would have to re enter all the users into the
backup system manually and continute to manually add/delete users to
the backup system as we make changes to the production server.

Is that true? Can't anything be done to copy the users (including
passwords, etc) file over in some kind of automated fashion. I have
been working with these guys for 20 years and they are excellent, but I
find it hard to believe it cannot be done.

Please help if you know. We are running SCO open server release 5.

Thank you.

man ap

on old/live box:
ap -dgv >users.ap

on new box:
ap -rvf users.ap

ap doesn't copy or create new home directories so you have to collect them
manually, but even so you don't have to do it manually manually

there are any number of ways to go about copying the home dirs.
on osr 505 it's an interesting little challenge because the users homes are
in /usr, mixed right in with the entire rest of the os. (vs
linux/freebsd/others where user homes are all by themselves in /home and
it's trivial to just tar up or rsync the entire /home in one command)

Here's one way, use find to look for .profile files under /usr, filter
through cut to clip out just the directory names, let tar process the
resulting list.

On the old box:
cd /usr
find ./ -name '.profile' -level 1 |cut -d/ -f2 >/tmp/users.txt
tar cvfF /tmp/homes.tar /tmp/users.txt

Or, if you migt have users with home directories in odd places, another
approach is just read the definitive /etc/passwd and archiive them by full
absolute path. Less flexable since you can't easily move everyone from /usr
to /home this way. Also this won't handle any chroot jail users whereas
above doesn't care as long as they were in /usr.
awk -F: '($3>=200){print $7}' >/tmp/homes.txt
tar cvfF /tmp/homes.tar /tmp/homes.txt


now copy /tmp/homes.tar to the new box

On the new box, :
cd /home # (*)
tar xvf /tmp/homes.tar


(*) or /usr, or /u, or /home, as appropriate.
I always edit /etc/default/accounts and make it /home
And I suggest you do that too, unless you think you might have legacy
application code that is hard coded to look for things in /usr/username
It's probably less greif to keep using /usr than to change the app in that
case even if you have access to the authors.


If you are moving from sco to linux I just recenmtly made a handy little
script to read the passwd and shadow files from a sco box, and from them
generate useradd commands on linux that will create new home dirs and
preserve the passwords and uid's from the sco box.
It might be necessary for the linux box to be configured to use DES for the
passwords.
My linux boxes mostly are because FacetWin (the vtpd part) needs it, and I
havent tried this on a linux box that was using blowfish or md5 for
passwords yet. The man page for useradd just says the -p option takes "the
output of the crypt() command)" so if linux man pages adhered to the
standards of sco man pages, this works anywhere. but often linux man pages
frankly suck and I'd only say it will work in the exact contexts i've
actually tried it.

Won''t hurt to try, merely the users created won't have working passwords
until you reset them.

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

It's only the first version so among it's weaknesses, it captures the list
of names to process into a variable and uses the variable on a shell command
line, which means very large passwd files may possibly blow it up.

Until I improve the script you could probably get around that like this:
cut -d: -f1 < passwd |xargs aap passwd shadow |less
and if that looks ok:
cut -d: -f1 < passwd |xargs aap passwd shadow |sh

But note, linux and bash both allow for very large command lines so I don't
thing even "hundreds" of names will be a problem. And this is only meant to
run on linux anyways.

a quick test that emulates the questionable parts...
NAMES=`echo /*/*`
for i in $NAMES ; do echo $i ; done |wc
4644 4644 75384

Since it didn't blow up on those numbers, you're fine.

--
Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!



----- Original Message -----
From: <sdoscher@beealive.com>
Newsgroups: comp.unix.sco.misc
Cc: <sdoscher@beealive.com>
Sent: Saturday, January 13, 2007 3:43 AM
Subject: copy users from one server to another


> Hello,
>
> I have a production SCO server that contains hundreds of users. We are
> creating a backup server for disaster recovery. We have been able to
> transfer all the data and code over no problem. This happens on a
> nightly script.
>
> The programmer says we would have to re enter all the users into the
> backup system manually and continute to manually add/delete users to
> the backup system as we make changes to the production server.
>
> Is that true? Can't anything be done to copy the users (including
> passwords, etc) file over in some kind of automated fashion. I have
> been working with these guys for 20 years and they are excellent, but I
> find it hard to believe it cannot be done.
>
> Please help if you know. We are running SCO open server release 5.
>
> Thank you.
>
>

sdoscher@beealive.com wrote:
> Hello,
>
> I have a production SCO server that contains hundreds of users. We are
> creating a backup server for disaster recovery. We have been able to
> transfer all the data and code over no problem. This happens on a
> nightly script.
>
> The programmer says we would have to re enter all the users into the
> backup system manually and continute to manually add/delete users to
> the backup system as we make changes to the production server.
>
> Is that true? Can't anything be done to copy the users (including
> passwords, etc) file over in some kind of automated fashion. I have
> been working with these guys for 20 years and they are excellent, but I
> find it hard to believe it cannot be done.
>
> Please help if you know. We are running SCO open server release 5.


You should dump the programmer. He's incompetent.

See http://aplawrence.com/Unixart/upgrades.html

--
Tony Lawrence
Unix/Linux/Mac OS X Resources
http://aplawrence.com