I’ve recorded a screencast: Labtainers in docker demonstration (embedded below) demonstrating how I’ve tweaked Labtainers so as to run it inside its own Docker container.
I’m currently very much excited by the Labtainers framework for delivering virtual labs, for instance in the context of MOOCs.
Labtainers is quite interesting as it allows isolating a lab in several containers running in their own dedicated virtual network, which helps distributing a lab without needing to install anything locally.
My tweak allows to run what I called the “master” container which contains the labtainers scripts, instead of having to install labtainers on a Linux host. This should help installation and distribution of labtainers, as well as deploying it on cloud platforms, some day soon. In the meantime Labtainer containers of the labs run with privileges so it’s advised to be careful, and running the whole of these containers in a VM may be safer. Maybe Labtainers will evolve in the future to integrate a containerization of its scripts. My patches are pending, but the upstream authors are currently focused on some other priorities.
Another interesting property of labtainers that is shown in the demo is the auto-grading feature that uses traces of what was performed inside the lab environment by the student, to evaluate the activities. Here, the telnetlab that I’ve shown, is evaluated by looking at text input on the command line or messages appearing on the stdout or in logs : the student launched both telnet or ssh, some failed login appeared, etc.
However, the demo is a bit confusing, in that I recorded a second lab execution whereas I had previously attempted a first try at the same telnetlab. In labtainers, traces of execution can accumulate : the student wil make a first attempt, and restart later, before sending it all to the professor (unless a redo.py is issued). This explanes that the grading appears to give a different result than what I performed in the screencast.
Stay tuned for more news about my Labtainers adventures.
P.S. thanks to labtainers authors, and obs-studio folks for the screencast recording tool 🙂
La prochaine conférence MiNET, le 24/05/2018 après-midi, promet d’être très intéressante sur le sujet des systèmes d’exploitation, avec 4 intervenants pointus :
- Julia Lawall : “Introduction to Coccinelle and its usage in the Linux Kernel“
- Sebastien Valat : “Memory management and OS paging for high performance computing“
- Pierre Pronchery : “DeforaOS: Un voyage dans le développement de système d’exploitation“
- Cyril Brulebois : “Maintenir et développer la distribution Debian“
Plus de détails sur https://conference.minet.net/#conf2018
N’hésitez pas à nous rejoindre à Évry pour participer à cette conférence, ou à suivre la retransmission sur la chaîne Youtube de MiNET.
Todo-Backend lists many implementations of the same REST API with different backend-oriented Web development frameworks.
I’ve proposed my own version using Symfony 4 in PHP, and the api-platform project which helps implementing REST APIs.
I’ve documented the way I did it in the project’s documentation in details, for those curious about Symfony development of a very simple REST API (JSON based). See its README file (of course redacted with the mandatory org-mode ;).
You can find the rest of the code here : https://gitlab.com/olberger/todobackend-symfony4.
AFAICS api-platform offers a great set of features for Linked-Data/REST development with Symfony in general. However, some tweaks were necessary to conform the TodoBackend specs, mainly because TodoBackend is JSON only and doesn’t support JSON-LD…
Oh, and the hardest part was deploying on Heroku, making sure that the CORS headers would work as expected :-/
I’ve improved a bit the org-teaching framework in order to prepare for the next edition of the CSC4101 classes.
I’ve now added a docker container which is in charge of performing the HTML or PDF exports of the slides (using org-reveal) or handbooks (using LaTeX).
Emacs and org-mode are still advised for editing contents, but having this container in the loop ensures that colleagues are able to preview the changes to the teaching material, and I’m no longer a bottleneck for generating the handouts. This also allows to export in a reproducible way, which doesn’t depend on my Emacs config tweaks.
I’ve also added Gitlab pages to the project’s CI so that the docs are updated live at https://olberger.gitlab.io/org-teaching/.
It’s probably not yet rady for use by anyone else, but I’d be glad to get feedback 😉
I’ve installed Debian buster (testing at the time of writing) on a new Dell Latitude 5580 laptop, and one annoyance I’ve found is that the laptop would almost always resume as soon as it was suspended.
AFAIU, it seems the culprit is the network card (Ethernet controller: Intel Corporation Ethernet Connection (4) I219-LM) which would be configured with Wake-On-Lan (wol) set to the “magic packet” mode (ethtool enp0s31f6 | grep Wake-on would return ‘g’). One hint is that grep enabled /proc/acpi/wakeup returns GLAN.
There are many ways to change that for the rest of the session with a command like ethtool -s enp0s31f6 wol d.
But I had a hard time figuring out if there was a preferred way to make this persistant among the many hits in so many tutorials and forum posts.
My best hit so far is to add the a file named /etc/systemd/network/50-eth0.link containing :
The driver can be found by checking udev settings as reported by udevadm info -a /sys/class/net/enp0s31f6
There are other ways to do that with systemd, but so far it seems to be working for me. Hth,