nanopack / portal

An api-driven, in-kernel layer 2/3 load balancer.

nanopack

Hub for nanopack resources and content

portal's Issues

Configure connection timeouts to free proxy resources

Firewall blocking router ports

By default, portal should allow traffic in on the configured router ports (default 80/443). Workaround for now is registering the router as a service listening on ports 80 and 443 with "127.0.0.1" as the server ip.

Add health check to load balancer

This can bed defined by url and expected response code/body/header, but should remove the container from the rotation. Once healthy, it can be added back in.

CLI

CLI to interact with the daemon.

Create/Remove services

Add new services into the ipvs system
Service needs to have an ip address, port, scheduler (round robin, weighted round robin, least connected, ...), and protocol (tcp, udp)

Scribble database support

Initial support for storing data in a scribble database.

Add/Remove Servers

Add/remove servers from registered services. This will require host and port.

Sync services and servers

Synchronize the rules on the system with the services and servers for each service in the database

Pluggable database to store routes

If LVS doesn't keep it's own, be able to store information to rebuild the routes in a database.

pagodabox/na-lvs library not available anymore.

Hi guys!

The na-lvs library is not available anymore :(

The reference is here: https://github.com/nanopack/portal/blob/master/routes/server.go -line 15

If you have it locally please share with it somewhere, or try to put it in portal repo.

Cheers!

Set x-forwarded-proto header for http/ws

Currently it is only getting set on https requests

Deny adding services listening on ports 80/443

Since the router will listen on ports 80/443, portal should prohibit services from being registered using the same address that the the proxy-[tls|http] uses.

Start up and read settings from a config file

Upon startup it should read settings and configure itself using a config file.
Things to store in the config file:

• auth token
• host/port to listen on

respond to user provided data errors with 400 range response

Would it be possible for portal to respond with a 400 range response rather than a 500 when the error is a result of user provided input? For example:
500:{"error":"tls: failed to find any PEM data in certificate input"}

Reset the entire list

Option reload the entire db from a payload.

handle special characters in certs like é, ó

When a cert field has special characters like Velavi Cosméticos or Niterói portal responds with 500:{"error":"asn1: syntax error: PrintableString contains invalid character"} when attempting to register a new cert.

Ensure protocol is either tcp or udp

If a service is added with http for the protocol, iptables errors and a 500 is returned, maybe catch it faster and return a 4xx error.

`PUT`ing to `/services` allows duplicates

PUT /services the following body

[
  {
    "id": "tcp-192_168_0_2-7410",
    "host": "192.168.0.2",
    "port": 7410
  },
  {
    "id": "tcp-192_168_0_2-7410",
    "host": "192.168.0.2",
    "port": 7410
  },
  {
    "id": "udp-192_168_0_2-514",
    "host": "192.168.0.2",
    "port": 514
  }
]

with nginx as the balancer causes duplicate upstream blocks to be created and nginx fails to listen. Need to ensure list of services is unique before writing to config.

Support HTTP2

Currently the only way http2 is supported is by setting a web-server (nginx), complete with certs to listen on a different port, then configuring it as a 'service'. simply adding https://<IP>:8081 as a route target isn't sufficient for the http2 upgrade.

Portal cli `-i` should not depend on server `-i`

A portal server started normally ./portal -s will generate a certificate and listen securely. When the cli tries to access portal from a machine that doesn't trust the cert, we get the following error:

$ ./portal show-services
Could not contact portal - Get https://127.0.0.1:8443/services: x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs

The server gives us this helpful logline when started with -l trace:

2016/04/07 16:24:53 http: TLS handshake error from 127.0.0.1:49473: remote error: bad certificate

We can either add the (unknown) generated cert to our trusted list and try again, or try using the -i flag to ignore the cert check. Unfortunately there is a bug:

$ ./portal show-services -i
Could not contact portal - Get http://127.0.0.1:8443/services: malformed HTTP response "\x15\x03\x01\x00\x02\x02"

# Portal server log
#2016/04/07 16:23:11 http: TLS handshake error from 127.0.0.1:49472: tls: first record does not look like a TLS handshake

Notice it tries requesting http://. Portal cli shouldn't assume that the server was started with -i just because we want to ignore the cert check.

Allow SSL v3 connections for older clients

There are some embedded devices that are not getting updates. They need SSLv3 to be able to connect.

Open/Close firewall when services are created/removed

Modify the iptables rules when services are created/destroyed so the traffic can actually flow.

add port to error message "Port Already In Use"

Would it be possible to add the port that’s already in use to this error message?

portal/api/api.go

Line 61 in 2a7d436

BadListenAddr = errors.New("Port Already In Use")

So something like Port 80 Already In Use.