Tested with 1.3-rolling-202002091356, the issue is fixed. Thanks!

This is only the login section

login {
    user vyos {
        authentication {
            encrypted-password $6$***
            plaintext-password ""
            public-keys jernej@jernej {
                key ****************
                type ssh-ed25519
            }
        }
        level admin
    }
}

the config version line

/* Warning: Do not remove the following line. */
/* === vyatta-config-version: "broadcast-relay@1:cluster@1:config-management@1:conntrack@1:conntrack-sync@1:dhcp-relay@2:dhcp-server@5:dns-forwarding@2:firewall@5:interfaces@4:ipsec@5:l2tp@1:mdns@1:nat@4:ntp@1:pptp@1:qos@1:quagga@3:snmp@1:ssh@1:system@12:vrrp@2:vyos-accel-ppp@2:wanloadbalance@3:webgui@1:webproxy@2:zone-policy@1" === */
/* Release version: 1.3-rolling-201912110242 */

No, work would be needed to add the necessary logic to VyOS scripts.
This wasn't possible before the version of isc-dhcpd VyOS uses was
updated to one that supported PD length. But now it is at least
possible, before it wasn't possible at all.

I actually suggested using reload/SIGHUP. The problem is the very rapid reloads sent by the vyos script to systemd. start-stop-daemon is handled by systemd in Debian Buster, in Jessie it was still handled by sysvinit so it didn't have any limits. I suppose it uses some default restart limits/timeouts that can otherwise be adjusted in unit/service files. I suppose it could be converted to a native systemd service so the limits can be set if there is a corresponding setting that would fix the issue. Otherwise it'd be better if we don't use systemd to send SIGHUP at all and send the signal direclty to the daemon w/ pid read from pid file. Or switch to using frr for RAs - what's the progress on that?

@rps Great idea. A summary of some brainstorming that we had on Slack with @runar, @rps and @dmitry:

Is this only for crux or also for equuleus? There is also
https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1584
https://phabricator.vyos.net/T291

This is confusing. While NTP used to work (listen on all interfaces) without any listen-address set, now it doesn't. This means any old config without listen-address set will now have a non-working NTP without any warning. There was no migration script to migrate the old behavior to the new. ntp should have a mandatory listen-address if this new behavior is kept.

If this is the issue I would replace the init.d call with systemctl since in 1.3 init.d/radvd is redirected to systemd anyway (maybe the bugs are present in this redirection so it's best to completely avoid it).
1.2 and earlier would still need to call init.d as-is.

VyOS 1.3 (rolling/equuleus) is now based on Debian Buster so has isc-dhcp-client 4.4.1.
According to the manual dhclient now has a command line option

--prefix-len-hint
When used in conjunction with -P, it directs the client to use the given length to use a prefix hint of, "::/length", when requesting new prefixes.

It was added in 4.3.6:
https://ftp.isc.org/isc/dhcp/4.4.1/dhcp-4.4.1-RELNOTES

Added explanation on how to use quotes inside raw parameters to the docs.
https://github.com/vyos/vyos-documentation/pull/163

Confirmed on 1.3-20191213, tcpdump on the router shows no advertisements until radvd is restarted with sudo systemctl restart radvd.

https://github.com/vyos/vyos-build/pull/70

This is fixed/was not present in 1.3-rolling.
1.2 is not possible to fix, the bug is in isc-dhcp which would need to be upgraded to a newer version.

This was discussed previously: https://phabricator.vyos.net/T1129
Use """ which will be replaced with quotes when generating the isc dhcpd config.
https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/dhcp_server.py#L813-L815

Sorry, I misunderstood your issue, indeed adding quotes inside the parameters is not possible now. A reimplementation would be needed.

https://github.com/vyos/vyos-1x/pull/182
We have to ship our own /etc/{init.d,default}/isc-dhcp{v4,v6}-server files since we can't overwrite the ones supplied by the debian package.

The current static-mapping-parameters can be used to add a quoted value, e.g.

static-mapping test {
                    ip-address x.x.x.x
                    mac-address yy:yy:yy:yy:yy:yy
                    static-mapping-parameters "option domain-name-servers 1.1.1.1, 9.9.9.9;"
                }

command

set service dhcp-server shared-network-name dhcpexample subnet 192.0.2.0/24 static-mapping example static-mapping-parameters "option domain-name-servers 192.0.2.11, 192.0.2.12;"

I'm experiencing the same issue of the service failing to start on 1.3.
The installation was first started with the default config in a VM that had a serial port. Then the installation was transferred to a physical machine without a serial port, and the whole /config directory was manually copied from the old installation on that machine. The machine was then rebooted. The result were the same errors in syslog/journal.
I believe the issue is that if the config.boot is manually replaced or edited on disk, the script that would normally be triggered on commit when deleting system console is never triggered, thus the service remains enabled, but there is no system console in the config to delete any more.

Crux needs a backport of show_dhcp.py from current, I fixed this in current

This is related/a duplicate of T1744

The replacement of special characters with backslash decimal happened on upgrade from 1.2.0-rc11 to 1.2.0-rolling+201906231514.

This is present in branches crux and current too, so adding tag for crux.
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f
https://github.com/vyos/vyos-1x/commit/6f954ab56768af9a07d8a1dc086f54ddefa58da7
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f

Via the process of elimination I found the culprit - comments with special characters in them, that at some point in the upgrade cycle got converted into backslash-escped decimal:

description "\197\160" # this was once Š
description "\196\140 \196\141" # Č č

\197\160 is C5 A0 which is U+0160, which was the original character.
So old versions allowed these characters in comments and worked fine with them, then at one point an upgrade converted them to backslash decimal UTF-8, which still worked until at some point they started causing the error.

https://github.com/vyos/vyatta-cfg-system/pull/109

@c-po I can't see the issue here, that seems like normal expected behavior (tabbing gives a list of all possible nodes, even the long ones?)
I agree that if there is a problem, it's for a separate issue and describe what the problem and expected behavior is in more detail there.

@c-po can you provide a way to reproduce your issue?

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)