[systemd-devel] How to get array[struct type] using sd_bus_message_* API's

[Manojkiran Eda]

Hi All,

I am a beginner, trying to learn the sd_bus API's.

I am trying to replicate the following busctl call to get information:

$ busctl call xyz.openbmc_project.ObjectMapper
/xyz/openbmc_project/object_mapper xyz.openbmc_project.ObjectMapper
GetObject sas /xyz/openbmc_project/inventory 0 --verbose
MESSAGE "a{sas}" {
ARRAY "{sas}" {
DICT_ENTRY "sas" {
STRING "xyz.openbmc_project.EntityManager";
ARRAY "s" {
STRING
"org.freedesktop.DBus.Introspectable";
STRING "org.freedesktop.DBus.Peer";
STRING "org.freedesktop.DBus.Properties";
};
};
DICT_ENTRY "sas" {
STRING "xyz.openbmc_project.Inventory.Manager";
ARRAY "s" {
STRING
"org.freedesktop.DBus.Introspectable";
STRING "org.freedesktop.DBus.ObjectManager";
STRING "org.freedesktop.DBus.Peer";
STRING "org.freedesktop.DBus.Properties";
STRING
"xyz.openbmc_project.Inventory.Manager";
};
};
DICT_ENTRY "sas" {
STRING "xyz.openbmc_project.ObjectMapper";
ARRAY "s" {
STRING
"org.freedesktop.DBus.Introspectable";
STRING "org.freedesktop.DBus.Peer";
STRING "org.freedesktop.DBus.Properties";
};
};
DICT_ENTRY "sas" {
STRING "xyz.openbmc_project.PLDM";
ARRAY "s" {
STRING
"org.freedesktop.DBus.Introspectable";
STRING "org.freedesktop.DBus.ObjectManager";
STRING "org.freedesktop.DBus.Peer";
STRING "org.freedesktop.DBus.Properties";
};
};
};
};


In the `busctl monitor` i could confirm that i am getting a message of
signature a{sas} from the dbus call, and here is the logic that I could
come up with to read the data.

r = sd_bus_message_enter_container(reply, SD_BUS_TYPE_ARRAY, "{sas}");
if (r < 0)
goto exit;
while ((r = sd_bus_message_enter_container(reply,
SD_BUS_TYPE_DICT_ENTRY,
   "sas")) > 0)
{
char* service = NULL;
r = sd_bus_message_read(reply, "s", &service);
if (r < 0)
goto exit;
printf("service = %s\n", service);
r = sd_bus_message_enter_container(reply, 'a', "s");
if (r < 0)
goto exit;
for (;;)
{
const char* s;
r = sd_bus_message_read(reply, "s", &s);
if (r < 0)
goto exit;
if (r == 0)
break;
printf("%s\n", s);
}
}

Output:
service = xyz.openbmc_project.EntityManager
org.freedesktop.DBus.Introspectable
org.freedesktop.DBus.Peer
org.freedesktop.DBus.Properties

But, I was only able to get the data from the first dictionary, can anyone
help me to solve this issue? what am I missing?

Thanks,
Manoj

Re: [systemd-devel] Networking in a systemd-nspawn container

[Jarosław Fedewicz]

> I have been wondering: Would it be possible to forward the containers
> resolver to the host machine resolver somehow?

On my laptop's host system, I set NetworkManager to use dnsmasq as the DNS
server. I added a config file snippet to that dnsmasq so it also listens on
my bridge interface (which has a static IP address, and the containers are
on the same internal network with it and are using it as their default
route). Then I set the resolver in my containers to use the IP from the
host side of the bridge as their DNS.

Of course this is not a thing that I imagine systemd-nspawn would do all by
itself. It feels too complicated. I think the feature exists in its current
form because it was simple to implement and would cover maybe 85% of the
use cases.

But then again, could systemd-nspawn and systemd-resolved somehow be made
to work in tandem to provide an automagical solution?

Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

[Brian Hutchinson]

Hi Alvin,

On Thu, Nov 18, 2021 at 5:48 PM Alvin Šipraga  wrote:

> On 11/18/21 23:25, Brian Hutchinson wrote:
> > Hi Alvin,
> >
> >
> > On Thu, Nov 18, 2021 at 4:20 PM Alvin Šipraga  > > wrote:
> >
> > Hi Brian,
> >
> > On 11/18/21 01:20, Brian Hutchinson wrote:
> >   > Yet another update, I was able to get it working .. but feel
> > like it is
> >   > a hack so comments welcome ... see below:
> >   >
> >
> > 
> >
> >   >
> >   > I tried and tried to get eth0 to come up before the bond was
> brought
> >   > up.  I had everything named in lexical order but didn't appear to
> >   > matter.  I added a eth0.network file and in it specified
> >   > |ActivationPolicy=|always-up and other things but could not get
> > eth0 to
> >   > come up.
> >
> > What kernel version are you using? Since Linux 5.11 we have the
> >
> >
> > I'm using linux-fslc-imx 5.10.69
> >
> > following two changes ([1] and [2]) which should automatically bring
> > up/down the master (eth0) whenever user ports (lan1, lan2) are
> brought
> > up/down. Please confirm whether or not you are using 5.11 or later.
> >
> >
> > I don't think that will work either.  eth0 has to be up and stay up or
> > DSA driver won't work at all.  eth0 has to be up or the slaves can't be
> > added to the bond.
>
> This use-case is also addressed in the newer kernels (>=5.11), see the
> below commit. It is not only when a user port is brought up (as I
> summarized it), but rather when it is opened.
>
> commit 9d5ef190e5615a7b63af89f88c4106a5bc127974
> Author: Vladimir Oltean 
> Date:   Fri Feb 5 15:37:10 2021 +0200
>
>  net: dsa: automatically bring up DSA master when opening user port
>
>  DSA wants the master interface to be open before the user port is
> due to
>  historical reasons. The promiscuity of interfaces that are down used
> to
>  have issues, as referenced Lennert Buytenhek in commit df02c6ff2e39
>  ("dsa: fix master interface allmulti/promisc handling").
>
>  The bugfix mentioned there, commit b6c40d68ff64 ("net: only invoke
>  dev->change_rx_flags when device is UP"), was basically a "don't do
>  that" approach to working around the promiscuity while down issue.
>
>  Further work done by Vlad Yasevich in commit d2615bf45069 ("net: core:
>  Always propagate flag changes to interfaces") has resolved the
>  underlying issue, and it is strictly up to the DSA and 8021q drivers
>  now, it is no longer mandated by the networking core that the master
>  interface must be up when changing its promiscuity.
>
>  From DSA's point of view, deciding to error out in dsa_slave_open
>  because the master isn't up is
>  (a) a bad user experience and
>  (b) knocking at an open door.
>  Even if there still was an issue with promiscuity while down, DSA
> could
>  still just open the master and avoid it.
>
>  Doing it this way has the additional benefit that user space can now
>  remove DSA-specific workarounds, like systemd-networkd with
> BindCarrier:
>  https://github.com/systemd/systemd/issues/7478
>
>  And we can finally remove one of the 2 bullets in the "Common pitfalls
>  using DSA setups" chapter.
>
>  Tested with two cascaded DSA switches:
>
>  $ ip link set sw0p2 up
>  fsl_enetc :00:00.2 eno2: configuring for fixed/internal link mode
>  fsl_enetc :00:00.2 eno2: Link is Up - 1Gbps/Full - flow control
> rx/tx
>  mscc_felix :00:00.5 swp0: configuring for fixed/sgmii link mode
>  mscc_felix :00:00.5 swp0: Link is Up - 1Gbps/Full - flow
> control off
>  8021q: adding VLAN 0 to HW filter on device swp0
>  sja1105 spi2.0 sw0p2: configuring for phy/rgmii-id link mode
>  IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready
>  IPv6: ADDRCONF(NETDEV_CHANGE): swp0: link becomes ready
>
>  Signed-off-by: Vladimir Oltean 
>  Reviewed-by: Andrew Lunn 
>  Reviewed-by: Florian Fainelli 
>  Signed-off-by: Jakub Kicinski 
>
>
Hmm, looks like I might just have to wait a bit until we can step up to
5.11.  We just stepped up to 5.10.69.  IMX8 Freescale yocto lags a bit.
And too bleeding edge hurts.


> >
> > If you look back up the thread where I'm doing the commands manually
> > (I'll re-copy below) ... the first thing is to bring eth0 up.  If that
> > doesn't happen, nothing else works.
>
> I forgot about the bond in my reply. Does it work if you do
> BindCarrier=eth0 from the bond's .network file? You might be out of luck
>

No.  Trying it in my 10-bond1.network doesn't work either :(

depending on how networkd implements BindCarrier=, but hopefully
> something like that works. Remember also that you need a .network file
> covering eth0, even though it's just a conduit and you don't want to
>

So I tried having a pretty bare 05-eth0.network file and tried everything I
could think of to get eth0 up with systemd and 

Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

[Alvin Šipraga]

On 11/18/21 23:25, Brian Hutchinson wrote:
> Hi Alvin,
> 
> 
> On Thu, Nov 18, 2021 at 4:20 PM Alvin Šipraga  > wrote:
> 
> Hi Brian,
> 
> On 11/18/21 01:20, Brian Hutchinson wrote:
>   > Yet another update, I was able to get it working .. but feel
> like it is
>   > a hack so comments welcome ... see below:
>   >
> 
> 
> 
>   >
>   > I tried and tried to get eth0 to come up before the bond was brought
>   > up.  I had everything named in lexical order but didn't appear to
>   > matter.  I added a eth0.network file and in it specified
>   > |ActivationPolicy=|always-up and other things but could not get
> eth0 to
>   > come up.
> 
> What kernel version are you using? Since Linux 5.11 we have the
> 
> 
> I'm using linux-fslc-imx 5.10.69
> 
> following two changes ([1] and [2]) which should automatically bring
> up/down the master (eth0) whenever user ports (lan1, lan2) are brought
> up/down. Please confirm whether or not you are using 5.11 or later.
> 
> 
> I don't think that will work either.  eth0 has to be up and stay up or 
> DSA driver won't work at all.  eth0 has to be up or the slaves can't be 
> added to the bond.

This use-case is also addressed in the newer kernels (>=5.11), see the 
below commit. It is not only when a user port is brought up (as I 
summarized it), but rather when it is opened.

commit 9d5ef190e5615a7b63af89f88c4106a5bc127974
Author: Vladimir Oltean 
Date:   Fri Feb 5 15:37:10 2021 +0200

 net: dsa: automatically bring up DSA master when opening user port

 DSA wants the master interface to be open before the user port is 
due to
 historical reasons. The promiscuity of interfaces that are down used to
 have issues, as referenced Lennert Buytenhek in commit df02c6ff2e39
 ("dsa: fix master interface allmulti/promisc handling").

 The bugfix mentioned there, commit b6c40d68ff64 ("net: only invoke
 dev->change_rx_flags when device is UP"), was basically a "don't do
 that" approach to working around the promiscuity while down issue.

 Further work done by Vlad Yasevich in commit d2615bf45069 ("net: core:
 Always propagate flag changes to interfaces") has resolved the
 underlying issue, and it is strictly up to the DSA and 8021q drivers
 now, it is no longer mandated by the networking core that the master
 interface must be up when changing its promiscuity.

 From DSA's point of view, deciding to error out in dsa_slave_open
 because the master isn't up is
 (a) a bad user experience and
 (b) knocking at an open door.
 Even if there still was an issue with promiscuity while down, DSA could
 still just open the master and avoid it.

 Doing it this way has the additional benefit that user space can now
 remove DSA-specific workarounds, like systemd-networkd with 
BindCarrier:
 https://github.com/systemd/systemd/issues/7478

 And we can finally remove one of the 2 bullets in the "Common pitfalls
 using DSA setups" chapter.

 Tested with two cascaded DSA switches:

 $ ip link set sw0p2 up
 fsl_enetc :00:00.2 eno2: configuring for fixed/internal link mode
 fsl_enetc :00:00.2 eno2: Link is Up - 1Gbps/Full - flow control 
rx/tx
 mscc_felix :00:00.5 swp0: configuring for fixed/sgmii link mode
 mscc_felix :00:00.5 swp0: Link is Up - 1Gbps/Full - flow 
control off
 8021q: adding VLAN 0 to HW filter on device swp0
 sja1105 spi2.0 sw0p2: configuring for phy/rgmii-id link mode
 IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready
 IPv6: ADDRCONF(NETDEV_CHANGE): swp0: link becomes ready

 Signed-off-by: Vladimir Oltean 
 Reviewed-by: Andrew Lunn 
 Reviewed-by: Florian Fainelli 
 Signed-off-by: Jakub Kicinski 


> 
> If you look back up the thread where I'm doing the commands manually 
> (I'll re-copy below) ... the first thing is to bring eth0 up.  If that 
> doesn't happen, nothing else works.

I forgot about the bond in my reply. Does it work if you do 
BindCarrier=eth0 from the bond's .network file? You might be out of luck 
depending on how networkd implements BindCarrier=, but hopefully 
something like that works. Remember also that you need a .network file 
covering eth0, even though it's just a conduit and you don't want to 
give it an IP. You can do that by omitting the [Network] section and 
just having a [Match] on eth0.

> 
> These are the manual steps that work.  This is what I'm trying to 
> automate the "systemd way".  I read that "bond0" is somehow reserved so 
> my systemd.netdev and .network files use bond1.
> 
> #!/bin/bash
> 
> # Create a redundant bond between ksz9567 DSA lan1 and lan2 interfaces
> 
> # Load bonding kernel module
> modprobe bonding
> 
> # Bring up CPU interface (cpu to switch port 7 - the RGMII link)
> ip link set eth0 up
> 
> # Create a bond
> echo +bond0 > /sys/class/net/bonding_masters
> 
> # Set

Re: [systemd-devel] [RFC] Switching to OpenSSL 3?

[Davide Cavalca]

On Wed, 2021-09-15 at 14:29 +, Davide Cavalca wrote:
> On Tue, 2021-09-14 at 13:36 +0200, Lennart Poettering wrote:
> > Heya!
> > 
> > Some of the systemd developers have been discussing switching
> > systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop
> > support for older OpenSSL versions, as well as any GNUTLS/libgcrypt
> > support. As you might have noticed OpenSSL 3.0 has been released
> > recently, and for the first time resolves the GPL2 license
> > incompatibility mess comprehensively, which opens this door to us.
> > 
> > I personally care a lot about reducing the combinatorial explosion of
> > deps a bit, and keeping our tree as maintainable as we can, with a
> > single implementation of everything, not multiple, and no abstraction
> > layers and such, and thus removing any compat kludges for other
> > libraries or other library versions.
> > 
> > Now, before we make a decision on this, I'd like to collect feedback
> > on such a move. I know that there are some people who backpart new
> > systemd onto old distros. How big would the pain be require porting
> > OpenSSL 3, too, at the same time?
> 
> This will be an issue for CentOS Stream 8, among others. We ship a
> backport of the latest systemd (and dailies from the github master) for
> it as part of the CentOS Hyperscale SIG
> (https://wiki.centos.org/SpecialInterestGroup/Hyperscale). C8 currently
> ships OpenSSL 1.1.1k, and given that this is a package from base it's
> unlikely to get bumped throughout the lifecycle of the distro. We could
> theoretically build OpenSSL 3 as part of Hyperscale, but that would
> require rebuilding half the distribution, which is obviously not
> practical. We might be able to build and ship a coinstallable private
> OpenSSL 3 build just for systemd, but I don't know how technically
> feasible that'll be in practice, and it'll definitely be a pain to
> maintain and likely bring along some security fun.

To close the loop on this -- Michel (in CC) has built a coinstallable
openssl3 package in EPEL 8:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ff6e908f7e

This should make it possible to continue backporting systemd on CentOS
Stream 8 even after the move to openssl3.

Cheers
Davide

Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

[Brian Hutchinson]

Hi Alvin,


On Thu, Nov 18, 2021 at 4:20 PM Alvin Šipraga  wrote:

> Hi Brian,
>
> On 11/18/21 01:20, Brian Hutchinson wrote:
>  > Yet another update, I was able to get it working .. but feel like it is
>  > a hack so comments welcome ... see below:
>  >
>
> 
>
>  >
>  > I tried and tried to get eth0 to come up before the bond was brought
>  > up.  I had everything named in lexical order but didn't appear to
>  > matter.  I added a eth0.network file and in it specified
>  > |ActivationPolicy=|always-up and other things but could not get eth0 to
>  > come up.
>
> What kernel version are you using? Since Linux 5.11 we have the
>

I'm using linux-fslc-imx 5.10.69

following two changes ([1] and [2]) which should automatically bring
> up/down the master (eth0) whenever user ports (lan1, lan2) are brought
> up/down. Please confirm whether or not you are using 5.11 or later.
>

I don't think that will work either.  eth0 has to be up and stay up or DSA
driver won't work at all.  eth0 has to be up or the slaves can't be added
to the bond.

If you look back up the thread where I'm doing the commands manually (I'll
re-copy below) ... the first thing is to bring eth0 up.  If that doesn't
happen, nothing else works.

These are the manual steps that work.  This is what I'm trying to automate
the "systemd way".  I read that "bond0" is somehow reserved so my
systemd.netdev and .network files use bond1.

#!/bin/bash

# Create a redundant bond between ksz9567 DSA lan1 and lan2 interfaces

# Load bonding kernel module
modprobe bonding

# Bring up CPU interface (cpu to switch port 7 - the RGMII link)
ip link set eth0 up

# Create a bond
echo +bond0 > /sys/class/net/bonding_masters

# Set mode to active-backup (redundancy failover)
echo active-backup > /sys/class/net/bond0/bonding/mode

# Set time it takes (in ms) for slave to move when a link goes down
echo 1000 > /sys/class/net/bond0/bonding/miimon

# Add slaves to bond

echo +lan1 > /sys/class/net/bond0/bonding/slaves
echo +lan2 > /sys/class/net/bond0/bonding/slaves

# Set IP and netmask of the bond
ip addr add 192.168.0.4/24 dev bond0

# And bring bond up.  Pings and network connectivity should work now
ip link set bond0 up

# For a board that doesn't have Ethernet switch hardware strapped to enable
at boot .. enable it now
i2cset -f -y 0 0x5f 0x03 0x00 0x01 i


> If you are using an older kernel, and systemd is version 243 or later,
>

I checked and I'm using 244.5

you can use the BindCarrier= setting (see [1]) in the [Network] section
> of your .network file(s) for lan1 and lan2. Something like this:
>
> [Match]
> Name=lan*
>
> [Network]
> BindCarrier=eth0
>

I added the BindCarrier=eth0 in both of my DSA lan1 and lan2 .network
files.  I got the same result as before ... dmesg reports lan1 and lan2
slaves are brought up before eth0 ... and so they fail.  The only thing so
far that works is to bring eth0 up with a network-pre.target service.  And
I'm doing the i2c command to enable my switch in a
After=network-online.target service.

[4.367802] bond1: (slave lan2): Opening slave failed
[4.467561] bond1: (slave lan1): Opening slave failed
[4.640914] fec 30be.ethernet eth0: Link is Up - 1Gbps/Full - flow
control off
[5.104983] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Regards,

Brian

Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?

[Alvin Šipraga]

Hi Brian,

On 11/18/21 01:20, Brian Hutchinson wrote:
 > Yet another update, I was able to get it working .. but feel like it is
 > a hack so comments welcome ... see below:
 >



 >
 > I tried and tried to get eth0 to come up before the bond was brought
 > up.  I had everything named in lexical order but didn't appear to
 > matter.  I added a eth0.network file and in it specified
 > |ActivationPolicy=|always-up and other things but could not get eth0 to
 > come up.

What kernel version are you using? Since Linux 5.11 we have the 
following two changes ([1] and [2]) which should automatically bring 
up/down the master (eth0) whenever user ports (lan1, lan2) are brought 
up/down. Please confirm whether or not you are using 5.11 or later.

If you are using an older kernel, and systemd is version 243 or later, 
you can use the BindCarrier= setting (see [1]) in the [Network] section 
of your .network file(s) for lan1 and lan2. Something like this:

[Match]
Name=lan*

[Network]
BindCarrier=eth0

See also [3].

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5ef190e5615a7b63af89f88c4106a5bc127974
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0a8a9c274936543e436aef691499304ce3127dc
[3] 
https://www.freedesktop.org/software/systemd/man/systemd.network.html#BindCarrier=
[4] https://github.com/systemd/systemd/issues/7478#issuecomment-514562190

If both your kernel and systemd are old, I think you'll have to use 
something like your hack.

One more thing:

 > [Service]
 > ExecStart=/usr/local/bin/eth0-up.sh
 > RemainAfterExit=yes
 >
 > [Install]
 > WantedBy=multi-user.target
 >
 > cat /usr/local/bin/eth0-up.sh
 > #!/bin/bash
 > ip link set eth0 up

You don't need a separate shell script, you can just invoke the ip 
command directly:

[Service]
ExecStart=/usr/bin/ip link set eth0 up
...


Kind regards,

Alvin

Re: [systemd-devel] the need for a discoverable sub-volumes specification

[Chris Murphy]

On Thu, Nov 18, 2021 at 2:51 PM Chris Murphy  wrote:
>
> How to do swapfiles?
>
> Currently I'm creating a "swap" subvolume in the top-level of the file
> system and /etc/fstab looks like this
>
> UUID=$FSUUID/var/swap   btrfs   noatime,subvol=swap 0 0
> /var/swap/swapfile1 none swap defaults 0 0
>
> This seems to work reliably after hundreds of boots.
>
> a. Is this naming convention for the subvolume adequate? Seems like it
> can just be "swap" because the GPT method is just a single partition
> type GUID that's shared by multiboot Linux setups, i.e. not arch or
> distro specific
> b. Is the mount point, /var/swap, OK?
> c. What should the additional naming convention be for the swapfile
> itself so swapon happens automatically?

Actually I'm thinking of something different suddenly... because
without user ownership of swapfiles, and instead systemd having domain
over this, it's perhaps more like:

/x-systemd.auto/swap -> /run/systemd/swap

And then systemd just manages the files in that directory per policy,
e.g. do on demand creation of swapfiles with variable size increments,
as well as cleanup.


-- 
Chris Murphy

Re: [systemd-devel] the need for a discoverable sub-volumes specification

[Chris Murphy]

How to do swapfiles?

Currently I'm creating a "swap" subvolume in the top-level of the file
system and /etc/fstab looks like this

UUID=$FSUUID/var/swap   btrfs   noatime,subvol=swap 0 0
/var/swap/swapfile1 none swap defaults 0 0

This seems to work reliably after hundreds of boots.

a. Is this naming convention for the subvolume adequate? Seems like it
can just be "swap" because the GPT method is just a single partition
type GUID that's shared by multiboot Linux setups, i.e. not arch or
distro specific
b. Is the mount point, /var/swap, OK?
c. What should the additional naming convention be for the swapfile
itself so swapon happens automatically?


Also, instead of /@auto/ I'm wondering if we could have
/x-systemd.auto/ ? This makes it more clearly systemd's namespace, and
while I'm a big fan of the @ symbol for typographic history reasons,
it's being used in the subvolume/snapshot regimes rather haphazardly
for different purposes which might be confusing? e.g. Timeshift
expects subvolumes it manages to be prefixed with @. Meanwhile SUSE
uses @ for its (visible) root subvolume in which everything else goes.
And still ZFS uses @ for their (read-only) snapshots.

--
Chris Murphy