Home Features History Support Docs Code People

OpenWISP

Home Features History Docs Support Code People

OpenWISP

Google Summer of Code 2018 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.

Get started!

openwisp-radius: integrating django-freeradius in OpenWISP 2

Languages & technologies used: python, django, freeradius, django-rest-framework, ansible.

One of the most important features missing in OpenWISP 2 is the AAA (Authorization, Authenticatio and Accounting), which in OpenWISP 1 is implemented with OpenWISP User Management System from now on (OWUMS).

In 2017 we worked on the base module of OpenWISP 2: django-freeradius, now is time to improve django-freeradius and integrate it in the OpenWISP 2 ecosystem.

Measurable outcomes:

  • add a way to enforce session limits (traffic limit, session time limit) in a similar way as OWUMS does, using radius groups
  • add a way to import users from CSV, first via a management command, then via the django admin
  • add optional ways to restrict API usage for security reasons, eg: token authentication, ip range; the default behaviour should allow the application to work out of the box without additional configuration
  • integrate django-freeradius in the rest of the openwisp2 ecosystem; we will create a new wrapper python package (openwisp-radius) that will wrap django-freeradius and add multitenancy features to it, similarly to how openwisp-controller wraps django-netjsonconfig or openwisp-network-topology wraps django-netjsongraph
  • the user model of openwisp-radius will reuse what is already defined in openwisp-users, but we need to add a way to easily define additional fields that user may need (think about social security number, badge ID, ecc) by using a Profile model. We'll need to figure out in which module is better to add this feature
  • integrate openwisp-radius in ansible-openwisp2 as an optional module; since some users will want to install only openwisp-radius we will need to change the ansible role so that openwisp-controller can be disabled if needed; we may decide to implement the logic of openwisp-radius in a sub-role that becomes a dependency of ansible-openwisp2 if we feel this makes maintenance easier
  • keep test coverage of django-freeradius at 100%
  • keep documentation of django-freeradius up to date
  • achieve test coverage of openwisp-radius of 100%
  • ensure the README of openwisp-radius is in line with the quality of the openwisp2 modules

openwisp-ipam: IP Address Management module for OpenWISP 2

Languages & technologies used: python, django, django-rest-framework, javascript.

This project idea consists in creating a new OpenWISP 2 IPAM module with the basic features for IP Address Management.

The project is divided in 2 phases.

Phase 1: django-ipam

This project idea consists in creating a django reusable app which provides the common features for IP Address Management:

  • IPv4 and IPv6 IP address management
  • Section / Subnet management with nested subnets
  • Automatic free space display for all subnets
  • Visual display for a specific subnet
  • IP request module (similar to phpipam)
  • RESTful API to for CRUD operations (using session authentication and django model permissions for authorization)
  • Possibility to search for an IP or subnet
  • CSV Import and Export of subnets and their IPs (using the same format of phpipam)

The django app must have also the following traits that will be needed for the second phase:

  • abstract abase models
  • reusable views for its API
  • reusable admin classes
  • reusable test classes (as in django-netjsongraph and django-freeradius)

Phase 2: openwisp-ipam

In this phase we will integrate django-ipam with the rest of the OpenWISP 2 ecosystem

This will require creating a module called openwisp-ipam which will wrap and integrate django-ipam in the rest of the OpenWISP 2 ecosystem, in a very similar way as openwisp-controller integrates django-netjsonconfig, and openwisp-network-topology integrates django-netjsongraph.

Measurable outcomes:

  • complete items described in phase 1
  • complete items described in phase 2
  • provide good documentation for django-ipam in form of a README.rst (using ResStructuredText), explaining how to install, run tests, configuration details, screenshots and explanation of the main features
  • provide basic developer documentation for openwisp-ipam in form of a README.rst (using ResStructuredText), explaining how to install and run tests
  • achieve a test coverage higher than 90% in both modules

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 "2018-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

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/LEDE 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 Chaos Calmer and 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

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 community networks. 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 LEDE and 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 90%
  • 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!