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 & trustst
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
> >
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 *sp
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
> fundam
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 ad
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
(
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)
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
> &
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 machi
---
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
10 matches
Mail list logo
