Pagekite using augeas

Created by: fonfon

Most of the pagekite actions are handled via augeas now. Users can:

• use any frontend server, not only pagekite.net
• use ssh
• define custom services: raw/http/https with any frontend to any backend port

This closes #46 (closed) except for "Explore using other FreedomBoxes as frontend servers", which is an interesting option and I don't see why it shouldn't work.

This pull request got bigger than I thought, I'm happy about proposals how to implement some parts in a simpler/cleaner way.

Further notes:

• the pagekite lens included here is not the one that's in the most recent pagekite release. The pull request is pending: https://github.com/hercules-team/augeas/pull/193. That's no problem because custom lenses have precedence over dist lenses, see https://github.com/hercules-team/augeas/blob/b61a78d2e629e4f1395270a1ee72876e27b12990/src/augeas.c#L497 -- so our lens will be used even if later on the old lens gets installed via the (not yet existing) debian package.
• In two cases the config can't be written using the pagekite lens (that's perhaps a bug or missing entries in the lens). In these cases I just edit the config files via python.

Some thoughts about pagekite and its configuration that you don't have to read to review the pull request:

• it's strongly and unnecessarily bound to pagekite.net which is surprising for a debian package. pagekite --add 80 mybox.customdomain.net will just tell you to either use a pagekite.net account or configure your services manually.
• so you configure everything manually and get the services running. The pagekite --list command won't detect your services (i.e. HTTPS) although they are up and running. To remind you, that's the same program that actually runs the services.
• theoretically, the pagekite command would offer all options we need: configure frontends and list, add and disable services. But it's too unreliable/buggy to use programatically.
• the configuration is awkward. There are literals like abort_not_configured (which should mean run_as_service=no or so) and defaults (which will use the pagekite.net frontend and should be deleted entirely, just use frontend=pagekite.net ).
• because of these literals it's not valid .ini syntax (which is my smallest concern)
• the service_on entries throw the frontend port and the protocol into one field (all fields are colon-separated). Sometimes the port is optional, so http is equal to http/80 which makes reading/writing the configuration unnecessarily complicated.
• pagekite.py comes with loads of servers and encryption options, it tries to solve everything at once. Yet it fails at simple tasks like listing its own services, so I wouldn't trust that other functionality too much.
• it's not very active anymore, but there's one fork where somebody is carving out all the servers/encryption that pagekite brings along