m20481@MWVM.MITRE.ORG (Heather Mackintosh) (05/30/91)
Here is the situation: Currently I have 18 nodes on token ring. I am going to be moving them to our Corporate ethernet. The problem is that there are other departments within my company that already have Apollos on the ethernet. When I put my nodes on the ethernet, the other departments will be able to get onto my nodes. The danger is that they can log in on their nodes as root and crp onto my nodes as root. The corporate ethernet's net ID is 1. I can't change my nodes net ID to something else because whenever I reboot it, the net ID is changed back to 1. I called Apollo response line and they said that there is only one way around it: Put all of your nodes on a seperate ethernet line and then have a node with 2 ethernet cards act as a router. Well, I can't do this because we are not allowed to do cabling in our building. We have to use the existing ethernet cable that is in every office. Does anyone know a way around this problem? Any help would be appreciated. * * Heather
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/30/91)
> Here is the situation: Currently I have 18 nodes on token ring. I am going > to be moving them to our Corporate ethernet. The problem is that there are > other departments within my company that already have Apollos on the > ethernet. When I put my nodes on the ethernet, the other departments > will be able to get onto my nodes. The danger is that they can log in on > their nodes as root and crp onto my nodes as root. Just a comment -- if you can't trust your own company employees, who can you trust? (This is assuming that you don't have root privileges given willy-nilly to anyone.) > I called Apollo response line and they said that there is only one way around > it: Put all of your nodes on a seperate ethernet line and then have a node > with 2 ethernet cards act as a router. Well, I can't do this because we are > not allowed to do cabling in our building. We have to use the existing > ethernet cable that is in every office. Well, they're wrong, too. See below. > Does anyone know a way around this problem? Any help would be appreciated. If you aren't already, go up to sr10.3. This will need to be done on all the other Apollos as well. (I don't think that separate glb cells are supported before then -- right?) After you're at 10.3, do the following (this is grabbed from the 10.3 admin update seminar that HP/Apollo offers/offered) -- 1) Identify the 'default' and 'alternate' cell hosts. This means 'write down a list of all the nodes that will be in each separate network.' 2) Identify the hosts in each cell that will run a glbd. 3) Stop all NCS-based servers on hosts that will become part of the new cell. 4) Using drm_admin, delete all glbd replicas on nodes that will be part of the new cell. 5) On a new_cell node, create a 'glb_obj.txt' file -- #ROOT_nodeX> /etc/ncs/uuid_gen > /etc/ncs/glb_obj.txt 6) Copy this file to all hosts that make up the new cell. 7) Reboot all the glbd hosts on the new cell. 8) Set up glbd services for the new cell, as if it were a newly created net -- #ROOT_nodeX> /etc/server -p /etc/ncs/glbd -create -first [-li dds | ip] & #ROOT_nodeY> /etc/server -p /etc/ncs/glbd -create -from //node_X [-li dds | ip] & #ROOT_nodeZ> /etc/server -p /etc/ncs/glbd -create -from //node_X [-li dds | ip] & 9) Reboot all other NCS server hosts in the new cell. 10) Reboot all the other host in the new cell. Since you _will_be_ moving into a current network, you should be able to just run steps 3..10 on your current network, and then it _should_ be ok when you move it over. Note that you'll need to copy that glb_obj.txt file to any new node that you set up in your cell (and that you won't want to make that file easily deleted). I haven't tried this, but it seems that it would be somewhat difficult to run all the steps, since you'll need to become root when there won't be a registry. Make sure that you have root in the local registry, and/or try staying logged in as root somewhere else, and crp over to the nodes as needed. You might also want to take one of the nodes (that has a registry and glbd database, and pull it out of the net. Then, if you have problems, just kill all the NCS services, remove the glb_obj.txt files, put the isolated node back in the network, and reboot. You should be back at square 1 safely. (Also, get a backup made of the original registry, just as insurance. Problems with this: 1) The only uids that will be 'shared' between the rgys will be worlds. You could use the adopt capability of edrgy to adopt current accounts across to the other registry, but for the most part, you need to consider the node-cells to be distinct. 2) Domain print services are NCS based, so they won't be shared either. 3) Domain NetLS floating licenses are NCS based, so they won't be shared. 4) Mentor 8.0 online documentation is NCS based, "" "" "" "" "" "" "" "". If you're just concerned about the root account(s), you should be able to use the passwd_override file on each of your machines to exclude root. It's not too tough, but it's a long procedure, and this is already too long. If the alternate cells (above) aren't for you, call up HP/Apollo and ask for someone to help you with the passwd_override capability (also a 10.3 feature). You might also want some help from them with the alternate_cells concept.... Good Luck -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com When in danger, when in doubt -- run in circles, scream and shout.
troy@plod.cbme.unsw.oz.au (Troy Rollo) (05/31/91)
From article <9105301144.AA06362@mwunix.mitre.org>, by m20481@MWVM.MITRE.ORG (Heather Mackintosh): m20481> Here is the situation: Currently I have 18 nodes on token ring. I am going m20481> to be moving them to our Corporate ethernet. The problem is that there are m20481> other departments within my company that already have Apollos on the m20481> ethernet. When I put my nodes on the ethernet, the other departments m20481> will be able to get onto my nodes. The danger is that they can log in on m20481> their nodes as root and crp onto my nodes as root. Which they can do even if you do change the net number. They could change their net number to yours (which, even if you did make obscure, they could find out by using lb_admin to ask your glb), and be a part of your net. THey could even ctnode your node (Again by asking your glb, and llb for that matter) for its node numbers and net numbers). m20481> The corporate ethernet's net ID is 1. I can't change my nodes net ID to m20481> something else because whenever I reboot it, the net ID is changed back m20481> to 1. m20481> I called Apollo response line and they said that there is only one way around m20481> it: Put all of your nodes on a seperate ethernet line and then have a node m20481> with 2 ethernet cards act as a router. Well, I can't do this because we are m20481> not allowed to do cabling in our building. We have to use the existing m20481> ethernet cable that is in every office. m20481> Does anyone know a way around this problem? Any help would be appreciated. PRovided you don't have any diskless nodes, you can change the rtsvc line in /etc/rc. The only time this could be a problem is while the machine is rebooting. The other departments should change their net number too, which would mostly avoid this. OF course the same thing about diskless nodes applies to them. -- __________________________________________________________________________ troy@plod.cbme.unsw.oz.au