moscajs / aedes-cli Goto Github PK

System Information
moscajs/aedes:dev
Tested on MacOS Catalina and Ubuntu 18.04.4 LTS

Describe the bug
When a client tries to connect, it gets connected and then immediately disconnected

To Reproduce

1. Start aedes docker run --rm -it -p 3000:3000 moscajs/aedes:dev --protos ws
2. Use telnet to observe connections are dropped.

% telnet 127.0.0.1 3000                                                                   
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.

Expected behavior
Connection is not dropped and aedes waits for requests.

% telnet localhost 3000
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Im typing something here
HTTP/1.1 400 Bad Request
Connection: close

Connection closed by foreign host.

Additional context
Running outside of the container works fine.

I receved an error after trying to setup redis persistence. Here's the error I received.

My docker-compose.yaml:

version: '3.7'
services:
  aedes-1:
    container_name: aedes-1
    image: i/aedes:latest
    restart: always
    stop_signal: SIGINT
    networks:
      - mqtt
    command: --config /data/config-persistent.js --credentials /data/credentials.json # add here the options to pass to aedes
    volumes:
      - ./:/data # map the local folder to aedes
    ports:
      - '1884:1883'
      - '8884:8883'
  # mongo:
  #   container_name: mongo
  #   networks:
  #     - mqtt
  #   logging:
  #     driver: none
  #   image: mvertes/alpine-mongo
  #   volumes:
  #     - db-data:/data/db
  #   ports:
  #     - "27018:27017"
  redis:
    container_name: redis
    networks:
      - mqtt
    logging:
      driver: none
    image: redis:6-alpine
    volumes:
      - db-data:/data/redis
    ports:
      - "6379:6379"
volumes:
  db-data:
    name: db-data
networks:
  mqtt:

and my config-persistent.js:

module.exports = {
  // SERVERS
  protos: ['tcp'],
  host: '0.0.0.0',
  port: 1883,
  wsPort: 3000,
  wssPort: 4000,
  tlsPort: 8883,
  key: null,
  cert: null,
  rejectUnauthorized: false,
  // AUTHORIZER
  credentials: '/data/credentials.json',
  // AEDES
  brokerId: 'aedes-cli',
  concurrency: 100,
  queueLimit: 42,
  maxClientsIdLength: 23,
  heartbeatInterval: 60000,
  connectTimeout: 30000,
  stats: true,
  statsInterval: 5000,
  // PERSISTENCES
  persistence: {
    name: 'redis',
    options: {
      url: 'redis'
    }
  },
  mq: null,
  verbose: false,
  veryVerbose: false,
  noPretty: false
}

I encountered this issue then I tried to use emqx/emqtt-bench for benchmark and run sub

I am using redis-ha as my persistence and emitter.

(node:1) UnhandledPromiseRejectionWarning: ReplyError: READONLY You can't write against a read only replica.                                                                                                                                  
    at parseError (/usr/local/lib/node_modules/aedes-cli/node_modules/redis-parser/lib/parser.js:179:12)                                                                                                                                      
    at parseType (/usr/local/lib/node_modules/aedes-cli/node_modules/redis-parser/lib/parser.js:302:14)                                                                                                                                       
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminat
e the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4819)

System Information

• Aedes: 0.46.1
• NodeJS: 16.18.1
• OS: Debian 11
• Arch: amd64

Describe the bug
I manage to publish and subscribe to a topic that is not in the authorised paths for the user.

To Reproduce
Steps to reproduce the behavior:

1. use following conf file:
   module.exports = { protos: ['tcp'], host: '127.0.0.1', port: 1883, wsPort: 3000, wssPort: 4000, tlsPort: 8883, brokerId: 'aedes-cli', credentials: './credentials.json', persistence: { name: 'mongodb', options: { url: 'mongodb://127.0.0.1/aedes' } }, mq: { name: 'mongodb', options: { url: 'mongodb://127.0.0.1/aedes' } }, key: null, cert: null, rejectUnauthorized: true, verbose: false, veryVerbose: false, noPretty: false }

2. create two users:
   ./aedes adduser ward pwd4ward --credentials ./credentials.json --authorize-publish 'ward/**' --authorize-subscribe 'ward/**'
./aedes adduser pete pwd4pete --credentials ./credentials.json --authorize-publish 'pete/**' --authorize-subscribe 'pete/**'

3. publish retained message using first user
   mosquitto_pub -h 34.69.176.86 -u ward -P pwd4ward -t 'ward/1' -m mymessage -r

4. subscribe to everything with other user
   mosquitto_sub -h 34.69.176.86 -u pete -P pwd4pete -t '#'
   results in: mymessage

Expected behavior
I would expect the broker to log an error saying "subscription not authorized".
Even if no error is logged, the message "mymessage" from user ward should not be shown to user pete

First asked on SO.

I need to create a MQTT broker cluster. I want to use aedes (as I already use it, albeit without cluster) and Docker. Note that I have never created a cluster before (with nor without Docker).

Here I found official example how to create a cluster using aedes, but I was thinking about using aedes-cli Docker image.

Now, I have no idea which is better: should I create separate containers per broker (similarly to this question) or use mqemitter-redis/mqemitter-mongodb (as the aedes-cli docs suggest).

As for creating separate containers, I have no idea how to connect them.

As for using mqemitter-redis/mqemitter-mongodb, I have no idea how to setup them in the aedes-cli config file.

I have no need for data persistance accross broker cluster restarts. All I need is to distribute the messages accross multiple brokers in order to improve the runtime performance.

Below is a working, single-broker configuration.

• aedes.yml:

version: '3.7'
services:
  aedes:
    container_name: aedes
    image: moscajs/aedes:latest
    restart: always
    stop_signal: SIGINT
    network_mode: host
    command: -c /data/dockerConfig.js
    volumes:
      - /some/path/mqtt:/data
  mongo:
    container_name: mongo
    restart: always
    network_mode: host
    logging:
      driver: none
    image: mvertes/alpine-mongo
    volumes:
      - mongo_data:/data/db
    ports:
      - 27017:27017
volumes:
  mongo_data:
    name: mongo_data

• /some/path/mqtt/dockerConfig.js

module.exports = {
  protos: ['tcp', 'ws'],
  host: 'localhost',
  port: 1883,
  wsPort: 3000,
  wssPort: 4000,
  tlsPort: 8883,
  key: null,
  cert: null,
  rejectUnauthorized: true,
  credentials: null,
  brokerId: 'aedes',
  concurrency: 100,
  queueLimit: 42,
  maxClientsIdLength: 23,
  heartbeatInterval: 60000,
  connectTimeout: 30000,
  stats: false,
  statsInterval: 5000,
  mq: {
    name: 'mongodb',
    options: {
      url: 'mongodb://localhost:27017/aedes'
    }
  },
  verbose: false,
  veryVerbose: false,
  noPretty: false
}

I have two instances of Aedes-cli running, and there is a load balancer in front of them.

It uses Redis a Redis master/slave/slave cluster as as an emitter and for persistence.

I see that Redis contains only one key, 'retained'.

The scenario:

1. A subscriber connects to aedes via the load balancer, and listens on testtopic
2. A publisher connects to aedes via the load balancer, and publishes on testtopic. The subscriber receives the message.
3. I disconnect the publisher, then have it reconnect via the load balancer. It publishes on testtopic. The subscriber receives no message.

How do I troubleshoot this or isolate where the issue is?

System Information

• Aedes-cli: latest
• NodeJS: 14.5.0
• OS: Alpine 3.11.6
• Arch: x86_64

Describe the bug

To Reproduce
Steps to reproduce the behavior:

1. Run the docker-compose.yaml file
2. See error

Expected behavior
Aedes container should be running ok with Mongodb connection.

Additional context
config.js

module.exports = {
  // SERVERS
  protos: ['tcp'],
  host: '0.0.0.0',
  port: 1883,
  wsPort: 3000,
  wssPort: 4000,
  tlsPort: 8883,
  key: null,
  cert: null,
  rejectUnauthorized: false,
  // AUTHORIZER
  credentials: '/data/credentials.json',
  // AEDES
  brokerId: 'aedes-cli',
  concurrency: 100,
  queueLimit: 42,
  maxClientsIdLength: 23,
  heartbeatInterval: 60000,
  connectTimeout: 30000,
  stats: true,
  statsInterval: 5000,
  // PERSISTENCES
  persistence: {
    name: 'mongodb',
    options: {
      url: 'mongodb://127.0.0.1/aedes'
    }
  },
  mq: null,
  // LOGGER
  verbose: true,
  veryVerbose: false,
  noPretty: false
}

docker-compose.yaml

version: '3.7'
services:
 aedes:
   container_name: aedes
   image: i/aedes:latest
   restart: always
   stop_signal: SIGINT
   networks:
     - mqtt
   command: --config /data/config-persistent.js --credentials /data/credentials.json # add here the options to pass to aedes
   volumes:
     - ./:/data # map the local folder to aedes
   ports:
     - '1884:1883'
     - '3001:3000'
     - '4001:4000'
     - '8884:8883'
 mongo:
   container_name: mongo
   networks:
     - mqtt
   logging:
     driver: none
   image: mvertes/alpine-mongo
   volumes:
     - db-data:/data/db
   ports:
     - "27018:27017"
volumes:
 db-data:
   name: db-data
networks:
 mqtt:

I created my own image since the image from docker-hub is not working.

System Information
Aedes-cli: 0.3.0
NodeJS: 14.5.0
OS: Alpine 3.11.6
Arch: x86_64

Describe the bug
A user can publish in any topic even if you set a limitation in authorizePublish under credentials.json

To Reproduce
Steps to reproduce the behavior:

1. Run the latest aedes-cli server
2. Create 2 or 3 users and add access limit in topic for each user.
3. Subscribe to user1 topic
4. Publish a topic to user1 topic using user2 or user3

Expected behavior
A user should be limited to what topic a user can access to based on authorizePublish setting under credentials.json

Additional context

Help!! I understand how persistence works, it is particularly for a cluster setup. But what about mqemiiter and what are some of its use-case?

If I publish a message with QoS of >1 without any subscriber at first, will it store the messages in the broker?
And after publishing the message, then I subscribed in the same topic, will I get all the messages published?

System Information

• Aedes-cli: 0.2.4
• NodeJS: 14.5.0
• OS: Alpine 3.11.6
• Arch: x86_64

Describe the bug
I run an aedes-cli command with this two --config and --credentials but after trying to connect to the broker, it is not working. I set rejectUnauthorized to true in the config file, so I am expecting that my connection requires but it did not.

Then I try to include in the aedes-cli command --reject-unautorized and it reads it, BUT it seems it can't read the file I set in --credentials.

To Reproduce
Steps to reproduce the behavior:

1. npm install aedes-cli -g
2. run aedes --config config.js with rejectUnauthorized: true and set a value in credentials
3. Try to run a mqtt-client and connect to aedes broker without username/password
4. The broker will allow the connection

Expected behavior
Aedes are not reading both the files set in --config and --credentials

i was thinking to create data logging on database like mysql for example.
every time client publishing data using broker, so it'll store that data on table.