[Server-devel] DXS demo: highlights

Anish Mangal anish at activitycentral.com
Sat Sep 7 15:49:34 EDT 2013


Hi,

A demonstration of the capabilities of the Dextrose Server server happen
earlier this week. It went on for much longer than anticipated, which I
guess is a good thing. Thus, it's only fair that I follow up with this
email to point out the highlights from the last week meeting.

Agenda of the demo was:

   - Ansible playbooks
   - Ajenti GUI | Wondershaper Bandwidth throttling
   - Github workflow for DXS
   - Transparent Client Authentication How does Moodle magically log
   clients in, and how may it be scaled to other services
   - Munin, ejabberd & collaboration on the public DXS instance.

*Before we go any further, it's paramount to make it clear that DXS is very
much a close downstream of the larger XSCE project. It is our intent to
push upstream, everything we work on in the DXS, and that most of the
conversations regarding development and feedback happen on the primary XSCE
channel itself.
*
*
*

Ansible Playbooks

*Note: The demo happened as a live terminal broadcast session on
http://83.165.130.53:8855/ (that link may not work now, and the information
there is no longer relevant to ansible).*
*
*
As pointed out in previous threads, ansible
<http://www.ansibleworks.com/>is a provisioning system, which is meant
to make it easy to install,
configure, deploy and manage schoolservers which are local or remotely
accessible. Ansible forms the foundation on which DXS is built, and serves
as a backend for carrying out these tasks.

In DXS, the ansible playbooks, often rely on variables and template files.
For an example you can look at:

https://github.com/activitycentral/dxs/blob/master/tasks/network.yml
https://github.com/activitycentral/dxs/blob/master/templates/network/sysconfig.network.j2

It's using ansible_variables. Some of them are automatically defined, and
some can be defined.

Some advantages of ansible over bash/shell are:
* Makes it easy to include more services in less time.
* Makes it easy to integrate with other services (like Frontend-Ajenti)

The tradeoff is learning the ansible yaml, and jinja2 framework, both of
which are easy to pick up on. We'll be working on HowTo's for the same.


Ajenti GUI | Wondershaper Bandwidth throttling

Ajenti <http://ajenti.org/> was chosen (atleast for a start) as the DXS
administrative GUI. There are a few things that make it a favorable choice,
including the fact that it's in python. The broad idea here is to form an
architecture, where Ajenti presents the front-end to the user, while
ansible handles the back-end. This way, new services can be scalably (and
easily) added. As a first example of this,
wondershaper<http://lartc.org/wondershaper/>has been included. It's a
service that allows the control of uplink and
downlink bandwidths on various network interfaces the server uses.

Here's a video demonstrating Ajenti and Wondershaper.
http://www.youtube.com/watch?v=-LbPRVc5Bv4 (apologies for the choppy audio)


GitHub workflow

DXS shifted to GitHub <https://github.com/activitycentral/dxs> a some time
ago. We have been finding that the GitHub workflow offers better code
visibility and makes collaboration easier. The switching cost is very less
technically, but it takes a slight bit of getting used to (what the hell is
a Pull Request?). However, based on the DXS team's experience, I would
definitely recommend that XSCE also seriously consider switching to GitHub.
AC is willing to invest resources to support this switch in whatever way
necessary.

Here's a video demonstrating the GitHub workflow.
http://www.youtube.com/watch?v=CEE85F3Zjcs
Repo link: https://github.com/activitycentral/dxs


Transparent Client Authentication

This is still very much a topic being researched (so opinions, ideas,
feedback is very welcome). The broad problem we want to address is that the
XSCE/DXS may be running many services in the future, some of which would
require per user accounts and authentication. We want to build a mechanism
through which a child doesn't have to remember his/her username/password to
be able to access the service. One such example which is already part of
the XS/XSCE/DXS is Moodle. If you're registered to the schoolserver, you
don't need to type in your username and password when you go to
schoolserver/moodle. We would like to make it generic for more services
that may be added in the future.

This is a very tricky problem to solve, and we don't claim to have the
perfect solution yet. Even so, you may look at this video, that
demonstrates one possible approach.
https://plus.google.com/u/0/116719750476123557573/posts/PwYwPSPuTyC


Munin, ejabberd & collaboration on the public DXS instance.

We have included Munin on an experimental basis in the DXS. It's certainly
useful to be able to see usage data in nice looking graphs when you're
testing stuff. Also, one may go to the public instance of the DXS, follow
the instructions there to register, and test out collaboration and other
features.

http://schoolserver.alabamaxo.org/

*Note: The homepage portal that is included in XSCE isn't part of the DXS
yet. The homepage on the above link was created by Anna to make it easy for
users/testers to experiment with the public DXS instance.*
*
*
*- - - -*
*
*
*Should you have any questions, or feedback, pls reply to this thread. DXS
team-members (aklis, ajay, annabham, migonzalvar, m_anish) are also present
on #schoolserver and should be able to answer any questions you may have.
Also, there is an XSCE meeting on Tuesday, 12 noon, EDT @ #schoolserver,
where we all plan to be present.*
*
*
*The full meeting minutes and logs can be accessed at:
https://sugardextrose.org/issues/4612*

Cheers,
Anish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/server-devel/attachments/20130907/dda19bb3/attachment.html>


More information about the Server-devel mailing list