Man I had high hopes for Pine64 but open source software is also not great. I'm talking a $400 phone with cameras that don't work. Which isn't Pine's fault but yeah.
I want Pine64 to work, but I have a shelf of e-waste because I bought in, hoping. It seems they have selectively alienated some of the developers working with their hardware, rather than feeding the community they expect to produce the software ecosystem that sits around their hardware.
Yes, but the OpenPandora is actually useful for the task. Tons of apps in the repository and not just emulation but original homebrew too. And it just works like a polished product.
After 10 years, the Pandora still is one of the best emulation handhelds out there.
It's just a config generator but you can share the configs. You bring your own cloud.
Check the generated examples once you log in, but for a hub and spoke network let's say, the idea is this:
- Create your network.
- Add a device. Name it hub. Label it hub. Do not assign the device to your self, but create a guest invite. Name the invite hub.
- Add more devices, one for each server or enduser device. Label them as you wish. For servers, create guest invites. For enduser, create guests or members. Guests don't need to create an account to get their configs.
- In connections, add two rules. all to hub, and hub to all.
Now the network is defined, but there are no associated private/public keys with these devices. You need to create Interfaces for that.
For your servers, for which you created guest members, create an interface for each device. Either generate the keys in browser, or just provide the public key if you already have one.
For the hub interface, you need an endpoint url, that's where all other devices will connect to. No endpoint is needed for the other interfaces.
For the devices belonging to end users, just copy and share their invite url. They will be able to generate their own Interfaces and keys.
During all these changes , all configs are kept in sync.
Going back to your server devices, you can just curl their respective interface url (including the invite code) and you'll get your config. Add a cron and a fallback in case of a botched change, and you're set. (in theory at least)
I'm going to be honest, I didn't understand the use case of the site until I read this comment.
And I've worked in IT for 25 years, I make and manage my own wireguard setups.
I wish new products and sites were more to the point in how they're supposed to be used. I generally don't check the docs unless I already have an inkling that I want to make use of it.
So in other words this is a service for the selfhoster that provides wireguard to their family and friends. This way they don't have to manually send them a config or a qr code, instead just send them to this site.
> And I've worked in IT for 25 years, I make and manage my own wireguard setups.
You are the target audience, I guess, so your feedback is doubly appreciated. Thanks! :)
You described it just right. That's it. Right now, on the "hero" section of the landing page, I have this:
The easiest way to create and share WireGuard Networks.
Define WireGuard networks, devices, and connections.
Invite friends, family and teammates to add their devices.
View, Scan or Download WireGuard configuration files.
>The easiest way to create and share WireGuard Networks. Define WireGuard networks, devices, and connections. Invite friends, family and teammates to add their devices. View, Scan or Download WireGuard configuration files.
I think it was a combination of me not expecting a service like this, and the fact that you use terminology like "invite".
You mean that as in "add devices of friends by inviting them" right? Because the main question in my mind is "wait, who's generating the keys? who's storing the keys? who has access to my private key?"
I do not want to tell you how to write stuff, I'm an autistic nerd with limited people skills. But I think it would make more sense if you said something along the lines of "easy way to share client wireguard config with friends and family".
No, I get it. I'm not a network guy so I don't know the terminology :)
What I think is kind of confusing, is that I'm separating the notions of a Network Device and the WireGuard Keys that go with a device. So it's like this:
Network <-> Device <-> Invited Member <-> Interface (PrivateKeys)
As a network owner/admin, you get to define your devices, routes/connections etc. To associate and/or generate keys for those devices, there's a separate step, the Interfaces. Those are managed by end-users themselves, who can generate and encrypt their key set right from the browser.
Of course, you can just create an Interface for each device in your networks so that your end-users won't have to do anything other than scanning the QR codes or downloading the relevant configs to their devices.
This design makes it super clear who has access to what: Interfaces are owned by their creators, Devices are owned by their Network owners or the Member they were assigned to. Also makes it easier to make changes to WireGuard related data (key rotation maybe?) without needing to make changes to the network-level settings.
> "wait, who's generating the keys? who's storing the keys? who has access to my private key?"
So, the user owning the network or the device can generate keys for that device. The private keys, if provided, are encrypted in the browser before storing them on WireHub. The user who created the Interface has access to the private key, if they provided it, and if they remember the password they used to encrypt it in the first place.
If you forget the password to an Interface, you create a new Interface for that device with a new set of keys. The configs of all other devices will be updated to reflect that change (they will need to re-download and re-install of course).
Thank you for the quick how-to. Makes for a great intro to see how you thought about the workflow. I was able to follow it no problem and now understand the Connections section. Of course you have the pre-loaded examples in there as well. Pretty neat actually! What I also really like is the export function for a quick backup. Do you have an example of the cronjob?
So for the cronjob part, that only applies to devices assigned to guests, as they can be used without creating an account on wirehub.
- Create your invite, Guest Role.
- Assign the Device to that Guest.
- Add an Interface on that Device.
- Preview the network as that Guest (click the eye icon next to their username). Open the URL in a new private window, because you need to:
- Accept the Invite.
- As that Guest, you'll just see the device(s) assigned to you. Click on the config button for any device and right click, copy the Download URL. That should contain the invite_code as well, which is basically the authorization token for that Guest.
This pulls the config and stores it in `wg0.conf`. The [Interface] section though is invalid (as there's no private key). So you'd have to either generate the keys on the server or somehow get them there. From then on it's just standard wg-quick and wg to create the interface and load your keys.
After the cron job, you'd want to do something like `wg syncconf wg0 <(wg-quick strip wg0)` so that wireguard picks up any changes from the pulled config.
