Migrate Users/Groups from 4.0F system to new 5.0B system

Migrate Users/Groups from 4.0F system to new 5.0B system

Post by Netware » Tue, 24 Jun 2003 11:51:17

On there any docs on the web that outline the procedure I would have
to go thru in order to migrate my C2 passwd protected database and
groups from our old 4.0F system to another system running a freshly
installed copy of tru64 v5.0b.

Rather than doing an upgrade on the old 4.0F system I decided to do a
fresh install of 5.0B on another comparable system  and try to migrate
my password protected db and /etc/group . Are there any tools
available that would all me to do a mass move of users accounts from a
4.0F system to a v5.1B??


Migrate Users/Groups from 4.0F system to new 5.0B system

Post by Ann Majesk » Wed, 25 Jun 2003 01:56:04

Here's some information I've supplied to other people
on how to migrate Enhanced Security users from
system to system.  I haven't had any complaints so far,
so it must work :)  You can't just copy the auth.db files
directly because the format can change between versions.

In addition to doing all of the things you'd normally do
to move users from one system to another (moving/copying
home directories, copying entries from /etc/passwd and
/etc/group, etc.)  you can do the following to copy the
user entries from the auth.db on one system to another:

   on first system:  #/usr/tcb/bin/edauth -g > auth.out

copy auth.out to new system and edit it to remove any
system accounts that you don't want/need copied from
the first system.

   on second system:  #edauth -s < auth.out

Note that you have to do this AFTER setting up the
accounts in the /etc/passwd file, or it won't work.


1. Need information about system-users and system-groups

Is there any good place to find comprehensive information
about the different system-users (adm,lp,sync,halt)
and system-groups (bin,daemon,wheel,kmem)?

I'm looking for information about:

-what files/directories/devices should be owned by a
particular user and/or group.

-what programms should be SUID or SGID to a
particular user and/or group.

-what processess should be run on behalf of a
specific system-user.

-which system- and/or normal-users should belong
which groups (if any).

-when and *how* are some users (like sync and halt)
used (I actually get the "when", but how about
the *why*).

-the use of certain users and groups (like wheel --
I belive users allowed to su is supposed to be
meber of it, but how is it to be used correctly?).


I do see the purpose of the users and groups for
differenting the different types of files and for
running processes with as little privlige as possible.

That a program needing to *read* the passwords in
/etc/shadow could be made a member of the shadow-
group, and then run with SGID -- instead of running
it with full root-privlige *just* to *read*

Or making a user game whom all games are run as, and
then making game a member of the groups owning the
soundcard, console (i.e. screencard) and any other
resource it *really needs* to use -- rather than
letting it run with root-privliges.

But still there are some users and groups who's
purpose alludes me, and I'll also like to know
when and how to use them correctly (when to
make file SUID and/or GUID, when to run a process
as a system-user, when to create a new user and/or
group, and when and to which groups a new system-
user should be made member of).

If there isn't any documentation on the subject,
I'd like to know what experiences you've made, and
would appriciate a summed-up who's-who among Linux'
users and groups list.


2. Java Enerprise System Installation Problem

3. migrating linux system to new hardware/new harddrive

4. HELP: Two server issues.

5. How to move users from an old system to a new system

6. eth0:1 and nmap?

7. Figuring out basic groups and group ids for a new linux system

8. HP 690c colour-printing

9. migrating HDD from celeron system to athlon system

10. times call: user, system, child user, child system

11. 4.0F -> 5.0A update hosed system in single user mode

12. Trying to migrate linux disk to new system

13. Migrating psyche system to new hardware