<div dir="ltr">Hi,<div><br></div><div>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. </div>
<div><br></div><div>Agenda of the demo was:</div><div><div><ul><li>Ansible playbooks<br></li><li>Ajenti GUI | Wondershaper Bandwidth throttling<br></li><li>Github workflow for DXS<br></li><li>Transparent Client Authentication How does Moodle magically log clients in, and how may it be scaled to other services<br>
</li><li>Munin, ejabberd & collaboration on the public DXS instance.<br></li></ul></div></div><div><i>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. <br>
</i></div><div><i><br></i></div><div><br></div><div><font size="4">Ansible Playbooks</font></div><div><br></div><div><i>Note: The demo happened as a live terminal broadcast session on <a href="http://83.165.130.53:8855/">http://83.165.130.53:8855/</a> (that link may not work now, and the information there is no longer relevant to ansible).</i></div>
<div><i><br></i></div><div>As pointed out in previous threads, <a href="http://www.ansibleworks.com/">ansible</a> 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.</div>
<div><br></div><div>In DXS, the ansible playbooks, often rely on variables and template files. For an example you can look at:</div><div><br></div><div><a href="https://github.com/activitycentral/dxs/blob/master/tasks/network.yml">https://github.com/activitycentral/dxs/blob/master/tasks/network.yml</a><br>
</div><div><a href="https://github.com/activitycentral/dxs/blob/master/templates/network/sysconfig.network.j2">https://github.com/activitycentral/dxs/blob/master/templates/network/sysconfig.network.j2</a><br></div><div><br>
</div><div>It's using ansible_variables. Some of them are automatically defined, and some can be defined.</div><div><br></div><div>Some advantages of ansible over bash/shell are:</div><div>* Makes it easy to include more services in less time. </div>
<div>* Makes it easy to integrate with other services (like Frontend-Ajenti)<br></div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div><font size="4">Ajenti GUI | Wondershaper Bandwidth throttling</font></div><div><font size="4"><br></font></div><div><a href="http://ajenti.org/">Ajenti</a> 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, <a href="http://lartc.org/wondershaper/">wondershaper</a> has been included. It's a service that allows the control of uplink and downlink bandwidths on various network interfaces the server uses.</div>
<div><br></div><div>Here's a video demonstrating Ajenti and Wondershaper. <a href="http://www.youtube.com/watch?v=-LbPRVc5Bv4">http://www.youtube.com/watch?v=-LbPRVc5Bv4</a> (apologies for the choppy audio)</div><div>
<br></div><div><br></div><div><font size="4">GitHub workflow</font></div><div><font size="4"><br></font></div><div>DXS shifted to <a href="https://github.com/activitycentral/dxs">GitHub</a> 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.</div>
<div><br></div><div>Here's a video demonstrating the GitHub workflow. <a href="http://www.youtube.com/watch?v=CEE85F3Zjcs">http://www.youtube.com/watch?v=CEE85F3Zjcs</a></div><div>Repo link: <a href="https://github.com/activitycentral/dxs">https://github.com/activitycentral/dxs</a><br>
</div><div><br></div><div><br></div><div><font size="4">Transparent Client Authentication</font><br></div><div><font size="4"><br></font></div><div>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. </div>
<div><br></div><div>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. <a href="https://plus.google.com/u/0/116719750476123557573/posts/PwYwPSPuTyC">https://plus.google.com/u/0/116719750476123557573/posts/PwYwPSPuTyC</a></div>
<div><br></div><div><br></div><div><font size="4">Munin, ejabberd & collaboration on the public DXS instance.</font></div><div><br></div><div>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.</div>
<div><br></div><div><a href="http://schoolserver.alabamaxo.org/">http://schoolserver.alabamaxo.org/</a><br></div><div><br></div><div><i>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.</i></div>
<div><i><br></i></div><div><i>- - - -</i></div><div><i><br></i></div><div><i>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.</i></div>
<div><i><br></i></div><div><i>The full meeting minutes and logs can be accessed at: <a href="https://sugardextrose.org/issues/4612">https://sugardextrose.org/issues/4612</a></i></div><div><br></div><div>Cheers,</div><div>
Anish</div><div><br></div></div>