Generate a specific image for EMQX 5.7, configure its emqx.conf and acl.conf, support ports 1883, 8883, and 8884, with authentication on port 8884, and reject publish actions and set commands.

[zhouruiruiruiyan]

trafficstars

What happened?

Environment

1. There is a Dockerfile
2. docker-compose file
3. Under conf, acl.conf file
4. Under conf, emqx.conf file

node {
  name = "[email protected]"
  cookie = "emqxsecretcookie"
  data_dir = "data"
}

cluster {
  name = emqxcl
  discovery_strategy = manual
}

dashboard {
    listeners.http {
        bind = 18083
    }
}

authentication = [
 {
  method="post"
	headers= {content-type="application/json"}
	mechanism="password_based"
	backend="http"
	url= "http://mqtt-auth:18087/api/v1/auth",
	enable=true
	body={"username": "${username}","password": "${password}"}
 }
]

zones.devicezone.mqtt.max_packet_size=10485760

mqtt {
 client_attrs_init = [
         { expression = "iif(str_eq(zone,'devicezone'),'action','none')" set_as_attr = action},
         { expression = "iif(str_eq(zone,'devicezone'),'set','none')" set_as_attr = set},
         { expression = "iif(str_eq(zone,'devicezone'),'req','none')" set_as_attr = req} ]
 }

listeners.tcp.default{
  enable_authn = false
}

listeners.ssl.default{
  enable_authn = false
  zone = devicezone
}

listeners.ssl.auth{
  bind = "0.0.0.0:8884"
  enabled = true
  proxy_protocol = false
  enable_authn = true
  max_connections = infinity
}

Problem

The above is the environment, which will be deployed. However, we are currently encountering a problem on-site, which is sporadic. When deploying the system, a client connects to port 1883 and subscribes to a topic (because this client manages device online status, all devices appeared offline).

Problem Summary

Client connects successfully, subscribes to topic (as the QoS value after listening was not handled before, it's unknown if the subscription was truly successful)

Analysis records and log screenshots are as follows:

1. Inside the container where the client is connected, querying port 1883 shows a connection
2. But in the MQTT container, the current subscription does not exist
3. Checking the MQTT logs, the following issues were found Searching for issues, found someone posted this: https://askemq.com/t/topic/9241
4. Moreover, this problem is sporadic. I don't know what the QoS return value is when subscribing to a topic under these circumstances. Is it 128?

What did you expect to happen?

Is it possible to avoid this sporadic issue under these circumstances?

How can we reproduce it (as minimally and precisely as possible)?

No response

Anything else we need to know?

No response

EMQX version

$ ./bin/emqx_ctl broker
# paste output here

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

Log files

---

This issue was automatically translated from Chinese.

[savonarola]

Hello!

The described situation is not a bug — it happens when EMQX is started, but the authorization system has not yet been fully initialized. During this initialization period, EMQX returns 0x87 code for actions (RC_NOT_AUTHORIZED).

[zhouruiruiruiyan]

Hello!

The described situation is not a bug — it happens when EMQX is started, but the authorization system has not yet been fully initialized. During this initialization period, EMQX returns 0x87 code for actions (RC_NOT_AUTHORIZED).

那以上问题，只能在我连接时候的根据client.subscribe 的错误码回复去处理了？

[zhouruiruiruiyan]

Hello! The described situation is not a bug — it happens when EMQX is started, but the authorization system has not yet been fully initialized. During this initialization period, EMQX returns 0x87 code for actions (RC_NOT_AUTHORIZED).

那以上问题，只能在我连接时候的根据client.subscribe 的错误码回复去处理了？

或者有没有办法缩短从启动端口到emqx正常启动的时间差？