From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] applied: [PATCH proxmox-backup] tape: fix regression in restoring key from medium
Date: Tue, 6 Feb 2024 09:07:36 +0100 [thread overview]
Message-ID: <9823b24b-1447-4a91-9bb4-8e0810658dda@proxmox.com> (raw)
In-Reply-To: <e5adf116-ca29-4eea-9fe8-026be0d0cc19@proxmox.com>
On 2/2/24 17:07, Thomas Lamprecht wrote:
> Am 31/01/2024 um 14:42 schrieb Dominik Csapak:
>> when trying to restore a key from a tape, we automatically try to load
>> the key into the drive after reading the media-set label.
>>
>> Since the key restore is only useful when the key is not already on
>> disk, this fails of course.
>>
>> To fix it but leave the automatism in place, introduce a function
>> 'read_label_without_loading_key' that does the heavy lifting of reading
>> the labels but does not load the encryption key. Then in read_label,
>> call that function and explictely load the key (when one exists).
>>
>> Then, we only have to use this new function in the 'restore-key' api
>> call for the restore to work as intended.
>>
>> Fixes: 1343dcaf ("tape: move 'set_encryption' calls to the TapeDriver (and implementation)")
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>> should be cherry-pickable for stable-2 if necessary
>>
>> src/api2/tape/drive.rs | 2 +-
>> src/tape/drive/mod.rs | 42 ++++++++++++++++++++++++++++++------------
>> 2 files changed, 31 insertions(+), 13 deletions(-)
>>
>>
>
> applied, with a reword commit message, thanks!
>
> But I'm wondering, why exactly caused the key load issues if we are
> in the mixed mode anyway?
the error was from our side, since we did not find the key in a
disaster recovery case (when you want to restore the key from tape)
>
> A reference to the forum post, bugzilla with the report of the user
> running into this would have been nice too..
it was a customer in the enterprise support, so there's nothing public
to link to
>
> But yeah, as this should not hurt and we got other fixes to roll out
> I'm keeping continuing to roll this out nonetheless for now.
thanks!
prev parent reply other threads:[~2024-02-06 8:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 13:42 [pbs-devel] " Dominik Csapak
2024-02-02 16:07 ` [pbs-devel] applied: " Thomas Lamprecht
2024-02-06 8:07 ` Dominik Csapak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9823b24b-1447-4a91-9bb4-8e0810658dda@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox