|
|
Line 1: |
Line 1: |
- | == RemoteLab Handbook ==
| |
- | 8.11.2015, Alexander Wold
| |
| | | |
- | == Introduction ==
| |
- | This document describes the RemoteLab software.
| |
- | The RemoteLab software allows students to upload and interact with lab-excercises though the web browser.
| |
- | The document is contains a software quick guide, description of the software architecture, installation instructions, and finally developer notes.
| |
- |
| |
- | == Software quick guide ==
| |
- | To download the lab text and the project files:
| |
- |
| |
- | Log on to RemoteLab at
| |
- |
| |
- | Find the lab assigment you want to work on.
| |
- |
| |
- | Download the lab text and then download the project files.
| |
- |
| |
- | Develop and simulate the lab using Vivado Webpack.
| |
- |
| |
- | When the lab simulates correcly, you can upload the project and test in on an FPGA-board.
| |
- |
| |
- | First create a tar.gz file of the vhdl files in your project folder.
| |
- |
| |
- | Log on to RemoteLab at
| |
- |
| |
- | Select Submit.
| |
- |
| |
- | Select Choose File, and select the tar.gz file containing the vhdl files.
| |
- |
| |
- | Select Upload.
| |
- |
| |
- | After the project has been implemented correctly, you can select Run.
| |
- |
| |
- | You can the interact with the board to test your solution.
| |
- |
| |
- | After some time, the session will expire to allow other users to test their projects.
| |
- |
| |
- | You can test your solution multiple times by refreshing the browser after the session has expired.
| |
- |
| |
- | == Software architecture ==
| |
- |
| |
- | The software is written in Python using the Django web framework.
| |
- | Users connect to a server which runs the webserver, a proxy, RabbitMQ (message server).
| |
- | Users only connect to the webserver.
| |
- | Lab excercises are executed on compute nodes.
| |
- | Messages are sent/received using Celery/RabbitMQ to the compute nodes.
| |
- | This allows students to interact with FPGA-hardware through the server.
| |
- | The compute nodes run Xilinx Vivado, Celery, and a live video stream of the FPGA board.
| |
- | Files are transmitted over HTTP, alternatively SFTP using certificate credentials.
| |
- |
| |
- | == Norsk software arkitektur/virkemåte ==
| |
- |
| |
- | Hensikten er å kunne tilby laboppsett gjennom nettleseren.
| |
- | Brukerne skal logge seg inn og kunne laste opp kildekode (vhdl) som kompileres, og deretter kan studentene kontrollere brytere gjennom nettleseren.
| |
- | Nettleseren viser video som streames slik at det er sanntids feedback på hva som skjer når en bruker trykker på en knapp.
| |
- | Dette systemet kan tilby mer kompliserte laboppsett, for eksempel styring av robotarm og lignende.
| |
- |
| |
- | Systemet består av 1 stk spluf-prod01 som brukerne kobler seg til.
| |
- | Det er også satt opp 3 stk pcer som tar seg av kompileringen med elektronikksoftware, og interface til et fpga-utviklerkort som programmeres av studenten, samt ett webkamera for streaming.
| |
- |
| |
- | All kommunikasjon mellom server og bruker er http.
| |
- | Det er *ingen* kommunikasjon mellom node-* og brukerne.
| |
- | Kommunikasjon mellom node-* og server er RabbitMQ meldinger og HTTP.
| |
- | HTTP skal brukes til overføring av filer og streaming av low-latency video.
| |
- | Oveføring av filer mellom server og node skjer ved at Celery/job-software på node-* logger seg på server med eget brukernavn/passord og henter ned bestemte filer.
| |
- | Det er eget brukernavn/passord på nedlasting av filer.
| |
- | Brukere kan ikke laste ned filer de har lastet opp.
| |
- |
| |
- | Følgende skjer med når en student bruker systemet:
| |
- |
| |
- | Bruker laster opp fil etter å ha logget seg på.
| |
- |
| |
- | Det opprettes en ny jobb, og en leding node tar denne jobben.
| |
- |
| |
- | Spluf-pc leser inn jobben, som inneholder filnavnet.
| |
- |
| |
- | Spluf-pc logger seg inn på server og henter filen brukeren lastet opp.
| |
- |
| |
- | Filen slettes samtidig fra server.
| |
- |
| |
- | Spluf-pc sjekker med fasit hvilke filer som skal hentes ut av filen brukeren lastet opp.
| |
- |
| |
- | Spluf-pc kompilerer. Dette er en CPU og IO intensiv jobb.
| |
- |
| |
- | Kompileringsloggen blir sendt som RabbitMQ-meldinger til server.
| |
- |
| |
- | Spluf-prod01 viser kompileringsloggen efterhvert som den blir motatt fra node.
| |
- |
| |
- | Etter kompilering laster node opp en kompilert fil til server.
| |
- |
| |
- | (Den kompilerte filen er laget for en FPGA-krets og er ikke det samme som en kompilert fil for pc).
| |
- |
| |
- | En ny jobb genereres av server.
| |
- |
| |
- | En leding spluf-pc starter den nye jobben ved å hente kompilert fil.
| |
- |
| |
- | Node programmerer den kompilerte filen inn på utviklerkortet.
| |
- |
| |
- | Server starter å vise HTTP-streaming av utviklerkort til bruker.
| |
- |
| |
- | Bruker får knapper å trykke på. Status og endringer på knappene blir sendt som RabbitMQ-meldinger mellom server og node.
| |
- |
| |
- | server rendrer for bruker via JSON/ajax.
| |
- |
| |
- | Efter en definert tid (noen minutter) vil brukeren bli logget ut og andre brukere kan få muligheten til å teste sine kompilerte filer.
| |
- |
| |
- | == Sikkerhet og skalerbarhet ==
| |
- | Sikkerhet og skalerbarhet er ivaretatt på følgende måte:
| |
- | Dersom det viser seg at det er for lite med 3 pcer kan vi enkelt legge til flere pcer uten å endre arkitekturen.
| |
- | Brukerne kobler seg bare til server.
| |
- | Node er isolert fra bruker.
| |
- | Brukerne laster opp zip/tar.gz filer.
| |
- | Disse filene blir distribuert til node som tar seg av utpakking av *bestemte* filer i arkivet.
| |
- | Nodene står får kompilering.
| |
- | Filene som komplieres er vhdl-tekstfiler.
| |
- | Kommentarer/pragrmas blir scrubbet før kompilering.
| |
- | Kataloger i zip/tar.gz-filen blir ikke ivaretatt (vi bryr oss bare om basename).
| |
- | Enkelte detaljer fra kompileringsloggen som sendes til bruker blir slettet (hostnames, lisensserver som er brukt, katalognavn).
| |
- | HTTP streaming skal settes opp til å forwarde bestemte stier: /video-01. /video-01/noe forwardes ikke.
| |
- |
| |
- |
| |
- |
| |
- | == Software installation ==
| |
- |
| |
- | == Software requirements on server ==
| |
- | The following software is required on the server:
| |
- | * rabbitmq
| |
- | * apache (proxy/webserver)
| |
- | * python 3.4
| |
- |
| |
- | In additon, the follewing python packages are required:
| |
- | * django
| |
- | * celery
| |
- | * django-file-form
| |
- | * django-bootstrap-toolkit
| |
- | * django-celery
| |
- | * django-crispy-forms
| |
- | * django-async-messages
| |
- | * django-cors-headers
| |
- |
| |
- |
| |
- |
| |
- | == Python software install on server ==
| |
- |
| |
- | As user create a virtualenv
| |
- | After installation of python software with
| |
- | Install python software with:
| |
- | ``pip install -r requirements.txt``
| |
- | Copy this directory to remotelab/site-packages
| |
- |
| |
- | == Software requirements on clients ==
| |
- |
| |
- | The following software is required on the compute nodes:
| |
- | * digilent utils
| |
- | * vivado
| |
- | * avconv,ffmpeg or MJPG-Streamer
| |
- |
| |
- | In additon, the follewing python packages are required:
| |
- | * pyserial
| |
- |
| |
- |
| |
- | == Developer notes ==
| |
- |
| |
- | Denne delen inneholder kommandoer som ofte er brukt under utvikling/oppgradering/vedlikehold.
| |
- |
| |
- | == Collecting static files ==
| |
- |
| |
- | In redhat enterprise linux to collect static files:
| |
- | First enable rh-python3:
| |
- | ``scl enable rh-python34 bash``
| |
- | then enable virtualenv
| |
- | ``source ~/opt/virtualenv/bin/activate``
| |
- | then collect static files
| |
- | ``python manage.py collectstatic``
| |
- |
| |
- |
| |
- | == SELinux ==
| |
- |
| |
- | If the server is using SELinux, use ``chcon -Rv -t httpd_sys_content_t *`` to update files after they have been checked out of subversion repo.
| |
- |
| |
- |
| |
- | setsebool -P httpd_can_network_connect 1
| |
- | chcon -Rv -t httpd_sys_content_t # python-directory
| |
- |
| |
- | == Starting Django ==
| |
- | To start the webserver
| |
- | On RHEL, first SCL
| |
- | ``scl enable rh-python34 bash``
| |
- | ``source ~/opt/rh-python34/bin/activate``
| |
- | ``python manago.py migrate``
| |
- | ``python manago.py createsuperuser``
| |
- |
| |
- | ``python manage.py runserver``
| |