| Age | Commit message (Collapse) | Author |
|---|
|
After migrating from ISC DHCLIENT for IPv6 to wide-dhcp-client the logic which
was present to update /etc/resolv.conf with the DHCP specified nameservers and
also the search domain list was no longer present.
This commit adds a per interface rendered script to inform vyos-hostsd about
the received IPv6 nameservers and search domains.
(cherry picked from commit ece425f0191762638b7c967097accd8739e9103d)
|
|
This is a backport of https://github.com/vyos/vyos-1x/pull/1656.
Note I also changed `ip-down.script.tmpl` to not wait for `systemctl
stop dhcp6c@$iface.service`, because that command is slow and pppd will
kill the ip-down script if it times out.
I didn't see `ip-down.script.tmpl` or its equivalent in the 1.4 branch.
Not sure if there is another mechanism to handle that functionality or
it is missed.
|
|
- Default dhclient script only uses value of `$IF_MERIC` envvar for default route recived via `router` option.
- This variable has no effect on rotes received via `rfc3442-classless-static-routes` option
- Considering that Vyos overrrides `ip` command originating from `dhclient` this can be easily fixed in `iptovtysh()` function by using the `$IF_METRIC` envvar directly in the dhclient hook.
|
|
In case if a CLI configuration is not available, dhclient cannot add
nameservers to a `resolv.conf` file, because `vyos-hostsd` requires that
an interface be listed in the `set system name-server` option.
This commit introduces two changes:
* `vyos-hostsd` service will not be started before Cloud-Init fetch all
remote data. This is required because all meta-data should be available
for Cloud-Init before any of VyOS-related services start since it is
used for configuration generation.
* the `vyos-hostsd-client` in the `dhclient-script` will be used only if
the `vyos-hostsd` is running. In other words - if VyOS services already
started, dhclient changes `resolv.conf` using `vyos-hostsd`; in other
cases - does this directly.
These changes should protect us from problems with DHCP during system
boot if DHCP is required by third-party utils.
|
|
When `dhclient` with the `-x` option is used to stop running DHCP client
with a lease file that is not the same as in the new `dhclient` process,
it requires a `-lf` argument with a path to the old lease file to find
information about old/active leases and process them according to
instructions and config.
This commit adds the option to the `02-vyos-stopdhclient` hook, which
allows to properly process `dhclient` instances started in different
ways.
(cherry picked from commit 393970f9ee5b3dfc58e0e999d3d5941a198b2c6f)
|
|
Backported commits:
13abffe43b2a5c41bb4ec4675c227f6cf1f868da
01158a8eaa574c48c726c20693479e4aa6e18ee6
This allows finding all running dhclient processes properly.
|
|
Since in some cases a dhclient command may not end with an interface name, the
way to find out a list of dhclients running for a current interface was replaced
to catch PIDs regardless of the exact command syntax.
(cherry picked from commit 13abffe43b2a5c41bb4ec4675c227f6cf1f868da)
|
|
(cherry picked from commit dd2eb5e5686655c996ae95285b8ad7eb73d63d0b)
|
|
(cherry picked from commit ce0600e97baec18c1781605f3a80c26d4ed01e2b)
|
|
|
|
|
|
|
|
- vyos-hostsd-client syntax changed
- track changes in changes variable
- call apply only once at the end if any changes were made
- remove 'cli-shell-api existsEffective system disable-dhcp-nameservers'
condition check as the functionality was moved into vyos-hostsd
- remove comparison between old_ and new_ variables as it caused a bug
as the nameservers didn't get updated on renew or system restart,
the dhclient lease file persists across reboots, so on boot the old
variables will contain the values from previous dhclient run so they
will usually be equal to the new variables.
|
|
Several improvements in processing RFC3442 routes (support for route deletion, DHCP RENEW and link-local routes)
|
|
This changeset contains multiple changes in structure, logic, and bugfixes for dhclient-script. It should provide better compatibility with new Debian versions and flexibility in controlling and changing VyOS-related functions.
1. Structure change:
* All VyOS-related functionality was moved from dhclient-script itself to separated hook files.
* Old vyatta-dhclient-hook was moved from vyatta-cfg to vyos-1x.
* This change allows discard dhclient-script replacing and use the original one from Debian without any changes. So, we do not need to track all changes in upstream so carefully.
* To provide compatibility between original dhclient-script and VyOS, two internal commands/functions are repaced in hooks: ip and make_resolv_conf. So, in all places where used ${ip} or make_resolv_conf, actually using VyOS-tuned functions instead original.
* `ip` function is a wrapper, which automatically chooses what to use: transparently pass a command to /usr/sbin/ip, change a route in kernel table or FRRouting config via vtysh.
* `make_resolv_conf` function main logic was copied from current VyOS implementation and use vyos-hostsd-client for making changes
2. Added:
* Logging. Now is possible to log all changes, what is doing by dhclient-script. Logs can be saved to the journal and displayed in stderr (for debugging purposes). By default, logging to the journal is enabled (at least for some time) to provide a way to collect enough information in case if some bug in this new implementation will be found. This can be changed in the 01-vyos-logging file.
3. Fixed/Changed:
* If DHCP lease was expired, released or dhclient was stopped, dhclient-script will try to delete default route from this lease.
* Instead of blindly killing all dhclients in case if FRRouting daemon is not running, now used more intelligent logic:
* dhclients are stopping natively (with all triggers processing), instead of killing;
* dhclient-script will not kill parent dhclient process. This allows to fix the problem when systemd inform about failing to rise up interfaces at early boot stages (used in Cloud-init images);
* dhclient-script will not touch dhclients, which are not related to the current interface or IP protocol version.
* For getting FRRouting daemon status used native way via watchfrr.sh, instead of the previous trick with vtysh accessibility.
* before adding a new route to FRRouting configuration, this route will be deleted from the kernel (if it is presented there). This allows to properly replace routes, added at early boot stages, when FRR not available.
* Routes in FRRouting are adding with "tag 210". This allows protecting static routes, added via CLI, from deletion when old routes are deleting by DHCP.
* DNS servers will be reconfigured only when $new_domain_name_servers are not the same as $old_domain_name_servers. Previously, this was done during each RENEW procedure.
* Replacing MTU for preconfigured one was changed to Python (via vyos.config). The previous version with vyatta-interfaces.pl was obsoleted and seems to be broken.
|
