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>
In order to test did the following:
`systemd-socket-activate -l /run/incus-user.sock $PWD/incus-user -d -v 2>&1`
in separate terminal connect and disconnect to the socket:
`nc -U /run/my_app.sock`
Wait and obtained following shutdown log:
```
INFO [2025-11-24T12:33:45+09:00] Starting up the server
INFO [2025-11-24T12:34:20+09:00] Daemon has been inactive, shutting down
```
Signed-off-by: Olivier Lechevalier <olivier.lechevalier@gmail.com>
Refactor logging setup so that it matches the rest of the code base. Add
support for --verbose and --debug, similarly to other commands.
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
The logic used to figure out the correct Unix socket path for access to
the demon in `client.ConnectIncusUnix()` was fixed in in
d8b78d5007 to account for use of
/run/incus/unix.socket as an alternative socket location. However, the
proxying code of incus-user was not updated when the fix was
introduced. As a result, even if initial connection to the server and
the configuration queries were successful, the actual attempt to proxy
a client request would fail while trying to connect to
/var/lib/incus/unix.socket regardless of prior findings.
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Add logic to keep track of the available projects and if the user's
project is missing, re-create it automatically.
Closes #1149
Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
