Debian/tru64 integration issue

[bnilsson]

Dear all,

We have a few tru64 machines as well as one VAX/VMS system connected to complex lab hardware, where the os version(s) are locked to support the software that runs the equipment. We want to access the file systems thru samba and Windows PC's but with time we have found it more and more difficult to update the samba software, since our tru64 version is of some age. 

Now we are planning to add a modern file server (HP Proliant) running Debian and a modern SMB server, and connect our old systems via NFS and put a HW firewall around it all.  We match the user uid so that it is the same for tru64 users and Debian users to enable proper user access between the systems. The Debian file system is exported to the tru64 and VAX systems so that a tru64 user can access the server and keep the equipment related data and control files there. We have tested this and it seems to work well enough.

However, there are some possible worries:

The uid/gid setup is very different on tru64 vs Debian. On tru64, all users have the same gid, usually 15(user), while on Debian, each user gets assigned the same uid (e.g. 1001) as the gid (e.g. 1001). When a tru64 user is creating a file on the server, this file gets the group=15, which means 'kmem' as seen from the Debian side.

Is this just ugly, or is this a real issue to really worry about? A security problem?

Can this scheme be done in a better way?

[Dennis Handly]

>The uid/gid setup is very different on tru64 vs Debian. On tru64, all users have the same gid, usually 15(user), while on Debian, each user gets assigned the same uid (e.g. 1001) as the gid (e.g. 1001).

As Steven says, you need to match these up.

Probably on the systems with the smaller number of users/files you need to change.

Or if you can't change the legacy Tru64, perhaps on Debian.

[bnilsson]

Ok, I will clarify.

These are the systems we want to integrate:

p009  PWS500au tru64 v5.1B lab hardware controller, NFS server

p006  Alphaserver DS10 tru64 v4.0F, data prep support for the PWS500au and VAX, NFS client to p009 and p008

p007  Alphaserver DS10 tru64 v5.1B, secondary data prep support, NFS and SMB server

p001  VAX4000 VMS 5.5-2H lab hardware controller, NFS client to p007

p008  AMD64 Debian 5 data prep support, SMB server, NFS client to p009 and p008

$ ucx show version
Digital TCP/IP Services for OpenVMS VAX Version V4.1 - ECO 10
on a VAX 4000-100A running OpenVMS V5.5-2H4

(p006)/ sizer -v
Digital UNIX V4.0F (Rev. 1229); Mon Aug 19 14:38:41 MET DST 2002

(p006) # /usr/local/samba/sbin/smbd -V

Version 3.0.30

(p007)/ sizer -v
Compaq Tru64 UNIX V5.1B (Rev. 2650); Tue Dec 30 08:33:31 CET 2003

(p007) /usr/local/samba/sbin/smbd -V

Version 3.0.30

p008:~$ uname -a
Linux mc2-p008 2.6.26-2-amd64 #1 SMP Tue Jan 25 05:59:43 UTC 2011 x86_64 GNU/Linux
(p009)/ sizer -v
HP Tru64 UNIX V5.1B (Rev. 2650); Fri Dec 4 12:09:59 CET 2009

We want to clean up this structure and make the new system a common NFS server for the rest of the systems. The systems for demanding calculations (p006 and p008) should be doing only this, no other services except NFS.

Maybe this information is redundant since I think I already have recieved an answer from Steven S.

If here is any more to add, please do so.

Especially, if there are any problems anticipated by removing the default group gid=15(users) and replacing it with new groups per-uid debian style? Input on how to change the adduser procedure to have this done automatically would be appreciated.

Some comment to Steven's reply:

The choice of gid=15(users) was not ours, this was in the system as-delivered. The uid's starts from 200 and up.

 The VAX integration of uid/gid actually works very well, since UCX uses a proxy translation table to translate the VMS [UID,GID] to uid/gid on the NFS server.