- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Dec 7 2023
Now we receive this error in 1.5-rolling-202312060024 when the command is executed:
Dec 6 2023
Dec 5 2023
PR https://github.com/vyos/vyos-1x/pull/2573
set interfaces ethernet eth0 address '192.168.122.14/24' set interfaces ethernet eth0 address '192.168.122.10/24' set interfaces ethernet eth2 address '2001:db8::1/64'
Dec 4 2023
tested on 1.5/1.4 :
Dec 3 2023
tcpdump of internal MPLS interface during initial connection
Adding trace, and monitoring, shows that the rule is never being hit.
PR for 1.4 https://github.com/vyos/vyos-1x/pull/2568
This happened again.
Wouldnt this break things with compatibility with other vendors?
Dec 2 2023
PR 1.5/1.4 : https://github.com/vyos/vyos-1x/pull/2564
@Viacheslav, updated PR https://github.com/vyos/vyos-1x/pull/2562
Looks like, we still need to keep /etc/avahi/services because avahi-daemon chroot to that location at startup. This is set up at build time via AVAHI_CONFIG_DIR and there is no way to change it at runtime.
Cannot pass smoketest, @indrajitr could you re-check?
DEBUG - Running Testcase: /usr/libexec/vyos/tests/smoke/cli/test_service_mdns-repeater.py
DEBUG - test_service_dual_stack (__main__.TestServiceMDNSrepeater.test_service_dual_stack) ... FAIL
DEBUG - test_service_ipv4 (__main__.TestServiceMDNSrepeater.test_service_ipv4) ... FAIL
DEBUG - test_service_ipv6 (__main__.TestServiceMDNSrepeater.test_service_ipv6) ... FAIL
DEBUG -
DEBUG - ======================================================================
DEBUG - FAIL: test_service_dual_stack (__main__.TestServiceMDNSrepeater.test_service_dual_stack)
DEBUG - ----------------------------------------------------------------------
DEBUG - Traceback (most recent call last):
DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/test_service_mdns-repeater.py", line 47, in tearDown
DEBUG - self.assertTrue(process_named_running('avahi-daemon'))
DEBUG - AssertionError: None is not true
DEBUG -
DEBUG - ======================================================================
DEBUG - FAIL: test_service_ipv4 (__main__.TestServiceMDNSrepeater.test_service_ipv4)
DEBUG - ----------------------------------------------------------------------
DEBUG - Traceback (most recent call last):
DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/test_service_mdns-repeater.py", line 47, in tearDown
DEBUG - self.assertTrue(process_named_running('avahi-daemon'))
DEBUG - AssertionError: None is not true
DEBUG -
DEBUG - ======================================================================
DEBUG - FAIL: test_service_ipv6 (__main__.TestServiceMDNSrepeater.test_service_ipv6)
DEBUG - ----------------------------------------------------------------------
DEBUG - Traceback (most recent call last):
DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/test_service_mdns-repeater.py", line 47, in tearDown
DEBUG - self.assertTrue(process_named_running('avahi-daemon'))
DEBUG - AssertionError: None is not true
DEBUG -
DEBUG - ----------------------------------------------------------------------
DEBUG - Ran 3 tests in 11.145s
DEBUG -
DEBUG - FAILED (failures=3)Dec 1 2023
The similar task, leave a link here https://vyos.dev/T3771
Note: Mikrotik's RouterOS can add received IPv6 prefixes to a pool in its DHCPv6 client configuration, then the pool can be configured for DHCPv6 server to hand out addresses or sub-prefixes: https://wiki.mikrotik.com/wiki/Manual:IPv6/DHCP_Client
Nov 30 2023
Nov 29 2023
currently OSPF smoketests fail b/c of https://github.com/FRRouting/frr/issues/14910
Nov 28 2023
You can use GraphQL query. It shows you what does container.py for raw format
set service https api graphql set service https api keys id KID key 'foo'
Query
curl -k --raw 'https://localhost/graphql' \
-H 'Content-Type: application/json' \
-d '{"query":" { ShowImageContainer (data: {key: \"foo\"}) {\n success\n errors\n data {\n result\n }\n}\n}\n"}'For example
Nov 27 2023
Seems like it's the same for the other functions
sudo podman ps --all vs. sudo podman ps --all --format='{{json .}}'
sudo podman network ls vs. sudo podman network ls --format='{{json .}}'
The implementation in file container.py has the command podman image ls which is ok when called from shell.
When called from API it should have been podman image ls --format='{{json .}}'
Seems like I was wrong, the content is returned but not in structured json format.
For further automation it would be nice to have json objects instead of a string which needs to be parsed by the client.