Publish message to kapua using kura or MQTT - eclipse

I am working on an IoT device. I have installed Eclipse Kura in raspberry pi 3
to use it as a gateway. I want to publish a message to Kapua server (installed in the same network) using Kura or directly using the raspberry pi. I have tried both methods.
1- Using Kura
I have followed the given instructions on GitHub Kura Kapua connection tutorial #780. After following these steps I am able to establish the Kura Kapua connection but unable to send data, Example.publisher package is also installed in Kura. I want to create a topic and publish data on that topic.
2- Using MQTT-Client library
I have installed the MQTT-Client library in raspberry pi and use the following commands to publish and subscribe the data.
To Publish :
sudo mosquitto_pub -h "broker-URL" -p "Port" -t "topic" -m "message" -u "user-name"-P "user-pass" -i "client-id"
To subscribe :
sudo mosquitto_pub -h "broker-URL" -p "Port" -t "topic" -u "user-name"-P "user-pass" -i "client-id"
this has the same behavior, It also establishes the connection but unable to create the topic and publish data.When I do the same for localhost it does send the message. I am using two different terminals to publish and subscribe.
Is there any method or example where I can actually send some data and observe at the other end using Kura or MQTT.

General knowledge
Correct connection parameters (if you followed the tutorial you mentioned) are:
-h localhost
-p 1883
-u kapua-broker
-P kapua-password
(not sure the doublequote is required)
Kapua uses has a specific topic format to grant access control over the topics.
The semantic of the format is:
{account-name}/{client-id/{semantic-topic}
Depending on your privileges you can access different levels of topics.
The defaults user kapua-broker allows only to connect, publish and subscribe under:
{kapua-sys}/{connection-client-id}/#
You need more permissions to subscribe to other client-id topics.
The permission required to do that is:
data:view
Your example
First, it seems that you are using the published to subscribe. This is your command.
sudo mosquitto_pub -h "broker-URL" -p "Port" -t "topic" -u "user-name"-P "user-pass" -i "client-id"
Secondly credential, host, usenrname, password, and topic are all wrong (unless you "obscured" them before publishing to SO).
To make your test work you need to use the following commands,
Subscribe
mosquitto_sub -h "localhost" -p "1883" -t "kapua-sys/mosquitto_pub/my/test/topic" -u "kapua-sys" -P "kapua-password" -i "mosquitto_sub"
Publish
mosquitto_pub -h "localhost" -p "1883" -t "kapua-sys/mosquitto_pub/my/test/topic" -m "My test message" -u "kapua-broker" -P "kapua-password" -i "mosquitto_pub"
For the Kura example publisher, I don't know where could be the problem, due to lack of info. I'm assuming you are publishing or subscribing to a topic you cannot access to due to write/read permission on topics.
Hope that this help! :)

Related

Connect to remote kafka from command within docker container

We tried to connect to kafka using below command however we are not able to reach the broker. Could anyone help us here.
sudo docker run --rm --name=jaeger1 -e SPAN_STORAGE_TYPE=kafka -p 14267:14267/tcp -p 14268:14268/tcp -p 9411:9411/tcp jaegertracing/jaeger-collector --kafka.producer.topic="test Span" --kafka.producer.brokers=<broker>:9092 --kafka.producer.plaintext.password="" --kafka.producer.plaintext.username="<username>"
{"level":"fatal","ts":1585232844.0954845,"caller":"collector/main.go:70","msg":"Failed to init storage factory","error":"kafka: client has run out of available brokers to talk to (Is your cluster reachable?)"
Please let us know what we are missing.

Using IPMI tool from Romulus

How to run IPMI tool from the openBMC romulus image. I was successful in running the Hello World program as per the tutorials. I want to run IPMI tool command from the romulus to the BMC of another server. Is there is any method of doing this? As ipmitool command is not included. Is there any way of including it in the romulus Image.
ipmitool is really meant to be used outside of the BMC to control it. So in most use cases you install the ipmitool package on your computer (sudo apt install ipmitool), and then use it to talk to the server.
i.e.:
ipmitool -I lanplus -U root -H <server> -P <password> chassis power status
If you're using QEMU, then I believe you need to hostfwd port 623 for this to work. I personally have not gotten ipmitool to talk to a QEMU session before though.
If you really want ipmitool in your BMC image, then you could add it as a RDEPENDS to the packagegroup file similar to what facebook does in https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-fbtp/packagegroups/packagegroup-fb-apps.bb
Romulus does not have ipmitool in it OpenBMC firmware image, as do some other OpenBMC platforms; not all platforms have the SPI FLASH space supply many utilites. You can use ipmitool from a remote machine to a Romulus like below.
ipmitool -I lanplus -C 17 -p 623 -U root -H <server> -P <password> bmc info
or
ipmitool -I lanplus -C 17 -p 623 -U root -H <server> -P <password> raw 0x06 0x01
I chose to use -C 17 for cipher suite 17 as ipmitool defaults to cipher suite 3 and modern platforms have deprecated cipher suite 3 for security reasons.
Cipher suites 3 and 17 were last 2 suites that had any security strength, and 17 is the stronger (do not read that as strong) and now suite 3 is considered weak.
and here are the ipmitool commands:
usage: ipmitool [options...] <command>
-h This help
-V Show version information
-v Verbose (can use multiple times)
-c Display output in comma separated format
-d N Specify a /dev/ipmiN device to use (default=0)
-I intf Interface to use
-H hostname Remote host name for LAN interface
-p port Remote RMCP port [default=623]
-U username Remote session username
-f file Read remote session password from file
-z size Change Size of Communication Channel (OEM)
-S sdr Use local file for remote SDR cache
-D tty:b[:s] Specify the serial device, baud rate to use
and, optionally, specify that interface is the system one
-4 Use only IPv4
-6 Use only IPv6
-a Prompt for remote password
-Y Prompt for the Kg key for IPMIv2 authentication
-e char Set SOL escape character
-C ciphersuite Cipher suite to be used by lanplus interface
-k key Use Kg key for IPMIv2 authentication
-y hex_key Use hexadecimal-encoded Kg key for IPMIv2 authentication
-L level Remote session privilege level [default=ADMINISTRATOR]
Append a '+' to use name/privilege lookup in RAKP1
-A authtype Force use of auth type NONE, PASSWORD, MD2, MD5 or OEM
-P password Remote session password
-E Read password from IPMI_PASSWORD environment variable
-K Read kgkey from IPMI_KGKEY environment variable
-m address Set local IPMB address
-b channel Set destination channel for bridged request
-t address Bridge request to remote target address
-B channel Set transit channel for bridged request (dual bridge)
-T address Set transit address for bridge request (dual bridge)
-l lun Set destination lun for raw commands
-o oemtype Setup for OEM (use 'list' to see available OEM types)
-O seloem Use file for OEM SEL event descriptions
-N seconds Specify timeout for lan [default=2] / lanplus [default=1] interface
-R retry Set the number of retries for lan/lanplus interface [default=4]
Interfaces:
open Linux OpenIPMI Interface [default]
lan IPMI v1.5 LAN Interface
lanplus IPMI v2.0 RMCP+ LAN Interface
serial-terminal Serial Interface, Terminal Mode
serial-basic Serial Interface, Basic Mode
Commands:
raw Send a RAW IPMI request and print response
i2c Send an I2C Master Write-Read command and print response
spd Print SPD info from remote I2C device
lan Configure LAN Channels
chassis Get chassis status and set power state
power Shortcut to chassis power commands
event Send pre-defined events to MC
mc Management Controller status and global enables
sdr Print Sensor Data Repository entries and readings
sensor Print detailed sensor information
fru Print built-in FRU and scan SDR for FRU locators
gendev Read/Write Device associated with Generic Device locators sdr
sel Print System Event Log (SEL)
pef Configure Platform Event Filtering (PEF)
sol Configure and connect IPMIv2.0 Serial-over-LAN
tsol Configure and connect with Tyan IPMIv1.5 Serial-over-LAN
isol Configure IPMIv1.5 Serial-over-LAN
user Configure Management Controller users
channel Configure Management Controller channels
session Print session information
dcmi Data Center Management Interface
nm Node Manager Interface
sunoem OEM Commands for Sun servers
kontronoem OEM Commands for Kontron devices
picmg Run a PICMG/ATCA extended cmd
fwum Update IPMC using Kontron OEM Firmware Update Manager
firewall Configure Firmware Firewall
delloem OEM Commands for Dell systems
shell Launch interactive IPMI shell
exec Run list of commands from file
set Set runtime variable for shell and exec
hpm Update HPM components using PICMG HPM.1 file
ekanalyzer run FRU-Ekeying analyzer using FRU files
ime Update Intel Manageability Engine Firmware
vita Run a VITA 46.11 extended cmd
lan6 Configure IPv6 LAN Channels

IBM watson internet of things platform: Connecting using client certs & mosquitto client

I get below error while trying to connect to IBM Watson internet of things platform using client certs & mosquitto client. The same certs work fine with node.js client hence I know certs are fine, just some config in mosquitto client which is erroneous.
mosquitto_sub -h dumorg.messaging.internetofthings.ibmcloud.com -p 8883 --capath ./certs/ -t "iot-2/type/dumtype/id/dumid/cmd/+/fmt/json" -v -i g:dumorg:dumtype:dummid --cert ./client.crt --key ./client.key
Connection Refused: not authorised.
When I try to perform same connection using auth-token it goes through fine
$ mosquitto_sub -h dumorg.messaging.internetofthings.ibmcloud.com -p 8883 --capath ./certs/ -t "iot-2/type/dumtype/id/dumid/cmd/+/fmt/json" -v -i g:dumorg:dumtype:dumid -P dumpassword -u use-token-auth
I am also able to successfully connect using certs through another client. I know the certs are fine, and mosquitto command works with auth token. hence issue is some missing/incorrect config in mosquitto due to which IoT platform doesn't like certs used to connect with mosquitto?
Seems mosquitto does not support SNI which is required to connect to MQTT broker on IBM cloud. Manually inserting this patch https://github.com/eclipse/mosquitto/pull/626 and building mosquitto resolved issue. Hope this is merged in main branch in near future.

Bluemix Connection Refused: not authorised, can't register device

I have read several tutorials and topics and I did everything as described, but still I am not able to register device.
I have been trying to use MQTTlens and mosquitto but same problem, not authorised
Bellow is command for mosquitto
mosquitto_pub -h xwc8vm.messaging.internetofthings.ibmcloud.com -u use-token-auth -P 'YpSP?P98Wwe0pYGXPj' -i 'd:xwc8vm:devicetype:mydevice' -t /iot/x -m '{"d":"heloo"}'
This are devices data
Organization ID xwc8vm
Device Type devicetype
Device ID mydevice
Authentication Method token
Authentication Token XXXXXXXXXX
I have used host
xwc8vm.messaging.internetofthings.ibmcloud.com
and client
d:xwc8vm:devicetype:mydevice
I even tried using http://mqtt-helper.mybluemix.net/?cm_sp=dw-bluemix--nospace--answers, but got this error
(23:42:45.044)Failed to connect to xwc8vm.messaging.internetofthings.ibmcloud.com:1883. Code: 1, Message: AMQJSC0001E Connect timed out.
Everything is configured as here http://heidloff.net/article/useful-mqtt-tools-ibm-watson-iot-bluemix?cm_mc_uid=27677244132415055778021&cm_mc_sid_50200000=1505944109
You can check your TLS security setting in your dashboard under the security tab. New IoT services by default require TLS. If you are not using TLS then try setting it to optional to see if that resolves the problem.
The mosquito command is not complete, you need to specify the port 8883, and the connection is secure by default and you need to specify the server certificate that can be downloaded from below:
https://github.com/ibm-watson-iot/iot-python/blob/master/src/ibmiotf/messaging.pem
So the command should look like:
mosquitto_pub -h xwc8vm.messaging.internetofthings.ibmcloud.com -p 8883 -u "use-token-auth" -P "xxxxxxxxx" -i "d:xwc8vm:device-type:my-device" -t "iot-2/evt/x/fmt/json" -m {"d":"hello"} --cafile messaging.pem -d
messaging.pem file needs to be in the same location as mosquitto_pub file or you can pass the path to it
Note: Please mind the topic format:
"iot-2/evt/x/fmt/json" >>>>> iot-2/evt/event/fmt/event_format
Very important, please edit your post and remove or mask the authentication token

How can I use REST API to interact with the Docker engine?

We can use the command docker images to list the Docker images we have on local host.
Now I want to get the same information from a remote server by sending an HTTP GET request in Firefox or Chrome. Does Docker provide some REST API to do this?
I did a lot of search. For example:
Examples using the Docker Engine SDKs and Docker API
It provides a way something like this:
curl --unix-socket /var/run/docker.sock http:/v1.24/containers/json
I know a little about Unix sockets, and I don't think this is what I want. The URL (http:/v1.24/containers/json) is so weird and don't even have a server name in it. I don't think it can work on a remote server. (It does work on a local server.)
Is there any official documentation that Docker provides on this topic?
You need to expose the Docker daemon on a port.
You can configure the Docker daemon to listen to multiple sockets at the same time using multiple -H options:
listen using the default Unix socket, and on two specific IP addresses on this host.
$ sudo dockerd -H unix:///var/run/docker.sock -H tcp://192.168.59.106 -H tcp://10.10.10.2
The Docker client will honor the DOCKER_HOST environment variable to set the -H flag for the client. Use one of the following commands:
https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-socket-option
You need to do this by creating a systemd dropin:
mkdir -p /etc/systemd/system/docker.service.d/
cat > /etc/systemd/system/docker.service.d/10_docker.conf <<EOF
[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// -H tcp://0.0.0.0:2376
EOF
Then reload and restart Docker:
systemctl daemon-reload
systemctl restart docker
Note: this way you would be exposing your host and you shouldn't do it this way in production. Please read more about this on the link I shared earlier.