Episode: 910
Title: HPR0910: Introduction to Pagekite.
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0910/hpr0910.mp3
Transcribed: 2025-10-08 04:46:42

---

Hi there, this is Kevin Grenade. Welcome to my awkward second episode. Today I'm going
to introduce you to PageKite, a service for exposing your local servers on the internet,
written by Jotterny Anderson. The name PageKite is shared by the service provided by PageKite.net,
the software that implements its infrastructure and the protocol used by the software. For
most of the cast, when I say PageKite, I mean the service. PageKite.net is a service run
by the Beanstalks project, an employee owned ice-landic company that also holds the copyrights
to the open source PageKite software. The PageKite software is implemented in Python
and released under the AferoGPL license. In a nutshell, PageKite is a reverse proxy tunneled
over SSL that provides a name service. Let's break that down. A proxy is software that a client,
for example, a web browser, connects to in order to talk to an external network, usually
the internet. Generally, the client asks the proxy to fetch a resource in the proxy
connects to the outside world to do so. Proxies are used to bridge clients to the internet
when they don't have direct access, filter out unwanted requests and replies, and or shield
the identity of the client. Many corporate environments deploy filtering proxies to prevent
employees from accessing certain sites, but another well-known proxy is Tor, which uses
forwarding and encryption to hide the identity of its users. Technically, a reverse proxy is
almost the same thing, except instead of working for a client, a reverse proxy is working for
a server. It sits between the server and the internet, accepting all incoming connections
and forwarding them along if they look reasonable or important. Reverse proxies are usually used
to reduce the load on a server, balance traffic between multiple servers, or to improve security
by imposing policies on what kind of requests are allowed. In the case of PageKite, and I think
Tor, they can also be used to protect the anonymity of servers situated behind them. Tunnel over
SSL is pretty self-explanatory. The service tunnels its connection over SSL. PageKite also provides
a name service. If you sign up for an account, you get a yourname.pagekite.me name that points
at your server. In plain English, the system gives you a fast, simple, secure way to run a server
in your home and access it from anywhere you have internet access. If you've looked into hosting
a server from your house, you may be thinking, what about Dynamic DNS? Well, it did try Dynamic DNS
first, but it turns out my ISP blocks incoming packets on port 80, also port 443, also they lie to
you about it when you ask them why your traffic isn't getting through. So what if your ISP actually
lets you use your connection? Well, there's one thing that gives me pause even if you can set it
up. So you configure your server. You point a DNS entry at it, which is updated via Dynamic DNS.
And you forward the ports you're using from the router to the server. Now, this is the standard
issue consumer router that your ISP gave you. And now it has a signpost on the internet pointing at
it. I don't know about you, but while I have DDWRT on my router, I don't really know how securely
configured it is. And I'm pretty sure figuring out whether it is or not and setting it up to be
would be quite a task. This brings us to something else, PageKite brings to the table limited
exposure. PageKite doesn't expose your IP address like Dynamic DNS does, it only routes traffic
of the correct protocol straight to your server. You may very well be confident that your router is
secure, but if you're starting out, it seems unlikely. Another feature that wasn't really a
selling point for me, but I can see the benefit of it. PageKite is much more responsive to your
local IP address changing. Since it's your server initiating a connection, there's no need to wait
for information to propagate like with DNS. An example of a scenario where this would actually
be very useful is if you ran a server on a portable device like a laptop or even a phone.
That might seem odd, but as long as the device has internet access, it can maintain an SSL
connection to PageKite and anybody on the internet can access it. Obviously you don't want to run
a heavy-duty server on your phone, but for example, you could run OpenID and have your identity
centralized in your phone and it's actually fielding queries to verify who you are.
Rounding out the benefits is the fact that since your server traffic is being transmitted via SSL,
your ISP can't take a look at the contents. So I hear you asking, what do I need to give PageKite a try?
Well, you need an internet connection and a server. That's it. Notice I didn't say web server
there. PageKite is definitely geared towards HTTP, but it can also proxy for SSH, web socket,
IRC, and finger. Development is continuing and got our need continues to add new protocols.
One limitation to be aware of, though, with most protocols other than HTTP is that the client
that you use to connect to the server must be HTTP proxy aware. A word on price, PageKite charges
based on data usage. Currently, they're charging $15 for 10 gigabytes of data.
Also, to get you started, they give you two and a half gigabytes of data for signing up.
As an anecdotal example of how long that will last, I set up my PageKite account on November 25th
and have only used about half a gig as of December 14th. I'm running a status net instance 24-7
and playing with an own cloud server. At the current rate of usage, I'll run out of my starter
quota sometime in February and a $15 purchase will last me most of next year. The price overall
seems on par with or possibly a little bit lower than really basic hosted serving, but without
a lot of the limitations such as lack of SSH access and ability to install things. That having been
said, though, the software is open source and the AferoGPL requires the Beanstalk project to make
the version of the software that they use available. So, if you want to make use of PageKite's
features and you already have an internet-facing server you can put it on, you can run an instance
yourself. To ground all of this in reality, here's a loose outline of bringing up my status net
instance. A few disclaimers first. I am a professional, but feel free to try this at home.
I spend a lot of time getting the services set up, but that's partially because I'm using a
15-year-old server that's running Gen2. What can I say? I like pain. I spend a long time just waiting
for things to compile while in most distros, whatever package manager you have, install
my SQL Apache PHP would have gotten things done in 20 minutes or so. First, I set up an Apache
instance on my server and made sure I could access a simple page from another computer.
Not counting compilation time, this only took about 30 minutes, and that was because I'd never
looked at an Apache config file before. I checked out the latest status net code from Gatorius and
installed the software requirements. Status net is written in PHP and uses my SQL for the database
by default, so I installed those. Then I configured status net, the hard parts of which were
configuring Apache and setting up the MySQL user, since I don't know my way around either program.
Part of the status net setup is loading the page for final configuration, so saying that
testing that I could access it is a bit redundant. This book, this bit, took several evenings of
spare time due to me not understanding mod rewrite and how Apache handles filing URL paths,
but eventually had it sorted out. Once it was working on my LAN, I grabbed the pagekite software,
and I think I could log into my status net instance from the pagekite address within about 30 minutes.
I think I then spent four or five evenings tweaking my status net settings mostly because of my
underpowered server. I decided at some point that I wanted to grab a domain to serve all this
under, so I shopped around for a name provider and grabbed linux wrangling.com. Then I spent the
next three evenings reconfiguring things, since status net is pretty strict about the domain it
lives on, since the domain provides part of your identity, and I think it is included in some
crypto signatures in the O status and open ID protocols. The entire process hasn't been all that easy,
but I've had issues with basically every part of my setup except for pagekite. This far have been
talking about the pagekite service. Now I'll describe how the program that provides the service
operates. You run an instance of pagekite on a local computer called the back end, and an
instance on a remote computer called the front end. Front and back in this case are relative to
your local network. Think of the front end as your front door, or perhaps a lobby, and the back end
is where the real work happens, but customers aren't allowed. Well enough metaphors. In the simple
case the front end is running at pagekite.net, and the back end is running on the same computer as
your web server. The other players in this setup are the clients in your server. The clients are
usually web browsers. The server is often a web server like Apache or IngenX. So the back end
opens an SSL connection to the front end and waits. The server meanwhile is listening for
connections as servers tend to do. When a client connects to the front end, it determines which
back end the client wants to talk to based on domain, and relays the connection down the SSL
connection. When the back end gets the connection, it relays it to the server, which is basically
unaware of the path the data takes to reach it. From this point on, messages are related between
the client and server along this route. Now remember I said I was describing the simple case.
The front end can run on any system reachable from the clients, and that can reach the back end,
and the back end doesn't have to run on the same computer as the server. It can relay connections
to the server across the network. So it also only needs to run somewhere that it can reach the server.
I'm not going to get into it in any detail, but the protocol the pagekite front-ended back end
used to communicate is also defined on the pagekite site. That's all I have for now. If you want
to learn more about pagekite, the first place to look is the pagekite.net site. It has tons of
helpful documentation. Also Björnj hangs out on pound pagekite on free node, and he's extremely
nice and helpful. Even if your question is more about DNS or Apache configuration like most of
mine were. If you want to contact me, my status net instance is Kevin Grenade at status.linuxrangling.com,
and my email is Kevin.Grenade at gmail.com. This is Kevin Grenade signing off and hoping to hear from you.
You have been listening to Hacker Public Radio at Hacker Public Radio does our. We are a community
podcast network that releases shows every weekday Monday through Friday. Today's show, like all our
shows, was contributed by an HBR listener by yourself. If you ever consider recording a podcast,
then visit our website to find out how easy it really is. Hacker Public Radio was founded by
the Digital Dark Pound and the International Computer Club. HBR is funded by the binary revolution
at binref.com. All binref projects are crowd-sponsored by linear pages. From shared hosting to custom
private clouds, go to lunarpages.com for all your hosting needs. Unless otherwise stasis,
today's show is released on the creative commons, attribution, share a line, read those