diff --git a/docs/blog/posts/2023/instant-srl-labs.md b/docs/blog/posts/2023/instant-srl-labs.md
index 6f917ea7..d8a22155 100644
--- a/docs/blog/posts/2023/instant-srl-labs.md
+++ b/docs/blog/posts/2023/instant-srl-labs.md
@@ -9,7 +9,7 @@ authors:
# Instant SR Linux Labs
-With [containerlab](https://containerlab.dev) we already made it possible to quickly launch labs on demand with just a few commands. You would need to clone a repository with the lab and then call `containerlab deploy` to start the lab.
+[Containerlab](https://containerlab.dev) already made it possible to quickly launch labs on demand with just a few commands. You would need to clone a repository with the lab and then call `containerlab deploy` to start the lab.
Simple enough, but quite often you want to run this simple SR Linux lab to test something quickly using a very basic topology. At times like this it is cumbersome to find and clone the repository and then call `deploy` command. Can we make it even more simple? Yes, we can!
@@ -17,95 +17,180 @@ Simple enough, but quite often you want to run this simple SR Linux lab to test
If we have two steps to start a lab (cloning and calling `deploy`) we can combine them into one step by using two different approaches:
-1. curl the lab definition file from the repository and pipe it to `containerlab deploy` command
-2. provide the github URL to the `deploy` command and [let it do the cloning](https://containerlab.dev/cmd/deploy/#remote-topology-files) for us
+1. provide HTTP(S) URL to the deploy command and let containerlab fetch the clab file and deploy from it
+1. provide GitHub/GitLab URL to the `deploy` command and [let containerlab clone the repo](https://containerlab.dev/cmd/deploy/#remote-topology-files) for us and deploy from it
+2. curl the lab definition file from the repository and pipe it to `containerlab deploy` command
-Both approaches are equally simple and can be used interchangeably, but they have some differences in the way they work. We will cover the `curl` approach as it is more akin to the goals of this post - which is to quickly start a tiny lab with SR Linux.
+These approaches are equally simple, but they have quite distinct powers and limitations. Let's explore them in more detail.
-## Using curl to deploy a lab
+/// warning
+These features require [containerlab v0.48.2](https://containerlab.dev/install/) or later.
+///
-The workflow boils down to getting the lab definition file contents from a remote location and pipe it to `containerlab deploy` command. Since most labs are stored in git repositories, using `curl` is likely the most convenient way to get the file contents.
+## Using HTTP(S) URL
-```bash title="using stdin to deploy a lab"
-curl some.url | containerlab deploy -c -t -
+Deploying a lab from a remote HTTP(S) URL is the simplest way to get a lab up and running. All you need to do is to provide the URL to the `deploy` command and containerlab will fetch the file and deploy from it.
+
+```bash title="Deploying a lab from a remote URL"
+sudo clab deploy -c -t https://srlinux.dev/clab-srl
```
-Since we wanted to let our users deploy basic SR Linux labs using a memorizable command, we created the following topology files hosted in the containerlab repository:
+
-=== "Single SR Linux node"
- This lab defines a single SR Linux node named `clab-srl`. This lab is meant for users who just want to quickly test something on a single SR Linux node.
+When deploying a clab file from a remote URL containerlab will download the clab file to a temporary directory - `/tmp/.clab` - and then perform a deploy command using the downloaded file. The temporary file will be deleted when the lab is destroyed with the cleanup flag provided.
- ```yaml
- --8<-- "https://raw.githubusercontent.com/srl-labs/containerlab/main/lab-examples/srl-quickstart/srl01.clab.yml"
- ```
+/// details | Where exactly is my topology file?
+The lab file is downloaded to a temporary location as can be verified with the `containerlab inspect --all` command:
+
+```note
+$ containerlab inspect --all
++---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
+| # | Topo Path | Lab Name | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
++---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
+| 1 | ../../../tmp/.clab/topo-288756812.clab.yml | srl | srl | 6b5cad8a221d | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
++---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
+```
-=== "Two SR Linux nodes"
- This lab defines two SR Linux nodes named `clab-srl1` and `clab-srl2` connected with two links. In this lab users can test protocol interactions between two SR Linux nodes.
+///
- ```yaml
- --8<-- "https://raw.githubusercontent.com/srl-labs/containerlab/main/lab-examples/srl-quickstart/srl02.clab.yml"
- ```
+Using HTTP-based lab deployment technique opens up a door to quickly deploy simple SR Linux labs with a single **mermorizable** command. This is handy when you need to quickly test something on SR Linux or demonstrate a feature to a colleague.
-And here is how you can deploy an Single node SR Linux lab with an easy to remember command:
+### Single node SR Linux lab
-```{.bash .no-select}
-curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -
+Here is the lab definition file that we used in the above example:
+
+```yaml
+--8<-- "https://raw.githubusercontent.com/srl-labs/containerlab/main/lab-examples/srl-quickstart/srl01.clab.yml"
+```
+
+As you can see, it is a simple single-node lab with SR Linux node named `srl`. This lab is meant for users who just want to quickly test something on a single SR Linux node and doesn't require any networking part to be configured.
+
+The command can even be shortened further to:
+
+```
+sudo clab dep -c -t srlinux.dev/clab-srl
+```
+
+Once the lab is deployed you can type in `ssh srl` and get access to the SR Linux shell. Easy!
+
+#### Parametrization
+
+An attentive reader might have noticed that the lab definition file contains some environment variables. They allow to parametrize the lab definition file and change the SR Linux version or the type of the node.
+
+If you deploy the commands as we did a few moments ago, the lab will be deployed with the default parameters:
+
+* `ghcr.io/nokia/srlinux:latest` image will be used
+* `ixrd3l` type will be used
+* lab prefix is removed
+
+If you wish to change the SR Linux version or the type, you can do so by providing the env vars to the `containerlab` command:
+
+```bash title="Deploying a lab with a different image and type"
+SRL_VERSION=23.10.1 SRL_TYPE=ixrd2 \
+sudo containerlab deploy -c -t srlinux.dev/clab-srl
+```
+
+Since the default value for the lab prefix is an empty string, the node name (as well as container name) will be just `srl`. This makes it easy to connect to the node with `ssh srl` command, but if you want to deploy multiple labs with the same topology, you will need to change the prefix to avoid name collisions. Simply set `CLAB_PREFIX` variable to any value you want.
+
+### Two-node SR Linux lab
+
+In exactly the same spirit as the single-node lab, we thought it would be cool to have two SR Linux nodes connected back-to-back together. This lab can be deployed as:
+
+```
+sudo clab deploy -c -t https://srlinux.dev/clab-srl2
```
-??? "Where is my topology downloaded to?"
- The lab file is downloaded to a temporary location as can be verified with the `containerlab inspect --all` command:
+This lab deploys nodes `srl1` and `srl2` and provides the same environment variables to parametrize the lab definition file.
+
+### Limitations
+
+The limitations of this approach is that clab file can not have external files used in the lab definition. For example, if you have a lab definition that relies on bind mounting of local files, you will not be able to deploy it from a remote URL. But thankfully we have a way to deploy labs from git repositories :wink:
+
+## Using Git URL
+
+Containerlab [added support](https://containerlab.dev/cmd/deploy/#git) for GitHub/GitLab URLs provided to the `deploy` command. The linked documentation article explains how different flavors of git URLs can be used to deploy labs from managed git repositories.
+
+What is important for us here, is that we can now deploy full-blown labs by simply copying URL of the lab repository from the browser. Here is how it works:
+
+
+
+
+
+Because containerlab will clone the repository, the limitations of the previous approach are not applicable here. Your repository will be cloned in its entirety and therefore you will have access to all the files that are part of the repository. For example, deploying the SR Linux Streaming Telemetry Lab is as simple as:
- ```note
- $ containerlab inspect --all
- +---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
- | # | Topo Path | Lab Name | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
- +---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
- | 1 | ../../../tmp/.clab/topo-288756812.clab.yml | srl | srl | 6b5cad8a221d | ghcr.io/nokia/srlinux:latest | nokia_srlinux | running | 172.20.20.2/24 | 2001:172:20:20::2/64 |
- +---+--------------------------------------------+----------+------+--------------+------------------------------+---------------+---------+----------------+----------------------+
- ```
+```bash title="Deploying a lab from a git repository"
+sudo clab dep -c -t https://github.com/srl-labs/srl-telemetry-lab
+```
-Now you can type in `ssh srl` and get access to the SR Linux shell. Easy!
+
-In the same spirit you can deploy a two-node SR Linux lab with a similar command (watch out for the `clab-srl2` name in the URL):
+/// tip | Did you know?
+For GitHub-hosted repos you can shrink the URL down to just as `user/repo`, for example:
-```{.bash .no-select}
-curl -sL srlinux.dev/clab-srl2 | containerlab deploy -c -t -
+```
+sudo clab dep -c -t srl-labs/srl-telemetry-lab
```
-## Parametrizing the lab
+///
-If you run the above commands as is, the labs will be deployed with the default parameters:
+## Using `curl`
-* `ghcr.io/nokia/srlinux:latest` image will be used
-* `ixrd3l` type will be used
+And then lastly, you can use `curl`, `wget` or any other HTTP client to fetch the clab file and pipe it to `containerlab deploy` command. That way you can provide custom proxies to the HTTP client if required.
-If you wish to change the SR Linux version or the type, you can do so by providing the env vars to the `containerlab` command:
+For example, deploying the same single-node SR Linux lab with `curl` can be done as:
-```bash title="Deploying a lab with a different image and type"
-curl -sL srlinux.dev/clab-srl | \
-SRL_VERSION=23.3.2 SRL_TYPE=ixrd2 \
-containerlab deploy -c -t -
+```bash title="Deploying a lab from a remote URL with curl"
+curl -sL srlinux.dev/clab-srl | sudo clab deploy -c -t -
```
## Summary
-In this post we showed how to quickly deploy a single or two-node SR Linux lab using a simple command. Anywhere you are you can just type in `curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -` and get a lab up and running in a matter of seconds.
+In this post we showed different ways to quickly deploy a single or two-node SR Linux lab using a simple, memorizable commands. Anywhere you are, you can just type in `curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -` and get a lab up and running in a matter of seconds.
+
+We identified which limitations deployment from a remote URL has and how to overcome them by deploying labs from git repositories. Giving the flexibility in options whilst keeping the simplicity of the deployment process is what makes containerlab a great tool for SR Linux labs in particular and networking labs in general.
diff --git a/docs/blog/posts/2023/srlgpt.md b/docs/blog/posts/2023/srlgpt.md
index ed8cec0e..aafb7597 100644
--- a/docs/blog/posts/2023/srlgpt.md
+++ b/docs/blog/posts/2023/srlgpt.md
@@ -4,6 +4,7 @@ tags:
- ndk
- ai
- chatgpt
+ - media
authors:
- ejames
---
@@ -76,11 +77,12 @@ Additionally, in today's release we only support using OpenAI's LLM and you must
[[[% import 'macros.html' as macros %]]]
[[[ macros.srl_version('23.7.1') ]]]
+[[[ macros.clab_version('0.48.2') ]]]
OK, so to demonstrate SR Linux GPT app we will use Containerlab (min version 0.47.1) and spin up a very simple single node SR Linux topology:
```bash
-curl -sL srlinux.dev/clab-srl | containerlab deploy -c -t -
+sudo containerlab deploy -c -t srlinux.dev/clab-srl
```
Wait ~20 seconds for the lab to deploy and SSH into the node:
@@ -119,108 +121,122 @@ There are two different package formats that SR Linux uses:
Depending on which version of SR Linux you're running you will need to run the relevant installation command:
-=== "APT (deb)"
- ```srl
- --{ running }--[ ]--
- A:srl# bash sudo apt install -y srlgpt
- ```
+/// tab | APT (deb)
-=== "YUM (rpm)"
- To speed things up in YUM/rpm system we will disable all the repos except for the one that contains the `srlgpt` package.
+```srl
+--{ running }--[ ]--
+A:srl# bash sudo apt update && sudo apt install -y srlgpt
+```
- ```srl title="paste this two-line command into your CLI"
- --{ running }--[ ]--
- A:srl# bash sudo yum install -y --disablerepo=* --enablerepo=srlinux srlgpt
- ```
+In case APT index update is taking too long, use the following command to only update the custom repository:
+
+```
+bash sudo apt -o Dir::Etc::sourcelist=sources.list.d/srlinux.list -o Dir::Etc::sourceparts=- -o APT::Get::List-Cleanup=0 update && sudo apt install srlgpt
+```
+
+///
+/// tab | YUM (rpm)
+To speed things up in YUM/rpm system we will disable all the repos except for the one that contains the `srlgpt` package.
+
+```srl title="paste this two-line command into your CLI"
+--{ running }--[ ]--
+A:srl# bash sudo yum install -y --disablerepo=* --enablerepo=srlinux srlgpt
+```
+
+///
Wait a few seconds for the app to download and install. It is that simple!
-??? "Alternative installation options"
- If you want to install SR Linux GPT app on a hardware device, or a virtual device that is run by a different orchestrator, you can download the SR Linux GPT application package and `scp` it to your SR Linux device.
-
- !!!note
- SR Linux GPT uses some advanced CLI capabilities that we added in 23.7.1, therefore you need to be running 23.7.1 or later.
-
- === "Install RPM"
- Up until release 23.10 SR Linux used to run Centos-based Linux OS with RPM package manager.
-
- ```bash
- curl -L https://gitlab.com/rdodin/pics/-/wikis/uploads/5b5a3eab3e14229d484a35dcd2f23264/srlgpt_1.0.99_linux_amd64.rpm \
- -o /tmp/srlgpt.rpm && scp /tmp/srlgpt.rpm clab-srl-srl: #(1)!
- ```
-
- 1. In the example the SR Linux node is named `clab-srl-srl`, replace with the name/address you have.
-
- === "Install DEB"
- Starting from 23.10 version, SR Linux uses Debian-based Linux OS with DEB package manager.
-
- ```bash
- curl -L https://gitlab.com/rdodin/pics/-/wikis/uploads/19637b56a042c6d6aaa51072e3fefa55/srlgpt_1.0.99_linux_amd64.deb \
- -o /tmp/srlgpt.deb && scp /tmp/srlgpt.deb clab-srl-srl: #(1)!
- ```
-
- 2. In the example the SR Linux node is named `clab-srl-srl`, replace with the name/address you have.
-
- Now install the copied package by opening a bash shell and running the relevant command for the package manager used in your SR Linux version.
-
- ```bash
- docker exec -it clab-srl-srl bash
- ```
-
- ```bash
- [admin@srl ~]$ sudo rpm -i srlgpt.rpm #(1)!
- ```
-
- 1. Replace with `sudo dpkg -i srlgpt.deb` if you're using DEB package manager.
-
- Now enter SR Linux CLI and reload `app_mgr` so that it can read the new application YANG models:
-
- ```
- [root@srl /]# sr_cli
- Using configuration file(s): []
- Welcome to the srlinux CLI.
- Type 'help' (and press ) if you need any help using this.
- --{ running }--[ ]--
- A:srl# tools system app-management application app_mgr reload
- ```
-
- We need to get into a new CLI session to pickup on the newly installed CLI plugin and configuration tree. So close the existing session and open a new one:
-
- ```srl
- ❯ ssh admin@clab-srl-srl
-
- ................................................................
- : Welcome to Nokia SR Linux! :
- : Open Network OS for the NetOps era. :
- : :
- : This is a freely distributed official container image. :
- : Use it - Share it :
- : :
- : Get started: https://learn.srlinux.dev :
- : Container: https://go.srlinux.dev/container-image :
- : Docs: https://doc.srlinux.dev/23-7 :
- : Rel. notes: https://doc.srlinux.dev/rn23-7-1 :
- : YANG: https://yang.srlinux.dev/v23.7.1 :
- : Discord: https://go.srlinux.dev/discord :
- : Contact: https://go.srlinux.dev/contact-sales :
- ................................................................
-
- Last login: Mon Oct 9 21:24:47 2023 from 2001:172:20:20::1
- Using configuration file(s): []
- Welcome to the srlinux CLI.
- Type 'help' (and press ) if you need any help using this.
- --{ running }--[ ]--
- A:srl#
- ```
-
- !!!note "Configuring DNS servers"
- For SR Linux GPT app to reach out to OpenAI API you need to configure DNS servers on your SR Linux device ensuring that DNS resolution works. Containerlab does that on your behalf, but if you don't use it you have to configure it manually. It might depend on your infra, but usually configuring public DNS servers works just fine:
-
- ```srl title="paste this into your CLI"
- enter candidate
- system dns network-instance mgmt server-list [ 1.1.1.1 ]
- commit now
- ```
+//// details | Alternative installation options
+If you want to install SR Linux GPT app on a hardware device, or a virtual device that is run by a different orchestrator, you can download the SR Linux GPT application package and `scp` it to your SR Linux device.
+
+!!!note
+ SR Linux GPT uses some advanced CLI capabilities that we added in 23.7.1, therefore you need to be running 23.7.1 or later.
+
+/// tab | Install RPM
+Up until release 23.10 SR Linux used to run Centos-based Linux OS with RPM package manager.
+
+```bash
+curl -L https://gitlab.com/rdodin/pics/-/wikis/uploads/5b5a3eab3e14229d484a35dcd2f23264/srlgpt_1.0.99_linux_amd64.rpm \
+-o /tmp/srlgpt.rpm && scp /tmp/srlgpt.rpm clab-srl-srl: #(1)!
+```
+
+1. In the example the SR Linux node is named `clab-srl-srl`, replace with the name/address you have.
+///
+/// tab | Install DEB
+Starting from 23.10 version, SR Linux uses Debian-based Linux OS with DEB package manager.
+
+```bash
+curl -L https://gitlab.com/rdodin/pics/-/wikis/uploads/19637b56a042c6d6aaa51072e3fefa55/srlgpt_1.0.99_linux_amd64.deb \
+-o /tmp/srlgpt.deb && scp /tmp/srlgpt.deb clab-srl-srl: #(1)!
+```
+
+2. In the example the SR Linux node is named `clab-srl-srl`, replace with the name/address you have.
+///
+
+Now install the copied package by opening a bash shell and running the relevant command for the package manager used in your SR Linux version.
+
+```bash
+docker exec -it clab-srl-srl bash
+```
+
+```bash
+[admin@srl ~]$ sudo rpm -i srlgpt.rpm #(1)!
+```
+
+1. Replace with `sudo dpkg -i srlgpt.deb` if you're using DEB package manager.
+
+Now enter SR Linux CLI and reload `app_mgr` so that it can read the new application YANG models:
+
+```
+[root@srl /]# sr_cli
+Using configuration file(s): []
+Welcome to the srlinux CLI.
+Type 'help' (and press ) if you need any help using this.
+--{ running }--[ ]--
+A:srl# tools system app-management application app_mgr reload
+```
+
+We need to get into a new CLI session to pickup on the newly installed CLI plugin and configuration tree. So close the existing session and open a new one:
+
+```srl
+❯ ssh admin@clab-srl-srl
+
+................................................................
+: Welcome to Nokia SR Linux! :
+: Open Network OS for the NetOps era. :
+: :
+: This is a freely distributed official container image. :
+: Use it - Share it :
+: :
+: Get started: https://learn.srlinux.dev :
+: Container: https://go.srlinux.dev/container-image :
+: Docs: https://doc.srlinux.dev/23-7 :
+: Rel. notes: https://doc.srlinux.dev/rn23-7-1 :
+: YANG: https://yang.srlinux.dev/v23.7.1 :
+: Discord: https://go.srlinux.dev/discord :
+: Contact: https://go.srlinux.dev/contact-sales :
+................................................................
+
+Last login: Mon Oct 9 21:24:47 2023 from 2001:172:20:20::1
+Using configuration file(s): []
+Welcome to the srlinux CLI.
+Type 'help' (and press ) if you need any help using this.
+--{ running }--[ ]--
+A:srl#
+```
+
+/// note | Configuring DNS servers
+For SR Linux GPT app to reach out to OpenAI API you need to configure DNS servers on your SR Linux device ensuring that DNS resolution works. Containerlab does that on your behalf, but if you don't use it you have to configure it manually. It might depend on your infra, but usually configuring public DNS servers works just fine:
+
+```srl title="paste this into your CLI"
+enter candidate
+ system dns network-instance mgmt server-list [ 1.1.1.1 ]
+commit now
+```
+
+///
+////
### Configuring SR Linux GPT App
@@ -277,3 +293,8 @@ And for a deep dive into the SR Linux GPT app, check out Erwan James' appearance
+
+and a demo of the SR Linux GPT app in action at NFD33:
+
+
+
diff --git a/docs/blog/posts/2023/sshx.md b/docs/blog/posts/2023/sshx.md
new file mode 100644
index 00000000..c6f2267b
--- /dev/null
+++ b/docs/blog/posts/2023/sshx.md
@@ -0,0 +1,73 @@
+---
+date: 2023-11-07
+tags:
+ - sr linux
+ - ssh
+authors:
+ - rdodin
+---
+
+# Sharing SR Linux Terminal with SSHX
+
+Countless times I've been in a situation where I needed to share my terminal with someone or being asked to connect to someone's device instead.
+
+Either I exhausted my networking foo and needed help from a colleague, or I was the one who was asked to help. In both cases, the problem was the same - how to **quickly**, **securely**[^1] and **effortlessly** share the terminal with someone else.
+
+The problem is not new and there are many options on the table. From installing a VPN software and sharing the credentials, through zero-trust solutions like [teleport](https://goteleport.com/), to using a simple SSH tunnel. All of these solutions are great, but they require some setup and configuration. And sometimes you just want to share your terminal with someone without going through the hassle of setting up a VPN or a zero-trust solution.
+
+The [sshx.io](https://sshx.io) open-source service that [just](https://twitter.com/ekzhang1/status/1721288674204131523) popped out offers a simple solution to this problem.
+
+1. Install the multi-arch lightweight[^2] `sshx` binary on your machine
+2. Run `sshx`
+3. Share the URL with someone
+4. Enjoy collaborative terminal in a responsive web UI with a multi panel canvas
+
+I felt an immediate urge to try it out with SR Linux. And it worked like a charm!
+
+
+
+
+
+
+
+It is super easy to bring `sshx` to SR Linux, here is a quick demo environment that you can spin up to try it out:
+
+1. Deploy a single-node SR Linux lab
+
+ ```
+ curl -sL srlinux.dev/clab-srl | sudo clab dep -c -t -
+ ```
+
+2. Login to the newly-created `srl` node
+
+ ```
+ ssh srl
+ ```
+
+3. In the SR Linux terminal go to `bash` and install `sshx`
+
+ ```srl
+ --{ running }--[ ]--
+ A:srl# bash
+ [admin@srl ~]$
+ ```
+
+4. Install `sshx`
+
+ ```bash
+ [admin@srl ~]$ curl -sSf https://sshx.io/get | sh
+ ```
+
+5. Run `sshx`, grab a link and pop up the Web UI with the terminal
+
+ ```bash
+ [admin@srl ~]$ sshx
+
+ sshx v0.2.0
+
+ ➜ Link: https://sshx.io/s/bRPTeBxXiY#YKcwyLj03r0tik
+ ➜ Shell: /bin/bash
+ ```
+
+[^1]: Usual security measures apply. Vet the installation binary, keep a vetted copy of the binary, etc.
+[^2]: The binary is around 3MB in size
diff --git a/docs/get-started.md b/docs/get-started.md
index 21bb96fb..192d0a1e 100644
--- a/docs/get-started.md
+++ b/docs/get-started.md
@@ -44,7 +44,7 @@ Let's explore the different ways you can launch SR Linux container.
```shell
sudo docker run -t -d --rm --privileged \
-u 0:0 \
- -v srl23-7-1.json:/etc/opt/srlinux/config.json \ #(1)!
+ -v srl23-7-1.json:/etc/opt/srlinux/config.json \#(1)!
--name srlinux ghcr.io/nokia/srlinux:23.7.1 \
sudo bash /opt/srlinux/bin/sr_linux
```
diff --git a/docs/images/srl-icong-1.svg b/docs/images/srl-icong-1.svg
new file mode 100644
index 00000000..fa26a865
--- /dev/null
+++ b/docs/images/srl-icong-1.svg
@@ -0,0 +1,5 @@
+
+
\ No newline at end of file
diff --git a/docs/ndk/guide/agent.md b/docs/ndk/guide/agent.md
index fe454076..278be2ef 100644
--- a/docs/ndk/guide/agent.md
+++ b/docs/ndk/guide/agent.md
@@ -30,8 +30,9 @@ The "cost" associated with requiring users to write YANG models for their apps p
And secondly, the YANG modules for custom apps are not that hard to write as their data model is typically relatively small.
-!!!note
- The YANG module is only needed if a developer wants their agent to be configurable via any management interfaces or keep state.
+///note
+The YANG module is only needed if a developer wants their agent to be configurable via any management interfaces or keep state.
+///
YANG files related to an agent are typically located by the `/opt/$agentName/yang` path.
@@ -51,88 +52,93 @@ Custom agents must have their config file present by the `/etc/opt/srlinux/appmg
Through the subsequent chapters of the Developers Guide, we will cover the most important options, but here is a complete list of config file parameters:
-???info "Complete list of config files parameters"
- ```yaml
- # Example configuration file for the applications on sr_linux
- # All valid options are shown and explained
- # The name of the application.
- # This must be unique.
- application-name:
- # [Mandatory] The source path where the binary can be found
- path: /usr/local/bin
- # [Optional, default='./'] The command to launch the application.
- # Note these replacement rules:
- # {slot-num} will be replaced by the slot number the process is running on
- # {0}, {1}, ... can be replaced by parameters provided in the launch request (launch-by-request: Yes)
- launch-command: "VALUE=2 ./binary_name --log-level debug"
- # [Optional, default=''] The command to search for when checking if the application is running.
- # This will be executed as a prefix search, so if the application was launched using './app-name -loglevel debug'
- # a search-command './app-name' would work.
- # Note: same replacement rules as launch-command
- search-command: "./binary_name"
- # [Optional, default=No] Indicates whether the application needs to be launched automatically
- never-start: No
- # [Optional, default=No] Indicates whether the application can be restarted automatically when it crashes.
- # Applies only when never-start is No (if the app is not started by app_mgr it would not be restarted either).
- # Applications are only restarted when running app_mgr in restart mode (e.g. sr_linux --restart)
- never-restart: No
- # [Optional, default=No] Indicates whether the application will be shown in app manager status
- never-show: No
- # [Optional, default=No] Indicates whether the launch of the application is delayed
- # until any configuration is loaded in the application's YANG modules.
- wait-for-config: No
- # [Optional] Indicates the application is run as 'user' including 'root'
- run-as-user: root
- # [Optional, default=200] Indicates the order in which the application needs to be launched.
- # The applications with the lowest value are launched first.
- # Applications with the same value are launched in an undefined order.
- # By convention, start-order >= 100 require idb. 1 is reserved for device-mgr, which determines chassis type.
- start-order: 123
- # [Optional, default=No] Indicates whether this application is launched via an request (idb only at this point).
- launch-by-request: No
- # [Optional, default=No] Indicates whether this application is launched in a net namespace (launch-by-request
- # must be set to Yes).
- launch-in-net-namespace: No
- # [Optional, default=3] Indicates the number of restarts within failure-window which will trigger the system restart
- failure-threshold: 3
- # [Optional, default=300] Indicates the window in seconds over which to count restarts towards failure-threshold
- failure-window: 400
- # [Optional, default=reboot] Indicates the action taken after 'failure-threshold' failures within 'failure-window'
- failure-action: 'reboot'
- # [Optional, default=Nokia] Indicates the author of the application
- author: 'Nokia'
- # [Optional, default=””] The command for app_mgr to run to read the application version
- version-command: 'snmpd --version'
- # [Optional The operations that may not be manually performed on this application
- restricted-operations: ['start', 'stop', 'restart', 'quit', 'kill']
- # [Optional, default No] app-mgr will wait for app to acknowledge it via oob channel
- oob-init: No
- # [Optional] The list of launch restrictions - if of all of the restrictions of an element in the list are met,
- # then the application is launched. The restrictions are separated by a ':'. Valid restrictions are:
- # 'sim' - running in sim mode (like in container env.)
- # 'hw' - running on real h/w
- # 'chassis' - running on a chassis (cpm and imm are running on different processors)
- # 'imm' - runs on the imm
- # 'cpm' - runs on the cpm (default)
- launch-restrictions: ['hw:cpm', 'hw:chassis:imm']
- yang-modules:
- # [Mandatory] The names of the YANG modules to load. This is usually the file-name without '.yang'
- names: [module-name, other-module-name]
- # [Optional] List of enabled YANG features. Each needs to be qualified (e.g. srl_nokia-common:foo)
- enabled-features: ['module-name:foo', 'other-module-name:bar']
- # [Optional] The names of the YANG validation plugins to load.
- validation-plugins: [plugin-name, other-plugin-name]
- # [Mandatory] All the source-directories where we should search for:
- # - The YANG modules listed here
- # - any YANG module included/imported in these modules
- source-directories: [/path/one, /path/two]
- # [Optional] The names of the not owned YANG modules to load for commit confirmation purposes.
- not-owned-names: [module-name, other-module-name]
- # [Optional] Multiple applications can be defined in the same YAML file
- other-application-name:
- command: "./other-binary"
- path: /other/path
- ```
+///details | Complete list of config files parameters
+
+```yaml
+# Example configuration file for the applications on sr_linux
+# All valid options are shown and explained
+# The name of the application.
+# This must be unique.
+application-name:
+ # [Mandatory] The source path where the binary can be found
+ path: /usr/local/bin
+ # [Optional, default='./'] The command to launch the application.
+ # Note these replacement rules:
+ # {slot-num} will be replaced by the slot number the process is running on
+ # {0}, {1}, ... can be replaced by parameters provided in the launch request (launch-by-request: Yes)
+ launch-command: "VALUE=2 ./binary_name --log-level debug"
+ # [Optional, default=''] The command to search for when checking if the application is running.
+ # This will be executed as a prefix search, so if the application was launched using './app-name -loglevel debug'
+ # a search-command './app-name' would work.
+ # Note: same replacement rules as launch-command
+ search-command: "./binary_name"
+ # [Optional, default=No] Indicates whether the application needs to be launched automatically
+ never-start: No
+ # [Optional, default=No] Indicates whether the application can be restarted automatically when it crashes.
+ # Applies only when never-start is No (if the app is not started by app_mgr it would not be restarted either).
+ # Applications are only restarted when running app_mgr in restart mode (e.g. sr_linux --restart)
+ never-restart: No
+ # [Optional, default=No] Indicates whether the application will be shown in app manager status
+ never-show: No
+ # options are "proto-json", "json", "binary-tlvs" (default is proto-json)
+ config-delivery-format: json
+ # [Optional, default=No] Indicates whether the launch of the application is delayed
+ # until any configuration is loaded in the application's YANG modules.
+ wait-for-config: No
+ # [Optional] Indicates the application is run as 'user' including 'root'
+ run-as-user: root
+ # [Optional, default=200] Indicates the order in which the application needs to be launched.
+ # The applications with the lowest value are launched first.
+ # Applications with the same value are launched in an undefined order.
+ # By convention, start-order >= 100 require idb. 1 is reserved for device-mgr, which determines chassis type.
+ start-order: 123
+ # [Optional, default=No] Indicates whether this application is launched via an request (idb only at this point).
+ launch-by-request: No
+ # [Optional, default=No] Indicates whether this application is launched in a net namespace (launch-by-request
+ # must be set to Yes).
+ launch-in-net-namespace: No
+ # [Optional, default=3] Indicates the number of restarts within failure-window which will trigger the system restart
+ failure-threshold: 3
+ # [Optional, default=300] Indicates the window in seconds over which to count restarts towards failure-threshold
+ failure-window: 400
+ # [Optional, default=reboot] Indicates the action taken after 'failure-threshold' failures within 'failure-window'
+ failure-action: 'reboot'
+ # [Optional, default=Nokia] Indicates the author of the application
+ author: 'Nokia'
+ # [Optional, default=””] The command for app_mgr to run to read the application version
+ version-command: 'snmpd --version'
+ # [Optional The operations that may not be manually performed on this application
+ restricted-operations: ['start', 'stop', 'restart', 'quit', 'kill']
+ # [Optional, default No] app-mgr will wait for app to acknowledge it via oob channel
+ oob-init: No
+ # [Optional] The list of launch restrictions - if of all of the restrictions of an element in the list are met,
+ # then the application is launched. The restrictions are separated by a ':'. Valid restrictions are:
+ # 'sim' - running in sim mode (like in container env.)
+ # 'hw' - running on real h/w
+ # 'chassis' - running on a chassis (cpm and imm are running on different processors)
+ # 'imm' - runs on the imm
+ # 'cpm' - runs on the cpm (default)
+ launch-restrictions: ['hw:cpm', 'hw:chassis:imm']
+ yang-modules:
+ # [Mandatory] The names of the YANG modules to load. This is usually the file-name without '.yang'
+ names: [module-name, other-module-name]
+ # [Optional] List of enabled YANG features. Each needs to be qualified (e.g. srl_nokia-common:foo)
+ enabled-features: ['module-name:foo', 'other-module-name:bar']
+ # [Optional] The names of the YANG validation plugins to load.
+ validation-plugins: [plugin-name, other-plugin-name]
+ # [Mandatory] All the source-directories where we should search for:
+ # - The YANG modules listed here
+ # - any YANG module included/imported in these modules
+ source-directories: [/path/one, /path/two]
+ # [Optional] The names of the not owned YANG modules to load for commit confirmation purposes.
+ not-owned-names: [module-name, other-module-name]
+# [Optional] Multiple applications can be defined in the same YAML file
+other-application-name:
+ command: "./other-binary"
+ path: /other/path
+```
+
+///
## Dependency and other files
diff --git a/docs/overrides/main.html b/docs/overrides/main.html
index c9b724bf..b066d3b6 100644
--- a/docs/overrides/main.html
+++ b/docs/overrides/main.html
@@ -40,9 +40,8 @@
-SR Linux makes its way to IP
- Networking! Join our Discord
+Enjoy the most recent SR Linux 23.10
+release! Join our Discord
server to learn more!
{% endblock %}
diff --git a/macros/macros.html b/macros/macros.html
index e961aae8..28af9682 100644
--- a/macros/macros.html
+++ b/macros/macros.html
@@ -1,9 +1,31 @@
-[[[% macro srl_version(version) -%]]]
-
[[[%- endmacro %]]]
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index 442b7555..b18d9e46 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -286,6 +286,7 @@ markdown_extensions:
alternate_style: true
- pymdownx.blocks.admonition
- pymdownx.blocks.definition
+ - pymdownx.blocks.details
- pymdownx.tasklist:
custom_checkbox: true
- pymdownx.tilde
-SR Linux makes its way to IP
- Networking! Join our Discord
+Enjoy the most recent SR Linux 23.10
+release! Join our Discord
server to learn more!
{% endblock %}
diff --git a/macros/macros.html b/macros/macros.html
index e961aae8..28af9682 100644
--- a/macros/macros.html
+++ b/macros/macros.html
@@ -1,9 +1,31 @@
-[[[% macro srl_version(version) -%]]]
-
[[[%- endmacro %]]]
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index 442b7555..b18d9e46 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -286,6 +286,7 @@ markdown_extensions:
alternate_style: true
- pymdownx.blocks.admonition
- pymdownx.blocks.definition
+ - pymdownx.blocks.details
- pymdownx.tasklist:
custom_checkbox: true
- pymdownx.tilde