Wicked DHCP client and ISC DHCP server timezone configuration failing

Hello all,
I’m having an issue with the ISC dhcpd server (4.3.5-lp150.4.2) and the builtin wicked DHCP client (dhcpcd or ISC dhclient are not installed). The configured time service components are not being picked up by the client host/daemons. These are HPC compute nodes so a minimalist configuration is desired, using as many of the native host facilities as possible.

The DHCP server configuration directives:

option ntp-servers;

RFC 4833 Timezone directives

option pcode “EST5EDT4,M3.2.0/02:00,M11.1.0/02:00”;
option tcode “America/New_York”;

The client system utilising the builtin wicked DHCP client is pulling down the standard network stack parameters from the ISC DHCP server, including the NTP server, but not the time zone configuration. The client remains at UTC 00:00.

node7:~ # timedatectl

Local time: Fri 2018-12-28 18:39:59 UTC
Universal time: Fri 2018-12-28 18:39:59 UTC
RTC time: n/a
Time zone: UTC (UTC, +0000)
Network time on: no
NTP synchronized: yes
RTC in local TZ: no

Additionally the legacy NTP daemon does pull down the time server:

node7:~ # systemctl status ntpd

node7 /usr/sbin/start-ntpd[1054]: runtime configuration: server

If chrony is installed, the NTP server is not pulled in by the chrony daemon.

The version of the ISC dhcpd does support the pcode and tcode options, but the wicked DHCP client doesn’t seem to pull them in (and should chrony pull in all of the NTP settings).


– lawrence

A bit of an update.

It would appear that timezone settings are not applied by the system even though the wicked DHCP client pulls the settings down. The ISC DHCP server “pcode” and “tcode” options permitted them to be pulled down successfully.

wickedd-dhcp4 --test eth0


However unless the timezone is explicitly set in YaST the NTP daemon doesn’t apply them. Which brings me to the chrony daemon which doesn’t even use the NTP server from the DHCP server. Considering the YaST ntp-client module installs chrony in favour of ntpd and seems to be deployed with the expectation the ISC DHCP client is installed I would say something has been overlooked with the wicked DHCP client.

Definitely open to feedback if I’ve missed something.

– lawrence

As referenced in the comment to your entry, RFC 4833 describes all(?) its drawbacks which are considerable and includes comment that many if not most DHCP clients may not support the “newer” POSIX terms. It goes on to suggest that the older offset terminology might be supported but describes the drawback to that as well.


  1. RFC 4833 paints a pretty bleak picture for implementing, even if it works won’t support DST automatically, you’ll have to manually modify as necessary (or script the change).

  2. If you’re still interested in implementing and based on your investigation to this point, you can submit a bug to https://bugzilla.opensuse.org. Someone would then evaluate the issue and decide what to do.

  3. I haven’t looked around, don’t know if other DHCP clients are available. Maybe a different client is your solution?



Thank you for the feedback. Some additional notes:

The legacy time-offset option produced the same results with the wicked DHCP client, ntp, and chrony daemons.

option time-offset -18000;

I did attempt to implement the ISC DHCP client (/sbin/dhclient provided by the dhcp-client package in the openSUSE repo), but gleaned the same results. I did not attempt the dhcpcd client as it was not in the standard repo. Moreover I suspect that the installed ISC client was not used as long as wicked was active. I could disable the wickedd-dhcp4, wickedd-dhcp6, and wickedd-auto4 services but as long as the wickedd service was active they would still be invoked unless they were masked. If I assume correctly I would need to install the NetworkManager service before disabling wicked. Any of these options, or modifying the service files, of course seem to inject too much complication when in my opinion the wicked DHCP client (and ntpd and chrony) should use either the deprecated time-offset or RFC 4833 timezone settings distributed by the DHCP server.

All of that said I will offer a sincere thank you for your feedback and that of others if I’ve missed the mark on how this is supposed to work. I do suspect an issue with the wicked DHCP client functionality and the lack of a simple way to disable it in favour of implementing other DHCP clients.

If I don’t hear anything back on this thread that resolves the issue (or my understanding of it :slight_smile: ) by the end of the week I’ll file a bug as suggested.

– lawrence

Just a FYI -
Considering the imperfectness even if you get this working, there may be other solutions to what you want.

So, for instance Active Directory addresses this through Domain Policy (or maybe more likely Machine Policy pushed by the Domain?), which might support Linux through extensions. Other policy based network configuration also might do a better job.


… indeed. My thoughts as well and it may come to using things such as Puppet, Ansible, or Salt configurations to resolve the need.

My use case is attempting to develop HPC compute node deployment techniques using as many distro-agnostic in-band methods as possible. The first layer being to let DHCP do as much node configuration as possible reducing potential configuration management sprawl.

Since this should work I’ll attempt to press getting an answer, technical correction, or submitting a bug report. Even if I end up going out-of-band so to speak for a solution getting the ball rolling for others will still be helpful in the long run.

– lawrence

wicked manual explicitly says that timezone setting update is not implemented. You have two options - add timezone module update to netconfig (which is used by wicked to implement dynamic changes) or write your own system-updater extension. Note that the only extension input format that wcked supports is netconfig anyway, so extending netconfig looks more straightforward.

… ahh. I wasn’t able to find references that confirmed time zone updates were not supported by wicked, but if the manual does state as much and my observations and testing align with that, so 'nuff said :slight_smile: .

Not being a developer myself, currently my only operational options would be:

  • To install NetWork Manager and retest with the ISC DHCP client (again because it is available in the standard repo), understanding that netconfig awareness may still be an issue.
  • Implement the time zone settings on openSUSE using configuration management tools or auto-yast for beuwulf type clusters.

I will still consider submitting an enhancement that wicked on openSUSE support the timezone updates via DHCP and/or provide a mechanism to implement a DHCP client that does.

openSUSE and SLES are my preferred distros for this use case, but I will move on to testing the scope of DHCP functionality on other target distros as well, primarily CentOS.

– lawrence

Third option - use systemd-networkd.

Does this Red Hat bug report have any relevance to your issue? <1024568 – chrony does not obtain DHCP NTP server address.

“/etc/dhcp/dhclient.d/chrony.sh” exists on this Leap 15.0 system – needs that the systemd Network Manager dispatcher service is enabled:



chrony_config() {
        rm -f $SERVERFILE
        if  "$PEERNTP" != "no" ]; then
                for server in $new_ntp_servers; do
                        echo "$server ${NTPSERVERARGS:-iburst}" >> $SERVERFILE
                /usr/share/chrony-helper update-daemon || :

chrony_restore() {
        if  -f $SERVERFILE ]; then
                rm -f $SERVERFILE
                /usr/share/chrony-helper update-daemon || :