5 ms·

What do you mean it talks to the network? Can you give some reference?

by revanx_ 6y ago

dijit 6y ago
Socket activation (by its very nature) is systemd listening to the network on your programs behalf. If nothing else.
- revanx_ 6y ago
  I see, I've heard about it but I couldn't find any reference that systemd starts listening on sockets before the firewall service is started. Even if it did, with systemd you can setup your firewall service to start before the eth link goes up.
  - corty 6y ago
    You can't typically start the firewall before the eth link goes up, since rules that contain network interfaces might not work before those are created (e.g. in case of bridge or bonding interfaces). Systemd's "start everything at once, let the dependencies sort out automatically" is a major regression for server systems. With sysv-init you could just pick the right ordering and be done, everything was stable for every boot after that.
    - genghizkhan 6y ago
      You can, using the directives "Wants=network-pre.target" & "Before=network-pre.target". This will make sure the service is up before any network interface is configured. Source: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ https://www.freedesktop.org/wiki/Software/systemd/NetworkTar...
      - corty 6y ago
        Not quite. First, this doesn't apply to any interfaces that are created by system services like VPN tunnels. Second, you would usually want and need network-online.target, because firewall config often is applied after network-pre only. Third, dynamic stuff like VLAN interfaces also only appear after network-pre and often only after network-online. So no cookies for you. This kind of non-attention to details is actually what makes systemd bad: Everything looks like the authors laptop, if it doesn't, tough luck.
        genghizkhan 6y ago
        Edit: Sorry, I just realised what you mean. I don't know about iptables, but I've got nftables set to come up before the network is set up and it works perfectly fine without enp3s0 or wg0 having come up. The rules are set and then the interfaces come up. Original comment follows: I'm... not sure I understand. VPNs would only work after your physical interfaces are up, right? So if you want your firewall rules to be applied before a VPN interface comes up then you'd be perfectly fine with network-pre. From the page I linked in the comment you replied to: "network-pre.target is a target that may be used to order services before any network interface is configured. Its primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up. It's a passive unit: you cannot start it directly and it is not pulled in by the the network management service, but by the service that wants to run before it. Network management services hence should set After=network-pre.target, but avoid any Wants=network-pre.target or even Requires=network-pre.target. Services that want to be run before the network is configured should place Before=network-pre.target and also set Wants=network-pre.target to pull it in. This way, unless there's actually a service that needs to be ordered before the network is up the target is not pulled in, hence avoiding any unnecessary synchronization point." So ideally you'd run your VPN service after network-online.target has been reached, which would certainly be after the firewall rules have been applied. The great thing about persistent interface names is that if you know the names of the interfaces which are going to be coming up, then you can set up a firewall before any of them come up. Which takes care of dynamic VLAN interfaces. You can use IP addresses or blocks to refer to them in your firewall config, am I right? If you think I'm unable to grasp your situation, can you give me a more detailed example?
    - revanx_ 6y ago
      iptables and nftables both have ways to declare rules for interfaces that come and go. Identifying dynamic interfaces is done by string comparison instead of by index (for static interfaces).
      - corty 6y ago
        Which doesn't always help you if you are actually using one of the make-firewalling-easier-daemons (which I personally would advise against). Those often only support very basic features, but are pushed heavily by the commercial distros.
    - fao_ 6y ago
      > Systemd's "start everything at once, let the dependencies sort out automatically" is a major regression for server systems. With sysv-init you could just pick the right ordering and be done, everything was stable for every boot after that. This is a big point. All of the systemd systems I've been exposed to in the wild have non-deterministic inits, i.e. if it takes longer than average to boot up once (A problem I had a few times), starting it again doesn't replicate said problem. If the network craps itself when booting sometimes, that problem is variable so it's impossible to tell if you've fixed the problem, and it was what you suspected, or if it's something else and you only think that you've fixed it. On the other hand, my alpine system consistently boots up. If it errors once, it will error consistently enough to allow tracing of the cause, but regardless, it has never had a problem on boot.
sliken 6y ago
Sure, try https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd By default systemd includes journald, rather controversial (and mentioned in a comment on this thread) picked binary logging (harder for humans) and much less robust in the face of a small corruption, and ignored encryption. I believe it doesn't support encryption (by default). This replaces more robust solutions (by default) like syslog-ng and rsyslog that have long histories of battle tested real world usage. resolved replaces the local DNS resolvers, and at least for awhile ignored DNSSEC. This is particularly bothersome since it is such a security sensitive daemon. Sure you can disable it and pick unbound, but it's not default. timesyncd is a time daemon, replacing NTP, another security sensitive app. Not that NTP is a paragon of security, but various projects have arisen to improve things. networkd is a replacement for DHCP and similar for IPv6. Again not nearly as nice or secure as existing solutions. So basically decades of developer work, security audits, and competition among network services had been ditched and is now part of systemd and a typically cavalier attitude towards security. There are good parts of systemd, it filled a need. But this swallowing of security sensitive network services really bugs me. Being able to be compromised so early in the process and the tight integration going against the idea the unix philosophy of using minimalist modular software. Normally I'd run unbound as a non-root user with access to read few directories, and write to even fewer, DNSSEC enabled, and logging via syslog (human readable). By default on an ubuntu 20.04 (and 18.04 before that) I'd have issues with dns failures... till I replaced the systemd resolver. I'd mention it to other admins and they would shrug and mention that systemd sucks.
- revanx_ 6y ago
  thank you for the follow up. You have made some good points but I couldn't find any explanation to what you said : systemd talking to the network before I even have the client firewall up.
- viraptor 6y ago
  Worth noting that these are optional. You can forward logs to your preferred syslog daemon. You can turn off resolved, timesyncd, networkd and use something else instead of them. It's not ideal when looking at the whole environment, but specifically for our services - we've got the choice.

What do you mean it talks to the network? Can you give some reference?

dijit 6y ago

Socket activation (by its very nature) is systemd listening to the network on your programs behalf. If nothing else.

revanx_ 6y ago
I see, I've heard about it but I couldn't find any reference that systemd starts listening on sockets before the firewall service is started. Even if it did, with systemd you can setup your firewall service to start before the eth link goes up.
- corty 6y ago
  You can't typically start the firewall before the eth link goes up, since rules that contain network interfaces might not work before those are created (e.g. in case of bridge or bonding interfaces). Systemd's "start everything at once, let the dependencies sort out automatically" is a major regression for server systems. With sysv-init you could just pick the right ordering and be done, everything was stable for every boot after that.
  - genghizkhan 6y ago
    You can, using the directives "Wants=network-pre.target" & "Before=network-pre.target". This will make sure the service is up before any network interface is configured. Source: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ https://www.freedesktop.org/wiki/Software/systemd/NetworkTar...
    - corty 6y ago
      Not quite. First, this doesn't apply to any interfaces that are created by system services like VPN tunnels. Second, you would usually want and need network-online.target, because firewall config often is applied after network-pre only. Third, dynamic stuff like VLAN interfaces also only appear after network-pre and often only after network-online. So no cookies for you. This kind of non-attention to details is actually what makes systemd bad: Everything looks like the authors laptop, if it doesn't, tough luck.
      - genghizkhan 6y ago
        Edit: Sorry, I just realised what you mean. I don't know about iptables, but I've got nftables set to come up before the network is set up and it works perfectly fine without enp3s0 or wg0 having come up. The rules are set and then the interfaces come up. Original comment follows: I'm... not sure I understand. VPNs would only work after your physical interfaces are up, right? So if you want your firewall rules to be applied before a VPN interface comes up then you'd be perfectly fine with network-pre. From the page I linked in the comment you replied to: "network-pre.target is a target that may be used to order services before any network interface is configured. Its primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up. It's a passive unit: you cannot start it directly and it is not pulled in by the the network management service, but by the service that wants to run before it. Network management services hence should set After=network-pre.target, but avoid any Wants=network-pre.target or even Requires=network-pre.target. Services that want to be run before the network is configured should place Before=network-pre.target and also set Wants=network-pre.target to pull it in. This way, unless there's actually a service that needs to be ordered before the network is up the target is not pulled in, hence avoiding any unnecessary synchronization point." So ideally you'd run your VPN service after network-online.target has been reached, which would certainly be after the firewall rules have been applied. The great thing about persistent interface names is that if you know the names of the interfaces which are going to be coming up, then you can set up a firewall before any of them come up. Which takes care of dynamic VLAN interfaces. You can use IP addresses or blocks to refer to them in your firewall config, am I right? If you think I'm unable to grasp your situation, can you give me a more detailed example?
  - revanx_ 6y ago
    iptables and nftables both have ways to declare rules for interfaces that come and go. Identifying dynamic interfaces is done by string comparison instead of by index (for static interfaces).
    - corty 6y ago
      Which doesn't always help you if you are actually using one of the make-firewalling-easier-daemons (which I personally would advise against). Those often only support very basic features, but are pushed heavily by the commercial distros.
  - fao_ 6y ago
    > Systemd's "start everything at once, let the dependencies sort out automatically" is a major regression for server systems. With sysv-init you could just pick the right ordering and be done, everything was stable for every boot after that. This is a big point. All of the systemd systems I've been exposed to in the wild have non-deterministic inits, i.e. if it takes longer than average to boot up once (A problem I had a few times), starting it again doesn't replicate said problem. If the network craps itself when booting sometimes, that problem is variable so it's impossible to tell if you've fixed the problem, and it was what you suspected, or if it's something else and you only think that you've fixed it. On the other hand, my alpine system consistently boots up. If it errors once, it will error consistently enough to allow tracing of the cause, but regardless, it has never had a problem on boot.

sliken 6y ago

Sure, try https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd By default systemd includes journald, rather controversial (and mentioned in a comment on this thread) picked binary logging (harder for humans) and much less robust in the face of a small corruption, and ignored encryption. I believe it doesn't support encryption (by default). This replaces more robust solutions (by default) like syslog-ng and rsyslog that have long histories of battle tested real world usage. resolved replaces the local DNS resolvers, and at least for awhile ignored DNSSEC. This is particularly bothersome since it is such a security sensitive daemon. Sure you can disable it and pick unbound, but it's not default. timesyncd is a time daemon, replacing NTP, another security sensitive app. Not that NTP is a paragon of security, but various projects have arisen to improve things. networkd is a replacement for DHCP and similar for IPv6. Again not nearly as nice or secure as existing solutions. So basically decades of developer work, security audits, and competition among network services had been ditched and is now part of systemd and a typically cavalier attitude towards security. There are good parts of systemd, it filled a need. But this swallowing of security sensitive network services really bugs me. Being able to be compromised so early in the process and the tight integration going against the idea the unix philosophy of using minimalist modular software. Normally I'd run unbound as a non-root user with access to read few directories, and write to even fewer, DNSSEC enabled, and logging via syslog (human readable). By default on an ubuntu 20.04 (and 18.04 before that) I'd have issues with dns failures... till I replaced the systemd resolver. I'd mention it to other admins and they would shrug and mention that systemd sucks.

revanx_ 6y ago
thank you for the follow up. You have made some good points but I couldn't find any explanation to what you said : systemd talking to the network before I even have the client firewall up.
viraptor 6y ago
Worth noting that these are optional. You can forward logs to your preferred syslog daemon. You can turn off resolved, timesyncd, networkd and use something else instead of them. It's not ideal when looking at the whole environment, but specifically for our services - we've got the choice.