Ansible to get config and randomly ANSI code in output

Bugs
1

Hello,

We are using Ansible to get config from our VyOS and sometimes some ANSI code are coming in the middle of the output.

It did not happen with 1.2 release but happens now with the latest rolling.

ansible-playbook plbks/get_config.yml | grep “\\u001b[m”

        "                    network-group MGMT\u001b[m",
        "        description VLAN106\u001b[m",

ansible-playbook plbks/get_config.yml | grep “\\u001b[m”

        "set firewall group port-group PG-UDP-DC1 port '123'\u001b[m",
        "                    network-group MGMT\u001b[m",
        "                new enable\u001b[m",

Any idea from where it could come from ?

Thank you for your work and for your help.

jba

2

Could it be that you have by accident included bad characters which VyOS didnt properly sanitize before storing it in its config.boot file?

And does this occur in random or always at the same place in config?

Could you verify this by using something similar to:

grep -i network-group /config/config.boot | hexdump -C

The whitespaces should read 0x20.

3

random

grep -i network-group /config/config.boot | hexdump -C | grep 0x20
grep -i network-group /config/config.boot | hexdump -C | wc
166 3159 13033

The file seems to be clean, it is only when Ansible get it with this ansible commands:

  • name: Get version remote GWxx
    vyos_command:
    commands:
    - show version
    - show configuration commands
    - show configuration
4

So when you fetch it the first time the odd chars shows up at some random places. You fetch the same command again and the odd chars shows now up at different random places?

Sounds like some bad RAM or bad storage is in play here?

5

Yes, different places, randomly.
Not odd chars but ANSI code (reset color) invisible on console or tty but if you redirect on a file, they are on file.

6

There was a discussion at slack regarding failed upgrades (add system image) which seems to be a known thing but hard to replicate since they seem to occur at random.

That is you upgrade to a new version (could be from one to another rolling release) but the configuration fails the migration. If you save the configuration at this point sections will be missing (compared to how the config was before the upgrade).

The workaround for this is (credit Sander) to reapply the upgrade twice (with a reboot in between to the old version) like so:

  1. add system image
  2. reboot
  3. Check if it works or not. Works, then \o/. Fail the goto 4.
  4. reboot into old image selecting it in grub
  5. delete system image
  6. add system image again
  7. reboot
  8. This always works for me ™

A theory is if what you see through ansible could be related to the above?

That is if bogus characters shows up during migration phase of the upgrade then of course that section of the config would fail. But it doesnt explain why reapply the same upgrade would fix this issue.

Is the above something you could test with your installation and see if it resolves anything?

7

Hello,
Thank you for your answer.

I am afraid I perhaps did not explain correctly the issue.

There is no odd chars in config file stored in vyos appliance, therefore no problem occurs during upgrade nor reboot.

It is only when this file is get with ansible command show configuration , then some ANSI reset color code are randomly inserted into.

This issue happens with all last rolling releases and did not with 1.2 release.

8

Maybe this as a band-aid until things are figured out? I’m wondering since xterm supports a subset of ANSI could a different terminal type be used? xterm-mono or VT220?

Snippet of ENV variables 
vyos@vyos:~$ env
CAML_LD_LIBRARY_PATH=/opt/opam/4.07.0/lib/stublibs:/opt/opam/4.07.0/lib/ocaml/stublibs:/opt/opam/4.07.0/lib/ocaml
MANPATH=:/opt/opam/4.07.0/man
XDG_SESSION_ID=770
COMP_WORDBREAKS=
"'><=;|&(
vyos_libexec_dir=/usr/libexec/vyos
vyos_cfg_templates=/opt/vyatta/share/vyatta-cfg/templates
TERM=xterm
SHELL=/bin/vbash
HISTSIZE=10000
vyatta_htmldir=/opt/vyatta/share/html
SSH_CLIENT=192.168.1.150 55241 22
vyatta_datadir=/opt/vyatta/share
OPAM_SWITCH_PREFIX=/opt/opam/4.07.0
vyos_libdir=/opt/vyatta/lib
SSH_TTY=/dev/pts/0
OPAMROOT=/opt/opam
XDG_SESSION_CLASS=user
OCAML_TOPLEVEL_PATH=/opt/opam/4.07.0/lib/toplevel
HISTFILESIZE=10000
USER=vyos
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90: