Wireguard: "Patching" AllowedIps and interface PostUp

[robi]

Look for a start.sh or run.sh file which gets called on start.

[sirthias]

Thank you, robi, I've seen /app/code/start.sh and it'd be a great place to put the needed changes, but this file is not in the /app/data/ folder and -- as such -- isn't writeable.
It seems to me I have to somehow sneak something into /app/data/ as that's the only place I have influence over.

One thought: Could I simply patch /app/data/wg/wg0.conf and chmod -r it to prevent it being rewritten on app restart?

[robi]

@sirthias probably not -r, how would the app read it?

Needs some TLC from staff and a package fix

[sirthias]

Ah, of course I meant -w to prevent the rewrite.

I don't think there is a lot of TLC required.
One additional line in start.sh would suffice, which simply checks for the existence of a custom script like /app/data/poststart.sh and calls it if it exists.
So, a hook for custom logic to run after the app has started and the tunnel is up.
Where can I best propose/submit this little feature request?

[robi]

This is it, however it is the weekend and staff need a break

[girish]

@sirthias if I understand correctly, you are adding a device that has a network behind it. What do you think of taking this network IP (or a list of IPs) when adding a new device? This way we don't need the special scripts.

[girish]

Something like this:

[robi]

@girish It would still be useful to expose an editable configuration file for future remote control or even API management.

Automation

[sirthias]

@girish Yes, of course, it'd be great it the VPN App had native support for routed networks behind a device.
This would make it easier for users who are less experienced with networking setups to quickly set this up.

I'd be happy to test-drive an update if you'd like to make one available.

Nevertheless I agree with @robi in that providing a simple hook for a custom script in the /app/data/ directory would also work and be even more flexible.
It wouldn't even have to become part of the UI and thus be somewhat less intrusive to the clean nature of the app.

Cheers
Mathias

[girish]

We prefer a UI-based and use case driven configuration approach to our software. You can even say flexibility is not a goal for this app. There is no way we can support complicated VPN setups that would arise from all the various configurations. Part of the reason this app exists is that the OpenVPN without the UI is really complicated to use for normal people. Of course, people are free to change the source to match their philosophy of how software should be :).

@sirthias I pushed a change with minimal testing, please check.

[sirthias]

I completely understand @girish. It's great that you have a clear vision for Cloudron's development which acts as a good guideline in cases like this.

@sirthias I pushed a change with minimal testing, please check.

Where can I see/find that change and how can I test it best?