I noticed the following:
On my local Ubuntu machines at home I always create 2 User accounts for myself with sudo privileges so if I hose something up on one login I can always login using the 2nd User account and fix whatever is wrong with the 1st.
The 1st User on my home Ubuntu systems all have their default incus bridge named "incusbr0"
But any additional Users on those Ubuntu machines have their default incus bridge named "incusbr-1xxx" where "1xxx" is that additional User's system UID.
However, I just found that if I do the same thing on a Digital Ocean ubuntu server all Users are assigned an incus bridge following the naming convention:
"incusbr-1xxx" where "1xxx is that User's system UID.
But on Digital Ocean the 1st user is assigned "incusbr-1000" not incusbr0 as on my local systems.
Thought I'd ask if about the difference for the 1st User (UID 1000) on my local home Ubuntu Incus host servers?
On the Digital Ocean Ubuntu Incus Host there is an incusbr0 bridge.
But for every user if I execute:
$ incus network ls
Only the Incus bridge for "that" user gets listed.
example: for the 2nd user account it will list "incusbr-1001" only
Neither the incusbr0 or incusbr-1000 bridge is shown!
But on my Home Incus Hosts when logged in as the 1st user acct (UID=1000):
$ incus network ls
will list "all" User Incus bridges incusbr0, incusbr-1000, incusbr-1001 etc.
Just curious of the difference btwn the cloud & the local servers for UID=1000?
sudo privileges or not doesn’t really matter here, what does matter is whether the user is a member of the incus or incus-admin group.
If you are only a member of the incus group, then you’ll get a restricted user-specific project which gets its own bridge and is restricted in a way to prevent you from escalating to full root privileges. It will block privileged containers, will block a variety of devices and quite a few more features. You can easily spot this mode by doing incus project list. Such a user would only see their user-specific project and won’t see the default project.
When you’re a member of incus-admin instead, then you default to interacting with the default project and don’t get a user-specific restricted project at all, though you can see and can switch to any of the user-specific projects on the system (again incus project list and then incus project switch).
Where things can be slightly confusing is if you have a user who’s a member of the incus group who then gets added to the incus-admin group.
In that scenario, their CLI will have picked up the user-specific project and set that as the default, so they’ll still be interacting with that restricted project by default. Though they can do incus project switch default to interact with the default project as they would if they had been a member of the incus-admin group from the start.