-
Notifications
You must be signed in to change notification settings - Fork 46
/
ideas-2019.html
894 lines (867 loc) · 46.9 KB
/
ideas-2019.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<title>OpenWISP GSoC 2019 Ideas List</title>
<link rel="stylesheet" href="../css/reset.css" type="text/css">
<link rel="stylesheet" href="../css/semantic.min.css" type="text/css">
<link rel="stylesheet" href="../css/style.css" type="text/css" media="screen">
<link rel="icon" type="image/x-icon" href="../images/favicon.png" />
</head>
<body class="content">
<div class="ui sidebar vertical menu">
<a class="item" href="../index.html">Home</a>
<a class="item" href="../whatis.html">Features</a>
<a class="item" href="../history.html">History</a>
<a class="item" href="../support.html">Support</a>
<a class="item" href="https://openwisp.io/docs">Docs</a>
<a class="item" href="../thecode.html">Code</a>
<a class="item" href="../about.html">People</a>
</div>
<div class="pusher">
<div class="ui grid" id="top-bar">
<div class="ui computer only column sixteen wide">
<div class="ui center aligned container secondary menu">
<h1 class="item logo">
<a href="../">OpenWISP</a>
</h1>
<div class="right menu">
<a class="item" href="../index.html">Home</a>
<a class="item" href="../whatis.html">Features</a>
<a class="item" href="../history.html">History</a>
<a class="item" href="https://openwisp.io/docs">Docs</a>
<a class="item" href="../support.html">Support</a>
<a class="item" href="../thecode.html">Code</a>
<a class="item" href="../about.html">People</a>
</div>
</div>
</div>
<div class="ui mobile tablet only sixteen wide column">
<div class="ui menu">
<h1 class="item logo">
<a href="../">OpenWISP</a>
</h1>
<div class="right menu">
<div class="menu-open item">
<i class="sidebar icon"></i>
</div>
</div>
</div>
</div>
</div>
<div class="ui grid" id="main">
<article class="ui container">
<h1>Google Summer of Code 2019 Idea List</h1>
<p>
Do you want to apply with us?
We have a page that describes how to increase your chances of success. Please read it carefully.
</p>
<p class="center">
<a class="ui big inverted red button"
href="https://openwisp.io/docs/developer/google-summer-of-code.html">
Read our GSoC Quick Start!
</a>
</p>
<h2>General suggestions and warnings</h2>
<ul class="ui bulleted link list">
<li>
<strong>some details may be missing from the project idea</strong>:
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
</li>
<li>
<strong>
code and prototypes are preferred over detailed documents
and unreliable estimates:
</strong>
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
</li>
<li>
<strong>accepted students will have to create github issues and
a kanban board on github for their project</strong>:
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
</li>
</ul>
<h2 id="docker">Dockerization of OpenWISP 2</h2>
<p><strong>Languages & technologies used:</strong> Python, Bash, Docker, Docker Compose, OpenVPN.</p>
<p>
The current automated <a href="https://github.com/openwisp/ansible-openwisp2">
deployment procedure for OpenWISP 2 is based on Ansible</a> 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
<strong>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</strong>.
</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>
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.<br>
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.<br>
</li>
<li>
Create a docker-compose configuration that achieves the following goals:
<ul>
<li>
Provide the OpenWISP Admin interface and the views
managing account information (password reset, email confirmation)
in a dedicated container.
</li>
<li>
Provide the OpenWISP Controller (<code>connections</code> branch)
views and APIs in a dedicated container
</li>
<li>Provide the OpenWISP Network Topology views and APIs in a dedicated container</li>
<li>Provide the websocket server of OpenWISP in a dedicated container</li>
<li>Provide a celery worker, initially used only by OpenWISP Controller
(<code>connections</code> branch), but which later will executes background
tasks of other modules as well, in a dedicated container.
</li>
<li>Provide a dedicated container for celery-beat
(used to automatically execute background tasks periodically)
</li>
<li>
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
</li>
<li>
Provide mounted volumes that allow to store persistently
files that are uploaded by users (eg: floor plan images).
</li>
<li>Provide the OpenWISP Radius views and APIs in a dedicated container</li>
<li>
Provide a configurable freeradius instance in a dedicated container
</li>
<li>
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.
</li>
<li>
Ensure each OpenWISP module and its related services
can be turned off if not needed
</li>
<li>
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)
</li>
<li>
Provide a redis instance in a dedicated container
and ensure the django settings point to it
</li>
<li>
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)
</li>
</ul>
</li>
<li>
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
</li>
<li>
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
</li>
<li>
Allow users to easily configure some django settings:
<ul>
<li>CORS settings</li>
<li>Sentry logging (including the celery container)
using the more recent <code>sentry_sdk</code>
(in ansible-openwisp2 we use the old pyhon-raven module)
</li>
<li>DEFAULT_FROM_EMAIL</li>
<li>SMTP settings</li>
<li>language code</li>
<li>timezone</li>
<li>Leaflet settings</li>
<li>default cert validity for django-x509</li>
<li>default CA validity for django-x509</li>
</ul>
</li>
<li>
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
</li>
<li>
Include installation, upgrade and usage information as well as
an explanation of configuration settings in the README.
</li>
</ul>
<h2 id="login-page">
React based WiFi Login Page with Auto-Login Feature
</h2>
<p>
<strong>Languages & technologies used:</strong>
ReactJS, NodeJS, HTML5, CSS and Javascript ES6 for the login page app,
Python and Django to edit django-freeradius and openwisp-radius.
</p>
<p>
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.
</p>
<p>
A few years ago we developed a configurable login page
that is configured and built via ansible:
<a href="https://github.com/openwisp/ansible-freeitaliawifi-login-page">
ansible-freeitaliawifi-login-page
</a>
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
<strong>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</strong>.
</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>
Implement a React.js based login page with a feature set that is similar
to <a href="https://github.com/openwisp/ansible-freeitaliawifi-login-page">
ansible-freeitaliawifi-login-page
</a>
</li>
<li>
The code shall be based on ES6 and transpiled with babel.js for old browsers
</li>
<li>
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
</li>
<li>
Provide in-browser automated testing with a modern and widely used solution
based on javascript<br>
Waiting the end of the project to begin this task is not acceptable
</li>
<li>
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<br>
Waiting the end of the project to begin this task is not acceptable
</li>
<li>
Prepare a README with installation, upgrade and usage instructions<br>
Waiting the end of the project to begin this task is not acceptable
</li>
<li>
Provide support for multiple organizations: the look and feel of the page
must be configurable as follows
<ul>
<li>
Each organization shall be reachable at its own URL path,
eg: <code>https://<domain>/<organization></code>
</li>
<li>
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
</li>
<li>
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
</li>
<li>
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:<br>
<strong>case 1</strong>: if the response is positive,
the user can see the login page;<br>
<strong>case 2</strong>: 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);<br>
<strong>case 3</strong>: if the request times out, the
login page will not be displayed and an error message
will be shown;<br>
the URL for case 2 shall be implemented in the node.js backend
and it shall return a simple JSON response
</li>
</ul>
</li>
<li>
The login form of the page shall have
the features described below
<ul>
<li>
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)
</li>
<li>
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)
</li>
<li>
If the authentication fails because the openwisp-radius API
is not reachable, an appropriate error message should be displayed
</li>
<li>
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
</li>
<li>
The status page shall provide a link to where users can
change their own password
(<a href="https://github.com/openwisp/openwisp-radius/issues/44">will
need a backend API endpoint described in this github issue</a>)
</li>
<li>
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)
</li>
<li>
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);<br>
<strong>case 1</strong>: if the user token is valid and the user
does not have an already open session in freeradius,
perform automatic authenticatation<br>
<strong>case 2</strong>: if the user already has an open session
redirect to the status page;<br>
<strong>case 3</strong>: if the token is not valid, log a
warning and proceed to show the login page to the user;<br>
<strong>case 4</strong>: if the request to check the token
times out, the login page will not be displayed and an error message
will be shown;
</li>
<li>
Add an API endpoint to django-freeradius/openwisp-radius
that given an user auth token, returns the following information:<br>
<b>1.</b> whether the user token is valid<br>
<b>2.</b> whether the user has a radius session open or not
</li>
<li>It shall be possible to turn off the auto-login feature</li>
<li>The login page shall provide a checkbox, checked by default,
which allows the user to turn on or off the auto-login feature</li>
<li>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
(<a href="https://github.com/openwisp/openwisp-radius/issues/44">will
need a backend API endpoint described in this github issue</a>)
</li>
</ul>
</li>
<li>
Provide a sign up page with the following features
<ul>
<li>
The page shall use the registration API of
OpenWISP Radius to sign up new users
</li>
<li>
If the sign up fails (eg: email already taken), the error
message provided by the API shall be shown in the sign up form
</li>
<li>
If the sign up fails because the openwisp-radius API
is not reachable, an appropriate error message should be displayed
</li>
<li>
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
</li>
</ul>
</li>
<li>
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
</li>
</ul>
<h2 id="template-library">OpenWISP Template Sharing & Template Library</h2>
<p>
<strong>Languages & technologies used:</strong>
Python and Django on the OpenWISP side,
ReactJS, NodeJS, Javascript ES6, HTML5 and CSS for the template library.
</p>
<p>
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.
</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>
Modify django-netjsonconfig and openwisp-controller to share templates:
<ul>
<li>the template can be flagged as private
(it would work as it does now)</li>
<li>the template can be flagged as shared publicly</li>
<li>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)</li>
<li>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
</li>
<li>if the template is shared (publicly or link-sharing),
its contents serialized to JSON will be available via an API endpoint;<br>
<b>public template example:</b> <code>/api/v1/templates/<uuid>/</code><br>
<b>private template example:</b> <code>/api/v1/templates/<uuid>/?key=<key></code><br>
</li>
<li>
a <code>description</code> text field shall be added to the <code>Template</code> model;
this field shall be used for the public description of the shared templates
(explain this in the <code>help_text</code>)
</li>
<li>
a <code>notes</code> text field shall be added to the <code>Template</code> model;
this field shall be used only for internal notes for the administrators
(explain this in the <code>help_text</code>)
</li>
<li>
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
</li>
<li>
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
</li>
<li>
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
</li>
<li>
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
</li>
<li>
there are other objects in OpenWISP which provide a key field,
the same logic should be reused in this project,
<a href="https://github.com/openwisp/openwisp-utils/issues/40">look
at this github issue in openwisp-utils</a>
if you want to get warmed up
and demonstrate that you can work on this project
</li>
<li>
edit the Template model and admin to allow specifying a URL
from which the template contents should be taken from;<br>
remember to manage the failure case (eg: the URL is not reachable,
the retrieved content is unusable or there's a validation error);<br>
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:<br>
<a href="https://github.com/openwisp/django-x509/blob/master/django_x509/base/admin.py#L9-L15">
Python part
</a><br>
<a href="https://github.com/openwisp/django-x509/blob/master/django_x509/static/django-x509/js/x509-admin.js">
Javascript part
</a>
</li>
<li>
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
</li>
<li>
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
</li>
<li>
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 (<code>ForeignKey</code> pointing to <code>Template</code> model),
ip, subscription date, last sync date
</li>
<li>
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
</li>
<li>
include the count of subscriptions of each external template in
its API endpoint and in its admin page (readonly field)
</li>
<li>Ensure test coverage remains high also while these changes are introduced</li>
</ul>
</li>
<li>
Implement a template library backend app in python and django with
the following features
<ul>
<li>
based on openwisp-users to implement users and organizations
</li>
<li>
based and django-allauth for social login
</li>
<li>
provides API endpoints for password forgotten, change password,
login, logout using django-rest-auth
</li>
<li>
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
</li>
<li>
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
</li>
<li>
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;<br>
it shall be possible to get the list of organizations as well as
their details;<br>
these API endpoints shall be included in openwisp-users and be
disabled by default (will be used explicitly enabled in the
template library website)
</li>
</ul>
</li>
<li>
Implement a template library web app based on ReactJS, which provides
the following features:
<ul>
<li>social sign up and login</li>
<li>log out</li>
<li>user profile page</li>
<li>create organization</li>
<li>edit owned organization</li>
<li>delete owned organization</li>
<li>list and search publicly shared templates</li>
<li>list and search publicly shared templates of a specific organization</li>
<li>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
</li>
<li>list organizations</li>
<li>organization detail page</li>
<li>provide autometed UI tests + test coverage,
linter and quality checks executed in a travis build</li>
<li>
provide basic installation and usage documentation in the README
</li>
</ul>
</li>
</ul>
<h2 id="netengine">netengine: pull monitoring info from network devices</h2>
<p><strong>Languages & technologies used:</strong> python, NetJSON, SNMP, HTTP, OpenWRT, Linux.</p>
<p>
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).
</p>
<p>
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.
</p>
<p>
<strong>NOTE</strong>: 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.
</p>
<p>
<strong>WARNING</strong>: 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.<br>
If it ever happens that you get accepted but you fail to buy an AirOS device,
you will be failed.
</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>
change the output format of the <code>to_json</code> method to
<a href="http://netjson.org/docs/what.html#devicemonitoring">NetJSON DeviceMonitoring</a>
</li>
<li>
mock all external network calls during tests (SSH, HTTP, SNMP)
</li>
<li>
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
</li>
<li>
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
</li>
<li>achieve 95% test coverage</li>
<li>
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
</li>
<li>set up a travis build that performs tests and checks test coverage</li>
</ul>
<p><strong>NOTE</strong>: this is one of those projects that sounds easy but is not.</p>
<h2 id="ansible-plugin-for-netjsonconfig">Ansible plugin for the netjsonconfig library</h2>
<p><strong>Languages & technologies used:</strong> python, ansible.</p>
<p><a class="reference external" href="https://github.com/ansible/ansible">Ansible</a> is an IT automation tool that has been recently
gaining popularity also in the <a class="reference external" href="http://openwrt.org">OpenWRT</a> world.</p>
<p>We want to implement an ansible plugin that integrates <a class="reference external" href="http://netjsonconfig.openwisp.org">netjsonconfig</a>
and allows using its two most interesting features, that is templates and context, in ansible.</p>
<p>It should be possible to define configuration templates, assign them to specific playbooks and define
specific configurations for hosts.</p>
<p>The configuration format format used by netjsonconfig is <a class="reference external" href="http://netjson.org/docs/what.html#deviceconfiguration">NetJSON DeviceConfiguration</a>, but a <em>YAML</em>
conversion of <em>NetJSON</em> would be good as well. Support for both would be preferred.</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>Implement an ansible module that integrates netjsonconfig in ansible and allows using
<a class="reference external" href="http://netjson.org/docs/what.html#deviceconfiguration">NetJSON DeviceConfiguration</a> (or its <em>YAML</em> equivalent) to configure OpenWRT devices</li>
<li>Achieve a test coverage higher than 80%</li>
<li>Provide documentation using <a class="reference external" href="http://www.sphinx-doc.org/">python-sphinx</a></li>
</ul>
<h2 id="netjsongraphjs">netjsongraph.js: canvas and geographic data</h2>
<p><strong>Languages & technologies used:</strong> javascript, ES6, CSS, netjson and a bit of python and django in the last phase.</p>
<p><a href="https://github.com/interop-dev/netjsongraph.js">netjsongraph.js</a> is a javascript library based on d3 that allows visualization of
<a href="http://netjson.org/docs/what.html#networkgraph">NetJSON NetworkGraph objects</a>.</p>
<p>
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.<br>
We also need an optional mode in which the network is displayed on a map.</p>
<p>
We aim at building something like <a href="https://regensburg.freifunk.net/meshviewer/#/en/graph">mesh viewer</a>
with the difference that this is a library and not an application.<br>
We want to give developers the possibility to implement features like those of mesh-viewer
in their application without reinventing the weel <b>BUT</b> we also want to integrate
these features in OpenWISP 2, infact we are already using the current <i>netjsongraph.js</i> version
in our network topology module, for more information see
<a href="https://github.com/netjson/django-netjsongraph">django-netjsongraph</a> (which is
the base module wrapped by <a href="https://github.com/openwisp/openwisp-network-topology">openwisp-network-topology</a>).
</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>Rewrite the visualizer to use canvas</li>
<li>Add an optional map mode</li>
<li>
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
</li>
<li>
Provide a well written but short example in the README of how to use the
<i>real time update</i> feature to update the graph using websockets
</li>
<li>
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.
</li>
<li>Modernize javascript code organization:
you may want to use some modern JS tool for building the library and perform testing
</li>
<li>Achieve test coverage of 90%</li>
<li>Update the travis build so that it automatically runs tests, style checks and test coverage</li>
<li>Update documentation and examples in README</li>
<li>Explain how to migrate from the previous version to the new version in the README</li>
<li>Upgrade the netjsongraph.js version in <a href="https://github.com/netjson/django-netjsongraph">django-netjsongraph</a>, ensuring everything works!</li>
<li>Release netjsongraph.js on npm</li>
</ul>
<h2 id="netjson-ubus">Implement NetJSON output in ubus (OpenWRT/LEDE)</h2>
<p><a href="http://netjson.org">NetJSON</a> 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 <a href="https://wiki.openwrt.org/doc/techref/ubus">ubus (OpenWrt micro bus architecture)</a>,
which is included by default in <a href="https://openwrt.org/">OpenWRT</a>, the two linux distributions
commonly used with OpenWISP.
</p>
<p>In this project the student will have to develop ubus API extensions that allow retrieving monitoring informatio in NetJSON format
(<a href="http://netjson.org/docs/what.html#devicemonitoring">NetJSON DeviceMonitoring</a>) from ubus.
</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>
Implement a way to retrieve <a href="http://netjson.org/docs/what.html#devicemonitoring">DeviceMonitoring</a> output in ubus,
consider reusing part of the code used in <a href="https://github.com/wlanslovenija/nodewatcher-agent#ubus-api">nodewatcher-agent</a>
</li>
<li>Write tests and obtain test coverage of 95%</li>
<li>Write a Makefile to package the software for OpenWRT/LEDE</li>
<li>Document the compilation/install process and the usage of the module in the README</li>
<li>Set up a build on travis that automatically compiles the modules and runs tests</li>
</ul>
<h2 id="pfsense-backend-for-netjsonconfig">PfSense backend for OpenWISP 2</h2>
<p><strong>Languages & technologies used:</strong> python, pfsense, json-schema, netjson.</p>
<p>Implement a <a class="reference external" href="https://pfsense.org/">PfSense</a> backend in <a class="reference external" href="http://netjsonconfig.openwisp.org">netjsonconfig</a>.</p>
<p><strong>Measurable outcomes:</strong></p>
<ul class="ui bulleted link list">
<li>The <code class="docutils literal"><span class="pre">PfSense</span></code> backend must generate a configuration archive compatible with PfSense 2.2.x</li>
<li>The <code class="docutils literal"><span class="pre">PfSense</span></code> backend must generate a configuration archive compatible with PfSense 2.3.x</li>
<li>The <code class="docutils literal"><span class="pre">PfSense</span></code> 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</li>
<li>The general test coverage of the library must be kept higher than 95%</li>
<li>The backend must be to be documented inside the <a class="reference external" href="http://www.sphinx-doc.org/">python-sphinx</a> docs dir
contained in the <em>netjsonconfig</em> repo</li>
</ul>
<h2>Apply with us</h2>
<p>
Do you want to apply with us?
We have a page that describes how to increase your chances of success. Please read it carefully.
</p>
<p class="center">
<a class="ui big inverted red button"
href="https://openwisp.io/docs/developer/google-summer-of-code.html">
Get started!
</a>
</p>
</article>
</div>
<div class="ui black inverted segment padding-vertical" id="footer">
<div class="ui container stackable two column grid">
<div class="column logo white">
<a href="./">OpenWISP</a>
</div>
<div class="column social">
<a href="https://twitter.com/openwisp" class="ui twitter button">
<i class="twitter icon"></i>
Twitter
</a>
<a href="https://facebook.com/openwisp" class="ui facebook button">
<i class="facebook icon"></i>
Facebook
</a>
<a href="https://www.linkedin.com/company/openwisp" class="ui linkedin button">
<i class="linkedin icon"></i>
Linked In
</a>
<a href="https://github.com/openwisp" class="ui black button">
<i class="github icon"></i> Github
</a>
</div>
<p>© 2008-<script>document.write(new Date().getFullYear())</script> OpenWISP and individual contributors.</p>
</div>
</div>
</div>
<script src="../js/jquery-3.7.1.min.js"></script>
<script src="../js/semantic.min.js"></script>
<script src="../js/scripts.js"></script>
</body>
</html>