I've setup mosquitto auth plugin in my server and configured MongoDB as backend. I have a collection like:
{
"_id" : ObjectId("5d696b3a23bb5613fea4c2c0"),
"username" : "user1",
"password" : "PBKDF2$sha256$901$jvmyoNAi2GYOELnS$8syPnDylOIpxInBlL14GOLbyAnFHI1bl",
"superuser" : false,
"topics" : {
"article/#" : "r",
"article/+/comments" : "rw",
"ballotbox" : "w"
}
}
A sub:
mosquitto_sub -h mqtt.myserver.com -t "article/#" -u user1 -P 123
A pub:
mosquitto_pub -h mqtt.myserver.com -t "article/1/comments" -m "testing..." -u user1 -P 123
Or
mosquitto_pub -h mqtt.myserver.com -t "article" -m "testing..." -u user1 -P 123
this is the plugin log:
-- mosquitto_auth_unpwd_check(user1)
-- ** checking backend mongo
-- getuser(user1) AUTHENTICATED=1 by mongo
-- mosquitto_auth_acl_check(..., client id not available, user1, article/1/comments, MOSQ_ACL_WRITE)
-- aclcheck(user1, article/1/comments, 2) trying to acl with mongo
-- aclcheck(user1, article/1/comments, 2) AUTHORIZED=1 by mongo
-- Cached [C909F3664285F35139ED8836043853B5C5F70616] for (client id not available,user1,2)
In any case, when I subscribe to wildcard topics, I can't get any messages.
However, without wildcards it works perfectly.
Tested before enabling the plugin, Mosquitto works perfectly, which leads me to debug only the plugin and its particularities.
EDIT 1
The problem occurs only when Mosquitto is compiled with WITH_WEBSOCKETS=yes otherwise it works.
If WITH_WEBSOCKETS=yes and WebSockets not configured in conf file, wildcard doesn’t work at all, only MOSQ_ACL_WRITE appears on log.
If WITH_WEBSOCKETS=yes and WebSockets configured in conf file, it does work but with certain intermittence and a HUGE delay publishing and receiving the message.
EDIT 2
Mosquitto: 1.5.8
Mosquitto Auth: 0.13
LibWebSockets: 3.2.0
What am I missing with the WebSockets configuration ?
Couldn't find any topic related.
Any help appreciated.
Related
I'm trying out the Dynamic Security module for mosquitto and everything seems to work fine as long as I never systemctl restart mosquitto.service. After install mosquitto and enabling the Dynamic Security module, I ran these two commands:
mosquitto_ctrl dynsec init /etc/mosquitto/dynamic-security.json steve
systemctl restart mosquitto.service
Then I was able to create a user, role, subscribe and publish to a topic like this:
mosquitto_ctrl -u steve -P Pass1234 dynsec createClient john0
mosquitto_ctrl -u steve -P Pass1234 dynsec createRole role0
mosquitto_ctrl -u steve -P Pass1234 dynsec addClientRole john0 role0 1
mosquitto_ctrl -u steve -P Pass1234 dynsec addRoleACL role0 publishClientSend pizza allow
mosquitto_ctrl -u steve -P Pass1234 dynsec addRoleACL role0 subscribeLiteral pizza allow
mosquitto_sub -u john0 -P Pass1234 -t pizza
# then open a second terminal window and do this:
mosquitto_pub -u john0 -P Pass1234 -t pizza -m 'hi'
# result is the word `hi` appears in the first/original terminal window
I can repeatedly publish and subscribe to topics with the john0 user on the pizza topic.
However, the moment I have to reboot my server or if I run a systemctl restart mosquitto.service, then the john0 client no longer exists.
How do I prevent the john0 user and all the roles and access privileges from disappearing after a systemctl restart mosquitto.service?
EDIT
Here's my /etc/mosquitto/mosquitto.conf
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
allow_anonymous false
per_listener_settings false
plugin /usr/lib/x86_64-linux-gnu/mosquitto_dynamic_security.so
plugin_opt_config_file /etc/mosquitto/dynamic-security.json
Also, in my /etc/mosquitto/dynamic-security.json, the only record taht exists is he one for steve. I do not see any other clients in the dynamic-security.json file.
EDIT
Also, it seems if I manually edit the /etc/mosquitto/dynamic-security.json, it does NOT immediately take effect. I need to run systemctl restart mosquitto.service in order for the changes to take effect.
So I guess now my question is specifically how do I add clients and roles such that it meets all these criteria:
I can add them during run time and they immediately take effect without a systemctl restart mosquitto.service.
After a systemctl restart mosquitto.service, that the clients and roles still exist (ie. they are not deleted)
Mosquitto was configured to store its dynamic security state in /etc/mosquitto/dynamic-security.json.
Unfortunately, /etc/mosquitto is frequently not writable by mosquitto, for security reasons. State is generally meant to be stored in /var/lib/mosquitto, which Mosquitto is able to write to.
To fix this, change the configuration to read:
plugin_opt_config_file /var/lib/mosquitto/dynamic-security.json
If you have an existing dynamic-security.json file in /etc/mosquitto you can move it to /var/lib/mosquitto and retain whatever is currently in it:
mv /etc/mosquitto/dynamic-security.json /var/lib/mosquitto
chown mosquitto /var/lib/mosquitto/dynamic-security.json
chmod 700 /var/lib/mosquitto/dynamic-security.json
The chown line makes sure it's owned by the user mosquitto - if you run mosquitto as a different user, change this line to be the user you run it as.
The chmod line makes sure that only the file's owner (and root) can read the file. Even though the passwords in the file are encrypted, we don't want to make it any easier than necessary for an attacker to access it.
This happens due to permission issues for mosquitto
You can just simply do
chown mosquitto /etc/mosquitto/dynamic-security.json
After this when you use mosquitto_ctrl commands.
It will be visible in the json file.
I am new to Mosquitto. I have installed Mosquitto and Mosquitto Client in Ubuntu. I am trying to subscribe with client-id also publish with client-id, please look the command that I have run in console, but unfortunately, the subscriber is not receiving the message.
Subscription
mosquitto_sub -h localhost -t temp/city1 -c -q 2 --id client-one
Publish
mosquitto_pub -h localhost -t temp/city1 -m "32 Celsius" -q 2 --id client-one
but if I Publish message without client id the subscriber is receiving message, so please help me where I did the mistake?
As mentioned in the comment, clientIds are just that, they are a unique identifier for each client connected to the broker.
ClientIds need to be totally unique, if a second client tries to connect with a clientid that is already connected the broker must disconnect the first client to allow the second to connect (this is dictated by the specification). In the example you have given the subscriber will be disconnected before it receives the message published by the second.
Messages are published to topics and clients can subscribe to these topics (or patterns of topics with wildcards)
So using the mosquitto command line tools you can do the following:
mosquitto_sub -v -t 'foo/bar'
This will subscribe to the topic foo/bar and will print out the topic and then message when ever a message is published to that topic. To publish a message containing the string testing you would use:
mosquitto_pub -t 'foo/bar' -m 'testing'
The mosquitto command line tools will generate random clientids if none are provided on the command line.
https://i.imgur.com/nGh5orv.png
I am setting this up in a AWS ec2 environment.Everything works fine till I tried doing a multi-user mode.
I am facing this issue where I had setup the mongoldb persistent data store following the tutorials.
Here is my setup on the envvars.txt
COMPOSER_CARD=admin#property-network
COMPOSER_NAMESPACES=never
COMPOSER_AUTHENTICATION=true
COMPOSER_MULTIUSER=true
COMPOSER_PROVIDERS='{
"github": {
"provider": "github",
"module": "passport-github",
"clientID": "xxxx",
"clientSecret": "xxxx
"authPath": "/auth/github",
"callbackURL": "/auth/github/callback",
"successRedirect": "/",
"failureRedirect": "/"
}
}'
COMPOSER_DATASOURCES='{
"db": {
"name": "db",
"connector": "mongodb",
"host": "mongo"
}
}'
And I had changed the connection profile of both h1lfv1 and admin#xxx-network to 0.0.0.0 as seen here.
https://github.com/hyperledger/composer/issues/1784
I tried his solution here and it doesn't work.
Thank you!
Currently there's an issue with admin re-enrolling (strictly an issue with REST server) even though the admin card has a certificate (it ignores it - but fixed in 0.18.x).
Further, there's a hostname resolution issue which you'll need to address because Docker needs to be able to resolve the container names from within the persistent REST server container - we will need to change the hostnames to represent the docker resolvable hostnames as they are current set to localhost values - (example shows a newly issued 'restadmin' card that was created for the purposes of using it to start the REST server and using the standard 'Developer setup' Composer environment):
Create a REST Adninistrator identity restadmin and an associated business network card (used to launch the REST server later).
composer participant add -c admin#property-network -d '{"$class":"org.hyperledger.composer.system.NetworkAdmin", "participantId":"restadmin"}'
Issue a 'restadmin' identity, mapped to the above participant:
composer identity issue -c admin#property-network -f restadmin.card -u restadmin -a "resource:org.hyperledger.composer.system.NetworkAdmin#restadmin"
Import and test the card:
composer card import -f restadmin.card
composer network ping -c restadmin#property-network
run this one-liner to carry out the resolution changes easily:
sed -e 's/localhost:/orderer.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' < $HOME/.composer/cards/restadmin#property-network/connection.json > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/restadmin#property-network
Try running the REST server with the card -c restadmin#property-network - if you're running this tutorial https://hyperledger.github.io/composer/latest/integrating/deploying-the-rest-server then you will need to put this CARD NAME in the top of your envvars.txt and then ensure you run source envvars.txt to get it set 'in your current shell environment'
If you wish to issue further identities - say kcoe below - from the REST client (given you're currently 'restadmin') you simply do the following (first two can be done in Playground too FYI):
composer participant add -c admin#trade-network -d '{"$class":"org.acme.trading.Trader","tradeId":"trader2", "firstName":"Ken","lastName":"Coe"}'
composer identity issue -c admin#trade-network -f kcoe.card -u kcoe -a "resource:org.acme.trading.Trader#trader2"
composer card import -f kcoe.card # imported to the card store
Next - one-liner to get docker hostname resolution right, from inside the persistent dockerized REST server:
sed -e 's/localhost:/orderer.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' < $HOME/.composer/cards/kcoe#trade-network/connection.json > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/kcoe#trade-network
Start your REST server as per the Deploy REST server doc:
docker run \
-d \
-e COMPOSER_CARD=${COMPOSER_CARD} \
-e COMPOSER_NAMESPACES=${COMPOSER_NAMESPACES} \
-e COMPOSER_AUTHENTICATION=${COMPOSER_AUTHENTICATION} \
-e COMPOSER_MULTIUSER=${COMPOSER_MULTIUSER} \
-e COMPOSER_PROVIDERS="${COMPOSER_PROVIDERS}" \
-e COMPOSER_DATASOURCES="${COMPOSER_DATASOURCES}" \
-v ~/.composer:/home/composer/.composer \
--name rest \
--network composer_default \
-p 3000:3000 \
myorg/my-composer-rest-server
From the System REST API in http://localhost:3000/explorer - go to the POST /wallet/import operation and import the card file kcoe.card with (in this case) the card name set to kcoe#trade-network and click on 'Try it Out' to import it - it should return a successful (204) response.
This is set as the default ID in the Wallet via System REST API endpoint
(if you need to set any further imported cards as the default card name in our REST client Wallet - go to the POST /wallet/name/setDefault/ method and choose the card name and click on Try it Out. This would now the default card).
Test it out - try getting a list of Traders (trade-network example):
Return to the Trader methods in the REST API client and expand the /GET Trader endpoint then click 'Try it Out' . It should confirm that we are now using a card in the business network, and should be able to interact with the REST Server and get a list of Traders (that were added to your business network)..
I found this : curl: (7) Failed to connect to localhost port 8090: Connection refused . But, not able to resolve the issue.
I tried using the public ip of my machine but then it gave me another error : "curl: (52) Empty reply from server" .
I also tried 0.0.0.0 as it was mentioned in some other posts. But same issue. Do i need to do something else ?
here is the command I execute to run my docker image : "docker run -t -p 8000:8000 -p 8090:8090 $IMAGE_ID"
and this is the command I use to ingest batch data into druid :
"curl -X 'POST' -H 'Content-Type:application/json' -d #./../druid/stb_ad_trait/index.json $MY_MACHINE_IP:8090/druid/indexer/v1/task" .
Any idea please ?
In the official dockerised image the Coordinator works as both the Coordinator and the Overlord.
See for a reference:
https://github.com/druid-io/docker-druid/blob/master/supervisord.conf#L30
Perhaps that is the case with your setup as well? If so, simply use the Coordinator port (8081) instead of the Overlord port (8090).
http://host:8081/druid/indexer/v1/supervisor
I'm just playing around with mosquitto ans mqtt protocol
following the very good video
https://www.youtube.com/watch?feature=player_embedded&v=WE7GVIFRV7Q
trying to test it on my localhost
in a terminal window I run :
mosquitto_sub -t "nodeconf/eu" -v
but when I run this snippet:
var mqtt = require('mqtt');
var client = mqtt.connect();
client.on('connect', function () {
client.subscribe('nodeconf/eu');
client.publish('nodeconf/eu','Hello');
});
client.on('message', function (topic, message) {
// message is Buffer
console.log(message.toString());
client.end();
});
I don't see (in my terminal window) any Hello.
What's wrong, please ?
BTW
I'm also looking for good tutorial and guide on the topic thanks.
You have to add a console.log to your second (the javascript) client to see why it doesn't publishes the Hello properly.
But you can do a typical test with the mosquitto clients:
1) Subscribing to a topic:
mosquitto_sub -d -h localhost -p 1883 -t "myfirst/test"
2) Other client publishes a message content to that topic:
mosquitto_pub -d -h localhost -p 1883 -t "myfirst/test" -m "Hello"
3) All the subscribed clients to this topic will automatically get the message.