Currently, sessions are created as files in /var/lib/plinth/sessions. If a user
does not logout, the sessions remains there ever after expiry. Cleanup these
accumulating files by running a cleanup job every week.
Adding django.contrib.sessions to apps list necessary to ensure that
'clearsessions' management command is available. This creates an empty database
table for session storage but is harmless.
Tests performed:
- When run with the change for first time, migration is run for
django.contrib.sessions app.
- Change the scheduled interval to 30 seconds in the code. Login as a user. A
new session file is created in data/var/lib/plinth/sessions. Forward the system
clock by at least 2 weeks. The session expires. Within 30 seconds the file is
also removed.
- Login, then remove the django-secret.key. In 30 seconds we see a message that
the session data is corrupt. Advance the clock by at least 2 weeks. The session
file is removed and the message about session data is no longer printed.
- Repeat for system level plinth after `./setup.py install` and `sudo -u plinth
plinth`.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Secret is important for various functions of Django. There is no impact on
existing installations due to the change. Improves the security of existing
functions in minor ways and will be useful in future usage of Django.
- Create the file in /var/lib/plinth/ with 0o600 permissions.
- Make git ignore the file in code folder.
- Don't copy the file during './setup.py install' operation.
Impact to users after upgrade:
- All existing sessions will get logged out. This is because SECRET_KEY is used
to generate user session hash that is used to logout users when their password
changes.
Tests performed:
- Run development version of service. File should get created in
data/var/lib/plinth/django-secret.key. Permissions should be 0o600.
- Run again, the file should not be overwritten. Printing
django.conf.settings.SECRET_KEY should match the one in the file.
- Run `setup.py install`. This should not install django-secret.key in
/var/lib/plinth.
- Run `sudo -u plinth plinth`. This should create the secret key file in
/var/lib/plinth/django-secret.key. Permissions on the file should be 0o600.
Ownership should be plinth:plinth.
- Remove the file in both cases, a fresh new file should get created with new key.
- Truncate the file to less than 128 chars, the existing file should get
overwritten with new key.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Cosmetic styling fixes. Having doc string as suggested by Python doc string
guidelines.
- 'connected to the Internet' seems much more popular phrase than 'connected on
the Internet' judging by web search results.
- Stylize as 'Internet' for consistency although 'internet' is correct too.
- Add space at the end of main radio button option text as translators seems to
understand it incorrectly. See current Spanish translation.
- Recommend 'DMZ' for router configuration.
- Remove incorrect title casing port forwarding text.
- Internationalize some strings.
- Update the default value for router configuration to 'not_configured'.
- Update the default value for Internet connection type to None so that nothing
is selected by default. We could consider introducing a fourth option
'not_configured'.
- Update the ID of first boot wizard step for Internet connectivity.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
- Using Markup on format_lazy objects seems to convert negate their lazy
behavior.
- Extend the format_lazy() utility method to handle markup.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
This allows for many cases of having to deal with Django objects such as models.
- Allows all modules including ones with models to be imported by Sphinx.
- Run most of the management commands using django-admin.
- Make it simpler to import all modules on REPL interactive Python shells.
Does not change any of the settings that we are passing to Django for
configuration.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: #1779.
Wait until configuration files are created the deluge services.
- Deluged service on Debian Stable creates the core configuration file after
first exit. The version on Debian Testing creates the configuration file during
first run.
- deluge-web seems to create web.conf on first run.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Closes: #1782.
This restores the API to the earlier behavior of ignoring errors when firewalld
is not running. This may not be the best approach however.
- Ignore errors on all operations when firewalld is not running. This include
enable/disable service, list interfaces of a zone, get service ports and get
enabled service.
- Log errors when firewalld is not running.
- ALREADY_ENABLE and NOT_ENABLED errors already ignored during enable/disable
service operations respectively.
Tests successfully executed:
- Turn off firewalld and perform following operations. They should all log an
error that firewalld is not running.
- Visit app page of an app that works only on internal networks such as
Privoxy. It should show that there are no internal networks.
- Run diagnostics of an app. It should show ports for a service as empty list.
- Enable/disable an app, it should enable/disable without failure.
- Visit firewall app page. It should show that firewalld is not running.
- Perform all the about operations without error message showing up and with
expected results.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
None of the files are installed into /etc/. They will unconditionally override
older versions of themselves. They are not likely to cause any configuration
file prompts.
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Significantly reduce the time taken to perform the operations in the following
cases:
- Enable/disable an app
- list services in firewall page
- Load app page when interfaces belonging to internal zone need to shown
- First run setup of FreedomBox
- Install a polkit local authority configuration file to allow FreedomBox
service to perform: information queries and configuration changes.
- Drop unused actions.
- Alter the template for showing firewall port information since port/protocol
pairs are no longer pre-formatted.
- Handle errors when trying to get ports details of an unknown service.
Tests performed:
- Enable/disable an app. Ensure with firewall-cmd that ports are added/removed
properly.
- Temporarily modify code to call add_service() and remove_service() twice in a
row. Perform enable/disable operations and ensure that there are not error
thrown to test that add/remove services operations are idempotent.
- Visit the firewalld page and see the current state is reflected properly.
- Visit an app that shows the list of interfaces in firewall zone. Internal
interfaces should be listed properly.
- Reset the installed version of firewall app and disable all firewall services.
Start FreedomBox and ensure that when setup is re-run, default ports (http,
https, dns and dhcp) are opened properly. Run again but with ports already
enabled to check that the setup operation is idempotent.
- Visit diagnostics of an app that uses firewall components and see that ports
are listed properly in the port diagnostic test result.
- Remove some needed services such as those in /etc/firewalld/services and try
to visit the firewalld page. The page should show blank details against the
affected services.
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Remove the need to pass all the individual information elements to the AppView
separately. This eliminates many issues with elements that were mistakenly not
sent to AppView. Also reduces a lot of code duplication.
- Create App classes for power and sso for consistency.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
