Re: [systemd-devel] Bouncing interface once chrony is synced

[Mantas Mikulėnas]

On Mon, Jul 10, 2017 at 7:03 PM, Julian Andres Klode  wrote:

> On Wed, Jul 05, 2017 at 10:29:21AM -0500, Ian Pilcher wrote:
> > I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
> > firewall/gateway.  The Banana Pi does not have a persistent clock, so
> > it has no idea what the time is until it is able to sync via NTP.  Thus,
> > the initial DHCP leases that the BPi receives have incorrect expiration/
> > renewal times (since the system can't sync via NTP before it has an IP
> > address - chicken and egg).
>
> Can't you just store the time on shutdown and restore it at boot (e.g.,
> take the time of the journal file) - that is usually close enough, at
> least it works well enough for use cases in openwrt and lede.
>

systemd-timesyncd already does this. I doubt it would help though, since
the clock would be late anyway, and dhclient seems to break if *any* clock
jumps happen at all (unlike e.g. TLS which only needs to know the
approximate time).

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bouncing interface once chrony is synced

[Ian Pilcher]

On 07/10/2017 03:43 AM, Lennart Poettering wrote:

If your DHCP client implementation gets confused by the wallclock not
being steady then this appears to be a bug in the
implementation. Given that there are so many DHCP clients to choose
from, maybe use a different one?


Oh, it's definitely a bug in ISC dhclient:

  https://bugzilla.redhat.com/show_bug.cgi?id=1093803

Switching DHCP clients doesn't exactly sound like a trivial exercise,
however, since it would need to be integrated into the CentOS network
startup scripts; bouncing the interface (inelegant as it is) seems like
the easier option.

This unit file seems to be doing the job for IPv6 (since *something*
seems to be already doing this for IPv4):

  [Unit]
  Description=IPv6 DHCP client for %I
  Requires=chrony-wait.service
  After=chrony-wait.service

  [Service]
  Type=simple
  ExecStartPre=/usr/sbin/dhclient -6 -d -q -x -lf 
/var/lib/dhclient/dhclient6--%I.lease -pf /var/run/dhclient6-%I.pid %I
  ExecStart=/usr/sbin/dhclient -6 -d -q -1 -lf 
/var/lib/dhclient/dhclient6--%I.lease -pf /var/run/dhclient6-%I.pid %I


  [Install]
  WantedBy=multi-user.target

Maybe systemd-networkd ...

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bouncing interface once chrony is synced

[Julian Andres Klode]

On Wed, Jul 05, 2017 at 10:29:21AM -0500, Ian Pilcher wrote:
> I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
> firewall/gateway.  The Banana Pi does not have a persistent clock, so
> it has no idea what the time is until it is able to sync via NTP.  Thus,
> the initial DHCP leases that the BPi receives have incorrect expiration/
> renewal times (since the system can't sync via NTP before it has an IP
> address - chicken and egg).

Can't you just store the time on shutdown and restore it at boot (e.g.,
take the time of the journal file) - that is usually close enough, at
least it works well enough for use cases in openwrt and lede.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bouncing interface once chrony is synced

[Lennart Poettering]

On Wed, 05.07.17 10:29, Ian Pilcher (arequip...@gmail.com) wrote:

> I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
> firewall/gateway.  The Banana Pi does not have a persistent clock, so
> it has no idea what the time is until it is able to sync via NTP.  Thus,
> the initial DHCP leases that the BPi receives have incorrect expiration/
> renewal times (since the system can't sync via NTP before it has an IP
> address - chicken and egg).

DHCP only sends times as relative times, precisely to not require
synchronized clocks.

See RFC2131, section 3.3:

"As clients and servers may not have synchronized clocks, times
are represented in DHCP messages as relative times, to be
interpreted with respect to the client's local clock.
Representing relative times in units of seconds in an unsigned 32
bit word gives a range of relative times from 0 to approximately
100 years, which is sufficient for the relative times to be
measured using DHCP."

If your DHCP client implementation gets confused by the wallclock not
being steady then this appears to be a bug in the
implementation. Given that there are so many DHCP clients to choose
from, maybe use a different one?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bouncing interface once chrony is synced

[Reindl Harald]

Am 05.07.2017 um 17:29 schrieb Ian Pilcher:

I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway.  The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP.  Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).

My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.

Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed.  I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.

Can anyone suggest a way to achieve this?


by just doing the dhcpd stuff on your own, do what ever you need 
"oneshot" in ExecStartPre/ExecStartPost and put the dchclient into 
ExecStart of a Type=forking unit


s[root@srv-rhsoft:~]$ systemctl status network-wan-bridge.service
? network-wan-bridge.service - Network Internet Bridge
   Loaded: loaded (/etc/systemd/system/network-wan-bridge.service; 
enabled; vendor preset: disabled)

   Active: active (running) since Di 2017-07-04 08:47:33 CEST; 1 day 8h ago
 Main PID: 8182 (dhclient)
Tasks: 1 (limit: 512)
   CGroup: /system.slice/network-wan-bridge.service
   ??8182 /usr/sbin/dhclient -4 -H srv-rhsoft -q 
--request-options subnet-mask,broadcast-address,routers,interface-mtu br-wan


Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.

[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-bridge.service
[Unit]
Description=Network Internet Bridge
After=network.service systemd-networkd.service network-online.target

[Service]
Type=forking
ExecStartPre=-/usr/sbin/brctl addbr br-wan
ExecStartPre=-/usr/sbin/brctl stp br-wan off
ExecStartPre=-/usr/sbin/brctl setageing br-wan 600
ExecStartPre=-/usr/sbin/brctl setfd br-wan 5
ExecStartPre=-/usr/sbin/brctl addif br-wan wan
ExecStartPre=-/usr/sbin/brctl addif br-wan vmnet1
ExecStartPre=-/usr/sbin/ifconfig br-wan hw ether 00:50:8D:B5:CC:DE up
ExecStart=/usr/sbin/dhclient -4 -H srv-rhsoft -q --request-options 
subnet-mask,broadcast-address,routers,interface-mtu br-wan

ExecStartPost=-/usr/sbin/ifconfig br-wan -multicast -allmulti
ExecStartPost=-/usr/sbin/ifconfig vmnet1 0.0.0.0 -multicast -allmulti up
ExecStopPost=-/usr/sbin/ifconfig br-wan down
ExecStopPost=-/usr/sbin/brctl delbr br-wan

Restart=always
RestartSec=1

PrivateTmp=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_BROADCAST CAP_NET_RAW
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime 
delete_module fanotify_init finit_module get_mempolicy init_module 
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp 
kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages 
open_by_handle_at perf_event_open pivot_root process_vm_readv 
process_vm_writev ptrace remap_file_pages request_key set_mempolicy 
swapoff swapon umount2 uselib vmsplice 





ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr

InaccessibleDirectories=-/mnt
InaccessibleDirectories=-/mnt/data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Bouncing interface once chrony is synced

[Ian Pilcher]

I am using CentOS 7 (systemd 219) on a Banana Pi as my residential
firewall/gateway.  The Banana Pi does not have a persistent clock, so
it has no idea what the time is until it is able to sync via NTP.  Thus,
the initial DHCP leases that the BPi receives have incorrect expiration/
renewal times (since the system can't sync via NTP before it has an IP
address - chicken and egg).

My first attempt to address this was to add a drop-in to
chrony-wait.service that bounces the WAN interface.

  /etc/systemd/system/chrony-wait.service.d/bounce-wan.conf:

# Bounce the WAN interface once time is synced, ensuring that
# DHCP leases have proper expiration/refresh times.

[Service]
ExecStartPost=/usr/sbin/ifdown eth0.256
ExecStartPost=/usr/sbin/ifup eth0.256

This does bounce the interface at boot time:

  Dec 31 18:00:18 firewall.penurio.us systemd[1]: Starting Wait for 
chrony to synchronize system clock...
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPDISCOVER on 
eth0.256 to 255.255.255.255 port 67 interval 8 (xid=0x38c8bfa7)
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPREQUEST on 
eth0.256 to 255.255.255.255 port 67 (xid=0x38c8bfa7)
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPOFFER from 
70.119.128.1
  Jul 04 13:05:07 firewall.penurio.us dhclient[1336]: DHCPACK from 
70.119.128.1 (xid=0x38c8bfa7)
  Jul 04 13:05:10 firewall.penurio.us dhclient[1336]: bound to 
70.119.136.2 -- renewal in 23274 seconds.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: PRC: Previous 
lease is devoid of active addresses.  Re-initializing.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Solicit on 
eth0.256, interval 1010ms.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: XMT: Request on 
eth0.256, interval 940ms.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Advertise 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: Packet received, 
but nothing done with it.
  Jul 04 13:05:11 firewall.penurio.us dhclient[1431]: RCV: Reply 
message on eth0.256 from fe80::201:5cff:fe77:bc46.
  Jul 04 13:05:20 firewall.penurio.us systemd[1]: Started Wait for 
chrony to synchronize system clock.


Unfortunately, the expected dhclient processes are not running, so the
addresses are never renewed.  I suspect that systemd may be killing
them, because chrony-wait is a oneshot service.

Can anyone suggest a way to achieve this?

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel