Tests:
- When arguments are not provided to freedombox-cmd it shows errors on the
console.
- When a command is successfully executed, the output is printed on the console.
- The output of the privileged daemon goes to the journald.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Upto 200 lines are shown in the logs. The description and unit name of the app
is correct.
- Apps without systemd units don't have 'View Logs' menu item.
- Nextcloud container logs are shown.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- This prevents double logging for all log statements in privileged daemon.
- Also drop conditional checking for systemd.journal python module. We hard
depend on python3-systemd package which has it.
Tests:
- All logs messages from privileged daemon log only once to the journal.
- For main service, the log message happens on console only when running on the
command line. When the systemd service is started, it is only logged to the
journal.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Joseph Nuthalapati <njoseph@riseup.net>
This would be better for collecting the stderr of the action and logging it
again.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Add explicit dependency on django-ipware >=3. django-axes >= 6 adds
only and optional dependency on django-ipware. Adding explicit dependency make
the behavior safer.
- Depend on django-axes >= 5 where the authentication backend and other features
are available. The new code won't work with older versions. The new approach
uses and authentication backend to deny access to the login form on lockout and
a middleware to redirect user to locked out form when limit of attempts have
been reached.
- Drop old code used for compatibility with django-axes 3.x.
- Suppress verbose and debug messages as django-axes is too chatty.
- Re-implment the CAPTCHA form entirely. In the old style, we have a login form
with CAPTCHA field. That would not work with the new django-axes authentication
middle. On submission of the form, auth.authenticate() will be called. This
call invokes various authentication backends include django-axes authentication
backend. This backend's behavior is to reject all authentication attempts when
the IP is listed in locked table. The new approach is to provide a simple
CAPTCHA form with just the CAPTCHA field. If the form is successfully
validated (correct CAPTCHA is provided), then the lock on the IP address is
reset. The user is then free to perform 3 more attempts to login.
- Update firstboot form to send the request parameter when using
auth.authenticate() method. This needed by Django axes' authentication method
which will be triggered.
Tests:
- Run tests on Debian Bookworm and Debian testing.
- Axes verbose messages and debug messages are not printed on the console when
running FreedomBox in debug mode.
- Only three invalid attempts are allowed at the login page. After the final
incorrect attempt, user is redirected to CAPTCHA page. Visiting the login page
using the URL works but entering the correct credentials still takes the user to
CAPTCHA page.
- CAPTCHA form appears as expected. Clicking the CAPTCHA images downloads the
audio file corresponding to the image. Incorrect CAPTCHA shows an error. Correct
CAPTCHA takes the user to login form where they are able to login with correct
credentials. Entering incorrect credentials 3 times will take the user again to
CAPTCHA page.
- Creating user account during firstboot works.
- Blocked IP address the IP of the client such as 10.42.0.1 and not the local IP
address 127.0.0.1 according the django-axes log messages. While one client IP
address is blocked, another IP is able to login to the same user account that
was attempted by the blocked client.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Syslog is not used on FreedomBox machines. Logging to syslog instead of
journald looses a lot of information fields that are otherwise available.
- Drop logging additional information. Most of the information is already
present in full journald records. Access using journalctl -o json.
- Use the same formatting for console as the primary daemon.
- When logging for actions, capture warnings too.
- Always log to stderr so that UI can capture the traceback and show UI error
messages. stderr is never used for returning data.
Tests:
- Run action script using command line with a error 'sudo actions/email_server
home mk a b'. See the traceback message printed on stderr (not stdout). Message
is printed with full field information in journalctl -o json.
- Main daemon writes to stderr and to journal with same formatting as before.
- Adding a warning in action code or main daemon results in printing of the
warning with desired formatting. import warnings; warnings.warn('Foo warning')
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
