https://github.com/vyos/vyatta-cfg/pull/19
This fixes the conf mode completion, at least in the bash cli shell.

@thinkl33t you can run your own DNS server with dynamic update functionality, vyos's dhcp server will write the hostnames to it. Doing that is outside the scope of vyos though, and you'd have to think of security, e.g. can a rogue dhcp client DNS spoof your hostnames to do a MITM attack. Systems that do do dyn-dns updates, for example FreeIPA, usually use some sort of pre-shared keys/certificates on the clients (for authentication) and limit the scope to IP updates on preexisting hostnames only, they don't allow adding arbitrary hostnames. At least I'd limit the scope to add all dynamic dns updates to a single zone predefined expressly for that purpose, and not use that zone for any security-critical applications, like logging in to services or doing unauthenticated connections, where a MITM may scrape your sensitive data. I'd only do dyn-dns hostnames from dhcp on a DHCP network where I'm absolutely sure no rogue client could gain access to it, via the network or physically, and that is almost never useful.

It still fails in config mode:

vyos@vyos# ls <TAB>
  Configuration path [-o] is not valid
  Set failed

This PR fixes it for me: https://github.com/vyos/vyatta-op/pull/29

The same, but on current (jessie):

reset=$(shopt -po noglob); set -o noglob
toks=( $( compgen -d -- "$cur" ) )
eval $reset

when eval is called, it expands to eval 'set -o noglob' which triggers _vyatta_op_run set -o noglob, which chokes on the input.
_vyatta_op_run was set up as alias for "set" in https://github.com/vyos/vyatta-op/blob/66753705b86a3d104dfe127d4dd2b904a54ab404/functions/interpreter/vyatta-op-run#L38

eval alias ${cmd:0:$pos}=\'_vyatta_op_run ${cmd:0:$pos}\'

due to "set" being part of the templates.

Here's the output of set -x redirected to a file when doing "ls <TAB>" as root.

Here's the sanitized dhcp-server config.

On my routers they are definitely missing from /config/dhcpd.leases. I have some static host mappings in the config too. I also confirmed the "on commit set shared-networkname" line is in dhcpd.conf.

+1 to this. I have VyOS running on several serial-console-only devices (they do have a graphics card on the chipset but it has no connector and is disabled in BIOS).
The console works in GRUB and once fully booted (login screen) but the boot console messages (kernel) still go to the video console. I have console device ttyS0 set in config, but every "install system image" resets the GRUB default entry to KVM console.

Adding "tls-crypt" and in the upcoming 2.5 release "tls-crypt-v2" options would also be desirable.

https://github.com/vyos/vyos-1x/pull/116

vyos-1x src/migration-scripts/interfaces/0-to-1 line 41:
https://github.com/vyos/vyos-1x/blob/2f3aa28f259ee7f23ef8a4a091db8ced2202bbd8/src/migration-scripts/interfaces/0-to-1#L41:

# igmp-snooping: check if enabled
igmp_val = config.return_value(base + [br, 'igmp-snooping', 'querier'])

This should be preceded by a if config.exists, as should line 33:

    # STP: check if enabled
        stp_val = config.return_value(base + [br, 'stp'])
`

The interface/0-to-1 migration script is failing on upgrade (T1611).

@c-po The above commits should reference T1556, probably a typo.

Would something like https://openwrt.org/docs/techref/netifd be useful? The drawback that it's dependent on ubus https://openwrt.org/docs/techref/ubus

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?

PR https://github.com/vyos/vyos-1x/pull/91

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.

This is already fixed in the latest rolling images (equuleus).

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...

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.

In T1416#38821, @zsdc wrote:

I have checked behavior in 4.3.5 and 4.4.1 versions. The information about hostname is still not synced from primary to secondary.

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.

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.

I think this is a parser issue

vyos@vyos# set interfaces openvpn vtun0 openvpn-option "route-up \"echo arg1 arg2\""

https://github.com/vyos/vyatta-openvpn/pull/11
Tested working on current rolling

https://github.com/vyos/vyos-1x/pull/77
tested working on rolling (current)

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.

https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdleases#the-dhcpv6-lease-ia-declaration
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.

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)

@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?

https://github.com/vyos/vyos-1x/pull/71

ISC-dhcp can parse this option either as a quoted string or colon-separated hex list. common/tables.c

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).

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.

Creating /var/log/squid (sudo mkdir /var/log/squid) allows the commit to complete.