On August 28, 2019 1:25 pm, Dominic Jäger wrote:
> After Fabian had sent his patch [0] we actually thought that this patch
> for pve5to6 would be obsolete. Upgrades as well as fresh installs worked
> flawlessly in my tests. Consequently, I removed the hint from the
> upgrade documentation [1] an
On August 26, 2019 1:30 pm, Thomas Lamprecht wrote:
> On 24.07.19 13:37, Fabian Grünbichler wrote:
>> otherwise unprivileged containers might end up with directories that
>> they cannot modify since they are owned by the user root in the host
>> namespace, instead of root
On August 23, 2019 2:03 pm, Dominik Csapak wrote:
> this add the 'tags' property to vms, which has the format:
why 'tags'? seems rather generic for what it does ;)
>
> key=value(;key=value)*
>
> each value will be set as
>
> -fw_cfg 'name=opt/com.proxmox/$key,string=$value'
> (qemu recommends
On August 27, 2019 11:24 am, Alexandre DERUMIER wrote:
> Hi,
>
> I think 1 benefit of gitlab,github,... is the tracking of merge request.
IMHO this is a big downside of Github and Gitlab - cleanly checking out
an older iteration of a PR/MR is very cumbersome (and wasn't even really
possible for
On September 2, 2019 2:27 pm, Thomas Lamprecht wrote:
> On 9/2/19 2:14 PM, Fabian Grünbichler wrote:
>> On August 23, 2019 2:03 pm, Dominik Csapak wrote:
>>> this add the 'tags' property to vms, which has the format:
>>
>> why 'tags'? seems rathe
On September 4, 2019 8:49 am, Dominik Csapak wrote:
> On 9/2/19 2:14 PM, Fabian Grünbichler wrote:
>> On August 23, 2019 2:03 pm, Dominik Csapak wrote:
>>> this add the 'tags' property to vms, which has the format:
>>
>> why 'tags'? seems r
On September 4, 2019 3:59 pm, Oguz Bektas wrote:
> the description doesn't match the default behaviour, which is to replace
> the current values with pending ones in the returned config, unless the
> 'current' option is passed.
>
> Signed-off-by: Oguz Bektas
> ---
>
> i tried to come up with a r
On September 4, 2019 4:41 pm, Thomas Lamprecht wrote:
> On 01.07.19 15:43, Christian Ebner wrote:
>> remove_vmid_from_backup_jobs updates the vzdump.cron backup jobs,
>> excluding the given vmid.
>>
>> Signed-off-by: Christian Ebner
>> ---
>> PVE/VZDump/Plugin.pm | 46 +++
thanks to all three involved people ;)
On September 3, 2019 1:06 pm, Thomas Lamprecht wrote:
> This was wrongly shipped by our ISO since quite a bit (AFAICT, at
> least 4.x), so fix it up in a versioned postinst snippet.
>
> Do so by usind sed with the following pattern:
> # sed -E -i -e 's/^www
On March 27, 2019 5:42 pm, Thomas Lamprecht wrote:
> Actually this'd be v8, but it's to old and to unreviewed for anybody do
> remember anyway, so best seen as new series.
>
> Thomas Lamprecht (4):
> allow LRM lock stealing for fenced nodes
> allow use of external fencing devices
> send also
for reference docs IMHO.
one nit inline, otherwise
Acked-by: Fabian Grünbichler
> ---
> README | 110 +
> 1 file changed, 110 insertions(+)
>
> diff --git a/README b/README
> index 1c5177f..dbf8d6a 100644
> --- a/READ
On March 27, 2019 5:42 pm, Thomas Lamprecht wrote:
> We introduced sending an email when Fencing fails/succeeds in
> general some time ago, send now also an email if a HW fence
> fails
missing S-O-B
> ---
> src/PVE/HA/NodeStatus.pm | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
On March 27, 2019 5:42 pm, Thomas Lamprecht wrote:
> A node now can be fenced with the use of external hardware fence
> devices.
> Those device can be configured at /etc/pve/ha/fence.cfg
> also the fencing option in the datacenter configuration file must
> be set to either 'hardware' or 'both', els
r want to start a service on two nodes!
small nits inline, otherwise
Acked-by: Fabian Grünbichler
> ---
> src/PVE/HA/Env.pm | 4 ++--
> src/PVE/HA/Env/PVE2.pm | 4 ++--
> src/PVE/HA/Sim/Env.pm | 16 ++--
> 3 files changed, 14 insertions(+), 10 deletions(-)
&
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> A QEMU update can change supported CPU flags, thus we need to restart
> API services (especially pvestatd) to refresh their cached values.
given the recent discussion about this exact change, we could also use
PVE::QemuServer::kvm_user_version(
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> pvestatd will read supported CPU flags once on startup (since these
> never change during runtime, and QEMU updates trigger a service
> restart), then broadcasts them as a key-value pair to the cluster.
>
> Signed-off-by: Stefan Reiter
> ---
>
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> * query_understood_cpu_flags returns all flags that QEMU/KVM knows about
> * query_supported_cpu_flags returns all flags that QEMU/KVM can use on
> this particular host.
>
> To get supported flags, a temporary VM is started with QEMU, so we ca
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Inherits from SectionConfig to provide base parsing infrastructure.
>
> Use with helper functions:
> * config_from_file gives bless'd config
> * get_model_by_name returns a "formatted" hash for a single CPU model
> * config_to_file writes change
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Special care is taken not to overwrite any special flags, or ones
> manually set on the VM by the user. We warn if a flag is overruled.
hmm. I am unsure whether I like that behaviour or not. it's a bit
strange that VM specific flags get applied
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Supports custom basemodels (model shown to QEMU, i.e. must be a default
nit: s/shown/known/ ?
high-level: if we allow basing custom models on other custom models,
wouldn't we need to compute an effective model first, and then use that?
e.g.,
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Custom CPU types can be specified via the API, but to prevent arbitrary
> ones we have to manually check if the given model exists (as default or
> custom).
>
> Signed-off-by: Stefan Reiter
> ---
> PVE/QemuServer.pm | 31 ++
On September 2, 2019 4:27 pm, Stefan Reiter wrote:
> Based on the RFC and following on- and off-list discussion about custom CPU
> models [0].
>
> In essence, this revised patch allows a user to specify custom CPU models in
> /etc/pve/cpu-models.conf (section-config style [1]), where VMs using tha
On September 9, 2019 2:56 pm, Stefan Reiter wrote:
> On 9/6/19 1:42 PM, Fabian Grünbichler wrote:
>>> +# this is neither the default for 'query_supported_cpu_flags' below, nor
>>> for
>>> +# /proc/cpuinfo.
>>> +#
>>> +# To compare (o
NAK, see inline
On September 10, 2019 3:27 pm, Oguz Bektas wrote:
> restore from unpriv to priv causes a problem with the log-in, since the
> /etc/securetty file isn't modified after a restore to reflect the change
> (/dev/lxc/tty1 and so on).
>
> template_fixup is normally called in post_create_
meta: please send v2 together with v2 of pve-container (and future) patches.
On September 4, 2019 6:00 pm, Oguz Bektas wrote:
> some functions from Qemu w.r.t. pending changes can be moved to
> AbstractConfig, in order to make them available for both QemuConfig and
> LXC::Config.
>
> Signed-off-b
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> the default behaviour is the same as in Qemu, so without the 'current'
> flag set, current values will be replaced with their respective pending
> counterparts.
>
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/API2/LXC/Config.pm | 23 +
NAK, this breaks existing configs with a snapshot called pending (which
is an allowed snapshot name, and not such an uncommon word that we can
confidently say that noone would be affected). we could do _PENDING_ or
__PENDING__ (similar to what we do with __base__ and __replicate__ and
__migrati
the commit message is misleading - this just adds two parameters, but no
code that handles them? the code/change that adds handling only comes in
patch #8. either merge these two, or put this one after the other
please.
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> Signed-off-by: Oguz Bekt
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> analog to Qemu, it returns an array of elements, which shows the
> current value, pending value, and delete requests.
and again, this is completely identical to the Qemu API path (modulo
comments, one superfluous next statement) except for the ci
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> analog to 'qm pending', it shows a list of keys and values defined in
> configuration.
copied verbatim from qm.pm, maybe we could move this code to
GuestHelpers.pm (format_pending)?
>
> cur: current change
> new: pending change
> del: pending d
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> vmconfig_hotplug_pending is responsible for checking if a key in the
> pending section is hotpluggable, if yes; perform a generic config value
> replace or perform specific actions if a special case.
>
> vmconfig_apply_pending is only supposed to
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/LXC.pm | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
> index 475d9be..9dd5bc9 100644
> --- a/src/PVE/LXC.pm
> +++ b/src/PVE/LXC.pm
> @@ -1939,6 +1939,13
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> this series makes it possible to add/revert/delete pending changes in
> the backend.
>
> it depends on my previous patch for pve-guest-common, for enabling
> inheritance of pending changes related methods into PVE::LXC::Config
thanks for these pa
On September 5, 2019 4:11 pm, Oguz Bektas wrote:
> use vmconfig_hotplug_pending (when ct up) and vmconfig_apply_pending
> (when ct down) to apply or write pending changes.
>
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/API2/LXC/Config.pm | 52 +-
> src/PVE/LXC/Config.pm | 328 +
On September 11, 2019 2:02 pm, Thomas Lamprecht wrote:
> On 11.09.19 09:39, Fabian Grünbichler wrote:
>> NAK, this breaks existing configs with a snapshot called pending (which
>> is an allowed snapshot name, and not such an uncommon word that we can
>> confidently sa
since it has all the necessary wrapping to download and verify dscs from
arbitraty repositories, without being affected by the system's APT state
and configuration.
Signed-off-by: Fabian Grünbichler
---
Makefile | 13 +++--
upstream-key.asc | 29 +++
On September 24, 2019 4:04 pm, Oguz Bektas wrote:
> merging $conf->{lxc} causes lxc.idmap entries to be duplicated in the
> restored configuration. instead, we can overwrite the contents from the
> extracted configuration file. this way we don't duplicate these entries.
> (having duplicate idmap en
er via recover_config, OR via restore_configuration. non-root behaviour
stays the same.
Signed-off-by: Fabian Grünbichler
---
src/PVE/API2/LXC.pm | 4 ++--
src/PVE/LXC/Create.pm | 6 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
index 0728
On September 27, 2019 8:53 am, Alexandre DERUMIER wrote:
> Hi,
>
> I have noticed that when you upgrade libknet1 (and fix the crash of corosync),
>
> corosync is not auto restarted.
yes, just like any other library except libc6 in Debian. there is
tooling to handle this in general ('needrestart
one comment inline
On September 26, 2019 1:38 pm, Fabian Ebner wrote:
> Not every command parameter is 'target' anymore, so
> it was necessary to modify the parsing of $sd->{cmd}.
>
> Just changing the state to request_stop is not enough,
> we need to actually update the service configuration as
small nit inline, otherwise
Acked-by: Fabian Grünbichler
On September 27, 2019 12:49 pm, Thomas Lamprecht wrote:
> This allows us to fix the ZFS SIMD patch for 5.0 kernel way easier,
> as we can use the same code path as used for 5.2 and newer kernels
> there.
>
> The helper i
Acked-by: Fabian Grünbichler
On September 27, 2019 12:49 pm, Thomas Lamprecht wrote:
> Do a very minimal fix, effectively just making the code path for 5.0
> to 5.1 and 5.2 to 5.3 the same one, which can be done by backporting
> the new copy_kernel helpers into the kernel, as the exis
either via recover_config, OR via restore_configuration. non-root behaviour
stays the same.
Tested-by: Oguz Bektas
Signed-off-by: Fabian Grünbichler
---
Note: added Tested-by
src/PVE/API2/LXC.pm | 4 ++--
src/PVE/LXC/Create.pm | 16 ++--
2 files changed, 8 insertions(+), 12
On September 30, 2019 12:55 pm, Fabian Ebner wrote:
> Before, the check whether a syncing instance of the same job is already
> present
> was inside the locked section. This caused cron to continuously spawn new
> instances of pve-zsync on syncs (or rather groups of syncs) taking longer
> than 15
On October 1, 2019 12:17 pm, Fabian Ebner wrote:
> Seems like 'zfs destroy' can take longer than 5 seconds, see [0].
> I changed the timeout to 15 seconds and also changed the default
> timeout to 10 instead of 5 seconds, to be on the safe side
> for other commands like 'zfs create'.
>
> [0]:
> h
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> also use a better naming scheme for methods:
>
> split_flagged_list -> parse_pending_delete
> join_flagged_list -> print_pending_delete
> vmconfig_delete_pending_option -> add_to_pending_delete
> vmconfig_undelete_pending_option -> remove_from_pe
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> since this method will be both used by qemu and lxc config GET calls, it
> makes sense to move it into AbstractConfig. only difference is that qemu
> also hides the cipassword when it's set. this can be handled by having
> qemu overwrite the metho
you completely ignored my comments for v1 of this patch? the whole code
is identical to qemu-server's, except for cipassword handling. pending
changes are also encoded identically for both pve-container and
qemu-server, so it makes sense to move this to AbstractConfig or
GuestHelpers.pm with an
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> config parser can now read/write [pve:pending] section. this was named
> such, instead of [PENDING], after on- and offline discussion regarding
> namespacing the pending section and snapshots.
>
> this also adds an optional non-capturing regex gr
On October 2, 2019 12:22 pm, Thomas Lamprecht wrote:
> On 9/30/19 2:44 PM, Oguz Bektas wrote:
>> config parser can now read/write [pve:pending] section. this was named
>> such, instead of [PENDING], after on- and offline discussion regarding
>> namespacing the pending section and snapshots.
>>
>>
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> we don't need to extract 'delete' here, instead we pass it all as $param
> and extract 'delete', 'revert' and most other things in
> update_pct_config
I already asked that in v1 - wouldn't it make sense to keep the
parameter checks in the API ca
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> use vmconfig_hotplug_pending or vmconfig_apply_pending to apply the
> pending changes, depending on whether the CT is on- or offline.
>
> Signed-off-by: Oguz Bektas
> ---
> src/PVE/LXC/Config.pm | 334 ++
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> vmconfig_hotplug_pending is responsible for checking if a key/value pair in
> the
> pending section can be hotplugged, if yes; perform a generic replace,
> or perform specific actions for hotplugging the special cases.
>
> vmconfig_apply_pending
On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> this series makes it possible to add/delete/revert pending changes in
> the backend for containers.
>
> this v2 took longer than expected, mainly because there were small bugs
> popping up everywhere, everytime i tried to change anything :)
>
>
group reference in an ACL can
only contain one '@' (as first character).
Signed-off-by: Fabian Grünbichler
---
Notes:
alternatively, we could also disallow usernames starting with '@', but those
are currently working as long as they just have ACLs via groups, and not
On October 3, 2019 4:32 pm, Oguz Bektas wrote:
> On Wed, Oct 02, 2019 at 01:52:58PM +0200, Fabian Grünbichler wrote:
>> On September 30, 2019 2:44 pm, Oguz Bektas wrote:
>> > we don't need to extract 'delete' here, instead we pass it all as $param
>> > and
On October 4, 2019 10:55 am, Dominik Csapak wrote:
> otherwise qemu-img uses its default intiator id which may not have access
isn't this also missing from
PVE/QemuServer/Cloudinit.pm
PVE/QemuServer/ImportDisk.pm
and isn't the 'cache=none' addition for ZFS missing from all three?
maybe it would
On October 7, 2019 2:41 pm, Alwin Antreich wrote:
> Machine states that were created on snapshots with memory could not be
> restored on rollback. The state volume was not activated so KVM couldn't
> load the state.
>
> This patch moves the path generation into vm_start and de-/activates the
> sta
On October 8, 2019 11:25 am, Alwin Antreich wrote:
> On Tue, Oct 08, 2019 at 08:36:57AM +0200, Fabian Grünbichler wrote:
>> On October 7, 2019 2:41 pm, Alwin Antreich wrote:
>> > Machine states that were created on snapshots with memory could not be
>> > restored on rol
On October 10, 2019 8:55 am, Fabian Ebner wrote:
> On 10/1/19 12:28 PM, Fabian Grünbichler wrote:
>> On October 1, 2019 12:17 pm, Fabian Ebner wrote:
>>> Seems like 'zfs destroy' can take longer than 5 seconds, see [0].
>>> I changed the timeout to 15
On October 11, 2019 11:55 am, Dominic Jäger wrote:
> Between destroying a VM (unlink config file) and removing it from user.cfg
> creating a new VM with the ID that is still in use in user.cfg was possible.
> VMs could go missing as a consequence.
>
> Adding a lock solves this. This lock does not
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> located at /usr/share/kvm/cpu-flags-understood-$arch
>
> This file can be read by qemu-server's "query_understood_cpu_flags"
> function, avoiding a more expensive call to QEMU.
>
> For now, only x86_64 is implemented, since aarch64 doesn't print
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> pvestatd will check if the KVM version has changed using
> kvm_user_version (which automatically clears its cache if QEMU/KVM
> updates), and if it has, query supported CPU flags and broadcast them as
> key-value pairs to the cluster.
>
> If detec
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> The package will be used for custom CPU models as a SectionConfig, hence
> the name. For now we simply move some CPU related helper functions and
> declarations over from QemuServer to reduce clutter there.
>
> qemu_machine_feature_enabled is move
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> Add two overrides to avoid writing redundant information to the config
> file.
>
> get_model_by_name is used to return a cpu config with default values
> filled out.
>
> Signed-off-by: Stefan Reiter
> ---
>
> v3 -> v4:
> * add is_custom_model
>
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> Turn CPUConfig into a SectionConfig with parsing/writing support for
> custom CPU models. IO is handled using cfs.
>
> Namespacing will be provided using "custom-" prefix for custom model
> names (in VM config only, cpu-models.conf will contain un
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> $cpu_fmt is being reused for custom CPUs as well as VM-specific CPU
> settings. The "pve-vm-cpu-conf" format is introduced to verify a config
> specifically for use as VM-specific settings.
>
> Signed-off-by: Stefan Reiter
> ---
>
> v3 -> v4:
>
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> To avoid hardcoding even more CPU-flag related things for custom CPU
> models, introduce a dynamic approach to resolving flags.
>
> resolve_cpu_flags takes a list of hashes (as documented in the
> comment) and resolves them to a valid "-cpu" argum
On October 7, 2019 2:47 pm, Stefan Reiter wrote:
> If a cputype is custom (check via prefix), try to load options from the
> custom CPU model config, and set values accordingly.
>
> While at it, extract currently hardcoded values into seperate sub and add
> reasonings.
>
> Since the new flag reso
On October 15, 2019 3:54 pm, Thomas Lamprecht wrote:
> On 10/15/19 3:22 PM, Oguz Bektas wrote:
>> if we fallback to /proc/cmdline, it can include the booted initrd.
>>
>> to avoid loader entries with (sometimes even multiple) initrd lines,
>> we have to parse them out.
>>
>> Signed-off-by: Oguz B
On October 17, 2019 7:45 am, Thomas Lamprecht wrote:
> On 10/16/19 1:17 PM, Oguz Bektas wrote:
>> if we fallback to /proc/cmdline, it can include the booted initrd.
>>
>> to avoid loader entries with initrd 'options' lines, we have to parse
>> them out.
>>
>> Signed-off-by: Oguz Bektas
>> ---
>>
Signed-off-by: Fabian Grünbichler
---
PVE/API2/AccessControl.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/PVE/API2/AccessControl.pm b/PVE/API2/AccessControl.pm
index dfbdfc6..9d2da8d 100644
--- a/PVE/API2/AccessControl.pm
+++ b/PVE/API2/AccessControl.pm
@@ -19,6 +19,7 @@ use PVE::API2
to mark API methods which should not be available to clients authenticated
using an API token
Signed-off-by: Fabian Grünbichler
---
Notes:
if applied, any users of this need corresponding versioned depends.
src/PVE/JSONSchema.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a
Signed-off-by: Fabian Grünbichler
---
PVE/AccessControl.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/PVE/AccessControl.pm b/PVE/AccessControl.pm
index 3e52c5f..aff9137 100644
--- a/PVE/AccessControl.pm
+++ b/PVE/AccessControl.pm
@@ -1135,11 +1135,11 @@ sub
it's not required for dependencies (since those are only ever between
sections, and not within), but makes for easier diffing.
Signed-off-by: Fabian Grünbichler
---
PVE/AccessControl.pm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/PVE/AccessControl.pm
for reusage in API token ID format/verification
Signed-off-by: Fabian Grünbichler
---
PVE/Auth/Plugin.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/PVE/Auth/Plugin.pm b/PVE/Auth/Plugin.pm
index 5c11991..6d59b72 100755
--- a/PVE/Auth/Plugin.pm
+++ b/PVE/Auth
of the
corresponding user and those of the API token itself.
Signed-off-by: Fabian Grünbichler
---
Notes:
I am a bit unsure how to differentiate in a clean way between:
A full userid/tokenid (username@realm OR username@real!token)
B user (username@realm)
C tokenid (username@realm!t
which was mistakenly added back when this was still in pve-manager.
Signed-off-by: Fabian Grünbichler
---
PVE/APIServer/AnyEvent.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/APIServer/AnyEvent.pm b/PVE/APIServer/AnyEvent.pm
index c1dade8..9aba27d 100644
--- a/PVE
the _exist/_enabled are modelled after the corresponding user methods.
the 'tokenid' option goes into PVE::AccessControl, since we need it in
multiple API modules.
Signed-off-by: Fabian Grünbichler
---
PVE/AccessControl.pm | 32
1 file changed, 32
pull it into helper sub, since we need this one more time for token ACL
members.
Signed-off-by: Fabian Grünbichler
---
PVE/AccessControl.pm | 61 +++-
1 file changed, 26 insertions(+), 35 deletions(-)
diff --git a/PVE/AccessControl.pm b/PVE
and integration for user API endpoints.
Signed-off-by: Fabian Grünbichler
---
Notes:
pveum integration will come in a future version, but
pveum token add/modify/delete [OPTIONS]
or
pveum user token add/modify/delete [OPTIONS]
seem like likely
it doesn't really serve a purpose, and it's not called anywhere in the codebase.
Signed-off-by: Fabian Grünbichler
---
Notes:
alternatively, we can give this the same semantics w.r.t. tokens as
PVE::AccessControl::roles, but with pool roles mixed in via
$compile_acl_path
d-off-by: Fabian Grünbichler
---
PVE/AccessControl.pm | 47
1 file changed, 47 insertions(+)
diff --git a/PVE/AccessControl.pm b/PVE/AccessControl.pm
index 432ccc0..b5dfe4b 100644
--- a/PVE/AccessControl.pm
+++ b/PVE/AccessControl.pm
@@ -397,6 +397,39 @
based on idea & RFC by Tim Marx, incorporating feedback by Thomas
Lamprecht. this will be extended to support API tokens in the
Authorization header as well, so make it generic.
Signed-off-by: Fabian Grünbichler
---
Notes:
semi-independent, could also leave extract_auth_cookie as a
ve-http-server)
- checking API endpoints for 'notoken'-ification
I tried to order independent clean-ups etc. up front with-in each repo,
but some of them require versioned breaks/depends so it might make sense
to wait for the full series for those.
pve-common:
Fabian Grünbichler (1):
Signed-off-by: Fabian Grünbichler
---
Notes:
requires versioned dependency on libpve-common-perl
PVE/API2/AccessControl.pm | 4
1 file changed, 4 insertions(+)
diff --git a/PVE/API2/AccessControl.pm b/PVE/API2/AccessControl.pm
index 9d2da8d..2a52105 100644
--- a/PVE/API2
Signed-off-by: Fabian Grünbichler
---
PVE/API2/ACL.pm | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/PVE/API2/ACL.pm b/PVE/API2/ACL.pm
index 3e42ac0..c340267 100644
--- a/PVE/API2/ACL.pm
+++ b/PVE/API2/ACL.pm
@@ -46,7 +46,7 @@ __PACKAGE__
they have been handled by PVE::RPCEnvironment for quite some time
already, and the versions there are the complete ones that should be
actually used.
Signed-off-by: Fabian Grünbichler
---
Notes:
this requires the corresponding patch for and a versioned breaks on
pve-manager, where a
that are not available with API tokens for security reasons, such as access
control related endpoints.
Signed-off-by: Fabian Grünbichler
---
Notes:
pairs with patch in pve-common that adds this to the schema-schema. any
modules
setting that flag need a corresponding versioned depends
this is the last caller of PVE::AccessControl::check_permissions(),
which is the last caller of PVE::AccessControl::permission(). both can
thus be dropped altogether.
Signed-off-by: Fabian Grünbichler
---
Notes:
this is semi-independent, but if applied we need to remember that the
non-privsep tokens will always return the roles/permissions of their
associated users. privsep tokens will return unfiltered roles, but
filtered permissions.
Signed-off-by: Fabian Grünbichler
---
PVE/AccessControl.pm | 30 ++
PVE/RPCEnvironment.pm | 27
Signed-off-by: Fabian Grünbichler
---
Notes:
versioned breaks/depends with pve-manager and part of PMG?
PVE/APIServer/AnyEvent.pm| 22 +++---
PVE/APIServer/Formatter.pm | 9 +
PVE/APIServer/Formatter/Bootstrap.pm | 1 +
3 files changed, 25
Signed-off-by: Fabian Grünbichler
---
Notes:
versioned breaks/depends between pve-manager and libpve-http-server-perl!
versioned depends on libpve-access-control
PVE/HTTPServer.pm | 55 ++-
1 file changed, 30 insertions(+), 25 deletions
and store token ID in separate, currently unused member.
Signed-off-by: Fabian Grünbichler
---
Notes:
versioned depends on libpve-access-control
alternatively, we could also change the fork_worker signature and encode
this
inside the task information on disk, but that would be
we only care about the regular cookie case for the index.
Signed-off-by: Fabian Grünbichler
---
Notes:
versioned breaks/depends on libpve-http-perl!
PVE/Service/pveproxy.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/PVE/Service/pveproxy.pm b/PVE/Service
and I just realized that I dropped the per-repo subject-prefix from all
patches instead of just the cover-letter..
#1 is pve-common
#2-15 are pve-access-control
#16-18 are pve-http-server
#19-#23 are pve-manager
if you want a resend, just shout..
On October 17, 2019 3:13 pm, Fabian Grünbichler
On October 17, 2019 4:46 pm, Thomas Lamprecht wrote:
> On 10/17/19 3:13 PM, Fabian Grünbichler wrote:
>> to mark API methods which should not be available to clients authenticated
>> using an API token
>
> please wrap lines, for commit messages it's common to use <&l
On October 17, 2019 7:48 pm, Thomas Lamprecht wrote:
> On 10/14/19 10:28 AM, Oguz Bektas wrote:
>> in vm_pending API, this method is used to represent the configuration as
>> a table with current, pending and delete columns.
>>
>> by adding it as a guesthelper, we can also use it for container pen
es from the same node. Additionally,
> unlinking must happen at the very end of the deletion process to avoid that
> other nodes use the ID in the meanwhile.
>
> Co-developed-by: Fabian Grünbichler
> Signed-off-by: Dominic Jäger
> ---
> v1->v2: Move unlink to the end o
On October 17, 2019 6:40 pm, Thomas Lamprecht wrote:
> On 10/15/19 1:00 PM, Christian Ebner wrote:
>> When destroying a VM/CT, we intentionally did not remove all related configs
>> such
>> as backup or replication jobs.
>> The intention of this flag is to allow the removal of such configs on
>>
1 - 100 of 2770 matches
Mail list logo
