Re: [systemd-devel] certificate and trust store feature for systemd
On Thu, 2022-05-26 at 12:42 +0300, Mantas Mikulėnas wrote: > On Wed, May 25, 2022 at 4:28 PM SCOTT FIELDS > wrote: > > I apologize for the very general inquiry. > > > > Are there any plans to have system natively support its own trust > > store for items like CAs, x509 certs, passwords & truststores akin > > to the keychain in Windows and OS X? > > > > I still find the management of PKIs in /etc/pki to be problematic. > > > > Having this available as a core service within systemd using like > > APIs either in (mostly deprecated) CAPI or the new CNG > > > > > This sounds more like the area of p11-kit, rather than systemd. > Hi, I also think that this is an area that is lacking on Linux. For NetworkManager, the plan was something like https://wiki.gnome.org/Projects/NetworkManager/PKCS11 Related also: https://wiki.gnome.org/LubomirRintel/NMPkcs11 (of course, this is not supposed to be NetworkManager-specific). More work is needed. best, Thomas
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Thu, 2022-05-12 at 18:41 +0200, Lennart Poettering wrote: > On Mo, 09.05.22 19:27, Zbigniew Jędrzejewski-Szmek > (zbys...@in.waw.pl) wrote: > > > FWIW, I still think it's a better _default_. The patch that finally > > introduced this was my patch [1], so I'm obviously biased… Some > > more > > considerations: > > I agree with this. > > Finding good defaults is always difficult, but I must say stability > and predictability is a property I like above a lot of other stuff. I > understand that in plenty environments it's important not to add new > MAC addresses to the mix, but it's impossible to know in which > environment we are. Most devices are created by tools that intentionally choose the MAC address. So this primarily matters for simpler tools. The predictability comes at the expense of introducing races. Races that theoretically already exist when you don't wait for udev to complete initialization. But which in practice are not be harmful, because udev does not do much of relevance for software devices (MacAddressPolicy= aside). I am surprised that this race doesn't bother more people. It seems more severe to me than the bond/bridge problem that Dusty is about. Because that is just an undesired configuration, that can be changed. > > So, either way, some people will always be unhappy with the defaults > we pick. Changing defaults makes sense if it's highly likely that the > vast majority of users would benefit from the new default. But I > don't > see that here... And changing defaults comes at a price, because it > will break people's setup. We made a change once here, but I wouldn't > use that as excuse to change it again... Maybe we can just accept that RHEL8/9/10 won't have this behavior. After all, not every default may be best for very distro. In case of CoreOS, maybe that applies to some Fedora spins as well. > > So, I am not convinced. > > What makes me wonder about all of this: we are talking about > synthetic > devices, which means some tool is used to create them. If those tools > prefer a different MAC policy, why don't they drop in a .link file > that matches against the devices that specific software creates? NetworkManager doesn't mind. NetworkManager sets a MAC address (or doesn't) and udev too. Everything happens according to configuration. NetworkManager won't fight udev's configuration, or try to overrule it. It's the user's choice... Except, this choice here comes from the distro and seems to cause problems for some users. If we really wanted to overule this, we would install a 98-nm- default.conf, and don't bother with ID_NM_OWNED_AND_OPERATED=1. That essentially happens on RHEL already, by patching 99-default.conf. > > i.e. let's say NM prefers to use a different MAC policy: they could > drop in a udev rules file that adds some udev property onto the > network devices they manage (i.e. invoke a callout binary, or do a > TEST check or so which checks the iface against some NM state, and > then set ID_NM_OWNED_AND_OPERATED=1 or so). Then, ship a .link file > (or multiple) with a Property= match in the [Match] section, that > sets > the desired policy. ID_NM_OWNED_AND_OPERATED=1 would be nice and have general uses, outside this dicussion. If we had such a property we could tell the user to drop their own .link file to adjust the udev configuration to what they want, specially targeting NetworkManager devices. But it's not clear they really need this. Link files already have plenty of matching capabilities, so they probably could sufficiently just match on the name. Nice feature in theory, but the actual usecases so far were not strong enough to implement it. Patch welcome! > > With such a logic, NM could make its own choices on MAC policy, but > the default systemd policy wouldn't have to change. > > Also, afaik OSes that run in clouds all have some tool like cloud- > init > or ignition or so, which generate .network files in /run with the > right > configuration. Why not generate .link files in /run the same way with > a MAC policy appropriate for the cloud provider? best, Thomas
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Thu, 2022-05-12 at 13:36 -0400, Dan Streetman wrote: > On Thu, May 12, 2022 at 11:11 AM Thomas Haller > wrote: > > > > Either > > > > - a user doesn't care about the MAC address, > > note that it's possible for a user not to care about the *specific* > mac address, only that they want the mac to remain consistent. > > for example, on my system i have br0 bridge with multiple interfaces > attached, and my local DHCP server is configured to provide a static > addr to br0's mac. If I replace an interface card (e.g. change from > 1g > to 10g, or just replace a failing nic) then the br0 mac *does not* > change, if using systemd's default. If I had br0 inheriting its mac > from one of the attached interfaces, it would change, and i'd have to > update my dhcp server config. > > I think the argument really comes down to, should the default be to > have (without user configuration) a mac that is predictable or a mac > that is consistent. Your argument is for predictability, which makes > the field engineer's work deploying systems easier, but if you lose > consistency then the life of the maintenance engineer gets harder. > > > > - a user sets the desired MAC address themselves (possibly by > > setting MacAddressPolicy=) > > - or, the user intentionally does not set a MAC address (e.g. for > > bridge/bond). > > > > In no case there is a strong argument why udev should do it, and > > it's > > harmful in some cases. Hi, I considered that as case 2, the one where you care. You have all the means to set a MAC address also to something not specific. According to `man systemd.netdev`, a permanent MAC address is already the default. And I think systemd-networkd doesn't rely on udev's MACAddressPolicy for that (or does it?). NetworkManager also sets the MAC address that was configured, it does not expect udev to handle this. NetworkManager also supports a stable policy. If you use another tool which cannot set the MAC address, you can even use udev's MACAddressPolicy=. But that is then your configuration, not the distro default. Thomas
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
On Thu, 2022-05-12 at 17:11 +0200, Thomas Haller wrote: > We are talking here about software device which are always created by > some tool/software/user. Presumably that creator has plans for this > interface, and it's not clear why udev is supposed to change such a > fundamental setting. I think that's the important point here. This interface is created by somebody (NetworkManager, networkd, docker, etc.). In all cases, they did not leave the MAC address unspecified by accident. They create (or could create) the interface with the right parameters already. If networkd wishes to default to MACAddressPolicy=persistent (a sensible choice!), it may fully do so. Why is udev doing this? To "help" unknowing users who use `ip link add`? When it just introduces a race for them. best, Thomas
Re: [systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
Hi Zbyszek, I must say, I personally don't care too much. NetworkManager is fine either way. There is however the problem about RHEL8/9, which patches this downstream. I don't like that deviation, but I'd also be uncomfortable to push that change for RHEL(10) users. But let me play devil's advocate here... On Mon, 2022-05-09 at 19:27 +0200, Zbigniew Jędrzejewski-Szmek wrote: > > FWIW, I still think it's a better _default_. I don't agree that it's clearly better. Your arguments don't seem strong, arguably, neither are mine. Except, that it's not clear that this solves an actual problem, while it clearly causes problems for some people. Just look at the referened issues from !3374. Either - a user doesn't care about the MAC address, - a user sets the desired MAC address themselves (possibly by setting MacAddressPolicy=) - or, the user intentionally does not set a MAC address (e.g. for bridge/bond). In no case there is a strong argument why udev should do it, and it's harmful in some cases. > The patch that finally > introduced this was my patch [1], so I'm obviously biased… Some more > considerations: > > 1. this allows bridge devices to be created without attached > interfaces, and have a stable MAC address. yes. Does somebody care? In particular, kernel will assign a certain MAC address when the first port gets attached. Some people care about that. > 2. the idea that all interfaces are always available and always in > the > same order is something that isn't necessarilly true for modern > systems > where we want to react to hardware being detected dynamically. > If we wait until late userspace to configure networking, then yeah, > all > devices will most likely have been detected by that time. But if we > want > to bring networking in the initrd, not all hardware must be detected > by > the time we start configuration. It's either way a well-known MAC address from one of the interfaces. > > 3. one of the reasons to use bridge/bond and similar devices it that > the agreggate device can function when some of the child devices die. > By requiring the presence of one of the devices, we're partially > defeating this. In practice, this race is not happening for many users. It's not clear why it's a problem to get the MAC address of an "unexpected" port (due to the race). It does not negate the uses of the bride/bond. > > [1] https://github.com/systemd/systemd/commit/6d36464065 > > > 1) for bridge/bond interfaces, there is a special meaning of > > leaving > > the MAC address unassigned. It causes kernel to automatically set > > the > > MAC address when the first port gets attached. By setting a > > persistent > > MAC address, that automatism is not longer possible. > > > > The MAC address can matter, for example, if you configure the DHCP > > server to hand out IP addresses based on the MAC address (or based > > on > > the client-id, which in turn might be based on the MAC address). If > > you > > boot many machines (e.g. in data center or cloud), you might know > > the > > MAC address of the machines, and thereby can also determine the > > assigned IP addresses. With MACAddressPolicy=persistent the MAC > > address > > is not predictable. > > This is true. But one can just as well argument that with > MACAddressPolicy=persistent the address is even more predictable. If > you know the machine-id and device name, you can calculate the > address > in advance, even before deciding if the device will e.g. have this or > that card attached. It's unpredictable, because you need to know the machine-id. If you boot a machine the first, you may not know that before hand. Unless you explicitly specifying the machine-id via kernel command line, or similar. At which point, you need individual boot options (or images) for each machine. > > I'm not sure if we expose this conveniently anywhere… Would it help > if > we document how to do this calculation with python one-liner or some > helper? > > > 2) udev changing the MAC address causes races with naive > > scripts/tools. > > For example: > > > > ip monitor link & > > while : ; do > > ip link del xxx > > ip link add name xxx type dummy \ > > && ip link set xxx addr aa:00:00:00:00:00 \ > > && ip link show xxx | grep -q aa:00:00:00:00:00 \ > > || break > > done > > Again, this is a question of expecations. With MACAP=p, 'dummy' gets > the same address every time, and maybe there's no reason to set it > manually. > > It would be great if we could have 'ip link add' wait for udev to > process the device. Maybe even by default? > > We also discussed adding a kernel command-line switch similar to > net.ifnames= to allow this to be configured globally. Would that > help? That might help. Granted, it's pretty easy already. RHEL ships a one- line patch downstream, and CoreOS probably could deploy some .link file that overrules this. And any user can write their own .link file. > > The cases
[systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?
Hi everybody, this email is for discussing MACAddressPolicy=persistent in /data/src/systemd/network/99-default.link there is a Fedora CoreOS issue about this: [1] https://github.com/coreos/fedora-coreos-tracker/issues/919 Since systemd 242 (Apr 2019), this policy applies to more device types ([2]). [2] https://github.com/systemd/systemd/blob/v247/NEWS#L2332-L2358 This topic was already discussed. For example at [3]. I also brought this up before at [4], but I'd like to reopen this discussion with the recent Fedora CoreOS issue. [3] https://github.com/systemd/systemd/issues/3374 [4] https://github.com/systemd/systemd/issues/3374#issuecomment-522528484 To reiterate, this causes two problems: 1) for bridge/bond interfaces, there is a special meaning of leaving the MAC address unassigned. It causes kernel to automatically set the MAC address when the first port gets attached. By setting a persistent MAC address, that automatism is not longer possible. The MAC address can matter, for example, if you configure the DHCP server to hand out IP addresses based on the MAC address (or based on the client-id, which in turn might be based on the MAC address). If you boot many machines (e.g. in data center or cloud), you might know the MAC address of the machines, and thereby can also determine the assigned IP addresses. With MACAddressPolicy=persistent the MAC address is not predictable. 2) udev changing the MAC address causes races with naive scripts/tools. For example: ip monitor link & while : ; do ip link del xxx ip link add name xxx type dummy \ && ip link set xxx addr aa:00:00:00:00:00 \ && ip link show xxx | grep -q aa:00:00:00:00:00 \ || break done granted, a script should either set the MAC address from the start, or it should wait for udev to settle. Still, how many tools out there are (still) broken? On RHEL, 99-default.link is patched to set MACAddressPolicy=none. On Fedora, despite this behavior being there for a while now, I think it's harmful and should be dropped as well... at least for bridges/bonds (problem 1) or even all software devices (problem 2). In my opionion, this approach should be reconsidered for udev in general. best, Thomas signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] F30->F31 systemd-networkd no IPv6 autoconfiguration
On Fri, 2019-11-08 at 20:30 -0600, Anthony Joseph Messina wrote:
> Thank you for responding Ryan. AFAIK, I don't have both systemd-
> networkd and
> NetworkManager "running" or enabled. In fact, I have had
> NetworkManager
> disabled on these systems for some time (back through F27, I
> believe). Post
> upgrade (or fresh install) I ensure that NetworkManager is not re-
> enabled, and
> that systemd-networkd is enabled.
> Unforuntately, trying to remove
> NetworkManager completely seems like a heavy hammer based on the `dnf
> remove`
> output below.
Seems dnf wants to also unstall packages that were installed due to
NetworkManager. For exapmle, "libndp" obvoiusly has no dependency on
NetworkManager (but the other way around). You probable should use the
right argument to dnf to not remove unrelated packages.
>
> Also, these identical systemd-networkd configurations do work on F30,
> just not
> on systems upgraded to F31.
>
> The only recent change I notice in F31, is that NetworkManager is
> initialized
> during early boot even when the service is disabled and masked.
NM indeed may now run in early boot. That has no relation to whether
you enable the systemd service ("enabling" a service in systemd anyway
only means to hook it up accroding to the [Install] section, and that
does not cover what runs in initrd).
I would suspect that NetworkManager sets the interface to disable ipv6
address generation (e.g. `ip -d link` would report "addrgenmode none").
It probably shouldn't do so, if there is not configuration for the
device. This is probably a bug.
Another question is what causes NM to run in initrd in the first place.
Usually that would be caused by setting "rd.neednet=1" on the kernel
command line. But dracut may also artificially add such a command line,
according to its configuration. You probably don't want to setup
networking in initrd in the first place. That is, check your dracut
configuration...
best,
Thomas
>
> This is the early boot NetworkManager output:
> [1573262139.2398] NetworkManager (version 1.20.4-1.fc31) is
> starting... (for the first time)
> [1573262139.2399] Read config:
> /etc/NetworkManager/NetworkManager.conf
> [1573262139.2416] auth[0x55b3f3c8b4a0]: create auth-manager:
> D-Bus
> connection not available. Polkit is disabled and all requests are
> authenticated.
> [1573262139.2426] manager[0x55b3f3c94060]: monitoring kernel
> firmware
> directory '/lib/firmware'.
> [1573262139.2427] hostname: hostname: hostnamed not used as
> proxy
> creation failed with: Could not connect: No such file or directory
> [1573262139.2428] hostname: hostname changed from (none) to
> "linux-
> ws1.messinet.com"
> [1573262139.2430] dns-mgr[0x55b3f3c8f210]: init:
> dns=default,systemd-
> resolved rc-manager=symlink
> [1573262139.2447] Loaded device plugin: NMTeamFactory
> (/usr/lib64/
> NetworkManager/1.20.4-1.fc31/libnm-device-plugin-team.so)
> [1573262139.2448] manager: rfkill: Wi-Fi enabled by radio
> killswitch;
> enabled by state file
> [1573262139.2448] manager: rfkill: WWAN enabled by radio
> killswitch;
> enabled by state file
> [1573262139.2448] manager: Networking is enabled by state
> file
> [1573262139.2448] dhcp-init: Using DHCP client 'internal'
> [1573262139.2453] settings: Loaded settings plugin: ifcfg-rh
> ("/usr/
> lib64/NetworkManager/1.20.4-1.fc31/libnm-settings-plugin-ifcfg-
> rh.so")
> [1573262139.2454] settings: Loaded settings plugin: keyfile
> (internal)
> [1573262139.2459] device (lo): carrier: link connected
> [1573262139.2460] manager: (lo): new Generic device
> (/org/freedesktop/
> NetworkManager/Devices/1)
> [1573262139.2464] manager: (eno1): new Ethernet device (/org/
> freedesktop/NetworkManager/Devices/2)
> [1573262139.2466] device (eno1): state change: unmanaged ->
> unavailable (reason 'managed', sys-iface-state: 'external')
> [1573262139.4343] sleep-monitor-sd: failed to acquire D-Bus
> proxy:
> Could not connect: No such file or directory
> [1573262139.4343] firewall: could not connect to system D-Bus
> (Could
> not connect: No such file or directory)
> [1573262139.4344] ifcfg-rh: dbus: couldn't initialize system
> bus:
> Could not connect: No such file or directory
>
> ~]# dnf --assumeno remove NetworkManager
> Dependencies resolved.
> =
> =
> =
> =
> ==
> Package
>
> Architecture Version
>
> Repository Size
>
Re: [systemd-devel] [PATCH 1/1] sd-dhcp6-client: delay setting the DUID and don't fail constructor
On Wed, 2015-03-04 at 12:52 +0100, Lennart Poettering wrote: On Tue, 03.03.15 21:06, Thomas Haller (thal...@redhat.com) wrote: sd_dhcp6_client_new() tried to set the DUID based on the machine id. If the host has no /etc/machine-id, the constructor would fail making it impossible to create an sd_dhcp6_client instance. We do not even allow bootups without /etc/machine-id. If the file is missing then things really *should* fail. Hi I understand, and agree that it makes sense for systemd. networkd will still fail, at bit later. With this change, libsystemd-network might handle systems without machine-id file -- as long as the user cares and sets an alternative DUID via sd_dhcp6_client_set_duid(). That is interesting for NetworkManager. Thomas signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] sd-dhcp6-client: delay setting the DUID and don't fail constructor
sd_dhcp6_client_new() tried to set the DUID based on the machine id.
If the host has no /etc/machine-id, the constructor would fail
making it impossible to create an sd_dhcp6_client instance.
Relax this and create a DUID only later as needed. This way a caller
caller can workaround a missing machine-id file and set a DUID of his
choosing via sd_dhcp6_client_set_duid().
---
src/libsystemd-network/sd-dhcp6-client.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/libsystemd-network/sd-dhcp6-client.c
b/src/libsystemd-network/sd-dhcp6-client.c
index a432bbf..3db1cb0 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -158,6 +158,13 @@ int sd_dhcp6_client_set_mac(sd_dhcp6_client *client, const
uint8_t *addr,
return 0;
}
+static int client_ensure_duid(sd_dhcp6_client *client)
+{
+if (client-duid_len != 0)
+return 0;
+return dhcp_identifier_set_duid_en(client-duid, client-duid_len);
+}
+
int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, uint16_t type, uint8_t
*duid,
size_t duid_len)
{
@@ -378,6 +385,7 @@ static int client_send_message(sd_dhcp6_client *client,
usec_t time_now) {
if (r 0)
return r;
+assert (client-duid_len);
r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
client-duid_len, client-duid);
if (r 0)
@@ -1108,6 +1116,10 @@ int sd_dhcp6_client_start(sd_dhcp6_client *client)
if (r 0)
return r;
+r = client_ensure_duid(client);
+if (r 0)
+return r;
+
r = dhcp6_network_bind_udp_socket(client-index, NULL);
if (r 0)
return r;
@@ -1205,7 +1217,6 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client
*client) {
int sd_dhcp6_client_new(sd_dhcp6_client **ret)
{
_cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
-int r;
size_t t;
assert_return(ret, -EINVAL);
@@ -1222,11 +1233,6 @@ int sd_dhcp6_client_new(sd_dhcp6_client **ret)
client-fd = -1;
-/* initialize DUID */
-r = dhcp_identifier_set_duid_en(client-duid, client-duid_len);
-if (r 0)
-return r;
-
client-req_opts_len = ELEMENTSOF(default_req_opts);
client-req_opts = new0(be16_t, client-req_opts_len);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] sd-dhcp-lease: fix copy-paste error asserting wrong function argument
---
src/libsystemd-network/sd-dhcp-lease.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-network/sd-dhcp-lease.c
b/src/libsystemd-network/sd-dhcp-lease.c
index f046ac5..3da71a2 100644
--- a/src/libsystemd-network/sd-dhcp-lease.c
+++ b/src/libsystemd-network/sd-dhcp-lease.c
@@ -51,7 +51,7 @@ int sd_dhcp_lease_get_address(sd_dhcp_lease *lease, struct
in_addr *addr) {
int sd_dhcp_lease_get_lifetime(sd_dhcp_lease *lease, uint32_t *lifetime) {
assert_return(lease, -EINVAL);
-assert_return(lease, -EINVAL);
+assert_return(lifetime, -EINVAL);
*lifetime = lease-lifetime;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
