Signed-off-by: Moayad Almalat
---
qm.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qm.adoc b/qm.adoc
index 333b2e6..0ff9f1f 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -203,7 +203,7 @@ either the *raw disk image format* or the *QEMU image
format*.
format does not support t
Hi Alwin,
> Hi Moayad,
>
> February 10, 2021 8:16 AM, "Moayad Almalat" wrote:
>
> > Signed-off-by: Moayad Almalat
> > ---
> > qm.adoc | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/qm.adoc b/qm.adoc
> > index 333b2e6..1108908 100644
> > --- a/qm.adoc
> > +++ b/q
On 10.02.21 17:01, Oguz Bektas wrote:
> maybe a simple approach like this is okay?
>
I'd rather go the way PBS does, just listen on really all by default.
PVE often uses multiple networks where the proxy needs to be able on more
than one, a single settign may not cut it in all setups.
It's simp
Thanks for looking into this!
On Wed, 10 Feb 2021 17:01:42 +0100
Oguz Bektas wrote:
> default to 0.0.0.0 to preserve backwards behavior
>
> Signed-off-by: Oguz Bektas
> ---
> PVE/Service/pveproxy.pm | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/Service/pvepro
default to 0.0.0.0 to preserve backwards behavior
Signed-off-by: Oguz Bektas
---
PVE/Service/pveproxy.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/PVE/Service/pveproxy.pm b/PVE/Service/pveproxy.pm
index 571a6bf5..ce1d42a6 100755
--- a/PVE/Service/pveproxy.pm
+++ b/PVE
maybe a simple approach like this is okay?
can also be called "LISTEN_IP" or similar
pve-manager:
Oguz Bektas (1):
proxy: allow setting BIND_IP for pveproxy
PVE/Service/pveproxy.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pve-http-server:
Oguz Bektas (1):
utils: add BIND_
to allow setting arbitrary IP address to listen on
Signed-off-by: Oguz Bektas
---
PVE/APIServer/Utils.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/PVE/APIServer/Utils.pm b/PVE/APIServer/Utils.pm
index e843e5f..94bacb8 100644
--- a/PVE/APIServer/Utils.pm
+++ b/PVE/APIServer/Utils.pm
the patch fixes a potential panic on systems running ZFS > 2.0.0 and
is already queued for inclusion in 2.0.3 - see [0] for a related
github issue.
[0] https://github.com/openzfs/zfs/issues/11474
Signed-off-by: Stoiko Ivanov
---
tested by compiling our current 5.4 kernel and booting that in a vi
Hi Moayad,
February 10, 2021 8:16 AM, "Moayad Almalat" wrote:
> Signed-off-by: Moayad Almalat
> ---
> qm.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qm.adoc b/qm.adoc
> index 333b2e6..1108908 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -203,7 +203,7 @@ either t
On February 10, 2021 12:05 pm, Stefan Reiter wrote:
> Patch looks good in general, but the added file does not follow our
> formatting for the other patches. I'd prefer to keep them the same, or
> at least applicable with 'git am'.
>
> Since one of us is going to have to rebase anyway, I can als
Installing the ha-simulator on a PVE node directly to start it via ssh
and x11 forwarding will need the 'xauth' package installed on the PVE
node as well and X11Forwarding enabled.
Otherwise one is likely to encounter the following error when starting
the simulator: `Unable to init server: Could n
Hi Moayad,
February 10, 2021 8:16 AM, "Moayad Almalat" wrote:
> Signed-off-by: Moayad Almalat
> ---
> qm.adoc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/qm.adoc b/qm.adoc
> index 333b2e6..1108908 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -203,7 +203,7 @@ either t
Hi,
first of all, sorry for the late reply.
It seems that long lines got warped and the patch therefore does not
apply. Please use 'git format-patch' and/or 'git send-email'.
Is there a specific reason why you opted for gzip with the default
options instead of e.g. zstd?
ZFS itself can prod
Patch looks good in general, but the added file does not follow our
formatting for the other patches. I'd prefer to keep them the same, or
at least applicable with 'git am'.
Since one of us is going to have to rebase anyway, I can also send along
a fixed up version with v2 of my 5.2 series if
so the test still works when it's not installed.
Signed-off-by: Fabian Ebner
---
PVE/Diskmanage.pm | 8 +++-
test/disklist_test.pm | 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/PVE/Diskmanage.pm b/PVE/Diskmanage.pm
index e356fb3..64bb813 100644
--- a/PVE/Diskmanag
haven't taken a closer look at the GUI stuff as I think the backend will
potentially change a bit more.
also regarding the permissions and the problem of importing from
arbitrary paths, I wonder whether a simple file upload to a dir storage
to
import/$authuser/$file
if the user has permission
high level review: this is starting to take shape :)
I wonder whether it doesn't make sense to add proper permissions
already? most of it is handled in PVE::Storage::check_volume_access
or check_storage_access in this API module already.. the latter could be
extended to handle the new special s
17 matches
Mail list logo
