* Re: [pve-devel] [PATCH pve-docs 2/3] Fixed the table in 3.11.8
2023-01-03 15:35 ` Thomas Lamprecht
@ 2023-01-10 12:56 ` Noel Ullreich
0 siblings, 0 replies; 7+ messages in thread
From: Noel Ullreich @ 2023-01-10 12:56 UTC (permalink / raw)
To: Proxmox VE development discussion
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.
^ permalink raw reply [flat|nested] 7+ messages in thread