Page MenuHomeVyOS Platform

New "service https" implementation
Closed, ResolvedPublic


Now that we have a working HTTP API prototype, it's time to resurrect "service https" that has been removed from the nightly build along with the corpse of the old GUI.

Some considerations:

  • nginx-based, obviously. That's the default HTTP server now.
  • HTTP applications such as API and GUI must be explicitly enabled, by default just display a static info page
  • user-supplied cert support would be cool, but intermediate certs may make it complicated
  • support for custom proxy rules would be nice

A draft of what we need right now:

service https
  # global options
  listen-address <IPv4|IPv6|any> (multi)

  # applications
    port <port number>
    debug <valueless>
        id <txt>
          key <txt>

There's also a bit of a chicken and egg problem: API and in the future the GUI are HTTP servers on their own, but they also need the HTTP proxy. So we likely need separate scripts for configuring the proxy, and one script per API/GUI/etc.
The proxy configuration script can look into the subtrees to see what port to proxy requests too etc.
We need to find out if making the proxy script the "owner" of "service https" and making the API script the owner of "service https api" is sufficient to achieve that, or we need to do some trickery to make sure when you change "service https api port" for example, both scripts are triggered.


Difficulty level
Unknown (require assessment)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change

Event Timeline

dmbaturin created this task.

I'd propose adding letsencrypt support for the certificates, too

When were talking web-interface (not the api itself) it needs to have the functionality to "stage" multiple changes before commit'ing everything in one go, just like in the cli

Just to confirm, HTTP proxy in this context being nginx being a reverse proxy frontend for GUI and API HTTP servers, likely living on localhost bindings, right?

I ask, because being able to serve an onboard PAC file for the onboard squid web proxy instance would allow PAC file self servicing, though that would also depend on DHCP server WPAD URL configurations, and being served via HTTP due to the chicken/egg issue of trusting an SSL certificate during PAC file retrieval by an isolated client.

jestabro changed the task status from Open to In progress.Jul 1 2019, 7:44 PM
dmbaturin changed the task status from In progress to Needs testing.Sep 5 2019, 1:09 AM
dmbaturin set Is it a breaking change? to Unspecified (possibly destroys the router).
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Behavior change.
syncer moved this task from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.3) board.
syncer moved this task from In Progress to Finished on the VyOS 1.3 Equuleus board.