@commo That's an issue I can't solve. l2tp needs an uplink and needs to be able to reach the destination to exchange protocol information such as the tunnel id.

so I suppose something like: "set service snmp script1 [name path]" would do it?

https://github.com/vyos/vyos-1x/commit/0f354688d7bd63b63fb91faf17a38c77fb05f660

host_name.py has "os.system("systemctl restart rsyslog.service")" which causes the race condition at boot time.

Jun 17 16:57:53 vyos sudo[1417]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/libexec/vyos/conf_mode/host_name.py
Jun 17 16:57:53 vyos sudo[1417]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jun 17 16:57:53 vyos systemd[1]: Stopping System Logging Service...

• Subject: Unit rsyslog.service has begun shutting down
• Defined-By: systemd
• Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
• Unit rsyslog.service has begun shutting down.

Jun 17 16:57:53 vyos systemd[1]: Starting System Logging Service...

• Subject: Unit rsyslog.service has begun with start-up
• Defined-By: systemd
• Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
• Unit rsyslog.service has begun starting up.

Jun 17 16:57:53 vyos systemd[1]: rsyslog.service start request repeated too quickly, refusing to start.
Jun 17 16:57:53 vyos systemd[1]: Failed to start System Logging Service.

• Subject: Unit rsyslog.service has failed
• Defined-By: systemd
• Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
• Unit rsyslog.service has failed.
• The result is failed.

Jun 17 16:57:53 vyos systemd[1]: Unit syslog.socket entered failed state.
Jun 17 16:57:53 vyos systemd[1]: Unit rsyslog.service entered failed state.

start via systemd is required, otherwise if disabled systemd dependency craps out.

https://github.com/vyos/vyos-1x/commit/9b4447f039655b9e24187302b9c4d9bb2116aa99

I'd propose adding letsencrypt support for the certificates, too

Thanks @c-po --- to clarify, I had pointed out this issue with https://github.com/vyos/vyatta-config-migrate/blob/current/migrate/system/3-to-4 earlier in the task, which will be a non-issue once T805: Drop config compatibility with Vyatta Core older than 6.5 is completed. However, since we are not quite ready for that, I will find a current solution.

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

I‘d keep it as it is as it was previously a bug accessibg the wrong file. As DHCP clients usually request their last assigned address not to many systems will break.

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

A preliminary CLI interface has been created:

@jestabro the root cause looks like this line: https://github.com/vyos/vyatta-config-migrate/blob/current/migrate/system/3-to-4#L33-L37

In addition, latest rolling release when beeted from ISO show this behavior in /opt/vyatta/etc/config/config.boot

Using an APU4 board this does not work. ISOLINUX has no serial console set, and the kernel command line seems to have no serial interface either.

Also supported in EdgeOS

Pull request: https://github.com/vyos/vyos-build/pull/48

Could we work around this by implementing an overlay for every commit, with the entire stack of overlays being combined with the root overlay when a save is issued?

https://github.com/jestabro/vyos-1x/tree/load-config

@etfeet you also get

mdadm: WARNING /dev/sda3 and /dev/sda appear to have very similar superblocks.
      If they are really different, please --zero the superblock on one
      If they are the same or overlap, please remove one from the
      DEVICE list in mdadm.conf.

maybe you can try my post above also then?

@jmlccdmd Strange is the superblock on /dev/sda, without uefi we use sda1 for raid and with uefi sda3.
Could you clear the superblock from sda and sdb and maybe try again?

It looks like the check that determines if 'mdadm --zero-superblock' is needed does not work.
Also ill try to get the config in with update-initramfs so that it does not go to md127.

SNMP can be used as a workaround, but it is not suitable for much more than a couple metrics because is it very inefficient. Moreover the prometheus node exporter provide many more metrics out of the box.

In T1416#37376, @c-po wrote:

Unfortunately this was a miss understanding between @zsdc and me, but the provided fix targeted the same direction.

You can scrap SNMP to prometheus. Not sure if you want any gauges not covered by snmp

All you need for ssh keys to work for AMI is to add cloud-init package in configure step:

Unfortunately this was a miss understanding between @zsdc and me, but the provided fix targeted the same direction.

I have ran into this as well where we have a router plugged into a juniper switch, the router loads faster then the juniper so at the moment the router comes up all the interfaces are down, then the switch comes up.

Fix pushed.

It was resolved with https://github.com/vyos/vyatta-cfg-quagga/pull/27/files#diff-2d07759ce6afdf217934849f11a824f6

Is there any chance to get this feature back into 1.2.x? I could heavily use this for management traffic and for pinning tunnels to specific interfaces.

I was looking on this issue. Please find below a description of what I think is the root cause for this issue:

@hagbard
Yes, it is still an issue. I just did some test with my hardware. If all interfaces are disconnected, I can't create the l2tpv3 interface. If I have the interface up and a default route set, I can create a l2tpv3 interface on the system.

It didn't fix my problem. I don't think it is caused by the igb driver.

I've tried upgrade version from 3.8.2 to 3.9.0 by replacing the ddclient executable (downloadable from the official site) in /usr/sbin/ddclient
This version needs also the libdata-validate-ip-perl package installed.
After that, reload the configuration and it works.

In T1416#37304, @c-po wrote:

Please test and verify with latest rolling

@SteveP latest ISO has the driver updates, please test.

Added pull requests:
https://github.com/vyos/vyos-1x/pull/69
https://github.com/vyos/libvyosconfig/pull/2
https://github.com/vyos/vyatta-cfg/pull/18
https://github.com/vyos/vyatta-conntrack/pull/1

build-ami is working for me if I remove disable-password-authentication from the config template and add in a password into the config template. I have come across another issue though. I was able to get it to work in us-east-1 and us-east-2, but I can't deploy into us-gov-west-1. First problem was it couldn't find a debian-jessie image but that was solved by changing the owner from 379101102735 to 256493402735. Now it's throwing an 401 when attempting to list all subnets. I'm guessing that the python code pulled from ansible is configured for a specific region or the cli command used in GovCloud is slightly different. Either way it's not working.

I have added the Documentation: