1 INFO-VAX	Sun, 10 Aug 2003	Volume 2003 : Issue 439       Contents: Re: Changing group Re: mount count  rpc on HP TCP/IP  F ----------------------------------------------------------------------   Date: 10 Aug 03 07:24:10 +0200) From: p_sture@elias.decus.ch (Paul Sture)  Subject: Re: Changing group ) Message-ID: <9M8PwSSbOXYo@elias.decus.ch>   c In article <pAw$Jlip$fl5@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: e > In article <agSYa.19808$qg3.1355009@twister.tampabay.rr.com>, "John N." <JNixon@cfl.rr.com> writes: N >> Will it be dangerous to give an in-house application permission to create aG >> captive account which would  execute a utility to change their GROUP  >> membership. > G > It would be particularly dangerous because it would not fully emulate $ > an actual login to that UIC group. > @ >> We have several uic groups set up which each have a differentK >> application version under testing.  We are looking for good ways for the O >> testers to jump from group to group without having several accounts for each  >> user. > H > Accounts are cheap, and the use of separate login directories prevents. > the users from tromping all over each other.  E And I'll say roughly the same. In our setup, we have dummy records in J the UAF called 100, 123 etc, according to group, so creating a new account is as simple as:  < UAF> copy 100 new_user_xx /uic=[100,10] /owner=new_user_xx -: /account=new_user_xx /dir=[new_user_xx] /password=blahblah  E Where xx is the project code. Record 100 has the group login file and H device already set, together with the necessary quotas suitable for work on that project.  F We have a piece of DCL which lists the UICs already used in the chosenB group, "fills in the blanks", and creates the login directory too,I making the creation of a new username a 1 minute job. Indeed, writing the I email informing a user about their new account takes longer than actually C creating the account. (and yes, I've just thought of an enhancement 	 there:-))    ------------------------------   Date: 10 Aug 03 07:27:29 +0200) From: p_sture@elias.decus.ch (Paul Sture)  Subject: Re: mount count) Message-ID: <HNMZwLIMbM4C@elias.decus.ch>   q In article <Ts2wuaDK3QAA@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: l > In article <2ygOWpOFxEF6@eisner.encompasserve.org>, kuhrt@nospammy.encompasserve.org (Marty Kuhrt) writes: >>  L >> On my machines DSA devices are the ones created when I make a shadow set.L >> In that instance the mount count can be up to a maximum of the number of  >> nodes in the cluster. >  >   Name space pollution?     7 Evidently so, because DSA means a shadow set to me too.    ------------------------------  $ Date: Sat, 9 Aug 2003 22:34:11 -0500) From: "Sam Rozenfeld" <rozenfeld@dls.net>  Subject: rpc on HP TCP/IP , Message-ID: <opydnTOu8YxuIaiiXTWJhQ@dls.net>   Hi,   K this started with me trying to mount NFS share on a Windows box. I could do L it from BSD machine but was unable to do it with my VMS 7.3-1 system runningK 5.3 ECO 2 version of DEC TCP/IP. I tried 4 different implementations of NFS H for Windows 2000. So I started looking a little deeper. I can't even getK RPCINFO from VMS, it hangs. But again I can do it from BSD or Unix machine. K Did anyone else come across this ? Any help with this would be appreciated. H This looks like a bug and I do have a support call opened to HP but theyL suggested trying another NFS server implementation on Windows box (figures).+ I did and am still having the same problem.    Thanks.    ------------------------------   End of INFO-VAX 2003.439 ************************