CAN bus openDuT network example setup

[mirenz1]

Validate CAN-Test example setup: peer1 (test script on CAN) --> openDuT tunnel --> peer2 (CAN interface)

• [x] CARL setup (VM, "DEV-box"), relates to #151
• [x] setup CLEO for CARL (provide as container in registry)
• [x] provide EDGAR release for x86 and ARM64 target
• [x] roll out EDGAR on peers
• [x] provide Cannelloni build for for x86 and ARM64 target
• [x] test script for sending/receiving CAN message
• [x] Architecture Overview in documentation

AC:

• CARL and its dependencies (keycloak, netbird,....) are installed and running on test PC
• EDGAR is installed in test PC including Cannelloni
• EDGAR is installed on Edge-Device (ARM64) including Cannelloni
• Peers and Cluster can be configured via CLEO
• Cluster is configured with 2 peers (test PC and Edge-Device)
• Cluster can be deployed and 2 peers tunnel CAN bus from test board to test PC
• test script can be executed on test PC communicating on CAN bus with test board

Open issues:

• [ ] (nice-to-have) #218 - EDGAR should stop reconnecting when authentication failed due to wrong credentials being provided Workaround: check for correct credentials
• [ ] (nice-to-have) #200 - Fix client registration for CARL Workaround: keep using shared credentials for peers
• [ ] (nice-to-have) Fix custom certificate authority for clients in general, see #200, https://github.com/eclipse-opendut/opendut/issues/200#issuecomment-2084532898 Workaround: Set PATH variable SSL_CERT_FILE
• [x] #219 EDGAR should not fail when OpenTelemetry URL is missing or is unparseable EDGAR fails to start when opentelemetry url is missing or is unparseable Error: Invalid field 'opentelemetry.endpoint': relative URL without a base
• [x] In case of development mode, EDGAR performs a dry-run which looks like actually setting up the peer. This is misleading. The note that EDGAR is running in "Dry-run mode" should be more prominent (banner, color, ...).
• [x] update-ca-certificates wird nicht gefunden (standard Linux command), wenn die Variable PATH nicht gesetzt ist (für EDGAR). Not reproducible in normal shell (env -i bash). implement Fallback
  • Use which crate lookup, or
  • search standard default paths, or
  • add default paths to PATH variable if not exist (PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)?
• [x] EDGAR write configuration does not allow to configure an extended edgar.toml with "custom" attributes. #220 Mitigated: no custom attributes are required for default setup
• [x] if there is already an existing ca.pem and netbird certificate, new certificates from setup string cannot be used in EDGAR managed setup. #224 Workaround: manually delete certificates on peer
• [ ] (nice-to-have) #188

[reimarstier]

At the moment there are a lot of configuration parameters to be set that make automation rather tedious. The test environment does a fine job of hiding this complexity.

To use CLEO in different setups and remove a lot of the manual configuration tasks when connecting to a new CARL instance, a few other issues need to be done first.

Therefore this issue relates to the following issues:

• #190
• #193
• #191
• #198

[reimarstier]

There are currently a few known issues with the current setup that are being addressed (WIP) in branch issue-171-revised:

• #186
• [ ] Create PKI in container with predictable user id and group id currently owned by the user who cloned the repository, carl.key only readable by user id of host system

[voelkera]

Validate CAN-Test example setup: peer1 (test script on CAN) --> openDuT tunnel --> peer2 (CAN interface)

• [x] CARL setup (VM, "DEV-box"), relates to https://github.com/eclipse-opendut/opendut/issues/151
• [x] #193
• [x] provide EDGAR release for x86 and ARM64 target
• [x] roll out EDGAR on peers (was done manually for now -> #197)
• [x] provide Cannelloni build for for x86 and ARM64 target
• [x] test script for sending/receiving CAN message

[mtwardawski]

• [x] Create PKI in container with predictable user id and group id currently owned by the user who cloned the repository, carl.key only readable by user id of host system

[mtwardawski]

• [x] if there is already an existing ca.pem and netbird certificate, new certificates from setup string cannot be used in EDGAR managed setup. https://github.com/eclipse-opendut/opendut/issues/224

[mtwardawski]

• [x] In case of development mode, EDGAR performs a dry-run which looks like actually setting up the peer. This is misleading. The note that EDGAR is running in "Dry-run mode" should be more prominent (banner, color, ...).

[mbfm]

I've added another task, that we need an architecture overview which shows how the different containers work together.

Such a diagram already exists for THEO, which we can likely adapt: https://opendut.eclipse.dev/book/development/testenv/index.html

[mtwardawski]

• [x] Architecture Overview in documentation

[mtwardawski]

We achieved to get a connection between two EDGARs now:

• [x] roll out EDGAR on peers