Personally I'd use systemd-journald which I think provides the same logging facilities as rsyslog used to, but vyos still runs both. IMO the logging section is a mess and would need a complete rewrite to journal.

@dmbaturin I was aked on slack to report the information via syslog. However the syslog server is not listening on on UDP port 514 on localhost. How would you like to proceed ?
should it be opened (I am not sure where this should be configured) or should the log be written on the drive using the python logging module (as I currently have implemented).

@cpo AFAIU the patches are not right as the code making use of Config() in the verify() section and AFAIU this is against the separation between get_config()

Already possible via Cloud-init. For different environments may be required differently tuned images (data sources, additional tools like guest agents, etc.).

I think I can pinpoint it down to the mesh generation using wireguard. Please see the logs of two failed nodes attached. I dont find older rotations of the log file. Thats all I have.

Looks good. I don't have merge access but this definitely is a fix to an oversight in the build.

@chrismarget we autogenerate list of resolved issues for releases
so tasks names should be with more context

Not really, just make sure you include VyOS 1.3 project so we can track what can be backported
you will need to adjust your PR message to include task number T2239

Did I do the wrong thing by tagging this for vyos-build?

@fetzerms I was mistaken: cfg-stdout.log is logrotated, but not removed on boot, and this is useful info. When you are able to reproduce, please share. I believe the corner case I am seeing is distinct but related to what you are seeing. Thanks.

The automatic helper assignment is enabled in both the LTS and the current rolling releases. The only thing that is needed to make the TFTP working is to allow the udp/69 and "related" traffic.

The automatic helper assignment is enabled in both the LTS and the current rolling releases. The only thing that is needed to make the FTP working is to allow the tcp/21, "related" and "established" traffic.

merged.

@UnicronNL

vyos@R3# run show version all | match strongswan
ii  strongswan                       5.7.2-1                             all          IPsec VPN solution metapackage

But in this case, we have an issue with command

vyos@R3# sudo ip link add tun0 type gretap local 0.0.0.0
RTNETLINK answers: File exists

In old scripts, tunnels were created by following commands

ip tunnel add tun0 local 0.0.0.0 mode gre key 1 ttl 255 tos inherit
ip link set tun0 multicast on allmulticast on up
ip addr add 10.0.0.4/24 broadcast + dev tun0
ip tunnel cha tun0 local 0.0.0.0

@Dmitry @c-po is this an other version of strongswan? or is this the strongswan with dmvpn pathes in from vyos repo?

The main reason for this issue - we can't create properly tunnel

set interfaces tunnel tun0 address 10.0.0.3/24
set interfaces tunnel tun0 encapsulation gre
set interfaces tunnel tun0 local-ip 0.0.0.0
set interfaces tunnel tun0 multicast enable
set interfaces tunnel tun0 parameters ip key 1

@fetzerms I am able to reproduce this, in a manner that's not completely clean, but which will allow me to investigate further. Feel free to add any other details you run across; thanks.

@c-po let me reproduce this locally, I will find an answer.

@Dmitry maybe you have an idea why?

Re: logging, DANOS mounts a permanent /var/log at boot (I think it's shared by all images). If any work on logging is going to be done, /var/log should be mounted before any vyos config migration or load is done so it can be used as the destination for logging.

Note, there is /opt/vyatta/etc/config/vyos-migrate.log (/config/vyos-migrate.log after image installation) that will list failed migration scripts, if any). This is created before /var/log is available, hence the non-canonical location.

Regarding the first question, yes, cfg-stdout.log is cleared on reboot, unfortunately. The commit error logging is currently a mixture of (un-verbose) reporting from the backend, and limited reporting from python; improvements pending. Firstly, if there are migration errors, those need to be investigated; secondly, the error that you initially reported is (generally) related to stale information in the config hierarchy itself, but may be obscuring earlier errors.

If you comment out this line, arp after reboot doesn't lose.

I couldn't find anything in /var/log/vyatta the last few times I've ran into boot-time commit errors. It seems like the python code doesn't log commit errors into a file or syslog, or at least I couldn't find it. I had to log into the console, go into config mode, load the config (usually pre-migration when there are migrator script errors) and commit it, then the errors are printed to the console. Someone can correct me if I'm wrong.

Latest rolling.

sever@vyos-1.3:~$ poweroff in 5
Poweroff is scheduled 2020-04-06 12:02:52
sever@vyos-1.3:~$

I think we can close this task

@dongjunbo Can you send an example?

Commands were rewritten to:

$ reset ip igmp interfaces
$ reset ip multicast route

@c-po the second part of task.
An example, we can't execute analog of this command in the VyOS syntax:

sudo ip link add vxlan11 type vxlan id 11 dstport 8472 local 22.22.22.1 nolearning

We need to add commands for vxlan:

Does this get cleared on each reboot? Because I usually rebooted after it "locked".

Pull request: https://github.com/vyos/vyos-1x/pull/306

In this failure case, there are some expected "failed" lines in /var/log/vyatta/cfg-stdout.log. Although they are not detailed log messages, they may help narrow down the source of the failure, if you could share those.