<feed xmlns='http://www.w3.org/2005/Atom'>
<title>vyos-1x.git/src/etc, branch 1.4.0-rc2</title>
<subtitle>VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git)
</subtitle>
<id>https://git.amelek.net/vyos/vyos-1x.git/atom?h=1.4.0-rc2</id>
<link rel='self' href='https://git.amelek.net/vyos/vyos-1x.git/atom?h=1.4.0-rc2'/>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/'/>
<updated>2024-01-10T07:11:39+00:00</updated>
<entry>
<title>https: T5902: remove virtual-host configuration</title>
<updated>2024-01-10T07:11:39+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2024-01-06T09:55:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=34eadcf2f74ae57342997bed77ce64bddd34219b'/>
<id>urn:sha1:34eadcf2f74ae57342997bed77ce64bddd34219b</id>
<content type='text'>
We have not seen the adoption of the https virtual-host CLI option.

What it did?
* Create multiple webservers each listening on a different IP/port
  (but in the same VRF)
* All webservers shared one common document root
* All webservers shared the same SSL certificates
* All webservers could have had individual allow-client configurations
* API could be enabled for a particular virtual-host but was always enabled on
  the default host

This configuration tried to provide a full webserver via the CLI but VyOS is a
router and the Webserver is there for an API or to serve files for a local-ui.

Changes

Remove support for virtual-hosts as it's an incomplete and thus mostly useless
"thing". Migrate all allow-client statements to one top-level allow statement.

(cherry picked from commit d0d3071e99eb65edb888c26ef2fdc9e038438887)
</content>
</entry>
<entry>
<title>pki: T5886: add support for ACME protocol (LetsEncrypt)</title>
<updated>2024-01-08T20:11:13+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2024-01-05T21:27:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=f8f51939ae5ad852563cc69c4e2c8c2717318c9c'/>
<id>urn:sha1:f8f51939ae5ad852563cc69c4e2c8c2717318c9c</id>
<content type='text'>
The "idea" of this PR is to add new CLI nodes under the pki subsystem to
activate ACME for any given certificate.

vyos@vyos# set pki certificate NAME acme
Possible completions:
+  domain-name          Domain Name
   email                Email address to associate with certificate
   listen-address       Local IPv4 addresses to listen on
   rsa-key-size         Size of the RSA key (default: 2048)
   url                  Remote URL (default:
                        https://acme-v02.api.letsencrypt.org/directory)

Users choose if the CLI based custom certificates are used
  set pki certificate EXAMPLE acme certificate &lt;base64&gt;
or if it should be generated via ACME.

The ACME server URL defaults to LetsEncrypt but can be changed to their staging
API for testing to not get blacklisted.
  set pki certificate EXAMPLE acme url https://acme-staging-v02.api.letsencrypt.org/directory

Certificate retrieval has a certbot --dry-run stage in verify() to see if it
can be generated.

After successful generation, the certificate is stored in under
/config/auth/letsencrypt. Once a certificate is referenced in the CLI (e.g. set
interfaces ethernet eth0 eapol certificate EXAMPLE) we call
vyos.config.get_config_dict() which will (if with_pki=True is set) blend in the
base64 encoded certificate into the JSON data structure normally used when
using a certificate set by the CLI.

Using this "design" does not need any change to any other code referencing the
PKI system, as the base64 encoded certificate is already there.

certbot renewal will call the PKI python script to trigger dependency updates.

(cherry picked from commit b8db1a9d7baf91b70c1b735e58710f1e2bc9fc7a)

# Conflicts:
#	debian/control
</content>
</entry>
<entry>
<title>T5897: frr should be stopped before vyos-router</title>
<updated>2024-01-04T17:16:52+00:00</updated>
<author>
<name>Date Huang</name>
<email>tjjh89017@hotmail.com</email>
</author>
<published>2024-01-04T10:16:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=d8a66a1022fa2f6b62ca6b09e16756a7440f749d'/>
<id>urn:sha1:d8a66a1022fa2f6b62ca6b09e16756a7440f749d</id>
<content type='text'>
Signed-off-by: Date Huang &lt;tjjh89017@hotmail.com&gt;
(cherry picked from commit 6d16ab081b70bc4ea837b66dfe032ec6bdb563d7)
</content>
</entry>
<entry>
<title>T5474: establish common file name pattern for XML conf mode commands</title>
<updated>2024-01-01T08:25:32+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2023-12-30T22:25:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=c9eaafd9f808aba8d29be73054e11d37577e539a'/>
<id>urn:sha1:c9eaafd9f808aba8d29be73054e11d37577e539a</id>
<content type='text'>
We will use _ as CLI level divider. The XML definition filename and also
the Python helper should match the CLI node.

Example:
set interfaces ethernet -&gt; interfaces_ethernet.xml.in
set interfaces bond -&gt; interfaces_bond.xml.in
set service dhcp-server -&gt; service_dhcp-server-xml.in

(cherry picked from commit 4ef110fd2c501b718344c72d495ad7e16d2bd465)
</content>
</entry>
<entry>
<title>srv6: T591: enable SR enabled packet processing on defined interfaces</title>
<updated>2023-12-21T15:28:52+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2023-12-20T21:38:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=0ee2f8285c81878687a9f92e6a3b0f10c4d75584'/>
<id>urn:sha1:0ee2f8285c81878687a9f92e6a3b0f10c4d75584</id>
<content type='text'>
The Linux Kernel needs to be told if IPv6 SR enabled packets whether should be
processed or not. This is done using

/proc/sys/net/conf/&lt;iface&gt;/seg6_* variables:

seg6_enabled - BOOL
  Accept or drop SR-enabled IPv6 packets on this interface.
  Relevant packets are those with SRH present and DA = local.
  0 - disabled (default)
  not 0 - enabled

Or the VyOS CLI command:
* set protocols segment-routing interface eth0 srv6

(cherry picked from commit 774cc97eda61eb0b91df820797fb3c705d0073d5)
</content>
</entry>
<entry>
<title>vrf: T591: define sysctl setting for net.vrf.strict_mode</title>
<updated>2023-12-21T15:28:51+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2023-12-20T21:25:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=9219b5e2e0f2a9d6aa181fc6bc460459d727f399'/>
<id>urn:sha1:9219b5e2e0f2a9d6aa181fc6bc460459d727f399</id>
<content type='text'>
Enable/Disable VRF strict mode, when net.vrf.strict_mode=0 (default) it is
possible to associate multiple VRF devices to the same table. Conversely, when
net.vrf.strict_mode=1 a table can be associated to a single VRF device.

A VRF table can be used by the VyOS CLI only once (ensured by verify()), this
simply adds an additional Kernel safety net, but a requirement for IPv6 segment
routing headers.

(cherry picked from commit 10701108fecb36f7be7eb7ef5f1e54e63da5fb4e)
</content>
</entry>
<entry>
<title>vti: T5769: restore interface settings on down -&gt; up event</title>
<updated>2023-12-03T14:26:42+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2023-12-02T20:05:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=f11f41d01a9e03fe11a12812fe3b481bd53826c1'/>
<id>urn:sha1:f11f41d01a9e03fe11a12812fe3b481bd53826c1</id>
<content type='text'>
On VTI interface link down the link-local IPv6 address is removed. As soon as
the IPSec tunnel is online again, vti-up-down helper is called which only places
the interface in up state using iproute2 command

    sudo ip link set vti0 up

This does not restore the IPv6 LL address. Instead use vyos.ifconfig to properly
re-initialize the VTI interface using the generic update() method.

(cherry picked from commit d90ca4415bed8ce99c854243dca3036e76497270)
</content>
</entry>
<entry>
<title>mdns: T5723: Always reload systemd daemon before applying changes</title>
<updated>2023-12-01T05:39:38+00:00</updated>
<author>
<name>Indrajit Raychaudhuri</name>
<email>irc@indrajit.com</email>
</author>
<published>2023-11-07T20:03:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=ccee236ee5f60969e07df5578dd1cb95f8573d82'/>
<id>urn:sha1:ccee236ee5f60969e07df5578dd1cb95f8573d82</id>
<content type='text'>
Additionally, templatize system service override and move it to the
runtime path.

(cherry picked from commit eb906739047187c322b6ce9efe7c9479bed9a024)
</content>
</entry>
<entry>
<title>http: T5762: api: make API socket backend communication the one and only default</title>
<updated>2023-11-20T18:22:08+00:00</updated>
<author>
<name>Christian Breunig</name>
<email>christian@breunig.cc</email>
</author>
<published>2023-11-20T09:13:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=3280a153713decf28eb5c564573028df19a4e1b1'/>
<id>urn:sha1:3280a153713decf28eb5c564573028df19a4e1b1</id>
<content type='text'>
Why: Smoketests fail as they can not establish IPv6 connection to uvicorn
backend server.

https://github.com/vyos/vyos-1x/pull/2481 added a bunch of new smoketests.

While debugging those failing, it was uncovered, that uvicorn only listens on
IPv4 connections

vyos@vyos# netstat -tulnp | grep 8080
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      -

As the CLI already has an option to move the API communication from an IP to a
UNIX domain socket, the best idea is to make this the default way of
communication, as we never directly talk to the API server but rather use the
NGINX reverse proxy.

(cherry picked from commit f5e43b1361fb59a9c260739bdb28729d5119507c)
</content>
</entry>
<entry>
<title>op-mode: T5658: add VRF support for "monitor traceroute"</title>
<updated>2023-11-12T09:12:26+00:00</updated>
<author>
<name>bbabich</name>
<email>bbabich@datamossa.com</email>
</author>
<published>2023-11-04T11:23:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.amelek.net/vyos/vyos-1x.git/commit/?id=b1bee9e29ed8f6464e14b577d79a23b5c128ac8a'/>
<id>urn:sha1:b1bee9e29ed8f6464e14b577d79a23b5c128ac8a</id>
<content type='text'>
(cherry picked from commit 07ecc0c33fb32878cac25ec84f2f3a977588f0dd)
</content>
</entry>
</feed>
