10 Commits

Author SHA1 Message Date
Sunil Mohan Adapa
61ff15a04f
*: Use action_utils.run instead of subprocess.run
- This is to capture stdout and stderr and transmit that from privileged daemon
back to the service to be displayed in HTML.

Tests:

- Unit tests and code checks pass.

- Some of the modified actions work as expected.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
2025-09-29 16:58:53 +03:00
Sunil Mohan Adapa
5a9d5730a7
names: Store domains in kvstore instead of /etc/hosts
As reported in discussion forum[1], when clients connected via 'shared' network
connection try to resolve the a static domain name configured in FreedomBox,
they resolve to 127.0.1.1. Since this refers to client's own IP address, they
fail to connect.

In the previous version, this was not a problem because the entry was stored as
<hostname>.<domainname>. To resolve this, store domain names in kvstore instead
of /etc/hosts.

Links:

1)
https://discuss.freedombox.org/t/freedombox-resolves-its-own-external-name-as-127-0-1-1/3660

Tests:

- Adding/removing static domains from Names app works. The order of added
domains is preserved in the stored configuration. When adding a existing domain,
a proper error message is shown.

- Without the patch, configure multiple domains. They show up in /etc/hosts.
Apply the patches and restart the service. Names app setup will run. Entries
from /etc/hosts are removed and will be added to kvstore. The list of domains
shows properly in Names app. After restarting the services, domains are show
properly.

- Without the patch on a version of FreedomBox without support for multiple
static domains, configure a static domain. Switch to latest version FreedomBox
with the patches. Restart the service. Names app setup will run. Entry from
/etc/hosts will be removed and will be added to kvstore. The list of domains
shows properly in Names app. After restarting the services, domains are show
properly.

Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
2025-03-21 16:01:41 -04:00
Sunil Mohan Adapa
863d170219
names: Allow adding multiple static domain names
- Change the mechanism for storing domain names in /etc/hosts. Don't write
hostname to /etc/hosts. Don't prepend hostname to domain name. This means that
when hostname changes, set_domain_name need not be called.

- This means that domain names such as example.fbx.one were not resolvable using
/etc/hosts but these will now resolve to 127.0.1.1. This is a minor concern to
becoming a breaking change.

- Don't use socket.getfqdn() for finding the domain name of the machine. Instead
read from /etc/hosts. There does not seem to a glibc/python API for querying
domain names from /etc/hosts with all variations it allows. Forward resolution
properly works no matter the library.

- Drop a pre-Python 3 conversion from unicode to ascii string for hostname. This
is no longer relevant.

- Domain name form is now domain add form. Passing domain name is mandatory.
Domain delete form and view have been introduced.

- Use augeas to edit hosts file. Add privileged methods to add/delete/get
domains. Add method to migration from old format to new. Support reading old
format too in get_domains.

Tests:

- Without hostname written in /etc/hosts, 'resolvectl query <hostname>' and
'ping <hostname>' work.

- With old /etc/hosts format apply patches and restart service. It will be
converted to new format.

- Adding a domain adds a new line to /etc/hosts file. The domain is shown in
domains list in Names app. Applications get reconfigured with the new domain
name.

- Deleting a domain adds a new line to /etc/hosts file. The domain is shown in
domains list in Names app. Applications get reconfigured with the new domain
name.

- Restarting app triggers domain added signal for all domains and all the
domains are shown in the Names app.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
2025-02-16 10:44:50 -05:00
Sunil Mohan Adapa
7e8819d7d5
names: Try to install systemd-resolved during app setup
- If installing systemd-resolved for the first time, set fallback DNS setting to
True irrespective of the app version.

Tests:

- Ensure that systemd-resolved is not installed. On a fresh systemd without
first setup done, run service.

- Names app setup is run and systemd-resolved is installed if internet
connection is available. Setup succeeds. Fallback DNS setting is true in privacy
app. systemd-resolved has been restarted and current DNS known to Network
Manager has been populated in it. Name resolution works.

- If Internet connection is not available, setup still succeeds but
systemd-resolved package is not installed.

- Rerun setup without internet connectivity. Setup succeeds without installing
systemd-resolved.

- Rerun setup with internet connectivity. Setup succeeds and installs
systemd-resolved. Fallback DNS setting is true in privacy app. systemd-resolved
has been restarted and current DNS known to Network Manager has been populated
in it. Name resolution works.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
2024-10-07 01:34:37 +03:00
Sunil Mohan Adapa
9009cdafd6
config, names: Move domain name configuration to names app
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>
2024-09-19 13:43:32 +03:00
Sunil Mohan Adapa
8c69858d43
config, names: Move setting hostname from config to names
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>
2024-09-19 13:42:47 +03:00
Sunil Mohan Adapa
ffa628c4e4
names: Add option for setting global DNSSEC preference
Closes: #603.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
2024-09-07 12:25:03 +03:00
Sunil Mohan Adapa
6062b9ef85
names: Restart instead of reload for systemd-resolved changes
- 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>
2024-09-07 12:24:41 +03:00
Sunil Mohan Adapa
a124681083
names: Add option for setting global DNS-over-TLS preference
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>
2024-09-07 12:23:52 +03:00
Sunil Mohan Adapa
0817e7af45
names: Use systemd-resolved for DNS resolution
- Disable mDNS resolution. While we can migrate our DNS-SD service definition
files to systemd-resolved and switch from using avahi to systemd-resolved, many
programs still solely depend on avahi-daemon. Examples include cups and GNOME.
It is not clear if they will work any mDNS daemon or if they interact with
avahi-daemon in other ways that the mDNS protocol. So, for now, disable mDNS in
systemd-resolved and continue to use avahi-daemon for it. This is also Fedora's
default.

- Re-introduce Fallback DNS servers with the value same as the upstream systemd
project. Debian removes the default fallback DNS servers likely because they
could be considered a privacy violation. However, when systemd-resolved package
is first installed, the post install script recommends a reboot instead of
feeding the currently configured nameservers from /etc/resolve.conf into
systemd-resolved. Immediately, this causes the system not be able to connect to
any external servers. While this may be acceptable solution for interactive
systems and pre-built images, FreedomBox has to a) be available for remote
access b) perform upgrades without user intervention (and without reboot until a
day). To mitigate privacy concerns, an option to disable these fallback servers
will be provided in the UI.

- systemd-resolved's stub resolver runs on 127.0.0.53%lo:53 and 127.0.0.54. This
does not conflict either with shared connections which listen on 10.42.x.1 or
with bind which listens on 127.0.0.1 (and other IP addresses). This MR does not
address the existing conflict between bind and shared network connections.
However, it does not cause any further conflicts.

Tests:

* mDNS

- Avahi diagnostics works. daemon is running. mdns port is exposed in the
firewall.

- systemd-resolved does not listen on mDNS ports.

- Running avahi-browse shows freedombox on local network.

- Running avahi-browse shows the services ssh, sftp-ssh, http and ejabberd.

- Machine can be discovered in Gnome Files.

* NetworkManager shared connections

- After install/upgrade to systemd-resolved, 'shared' connections can be
created.

- With a 'shared' connection configured and active, it is possible to upgrade to
using systemd-resolved.

- Resolving domains from a machine on shared network goes via systemd-resolved
on FreedomBox.

* Bind

- Installing, running tests on bind works.

- Programs connecting from outside network can connect to bind as expected.

- Programs connecting from local machine can connect to bind as expected.

* Upgrading works

- Upgrading to new FreedomBox package works

- systemd-resolved is installed and running. 'resolvectl' shows a proper name
server (or fallback nameserver like 1.1.1.1).

- libnss-resolve is installed and configured in /etc/nsswitch.conf

- /etc/resolv.conf has proper link to /run/systemd/resolve/stub-resolv.conf.

- Programs using /etc/resolv.conf directly work. Install python3-pycares.
python3 -m pycares freedombox.org.

- NetworkManager has passed on proper DNS entries. In logs dns=systemd-resolved,
rc-manager=unmanaged, plugin=systemd-resolved

- DNS resolution works after first setup. Installing packages works.

- 'resolvectl query' resolution works.

- Programs using glibc API resolution such as 'ping' work.

* Fresh image

- Building an image with new freedombox package works without error.

- Booting from fresh images works.

- systemd-resolved is installed and running. 'resolvectl' show proper name
server.

- libnss-resolve is installed and configured in /etc/nsswitch.conf

- /etc/resolv.conf has proper link to /run/systemd/resolve/stub-resolv.conf

- Programs using /etc/resolv.conf directly work. Install python3-pycares.
python3 -m pycares wikipedia.org

- NetworkManager has passed on proper DNS entries. In logs dns=systemd-resolved,
rc-manager=unmanaged, plugin=systemd-resolved

- DNS resolution works after first setup. Installing packages works.

* Installing package on Debian

- Installing new freedombox package in Debian machine works.

- systemd-resolved is installed and running.

- libnss-resolve is installed and configured.

- /etc/resolv.conf has proper link to /run

- NetworkManager has passed on proper DNS entries to systemd-resolved using
'nmcli reload dns-rc'.

- Resolution works with fallback DNS servers when network interfaces are
configured with /etc/network/interfaces

* OpenVPNs works

- As a server, we don't push DNS servers to the client. So, a client continues
to use its old DNS servers. With systemd-resolved running on server, the client
is able to connect to OpenVPN server, route traffic to the internet, and resolve
DNS queries.

* WireGuard works

- As a server, we can't push DNS servers to the client. So, a client continues
to use its old DNS servers. With systemd-resolved running on server, the client
is able to connect to WireGuard server, route traffic to the internet, and
resolve DNS queries.

- As a client, server does not push DNS servers to the client. So, a client
continues to use its old DNS servers. With systemd-resolved running on the
client, the client is able to connect to WireGuard server, route traffic to the
internet, and resolve DNS queries.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
2024-09-04 10:28:47 +03:00