I try to install the Orion Context Broker, I first registered an account in
Fiware Lab, but the user guide says that I need to get and run the
token_script.sh in order to get a token, I have no idea what this means.
In FIWARE Lab you can either deploy an instance of CentOS with Orion Context Broker already installed, or a fresh one on which to install it yourself. Which way are you doing it?
You only need a token if you want to connect to a public instance of Orion, such as the one in Santander (see this for more info on that).
The way it works is that you get a token (you need a FIWARE account, which you already have) using that script, and then use it in succesive calls to the Orion API.
Bottom line: if you just want to check out Orion Context Broker you don't need any tokens. Just set up your Orion VM in the cloud (Cloud tab in FIWARE Lab, orion-psb-R4.1 image). If you want to access Orion Context Broker deployed in a publicly accesible instance (such as the one in Santander) then you would need a token.
Related
for a project i have to connect the Eclipse Leshan Client to a IoT Agent Server.
My problem is to read the device's mesurements with Postman or cUrl command.
The client after the configuration of the port (5683) look like it's connected to the server but i can't read the values of the dummy device.
I ask how i can connect the client to server. Which file have i to config for my work?.
Also i have set up an orion context broker on the port 1026. The listening port of the server is the port 5683.
I wish to use the devices registered in the client Leshan, but the data results EMPTY.
Fiware IoTAgent:
https://github.com/telefonicaid/lightweightm2m-iotagent;
Eclipse Leshan:
https://github.com/eclipse/leshan
You need to take a workaround through that port in order to achieve your goal.
Best luck!
I am using the JMSInput node in an IIB flow to connect with Rabbitmq. Locally it's working fine with a binding file, but how/where to set login credentials for a remote rabbitmq server?
You will have to use JMS Node and create your own JMSProviders in configurable services.
I'm an MQTT newbie, so maybe this is obivous but I'm not getting it.
I've got IoT devices that publish data to a cloud MQTT broker. I can't change that. I want to be able to get the messages from the cloud broker and pass them to IoT Hub in Azure. Here's what I've done so far:
Configured a VM running CentOS to host my Mosquitto server
Installed Mosquitto and configured as a bridge to IoT Hub (IoTHubBridge)
Created a separate Mosquitto config to bridge to the cloud MQTT broker (CloudBridge)
Note that both Mosquitto bridge instances are running on the same VM.
So far, so good. IoT Hub can receive test messages that pass through IoTHubBridge and CloudBridge receives messages from the cloud broker. Here's where I'm stuck - how do I get messages to pass from CloudBridge to IoTHubBridge?
Thanks!
As hashed out in the comments.
There is no need for 2 MQTT brokers here. You should configure both bridges in a single broker, that way with the right topic declarations for the bridges messages should just flow between the IoT Hub and Cloud brokers.
This does assume that the topic/message structure for the cloud broker is compatible with what you need to send to IoT hub. The bridge will allow you to add/remove a prefix from the topic but not totally remap it. And there is no way to change the payload format.
If you need to make changes to the payload format or major changes to the topic structure then a bridge is not the right solution. You will need to create an application that subscribes to the cloud broker and then republishes the transformed message to the IoT Hub broker. There are many ways to do this in any number of languages but I might suggest you look at something like Node-RED if you are not already comfortable with an existing language/MQTT client combination.
I think to understood how fabric mainly works and how consens is reached. What I am still missing in the documentation is the part of what happens inside of a docker container of fabric to take part in communication process.
So, communication starting from a client (e.g. an app) takes place in using gRPC messages between peers and orderer.
But what happens inside of the containers?
I imagine it for myself as a process that is only receiving gRPC message and answering them in using functions in the background of a peer/orderer, to hands out its response for further processing in another unit like the client to collect the responses of multiple peers for a smart contract.
But what happens really inside a container? I mean, a container spawns, when the docker image file is loaded and launched by the yaml config file. But what is started there inside of it (is there only a single peer binary started, e.g. like the command "peer node start") - I mean the compiled go binary file "peer" only?? What is listening? What is responding there? I discovered only one port for every container that is exposed out. This seems for me to be the gate for gRPC (cause it is often used as Port ID: **51).
The same questions goes for the orderer, the chaincode and the cli. How are they talking to each other or is gRPC the only way of communication and processing (excluded of the discovery service and gossip, how is this started inside of the containers (in using the yaml files for lauchun only or is there further internal configuration or a startupscript in the image files (cause I cannot look inside the images, only login on running containers while runtime).
When your client sends request to one of the peers, peer instance checks if requested chaincode (CC) installed on it. If CC not installed: Obviously you'll get an error.
If CC is installed: Peer checks if a dedicated container is already started for the given CC and corresponding version. If container is started, peer sends transaction request to that CC instance and returns back the response to your client after signing the transaction. Signing guarantees that response is really sent by that peer.
If container not started:
It builds a docker image and starts that instance (docker container). New image would be based on one of the hyperledger images. i.e. if your CC is GO, then hyperledger/baseos, which is very basic linux os, will be used. This new image contains CC binary and META-DATA as well.
That peer instance is using underlying (your) machine's docker server to do all of those. That's the reason why we need to pass /var/run:/host/var/run into volume mapping and CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock into environment variables.
Once the CC container starts, it connects to its parent peer node which is defined with
CORE_PEER_CHAINCODEADDRESS attribute. Peer dictates to child (probably during image creation) to use this address, so they obey. Peer node defines its own listen URL with CORE_PEER_CHAINCODELISTENADDRESS attribute.
About your last question; communication is with gRPC in between nodes also with clients. If TLS is enabled, then it's for sure secure communication. Entry point for orderers to know about peers and peers know about other organizations' peers is the definition of anchor peers defined during channel creation. Discovery service is running in peer nodes, so they can hold a close to real-time network layout. Discovery service also provides peers' identity, that's how clients can detect other organizations' peers when endorsement policy requires multiple organizations' endorsement policy (i.e. if policy look like AND(Org1MSP.member, Org2MSP.member)).
I want to run ActiveMQ Artemis (2.10.1) as a Windows Service as a windows service on a Windows Server 2016. I followed the documentation:
On windows you will have the option to run ActiveMQ Artemis as a service. Just use the following command to install it:
$ ./artemis-service.exe install
It works very well as long as I switch user to an account with Administrator rights. However in the project I am working it would be preferable to run the service as a special "service user" account.
When one develops your own Windows service one can use the ServiceProcessInstaller.Account class/property to control which account is used for the service.
I guess this behavior is built into the artemis-service.exe binary and accompanying configuration file, artemis-service.xml.
However I cannot find any documentation or source code for this. Anyone knows?
According to pom.xml during build of Artemis artemis-service.exe is pulled from Maven Repository Artifact winsw what is from WinSW on github. According to its documentation you have to specify the service account in the xml file:
Service account
It is possible to specify the useraccount (and password) that the
service will run as. To do this, specify a element
like this:
<serviceaccount>
<domain>YOURDOMAIN</domain>
<user>useraccount</user>
<password>Pa55w0rd</password>
<allowservicelogon>true</allowservicelogon>
</serviceaccount>
The <allowservicelogon> is optional. If set to true, will
automatically set the "Allow Log On As A Service" right to the listed
account.
Someone already tried to do something similar you are triying and opened the issue register service as local service and not system service #121.