Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from turing.freelists.org (turing.freelists.org [206.53.239.180]) by malta2546.startdedicated.com (Postfix) with ESMTPS id CFC421003924E1 for ; Wed, 1 Jan 2020 21:21:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3CF1222D7C; Wed, 1 Jan 2020 15:21:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1577910090; bh=jNUD83ZI/4huAmNhqd8avvDeIxUBGc7uVG27h0ee184=; h=From:Sender:Sender:From; b=cXNa5IgPg5DxYydgLSWBw9ZJpg7x/UwdbBNowz1vdrCsJBGgruW8mWorD2Zs5Wdtw mKyQZfa0SwN7zIaV6YTr58LNAb6crYoNQ5CK9F1MJ/pzbeVdcgwJKj0RhAMupazM81 fcbO7wKhnDtKXXxxztA0dmrllx7h/WGS0Bx6+WTw= X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS1tA0Y4Kq4H; Wed, 1 Jan 2020 15:21:29 -0500 (EST) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 0A96122D21; Wed, 1 Jan 2020 15:20:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freelists.org; s=turing; t=1577910086; bh=jNUD83ZI/4huAmNhqd8avvDeIxUBGc7uVG27h0ee184=; h=From:Sender:Sender:From; b=FHMIMrZeMS7lSGUKvoEeANX5y2dUqiEo7hP49sbjxd0rtAYDRP0dB6249F/UaZ+1n 3LMtH1tsboKr/CGCVD6KtVenU3nkN/Cumi483j9UuMpT7IT3d6tZ8QNryC0xh34PPh YxSP42lKQspm34macraYUZ5hfrt5SD+JD4QF/ZD8= Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 01 Jan 2020 15:19:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id DECB922BBB for ; Wed, 1 Jan 2020 15:19:56 -0500 (EST) Authentication-Results: turing.freelists.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="CqLLp3s5"; dkim-atps=neutral Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8E5WXjYtuAJ for ; Wed, 1 Jan 2020 15:19:56 -0500 (EST) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 8500D22B9F for ; Wed, 1 Jan 2020 15:19:56 -0500 (EST) Received: by mail-ua1-f48.google.com with SMTP id c14so11784880uaq.11 for ; Wed, 01 Jan 2020 12:19:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cSyEs0NuJiHbSb0kzj205mPRyG9Lq4G1/wU42VDduvE=; b=pSLbxlvy7qTqYJrDbH9O8O/hiuvJ9Ao0Mb9y1lbTIqjoHHQWooOtNUqhcocAZr5MYS KTQ36W8rn6uHj/czEKkrT3mmWxd/mKeC4GBK3uNAy7F0La7/pJqYSOZhraif5pC/uutJ jY+pY0UYBX0KxmkjtkAOU3uXx5eVCsRBXnY9zUXqZ1yIp08vywgtMrPcS/B7IhONHDKe +bbPw8PaA+65d12ZmsJZZkIYkWGCzFfYAcVckQZiFQDBTON3Hg/B712cpBd//Mbj5LYK Nmc0IsSeq1ojzaZki2A4Bk9b5wC1/P0rODlCPy/zY9IAy5CcLGa06WHWidkwlkBFfzox VIAw== X-Gm-Message-State: APjAAAX3CWxElFfAoKHMW0oNCN3ibY3gbW/JS+q6pPiDR9R8D2S92xy0 6Ul+CooV+Mb0B7FEK/1WSVRySqGYziQcYSRFAuI= X-Google-Smtp-Source: APXvYqziyZg7IqJ83/U+yD9A7zraSknp4B311+WrIm9x3vtKA/xHQtosXkgr0Zm4vtT/PmarF9QXBml5Ymk4J4pHx+A= X-Received: by 2002:ab0:14ea:: with SMTP id f39mr35745726uae.40.1577909995858; Wed, 01 Jan 2020 12:19:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ruan Linehan Date: Wed, 1 Jan 2020 20:19:44 +0000 Message-ID: Subject: Re: 12.1-12.2 PDB Upgrade with TDE To: anthony Sanchez , Oracle-L oracle-l Content-Type: multipart/alternative; boundary="000000000000ca70fb059b19ccbf" X-archive-position: 75770 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: ruandav@gmail.com Precedence: normal Reply-To: ruandav@gmail.com List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-Subscribe: List-Owner: List-post: List-Archive: X-list: oracle-l --000000000000ca70fb059b19ccbf Content-Type: text/plain; charset="UTF-8" Hi Angthony, Yes, have tried to rekey and also tried to explicitly direct the cloned PDB to "use" the supposedly (partially?) imported key (when the key has been imported prior to a clone attempt). e.g. administer key management use key 'Abcf34545....etc' identified by "password2" with backup; Notably, a rekey or the 'use key' AKM commands will not work until I have brought the cloned PDB out of restricted mode as I will receive the error below... ORA-28442: Rekey of the TDE Master encryption key is not permitted when the database is in restricted mode... Which means that I pretty much have to attempt an import of the key to remove the pdb_plug_in_violation, and perform the upgrade steps, in order to reach a position where I must close/open the PDB to finally get it out of restricted mode *before* I attempt to either 'set' or 'use key'... and by that stage, the PDB is not in a positive state with the usual TDE specific errors and complaints completely littering the alert log. There are about 33 slightly different methods now (in terms of either sequencing or commands) which I have attempted to perform. All of which I know do not work in my scenario. Just hoping someone may have crossed this particular bridge before me and can suggest what just one working sequence/path should look like, so I can focus on debugging that route... Thanks, Ruan On Wed, Jan 1, 2020 at 4:45 PM anthony Sanchez wrote: > Hi ruan, > Have you tried resetting the master key in your pdb after clone? > > Connect to pdb > > ADMINISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY > keystorepassword with backup; > > > > > On Wed, Jan 1, 2020, 3:40 AM Ruan Linehan wrote: > >> Hi list, >> >> I am very stuck and really beginning to tread water on an SR with the >> below scenario. Would anyone have experience of a 12.1-12.2 Multitenant PDB >> upgrade path via remote clone including TDE?? >> >> Source 12.1 Multitenant PDB on Exadata RAC with TDE. >> Destination 12.2 Multitenant PDB on Exadata RAC (Separate CDB on >> the same cluster with separate software wallet). >> >> I am attempting to perform a 12.1 --> 12.2 individual PDB upgrade via >> remote clone between CDB containers. I have verified the process as >> successful when using a non-TDE [Tablespace] specific PDB. i.e. perform the >> necessary preupgrade.jar steps in the 12.1 source side, clone the PDB over >> a DB link into the 12.2 destination side and then proceed with the >> catctl/catupgrd scripting to perform the upgrade. No issues and all works >> fine... without TDE. >> >> However, when TDE is in the mix on the source PDB, I cannot manage to >> succeed in transitioning the TDE key properly from source side over into >> the destination side (Either before, during or post the upgrade scripting). >> Below is a summary of steps for context but the issues comes down to; how >> do I get a TDE key imported successfully when cloning from a 12.1 CDB to a >> 12.2 CDB... >> >> >> *High Level summary:* >> >> 1. Export the TDE key from the source 12.1 side (*From within the PDB >> itself)... >> - administer key management set keystore open identified by >> "password1"; >> - administer key management export encryption keys with secret >> "password1" to '/tmp/source_side.p12' identified by "password1"; >> >> * Note1* - I believe the export operation is 100% clean as the same >> steps used for this export work seamlessly when performing clones of TDE >> specific PDBs between *12.1* CDBs. >> >> 2. Put the source PDB in ReadOnly... >> - alter pluggable database ORCL close immediate instances=all; >> - alter pluggable database ORCL open read only instances=all; >> >> 3. Perform DB Link clone between containers (*From the CDB$ROOT of the >> destination 12.2 CDB) >> - create pluggable database ORCL122 from ORCL@CLONE_LINK standbys = >> none; >> >> * Note2* - The DB link is fine as the PDB creates in restricted mode. I >> have also attempted incorporating the "keystore identified by" syntax as >> part of the create statement. >> i.e. create pluggable database ORCL122 from ORCL@CLONE_LINK keystore >> identified by "password1" standbys = none; >> >> 4. Open the cloned pluggable... >> - alter pluggable database ORCL122 open instances=all; >> >> * Note3* - At this point, the absence of the TDE required key is evident >> in the alert log messaging, "PDB needs to import keys from source". But >> there is no PDB_PLUG_IN_VIOLATION entry present yet, for the TDE key. Only >> an error as expected for the upgrade path, "PDB's version does not match >> CDB's version", which is quite expected. The PDB exists in restricted mode, >> ready for upgrade. >> >> 5. It's from this point that I run into difficulty. I can try to proceed >> with the catupgrd script operations firstly. Once that completes (seemingly >> cleanly), there is a PDB_PLUG_IN_VIOLATION entry for the TDE key >> requirement. I can then try and import the TDE (*From within the 122 PDB >> itself) key per: >> - administer key management import encryption keys with secret >> "password1" from '/tmp/source_side.p12' identified by "password1" with >> backup; >> >> Alternatively, I could try and perform the import 'ahead of time' at the >> CDB$ROOT container, prior to the clone operation at all. This command >> succeeds as I can see the additional entry populated into the >> v$encryption_keys view and within the software wallet, detailing the source >> of the key. >> >> Alternatively, I can try and transition the key, from the CDB$ROOT >> container levels between CDBs instead using the "WITH IDENTIFIER" clause >> syntax as I note that certain operations are directed to be performed at >> the root level from 12.2 forward, but the very same result occurs in the >> end... >> >> >> I can observe the messaging "Keys imported: PDB ORCL122 can now open in >> normal mode" recorded in the alert log and the PDB_PLUG_IN_VIOLATION entry >> disappears. Great! >> However, no matter how I "get the Key in", post a close/open of the PDB >> (To get it out of restricted mode) - I immediately start receiving errors >> in the alert log around master key not found in current keystore and typed >> master key not found in wallet. It seems no matter how I try to transition >> the correct key INTO the 12.2 destination side, the AKM commands appear to >> succeed but upon proper opening of the PDB, I am flooded with TDE errors in >> the alert logs. >> >> >> Mr. Pachot made it look frustratingly easy here - my experience differs >> significantly, and not sure where I am going wrong: >> https://blog.dbi-services.com/12cr2-upgrade-by-remote-clone-with-tde-in-dbaas/ >> >> So the TL;DR version of the above is simply... >> a) Is this manner of migration path supported? >> b) At what stage/point in the sequence should I look to perform the TDE >> key IMPORT on the destination side when cloning between 12.1-12.2 CDBs for >> an upgrade in this manner? >> c) And should the tried and trusted 12.1 key import syntax work >> effectively for importing the key on the 12.2 destination side or am >> missing something? >> "administer key management import encryption keys with secret >> "password1" from '/tmp/source_side.p12' identified by "password1" with >> backup;"" >> >> Regards, >> Ruan >> > --000000000000ca70fb059b19ccbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Angthony,

Yes, have tried to rekey and also trie= d to explicitly direct the cloned PDB to "use" the supposedly (pa= rtially?) imported key (when the key has been imported prior to a clone att= empt). e.g. administer key management use key 'Abcf34545....etc' id= entified=C2=A0by "password2" with backup;=C2=A0

Notably, = a rekey or the 'use key' AKM commands will not work until I have br= ought the cloned PDB out of restricted mode as I will receive the error bel= ow...
ORA-28442: Rekey of the TDE Master encryption key is not permitted= when the database is in restricted mode...

Which means that I prett= y much have to attempt an import of the key to remove the pdb_plug_in_viola= tion, and perform the upgrade steps, in order to reach a position where I m= ust close/open the PDB to finally get it out of restricted mode before I attempt to either 'set' or 'use key'... and by that st= age, the PDB is not in a positive state with the usual TDE specific errors = and complaints completely littering the alert log.

There are about = 33 slightly different methods now (in terms of either sequencing or command= s) which I have attempted to perform. All of which I know do not work in my= scenario. Just hoping someone may have crossed this particular bridge befo= re me and can suggest what just one working sequence/path should look like,= so I can focus on debugging that route...

Thanks,
Ruan=C2=A0
=

On Wed, Jan 1, 2020 at 4:45 PM anthony Sanchez <anthonycsanchez@gmail.com> wrote:
Hi ru= an,
Have you tried resetting the master key in your pdb af= ter clone?

Connect to pd= b

ADMI= NISTER KEY MANAGEMENT SET KEY FORCE KEYSTORE IDENTIFIED BY keystorepassword= with backup;


=


On Wed, Jan 1, 2020, 3:40 AM Ruan Linehan= <ruandav@gmail.c= om> wrote:
Hi list,

I am very stuck and really beginning to = tread water on an SR with the below scenario. Would anyone have experience = of a 12.1-12.2 Multitenant PDB upgrade path via remote clone including TDE?= ?

=C2=A0 =C2=A0 =C2=A0 Source 12.1 Multitenant PDB on Exadata RAC wi= th TDE.
=C2=A0 =C2=A0 =C2=A0 Destination 12.2 Multitenant PDB on Exadat= a RAC (Separate CDB on the same cluster with separate software wallet).
=
I am attempting to perform a 12.1 --> 12.2 individual PDB upgrade vi= a remote clone between CDB containers. I have verified the process as succe= ssful when using a non-TDE [Tablespace] specific PDB. i.e. perform the nece= ssary preupgrade.jar steps in the 12.1 source side, clone the PDB over a DB= link into the 12.2 destination side and then proceed with the catctl/catup= grd scripting to perform the upgrade. No issues and all works fine... witho= ut TDE.

However, when TDE is in the mix on the source PDB, I cannot= manage to succeed in transitioning the TDE key properly from source side o= ver into the destination side (Either before, during or post the upgrade sc= ripting). Below is a summary of steps for context but the issues comes down= to; how do I get a TDE key imported successfully when cloning from a 12.1 = CDB to a 12.2 CDB...


High Level summary:

1.= Export the TDE key from the source 12.1 side (*From within the PDB itself)= ...
=C2=A0 =C2=A0 - administer key management set keystore open identifi= ed by "password1";=C2=A0
=C2=A0 =C2=A0 - administer key manag= ement export encryption keys with secret "password1" to '/tmp= /source_side.p12' identified by "password1";

Note= 1 - I believe the export operation is 100% clean as the same steps used= for this export work seamlessly when performing clones of TDE specific PDB= s between 12.1 CDBs.

2. Put the source PDB in ReadOnly...
= =C2=A0 =C2=A0 - alter pluggable database ORCL close immediate instances=3D= all;
=C2=A0 =C2=A0 - alter pluggable database ORCL open =C2=A0read onl= y instances=3Dall;

3. Perform DB Link clone between containers (*Fr= om the CDB$ROOT of the destination 12.2 CDB)
=C2=A0 =C2=A0 - create plu= ggable database ORCL122 from ORCL@CLONE_LINK standbys =3D none;

= Note2 - The DB link is fine as the PDB creates in restricted mode. I h= ave also attempted incorporating the "keystore identified by" syn= tax as part of the create statement.
=C2=A0 =C2=A0 i.e. create pluggabl= e database ORCL122 from ORCL@CLONE_LINK keystore identified by "passwo= rd1" standbys =3D none;

4. Open the cloned pluggable...
= =C2=A0 =C2=A0 - alter pluggable database ORCL122 open instances=3Dall;
=
Note3 - At this point, the absence of the TDE required key is = evident in the alert log messaging, "PDB needs to import keys from sou= rce". But there is no PDB_PLUG_IN_VIOLATION entry present yet, for the= TDE key. Only an error as expected for the upgrade path, "PDB's v= ersion does not match CDB's version", which is quite expected. The= PDB exists in restricted mode, ready for upgrade.

5.=C2=A0 It'= s from this point that I run into difficulty. I can try to proceed with the= catupgrd script operations firstly. Once that completes (seemingly cleanly= ), there is a PDB_PLUG_IN_VIOLATION entry for the TDE key requirement.=C2= =A0 I can then try and import the TDE (*From within the 122 PDB itself) key= per:
=C2=A0 =C2=A0 - administer key management import encryption keys= with secret "password1" from '/tmp/source_side.p12' iden= tified by "password1" with backup;

Alternatively, I could= try and perform the import 'ahead of time' at the CDB$ROOT contain= er, prior to the clone operation at all. This command succeeds as I can see= the additional entry populated into the v$encryption_keys view and within = the software wallet, detailing the source of the key.

Alternatively= , I can try and transition the key, from the CDB$ROOT container levels betw= een CDBs instead using the "WITH IDENTIFIER" clause syntax as I n= ote that certain operations are directed to be performed at the root level = from 12.2 forward, but the very same result occurs in the end...

I can observe the messaging "Keys imported: PDB ORCL122 can now open = in normal mode" recorded in the alert log and the PDB_PLUG_IN_VIOLATIO= N entry disappears. Great!
However, no matter how I "get the Key in= ", post a close/open of the PDB (To get it out of restricted mode) - I= immediately start receiving errors in the alert log around master key not = found in current keystore and typed master key not found in wallet. It seem= s no matter how I try to transition the correct key INTO the 12.2 destinati= on side, the AKM commands appear to succeed but upon proper opening of the = PDB, I am flooded with TDE errors in the alert logs.


Mr. Pachot= made it look frustratingly easy here - my experience differs significantly= , and not sure where I am going wrong: https://blog.dbi-services.com/12cr2-upgrade-by-remote-clon= e-with-tde-in-dbaas/

So the TL;DR version of the above is= simply...
a) Is this manner of migration path supported?=C2=A0
b) At what stage/point in the sequence should I look to perform the TDE k= ey IMPORT on the destination side when cloning between 12.1-12.2 CDBs for a= n upgrade in this manner?
c) And should the tried and trusted 12.1 key i= mport syntax work effectively for importing the key on the 12.2 destination= side or am missing something?=C2=A0
=C2=A0 =C2=A0 "administ= er key management import encryption keys with secret "password1" = from '/tmp/source_side.p12' identified by "password1" wit= h backup;""

Regards,
Ruan
--000000000000ca70fb059b19ccbf-- -- http://www.freelists.org/webpage/oracle-l