This introduces a new custom OIDC claim (`incus.restricted_subnets`)
which can be set by the IdP to a list of CIDRs that are allowed access
to Incus.
That's useful to restrict access for Incus for some specific users to a
specific set of source subnets (VPNs).
Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
Currently, incus-user might reset a user's setup if the project name
doesn't match the expected format. This change checks if the user
already has a valid certificate and access to at least one project
before attempting a reset.
Fixes #2524
Signed-off-by: Marcos Guillermo <marcos.cosson@ccc.ufcg.edu.br>
cmd/incus-user: Don't reset setup if user has access
Currently, incus-user might reset a user's setup if the project name
doesn't match the expected format. This change checks if the user
already has a valid certificate and access to at least one project
before attempting a reset.
Fixes #2524
Signed-off-by: Marcos Guillermo <marcos.cosson@ccc.ufcg.edu.br>
Fixes https://github.com/lxc/incus/issues/2776
When growing an FS volume, the remote volume was resized, but the change
was not visible until the remote volume was re-activated.
Thus the filesystem was only expanded to the visible size, but since the
visible size was still the old size, this would cause a quiet failure.
The first thing to do was to actually check the device size after the
resize to determine if the resize had succeeded before attempting a FS
resize, which should then succeed
The second part of the fix is to simply activate the volume after resizing
it rather than before, which means it can succeed.
Unfortunately, this means we could no longer grow an inUse filesystem, as we
must de-activate in order to re-activate.
To rectify this, `iscsi refresh` support was added to the TrueNAS tool,
and when using version >=0.7.5, the driver can refresh the iscsi bus to
pickup a size change without having to de-activate an inUse volume.
When the `iscsi refresh` command is not available, and the volume is not
in use, the driver will atttempt to de-activate the volume before changing
the size.
Signed-off-by: Stuart Espey <stuart.espey@mactrix.com>
The logic currently fails and I believe for good reasons.
It's not safe to mount and rsync data from a volume which may be mounted
elsewhere. Unless snapshots copies can be handled at the Linstor level,
they would need to be redirected to the migration codepath to have the
server currently running the container/VM send the data over.
Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
Replace Example test with proper unit tests for all URL builder methods.
Focus on testing our business logic rather than standard library behavior.
Fix Target method comment (checks "none" not "default").
Signed-off-by: baconyao <bacon735392@gmail.com>
