Re: [Server-devel] Collaboration server for existing network

2010-03-14 Thread Jerry Vonau
On Mon, 2010-03-15 at 14:49 +1100, Sridhar Dhanapalan wrote:
> Hi Martin,
> 
> Thank you very much for that explanation. It certainly helps to keep
> everything in perspective.
> 
> What I think we really need is a turn-key ejabberd solution that
> integrates with existing network services. If you or anyone else can
> assist we'd be immensely grateful. I'll explain...
> 
> There appears to be some a difference in the design assumptions for
> the XS versus what we see in Australian schools. The XS works great
> where no other network exists, or where it is acceptable to establish
> a separate subnet and wireless infrastructure. Schools in remote
> Australia are attended by children who literally live in third-world
> conditions (making them good candidates for XOs), but the schools
> themselves are generally well-funded and have great network
> connectivity. Buildings are networked together, wireless points are
> mounted around the place, and so on. If we can harness this existing
> infrastructure, we can make our jobs easier and more cost-effective.
> It will also give us considerably greater buy-in from stakeholders.
> 
> We are also constrained by the remoteness of these schools. Take a
> look at a map of Australia and you'll see why. Settlements are very
> far apart and it is a very expensive exercise sending a team out to
> one. The deployment needs to work the first time, as it is difficult
> to return to the location.
> 
> The 'Easy' method you outline (i.e. what the XS is designed to do) is
> what we have been doing so far. I like how the XS automagically
> handles much of the complexity for this. However, because it is
> self-contained we need to also deploy our own wireless points and so
> on. The 'Hard' method is too difficult to expect a volunteer to
> perform, and there are too many things that could go wrong either
> during setup or afterwards.
> 

Yea, that is true, we would need to identify all the config file that
have hard-coded network information, such as httpd-xs.conf. 

> Long-term, I'd like to see us using the XS as our primary platform. At
> the moment, however, it doesn't integrate into existing networks and
> therefore can unfortunately be perceived as a burden.
> 

All the custom xs-server config files are contained in the xs-config rpm
package. Most services are setup binding only to the internal interface
as to minimize external exposure of services.   The all config .in files
are listed in the .spec file:
http://dev.laptop.org/git/projects/xs-config/tree/xs-config.spec.in  

You'd have to check/edit all the config files for the services that you
wish to offer on the XS and disabling the un-wanted services.

> Shorter-term, we have identified that the key feature we need is the
> collaboration. Schools would be very happy if they just had that. It
> seems like a way forwards is to have a more 'standard' Linux server
> (running something like CentOS or Fedora). It would run ejabberd to
> manage the collaboration. There should only be a need for one network
> interface, eth0, which would get its DHCP, DNS and other network
> services from the LAN. The XOs can connect to existing wireless
> points.
> 

That is not too hard to do, disable all the *bond*, msh*, wmesh*, eth1
interface files in /etc/sysconfig/network-scripts/ and edit 
/etc/dhclient-exit-hooks, disabling the resolve.conf re-write.
then setup eth0. Having the local changes respected upon updating, is
something that would need to be tested.
 
The biggest issue, I think would be to have the dns/dhcp setup right for
the schoolserver, once that is in place, things should go ok.
 

> A key design goal is that this needs to be easy to set up and
> maintain, so that a volunteer can do it in the field. So far I've
> found ejabberd to be extraordinary fiddly to set up, which has given
> me an appreciation for the good work done on making the XS easy to
> deploy.
> 
> I'm sure that a solution to this problem would be of great use in many
> locations worldwide. I don't believe that our use case is particularly
> unique.
> 
> I'd love to hear the list's opinion on this. Even better, we'd love to
> hear from anyone who can help us out.
> 
Think we can do up a howto, I just need to do a fresh install on a test
box, and see what I have to edit on a bone stock install. 

Jerry

___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] GNOME hesitance build 112

2010-03-14 Thread John Watlington

What is your power management setting ?
Unfortunately, I don't believe you can see this from GNOME, and
I don't know the new powerd file triggers used in os112.

Please trac this, I believe you are seeing the laptop suspend, then
resume.

Cheers,
wad

On Mar 14, 2010, at 2:27 PM, Sameer Verma wrote:

> Apps in GNOME on build 112 (most noticeable in FF) hesitate every 30
> seconds or so. Its as if the keyboard/mouse pipeline backs up, clears
> in about 3 seconds or so, and then works for the next 30 seconds.
>
> I can keep typing, but the screen won't echo the characters for that
> three second window, and then it all comes in quickly. Anybody else
> see this?
>
> I'm on build 112 X 1.5 B2. Haven't noticed this on the Sugar side.
>
> Sameer
> ___
> Server-devel mailing list
> Server-devel@lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel

___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] Collaboration server for existing network

2010-03-14 Thread John Watlington

On Mar 15, 2010, at 12:06 AM, James Cameron wrote:

> I don't know XS very well, but if ejabberd is all you need why not  
> take
> the ejabberd configuration from XS sources and deploy that on an
> otherwise vanilla instance?

And indeed, the XS services are intended for such reuse.   I'm not sure
how many patches to the stock ejabberd are still needed...

The main hook needed in the existing infrastructure is a DNS entry
for the machine running the school server services.   Those services
can either be easily grafted on top of a Fedora server using the school
server packages, or supported on another Linux distro with some hand
tweaking.

wad
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] Collaboration server for existing network

2010-03-14 Thread James Cameron
I don't know XS very well, but if ejabberd is all you need why not take
the ejabberd configuration from XS sources and deploy that on an
otherwise vanilla instance?

(I second your comment about technology in Australian schools ... plenty
of equipment, usually centrally managed, and often a teaching staff who
haven't enough time to use it ... except via telephone to the technology
shamans at head office).

-- 
James Cameron
http://quozl.linux.org.au/
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: [Server-devel] Collaboration server for existing network

2010-03-14 Thread Sridhar Dhanapalan
Hi Martin,

Thank you very much for that explanation. It certainly helps to keep
everything in perspective.

What I think we really need is a turn-key ejabberd solution that
integrates with existing network services. If you or anyone else can
assist we'd be immensely grateful. I'll explain...

There appears to be some a difference in the design assumptions for
the XS versus what we see in Australian schools. The XS works great
where no other network exists, or where it is acceptable to establish
a separate subnet and wireless infrastructure. Schools in remote
Australia are attended by children who literally live in third-world
conditions (making them good candidates for XOs), but the schools
themselves are generally well-funded and have great network
connectivity. Buildings are networked together, wireless points are
mounted around the place, and so on. If we can harness this existing
infrastructure, we can make our jobs easier and more cost-effective.
It will also give us considerably greater buy-in from stakeholders.

We are also constrained by the remoteness of these schools. Take a
look at a map of Australia and you'll see why. Settlements are very
far apart and it is a very expensive exercise sending a team out to
one. The deployment needs to work the first time, as it is difficult
to return to the location.

The 'Easy' method you outline (i.e. what the XS is designed to do) is
what we have been doing so far. I like how the XS automagically
handles much of the complexity for this. However, because it is
self-contained we need to also deploy our own wireless points and so
on. The 'Hard' method is too difficult to expect a volunteer to
perform, and there are too many things that could go wrong either
during setup or afterwards.

Long-term, I'd like to see us using the XS as our primary platform. At
the moment, however, it doesn't integrate into existing networks and
therefore can unfortunately be perceived as a burden.

Shorter-term, we have identified that the key feature we need is the
collaboration. Schools would be very happy if they just had that. It
seems like a way forwards is to have a more 'standard' Linux server
(running something like CentOS or Fedora). It would run ejabberd to
manage the collaboration. There should only be a need for one network
interface, eth0, which would get its DHCP, DNS and other network
services from the LAN. The XOs can connect to existing wireless
points.

A key design goal is that this needs to be easy to set up and
maintain, so that a volunteer can do it in the field. So far I've
found ejabberd to be extraordinary fiddly to set up, which has given
me an appreciation for the good work done on making the XS easy to
deploy.

I'm sure that a solution to this problem would be of great use in many
locations worldwide. I don't believe that our use case is particularly
unique.

I'd love to hear the list's opinion on this. Even better, we'd love to
hear from anyone who can help us out.

Cheers,
Sridhar


Sridhar Dhanapalan
Technical Co-ordinator
OLPC Australia
p: +61 425 239 701
w: http://laptop.org.au



On 12 March 2010 02:46, Martin Langhoff  wrote:
> Hi Sridhar!
>
> you are right, for some reason, I find various emails from Andrew
> Berkowics but not the discussion about fitting an XS in an existing
> network.
>
> There are two main paths you can follow --one easy, one hard. For the
> hard one, I can give you high level pointers -- you'll have to DIY
> (and hopefully document it in the wiki ;-) ).
>
> =Easy=
>
> Run the XS as intended -- hook up the WAN port to the existing School
> LAN (we'll call it SLAN here) and let the XS run its own LAN ("XLAN"
> ;-) ).
>
> From the PoV of the XS, the SLAN is its WAN.
>
> You will need then to have 2 network infrastructures -- this could be
> awkward at the wiring and AP setup level. But it's guaranteed to be
> easy on the XS configuration side and future upgrades.
>
> =Hard=
>
> You will need to tweak the XS to disable all the "base network
> services" (routing, DNS, DHCP), use only the "LAN" NIC, and disable
> un-needed services. This is rather involved and unsupported: some
> services (notably some aspects of antitheft) won't work and will most
> likely break on upgrade.
>
> Outline of how to do it
>
>  - Install the XS with only one NIC, and use xs-swapnics to make that NIC eth1
>  - Change all the eth1 configuration -- note that it has various IP
> addresses and odd routing tables -- to fit your LAN.
>  - Disable and stop dhcpd and named services.
>  - Use domain_config to set the FQDN
>  - Look at the BIND zone files, and make sure the "local" names
> ("schoolserver", etc) _and_ the FQDN are published by your DNS server.
>  - Set resolv.conf on the XS -- can the XS itself resolve all its
> local aliases, as well as its FQDN?
>  - Check that any conffiles in /etc referring to the hardcoded eth1 IP
> address are changed to use the IP address you use on your LAN for the
> XS.
>  - the xinetd "xs-activation" service won't work -

[Server-devel] GNOME hesitance build 112

2010-03-14 Thread Sameer Verma
Apps in GNOME on build 112 (most noticeable in FF) hesitate every 30
seconds or so. Its as if the keyboard/mouse pipeline backs up, clears
in about 3 seconds or so, and then works for the next 30 seconds.

I can keep typing, but the screen won't echo the characters for that
three second window, and then it all comes in quickly. Anybody else
see this?

I'm on build 112 X 1.5 B2. Haven't noticed this on the Sugar side.

Sameer
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel