[Server-devel] Collaboration server for existing network

Jerry Vonau jvonau at shaw.ca
Mon Mar 15 01:38:47 EDT 2010


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



More information about the Server-devel mailing list