Also the machine is using another apollo as its registry server.
I would like to keep it that way (on the ring), but not let everyone who
has an account on the registry log into the series 400 machine. A colleage
pointed me in the direction of "passwd-override" and I am just now leafing
through TFM. Am I on the right track? Any better ways?
Thanks,
Mike
mi...@asylum.gsfc.nasa.gov
=-=-=-=-====-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=
Std. Disclaimers...
If its a 400-T or -E series machine, it can take 2 3.5" internal disks, and can
have up to 7 SCSI devices, IDs 6..0. Last I knew, the floppy/cartridge device
had to be unit 0, though that may have changed. At any rate, the number of
drives is dependent on the number of other SCSI devices you have or plan on.
If you have a 400-S series, then (I believe) it can take up to 2 5.25" internal
disks, and the same 7 SCSI devices total. Contrary to what I wrote (that got
put in the FAQ) earlier, you can NOT have multiple SCSI controllers in the S
series -- at least, that's what all the current literature and people say. My
memory from June 90 says differently, but that _was_ a while ago.
> Also the machine is using another apollo as its registry server.
> I would like to keep it that way (on the ring), but not let everyone who
> has an account on the registry log into the series 400 machine. A colleage
> pointed me in the direction of "passwd-override" and I am just now leafing
> through TFM. Am I on the right track? Any better ways?
Depending on the number of people you want to include/exclude, it may be a
fine way to work it or it may be a little bad. If you can easily include or
exclude the users, as appropriate, with just a few quick lines in the
override file, then I'd say do it.
However, if you have a lot of disparate accounts that you need to manage, and
you want to let joe.mgmt.mgmt in, while excluding sam.mgmt.mgmt, and you have
similar splits throughout all your groups and orgs, then you may have a LOT of
work in managing this. Also, if you want the people to not just be restricted
from logging in, but you also want to restrict their file accesses, you have a
much bigger job. If this is the case, you _MIGHT_ want to look into NCS cells,
and have a separate registry for the machine. You can start a rgyd on the node
to be (logically) isolated, and then physically isolate it, make slave registry
the master one (with 'become -master'), stop the registry, create a glb_obj.txt
file in /etc/ncs, start up llbd and glbd (with a create -first on the latter),
restart the registry, and prune people/groups/orgs/accounts that you don't want.
Then lock it up so that world doesn't have rights to most areas (don't change
the `node_data directory willy-nilly though). Finally, take //isolated out
of the registry (and any other NCS services) for the rest of the ring, and
physically connect them again. You now have 2 distinct NCS areas (registry,
printers, NetLS licenses, ...) so your accounts are only duplicated if you
make the effort to import a UID in to the second registry. All other accounts
will not match, and so will drop down to world access, which you can limit as
necessary.
-- jt --
John Thompson
Senior Design Automation Engineer / Sys-Admin On The Loose
Honeywell, SSEC
Plymouth, MN 55441
thom...@pan.ssec.honeywell.com
*************************************************************************
* If I were allowed to speak for Honeywell, I couldn't say anything. *
* *
* When all you have is a hammer, everything looks like a nail. *
*************************************************************************