[pbs-devel] [PATCH proxmox-network-interface-pinning 1/1] initial commit

[Fabian Grünbichler]

On July 30, 2025 3:24 pm, Thomas Lamprecht wrote:
> Am 30.07.25 um 15:14 schrieb Stefan Hanreich:
>> On 7/30/25 3:07 PM, Thomas Lamprecht wrote:
>>> Am 29.07.25 um 18:57 schrieb Stefan Hanreich:
>>>> +    // This is run on a PVE host, so we use the PVE-specific pinning tool instead with the
>>>> +    // parameters supplied.
>>>> +    if std::fs::exists("/usr/bin/proxmox-network-interface-pinning")? {
>>>
>>> Hmm, why does this here live in libexec if it's intended to be the main one?
>>>
>>> Should we rather move the one from pve-manager into libexec with a product
>>> specific name like "pve-network-interface-pinning" and keep this here in
>>> bin with the generic name? As otherwise one needs to use the full libexec
>>> path when using this on PBS/PMG/PDM? Or what's the idea here?
>> 
>> Yes, that sounds better, so the pve-manager one into
>> 
>>   /usr/libexec/proxmox/pve-network-interface-pinning
>> 
>> and this one into
>> 
>>   /usr/bin/proxmox-network-interface-pinning
>> 
>> Or even sbin?
> 
> bin an sbin will be probably merged in a future major release anyway as
> systemd pushes for doing so, so that doesn't really matters.
> 
>> 
>> I assume, we would then install the standalone package by default in PVE?
> 
> That's the only small "ugliness" there is with this approach, as it would
> not be required per se.
> 
> The alternative I see is that both life in /usr/bin, either with
> "pve" and "proxmox" prefix in the name, respectively, or under the same
> name but with conflicts on packaging level and this package here being
> added only as Recommended for PBS/PDM/PMG to allow co-installation.
> 
> tbh. I'm not opposed of either variant, CC'in Fabian, maybe he can act
> as tie breaker here.

I think installing the rust one always is the simplest solution, even if
it is basically a wrapper doing nothing except forwarding the invocation
on systems with PVE installed.

we could also solve this cleanly on the packaging level, but all the
variants I can come up with[0] are more involved - and at some point we
will probably want to drop the PVE specific one anyway, i.e., when we
switch the network config parsing there over to the Rust-based one one
it reaches feature parity ;)

0: alternatives preferring the PVE one, diverting by the PVE package, ..