Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) Newsgroups: comp.sys.apollo Subject: re: Routing Message-ID: <9105301444.AA24301@pan.ssec.honeywell.com> Date: 30 May 91 14:44:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The Internet Lines: 90 > 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.