[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>
* If only the SETTINGS_FILE gets removed, the setup
process fails afterwards
* Don't remove the public access file since the setup process
will remove it anyway
Test: Functional tests passed
Signed-off-by: nbenedek <contact@nbenedek.me>
[sunil: Update docstrings, make uninstall fail-safe]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
When the security access restrictions are removed from /etc/security/access.d,
we don't want users to bypass Apache access control and directly access the app.
Tests:
- Without the patch, the uwsgi socket file is with permissions 666 in
/run/uwsgi/apps/searx/socket. nc -U <socket> succeeds as non-admin user on the
system.
- Apply the patch and restart FreedomBox. searx set is run and uwsgi service is
restarted and permissions are 660 on /run/uwsgi/apps/searx/socket. nc -U
<socket> fails as non-admin user on the system.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- Functional tests work
- Initial setup works
- UWSGI configuration is created and daemon is running.
- Enabling and disabling public access works. Public access file is
created/removed. App page shows current value. If exception is raised, error
is shown properly.
- Setting safe search to all three values works. Configuration file is updated
properly. App page shows current value properly. If exception is raised, error
is shown properly.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
