- User Since
- Nov 6 2018, 10:08 PM (40 w, 5 d)
Jul 19 2019
I'll set up monitoring, sure.
Can be set to finished on 1.3 Equuleus
That's unfortunate. I've had to restart dns every few days at some clients due to an outage because of this bug. It would be not nice if it were to regress. Is there a way to build on buster with newer packages?
Jul 18 2019
Even if it was allowed, dhcpd would fail to start with the generated config so it shouldn't be a problem? Unless some had their invalid config kept even with broken dhcp-server, which I doubt.
It would be fixed first in current, of course. It's not a priority for me so I won't be tackling it.
Jul 16 2019
This is already fixed in the latest rolling images (equuleus).
Jul 4 2019
Fix is commited in current branch (rolling/Equuleus), it can be tested with the latest rolling build and task status updated.
Also to consider, if going to a different naming scheme: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
mode 802.3ad doesn't support setting a primary interface.
I had a few (one or two) cases where I did a rolling-to-rolling offline migration (installed the new rolling to a clean drive and copied the old config dir into new image's /boot/<image>/rw/) that the interface naming got completely screwed up, creating new eth devices in the config with higher numbers and leaving the config defined ones inactive, I then had to rescue the situation manually on console (don't remember how exactly). I probably should've created a issue then but I was just glad it was over with. Hopefully this does something to improve the situation as I'm now hesitant to do remote upgrades for fear of losing connectivity...
Jun 28 2019
Putting the migration script on hold until I can get sample configs for "service dhcp6-server static-mapping identifier ..." and related host entries in /etc/dhcp/dhcpdv6.conf from an old vyos version with the old vyatta-cfg-dhcp-server scripts.
In particular if it was possible to set quoted strings as identifier which would be set unchanged in dhcpd6.conf, this would necessitate detecting whether the identifier was a quoted string or not, and converting the string to hex. If it wasn't possible to set quoted strings the migration script is not necessary.
Jun 26 2019
I wonder if this was even ever a working feature. Perhaps check the source of isc-dhcp.
As I see from the information in the Debian bug report, it is about the other bug - when hostname not rewritten after offering lease. From the ISC-DHCP changelog:
This corrects an issue where leases that were offered but ignored retained the client hostname from the original client.
Also, I have found another one problem - there is no trigger in the failover mechanism to run external commands, which are using for hostname updates. This means that, even if hostname would be synced via failover, this will be not enough for updating information inside the hosts.
Therefore, due to lack of functionality inside the ISC-DHCP syncing hostnames inside the hosts file via DHCP failover is currently impossible in the VyOS.
Yeah, I'd mark this not-a-bug. Update the documentation to mention hosts file update with failover doesn't maintain consistent state between failover servers.
@zsdc I'm thinking of partially rewriting show_dhcp.py soon. You can wait a few days if it's not urgent.
@dongjunbo please attach your /config/dhcpd.leases as a file so we can test the code against it. You can sanitize it manually of MAC addresses if you prefer.
Since this changed dhcp6.client-id to only accept colon-separated hex lists, configs that still have the strings will fail to apply, leading to nonworking configs.
Should we bump the dhcp-server vyatta-config-version and write a migration script?
Shouldn't there be a separate dhcpv6-server/relay vyatta-config-version? Perhaps the migration script could add those.
Jun 25 2019
I think this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810971
Fixed in isc-dhcp 4.3.4-1 so pulling in newer isc-dhcp should fix it.
Jun 24 2019
I think this is a parser issue
vyos@vyos# set interfaces openvpn vtun0 openvpn-option "route-up \"echo arg1 arg2\""
Tested working on current rolling
tested working on rolling (current)
Jun 23 2019
Tested working on 1.2.0-rolling+201906210337
Still present on 1.2.0-rolling+20190616
Some domains were still working normally while most returned SERVFAIL.
Jun 22 2019
isc-dhcpd can store IANA_DUID either as octal string (default) or hex, as set by lease-id-format parameter.
python-isc-dhcp-leases currently only supports string type, so it internally parses it into hex. We need to parse it again to add colons to unify with isc-dhcp hex format.
If python-isc-dhcp-leases were improved to add hex type support, we could set lease-id-format to hex and do away with all this parsing.
With https://github.com/vyos/vyos-1x/pull/74 tested working on crux.
Jun 21 2019
Looking at the dhcp_server.py for reference, I see the *-parameters were considered to be deprecated:
# HACKS AND TRICKS # # check for 'raw' ISC DHCP parameters configured by users # actually this is a bad idea in general to pass raw parameters # from any user # # deprecate this and issue a warning like we do for DNS forwarding? if conf.exists('shared-network-parameters'): config['network_parameters'] = conf.return_values('shared-network-parameters')
Now I'm not sure whether this would be a welcome addition to dhcpv6 server.
My particular use-case that I considered this for is assigning per-static-mapping DNS server config (manually migrating clients enrolled into a IPA domain means I have to have some clients pointed to old DNS servers and some to new, currently I get by with setting static v6 addresses on the clients)
Jun 16 2019
@c-po Line 115 and 116 of src/conf_mode/dhcpv6_server.py (that generate /etc/default/isc-dhcpdv6-server) still reference the dhcpd6 name and would need to be changed also.
Are you sure we should change all these filenames and the leases filename without migrating it? I guess if you wanted the naming with "dhcpv6" consistent, but IMO it's unnecessary.
The alternative would be to just fix src/op_mode/show_dhcpv6.py and keep the old lease file naming, thus not breaking the cache on upgrade for all users.
I'll create a PR with the version you decide...
Closed PR and reopened in https://github.com/vyos/vyos-1x/pull/72 due to creating a new branch
@c-po The commits only fix the generated config filename, not the one used by dhcpd (set in /etc/default/isc-dhcpdv6-server) so it would probably break the dhcpv6-server. Even if both were updated, that would cause the server to forget all the cached leases on upgrade that are stored in the old leases file as there is no migration script to copy the old filename to new.
Change priority to high as the bug makes DHCPv6 static mappings inoperable.
vyos 1.2.0-rolling+201906161308 has pdns_recursor 4.1.14, should this be marked as fixed?
ISC-dhcp can parse this option either as a quoted string or colon-separated hex list. common/tables.c
Jun 12 2019
After some more investigation, dhcpd6.leases in /config/ and /opt/vyatta/etc/config/ are the same.
In the same config folder there's also dhcpdv6.leases (with the letter "v" before 6) that's a leftover from an older image.
-rw-r--r-- 1 root root 3262 Jun 12 14:55 dhcpd6.leases -rw-r--r-- 1 root root 2615 Jun 12 14:23 dhcpd6.leases~ -rw-r--r-- 1 root root 27726 Jun 12 14:30 dhcpd.leases -rw-r--r-- 1 root root 28072 Jun 12 14:22 dhcpd.leases~ -rwxrwxr-x 1 root vyattacfg 8141 Oct 27 2018 dhcpdv6.leases -rwxrwxr-x 1 root vyattacfg 17618 Oct 27 2018 dhcpdv6.leases~
If I delete these two, I get a nice traceback when running show dhcpv6 server leases:
vyos@vyos:~$ show dhcpv6 server leases Traceback (most recent call last): File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 81, in <module> leases = get_leases(lease_file, state='active') File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 44, in get_leases leases = IscDhcpLeases(lease_file).get() File "/usr/lib/python3/dist-packages/isc_dhcp_leases/iscdhcpleases.py", line 110, in get with open(self.filename) as lease_file: FileNotFoundError: [Errno 2] No such file or directory: '/config/dhcpdv6.leases'
So it seems that at some point the dhcpd leases filename was changed without updating the name everywhere else (and leaving the old files dangling).
May 31 2019
May 4 2019
I've had this bug occur on 1.2.0-rc11, at one site (with moderately high load) at least once a day, and at the second site (with small load) only once after several months.
After upgrading to the latest 1.2.0 rolling release I've had no issues any more, however the bug may still remain.
It may have something to do with DNSSEC setting as the second system that ran flawlessly for months before started doing it immediately after setting dnssec=validate.
Dec 16 2018
Nov 28 2018
Creating /var/log/squid (sudo mkdir /var/log/squid) allows the commit to complete.