<commit_before>## Name ##

pagekite - Make localhost servers publicly visible.

## Synopsis ##

<b>pagekite</b> [`--options`] [`service`] `kite-name` [`+flags`]

## Description ##

PageKite is a system for exposing `localhost` servers to the
public Internet.  It is most commonly used to make local web servers or
SSH servers publicly visible, although almost any TCP-based protocol can
work if the client knows how to use an HTTP proxy.

PageKite uses a combination of tunnels and reverse proxies to compensate
for the fact that `localhost` usually does not have a public IP
address and is often subject to adverse network conditions, including
aggressive firewalls and multiple layers of NAT.

This program implements both ends of the tunnel: the local "back-end"
and the remote "front-end" reverse-proxy relay.  For convenience,
<b>pagekite</b> also includes a basic HTTP server for quickly exposing
files and directories to the World Wide Web for casual sharing and
collaboration.

## Basic examples ##

<pre>Basic usage, gives `http://localhost:80/` a public name:
$ pagekite NAME.pagekite.me

To expose specific folders, files or use alternate local ports:
$ pagekite /a/path/ NAME.pagekite.me +indexes  # built-in HTTPD
$ pagekite *.html   NAME.pagekite.me           # built-in HTTPD
$ pagekite 3000     NAME.pagekite.me           # HTTPD on 3000

To expose multiple local servers (SSH and HTTP):
$ pagekite ssh://NAME.pagekite.me AND 3000 NAME.pagekite.me</pre>

## Services and kites ##

The most comman usage of <b>pagekite</b> is as a back-end, where it
is used to expose local services to the outside world.

Examples of services are: a local HTTP server, a local SSH server,
a folder or a file.

As illustrated above, one simply tells the program which local services
to expose to the world and which names to use.  If a kite name is
requested which does not already exist in the configuration file and
program is run interactively, the user will be prompted and given the
option of signing up and/or creating a new kite using the <b>pagekite.net</b>
service.

Multiple services and kites can be specified on a single command-line,
separated by the word 'AND' (note capital letters are required).
This may cause problems if you have many files and folders by that
name, but that should be relatively rare. :-)

The options <b>--list</b>, <b>--add</b>, <b>--disable</b> and <b>--remove</b> can be used to
manipulate the kites in your configuration, if you prefer not to edit
the file by hand.

## Flags ##

Flags are used to tune the behavior of a particular kite, for example
by enabling access controls or specific features of the built-in HTTP
server.

### Common flags ###

   * <b>+ip</b>/`1.2.3.4`  
     Enable connections only from this IP address.
   * <b>+ip</b>/`1.2.3`  
     Enable connections only from this /24 netblock.

### HTTP protocol flags ###

   * <b>+password</b>/`name`=`pass`
     Require a username and password (HTTP Basic Authentication)

   * <b>+rewritehost</b>  
     Rewrite the incoming Host: header.
   * <b>+rewritehost</b>=`N`  
     Replace Host: header value with N.
   * <b>+rawheaders</b>  
     Do not rewrite (or add) any HTTP headers at all.

### Built-in HTTPD flags ###

   * <b>+indexes</b>  
     Enable directory indexes.
   * <b>+indexes</b>=`all`  
     Enable directory indexes including hidden (dot-) files.
   * <b>+hide</b>  
     Obfuscate URLs of shared files.

   * <b>+cgi</b>=`list`
     A list of extensions, for which files should be treated as
     CGI scripts (example: `+cgi=cgi,pl,sh`).

## Options ##

The full power of <b>pagekite</b> lies in the numerous options which
can be specified on the command line or in a configuration file (see below).

Note that many options, especially the service and domain definitions,
are additive and if given multiple options the program will attempt to
obey them all.  Options are processed in order and if they are not
additive then the last option will override all preceding ones.

Although <b>pagekite</b> accepts a great many options, most of the
time the program defaults will Just Work.

### Common options ###

   * <b>--clean</b>  
     Skip loading the default configuration file.
   * <b>--signup</b>  
     Interactively sign up for pagekite.net service.
   * <b>--defaults</b>  
     Set defaults for use with pagekite.net service.
   * <b>--nocrashreport</b>  
     Don't send anonymous crash reports to pagekite.net.

### Back-end options ###

   * <b>--list</b>  
     List all configured kites.
   * <b>--add</b>  
     Add (or enable) the following kites, save config.
   * <b>--remove</b>  
     Remove the following kites, save config.
   * <b>--disable</b>  
     Disable the following kites, save config.
   * <b>--only</b>  
     Disable all but the following kites, save config.

   * <b>--nullui</b>  
     Silent UI for scripting. Assumes Yes on all questions.

   * <b>--local</b>=`ports`  
     Configure for local serving only (no remote front-end).
   * <b>--watch</b>=`N`  
     Display proxied data (higher N = more verbosity).

   * <b>--proxy</b>=`type`:`server`:`port`, <b>--socksify</b>=`server`:`port`, <b>--torify</b>=`server`:`port` <br />
     Connect to the front-ends using a chain of proxies, a single SOCKS
     proxy or the Tor anonymity network.  The type can be any of
     'ssl', 'http' or 'socks5'.

   * <b>--service_on</b>=`proto`:`kitename`:`host`:`port`:`secret` <br />
     Explicit configuration for a service kite.  Generally kites are
     created on the command-line using the service short-hand
     described above, but this syntax is used in the config file.

   * <b>--service_off</b>=`proto`:`kitename`:`host`:`port`:`secret` <br />
     Same as --service, except disabled by default.

   * <b>--service_cfg</b>=`...`, <b>--webpath</b>=`...` <br />
     These options are used in the configuration file to store service
     and flag settings (see above). These are both likely to change in
     the near future, so please just pretend you didn't notice them.

   * <b>--frontend</b>=`host`:`port` <br />
     Connect to the named front-end server. If this option is repeated,
     multiple connections will be made.

   * <b>--frontends</b>=`num`:`dns-name`:`port` <br />
     Choose `num` front-ends from the A records of a DNS domain
     name, using the given port number. Default behavior is to probe
     all addresses and use the fastest one.

   * <b>--fe_certname</b>=`domain` <br />
     Connect using SSL, accepting valid certs for this domain. If
     this option is repeated, any of the named certificates will be
     accepted, but the first will be preferred.

   * <b>--ca_certs</b>=`/path/to/file` <br />
     Path to your trusted root SSL certificates file.

   * <b>--dyndns</b>=`X` <br />
     Register changes with DynDNS provider X.  X can either be simply
     the name of one of the 'built-in' providers, or a URL format
     string for ad-hoc updating.

   * <b>--all</b>  
     Terminate early if any tunnels fail to register.
   * <b>--new</b>  
     Don't attempt to connect to any kites' old front-ends.
   * <b>--fingerpath</b>=`P`  
     Path recipe for the httpfinger back-end proxy.
   * <b>--noprobes</b>  
     Reject all probes for service state.

### Front-end options ###

   * <b>--isfrontend</b>  
     Enable front-end operation.

   * <b>--domain</b>=`proto,proto2,pN`:`domain`:`secret` <br /><commit_msg>Man page updated to latest<commit_after>## Name ##

pagekite - Make localhost servers publicly visible.

## Synopsis ##

<b>pagekite</b> [`--options`] [`service`] `kite-name` [`+flags`]

## Description ##

PageKite is a system for exposing `localhost` servers to the
public Internet.  It is most commonly used to make local web servers or
SSH servers publicly visible, although almost any TCP-based protocol can
work if the client knows how to use an HTTP proxy.

PageKite uses a combination of tunnels and reverse proxies to compensate
for the fact that `localhost` usually does not have a public IP
address and is often subject to adverse network conditions, including
aggressive firewalls and multiple layers of NAT.

This program implements both ends of the tunnel: the local "back-end"
and the remote "front-end" reverse-proxy relay.  For convenience,
<b>pagekite</b> also includes a basic HTTP server for quickly exposing
files and directories to the World Wide Web for casual sharing and
collaboration.

## Basic examples ##

<pre>Basic usage, gives `http://localhost:80/` a public name:
$ pagekite NAME.pagekite.me

To expose specific folders, files or use alternate local ports:
$ pagekite /a/path/ NAME.pagekite.me +indexes  # built-in HTTPD
$ pagekite *.html   NAME.pagekite.me           # built-in HTTPD
$ pagekite 3000     NAME.pagekite.me           # HTTPD on 3000

To expose multiple local servers (SSH and HTTP):
$ pagekite ssh://NAME.pagekite.me AND 3000 NAME.pagekite.me</pre>

## Services and kites ##

The most comman usage of <b>pagekite</b> is as a back-end, where it
is used to expose local services to the outside world.

Examples of services are: a local HTTP server, a local SSH server,
a folder or a file.

As illustrated above, one simply tells the program which local services
to expose to the world and which names to use.  If a kite name is
requested which does not already exist in the configuration file and
program is run interactively, the user will be prompted and given the
option of signing up and/or creating a new kite using the <b>pagekite.net</b>
service.

Multiple services and kites can be specified on a single command-line,
separated by the word 'AND' (note capital letters are required).
This may cause problems if you have many files and folders by that
name, but that should be relatively rare. :-)

The options <b>--list</b>, <b>--add</b>, <b>--disable</b> and <b>--remove</b> can be used to
manipulate the kites in your configuration, if you prefer not to edit
the file by hand.

## Flags ##

Flags are used to tune the behavior of a particular kite, for example
by enabling access controls or specific features of the built-in HTTP
server.

### Common flags ###

   * <b>+ip</b>/`1.2.3.4`  
     Enable connections only from this IP address.
   * <b>+ip</b>/`1.2.3`  
     Enable connections only from this /24 netblock.

### HTTP protocol flags ###

   * <b>+password</b>/`name`=`pass`
     Require a username and password (HTTP Basic Authentication)

   * <b>+rewritehost</b>  
     Rewrite the incoming Host: header.
   * <b>+rewritehost</b>=`N`  
     Replace Host: header value with N.
   * <b>+rawheaders</b>  
     Do not rewrite (or add) any HTTP headers at all.

### Built-in HTTPD flags ###

   * <b>+indexes</b>  
     Enable directory indexes.
   * <b>+indexes</b>=`all`  
     Enable directory indexes including hidden (dot-) files.
   * <b>+hide</b>  
     Obfuscate URLs of shared files.

   * <b>+cgi</b>=`list`
     A list of extensions, for which files should be treated as
     CGI scripts (example: `+cgi=cgi,pl,sh`).

## Options ##

The full power of <b>pagekite</b> lies in the numerous options which
can be specified on the command line or in a configuration file (see below).

Note that many options, especially the service and domain definitions,
are additive and if given multiple options the program will attempt to
obey them all.  Options are processed in order and if they are not
additive then the last option will override all preceding ones.

Although <b>pagekite</b> accepts a great many options, most of the
time the program defaults will Just Work.

### Common options ###

   * <b>--clean</b>  
     Skip loading the default configuration file.
   * <b>--signup</b>  
     Interactively sign up for pagekite.net service.
   * <b>--defaults</b>  
     Set defaults for use with pagekite.net service.
   * <b>--nocrashreport</b>  
     Don't send anonymous crash reports to pagekite.net.

### Back-end options ###

   * <b>--list</b>  
     List all configured kites.
   * <b>--add</b>  
     Add (or enable) the following kites, save config.
   * <b>--remove</b>  
     Remove the following kites, save config.
   * <b>--disable</b>  
     Disable the following kites, save config.
   * <b>--only</b>  
     Disable all but the following kites, save config.

   * <b>--nullui</b>  
     Silent UI for scripting. Assumes Yes on all questions.

   * <b>--local</b>=`ports`  
     Configure for local serving only (no remote front-end).
   * <b>--watch</b>=`N`  
     Display proxied data (higher N = more verbosity).

   * <b>--proxy</b>=`type`:`server`:`port`, <b>--socksify</b>=`server`:`port`, <b>--torify</b>=`server`:`port` <br />
     Connect to the front-ends using a chain of proxies, a single SOCKS
     proxy or the Tor anonymity network.  The type can be any of
     'ssl', 'http' or 'socks5'.

   * <b>--service_on</b>=`proto`:`kitename`:`host`:`port`:`secret` <br />
     Explicit configuration for a service kite.  Generally kites are
     created on the command-line using the service short-hand
     described above, but this syntax is used in the config file.

   * <b>--service_off</b>=`proto`:`kitename`:`host`:`port`:`secret` <br />
     Same as --service, except disabled by default.

   * <b>--service_cfg</b>=`...`, <b>--webpath</b>=`...` <br />
     These options are used in the configuration file to store service
     and flag settings (see above). These are both likely to change in
     the near future, so please just pretend you didn't notice them.

   * <b>--frontend</b>=`host`:`port` <br />
     Connect to the named front-end server. If this option is repeated,
     multiple connections will be made.

   * <b>--frontends</b>=`num`:`dns-name`:`port` <br />
     Choose `num` front-ends from the A records of a DNS domain
     name, using the given port number. Default behavior is to probe
     all addresses and use the fastest one.

   * <b>--nofrontend</b>=`ip`:`port` <br />
     Never connect to the named front-end server. This can be used to
     exclude some front-ends from auto-configuration.

   * <b>--fe_certname</b>=`domain` <br />
     Connect using SSL, accepting valid certs for this domain. If
     this option is repeated, any of the named certificates will be
     accepted, but the first will be preferred.

   * <b>--ca_certs</b>=`/path/to/file` <br />
     Path to your trusted root SSL certificates file.

   * <b>--dyndns</b>=`X` <br />
     Register changes with DynDNS provider X.  X can either be simply
     the name of one of the 'built-in' providers, or a URL format
     string for ad-hoc updating.

   * <b>--all</b>  
     Terminate early if any tunnels fail to register.
   * <b>--new</b>  
     Don't attempt to connect to any kites' old front-ends.
   * <b>--fingerpath</b>=`P`  
     Path recipe for the httpfinger back-end proxy.
   * <b>--noprobes</b>  
     Reject all probes for service state.

### Front-end options ###

   * <b>--isfrontend</b>  
     Enable front-end operation.

   * <b>--domain</b>=`proto,proto2,pN`:`domain`:`secret` <br />
{'fraction_non_alphanumeric': 0.11505719606278265, 'fraction_numerical': 0.0033253524873636604, 'mean_word_length': 3.1711511789181692, 'pattern_counts': {'":': 0, '<': 230, '<?xml version=': 0, '>': 230, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2827858', 'n_tokens_mistral': 4731, 'n_tokens_neox': 4554, 'n_words': 1893}