Run scripts on Vyatta

Recently, I met an “issue” with running scripts on Vyatta.

In one of my Softlayer solutions, I define “backup” and “master” run-transition-scripts to control the routing path selection for HA when Vyatta change VRRP role from “master” to “backup” or “backup” to “master”

set interfaces ethernet eth1 vrrp vrrp-group 1 run-transition-scripts backup ‘/config/scripts/vrrpbackup’ 

set interfaces ethernet eth1 vrrp vrrp-group 1 run-transition-scripts master ‘/config/scripts/vrrpmaster’

The backup and master scripts work as expected.

However, after the above configuration, i found i cant  change the Vyatta configuration any more even after reboot/power off and on.

vyatta@ha1# set system host-name ha

Set failed



vyatta@ha1# delete interfaces ethernet eth1 vrrp vrrp-group 1

Failed to delete specified config path

Delete failed


vyatta@ha1# set protocols bgp 100 neighbor remote-as 103

Set failed


vyatta@ha1# set firewall name vyattafire


vyatta@ha1# commit



vyatta@ha1# discard 

Discard failed


In addition, I tried to restore to factory default but no lucky either. The error message suggest something is wrong at line 47 but i cant see line 47 in the config.boot.default

vyatta@ha1# load /opt/vyatta/etc/config.boot.default

Loading configuration from ‘/config.boot.default’…

Invalid config file (syntax error): error at line 47, text []

Failed to parse specified config file

No configuration changes to commit


vyatta@ha1# cat -n /opt/vyatta/etc/config.boot.default

  1  system {

  2      login {

  3          user vyatta {

  4              authentication {

  5                  encrypted-password “$1$4XHPj9eT$G3ww9B/pYDLSXC8YVvazP0”

  6              }

  7          }

  8      }

  9      syslog {

 10          global {

 11              facility all {

 12                  level notice

 13              }

 14              facility protocols {

 15                  level debug

 16              }

 17          }

 18          user all {

 19              facility all {

 20                  level emerg

 21          }

 22      }

 23      ntp {

 24          server “”

 25          server “”

 26          server “”

 27      }

 28      console {

 29          device ttyS0 {

 30              speed 9600

 31          }

 32      }

 33      config-management {

 34          commit-revisions 20

 35      }

 36  }


 38  interfaces {

 39      loopback lo {

 40      }

 41  }



 44  /* Warning: Do not remove the following line. */

 45  /* === vyatta-config-version: “zone-policy@1:ipsec@4:config-management@1:wanloadbalance@3:dhcp-relay@1:nat@4:quagga@3:qos@1:entitlement@1:pim@1:conntrack@1:conntrack-sync@1:system@7:vrrp@1:firewall@5:webgui@1:dhcp-server@4″ === */

46  /* Release version: VSE6.7R5S1 */

I spent 10+ hours to dig into the “issue”. Finally, I found the below:

It looks like that Vyatta uses “root” account to run scripts although I use “vyatta” account to do my entire configuration.  Once the scripts are implemented and change the Vyatta active configuration, the Vyatta configuration will be locked by the “root” account.

Although the “vyatta” is admin level user which is same as the “root”, the “vyatta” account will be locked out of the active configuration until after a reboot. This is the reason why I cant perform any configuration change after the scripts is implemented.

set system login user root level ‘admin’

set system login user vyatta level ‘admin’

In addition, my scripts will run immediately once the Vyatta is powered on.  So the “vyatta” account will always be locked out of the configuration even after reboot.

The work around/solution which I just found is:

Log in the Vyatta OS CLI by “root” account and perform & commit another change. After that “unlock”, the “vyatta” account will be able to edit the vyatta configuration again.

I have not seen any vyatta doc which talks about my finding. I reported this usability issue to Brocade and hope they can fix this asap.

Update: looks like that the issue is still there in version 6.7 R9

One of my colleague suggest another fix:

Hey. Had a similar problem and found out it’s a problem with the permissions. This solved the issue for me.
sudo chown -R root:vyattacfg /opt/vyatta/config/active/

(what it does, is it changes the owner of the active configuration. With that, it probably resets the permissions to the files and therefore works around the bug that prevents “vyatta” user to do changes)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s