<br><br><div class="gmail_quote">On Wed, Jul 3, 2013 at 2:40 PM, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div><br></div><div>* The XSCE is supposed to stay on for major times of day, if not 24x7.</div><div>* Internet connectivity to the XSCE is going to be flakey.</div><div>* 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).</div>

<div><br></div><div>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).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A relay using socat could be run on the XSCE for this purpose, and so<br>
a user of the OpenVPN service could reach an XO (or another XSCE) to<br>
analyse or fix non-booting scenarios.<br>
<br>
I know you already have the capability to deploy puppet for XO remote<br>
administration ... if the Linux kernel is running.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
James Cameron<br>
<a href="http://quozl.linux.org.au/" target="_blank">http://quozl.linux.org.au/</a></div></div></blockquote><div><br></div><div>--</div><div>Anish </div></div><br>