[Sunil]:
- Drop Uwsgi component entirely. After the changes, it mostly looks like Daemon
component minus some features. One change that Uwsgi component does is when
component is disabled, it also stops and disables the .service unit. Stopping
the service is useful and we can add this to Daemon component.
- Use /run instead of /var/run/ as 1) /var/run is a symlink to /run 2) /run/
path is what is listed in uwsgi-app@.socket unit file.
- Implement upgrade for apps from older version. Disable and mask uwsgi init.d
script. Enable the daemon component if the webserver component is enabled.
- Update manifest files to deal with .socket units instead of 'uwsgi' service.
Backup the /var/lib/private directories as that is actual directory to backup
with DynamicUser=yes.
- For bepasty load the configuration as a systemd provided credential since
DynamicUser=yes.
- Remove the /var/lib/private directories during uninstall.
- Don't create user/group for bepasty as it is not needed with DynamicUser=yes.
Tests:
- Radicale
- Functional tests pass
- Freshly install radicale.
- Web interface works.
- Create and edit calendars
- Path of the storage directory is in /var/lib/private/radicale (after
accessing web interface)
- Permissions on the storage folder and files inside are set to nobody:nobody.
- Uninstall removes the /var/lib/private/radicale directory.
- Create a calender and backup the app. Uninstall the app. Re-install the app.
The calendar is not available. After restoring the backup, the calendar is
available.
- Install radicale without patch and create a calendar. Apply patches and
start plinth.service. Setup is run. UWSGI is disabled and masked. Service is
running. Old calender is visible.
- Install radicale without patch. Disable and apply patches and start
plinth.service. Setup is run. UWSGI is disabled and masked. Service is not
running. Enabling the service works.
- After upgrade, data storage path got migrated to /var/lib/private/radicale.
Old data is accessible.
- After upgrade the directory is still owned by radicale:radicale.
- Freshly install radicale with patch and restore an old backup. The data is
available in the web interface and data was migrated to
/var/lib/private/radicale.
- Bepasty
- Functional tests pass
- Freshly install bepasy.
- Enabling and disabling rapidly works.
- Uploading files works.
- Path of the storage directory is /var/lib/private/bepasty.
- Permissions on the storage folder are as expect 755 but on the parent are
700.
- Permissions on the stored files are 644 and owned by nobody:nobody.
- Uninstall removes the /var/lib/private/bepasty directory.
- Upload a picture and backup the app. Uninstall the app. Re-install the app.
The uploaded file is not available. After restoring the backup, the uploaded
file is available.
- Install bepasty without patch and upload a file. Apply patches and start
plinth.service. Setup is run. UWSGI is disabled and masked. Service is
running. Old uploaded picture is visible.
- Install bepasty without patch. Disable app. Apply patches and start
plinth.service. Setup is run. UWSGI is disabled and masked. Service is not
running. Enabling the service works.
- After upgrade, data storage path got migrated to /var/lib/private/bepasty.
Old data is accessible.
- After upgrade the directory is still owned by bepasty:bepasty.
- Freshly install bepasty with patch and restore an old backup. The uploaded
file is available in the web interface and data was migrated to
/var/lib/private/bepasty.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Helps: #2410.
- Ensure that diagnostics methods and parameters are type checked so that we can
catch any potential issues.
- Move plinth/modules/diagnostics/check.py to plinth/diagnostic_check.py to
avoid many circular dependencies created. This is due to
plinth.modules.diagnostics automatically imported when
plinth.modules.diagnostics.check is imported. Also app.py is already (type)
dependent on diagnostic_check due to diagnose() method. To make the Check
classes independent of diagnostic module is okay.
Tests:
- Run make check-type.
- Run full diagnostics with following apps installed: torproxy, tor.
- Test to netcat to 9051 in tor works.
- Test 'port available for internal/external networks' in firewall works.
- Test 'Package is latest' works.
- Test 'Access url with proxy' in privoxy works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
[jvalleroy: Also move tests for diagnostic_check]
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
- This is useful for managing redis service needed by the upcoming Nextcloud
app.
- Disable the daemon only if all the apps using it are disabled. Enable it when
even one of the them is enabled.
- The component is not a 'leader' component as it does not decide the
enabled/disabled status of the app.
Tests:
- Unit tests pass.
- Install zoph and wordpress with full patch series. If one of the apps is
disabled, mysql service is still enabled and running. If both apps are disabled,
then mysql service is disabled and not running. Enabled/disabled status of apps
are accurate after they are enabled/disabled.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Add reference documentation for the DiagnosticCheck and Result classes]
[sunil: Add link to DiagnosticCheck class from docstring]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Use two separate strategies: one to symlink from /etc to files in /usr/ and
two to copy files from /usr to /etc. The latter is needed for some rare cases
where symlinks don't work because the daemon runs in a chrooted environment.
- Update tutorial and reference sections in developer documentation.
Tests:
- Unit tests works and are comprehensive.
- Using the component in apps works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Automatically handle a setup of the component getting added to an existing
app.
Tests:
- Run unit tests
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- Build HTML and ensure build succeeds that the changes are reflected.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
[sunil: Include the new component reference in the components index]
[sunil: Minor changes to component doc string]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Sunil:
- Add TurnConfiguration to reference documentation. Add more details in
docstrings.
- Rename the component to TurnConsumer since 'Component' in the name is
redundant and unconventional. Also, hopefully, the component will retain the
API over multiple TURN servers.
- Log when notifying other components about configuration change.
- Use TurnConfiguration class more widely.
- Refactor for simplicity.
- Additional tests.
- Move URI generation code into TurnConfiguration.
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- This is completely reworked but based on /Developer page in the FreedomBox
Manual.
- This documentation can be made available as static site on
https://docs.freedombox.org and the /Developer page in the FreedomBox Manual
can be dropped.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
