network connections

[Sean Middleditch]

On Thu, 2003-10-02 at 10:33, Rodney Dawes wrote:
> It sounds like you are more proposing a "locations" system, than
> anything else. I am very much in favor of getting that done, and
> there are many pieces of software in place, which when combined
> together can create something similar, but still requires some
> extensive knowledge of what you are doing with all of the pieces.

Well, here's the pieces as I see it:

1) locations/profiles configuration (basic config files in
/etc/net-profile/ or something)
2) library/shell-interface for controlling and querying backends, such
as a CIPE backend, a PPP over SSH backend, dialup backend, ethernet
backend, a 'connect' backend (lets a network of users share control of a
dialup line), and so on.
3) library/daemon for handling network request, needs to resolve needed
profile from the config files, and be able to tell a variable GUI
frontend to display connection status, let user select from a list of
matching profiles, or even deny the application request.
4) one or more GUI apps for the control, which should also, if possible,
offer configuration interface to the user, and allow the user to
manually bring up or bring down profiles.

The profiles configuration needs some standard information, and can also
provide extra information the backends might use (for example, SSN for
wireless roaming or DHCP MAC address for ethernet roaming, or whatever):

 id: system id for the profile, probably the name of the profile's file
in /etc/net-profile.d as well
 name: user visible name, such as "Central Office VPN" or "Home Dial-Up"
 backend: the backend system to use, such as ppp, ssh-vpn, wireless,
cipe, etc.
 network: a network the profile grantes access to, such as
10.2.0.0/255.255.0.0 or 192.168.7.0/24 or 0.0.0.0/0.  there can be
multiple network's configured for each interface.
 network6: ipv6 version of the above
 domain: a domain the network provides access to, like freedesktop.org. 
multiple items can exist.  similar to how the network/network6 options
work, but at the name level vs. ip level.
 interface: network interface to be used (eth1, ppp0, etc.)
 auth: information describing authentication; actual passwords should
probably be stored in a root-readable-only file.
 x-macaddr: custom information for the backend
 x-blah: same

 We'd also need to add the access control stuff mentioned in my original
mail (can the interface be silently brought up on request, or must user
approval be given first?  which apps/services are banned from requesting
the service, or which are allowed to always bring it up?)

The backends can be done in a couple ways.  The "cool, modern" way would
be to use D-BUS.  The classic way would be to provide a set of shell
scripts.  Having more working experience with the later, I'll use that
as an example.

 The ssh-vpn (ppp over ssh) backend might be found in
/usr/share/net-backend/ssh-vpn/.  There, we might find these files:

 * ./description - meta-information for the user and/or config
interface.  Fields like:
  id: probably same as the directory its in
  name: user visible name, like "VPN over SSH"
 
  and perhaps fields description the extra config options usable, to
help auto-build a config interface (personally, I'd prefer well-designed
hand-crafted config interfaces)

 * ./query-status - an executable (likely a shell script) that queries
the status of the backend.  The script would take a profile name as
argument, so the backend can determine which interface to check, what
options the user selected, etc.

   script would return 0 (success) always, unless a problem occured
preventing it from checking the status at all.  information would be
printed to stdout, in a format <CODE>: <MSG>, where <CODE> is something
machine readable (CONNECTING, ACTIVE, INACTIVE, UNAVAILABLE, etc.) and
<MSG> is something human-readable ("Finding remote host...", "Connection
established.", "Service not available.", etc.).  (on second thought,
perhaps numeric return codes would be better than <CODE> - this is a
thought process and not a specification proposal, so forgive me ;-)

   in the case of ssh-vpn, it would see if its active (pid lockfile? 
ppp interface active?), and display what it finds.  ssh-vpn needs a net
connection to the remove host, so it might indicate the service isn't
available (UNAVAILABLE code) if not route to the host is found.

 * ./activate - executable (likely script) that activates the
connection.  returns 0 on success, 1 if the connection is already
active, or 2 if its unavailable.  User-oriented messages should be
printed to stdout.  ./active also takes the profile name as an argument.

   ssh-vpn would check if the connection is active (perhaps calling
./query-status), and echo "Connection already established." and return 1
if it is.

   ssh-vpn would then echo "Launching VPN connection..." and launch the
ssh daemon and pppd service over it (i don't have the exact code on
hands, it's not overly complicated tho); if the connection is
established, it would print "Connection established." and return 0;
otherwise, it would print out something like "Authentication failed" or
"Remote host not found." and return 2.

 * ./deactivate - do the opposite of ./activate, probably doesn't need
much explanation.

Now, a D-BUS version would probably be much better.  Status updates (ssh
or ppp died?) would be real-time, the backends could make use of a
protocol for requesting user input (perhaps the backend needs a
user-supplied password, since one wasn't provided in the profile
configuration?).  I'm not familiar enough with D-BUS yet tho to provide
a good proposal on an interface for that.

Despite that lack of knowledge, I'm fairly sure the netprofiled
daemon/service should run over D-BUS.  Likewise, the libnetprofile
library should make use of D-BUS.  Again, the use case is something like
this:

 Shirley has a home network of three computers.  Her machine, user01,
has not Internet connection of its own, but uses user03 as a gateway. 
user03's 'net connection is a dialup line that is usually down.  the
'connect' framework has been installed on user03 to let other machines
on the network request Internet access.

 Shirley is oblivious to all this complexity.  She turns on her
computer, and opens up Epiphany (or Mozilla, or GAIM, or any such app). 
Epiphany's homepage is http://www.freedesktop.org (probably not, but its
a neutral enough example ;-)  Epiphany tries to connect, but finds that
the network freedesktop.org is on cannot be found (actually, on second
thought, it would likely be a DNS error - I need to look into what kinds
of errors that would report, and if apps can determine the error means
no 'net connection is available).  So Epiphany uses libnetprofile to
request access to the host 'www.freedesktop.org', as that's where
freedesktop.org is determined to be.

 netprofiled, getting the request, looks at the profiles available.  the
only profile available is user03-dialup, called 'User03 Shared Dialup',
using the 'connect' backend.  user03-dialup provides access to all
undefined domains/networks (none defined), so netprofiled invokes
"/usr/share/net-profile/connect/query-status user03-dialup", and gets an
"INACTIVE" status.  The profile is configured to allow automatic
connections, so netprofiled then invokes
"/usr/share/net-profile/connect/active user03-dialup".  The connection
succeeds, and netprofiled then tells Epiphany the connection is
available, and tells Shirly's desktop's netprofiled monitor (perhaps a
KDE or GNOME notification area icon based app) that the connection is
open.

 I should also note that in many cases, user interaction will be
required.  For example, if the user has several profiles available that
can provide a service (like multiple 'net connections), the user must
select one.  The backends need to be able to cut down this list as much
as possible tho, pruning out profiles that aren't currently usable.  In
that case, netprofiled would tell the user's GUI frontend that profiles
'foo' and 'bar' are available matching profiles for the requested
operation ('Epiphany'), and 'baz' is an unavailable matching profile
(the later may be useful; say the user normally uses the 'baz' profile,
but as they forgot to plug in their net cable, its not available - if
its not shown at all, the user may freak out, while if its shown as
unavailable with the user message "No cable detected" given by the
query-status script, the user can easily discover and correct the
problem.)

 The real thing is, does the above system sound capable of handling all
(or at least most) needs?  I don't want to implement something, get to
where it seems done, and then find out it doesn't work for 30% of
people.  ~,^
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.