What were the steps you used when you upated the pubkey?

When the config was gone, the processes still seemed to be running

Could you provide the log output in a case when DNS servers, received from DHCP appears in resolv.conf? As I understand, it should happen immediately after the boot.
Also, please, check if they are not deleting after the first DHCP lease renewal.

Just a quick note that this issue remains in 1.2.4-epa1

You can via https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27, which just sets the completion help.
For T1845, yes it solves the issue with setting address:port _and_ moves protocol up from facility to host. Do you want me to revert and do 2 commits, which requires then 2 migrations, once for address:port and one to solve the logical issue with protocol. Right now you can set a different protocol for different facilities for the same host.

https://github.com/vyos/vyos-1x/pull/177
https://github.com/vyos/vyatta-cfg-vpn/pull/27

Wrong logic.
Need to return line 108 code

print (cmd.decode (). split (",", 1) [0])

Bug in latest rolling

@zsdc:

Please reopen T1786 in case of further troubles.

I can't so I've reopened this one; I don't have permissions to do this :(

Wha cant the change which adds the completion helper be backported? Git best practice is you should group changes per commit. But in this commit you add the completion helper and also other regexes (BAD!)

I agree. If it works in a way that is consistent with what the command promises, let's use it.

Will interfere with T1845, while I think T1845 should be the backport candidate. Facility is a tag node, protocol has been moved on level up and is host specific. Having the availability to set different port per facility doesn't really make sense.

The fix suggested in the pull request did not resolve the issue as a consequence of T1847. With that issue resolved, we can consider this merge.

https://github.com/vyos/vyos-1x/pull/175

@christopher.crews07
In you example some mistake (2 times vif-s)

This bug is fixed in latest rolling releases 1.3.
Tested on

[email protected]# run show vers
Version:          VyOS 1.3-rolling-201912040242

Thanks

Ah yes, it's taken entirely from the string, my fault I tested with the version you can only use an IP address.

It actually does work, if only by accident

Actually I found out that the address:port wasn't implemented at all even if you were able to set it, it never was used within the config. I have that fixed now (not pushed yet). I also moved that part within the nodes, so it's going to be:

It work for 1.2 version (used systemd-shutdownd.service).
For 1.3 some bug with:

Thank you @kroy,

[email protected]:~$ sudo ip addr add "192.168.1.1/24" dev eth1.100

That command (above) don't correct for vif-s, with sudo you assign ipv4 only to one tag 8021q (Cvlan) .

This should be all of the relevant configs from the ASA side

Do you keep by any chance the ASA configuration you used? If so, would you please share it?

This is reported as resolved by Line2 in parent T1801; the related issue mentioned therein is also resolved by the revised fix in T1801.

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():

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

Can this please be splittet in a host and a port node? Only WireGuard uses this notation all other services have a dedicated port node

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.

If your node exists, you won't see that issue, only if it doesn't. The above PR should fix that, but I have requested a review from @dmbaturin to make sure I don't introduce something into it he doesn't want there.

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.

https://github.com/vyos/vyos-1x/pull/172
should also fix https://github.com/vyos/vyos-1x/pull/171 which wouldn't be required then anymore

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:

@dmbaturin

c.return_value('local-ip') &&  c.return_value(['local-ip'])

would work, shall I rewrite it to a single item list? conf.exists() does only accept s string as argument.

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

Personally I would keep it under the interface itself but @dmbaturin should have the final decission

Yup, I tested almost all parameters we have currently in our cli, works all quite well. So, I'm going to implement it under service then?

If FRR has all we need we should use it - drops one additional dependency

I just tested frr sending RAs, setup manually which works quite well. So, now it needs the determined what path it should go (stay in interface or move out to service) and if we go with frr for it or stay with radvd. I would be in favor of frr.

@Merijn I am consulting with the author of the pull request; I still need to confirm behavior before we can consider merging.

You can announce multiple prefixes with different options. If you leave for each interface all the options need to be generated (like it is right now), or manually setup or generate for vyos-1x. Also you need to consider that you may send RAs on vif and stuff like that only. dup-addr-detect-transmits has not real anything to do with sending RAs.

The resolution in T1801 will prevent the error in this case.

I just have a gut feeling its better suited under the interface instead of a dedicated service. For FRR, have a look into the BFD implementation

• What other nodes will be unter the prefix tagNode?
• How would namesevrers be configured?

The general solution has been merged into vyos-1x.

very basic example (uses default paramaters):

 service {
+    ipv6-ra {
+        interface eth3 {
+            disable
+            prefix 2001:db8:cafe:beef::/64 {
+            }
+            prefix 2001:db8:dead:beef::/64 {
+            }
+        }
+    }

Hmm, that's actually a good point (http://docs.frrouting.org/en/latest/ipv6.html). I started with implementing it as service, it has the advantage that you don't have the duplicated template code. I would lean the towards implementing it for frr rather then using radvd. I currently have set service ipv6-ra interface eth3 ... as CLI path which I would stay with, or should it then be moved into protocol? I'll focus on implementing it for frr, since the CLI path is different the current as well as a new implementation could coexist for testing so we can find the best way out.