I guess we were causing the kernel to syslog on every single packet on
MacOS.  Oops.

If the subprocess was trying to write to its stdout/stderr, its process
would never actually finish because it was blocked waiting for us to read
it, but we were blocked on waitpid().  Instead, use waitpid(WNOHANG) and
continually read from the subprocess (which should be a blocking operation)
until it exits.

Not sure if this will fix anything, but it might stop the problem reported
on some MacOS versions where the firewall doesn't get cleaned up correctly.

(apenwarr: also updates to the matching, latest minimal/do)

This makes it easier (possible?) to generate sshuttle.8 from sshuttle.md on
MacOS.  We also import the git-enhanced version numbering magic so the
generated manpage can have a real version number.

Now that we imported the feature from redo, might as well use it.

On top of the bug that already existed in 10.6, Lion also makes the sysctl
needed to fix the problem into a read-only variable, so we have to actually
change it at kernel boot time and force people to reboot.  Nice job, Apple.

And make sshuttle exit with a well-defined exit code (111) if it needs to
reboot.

If the expected arch directory doesn't exist, give up and don't specify arch at
all. Currently it expands to '*' which fails.

[slightly modified by apenwarr]

Add some documentation about the int() vs long() and the reason behind
_shl().  Instead of "from __future__ import generators", just don't use
generators.

There were still a few conditions under some OSes that would cause
firewall.py to terminate without cleaning up the firewall settings.  'pkill
sshuttle' was one of them.  Ignore a couple more signals to further ensure a
correct cleanup.

(This only affects sshuttle --firewall, which is a subprocess of the main
sshuttle process.  The firewall is supposed to exit automatically whenever
the client exits, and so far that part seems to work reliably.)

(Slightly modified by apenwarr)

I've been meaning to add this patch for a long time, but it's especially
important once we add FQDN support to --auto-hosts.  Basically, auto-hosts
will still discover all the hostnames it can, but we'll only add them to
/etc/hosts if their IP address is in one of the routed subnet ranges.  That
prevents polluting the /etc/hosts file with cruft.

(slightly modified by apenwarr)

* fqdn:
  hostwatch: handle fully qualified domain names
  auto-hosts: don't add hosts that aren't being routed by sshuttle.

This adds a dns_hosts command-line option, which is passed internally to
the firewall, containing a comma-separated list of nameservers to target
when creating firewall rules.

The --dns switch adds firewall rules to intercept queries only for
nameservers found in resolv.conf ; This command-line option allows
the user to explicitly specify the nameservers to create firewall
redirection rules for.

This is useful when using a local DNS forwarder to redirect DNS queries
to different nameservers.

Example:

  We can use sshuttle to access a private subnet 172.30.0.0/16, which hosts
  a local DNS server resolving private domain names in that subnet.

  Currently, the only way to be able to resolve those domain names is to use
  the --dns switch. However, all DNS queries will then go through the remote
  nameserver, which might not be desirable especially if said nameserver
  does not know how to resolve every query.

  One solution is to run a local DNS forwarder, which knows that the private
  domain names can be resolved through a private IP, say 172.30.128.40.

  Now, we can run :

    sshuttle -r ssh.remoteserver.com -i 172.30.0.0/16 --dns-hosts 172.30.128.40

  DNS queries for private domain names will get forwarded to 172.30.128.40,
  intercepted by the firewall rule and sent through the tunnel to the nameserver
  used by the remote endpoint (which might or might not be 172.30.128.40 !).

Notes :

    * There is nothing preventing --dns-hosts from being used together with
	  --dns, in which case the nameservers found in resolv.conf will also be
	  added to the firewall rules as usual. This defeats the purpose of the
	  example, however.
	  There might be some weird use-case where this is useful ?

    * Since there is no control over which nameserver the query gets sent to
	  after it has crossed the tunnel, the IPs specified in --dns-hosts are
	  irrelevant (as long as they are the same as found in the DNS forwarder
	  configuration). This might be a little counter-intuitive.