[Server-devel] [support-gang] Value of remote access to School Servers.

[James Cameron]

On Wed, Jul 03, 2013 at 02:52:17PM +0530, Anish Mangal wrote:
> 
> 
> On Wed, Jul 3, 2013 at 2:40 PM, James Cameron <quozl at laptop.org> wrote:
> 
>     On Wed, Jul 03, 2013 at 02:06:04PM +0530, Anish Mangal wrote:
>     >
>     >
>     > On Wed, Jul 3, 2013 at 1:54 PM, James Cameron <quozl at laptop.org> wrote:
>     >
>     >     On Wed, Jul 03, 2013 at 12:45:35PM +0530, Anish Mangal wrote:
>     >     > James wrote:
>     >     > > Would the person accessing their XSCE remotely then establish
>     >     > > another tunnel to your OpenVPN server, or would your server do
>     >     > > inbound connection forwarding?
>     >     >
>     >     > Hmm. I'm not so clear on that. I can give the example of a setup in
>     >     > Bhagmalpur (a pilot we recently did).
>     >     >
>     >     > 1. There is an openVPN server hosted by Sameer.
>     >     > 2. The XSCE when connected to the internet dials into this open vpn
>     >     >    server.
>     >
>     >     Thanks, I understand the first two steps, and they sound good.
>     >
>     >     > 3. I can login to the XSCE through the openVPN connection through
>     >     >    ssh and administer remotely.
>     >
>     >     How is this last step achieved?  There's much flexibility, so I'm
>     >     curious.  I imagine one of three methods:
>     >
>     >     a.  does the user first SSH into an account on the OpenVPN server and
>     >     then SSH again to the XSCE, or;
>     >
>     >     b.  does the user SSH to a particular port on the OpenVPN server that
>     >     is automatically forwarded to the XSCE, or;
>     >
>     >     c.  does the XSCE have a routable IP address, courtesy of the OpenVPN
>     >     server, to which SSH is directed?
>     >
>     >
>     >
>     > I'm not sure... let me explain (perhaps Sameer or Santi can chime in)...
>     >
>     > I have a set of openVPN keys on may laptop through which I connect to the
>     > openVPN server automatically (and a network called tun0 is created)
>     >
>     > I know the IP address of the XSCE in Bpur
>     >
>     > So, from my laptop, I just do ssh root@<ip address of XSCE on the openVPN
>     > network>
>     >
>     > Does it make things any clearer?
> 
>     Yes, this would be a case "d", where both the client (your laptop) and
>     the server (the XSCE) have an unroutable address on a network that is
>     unreachable except through OpenVPN.
> 
>     By unroutable I mean one that cannot be reached from the public
>     network.
> 
>     This is a good choice, because:
> 
>     - it allows the server hosting the OpenVPN to avoid dealing with
>       traffic unrelated to the task of remote access,
> 
>     - it allows the administrator of the OpenVPN server to set up packet
>       filtering rules to permit specific individuals to access specific
>       XSCEs,
> 
>     - it prevents access to either party from the public network.
> 
> 
> 
> So, I guess this is a good setup to run with.
>  
> 
>     Now that you have remote XSCE settled, have you considered remote XO
>     access for hardware diagnosis and maintenance?  Write up of that
>     feature is here:
> 
>     http://wiki.laptop.org/go/Firmware/Remote
> 
> 
> 
> Hmm, Haven't really put a lot of thought to it so welcome to inputs :-)
> 
> You gave one example use case. Perhaps if you could explain if this
> would be required in everyday usage or emergency scenarios.

No, I couldn't possibly.  I'm not in a deployment and have not visited
one even yet.  I only speak from experience of hardware, software,
and firmware.  Someone else would have to do the evaluation you are
asking for, because it depends on the skills and expertise available
at the deployment, and the skills and expertise available remotely.

> The reason I'm asking is because we're designing an architecture
> where:
> 
> * The XSCE is supposed to stay on for major times of day, if not 24x7.
> * Internet connectivity to the XSCE is going to be flakey.
> * If a remote XO is to be 'repaired', there has to be communication
> to make sure that the specific XO is turned on, the XSCE is
> connected to the internet, and an administrator has access to it
> through openVPN. It seems like many elements have to be in place for
> this to happen reliably. (would be happy to be proved wrong though).

You already face this issue with remote access to an XSCE.  Obviously
if you cannot access the XSCE you cannot provide remote support via
internet, and so the question is moot.

> Do you think there could be alternate approaches. For example, in
> Dextrose builds, we have an automatic yum-based updater. There is a
> local repo on the XSCE, which the clients regularly check for
> package updates, and install automatically. This works quite
> reliably in environments with flakey internet.  One just has to copy
> the new package on the xsce, and everything else from then on is
> local (and pretty reliable).

Entirely unrelated.  With the yum-based updater mechanism you are
presuming that the faulty XO can run Linux.  I'm talking about remote
support when the XO can't even run Linux.

I expect in most cases the XO would be either reflashed, or returned
for hardware service by a repair centre or volunteer.  Reflashing may
lose data.  Returning may reduce the number of XO available to the
deployment.

>     A relay using socat could be run on the XSCE for this purpose, and so
>     a user of the OpenVPN service could reach an XO (or another XSCE) to
>     analyse or fix non-booting scenarios.
> 
>     I know you already have the capability to deploy puppet for XO remote
>     administration ... if the Linux kernel is running.
> 
>     --
>     James Cameron
>     http://quozl.linux.org.au/
> 
> 
> --
> Anish 
> 

-- 
James Cameron
http://quozl.linux.org.au/