dhcpcd.sh meant to work?¶

Labels: cleanup, discuss / RFC

jsmeix opened issue at 2024-07-23 10:45:¶

Triggered by
https://github.com/rear/rear/issues/3285#issuecomment-2239071913
I tried to make sense how
skel/default/bin/dhcpcd.sh
is meant to work but I fail to understand it.

As far as I see we at SUSE do no longer provide dhcpcd
at least not in openSUSE Leap but likely since earlier
so I cannot try out dhcpcd with reasonable effort
(I use only dhclient).

In
prep/GNU/Linux/210_include_dhclient.sh
I noticed

# We made our own /etc/dhclient.conf and /bin/dhclient-script files (no need to copy these
# from the local Linux system for dhclient). For dhcpcd we have /bin/dhcpcd.sh foreseen.

In
skel/default/etc/scripts/system-setup.d/58-start-dhclient.sh
there is

        case "$DHCLIENT_BIN" in
            ...
                (dhcpcd*)
                        "$DHCLIENT_BIN" ${DEVICE}
                    ;;

but I think this cannot work
because from plain looking at the code in
skel/default/bin/dhcpcd.sh

if [ $# -lt 2 ]; then
  logger -s -p local0.err -t dhcpcd.sh "wrong usage"
  exit 1
fi

it exits when there are less than 2 arguments.

jsmeix commented at 2024-07-23 11:05:¶

@rear/contributors
could you please (as time permits) have a look here?

schlomo commented at 2024-07-23 17:00:¶

I'm wondering which distros actually use dhcpcd by default instead of dhclient?

jsmeix commented at 2024-07-24 11:57:¶

@pcahyna @lzaoral
do you know if Red Hat or Fedora based distros
may use dhcpcd instead of dhclient?

jsmeix commented at 2024-07-24 12:08:¶

FYI regarding SUSE and openSUSE:

In openSUSE Factory (i.e. SUSE's "head of development"
wherefrom openSUSE Tubleweed gets built)
there is since 11. July 2024 a new package 'dhcpcd'
see
https://build.opensuse.org/package/show/openSUSE:Factory/dhcpcd
and
https://build.opensuse.org/request/show/1185096
where the latter tells about a reason behind:

New dhcp client package to allow replacing of the
deprecated dhclient from dhcp-server in e.g. cloud-init.

So in future SLES versions there will be likely 'dhcpcd'
but that is not something I worry about right now.

When 'dhcpcd' will be in a future SLES version
I will have a look how that actually behaves - but
not earlier because currently I have other things to do
which have higher importance / priority than that.

lzaoral commented at 2024-07-24 12:42:¶

do you know if Red Hat or Fedora based distros may use dhcpcd instead of dhclient?

@jsmeix Yes, they even have to. Our rear packages already use it on Fedora and RHEL 10 because dhclient is removed in RHEL 10 and deprecated in Fedora: https://fedoraproject.org/wiki/Changes/dhclient_deprecation

jsmeix commented at 2024-07-24 12:58:¶

@lzaoral
thank you for your prompt reply!

I think hereby you "won the price" to have a look
how skel/default/bin/dhcpcd.sh is meant to work ;-)

Would you mind when I assign this issue to you?

lzaoral commented at 2024-07-24 13:03:¶

Sure! Me or @pcahyna can take a look. But beware that I have zero knowledge how dhcpcd work. I have just swapped the Requires: in the spec file and it worked automagically with rear out of the box. 😄

jsmeix commented at 2024-07-24 13:04:¶

@lzaoral
my current only problem for the ReaR 3.0 release is
to find out if in skel/default/bin/dhcpcd.sh
sourcing the HostInfoFilePath e.g /var/lib/dhcpcd/dhcpcd-eth0.info
is sufficiently safe - in particular if that may
(by chance, by accident) source third party code?
Cf.
https://github.com/rear/rear/blob/master/usr/share/rear/skel/default/bin/dhcpcd.sh#L24

jsmeix commented at 2024-07-24 13:07:¶

@lzaoral
interestingly - as far as I understand it - your
https://github.com/rear/rear/issues/3295#issuecomment-2247867440
seems to prove that the 'dhcpcd' code in ReaR
"just works" in practice
(regardless that from plain looking at the code
at least I do not understand how it works).

[Export of Github issue for rear/rear.]

#3295 Issue open: How is skel/default/bin/dhcpcd.sh meant to work?¶