What happened to daemon / InfluxDB sidecar + Telegraf with ExecD

[Space2Man]

Hello,

some time ago there was a demo using a sidecar for InfluxDB and ExecD for Telegraf. While the code can still be found in branch 0.10.1, what is the current way to connect Telegraf to InfluxDB via ockam. Do I need to write my own rust code or is there still a way with prebuild binaries?

Thanks and best regards, Space

[mrinalwadhwa]

Hey Space 👋

There isn't currently a pre-baked binary but there is a container image.

See the docker instructions in this guide to use it for Telegraf to InfluxDB communication through Ockam.
https://github.com/ockam-network/ockam/tree/develop/documentation/use-cases/end-to-end-encrypt-all-application-layer-communication#readme

The Ockam rust library evolved quite a bit over the last year and now allows for pluggable transport inlets and outlets. The guide above walks through a TCP Inlet/Outlet setup that would allow tunneling Telegraf to InfluxDB traffic. But it has become super easy to replace TCP Inlet/Outlet with a UDP Inlet/Outlet or a Bluetooth Inlet/Outlet etc.

Our plan is to have new Ockam Command soon (development of that has started here but its super early) to create an easy CLI experience around the functionality from our various guides.

Could you share more information about your use case (here or on a call) ... that would be great input for the design of Ockam Command and we may be able to accelerate what you need.

Cheers,
Mrinal

[Space2Man]

Hi Mrinal,

I will check those examples! It was my guess already that you have done some major development on the library and that that's the reason why the daemon is available in an old branch only.

We have just began to make a plan. The scenario is that we need multiple monitoring stations (e.g. telegraf or beats) running on some satelite systems to send their data via the internet to a centralized system (either running influxdb or prometheus). Since we want the central system not to be located in the DMZ an ockam hub in the DMZ sounds like a good plan.
The main requirement is that the monitoring stations do initiate the outbound connection since we don't control the firewalls at the satelite. But outbound access should be possible. That's the reason why we at first thought that Prometheus is not the way to go but maybe this can be changed by using the hub.
And of course only the monitoring stations that we provide to the satelites should be the ones who are allowed to send data.

So I was very happy to find this project since I think I can tick off all requirements by using Ockam 👍

Cheers, Space

[mrinalwadhwa]

That sounds like a great scenario to apply Ockam. It should be simple to move traffic between Telegraf <> InfluxDB or use Prometheus, Beats etc. in their place.

There was a team demo yesterday where Ockam Command could do the the same things as the Docker container in this guide.. So an early version of the binary you need is close to landing.

We are actively working on various Authentication / Authorization design questions currently and I would love to learn more about your needs in that area. (my email is mrinal at ockam.io)

[Space2Man]

Hi,

I see an ockam-cli in the develop branch but I can't find an example how to use it, e.g. to send traffic via a self hosted hub somewhere in the internet. Is this already possible with the ockam-cli?

Thanks and best regards, Jogi

[mrinalwadhwa]

Hi Jogi, sorry about taking a few days to respond.
There are a lot of moving parts around the ockam cli that are currently evolving.

There is a super early prototype version here that currently doesn't work with our public playground node.
https://github.com/ockam-network/ockam/releases/tag/ockam_cli_preview_v0.0.1

If it did, it would looks something like this:

# Download Ockam Command
curl --proto '=https' --tlsv1.2 -sSfL -o ockam https://github.com/ockam-network/ockam/releases/download/ockam_cli_preview_v0.0.1/ockam.aarch64-apple-darwin
chmod u+x ockam

# Create Identities for Alice and Bob
mkdir -p alice bob
OCKAM_DIR=$(pwd)/alice ./ockam create-identity
OCKAM_DIR=$(pwd)/bob ./ockam create-identity

# Make Bob trust Alice
OCKAM_DIR=$(pwd)/alice ./ockam print-identity > ./bob/trusted
# Make Alice trust Bob
OCKAM_DIR=$(pwd)/bob ./ockam print-identity > ./alice/trusted

# Start a server that is local to Alice, that Bob wants to reach.
pushd $(mktemp -d 2>/dev/null || mktemp -d -t 'tmpdir') &>/dev/null; python3 -m http.server --bind 127.0.0.1 4001; popd 

# Start a TCP Outlet at Alice with a forwarding address in Ockam Cloud
OCKAM_DIR=$(pwd)/alice ./ockam create-outlet 1.node.ockam.network:4000 alice 127.0.0.1:4001

# Start a TCP Inlet at Bob that will:
# 1. Create an end-to-end trusted channel with the TCP inlet at Alice using Alice's fowarding address in Ockam Cloud
# 2. Listen for local TCP connections on 127.0.0.1:4002
OCKAM_DIR=$(pwd)/bob ./ockam create-inlet 1.node.ockam.network:4000 alice 127.0.0.1:4002

# Create an HTTP request to the local inlet at Bob which will encrypt the request and send all the way to server at alice.
curl 127.0.0.1:4002

Is this the right direction for your use case?

In the above we're aware that establishing trust between the two ends gets cumbersome, especially if there are lots of parties that want to talk to each other. We are working on ways to simplify this across a fleet.

[Space2Man]

Yes, this looks very promising. I will evaluate it. Is it possible with this CLI to run a cloud hub as well already? In that case we could run the hub in the DMZ and both the satellite systems and the database can connect to it from the inside. Is it possible to replace the 1.node.ockam.network hub by some command we can host ourselves in the cloud / DMZ?

[Space2Man]

Is there something wrong with the node at the moment? I only get timeouts even though I can ping that hub on port 4000 ...

2022-03-14T15:30:25.399340Z TRACE ockam_transport_tcp::router: TCP registration request: 1#50.18.236.180:4000 => 0#9ce93d40ddcf1f4ecb246a3be1c53cac
2022-03-14T15:30:25.399369Z TRACE ockam_node::router::utils: Resolving worker address '0#9ce93d40ddcf1f4ecb246a3be1c53cac'... OK
2022-03-14T15:30:25.399393Z TRACE mio::poll: registering event source with poller: token=Token(1), interests=READABLE | WRITABLE
2022-03-14T15:30:25.552684Z DEBUG ockam_node::router::start_processor: Starting new processor '0#883917c4bcd5a5b95a7fc4994c12bfe0'
2022-03-14T15:30:25.552725Z DEBUG ockam_node::router: Setting cluster on address 0#883917c4bcd5a5b95a7fc4994c12bfe0
2022-03-14T15:30:25.552759Z DEBUG ockam_node::router::start_worker: Starting new worker '0#24cab41f227d1717a7472f165b0fb975'
2022-03-14T15:30:25.552768Z TRACE ockam_node::router: Marking address 0#883917c4bcd5a5b95a7fc4994c12bfe0 as ready!
2022-03-14T15:30:25.552809Z TRACE ockam_node::router: Marking address 0#9ce93d40ddcf1f4ecb246a3be1c53cac as ready!
2022-03-14T15:30:25.552813Z TRACE ockam_node::context: 0#9ce93d40ddcf1f4ecb246a3be1c53cac: received new message!
2022-03-14T15:30:25.552894Z DEBUG ockam_node::router::start_worker: Starting new worker '0#b517557f198de8bf8cf4c3e94c6261c4'
2022-03-14T15:30:55.398141Z TRACE ockam_cli_demo: Exiting with error Error { code: 11014, domain: "ockam_node::error::Timeout" }
Error: Error { code: 11014, domain: "ockam_node::error::Timeout" }