Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on non-local/non-private causes connection attempt

[anthony_ful...@trendmicro.com]

I tried this on a fresh installation of Fedora Workstation 39. I installed 
wireshark and set the filter to `tcp.port == 5355` then ran the python script 
again with an ip of `123.123.123.123` and I see an outbound connection attempt 
to IP 123.123.123.123 on port 5355.

Hope that helps,
Anthony

From: Anthony Fuller (TR-NA) 
Date: Friday, February 23, 2024 at 10:22 AM
To: Cristian Rodríguez 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on 
non-local/non-private causes connection attempt
Hi Cristian,

Below is my complete /etc/nsswitch.conf file.

Have you tried any other IP addresses by chance? I noticed that some IPs do not 
exhibit this behavior such as 1.1.1.1 and 8.8.8.8.

I’m also willing to see if this behavior exists outside Debian, maybe it’s a 
default Debian configuration causing this.

Thanks,
Anthony

```
user@debian12:~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files systemd
group:  files systemd
shadow: files systemd
gshadow:files systemd

hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis
```

From: Cristian Rodríguez 
Date: Friday, February 23, 2024 at 10:07 AM
To: Anthony Fuller (TR-NA) 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on 
non-local/non-private causes connection attempt

This message was sent from outside of Trend Micro. Please do not click links or 
open attachments unless you recognise the source of this email and know the 
content is safe.


On Thu, Feb 22, 2024 at 8:13 PM anthony_ful...@trendmicro.com
 wrote:


I tried again now with packet capture software and no such behaviour
was found. ..what you have in the hosts line of nsswitch.conf ?

TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential and 
may be subject to copyright or other intellectual property protection. If you 
are not the intended recipient, you are not authorized to use or disclose this 
information, and we request that you notify us by reply mail or telephone and 
delete the original message from your mail system.

For details about what personal information we collect and why, please see our 
Privacy Notice on our website at: Read privacy 
policy

Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on non-local/non-private causes connection attempt

[anthony_ful...@trendmicro.com]

Hi Cristian,

Below is my complete /etc/nsswitch.conf file.

Have you tried any other IP addresses by chance? I noticed that some IPs do not 
exhibit this behavior such as 1.1.1.1 and 8.8.8.8.

I’m also willing to see if this behavior exists outside Debian, maybe it’s a 
default Debian configuration causing this.

Thanks,
Anthony

```
user@debian12:~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files systemd
group:  files systemd
shadow: files systemd
gshadow:files systemd

hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis
```

From: Cristian Rodríguez 
Date: Friday, February 23, 2024 at 10:07 AM
To: Anthony Fuller (TR-NA) 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on 
non-local/non-private causes connection attempt

This message was sent from outside of Trend Micro. Please do not click links or 
open attachments unless you recognise the source of this email and know the 
content is safe.


On Thu, Feb 22, 2024 at 8:13 PM anthony_ful...@trendmicro.com
 wrote:


I tried again now with packet capture software and no such behaviour
was found. ..what you have in the hosts line of nsswitch.conf ?

TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential and 
may be subject to copyright or other intellectual property protection. If you 
are not the intended recipient, you are not authorized to use or disclose this 
information, and we request that you notify us by reply mail or telephone and 
delete the original message from your mail system.

For details about what personal information we collect and why, please see our 
Privacy Notice on our website at: Read privacy 
policy

Re: [systemd-devel] Systems-resolved: Calling gethostbyaddr on non-local/non-private causes connection attempt

[Cristian Rodríguez]

On Thu, Feb 22, 2024 at 8:13 PM anthony_ful...@trendmicro.com
 wrote:


I tried again now with packet capture software and no such behaviour
was found. ..what you have in the hosts line of nsswitch.conf ?

Re: [systemd-devel] Wireguard routes only after connect

[Andrei Borzenkov]

On 14.02.2024 11:55, Julian Zielke wrote:

Hi,

is there a possibility to only add the routes from allowed-ips to the kernel 
routing table after the peer has connected?


This directly contradicts your next statement


Because since the tunnel itself is stateless, there is no way for me to make 
use of OSPF to route packets to a selective server running a tunnel to the same 
endpoint (for loadbalancing and multi-wan reasons).



As you write yourself, WireGuard protocol is stateless, there is no 
connection at all. The closest thing to the "connection" is successful 
handshake which runs periodically. There does not appear to be any 
notification when it happens, so at most one could poll wireguard 
interface for the "last handshake time" and assume "connection loss" if 
it has not been updated for long enough. I do not think anything like 
this is currently implemented.

Re: [systemd-devel] Can I provide separate enabling for dbus-activation and "normal" start ?

[Max Gautier]

On Fri, Feb 23, 2024 at 10:19:12AM +0100, Lennart Poettering wrote:
> On Do, 22.02.24 17:09, Max Gautier (m...@max.gautier.name) wrote:
> 
> > Is it possible when writing a dbus-activable service to provide two
> > separate and independent ways to enable it ?
> >
> > The D-Bus service file would for instance be:
> > [D-BUS Service]
> > Name=org.freedesktop.Notifications
> > Exec=notification-daemon
> > SystemdService=dbus-org.freedesktop.Notifications.service
> >
> > The systemd service:
> > [Unit]
> > PartOf=graphical-session.target
> > After=graphical-session.target
> >
> > [Service]
> > Type=dbus
> > BusName=org.freedesktop.Notifications
> > ExecStart=notification-daemon
> >
> > [Install]
> > Alias=dbus-org.freedesktop.Notifications.service
> > WantedBy=graphical-session.target
> >
> >
> > With that systemd service file, `systemctl enable` would cause the
> > service to be started by graphical-session.target and by
> > dbus-activation; but it is possible to have two separate enable
> > commands, one which would enable the dbus activation, one the
> > graphical-session start ?
> >
> > I suppose I should have two separate unit files but I'm not completely
> > sure how to do that without copying the whole file (i.e, is there some
> > Install/Unit relation I can use for that ?)
> 
> No, in systemd there's only one "systemctl enable" and it applies the
> [Install] section of the unit file, and that's really all there is.
> 
> You can probably add two unit files and use Alias= so that they pick a
> common name as alias.

I guess I'll end up doing that. Thanks for the confirmation then

> 
> But one unit cannot have two distinct [Install] sections, if that's
> what you are looking for.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

-- 
Max Gautier

Re: [systemd-devel] Can I provide separate enabling for dbus-activation and "normal" start ?

[Lennart Poettering]

On Do, 22.02.24 17:09, Max Gautier (m...@max.gautier.name) wrote:

> Is it possible when writing a dbus-activable service to provide two
> separate and independent ways to enable it ?
>
> The D-Bus service file would for instance be:
> [D-BUS Service]
> Name=org.freedesktop.Notifications
> Exec=notification-daemon
> SystemdService=dbus-org.freedesktop.Notifications.service
>
> The systemd service:
> [Unit]
> PartOf=graphical-session.target
> After=graphical-session.target
>
> [Service]
> Type=dbus
> BusName=org.freedesktop.Notifications
> ExecStart=notification-daemon
>
> [Install]
> Alias=dbus-org.freedesktop.Notifications.service
> WantedBy=graphical-session.target
>
>
> With that systemd service file, `systemctl enable` would cause the
> service to be started by graphical-session.target and by
> dbus-activation; but it is possible to have two separate enable
> commands, one which would enable the dbus activation, one the
> graphical-session start ?
>
> I suppose I should have two separate unit files but I'm not completely
> sure how to do that without copying the whole file (i.e, is there some
> Install/Unit relation I can use for that ?)

No, in systemd there's only one "systemctl enable" and it applies the
[Install] section of the unit file, and that's really all there is.

You can probably add two unit files and use Alias= so that they pick a
common name as alias.

But one unit cannot have two distinct [Install] sections, if that's
what you are looking for.

Lennart

--
Lennart Poettering, Berlin