Google Summer of Code 2019 Idea List

Do you want to apply with us? We have a page that describes how to increase your chances of success. Please read it carefully.

Read our GSoC Quick Start!

General suggestions and warnings

• some details may be missing from the project idea: we expect students to do their own research, propose solutions, and be ready to deal with uncertainty and solve challenges that may come up during the project
• code and prototypes are preferred over detailed documents and unreliable estimates: rather than wasting your time on writing a very long application document, we suggest you to invest in writing a prototype (which means the code may be thrown out entirely) which will help you understand the challenges of the project you want to work on; your application should refer to the prototype or other github contributions you made to OpenWISP that show you have the capability to succeed in the project idea you are applying for
• accepted students will have to create github issues and a kanban board on github for their project: the requirements listed in the idea page will have to be converted into github issues which shall be tracked from a kanban board on github to allow the openwisp community to easily keep track of the project progress

Dockerization of OpenWISP 2

Languages & technologies used: Python, Bash, Docker, Docker Compose, OpenVPN.

The current automated deployment procedure for OpenWISP 2 is based on Ansible and has served us well until today but has some limitations that make it unsuited for more complex deployments that need horizontal scaling, custom setups and easily replicable deployments.

This project idea aims to develop an automated deployment procedure based on Docker and Docker Compose, mixing in also other technologies like Python and Shell scripts to glue together all the pieces needed to achieve it.

We also aim to provide a fully working OpenWISP instance that includes a management VPN (based on OpenVPN) that works out of the box and is pre-configured in OpenWISP.

Keep in mind that some parts of some OpenWISP may need to be changed to make the dockerization easier, so if you want to work on this project you must be familiar with changing the internals of OpenWISP modules.

Feel free to suggest some tools or technologies to solve specific problems if you think it's appropriate and would be beneficial, keeping in mind that we want to keep things as simple as possible.

Measurable outcomes:

• Create one or more set of images based on Alpine Linux and python 3.7 which have all the python packages needed for the different services.
  Find out the right balance between efficiency, configurability and simplicity by leveraging the docker features like base images, build arguments, multi stage builds and any other tool that may be useful to create a good set of docker images.
  
• Create a docker-compose configuration that achieves the following goals:
  • Provide the OpenWISP Admin interface and the views managing account information (password reset, email confirmation) in a dedicated container.
  • Provide the OpenWISP Controller (connections branch) views and APIs in a dedicated container
  • Provide the OpenWISP Network Topology views and APIs in a dedicated container
  • Provide the websocket server of OpenWISP in a dedicated container
  • Provide a celery worker, initially used only by OpenWISP Controller (connections branch), but which later will executes background tasks of other modules as well, in a dedicated container.
  • Provide a dedicated container for celery-beat (used to automatically execute background tasks periodically)
  • Provide a default management VPN based on OpenVPN in a dedicated container. The VPN shall be also pre-configured in OpenWISP, both as a VPN Server and a related VPN client template (ask questions to your mentors to know more about this), the OpenVPN configuration used in the container shall be kept in sync with the definition available in the VPN Server of OpenWISP. The Certificate Revocation List of the VPN shall be downloaded periodically from openwisp on the filesystem (a script run in a crontab) of the VPN server and the configuration of the VPN server
  • Provide mounted volumes that allow to store persistently files that are uploaded by users (eg: floor plan images).
  • Provide the OpenWISP Radius views and APIs in a dedicated container
  • Provide a configurable freeradius instance in a dedicated container
  • Provide a dedicated container with an nginx instance which has HTTP 2, IPv6 and Gzip enabled by deafult (but can be turned off if needed) that dispatches HTTP requests to the different containers, depending on which domain is called (eg: dashboard.mydomain.com for the admin container, controller.mydomain.com for openwisp-controller container and so on); Allow to provide custom settings for each site.
  • Ensure each OpenWISP module and its related services can be turned off if not needed
  • Provide a PostgreSQL instance in a dedicated container, ensure all the other services point to this postgres instance, ensure the data is stored on persistent storage, allow using a PostgreSQL hosted elsewhere as an alternative (some users may want to use managed PostgreSQL services)
  • Provide a redis instance in a dedicated container and ensure the django settings point to it
  • Provide a deafult working postfix instance which is able to send emails but can also be turned off (users may want to use an external SMTP service)
• The different containers may have very similar or some times identical django settings but we need to absolutely avoid having to manually maintain duplicated settings; find a way to manage the django settings of OpenWISP efficiently and in a way that allows to avoid duplication between the different services
• Customizability: it should be possible to use custom Docker images and custom django settings for OpenWISP in order to ensure that different users can deploy their tailored OpenWISP based network automation solution
• Allow users to easily configure some django settings:
  • CORS settings
  • Sentry logging (including the celery container) using the more recent sentry_sdk (in ansible-openwisp2 we use the old pyhon-raven module)
  • DEFAULT_FROM_EMAIL
  • SMTP settings
  • language code
  • timezone
  • Leaflet settings
  • default cert validity for django-x509
  • default CA validity for django-x509
• Implement automated testing with basic checks for each service, eg: for the admin interface, send and HTTP request expecting to see the login page (at least one similar checks should be implemented for each service); the tests shall be executed in a travis-ci build
• Include installation, upgrade and usage information as well as an explanation of configuration settings in the README.

React based WiFi Login Page with Auto-Login Feature

Languages & technologies used: ReactJS, NodeJS, HTML5, CSS and Javascript ES6 for the login page app, Python and Django to edit django-freeradius and openwisp-radius.

WiFi services most often make use of a login page (a.k.a captive page) that is used to allow users to authenticate, sign up and know more about the WiFi service they are using.

A few years ago we developed a configurable login page that is configured and built via ansible: ansible-freeitaliawifi-login-page

In this project idea we want to use that work as a base to improve upon that concept and integrate the result in the official OpenWISP toolset.

While using the current login page we encountered limitations that we aim to overcome with a different solution that will allow us to achieve more advanced features and more maintenability.

To achieve the goals of this project some small modifications to django-freeradius/openwisp-radius will be needed, so we encourage students interested in this project idea to become familiar with those two modules of OpenWISP.

Feel free to suggest some tools or technologies to solve specific problems if you think it's appropriate and would be beneficial, keeping in mind that we want to keep things as simple as possible.

Measurable outcomes:

• Implement a React.js based login page with a feature set that is similar to ansible-freeitaliawifi-login-page
• The code shall be based on ES6 and transpiled with babel.js for old browsers
• The software shall provide a backend part implemented in Node.js, which also serves as a proxy for all asynchronous (a.k.a. Ajax) HTTP requests that need to be made to external services (obtaining auth token, sign up, etc.); a configurable time-out should be set for all the external requests, defaulting to 2 seconds and the failure scenarios should be handled by displaying a nice error message to the user
• Provide in-browser automated testing with a modern and widely used solution based on javascript
  Waiting the end of the project to begin this task is not acceptable
• Ensure automated tests, code coverage, code-quality checks (JSHint, CSS linter, HTML linter) are executed automatically in a travis-ci build that is run on each commit
  Waiting the end of the project to begin this task is not acceptable
• Prepare a README with installation, upgrade and usage instructions
  Waiting the end of the project to begin this task is not acceptable
• Provide support for multiple organizations: the look and feel of the page must be configurable as follows
  • Each organization shall be reachable at its own URL path, eg: https://<domain>/<organization>
  • Only relative paths shall be used (to load CSS, JS, images, provide internal links), so that it will be possible to use nginx to reverse proxy specific domain names to a specific organization
  • Since different organizations have different needs, different logos, different themes, different languages, different features, most of the configuration options of this project must be editable at organization level, but since some settings may be identical for each organization it should also be possible to define the default settings at a general level
  • An optional feature, disabled by default, shall perform an asynchronous HTTP call to a specific URL before the page is displayed to the user, depending on the response returned by this URL the page may be displayed or not:
    case 1: if the response is positive, the user can see the login page;
    case 2: if the response is negative, the user cannot see the login page because they are not directly connected to the public wifi service (it means the login page is being accessed from a normal internet connection, think about your house or your 4G connection);
    case 3: if the request times out, the login page will not be displayed and an error message will be shown;
    the URL for case 2 shall be implemented in the node.js backend and it shall return a simple JSON response
• The login form of the page shall have the features described below
  • The login form shall authenticate users using the openwisp-radius "obtain auth token" API endpoint and use this token as a password that will be sent to the captive portal, usually Coova-Chilli or PfSense (a code sample will be provided)
  • If the authentication fails (eg: wrong password), the error message provided by the API shall be shown in the login form (a code sample will be provided)
  • If the authentication fails because the openwisp-radius API is not reachable, an appropriate error message should be displayed
  • After successful login, the user shall be redirected to an internal status page which displays a success message and informs the user that now they can use the internet
  • The status page shall provide a link to where users can change their own password (will need a backend API endpoint described in this github issue)
  • At successful login, the backend code should obtain a new user access token, encrypt it in a secure way (eg: with a secret key that is different for each organization and is accessible only by the backend, or an equivalent secure way) and the resulting encrypted token shall be stored in a signed cookie, served via HTTPS only (this feature shall be enabled by default and it should be possible to turn it off if needed)
  • When user comes back to the login page, if the cookie containing the encrypted token is detected by the backend, the user token shall be decrypted and used to check if it's valid and if the user needs to be authenticated again (this implies adding a new API endpoint in django-freeradius/openwisp-radius);
    case 1: if the user token is valid and the user does not have an already open session in freeradius, perform automatic authenticatation
    case 2: if the user already has an open session redirect to the status page;
    case 3: if the token is not valid, log a warning and proceed to show the login page to the user;
    case 4: if the request to check the token times out, the login page will not be displayed and an error message will be shown;
  • Add an API endpoint to django-freeradius/openwisp-radius that given an user auth token, returns the following information:
    1. whether the user token is valid
    2. whether the user has a radius session open or not
  • It shall be possible to turn off the auto-login feature
  • The login page shall provide a checkbox, checked by default, which allows the user to turn on or off the auto-login feature
  • The login page shall provie a link which when clicked shall allow users who forgot their password to reset it by providing their email address (will need a backend API endpoint described in this github issue)
• Provide a sign up page with the following features
  • The page shall use the registration API of OpenWISP Radius to sign up new users
  • If the sign up fails (eg: email already taken), the error message provided by the API shall be shown in the sign up form
  • If the sign up fails because the openwisp-radius API is not reachable, an appropriate error message should be displayed
  • The form should be automatically generated from a JSON-schema; the JSON schema should be configurable but a default schema that works out of the box with OpenWISP Radius shall be provided
• Provide support for multiple languages, English shall be the default, but we shall support also Italian and Spanish (translations will be provided by us); the available languages must be configurable

OpenWISP Template Sharing & Template Library

Languages & technologies used: Python and Django on the OpenWISP side, ReactJS, NodeJS, Javascript ES6, HTML5 and CSS for the template library.

The goal of this project idea is to implement features that will allow templates to be shared across different OpenWISP instances, as well as allow templates to be collected in a template library, one of which will be published and linked from the openwisp website.

Measurable outcomes:

• Modify django-netjsonconfig and openwisp-controller to share templates:
  • the template can be flagged as private (it would work as it does now)
  • the template can be flagged as shared publicly
  • the template can be flagged as shared with a secret key that will used to build a link that is shared with only those who know it (like google docs link sharing)
  • the template can be flagged as taken from an external source, in that case additional fields should be provided to allow users to specify the URL and the settings of the template
  • if the template is shared (publicly or link-sharing), its contents serialized to JSON will be available via an API endpoint;
    public template example: /api/v1/templates/<uuid>/
    private template example: /api/v1/templates/<uuid>/?key=<key>
    
  • a description text field shall be added to the Template model; this field shall be used for the public description of the shared templates (explain this in the help_text)
  • a notes text field shall be added to the Template model; this field shall be used only for internal notes for the administrators (explain this in the help_text)
  • shared templates will likely contain mostly variables (for example, imagine a coova-chilli captive portal configuration, the captive page URL, interface name, radius ip and ports will always differ for each user that wants to use the shared template), this may cause the backend validation to fail because variables are not recognized; find a way to overcome this problem, for example, sample values for each variable may be provided by the designer of the template and these values can be substituted to the variables so the validation doesn't fail, this means the template designer user should be allowed to fill these variables in some way
  • templates taken from external sources will likely contain variables that have to be filled by the user which imports that template from the external source, this means that the admin UI of OpenWISP should allow the user to fill these variables in some way; the list of variables may also be provided by the instance which shares the template
  • add an API endpoint in django-netjsonconfig which lists all the available public templates; include the possibility to perform a search in the name and description
  • add an API endpoint to openwisp-controller which lists all the available public templates for each organization, using the API endpoint of django-netjsonconfig described in the previous point as base class; openwisp-controller should also provide an API endpoint which lists all the available templates for all the
  • there are other objects in OpenWISP which provide a key field, the same logic should be reused in this project, look at this github issue in openwisp-utils if you want to get warmed up and demonstrate that you can work on this project
  • edit the Template model and admin to allow specifying a URL from which the template contents should be taken from;
    remember to manage the failure case (eg: the URL is not reachable, the retrieved content is unusable or there's a validation error);
    we shall add a switcher in the admin that explicitly asks the user to choose whether the template contents will be defined by themselves or be taken from an external source, the switcher logic shall be similar to the switcher we already have in django-x509 for new vs imported certificates, see the implementation:
    Python part
    Javascript part
  • when a user adds an external template successfully, the application shall start a background celery task that notifies the target openwisp instance that someone has subscribed to that template
  • when a user deletes an external template, the application shall start a background celery task that notifies the target openwisp instance that someone has unsubscribed from that template
  • implement the necessary API endpoint and model changes needed to receive notifications about subscriptions and unsubscriptions so that we can keep some statistics; each subscription should be stored in its own database record and should keep track of: template id (ForeignKey pointing to Template model), ip, subscription date, last sync date
  • add a Celery beat task to sync contents of external templates periodically; keep in mind the instance which sends the API request to sync its contents should do it in a way that lets the external source know that it should update the last sync date
  • include the count of subscriptions of each external template in its API endpoint and in its admin page (readonly field)
  • Ensure test coverage remains high also while these changes are introduced
• Implement a template library backend app in python and django with the following features
  • based on openwisp-users to implement users and organizations
  • based and django-allauth for social login
  • provides API endpoints for password forgotten, change password, login, logout using django-rest-auth
  • based on openwisp-controller to provide external templates, we should find a way to only use the template feature and only allow to create external templates
  • we shall add an API endpoint which allows creating external templates, we shall add this into openwisp-controller but keep it disabled by deafult and enable it only in the template library app
  • when users sign up using social login, they should proceed to create an organization, only then they will be allowed to create templates, this operation shall be performed via an API endpoint, it shall be also possible to edit and delete owned organizations, users should be also allowed to retrieve and edit their own user profile information;
    it shall be possible to get the list of organizations as well as their details;
    these API endpoints shall be included in openwisp-users and be disabled by default (will be used explicitly enabled in the template library website)
• Implement a template library web app based on ReactJS, which provides the following features:
  • social sign up and login
  • log out
  • user profile page
  • create organization
  • edit owned organization
  • delete owned organization
  • list and search publicly shared templates
  • list and search publicly shared templates of a specific organization
  • template detail page which includes subscription count, URL which can be used to import the template in openwisp-controller, organization owining the template and a link to the organization details
  • list organizations
  • organization detail page
  • provide autometed UI tests + test coverage, linter and quality checks executed in a travis build
  • provide basic installation and usage documentation in the README

netengine: pull monitoring info from network devices

Languages & technologies used: python, NetJSON, SNMP, HTTP, OpenWRT, Linux.

Netengine is a python library that aims to provide a single API to extract common information from network devices using different protocols (eg: SNMP, SSH, HTTP) and different firwmares (eg: OpenWRT, AirOS).

The library kinda worked but was not brought to production level work and since OpenWISP 2 is going to have a monitoring system soon, wa want to rewrite this library to bring its implementation to production level.

NOTE: backward compatibility does not have to be maintained we can freely change and improve the API and internal structure of the library if we think the change is going to improve the quality of the implementation.

WARNING: to work on this project you need an AirOS device; OpenWRT can be installed in a virtual box VM, but AirOS cannot (at least not as easily). If you don't have an AirOS device compatible with the latest version and you do not indend to buy one you cannot work on this project.
If it ever happens that you get accepted but you fail to buy an AirOS device, you will be failed.

Measurable outcomes:

• change the output format of the to_json method to NetJSON DeviceMonitoring
• mock all external network calls during tests (SSH, HTTP, SNMP)
• upgrade the OpenWRT backends to make it work well on OpenWRT 18.06 and OpenWRT (LEDE) 17-01; if there are incompatibilities, create different backends for each version, ensuring the shared logic is stored in a common class
• upgrade the AirOS backends to make it work with the latest 2 version of AirOS; if there are incompatibilities, create different backends for each version, ensuring the shared logic is stored in a common class
• achieve 95% test coverage
• improve documentation: at the moment the documentation is really scarce, we need the documentation to mention all the backends and all the important features, providing also a few examples of how to use the library
• set up a travis build that performs tests and checks test coverage

NOTE: this is one of those projects that sounds easy but is not.

Ansible plugin for the netjsonconfig library

Languages & technologies used: python, ansible.

Ansible is an IT automation tool that has been recently gaining popularity also in the OpenWRT world.

We want to implement an ansible plugin that integrates netjsonconfig and allows using its two most interesting features, that is templates and context, in ansible.

It should be possible to define configuration templates, assign them to specific playbooks and define specific configurations for hosts.

The configuration format format used by netjsonconfig is NetJSON DeviceConfiguration, but a YAML conversion of NetJSON would be good as well. Support for both would be preferred.

Measurable outcomes:

• Implement an ansible module that integrates netjsonconfig in ansible and allows using NetJSON DeviceConfiguration (or its YAML equivalent) to configure OpenWRT devices
• Achieve a test coverage higher than 80%
• Provide documentation using python-sphinx

netjsongraph.js: canvas and geographic data

Languages & technologies used: javascript, ES6, CSS, netjson and a bit of python and django in the last phase.

netjsongraph.js is a javascript library based on d3 that allows visualization of NetJSON NetworkGraph objects.

The library uses SVG for visualization, which can be quite slow when many elements are shown, therefore we would like to try switching to canvas.
We also need an optional mode in which the network is displayed on a map.

We aim at building something like mesh viewer with the difference that this is a library and not an application.
We want to give developers the possibility to implement features like those of mesh-viewer in their application without reinventing the weel BUT we also want to integrate these features in OpenWISP 2, infact we are already using the current netjsongraph.js version in our network topology module, for more information see django-netjsongraph (which is the base module wrapped by openwisp-network-topology).

Measurable outcomes:

• Rewrite the visualizer to use canvas
• Add an optional map mode
• Real time updates: refactor/change the javascript API so it becomes easy to update the network topology graph as updates are received from the server
• Provide a well written but short example in the README of how to use the real time update feature to update the graph using websockets
• Add support for date parsing, for example "2019-02-12T10:00:00Z" should be converted to the date, time and time zone used by the browser.
• Modernize javascript code organization: you may want to use some modern JS tool for building the library and perform testing
• Achieve test coverage of 90%
• Update the travis build so that it automatically runs tests, style checks and test coverage
• Update documentation and examples in README
• Explain how to migrate from the previous version to the new version in the README
• Upgrade the netjsongraph.js version in django-netjsongraph, ensuring everything works!
• Release netjsongraph.js on npm

Implement NetJSON output in ubus (OpenWRT/LEDE)

NetJSON is emerging as a common format to exchange configuration and monitoring information from network devices. Year after year it's becoming easier to achieve interoperability between different software packages for networking software. Now is time to start implementing NetJSON in a lower level of the stack and the next natural step in that direction is to implement it in ubus (OpenWrt micro bus architecture), which is included by default in OpenWRT, the two linux distributions commonly used with OpenWISP.

In this project the student will have to develop ubus API extensions that allow retrieving monitoring informatio in NetJSON format (NetJSON DeviceMonitoring) from ubus.

Measurable outcomes:

• Implement a way to retrieve DeviceMonitoring output in ubus, consider reusing part of the code used in nodewatcher-agent
• Write tests and obtain test coverage of 95%
• Write a Makefile to package the software for OpenWRT/LEDE
• Document the compilation/install process and the usage of the module in the README
• Set up a build on travis that automatically compiles the modules and runs tests

PfSense backend for OpenWISP 2

Languages & technologies used: python, pfsense, json-schema, netjson.

Implement a PfSense backend in netjsonconfig.

Measurable outcomes:

• The PfSense backend must generate a configuration archive compatible with PfSense 2.2.x
• The PfSense backend must generate a configuration archive compatible with PfSense 2.3.x
• The PfSense backend schema must cover at least 75% of the features offered by the PfSense web interface, with particular attention to interfaces, wireless settings, vlans, firewall rules and VPNs
• The general test coverage of the library must be kept higher than 95%
• The backend must be to be documented inside the python-sphinx docs dir contained in the netjsonconfig repo

Apply with us

Do you want to apply with us? We have a page that describes how to increase your chances of success. Please read it carefully.

Get started!