Conference tuxedo::dce-products

in theory, you should be able to configure the new machine into the old cell,
create a security replica, and then make it the new master. not too sure how
to easily move CDS - i would suspect that one would - create a replica, 
replicate all of the directories, and then somehow make the replica the 
master (read/write) of those directories.

but i think an easier way would be to export the password table from the 
old cell and then import it into the new one, and then verify every
account. You'll probably have less trouble with this method than trying to
move the masters around.

garry

I'm not sure I clearly understand what you wish to do.  Am I correct
in saying:

- You only have one DCE server machine (for both CDS and Security) in your
  cell that is running DCE V1.2A.

- You have 100 users already registered in the above cell.

- You have installed DCE V1.3B on a separate machine and configured DCE
  with the same cell name, using the same system name and TCP address as the
  machine that is running DCE V1.2A above.  If you created a new cell
  with the same name as the existing cell, you are in trouble already.

If so, here are my questions:

1. Since DCE V1.2A runs on OSF/1 V2.x and DCE V1.3B runs on Digital UNIX
   V3.x, is it true that you do not want to upgrade the operating system
   and associated software on the OSF/1 V2.x machine?

2. If I understand correctly, you wish to "upgrade" your DCE cell server
   machine by configuring a second machine with Digital UNIX V3.x and
   DCE V1.3B and then physically replace the first machine with the second
   machine, keeping the same node name and TCP address?

3. What do you plan to do with the OSF/1 V2.x system that was previously
   running the cell servers?

--Roger

Hi, Roger.

>>I'm not sure I clearly understand what you wish to do.  Am I correct
>>in saying:
>>
>>- You only have one DCE server machine (for both CDS and Security) in your
>>  cell that is running DCE V1.2A.
>>
>>- You have 100 users already registered in the above cell.
	RIGHT

>>- You have installed DCE V1.3B on a separate machine and configured DCE
>>  with the same cell name, using the same system name and TCP address as the
>>  machine that is running DCE V1.2A above.  If you created a new cell
>>  with the same name as the existing cell, you are in trouble already.
	RIGHT

>>If so, here are my questions:
>>
>>1. Since DCE V1.2A runs on OSF/1 V2.x and DCE V1.3B runs on Digital UNIX
>>   V3.x, is it true that you do not want to upgrade the operating system
>>   and associated software on the OSF/1 V2.x machine?
	
	
>>2. If I understand correctly, you wish to "upgrade" your DCE cell server
>>   machine by configuring a second machine with Digital UNIX V3.x and
>>   DCE V1.3B and then physically replace the first machine with the second
>>   machine, keeping the same node name and TCP address?

>>3. What do you plan to do with the OSF/1 V2.x system that was previously
>>   running the cell servers?

In fact I will upgrade this machine too, but in a near future, because
for some time the Customer will be runnig your application in the old environ-
ment e migrating those application to the new environment. This solution was
proposed to maintain Customer working during the Upgrade. When finally all
application are running on the new version I will upgrade this machine, but now
it will become a DCE Client, with a new name and TCP/IP address.
Naturally during the upgrade phase I'm going to have two separate LAN's to avoid
TCP/IP conflic.

I think that the suggestion in .1 by Garry, to export and reimport the database
    are a good solution. But how do I do this ? Are there explanations in
    the Manuals ?

		Thanks, Joaquim.
                 

   use:  passwd_export and then passwd_import

   These are documented in the DCE Administration Reference Manual.

>>- You have installed DCE V1.3B on a separate machine and configured DCE
>>  with the same cell name, using the same system name and TCP address as the
>>  machine that is running DCE V1.2A above.  If you created a new cell
>>  with the same name as the existing cell, you are in trouble already.
>	RIGHT

Stop right here - by creating another cell that happens to have the same
name as an existing cell, you will run into a few problems.  CDS deals
with cells based upon their creation timestamp.  The string cell name is just
the human-readable method to reference the creation timestamp.  So, by
having two different cells (based upon their creation timestamps) with
the same name, you have made the cellname ambiguous to all of the clients
in the cell.  You may end up having references to both cells in the
clerk cache on your client machines.  You will get an error from the
CDS server if you mean to contact one instance of the cell, but the clerk
extracts the UID of the other instance.  The CDS server will say that
"I don't answer queries to that cell UID."  You could clear this issue up
by doing a "dcesetup clean" on each of your client machines, but this
is labor intensive.  In addition, you then have to repopulate the new
instance of the cell, using Garry's suggestions.

Alternative:  Since you have the same cell server for both CDS and
Security and only one server, all of the cell information is there
beneath /opt/dcelocal/.  You can:

1. On the DCE V1.2 machine, do a "dcesetup stop" and "dcesetup clean".

2. Tar the entire /opt/dcelocal/ subtree to a file and get it to the
   prospective DCE V1.3 machine (you can't network copy if they have
   the same IP address).

3. You can then restart DCE on the V1.2 machine.

4. On the V1.3B machine, un-tar the saveset and re-install DCE V1.3B.

5. On the V1.3B machine, run "dcesetup start" and the cell should come
   up.  Obviously, make sure this machine is on a different physical
   network from the V1.2 machine.

6. Replace the V1.2 machine on the network with the V1.3B machine.
   No repopulation should be necessary.

--Roger