diskimage-builder/elements/dhcp-all-interfaces/install.d/dhcp-interface@.service

[Unit]
Description=DHCP interface %I
# We want to run after network.target so it doesn't try to bring
# up the interfaces a second time, but network-online should not
# be reached until after we've brought up the interfaces.
After=network.target
Before=network-online.target
Wants=network-online.target

ConditionPathExists=!/etc/sysconfig/network-scripts/ifcfg-%I

[Service]
Type=oneshot
User=root
ExecStartPre=/usr/local/sbin/dhcp-all-interfaces.sh %I
ExecStart=/sbin/ifup %I
RemainAfterExit=true
TimeoutStartSec=DIB_DHCP_TIMEOUT

[Install]
WantedBy=multi-user.target
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803 2014-03-19 18:33:14 +00:00			`[Unit]`
			`Description=DHCP interface %I`
Run dhcp-interface@.service after network.target When we configure dhcp interfaces before network.target has run, network.target will try to bring up those interfaces a second time after our service does so. This causes two issues - first, the network target will always fail because it can't bring up an interface that is already up, and second, when configuring interfaces that don't actually have an available DHCP server it will result in a five minute delay waiting for DHCP on those interfaces. This will also cause the network target to fail and is an unnecessary delay. By moving the dhcp-interface service to run after the network target we avoid both of these problems. network.target will still bring up the interfaces on subsequent boots. This could result in the five minute delay happening on reboots, but the expected use case for interfaces without DHCP is that they would be configured statically on initial deployment so this should be a minor issue. The dhcp-interface service is also configured to run before the network-online target so that services which depend on the network actually being available will not race the DHCP process. A snippet from /var/log/messages on a node with this patch applied is included in the bug to demonstrate the behavior described above. Change-Id: I5cfabf20f920beea52abf4c42362b6f6ac0b37c4 Closes-Bug: 1653812 2017-01-04 16:49:59 +00:00			`# We want to run after network.target so it doesn't try to bring`
			`# up the interfaces a second time, but network-online should not`
			`# be reached until after we've brought up the interfaces.`
			`After=network.target`
			`Before=network-online.target`
			`Wants=network-online.target`
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803 2014-03-19 18:33:14 +00:00
			`ConditionPathExists=!/etc/sysconfig/network-scripts/ifcfg-%I`

			`[Service]`
			`Type=oneshot`
			`User=root`
			`ExecStartPre=/usr/local/sbin/dhcp-all-interfaces.sh %I`
			`ExecStart=/sbin/ifup %I`
			`RemainAfterExit=true`
Make DHCP timeout configurable As noted in the bug, there may be circumstances where a longer timeout than the current default is needed. This patch allows users to tune this timeout for their environment if need be. Change-Id: I173f3dad684894fbc3c27dece5ae15b5f63bae5a Closes-Bug: 1654027 2017-01-04 17:21:03 +00:00			`TimeoutStartSec=DIB_DHCP_TIMEOUT`
DHCP: make udev rules want dhcp-interface@.service Updates the dhcp-all-interfaces element to fix a race with the recent udev rules implementation on Fedora. With the new approach we make the udev rule want (require to startup) a generic dhcp-interface@.service template which can be started individually for each interface that is discovered. The dhcp-interface@.service is setup such that it: 1) It calls dhcp-all-interfaces <iface> directly with a pre-exec script. This creates the ifcfg file right before we need it but avoids the case where network.service might get greedy and try to start it itself. 2) Only runs if the ifcfg script doesn't already exist. This is important because we only need to bootstrap the DHCP configs... Once they exist the network.service will take care of starting them on reboots, upgrades, etc. 3) On initial boot ensure that the initial DHCP interfaces come up after network.service. Since we really only want dhcp-all-interfaces to help bootstrap that haven't already been configured this seems reasonable. 4) We also try to ensure that cloud-init comes up after the DHCP interfaces. Cloud init has a decently long timeout that this wasn't a functional problem but it keeps log file spew down. Change-Id: I71b026f027182aad49c3435bb903e5e38e524685 Closes-bug: #1294803 2014-03-19 18:33:14 +00:00
			`[Install]`
			`WantedBy=multi-user.target`