Re: [pve-devel] [PATCH pve-docs 2/3] Fixed the table in 3.11.8

[Noel Ullreich <n.ullreich@proxmox.com>]

On 03-01-2023 16:35, Thomas Lamprecht wrote:
> Am 03/01/2023 um 14:31 schrieb Noel Ullreich:
>> Fixed the table by manually replacing the characters latex could not
>> render with simpler characters. This will have to be done manually
>> again for any future tables of the same style for now.
> you don't remove the old one though...?

I left the old one for future reference if someone copy/pastes another
table into the docs and then wonders why the pdf doesn't build
correctly. If they then grep through the .adoc files (which is what I
would do) they should more easily find my workaround.

I can also take this out, though.

>
>> Signed-off-by: Noel Ullreich<n.ullreich@proxmox.com>
>> ---
>>   certificate-management.adoc | 24 ++++++++++++++++++++++--
>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/certificate-management.adoc b/certificate-management.adoc
>> index edf0468..f481916 100644
>> --- a/certificate-management.adoc
>> +++ b/certificate-management.adoc
>> @@ -292,10 +292,29 @@ root@proxmox:~# echo "OVH_CK=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ" >> /path/to/api-t
>>   ----
>>   
>>   Now you can setup the the ACME plugin:
>> -
>>   ----
>>   root@proxmox:~# pvenode acme plugin add dns example_plugin --api ovh --data /path/to/api_token
>>   root@proxmox:~# pvenode acme plugin config example_plugin
>> + ---------------------------------------------------
>> +| key    | value                                    |
>> + ---------------------------------------------------
>> +| api    | ovh                                      |
>> + ---------------------------------------------------
>> +| data   | OVH_AK=XXXXXXXXXXXXXXXX                  |
>> +|        | OVH_AS=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY  |
>> +|        | OVH_CK=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ  |
>> + ---------------------------------------------------
>> +| digest | 867fcf556363ca1bea866863093fcab83edf47a1 |
>> + ---------------------------------------------------
>> +| plugin | example_plugin                           |
>> + ---------------------------------------------------
>> +| type   | dns                                      |
>> + ---------------------------------------------------
>> +----
>> +
>> +////
>> +actually looks like this but this won't render, not even in xetex
>> +with --fop, a2x can kinda handle it but that breaks other stuff
>>   ┌────────┬──────────────────────────────────────────┐
>>   │ key    │ value                                    │
>>   ╞════════╪══════════════════════════════════════════╡
>> @@ -311,7 +330,8 @@ root@proxmox:~# pvenode acme plugin config example_plugin
>>   ├────────┼──────────────────────────────────────────┤
>>   │ type   │ dns                                      │
>>   └────────┴──────────────────────────────────────────┘
>> -----
>> +////
>> +
>>   
>>   At last you can configure the domain you want to get certificates for and
>>   place the certificate order for it:
From n.ullreich@proxmox.com  Tue Jan 10 14:05:57 2023
Return-Path: <n.ullreich@proxmox.com>
X-Original-To: pve-devel@lists.proxmox.com
Delivered-To: pve-devel@lists.proxmox.com
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id A40E294261
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:05:57 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 7BC84AB2A
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:05:27 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:05:26 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 3B30F44A34
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:05:26 +0100 (CET)
Message-ID: <a4751900-8edb-c09b-a817-1ce5753687d2@proxmox.com>
Date: Tue, 10 Jan 2023 14:05:24 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Content-Language: en-US
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20230103133121.114234-1-n.ullreich@proxmox.com>
 <20230103133121.114234-2-n.ullreich@proxmox.com>
 <61b40856-60ea-f9b2-ba99-700e7ce1b899@proxmox.com>
From: Noel Ullreich <n.ullreich@proxmox.com>
In-Reply-To: <61b40856-60ea-f9b2-ba99-700e7ce1b899@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.133 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 HTML_MESSAGE            0.001 HTML included in message
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [stackexchange.com]
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
Subject: Re: [pve-devel] [PATCH pve-docs 1/3] Fixed inline code breaking in
 pdf docs
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2023 13:05:57 -0000


On 03-01-2023 16:36, Thomas Lamprecht wrote:
> Am 03/01/2023 um 14:31 schrieb Noel Ullreich:
>> Had to overwrite the `texttt` command to allow breaks in long strings
>> with no space. Now the line can be broken on specific chars as well.
>>
> any context/reference where you pulled this from or how
> you came up with it?

I adapted this stackexchange answer:
https://tex.stackexchange.com/questions/219445/line-break-in-texttt?rq=1

This works well because it allows breaks at predefined
characters in inline code. If this is not done, Latex will not know
where to break long commands.

>
>> Signed-off-by: Noel Ullreich<n.ullreich@proxmox.com>
>> ---
>>   asciidoc/dblatex-custom.sty | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/asciidoc/dblatex-custom.sty b/asciidoc/dblatex-custom.sty
>> index 6b2578c..02fbe16 100644
>> --- a/asciidoc/dblatex-custom.sty
>> +++ b/asciidoc/dblatex-custom.sty
>> @@ -66,3 +66,16 @@
>>     \drawtitlepage
>>     \pagebreak[4]
>>   }
>> +
>> +% to correctly break inline code the texttt command needs to be renewed
>> +\DeclareRobustCommand{\texttt}[1]{
>> +  \begingroup%
>> +  \ttfamily%
>> +  % characters on which to break. `_` does not work
>> +  \begingroup\lccode`~=`/\lowercase{\endgroup\def~}{/\discretionary{}{}{}}%
>> +  \begingroup\lccode`~=`.\lowercase{\endgroup\def~}{.\discretionary{}{}{}}%
>> +  \begingroup\lccode`~=`-\lowercase{\endgroup\def~}{-\discretionary{}{}{}}%
>> +  \catcode`/=\active\catcode`.=\active\catcode`-=\active%
>> +  \scantokens{#1\noexpand}%
>> +  \endgroup%
>> +}
From f.ebner@proxmox.com  Tue Jan 10 14:07:07 2023
Return-Path: <f.ebner@proxmox.com>
X-Original-To: pve-devel@lists.proxmox.com
Delivered-To: pve-devel@lists.proxmox.com
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 1622D942B4
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:07:07 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id E9A82ABC3
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:06:36 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:06:32 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4E9C144A34
 for <pve-devel@lists.proxmox.com>; Tue, 10 Jan 2023 14:06:32 +0100 (CET)
Message-ID: <159837ba-f916-7b03-2cab-8e486b38b6bb@proxmox.com>
Date: Tue, 10 Jan 2023 14:06:31 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Content-Language: en-US
To: Christoph Heiss <c.heiss@proxmox.com>
Cc: pve-devel@lists.proxmox.com
References: <20230102123633.2493599-1-c.heiss@proxmox.com>
 <20230102123633.2493599-3-c.heiss@proxmox.com>
 <dff207ed-4116-2010-1be0-d3b263469ea9@proxmox.com>
 <20230110111141.2hxrozsr7fatvswj@maui.proxmox.com>
 <cd42c9e1-f890-0b6a-b00b-5ef96f74a513@proxmox.com>
 <20230110124441.g6mapiv7yauo2xjc@maui.proxmox.com>
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <20230110124441.g6mapiv7yauo2xjc@maui.proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.127 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 POISEN_SPAM_PILL          0.1 Meta: its spam
 POISEN_SPAM_PILL_1        0.1 random spam to be learned in bayes
 POISEN_SPAM_PILL_3        0.1 random spam to be learned in bayes
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [PATCH storage] fix #4289: pbs: wait for backup
 verification to finish before updating volume attribute
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2023 13:07:07 -0000

Am 10.01.23 um 13:44 schrieb Christoph Heiss:
> On Tue, Jan 10, 2023 at 01:34:14PM +0100, Fiona Ebner wrote:
>> Am 10.01.23 um 12:11 schrieb Christoph Heiss:
>>> On Wed, Jan 04, 2023 at 11:50:38AM +0100, Fiona Ebner wrote:
>> Regarding the API, maybe it can be its own endpoint in the backup API
>> (alongside endpoints like 'blob' and 'finish')? As long as we protect
>> the backup before marking it as finished it should be good. Just an
>> idea, not sure if it would be better.
> After looking into it, my first though was maybe to add a (boolean)
> parameter to the `finish` endpoint.
> But creating a separate endpoint and calling that before `finish` sounds
> very reasonable as well.
> Any thoughts on what would be more idiomatic/reasonable?
> 

Having a parameter for 'finish' seems a bit cleaner to me. I'm sure the
PBS people will complain if they are not happy with it ;)

>>> And I guess I need to figure out a way how to detect whether the new
>>> parameter is supported or not?
>>
>> If there is no straightforward way to make that information available in
>> VZDump.pm, we could also just base the decision off of the PBS version.
> Thanks for the idea, that may be doable!
> 
>>
>> One way to decide if the current behavior should be used as a fallback
>> would be to check the protected status after finishing the backup. That
>> is slightly racy though, because something else could've already changed
>> the protection between finishing and the check.
> I'd base it off the decision from above - if the `proxmox-backup-client`
> version supports setting it directly, use that, otherwise simply fall
> back.
It's not just the client, but the server that needs to support it too.
To make sure that the client/QEMU/etc. support it, we can just have
pve-manager depend on a recent enough version. For the server, there is
a /version API endpoint we can query.