[Server-devel] Nepal Server Open Issues

Tue Feb 12 12:23:10 EST 2008

Have you considered using client certs to achieve single signon?  Since
apache has the "make it look like basic auth occurred" setting, it would be
at least possible that this might do what you want.  Of course it would
require code on the xo, presumably added to the school server registration,
to install a client cert in the browse activity.

On Feb 12, 2008 9:07 AM, Greg Smith (gregmsmi) <gregmsmi at cisco.com> wrote:

> Hi Sulochan et al,
>
> Thanks for the details and closing off a bunch of issues. I think we are
> converging on a short term design. Time permitting, I'll create a new
> wiki page this week showing the April design. The existing page can
> track the "Phase 2" design. Nice and simple for Phase 1 with XS doing
> network access, basic web serving, caching and maybe filtering sounds
> wise.
>
> Here's what I see for phase 1:
> - XS build 150 (unless Wad or someone else comes up with a must have
> reason and stable build in time)
> - No SSO (also means no Moodle tracking by student, grade or group)
> - 2 x XS servers
> - No automated XO backup on XS
>
> Let me know if you agree and we can revisit all in phase 2 with a newer
> XS build.
>
> Still open questions on phase 1:
> 1 - Network design.
> I think we need this based on Wads comment it's the only one supported
> for >150 Xos:
> (ISP)-------------(hub)---------eth0 [XS] eth1 ------------  (WiFi)----[
> XO ]
>
> The only downside is when XS is down you're off the Internet and Library
> server. A second Wifi AP between the hub and eth0 helps but requires
> manual intervention (e.g. change WEP to open on XS failure). It also
> leaves the Internet open (aka no filtering) on XS failure. The 2 x XS
> design may help but needs more definition.
>
> Will you have 2 x DSL lines, one for each XS? Should we consider the
> second AP on each XS or start with the design above? Does your DSL line
> ever go down and is that a major concern?
>
> 2 - 2 x XS design.
> We need to define the "backup" scripts which allow one to backup the
> other. Also need to spell out the domain name and web site design.
> Lastly, need to define how Xos "attach" to an XS and if we can/should
> segment the mesh. Some high level options for 2 x XS boxes are:
> - active/standby. Mirrored and may require manual intervention to bring
> up standby on active failure.
> - active/active mirrored and load balanced by DNS, client (XO) config or
> other
> - active/active one for Grade 6 one for Grade 2 with each serving the
> other grade on failure. Needs client config or other method to load
> balance with Xos sticky to the right XS for their grade.
>
> I think Tony has been commenting on the last option but we need another
> level of detail for that to make phase 1.
>
> 3 - On Squid. I think you want a full Moodle, library and activities
> store on the XS.  That keeps your XS useful even if DSL line is down. In
> this case, Squid is mostly for transparent proxy (TP = close to the
> user, caches everything and saves WAN BW)). Also some reverse proxy (RP
> = close to the server, caches server content only, offloads server CPU
> and HD). I think you can add some commands to the squid.conf to do the
> RP and persist the Library server content. That way, even if the kids
> surf the Internet and cache a whole bunch of stuff the Library and
> Moodle is always local on the XS.
>
> Maybe squid experts know the command to persist (aka flush last) a
> domain name? Also, can a squid expert confirm how to ensure cached
> content gets served even if the origin domain is unreachable?
>
> If you have a second box in the school you could run Squid on one and XS
> on the other. That keeps content local and does TP and RP. Only down
> side is it needs more HW (more points of failure), network and
> management. I would start with Squid on same box as XS for simplicity.
>
> FYI on some good links:
> I noticed a bunch of new activities on Nepal page.
> http://www.olenepal.org/activities_download.html
>
> Cross posting this from the developer list:
> For the archives and those interested, the scripts Uruguay used for
> their deployment are in git at:
>   http://dev.laptop.org/git?p=projects/ceibal-scripts;a=tree
>
> I hope to actually get a complete build image at some point.  (Thanks
> for cjb for pointing these out to me.)
>  --scott http://cscott.net/ )
> *******
>
> Let me know if you want a translation. We probably need a point person
> to write Nepal install scripts too. That will force us to define some XS
> details (e.g. domain names, XO home pages, directory structures for
> activity store, etc.).
>
> On Wiki updates, thanks for the edits/additions and keep them coming.
> I'll try to spend an hour cleaning and editing on Friday. I also owe
> more edits/comments on redundancy design.
>
> Thanks,
>
> Greg S
>
> PS sorry for the long post again! Let me know if the list see this as
> SPAM and wants me to toggle it back.
>
> _______________________________
> From: sulochan acharya [mailto:sulochan at gmail.com]
> Sent: Tuesday, February 12, 2008 1:46 AM
> To: Greg Smith (gregmsmi)
> Cc: server-devel at lists.laptop.org
> Subject: Re: [Server-devel] Nepal Server Open Issues
>
>
>
>        Nepal team - here are a few questions, suggestions and decisions
> needed:
>        1 - Need to decide ASAP if we will deploy the new XS image or
> the
>        current one. Also, please confirm if we have two XS boxes in the
> school
>        or one.
>
> >>Yeah i think we are going to use two XS boxes in each school, for
> redundancy purpose as proposed by Tony and others.
>
>
>
>
>        2 - I suggest that people try upgrading their XS to the latest
> image and
>        take notes on how its done. Even if we deploy OLPC_XS_150.iso it
> helps
>        to have docs on to re-image. We want to know what Nepal or user
> specific
>        content can be preserved. We may also want to upgrade modules
> one at a
>        time. Does anyone know of docs or best practices on upgrading
> whole
>        boxes or by components for LAMP servers?
>
> >>The latest stable built is 150, and yeah we can update modules through
> yum.
>
>
>
>
>        3 - Need closure on SSO. Pending Martin's comments on the
> applicability
>        of the existing paradigm, you should pick a solution. Sounds
> like John W
>        suggests no user tracking or possibly one of the work arounds.
>        See item 3 at this link for proposed workarounds:
>        If it's a workaround we better clarify which right away.
>
> >>I dont see SSO working anytime soon. It would be great to have it,
> because it would solve quite a few auth problems. If Ivan can make it
> work great, but we should not depend on it at least fot the test phase.
>
>
>
>
>        4 - Based on SSO decision you need to confirm what kind of
> Moodle
>        interface and services will be in phase 1. My main question is
> if we
>        will use Moodle to access activities.
>
> >>Needs testing. Will update later.
>
>
>
>
>        5 - On the school network. Can you confirm if we can get 2 x
> router +
>        wireless Access points per XS? We need to flush out the failure
> cases
>        and the available HW will have a big effect on that. Let us know
> what HW
>        is in place. If ts just a matter of buying a few Linksys
> routers, I
>        think we can find a way to do that.
>
> >> The network structure might be a little different. Please take a look
> at the attached file and let me know what you guys think.
>
>
>
>
>
>
> >>Moodle does not handle IP based authentication.
>
> >>I am attaching a file that shows cache and xs structure for the pilot.
> I think its a good idea to run proxy and content on different machines.
> On a long run it becomes more efficient to do it like that. It also
> reduces content handling and traffic processing on the XS. What do you
> guys think?
>
> _______________________________________________
> Server-devel mailing list
> Server-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel
>

-- 
"Always do right," said Mark Twain. "This will gratify some people and
astonish the rest."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/server-devel/attachments/20080212/e92a6d87/attachment.htm 