I introduced this code quality issue when handling a merge conflict in
711c19b511f969d0dce5c36221428e8caa0e7473.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
The latest version of miniflux can't connect to the database after a fresh
installation. This is due to incorrect ownership of /etc/miniflux/database file
which is owned by root (and correctly having the permissions 0600). After
changes in bug #1078416, miniflux no longer runs as root user and instead runs
as miniflux user. This user can't read the database file. The daemon silently
falls back to using built in defaults and fails to connect to PostgreSQL
database. This is originally caught by functional tests in FreedomBox's miniflux
integration.
Links:
1) https://bugs.debian.org/1081562
2) https://salsa.debian.org/go-team/packages/miniflux/-/merge_requests/2
Tests:
- Freshly install miniflux with the patch and the daemon is running. Ownership
for the file /etc/miniflux/database is as expected.
- Install miniflux without the patch. Daemon is not running. Apply patch and
restart service. miniflux app is updated. Daemon is running. Ownership for the
file /etc/miniflux/database is as expected.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
nscd daemon caches queries made to NSS via glibc. In our case queries to passwd
and group databases are cached. But this leads to many problems.
See: https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/2520
The bug that this MR fixes, that is, the inaccuracy of the authentication data,
is horrible and only acceptable if the caching provides very important
functionality. Already, having to purge nscd caches after modifying user
accounts is not nice.
I believe that we have encountered this bug before and blamed libpam-abl due to
the time sensitive nature of the problem.
nscd itself recommends that it should be used if NSS lookup are expensive (such
as in case of NIS, NIS+ queries according to /etc/init.d/nscd). In case of
FreedomBox, LDAP queries are unlikely to be made using network. LDAP server is
likely always local. I believe we can safely remove nscd by masking and stopping
nscd.service and unscd.service.
Tests:
- After applying the patches, users app setup is re-run. Service nscd is stopped
and masked. unscd is also masked.
- Running 'id tester' shows expected value 'uid=10001(tester) gid=100(users)
groups=100(users),10002(admin)'.
- Adding, removing, renaming a user immediately reflects in 'id <user>'.
- Adding and removing a user from groups immediately reflects in 'id <user>'.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Don't delete overwrite.cli.url when the Nextcloud app's settings are
updated with no domain configured. Instead, set it to the default value
of http://localhost/nextcloud
We might want to consider updating existing, faulty setups.
Helps: #2433
Signed-off-by: Benedek Nagy <contact@nbenedek.me>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Fixes an issue where LDAP group membership info is not available long time
after system restart. This can happen when nscd cache is expired and name
service queries are made while nslcd is not yet started. As a result, nscd
group cache contains only local system groups and not LDAP groups. The issue
arises more likely in slow systems where slapd/nslcd startup can take minutes.
Could also depend on how long the device has been shut down before.
Tests performed:
- stop nscd service, start nslcd service, check form the logs that
nscd reload errors are ignored and nslcd service starts successfully.
- Test when nscd group cache is invalidated while nslcd is not running.
Run commands:
```
systemctl reload nscd
id tester
systemctl stop nslcd
nscd -i group
id tester
systemctl start nslcd
id tester
```
Result before patch applied.
```
uid=10001(tester) gid=100(users) groups=10002(admin),100(users)
uid=10001(tester) gid=100(users) groups=100(users)
uid=10001(tester) gid=100(users) groups=100(users)
```
Result after patch applied, tester is in the admins group at the end.
```
uid=10001(tester) gid=100(users) groups=10002(admin),100(users)
uid=10001(tester) gid=100(users) groups=100(users)
uid=10001(tester) gid=100(users) groups=10002(admin),100(users)
```
Signed-off-by: Veiko Aasa <veiko17@disroot.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
This is attempting to fix a test setup issue in Debian CI, see #2450.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Fixes: #2271
When domain name is updated, it usually results in a error page as the HTTP
connection is broken in the middle of a page load. This is due to apache
restarting in the middle of domain change operation by letsencrypt component.
This also leads to several functional tests failing. To fix this, ensure that
letsencrypt does a reload on the apache2 daemon instead of restarting it.
'reload' operation on apache2 triggers the command 'apachectl graceful'. It
ensures that currently running continue to serve the open HTTP connection until
the page load has been completed. After that those connections stop. Meanwhile,
the server reloads configuration (and apparently the related TLS certificates too).
Tests:
- Unit tests pass.
- When self-signed certificate is updated with 'make-ssl-cert
generate-default-snakeoil --force-overwrite' and 'systemctl
try-reload-or-restart apache2' is called, the new certificate is loaded by
apache2. Browser shows the untrusted certificate warning again. The
certificate information in the connection details has been updated.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Reload a service if it supports reloading, otherwise restart. Do nothing if
service is not running.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Likely helps: #2271.
When web server restarts we are shown an error page. Trying to lookup and
element in this error page still raises StaleElementReferenceException. However,
if the page was reloaded with driver.visit(), then trying to lookup the old
element does not throw StaleElementReferenceException. Instead the
NoSuchElementException is thrown. For this case, ensure that we stop waiting
appropriately. This is likely to solve the large waits and timeouts when testing
dynamicdns.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Tests:
- Config app description is as expected.
- Config form does not show domain name field anymore.
- Submitting the form with changes works.
- Names app has correct link for configuring static domain name. Clicking it
takes to page for setting domain name.
- On startup, static domian name signal is sent properly if set. Otherwise no
signal is send.
- Change domain name form shows correct value for current domain name.
- Change domain name form sets the value for domain name properly.
- Page title is correct.
- Validations works.
- Add/remove domain name signals are sent properly.
- Success message as shown expected
- /etc/hosts is updated as expected.
- Unit tests work.
- Functional tests on ejabberd, letsencrypt, matrix, email, jsxc, openvpn
- After freshly starting the service. Visiting names app shows correct list of
domains.
- ejabberd:
- Installs works as expected. Currently set domain_name is setup properly.
Copy certificate happens on proper domain.
- Changing the domain sets the domain properly in ejabberd configuration.
- Ejabberd app page shows link to name services instead of config app.
Clicking works as expected.
- letsencrypt:
- When no domains are configured, the link to 'Configure domains' is to the
names app.
- matrix-synapse:
- Domain name is properly shown in the status.
- email:
- Primary domain name is shows properly in the app page.
- Setting new primary domain works.
- When installing, domain set as static domain name is prioritized as primary
domain.
- jsxc:
- Show the current static domain name in the domain field. BOSH server is
available.
- openvpn:
- Show the current static domain in profile is set otherwise show the current
hostname.
- If domain name is not set, downloaded OpenVPN profile shows hostname.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Config app description is as expected.
- Config form does not show hostname anymore.
- Submitting the form with changes works.
- Names app has correct link for configuring Local Domain Name. Clicking it
takes to page for setting hostname.
- Avahi shows the current .local domain correctly in Names app.
- Change hostname form shows correct value for current hostname.
- Change hostname form sets the value for hostname properly.
- Page title is correct.
- Validations works.
- Pre/post hostname change signals are sent properly
- Success message as shown expected
- hostnamectl shows the set domain
- If domain name is not set, downloaded OpenVPN profile shows hostname.
- Unit tests work.
- Functional tests on names/config/avahi apps work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Closes#2092
On testing and unstable systems, /etc/os-release does not contain
VERSION_ID. In this case, lsb_release will report the release as
"n/a".
For unstable, this means that backports can be enabled in development
mode. When this happens, trixie-backports will be added as an apt
repository. The repository already exists, so it does not cause any
problem.
Tests:
- In stable container, backports can be enabled.
- In stable container, dist-upgrade can be disable and enabled.
- In stable container, in development mode, dist-upgrade can be
started.
- In testing container, backports cannot be enabled.
- In testing container, dist-upgrade cannot be enabled or started.
- In testing container, in development mode, backports can be enabled.
- In testing container, in development mode, dist-upgrade cannot be
started.
- In unstable container, in development mode, backports can be enabled
(as trixie-backports).
- In unstable container, in development mode, dist-upgrade cannot be
started.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil: Merge the case of outdated unstable distributions that return 'unstable'
as release and newer unstable distributions that return 'n/a']
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Closes: #707
Helps: #1570
- Network Manager's 'shared' connections use port 53 on those interfaces. Bind
by default also listens on them if possible. In some corner cases, this could
lead to a clash. This patch fixes to cases by making sure bind does not listen
on IP address likely used by Network Manager's 'shared' connections. If user
custom configures address, they will need to update the bind configuration
accordingly.
- App version increment is not necessary because in this release cycle we have
already incremented it once.
Tests:
- Install without patch. Increment the app version number (and the version
number in the privileged script). Notice that bind app setup is run again.
'listen-on' line is inserted into the configuration file as expected.
- Increment the version numbers again and a second 'listen-on' line is not
inserted.
- Without patch, on a machine with two network interfaces, start a 'shared'
network connection. Start bind. Notice the error that bind could not listen on
the shared network IP address.
- Without patch, on a machine with two network interface, start bind while
'shared' network connection is configured with just the IP address. Start bind
and it will listening on the IP address with shared network IP address.
Configure a shared connection and it fails to start.
- Apply the patch. Start 'shared' network connection. Start bind and notice that
bind does not attempt to listen on that shared network IP address and does not
print error message as well.
- Apply the patch. Start bind while 'shared' network connection is configured
with just the IP address. Bind does not attempt to listen on that shared network
IP address. Start the shared network connection. It start without issues.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- In create/edit network connection form, if the accordion is closed for
'General' section, Network Interface has not be selected yet and Submit button
is pressed, 'General' section should be expanded and focus should go to Network
Interface field. This is not working as expected as the code to expand
accordions didn't match 'select' type input fields properly. Fix this.
- Declare a common class name for both create and edit forms to make writing
queries easier.
- Drop console logs that where meant for debugging.
Tests:
- On both create and edit connection forms, set the value of network interface
to '--select--' and collapse the 'General' section. Press submit. The 'General'
section is expanded, Network Interface field is focus and scrolled into view.
- Do the same check for another field such as Connection Name and that works
too.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
This improves the user experience in many ways:
- Help user understand if DNSSEC is being used on the current DNS server in case
'allow-fallback' is supported.
- Nudges the user to explore enabling DNS-over-TLS and DNSSEC.
- Help user understand how global vs. link specific configuration works. Help
user understand if a global DNS is being used.
- Show the list of fallback DNS servers being used (as this poses privacy
concerns).
Also helps with debugging in problematic situations:
- Find out which DNS server is being used (and leading to problems) and show the
cycling mechanism.
Tests:
- Enable/disable fallback DNS server in privacy app. See that fallback servers
line is only shown when enabled.
- Set various global values of DNS-over-TLS and DNSSEC and see the status
changes.
- Set various values of DNS-over-TLS in the network connection settings and see
the changes in status.
- Set DNSSEC to allow-fallback. Perform a query and see that the value of
supported/unsupported changes.
- Set DNS servers with special configuration file in
/etc/systemd/resolved.conf.d/test.conf and restart systemd-resolved. See change
in status page. Notice that if connection specific DNS server is set to an
invalid server, global section has a current DNS server.
- Set SNI domain name and port for the an IPv4 DNS and an IPv6 DNS. See that the
display is as expected.
- Raise an exception in get_status() and notice that an error alert is show
properly.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewd-by: Veiko Aasa <veiko17@disroot.org>
Pass remaining failed checks to super.
Tests:
- Remove /etc/letsencrypt/renewal-hooks/deploy/50-freedombox so that
the diagnostic fails. Running repair causes the file to be
re-created.
- Set domain name to non-existing domain so that the diagnostic
fails. Running repair attempts to obtain the certificate.
- Have both diagnostics failing. Running repair will attempt to repair
both.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
So that when users select 'Default' they understand what value applies and how
to change it.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Reloading systemd-resolved does not seem to apply the DNS-over-TLS changes
fully. Although resolvectl shows the new status after a reload, systemd-resolved
seems to be using incorrect DNS-over-TLS setting.
Tests:
- Without the patch, set DNS server that does not support DNS-over-TLS such as
dnsmasq in Network Manager's 'shared' connection. Then enable DNS-over-TLS.
resolvectl shows that DNSOverTLS flag correctly. But name resolutions still
work.
- With the patch, repeat the above and notice that resolution does not work.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Use deb.debian.org because it is already contacted regularly for
checking/downloading packages and updates.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Visit the names app. New 'Domains' heading and configuration section appear.
- DNS-over-TLS configuration option is as expected.
- When the configuration file does not exist, the option selected is 'no'.
- When the configuration option is changed, 'resolvectl' shows the newly set
configuration. Using 'resolvectl query {domain}' does not work when DoT is on
and server does not support DoT. 'opportunistic' and 'no' work on those cases.
- When a DNS server supporting DoT (such as 1.1.1.1) is manually set, resolution
with all three settings works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Without selecting an option, trying to submit the form leads to an error.
Tests:
- Go to the new connection form, notice that the 'auto' method is selected by
default.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- If an existing network manager connection with the missing values is ever
edited, it leads an awkward interface.
- So, complete the setting by allowing values supported by Network Manager.
Tests:
- Create new connections with the new values 'link-local' and 'disabled'.
Connection creation succeeds.
- Editing connection to these values works too.
- When 'link-local' or 'disabled' values are selected, primary and secondary DNS
fields are disabled.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Expose Network Manager per-connection setting for DNS-over-TLS. Support all
four values: default, no, opportunistic, and yes.
- Create a new collapsible section all 'Privacy' for this setting the connection
create/edit form. Strictly speaking this is related to security and censorship
resistance too.
- Don't show the DoT field for PPPoE connection types are DNS servers are not
relevant.
- Show the status of DoT for a connection in the connection status page.
Tests:
- In all Add New Connection forms except PPPoE form, the privacy
section shows up as expected.
- For each value for DoT, create a new connection and set the value for DoT to the
desired value and observe that the connection status page shows DoT to the set
value.
- For each value for DoT, edit an existing connection and set the value for the
DoT to the desired value and observe that the connection status page shows DoT
to the set value.
- Connection status page shows the values for DoT as expected.
- Update the primary Internet connection for the machine. Set the value to 'yes'
and notice that DNS resolutions fail. Set the value to 'opportunistic' or 'no'
and the DNS resolutions pass. In each case, 'resolvectl' shows the correct DoT
value for the connection. When 1.1.1.1 is set as DNS server, all values of DoT
in the connection succeed.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Package holds are only expected when apps are being installed or
uninstalled, or during distribution upgrade process. At any other
time, package holds are not expected and should be released.
Tests:
- Place a hold on one package. Run the upgrades diagnostics, which
will have a failure. Try to repair the failure, and confirm that the
package is no longer held.
- Repeat with two or three packages being held.
[sunil]
- When the package 'needsrestart' is outdated and another package is held,
running repair unholds the package as well as runs setup() on the upgrades app
leading to 'needsrestart' package getting upgrade.
- When only failed diagnostic is for package holds. Running repair unholds the
packages but does not rung setup().
Helps: #2347
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Fixes: #2432
Tests:
- Without patch install MediaWiki. phpinfo() shows max execution time for 30
seconds. Apply patch, run 'make install' and restart service. Mediawiki app is
updated. Apache2 is reloaded. phpinfo() shows max execution time for 100
seconds.
- Create a script to 100% utilize the CPU for 90 seconds. It works.
- Create a script to 100% utilize the CPU for 110 seconds. It fails and get
killed after about 100 seconds.
Signed-off-by: Joseph Nuthalapati <njoseph@riseup.net>
Tested-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- If provision fails and the container is in running state, then running
'./container up' does not lead to re-run of provisioning script. Fix this.
Tests:
- Without patch, insert 'exit 1' in provisioning script. Run './container
destroy; ./container up'. Provision script will fail. Re-run './container up'.
Provision script is not run and message that container is already running is
printed.
- With patch, insert 'exit 1' in provisioning script. Run './container destroy;
./container up'. Provision script will fail. Re-run './container up'. Provision
script is not run and message that container is already running is printed.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Closes: #1196.
- systemd-resolved always contains the current list of known DNS servers taken
from systemd-networkd, network-manager, or by other means. It also has fallback
DNS servers. Forwarding requests to it allows correct and failsafe way to reach
external DNS servers.
Tests:
- Freshly install bind and notice that the fowarders list is set to 127.0.0.53.
- Install without the patch. Apply patch. Restart service. bind is upgraded to
new version and forwarder is set to 127.0.0.53 if it is blank. Otherwise, it
remains as is.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
Tests:
- Without patch, disable bind. Incrementing the app's version number results in
bind getting started.
- With patch, disable bind. Incrementing the app's version number does not
result in bind getting started.
- Without patch, disable bind. Update forwarders. Bind is running again.
- With patch, disable bind. Update forwarders. Bind is not running again.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- Before this change, when bind is disabled, dns port is removed from firewall
causing all 'shared' connection to not be able to resolve domains. This was
because no other application was declaring a need for 'dns' port to be kept
open. Declare a firewall component in the networks app needing 'dns' and 'dhcp'
services on the internal networks.
Tests:
- Without the patch, install and disable bind. 'dns' port is removed from
'internal' zone of the firewall.
- Install and disable bind. 'dns' port is not removed from 'internal' zone of
the firewall.
- On a fresh Debian machine. Install the freedombox package. 'http', 'https',
'dns' and 'dhcp' port are opened on the firewall as expected.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
- To complete the provisioning process with container script and vagrant.
Tests:
- Start a fresh testing container, it should succeed. systemd-resolved is
running and resolving queries.
- Start a fresh stable container, it should succeed. systemd-resolved is running
and resolving queries.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
