Re: [systemd-devel] Recommended way to enable IPForward for a system using networkd?

2018-08-02 Thread Mantas Mikulėnas
On Thu, Aug 2, 2018 at 8:18 PM Filipe Brandenburger 
wrote:

> So, IPForward is a global setting and yet with networkd it needs to be
> attached to an interface...
>
> What's the best way to enable it on a system, that's general enough and
> won't really depend on the existing interface configurations (let's assume
> those will be managed separately through drop-ins somehow...)
>

It's a sysctl, so just set it through /etc/sysctl.d:

net.ipv4.conf.all.forwarding = 1
net.ipv6.conf.all.forwarding = 1

(For IPv4 it is both a global *and* per-interface setting, for some reason.)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Supervisory Watchdog notification not working when using SmackProcessLabel

2018-08-02 Thread Lennart Poettering
On Mi, 01.08.18 11:18, Martin Townsend (mtownsend1...@gmail.com) wrote:

> @@ -728,7 +729,12 @@ static int manager_setup_notify(Manager *m) {
> 
>  m->notify_fd = fd;
>  fd = -1;
> -
> +r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPIN, "*");
> +if (r < 0)
> +log_error_errno(r, "mac_smack_apply_ip_in_fd: %m");
> +r = mac_smack_apply_fd(m->notify_fd, SMACK_ATTR_IPOUT, "@");
> +if (r < 0)
> +log_error_errno(r, "mac_smack_apply_ip_out_fd: %m");
>  log_debug("Using notification socket %s", m->notify_socket);
>  }
> 
> Is there a better way of ensuring /run/systemd/notify can be accessed
> by a service with a User defined SMACK label? or is this patch to
> manager_setup_notify sufficient?

Generally, we upstream rely on submitted patches for everything MAC
related. We do not know the various MACs well enough to be able to
maintain this part of our codebase on our own.

Hence, if the patch like the one above is something we are supposed to
merge upstream, then please post this as PR on our systemd github, and
make sure that someone from SMACK upstream (for example Casey) likes
it and says so on the PR.

Thank you,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Question about the default value of NamePolicy=

2018-08-02 Thread Francis Moreau
Hello,

On Wed, Aug 1, 2018 at 7:36 PM, Mantas Mikulėnas  wrote:
>
> AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so their
> relative ordering isn't that important... but if the firmware marks a device
> as on-board *and* also provides a slot number, then it's more likely that
> the slot# is garbage.
>

Thanks for the info.

> Both "onboard" and "slot" are preferred over "path" because they're shorter
> and more descriptive (as long as the firmware provides correct values). The
> path, being based on PCI bus addressing, doesn't say much to most people --
> at best, it's just a stable identifier. (For example, my server's integrated
> NIC port #1 is better named "eno1", not "enp3s0f0".)
>

"path" can also run onto problem when adapters are replaced by new
ones with multiple ports for example.

Would "onboard" or "slot" be a better alternative for such case ?

Thanks.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel