GDB however tells a different story:

vyos@vyos# ps aux | grep cli
root      1624  0.1  1.9  35212 19508 ?        S    12:11   0:00 /bin/cli-shell-api showConfig
root      1684  0.0  0.5   9492  5720 ?        Ss   Feb16   0:00 /sbin/dhclient -4 -nw -cf /var/lib/dhcp/dhclient_eth0.conf -pf /var/lib/dhcp/dhclient_eth0.pid -lf /var/lib/dhcp/dhclient_eth0.leases eth0
vyos      2534  0.0  0.0   6084   892 pts/0    S+   12:22   0:00 grep cli

Seems like the issue manifests in cnode-algorithm.cpp:_diff_print_indent:

Tried to mess around/instrument https://github.com/vyos/vyatta-cfg/blob/current/src/cnode/cnode-algorithm.cpp#L924,
ended up loosing the active config and /opt/vyatta/config/active becoming empty.

It seems that the stall happens in ConfigSession.show_config() which calls /bin/cli-shell-api showConfig.

Created PR: https://github.com/vyos/vyos-1x/pull/731

Tested with:

Possible fix, pending testing: https://github.com/varesa/vyos-1x/commit/4a0504a96cf0f3078e964ed201f196fb55172e00

Pull request to revert that changed line: https://github.com/vyos/vyos-1x/pull/516

Issue only happens if a user is defined without a password, otherwise the correct field gets set:

# Encrypted password
if conf.exists(['authentication', 'encrypted-password']):
    user['password_encrypted'] = conf.return_value(['authentication', 'encrypted-password'])

https://github.com/vyos/vyos-1x/commit/a07e22377ab83104ac925e13d1824f241f0f8d4a#diff-38def27d6150350cf8bd539da90de66b (T2492) seems to have changed the initialization:

Fix in https://github.com/vyos/vyos-documentation/pull/234

Opened a separate task about the incorrect behaviour with the edit-level: T1846

Created a PR with the above change: https://github.com/vyos/vyos-1x/pull/174

This works better:

diff --git a/python/vyos/config.py b/python/vyos/config.py
index 13b2c10..82483cb 100644
--- a/python/vyos/config.py
+++ b/python/vyos/config.py
@@ -137,7 +137,10 @@ class Config(object):
         if self.__session_env:
             p = subprocess.Popen(cmd, stdout=subprocess.PIPE, env=self.__session_env)
         else:
-            p = subprocess.Popen(cmd, stdout=subprocess.PIPE)
+            env = os.environ
+            env['VYATTA_TEMPLATE_LEVEL'] = '/'
+            env['VYATTA_EDIT_LEVEL'] = '/'
+            p = subprocess.Popen(cmd, stdout=subprocess.PIPE, env=env)
         out = p.stdout.read()
         p.wait()
         if p.returncode != 0:

Simple fix could be to just override VYATTA_TEMPLATE_LEVEL and VYATTA_EDIT_LEVEL.

Okay, that doesn't work. It likely requires some variables like these:

VYATTA_ACTIVE_CONFIGURATION_DIR=/opt/vyatta/config/active
VYATTA_CONFIG_TMP=/opt/vyatta/config/tmp/tmp_1929
VYATTA_CHANGES_ONLY_DIR=/opt/vyatta/config/tmp/changes_only_1929
VYATTA_TEMP_CONFIG_DIR=/opt/vyatta/config/tmp/new_config_1929

Seems based on the uses of the Config-class, for example this in vyos-http-api-server:

session = ConfigSession(os.getpid())    
env = session.get_session_env()    
config = vyos.config.Config(session_env=env)

that the intention was to have a clean environment unless called with session_env=something.

Seems like that paths are absolute regardless of the environment variables:

It would be pretty simple to pass VYATTA_{TEMPLATE,EDIT}_LEVEL=/ as environment variables in Config._run():

That is caused by: session_config_text = self._run([self._cli_shell_api, '--show-working-only', '--show-show-defaults', 'showConfig'])

@hagbard That however doesn't fix the issue where the entire config session seems to be invalid if you are not at the top level. After T1758 (commit above) the ConfigTree for session_config only contains nodes under the [edit <node>] level, not the whole config.

Okay, it seems that the major issue here is caused by commit d9ee0b95d1020b6d5412dd011ebb1ef7f6ef3fc7 / [vyos.config] T1758: use vyos.configtree for reading values, instead of calling cli-shell-api.

I just noticed that the contents of that config look awfully lot like the config node ([edit interfaces ethernet eth0]) I was at.

The ConfigTree gets created with config_string:

in configtree.py the function return_value from /usr/lib/libvyosconfig.so.0 gets called with some integer and 'interfaces ethernet'. It returns 'null'

Regardin the interface not being configured:

The original error for reference:

The above PR gets rid of the exception during commit.

https://phabricator.vyos.net/rVYOSONEX3400b1dd79702553ebbd40516bf454f3fe47885b seems to have broken interface configuration. See T1844

Pull request with a fix: https://github.com/vyos/vyos-1x/pull/171

https://github.com/vyos/vyos-documentation/pull/74

Looking at the Jenkinsfile it seems that missing sudo is the only difference:

The place that limits it to only ethernet devices seems to be: https://github.com/vyos/vyatta-cfg-system/blob/crux/templates/interfaces/pseudo-ethernet/node.tag/link/node.def (the checking itself happens at https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/vyatta-interfaces.pl#L377)

I managed to reproduce this earlier. These were the generated iptables rules and pinging from any source IP except the first one did not work. https://phabricator.vyos.net/P66
I could see the responses in tcpdump but they were getting blocked (so I assume. They did not reach the running ping program)

From the man page:

You can put the server into the PARTNER-DOWN state either by using the omshell (1) command or by stopping the server, editing the last peer state declaration in the lease file, and restarting the server.

In T1276#33655, @syncer wrote:

Wondering if we should disable all offload stuff in virtualized environments (which not make sense anyway)

In T1276#33579, @Gislaved wrote:

I have tested this also with putting the DHCP subnet tagged on the interface itself within proxmox. Same problem occures... So removing the server from the vlan.interface doesn't change a thing, I could test with the clients on their own interface (ethX) and add that to the relay section instead of ethX.clientVlanId but I doubt if that works.

So I don't see where do you see that this could not be a bug.

The way ISC DHCP Relay works you need to give it both the upstream and downstream interfaces (e.g. where it will listen to requests and ones where it will talk to the DHCP server). It is also shown (while not explicitly said) in the documentation: https://wiki.vyos.net/wiki/DHCP_relay

In T1276#33553, @byteshifter wrote:

vyos@vyos:~$ sh conf commands
set interfaces ethernet eth0 address '172.16.0.1/24'
[...]
set service dhcp-relay interface 'eth1.40'
set service dhcp-relay interface 'eth1.41'
set service dhcp-relay interface 'eth1.42'
set service dhcp-relay interface 'eth1.100'
set service dhcp-relay interface 'eth1.101'
set service dhcp-relay interface 'eth1.102'
set service dhcp-relay relay-options relay-agents-packets 'discard'
set service dhcp-relay server '172.16.0.10'
[...]

For those of you with issues with DHCP relay and VLANs, have you:

• Added the interface that the DHCP server is reachable on to the service dhcp-relay interface <interface> list?
• Added the sub-interface (e.g. eth0.20) to the interfaces instead of the parent interface (eth0)?

Tested on:

I was asked to test with VRRP, still works fine.

I did not manage to reproduce the issue.

I should note that this is not my issue/task nor am I personally affected by it. I just pointed out that part of the original issue should be solved by my PR which originated from elsewhere and left my two cents about how to handle the other case here.

In T1246#33353, @hagbard wrote:

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

There is open-vpn server push-route or so available. Sooner or later that backend will be rewritten.

What comes to the quoting of openvpn-option --push "xxx", if we do not want to introduce nested quotes to the parser, maybe we should have a second configuration option dedicated to --push?

In T1246#33342, @hagbard wrote:

@varesa so 'server push-route x.x.x.0/24' does work for you?
The double quotes are an issue with the parser and I doubt that if will be allowed in the future again.

In T1246 I noticed that while my fix makes the syntax correct enough that OpenVPN starts, it is actually missing the $variables inside the quotes as the patch changed double quotes to single quotes.
That means that instead of --push "dhcp-option DNS 1.1.1.1" or --push "route 192.168.0.0 255.255.255.0" it started with --push "dhcp-option " and --push "route "

In T1246#33335, @gmurphy42 wrote:

I went ahead and dug out the other configuration that doesn't work in 1.2.0 either. This is pulled from the config.boot file in the vyos 1.2.0 image i have installed.

openvpn vtun1 {
      description clientvpn
      encryption aes256
      hash sha256
      local-port 1194
      mode server
      protocol tcp-passive
      server {
          name-server x.x.x.4
          name-server x.x.x.3
          push-route x.x.x.0/24
          push-route x.x.x.0/24
          subnet x.x.x.0/24
      }
      tls {
          ca-cert-file /config/auth/ca.crt
          cert-file /config/auth/server.crt
          dh-file /config/auth/dh2048.pem
          key-file /config/auth/server.key
      }
      use-lzo-compression
  }

e.g. could indeed be tested to make sure that it works

I think the issue you found might still be a valid one, even though it was not the same one that was originally talked about on IRC.

PR: https://github.com/vyos/vyatta-openvpn/pull/7

Hopefully a fix: https://github.com/varesa/vyatta-openvpn/commit/a0d7c07f1ff0b5fe7450d3a13c1365b8e3589725

Produced command seems to be:

Also managed to reproduce, some set-commands to help reproduction:

Above was on 1.1.7, the same thing happens on 1.1.8:

I don't think the alphabetic order is even relevant (or ansible for that matter). Once you delete a user it frees up the UID but leaves the home directory around with the now unused UID. If you re-create users in a different order the UIDs that still own the home directories no longer match the corresponding users.