NetBird - WireGuard based VPN

[marcusquinn]

@andreasdueren investigating...

[marcusquinn]

@andreasdueren courtesy of AI — opus does all my r&d now):

Glad it works! It isn't fully automatic, by design:

• NetBird keeps external login providers in its database and only accepts new ones through its API from a logged-in owner. The combined server's config.yaml (v0.80.0) has no option to predefine an OIDC provider. Doing it at startup would mean storing an owner API token inside the app, and it could overwrite an existing provider or spread the client secret around.
• If you ticked Cloudron SSO at install, it's about a minute of work: Settings > Identity Providers > Add > Generic OIDC, name it Cloudron, and paste the values from cloudron exec --app <app> -- printenv CLOUDRON_OIDC_ISSUER (then CLOUDRON_OIDC_CLIENT_ID and CLOUDRON_OIDC_CLIENT_SECRET). Keep the built-in email login working as your recovery login.
• To script it, or to add Cloudron login to an install without SSO, scripts/cloudron-sso.py in the repo does it with short-lived tokens; see docs/SSO-SWITCH.md. A login client added that way doesn't follow the app's Cloudron access list, so the script requires NetBird's new-user approval to be switched on.

If NetBird adds login providers to config.yaml, I'll switch the package to that.

And some more improvements from testing in a new release:

The monitoring guide now covers the proxy backend over IPv6 as well as IPv4 (PR #183, merged). This was a docs-only change, so no new package was published and your app stays on 2.4.3.
What changed in docs/MONITORING.md:

• A new IPv6 row for the inverted <closed> check on the proxy backend port.
• A note that Docker publishes app ports over IPv6 too, so on an IPv6 server you need the check for both IPv4 and IPv6.
• The API example now includes the IPv6 native-port and IPv6 backend checks.
• A note that updown rejects a URL that is already registered, so running the example again is safe. I saw this happen when I re-ran my own script.
  The docs and package tests passed, and CI passed.
  You already have both IPv6 checks running for your server, and both are up.

[andreasdueren]

@marcusquinn Looking into this, I found NetBird’s automated setup documentation, which looks like it could offer an alternative for fresh installs.

With NB_SETUP_PAT_ENABLED=true, the initial POST /api/setup request can create the local owner and return a short-lived PAT. A setup script could then use that token to call POST /api/identity-providers, passing Cloudron’s CLOUDRON_OIDC_ISSUER, CLOUDRON_OIDC_CLIENT_ID and CLOUDRON_OIDC_CLIENT_SECRET as a generic OIDC provider.

The provider configuration would remain in NetBird’s database, so the bootstrap token could be revoked afterward rather than kept inside the app. The local owner login could remain available for recovery.

Would that be worth considering for automatic SSO configuration when the Cloudron SSO checkbox is selected?

[marcusquinn]

@andreasdueren Claude Opus 5.5 says:

Thanks Andreas, great suggestion. It's in NetBird package 2.6.0.

When the app is installed with Cloudron SSO ticked, the owner's first /setup goes through a small loopback helper. It adds create_pat: true, pat_expire_in: 1 (the dashboard doesn't send these) and uses the token once:

• turns on new-user approval;
• adds a Cloudron OIDC provider from the addon credentials, unless one already exists;
• deletes the token, checks it no longer works, and removes it from the response to the browser.

Nothing runs at startup, and the token and secret are never logged. The local owner login stays as the recovery login. If registration fails, setup still succeeds and the log points to the manual steps. Cloudron users wait for approval before they get access.

I've tested the fallback path (unreachable issuer, token cleanup). I haven't yet tested a successful registration on a real fresh SSO install, so reports are welcome.

The dashboard's Add Peer command now also includes --enable-rosenpass --rosenpass-permissive by default.

[marcusquinn]

@james do i get an APP DEV badge of honour yet?

[marcusquinn]

@robi rosenpass is on by default now

[marcusquinn]

@stevespaw my aidevops.sh harness has all the skills needed for Cloudron app packaging, now. I used that and Opus 5.5 to package this, and other community apps.

Worth a try if you want to package RustDesk & ManageEngine. It's prob a few hours work, and with ssh to a cloudron instance can do all the testing for you, too.

[james]

Hello @marcusquinn

@marcusquinn said:

do i get an APP DEV badge of honour yet?

You have 3x community apps, if you'd like the badge I'll add you.

[marcusquinn]

@james how many apps do you want?

Jeez, just seen my post count, here. You got a badge for SUPER FAN too?

[james]

Hello @marcusquinn

@marcusquinn said:

You got a badge for SUPER FAN too?

Not yet, but maybe we could add such a thing.
I know that Discourse has some gamification for topics read, created hearts given and received and more.
There even is a gamification in Discourse if you finish the tutorial of how to write topics you get a certificate and a badge.

[marcusquinn]

@james ahah, gold for you my friend

[necrevistonnezr]

@marcusquinn said:

@andreasdueren Claude Opus 5.5 says:

Did @andreasdueren just outsmart Opus?

[jdaviescoates]

@james said:

You have 3x community apps, if you'd like the badge I'll add you.

Wait, don't get me wrong, I think @marcusquinn is great, but the AppDev badge existed before Community Apps did, and until this moment I think had been reserved for people who initially packaged apps that are now in the official app store.

Given @staff's understandable desire to distinguish between official and community apps (the latter of which are of varying quality) IMHO it should probably be reserved for that.

[james]

Hello @jdaviescoates
The @appdev badge/group has been used like you have mentioned, but also for people who contributed to existing apps.
There also is the badge for @validated-app-maintainer which we currently use for upstream maintainers.

@jdaviescoates said:

I think had been reserved for people who initially packaged apps that are now in the official app store
...
IMHO it should probably be reserved for that

Hmm.
I understand your sentiment. I will create a group/badge for Community App Maintainers.
This also helps to identify people in the forum that maintain community apps.

@marcusquinn
Now that I have given you the badge, would you be okay with a Community App Maintainer badge instead?

Edit:
Now there is @community-app-maintainer and I have added everyone I could find from the community app store.

[marcusquinn]

Whatever you guys want is fine by me.

I generally keep up with notifications from here regardless, so if anyone has any issues with the apps packaged, just reply on the threads discussing them or log an issue in github.

If Cloudron does or doesn't also want to adopt any apps, also fine.

Needs and preferences are what they are. I'm just happy to be unconstrained to create what we need, and share the joy for the wisdom of the crowd to be more important than any one of us.

[timconsidine]

@marcusquinn said:

I'm just happy to be unconstrained to create what we need, and share the joy for the wisdom of the crowd to be more important than any one of us.

well said

[marcusquinn]

@james ahaha, brilliant, we have SUPER FAN badges

[james]

Hello @marcusquinn

The @super-fan badge and group will automatically be assigned to users that posted more than 500 times in our forum.
If you have more then 500 posts and you don't see the badge, edit your profile and you can enable the badge visibility or also hide it.