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

[edit]

vyatta@ha1# 

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

Failed to delete specified config path

Delete failed

[edit]

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

Set failed

[edit]

vyatta@ha1# set firewall name vyattafire

[edit]

vyatta@ha1# commit

Aborted

[edit]

vyatta@ha1# discard 

Discard failed

[edit] 

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

[edit] 

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 “0.vyatta.pool.ntp.org”

 25          server “1.vyatta.pool.ntp.org”

 26          server “2.vyatta.pool.ntp.org”

 27      }

 28      console {

 29          device ttyS0 {

 30              speed 9600

 31          }

 32      }

 33      config-management {

 34          commit-revisions 20

 35      }

 36  }

 37

 38  interfaces {

 39      loopback lo {

 40      }

 41  }

 42

 43

 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)